From guillaume.thouvenin@bull.net Tue Mar 1 00:21:41 2005 Received: with ECARTIS (v1.0.0; list netdev); Tue, 01 Mar 2005 00:21:48 -0800 (PST) Received: from ecfrec.frec.bull.fr (ecfrec.frec.bull.fr [129.183.4.8]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j218Ldbb024270 for ; Tue, 1 Mar 2005 00:21:40 -0800 Received: from localhost (localhost [127.0.0.1]) by ecfrec.frec.bull.fr (Postfix) with ESMTP id 001D919D90C; Tue, 1 Mar 2005 09:21:41 +0100 (CET) Received: from ecfrec.frec.bull.fr ([127.0.0.1]) by localhost (ecfrec.frec.bull.fr [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 07421-08; Tue, 1 Mar 2005 09:21:38 +0100 (CET) Received: from ecn002.frec.bull.fr (ecn002.frec.bull.fr [129.183.4.6]) by ecfrec.frec.bull.fr (Postfix) with ESMTP id 849FC19D90A; Tue, 1 Mar 2005 09:21:37 +0100 (CET) Received: from frecb000711.frec.bull.fr ([129.183.101.50]) by ecn002.frec.bull.fr (Lotus Domino Release 5.0.12) with ESMTP id 2005030109303957:2100 ; Tue, 1 Mar 2005 09:30:39 +0100 Subject: Re: [Lse-tech] Re: A common layer for Accounting packages From: Guillaume Thouvenin To: Evgeniy Polyakov Cc: hadi@cyberus.ca, Thomas Graf , Andrew Morton , Kaigai Kohei , marcelo.tosatti@cyclades.com, "David S. Miller" , jlan@sgi.com, LSE-Tech , lkml , netdev@oss.sgi.com, elsa-devel In-Reply-To: <20050228191759.6f7b656e@zanzibar.2ka.mipt.ru> References: <4221E548.4000008@ak.jp.nec.com> <20050227140355.GA23055@logos.cnet> <42227AEA.6050002@ak.jp.nec.com> <1109575236.8549.14.camel@frecb000711.frec.bull.fr> <20050227233943.6cb89226.akpm@osdl.org> <1109592658.2188.924.camel@jzny.localdomain> <20050228132051.GO31837@postel.suug.ch> <1109598010.2188.994.camel@jzny.localdomain> <20050228135307.GP31837@postel.suug.ch> <1109599803.2188.1014.camel@jzny.localdomain> <20050228142551.GQ31837@postel.suug.ch> <1109604693.1072.8.camel@jzny.localdomain> <20050228191759.6f7b656e@zanzibar.2ka.mipt.ru> Date: Tue, 01 Mar 2005 09:21:39 +0100 Message-Id: <1109665299.8594.55.camel@frecb000711.frec.bull.fr> Mime-Version: 1.0 X-Mailer: Evolution 2.0.2 X-MIMETrack: Itemize by SMTP Server on ECN002/FR/BULL(Release 5.0.12 |February 13, 2003) at 01/03/2005 09:30:39, Serialize by Router on ECN002/FR/BULL(Release 5.0.12 |February 13, 2003) at 01/03/2005 09:30:41, Serialize complete at 01/03/2005 09:30:41 Content-Transfer-Encoding: 7bit Content-Type: text/plain X-Virus-Scanned: ClamAV 0.83/733/Mon Feb 28 00:03:39 2005 on oss.sgi.com X-Virus-Scanned: by amavisd-new at frec.bull.fr X-Virus-Status: Clean X-archive-position: 2170 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: guillaume.thouvenin@bull.net Precedence: bulk X-list: netdev On Mon, 2005-02-28 at 19:17 +0300, Evgeniy Polyakov wrote: > On 28 Feb 2005 10:31:33 -0500 > jamal wrote: > > I would bet the benefit you are seeing has to do with batching rather > > than such an optimization flag. Different ballgame. > > I relooked at their code snippet, they dont even have skbs built nor > > even figured out what sock or PID. That work still needs to be done it > > seems in cn_netlink_send(). So probably all they need to do is move the > > check in cn_netlink_send() instead. This is assuming they are not > > scratching their heads with some realted complexities. > [...] > As connector author, I still doubt it worth copying several lines > from netlink_broadcast() before skb allocation in cn_netlink_send(). > Of course it is easy and can be done, but I do not see any profit here. > Atomic allocation is fast, if it succeds, but there are no groups/socket to send, > skb will be freed, if allocation fails, then group check is useless. > > I would prefer Guillaume Thouvenin as fork connector author to test > his current implementation and show that connector's cost is negligible > both with and without userspace listeners. > As far as I remember it is first entry in fork connector's TODO list. I tested without user space listeners and the cost is negligible. I will test with a user space listeners and see the results. I'm going to run the test this week after improving the mechanism that switch on/off the sending of the message. Best regards, Guillaume From gilles.quillard@bull.net Tue Mar 1 02:08:10 2005 Received: with ECARTIS (v1.0.0; list netdev); Tue, 01 Mar 2005 02:08:24 -0800 (PST) Received: from ecfrec.frec.bull.fr (ecfrec.frec.bull.fr [129.183.4.8]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j21A87Rj026474 for ; Tue, 1 Mar 2005 02:08:09 -0800 Received: from localhost (localhost [127.0.0.1]) by ecfrec.frec.bull.fr (Postfix) with ESMTP id 8031819D90A; Tue, 1 Mar 2005 11:08:07 +0100 (CET) Received: from ecfrec.frec.bull.fr ([127.0.0.1]) by localhost (ecfrec.frec.bull.fr [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 12440-01; Tue, 1 Mar 2005 11:08:05 +0100 (CET) Received: from ecn002.frec.bull.fr (ecn002.frec.bull.fr [129.183.4.6]) by ecfrec.frec.bull.fr (Postfix) with ESMTP id DF2F619D908; Tue, 1 Mar 2005 11:08:04 +0100 (CET) Received: from bull.net ([129.183.101.90]) by ecn002.frec.bull.fr (Lotus Domino Release 5.0.12) with ESMTP id 2005030111170463:2400 ; Tue, 1 Mar 2005 11:17:04 +0100 Message-ID: <42243F8D.5030302@bull.net> Date: Tue, 01 Mar 2005 11:10:21 +0100 From: Gilles Quillard User-Agent: Mozilla/5.0 (X11; U; Linux i686; fr; rv:1.6) Gecko/20040115 X-Accept-Language: fr, en MIME-Version: 1.0 To: netdev@oss.sgi.com, linux-ipv6@list.f00f.org Cc: Gerrit Huizenga , Tony Reix Subject: support of IPv6 by NFS X-MIMETrack: Itemize by SMTP Server on ECN002/FR/BULL(Release 5.0.12 |February 13, 2003) at 01/03/2005 11:17:04, Serialize by Router on ECN002/FR/BULL(Release 5.0.12 |February 13, 2003) at 01/03/2005 11:17:08, Serialize complete at 01/03/2005 11:17:08 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii; format=flowed X-Virus-Scanned: ClamAV 0.83/733/Mon Feb 28 00:03:39 2005 on oss.sgi.com X-Virus-Scanned: by amavisd-new at frec.bull.fr X-Virus-Status: Clean X-archive-position: 2171 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: gilles.quillard@bull.net Precedence: bulk X-list: netdev I'm working on the support of IPv6 by NFS and the RPC on Linux. As now preconized for the developing of new networking applications, I have developed a prototype implementation on which I have migrated all the NFS / RPC kernel stack and the user commands to use IPv6 addresses. The IPv4-mapping mechanism is used to assume the backward compatibility for IPv4 addresses which are still the most used. This works but this needs that the kernel has been compiled with IPv6, which is not mandotary. A lot of people in the Linux community do not have experience with IPv6 yet and are not ready to use it. So making it mandatory for NFS, even in a pure IPv4 network, is not easy. It seems that the most of the major distributions already provide default kernel built with IPv6, but the reference on kernel.org is still providing with the IPv6 support not set; and there are some unwillingness to make mandatory the compilation of the kernel with IPv6 to support NFS. The problem is not specific to NFS, any networking application written using IPv6 mechanisms for both IPv4 and IPv6 addresses (AF_INET6 socket opened, IPv4 addresses mapped) couldn't work without a kernel built with IPv6. Are the final users really against the use of kernels built with IPv6 ? What is preconized on Linux for the support of IPv6 ? The solution described above or the cohabitation of the two modes (struct sockaddr or sockaddr_storage used to contain either struct sockaddr_in or struct sockaddr_in6) with specific processing according to the family of the addresses ? Regards, Gilles From vda@port.imtp.ilyichevsk.odessa.ua Tue Mar 1 02:08:40 2005 Received: with ECARTIS (v1.0.0; list netdev); Tue, 01 Mar 2005 02:08:46 -0800 (PST) Received: from port.imtp.ilyichevsk.odessa.ua (168.imtp.Ilyichevsk.Odessa.UA [195.66.192.168] (may be forged)) by oss.sgi.com (8.13.0/8.13.0) with SMTP id j21A83Ak026471 for ; Tue, 1 Mar 2005 02:08:31 -0800 Received: (qmail 27030 invoked by alias); 1 Mar 2005 10:07:41 -0000 Received: from unknown (195.66.192.167) by 0 (195.66.192.168) with ESMTP; 01 Mar 2005 10:07:41 -0000 From: Denis Vlasenko To: "David S. Miller" , Quantum Scientific Subject: Re: Kernel 2.6 IPV6 Busted Date: Tue, 1 Mar 2005 12:07:33 +0200 User-Agent: KMail/1.5.4 Cc: netdev@oss.sgi.com References: <200502270928.44402.Info@Quantum-Sci.com> <200502271410.39611.Info@quantum-sci.com> <20050227133517.578884df.davem@davemloft.net> In-Reply-To: <20050227133517.578884df.davem@davemloft.net> MIME-Version: 1.0 Content-Type: text/plain; charset="koi8-r" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200503011207.34029.vda@port.imtp.ilyichevsk.odessa.ua> X-Virus-Scanned: ClamAV 0.83/733/Mon Feb 28 00:03:39 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 2172 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: vda@port.imtp.ilyichevsk.odessa.ua Precedence: bulk X-list: netdev On Sunday 27 February 2005 23:35, David S. Miller wrote: > On Sun, 27 Feb 2005 14:10:39 -0600 > Quantum Scientific wrote: > > > I am skeptical about this assertion that the whole internet needs to be hashed > > if connection tracking. > > Connection tracking and NAT broke entirely the end-to-end host > assumption that used to be valid on the internet. > > There are many very important optimizations we've had to disable > by default just in TCP alone because of NAT. I don't think future Internet will be safe enough to open corporate networks. I definitely won't do it. NAT firewall in front of my net is an absolute requirement for me. However, IPv6 in Internet won't happen tomorrow, no rush... -- vda From arnaldo.melo@gmail.com Tue Mar 1 02:13:54 2005 Received: with ECARTIS (v1.0.0; list netdev); Tue, 01 Mar 2005 02:13:59 -0800 (PST) Received: from wproxy.gmail.com (wproxy.gmail.com [64.233.184.193]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j21ADrME027574 for ; Tue, 1 Mar 2005 02:13:54 -0800 Received: by wproxy.gmail.com with SMTP id 68so1144745wri for ; Tue, 01 Mar 2005 02:13:48 -0800 (PST) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:reply-to:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:references; b=uNyMziy6JVdHC4Z4wNElXV+kXCvdAMLKOgygjI+HFHYCBYpRmHl1pX2Tm2AVTl6ZCqMxbHkKAi6GwrfjIBf8P6jPjkeIX7J1r3etHlx88w/mkNquTEm5BaYdUMtzqbgFDj0UeFLene6yecBRYUE0yJSURkO3Zwpinfs5cKk1tmA= Received: by 10.54.38.46 with SMTP id l46mr69061wrl; Tue, 01 Mar 2005 02:13:48 -0800 (PST) Received: by 10.54.10.28 with HTTP; Tue, 1 Mar 2005 02:13:48 -0800 (PST) Message-ID: <39e6f6c70503010213214101a@mail.gmail.com> Date: Tue, 1 Mar 2005 07:13:48 -0300 From: Arnaldo Carvalho de Melo Reply-To: acme@conectiva.com.br To: Stephen Torri Subject: Re: Understanding the reason for placing a tcp_sock on stack in tcp network functions Cc: netdev In-Reply-To: <1109638277.9693.15.camel@base.torri.org> Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit References: <1109638277.9693.15.camel@base.torri.org> X-Virus-Scanned: ClamAV 0.83/733/Mon Feb 28 00:03:39 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 2173 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: arnaldo.melo@gmail.com Precedence: bulk X-list: netdev This is not the case for at least some of these functions: ChangeSet@1.2035.2.55, 2005-02-22 10:48:28-08:00, acme@conectiva.com.br [TCP]: Fix excessive stack usage resulting in OOPS with 4KSTACKS. Various routines were putting a full struct tcp_sock on the local stack. What they really wanted was a subset of this information when doing TCP options processing when we only have a mini-socket (for example in SYN-RECVD and TIME_WAIT states). Therefore pull out the needed information into a sub-struct and use that in the TCP options processing routines. Signed-off-by: Arnaldo Carvalho de Melo Signed-off-by: David S. Miller On Mon, 28 Feb 2005 19:51:17 -0500, Stephen Torri wrote: > I am trying to help out reducing the stack size of functions in the > kernel. The function names and values below, with comments and > questions, was obtained of the linux-2.6 kernel kept at bkbits.net when > I did 'make checkstack'. From kaigai@ak.jp.nec.com Tue Mar 1 05:39:11 2005 Received: with ECARTIS (v1.0.0; list netdev); Tue, 01 Mar 2005 05:39:19 -0800 (PST) Received: from tyo201.gate.nec.co.jp (TYO201.gate.nec.co.jp [202.32.8.214]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j21Dd9qA005580 for ; Tue, 1 Mar 2005 05:39:10 -0800 Received: from mailgate4.nec.co.jp (mailgate53.nec.co.jp [10.7.69.184]) by tyo201.gate.nec.co.jp (8.11.7/3.7W01080315) with ESMTP id j21Dbc705138; Tue, 1 Mar 2005 22:37:38 +0900 (JST) Received: (from root@localhost) by mailgate4.nec.co.jp (8.11.7/3.7W-MAILGATE-NEC) id j21DbcZ24542; Tue, 1 Mar 2005 22:37:38 +0900 (JST) Received: from mailsv.bs1.fc.nec.co.jp (venus.hpc.bs1.fc.nec.co.jp [10.34.77.164]) by mailsv5.nec.co.jp (8.11.7/3.7W-MAILSV4-NEC) with ESMTP id j21Dbbe09898; Tue, 1 Mar 2005 22:37:37 +0900 (JST) Received: from mailsv.linux.bs1.fc.nec.co.jp (IDENT:postfix@namesv2.linux.bs1.fc.nec.co.jp [10.34.125.2]) by mailsv.bs1.fc.nec.co.jp (8.12.10/3.7W-HPC5.2F(mailsv)04081615) with ESMTP id j21DRMIK014882; Tue, 1 Mar 2005 22:27:24 +0900 (JST) Received: from [10.34.125.249] (sanma.linux.bs1.fc.nec.co.jp [10.34.125.249]) by mailsv.linux.bs1.fc.nec.co.jp (Postfix) with ESMTP id 831DF30986; Tue, 1 Mar 2005 22:37:34 +0900 (JST) Message-ID: <42247051.7070303@ak.jp.nec.com> Date: Tue, 01 Mar 2005 22:38:25 +0900 From: Kaigai Kohei User-Agent: Mozilla Thunderbird 1.0 (Windows/20041206) X-Accept-Language: ja, en-us, en MIME-Version: 1.0 To: Guillaume Thouvenin Cc: Evgeniy Polyakov , hadi@cyberus.ca, Thomas Graf , Andrew Morton , marcelo.tosatti@cyclades.com, "David S. Miller" , jlan@sgi.com, LSE-Tech , lkml , netdev@oss.sgi.com, elsa-devel Subject: Re: [Lse-tech] Re: A common layer for Accounting packages References: <4221E548.4000008@ak.jp.nec.com> <20050227140355.GA23055@logos.cnet> <42227AEA.6050002@ak.jp.nec.com> <1109575236.8549.14.camel@frecb000711.frec.bull.fr> <20050227233943.6cb89226.akpm@osdl.org> <1109592658.2188.924.camel@jzny.localdomain> <20050228132051.GO31837@postel.suug.ch> <1109598010.2188.994.camel@jzny.localdomain> <20050228135307.GP31837@postel.suug.ch> <1109599803.2188.1014.camel@jzny.localdomain> <20050228142551.GQ31837@postel.suug.ch> <1109604693.1072.8.camel@jzny.localdomain> <20050228191759.6f7b656e@zanzibar.2ka.mipt.ru> <1109665299.8594.55.camel@frecb000711.frec.bull.fr> In-Reply-To: <1109665299.8594.55.camel@frecb000711.frec.bull.fr> Content-Type: text/plain; charset=ISO-2022-JP Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV 0.83/737/Mon Feb 28 22:22:18 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 2174 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: kaigai@ak.jp.nec.com Precedence: bulk X-list: netdev Hello, > I tested without user space listeners and the cost is negligible. I will > test with a user space listeners and see the results. I'm going to run > the test this week after improving the mechanism that switch on/off the > sending of the message. I'm also trying to mesure the process-creation/destruction performance on following three environment. Archtechture: i686 / Distribution: Fedora Core 3 * Kernel Preemption is DISABLE * SMP kernel but UP-machine / Not Hyper Threading [1] 2.6.11-rc4-mm1 normal [2] 2.6.11-rc4-mm1 with PAGG based Process Accounting Module [3] 2.6.11-rc4-mm1 with fork-connector notification (it's enabled) When 367th-fork() was called after fork-connector notification, kernel was locked up. (User-Space-Listener has been also run until 366th-fork() notification was received) Does this number have any sort of means ? In my second trial, kernel was also locked up after 366th-fork() notification. Currently, I don't know its causition. Is there a person encounted it? # I wanted to say "[2] is faster than [3]" when process-grouping is enable, but the plan came off. :( Thanks. -- Linux Promotion Center, NEC KaiGai Kohei From Info@Quantum-Sci.com Tue Mar 1 05:44:41 2005 Received: with ECARTIS (v1.0.0; list netdev); Tue, 01 Mar 2005 05:44:44 -0800 (PST) Received: from xeonone.bizarre-host.com (xeonone.bizarre-host.com [70.84.110.116]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j21DieBo006171 for ; Tue, 1 Mar 2005 05:44:40 -0800 Received: from c-24-1-54-54.client.comcast.net ([24.1.54.54] helo=hydra.darkmatter.org) by xeonone.bizarre-host.com with esmtpsa (SSLv3:RC4-MD5:128) (Exim 4.44) id 1D67g2-0003ar-6S; Tue, 01 Mar 2005 13:44:42 +0000 From: Quantum Scientific To: netdev@oss.sgi.com Subject: Re: support of IPv6 by NFS Date: Tue, 1 Mar 2005 07:44:37 -0600 User-Agent: KMail/1.7.1 References: <42243F8D.5030302@bull.net> In-Reply-To: <42243F8D.5030302@bull.net> Cc: usagi-users@linux-ipv6.org helo: PowerMAC MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200503010744.38339.Info@Quantum-Sci.com> X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - xeonone.bizarre-host.com X-AntiAbuse: Original Domain - oss.sgi.com X-AntiAbuse: Originator/Caller UID/GID - [0 0] / [47 12] X-AntiAbuse: Sender Address Domain - Quantum-Sci.com X-Source: X-Source-Args: X-Source-Dir: X-Virus-Scanned: ClamAV 0.83/737/Mon Feb 28 22:22:18 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 2175 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: Info@Quantum-Sci.com Precedence: bulk X-list: netdev On Tuesday 01 March 2005 4:10, Gilles Quillard wrote: > This works but this needs that the kernel has been compiled with IPv6, > which is not mandotary. A lot of people in the Linux community do not > have experience with IPv6 yet and are not ready to use it. So making it > mandatory for NFS, even in a pure IPv4 network, is not easy. My experience is that IPV6 is extremely difficult to figure out how to set up securely, for the time being, due to lack of connection-sharing. This little fact goes completely unmentioned in ALL of the HowTos. Thank goodness for the USAGI project. Also one must become an ip6tables expert in order to have a reasonably secure firewall, because ip6tables and 6tables are dead, and Shorewall does not support IPV6 security for some reason. Another deterrant. And 80% of potential users are behind a cable/DSL 4 NATting router. There is no clarity that it is possible overcome this by either setting to DMZ, or hoping your cablemodem passes protos 41, 50 & 51. Even some tunnel operators do not know this, so I had to figure it out myself. There is no Linux 6to4 UDP tunnelling app, but there should be, because this is such a common problem. (As I understand, Teredo is Winduhs-only, and is not supported by most tunnel operators) And frankly, most Linux users' only contact with IPV6 has been the DNS AAAA browser delay seemingly inherent in some distros. Although I realize that all of us who run Linux are ostensibly uber-gurus, fact is this is a negative first experience for most, stemming from attempts by distros to encourage ppl to use it with an inoperative function, and without an obvious way to troubleshoot/repair. These issues contradict assertions that IPV6 is beneficial and easy. If I didn't have a strong motivation and lots of time, I would have chucked early-on. Speaking the actual truth, not propaganda or spin, leads to understanding of the *real* world. Carl Cook From Info@quantum-sci.com Tue Mar 1 05:50:02 2005 Received: with ECARTIS (v1.0.0; list netdev); Tue, 01 Mar 2005 05:50:05 -0800 (PST) Received: from xeonone.bizarre-host.com (xeonone.bizarre-host.com [70.84.110.116]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j21Do199006734 for ; Tue, 1 Mar 2005 05:50:02 -0800 Received: from c-24-1-54-54.client.comcast.net ([24.1.54.54] helo=hydra.darkmatter.org) by xeonone.bizarre-host.com with esmtpsa (SSLv3:RC4-MD5:128) (Exim 4.44) id 1D67lE-0003xU-4h for netdev@oss.sgi.com; Tue, 01 Mar 2005 13:50:04 +0000 From: Quantum Scientific To: netdev@oss.sgi.com Subject: Re: Kernel 2.6 IPV6 Busted Date: Tue, 1 Mar 2005 07:50:00 -0600 User-Agent: KMail/1.7.1 References: <200502270928.44402.Info@Quantum-Sci.com> <20050227133517.578884df.davem@davemloft.net> <200503011207.34029.vda@port.imtp.ilyichevsk.odessa.ua> In-Reply-To: <200503011207.34029.vda@port.imtp.ilyichevsk.odessa.ua> helo: PowerMAC MIME-Version: 1.0 Content-Type: text/plain; charset="koi8-r" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200503010750.00630.Info@quantum-sci.com> X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - xeonone.bizarre-host.com X-AntiAbuse: Original Domain - oss.sgi.com X-AntiAbuse: Originator/Caller UID/GID - [0 0] / [47 12] X-AntiAbuse: Sender Address Domain - quantum-sci.com X-Source: X-Source-Args: X-Source-Dir: X-Virus-Scanned: ClamAV 0.83/737/Mon Feb 28 22:22:18 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 2176 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: Info@quantum-sci.com Precedence: bulk X-list: netdev On Tuesday 01 March 2005 4:07, Denis Vlasenko wrote: > I don't think future Internet will be safe enough to open > corporate networks. I definitely won't do it. > NAT firewall in front of my net is an absolute requirement > for me. I agree that security is an absolute must. It's irresponsible to contend otherwise. But black-box NAT is just *simulating* what a well-made ip6tables firewall does much better. There's no reason every node can't be secure, except the expertise of the script designer. This is why I wish Shorewall would support IPV6. Carl Cook From guillaume.thouvenin@bull.net Tue Mar 1 05:54:01 2005 Received: with ECARTIS (v1.0.0; list netdev); Tue, 01 Mar 2005 05:54:05 -0800 (PST) Received: from ecfrec.frec.bull.fr (ecfrec.frec.bull.fr [129.183.4.8]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j21DrvR5007297 for ; Tue, 1 Mar 2005 05:54:00 -0800 Received: from localhost (localhost [127.0.0.1]) by ecfrec.frec.bull.fr (Postfix) with ESMTP id E67F119D90C; Tue, 1 Mar 2005 14:53:57 +0100 (CET) Received: from ecfrec.frec.bull.fr ([127.0.0.1]) by localhost (ecfrec.frec.bull.fr [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 23048-08; Tue, 1 Mar 2005 14:53:55 +0100 (CET) Received: from ecn002.frec.bull.fr (ecn002.frec.bull.fr [129.183.4.6]) by ecfrec.frec.bull.fr (Postfix) with ESMTP id 4D1A719D908; Tue, 1 Mar 2005 14:53:54 +0100 (CET) Received: from frecb000711.frec.bull.fr ([129.183.101.50]) by ecn002.frec.bull.fr (Lotus Domino Release 5.0.12) with ESMTP id 2005030115025690:2983 ; Tue, 1 Mar 2005 15:02:56 +0100 Subject: Re: [Lse-tech] Re: A common layer for Accounting packages From: Guillaume Thouvenin To: Kaigai Kohei Cc: Evgeniy Polyakov , hadi@cyberus.ca, Thomas Graf , Andrew Morton , marcelo.tosatti@cyclades.com, "David S. Miller" , jlan@sgi.com, LSE-Tech , lkml , netdev@oss.sgi.com, elsa-devel In-Reply-To: <42247051.7070303@ak.jp.nec.com> References: <4221E548.4000008@ak.jp.nec.com> <20050227140355.GA23055@logos.cnet> <42227AEA.6050002@ak.jp.nec.com> <1109575236.8549.14.camel@frecb000711.frec.bull.fr> <20050227233943.6cb89226.akpm@osdl.org> <1109592658.2188.924.camel@jzny.localdomain> <20050228132051.GO31837@postel.suug.ch> <1109598010.2188.994.camel@jzny.localdomain> <20050228135307.GP31837@postel.suug.ch> <1109599803.2188.1014.camel@jzny.localdomain> <20050228142551.GQ31837@postel.suug.ch> <1109604693.1072.8.camel@jzny.localdomain> <20050228191759.6f7b656e@zanzibar.2ka.mipt.ru> <1109665299.8594.55.camel@frecb000711.frec.bull.fr> <42247051.7070303@ak.jp.nec.com> Date: Tue, 01 Mar 2005 14:53:56 +0100 Message-Id: <1109685236.8594.75.camel@frecb000711.frec.bull.fr> Mime-Version: 1.0 X-Mailer: Evolution 2.0.2 X-MIMETrack: Itemize by SMTP Server on ECN002/FR/BULL(Release 5.0.12 |February 13, 2003) at 01/03/2005 15:02:56, Serialize by Router on ECN002/FR/BULL(Release 5.0.12 |February 13, 2003) at 01/03/2005 15:02:59, Serialize complete at 01/03/2005 15:02:59 Content-Transfer-Encoding: 7bit Content-Type: text/plain X-Virus-Scanned: ClamAV 0.83/737/Mon Feb 28 22:22:18 2005 on oss.sgi.com X-Virus-Scanned: by amavisd-new at frec.bull.fr X-Virus-Status: Clean X-archive-position: 2177 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: guillaume.thouvenin@bull.net Precedence: bulk X-list: netdev On Tue, 2005-03-01 at 22:38 +0900, Kaigai Kohei wrote: > > I tested without user space listeners and the cost is negligible. I will > > test with a user space listeners and see the results. I'm going to run > > the test this week after improving the mechanism that switch on/off the > > sending of the message. > > I'm also trying to mesure the process-creation/destruction performance on following three environment. > Archtechture: i686 / Distribution: Fedora Core 3 > * Kernel Preemption is DISABLE > * SMP kernel but UP-machine / Not Hyper Threading > [1] 2.6.11-rc4-mm1 normal > [2] 2.6.11-rc4-mm1 with PAGG based Process Accounting Module > [3] 2.6.11-rc4-mm1 with fork-connector notification (it's enabled) > > When 367th-fork() was called after fork-connector notification, kernel was locked up. > (User-Space-Listener has been also run until 366th-fork() notification was received) I don't see this limit on my computer. I'm currently running the lmbench with a new fork connector patch (one that enable/disable fork connector) on an SMP computer. I will send results and the new patch tomorrow because the test takes a while... I'm using a small patch provided by Evgeniy and not included in the 2.6.11-rc4-mm1 tree. Best regards, Guillaume --- orig/connector.c +++ mod/connector.c @@ -168,12 +168,11 @@ group = NETLINK_CB((skb)).groups; msg = (struct cn_msg *)NLMSG_DATA(nlh); - if (msg->len != nlh->nlmsg_len - sizeof(*msg) - sizeof(*nlh)) { + if (NLMSG_SPACE(msg->len + sizeof(*msg)) != nlh->nlmsg_len) { printk(KERN_ERR "skb does not have enough length: " - "requested msg->len=%u[%u], nlh->nlmsg_len=%u[%u], skb->len=%u[must be %u].\n", - msg->len, NLMSG_SPACE(msg->len), - nlh->nlmsg_len, nlh->nlmsg_len - sizeof(*nlh), - skb->len, msg->len + sizeof(*msg)); + "requested msg->len=%u[%u], nlh->nlmsg_len=%u, skb->len=%u.\n", + msg->len, NLMSG_SPACE(msg->len + sizeof(*msg)), + nlh->nlmsg_len, skb->len); kfree_skb(skb); return -EINVAL; } From buytenh@wantstofly.org Tue Mar 1 05:59:33 2005 Received: with ECARTIS (v1.0.0; list netdev); Tue, 01 Mar 2005 05:59:37 -0800 (PST) Received: from xi.wantstofly.org (alephnull.demon.nl [212.238.201.82]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j21DxWXg007991 for ; Tue, 1 Mar 2005 05:59:33 -0800 Received: by xi.wantstofly.org (Postfix, from userid 500) id 1BE4C2B0EC; Tue, 1 Mar 2005 14:59:31 +0100 (MET) Date: Tue, 1 Mar 2005 14:59:31 +0100 From: Lennert Buytenhek To: netdev@oss.sgi.com Cc: hadi@cyberus.ca, robert.olsson@data.slu.se Subject: e1000 problem with NAPI? Message-ID: <20050301135931.GA14610@xi.wantstofly.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.4.1i X-Virus-Scanned: ClamAV 0.83/737/Mon Feb 28 22:22:18 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 2178 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: buytenh@wantstofly.org Precedence: bulk X-list: netdev Hi all, I'm seeing some strange issues with an e1000 NIC. I'm flooding it with tinygrams from a packet generator and then abruptly stop the generator. The last few packets from the burst don't come through until after two seconds. Sometimes there are multiple trailing bursts, each of them separated by two seconds. For example: (The low 24 bits of the destination address are set to the packet sequence number by the generator.) 14:44:19.649874 IP 10.10.0.0 > 1.4.10.11: [|tcp] 14:44:19.649878 IP 10.10.0.0 > 1.4.10.12: [|tcp] 14:44:19.649882 IP 10.10.0.0 > 1.4.10.13: [|tcp] 14:44:19.649887 IP 10.10.0.0 > 1.4.10.14: [|tcp] 14:44:19.649891 IP 10.10.0.0 > 1.4.10.15: [|tcp] 14:44:19.649895 IP 10.10.0.0 > 1.4.10.16: [|tcp] 14:44:19.649899 IP 10.10.0.0 > 1.4.10.17: [|tcp] 14:44:21.650293 IP 10.10.0.0 > 1.4.10.18: [|tcp] <=== delayed 14:44:21.650303 IP 10.10.0.0 > 1.4.10.19: [|tcp] 14:44:21.650308 IP 10.10.0.0 > 1.4.10.20: [|tcp] 14:44:21.650312 IP 10.10.0.0 > 1.4.10.21: [|tcp] 14:44:21.650316 IP 10.10.0.0 > 1.4.10.22: [|tcp] 14:44:21.650320 IP 10.10.0.0 > 1.4.10.23: [|tcp] 14:44:21.650324 IP 10.10.0.0 > 1.4.10.24: [|tcp] 14:44:21.650328 IP 10.10.0.0 > 1.4.10.25: [|tcp] 14:44:21.650332 IP 10.10.0.0 > 1.4.10.26: [|tcp] I wrote the packet generator code myself (ixp2400 platform), but I've verified that the packets do leave the generator back-to-back. What's also strange is that when these trailing bursts come in, the interface statistics counters do not change -- the packets in the trailing bursts have already been counted by the time they show up in tcpdump. Jamal suspects a NAPI 'rotting packet' issue, which doesn't sound all that unlikely. (Oh, this is kernel 2.6.10-something with e1000 driver version "5.5.4-k2-NAPI".) Ideas? cheers, Lennert From johnpol@2ka.mipt.ru Tue Mar 1 06:13:16 2005 Received: with ECARTIS (v1.0.0; list netdev); Tue, 01 Mar 2005 06:13:19 -0800 (PST) Received: from vocord.com (dea.vocord.ru [217.67.177.50]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j21EDDTr008706 for ; Tue, 1 Mar 2005 06:13:15 -0800 Received: from uganda.factory.vocord.ru (uganda.factory.vocord.ru [192.168.0.48]) by vocord.com (8.13.1/8.13.1) with ESMTP id j21EBYkb032671; Tue, 1 Mar 2005 17:11:34 +0300 Subject: Re: [Lse-tech] Re: A common layer for Accounting packages From: Evgeniy Polyakov Reply-To: johnpol@2ka.mipt.ru To: Guillaume Thouvenin Cc: Kaigai Kohei , hadi@cyberus.ca, Thomas Graf , Andrew Morton , marcelo.tosatti@cyclades.com, "David S. Miller" , jlan@sgi.com, LSE-Tech , lkml , netdev@oss.sgi.com, elsa-devel In-Reply-To: <1109685236.8594.75.camel@frecb000711.frec.bull.fr> References: <4221E548.4000008@ak.jp.nec.com> <20050227140355.GA23055@logos.cnet> <42227AEA.6050002@ak.jp.nec.com> <1109575236.8549.14.camel@frecb000711.frec.bull.fr> <20050227233943.6cb89226.akpm@osdl.org> <1109592658.2188.924.camel@jzny.localdomain> <20050228132051.GO31837@postel.suug.ch> <1109598010.2188.994.camel@jzny.localdomain> <20050228135307.GP31837@postel.suug.ch> <1109599803.2188.1014.camel@jzny.localdomain> <20050228142551.GQ31837@postel.suug.ch> <1109604693.1072.8.camel@jzny.localdomain> <20050228191759.6f7b656e@zanzibar.2ka.mipt.ru> <1109665299.8594.55.camel@frecb000711.frec.bull.fr> <42247051.7070303@ak.jp.nec.com> <1109685236.8594.75.camel@frecb000711.frec.bull.fr> Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="=-T+HcrVsRNtFuhZ2bJkzx" Organization: MIPT Date: Tue, 01 Mar 2005 17:17:57 +0300 Message-Id: <1109686677.28266.66.camel@uganda> Mime-Version: 1.0 X-Mailer: Evolution 2.0.2 (2.0.2-3) X-Virus-Scanned: ClamAV 0.83/737/Mon Feb 28 22:22:18 2005 on oss.sgi.com X-Virus-Scanned: ClamAV 0.80/690/Fri Jan 28 15:09:45 2005 clamav-milter version 0.80j on dea.vocord.com X-Virus-Status: Clean X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-1.4 (vocord.com [192.168.0.1]); Tue, 01 Mar 2005 17:11:37 +0300 (MSK) X-archive-position: 2179 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: johnpol@2ka.mipt.ru Precedence: bulk X-list: netdev --=-T+HcrVsRNtFuhZ2bJkzx Content-Type: text/plain Content-Transfer-Encoding: quoted-printable On Tue, 2005-03-01 at 14:53 +0100, Guillaume Thouvenin wrote: > On Tue, 2005-03-01 at 22:38 +0900, Kaigai Kohei wrote: > > > I tested without user space listeners and the cost is negligible. I w= ill > > > test with a user space listeners and see the results. I'm going to ru= n > > > the test this week after improving the mechanism that switch on/off t= he > > > sending of the message. > >=20 > > I'm also trying to mesure the process-creation/destruction performance = on following three environment. > > Archtechture: i686 / Distribution: Fedora Core 3 > > * Kernel Preemption is DISABLE > > * SMP kernel but UP-machine / Not Hyper Threading > > [1] 2.6.11-rc4-mm1 normal > > [2] 2.6.11-rc4-mm1 with PAGG based Process Accounting Module > > [3] 2.6.11-rc4-mm1 with fork-connector notification (it's enabled) > >=20 > > When 367th-fork() was called after fork-connector notification, kernel = was locked up. > > (User-Space-Listener has been also run until 366th-fork() notification = was received) >=20 > I don't see this limit on my computer. I'm currently running the lmbench > with a new fork connector patch (one that enable/disable fork connector) > on an SMP computer. I will send results and the new patch tomorrow > because the test takes a while... >=20 > I'm using a small patch provided by Evgeniy and not included in the > 2.6.11-rc4-mm1 tree. 2.6.11-rc4-mm1 tree does not have the latest connector. Various fixes were added, not only that. I run the latest patch Guillaume sent to me(with small updates),=20 fork bomb with more than 100k forks passed already without any freeze. I do not have numbers thought. > Best regards, > Guillaume >=20 > --- orig/connector.c > +++ mod/connector.c > @@ -168,12 +168,11 @@ > group =3D NETLINK_CB((skb)).groups; > msg =3D (struct cn_msg *)NLMSG_DATA(nlh); >=20 > - if (msg->len !=3D nlh->nlmsg_len - sizeof(*msg) - sizeof(*nlh)) { > + if (NLMSG_SPACE(msg->len + sizeof(*msg)) !=3D nlh->nlmsg_len) { > printk(KERN_ERR "skb does not have enough length: " > - "requested msg->len=3D%u[%u], nlh->nlmsg_= len=3D%u[%u], skb->len=3D%u[must be %u].\n", > - msg->len, NLMSG_SPACE(msg->len), > - nlh->nlmsg_len, nlh->nlmsg_len - sizeof(*= nlh), > - skb->len, msg->len + sizeof(*msg)); > + "requested msg->len=3D%u[%u], nlh->nlmsg_= len=3D%u, skb->len=3D%u.\n", > + msg->len, NLMSG_SPACE(msg->len + sizeof(*= msg)), > + nlh->nlmsg_len, skb->len); > kfree_skb(skb); > return -EINVAL; > } >=20 --=20 Evgeniy Polyakov Crash is better than data corruption -- Arthur Grabowski --=-T+HcrVsRNtFuhZ2bJkzx Content-Type: application/pgp-signature; name=signature.asc Content-Description: This is a digitally signed message part -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.6 (GNU/Linux) iD8DBQBCJHmVIKTPhE+8wY0RArr4AJ43/qPErT1WsYHIXDcSs3Z4g7tKCwCfSdjl s1xDdJ3ZZYS4zmbpUe3+J1M= =U897 -----END PGP SIGNATURE----- --=-T+HcrVsRNtFuhZ2bJkzx-- From jeroen@unfix.org Tue Mar 1 07:08:41 2005 Received: with ECARTIS (v1.0.0; list netdev); Tue, 01 Mar 2005 07:08:48 -0800 (PST) Received: from noc.sixxs.net (postfix@noc.sixxs.net [213.197.29.32]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j21F8eab010031 for ; Tue, 1 Mar 2005 07:08:41 -0800 Received: from localhost (localhost [127.0.0.1]) by noc.sixxs.net (Postfix) with ESMTP id 6838E24061; Tue, 1 Mar 2005 16:08:38 +0100 (CET) Received: from noc.sixxs.net ([127.0.0.1]) by localhost (noc [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 11146-07; Tue, 1 Mar 2005 16:08:37 +0100 (CET) Received: from firenze.zurich.ibm.com (pat.zurich.ibm.com [195.176.20.45]) (using SSLv3 with cipher RC4-MD5 (128/128 bits)) (No client certificate requested) by noc.sixxs.net (Postfix) with ESMTP id 8984F2400D; Tue, 1 Mar 2005 16:08:37 +0100 (CET) Subject: Re: (usagi-users 03222) Re: support of IPv6 by NFS From: Jeroen Massar To: usagi-users@linux-ipv6.org Cc: netdev@oss.sgi.com In-Reply-To: <200503010744.38339.Info@Quantum-Sci.com> References: <42243F8D.5030302@bull.net> <200503010744.38339.Info@Quantum-Sci.com> Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="=-CXIFG70UQeVul0i4ytiq" Organization: Unfix Date: Tue, 01 Mar 2005 16:08:32 +0100 Message-Id: <1109689712.17484.6.camel@firenze.zurich.ibm.com> Mime-Version: 1.0 X-Mailer: Evolution 2.1.5 (2.1.5-1) X-Virus-Scanned: ClamAV 0.83/737/Mon Feb 28 22:22:18 2005 on oss.sgi.com X-Virus-Scanned: noc.sixxs.net - http://www.sixxs.net X-Virus-Status: Clean X-archive-position: 2180 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: jeroen@unfix.org Precedence: bulk X-list: netdev --=-CXIFG70UQeVul0i4ytiq Content-Type: text/plain Content-Transfer-Encoding: quoted-printable On Tue, 2005-03-01 at 07:44 -0600, Quantum Scientific wrote:=20 >On Tuesday 01 March 2005 4:10, Gilles Quillard wrote: >> This works but this needs that the kernel has been compiled with IPv6,=20 >> which is not mandotary. A lot of people in the Linux community do not=20 >> have experience with IPv6 yet and are not ready to use it. So making it=20 >> mandatory for NFS, even in a pure IPv4 network, is not easy. > >My experience is that IPV6 is extremely difficult to figure out how to set= up=20 >securely, for the time being, due to lack of connection-sharing. NAT is not a firewall. Get that into your brain. And indeed there is no Linux firewalling code yet, in the mainstream that can do connection tracking. There is no non-EFT Cisco PIX code for this either. The only OS that can do it is the various BSD's. >And 80% of potential users are behind a cable/DSL 4 NATting router. There= is=20 >no clarity that it is possible overcome this by either setting to DMZ, or=20 >hoping your cablemodem passes protos 41, 50 & 51. Even some tunnel operat= ors=20 >do not know this, so I had to figure it out myself. Freenet6/Hexago have a UDP protocol and SixXS has AYIYA. Works perfectly fine. In most cases, I know from quite a bit of experience, proto-41 forwarding works very well in most of these DSL boxes. > There is no Linux 6to4=20 >UDP tunnelling app, but there should be, because this is such a common=20 >problem. (As I understand, Teredo is Winduhs-only, and is not supported b= y=20 >most tunnel operators) The protocol for Teredo is open and can be implemented at will: http://www-rp.lip6.fr/teredo/ http://www.simphalempin.com/dev/miredo http://people.via.ecp.fr/~rem/miredo/?C=3DN;O=3DD First couple of hits when doing a google on "Teredo BSD", or for you to click as that might be difficult: http://www.google.com/search?q=3Dteredo+bsd >And frankly, most Linux users' only contact with IPV6 has been the DNS AAA= A=20 >browser delay seemingly inherent in some distros. Although I realize that= =20 >all of us who run Linux are ostensibly uber-gurus, fact is this is a negat= ive=20 >first experience for most, stemming from attempts by distros to encourage = ppl=20 >to use it with an inoperative function, and without an obvious way to=20 >troubleshoot/repair. I can clearly assume that you are not part of the 'ostensibly uber-gurus' you try to mention.=20 > >These issues contradict assertions that IPV6 is beneficial and easy. That you don't understand it is your problem ;) >If I=20 >didn't have a strong motivation and lots of time, I would have chucked=20 >early-on. Speaking the actual truth, not propaganda or spin, leads to=20 >understanding of the *real* world. Loads of people seem to have no problem at all with IPv6, getting it up and running and actually using it for a lot of traffic. That fact that you are only complaining, without doing any actual research, typing two words in google, says enough. You are not even capable of configuring your mailer properly to include your own name, the field is not called "Realname" for nothing... Greets, Jeroen --=-CXIFG70UQeVul0i4ytiq Content-Type: application/pgp-signature; name=signature.asc Content-Description: This is a digitally signed message part -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.0 (GNU/Linux) Comment: Jeroen Massar / http://unfix.org/~jeroen/ iD8DBQBCJIVwKaooUjM+fCMRAkLoAJ9m855fpWBV+bmKxXeM6dUWnhlIfgCdF/ei uKA8xiFscO2H3ZlT2IMQceo= =HzTF -----END PGP SIGNATURE----- --=-CXIFG70UQeVul0i4ytiq-- From devesh.agrawal@gmail.com Tue Mar 1 07:15:33 2005 Received: with ECARTIS (v1.0.0; list netdev); Tue, 01 Mar 2005 07:15:37 -0800 (PST) Received: from wproxy.gmail.com (wproxy.gmail.com [64.233.184.194]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j21FFWL1010602 for ; Tue, 1 Mar 2005 07:15:32 -0800 Received: by wproxy.gmail.com with SMTP id 68so1284370wra for ; Tue, 01 Mar 2005 07:15:26 -0800 (PST) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:reply-to:to:subject:mime-version:content-type:content-transfer-encoding; b=Bb99FIeCdj+emHxi/G13f7Vxs6zw+rxzouvoSnxP07DTd/2Wj+fMtX57PAtpFk0qdAhoPdvMo5WfgjDpOp4zsLt2h2R55nXEaP+MRO7ghfgcH9R3LG+lqQzPV9e4Q8xaeGrj6gGyJkxeSh6Cj3Zpu7++16LiP1tfrt2xEy799Bs= Received: by 10.54.11.73 with SMTP id 73mr22086wrk; Tue, 01 Mar 2005 07:15:19 -0800 (PST) Received: by 10.54.28.48 with HTTP; Tue, 1 Mar 2005 07:15:18 -0800 (PST) Message-ID: Date: Tue, 1 Mar 2005 20:45:18 +0530 From: Devesh Agrawal Reply-To: Devesh Agrawal To: netdev@oss.sgi.com Subject: Kernel panic when an icmp packet is generated in response to an ARP failure Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV 0.83/737/Mon Feb 28 22:22:18 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 2181 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: devesh.agrawal@gmail.com Precedence: bulk X-list: netdev Hi, The protocol I am writing is a source routing based protocol called Meghadoot similar to the wireless networks DSR, as written by Alex Song (http://piconet.sf.net). I am using netfilter, I am using linux 2.6.5 (supplied along with FC2), without the SMP and PREEMPTIBLE options. I have a seperate header called MeghHeader, which carries the source route and it comes b/w the iph and the tcph. I am using an isolated machine called A from which I send out ping packets. Here is what is happening: In my local_out_handler, I cruft the source routing header, route the packet using ip_route_output (which causes an arp request to be send). And then call the output routine passed to me by netfilter (okfn). As the arp request obviously will fail, and hence skb->dst->neighbour->output points to neigh_resolve_output, which sends the arp request, and queues the skb in the neigh->arp_queue, the neigh->state is NUD_INCOMPLETE. When neigh_timer_handle fires, it walks thru the arp_queue and sends an icmp dest unreach for each of the queued skb's thru the ipv4_link_failure function. Please note that my local_out_handler is serialized by having a spinlock at its entry. Hence my debugging output looks something like this: Entering local out with icmp packet type 8, code 0 : The normal ping packet, in pings context. ... Some more of the above Entering local out with icmp packet type 3, code 1 : The icmp dest unreach, given off in the TIMER_SOFTIRQ context, when neigh_timer_handler is fired. ...And then some more of the two... Now this is something, that has totally freaked me out .... I sometimes get an icmp skb in my local out handler with some invalid type say like 234 etc, As a hack in my local_out_handler, I return NF_DROP ('cos I noticed that icmp_send, assumes that the type is correct before indexing into the icmp table). As soon as my local_out_handler exits with this screwed up skb,(Again, my local_out_handler is not reentrant, it is locked by a spinlock) I get either a bad eip or a null eip somewhere in the neigh_timer_handler. The stack dump looks like this. (The full debugging output, including the oops message is available online at http://www.cs.iitm.ernet.in/~dvagr/helpme): I am trying to ping the machine 10.6.6.2, whose route is hardcoded into 10.6.6.5. <------------ My debugging output begins ----------------> Meghadoot: ****************** Entering local out ******************* function addr 224c483, dst output 224a842<2> Meghadoot: okfn points to :Address: 224c483, name: dst_output, offset: 0,size: 1c, module: Kernel<2>, Meghadoot: skb->dst->output points to : Address: 224a842, name: ip_output, offset: 0,size: 5c, module: Kernel<2> Meghadoot: local out handler, dumping call trace [<22926360>] local_out_handler+0x4e/0x296 [megh_linux] [<0224c483>] dst_output+0x0/0x1c [<0224a842>] ip_output+0x0/0x5c [<0223c787>] nf_iterate+0x40/0x89 [<0224c483>] dst_output+0x0/0x1c [<0223ca91>] nf_hook_slow+0x90/0x101 [<0224c483>] dst_output+0x0/0x1c [<0224c0dc>] ip_push_pending_frames+0x2cf/0x37c [<0224c483>] dst_output+0x0/0x1c [<0226686f>] icmp_send+0x35e/0x397 [<02107352>] do_IRQ+0x134/0x169 [<02239dc9>] neigh_timer_handler+0x0/0x112 [<0211de03>] run_timer_softirq+0x10b/0x12a [<0211af6d>] __do_softirq+0x35/0x73 [<021078f5>] do_softirq+0x46/0x4d ======================= [<0210737b>] do_IRQ+0x15d/0x169 [<0210403b>] default_idle+0x23/0x26 [<0210408c>] cpu_idle+0x1f/0x34 [<02318612>] start_kernel+0x174/0x176 Meghadoot: In context: in_softirq:1024,in_irq:0,in_interrupt:1024<2> Meghadoot: local out called in context of swapper<2> Meghadoot: finished dumping stack ....<2> Meghadoot: Entered local Out handler,printing skb info<2> Meghadoot: Local out handler , icmp type is 0, code is 0<2>s:127.0.0.1 d:127.0.0.1 and protocol is 1<2> (Valid icmph->type, I return NF_DROP if icmph->type > NR_ICMP_TYPES ) Meghadoot: Got Locally destined packet (ie iph->daddr = MYIPADDR )<2>, returned NF_ACCEPT. Meghadoot: ****************** Exiting local out *******************<1>Unable to handle kernel NULL pointer dereference at virtual address 00000000 printing eip: 00000000 *pde = 00000000 Oops: 0000 [#1] CPU: 0 EIP: 0060:[<00000000>] Not tainted EFLAGS: 00010206 (2.6.5-1.358) EIP is at 0x0 eax: 00000000 ebx: 00000000 ecx: 0000b404 edx: 00000007 esi: 00000000 edi: 00000000 ebp: 00000000 esp: 02344fb0 ds: 007b es: 007b ss: 0068 Process swapper (pid: 0, threadinfo=02344000 task=022c5aa0) Stack: 00020000 00000000 00594400 1c8e4900 00000056 02239dc9 1c8e495c 0211de03 02344fd0 02344fd0 0234007b 00000001 02369428 0000000a 02316000 0211af6d 02317f94 00000046 00000000 021078f5 Call Trace: [<02239dc9>] neigh_timer_handler+0x0/0x112 [<0211de03>] run_timer_softirq+0x10b/0x12a [<0211af6d>] __do_softirq+0x35/0x73 [<021078f5>] do_softirq+0x46/0x4d ======================= [<0210737b>] do_IRQ+0x15d/0x169 [<0210403b>] default_idle+0x23/0x26 [<0210408c>] cpu_idle+0x1f/0x34 [<02318612>] start_kernel+0x174/0x176 Code: Bad EIP value. <0>Kernel panic: Fatal exception in interrupt In interrupt handler - not syncing <---------------------- End of debugging dump ---------------------> I will be really greateful, if any one of you could help me out with this. Please. Expecting your reply eagerly. Regards, Devesh From yoshfuji@linux-ipv6.org Tue Mar 1 07:18:03 2005 Received: with ECARTIS (v1.0.0; list netdev); Tue, 01 Mar 2005 07:18:08 -0800 (PST) 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 j21FI2fE011108 for ; Tue, 1 Mar 2005 07:18:02 -0800 Received: from localhost (localhost [127.0.0.1]) by yue.st-paulia.net (Postfix) with ESMTP id 3E6E633CC2; Wed, 2 Mar 2005 00:19:28 +0900 (JST) Date: Wed, 02 Mar 2005 00:19:27 +0900 (JST) Message-Id: <20050302.001927.42589445.yoshfuji@linux-ipv6.org> To: Info@Quantum-Sci.com Cc: netdev@oss.sgi.com, usagi-users@linux-ipv6.org Subject: Re: (usagi-users 03222) Re: support of IPv6 by NFS From: YOSHIFUJI Hideaki / =?iso-2022-jp?B?GyRCNUhGIzFRTEAbKEI=?= In-Reply-To: <200503010744.38339.Info@Quantum-Sci.com> References: <42243F8D.5030302@bull.net> <200503010744.38339.Info@Quantum-Sci.com> Organization: USAGI Project X-URL: http://www.yoshifuji.org/%7Ehideaki/ X-Fingerprint: 9022 65EB 1ECF 3AD1 0BDF 80D8 4807 F894 E062 0EEA X-PGP-Key-URL: http://www.yoshifuji.org/%7Ehideaki/hideaki@yoshifuji.org.asc X-Face: "5$Al-.M>NJ%a'@hhZdQm:."qn~PA^gq4o*>iCFToq*bAi#4FRtx}enhuQKz7fNqQz\BYU] $~O_5m-9'}MIs`XGwIEscw;e5b>n"B_?j/AkL~i/MEaZBLP X-Mailer: Mew version 2.2 on Emacs 20.7 / Mule 4.1 (AOI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV 0.83/737/Mon Feb 28 22:22:18 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 2182 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 <200503010744.38339.Info@Quantum-Sci.com> (at Tue, 1 Mar 2005 07:44:37 -0600), Quantum Scientific says: > And frankly, most Linux users' only contact with IPV6 has been the DNS AAAA > browser delay seemingly inherent in some distros. Although I realize that > all of us who run Linux are ostensibly uber-gurus, fact is this is a negative > first experience for most, stemming from attempts by distros to encourage ppl > to use it with an inoperative function, and without an obvious way to > troubleshoot/repair. : > These issues contradict assertions that IPV6 is beneficial and easy. If I > didn't have a strong motivation and lots of time, I would have chucked > early-on. Speaking the actual truth, not propaganda or spin, leads to > understanding of the *real* world. Well, we really need to analyse and solve "negative experiences" and berries against IPv6, and the "IPv6-Fix" Project started: http://v6fix.net Please report any incidents to . We might need to list up pitwalls the people may have and tips to solve those issues. Thank you. -- Hideaki YOSHIFUJI @ USAGI Project GPG FP: 9022 65EB 1ECF 3AD1 0BDF 80D8 4807 F894 E062 0EEA From afleming@freescale.com Tue Mar 1 07:22:08 2005 Received: with ECARTIS (v1.0.0; list netdev); Tue, 01 Mar 2005 07:22:12 -0800 (PST) Received: from az33egw02.freescale.net (az33egw02.freescale.net [192.88.158.103]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j21FM7F4011681 for ; Tue, 1 Mar 2005 07:22:08 -0800 Received: from az33smr02.freescale.net (az33smr02.freescale.net [10.64.34.200]) by az33egw02.freescale.net (8.12.11/az33egw02) with ESMTP id j21FN9JI008654; Tue, 1 Mar 2005 08:23:09 -0700 (MST) Received: from [10.82.17.56] ([10.82.17.56]) by az33smr02.freescale.net (8.13.1/8.13.0) with ESMTP id j21FN5Kt003863; Tue, 1 Mar 2005 09:23:05 -0600 (CST) Mime-Version: 1.0 (Apple Message framework v619.2) To: Netdev Message-Id: <3a958240e12af10ef6777f908abfe682@freescale.com> Content-Type: multipart/mixed; boundary=Apple-Mail-5-386825446 Cc: Jeff Garzik Subject: RFC new ethtool command From: Andy Fleming Date: Tue, 1 Mar 2005 09:22:07 -0600 X-Mailer: Apple Mail (2.619.2) X-Virus-Scanned: ClamAV 0.83/737/Mon Feb 28 22:22:18 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 2183 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: afleming@freescale.com Precedence: bulk X-list: netdev --Apple-Mail-5-386825446 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII; format=flowed I propose adding a new command to ethtool which allows ethernet drivers to specify a command list. A command list would consist of a name/value pair, conforming to the cmdline_info structure already present in ethtool. I see two immediate benefits of this system: 1) controllers which have "cutting-edge", or at least unusual, features can easily add support for these features. As an example, the 85xx allows the ethernet controller's DMA engine to allocate and/or lock buffer descriptors into the L2 cache of the processor. Using this method, a command could be created which is specific to that driver which allows users to turn this feature on or off. 2) When debugging a new driver, or a new feature for an old driver, it is easy to add a quick interface to change the testing parameters without having to add new /proc entries. Three patches follow; the first allows ethtool to use this new feature, the second allows the kernel to invoke the new feature, and the third is an example of how the gianfar driver uses this feature to expose failure testing features in the PHY-level code (note that this third patch is not a final version. It also contains a few elements from the PHY abstraction patch, which can be ignored for the purposes of this discussion). Andy Fleming Open Source Software Freescale Semiconductor, Inc --Apple-Mail-5-386825446 Content-Transfer-Encoding: 7bit Content-Type: application/octet-stream; x-unix-mode=0644; name="xcmd-gfar.patch" Content-Disposition: attachment; filename=xcmd-gfar.patch diff -Nru a/drivers/net/gianfar_ethtool.c b/drivers/net/gianfar_ethtool.c --- a/drivers/net/gianfar_ethtool.c 2005-02-28 17:57:34 -06:00 +++ b/drivers/net/gianfar_ethtool.c 2005-02-28 17:57:34 -06:00 @@ -118,6 +116,12 @@ "tx-fragmented-frames", }; +static struct cmdline_info gfar_xcmds[] = { + {"phytest", CMDL_BOOL, NULL, NULL}, + {"ptest_reg", CMDL_INT, NULL, NULL}, + {"ptest_read", CMDL_BOOL, NULL, NULL}, +}; + /* Fill in an array of 64-bit statistics from various sources. * This array will be appended to the end of the ethtool_stats * structure, and returned to user space @@ -179,34 +183,75 @@ drvinfo->testinfo_len = 0; drvinfo->regdump_len = 0; drvinfo->eedump_len = 0; + drvinfo->n_xcmds = (sizeof(gfar_xcmds)/sizeof(gfar_xcmds[0])); +} + + +static int gfar_ssettings(struct net_device *dev, struct ethtool_cmd *cmd) +{ + struct gfar_private *priv = netdev_priv(dev); + struct phy_device *phydev = priv->phydev; + + if (NULL == phydev) + return -ENODEV; + + /* We make sure that we don't pass unsupported + * values in to the PHY */ + cmd->advertising &= phydev->supported; + + /* Verify the settings we care about. */ + if (cmd->autoneg != AUTONEG_ENABLE && cmd->autoneg != AUTONEG_DISABLE) + return -EINVAL; + + if (cmd->autoneg == AUTONEG_ENABLE && cmd->advertising == 0) + return -EINVAL; + + if (cmd->autoneg == AUTONEG_DISABLE + && ((cmd->speed != SPEED_1000 + && cmd->speed != SPEED_100 + && cmd->speed != SPEED_10) + || (cmd->duplex != DUPLEX_HALF + && cmd->duplex != DUPLEX_FULL))) + return -EINVAL; + + phydev->autoneg = cmd->autoneg; + + phydev->speed = cmd->speed; + + phydev->advertising = cmd->advertising; + + if (AUTONEG_ENABLE == cmd->autoneg) + phydev->advertising |= ADVERTISED_Autoneg; + else + phydev->advertising &= ~ADVERTISED_Autoneg; + + phydev->duplex = cmd->duplex; + + /* Restart the PHY */ + phy_start_aneg(phydev); + + return 0; } /* Return the current settings in the ethtool_cmd structure */ int gfar_gsettings(struct net_device *dev, struct ethtool_cmd *cmd) { struct gfar_private *priv = netdev_priv(dev); - uint gigabit_support = - priv->einfo->flags & GFAR_HAS_GIGABIT ? SUPPORTED_1000baseT_Full : 0; - uint gigabit_advert = - priv->einfo->flags & GFAR_HAS_GIGABIT ? ADVERTISED_1000baseT_Full: 0; - - cmd->supported = (SUPPORTED_10baseT_Half - | SUPPORTED_100baseT_Half - | SUPPORTED_100baseT_Full - | gigabit_support | SUPPORTED_Autoneg); - - /* For now, we always advertise everything */ - cmd->advertising = (ADVERTISED_10baseT_Half - | ADVERTISED_100baseT_Half - | ADVERTISED_100baseT_Full - | gigabit_advert | ADVERTISED_Autoneg); + struct phy_device *phydev = priv->phydev; + + if (NULL == phydev) + return -ENODEV; + + cmd->supported = phydev->supported; + + cmd->advertising = phydev->advertising; - cmd->speed = priv->mii_info->speed; - cmd->duplex = priv->mii_info->duplex; + cmd->speed = phydev->speed; + cmd->duplex = phydev->duplex; cmd->port = PORT_MII; - cmd->phy_address = priv->mii_info->mii_id; + cmd->phy_address = phydev->addr; cmd->transceiver = XCVR_EXTERNAL; - cmd->autoneg = AUTONEG_ENABLE; + cmd->autoneg = phydev->autoneg; cmd->maxtxpkt = priv->txcount; cmd->maxrxpkt = priv->rxcount; @@ -461,7 +512,33 @@ return err; } +static void gfar_gxcmds(struct net_device *dev, + struct ethtool_xcmd *xcmd, void *data) +{ + memcpy(data, &gfar_xcmds, sizeof(gfar_xcmds)); +} + +static void gfar_gxvals(struct net_device *dev, + struct ethtool_xcmd *xcmd, void *data) +{ + struct gfar_private *priv = netdev_priv(dev); + + memcpy(data, &priv->xvals, sizeof(struct gfar_xvals)); +} + +static void gfar_sxvals(struct net_device *dev, struct ethtool_xcmd *xcmd) +{ + struct gfar_private *priv = netdev_priv(dev); + struct gfar_xvals *xvals = (struct gfar_xvals *)&(xcmd->data[0]); + + priv->xvals = *xvals; + + gfar_phy_test(priv->mii_bus, priv->phydev, xvals->phytest, + xvals->ptest_reg, xvals->ptest_read); +} + struct ethtool_ops gfar_ethtool_ops = { + .set_settings = gfar_ssettings, .get_settings = gfar_gsettings, .get_drvinfo = gfar_gdrvinfo, .get_regs_len = gfar_reglen, @@ -474,9 +551,13 @@ .get_strings = gfar_gstrings, .get_stats_count = gfar_stats_count, .get_ethtool_stats = gfar_fill_stats, + .get_ethtool_xcmds = gfar_gxcmds, + .get_ethtool_xcmd_vals = gfar_gxvals, + .set_ethtool_xcmd_vals = gfar_sxvals, }; struct ethtool_ops gfar_normon_nocoalesce_ethtool_ops = { + .set_settings = gfar_ssettings, .get_settings = gfar_gsettings, .get_drvinfo = gfar_gdrvinfo, .get_regs_len = gfar_reglen, @@ -487,9 +568,13 @@ .get_strings = gfar_gstrings_normon, .get_stats_count = gfar_stats_count_normon, .get_ethtool_stats = gfar_fill_stats_normon, + .get_ethtool_xcmds = gfar_gxcmds, + .get_ethtool_xcmd_vals = gfar_gxvals, + .set_ethtool_xcmd_vals = gfar_sxvals, }; struct ethtool_ops gfar_nocoalesce_ethtool_ops = { + .set_settings = gfar_ssettings, .get_settings = gfar_gsettings, .get_drvinfo = gfar_gdrvinfo, .get_regs_len = gfar_reglen, @@ -500,9 +585,13 @@ .get_strings = gfar_gstrings, .get_stats_count = gfar_stats_count, .get_ethtool_stats = gfar_fill_stats, + .get_ethtool_xcmds = gfar_gxcmds, + .get_ethtool_xcmd_vals = gfar_gxvals, + .set_ethtool_xcmd_vals = gfar_sxvals, }; struct ethtool_ops gfar_normon_ethtool_ops = { + .set_settings = gfar_ssettings, .get_settings = gfar_gsettings, .get_drvinfo = gfar_gdrvinfo, .get_regs_len = gfar_reglen, @@ -515,6 +604,9 @@ .get_strings = gfar_gstrings_normon, .get_stats_count = gfar_stats_count_normon, .get_ethtool_stats = gfar_fill_stats_normon, + .get_ethtool_xcmds = gfar_gxcmds, + .get_ethtool_xcmd_vals = gfar_gxvals, + .set_ethtool_xcmd_vals = gfar_sxvals, }; struct ethtool_ops *gfar_op_array[] = { --Apple-Mail-5-386825446 Content-Transfer-Encoding: 7bit Content-Type: application/octet-stream; x-unix-mode=0644; name="xcmd-kernel.patch" Content-Disposition: attachment; filename=xcmd-kernel.patch diff -Nru a/net/core/ethtool.c b/net/core/ethtool.c --- a/net/core/ethtool.c 2005-02-28 17:57:35 -06:00 +++ b/net/core/ethtool.c 2005-02-28 17:57:35 -06:00 @@ -674,6 +674,101 @@ return ret; } +static int ethtool_get_xcmds(struct net_device *dev, void __user *useraddr) +{ + struct ethtool_xcmd xcmd; + struct ethtool_ops *ops = dev->ethtool_ops; + void *data; + int ret; + + if (!ops->get_ethtool_xcmds) + return -EOPNOTSUPP; + + if (copy_from_user(&xcmd, useraddr, sizeof(xcmd))) + return -EFAULT; + + data = kmalloc(xcmd.nr_xcmds * sizeof(struct cmdline_info), GFP_USER); + if (!data) + return -ENOMEM; + + ops->get_ethtool_xcmds(dev, &xcmd, data); + + ret = -EFAULT; + if (copy_to_user(useraddr, &xcmd, sizeof(xcmd))) + goto out; + useraddr += sizeof(xcmd); + if (copy_to_user(useraddr, data, + xcmd.nr_xcmds * sizeof(struct cmdline_info))) + goto out; + ret = 0; + +out: + kfree(data); + return ret; +} + +static int ethtool_get_xcmd_vals(struct net_device *dev, void __user *useraddr) +{ + struct ethtool_xcmd xcmd_vals; + struct ethtool_ops *ops = dev->ethtool_ops; + u32 *data; + int ret; + + if (!ops->get_ethtool_xcmd_vals) + return -EOPNOTSUPP; + + if (copy_from_user(&xcmd_vals, useraddr, sizeof(xcmd_vals))) + return -EFAULT; + + data = kmalloc(xcmd_vals.nr_xcmds * sizeof(u32), GFP_USER); + if (!data) + return -ENOMEM; + + ops->get_ethtool_xcmd_vals(dev, &xcmd_vals, data); + + ret = -EFAULT; + if (copy_to_user(useraddr, &xcmd_vals, sizeof(xcmd_vals))) + goto out; + useraddr += sizeof(xcmd_vals); + if (copy_to_user(useraddr, data, xcmd_vals.nr_xcmds*sizeof(u32))) + goto out; + ret = 0; + +out: + kfree(data); + return ret; +} +static int ethtool_set_xcmd_vals(struct net_device *dev, void __user *useraddr) +{ + struct ethtool_xcmd xcmd; + struct ethtool_xcmd *xcmd_vals; + struct ethtool_ops *ops = dev->ethtool_ops; + int ret; + + if (!ops->set_ethtool_xcmd_vals) + return -EOPNOTSUPP; + + if (copy_from_user(&xcmd, useraddr, sizeof(xcmd))) + return -EFAULT; + + xcmd_vals = kmalloc(sizeof(xcmd)+xcmd.nr_xcmds * sizeof(u32), + GFP_KERNEL); + if (!xcmd_vals) + return -ENOMEM; + + ret = -EFAULT; + if (copy_from_user(xcmd_vals, useraddr, + sizeof(xcmd)+xcmd.nr_xcmds * sizeof(u32))) + goto out; + + ops->set_ethtool_xcmd_vals(dev, xcmd_vals); + + ret = 0; + +out: + kfree(xcmd_vals); + return ret; +} /* The main entry point in this file. Called from net/core/dev.c */ int dev_ethtool(struct ifreq *ifr) @@ -794,6 +889,15 @@ break; case ETHTOOL_GSTATS: rc = ethtool_get_stats(dev, useraddr); + break; + case ETHTOOL_GXCMDS: + rc = ethtool_get_xcmds(dev, useraddr); + break; + case ETHTOOL_GXCMDVALS: + rc = ethtool_get_xcmd_vals(dev, useraddr); + break; + case ETHTOOL_SXCMDVALS: + rc = ethtool_set_xcmd_vals(dev, useraddr); break; default: rc = -EOPNOTSUPP; diff -Nru a/include/linux/ethtool.h b/include/linux/ethtool.h --- a/include/linux/ethtool.h 2005-02-28 17:57:34 -06:00 +++ b/include/linux/ethtool.h 2005-02-28 17:57:34 -06:00 @@ -44,6 +44,8 @@ u32 testinfo_len; u32 eedump_len; /* Size of data from ETHTOOL_GEEPROM (bytes) */ u32 regdump_len; /* Size of data from ETHTOOL_GREGS (bytes) */ + u32 n_xcmds; /* number of driver-defined commands */ + }; #define SOPASS_MAX 6 @@ -215,6 +217,29 @@ u32 tx_pause; }; +/* For getting the driver-specified command list, and also for + * getting the current values for those commands */ +struct ethtool_xcmd { + u32 cmd; + u32 nr_xcmds; + u8 data[0]; +}; + +typedef enum { + CMDL_NONE, + CMDL_BOOL, + CMDL_INT, +} cmdline_type_t; + +#define CMDLINE_NAME_LEN 32 +struct cmdline_info { + const char name[CMDLINE_NAME_LEN]; + cmdline_type_t type; + void *wanted_val; + void *ioctl_val; +}; + + #define ETH_GSTRING_LEN 32 enum ethtool_stringset { ETH_SS_TEST = 0, @@ -351,6 +376,9 @@ int (*phys_id)(struct net_device *, u32); int (*get_stats_count)(struct net_device *); void (*get_ethtool_stats)(struct net_device *, struct ethtool_stats *, u64 *); + void (*get_ethtool_xcmds)(struct net_device *, struct ethtool_xcmd *, void *); + void (*get_ethtool_xcmd_vals)(struct net_device *, struct ethtool_xcmd *, void *); + void (*set_ethtool_xcmd_vals)(struct net_device *, struct ethtool_xcmd *); int (*begin)(struct net_device *); void (*complete)(struct net_device *); }; @@ -388,6 +416,10 @@ #define ETHTOOL_GSTATS 0x0000001d /* get NIC-specific statistics */ #define ETHTOOL_GTSO 0x0000001e /* Get TSO enable (ethtool_value) */ #define ETHTOOL_STSO 0x0000001f /* Set TSO enable (ethtool_value) */ +#define ETHTOOL_GXCMDS 0x00000020 /* Get XCMD list */ +#define ETHTOOL_GXCMDVALS 0x00000021 /* Get current XCMD values */ +#define ETHTOOL_SXCMDVALS 0x00000022 /* Set current XCMD values */ + /* compatibility with older code */ #define SPARC_ETH_GSET ETHTOOL_GSET --Apple-Mail-5-386825446 Content-Transfer-Encoding: 7bit Content-Type: application/octet-stream; x-unix-mode=0644; name="xcmd.patch" Content-Disposition: attachment; filename=xcmd.patch ? xcmd.patch Index: ChangeLog =================================================================== RCS file: /cvsroot/gkernel/ethtool/ChangeLog,v retrieving revision 1.60 diff -u -r1.60 ChangeLog --- ChangeLog 17 Aug 2004 12:05:45 -0000 1.60 +++ ChangeLog 28 Feb 2005 22:41:26 -0000 @@ -1,3 +1,8 @@ +Mon Feb 28 2005 Andy Fleming + + * ethtool.c, ethtool-copy.h: Added a new command (-x) + which allows drivers to specify command-line arguments + Tue Aug 17 2004 Jeff Garzik * NEWS, configure.ac: Release version 2 Index: ethtool-copy.h =================================================================== RCS file: /cvsroot/gkernel/ethtool/ethtool-copy.h,v retrieving revision 1.13 diff -u -r1.13 ethtool-copy.h --- ethtool-copy.h 19 Jul 2003 15:19:52 -0000 1.13 +++ ethtool-copy.h 28 Feb 2005 22:41:26 -0000 @@ -44,6 +44,7 @@ u32 testinfo_len; u32 eedump_len; /* Size of data from ETHTOOL_GEEPROM (bytes) */ u32 regdump_len; /* Size of data from ETHTOOL_GREGS (bytes) */ + u32 n_xcmds; /* number of driver-defined commands */ }; #define SOPASS_MAX 6 @@ -215,6 +216,14 @@ u32 tx_pause; }; +/* For getting the driver-specified command list, and also for getting + * the current values for those commands */ +struct ethtool_xcmd { + u32 cmd; + u32 nr_xcmds; + u8 data[0]; +}; + #define ETH_GSTRING_LEN 32 enum ethtool_stringset { ETH_SS_TEST = 0, @@ -283,6 +292,9 @@ #define ETHTOOL_GSTATS 0x0000001d /* get NIC-specific statistics */ #define ETHTOOL_GTSO 0x0000001e /* Get TSO enable (ethtool_value) */ #define ETHTOOL_STSO 0x0000001f /* Set TSO enable (ethtool_value) */ +#define ETHTOOL_GXCMDS 0x00000020 /* Get XCMD list */ +#define ETHTOOL_GXCMDVALS 0x00000021 /* Get current XCMD values */ +#define ETHTOOL_SXCMDVALS 0x00000022 /* Set current XCMD values */ /* compatibility with older code */ #define SPARC_ETH_GSET ETHTOOL_GSET Index: ethtool.c =================================================================== RCS file: /cvsroot/gkernel/ethtool/ethtool.c,v retrieving revision 1.50 diff -u -r1.50 ethtool.c --- ethtool.c 2 Jul 2004 15:35:09 -0000 1.50 +++ ethtool.c 28 Feb 2005 22:41:26 -0000 @@ -64,6 +64,7 @@ static int do_goffload(int fd, struct ifreq *ifr); static int do_soffload(int fd, struct ifreq *ifr); static int do_gstats(int fd, struct ifreq *ifr); +static int do_xcmd(int fd, struct ifreq *ifr); /* Syntax: * @@ -132,6 +133,7 @@ * [ sopass %x:%x:%x:%x:%x:%x ] \ * [ msglvl %d ] * ethtool -S DEVNAME + * ethtool -x DEVNAME [x-command list] */ static void show_usage(int badarg) @@ -205,6 +207,7 @@ " [ sopass %%x:%%x:%%x:%%x:%%x:%%x ] \\\n" " [ msglvl %%d ] \n" " ethtool -S DEVNAME\n" + " ethtool -x DEVNAME [x-command list]\n" ); exit(badarg); } @@ -229,6 +232,7 @@ MODE_GOFFLOAD, MODE_SOFFLOAD, MODE_GSTATS, + MODE_XCMD, } mode = MODE_GSET; static int goffload_changed = 0; @@ -300,6 +304,10 @@ static int seeprom_magic = 0; static int seeprom_offset = -1; static int seeprom_value = 0; + +static char **gxcmd_argp = NULL; +static int gxcmd_argc = 0; + static enum { ONLINE=0, OFFLINE, @@ -311,8 +319,9 @@ CMDL_INT, } cmdline_type_t; +#define CMDLINE_NAME_LEN 32 struct cmdline_info { - const char *name; + const char name[CMDLINE_NAME_LEN]; cmdline_type_t type; void *wanted_val; void *ioctl_val; @@ -456,6 +465,8 @@ mode = MODE_TEST; else if (!strcmp(argp[i], "-S")) mode = MODE_GSTATS; + else if (!strcmp(argp[i], "-x")) + mode = MODE_XCMD; else if (!strcmp(argp[i], "-h")) show_usage(0); else @@ -478,6 +489,7 @@ (mode == MODE_GOFFLOAD) || (mode == MODE_SOFFLOAD) || (mode == MODE_GSTATS) || + (mode == MODE_XCMD) || (mode == MODE_PHYS_ID)) { devname = argp[i]; break; @@ -557,6 +569,13 @@ i = argc; break; } + /* X-Commands are parsed later */ + if (mode == MODE_XCMD) { + gxcmd_argp = &(argp[i]); + gxcmd_argc = argc - i; + i = argc; + break; + } if (mode != MODE_SSET) show_usage(1); if (!strcmp(argp[i], "speed")) { @@ -681,13 +700,21 @@ else if (speed_wanted == SPEED_100 && duplex_wanted == DUPLEX_FULL) advertising_wanted = ADVERTISED_100baseT_Full; - else + else if (speed_wanted == SPEED_1000 && + duplex_wanted == DUPLEX_HALF) + advertising_wanted = ADVERTISED_1000baseT_Half; + else if (speed_wanted == SPEED_1000 && + duplex_wanted == DUPLEX_FULL) + advertising_wanted = ADVERTISED_1000baseT_Full; + else { /* auto negotiate without forcing */ advertising_wanted = ADVERTISED_100baseT_Full | ADVERTISED_100baseT_Half | ADVERTISED_10baseT_Full | - ADVERTISED_100baseT_Half; - + ADVERTISED_10baseT_Half | + ADVERTISED_1000baseT_Half | + ADVERTISED_1000baseT_Full; + } } if (devname == NULL) { @@ -857,7 +884,7 @@ fprintf(stdout, "internal\n"); break; case XCVR_EXTERNAL: - fprintf(stdout, "externel\n"); + fprintf(stdout, "external\n"); break; default: fprintf(stdout, "Unknown!\n"); @@ -1243,6 +1270,8 @@ return do_soffload(fd, &ifr); } else if (mode == MODE_GSTATS) { return do_gstats(fd, &ifr); + } else if (mode == MODE_XCMD) { + return do_xcmd(fd, &ifr); } return 69; @@ -1313,6 +1342,151 @@ do_generic_set1(&info[i], changed_out); } +static void dump_command(struct cmdline_info *info) +{ + fprintf(stderr, "%s %s\n", info->name, + (info->type == CMDL_BOOL) ? "[on|off]" : + (info->type == CMDL_INT) ? "" : ""); +} + +static void dump_command_list(struct cmdline_info *info, + unsigned int n_info) +{ + int idx; + + fprintf(stderr, "Commands supported by %s:\n", devname); + + for (idx = 0; idx < n_info; idx++) { + fprintf(stderr, "\t"); + dump_command(&info[idx]); + } +} + +/* Each driver may specify a list of arbitrary commands to change + * driver values. These can be used to enable features which + * aren't widely available (thus meriting a unique ethtool + * command), or turn specific debugging features on and off. */ +static int do_xcmd(int fd, struct ifreq *ifr) +{ + int nr_xcmds; + int err; + struct cmdline_info *xcmd_list; + struct ethtool_drvinfo drvinfo; + struct ethtool_xcmd *xcmd; + struct ethtool_xcmd *xcmd_vals; + u32 *wanted_vals; + int changed; + int idx; + + /* Get the driver's info, so we know how many commands + * it provides */ + drvinfo.cmd = ETHTOOL_GDRVINFO; + ifr->ifr_data = (caddr_t)&drvinfo; + err = ioctl(fd, SIOCETHTOOL, ifr); + if (err < 0) { + perror("Cannot get X-Command list size"); + return err; + } + + nr_xcmds = drvinfo.n_xcmds; + + if (nr_xcmds < 1) { + fprintf(stderr, "No commands supported\n"); + return 94; + } + + /* Allocate space for the command list */ + xcmd = calloc(1, sizeof(*xcmd) + sizeof(*xcmd_list) * nr_xcmds); + + if (NULL == xcmd) { + fprintf(stderr, "No memory\n"); + return 94; + } + + /* Get the command list */ + xcmd->cmd = ETHTOOL_GXCMDS; + xcmd->nr_xcmds = nr_xcmds; + ifr->ifr_data = (caddr_t)xcmd; + err = ioctl(fd, SIOCETHTOOL, ifr); + if (err < 0) { + perror("Cannot get X-Command list"); + free(xcmd); + return err; + } + + xcmd_list = (struct cmdline_info *)&(xcmd->data); + + /* If the user didn't specify any commands, print out the + * command list */ + if (gxcmd_argc < 2) { + dump_command_list(xcmd_list, nr_xcmds); + return 94; + } + + /* Allocate space for the current values from the driver */ + xcmd_vals = calloc(1, sizeof(*xcmd) + sizeof(u32) * nr_xcmds); + + if (NULL == xcmd_vals) { + fprintf(stderr, "No memory\n"); + free(xcmd); + return 94; + } + + /* Get the xcmd values */ + xcmd_vals->cmd = ETHTOOL_GXCMDVALS; + xcmd_vals->nr_xcmds = nr_xcmds; + ifr->ifr_data = (caddr_t)xcmd_vals; + err = ioctl(fd, SIOCETHTOOL, ifr); + if (err < 0) { + perror("Cannot get X-Command values"); + free(xcmd); + free(xcmd_vals); + return err; + } + + /* Create a temporary array to store the values the user + * specified on the command line */ + wanted_vals = calloc(1, sizeof(u32)*nr_xcmds); + + /* Now tie the wanted_val fields of each command to + * entries in the wanted_vals array, and tie the + * ioctl_val fields to the data from xcmd_vals */ + for (idx = 0; idx < nr_xcmds; idx++) { + xcmd_list[idx].wanted_val = &wanted_vals[idx]; + xcmd_list[idx].ioctl_val = &xcmd_vals->data[idx*sizeof(u32)]; + } + + /* Parse the command line, and fill in the + * wanted_vals array */ + parse_generic_cmdline(gxcmd_argc, gxcmd_argp, 0, + &changed, xcmd_list, nr_xcmds); + + if (!changed) { + fprintf(stderr, "No xcmds specified\n"); + return 80; + } + + /* Now change the values in xcmd_vals to reflect + * those in the wanted_vals array */ + do_generic_set(xcmd_list, nr_xcmds, &changed); + + if (!changed) { + fprintf(stderr, "No xcmd values changed\n"); + return 80; + } + + /* Pass the new values back up to the driver */ + xcmd_vals->cmd = ETHTOOL_SXCMDVALS; + ifr->ifr_data = (caddr_t)xcmd_vals; + err = ioctl(fd, SIOCETHTOOL, ifr); + if (err < 0) { + perror("Could not set new X-Command values"); + return err; + } + + return 0; +} + static int do_spause(int fd, struct ifreq *ifr) { int err, changed = 0; --Apple-Mail-5-386825446-- From yoshfuji@linux-ipv6.org Tue Mar 1 07:41:19 2005 Received: with ECARTIS (v1.0.0; list netdev); Tue, 01 Mar 2005 07:41:29 -0800 (PST) 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 j21FfI5T012504 for ; Tue, 1 Mar 2005 07:41:18 -0800 Received: from localhost (localhost [127.0.0.1]) by yue.st-paulia.net (Postfix) with ESMTP id 9205933CC2; Wed, 2 Mar 2005 00:42:46 +0900 (JST) Date: Wed, 02 Mar 2005 00:42:45 +0900 (JST) Message-Id: <20050302.004245.114793740.yoshfuji@linux-ipv6.org> To: gilles.quillard@bull.net Cc: netdev@oss.sgi.com, linux-ipv6@list.f00f.org, gh@us.ibm.com, Tony.Reix@bull.net, yoshfuji@linux-ipv6.org Subject: Re: support of IPv6 by NFS From: YOSHIFUJI Hideaki / =?iso-2022-jp?B?GyRCNUhGIzFRTEAbKEI=?= In-Reply-To: <42243F8D.5030302@bull.net> References: <42243F8D.5030302@bull.net> Organization: USAGI Project X-URL: http://www.yoshifuji.org/%7Ehideaki/ X-Fingerprint: 9022 65EB 1ECF 3AD1 0BDF 80D8 4807 F894 E062 0EEA X-PGP-Key-URL: http://www.yoshifuji.org/%7Ehideaki/hideaki@yoshifuji.org.asc X-Face: "5$Al-.M>NJ%a'@hhZdQm:."qn~PA^gq4o*>iCFToq*bAi#4FRtx}enhuQKz7fNqQz\BYU] $~O_5m-9'}MIs`XGwIEscw;e5b>n"B_?j/AkL~i/MEaZBLP X-Mailer: Mew version 2.2 on Emacs 20.7 / Mule 4.1 (AOI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV 0.83/737/Mon Feb 28 22:22:18 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 2184 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 <42243F8D.5030302@bull.net> (at Tue, 01 Mar 2005 11:10:21 +0100), Gilles Quillard says: > The problem is not specific to NFS, any networking application written > using IPv6 mechanisms for both IPv4 and IPv6 addresses (AF_INET6 socket > opened, IPv4 addresses mapped) couldn't work without a kernel built with > IPv6. : > Are the final users really against the use of kernels built with IPv6 ? > What is preconized on Linux for the support of IPv6 ? The solution > described above or the cohabitation of the two modes (struct sockaddr or > sockaddr_storage used to contain either struct sockaddr_in or struct > sockaddr_in6) with specific processing according to the family of the > addresses ? You cannot assume whether the user enables IPv6 or not, and you cannot assume s/he has connectivity to global Internet, in most cases. So, you likely need to try both IPv6 and IPv4. Getaddrinfo() / getnameinfo(), or "protocol independent progarmming," are your friend. --yoshfuji From okir@suse.de Tue Mar 1 08:19:15 2005 Received: with ECARTIS (v1.0.0; list netdev); Tue, 01 Mar 2005 08:19:21 -0800 (PST) Received: from Cantor.suse.de (mail-ex.suse.de [195.135.220.2]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j21GJEKN016981 for ; Tue, 1 Mar 2005 08:19:14 -0800 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 387C0153AA86; Tue, 1 Mar 2005 17:19:08 +0100 (CET) Date: Tue, 1 Mar 2005 17:19:05 +0100 From: Olaf Kirch To: Jeroen Massar Cc: usagi-users@linux-ipv6.org, netdev@oss.sgi.com Subject: Re: (usagi-users 03222) Re: support of IPv6 by NFS Message-ID: <20050301161905.GD22324@suse.de> References: <42243F8D.5030302@bull.net> <200503010744.38339.Info@Quantum-Sci.com> <1109689712.17484.6.camel@firenze.zurich.ibm.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1109689712.17484.6.camel@firenze.zurich.ibm.com> User-Agent: Mutt/1.5.6i X-Virus-Scanned: ClamAV 0.83/737/Mon Feb 28 22:22:18 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 2185 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: okir@suse.de Precedence: bulk X-list: netdev On Tue, Mar 01, 2005 at 04:08:32PM +0100, Jeroen Massar wrote: > > There is no Linux 6to4 > >UDP tunnelling app, but there should be, because this is such a common > >problem. (As I understand, Teredo is Winduhs-only, and is not supported by > >most tunnel operators) > > The protocol for Teredo is open and can be implemented at will: Except that it's quite horrible, and it requires a centralized broker, and IIRC it also makes assumptions about the way your NAT implementation assigns ports. Olaf -- Olaf Kirch | --- o --- Nous sommes du soleil we love when we play okir@suse.de | / | \ sol.dhoop.naytheet.ah kin.ir.samse.qurax From jgarzik@pobox.com Tue Mar 1 08:26:56 2005 Received: with ECARTIS (v1.0.0; list netdev); Tue, 01 Mar 2005 08:27:00 -0800 (PST) Received: from parcelfarce.linux.theplanet.co.uk (IDENT:93@parcelfarce.linux.theplanet.co.uk [195.92.249.252]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j21GQsPq017836 for ; Tue, 1 Mar 2005 08:26:55 -0800 Received: from [69.134.152.124] (helo=[10.10.10.88]) by parcelfarce.linux.theplanet.co.uk with asmtp (TLSv1:AES256-SHA:256) (Exim 4.33) id 1D6ACy-0003GC-HM; Tue, 01 Mar 2005 16:26:52 +0000 Message-ID: <422497BA.9090606@pobox.com> Date: Tue, 01 Mar 2005 11:26:34 -0500 From: Jeff Garzik User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.3) Gecko/20040922 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Denis Vlasenko CC: "David S. Miller" , Quantum Scientific , netdev@oss.sgi.com Subject: Re: Kernel 2.6 IPV6 Busted References: <200502270928.44402.Info@Quantum-Sci.com> <200502271410.39611.Info@quantum-sci.com> <20050227133517.578884df.davem@davemloft.net> <200503011207.34029.vda@port.imtp.ilyichevsk.odessa.ua> In-Reply-To: <200503011207.34029.vda@port.imtp.ilyichevsk.odessa.ua> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV 0.83/737/Mon Feb 28 22:22:18 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 2186 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: jgarzik@pobox.com Precedence: bulk X-list: netdev Denis Vlasenko wrote: > On Sunday 27 February 2005 23:35, David S. Miller wrote: > >>On Sun, 27 Feb 2005 14:10:39 -0600 >>Quantum Scientific wrote: >> >> >>>I am skeptical about this assertion that the whole internet needs to be hashed >>>if connection tracking. >> >>Connection tracking and NAT broke entirely the end-to-end host >>assumption that used to be valid on the internet. >> >>There are many very important optimizations we've had to disable >>by default just in TCP alone because of NAT. > > > I don't think future Internet will be safe enough to open > corporate networks. I definitely won't do it. > NAT firewall in front of my net is an absolute requirement > for me. > > However, IPv6 in Internet won't happen tomorrow, > no rush... You don't need NAT to secure a corporate network. Just write sane firewall rules that don't allow incoming. Jeff From pedro.fortuna@gmail.com Tue Mar 1 08:33:54 2005 Received: with ECARTIS (v1.0.0; list netdev); Tue, 01 Mar 2005 08:33:57 -0800 (PST) Received: from rproxy.gmail.com (rproxy.gmail.com [64.233.170.197]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j21GXrQc018465 for ; Tue, 1 Mar 2005 08:33:54 -0800 Received: by rproxy.gmail.com with SMTP id a36so814938rnf for ; Tue, 01 Mar 2005 08:33:50 -0800 (PST) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:reply-to:to:subject:in-reply-to:mime-version:content-type:content-transfer-encoding:references; b=BX2/748sUtxErfiLSHAYUb/BgzmnZUJiOFdDGioSGC4OzaiNnGVjdSi9OWua/A1CIG764JFTcFxtMWXIprlTTY5vjWoCw4K8+9ZMFmONSQ+P3nekF6C/r2xZC8O2pPEPXLqIEj1lt40c0TFoSs6i3Xq0d2gy/6/Pr+WHtf/eCpo= Received: by 10.11.118.73 with SMTP id q73mr260716cwc; Tue, 01 Mar 2005 08:33:49 -0800 (PST) Received: by 10.11.99.66 with HTTP; Tue, 1 Mar 2005 08:33:49 -0800 (PST) Message-ID: Date: Tue, 1 Mar 2005 16:33:49 +0000 From: Pedro Fortuna Reply-To: Pedro Fortuna To: netdev@oss.sgi.com Subject: Re: filtering packtes before OS takes care about them In-Reply-To: <7bca1cb50502281935557b45cc@mail.gmail.com> Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit References: <09766A6E64A068419B362367800D50C0B58A17@moritz.faps.uni-erlangen.de> <7bca1cb50502281209798e8a00@mail.gmail.com> <7bca1cb50502281935557b45cc@mail.gmail.com> X-Virus-Scanned: ClamAV 0.83/737/Mon Feb 28 22:22:18 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 2187 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: pedro.fortuna@gmail.com Precedence: bulk X-list: netdev This subject is rather new to me. Is there some literature about linux kernel networking API that you would recommend? thanks, -Pedro Fortuna On Mon, 28 Feb 2005 21:35:09 -0600, Asim Shankar wrote: > > In my case, I'll need to intercept all outgoing IP packets and change > > them (including L2 frame) before they are passed to the network > > interface driver. > > The reverse operation is applied to incoming IP Packets in the destination host. > > I didnt investigate the packet_type example you provided but I hope I > > will be able to used for the purposes I explained. > > If the type field of the struct packet_type you register == > htons(ETH_P_ALL), then your packet handling function will be added to > the head of the ptype_all list. > > As a result, it will see all incoming and outgoing packets - incoming > will be delivered to your function from netif_receive_skb() before the > IP/other packet handlers get to see it and outgoing packets will be > delivered from dev_queue_xmit() (which calls dev_queue_xmit_nit()) > just before the packet is queued for sending by the NIC. This may work > for you. > > I'm assuming all outgoing packets go through dev_queue_xmit(), though > that may not always be the case (someone more knowledgeable would have > to explain this). > > Regards, > > -- Asim > From courmisch@via.ecp.fr Tue Mar 1 08:35:14 2005 Received: with ECARTIS (v1.0.0; list netdev); Tue, 01 Mar 2005 08:35:18 -0800 (PST) Received: from smtp2.wanadoo.fr (smtp2.wanadoo.fr [193.252.22.29]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j21GZDUC018840 for ; Tue, 1 Mar 2005 08:35:14 -0800 Received: from me-wanadoo.net (localhost [127.0.0.1]) by mwinf0202.wanadoo.fr (SMTP Server) with ESMTP id 541F31C001B5; Tue, 1 Mar 2005 17:35:01 +0100 (CET) Received: from ALille-251-1-3-135.w82-127.abo.wanadoo.fr (ALille-251-1-3-135.w82-127.abo.wanadoo.fr [82.127.145.135]) by mwinf0202.wanadoo.fr (SMTP Server) with ESMTP id 09F2D1C001B8; Tue, 1 Mar 2005 17:35:00 +0100 (CET) X-ME-UUID: 20050301163501409.09F2D1C001B8@mwinf0202.wanadoo.fr Received: from 192.168.1.64 by charlie.simphalempin.com with esmtp (masqmail 0.2.20) id 1D6AKs-0n8-00; Tue, 01 Mar 2005 17:35:02 +0100 From: =?iso-8859-1?q?R=E9mi_Denis-Courmont?= Organization: VIA Centrale =?utf-8?q?R=C3=A9seaux?= To: usagi-users@linux-ipv6.org Subject: Re: (usagi-users 03222) Re: support of IPv6 by NFS Date: Tue, 1 Mar 2005 17:35:01 +0100 User-Agent: KMail/1.7.2 Cc: Quantum Scientific , netdev@oss.sgi.com References: <42243F8D.5030302@bull.net> <200503010744.38339.Info@Quantum-Sci.com> In-Reply-To: <200503010744.38339.Info@Quantum-Sci.com> MIME-Version: 1.0 Content-Type: multipart/signed; boundary="nextPart2081891.0kPmRnMEtL"; protocol="application/pgp-signature"; micalg=pgp-sha1 Content-Transfer-Encoding: 7bit Message-Id: <200503011735.01578.courmisch@via.ecp.fr> X-Virus-Scanned: ClamAV 0.83/737/Mon Feb 28 22:22:18 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 2188 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: courmisch@via.ecp.fr Precedence: bulk X-list: netdev --nextPart2081891.0kPmRnMEtL Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Le Mardi 1 Mars 2005 14:44, Quantum Scientific a =E9crit : > And 80% of potential users are behind a cable/DSL 4 NATting router.=20 > There is no clarity that it is possible overcome this by either > setting to DMZ, or hoping your cablemodem passes protos 41, 50 & 51.=20 > Even some tunnel operators do not know this, so I had to figure it > out myself. There is no Linux 6to4 UDP tunnelling app, but there > should be, because this is such a common problem. (As I understand, > Teredo is Winduhs-only, and is not supported by most tunnel > operators) There is at least one Teredo client for Linux : http://www.simphalempin.com/dev/miredo/ Alternatively, TSP tunneling might also work through NAT devices. =2D-=20 R=E9mi Denis-Courmont --nextPart2081891.0kPmRnMEtL Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.0 (GNU/Linux) iD8DBQBCJJm1w+xtvt1tEr0RAr9OAJ9EzYHS98Cw17gsQTbeDT75JSZZmQCfbyPD 9M1wuf6dIaHA2WbGMMtzEGg= =SjbA -----END PGP SIGNATURE----- --nextPart2081891.0kPmRnMEtL-- From jeroen@unfix.org Tue Mar 1 09:19:00 2005 Received: with ECARTIS (v1.0.0; list netdev); Tue, 01 Mar 2005 09:19:03 -0800 (PST) Received: from noc.sixxs.net (postfix@noc.sixxs.net [213.197.29.32]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j21HIxYR020332 for ; Tue, 1 Mar 2005 09:18:59 -0800 Received: from localhost (localhost [127.0.0.1]) by noc.sixxs.net (Postfix) with ESMTP id 9777624061; Tue, 1 Mar 2005 18:18:53 +0100 (CET) Received: from noc.sixxs.net ([127.0.0.1]) by localhost (noc [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 20717-04; Tue, 1 Mar 2005 18:18:53 +0100 (CET) Received: from firenze.zurich.ibm.com (pat.zurich.ibm.com [195.176.20.45]) (using SSLv3 with cipher RC4-MD5 (128/128 bits)) (No client certificate requested) by noc.sixxs.net (Postfix) with ESMTP id 4A7AE2400D; Tue, 1 Mar 2005 18:18:52 +0100 (CET) Subject: Re: (usagi-users 03222) Re: support of IPv6 by NFS From: Jeroen Massar To: Olaf Kirch Cc: usagi-users@linux-ipv6.org, netdev@oss.sgi.com In-Reply-To: <20050301161905.GD22324@suse.de> References: <42243F8D.5030302@bull.net> <200503010744.38339.Info@Quantum-Sci.com> <1109689712.17484.6.camel@firenze.zurich.ibm.com> <20050301161905.GD22324@suse.de> Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="=-W6Xjqd05xD/Sh1PKo+6c" Organization: Unfix Date: Tue, 01 Mar 2005 18:18:49 +0100 Message-Id: <1109697529.17484.37.camel@firenze.zurich.ibm.com> Mime-Version: 1.0 X-Mailer: Evolution 2.1.5 (2.1.5-1) X-Virus-Scanned: ClamAV 0.83/737/Mon Feb 28 22:22:18 2005 on oss.sgi.com X-Virus-Scanned: noc.sixxs.net - http://www.sixxs.net X-Virus-Status: Clean X-archive-position: 2189 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: jeroen@unfix.org Precedence: bulk X-list: netdev --=-W6Xjqd05xD/Sh1PKo+6c Content-Type: text/plain Content-Transfer-Encoding: quoted-printable On Tue, 2005-03-01 at 17:19 +0100, Olaf Kirch wrote: >On Tue, Mar 01, 2005 at 04:08:32PM +0100, Jeroen Massar wrote: >> > There is no Linux 6to4=20 >> >UDP tunnelling app, but there should be, because this is such a common=20 >> >problem. (As I understand, Teredo is Winduhs-only, and is not supporte= d by=20 >> >most tunnel operators) >>=20 >> The protocol for Teredo is open and can be implemented at will: > >Except that it's quite horrible, It needs to be horrible as it needs to cross horrible NAT's. > and it requires a centralized broker, Doesn't every tunneling method require this? Or is 6to4 anycasted and thus not central? Do note that you can setup your own Teredo relay, see the docs at the Miredo site for more information. >and IIRC it also makes assumptions about the way your NAT implementation >assigns ports. It expects a Cone NAT (or was it the other thing?). The functionality for the others where taken out because of 'security' concerns from some people. Greets, Jeroen --=-W6Xjqd05xD/Sh1PKo+6c Content-Type: application/pgp-signature; name=signature.asc Content-Description: This is a digitally signed message part -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.0 (GNU/Linux) Comment: Jeroen Massar / http://unfix.org/~jeroen/ iD8DBQBCJKP5KaooUjM+fCMRAvRhAJ4o8IBuLj1o3Hw1dTAoCwIjLoIrKgCgi5KG INtpU/lvftq1ne3rFg9UqBo= =RBR4 -----END PGP SIGNATURE----- --=-W6Xjqd05xD/Sh1PKo+6c-- From shemminger@osdl.org Tue Mar 1 09:24:04 2005 Received: with ECARTIS (v1.0.0; list netdev); Tue, 01 Mar 2005 09:24:09 -0800 (PST) Received: from smtp.osdl.org (fire.osdl.org [65.172.181.4]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j21HO3JI020894 for ; Tue, 1 Mar 2005 09:24:03 -0800 Received: from shell0.pdx.osdl.net (fw.osdl.org [65.172.181.6]) by smtp.osdl.org (8.12.8/8.12.8) with ESMTP id j21HKiqi025569 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO); Tue, 1 Mar 2005 09:20:45 -0800 Received: from dxpl.pdx.osdl.net (dxpl.pdx.osdl.net [172.20.1.103]) by shell0.pdx.osdl.net (8.13.1/8.11.6) with ESMTP id j21HKixF021232; Tue, 1 Mar 2005 09:20:44 -0800 Date: Tue, 1 Mar 2005 09:20:58 -0800 From: Stephen Hemminger To: "Weber Matthias" Cc: Subject: Re: filtering packtes before OS takes care about them Message-ID: <20050301092058.570ed623@dxpl.pdx.osdl.net> In-Reply-To: <09766A6E64A068419B362367800D50C0B58A17@moritz.faps.uni-erlangen.de> References: <09766A6E64A068419B362367800D50C0B58A17@moritz.faps.uni-erlangen.de> Organization: Open Source Development Lab X-Mailer: Sylpheed-Claws 1.0.1 (GTK+ 1.2.10; x86_64-unknown-linux-gnu) X-Face: &@E+xe?c%:&e4D{>f1O<&U>2qwRREG5!}7R4;D<"NO^UI2mJ[eEOA2*3>(`Th.yP,VDPo9$ /`~cw![cmj~~jWe?AHY7D1S+\}5brN0k*NE?pPh_'_d>6;XGG[\KDRViCfumZT3@[ Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Received-SPF: pass (domain of shemminger@osdl.org designates 65.172.181.6 as permitted sender) X-MIMEDefang-Filter: osdl$Revision: 1.103 $ X-Scanned-By: MIMEDefang 2.36 X-Virus-Scanned: ClamAV 0.83/737/Mon Feb 28 22:22:18 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 2190 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: shemminger@osdl.org Precedence: bulk X-list: netdev On Mon, 28 Feb 2005 17:16:57 +0100 "Weber Matthias" wrote: > Hi, > > i need a possibility to catch IP4 packets (from ethernet devices) before OS' netmodules (IP, UDP, TCP, ICMP, ARP, ROUTE, NETFILTER ...) takes care about them and > * to delete them from input buffer such that OS' netmodules can't receive them > * to modify packet headers and move packets to interface related output buffers > * to keep them in input buffers such that OS' netmodules can take care about them. > > I would be thankfull for any hint, link or code example. > > Bye > Matthias If you need this as a "one off" type project, then another possibility is to hook onto netif_rx with jprobe (part of the kprobe) to redirect traffic to a local function first. It wouldn't useable for a real production type protocol. From john.ronciak@gmail.com Tue Mar 1 10:14:22 2005 Received: with ECARTIS (v1.0.0; list netdev); Tue, 01 Mar 2005 10:14:28 -0800 (PST) Received: from rproxy.gmail.com (rproxy.gmail.com [64.233.170.197]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j21IEL1w022411 for ; Tue, 1 Mar 2005 10:14:22 -0800 Received: by rproxy.gmail.com with SMTP id c51so1058460rne for ; Tue, 01 Mar 2005 10:14:21 -0800 (PST) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:reply-to:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:references; b=LPjSRlc9rSlmr+lj+rxx16ougUSs8DL2yzPnOwzU2WP+/ds98Wbn4HA6W5A/EO62UMN8L7kpGNB+iWcqP/kP6S/g86hvpcRre5v3mD9RELe80Kkakez7u25LIFORW9qZEErmaYPnPvEmHi1gRqTyDjnPYKeNBM5Wgqylfs5+MLM= Received: by 10.38.97.5 with SMTP id u5mr78106rnb; Tue, 01 Mar 2005 10:13:35 -0800 (PST) Received: by 10.38.150.13 with HTTP; Tue, 1 Mar 2005 10:13:34 -0800 (PST) Message-ID: <56a8daef05030110137b712879@mail.gmail.com> Date: Tue, 1 Mar 2005 10:13:34 -0800 From: John Ronciak Reply-To: John Ronciak To: Lennert Buytenhek Subject: Re: e1000 problem with NAPI? Cc: netdev@oss.sgi.com, hadi@cyberus.ca, robert.olsson@data.slu.se In-Reply-To: <20050301135931.GA14610@xi.wantstofly.org> Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit References: <20050301135931.GA14610@xi.wantstofly.org> X-Virus-Scanned: ClamAV 0.83/737/Mon Feb 28 22:22:18 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 2191 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: john.ronciak@gmail.com Precedence: bulk X-list: netdev Lennert, It sounds like you are running into a bug we had with NAPI in that e1000 driver. Robert actually found it. :-) Please try the 5.7.6 driver available from Sourceforge. It has the fixed NAPI code in it. Let us know if this fixes the problem. Thanks, John On Tue, 1 Mar 2005 14:59:31 +0100, Lennert Buytenhek wrote: > Hi all, > > I'm seeing some strange issues with an e1000 NIC. I'm flooding it > with tinygrams from a packet generator and then abruptly stop the > generator. The last few packets from the burst don't come through > until after two seconds. Sometimes there are multiple trailing > bursts, each of them separated by two seconds. > > For example: (The low 24 bits of the destination address are set > to the packet sequence number by the generator.) > > 14:44:19.649874 IP 10.10.0.0 > 1.4.10.11: [|tcp] > 14:44:19.649878 IP 10.10.0.0 > 1.4.10.12: [|tcp] > 14:44:19.649882 IP 10.10.0.0 > 1.4.10.13: [|tcp] > 14:44:19.649887 IP 10.10.0.0 > 1.4.10.14: [|tcp] > 14:44:19.649891 IP 10.10.0.0 > 1.4.10.15: [|tcp] > 14:44:19.649895 IP 10.10.0.0 > 1.4.10.16: [|tcp] > 14:44:19.649899 IP 10.10.0.0 > 1.4.10.17: [|tcp] > 14:44:21.650293 IP 10.10.0.0 > 1.4.10.18: [|tcp] <=== delayed > 14:44:21.650303 IP 10.10.0.0 > 1.4.10.19: [|tcp] > 14:44:21.650308 IP 10.10.0.0 > 1.4.10.20: [|tcp] > 14:44:21.650312 IP 10.10.0.0 > 1.4.10.21: [|tcp] > 14:44:21.650316 IP 10.10.0.0 > 1.4.10.22: [|tcp] > 14:44:21.650320 IP 10.10.0.0 > 1.4.10.23: [|tcp] > 14:44:21.650324 IP 10.10.0.0 > 1.4.10.24: [|tcp] > 14:44:21.650328 IP 10.10.0.0 > 1.4.10.25: [|tcp] > 14:44:21.650332 IP 10.10.0.0 > 1.4.10.26: [|tcp] > > I wrote the packet generator code myself (ixp2400 platform), but I've > verified that the packets do leave the generator back-to-back. What's > also strange is that when these trailing bursts come in, the interface > statistics counters do not change -- the packets in the trailing bursts > have already been counted by the time they show up in tcpdump. > > Jamal suspects a NAPI 'rotting packet' issue, which doesn't sound all > that unlikely. (Oh, this is kernel 2.6.10-something with e1000 driver > version "5.5.4-k2-NAPI".) > > Ideas? > > cheers, > Lennert > > -- Cheers, John From rdenis-usagi1@simphalempin.com Tue Mar 1 10:39:57 2005 Received: with ECARTIS (v1.0.0; list netdev); Tue, 01 Mar 2005 10:40:00 -0800 (PST) Received: from smtp10.wanadoo.fr (smtp10.wanadoo.fr [193.252.22.21]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j21IduwA023828 for ; Tue, 1 Mar 2005 10:39:57 -0800 Received: from me-wanadoo.net (localhost [127.0.0.1]) by mwinf1001.wanadoo.fr (SMTP Server) with ESMTP id 5051018000B9; Tue, 1 Mar 2005 19:39:50 +0100 (CET) Received: from ALille-251-1-3-135.w82-127.abo.wanadoo.fr (ALille-251-1-3-135.w82-127.abo.wanadoo.fr [82.127.145.135]) by mwinf1001.wanadoo.fr (SMTP Server) with ESMTP id 10C8C1800092; Tue, 1 Mar 2005 19:39:49 +0100 (CET) X-ME-UUID: 20050301183950688.10C8C1800092@mwinf1001.wanadoo.fr Received: from 192.168.1.64 by charlie.simphalempin.com with esmtp (masqmail 0.2.20) id 1D6CHf-0oP-00; Tue, 01 Mar 2005 19:39:51 +0100 From: =?iso-8859-1?q?R=E9mi_Denis-Courmont?= Organization: VIA Centrale =?utf-8?q?R=C3=A9seaux?= To: usagi-users@linux-ipv6.org Subject: Re: (usagi-users 03224) Re: support of IPv6 by NFS Date: Tue, 1 Mar 2005 19:39:49 +0100 User-Agent: KMail/1.7.2 Cc: Olaf Kirch , Jeroen Massar , netdev@oss.sgi.com References: <42243F8D.5030302@bull.net> <1109689712.17484.6.camel@firenze.zurich.ibm.com> <20050301161905.GD22324@suse.de> In-Reply-To: <20050301161905.GD22324@suse.de> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Disposition: inline Message-Id: <200503011939.50645.rdenis-usagi1@simphalempin.com> X-Virus-Scanned: ClamAV 0.83/737/Mon Feb 28 22:22:18 2005 on oss.sgi.com X-Virus-Status: Clean Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by oss.sgi.com id j21IduwA023828 X-archive-position: 2193 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: rdenis-usagi1@simphalempin.com Precedence: bulk X-list: netdev Le Mardi 1 Mars 2005 17:19, Olaf Kirch a écrit : > > The protocol for Teredo is open and can be implemented at will: > > Except that it's quite horrible, Yes, it is, and that's its biggest weakness. NAT traversal is horrible by design. So either you use a point-to-point tunnel over UDP (or TCP, but it is slow), either you end up with something horrible. > and it requires a centralized broker, Actually, Teredo is much more decentralised than, say, TSP. There could be several Teredo relays among the IPv6 world, from different entities, much like there are currently 6to4 relays. The only centralized thing is the server whose only purpose is autoconf and NAT traversal. > and IIRC it also makes assumptions about the way your NAT > implementation assigns ports. Yes, indeed. Unfortunately, the only way to avoid such assumptions is to use point-to-point IPv6 tunnels (or not try to use IPv6 from behind a NAT at all). Point-to-point tunneling might be fine, but, as far as I know, there is no automatic and registration-less IPv6 point-to-point tunneling solution at the moment :-( -- Rémi Denis-Courmont From buytenh@wantstofly.org Tue Mar 1 10:39:00 2005 Received: with ECARTIS (v1.0.0; list netdev); Tue, 01 Mar 2005 10:39:04 -0800 (PST) Received: from xi.wantstofly.org (alephnull.demon.nl [212.238.201.82]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j21IcxJj023596 for ; Tue, 1 Mar 2005 10:39:00 -0800 Received: by xi.wantstofly.org (Postfix, from userid 500) id A49C02B0EC; Tue, 1 Mar 2005 19:38:58 +0100 (MET) Date: Tue, 1 Mar 2005 19:38:58 +0100 From: Lennert Buytenhek To: John Ronciak Cc: netdev@oss.sgi.com, hadi@cyberus.ca, robert.olsson@data.slu.se Subject: Re: e1000 problem with NAPI? Message-ID: <20050301183858.GA15931@xi.wantstofly.org> References: <20050301135931.GA14610@xi.wantstofly.org> <56a8daef05030110137b712879@mail.gmail.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <56a8daef05030110137b712879@mail.gmail.com> User-Agent: Mutt/1.4.1i X-Virus-Scanned: ClamAV 0.83/737/Mon Feb 28 22:22:18 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 2192 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: buytenh@wantstofly.org Precedence: bulk X-list: netdev On Tue, Mar 01, 2005 at 10:13:34AM -0800, John Ronciak wrote: > Lennert, Hello, > It sounds like you are running into a bug we had with NAPI in that > e1000 driver. Robert actually found it. :-) Please try the 5.7.6 > driver available from Sourceforge. It has the fixed NAPI code in it. Works much better, thanks. It seems as if performance is much improved as well. With the old version (5.5.4-k2-NAPI), it would successfully receive ~350k pkts out of a 1Mpkt back-to-back tinygram burst and drop ~650k. With 5.7.6, it receives ~780k and drops ~220k. (82546GB dual copper GigE, dual Xeon 2.4 w/HT on an intel SE7505VB2.) cheers, Lennert From shemminger@osdl.org Tue Mar 1 10:43:33 2005 Received: with ECARTIS (v1.0.0; list netdev); Tue, 01 Mar 2005 10:43:38 -0800 (PST) Received: from smtp.osdl.org (fire.osdl.org [65.172.181.4]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j21IhWvg024876 for ; Tue, 1 Mar 2005 10:43:32 -0800 Received: from shell0.pdx.osdl.net (fw.osdl.org [65.172.181.6]) by smtp.osdl.org (8.12.8/8.12.8) with ESMTP id j21IhNqi001274 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO); Tue, 1 Mar 2005 10:43:24 -0800 Received: from dxpl.pdx.osdl.net (dxpl.pdx.osdl.net [172.20.1.103]) by shell0.pdx.osdl.net (8.13.1/8.11.6) with ESMTP id j21IhNNX025092; Tue, 1 Mar 2005 10:43:23 -0800 Date: Tue, 1 Mar 2005 10:43:38 -0800 From: Stephen Hemminger To: Andy Fleming Cc: Netdev , Jeff Garzik Subject: Re: RFC new ethtool command Message-ID: <20050301104338.1380b7cc@dxpl.pdx.osdl.net> In-Reply-To: <3a958240e12af10ef6777f908abfe682@freescale.com> References: <3a958240e12af10ef6777f908abfe682@freescale.com> Organization: Open Source Development Lab X-Mailer: Sylpheed-Claws 1.0.1 (GTK+ 1.2.10; x86_64-unknown-linux-gnu) X-Face: &@E+xe?c%:&e4D{>f1O<&U>2qwRREG5!}7R4;D<"NO^UI2mJ[eEOA2*3>(`Th.yP,VDPo9$ /`~cw![cmj~~jWe?AHY7D1S+\}5brN0k*NE?pPh_'_d>6;XGG[\KDRViCfumZT3@[ Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Received-SPF: pass (domain of shemminger@osdl.org designates 65.172.181.6 as permitted sender) X-MIMEDefang-Filter: osdl$Revision: 1.103 $ X-Scanned-By: MIMEDefang 2.36 X-Virus-Scanned: ClamAV 0.83/737/Mon Feb 28 22:22:18 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 2194 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: shemminger@osdl.org Precedence: bulk X-list: netdev On Tue, 1 Mar 2005 09:22:07 -0600 Andy Fleming wrote: > I propose adding a new command to ethtool which allows ethernet drivers > to specify a command list. A command list would consist of a > name/value pair, conforming to the cmdline_info structure already > present in ethtool. I see two immediate benefits of this system: > > 1) controllers which have "cutting-edge", or at least unusual, features > can easily add support for these features. As an example, the 85xx > allows the ethernet controller's DMA engine to allocate and/or lock > buffer descriptors into the L2 cache of the processor. Using this > method, a command could be created which is specific to that driver > which allows users to turn this feature on or off. > > 2) When debugging a new driver, or a new feature for an old driver, it > is easy to add a quick interface to change the testing parameters > without having to add new /proc entries. > > Three patches follow; the first allows ethtool to use this new feature, > the second allows the kernel to invoke the new feature, and the third > is an example of how the gianfar driver uses this feature to expose > failure testing features in the PHY-level code (note that this third > patch is not a final version. It also contains a few elements from the > PHY abstraction patch, which can be ignored for the purposes of this > discussion). I understand the motivation, but it seems to go against the philosophy of having a general purpose interface. Rather than having device driver specific special cases, why not add useful abstractions for new features. Phy interface testing and management is generic, and several devices could support it. This proposal is basically a device specific multiplexing interface like ioctl or SIOCDEVPRIVATE. This style of interface is considered bad, and undesirable. For the first case, of "cutting-edge" controller's, the best solution is to always turn the feature on and make it work correctly. If you can't make it work correctly then use module parameter or chip set detection to turn it off. Another option to expose warts is using sysfs attribute groups to add additional fields to /sys/class/net/ethXX/. When debugging a new driver, module parameters work find for controlling test parameters. If this needs to make into production code, sysfs could also be used. From Info@quantum-sci.com Tue Mar 1 11:07:40 2005 Received: with ECARTIS (v1.0.0; list netdev); Tue, 01 Mar 2005 11:07:44 -0800 (PST) Received: from xeonone.bizarre-host.com (xeonone.bizarre-host.com [70.84.110.116]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j21J7dBF026293 for ; Tue, 1 Mar 2005 11:07:40 -0800 Received: from c-24-1-62-21.client.comcast.net ([24.1.62.21] helo=hydra.darkmatter.org) by xeonone.bizarre-host.com with esmtpsa (SSLv3:RC4-MD5:128) (Exim 4.44) id 1D6Cic-0005eR-SN; Tue, 01 Mar 2005 19:07:42 +0000 From: Quantum Scientific To: netdev@oss.sgi.com, Jeroen Massar Subject: Re: (usagi-users 03222) Re: support of IPv6 by NFS Date: Tue, 1 Mar 2005 12:56:20 -0600 User-Agent: KMail/1.7.1 References: <42243F8D.5030302@bull.net> <200503010744.38339.Info@Quantum-Sci.com> <1109689712.17484.6.camel@firenze.zurich.ibm.com> In-Reply-To: <1109689712.17484.6.camel@firenze.zurich.ibm.com> Cc: usagi-users@linux-ipv6.org helo: PowerMAC MIME-Version: 1.0 Content-Disposition: inline Message-Id: <200503011256.25282.Info@quantum-sci.com> Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - xeonone.bizarre-host.com X-AntiAbuse: Original Domain - oss.sgi.com X-AntiAbuse: Originator/Caller UID/GID - [0 0] / [47 12] X-AntiAbuse: Sender Address Domain - quantum-sci.com X-Source: X-Source-Args: X-Source-Dir: X-Virus-Scanned: ClamAV 0.83/737/Mon Feb 28 22:22:18 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 2195 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: Info@quantum-sci.com Precedence: bulk X-list: netdev On Tuesday 01 March 2005 9:08, Jeroen Massar wrote: > On Tue, 2005-03-01 at 07:44 -0600, Quantum Scientific wrote: > >On Tuesday 01 March 2005 4:10, Gilles Quillard wrote: > >> This works but this needs that the kernel has been compiled with IPv6, > >> which is not mandotary. A lot of people in the Linux community do not > >> have experience with IPv6 yet and are not ready to use it. So making it > >> mandatory for NFS, even in a pure IPv4 network, is not easy. > > > >My experience is that IPV6 is extremely difficult to figure out how to set up > >securely, for the time being, due to lack of connection-sharing. > > NAT is not a firewall. Get that into your brain. Jeroen, was this addressed to me, or to Giles? Never mind, it doesn't matter; your words show that you are an uneducated man. On Tuesday 01 March 2005 9:08, Jeroen Massar wrote: > First couple of hits when doing a google on "Teredo BSD", or for you to > click as that might be difficult: > http://www.google.com/search?q=teredo+bsd ... > On Tue, 2005-03-01 at 07:44 -0600, Quantum Scientific wrote: > >Although I realize that all of us who run Linux are ostensibly uber-gurus, > >fact is this is a negative first experience for most, stemming from > >attempts by distros to encourage ppl to use it with an inoperative > >function, and without an obvious way to troubleshoot/repair. > > I can clearly assume that you are not part of the 'ostensibly > uber-gurus' you try to mention. And we can clearly assume that you are petty, and just an asshole. No, I am not a Linux uber-guru. I am a commercial real estate developer, using Linux as a hobby. You may not want my input, but others seem to, judging from emails I've gotten in back-channel about you. > Loads of people seem to have no problem at all with IPv6, getting it up > and running and actually using it for a lot of traffic. > That fact that you are only complaining, without doing any actual > research, typing two words in google, says enough. You are not even > capable of configuring your mailer properly to include your own name, > the field is not called "Realname" for nothing... Obviously you have not been following my emails, and have simply written your response to carp and ignorantly pretend you are superior in some way. This is no different than noise. As most here have ascertained, I said the things I have said, as reflective of the experiences of the majority when trying to set up IPV6. If you have a problem with that, you are unable to understand the true issues, and show it with every word. You will have no more responses from me. Carl Cook From akohlsmith@mixdown.ca Tue Mar 1 11:09:53 2005 Received: with ECARTIS (v1.0.0; list netdev); Tue, 01 Mar 2005 11:10:01 -0800 (PST) Received: from gromit.mixdown.ca (otherbrotherk-fw.mixdown.ca [165.154.13.35] (may be forged)) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j21J9mk2026853 for ; Tue, 1 Mar 2005 11:09:49 -0800 Received: from localhost (localhost [127.0.0.1]) by gromit.mixdown.ca (Postfix) with ESMTP id 1D23E2134A6B for ; Tue, 1 Mar 2005 14:16:02 -0500 (EST) From: Andrew Kohlsmith To: netdev@oss.sgi.com Subject: 2.6.10 and HTB dequeue bug Date: Tue, 1 Mar 2005 14:03:07 -0500 User-Agent: KMail/1.8 MIME-Version: 1.0 Content-Type: Multipart/Mixed; boundary="Boundary-00=_rxLJCJzqPO0Jvjl" Message-Id: <200503011403.07243.akohlsmith@mixdown.ca> X-Virus-Scanned: ClamAV 0.83/737/Mon Feb 28 22:22:18 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 2196 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: akohlsmith@mixdown.ca Precedence: bulk X-list: netdev --Boundary-00=_rxLJCJzqPO0Jvjl Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Content-Disposition: inline I received the following in my dmesg today. As requested by tgr in FreeNode's #lartc, I'm emailing all the requested information here. I'm using ipp2p version 0.7.1 (with a minor patch to make it work with 2.6.10) to detect p2p traffic, and a custom traffic shaping script (attached) to prioritize outgoing packets on both the ADSL and ethernet interfaces. Previous to this I was using the same setup on Slackware 9.1.0 with stock kernel 2.4.25. This is on a single P3/800 with an Intel eepro100 and Sangoma S518 PCI ADSL card. The box is running Slackware 10.0 with a stock kernel.org 2.6.10 kernel with no patches or changes aside from what Sangoma's beta5-2.3.2 drivers provide. (They are generally VERY well behaved and only modify the bare minimum to get their driver support in the kernel.) I've attached my kernel's configuration as well as lspci -v output, module list, ifconfig and ip link output. I will certainly provide any further information required. Regards, Andrew --Boundary-00=_rxLJCJzqPO0Jvjl Content-Type: text/plain; charset="us-ascii"; name="config" Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="config" # # Automatically generated make config: don't edit # Linux kernel version: 2.6.10 # Sun Feb 27 17:50:56 2005 # CONFIG_X86=y CONFIG_MMU=y CONFIG_UID16=y CONFIG_GENERIC_ISA_DMA=y CONFIG_GENERIC_IOMAP=y # # Code maturity level options # CONFIG_EXPERIMENTAL=y CONFIG_CLEAN_COMPILE=y CONFIG_LOCK_KERNEL=y # # General setup # CONFIG_LOCALVERSION="" CONFIG_SWAP=y CONFIG_SYSVIPC=y CONFIG_POSIX_MQUEUE=y CONFIG_BSD_PROCESS_ACCT=y CONFIG_BSD_PROCESS_ACCT_V3=y CONFIG_SYSCTL=y # CONFIG_AUDIT is not set CONFIG_LOG_BUF_SHIFT=14 CONFIG_HOTPLUG=y CONFIG_KOBJECT_UEVENT=y CONFIG_IKCONFIG=y CONFIG_IKCONFIG_PROC=y # CONFIG_EMBEDDED is not set CONFIG_KALLSYMS=y # CONFIG_KALLSYMS_ALL is not set # CONFIG_KALLSYMS_EXTRA_PASS is not set CONFIG_FUTEX=y CONFIG_EPOLL=y # CONFIG_CC_OPTIMIZE_FOR_SIZE is not set CONFIG_SHMEM=y CONFIG_CC_ALIGN_FUNCTIONS=0 CONFIG_CC_ALIGN_LABELS=0 CONFIG_CC_ALIGN_LOOPS=0 CONFIG_CC_ALIGN_JUMPS=0 # CONFIG_TINY_SHMEM is not set # # Loadable module support # CONFIG_MODULES=y CONFIG_MODULE_UNLOAD=y CONFIG_MODULE_FORCE_UNLOAD=y CONFIG_OBSOLETE_MODPARM=y # CONFIG_MODVERSIONS is not set CONFIG_MODULE_SRCVERSION_ALL=y CONFIG_KMOD=y CONFIG_STOP_MACHINE=y # # Processor type and features # CONFIG_X86_PC=y # CONFIG_X86_ELAN is not set # CONFIG_X86_VOYAGER is not set # CONFIG_X86_NUMAQ is not set # CONFIG_X86_SUMMIT is not set # CONFIG_X86_BIGSMP is not set # CONFIG_X86_VISWS is not set # CONFIG_X86_GENERICARCH is not set # CONFIG_X86_ES7000 is not set # CONFIG_M386 is not set # CONFIG_M486 is not set # CONFIG_M586 is not set # CONFIG_M586TSC is not set # CONFIG_M586MMX is not set # CONFIG_M686 is not set # CONFIG_MPENTIUMII is not set CONFIG_MPENTIUMIII=y # CONFIG_MPENTIUMM is not set # CONFIG_MPENTIUM4 is not set # CONFIG_MK6 is not set # CONFIG_MK7 is not set # CONFIG_MK8 is not set # CONFIG_MCRUSOE is not set # CONFIG_MEFFICEON is not set # CONFIG_MWINCHIPC6 is not set # CONFIG_MWINCHIP2 is not set # CONFIG_MWINCHIP3D is not set # CONFIG_MCYRIXIII is not set # CONFIG_MVIAC3_2 is not set # CONFIG_X86_GENERIC is not set CONFIG_X86_CMPXCHG=y CONFIG_X86_XADD=y CONFIG_X86_L1_CACHE_SHIFT=5 CONFIG_RWSEM_XCHGADD_ALGORITHM=y CONFIG_X86_WP_WORKS_OK=y CONFIG_X86_INVLPG=y CONFIG_X86_BSWAP=y CONFIG_X86_POPAD_OK=y CONFIG_X86_GOOD_APIC=y CONFIG_X86_INTEL_USERCOPY=y CONFIG_X86_USE_PPRO_CHECKSUM=y CONFIG_HPET_TIMER=y CONFIG_HPET_EMULATE_RTC=y CONFIG_SMP=y CONFIG_NR_CPUS=2 CONFIG_SCHED_SMT=y CONFIG_PREEMPT=y CONFIG_X86_LOCAL_APIC=y CONFIG_X86_IO_APIC=y CONFIG_X86_TSC=y CONFIG_X86_MCE=y CONFIG_X86_MCE_NONFATAL=y CONFIG_X86_MCE_P4THERMAL=y # CONFIG_TOSHIBA is not set # CONFIG_I8K is not set CONFIG_MICROCODE=m CONFIG_X86_MSR=m CONFIG_X86_CPUID=m # # Firmware Drivers # CONFIG_EDD=m CONFIG_NOHIGHMEM=y # CONFIG_HIGHMEM4G is not set # CONFIG_HIGHMEM64G is not set # CONFIG_MATH_EMULATION is not set CONFIG_MTRR=y # CONFIG_EFI is not set CONFIG_IRQBALANCE=y CONFIG_HAVE_DEC_LOCK=y CONFIG_REGPARM=y # # Power management options (ACPI, APM) # CONFIG_PM=y # CONFIG_PM_DEBUG is not set CONFIG_SOFTWARE_SUSPEND=y CONFIG_PM_STD_PARTITION="" # # ACPI (Advanced Configuration and Power Interface) Support # CONFIG_ACPI=y CONFIG_ACPI_BOOT=y CONFIG_ACPI_INTERPRETER=y CONFIG_ACPI_SLEEP=y CONFIG_ACPI_SLEEP_PROC_FS=y CONFIG_ACPI_AC=y CONFIG_ACPI_BATTERY=y CONFIG_ACPI_BUTTON=y # CONFIG_ACPI_VIDEO is not set CONFIG_ACPI_FAN=y CONFIG_ACPI_PROCESSOR=y CONFIG_ACPI_THERMAL=y # CONFIG_ACPI_ASUS is not set # CONFIG_ACPI_IBM is not set # CONFIG_ACPI_TOSHIBA is not set CONFIG_ACPI_BLACKLIST_YEAR=0 # CONFIG_ACPI_DEBUG is not set CONFIG_ACPI_BUS=y CONFIG_ACPI_EC=y CONFIG_ACPI_POWER=y CONFIG_ACPI_PCI=y CONFIG_ACPI_SYSTEM=y CONFIG_X86_PM_TIMER=y # # APM (Advanced Power Management) BIOS Support # # CONFIG_APM is not set # # CPU Frequency scaling # CONFIG_CPU_FREQ=y # CONFIG_CPU_FREQ_DEBUG is not set # CONFIG_CPU_FREQ_PROC_INTF is not set CONFIG_CPU_FREQ_DEFAULT_GOV_PERFORMANCE=y # CONFIG_CPU_FREQ_DEFAULT_GOV_USERSPACE is not set CONFIG_CPU_FREQ_GOV_PERFORMANCE=y CONFIG_CPU_FREQ_GOV_POWERSAVE=y CONFIG_CPU_FREQ_GOV_USERSPACE=y # CONFIG_CPU_FREQ_24_API is not set # CONFIG_CPU_FREQ_GOV_ONDEMAND is not set CONFIG_CPU_FREQ_TABLE=y # # CPUFreq processor drivers # CONFIG_X86_ACPI_CPUFREQ=y # CONFIG_X86_POWERNOW_K6 is not set # CONFIG_X86_POWERNOW_K7 is not set # CONFIG_X86_POWERNOW_K8 is not set # CONFIG_X86_GX_SUSPMOD is not set CONFIG_X86_SPEEDSTEP_CENTRINO=y CONFIG_X86_SPEEDSTEP_CENTRINO_ACPI=y CONFIG_X86_SPEEDSTEP_CENTRINO_TABLE=y CONFIG_X86_SPEEDSTEP_ICH=y CONFIG_X86_SPEEDSTEP_SMI=y CONFIG_X86_P4_CLOCKMOD=y # CONFIG_X86_CPUFREQ_NFORCE2 is not set # CONFIG_X86_LONGRUN is not set # CONFIG_X86_LONGHAUL is not set # # shared options # # CONFIG_X86_ACPI_CPUFREQ_PROC_INTF is not set CONFIG_X86_SPEEDSTEP_LIB=y # CONFIG_X86_SPEEDSTEP_RELAXED_CAP_CHECK is not set # # Bus options (PCI, PCMCIA, EISA, MCA, ISA) # CONFIG_PCI=y # CONFIG_PCI_GOBIOS is not set # CONFIG_PCI_GOMMCONFIG is not set # CONFIG_PCI_GODIRECT is not set CONFIG_PCI_GOANY=y CONFIG_PCI_BIOS=y CONFIG_PCI_DIRECT=y CONFIG_PCI_MMCONFIG=y # CONFIG_PCI_MSI is not set # CONFIG_PCI_LEGACY_PROC is not set CONFIG_PCI_NAMES=y CONFIG_ISA=y # CONFIG_EISA is not set # CONFIG_MCA is not set CONFIG_SCx200=m # # PCCARD (PCMCIA/CardBus) support # # CONFIG_PCCARD is not set # # PC-card bridges # CONFIG_PCMCIA_PROBE=y # # PCI Hotplug Support # CONFIG_HOTPLUG_PCI=m CONFIG_HOTPLUG_PCI_FAKE=m CONFIG_HOTPLUG_PCI_COMPAQ=m # CONFIG_HOTPLUG_PCI_COMPAQ_NVRAM is not set # CONFIG_HOTPLUG_PCI_IBM is not set # CONFIG_HOTPLUG_PCI_ACPI is not set # CONFIG_HOTPLUG_PCI_CPCI is not set # CONFIG_HOTPLUG_PCI_PCIE is not set # CONFIG_HOTPLUG_PCI_SHPC is not set # # Executable file formats # CONFIG_BINFMT_ELF=y # CONFIG_BINFMT_AOUT is not set # CONFIG_BINFMT_MISC is not set # # Device Drivers # # # Generic Driver Options # CONFIG_STANDALONE=y CONFIG_PREVENT_FIRMWARE_BUILD=y CONFIG_FW_LOADER=m # CONFIG_DEBUG_DRIVER is not set # # Memory Technology Devices (MTD) # # CONFIG_MTD is not set # # Parallel port support # CONFIG_PARPORT=m CONFIG_PARPORT_PC=m CONFIG_PARPORT_PC_CML1=m CONFIG_PARPORT_SERIAL=m CONFIG_PARPORT_PC_FIFO=y CONFIG_PARPORT_PC_SUPERIO=y # CONFIG_PARPORT_OTHER is not set CONFIG_PARPORT_1284=y # # Plug and Play support # # CONFIG_PNP is not set # # Block devices # CONFIG_BLK_DEV_FD=y CONFIG_BLK_DEV_XD=m CONFIG_PARIDE=m CONFIG_PARIDE_PARPORT=m # # Parallel IDE high-level drivers # CONFIG_PARIDE_PD=m CONFIG_PARIDE_PCD=m CONFIG_PARIDE_PF=m CONFIG_PARIDE_PT=m CONFIG_PARIDE_PG=m # # Parallel IDE protocol modules # CONFIG_PARIDE_ATEN=m CONFIG_PARIDE_BPCK=m CONFIG_PARIDE_BPCK6=m CONFIG_PARIDE_COMM=m CONFIG_PARIDE_DSTR=m CONFIG_PARIDE_FIT2=m CONFIG_PARIDE_FIT3=m CONFIG_PARIDE_EPAT=m CONFIG_PARIDE_EPATC8=y CONFIG_PARIDE_EPIA=m CONFIG_PARIDE_FRIQ=m CONFIG_PARIDE_FRPW=m CONFIG_PARIDE_KBIC=m CONFIG_PARIDE_KTTI=m CONFIG_PARIDE_ON20=m CONFIG_PARIDE_ON26=m CONFIG_BLK_CPQ_DA=m CONFIG_BLK_CPQ_CISS_DA=m CONFIG_CISS_SCSI_TAPE=y CONFIG_BLK_DEV_DAC960=m CONFIG_BLK_DEV_UMEM=m CONFIG_BLK_DEV_LOOP=y CONFIG_BLK_DEV_CRYPTOLOOP=m CONFIG_BLK_DEV_NBD=m # CONFIG_BLK_DEV_SX8 is not set # CONFIG_BLK_DEV_UB is not set CONFIG_BLK_DEV_RAM=y CONFIG_BLK_DEV_RAM_COUNT=16 CONFIG_BLK_DEV_RAM_SIZE=7777 CONFIG_BLK_DEV_INITRD=y CONFIG_INITRAMFS_SOURCE="" CONFIG_LBD=y # CONFIG_CDROM_PKTCDVD is not set # # IO Schedulers # CONFIG_IOSCHED_NOOP=y CONFIG_IOSCHED_AS=y CONFIG_IOSCHED_DEADLINE=y CONFIG_IOSCHED_CFQ=y # # ATA/ATAPI/MFM/RLL support # CONFIG_IDE=y CONFIG_BLK_DEV_IDE=y # # Please see Documentation/ide.txt for help/info on IDE drives # # CONFIG_BLK_DEV_IDE_SATA is not set # CONFIG_BLK_DEV_HD_IDE is not set CONFIG_BLK_DEV_IDEDISK=y # CONFIG_IDEDISK_MULTI_MODE is not set CONFIG_BLK_DEV_IDECD=y CONFIG_BLK_DEV_IDETAPE=m CONFIG_BLK_DEV_IDEFLOPPY=y CONFIG_BLK_DEV_IDESCSI=m # CONFIG_IDE_TASK_IOCTL is not set # # IDE chipset support/bugfixes # CONFIG_IDE_GENERIC=y CONFIG_BLK_DEV_CMD640=y # CONFIG_BLK_DEV_CMD640_ENHANCED is not set CONFIG_BLK_DEV_IDEPCI=y CONFIG_IDEPCI_SHARE_IRQ=y # CONFIG_BLK_DEV_OFFBOARD is not set CONFIG_BLK_DEV_GENERIC=y # CONFIG_BLK_DEV_OPTI621 is not set CONFIG_BLK_DEV_RZ1000=y CONFIG_BLK_DEV_IDEDMA_PCI=y # CONFIG_BLK_DEV_IDEDMA_FORCED is not set CONFIG_IDEDMA_PCI_AUTO=y # CONFIG_IDEDMA_ONLYDISK is not set CONFIG_BLK_DEV_AEC62XX=y CONFIG_BLK_DEV_ALI15X3=y # CONFIG_WDC_ALI15X3 is not set CONFIG_BLK_DEV_AMD74XX=y CONFIG_BLK_DEV_ATIIXP=y CONFIG_BLK_DEV_CMD64X=y CONFIG_BLK_DEV_TRIFLEX=y # CONFIG_BLK_DEV_CY82C693 is not set # CONFIG_BLK_DEV_CS5520 is not set CONFIG_BLK_DEV_CS5530=y CONFIG_BLK_DEV_HPT34X=y # CONFIG_HPT34X_AUTODMA is not set CONFIG_BLK_DEV_HPT366=y CONFIG_BLK_DEV_SC1200=y CONFIG_BLK_DEV_PIIX=y # CONFIG_BLK_DEV_NS87415 is not set CONFIG_BLK_DEV_PDC202XX_OLD=y # CONFIG_PDC202XX_BURST is not set CONFIG_BLK_DEV_PDC202XX_NEW=y # CONFIG_PDC202XX_FORCE is not set CONFIG_BLK_DEV_SVWKS=y CONFIG_BLK_DEV_SIIMAGE=y CONFIG_BLK_DEV_SIS5513=y CONFIG_BLK_DEV_SLC90E66=y # CONFIG_BLK_DEV_TRM290 is not set CONFIG_BLK_DEV_VIA82CXXX=y # CONFIG_IDE_ARM is not set CONFIG_IDE_CHIPSETS=y # # Note: most of these also require special kernel boot parameters # CONFIG_BLK_DEV_4DRIVES=y CONFIG_BLK_DEV_ALI14XX=y CONFIG_BLK_DEV_DTC2278=y CONFIG_BLK_DEV_HT6560B=y CONFIG_BLK_DEV_QD65XX=y CONFIG_BLK_DEV_UMC8672=y CONFIG_BLK_DEV_IDEDMA=y # CONFIG_IDEDMA_IVB is not set CONFIG_IDEDMA_AUTO=y # CONFIG_BLK_DEV_HD is not set # # SCSI device support # CONFIG_SCSI=y CONFIG_SCSI_PROC_FS=y # # SCSI support type (disk, tape, CD-ROM) # CONFIG_BLK_DEV_SD=y CONFIG_CHR_DEV_ST=m CONFIG_CHR_DEV_OSST=m CONFIG_BLK_DEV_SR=y # CONFIG_BLK_DEV_SR_VENDOR is not set CONFIG_CHR_DEV_SG=y # # Some SCSI devices (e.g. CD jukebox) support multiple LUNs # # CONFIG_SCSI_MULTI_LUN is not set # CONFIG_SCSI_CONSTANTS is not set # CONFIG_SCSI_LOGGING is not set # # SCSI Transport Attributes # CONFIG_SCSI_SPI_ATTRS=m # CONFIG_SCSI_FC_ATTRS is not set # # SCSI low-level drivers # CONFIG_BLK_DEV_3W_XXXX_RAID=m # CONFIG_SCSI_3W_9XXX is not set CONFIG_SCSI_7000FASST=m CONFIG_SCSI_ACARD=m CONFIG_SCSI_AHA152X=m CONFIG_SCSI_AHA1542=m CONFIG_SCSI_AACRAID=m CONFIG_SCSI_AIC7XXX=m CONFIG_AIC7XXX_CMDS_PER_DEVICE=8 CONFIG_AIC7XXX_RESET_DELAY_MS=15000 # CONFIG_AIC7XXX_DEBUG_ENABLE is not set CONFIG_AIC7XXX_DEBUG_MASK=0 # CONFIG_AIC7XXX_REG_PRETTY_PRINT is not set CONFIG_SCSI_AIC7XXX_OLD=m CONFIG_SCSI_AIC79XX=m CONFIG_AIC79XX_CMDS_PER_DEVICE=32 CONFIG_AIC79XX_RESET_DELAY_MS=15000 # CONFIG_AIC79XX_ENABLE_RD_STRM is not set # CONFIG_AIC79XX_DEBUG_ENABLE is not set CONFIG_AIC79XX_DEBUG_MASK=0 # CONFIG_AIC79XX_REG_PRETTY_PRINT is not set CONFIG_SCSI_DPT_I2O=m CONFIG_SCSI_IN2000=m # CONFIG_MEGARAID_NEWGEN is not set # CONFIG_MEGARAID_LEGACY is not set # CONFIG_SCSI_SATA is not set CONFIG_SCSI_BUSLOGIC=m # CONFIG_SCSI_OMIT_FLASHPOINT is not set CONFIG_SCSI_DMX3191D=m CONFIG_SCSI_DTC3280=m CONFIG_SCSI_EATA=m # CONFIG_SCSI_EATA_TAGGED_QUEUE is not set # CONFIG_SCSI_EATA_LINKED_COMMANDS is not set CONFIG_SCSI_EATA_MAX_TAGS=16 CONFIG_SCSI_EATA_PIO=m CONFIG_SCSI_FUTURE_DOMAIN=m CONFIG_SCSI_GDTH=m CONFIG_SCSI_GENERIC_NCR5380=m # CONFIG_SCSI_GENERIC_NCR5380_MMIO is not set CONFIG_SCSI_GENERIC_NCR53C400=y CONFIG_SCSI_IPS=m # CONFIG_SCSI_INITIO is not set CONFIG_SCSI_INIA100=m CONFIG_SCSI_PPA=m CONFIG_SCSI_IMM=m CONFIG_SCSI_IZIP_EPP16=y # CONFIG_SCSI_IZIP_SLOW_CTR is not set CONFIG_SCSI_NCR53C406A=m CONFIG_SCSI_SYM53C8XX_2=m CONFIG_SCSI_SYM53C8XX_DMA_ADDRESSING_MODE=1 CONFIG_SCSI_SYM53C8XX_DEFAULT_TAGS=16 CONFIG_SCSI_SYM53C8XX_MAX_TAGS=64 # CONFIG_SCSI_SYM53C8XX_IOMAPPED is not set # CONFIG_SCSI_IPR is not set CONFIG_SCSI_PAS16=m CONFIG_SCSI_PSI240I=m CONFIG_SCSI_QLOGIC_FAS=m CONFIG_SCSI_QLOGIC_ISP=m CONFIG_SCSI_QLOGIC_FC=m CONFIG_SCSI_QLOGIC_FC_FIRMWARE=y CONFIG_SCSI_QLOGIC_1280=m # CONFIG_SCSI_QLOGIC_1280_1040 is not set CONFIG_SCSI_QLA2XXX=y # CONFIG_SCSI_QLA21XX is not set # CONFIG_SCSI_QLA22XX is not set # CONFIG_SCSI_QLA2300 is not set # CONFIG_SCSI_QLA2322 is not set # CONFIG_SCSI_QLA6312 is not set # CONFIG_SCSI_QLA6322 is not set CONFIG_SCSI_SYM53C416=m # CONFIG_SCSI_DC395x is not set CONFIG_SCSI_DC390T=m CONFIG_SCSI_T128=m CONFIG_SCSI_U14_34F=m # CONFIG_SCSI_U14_34F_TAGGED_QUEUE is not set # CONFIG_SCSI_U14_34F_LINKED_COMMANDS is not set CONFIG_SCSI_U14_34F_MAX_TAGS=8 CONFIG_SCSI_ULTRASTOR=m CONFIG_SCSI_NSP32=m CONFIG_SCSI_DEBUG=m # # Old CD-ROM drivers (not SCSI, not IDE) # # CONFIG_CD_NO_IDESCSI is not set # # Multi-device support (RAID and LVM) # CONFIG_MD=y CONFIG_BLK_DEV_MD=y CONFIG_MD_LINEAR=y CONFIG_MD_RAID0=y CONFIG_MD_RAID1=y # CONFIG_MD_RAID10 is not set CONFIG_MD_RAID5=y # CONFIG_MD_RAID6 is not set CONFIG_MD_MULTIPATH=y # CONFIG_MD_FAULTY is not set CONFIG_BLK_DEV_DM=y CONFIG_DM_CRYPT=m CONFIG_DM_SNAPSHOT=m CONFIG_DM_MIRROR=m CONFIG_DM_ZERO=m # # Fusion MPT device support # # CONFIG_FUSION is not set # # IEEE 1394 (FireWire) support # CONFIG_IEEE1394=m # # Subsystem Options # # CONFIG_IEEE1394_VERBOSEDEBUG is not set CONFIG_IEEE1394_OUI_DB=y CONFIG_IEEE1394_EXTRA_CONFIG_ROMS=y CONFIG_IEEE1394_CONFIG_ROM_IP1394=y # # Device Drivers # CONFIG_IEEE1394_PCILYNX=m CONFIG_IEEE1394_OHCI1394=m # # Protocol Drivers # CONFIG_IEEE1394_VIDEO1394=m CONFIG_IEEE1394_SBP2=m # CONFIG_IEEE1394_SBP2_PHYS_DMA is not set CONFIG_IEEE1394_ETH1394=m CONFIG_IEEE1394_DV1394=m CONFIG_IEEE1394_RAWIO=m CONFIG_IEEE1394_CMP=m CONFIG_IEEE1394_AMDTP=m # # I2O device support # CONFIG_I2O=m CONFIG_I2O_CONFIG=m CONFIG_I2O_BLOCK=m CONFIG_I2O_SCSI=m CONFIG_I2O_PROC=m # # Networking support # CONFIG_NET=y # # Networking options # CONFIG_PACKET=y CONFIG_PACKET_MMAP=y CONFIG_NETLINK_DEV=m CONFIG_UNIX=y CONFIG_NET_KEY=y CONFIG_INET=y CONFIG_IP_MULTICAST=y CONFIG_IP_ADVANCED_ROUTER=y CONFIG_IP_MULTIPLE_TABLES=y CONFIG_IP_ROUTE_FWMARK=y CONFIG_IP_ROUTE_MULTIPATH=y CONFIG_IP_ROUTE_VERBOSE=y # CONFIG_IP_PNP is not set CONFIG_NET_IPIP=m CONFIG_NET_IPGRE=m CONFIG_NET_IPGRE_BROADCAST=y CONFIG_IP_MROUTE=y CONFIG_IP_PIMSM_V1=y # CONFIG_IP_PIMSM_V2 is not set # CONFIG_ARPD is not set CONFIG_SYN_COOKIES=y CONFIG_INET_AH=m CONFIG_INET_ESP=m CONFIG_INET_IPCOMP=m CONFIG_INET_TUNNEL=m CONFIG_IP_TCPDIAG=y # CONFIG_IP_TCPDIAG_IPV6 is not set # # IP: Virtual Server Configuration # CONFIG_IP_VS=m # CONFIG_IP_VS_DEBUG is not set CONFIG_IP_VS_TAB_BITS=12 # # IPVS transport protocol load balancing support # CONFIG_IP_VS_PROTO_TCP=y CONFIG_IP_VS_PROTO_UDP=y CONFIG_IP_VS_PROTO_ESP=y CONFIG_IP_VS_PROTO_AH=y # # IPVS scheduler # CONFIG_IP_VS_RR=m CONFIG_IP_VS_WRR=m CONFIG_IP_VS_LC=m CONFIG_IP_VS_WLC=m CONFIG_IP_VS_LBLC=m CONFIG_IP_VS_LBLCR=m CONFIG_IP_VS_DH=m CONFIG_IP_VS_SH=m CONFIG_IP_VS_SED=m CONFIG_IP_VS_NQ=m # # IPVS application helper # # CONFIG_IP_VS_FTP is not set # CONFIG_IPV6 is not set CONFIG_NETFILTER=y # CONFIG_NETFILTER_DEBUG is not set CONFIG_BRIDGE_NETFILTER=y # # IP: Netfilter Configuration # CONFIG_IP_NF_CONNTRACK=m CONFIG_IP_NF_CT_ACCT=y CONFIG_IP_NF_CONNTRACK_MARK=y CONFIG_IP_NF_CT_PROTO_SCTP=m CONFIG_IP_NF_FTP=m CONFIG_IP_NF_IRC=m CONFIG_IP_NF_TFTP=m CONFIG_IP_NF_AMANDA=m CONFIG_IP_NF_QUEUE=m CONFIG_IP_NF_IPTABLES=m CONFIG_IP_NF_MATCH_LIMIT=m CONFIG_IP_NF_MATCH_IPRANGE=m CONFIG_IP_NF_MATCH_MAC=m CONFIG_IP_NF_MATCH_PKTTYPE=m CONFIG_IP_NF_MATCH_MARK=m CONFIG_IP_NF_MATCH_MULTIPORT=m CONFIG_IP_NF_MATCH_TOS=m CONFIG_IP_NF_MATCH_RECENT=m CONFIG_IP_NF_MATCH_ECN=m CONFIG_IP_NF_MATCH_DSCP=m CONFIG_IP_NF_MATCH_AH_ESP=m CONFIG_IP_NF_MATCH_LENGTH=m CONFIG_IP_NF_MATCH_TTL=m CONFIG_IP_NF_MATCH_TCPMSS=m CONFIG_IP_NF_MATCH_HELPER=m CONFIG_IP_NF_MATCH_STATE=m CONFIG_IP_NF_MATCH_CONNTRACK=m CONFIG_IP_NF_MATCH_OWNER=m CONFIG_IP_NF_MATCH_PHYSDEV=m CONFIG_IP_NF_MATCH_ADDRTYPE=m CONFIG_IP_NF_MATCH_REALM=m CONFIG_IP_NF_MATCH_SCTP=m CONFIG_IP_NF_MATCH_COMMENT=m CONFIG_IP_NF_MATCH_CONNMARK=m CONFIG_IP_NF_MATCH_HASHLIMIT=m CONFIG_IP_NF_FILTER=m CONFIG_IP_NF_TARGET_REJECT=m CONFIG_IP_NF_TARGET_LOG=m CONFIG_IP_NF_TARGET_ULOG=m CONFIG_IP_NF_TARGET_TCPMSS=m CONFIG_IP_NF_NAT=m CONFIG_IP_NF_NAT_NEEDED=y CONFIG_IP_NF_TARGET_MASQUERADE=m CONFIG_IP_NF_TARGET_REDIRECT=m CONFIG_IP_NF_TARGET_NETMAP=m CONFIG_IP_NF_TARGET_SAME=m # CONFIG_IP_NF_NAT_LOCAL is not set CONFIG_IP_NF_NAT_SNMP_BASIC=m CONFIG_IP_NF_NAT_IRC=m CONFIG_IP_NF_NAT_FTP=m CONFIG_IP_NF_NAT_TFTP=m CONFIG_IP_NF_NAT_AMANDA=m CONFIG_IP_NF_MANGLE=m CONFIG_IP_NF_TARGET_TOS=m CONFIG_IP_NF_TARGET_ECN=m CONFIG_IP_NF_TARGET_DSCP=m CONFIG_IP_NF_TARGET_MARK=m CONFIG_IP_NF_TARGET_CLASSIFY=m CONFIG_IP_NF_TARGET_CONNMARK=m CONFIG_IP_NF_TARGET_CLUSTERIP=m CONFIG_IP_NF_RAW=m CONFIG_IP_NF_TARGET_NOTRACK=m CONFIG_IP_NF_ARPTABLES=m CONFIG_IP_NF_ARPFILTER=m CONFIG_IP_NF_ARP_MANGLE=m # CONFIG_IP_NF_COMPAT_IPCHAINS is not set # CONFIG_IP_NF_COMPAT_IPFWADM is not set # # Bridge: Netfilter Configuration # CONFIG_BRIDGE_NF_EBTABLES=m CONFIG_BRIDGE_EBT_BROUTE=m CONFIG_BRIDGE_EBT_T_FILTER=m CONFIG_BRIDGE_EBT_T_NAT=m CONFIG_BRIDGE_EBT_802_3=m CONFIG_BRIDGE_EBT_AMONG=m CONFIG_BRIDGE_EBT_ARP=m CONFIG_BRIDGE_EBT_IP=m CONFIG_BRIDGE_EBT_LIMIT=m CONFIG_BRIDGE_EBT_MARK=m CONFIG_BRIDGE_EBT_PKTTYPE=m CONFIG_BRIDGE_EBT_STP=m CONFIG_BRIDGE_EBT_VLAN=m CONFIG_BRIDGE_EBT_ARPREPLY=m CONFIG_BRIDGE_EBT_DNAT=m CONFIG_BRIDGE_EBT_MARK_T=m CONFIG_BRIDGE_EBT_REDIRECT=m CONFIG_BRIDGE_EBT_SNAT=m CONFIG_BRIDGE_EBT_LOG=m CONFIG_XFRM=y CONFIG_XFRM_USER=m # # SCTP Configuration (EXPERIMENTAL) # CONFIG_IP_SCTP=m # CONFIG_SCTP_DBG_MSG is not set # CONFIG_SCTP_DBG_OBJCNT is not set # CONFIG_SCTP_HMAC_NONE is not set # CONFIG_SCTP_HMAC_SHA1 is not set CONFIG_SCTP_HMAC_MD5=y # CONFIG_ATM is not set CONFIG_BRIDGE=m CONFIG_VLAN_8021Q=m # CONFIG_DECNET is not set # CONFIG_LLC2 is not set # CONFIG_IPX is not set # CONFIG_ATALK is not set # CONFIG_X25 is not set # CONFIG_LAPB is not set # CONFIG_NET_DIVERT is not set # CONFIG_ECONET is not set CONFIG_WAN_ROUTER=m # # QoS and/or fair queueing # CONFIG_NET_SCHED=y # CONFIG_NET_SCH_CLK_JIFFIES is not set # CONFIG_NET_SCH_CLK_GETTIMEOFDAY is not set CONFIG_NET_SCH_CLK_CPU=y CONFIG_NET_SCH_CBQ=m CONFIG_NET_SCH_HTB=m CONFIG_NET_SCH_HFSC=m CONFIG_NET_SCH_PRIO=m CONFIG_NET_SCH_RED=m CONFIG_NET_SCH_SFQ=m CONFIG_NET_SCH_TEQL=m CONFIG_NET_SCH_TBF=m CONFIG_NET_SCH_GRED=m CONFIG_NET_SCH_DSMARK=m CONFIG_NET_SCH_NETEM=m CONFIG_NET_SCH_INGRESS=m CONFIG_NET_QOS=y CONFIG_NET_ESTIMATOR=y CONFIG_NET_CLS=y CONFIG_NET_CLS_TCINDEX=m CONFIG_NET_CLS_ROUTE4=m CONFIG_NET_CLS_ROUTE=y CONFIG_NET_CLS_FW=m CONFIG_NET_CLS_U32=m CONFIG_CLS_U32_PERF=y # CONFIG_NET_CLS_IND is not set CONFIG_NET_CLS_RSVP=m CONFIG_NET_CLS_RSVP6=m CONFIG_NET_CLS_ACT=y CONFIG_NET_ACT_POLICE=y CONFIG_NET_ACT_GACT=m CONFIG_GACT_PROB=y CONFIG_NET_ACT_MIRRED=m CONFIG_NET_ACT_IPT=m CONFIG_NET_ACT_PEDIT=m # # Network testing # CONFIG_NET_PKTGEN=m # CONFIG_NETPOLL is not set # CONFIG_NET_POLL_CONTROLLER is not set CONFIG_HAMRADIO=y # # Packet Radio protocols # CONFIG_AX25=m CONFIG_AX25_DAMA_SLAVE=y CONFIG_NETROM=m CONFIG_ROSE=m # # AX.25 network device drivers # CONFIG_BPQETHER=m CONFIG_SCC=m CONFIG_SCC_DELAY=y CONFIG_SCC_TRXECHO=y CONFIG_BAYCOM_SER_FDX=m CONFIG_BAYCOM_SER_HDX=m CONFIG_BAYCOM_PAR=m CONFIG_BAYCOM_EPP=m CONFIG_YAM=m CONFIG_IRDA=m # # IrDA protocols # CONFIG_IRLAN=m CONFIG_IRNET=m CONFIG_IRCOMM=m # CONFIG_IRDA_ULTRA is not set # # IrDA options # CONFIG_IRDA_CACHE_LAST_LSAP=y CONFIG_IRDA_FAST_RR=y # CONFIG_IRDA_DEBUG is not set # # Infrared-port device drivers # # # SIR device drivers # CONFIG_IRTTY_SIR=m # # Dongle support # CONFIG_DONGLE=y CONFIG_ESI_DONGLE=m CONFIG_ACTISYS_DONGLE=m CONFIG_TEKRAM_DONGLE=m CONFIG_LITELINK_DONGLE=m CONFIG_MA600_DONGLE=m CONFIG_GIRBIL_DONGLE=m CONFIG_MCP2120_DONGLE=m CONFIG_OLD_BELKIN_DONGLE=m CONFIG_ACT200L_DONGLE=m # # Old SIR device drivers # # # Old Serial dongle support # # # FIR device drivers # CONFIG_USB_IRDA=m # CONFIG_SIGMATEL_FIR is not set CONFIG_NSC_FIR=m CONFIG_WINBOND_FIR=m CONFIG_TOSHIBA_FIR=m CONFIG_SMC_IRCC_FIR=m CONFIG_ALI_FIR=m CONFIG_VLSI_FIR=m # CONFIG_VIA_FIR is not set CONFIG_BT=m CONFIG_BT_L2CAP=m CONFIG_BT_SCO=m CONFIG_BT_RFCOMM=m CONFIG_BT_RFCOMM_TTY=y CONFIG_BT_BNEP=m CONFIG_BT_BNEP_MC_FILTER=y CONFIG_BT_BNEP_PROTO_FILTER=y CONFIG_BT_HIDP=m # # Bluetooth device drivers # CONFIG_BT_HCIUSB=m CONFIG_BT_HCIUSB_SCO=y CONFIG_BT_HCIUART=m CONFIG_BT_HCIUART_H4=y CONFIG_BT_HCIUART_BCSP=y # CONFIG_BT_HCIUART_BCSP_TXCRC is not set CONFIG_BT_HCIBCM203X=m CONFIG_BT_HCIBFUSB=m CONFIG_BT_HCIVHCI=m CONFIG_NETDEVICES=y CONFIG_DUMMY=m CONFIG_BONDING=m CONFIG_EQUALIZER=m CONFIG_TUN=m CONFIG_ETHERTAP=m # # ARCnet devices # # CONFIG_ARCNET is not set # # Ethernet (10 or 100Mbit) # CONFIG_NET_ETHERNET=y CONFIG_MII=y CONFIG_HAPPYMEAL=m CONFIG_SUNGEM=m CONFIG_NET_VENDOR_3COM=y CONFIG_EL1=m CONFIG_EL2=m CONFIG_ELPLUS=m CONFIG_EL16=m CONFIG_EL3=m CONFIG_3C515=m CONFIG_VORTEX=m CONFIG_TYPHOON=m CONFIG_LANCE=m CONFIG_NET_VENDOR_SMC=y CONFIG_WD80x3=m CONFIG_ULTRA=m CONFIG_SMC9194=m CONFIG_NET_VENDOR_RACAL=y CONFIG_NI52=m CONFIG_NI65=m # # Tulip family network device support # CONFIG_NET_TULIP=y CONFIG_DE2104X=m CONFIG_TULIP=m # CONFIG_TULIP_MWI is not set # CONFIG_TULIP_MMIO is not set # CONFIG_TULIP_NAPI is not set # CONFIG_DE4X5 is not set CONFIG_WINBOND_840=m CONFIG_DM9102=m CONFIG_AT1700=m CONFIG_DEPCA=m CONFIG_HP100=m CONFIG_NET_ISA=y CONFIG_E2100=m CONFIG_EWRK3=m CONFIG_EEXPRESS=m CONFIG_EEXPRESS_PRO=m CONFIG_HPLAN_PLUS=m CONFIG_HPLAN=m CONFIG_LP486E=m CONFIG_ETH16I=m CONFIG_NE2000=m # CONFIG_ZNET is not set # CONFIG_SEEQ8005 is not set CONFIG_NET_PCI=y CONFIG_PCNET32=m CONFIG_AMD8111_ETH=m # CONFIG_AMD8111E_NAPI is not set CONFIG_ADAPTEC_STARFIRE=m # CONFIG_ADAPTEC_STARFIRE_NAPI is not set CONFIG_AC3200=m CONFIG_APRICOT=m CONFIG_B44=m CONFIG_FORCEDETH=m CONFIG_CS89x0=m CONFIG_DGRS=m CONFIG_EEPRO100=m # CONFIG_EEPRO100_PIO is not set CONFIG_E100=m # CONFIG_E100_NAPI is not set CONFIG_FEALNX=m CONFIG_NATSEMI=m CONFIG_NE2K_PCI=m CONFIG_8139CP=m CONFIG_8139TOO=m # CONFIG_8139TOO_PIO is not set CONFIG_8139TOO_TUNE_TWISTER=y CONFIG_8139TOO_8129=y # CONFIG_8139_OLD_RX_RESET is not set CONFIG_SIS900=m CONFIG_EPIC100=m CONFIG_SUNDANCE=m # CONFIG_SUNDANCE_MMIO is not set CONFIG_TLAN=m CONFIG_VIA_RHINE=m # CONFIG_VIA_RHINE_MMIO is not set CONFIG_NET_POCKET=y CONFIG_ATP=m CONFIG_DE600=m CONFIG_DE620=m # # Ethernet (1000 Mbit) # # CONFIG_ACENIC is not set # CONFIG_DL2K is not set # CONFIG_E1000 is not set # CONFIG_NS83820 is not set # CONFIG_HAMACHI is not set # CONFIG_YELLOWFIN is not set # CONFIG_R8169 is not set # CONFIG_SK98LIN is not set CONFIG_VIA_VELOCITY=m # CONFIG_TIGON3 is not set # # Ethernet (10000 Mbit) # # CONFIG_IXGB is not set # CONFIG_S2IO is not set # # Token Ring devices # # CONFIG_TR is not set # # Wireless LAN (non-hamradio) # CONFIG_NET_RADIO=y # # Obsolete Wireless cards support (pre-802.11) # CONFIG_STRIP=m CONFIG_ARLAN=m CONFIG_WAVELAN=m # # Wireless 802.11b ISA/PCI cards support # CONFIG_AIRO=m CONFIG_HERMES=m CONFIG_PLX_HERMES=m CONFIG_TMD_HERMES=m CONFIG_PCI_HERMES=m CONFIG_ATMEL=m CONFIG_PCI_ATMEL=m # # Prism GT/Duette 802.11(a/b/g) PCI/Cardbus support # CONFIG_PRISM54=m CONFIG_NET_WIRELESS=y # # Wan interfaces # # CONFIG_WAN is not set CONFIG_FDDI=y CONFIG_DEFXX=m CONFIG_SKFP=m # CONFIG_HIPPI is not set CONFIG_PLIP=m CONFIG_PPP=m CONFIG_PPP_MULTILINK=y CONFIG_PPP_FILTER=y CONFIG_PPP_ASYNC=m CONFIG_PPP_SYNC_TTY=m CONFIG_PPP_DEFLATE=m CONFIG_PPP_BSDCOMP=m CONFIG_PPPOE=m CONFIG_SLIP=m CONFIG_SLIP_COMPRESSED=y CONFIG_SLIP_SMART=y # CONFIG_SLIP_MODE_SLIP6 is not set CONFIG_NET_FC=y CONFIG_SHAPER=m # CONFIG_NETCONSOLE is not set # # ISDN subsystem # # CONFIG_ISDN is not set # # Telephony Support # # CONFIG_PHONE is not set # # Input device support # CONFIG_INPUT=y # # Userland interfaces # CONFIG_INPUT_MOUSEDEV=y CONFIG_INPUT_MOUSEDEV_PSAUX=y CONFIG_INPUT_MOUSEDEV_SCREEN_X=1024 CONFIG_INPUT_MOUSEDEV_SCREEN_Y=768 CONFIG_INPUT_JOYDEV=m CONFIG_INPUT_TSDEV=m CONFIG_INPUT_TSDEV_SCREEN_X=240 CONFIG_INPUT_TSDEV_SCREEN_Y=320 CONFIG_INPUT_EVDEV=m # CONFIG_INPUT_EVBUG is not set # # Input I/O drivers # # CONFIG_GAMEPORT is not set CONFIG_SOUND_GAMEPORT=y CONFIG_SERIO=y CONFIG_SERIO_I8042=y CONFIG_SERIO_SERPORT=y # CONFIG_SERIO_CT82C710 is not set # CONFIG_SERIO_PARKBD is not set # CONFIG_SERIO_PCIPS2 is not set # CONFIG_SERIO_RAW is not set # # Input Device Drivers # CONFIG_INPUT_KEYBOARD=y CONFIG_KEYBOARD_ATKBD=y # CONFIG_KEYBOARD_SUNKBD is not set # CONFIG_KEYBOARD_LKKBD is not set # CONFIG_KEYBOARD_XTKBD is not set # CONFIG_KEYBOARD_NEWTON is not set CONFIG_INPUT_MOUSE=y CONFIG_MOUSE_PS2=y # CONFIG_MOUSE_SERIAL is not set # CONFIG_MOUSE_INPORT is not set # CONFIG_MOUSE_LOGIBM is not set # CONFIG_MOUSE_PC110PAD is not set # CONFIG_MOUSE_VSXXXAA is not set # CONFIG_INPUT_JOYSTICK is not set # CONFIG_INPUT_TOUCHSCREEN is not set # CONFIG_INPUT_MISC is not set # # Character devices # CONFIG_VT=y CONFIG_VT_CONSOLE=y CONFIG_HW_CONSOLE=y # CONFIG_SERIAL_NONSTANDARD is not set # # Serial drivers # CONFIG_SERIAL_8250=y CONFIG_SERIAL_8250_CONSOLE=y CONFIG_SERIAL_8250_ACPI=y CONFIG_SERIAL_8250_NR_UARTS=4 # CONFIG_SERIAL_8250_EXTENDED is not set # # Non-8250 serial port support # CONFIG_SERIAL_CORE=y CONFIG_SERIAL_CORE_CONSOLE=y CONFIG_UNIX98_PTYS=y # CONFIG_LEGACY_PTYS is not set CONFIG_PRINTER=m # CONFIG_LP_CONSOLE is not set CONFIG_PPDEV=m CONFIG_TIPAR=m # # IPMI # CONFIG_IPMI_HANDLER=m # CONFIG_IPMI_PANIC_EVENT is not set CONFIG_IPMI_DEVICE_INTERFACE=m CONFIG_IPMI_SI=m CONFIG_IPMI_WATCHDOG=m # CONFIG_IPMI_POWEROFF is not set # # Watchdog Cards # # CONFIG_WATCHDOG is not set CONFIG_HW_RANDOM=m CONFIG_NVRAM=y CONFIG_RTC=y CONFIG_DTLK=m CONFIG_R3964=m CONFIG_APPLICOM=m CONFIG_SONYPI=m # # Ftape, the floppy tape device driver # CONFIG_AGP=m CONFIG_AGP_ALI=m CONFIG_AGP_ATI=m CONFIG_AGP_AMD=m CONFIG_AGP_AMD64=m CONFIG_AGP_INTEL=m CONFIG_AGP_INTEL_MCH=m CONFIG_AGP_NVIDIA=m CONFIG_AGP_SIS=m CONFIG_AGP_SWORKS=m CONFIG_AGP_VIA=m CONFIG_AGP_EFFICEON=m CONFIG_DRM=y CONFIG_DRM_TDFX=m CONFIG_DRM_R128=m CONFIG_DRM_RADEON=m CONFIG_DRM_I810=m # CONFIG_DRM_I830 is not set # CONFIG_DRM_I915 is not set CONFIG_DRM_MGA=m CONFIG_DRM_SIS=m CONFIG_MWAVE=m CONFIG_SCx200_GPIO=m # CONFIG_RAW_DRIVER is not set # CONFIG_HPET is not set # CONFIG_HANGCHECK_TIMER is not set # # I2C support # CONFIG_I2C=m CONFIG_I2C_CHARDEV=m # # I2C Algorithms # CONFIG_I2C_ALGOBIT=m CONFIG_I2C_ALGOPCF=m # CONFIG_I2C_ALGOPCA is not set # # I2C Hardware Bus support # # CONFIG_I2C_ALI1535 is not set # CONFIG_I2C_ALI1563 is not set # CONFIG_I2C_ALI15X3 is not set # CONFIG_I2C_AMD756 is not set # CONFIG_I2C_AMD8111 is not set CONFIG_I2C_I801=m CONFIG_I2C_I810=m # CONFIG_I2C_ISA is not set # CONFIG_I2C_NFORCE2 is not set # CONFIG_I2C_PARPORT is not set # CONFIG_I2C_PARPORT_LIGHT is not set CONFIG_I2C_PIIX4=m CONFIG_I2C_PROSAVAGE=m # CONFIG_I2C_SAVAGE4 is not set CONFIG_SCx200_I2C=m CONFIG_SCx200_I2C_SCL=12 CONFIG_SCx200_I2C_SDA=13 CONFIG_SCx200_ACB=m CONFIG_I2C_SIS5595=m CONFIG_I2C_SIS630=m CONFIG_I2C_SIS96X=m # CONFIG_I2C_STUB is not set CONFIG_I2C_VIA=m CONFIG_I2C_VIAPRO=m # CONFIG_I2C_VOODOO3 is not set # CONFIG_I2C_PCA_ISA is not set # # Hardware Sensors Chip support # # CONFIG_I2C_SENSOR is not set # CONFIG_SENSORS_ADM1021 is not set # CONFIG_SENSORS_ADM1025 is not set # CONFIG_SENSORS_ADM1026 is not set # CONFIG_SENSORS_ADM1031 is not set # CONFIG_SENSORS_ASB100 is not set # CONFIG_SENSORS_DS1621 is not set # CONFIG_SENSORS_FSCHER is not set # CONFIG_SENSORS_GL518SM is not set # CONFIG_SENSORS_IT87 is not set # CONFIG_SENSORS_LM63 is not set # CONFIG_SENSORS_LM75 is not set # CONFIG_SENSORS_LM77 is not set # CONFIG_SENSORS_LM78 is not set # CONFIG_SENSORS_LM80 is not set # CONFIG_SENSORS_LM83 is not set # CONFIG_SENSORS_LM85 is not set # CONFIG_SENSORS_LM87 is not set # CONFIG_SENSORS_LM90 is not set # CONFIG_SENSORS_MAX1619 is not set # CONFIG_SENSORS_PC87360 is not set # CONFIG_SENSORS_SMSC47M1 is not set # CONFIG_SENSORS_VIA686A is not set # CONFIG_SENSORS_W83781D is not set # CONFIG_SENSORS_W83L785TS is not set # CONFIG_SENSORS_W83627HF is not set # # Other I2C Chip support # # CONFIG_SENSORS_EEPROM is not set # CONFIG_SENSORS_PCF8574 is not set # CONFIG_SENSORS_PCF8591 is not set # CONFIG_SENSORS_RTC8564 is not set # CONFIG_I2C_DEBUG_CORE is not set # CONFIG_I2C_DEBUG_ALGO is not set # CONFIG_I2C_DEBUG_BUS is not set # CONFIG_I2C_DEBUG_CHIP is not set # # Dallas's 1-wire bus # CONFIG_W1=m CONFIG_W1_MATROX=m # CONFIG_W1_DS9490 is not set CONFIG_W1_THERM=m # CONFIG_W1_SMEM is not set # # Misc devices # # CONFIG_IBM_ASM is not set # # Multimedia devices # CONFIG_VIDEO_DEV=m # # Video For Linux # # # Video Adapters # CONFIG_VIDEO_BT848=m CONFIG_VIDEO_PMS=m CONFIG_VIDEO_BWQCAM=m CONFIG_VIDEO_CQCAM=m CONFIG_VIDEO_W9966=m CONFIG_VIDEO_CPIA=m CONFIG_VIDEO_CPIA_PP=m CONFIG_VIDEO_CPIA_USB=m # CONFIG_VIDEO_SAA5246A is not set CONFIG_VIDEO_SAA5249=m CONFIG_TUNER_3036=m CONFIG_VIDEO_STRADIS=m CONFIG_VIDEO_ZORAN=m CONFIG_VIDEO_ZORAN_BUZ=m CONFIG_VIDEO_ZORAN_DC10=m # CONFIG_VIDEO_ZORAN_DC30 is not set CONFIG_VIDEO_ZORAN_LML33=m # CONFIG_VIDEO_ZORAN_LML33R10 is not set CONFIG_VIDEO_MEYE=m # CONFIG_VIDEO_SAA7134 is not set # CONFIG_VIDEO_MXB is not set # CONFIG_VIDEO_DPC is not set # CONFIG_VIDEO_HEXIUM_ORION is not set # CONFIG_VIDEO_HEXIUM_GEMINI is not set # CONFIG_VIDEO_CX88 is not set # CONFIG_VIDEO_OVCAMCHIP is not set # # Radio Adapters # CONFIG_RADIO_CADET=m CONFIG_RADIO_RTRACK=m CONFIG_RADIO_RTRACK2=m CONFIG_RADIO_AZTECH=m CONFIG_RADIO_GEMTEK=m CONFIG_RADIO_GEMTEK_PCI=m CONFIG_RADIO_MAXIRADIO=m CONFIG_RADIO_MAESTRO=m CONFIG_RADIO_SF16FMI=m CONFIG_RADIO_SF16FMR2=m CONFIG_RADIO_TERRATEC=m CONFIG_RADIO_TRUST=m CONFIG_RADIO_TYPHOON=m CONFIG_RADIO_TYPHOON_PROC_FS=y CONFIG_RADIO_ZOLTRIX=m # # Digital Video Broadcasting Devices # # CONFIG_DVB is not set CONFIG_VIDEO_TUNER=m CONFIG_VIDEO_BUF=m CONFIG_VIDEO_BTCX=m CONFIG_VIDEO_IR=m # # Graphics support # # CONFIG_FB is not set # CONFIG_VIDEO_SELECT is not set # # Console display driver support # CONFIG_VGA_CONSOLE=y # CONFIG_MDA_CONSOLE is not set CONFIG_DUMMY_CONSOLE=y # # Sound # CONFIG_SOUND=m # # Advanced Linux Sound Architecture # CONFIG_SND=m CONFIG_SND_TIMER=m CONFIG_SND_PCM=m CONFIG_SND_HWDEP=m CONFIG_SND_RAWMIDI=m CONFIG_SND_SEQUENCER=m # CONFIG_SND_SEQ_DUMMY is not set CONFIG_SND_OSSEMUL=y CONFIG_SND_MIXER_OSS=m CONFIG_SND_PCM_OSS=m CONFIG_SND_SEQUENCER_OSS=y CONFIG_SND_RTCTIMER=m # CONFIG_SND_VERBOSE_PRINTK is not set # CONFIG_SND_DEBUG is not set # # Generic devices # CONFIG_SND_MPU401_UART=m CONFIG_SND_OPL3_LIB=m CONFIG_SND_VX_LIB=m # CONFIG_SND_DUMMY is not set # CONFIG_SND_VIRMIDI is not set # CONFIG_SND_MTPAV is not set # CONFIG_SND_SERIAL_U16550 is not set # CONFIG_SND_MPU401 is not set # # ISA devices # # CONFIG_SND_AD1848 is not set # CONFIG_SND_CS4231 is not set # CONFIG_SND_CS4232 is not set # CONFIG_SND_CS4236 is not set # CONFIG_SND_ES1688 is not set # CONFIG_SND_ES18XX is not set # CONFIG_SND_GUSCLASSIC is not set # CONFIG_SND_GUSEXTREME is not set # CONFIG_SND_GUSMAX is not set # CONFIG_SND_INTERWAVE is not set # CONFIG_SND_INTERWAVE_STB is not set # CONFIG_SND_OPTI92X_AD1848 is not set # CONFIG_SND_OPTI92X_CS4231 is not set # CONFIG_SND_OPTI93X is not set # CONFIG_SND_SB8 is not set # CONFIG_SND_SB16 is not set # CONFIG_SND_SBAWE is not set # CONFIG_SND_WAVEFRONT is not set # CONFIG_SND_CMI8330 is not set # CONFIG_SND_OPL3SA2 is not set # CONFIG_SND_SGALAXY is not set # CONFIG_SND_SSCAPE is not set # # PCI devices # CONFIG_SND_AC97_CODEC=m CONFIG_SND_ALI5451=m CONFIG_SND_ATIIXP=m # CONFIG_SND_ATIIXP_MODEM is not set CONFIG_SND_AU8810=m CONFIG_SND_AU8820=m CONFIG_SND_AU8830=m CONFIG_SND_AZT3328=m CONFIG_SND_BT87X=m # CONFIG_SND_BT87X_OVERCLOCK is not set CONFIG_SND_CS46XX=m CONFIG_SND_CS46XX_NEW_DSP=y CONFIG_SND_CS4281=m CONFIG_SND_EMU10K1=m CONFIG_SND_KORG1212=m CONFIG_SND_MIXART=m CONFIG_SND_NM256=m CONFIG_SND_RME32=m CONFIG_SND_RME96=m CONFIG_SND_RME9652=m CONFIG_SND_HDSP=m CONFIG_SND_TRIDENT=m CONFIG_SND_YMFPCI=m CONFIG_SND_ALS4000=m CONFIG_SND_CMIPCI=m CONFIG_SND_ENS1370=m CONFIG_SND_ENS1371=m CONFIG_SND_ES1938=m CONFIG_SND_ES1968=m CONFIG_SND_MAESTRO3=m CONFIG_SND_FM801=m # CONFIG_SND_FM801_TEA575X is not set CONFIG_SND_ICE1712=m CONFIG_SND_ICE1724=m CONFIG_SND_INTEL8X0=m CONFIG_SND_INTEL8X0M=m CONFIG_SND_SONICVIBES=m CONFIG_SND_VIA82XX=m CONFIG_SND_VX222=m # # USB devices # CONFIG_SND_USB_AUDIO=m # CONFIG_SND_USB_USX2Y is not set # # Open Sound System # # CONFIG_SOUND_PRIME is not set # # USB support # CONFIG_USB=m # CONFIG_USB_DEBUG is not set # # Miscellaneous USB options # CONFIG_USB_DEVICEFS=y # CONFIG_USB_BANDWIDTH is not set # CONFIG_USB_DYNAMIC_MINORS is not set # CONFIG_USB_SUSPEND is not set # CONFIG_USB_OTG is not set CONFIG_USB_ARCH_HAS_HCD=y CONFIG_USB_ARCH_HAS_OHCI=y # # USB Host Controller Drivers # CONFIG_USB_EHCI_HCD=m # CONFIG_USB_EHCI_SPLIT_ISO is not set # CONFIG_USB_EHCI_ROOT_HUB_TT is not set CONFIG_USB_OHCI_HCD=m CONFIG_USB_UHCI_HCD=m # CONFIG_USB_SL811_HCD is not set # # USB Device Class drivers # CONFIG_USB_AUDIO=m # # USB Bluetooth TTY can only be used with disabled Bluetooth subsystem # CONFIG_USB_MIDI=m CONFIG_USB_ACM=m CONFIG_USB_PRINTER=m # # NOTE: USB_STORAGE enables SCSI, and 'SCSI disk support' may also be needed; see USB_STORAGE Help for more information # CONFIG_USB_STORAGE=m # CONFIG_USB_STORAGE_DEBUG is not set # CONFIG_USB_STORAGE_RW_DETECT is not set CONFIG_USB_STORAGE_DATAFAB=y CONFIG_USB_STORAGE_FREECOM=y CONFIG_USB_STORAGE_ISD200=y CONFIG_USB_STORAGE_DPCM=y CONFIG_USB_STORAGE_HP8200e=y CONFIG_USB_STORAGE_SDDR09=y CONFIG_USB_STORAGE_SDDR55=y CONFIG_USB_STORAGE_JUMPSHOT=y # # USB Input Devices # CONFIG_USB_HID=m CONFIG_USB_HIDINPUT=y # CONFIG_HID_FF is not set CONFIG_USB_HIDDEV=y # # USB HID Boot Protocol drivers # CONFIG_USB_KBD=m CONFIG_USB_MOUSE=m CONFIG_USB_AIPTEK=m CONFIG_USB_WACOM=m CONFIG_USB_KBTAB=m CONFIG_USB_POWERMATE=m CONFIG_USB_MTOUCH=m CONFIG_USB_EGALAX=m CONFIG_USB_XPAD=m CONFIG_USB_ATI_REMOTE=m # # USB Imaging devices # CONFIG_USB_MDC800=m CONFIG_USB_MICROTEK=m CONFIG_USB_HPUSBSCSI=m # # USB Multimedia devices # CONFIG_USB_DABUSB=m CONFIG_USB_VICAM=m CONFIG_USB_DSBR=m CONFIG_USB_IBMCAM=m CONFIG_USB_KONICAWC=m CONFIG_USB_OV511=m CONFIG_USB_SE401=m CONFIG_USB_SN9C102=m CONFIG_USB_STV680=m # # USB Network Adapters # CONFIG_USB_CATC=m CONFIG_USB_KAWETH=m CONFIG_USB_PEGASUS=m CONFIG_USB_RTL8150=m CONFIG_USB_USBNET=m # # USB Host-to-Host Cables # CONFIG_USB_ALI_M5632=y CONFIG_USB_AN2720=y CONFIG_USB_BELKIN=y CONFIG_USB_GENESYS=y CONFIG_USB_NET1080=y CONFIG_USB_PL2301=y CONFIG_USB_KC2190=y # # Intelligent USB Devices/Gadgets # CONFIG_USB_ARMLINUX=y CONFIG_USB_EPSON2888=y CONFIG_USB_ZAURUS=y CONFIG_USB_CDCETHER=y # # USB Network Adapters # CONFIG_USB_AX8817X=y # # USB port drivers # CONFIG_USB_USS720=m # # USB Serial Converter support # CONFIG_USB_SERIAL=m CONFIG_USB_SERIAL_GENERIC=y CONFIG_USB_SERIAL_BELKIN=m CONFIG_USB_SERIAL_DIGI_ACCELEPORT=m # CONFIG_USB_SERIAL_CYPRESS_M8 is not set CONFIG_USB_SERIAL_EMPEG=m CONFIG_USB_SERIAL_FTDI_SIO=m CONFIG_USB_SERIAL_VISOR=m CONFIG_USB_SERIAL_IPAQ=m CONFIG_USB_SERIAL_IR=m CONFIG_USB_SERIAL_EDGEPORT=m CONFIG_USB_SERIAL_EDGEPORT_TI=m # CONFIG_USB_SERIAL_IPW is not set CONFIG_USB_SERIAL_KEYSPAN_PDA=m CONFIG_USB_SERIAL_KEYSPAN=m CONFIG_USB_SERIAL_KEYSPAN_MPR=y CONFIG_USB_SERIAL_KEYSPAN_USA28=y CONFIG_USB_SERIAL_KEYSPAN_USA28X=y CONFIG_USB_SERIAL_KEYSPAN_USA28XA=y CONFIG_USB_SERIAL_KEYSPAN_USA28XB=y CONFIG_USB_SERIAL_KEYSPAN_USA19=y CONFIG_USB_SERIAL_KEYSPAN_USA18X=y CONFIG_USB_SERIAL_KEYSPAN_USA19W=y CONFIG_USB_SERIAL_KEYSPAN_USA19QW=y CONFIG_USB_SERIAL_KEYSPAN_USA19QI=y CONFIG_USB_SERIAL_KEYSPAN_USA49W=y CONFIG_USB_SERIAL_KEYSPAN_USA49WLC=y CONFIG_USB_SERIAL_KLSI=m CONFIG_USB_SERIAL_KOBIL_SCT=m CONFIG_USB_SERIAL_MCT_U232=m CONFIG_USB_SERIAL_PL2303=m # CONFIG_USB_SERIAL_SAFE is not set CONFIG_USB_SERIAL_CYBERJACK=m CONFIG_USB_SERIAL_XIRCOM=m CONFIG_USB_SERIAL_OMNINET=m CONFIG_USB_EZUSB=y # # USB Miscellaneous drivers # CONFIG_USB_EMI62=m CONFIG_USB_EMI26=m CONFIG_USB_TIGL=m CONFIG_USB_AUERSWALD=m CONFIG_USB_RIO500=m CONFIG_USB_LEGOTOWER=m CONFIG_USB_LCD=m CONFIG_USB_LED=m CONFIG_USB_CYTHERM=m # CONFIG_USB_PHIDGETKIT is not set CONFIG_USB_PHIDGETSERVO=m CONFIG_USB_TEST=m # # USB ATM/DSL drivers # # # USB Gadget Support # CONFIG_USB_GADGET=m # CONFIG_USB_GADGET_DEBUG_FILES is not set CONFIG_USB_GADGET_NET2280=y CONFIG_USB_NET2280=m # CONFIG_USB_GADGET_PXA2XX is not set # CONFIG_USB_GADGET_GOKU is not set # CONFIG_USB_GADGET_SA1100 is not set # CONFIG_USB_GADGET_LH7A40X is not set # CONFIG_USB_GADGET_DUMMY_HCD is not set # CONFIG_USB_GADGET_OMAP is not set CONFIG_USB_GADGET_DUALSPEED=y CONFIG_USB_ZERO=m CONFIG_USB_ETH=m CONFIG_USB_ETH_RNDIS=y CONFIG_USB_GADGETFS=m CONFIG_USB_FILE_STORAGE=m CONFIG_USB_FILE_STORAGE_TEST=y CONFIG_USB_G_SERIAL=m # # MMC/SD Card support # # CONFIG_MMC is not set # # File systems # CONFIG_EXT2_FS=y # CONFIG_EXT2_FS_XATTR is not set CONFIG_EXT3_FS=y CONFIG_EXT3_FS_XATTR=y # CONFIG_EXT3_FS_POSIX_ACL is not set # CONFIG_EXT3_FS_SECURITY is not set CONFIG_JBD=y # CONFIG_JBD_DEBUG is not set CONFIG_FS_MBCACHE=y CONFIG_REISERFS_FS=y # CONFIG_REISERFS_CHECK is not set # CONFIG_REISERFS_PROC_INFO is not set # CONFIG_REISERFS_FS_XATTR is not set CONFIG_JFS_FS=y # CONFIG_JFS_POSIX_ACL is not set # CONFIG_JFS_DEBUG is not set # CONFIG_JFS_STATISTICS is not set CONFIG_FS_POSIX_ACL=y CONFIG_XFS_FS=y # CONFIG_XFS_RT is not set CONFIG_XFS_QUOTA=y # CONFIG_XFS_SECURITY is not set # CONFIG_XFS_POSIX_ACL is not set CONFIG_MINIX_FS=m CONFIG_ROMFS_FS=m CONFIG_QUOTA=y # CONFIG_QFMT_V1 is not set CONFIG_QFMT_V2=m CONFIG_QUOTACTL=y CONFIG_DNOTIFY=y CONFIG_AUTOFS_FS=m CONFIG_AUTOFS4_FS=m # # CD-ROM/DVD Filesystems # CONFIG_ISO9660_FS=m CONFIG_JOLIET=y CONFIG_ZISOFS=y CONFIG_ZISOFS_FS=m CONFIG_UDF_FS=m CONFIG_UDF_NLS=y # # DOS/FAT/NT Filesystems # CONFIG_FAT_FS=m CONFIG_MSDOS_FS=m CONFIG_VFAT_FS=m CONFIG_FAT_DEFAULT_CODEPAGE=437 CONFIG_FAT_DEFAULT_IOCHARSET="iso8859-1" CONFIG_NTFS_FS=m # CONFIG_NTFS_DEBUG is not set CONFIG_NTFS_RW=y # # Pseudo filesystems # CONFIG_PROC_FS=y CONFIG_PROC_KCORE=y CONFIG_SYSFS=y # CONFIG_DEVFS_FS is not set # CONFIG_DEVPTS_FS_XATTR is not set CONFIG_TMPFS=y # CONFIG_TMPFS_XATTR is not set # CONFIG_HUGETLBFS is not set # CONFIG_HUGETLB_PAGE is not set CONFIG_RAMFS=y # # Miscellaneous filesystems # # CONFIG_ADFS_FS is not set # CONFIG_AFFS_FS is not set # CONFIG_HFS_FS is not set # CONFIG_HFSPLUS_FS is not set # CONFIG_BEFS_FS is not set # CONFIG_BFS_FS is not set # CONFIG_EFS_FS is not set CONFIG_CRAMFS=m # CONFIG_VXFS_FS is not set # CONFIG_HPFS_FS is not set # CONFIG_QNX4FS_FS is not set # CONFIG_SYSV_FS is not set CONFIG_UFS_FS=m CONFIG_UFS_FS_WRITE=y # # Network File Systems # CONFIG_NFS_FS=y CONFIG_NFS_V3=y CONFIG_NFS_V4=y # CONFIG_NFS_DIRECTIO is not set CONFIG_NFSD=m CONFIG_NFSD_V3=y CONFIG_NFSD_V4=y CONFIG_NFSD_TCP=y CONFIG_LOCKD=y CONFIG_LOCKD_V4=y CONFIG_EXPORTFS=m CONFIG_SUNRPC=y CONFIG_SUNRPC_GSS=y CONFIG_RPCSEC_GSS_KRB5=y # CONFIG_RPCSEC_GSS_SPKM3 is not set CONFIG_SMB_FS=m # CONFIG_SMB_NLS_DEFAULT is not set CONFIG_CIFS=m CONFIG_CIFS_STATS=y CONFIG_CIFS_XATTR=y CONFIG_CIFS_POSIX=y # CONFIG_CIFS_EXPERIMENTAL is not set # CONFIG_NCP_FS is not set CONFIG_CODA_FS=m # CONFIG_CODA_FS_OLD_API is not set CONFIG_AFS_FS=m CONFIG_RXRPC=m # # Partition Types # CONFIG_PARTITION_ADVANCED=y # CONFIG_ACORN_PARTITION is not set # CONFIG_OSF_PARTITION is not set # CONFIG_AMIGA_PARTITION is not set # CONFIG_ATARI_PARTITION is not set CONFIG_MAC_PARTITION=y CONFIG_MSDOS_PARTITION=y CONFIG_BSD_DISKLABEL=y # CONFIG_MINIX_SUBPARTITION is not set # CONFIG_SOLARIS_X86_PARTITION is not set # CONFIG_UNIXWARE_DISKLABEL is not set # CONFIG_LDM_PARTITION is not set # CONFIG_SGI_PARTITION is not set # CONFIG_ULTRIX_PARTITION is not set # CONFIG_SUN_PARTITION is not set # CONFIG_EFI_PARTITION is not set # # Native Language Support # CONFIG_NLS=y CONFIG_NLS_DEFAULT="cp437" CONFIG_NLS_CODEPAGE_437=y CONFIG_NLS_CODEPAGE_737=m CONFIG_NLS_CODEPAGE_775=m CONFIG_NLS_CODEPAGE_850=m CONFIG_NLS_CODEPAGE_852=m CONFIG_NLS_CODEPAGE_855=m CONFIG_NLS_CODEPAGE_857=m CONFIG_NLS_CODEPAGE_860=m CONFIG_NLS_CODEPAGE_861=m CONFIG_NLS_CODEPAGE_862=m CONFIG_NLS_CODEPAGE_863=m CONFIG_NLS_CODEPAGE_864=m CONFIG_NLS_CODEPAGE_865=m CONFIG_NLS_CODEPAGE_866=m CONFIG_NLS_CODEPAGE_869=m CONFIG_NLS_CODEPAGE_936=m CONFIG_NLS_CODEPAGE_950=m CONFIG_NLS_CODEPAGE_932=m CONFIG_NLS_CODEPAGE_949=m CONFIG_NLS_CODEPAGE_874=m CONFIG_NLS_ISO8859_8=m CONFIG_NLS_CODEPAGE_1250=m CONFIG_NLS_CODEPAGE_1251=m # CONFIG_NLS_ASCII is not set CONFIG_NLS_ISO8859_1=y CONFIG_NLS_ISO8859_2=m CONFIG_NLS_ISO8859_3=m CONFIG_NLS_ISO8859_4=m CONFIG_NLS_ISO8859_5=m CONFIG_NLS_ISO8859_6=m CONFIG_NLS_ISO8859_7=m CONFIG_NLS_ISO8859_9=m CONFIG_NLS_ISO8859_13=m CONFIG_NLS_ISO8859_14=m CONFIG_NLS_ISO8859_15=m CONFIG_NLS_KOI8_R=m CONFIG_NLS_KOI8_U=m CONFIG_NLS_UTF8=m # # Profiling support # # CONFIG_PROFILING is not set # # Kernel hacking # CONFIG_DEBUG_KERNEL=y CONFIG_MAGIC_SYSRQ=y # CONFIG_SCHEDSTATS is not set # CONFIG_DEBUG_SLAB is not set # CONFIG_DEBUG_SPINLOCK is not set # CONFIG_DEBUG_SPINLOCK_SLEEP is not set # CONFIG_DEBUG_KOBJECT is not set # CONFIG_DEBUG_INFO is not set # CONFIG_FRAME_POINTER is not set CONFIG_EARLY_PRINTK=y # CONFIG_DEBUG_STACKOVERFLOW is not set # CONFIG_KPROBES is not set # CONFIG_DEBUG_STACK_USAGE is not set # CONFIG_DEBUG_PAGEALLOC is not set # CONFIG_4KSTACKS is not set CONFIG_X86_FIND_SMP_CONFIG=y CONFIG_X86_MPPARSE=y # # Security options # # CONFIG_KEYS is not set # CONFIG_SECURITY is not set # # Cryptographic options # CONFIG_CRYPTO=y CONFIG_CRYPTO_HMAC=y CONFIG_CRYPTO_NULL=m CONFIG_CRYPTO_MD4=m CONFIG_CRYPTO_MD5=y CONFIG_CRYPTO_SHA1=m CONFIG_CRYPTO_SHA256=m CONFIG_CRYPTO_SHA512=m # CONFIG_CRYPTO_WP512 is not set CONFIG_CRYPTO_DES=y CONFIG_CRYPTO_BLOWFISH=m CONFIG_CRYPTO_TWOFISH=m CONFIG_CRYPTO_SERPENT=m CONFIG_CRYPTO_AES_586=m CONFIG_CRYPTO_CAST5=m CONFIG_CRYPTO_CAST6=m # CONFIG_CRYPTO_TEA is not set CONFIG_CRYPTO_ARC4=m # CONFIG_CRYPTO_KHAZAD is not set # CONFIG_CRYPTO_ANUBIS is not set CONFIG_CRYPTO_DEFLATE=m # CONFIG_CRYPTO_MICHAEL_MIC is not set # CONFIG_CRYPTO_CRC32C is not set CONFIG_CRYPTO_TEST=m # # Library routines # CONFIG_CRC_CCITT=m CONFIG_CRC32=m # CONFIG_LIBCRC32C is not set CONFIG_ZLIB_INFLATE=m CONFIG_ZLIB_DEFLATE=m CONFIG_GENERIC_HARDIRQS=y CONFIG_GENERIC_IRQ_PROBE=y CONFIG_X86_SMP=y CONFIG_X86_HT=y CONFIG_X86_BIOS_REBOOT=y CONFIG_X86_TRAMPOLINE=y CONFIG_PC=y --Boundary-00=_rxLJCJzqPO0Jvjl Content-Type: text/plain; charset="us-ascii"; name="iplink.txt" Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="iplink.txt" 1: lo: mtu 16436 qdisc noqueue link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00 2: eth0: mtu 1500 qdisc prio qlen 10 link/ether 00:90:27:1c:e0:08 brd ff:ff:ff:ff:ff:ff 3: wp1adsl: mtu 1500 qdisc htb qlen 10 link/ether 00:77:77:77:7a:d7 brd ff:ff:ff:ff:ff:ff --Boundary-00=_rxLJCJzqPO0Jvjl Content-Type: text/plain; charset="us-ascii"; name="lsmod.txt" Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="lsmod.txt" # lsmod Module Size Used by ipt_mark 1344 1 ipt_MARK 1664 1 ohci_hcd 18664 0 ehci_hcd 26148 0 via_agp 7200 1 ipt_connmark 1376 0 ipt_CONNMARK 1856 2 ipt_ipp2p 7968 1 sch_prio 4160 1 sch_ingress 2752 1 cls_fw 4160 2 cls_u32 7108 32 sch_sfq 4672 9 sch_htb 22784 1 iptable_mangle 2112 1 iptable_filter 2912 0 ip_tables 16256 7 ipt_mark,ipt_MARK,ipt_connmark,ipt_CONNMARK,ipt_ipp2p,iptable_mangle,iptable_filter parport_pc 37220 0 parport 30760 1 parport_pc wanpipe_lip 92820 0 af_wanpipe 33024 0 wanpipe 761724 0 wanpipe_syncppp 25868 1 wanpipe wanrouter 30364 4 wanpipe_lip,af_wanpipe,wanpipe,wanpipe_syncppp uhci_hcd 29424 0 sdladrv 45084 2 wanpipe,wanrouter usbcore 101688 4 ohci_hcd,ehci_hcd,uhci_hcd i2c_viapro 6220 0 i2c_core 17920 1 i2c_viapro eepro100 26028 0 evdev 6912 0 ide_scsi 13284 0 agpgart 27340 1 via_agp --Boundary-00=_rxLJCJzqPO0Jvjl Content-Type: text/plain; charset="us-ascii"; name="lspci.txt" Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="lspci.txt" # lspci -v 00:00.0 Host bridge: VIA Technologies, Inc. VT82C693A/694x [Apollo PRO133x] (rev c4) Flags: bus master, medium devsel, latency 0 Memory at d0000000 (32-bit, prefetchable) [size=64M] Capabilities: [a0] AGP version 2.0 Capabilities: [c0] Power Management version 2 00:01.0 PCI bridge: VIA Technologies, Inc. VT82C598/694x [Apollo MVP3/Pro133x AGP] (prog-if 00 [Normal decode]) Flags: bus master, 66Mhz, medium devsel, latency 0 Bus: primary=00, secondary=01, subordinate=01, sec-latency=0 Capabilities: [80] Power Management version 2 00:07.0 ISA bridge: VIA Technologies, Inc. VT82C686 [Apollo Super South] (rev 22) Subsystem: VIA Technologies, Inc. VT82C686/A PCI to ISA Bridge Flags: bus master, stepping, medium devsel, latency 0 00:07.1 IDE interface: VIA Technologies, Inc. VT82C586A/B/VT82C686/A/B/VT823x/A/C/VT8235 PIPC Bus Master IDE (rev 10) (prog-if 8a [Master SecP PriP]) Flags: bus master, medium devsel, latency 32 I/O ports at e000 [size=16] Capabilities: [c0] Power Management version 2 00:07.2 USB Controller: VIA Technologies, Inc. VT6202 [USB 2.0 controller] (rev 10) (prog-if 00 [UHCI]) Subsystem: VIA Technologies, Inc. (Wrong ID) USB Controller Flags: bus master, medium devsel, latency 32, IRQ 7 I/O ports at e400 [size=32] Capabilities: [80] Power Management version 2 00:07.4 Host bridge: VIA Technologies, Inc. VT82C686 [Apollo Super ACPI] (rev 30) Subsystem: VIA Technologies, Inc. VT82C686 [Apollo Super ACPI] Flags: medium devsel, IRQ 11 Capabilities: [68] Power Management version 2 00:08.0 Ethernet controller: Intel Corp. 82557/8/9 [Ethernet Pro 100] (rev 05) Subsystem: Intel Corp. EtherExpress PRO/100+ Flags: bus master, medium devsel, latency 128, IRQ 11 Memory at d8110000 (32-bit, prefetchable) [size=4K] I/O ports at ec00 [size=32] Memory at d8000000 (32-bit, non-prefetchable) [size=1M] Expansion ROM at [disabled] [size=1M] Capabilities: [dc] Power Management version 1 00:09.0 Network controller: Globespan Semiconductor Inc.: Unknown device d002 (rev 01) Subsystem: Globespan Semiconductor Inc.: Unknown device 0018 Flags: bus master, stepping, slow devsel, latency 128, IRQ 10 Memory at d8100000 (32-bit, non-prefetchable) [size=64K] Capabilities: [40] Power Management version 2 00:0b.0 VGA compatible controller: Matrox Graphics, Inc. MGA 2164W [Millennium II] (prog-if 00 [VGA]) Subsystem: Matrox Graphics, Inc.: Unknown device 1300 Flags: bus master, medium devsel, latency 32, IRQ 255 Memory at d5000000 (32-bit, prefetchable) [size=16M] Memory at d6000000 (32-bit, non-prefetchable) [size=16K] Memory at d7000000 (32-bit, non-prefetchable) [size=8M] Expansion ROM at [disabled] [size=64K] --Boundary-00=_rxLJCJzqPO0Jvjl Content-Type: application/x-shellscript; name="rc.tc" Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="rc.tc" #!/bin/bash DSLDEV=wp1adsl LANDEV=eth0 UPRATE=800 DOWNRATE=3800 if [ "$1" = "upstatus" ] then tc -s qdisc ls dev $DSLDEV echo tc -s class ls dev $DSLDEV exit fi if [ "$1" = "downstatus" ] then tc -s qdisc ls dev $LANDEV echo tc -s class ls dev $LANDEV exit fi # clean existing down- and uplink qdiscs, hide errors tc qdisc del dev $DSLDEV root 2> /dev/null > /dev/null tc qdisc del dev $DSLDEV ingress 2> /dev/null > /dev/null tc qdisc del dev $LANDEV root 2> /dev/null > /dev/null tc qdisc del dev $LANDEV ingress 2> /dev/null > /dev/null iptables -t mangle -D FORWARD -j CONNMARK --restore-mark &> /dev/null iptables -t mangle -D FORWARD -m mark ! --mark 0 -j ACCEPT &> /dev/null iptables -t mangle -D FORWARD -m ipp2p --tcp --udp --edk --dc --kazaa --gnu --bit --apple --winmx --soul -j MARK --set-mark 1 &> /dev/null iptables -t mangle -D FORWARD -j CONNMARK --save-mark &> /dev/null if [ "$1" = "stop" ] then exit fi # *** UPSTREAM (SENDING) CONFIG *** CEIL=$[100*$UPRATE/100] MISCRATE=$[90*$CEIL/100] # set packet queue much smaller than default (100): ip link set dev $DSLDEV qlen 10 # install root HTB, point default traffic to 1:30: tc qdisc add dev $DSLDEV root handle 1: htb r2q 1 default 30 # shape everything at $CEIL speed - this prevents huge queues in the DSL modem which destroy latency: tc class add dev $DSLDEV parent 1: classid 1:1 htb rate ${CEIL}kbit # 1:10 - ICMP ECHO, TCP ACK, interactive traffic # 1:20 - web traffic # 1:30 - default (bulk) traffic # 1:40 - mail # 1:50 - lowest priority traffic tc class add dev $DSLDEV parent 1:1 classid 1:10 htb rate 64kbit ceil ${MISCRATE}kbit prio 1 tc class add dev $DSLDEV parent 1:1 classid 1:20 htb rate 256kbit ceil ${MISCRATE}kbit prio 2 tc class add dev $DSLDEV parent 1:1 classid 1:30 htb rate 256kbit ceil ${MISCRATE}kbit prio 3 tc class add dev $DSLDEV parent 1:1 classid 1:40 htb rate 64kbit ceil ${MISCRATE}kbit prio 4 tc class add dev $DSLDEV parent 1:1 classid 1:50 htb rate 64kbit ceil ${MISCRATE}kbit prio 5 # VOIP gets FIFO with a (very) short queue, the rest get Stochastic Fairness: tc qdisc add dev $DSLDEV parent 1:10 handle 10: sfq perturb 10 tc qdisc add dev $DSLDEV parent 1:20 handle 20: sfq perturb 10 tc qdisc add dev $DSLDEV parent 1:30 handle 30: sfq perturb 10 tc qdisc add dev $DSLDEV parent 1:40 handle 40: sfq perturb 10 tc qdisc add dev $DSLDEV parent 1:50 handle 50: sfq perturb 10 # VOIP traffic in 1:0 (i.e. skip the HTB entirely and drop it directly into the interface queue) # TOS min delay, ICMP, DNS and TCP ACKs in 1:10 # web traffic (HTTP, HTTPS, 8080, etc.) in 1:20 # bulk traffic is already thrown in to 1:30 by "default" in root qdisc # all SMTP and P2P traffic and anything to/from Rosu's or Bakelaar's IPs go into 1:40 tc filter add dev $DSLDEV parent 1:0 protocol ip prio 1 u32 match ip dport 4569 0xffff match ip protocol 17 0xff flowid 1:0 tc filter add dev $DSLDEV parent 1:0 protocol ip prio 2 u32 match ip sport 4569 0xffff match ip protocol 17 0xff flowid 1:0 tc filter add dev $DSLDEV parent 1:0 protocol ip prio 3 u32 match ip dst 66.225.202.72 flowid 1:0 tc filter add dev $DSLDEV parent 1:0 protocol ip prio 9 u32 match ip src 165.154.13.120 flowid 1:10 tc filter add dev $DSLDEV parent 1:0 protocol ip prio 10 u32 match ip tos 0x10 0xff flowid 1:10 tc filter add dev $DSLDEV parent 1:0 protocol ip prio 11 u32 match ip protocol 1 0xff flowid 1:10 tc filter add dev $DSLDEV parent 1:0 protocol ip prio 12 u32 match ip protocol 47 0xff flowid 1:10 tc filter add dev $DSLDEV parent 1:0 protocol ip prio 13 u32 match ip protocol 50 0xff flowid 1:10 tc filter add dev $DSLDEV parent 1:0 protocol ip prio 14 u32 match ip sport 53 0xffff flowid 1:10 tc filter add dev $DSLDEV parent 1:0 protocol ip prio 15 u32 match ip dport 53 0xffff flowid 1:10 tc filter add dev $DSLDEV parent 1:0 protocol ip prio 16 u32 \ match ip protocol 6 0xff \ match u8 0x05 0x0f at 0 \ match u16 0x0000 0xffc0 at 2 \ match u8 0x10 0xff at 33 \ flowid 1:10 tc filter add dev $DSLDEV parent 1:0 protocol ip prio 20 u32 match ip sport 80 0xfff flowid 1:20 tc filter add dev $DSLDEV parent 1:0 protocol ip prio 21 u32 match ip sport 443 0xfff flowid 1:20 tc filter add dev $DSLDEV parent 1:0 protocol ip prio 22 u32 match ip dport 80 0xfff flowid 1:20 tc filter add dev $DSLDEV parent 1:0 protocol ip prio 23 u32 match ip dport 443 0xfff flowid 1:20 # low-priority src/dest ports tc filter add dev $DSLDEV parent 1:0 protocol ip prio 40 u32 match ip dport 25 0xffff flowid 1:40 tc filter add dev $DSLDEV parent 1:0 protocol ip prio 41 u32 match ip sport 25 0xffff flowid 1:40 tc filter add dev $DSLDEV parent 1:0 protocol ip prio 42 u32 match ip sport 110 0xffff flowid 1:20 tc filter add dev $DSLDEV parent 1:0 protocol ip prio 43 u32 match ip sport 143 0xffff flowid 1:20 # low-priority specific src/dest *hosts* tc filter add dev $DSLDEV parent 1:0 protocol ip prio 44 u32 match ip src 165.154.13.82 flowid 1:40 tc filter add dev $DSLDEV parent 1:0 protocol ip prio 45 u32 match ip src 165.154.13.83 flowid 1:40 # any traffic that the p2p match module for iptables finds (it marks with --set-mark 1): tc filter add dev $DSLDEV parent 1:0 protocol ip prio 59 handle 1 fw flowid 1:50 # LAN ingress handler; drop any NON-VOIP traffic > rate tc qdisc add dev $DSLDEV handle ffff: ingress tc filter add dev $DSLDEV parent ffff: protocol ip prio 90 u32 match ip dport 4569 0xffff match ip protocol 17 0xff flowid :1 tc filter add dev $DSLDEV parent ffff: protocol ip prio 91 u32 match ip sport 4569 0xffff match ip protocol 17 0xff flowid :1 tc filter add dev $DSLDEV parent ffff: protocol ip prio 92 u32 match ip dst 165.154.13.120 flowid :1 tc filter add dev $DSLDEV parent ffff: protocol ip prio 99 u32 match ip dst 0.0.0.0/0 \ police rate $[80*$DOWNRATE/100]kbit burst 10k drop flowid :1 # *** DOWNSTREAM (RECEIVING) CONFIG *** # set packet queue much smaller than default (100): ip link set dev $LANDEV qlen 10 # default priomap -----------------------------------------> 1 2 1 1 2 2 2 2 0 0 0 0 1 1 1 1 tc qdisc add dev $LANDEV root handle 1: prio bands 5 priomap 2 2 2 2 2 2 2 2 1 1 1 1 2 2 2 2 # 1:1 - VOIP # 1:2 - interactive traffic # 1:3 - bulk traffic # 1:4 - low-priority traffic # 1:5 - P2P traffic tc qdisc add dev $LANDEV parent 1:1 handle 10: pfifo tc qdisc add dev $LANDEV parent 1:2 handle 20: sfq tc qdisc add dev $LANDEV parent 1:3 handle 30: sfq tc qdisc add dev $LANDEV parent 1:4 handle 40: sfq tc qdisc add dev $LANDEV parent 1:5 handle 50: sfq tc filter add dev $LANDEV parent 1: protocol ip prio 11 u32 match ip dport 4569 0xffff match ip protocol 17 0xff flowid 1:1 tc filter add dev $LANDEV parent 1: protocol ip prio 12 u32 match ip sport 4569 0xffff match ip protocol 17 0xff flowid 1:1 tc filter add dev $LANDEV parent 1: protocol ip prio 21 u32 \ match ip protocol 6 0xff \ match u8 0x05 0x0f at 0 \ match u16 0x0000 0xffc0 at 2 \ match u8 0x10 0xff at 33 \ flowid 1:2 tc filter add dev $LANDEV parent 1: protocol ip prio 41 u32 match ip dport 25 0xffff flowid 1:4 tc filter add dev $LANDEV parent 1: protocol ip prio 42 u32 match ip sport 25 0xffff flowid 1:4 tc filter add dev $LANDEV parent 1: protocol ip prio 43 u32 match ip dst 165.154.13.82 flowid 1:4 tc filter add dev $LANDEV parent 1: protocol ip prio 44 u32 match ip dst 165.154.13.83 flowid 1:4 tc filter add dev $LANDEV parent 1: protocol ip prio 51 handle 1 fw flowid 1:5 # clamp MSS to PTMU on forwarded packets since we're using an MTU of 576 bytes on the ADSL link #iptables -I FORWARD -p tcp --tcp-flags SYN,RST SYN -j TCPMSS --clamp-mss-to-pmtu # p2p detection iptables -t mangle -A FORWARD -j CONNMARK --restore-mark iptables -t mangle -A FORWARD -m mark ! --mark 0 -j ACCEPT iptables -t mangle -A FORWARD -m ipp2p --tcp --udp --edk --dc --kazaa --gnu --bit --apple --winmx --soul -j MARK --set-mark 1 iptables -t mangle -A FORWARD -j CONNMARK --save-mark --Boundary-00=_rxLJCJzqPO0Jvjl Content-Type: text/plain; charset="us-ascii"; name="cpuinfo.txt" Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="cpuinfo.txt" # cat /proc/cpuinfo processor : 0 vendor_id : GenuineIntel cpu family : 6 model : 8 model name : Pentium III (Coppermine) stepping : 3 cpu MHz : 802.310 cache size : 256 KB fdiv_bug : no hlt_bug : no f00f_bug : no coma_bug : no fpu : yes fpu_exception : yes cpuid level : 2 wp : yes flags : fpu vme de pse tsc msr pae mce cx8 sep mtrr pge mca cmov pat pse36 mmx fxsr sse bogomips : 1585.15 --Boundary-00=_rxLJCJzqPO0Jvjl Content-Type: text/plain; charset="us-ascii"; name="dmesg.txt" Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="dmesg.txt" HTB: dequeue bug (8,123376738,123376738), report it please ! htb*g j=123376738 lj=123376738 htb*r7 m=0 htb*r6 m=0 htb*r5 m=0 htb*r4 m=0 htb*r3 m=0 htb*r2 m=0 htb*r1 m=0 htb*r0 m=0 htb*c10001 m=2 t=24731 c=24731 pq=0 df=68181 ql=0 pa=0 f: htb*c10010 m=2 t=291481 c=28542 pq=0 df=68181 ql=0 pa=0 f: htb*c10020 m=2 t=77441 c=28542 pq=0 df=203144 ql=0 pa=0 f: htb*c10030 m=2 t=-91376 c=-2715 pq=0 df=92920 ql=0 pa=0 f: htb*c10040 m=2 t=303504 c=28402 pq=0 df=4498679 ql=0 pa=0 f: htb*c10050 m=2 t=283166 c=26595 pq=0 df=859108 ql=0 pa=0 f: --Boundary-00=_rxLJCJzqPO0Jvjl Content-Type: text/plain; charset="us-ascii"; name="ifconfig.txt" Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="ifconfig.txt" eth0 Link encap:Ethernet HWaddr 00:90:27:1C:E0:08 inet addr:165.154.13.1 Bcast:165.154.13.15 Mask:255.255.255.240 UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1 RX packets:32062631 errors:0 dropped:0 overruns:0 frame:0 TX packets:34466609 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:10 RX bytes:896639597 (855.1 Mb) TX bytes:2974219028 (2836.4 Mb) Interrupt:11 Base address:0x6000 eth0:0 Link encap:Ethernet HWaddr 00:90:27:1C:E0:08 inet addr:165.154.13.17 Bcast:165.154.13.31 Mask:255.255.255.240 UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1 Interrupt:11 Base address:0x6000 eth0:1 Link encap:Ethernet HWaddr 00:90:27:1C:E0:08 inet addr:165.154.13.33 Bcast:165.154.13.47 Mask:255.255.255.240 UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1 Interrupt:11 Base address:0x6000 eth0:2 Link encap:Ethernet HWaddr 00:90:27:1C:E0:08 inet addr:165.154.13.49 Bcast:165.154.13.63 Mask:255.255.255.240 UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1 Interrupt:11 Base address:0x6000 eth0:3 Link encap:Ethernet HWaddr 00:90:27:1C:E0:08 inet addr:165.154.13.65 Bcast:165.154.13.79 Mask:255.255.255.240 UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1 Interrupt:11 Base address:0x6000 eth0:4 Link encap:Ethernet HWaddr 00:90:27:1C:E0:08 inet addr:165.154.13.81 Bcast:165.154.13.95 Mask:255.255.255.240 UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1 Interrupt:11 Base address:0x6000 eth0:5 Link encap:Ethernet HWaddr 00:90:27:1C:E0:08 inet addr:165.154.13.97 Bcast:165.154.13.127 Mask:255.255.255.224 UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1 Interrupt:11 Base address:0x6000 lo Link encap:Local Loopback inet addr:127.0.0.1 Mask:255.0.0.0 UP LOOPBACK RUNNING MTU:16436 Metric:1 RX packets:2 errors:0 dropped:0 overruns:0 frame:0 TX packets:2 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:0 RX bytes:200 (200.0 b) TX bytes:200 (200.0 b) wp1adsl Link encap:Ethernet HWaddr 00:77:77:77:7A:D7 inet addr:165.154.5.138 Bcast:165.154.255.255 Mask:255.255.255.255 UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1 RX packets:33218697 errors:0 dropped:0 overruns:0 frame:0 TX packets:30854945 errors:0 dropped:0 overruns:0 carrier:20 collisions:17 txqueuelen:10 RX bytes:2672362584 (2548.5 Mb) TX bytes:501798888 (478.5 Mb) Interrupt:10 Memory:d0920000-d0921fff --Boundary-00=_rxLJCJzqPO0Jvjl-- From jeroen@unfix.org Tue Mar 1 11:46:29 2005 Received: with ECARTIS (v1.0.0; list netdev); Tue, 01 Mar 2005 11:46:35 -0800 (PST) Received: from noc.sixxs.net (postfix@noc.sixxs.net [213.197.29.32]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j21JkSVC028048 for ; Tue, 1 Mar 2005 11:46:29 -0800 Received: from localhost (localhost [127.0.0.1]) by noc.sixxs.net (Postfix) with ESMTP id B771524061; Tue, 1 Mar 2005 20:46:26 +0100 (CET) Received: from noc.sixxs.net ([127.0.0.1]) by localhost (noc [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 28559-05; Tue, 1 Mar 2005 20:46:26 +0100 (CET) Received: from firenze.zurich.ibm.com (pat.zurich.ibm.com [195.176.20.45]) (using SSLv3 with cipher RC4-MD5 (128/128 bits)) (No client certificate requested) by noc.sixxs.net (Postfix) with ESMTP id EB05B2400D; Tue, 1 Mar 2005 20:46:25 +0100 (CET) Subject: Re: (usagi-users 03222) Re: support of IPv6 by NFS From: Jeroen Massar To: Quantum Scientific Cc: netdev@oss.sgi.com, usagi-users@linux-ipv6.org In-Reply-To: <200503011256.25282.Info@quantum-sci.com> References: <42243F8D.5030302@bull.net> <200503010744.38339.Info@Quantum-Sci.com> <1109689712.17484.6.camel@firenze.zurich.ibm.com> <200503011256.25282.Info@quantum-sci.com> Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="=-GC/h5/qQDKSLl0sInN+V" Organization: Unfix Date: Tue, 01 Mar 2005 20:46:23 +0100 Message-Id: <1109706383.17484.52.camel@firenze.zurich.ibm.com> Mime-Version: 1.0 X-Mailer: Evolution 2.1.5 (2.1.5-1) X-Virus-Scanned: ClamAV 0.83/737/Mon Feb 28 22:22:18 2005 on oss.sgi.com X-Virus-Scanned: noc.sixxs.net - http://www.sixxs.net X-Virus-Status: Clean X-archive-position: 2197 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: jeroen@unfix.org Precedence: bulk X-list: netdev --=-GC/h5/qQDKSLl0sInN+V Content-Type: text/plain Content-Transfer-Encoding: quoted-printable On Tue, 2005-03-01 at 12:56 -0600, Quantum Scientific wrote: >On Tuesday 01 March 2005 9:08, Jeroen Massar wrote: >> On Tue, 2005-03-01 at 07:44 -0600, Quantum Scientific wrote:=20 >> >On Tuesday 01 March 2005 4:10, Gilles Quillard wrote: >> >> This works but this needs that the kernel has been compiled with IPv6= ,=20 >> >> which is not mandotary. A lot of people in the Linux community do not= =20 >> >> have experience with IPv6 yet and are not ready to use it. So making = it=20 >> >> mandatory for NFS, even in a pure IPv4 network, is not easy. >> > >> >My experience is that IPV6 is extremely difficult to figure out how to = set=20 >up=20 >> >securely, for the time being, due to lack of connection-sharing. >>=20 >> NAT is not a firewall. Get that into your brain. > >Jeroen, was this addressed to me, or to Giles? Never mind, it doesn't mat= ter; your=20 >words show that you are an uneducated man. As you have read correctly, and how the indentation of the message shows it was a reply to your post. Btw, I am 'educated' enough ;) =20 >On Tuesday 01 March 2005 9:08, Jeroen Massar wrote: >> First couple of hits when doing a google on "Teredo BSD", or for you to >> click as that might be difficult: >> http://www.google.com/search?q=3Dteredo+bsd >... >> On Tue, 2005-03-01 at 07:44 -0600, Quantum Scientific wrote:=20 >> >Although I realize that all of us who run Linux are ostensibly uber-gur= us,=20 >> >fact is this is a negative first experience for most, stemming from >> >attempts by distros to encourage ppl to use it with an inoperative >> >function, and without an obvious way to troubleshoot/repair. >>=20 >> I can clearly assume that you are not part of the 'ostensibly >> uber-gurus' you try to mention.=20 > >And we can clearly assume that you are petty, and just an asshole. Pretty depends on who you ask of course, most ladies will say so fortunately and I don't care about a guys opinion ;) > No, I am=20 >not a Linux uber-guru. I am a commercial real estate developer, using Lin= ux=20 >as a hobby. You may not want my input, but others seem to, judging from=20 >emails I've gotten in back-channel about you. Could you please publish these 'back-channel' communications? I would love to hear comments about me. They are apparently about me, and reading from your sentence you are implying that they are accusing me of a lot of bad things. I don't need names, but please publish them, then everybody knows what it is so bad about me, and even better, then I might learn from these 'issues' that so 'others' might be having. But I'll just assume you've misjudged me. The fact that you need faul words tells a lot about your reasoning. >> Loads of people seem to have no problem at all with IPv6, getting it up >> and running and actually using it for a lot of traffic. >> That fact that you are only complaining, without doing any actual >> research, typing two words in google, says enough. You are not even >> capable of configuring your mailer properly to include your own name, >> the field is not called "Realname" for nothing... > >Obviously you have not been following my emails, and have simply written y= our=20 >response to carp and ignorantly pretend you are superior in some way. Thi= s=20 >is no different than noise. Where is your actual technical arguments then? The only few items you named are wellknown and are being addressed already, but things like that take time, especially in an environment where people are doing it on a free basis. As for the 'superiority', let your 'back-channel' decide on that. >As most here have ascertained, I said the things I have said, as reflectiv= e of=20 >the experiences of the majority when trying to set up IPV6. "most" of the participants of these mailinglists, both of them to which you where at first unable to subscribe, contain people who simply lurk and listen and try to learn from the content that is brought forth here. Claiming 'most' is simply silly. >If you have a=20 >problem with that, you are unable to understand the true issues, and show = it=20 >with every word. =20 The problems are known, but you are trying to misleadingly shove them under the wrong header. Check http://www.v6fix.net as others have also pointed out to you. You might have also wanted to read my mails in where I noted that even Cisco PIX's don't support it yet, unless you get an EFT or the brand sprankling new 7.0 image. >You will have no more responses from me. Thank you very much, that saves me quite some valuable time trying to reply to posts which are misleading in various ways. Greets, Jeroen --=-GC/h5/qQDKSLl0sInN+V Content-Type: application/pgp-signature; name=signature.asc Content-Description: This is a digitally signed message part -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.0 (GNU/Linux) Comment: Jeroen Massar / http://unfix.org/~jeroen/ iD8DBQBCJMaPKaooUjM+fCMRAjLzAKCb+Eg1iugAvRuf3wZX3f9t/fB+qACcCYOa u0NImhiclZ+ONBjITRUzllI= =t1Qc -----END PGP SIGNATURE----- --=-GC/h5/qQDKSLl0sInN+V-- From pj@sgi.com Tue Mar 1 12:41:18 2005 Received: with ECARTIS (v1.0.0; list netdev); Tue, 01 Mar 2005 12:41:22 -0800 (PST) Received: from omx1.americas.sgi.com (omx1-ext.sgi.com [192.48.179.11]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j21KfBEc000790 for ; Tue, 1 Mar 2005 12:41:11 -0800 Received: from cthulhu.engr.sgi.com (cthulhu.engr.sgi.com [192.26.80.2]) by omx1.americas.sgi.com (8.12.10/8.12.9/linux-outbound_gateway-1.1) with ESMTP id j21KfAxT026327 for ; Tue, 1 Mar 2005 14:41:10 -0600 Received: from vpn2 (mtv-vpn-hw-pj-2.corp.sgi.com [134.15.25.219]) by cthulhu.engr.sgi.com (SGI-8.12.5/8.12.5) with SMTP id j21Kem0g30045031; Tue, 1 Mar 2005 12:40:48 -0800 (PST) Date: Tue, 1 Mar 2005 12:40:41 -0800 From: Paul Jackson To: hadi@cyberus.ca Cc: akpm@osdl.org, guillaume.thouvenin@bull.net, kaigai@ak.jp.nec.com, marcelo.tosatti@cyclades.com, davem@redhat.com, jlan@sgi.com, lse-tech@lists.sourceforge.net, linux-kernel@vger.kernel.org, netdev@oss.sgi.com, elsa-devel@lists.sourceforge.net Subject: Re: [Lse-tech] Re: A common layer for Accounting packages Message-Id: <20050301124041.2403d641.pj@sgi.com> In-Reply-To: <1109592658.2188.924.camel@jzny.localdomain> References: <42168D9E.1010900@sgi.com> <20050218171610.757ba9c9.akpm@osdl.org> <421993A2.4020308@ak.jp.nec.com> <421B955A.9060000@sgi.com> <421C2B99.2040600@ak.jp.nec.com> <421CEC38.7010008@sgi.com> <421EB299.4010906@ak.jp.nec.com> <20050224212839.7953167c.akpm@osdl.org> <20050227094949.GA22439@logos.cnet> <4221E548.4000008@ak.jp.nec.com> <20050227140355.GA23055@logos.cnet> <42227AEA.6050002@ak.jp.nec.com> <1109575236.8549.14.camel@frecb000711.frec.bull.fr> <20050227233943.6cb89226.akpm@osdl.org> <1109592658.2188.924.camel@jzny.localdomain> Organization: SGI X-Mailer: Sylpheed version 1.0.0 (GTK+ 1.2.10; i686-pc-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV 0.83/737/Mon Feb 28 22:22:18 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 2198 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: pj@sgi.com Precedence: bulk X-list: netdev Jamal wrote: > What was wrong with just going ahead and just always > invoking your netlink_send()? I think the hope was to reduce the cost of the accounting hook in fork to "next-to-zero" if accounting is not being used on that system. See Andrew's query earlier: > b) they are next-to-zero cost if something is listening on the netlink > socket but no accounting daemon is running. Presumably sending an ignored packet costs something, quite possibly more than "next-to-zero". -- I won't rest till it's the best ... Programmer, Linux Scalability Paul Jackson 1.650.933.1373, 1.925.600.0401 From zdzichu@irc.pl Tue Mar 1 12:44:38 2005 Received: with ECARTIS (v1.0.0; list netdev); Tue, 01 Mar 2005 12:44:41 -0800 (PST) Received: from pollux.ds.pg.gda.pl (postfix@pollux.ds.pg.gda.pl [153.19.208.7]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j21KibhL001363 for ; Tue, 1 Mar 2005 12:44:37 -0800 Received: from localhost (localhost [127.0.0.1]) by pollux.ds.pg.gda.pl (Postfix) with ESMTP id E12C1E1CAE for ; Tue, 1 Mar 2005 21:44:26 +0100 (CET) Received: from pollux.ds.pg.gda.pl ([127.0.0.1]) by localhost (pollux [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 14527-03 for ; Tue, 1 Mar 2005 21:44:26 +0100 (CET) Received: from piorun.ds.pg.gda.pl (piorun.ds.pg.gda.pl [153.19.208.8]) by pollux.ds.pg.gda.pl (Postfix) with ESMTP id 8CA8BE1CAA for ; Tue, 1 Mar 2005 21:44:26 +0100 (CET) Received: from matthew.ogrody.nsm.pl (localhost [127.0.0.1]) by piorun.ds.pg.gda.pl (8.13.1/8.13.1) with SMTP id j21KiJR8005565 for ; Tue, 1 Mar 2005 21:44:20 +0100 Received: (qmail 16954 invoked by uid 1000); 1 Mar 2005 20:46:15 -0000 Date: Tue, 1 Mar 2005 21:46:15 +0100 From: Tomasz Torcz To: netdev@oss.sgi.com Subject: Re: Kernel 2.6 IPV6 Busted Message-ID: <20050301204615.GC15329@irc.pl> References: <200502270928.44402.Info@Quantum-Sci.com> <200502271410.39611.Info@quantum-sci.com> <20050227133517.578884df.davem@davemloft.net> <200503011207.34029.vda@port.imtp.ilyichevsk.odessa.ua> <422497BA.9090606@pobox.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <422497BA.9090606@pobox.com> User-Agent: Mutt/1.5.4i X-Virus-Scanned: ClamAV 0.83/737/Mon Feb 28 22:22:18 2005 on oss.sgi.com X-Virus-Scanned: ClamAV 0.80/700/Fri Feb 4 00:33:15 2005 clamav-milter version 0.80j on piorun.ds.pg.gda.pl X-Virus-Status: Clean X-Virus-Scanned: by amavisd-new at pollux.ds.pg.gda.pl X-archive-position: 2199 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: zdzichu@irc.pl Precedence: bulk X-list: netdev On Tue, Mar 01, 2005 at 11:26:34AM -0500, Jeff Garzik wrote: > Just write sane firewall rules that don't allow incoming. Isn't this thread about non-working stateful firewalling? Specifically situation where -m state --state RELATED or ESTABLISHED isn't allowin any packets because there is no connection tracking? Without allowing incoming packets there could be no 2-way communication (for UDP at least). -- Tomasz Torcz "Never underestimate the bandwidth of a station zdzichu@irc.-nie.spam-.pl wagon filled with backup tapes." -- Jim Gray From ehem@m5p.com Tue Mar 1 13:39:56 2005 Received: with ECARTIS (v1.0.0; list netdev); Tue, 01 Mar 2005 13:40:02 -0800 (PST) Received: from mailhost.m5p.com (209-162-215-52.dq1sn.easystreet.com [209.162.215.52]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j21LdtMq003181 for ; Tue, 1 Mar 2005 13:39:56 -0800 Received: from m5p.com (mailhost.m5p.com [IPv6:2001:418:3fd::f7]) by mailhost.m5p.com (8.13.2/8.13.2) with ESMTP id j21LdnUh034998 (version=TLSv1/SSLv3 cipher=DHE-DSS-AES256-SHA bits=256 verify=OK) for ; Tue, 1 Mar 2005 13:39:49 -0800 (PST) Received: (from defang@localhost) by m5p.com (8.13.2/8.13.2/Submit) id j21Lbr1N034972 for ; Tue, 1 Mar 2005 13:37:53 -0800 (PST) X-Authentication-Warning: ashmont.m5p.com: defang set sender to using -f Received: from m5p.com (ssh.m5p.com [2001:418:3fd::fb]) by mailhost.m5p.com (envelope-sender ) (MIMEDefang) with ESMTP id j21Lbrtx034971; Tue, 01 Mar 2005 13:37:53 -0800 (PST) Received: (from ehem@localhost) by m5p.com (8.13.2/8.13.2/Submit) id j21LbqmL005962; Tue, 1 Mar 2005 13:37:52 -0800 (PST) From: Elliott Mitchell Message-Id: <200503012137.j21LbqmL005962@m5p.com> Subject: Re: (usagi-users 03226) Re: support of IPv6 by NFS In-Reply-To: <200503011256.25282.Info@quantum-sci.com> To: usagi-users@linux-ipv6.org Date: Tue, 1 Mar 2005 13:37:52 -0800 (PST) CC: netdev@oss.sgi.com, Jeroen Massar X-Mailer: ELM [version 2.4ME+ PL119 (25)] MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII X-Scanned-By: MIMEDefang 2.49 on IPv6:2001:418:3fd::f7 X-Virus-Scanned: ClamAV 0.83/737/Mon Feb 28 22:22:18 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 2200 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: ehem@m5p.com Precedence: bulk X-list: netdev >From: Quantum Scientific > On Tuesday 01 March 2005 9:08, Jeroen Massar wrote: > > On Tue, 2005-03-01 at 07:44 -0600, Quantum Scientific wrote: > > >On Tuesday 01 March 2005 4:10, Gilles Quillard wrote: > > >> This works but this needs that the kernel has been compiled with IPv6, > > >> which is not mandotary. A lot of people in the Linux community do not > > >> have experience with IPv6 yet and are not ready to use it. So making it > > >> mandatory for NFS, even in a pure IPv4 network, is not easy. > > > > > >My experience is that IPV6 is extremely difficult to figure out how to set > up > > >securely, for the time being, due to lack of connection-sharing. > > > > NAT is not a firewall. Get that into your brain. > > Jeroen, was this addressed to me, or to Giles? Never mind, it doesn't matter; your > words show that you are an uneducated man. Though I was planning to be more polite, I was going to write a similar message. If you're depending on a firewall as a main defense, you're already dead. If you wish your hosts to be secure, they MUST be secure even if they didn't have a firewall! The already mentioned approach works quite well. Filter packets with only the SYN bit set, no incoming connections will work, outgoing connections will be unaffected. No state needed. Though important for a firewall, stateful filtering isn't a critical feature to state the IPv6 stack is working. -- (\___(\___(\______ --=> 8-) EHM <=-- ______/)___/)___/) \ ( | EHeM@gremlin.m5p.com PGP 8881EF59 | ) / \_ \ | _____ -O #include O- _____ | / _/ \___\_|_/82 04 A1 3C C7 B1 37 2A*E3 6E 84 DA 97 4C 40 E6\_|_/___/ From andre@tomt.net Tue Mar 1 13:50:26 2005 Received: with ECARTIS (v1.0.0; list netdev); Tue, 01 Mar 2005 13:50:29 -0800 (PST) Received: from mx1.skjellin.no (mail1.skjellin.no [80.239.42.67]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j21LoPCJ004049 for ; Tue, 1 Mar 2005 13:50:25 -0800 Received: from localhost (localhost [127.0.0.1]) by mx1.skjellin.no (Postfix) with ESMTP id 15E8E88553; Tue, 1 Mar 2005 22:50:27 +0100 (CET) Received: from puppen.pasop.tomt.net (gw-fe-1.pasop.tomt.net [10.255.1.1]) by mail1.skjellin.no (Postfix) with ESMTP id 45C1F88552; Tue, 1 Mar 2005 22:50:25 +0100 (CET) Received: from [10.255.1.10] (slurv.pasop.tomt.net [10.255.1.10]) by puppen.pasop.tomt.net (Postfix) with ESMTP id 5C009229CD; Tue, 1 Mar 2005 22:50:22 +0100 (CET) Message-ID: <4224E3A1.5090003@tomt.net> Date: Tue, 01 Mar 2005 22:50:25 +0100 From: Andre Tomt User-Agent: Mozilla Thunderbird 1.0 (Windows/20041206) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Quantum Scientific Cc: netdev@oss.sgi.com Subject: Re: Kernel 2.6 IPV6 Busted References: <200502270928.44402.Info@Quantum-Sci.com> <422205F7.4080401@tomt.net> <200502271220.06560.Info@quantum-sci.com> In-Reply-To: <200502271220.06560.Info@quantum-sci.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV 0.83/737/Mon Feb 28 22:22:18 2005 on oss.sgi.com X-Virus-Scanned: by amavisd-new-20030616-p10 (Debian) at skjellin.no X-Virus-Status: Clean X-archive-position: 2201 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: andre@tomt.net Precedence: bulk X-list: netdev Quantum Scientific wrote: > On Sunday 27 February 2005 11:40, Andre Tomt wrote: >>You seem to be fixed on the idea that a ipv6 stack has to have stateful >>firewalling, or else its utter crap, correct? :-) > > > No, I'll try to say this clearer. > > The stack works fine in. And out. But for a useful virtual circuit you must > have something like connection tracking. > > Remember what my issue is: > - I have a very tight firewall, > - I ping6 out, > - The firewall blocks the reply back, because the connection is stateless! Never, ever, filter ICMP. Or at least be extremely careful doing so. You may end up breaking things like PMTU and error notification mechanisms. > - Same with http, etc. > > This means that I have to open for incoming, virtually every port I send > outgoing to, or else I do not get any replies. This is what I call > non-functional, because one does not open incoming ports, for the most part. > > Why are you not having this problem? Because I tend to use the oldskool way of doing it when there is not other option, by matching on SYN. It's a bit trickier with UDP, but doable for most UDP based protocols. Also on a per-system basis I tend to prefer to secure services rather than firewall them; by for example just shutting them off/uninstalling them if not used, binding to localhost, use tcpwrappers.. that sort of thing. Don't get me wrong; I'd *love* to see connection tracking integrated with ipv6 netfilter. It would simplify some of my setups greatly. But it would also be out of the question on a lot of my other setups; as connection tracking is a *severe* bottleneck when faced with any real amounts of load. It's not The universal solution, and the lack of it is not *that* bad. >>Connection tracking is on the way, currently a implementation exists in >>the netfilter.org patch-o-matic svn. > > > Is this reasonably solid? Does this operate on Layer 3, rather than Layer 2? It operates like the IPv4 state matches. Solid? Well, I guess testers are welcome :) From afleming@freescale.com Tue Mar 1 15:15:35 2005 Received: with ECARTIS (v1.0.0; list netdev); Tue, 01 Mar 2005 15:15:40 -0800 (PST) Received: from az33egw02.freescale.net (az33egw02.freescale.net [192.88.158.103]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j21NFZ6b006715 for ; Tue, 1 Mar 2005 15:15:35 -0800 Received: from az33smr02.freescale.net (az33smr02.freescale.net [10.64.34.200]) by az33egw02.freescale.net (8.12.11/az33egw02) with ESMTP id j21NGYgd001656; Tue, 1 Mar 2005 16:16:34 -0700 (MST) Received: from [10.82.17.56] ([10.82.17.56]) by az33smr02.freescale.net (8.13.1/8.13.0) with ESMTP id j21NGUJP020448; Tue, 1 Mar 2005 17:16:30 -0600 (CST) In-Reply-To: <20050301104338.1380b7cc@dxpl.pdx.osdl.net> References: <3a958240e12af10ef6777f908abfe682@freescale.com> <20050301104338.1380b7cc@dxpl.pdx.osdl.net> Mime-Version: 1.0 (Apple Message framework v619.2) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <2774b2c9a643fd8fadc48be99ec2b5c6@freescale.com> Content-Transfer-Encoding: 7bit Cc: Netdev , Jeff Garzik From: Andy Fleming Subject: Re: RFC new ethtool command Date: Tue, 1 Mar 2005 17:15:30 -0600 To: Stephen Hemminger X-Mailer: Apple Mail (2.619.2) X-Virus-Scanned: ClamAV 0.83/737/Mon Feb 28 22:22:18 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 2202 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: afleming@freescale.com Precedence: bulk X-list: netdev On Mar 1, 2005, at 12:43, Stephen Hemminger wrote: > > I understand the motivation, but it seems to go against the philosophy > of having a general purpose interface. Rather than having device > driver > specific special cases, why not add useful abstractions for new > features. > Phy interface testing and management is generic, and several devices > could > support it. Ok, I probably shouldn't have mentioned the PHY testing, which was just a hack to inject errors into some code I was working on. My point in this case was it is easy using this method to add temporary debug parameters. I concede that ethtool may not be the best place for debug support. The problem I'm trying to solve is for the new features I mentioned before. I have an ethernet controller which is part of an SOC, and has access to the L2 cache. As such, the controller can read and write buffer descriptors directly from/to the L2 cache, and even lock them into the L2. Adding an abstraction for this to ethtool when there's only one driver that uses it seems premature. If no other controllers implement such a feature, then ethtool is cluttered up with what amounts to driver-specific code. If other controllers implement a similar feature, it's quite possible that the abstraction will need to change. Changing the abstraction (or adding a new one) can take up a significant amount of time, since the driver writer now has to modify the ethtool source, the ethtool kernel support, and then get the changes accepted. I agree that, eventually, it would be the goal to implement an abstraction, and go through the process of getting the changes accepted, but not until there's a "market" for the abstraction. > > For the first case, of "cutting-edge" controller's, the best solution > is to > always turn the feature on and make it work correctly. If you can't > make it > work correctly then use module parameter or chip set detection to turn > it off. > Another option to expose warts is using sysfs attribute groups to add > additional > fields to /sys/class/net/ethXX/. Well, some features are a little more complex than on/off. The stashing feature in the 85xx ethernet controllers allows a portion of each incoming packet to be extracted and placed directly in L2. This has performance implications, and so it is useful to be able to tune the parameters at runtime. Especially for benchmarking purposes, but also, once benchmarking has been done, to tune performance to the workload. > > When debugging a new driver, module parameters work find for > controlling > test parameters. If this needs to make into production code, sysfs > could > also be used. Module parameters are fine as long as you aren't trying to root your filesystem over NFS using the driver. > > This proposal is basically a device specific multiplexing interface > like > ioctl or SIOCDEVPRIVATE. This style of interface is considered bad, and > undesirable. Well, yes... it uses ioctl and SIOCETHTOOL. I can see how sysfs could be used to do everything I'm trying to do. However, the same could be said about everything ethtool does. Is ethtool no longer the correct tool to use for tuning ethernet performance? I'm not philosophically opposed to the idea of supporting these features through sysfs, but it seems easier to be able to point people at ethtool for all their performance tuning needs. Andy Fleming Open Source Team Freescale Semiconductor, Inc From tommy.christensen@tpack.net Tue Mar 1 15:45:34 2005 Received: with ECARTIS (v1.0.0; list netdev); Tue, 01 Mar 2005 15:45:37 -0800 (PST) Received: from mail.tpack.net (ip18.tpack.net [213.173.228.18]) by oss.sgi.com (8.13.0/8.13.0) with SMTP id j21NjW7U007660 for ; Tue, 1 Mar 2005 15:45:33 -0800 Received: (qmail 5521 invoked from network); 1 Mar 2005 23:45:26 -0000 Received: from dhcp-197.cph.tpack.net (HELO ?172.17.159.11?) (192.168.0.197) by 0 with SMTP; 1 Mar 2005 23:45:26 -0000 Message-ID: <4224FEAF.2090209@tpack.net> Date: Wed, 02 Mar 2005 00:45:51 +0100 From: Tommy Christensen User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.2) Gecko/20040803 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Andrew Kohlsmith CC: netdev@oss.sgi.com Subject: Re: 2.6.10 and HTB dequeue bug References: <200503011403.07243.akohlsmith@mixdown.ca> In-Reply-To: <200503011403.07243.akohlsmith@mixdown.ca> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV 0.83/737/Mon Feb 28 22:22:18 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 2203 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: tommy.christensen@tpack.net Precedence: bulk X-list: netdev Andrew Kohlsmith wrote: > I received the following in my dmesg today. As requested by tgr in FreeNode's > #lartc, I'm emailing all the requested information here. > HTB: dequeue bug (8,123376738,123376738), report it please ! > htb*g j=123376738 lj=123376738 > htb*r7 m=0 > htb*r6 m=0 > htb*r5 m=0 > htb*r4 m=0 > htb*r3 m=0 > htb*r2 m=0 > htb*r1 m=0 > htb*r0 m=0 > htb*c10001 m=2 t=24731 c=24731 pq=0 df=68181 ql=0 pa=0 f: > htb*c10010 m=2 t=291481 c=28542 pq=0 df=68181 ql=0 pa=0 f: > htb*c10020 m=2 t=77441 c=28542 pq=0 df=203144 ql=0 pa=0 f: > htb*c10030 m=2 t=-91376 c=-2715 pq=0 df=92920 ql=0 pa=0 f: > htb*c10040 m=2 t=303504 c=28402 pq=0 df=4498679 ql=0 pa=0 f: > htb*c10050 m=2 t=283166 c=26595 pq=0 df=859108 ql=0 pa=0 f: An overflow of q->direct_queue (in htb_enqueue) seems to offset sch->q.qlen. Probably this is what's causing htb_dequeue to complain. -Tommy From Info@Quantum-Sci.com Tue Mar 1 16:10:47 2005 Received: with ECARTIS (v1.0.0; list netdev); Tue, 01 Mar 2005 16:10:55 -0800 (PST) Received: from xeonone.bizarre-host.com (xeonone.bizarre-host.com [70.84.110.116]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j220Ak2o008696 for ; Tue, 1 Mar 2005 16:10:46 -0800 Received: from c-24-1-54-54.client.comcast.net ([24.1.54.54] helo=hydra.darkmatter.org) by xeonone.bizarre-host.com with esmtpsa (SSLv3:RC4-MD5:128) (Exim 4.44) id 1D6HRx-0000HY-Gn for netdev@oss.sgi.com; Wed, 02 Mar 2005 00:10:49 +0000 From: Quantum Scientific To: netdev@oss.sgi.com Subject: Re: Kernel 2.6 IPV6 Busted Date: Tue, 1 Mar 2005 17:55:55 -0600 User-Agent: KMail/1.7.1 References: <200502270928.44402.Info@Quantum-Sci.com> <422497BA.9090606@pobox.com> <20050301204615.GC15329@irc.pl> In-Reply-To: <20050301204615.GC15329@irc.pl> helo: PowerMAC MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200503011755.55671.Info@Quantum-Sci.com> X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - xeonone.bizarre-host.com X-AntiAbuse: Original Domain - oss.sgi.com X-AntiAbuse: Originator/Caller UID/GID - [0 0] / [47 12] X-AntiAbuse: Sender Address Domain - Quantum-Sci.com X-Source: X-Source-Args: X-Source-Dir: X-Virus-Scanned: ClamAV 0.83/737/Mon Feb 28 22:22:18 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 2204 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: Info@Quantum-Sci.com Precedence: bulk X-list: netdev On Tuesday 01 March 2005 14:46, Tomasz Torcz wrote: > On Tue, Mar 01, 2005 at 11:26:34AM -0500, Jeff Garzik wrote: > > Just write sane firewall rules that don't allow incoming. > > Isn't this thread about non-working stateful firewalling? Specifically > situation where -m state --state RELATED or ESTABLISHED isn't allowin > any packets because there is no connection tracking? Without allowing > incoming packets there could be no 2-way communication (for UDP at > least). Right. Nor for any of the other protocols. No incoming packets. Carl Cook From Info@quantum-sci.com Tue Mar 1 16:10:47 2005 Received: with ECARTIS (v1.0.0; list netdev); Tue, 01 Mar 2005 16:10:55 -0800 (PST) Received: from xeonone.bizarre-host.com (xeonone.bizarre-host.com [70.84.110.116]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j220AikK008694 for ; Tue, 1 Mar 2005 16:10:46 -0800 Received: from c-24-1-54-54.client.comcast.net ([24.1.54.54] helo=hydra.darkmatter.org) by xeonone.bizarre-host.com with esmtpsa (SSLv3:RC4-MD5:128) (Exim 4.44) id 1D6HRx-0000HY-MT for netdev@oss.sgi.com; Wed, 02 Mar 2005 00:10:49 +0000 From: Quantum Scientific To: netdev@oss.sgi.com Subject: Re: Kernel 2.6 IPV6 Busted Date: Tue, 1 Mar 2005 17:59:53 -0600 User-Agent: KMail/1.7.1 References: <200502270928.44402.Info@Quantum-Sci.com> <200502271220.06560.Info@quantum-sci.com> <4224E3A1.5090003@tomt.net> In-Reply-To: <4224E3A1.5090003@tomt.net> helo: PowerMAC MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200503011759.53734.Info@quantum-sci.com> X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - xeonone.bizarre-host.com X-AntiAbuse: Original Domain - oss.sgi.com X-AntiAbuse: Originator/Caller UID/GID - [0 0] / [47 12] X-AntiAbuse: Sender Address Domain - quantum-sci.com X-Source: X-Source-Args: X-Source-Dir: X-Virus-Scanned: ClamAV 0.83/737/Mon Feb 28 22:22:18 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 2205 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: Info@quantum-sci.com Precedence: bulk X-list: netdev On Tuesday 01 March 2005 15:50, Andre Tomt wrote: > > Remember what my issue is: > > - I have a very tight firewall, > > - I ping6 out, > > - The firewall blocks the reply back, because the connection is stateless! > Never, ever, filter ICMP. Or at least be extremely careful doing so. You > may end up breaking things like PMTU and error notification mechanisms. Care to propose some rules? Maybe not. > Also on a per-system basis I tend to prefer to secure services rather > than firewall them; by for example just shutting them off/uninstalling > them if not used, binding to localhost, use tcpwrappers.. that sort of > thing. Of course. This is implicit. But closing everything is best, to avert investigative activity. Carl Cook From pj@sgi.com Tue Mar 1 20:53:49 2005 Received: with ECARTIS (v1.0.0; list netdev); Tue, 01 Mar 2005 20:53:58 -0800 (PST) Received: from omx2.sgi.com (omx2-ext.sgi.com [192.48.171.19]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j224qhN7021795 for ; Tue, 1 Mar 2005 20:52:43 -0800 Received: from nodin.corp.sgi.com (nodin.corp.sgi.com [192.26.51.193]) by omx2.sgi.com (8.12.11/8.12.9/linux-outbound_gateway-1.1) with ESMTP id j226PVt7028450 for ; Tue, 1 Mar 2005 22:25:41 -0800 Received: from cthulhu.engr.sgi.com (cthulhu.engr.sgi.com [192.26.80.2]) by nodin.corp.sgi.com (SGI-8.12.5/8.12.10/SGI_generic_relay-1.2) with ESMTP id j224qCbT41612974 for ; Tue, 1 Mar 2005 20:52:12 -0800 (PST) Received: from vpn2 (mtv-vpn-hw-pj-2.corp.sgi.com [134.15.25.219]) by cthulhu.engr.sgi.com (SGI-8.12.5/8.12.5) with SMTP id j224oY0g30149649; Tue, 1 Mar 2005 20:50:34 -0800 (PST) Date: Tue, 1 Mar 2005 20:50:33 -0800 From: Paul Jackson To: Kaigai Kohei Cc: guillaume.thouvenin@bull.net, johnpol@2ka.mipt.ru, hadi@cyberus.ca, tgraf@suug.ch, akpm@osdl.org, marcelo.tosatti@cyclades.com, davem@redhat.com, jlan@sgi.com, lse-tech@lists.sourceforge.net, linux-kernel@vger.kernel.org, netdev@oss.sgi.com, elsa-devel@lists.sourceforge.net Subject: Re: [Lse-tech] Re: A common layer for Accounting packages Message-Id: <20050301205033.1140cd5a.pj@sgi.com> In-Reply-To: <42247051.7070303@ak.jp.nec.com> References: <4221E548.4000008@ak.jp.nec.com> <20050227140355.GA23055@logos.cnet> <42227AEA.6050002@ak.jp.nec.com> <1109575236.8549.14.camel@frecb000711.frec.bull.fr> <20050227233943.6cb89226.akpm@osdl.org> <1109592658.2188.924.camel@jzny.localdomain> <20050228132051.GO31837@postel.suug.ch> <1109598010.2188.994.camel@jzny.localdomain> <20050228135307.GP31837@postel.suug.ch> <1109599803.2188.1014.camel@jzny.localdomain> <20050228142551.GQ31837@postel.suug.ch> <1109604693.1072.8.camel@jzny.localdomain> <20050228191759.6f7b656e@zanzibar.2ka.mipt.ru> <1109665299.8594.55.camel@frecb000711.frec.bull.fr> <42247051.7070303@ak.jp.nec.com> Organization: SGI X-Mailer: Sylpheed version 1.0.0 (GTK+ 1.2.10; i686-pc-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV 0.83/737/Mon Feb 28 22:22:18 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 2206 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: pj@sgi.com Precedence: bulk X-list: netdev Just a thought - perhaps you could see if Jay can test the performance scaling of these changes on larger systems (8 to 64 CPUs, give or take, small for SGI, but big for some vendors.) Things like a global lock, for example, might be harmless on smaller systems, but hurt big time on bigger systems. I don't know if you have any such constructs ... perhaps this doesn't matter. At the very least, we need to know that performance and scaling are not significantly impacted, on systems not using accounting, either because it is obvious from the code, or because someone has tested it. And if performance or scaling was impacted when accounting was enabled, then at least we would want to know how much performance was impacted, so that users would know what to expect when they use accounting. > the process-creation/destruction performance on following three environment. I think this is a good choice of what to measure, and where. Thank-you. > kernel was also locked up after 366th-fork() I have no idea what this is -- good luck finding it. -- I won't rest till it's the best ... Programmer, Linux Scalability Paul Jackson 1.650.933.1373, 1.925.600.0401 From rddunlap@osdl.org Tue Mar 1 21:33:08 2005 Received: with ECARTIS (v1.0.0; list netdev); Tue, 01 Mar 2005 21:33:13 -0800 (PST) Received: from smtp.osdl.org (fire.osdl.org [65.172.181.4]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j225X5l4023010 for ; Tue, 1 Mar 2005 21:33:08 -0800 Received: from shell0.pdx.osdl.net (fw.osdl.org [65.172.181.6]) by smtp.osdl.org (8.12.8/8.12.8) with ESMTP id j225Wxqi023858 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO); Tue, 1 Mar 2005 21:32:59 -0800 Received: from midway.verizon.net (shell0.pdx.osdl.net [10.9.0.31]) by shell0.pdx.osdl.net (8.13.1/8.11.6) with SMTP id j225WwhE021643; Tue, 1 Mar 2005 21:32:58 -0800 Date: Tue, 1 Mar 2005 21:21:37 -0800 From: "Randy.Dunlap" To: netdev@oss.sgi.com Cc: jgarzik , mcgrof@ruslug.rutgers.edu Subject: [PATCH] prism54: fix printk format warnings Message-Id: <20050301212137.57f9532f.rddunlap@osdl.org> Organization: OSDL X-Mailer: Sylpheed version 0.9.8a (GTK+ 1.2.10; i686-pc-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Received-SPF: pass (domain of rddunlap@osdl.org designates 65.172.181.6 as permitted sender) X-MIMEDefang-Filter: osdl$Revision: 1.104 $ X-Scanned-By: MIMEDefang 2.36 X-Virus-Scanned: ClamAV 0.83/737/Mon Feb 28 22:22:18 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 2207 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: rddunlap@osdl.org Precedence: bulk X-list: netdev prism54 build shows some printk format complaints: (sparc64 build warning) drivers/net/wireless/prism54/isl_38xx.c:131: warning: long int format, different type arg (arg 3) drivers/net/wireless/prism54/isl_38xx.c:151: warning: long int format, different type arg (arg 3) cross-compile results: https://www.osdl.org/plm-cgi/plm?module=patch_info&patch_id=4240 Signed-off-by: Randy Dunlap diffstat:= drivers/net/wireless/prism54/isl_38xx.c | 12 ++++++------ 1 files changed, 6 insertions(+), 6 deletions(-) diff -Naurp ./drivers/net/wireless/prism54/isl_38xx.c~prism_printk ./drivers/net/wireless/prism54/isl_38xx.c --- ./drivers/net/wireless/prism54/isl_38xx.c~prism_printk 2004-12-24 13:34:45.000000000 -0800 +++ ./drivers/net/wireless/prism54/isl_38xx.c 2005-03-01 20:15:00.189995120 -0800 @@ -125,11 +125,11 @@ isl38xx_trigger_device(int asleep, void #if VERBOSE > SHOW_ERROR_MESSAGES do_gettimeofday(¤t_time); DEBUG(SHOW_TRACING, "%08li.%08li Device wakeup triggered\n", - current_time.tv_sec, current_time.tv_usec); + current_time.tv_sec, (long)current_time.tv_usec); #endif DEBUG(SHOW_TRACING, "%08li.%08li Device register read %08x\n", - current_time.tv_sec, current_time.tv_usec, + current_time.tv_sec, (long)current_time.tv_usec, readl(device_base + ISL38XX_CTRL_STAT_REG)); udelay(ISL38XX_WRITEIO_DELAY); @@ -139,7 +139,7 @@ isl38xx_trigger_device(int asleep, void do_gettimeofday(¤t_time); DEBUG(SHOW_TRACING, "%08li.%08li Device register abadface\n", - current_time.tv_sec, current_time.tv_usec); + current_time.tv_sec, (long)current_time.tv_usec); #endif /* read the Device Status Register until Sleepmode bit is set */ while (reg = readl(device_base + ISL38XX_CTRL_STAT_REG), @@ -150,7 +150,7 @@ isl38xx_trigger_device(int asleep, void DEBUG(SHOW_TRACING, "%08li.%08li Device register read %08x\n", - current_time.tv_sec, current_time.tv_usec, + current_time.tv_sec, (long)current_time.tv_usec, readl(device_base + ISL38XX_CTRL_STAT_REG)); udelay(ISL38XX_WRITEIO_DELAY); @@ -158,7 +158,7 @@ isl38xx_trigger_device(int asleep, void do_gettimeofday(¤t_time); DEBUG(SHOW_TRACING, "%08li.%08li Device asleep counter %i\n", - current_time.tv_sec, current_time.tv_usec, + current_time.tv_sec, (long)current_time.tv_usec, counter); #endif } @@ -174,7 +174,7 @@ isl38xx_trigger_device(int asleep, void #if VERBOSE > SHOW_ERROR_MESSAGES do_gettimeofday(¤t_time); DEBUG(SHOW_TRACING, "%08li.%08li Device register read %08x\n", - current_time.tv_sec, current_time.tv_usec, reg); + current_time.tv_sec, (long)current_time.tv_usec, reg); #endif } else { /* device is (still) awake */ --- From jgarzik@pobox.com Tue Mar 1 21:54:46 2005 Received: with ECARTIS (v1.0.0; list netdev); Tue, 01 Mar 2005 21:54:50 -0800 (PST) Received: from parcelfarce.linux.theplanet.co.uk (IDENT:93@parcelfarce.linux.theplanet.co.uk [195.92.249.252]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j225sj9f024054 for ; Tue, 1 Mar 2005 21:54:46 -0800 Received: from [69.134.152.124] (helo=[10.10.10.88]) by parcelfarce.linux.theplanet.co.uk with asmtp (TLSv1:AES256-SHA:256) (Exim 4.33) id 1D6Mol-00017m-F6; Wed, 02 Mar 2005 05:54:43 +0000 Message-ID: <42255515.70804@pobox.com> Date: Wed, 02 Mar 2005 00:54:29 -0500 From: Jeff Garzik User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.3) Gecko/20040922 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Andy Fleming CC: Netdev Subject: Re: RFC new ethtool command References: <3a958240e12af10ef6777f908abfe682@freescale.com> In-Reply-To: <3a958240e12af10ef6777f908abfe682@freescale.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV 0.83/737/Mon Feb 28 22:22:18 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 2208 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: jgarzik@pobox.com Precedence: bulk X-list: netdev Stephen guessed right. We don't need to add yet another "black hole" (a.k.a. untyped / dynamic) userland interface. One of two directions is suggested: * Create a generalized interface, and add new ethtool commands. * Create a driver-specific ioctl, and submit a patch to userland ethtool which supports this. Driver-specific / device-specific code in userland ethtool is acceptable. Jeff From randy.dunlap@verizon.net Tue Mar 1 21:55:56 2005 Received: with ECARTIS (v1.0.0; list netdev); Tue, 01 Mar 2005 21:56:01 -0800 (PST) Received: from vms044pub.verizon.net (vms044pub.verizon.net [206.46.252.44]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j225tsTR024405 for ; Tue, 1 Mar 2005 21:55:56 -0800 Received: from midway.verizon.net ([4.5.49.23]) by vms044.mailsrvcs.net (Sun Java System Messaging Server 6.2 HotFix 0.04 (built Dec 24 2004)) with ESMTPA id <0ICP00L62N54PV01@vms044.mailsrvcs.net> for netdev@oss.sgi.com; Tue, 01 Mar 2005 23:55:53 -0600 (CST) Date: Tue, 01 Mar 2005 21:44:38 -0800 From: "Randy.Dunlap" X-Face: +5V?h'hZQPB9kW Subject: [PATCH] tulip: de2104x, fix init. sections To: netdev@oss.sgi.com, jgarzik Cc: torvalds , akpm Message-id: <20050301214438.4653810e.randy.dunlap@verizon.net> Organization: YPO4 MIME-version: 1.0 X-Mailer: Sylpheed version 0.9.12 (GTK+ 1.2.10; i386-vine-linux-gnu) Content-type: text/plain; charset=US-ASCII Content-transfer-encoding: 7bit X-Virus-Scanned: ClamAV 0.83/737/Mon Feb 28 22:22:18 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 2209 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: randy.dunlap@verizon.net Precedence: bulk X-list: netdev tulip/de2104x: some __devinit functions were calling __init functions, made the latter __devinit also; Error: ./drivers/net/tulip/de2104x.o .text refers to 000000000000176d R_X86_64_PC32 .init.text+0xfffffffffffffffc Error: ./drivers/net/tulip/de2104x.o .text refers to 0000000000001798 R_X86_64_PC32 .init.text+0xfffffffffffffffc Signed-off-by: Randy Dunlap diffstat:= drivers/net/tulip/de2104x.c | 8 ++++---- 1 files changed, 4 insertions(+), 4 deletions(-) diff -Naurp ./drivers/net/tulip/de2104x.c~de2104x_sections ./drivers/net/tulip/de2104x.c --- ./drivers/net/tulip/de2104x.c~de2104x_sections 2005-02-27 12:54:05.830037144 -0800 +++ ./drivers/net/tulip/de2104x.c 2005-03-01 21:41:19.354417488 -0800 @@ -1691,7 +1691,7 @@ static struct ethtool_ops de_ethtool_ops .get_regs = de_get_regs, }; -static void __init de21040_get_mac_address (struct de_private *de) +static void __devinit de21040_get_mac_address (struct de_private *de) { unsigned i; @@ -1709,7 +1709,7 @@ static void __init de21040_get_mac_addre } } -static void __init de21040_get_media_info(struct de_private *de) +static void __devinit de21040_get_media_info(struct de_private *de) { unsigned int i; @@ -1736,7 +1736,7 @@ static void __init de21040_get_media_inf } /* Note: this routine returns extra data bits for size detection. */ -static unsigned __init tulip_read_eeprom(void __iomem *regs, int location, int addr_len) +static unsigned __devinit tulip_read_eeprom(void __iomem *regs, int location, int addr_len) { int i; unsigned retval = 0; @@ -1771,7 +1771,7 @@ static unsigned __init tulip_read_eeprom return retval; } -static void __init de21041_get_srom_info (struct de_private *de) +static void __devinit de21041_get_srom_info (struct de_private *de) { unsigned i, sa_offset = 0, ofs; u8 ee_data[DE_EEPROM_SIZE + 6] = {}; --- From jgarzik@pobox.com Tue Mar 1 22:10:14 2005 Received: with ECARTIS (v1.0.0; list netdev); Tue, 01 Mar 2005 22:10:17 -0800 (PST) Received: from parcelfarce.linux.theplanet.co.uk (IDENT:93@parcelfarce.linux.theplanet.co.uk [195.92.249.252]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j226ADXs025464 for ; Tue, 1 Mar 2005 22:10:13 -0800 Received: from [69.134.152.124] (helo=[10.10.10.88]) by parcelfarce.linux.theplanet.co.uk with asmtp (TLSv1:AES256-SHA:256) (Exim 4.33) id 1D6N3i-0001Ms-A3; Wed, 02 Mar 2005 06:10:10 +0000 Message-ID: <422558B2.6020105@pobox.com> Date: Wed, 02 Mar 2005 01:09:54 -0500 From: Jeff Garzik User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.3) Gecko/20040922 X-Accept-Language: en-us, en MIME-Version: 1.0 To: "Randy.Dunlap" CC: netdev@oss.sgi.com, torvalds , akpm Subject: Re: [PATCH] tulip: de2104x, fix init. sections References: <20050301214438.4653810e.randy.dunlap@verizon.net> In-Reply-To: <20050301214438.4653810e.randy.dunlap@verizon.net> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV 0.83/737/Mon Feb 28 22:22:18 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 2210 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: jgarzik@pobox.com Precedence: bulk X-list: netdev Randy.Dunlap wrote: > tulip/de2104x: some __devinit functions were calling __init > functions, made the latter __devinit also; Should go the other way: all the stuff in de2104x should be __init, not __devinit. Nobody ever hotplugs a de2104x. Jeff From jgarzik@pobox.com Tue Mar 1 22:20:55 2005 Received: with ECARTIS (v1.0.0; list netdev); Tue, 01 Mar 2005 22:20:59 -0800 (PST) Received: from parcelfarce.linux.theplanet.co.uk (IDENT:93@parcelfarce.linux.theplanet.co.uk [195.92.249.252]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j226Ks7N026120 for ; Tue, 1 Mar 2005 22:20:55 -0800 Received: from [69.134.152.124] (helo=[10.10.10.88]) by parcelfarce.linux.theplanet.co.uk with asmtp (TLSv1:AES256-SHA:256) (Exim 4.33) id 1D6NE3-0001XV-N9; Wed, 02 Mar 2005 06:20:51 +0000 Message-ID: <42255B34.4070003@pobox.com> Date: Wed, 02 Mar 2005 01:20:36 -0500 From: Jeff Garzik User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.3) Gecko/20040922 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Dale Farnsworth CC: netdev@oss.sgi.com, Ralf Baechle , Manish Lachwani , Brian Waite , "Steven J. Hill" , Benjamin Herrenschmidt , James Chapman Subject: Re: [PATCH] mv643xx: permit VLAN tagged rx packets + minor cleanup References: <20050217224239.GA16609@xyzzy> <20050301000742.GA3163@xyzzy> In-Reply-To: <20050301000742.GA3163@xyzzy> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV 0.83/737/Mon Feb 28 22:22:18 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 2211 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: jgarzik@pobox.com Precedence: bulk X-list: netdev pulled, thanks From jgarzik@pobox.com Tue Mar 1 22:43:21 2005 Received: with ECARTIS (v1.0.0; list netdev); Tue, 01 Mar 2005 22:43:24 -0800 (PST) Received: from parcelfarce.linux.theplanet.co.uk (IDENT:93@parcelfarce.linux.theplanet.co.uk [195.92.249.252]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j226hKpl027079 for ; Tue, 1 Mar 2005 22:43:20 -0800 Received: from [69.134.152.124] (helo=[10.10.10.88]) by parcelfarce.linux.theplanet.co.uk with asmtp (TLSv1:AES256-SHA:256) (Exim 4.33) id 1D6NZm-0001up-3M; Wed, 02 Mar 2005 06:43:18 +0000 Message-ID: <42256078.1040002@pobox.com> Date: Wed, 02 Mar 2005 01:43:04 -0500 From: Jeff Garzik User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.3) Gecko/20040922 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Adrian Bunk CC: Andrew Morton , netdev@oss.sgi.com, linux-kernel@vger.kernel.org Subject: Re: [2.6.11-rc4-mm1 patch] fix buggy IEEE80211_CRYPT_* selects References: <20050223014233.6710fd73.akpm@osdl.org> <20050226113123.GJ3311@stusta.de> In-Reply-To: <20050226113123.GJ3311@stusta.de> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV 0.83/737/Mon Feb 28 22:22:18 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 2212 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: jgarzik@pobox.com Precedence: bulk X-list: netdev Adrian Bunk wrote: > + select CRYPTO > select CRYPTO_AES > ---help--- > Include software based cipher suites in support of IEEE 802.11i > (aka TGi, WPA, WPA2, WPA-PSK, etc.) for use with CCMP enabled > networks. > @@ -54,10 +55,11 @@ > "ieee80211_crypt_ccmp". > > config IEEE80211_CRYPT_TKIP > tristate "IEEE 802.11i TKIP encryption" > depends on IEEE80211 > + select CRYPTO > select CRYPTO_MICHAEL_MIC 'select CRYPTO_AES' should 'select CRYPTO' automatically, I would hope. Jeff From torvalds@osdl.org Tue Mar 1 23:01:04 2005 Received: with ECARTIS (v1.0.0; list netdev); Tue, 01 Mar 2005 23:01:08 -0800 (PST) Received: from smtp.osdl.org (fire.osdl.org [65.172.181.4]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j22714MM028332 for ; Tue, 1 Mar 2005 23:01:04 -0800 Received: from shell0.pdx.osdl.net (fw.osdl.org [65.172.181.6]) by smtp.osdl.org (8.12.8/8.12.8) with ESMTP id j2270vqi031108 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO); Tue, 1 Mar 2005 23:00:58 -0800 Received: from localhost (shell0.pdx.osdl.net [10.9.0.31]) by shell0.pdx.osdl.net (8.13.1/8.11.6) with ESMTP id j2270tOH024735; Tue, 1 Mar 2005 23:00:57 -0800 Date: Tue, 1 Mar 2005 23:02:16 -0800 (PST) From: Linus Torvalds To: Jeff Garzik cc: "Randy.Dunlap" , netdev@oss.sgi.com, akpm Subject: Re: [PATCH] tulip: de2104x, fix init. sections In-Reply-To: <422558B2.6020105@pobox.com> Message-ID: References: <20050301214438.4653810e.randy.dunlap@verizon.net> <422558B2.6020105@pobox.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Received-SPF: pass (domain of torvalds@osdl.org designates 65.172.181.6 as permitted sender) X-MIMEDefang-Filter: osdl$Revision: 1.104 $ X-Scanned-By: MIMEDefang 2.36 X-Virus-Scanned: ClamAV 0.83/737/Mon Feb 28 22:22:18 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 2213 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: torvalds@osdl.org Precedence: bulk X-list: netdev On Wed, 2 Mar 2005, Jeff Garzik wrote: > > Nobody ever hotplugs a de2104x. Are you sure? I'm pretty certain some of the Cardbus cards are based on that chipset. In fact, I'm pretty sure that's exactly that I used to have (and actually used when I did the "CardBus as a real PCI bridge" stuff). CardBus tulip network cards may be less interesting these days, but I'd be surprised if they are all gone. The tulip chip used to be the most common one. (And don't be fooled by the Xircom config stuff - those have a special driver partly because Xircom did something wrong, and probably partly because the old PCMCIA layer just was too damn confused, and thought that CardBus devices needed something else than a PCI driver. Most tulip cardbus cards used just the bog-standard tulip driver after my Cardbus rewrite, I do believe). Linus From garzik@havoc.gtf.org Tue Mar 1 23:03:38 2005 Received: with ECARTIS (v1.0.0; list netdev); Tue, 01 Mar 2005 23:03:43 -0800 (PST) Received: from bastet.signetmail.com (atlmail.prod.rxgsys.com [64.74.124.160]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j2273asU028801 for ; Tue, 1 Mar 2005 23:03:38 -0800 Received: from localhost (localhost.localdomain [127.0.0.1]) by bastet.signetmail.com (RXG Elite Mail Server) with ESMTP id 7CD87A881F; Wed, 2 Mar 2005 01:58:18 -0500 (EST) Received: from bastet.signetmail.com ([127.0.0.1]) by localhost (atlmail.prod.rxgsys.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 31804-09; Wed, 2 Mar 2005 01:58:16 -0500 (EST) Received: from havoc.gtf.org (havoc.gtf.org [63.115.148.101]) by bastet.signetmail.com (RXG Elite Mail Server) with ESMTP id 2CCAEA8819; Wed, 2 Mar 2005 01:58:13 -0500 (EST) Received: from havoc.gtf.org (havoc.gtf.org [127.0.0.1]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by havoc.gtf.org (Postfix) with ESMTP id 1ACC61C0A859; Wed, 2 Mar 2005 02:03:26 -0500 (EST) Received: (from garzik@localhost) by havoc.gtf.org (8.13.1/8.13.1/Submit) id j2273PHX019672; Wed, 2 Mar 2005 02:03:25 -0500 Date: Wed, 2 Mar 2005 02:03:25 -0500 From: Jeff Garzik To: Linus Torvalds Cc: "Randy.Dunlap" , netdev@oss.sgi.com, akpm Subject: Re: [PATCH] tulip: de2104x, fix init. sections Message-ID: <20050302070325.GA19643@havoc.gtf.org> References: <20050301214438.4653810e.randy.dunlap@verizon.net> <422558B2.6020105@pobox.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.1i X-Virus-Scanned: ClamAV 0.83/737/Mon Feb 28 22:22:18 2005 on oss.sgi.com X-Virus-Scanned: by EMS at localhost.localdomain X-Virus-Status: Clean X-archive-position: 2214 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: jgarzik@pobox.com Precedence: bulk X-list: netdev On Tue, Mar 01, 2005 at 11:02:16PM -0800, Linus Torvalds wrote: > > > On Wed, 2 Mar 2005, Jeff Garzik wrote: > > > > Nobody ever hotplugs a de2104x. > > Are you sure? I'm pretty certain some of the Cardbus cards are based on > that chipset. In fact, I'm pretty sure that's exactly that I used to have > (and actually used when I did the "CardBus as a real PCI bridge" stuff). Nope -- You are thinking of the 2114x stuff. You even bought me a cardbus card of my own to get things going on that, way back when. :) 2104x is truly ancient. Jeff From torvalds@osdl.org Tue Mar 1 23:13:06 2005 Received: with ECARTIS (v1.0.0; list netdev); Tue, 01 Mar 2005 23:13:12 -0800 (PST) Received: from smtp.osdl.org (fire.osdl.org [65.172.181.4]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j227D6wd029576 for ; Tue, 1 Mar 2005 23:13:06 -0800 Received: from shell0.pdx.osdl.net (fw.osdl.org [65.172.181.6]) by smtp.osdl.org (8.12.8/8.12.8) with ESMTP id j227D0qi031964 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO); Tue, 1 Mar 2005 23:13:00 -0800 Received: from localhost (shell0.pdx.osdl.net [10.9.0.31]) by shell0.pdx.osdl.net (8.13.1/8.11.6) with ESMTP id j227CxBn025050; Tue, 1 Mar 2005 23:12:59 -0800 Date: Tue, 1 Mar 2005 23:14:20 -0800 (PST) From: Linus Torvalds To: Jeff Garzik cc: "Randy.Dunlap" , netdev@oss.sgi.com, akpm Subject: Re: [PATCH] tulip: de2104x, fix init. sections In-Reply-To: <20050302070325.GA19643@havoc.gtf.org> Message-ID: References: <20050301214438.4653810e.randy.dunlap@verizon.net> <422558B2.6020105@pobox.com> <20050302070325.GA19643@havoc.gtf.org> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Received-SPF: pass (domain of torvalds@osdl.org designates 65.172.181.6 as permitted sender) X-MIMEDefang-Filter: osdl$Revision: 1.104 $ X-Scanned-By: MIMEDefang 2.36 X-Virus-Scanned: ClamAV 0.83/737/Mon Feb 28 22:22:18 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 2215 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: torvalds@osdl.org Precedence: bulk X-list: netdev On Wed, 2 Mar 2005, Jeff Garzik wrote: > > Nope -- You are thinking of the 2114x stuff. You even bought me a > cardbus card of my own to get things going on that, way back when. :) > > 2104x is truly ancient. Ahh, ok. Goodie. Linus From SRS0+a2f250e0592827ba527c+556+infradead.org+hch@pentafluge.srs.infradead.org Tue Mar 1 23:25:15 2005 Received: with ECARTIS (v1.0.0; list netdev); Tue, 01 Mar 2005 23:25:18 -0800 (PST) Received: from pentafluge.infradead.org (pentafluge.infradead.org [213.146.154.40]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j227PEWU030221 for ; Tue, 1 Mar 2005 23:25:15 -0800 Received: from hch by pentafluge.infradead.org with local (Exim 4.43 #1 (Red Hat Linux)) id 1D6OEI-0003JK-Jz; Wed, 02 Mar 2005 07:25:10 +0000 Date: Wed, 2 Mar 2005 07:25:10 +0000 From: Christoph Hellwig To: Jeff Garzik Cc: "Randy.Dunlap" , netdev@oss.sgi.com, torvalds , akpm Subject: Re: [PATCH] tulip: de2104x, fix init. sections Message-ID: <20050302072510.GA12464@infradead.org> References: <20050301214438.4653810e.randy.dunlap@verizon.net> <422558B2.6020105@pobox.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <422558B2.6020105@pobox.com> User-Agent: Mutt/1.4.1i X-SRS-Rewrite: SMTP reverse-path rewritten from by pentafluge.infradead.org See http://www.infradead.org/rpr.html X-Virus-Scanned: ClamAV 0.83/737/Mon Feb 28 22:22:18 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 2216 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: hch@infradead.org Precedence: bulk X-list: netdev On Wed, Mar 02, 2005 at 01:09:54AM -0500, Jeff Garzik wrote: > Randy.Dunlap wrote: > >tulip/de2104x: some __devinit functions were calling __init > > functions, made the latter __devinit also; > > Should go the other way: all the stuff in de2104x should be __init, not > __devinit. > > Nobody ever hotplugs a de2104x. How comes that you want to dictate what cards I put into my hotplug PCI slots? From jgarzik@pobox.com Tue Mar 1 23:30:32 2005 Received: with ECARTIS (v1.0.0; list netdev); Tue, 01 Mar 2005 23:30:36 -0800 (PST) Received: from parcelfarce.linux.theplanet.co.uk (IDENT:93@parcelfarce.linux.theplanet.co.uk [195.92.249.252]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j227UV7e030786 for ; Tue, 1 Mar 2005 23:30:32 -0800 Received: from [69.134.152.124] (helo=[10.10.10.88]) by parcelfarce.linux.theplanet.co.uk with asmtp (TLSv1:AES256-SHA:256) (Exim 4.33) id 1D6OJS-0004dq-HL; Wed, 02 Mar 2005 07:30:30 +0000 Message-ID: <42256B89.2000104@pobox.com> Date: Wed, 02 Mar 2005 02:30:17 -0500 From: Jeff Garzik User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.3) Gecko/20040922 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Christoph Hellwig CC: "Randy.Dunlap" , netdev@oss.sgi.com, torvalds , akpm Subject: Re: [PATCH] tulip: de2104x, fix init. sections References: <20050301214438.4653810e.randy.dunlap@verizon.net> <422558B2.6020105@pobox.com> <20050302072510.GA12464@infradead.org> In-Reply-To: <20050302072510.GA12464@infradead.org> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV 0.83/737/Mon Feb 28 22:22:18 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 2217 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: jgarzik@pobox.com Precedence: bulk X-list: netdev Christoph Hellwig wrote: > On Wed, Mar 02, 2005 at 01:09:54AM -0500, Jeff Garzik wrote: > >>Randy.Dunlap wrote: >> >>>tulip/de2104x: some __devinit functions were calling __init >>> functions, made the latter __devinit also; >> >>Should go the other way: all the stuff in de2104x should be __init, not >>__devinit. >> >>Nobody ever hotplugs a de2104x. > > > How comes that you want to dictate what cards I put into my hotplug > PCI slots? When someone proves this is possible, I will accept the code change. I doubt this will ever happen, for two reasons: 1) Hotplug PCI slots are highly likely to choke on the 2104x's very early and slightly weird PCI hardware implementation. 2) It's an ancient card and nobody will ever bother trying to hotplug it. Jeff From SRS0+a2f250e0592827ba527c+556+infradead.org+hch@pentafluge.srs.infradead.org Tue Mar 1 23:32:59 2005 Received: with ECARTIS (v1.0.0; list netdev); Tue, 01 Mar 2005 23:33:02 -0800 (PST) Received: from pentafluge.infradead.org (pentafluge.infradead.org [213.146.154.40]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j227WubU031352 for ; Tue, 1 Mar 2005 23:32:59 -0800 Received: from hch by pentafluge.infradead.org with local (Exim 4.43 #1 (Red Hat Linux)) id 1D6OLn-0003Lq-GW; Wed, 02 Mar 2005 07:32:55 +0000 Date: Wed, 2 Mar 2005 07:32:55 +0000 From: Christoph Hellwig To: Jeff Garzik Cc: Christoph Hellwig , "Randy.Dunlap" , netdev@oss.sgi.com, torvalds , akpm Subject: Re: [PATCH] tulip: de2104x, fix init. sections Message-ID: <20050302073255.GA12859@infradead.org> References: <20050301214438.4653810e.randy.dunlap@verizon.net> <422558B2.6020105@pobox.com> <20050302072510.GA12464@infradead.org> <42256B89.2000104@pobox.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <42256B89.2000104@pobox.com> User-Agent: Mutt/1.4.1i X-SRS-Rewrite: SMTP reverse-path rewritten from by pentafluge.infradead.org See http://www.infradead.org/rpr.html X-Virus-Scanned: ClamAV 0.83/737/Mon Feb 28 22:22:18 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 2218 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: hch@infradead.org Precedence: bulk X-list: netdev On Wed, Mar 02, 2005 at 02:30:17AM -0500, Jeff Garzik wrote: > When someone proves this is possible, I will accept the code change. I > doubt this will ever happen, for two reasons: > > 1) Hotplug PCI slots are highly likely to choke on the 2104x's very > early and slightly weird PCI hardware implementation. > > 2) It's an ancient card and nobody will ever bother trying to hotplug it. No, it's a matter of correctness. The pci core can call ->probe all the time and every driver must be prepared. Even if no one tries it physically it's easily done with Greg's fake hotplug driver. From jgarzik@pobox.com Tue Mar 1 23:37:41 2005 Received: with ECARTIS (v1.0.0; list netdev); Tue, 01 Mar 2005 23:37:45 -0800 (PST) Received: from parcelfarce.linux.theplanet.co.uk (IDENT:93@parcelfarce.linux.theplanet.co.uk [195.92.249.252]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j227beA1031991 for ; Tue, 1 Mar 2005 23:37:40 -0800 Received: from [69.134.152.124] (helo=[10.10.10.88]) by parcelfarce.linux.theplanet.co.uk with asmtp (TLSv1:AES256-SHA:256) (Exim 4.33) id 1D6OQN-00057I-B1; Wed, 02 Mar 2005 07:37:39 +0000 Message-ID: <42256D35.10602@pobox.com> Date: Wed, 02 Mar 2005 02:37:25 -0500 From: Jeff Garzik User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.3) Gecko/20040922 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Christoph Hellwig CC: "Randy.Dunlap" , netdev@oss.sgi.com, torvalds , akpm Subject: Re: [PATCH] tulip: de2104x, fix init. sections References: <20050301214438.4653810e.randy.dunlap@verizon.net> <422558B2.6020105@pobox.com> <20050302072510.GA12464@infradead.org> <42256B89.2000104@pobox.com> <20050302073255.GA12859@infradead.org> In-Reply-To: <20050302073255.GA12859@infradead.org> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV 0.83/737/Mon Feb 28 22:22:18 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 2219 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: jgarzik@pobox.com Precedence: bulk X-list: netdev Christoph Hellwig wrote: > On Wed, Mar 02, 2005 at 02:30:17AM -0500, Jeff Garzik wrote: > >>When someone proves this is possible, I will accept the code change. I >>doubt this will ever happen, for two reasons: >> >>1) Hotplug PCI slots are highly likely to choke on the 2104x's very >>early and slightly weird PCI hardware implementation. >> >>2) It's an ancient card and nobody will ever bother trying to hotplug it. > > > No, it's a matter of correctness. The pci core can call ->probe all the > time and every driver must be prepared. Even if no one tries it physically > it's easily done with Greg's fake hotplug driver. The change can be made when it's actually useful to someone. Making janitors and Christoph happy is not a good enough reason in my book. Jeff From jgarzik@pobox.com Tue Mar 1 23:41:59 2005 Received: with ECARTIS (v1.0.0; list netdev); Tue, 01 Mar 2005 23:42:37 -0800 (PST) Received: from parcelfarce.linux.theplanet.co.uk (IDENT:93@parcelfarce.linux.theplanet.co.uk [195.92.249.252]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j227fwbu032592 for ; Tue, 1 Mar 2005 23:41:58 -0800 Received: from [69.134.152.124] (helo=[10.10.10.88]) by parcelfarce.linux.theplanet.co.uk with asmtp (TLSv1:AES256-SHA:256) (Exim 4.33) id 1D6OUT-0005Dl-VP; Wed, 02 Mar 2005 07:41:54 +0000 Message-ID: <42256E2B.2040807@pobox.com> Date: Wed, 02 Mar 2005 02:41:31 -0500 From: Jeff Garzik User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.3) Gecko/20040922 X-Accept-Language: en-us, en MIME-Version: 1.0 To: netdev@oss.sgi.com CC: Christoph Hellwig , "Randy.Dunlap" , torvalds , akpm Subject: Re: [PATCH] tulip: de2104x, fix init. sections References: <20050301214438.4653810e.randy.dunlap@verizon.net> <422558B2.6020105@pobox.com> <20050302072510.GA12464@infradead.org> <42256B89.2000104@pobox.com> <20050302073255.GA12859@infradead.org> In-Reply-To: <20050302073255.GA12859@infradead.org> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV 0.83/737/Mon Feb 28 22:22:18 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 2220 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: jgarzik@pobox.com Precedence: bulk X-list: netdev For what it's worth, I'm not just being obstinate :) I build this driver in hotplug kernels, and I know it will never be hotplugged. In other words, I like it like that. Jeff From jgarzik@pobox.com Wed Mar 2 00:28:20 2005 Received: with ECARTIS (v1.0.0; list netdev); Wed, 02 Mar 2005 00:28:27 -0800 (PST) Received: from parcelfarce.linux.theplanet.co.uk (IDENT:93@parcelfarce.linux.theplanet.co.uk [195.92.249.252]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j228SI1g005634 for ; Wed, 2 Mar 2005 00:28:18 -0800 Received: from [69.134.152.124] (helo=[10.10.10.88]) by parcelfarce.linux.theplanet.co.uk with asmtp (TLSv1:AES256-SHA:256) (Exim 4.33) id 1D6PDM-0006Ei-A2; Wed, 02 Mar 2005 08:28:17 +0000 Message-ID: <4225790C.8030104@pobox.com> Date: Wed, 02 Mar 2005 03:27:56 -0500 From: Jeff Garzik User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.3) Gecko/20040922 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Andrew Morton , Linus Torvalds CC: Netdev Subject: [BK PATCHES] (resend) e1000, ixgb fixes Content-Type: multipart/mixed; boundary="------------030204050700050303050609" X-Virus-Scanned: ClamAV 0.83/737/Mon Feb 28 22:22:18 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 2221 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: jgarzik@pobox.com Precedence: bulk X-list: netdev This is a multi-part message in MIME format. --------------030204050700050303050609 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit See attached. No update other than pulling 2.6.11-final into the repo. --------------030204050700050303050609 Content-Type: text/plain; name="changelog.txt" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="changelog.txt" Please do a bk pull bk://gkernel.bkbits.net/net-drivers-2.6 This will update the following files: drivers/net/e1000/e1000.h | 3 drivers/net/e1000/e1000_ethtool.c | 11 - drivers/net/e1000/e1000_hw.c | 86 ++++++------- drivers/net/e1000/e1000_hw.h | 11 + drivers/net/e1000/e1000_main.c | 249 ++++++++++++++++++++++++++++++++++---- drivers/net/ixgb/ixgb.h | 3 drivers/net/ixgb/ixgb_ee.c | 16 +- drivers/net/ixgb/ixgb_ee.h | 3 drivers/net/ixgb/ixgb_ethtool.c | 5 drivers/net/ixgb/ixgb_hw.c | 2 drivers/net/ixgb/ixgb_hw.h | 2 drivers/net/ixgb/ixgb_ids.h | 2 drivers/net/ixgb/ixgb_main.c | 73 ++++++----- drivers/net/ixgb/ixgb_osdep.h | 2 drivers/net/ixgb/ixgb_param.c | 2 15 files changed, 354 insertions(+), 116 deletions(-) through these ChangeSets: : o e1000: Driver version white space, o e1000: Fixes related to Cable length o e1000: Report failure code when loopback o e1000: Checks for desc ring/rx data o e1000: Patch from Peter Kjellstroem -- o e1000: Fix WOL settings in 82544 based o e1000: Delay clean-up of last Tx buffer o e1000: Avoid race between e1000_watchdog o e1000: use netif_poll_{enable|disable} o e1000: Robert Olsson's fix and refinement o ixgb: Driver version, white space, other stuff o ixgb: Invalidate software cache, when EEPROM write occurs o ixgb: Robert Olsson's fix and refinement to poll o ixgb: Avoid race e1000_watchdog and ixgb_clean_tx_irq o ixgb: use netif_poll_{enable|disable} --------------030204050700050303050609 Content-Type: text/plain; name="patch" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="patch" diff -Nru a/drivers/net/e1000/e1000.h b/drivers/net/e1000/e1000.h --- a/drivers/net/e1000/e1000.h 2005-03-02 03:25:39 -05:00 +++ b/drivers/net/e1000/e1000.h 2005-03-02 03:25:39 -05:00 @@ -138,6 +138,7 @@ #define E1000_RX_BUFFER_WRITE 16 /* Must be power of 2 */ #define AUTO_ALL_MODES 0 +#define E1000_EEPROM_82544_APM 0x0004 #define E1000_EEPROM_APME 0x0400 #ifndef E1000_MASTER_SLAVE @@ -209,6 +210,7 @@ /* TX */ struct e1000_desc_ring tx_ring; + struct e1000_buffer previous_buffer_info; spinlock_t tx_lock; uint32_t txd_cmd; uint32_t tx_int_delay; @@ -222,6 +224,7 @@ uint32_t tx_fifo_size; atomic_t tx_fifo_stall; boolean_t pcix_82544; + boolean_t detect_tx_hung; /* RX */ struct e1000_desc_ring rx_ring; diff -Nru a/drivers/net/e1000/e1000_ethtool.c b/drivers/net/e1000/e1000_ethtool.c --- a/drivers/net/e1000/e1000_ethtool.c 2005-03-02 03:25:39 -05:00 +++ b/drivers/net/e1000/e1000_ethtool.c 2005-03-02 03:25:39 -05:00 @@ -1310,7 +1310,7 @@ struct e1000_desc_ring *txdr = &adapter->test_tx_ring; struct e1000_desc_ring *rxdr = &adapter->test_rx_ring; struct pci_dev *pdev = adapter->pdev; - int i; + int i, ret_val; E1000_WRITE_REG(&adapter->hw, RDT, rxdr->count - 1); @@ -1330,11 +1330,12 @@ rxdr->buffer_info[i].length, PCI_DMA_FROMDEVICE); - if (!e1000_check_lbtest_frame(rxdr->buffer_info[i++].skb, 1024)) - return 0; - } while (i < 64); + ret_val = e1000_check_lbtest_frame(rxdr->buffer_info[i].skb, + 1024); + i++; + } while (ret_val != 0 && i < 64); - return 13; + return ret_val; } static int diff -Nru a/drivers/net/e1000/e1000_hw.c b/drivers/net/e1000/e1000_hw.c --- a/drivers/net/e1000/e1000_hw.c 2005-03-02 03:25:39 -05:00 +++ b/drivers/net/e1000/e1000_hw.c 2005-03-02 03:25:39 -05:00 @@ -1572,7 +1572,8 @@ if(mii_status_reg & MII_SR_LINK_STATUS) break; msec_delay(100); } - if((i == 0) && (hw->phy_type == e1000_phy_m88)) { + if((i == 0) && + (hw->phy_type == e1000_phy_m88)) { /* We didn't get link. Reset the DSP and wait again for link. */ ret_val = e1000_phy_reset_dsp(hw); if(ret_val) { @@ -2503,7 +2504,7 @@ } } - ret_val = e1000_read_phy_reg_ex(hw, IGP01E1000_PHY_PAGE_SELECT & reg_addr, + ret_val = e1000_read_phy_reg_ex(hw, MAX_PHY_REG_ADDRESS & reg_addr, phy_data); return ret_val; @@ -2609,7 +2610,7 @@ } } - ret_val = e1000_write_phy_reg_ex(hw, IGP01E1000_PHY_PAGE_SELECT & reg_addr, + ret_val = e1000_write_phy_reg_ex(hw, MAX_PHY_REG_ADDRESS & reg_addr, phy_data); return ret_val; @@ -2955,8 +2956,7 @@ /* Check polarity status */ ret_val = e1000_check_polarity(hw, &polarity); if(ret_val) - return ret_val; - + return ret_val; phy_info->cable_polarity = polarity; ret_val = e1000_read_phy_reg(hw, M88E1000_PHY_SPEC_STATUS, &phy_data); @@ -2966,9 +2966,9 @@ phy_info->mdix_mode = (phy_data & M88E1000_PSSR_MDIX) >> M88E1000_PSSR_MDIX_SHIFT; - if(phy_data & M88E1000_PSSR_1000MBS) { - /* Cable Length Estimation and Local/Remote Receiver Informatoion - * are only valid at 1000 Mbps + if ((phy_data & M88E1000_PSSR_SPEED) == M88E1000_PSSR_1000MBS) { + /* Cable Length Estimation and Local/Remote Receiver Information + * are only valid at 1000 Mbps. */ phy_info->cable_length = ((phy_data & M88E1000_PSSR_CABLE_LENGTH) >> M88E1000_PSSR_CABLE_LENGTH_SHIFT); @@ -4639,41 +4639,44 @@ { uint32_t status; - if(hw->mac_type < e1000_82543) { + switch (hw->mac_type) { + case e1000_82542_rev2_0: + case e1000_82542_rev2_1: hw->bus_type = e1000_bus_type_unknown; hw->bus_speed = e1000_bus_speed_unknown; hw->bus_width = e1000_bus_width_unknown; - return; - } - - status = E1000_READ_REG(hw, STATUS); - hw->bus_type = (status & E1000_STATUS_PCIX_MODE) ? - e1000_bus_type_pcix : e1000_bus_type_pci; + break; + default: + status = E1000_READ_REG(hw, STATUS); + hw->bus_type = (status & E1000_STATUS_PCIX_MODE) ? + e1000_bus_type_pcix : e1000_bus_type_pci; - if(hw->device_id == E1000_DEV_ID_82546EB_QUAD_COPPER) { - hw->bus_speed = (hw->bus_type == e1000_bus_type_pci) ? - e1000_bus_speed_66 : e1000_bus_speed_120; - } else if(hw->bus_type == e1000_bus_type_pci) { - hw->bus_speed = (status & E1000_STATUS_PCI66) ? - e1000_bus_speed_66 : e1000_bus_speed_33; - } else { - switch (status & E1000_STATUS_PCIX_SPEED) { - case E1000_STATUS_PCIX_SPEED_66: - hw->bus_speed = e1000_bus_speed_66; - break; - case E1000_STATUS_PCIX_SPEED_100: - hw->bus_speed = e1000_bus_speed_100; - break; - case E1000_STATUS_PCIX_SPEED_133: - hw->bus_speed = e1000_bus_speed_133; - break; - default: - hw->bus_speed = e1000_bus_speed_reserved; - break; + if(hw->device_id == E1000_DEV_ID_82546EB_QUAD_COPPER) { + hw->bus_speed = (hw->bus_type == e1000_bus_type_pci) ? + e1000_bus_speed_66 : e1000_bus_speed_120; + } else if(hw->bus_type == e1000_bus_type_pci) { + hw->bus_speed = (status & E1000_STATUS_PCI66) ? + e1000_bus_speed_66 : e1000_bus_speed_33; + } else { + switch (status & E1000_STATUS_PCIX_SPEED) { + case E1000_STATUS_PCIX_SPEED_66: + hw->bus_speed = e1000_bus_speed_66; + break; + case E1000_STATUS_PCIX_SPEED_100: + hw->bus_speed = e1000_bus_speed_100; + break; + case E1000_STATUS_PCIX_SPEED_133: + hw->bus_speed = e1000_bus_speed_133; + break; + default: + hw->bus_speed = e1000_bus_speed_reserved; + break; + } } + hw->bus_width = (status & E1000_STATUS_BUS64) ? + e1000_bus_width_64 : e1000_bus_width_32; + break; } - hw->bus_width = (status & E1000_STATUS_BUS64) ? - e1000_bus_width_64 : e1000_bus_width_32; } /****************************************************************************** * Reads a value from one of the devices registers using port I/O (as opposed @@ -4738,6 +4741,7 @@ uint16_t agc_value = 0; uint16_t cur_agc, min_agc = IGP01E1000_AGC_LENGTH_TABLE_SIZE; uint16_t i, phy_data; + uint16_t cable_length; DEBUGFUNC("e1000_get_cable_length"); @@ -4749,10 +4753,11 @@ &phy_data); if(ret_val) return ret_val; + cable_length = (phy_data & M88E1000_PSSR_CABLE_LENGTH) >> + M88E1000_PSSR_CABLE_LENGTH_SHIFT; /* Convert the enum value to ranged values */ - switch((phy_data & M88E1000_PSSR_CABLE_LENGTH) >> - M88E1000_PSSR_CABLE_LENGTH_SHIFT) { + switch (cable_length) { case e1000_cable_length_50: *min_length = 0; *max_length = e1000_igp_cable_length_50; @@ -4919,8 +4924,7 @@ return ret_val; hw->speed_downgraded = (phy_data & IGP01E1000_PLHR_SS_DOWNGRADE) ? 1 : 0; - } - else if(hw->phy_type == e1000_phy_m88) { + } else if(hw->phy_type == e1000_phy_m88) { ret_val = e1000_read_phy_reg(hw, M88E1000_PHY_SPEC_STATUS, &phy_data); if(ret_val) diff -Nru a/drivers/net/e1000/e1000_hw.h b/drivers/net/e1000/e1000_hw.h --- a/drivers/net/e1000/e1000_hw.h 2005-03-02 03:25:39 -05:00 +++ b/drivers/net/e1000/e1000_hw.h 2005-03-02 03:25:39 -05:00 @@ -369,6 +369,7 @@ #define E1000_DEV_ID_82546GB_SERDES 0x107B #define E1000_DEV_ID_82546GB_PCIE 0x108A #define E1000_DEV_ID_82547EI 0x1019 + #define NODE_ADDRESS_SIZE 6 #define ETH_LENGTH_OF_ADDRESS 6 @@ -1734,6 +1735,9 @@ #define PHY_1000T_STATUS 0x0A /* 1000Base-T Status Reg */ #define PHY_EXT_STATUS 0x0F /* Extended Status Reg */ +#define MAX_PHY_REG_ADDRESS 0x1F /* 5 bit address bus (0-0x1F) */ +#define MAX_PHY_MULTI_PAGE_REG 0xF /* Registers equal on all pages */ + /* M88E1000 Specific Registers */ #define M88E1000_PHY_SPEC_CTRL 0x10 /* PHY Specific Control Register */ #define M88E1000_PHY_SPEC_STATUS 0x11 /* PHY Specific Status Register */ @@ -1794,8 +1798,7 @@ #define IGP01E1000_ANALOG_REGS_PAGE 0x20C0 -#define MAX_PHY_REG_ADDRESS 0x1F /* 5 bit address bus (0-0x1F) */ -#define MAX_PHY_MULTI_PAGE_REG 0xF /*Registers that are equal on all pages*/ + /* PHY Control Register */ #define MII_CR_SPEED_SELECT_MSB 0x0040 /* bits 6,13: 10=1000, 01=100, 00=10 */ #define MII_CR_COLL_TEST_ENABLE 0x0080 /* Collision test enable */ @@ -2098,7 +2101,11 @@ #define IGP01E1000_ANALOG_FUSE_FINE_1 0x0080 #define IGP01E1000_ANALOG_FUSE_FINE_10 0x0500 + /* Bit definitions for valid PHY IDs. */ +/* I = Integrated + * E = External + */ #define M88E1000_E_PHY_ID 0x01410C50 #define M88E1000_I_PHY_ID 0x01410C30 #define M88E1011_I_PHY_ID 0x01410C20 diff -Nru a/drivers/net/e1000/e1000_main.c b/drivers/net/e1000/e1000_main.c --- a/drivers/net/e1000/e1000_main.c 2005-03-02 03:25:39 -05:00 +++ b/drivers/net/e1000/e1000_main.c 2005-03-02 03:25:39 -05:00 @@ -35,6 +35,14 @@ * - More errlogging support from Jon Mason * - Fix TSO issues on PPC64 machines -- Jon Mason * + * 5.7.1 12/16/04 + * - Resurrect 82547EI/GI related fix in e1000_intr to avoid deadlocks. This + * fix was removed as it caused system instability. The suspected cause of + * this is the called to e1000_irq_disable in e1000_intr. Inlined the + * required piece of e1000_irq_disable into e1000_intr - Anton Blanchard + * 5.7.0 12/10/04 + * - include fix to the condition that determines when to quit NAPI - Robert Olsson + * - use netif_poll_{disable/enable} to synchronize between NAPI and i/f up/down * 5.6.5 11/01/04 * - Enabling NETIF_F_SG without checksum offload is illegal - John Mason @@ -57,7 +65,7 @@ #else #define DRIVERNAPI "-NAPI" #endif -char e1000_driver_version[] = "5.6.10.1-k2"DRIVERNAPI; +char e1000_driver_version[] = "5.7.6-k2"DRIVERNAPI; char e1000_copyright[] = "Copyright (c) 1999-2004 Intel Corporation."; /* e1000_pci_tbl - PCI Device ID Table @@ -81,6 +89,7 @@ INTEL_E1000_ETHERNET_DEVICE(0x1011), INTEL_E1000_ETHERNET_DEVICE(0x1012), INTEL_E1000_ETHERNET_DEVICE(0x1013), + INTEL_E1000_ETHERNET_DEVICE(0x1014), INTEL_E1000_ETHERNET_DEVICE(0x1015), INTEL_E1000_ETHERNET_DEVICE(0x1016), INTEL_E1000_ETHERNET_DEVICE(0x1017), @@ -308,6 +317,9 @@ mod_timer(&adapter->watchdog_timer, jiffies); e1000_irq_enable(adapter); +#ifdef CONFIG_E1000_NAPI + netif_poll_enable(netdev); +#endif return 0; } @@ -321,6 +333,10 @@ del_timer_sync(&adapter->tx_fifo_stall_timer); del_timer_sync(&adapter->watchdog_timer); del_timer_sync(&adapter->phy_info_timer); + +#ifdef CONFIG_E1000_NAPI + netif_poll_disable(netdev); +#endif adapter->link_speed = 0; adapter->link_duplex = 0; netif_carrier_off(netdev); @@ -414,6 +430,7 @@ int i; int err; uint16_t eeprom_data; + uint16_t eeprom_apme_mask = E1000_EEPROM_APME; if((err = pci_enable_device(pdev))) return err; @@ -510,9 +527,6 @@ } #ifdef NETIF_F_TSO - /* Disbaled for now until root-cause is found for - * hangs reported against non-IA archs. TSO can be - * enabled using ethtool -K eth tso on */ if((adapter->hw.mac_type >= e1000_82544) && (adapter->hw.mac_type != e1000_82547)) netdev->features |= NETIF_F_TSO; @@ -584,6 +598,11 @@ case e1000_82542_rev2_1: case e1000_82543: break; + case e1000_82544: + e1000_read_eeprom(&adapter->hw, + EEPROM_INIT_CONTROL2_REG, 1, &eeprom_data); + eeprom_apme_mask = E1000_EEPROM_82544_APM; + break; case e1000_82546: case e1000_82546_rev_3: if((E1000_READ_REG(&adapter->hw, STATUS) & E1000_STATUS_FUNC_1) @@ -598,7 +617,7 @@ EEPROM_INIT_CONTROL3_PORT_A, 1, &eeprom_data); break; } - if(eeprom_data & E1000_EEPROM_APME) + if(eeprom_data & eeprom_apme_mask) adapter->wol |= E1000_WUFC_MAG; /* reset the hardware with the new settings */ @@ -807,6 +826,31 @@ } /** + * e1000_check_64k_bound - check that memory doesn't cross 64kB boundary + * @adapter: address of board private structure + * @begin: address of beginning of memory + * @end: address of end of memory + **/ +static inline boolean_t +e1000_check_64k_bound(struct e1000_adapter *adapter, + void *start, unsigned long len) +{ + unsigned long begin = (unsigned long) start; + unsigned long end = begin + len; + + /* first rev 82545 and 82546 need to not allow any memory + * write location to cross a 64k boundary due to errata 23 */ + if (adapter->hw.mac_type == e1000_82545 || + adapter->hw.mac_type == e1000_82546 ) { + + /* check buffer doesn't cross 64kB */ + return ((begin ^ (end - 1)) >> 16) != 0 ? FALSE : TRUE; + } + + return TRUE; +} + +/** * e1000_setup_tx_resources - allocate Tx resources (Descriptors) * @adapter: board private structure * @@ -824,7 +868,7 @@ txdr->buffer_info = vmalloc(size); if(!txdr->buffer_info) { DPRINTK(PROBE, ERR, - "Unble to Allocate Memory for the Transmit descriptor ring\n"); + "Unable to Allocate Memory for the Transmit descriptor ring\n"); return -ENOMEM; } memset(txdr->buffer_info, 0, size); @@ -836,11 +880,42 @@ txdr->desc = pci_alloc_consistent(pdev, txdr->size, &txdr->dma); if(!txdr->desc) { +setup_tx_desc_die: DPRINTK(PROBE, ERR, - "Unble to Allocate Memory for the Transmit descriptor ring\n"); + "Unable to Allocate Memory for the Transmit descriptor ring\n"); vfree(txdr->buffer_info); return -ENOMEM; } + + /* fix for errata 23, cant cross 64kB boundary */ + if (!e1000_check_64k_bound(adapter, txdr->desc, txdr->size)) { + void *olddesc = txdr->desc; + dma_addr_t olddma = txdr->dma; + DPRINTK(TX_ERR,ERR,"txdr align check failed: %u bytes at %p\n", + txdr->size, txdr->desc); + /* try again, without freeing the previous */ + txdr->desc = pci_alloc_consistent(pdev, txdr->size, &txdr->dma); + /* failed allocation, critial failure */ + if(!txdr->desc) { + pci_free_consistent(pdev, txdr->size, olddesc, olddma); + goto setup_tx_desc_die; + } + + if (!e1000_check_64k_bound(adapter, txdr->desc, txdr->size)) { + /* give up */ + pci_free_consistent(pdev, txdr->size, + txdr->desc, txdr->dma); + pci_free_consistent(pdev, txdr->size, olddesc, olddma); + DPRINTK(PROBE, ERR, + "Unable to Allocate aligned Memory for the Transmit" + " descriptor ring\n"); + vfree(txdr->buffer_info); + return -ENOMEM; + } else { + /* free old, move on with the new one since its okay */ + pci_free_consistent(pdev, txdr->size, olddesc, olddma); + } + } memset(txdr->desc, 0, txdr->size); txdr->next_to_use = 0; @@ -945,7 +1020,7 @@ rxdr->buffer_info = vmalloc(size); if(!rxdr->buffer_info) { DPRINTK(PROBE, ERR, - "Unble to Allocate Memory for the Recieve descriptor ring\n"); + "Unable to Allocate Memory for the Recieve descriptor ring\n"); return -ENOMEM; } memset(rxdr->buffer_info, 0, size); @@ -958,11 +1033,43 @@ rxdr->desc = pci_alloc_consistent(pdev, rxdr->size, &rxdr->dma); if(!rxdr->desc) { +setup_rx_desc_die: DPRINTK(PROBE, ERR, "Unble to Allocate Memory for the Recieve descriptor ring\n"); vfree(rxdr->buffer_info); return -ENOMEM; } + + /* fix for errata 23, cant cross 64kB boundary */ + if (!e1000_check_64k_bound(adapter, rxdr->desc, rxdr->size)) { + void *olddesc = rxdr->desc; + dma_addr_t olddma = rxdr->dma; + DPRINTK(RX_ERR,ERR, + "rxdr align check failed: %u bytes at %p\n", + rxdr->size, rxdr->desc); + /* try again, without freeing the previous */ + rxdr->desc = pci_alloc_consistent(pdev, rxdr->size, &rxdr->dma); + /* failed allocation, critial failure */ + if(!rxdr->desc) { + pci_free_consistent(pdev, rxdr->size, olddesc, olddma); + goto setup_rx_desc_die; + } + + if (!e1000_check_64k_bound(adapter, rxdr->desc, rxdr->size)) { + /* give up */ + pci_free_consistent(pdev, rxdr->size, + rxdr->desc, rxdr->dma); + pci_free_consistent(pdev, rxdr->size, olddesc, olddma); + DPRINTK(PROBE, ERR, + "Unable to Allocate aligned Memory for the" + " Receive descriptor ring\n"); + vfree(rxdr->buffer_info); + return -ENOMEM; + } else { + /* free old, move on with the new one since its okay */ + pci_free_consistent(pdev, rxdr->size, olddesc, olddma); + } + } memset(rxdr->desc, 0, rxdr->size); rxdr->next_to_clean = 0; @@ -1096,6 +1203,7 @@ struct e1000_buffer *buffer_info) { struct pci_dev *pdev = adapter->pdev; + if(buffer_info->dma) { pci_unmap_page(pdev, buffer_info->dma, @@ -1124,6 +1232,11 @@ /* Free all the Tx ring sk_buffs */ + if (likely(adapter->previous_buffer_info.skb != NULL)) { + e1000_unmap_and_free_tx_resource(adapter, + &adapter->previous_buffer_info); + } + for(i = 0; i < tx_ring->count; i++) { buffer_info = &tx_ring->buffer_info[i]; e1000_unmap_and_free_tx_resource(adapter, buffer_info); @@ -1425,7 +1538,6 @@ struct e1000_adapter *adapter = (struct e1000_adapter *) data; struct net_device *netdev = adapter->netdev; struct e1000_desc_ring *txdr = &adapter->tx_ring; - unsigned int i; uint32_t link; e1000_check_for_link(&adapter->hw); @@ -1505,12 +1617,8 @@ /* Cause software interrupt to ensure rx ring is cleaned */ E1000_WRITE_REG(&adapter->hw, ICS, E1000_ICS_RXDMT0); - /* Early detection of hung controller */ - i = txdr->next_to_clean; - if(txdr->buffer_info[i].dma && - time_after(jiffies, txdr->buffer_info[i].time_stamp + HZ) && - !(E1000_READ_REG(&adapter->hw, STATUS) & E1000_STATUS_TXOFF)) - netif_stop_queue(netdev); + /* Force detection of hung controller every watchdog period*/ + adapter->detect_tx_hung = TRUE; /* Reset the timer */ mod_timer(&adapter->watchdog_timer, jiffies + 2 * HZ); @@ -2151,10 +2259,28 @@ __netif_rx_schedule(netdev); } #else + /* Writing IMC and IMS is needed for 82547. + Due to Hub Link bus being occupied, an interrupt + de-assertion message is not able to be sent. + When an interrupt assertion message is generated later, + two messages are re-ordered and sent out. + That causes APIC to think 82547 is in de-assertion + state, while 82547 is in assertion state, resulting + in dead lock. Writing IMC forces 82547 into + de-assertion state. + */ + if(hw->mac_type == e1000_82547 || hw->mac_type == e1000_82547_rev_2){ + atomic_inc(&adapter->irq_sem); + E1000_WRITE_REG(&adapter->hw, IMC, ~0); + } + for(i = 0; i < E1000_MAX_INTR; i++) if(unlikely(!e1000_clean_rx_irq(adapter) & !e1000_clean_tx_irq(adapter))) break; + + if(hw->mac_type == e1000_82547 || hw->mac_type == e1000_82547_rev_2) + e1000_irq_enable(adapter); #endif return IRQ_HANDLED; @@ -2174,24 +2300,21 @@ int tx_cleaned; int work_done = 0; - if (!netif_carrier_ok(netdev)) - goto quit_polling; - tx_cleaned = e1000_clean_tx_irq(adapter); e1000_clean_rx_irq(adapter, &work_done, work_to_do); *budget -= work_done; netdev->quota -= work_done; - /* if no Rx and Tx cleanup work was done, exit the polling mode */ - if(!tx_cleaned || (work_done < work_to_do) || + /* if no Tx and not enough Rx work done, exit the polling mode */ + if((!tx_cleaned && (work_done < work_to_do)) || !netif_running(netdev)) { -quit_polling: netif_rx_complete(netdev); + netif_rx_complete(netdev); e1000_irq_enable(adapter); return 0; } - return (work_done >= work_to_do); + return 1; } #endif @@ -2215,11 +2338,34 @@ eop_desc = E1000_TX_DESC(*tx_ring, eop); while(eop_desc->upper.data & cpu_to_le32(E1000_TXD_STAT_DD)) { + /* pre-mature writeback of Tx descriptors */ + /* clear (free buffers and unmap pci_mapping) */ + /* previous_buffer_info */ + if (likely(adapter->previous_buffer_info.skb != NULL)) { + e1000_unmap_and_free_tx_resource(adapter, + &adapter->previous_buffer_info); + } + for(cleaned = FALSE; !cleaned; ) { tx_desc = E1000_TX_DESC(*tx_ring, i); buffer_info = &tx_ring->buffer_info[i]; + cleaned = (i == eop); + + /* pre-mature writeback of Tx descriptors */ + /* save the cleaning of the this for the */ + /* next iteration */ + if (cleaned) { + memcpy(&adapter->previous_buffer_info, + buffer_info, + sizeof(struct e1000_buffer)); + memset(buffer_info, + 0, + sizeof(struct e1000_buffer)); + } else { + e1000_unmap_and_free_tx_resource(adapter, + buffer_info); + } - e1000_unmap_and_free_tx_resource(adapter, buffer_info); tx_desc->buffer_addr = 0; tx_desc->lower.data = 0; tx_desc->upper.data = 0; @@ -2241,6 +2387,16 @@ netif_wake_queue(netdev); spin_unlock(&adapter->tx_lock); + + if(adapter->detect_tx_hung) { + /* detect a transmit hang in hardware, this serializes the + * check with the clearing of time_stamp and movement of i */ + adapter->detect_tx_hung = FALSE; + if(tx_ring->buffer_info[i].dma && + time_after(jiffies, tx_ring->buffer_info[i].time_stamp + HZ) && + !(E1000_READ_REG(&adapter->hw, STATUS) & E1000_STATUS_TXOFF)) + netif_stop_queue(netdev); + } return cleaned; } @@ -2407,19 +2563,43 @@ struct e1000_rx_desc *rx_desc; struct e1000_buffer *buffer_info; struct sk_buff *skb; - unsigned int i; + unsigned int i, bufsz; i = rx_ring->next_to_use; buffer_info = &rx_ring->buffer_info[i]; while(!buffer_info->skb) { - skb = dev_alloc_skb(adapter->rx_buffer_len + NET_IP_ALIGN); + bufsz = adapter->rx_buffer_len + NET_IP_ALIGN; + skb = dev_alloc_skb(bufsz); if(unlikely(!skb)) { /* Better luck next round */ break; } + /* fix for errata 23, cant cross 64kB boundary */ + if (!e1000_check_64k_bound(adapter, skb->data, bufsz)) { + struct sk_buff *oldskb = skb; + DPRINTK(RX_ERR,ERR, + "skb align check failed: %u bytes at %p\n", + bufsz, skb->data); + /* try again, without freeing the previous */ + skb = dev_alloc_skb(bufsz); + if (!skb) { + dev_kfree_skb(oldskb); + break; + } + if (!e1000_check_64k_bound(adapter, skb->data, bufsz)) { + /* give up */ + dev_kfree_skb(skb); + dev_kfree_skb(oldskb); + break; /* while !buffer_info->skb */ + } else { + /* move on with the new one */ + dev_kfree_skb(oldskb); + } + } + /* Make buffer alignment 2 beyond a 16 byte boundary * this will result in a 16 byte aligned IP header after * the 14 byte MAC header is removed @@ -2434,6 +2614,25 @@ skb->data, adapter->rx_buffer_len, PCI_DMA_FROMDEVICE); + + /* fix for errata 23, cant cross 64kB boundary */ + if(!e1000_check_64k_bound(adapter, + (void *)(unsigned long)buffer_info->dma, + adapter->rx_buffer_len)) { + DPRINTK(RX_ERR,ERR, + "dma align check failed: %u bytes at %ld\n", + adapter->rx_buffer_len, (unsigned long)buffer_info->dma); + + dev_kfree_skb(skb); + buffer_info->skb = NULL; + + pci_unmap_single(pdev, + buffer_info->dma, + adapter->rx_buffer_len, + PCI_DMA_FROMDEVICE); + + break; /* while !buffer_info->skb */ + } rx_desc = E1000_RX_DESC(*rx_ring, i); rx_desc->buffer_addr = cpu_to_le64(buffer_info->dma); diff -Nru a/drivers/net/ixgb/ixgb.h b/drivers/net/ixgb/ixgb.h --- a/drivers/net/ixgb/ixgb.h 2005-03-02 03:25:39 -05:00 +++ b/drivers/net/ixgb/ixgb.h 2005-03-02 03:25:39 -05:00 @@ -1,7 +1,7 @@ /******************************************************************************* - Copyright(c) 1999 - 2004 Intel Corporation. All rights reserved. + Copyright(c) 1999 - 2005 Intel Corporation. All rights reserved. This program is free software; you can redistribute it and/or modify it under the terms of the GNU General Public License as published by the Free @@ -176,6 +176,7 @@ uint64_t hw_csum_tx_error; uint32_t tx_int_delay; boolean_t tx_int_delay_enable; + boolean_t detect_tx_hung; /* RX */ struct ixgb_desc_ring rx_ring; diff -Nru a/drivers/net/ixgb/ixgb_ee.c b/drivers/net/ixgb/ixgb_ee.c --- a/drivers/net/ixgb/ixgb_ee.c 2005-03-02 03:25:39 -05:00 +++ b/drivers/net/ixgb/ixgb_ee.c 2005-03-02 03:25:39 -05:00 @@ -1,7 +1,7 @@ /******************************************************************************* - Copyright(c) 1999 - 2004 Intel Corporation. All rights reserved. + Copyright(c) 1999 - 2005 Intel Corporation. All rights reserved. This program is free software; you can redistribute it and/or modify it under the terms of the GNU General Public License as published by the Free @@ -372,11 +372,11 @@ * *****************************************************************************/ void -ixgb_write_eeprom(struct ixgb_hw *hw, - uint16_t offset, - uint16_t data) +ixgb_write_eeprom(struct ixgb_hw *hw, uint16_t offset, uint16_t data) { - /* Prepare the EEPROM for writing */ + struct ixgb_ee_map_type *ee_map = (struct ixgb_ee_map_type *)hw->eeprom; + + /* Prepare the EEPROM for writing */ ixgb_setup_eeprom(hw); /* Send the 9-bit EWEN (write enable) command to the EEPROM (5-bit opcode @@ -410,6 +410,9 @@ /* Done with writing */ ixgb_cleanup_eeprom(hw); + /* clear the init_ctrl_reg_1 to signify that the cache is invalidated */ + ee_map->init_ctrl_reg_1 = EEPROM_ICW1_SIGNATURE_CLEAR; + return; } @@ -478,6 +481,9 @@ if (checksum != (uint16_t) EEPROM_SUM) { DEBUGOUT("ixgb_ee: Checksum invalid.\n"); + /* clear the init_ctrl_reg_1 to signify that the cache is + * invalidated */ + ee_map->init_ctrl_reg_1 = EEPROM_ICW1_SIGNATURE_CLEAR; return (FALSE); } diff -Nru a/drivers/net/ixgb/ixgb_ee.h b/drivers/net/ixgb/ixgb_ee.h --- a/drivers/net/ixgb/ixgb_ee.h 2005-03-02 03:25:39 -05:00 +++ b/drivers/net/ixgb/ixgb_ee.h 2005-03-02 03:25:39 -05:00 @@ -1,7 +1,7 @@ /******************************************************************************* - Copyright(c) 1999 - 2004 Intel Corporation. All rights reserved. + Copyright(c) 1999 - 2005 Intel Corporation. All rights reserved. This program is free software; you can redistribute it and/or modify it under the terms of the GNU General Public License as published by the Free @@ -63,6 +63,7 @@ #define EEPROM_ICW1_SIGNATURE_MASK 0xC000 #define EEPROM_ICW1_SIGNATURE_VALID 0x4000 +#define EEPROM_ICW1_SIGNATURE_CLEAR 0x0000 /* For checksumming, the sum of all words in the EEPROM should equal 0xBABA. */ #define EEPROM_SUM 0xBABA diff -Nru a/drivers/net/ixgb/ixgb_ethtool.c b/drivers/net/ixgb/ixgb_ethtool.c --- a/drivers/net/ixgb/ixgb_ethtool.c 2005-03-02 03:25:39 -05:00 +++ b/drivers/net/ixgb/ixgb_ethtool.c 2005-03-02 03:25:39 -05:00 @@ -1,7 +1,7 @@ /******************************************************************************* - Copyright(c) 1999 - 2004 Intel Corporation. All rights reserved. + Copyright(c) 1999 - 2005 Intel Corporation. All rights reserved. This program is free software; you can redistribute it and/or modify it under the terms of the GNU General Public License as published by the Free @@ -63,6 +63,7 @@ {"tx_dropped", IXGB_STAT(net_stats.tx_dropped)}, {"multicast", IXGB_STAT(net_stats.multicast)}, {"collisions", IXGB_STAT(net_stats.collisions)}, + /* { "rx_length_errors", IXGB_STAT(net_stats.rx_length_errors) }, */ {"rx_over_errors", IXGB_STAT(net_stats.rx_over_errors)}, {"rx_crc_errors", IXGB_STAT(net_stats.rx_crc_errors)}, @@ -98,6 +99,7 @@ ixgb_get_settings(struct net_device *netdev, struct ethtool_cmd *ecmd) { struct ixgb_adapter *adapter = netdev->priv; + ecmd->supported = (SUPPORTED_10000baseT_Full | SUPPORTED_FIBRE); ecmd->advertising = (SUPPORTED_10000baseT_Full | SUPPORTED_FIBRE); ecmd->port = PORT_FIBRE; @@ -119,6 +121,7 @@ ixgb_set_settings(struct net_device *netdev, struct ethtool_cmd *ecmd) { struct ixgb_adapter *adapter = netdev->priv; + if(ecmd->autoneg == AUTONEG_ENABLE || ecmd->speed + ecmd->duplex != SPEED_10000 + DUPLEX_FULL) return -EINVAL; diff -Nru a/drivers/net/ixgb/ixgb_hw.c b/drivers/net/ixgb/ixgb_hw.c --- a/drivers/net/ixgb/ixgb_hw.c 2005-03-02 03:25:39 -05:00 +++ b/drivers/net/ixgb/ixgb_hw.c 2005-03-02 03:25:39 -05:00 @@ -1,7 +1,7 @@ /******************************************************************************* - Copyright(c) 1999 - 2004 Intel Corporation. All rights reserved. + Copyright(c) 1999 - 2005 Intel Corporation. All rights reserved. This program is free software; you can redistribute it and/or modify it under the terms of the GNU General Public License as published by the Free diff -Nru a/drivers/net/ixgb/ixgb_hw.h b/drivers/net/ixgb/ixgb_hw.h --- a/drivers/net/ixgb/ixgb_hw.h 2005-03-02 03:25:39 -05:00 +++ b/drivers/net/ixgb/ixgb_hw.h 2005-03-02 03:25:39 -05:00 @@ -1,7 +1,7 @@ /******************************************************************************* - Copyright(c) 1999 - 2004 Intel Corporation. All rights reserved. + Copyright(c) 1999 - 2005 Intel Corporation. All rights reserved. This program is free software; you can redistribute it and/or modify it under the terms of the GNU General Public License as published by the Free diff -Nru a/drivers/net/ixgb/ixgb_ids.h b/drivers/net/ixgb/ixgb_ids.h --- a/drivers/net/ixgb/ixgb_ids.h 2005-03-02 03:25:39 -05:00 +++ b/drivers/net/ixgb/ixgb_ids.h 2005-03-02 03:25:39 -05:00 @@ -1,7 +1,7 @@ /******************************************************************************* - Copyright(c) 1999 - 2004 Intel Corporation. All rights reserved. + Copyright(c) 1999 - 2005 Intel Corporation. All rights reserved. This program is free software; you can redistribute it and/or modify it under the terms of the GNU General Public License as published by the Free diff -Nru a/drivers/net/ixgb/ixgb_main.c b/drivers/net/ixgb/ixgb_main.c --- a/drivers/net/ixgb/ixgb_main.c 2005-03-02 03:25:39 -05:00 +++ b/drivers/net/ixgb/ixgb_main.c 2005-03-02 03:25:39 -05:00 @@ -1,7 +1,7 @@ /******************************************************************************* - Copyright(c) 1999 - 2004 Intel Corporation. All rights reserved. + Copyright(c) 1999 - 2005 Intel Corporation. All rights reserved. This program is free software; you can redistribute it and/or modify it under the terms of the GNU General Public License as published by the Free @@ -29,6 +29,9 @@ #include "ixgb.h" /* Change Log + * 1.0.88 01/05/05 + * - include fix to the condition that determines when to quit NAPI - Robert Olsson + * - use netif_poll_{disable/enable} to synchronize between NAPI and i/f up/down * 1.0.84 10/26/04 * - reset buffer_info->dma in Tx resource cleanup logic * 1.0.83 10/12/04 @@ -38,13 +41,14 @@ char ixgb_driver_name[] = "ixgb"; char ixgb_driver_string[] = "Intel(R) PRO/10GbE Network Driver"; + #ifndef CONFIG_IXGB_NAPI #define DRIVERNAPI #else #define DRIVERNAPI "-NAPI" #endif -char ixgb_driver_version[] = "1.0.87-k2"DRIVERNAPI; -char ixgb_copyright[] = "Copyright (c) 1999-2004 Intel Corporation."; +char ixgb_driver_version[] = "1.0.90-k2"DRIVERNAPI; +char ixgb_copyright[] = "Copyright (c) 1999-2005 Intel Corporation."; /* ixgb_pci_tbl - PCI Device ID Table * @@ -292,6 +296,9 @@ mod_timer(&adapter->watchdog_timer, jiffies); ixgb_irq_enable(adapter); +#ifdef CONFIG_IXGB_NAPI + netif_poll_enable(netdev); +#endif return 0; } @@ -309,6 +316,9 @@ #endif if(kill_watchdog) del_timer_sync(&adapter->watchdog_timer); +#ifdef CONFIG_IXGB_NAPI + netif_poll_disable(netdev); +#endif adapter->link_speed = 0; adapter->link_duplex = 0; netif_carrier_off(netdev); @@ -709,14 +719,8 @@ IXGB_WRITE_REG(hw, TDH, 0); IXGB_WRITE_REG(hw, TDT, 0); - /* don't set up txdctl, it induces performance problems if - * configured incorrectly - txdctl = TXDCTL_PTHRESH_DEFAULT; // prefetch txds below this threshold - txdctl |= (TXDCTL_HTHRESH_DEFAULT // only prefetch if there are this many ready - << IXGB_TXDCTL_HTHRESH_SHIFT); - IXGB_WRITE_REG (hw, TXDCTL, txdctl); - */ - + /* don't set up txdctl, it induces performance problems if configured + * incorrectly */ /* Set the Tx Interrupt Delay register */ IXGB_WRITE_REG(hw, TIDV, adapter->tx_int_delay); @@ -849,10 +853,17 @@ IXGB_WRITE_REG(hw, RDH, 0); IXGB_WRITE_REG(hw, RDT, 0); - /* burst 16 or burst when RXT0*/ - rxdctl = RXDCTL_WTHRESH_DEFAULT << IXGB_RXDCTL_WTHRESH_SHIFT - | RXDCTL_HTHRESH_DEFAULT << IXGB_RXDCTL_HTHRESH_SHIFT - | RXDCTL_PTHRESH_DEFAULT << IXGB_RXDCTL_PTHRESH_SHIFT; + /* set up pre-fetching of receive buffers so we get some before we + * run out (default hardware behavior is to run out before fetching + * more). This sets up to fetch if HTHRESH rx descriptors are avail + * and the descriptors in hw cache are below PTHRESH. This avoids + * the hardware behavior of fetching <=512 descriptors in a single + * burst that pre-empts all other activity, usually causing fifo + * overflows. */ + /* use WTHRESH to burst write 16 descriptors or burst when RXT0 */ + rxdctl = RXDCTL_WTHRESH_DEFAULT << IXGB_RXDCTL_WTHRESH_SHIFT | + RXDCTL_HTHRESH_DEFAULT << IXGB_RXDCTL_HTHRESH_SHIFT | + RXDCTL_PTHRESH_DEFAULT << IXGB_RXDCTL_PTHRESH_SHIFT; IXGB_WRITE_REG(hw, RXDCTL, rxdctl); /* Enable Receive Checksum Offload for TCP and UDP */ @@ -1094,7 +1105,6 @@ struct ixgb_adapter *adapter = (struct ixgb_adapter *)data; struct net_device *netdev = adapter->netdev; struct ixgb_desc_ring *txdr = &adapter->tx_ring; - unsigned int i; ixgb_check_for_link(&adapter->hw); @@ -1137,12 +1147,8 @@ } } - /* Early detection of hung controller */ - i = txdr->next_to_clean; - if(txdr->buffer_info[i].dma && - time_after(jiffies, txdr->buffer_info[i].time_stamp + HZ) && - !(IXGB_READ_REG(&adapter->hw, STATUS) & IXGB_STATUS_TXOFF)) - netif_stop_queue(netdev); + /* Force detection of hung controller every watchdog period */ + adapter->detect_tx_hung = TRUE; /* generate an interrupt to force clean up of any stragglers */ IXGB_WRITE_REG(&adapter->hw, ICS, IXGB_INT_TXDW); @@ -1668,20 +1674,16 @@ int work_to_do = min(*budget, netdev->quota); int tx_cleaned; int work_done = 0; - - if (!netif_carrier_ok(netdev)) - goto quit_polling; tx_cleaned = ixgb_clean_tx_irq(adapter); ixgb_clean_rx_irq(adapter, &work_done, work_to_do); *budget -= work_done; netdev->quota -= work_done; - - /* if no Tx cleanup and not enough Rx work done, exit the polling mode */ - if((!tx_cleaned && (work_done < work_to_do)) || - !netif_running(netdev)) { -quit_polling: netif_rx_complete(netdev); + + /* if no Tx and not enough Rx work done, exit the polling mode */ + if((!tx_cleaned && (work_done == 0)) || !netif_running(netdev)) { + netif_rx_complete(netdev); ixgb_irq_enable(adapter); return 0; } @@ -1741,6 +1743,17 @@ netif_wake_queue(netdev); } spin_unlock(&adapter->tx_lock); + + if(adapter->detect_tx_hung) { + /* detect a transmit hang in hardware, this serializes the + * check with the clearing of time_stamp and movement of i */ + adapter->detect_tx_hung = FALSE; + if(tx_ring->buffer_info[i].dma && + time_after(jiffies, tx_ring->buffer_info[i].time_stamp + HZ) + && !(IXGB_READ_REG(&adapter->hw, STATUS) & + IXGB_STATUS_TXOFF)) + netif_stop_queue(netdev); + } return cleaned; } diff -Nru a/drivers/net/ixgb/ixgb_osdep.h b/drivers/net/ixgb/ixgb_osdep.h --- a/drivers/net/ixgb/ixgb_osdep.h 2005-03-02 03:25:39 -05:00 +++ b/drivers/net/ixgb/ixgb_osdep.h 2005-03-02 03:25:39 -05:00 @@ -1,7 +1,7 @@ /******************************************************************************* - Copyright(c) 1999 - 2004 Intel Corporation. All rights reserved. + Copyright(c) 1999 - 2005 Intel Corporation. All rights reserved. This program is free software; you can redistribute it and/or modify it under the terms of the GNU General Public License as published by the Free diff -Nru a/drivers/net/ixgb/ixgb_param.c b/drivers/net/ixgb/ixgb_param.c --- a/drivers/net/ixgb/ixgb_param.c 2005-03-02 03:25:39 -05:00 +++ b/drivers/net/ixgb/ixgb_param.c 2005-03-02 03:25:39 -05:00 @@ -1,7 +1,7 @@ /******************************************************************************* - Copyright(c) 1999 - 2004 Intel Corporation. All rights reserved. + Copyright(c) 1999 - 2005 Intel Corporation. All rights reserved. This program is free software; you can redistribute it and/or modify it under the terms of the GNU General Public License as published by the Free --------------030204050700050303050609-- From guillaume.thouvenin@bull.net Wed Mar 2 00:48:29 2005 Received: with ECARTIS (v1.0.0; list netdev); Wed, 02 Mar 2005 00:48:43 -0800 (PST) Received: from ecfrec.frec.bull.fr (ecfrec.frec.bull.fr [129.183.4.8]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j228mPME006450 for ; Wed, 2 Mar 2005 00:48:27 -0800 Received: from localhost (localhost [127.0.0.1]) by ecfrec.frec.bull.fr (Postfix) with ESMTP id 54E3F19D90C; Wed, 2 Mar 2005 09:48:23 +0100 (CET) Received: from ecfrec.frec.bull.fr ([127.0.0.1]) by localhost (ecfrec.frec.bull.fr [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 03705-08; Wed, 2 Mar 2005 09:48:21 +0100 (CET) Received: from ecn002.frec.bull.fr (ecn002.frec.bull.fr [129.183.4.6]) by ecfrec.frec.bull.fr (Postfix) with ESMTP id 6142119D906; Wed, 2 Mar 2005 09:48:20 +0100 (CET) Received: from frecb000711.frec.bull.fr ([129.183.101.50]) by ecn002.frec.bull.fr (Lotus Domino Release 5.0.12) with ESMTP id 2005030209571473:348 ; Wed, 2 Mar 2005 09:57:14 +0100 Subject: Re: [PATCH 2.6.11-rc4-mm1] connector: Add a fork connector From: Guillaume Thouvenin To: Andrew Morton Cc: lkml , Evgeniy Polyakov , elsa-devel , Jay Lan , Gerrit Huizenga , Erich Focht , Netlink List , Kaigai Kohei In-Reply-To: <1109240677.1738.196.camel@frecb000711.frec.bull.fr> References: <1109240677.1738.196.camel@frecb000711.frec.bull.fr> Date: Wed, 02 Mar 2005 09:48:12 +0100 Message-Id: <1109753292.8422.117.camel@frecb000711.frec.bull.fr> Mime-Version: 1.0 X-Mailer: Evolution 2.0.2 X-MIMETrack: Itemize by SMTP Server on ECN002/FR/BULL(Release 5.0.12 |February 13, 2003) at 02/03/2005 09:57:14, Serialize by Router on ECN002/FR/BULL(Release 5.0.12 |February 13, 2003) at 02/03/2005 09:57:25, Serialize complete at 02/03/2005 09:57:25 Content-Transfer-Encoding: 7bit Content-Type: text/plain X-Virus-Scanned: ClamAV 0.83/737/Mon Feb 28 22:22:18 2005 on oss.sgi.com X-Virus-Scanned: by amavisd-new at frec.bull.fr X-Virus-Status: Clean X-archive-position: 2222 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: guillaume.thouvenin@bull.net Precedence: bulk X-list: netdev ChangeLog: - Add parenthesis around sizeof(struct cn_msg) + CN_FORK_INFO_SIZE in the CN_FORK_MSG_SIZE macro - fork_cn_lock is declareed with DEFINE_SPINLOCK() - fork_cn_lock is defined as static and local to fork_connector() - Create a specific module cn_fork.c in drivers/connector to register the callback. - Improve the callback that turns on/off the fork connector I also run the lmbench and results are send in response to another thread "A common layer for Accounting packages". When fork connector is turned off the overhead is negligible. This patch works with another small patch that fix a problem in the connector. Without it, there is a message that says "skb does not have enough length". It will be fix in the next -mm tree I think. Thanks everyone for the comments, Guillaume Signed-off-by: Guillaume Thouvenin --- drivers/connector/Kconfig | 11 +++++ drivers/connector/Makefile | 1 drivers/connector/cn_fork.c | 85 ++++++++++++++++++++++++++++++++++++++++++++ include/linux/connector.h | 4 ++ kernel/fork.c | 44 ++++++++++++++++++++++ 5 files changed, 145 insertions(+) diff -uprN -X dontdiff linux-2.6.11-rc4-mm1/drivers/connector/cn_fork.c linux-2.6.11-rc4-mm1-cnfork/drivers/connector/cn_fork.c --- linux-2.6.11-rc4-mm1/drivers/connector/cn_fork.c 1970-01-01 01:00:00.000000000 +0100 +++ linux-2.6.11-rc4-mm1-cnfork/drivers/connector/cn_fork.c 2005-03-01 13:13:05.000000000 +0100 @@ -0,0 +1,85 @@ +/* + * cn_fork.c + * + * 2005 Copyright (c) Guillaume Thouvenin + * All rights reserved. + * + * This program is free software; you can redistribute it and/or modify + * it under the terms of the GNU General Public License as published by + * the Free Software Foundation; either version 2 of the License, or + * (at your option) any later version. + * + * This program is distributed in the hope that it will be useful, + * but WITHOUT ANY WARRANTY; without even the implied warranty of + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the + * GNU General Public License for more details. + * + * You should have received a copy of the GNU General Public License + * along with this program; if not, write to the Free Software + * Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA 02111-1307 USA + */ + +#include +#include +#include + +#include + +MODULE_LICENSE("GPL"); +MODULE_AUTHOR("Guillaume Thouvenin "); +MODULE_DESCRIPTION("Enable or disable the usage of the fork connector"); + +int cn_fork_enable = 0; +struct cb_id cb_fork_id = { CN_IDX_FORK, CN_VAL_FORK }; + +/** + * cn_fork_callback - enable or disable the fork connector + * @data: message send by the connector + * + * The callback allows to enable or disable the sending of information + * about fork in the do_fork() routine. To enable the fork, the user + * space application must send the integer 1 in the data part of the + * message. To disable the fork connector, it must send the integer 0. + */ +static void cn_fork_callback(void *data) +{ + struct cn_msg *msg = (struct cn_msg *)data; + + if (cn_already_initialized && (msg->len == sizeof(cn_fork_enable))) + memcpy(&cn_fork_enable, msg->data, sizeof(cn_fork_enable)); +} + +/** + * cn_fork_init - initialization entry point + * + * This routine will be run at kernel boot time because this driver is + * built in the kernel. It adds the connector callback to the connector + * driver. + */ +static int cn_fork_init(void) +{ + int err; + + err = cn_add_callback(&cb_fork_id, "cn_fork", &cn_fork_callback); + if (err) { + printk(KERN_WARNING "Failed to register cn_fork\n"); + return -EINVAL; + } + + printk(KERN_NOTICE "cn_fork is registered\n"); + return 0; +} + +/** + * cn_fork_exit - exit entry point + * + * As this driver is always statically compiled into the kernel the + * cn_fork_exit has no effect. + */ +static void cn_fork_exit(void) +{ + cn_del_callback(&cb_fork_id); +} + +module_init(cn_fork_init); +module_exit(cn_fork_exit); diff -uprN -X dontdiff linux-2.6.11-rc4-mm1/drivers/connector/Kconfig linux-2.6.11-rc4-mm1-cnfork/drivers/connector/Kconfig --- linux-2.6.11-rc4-mm1/drivers/connector/Kconfig 2005-02-23 11:12:15.000000000 +0100 +++ linux-2.6.11-rc4-mm1-cnfork/drivers/connector/Kconfig 2005-02-24 10:29:11.000000000 +0100 @@ -10,4 +10,15 @@ config CONNECTOR Connector support can also be built as a module. If so, the module will be called cn.ko. +config FORK_CONNECTOR + bool "Enable fork connector" + depends on CONNECTOR=y + default y + ---help--- + It adds a connector in kernel/fork.c:do_fork() function. When a fork + occurs, netlink is used to transfer information about the parent and + its child. This information can be used by a user space application. + The fork connector can be enable/disable by sending a message to the + connector with the corresponding group id. + endmenu diff -uprN -X dontdiff linux-2.6.11-rc4-mm1/drivers/connector/Makefile linux-2.6.11-rc4-mm1-cnfork/drivers/connector/Makefile --- linux-2.6.11-rc4-mm1/drivers/connector/Makefile 2005-02-23 11:12:15.000000000 +0100 +++ linux-2.6.11-rc4-mm1-cnfork/drivers/connector/Makefile 2005-02-25 13:49:57.000000000 +0100 @@ -1,2 +1,3 @@ obj-$(CONFIG_CONNECTOR) += cn.o +obj-$(CONFIG_FORK_CONNECTOR) += cn_fork.o cn-objs := cn_queue.o connector.o diff -uprN -X dontdiff linux-2.6.11-rc4-mm1/include/linux/connector.h linux-2.6.11-rc4-mm1-cnfork/include/linux/connector.h --- linux-2.6.11-rc4-mm1/include/linux/connector.h 2005-02-23 11:12:17.000000000 +0100 +++ linux-2.6.11-rc4-mm1-cnfork/include/linux/connector.h 2005-03-01 12:44:50.000000000 +0100 @@ -28,6 +28,8 @@ #define CN_VAL_KOBJECT_UEVENT 0x0000 #define CN_IDX_SUPERIO 0xaabb /* SuperIO subsystem */ #define CN_VAL_SUPERIO 0xccdd +#define CN_IDX_FORK 0xfeed /* fork events */ +#define CN_VAL_FORK 0xbeef #define CONNECTOR_MAX_MSG_SIZE 1024 @@ -133,6 +135,8 @@ struct cn_dev }; extern int cn_already_initialized; +extern int cn_fork_enable; +extern struct cb_id cb_fork_id; int cn_add_callback(struct cb_id *, char *, void (* callback)(void *)); void cn_del_callback(struct cb_id *); diff -uprN -X dontdiff linux-2.6.11-rc4-mm1/kernel/fork.c linux-2.6.11-rc4-mm1-cnfork/kernel/fork.c --- linux-2.6.11-rc4-mm1/kernel/fork.c 2005-02-23 11:12:17.000000000 +0100 +++ linux-2.6.11-rc4-mm1-cnfork/kernel/fork.c 2005-03-01 08:39:13.000000000 +0100 @@ -41,6 +41,7 @@ #include #include #include +#include #include #include @@ -63,6 +64,47 @@ DEFINE_PER_CPU(unsigned long, process_co EXPORT_SYMBOL(tasklist_lock); +#ifdef CONFIG_FORK_CONNECTOR + +#define CN_FORK_INFO_SIZE 64 +#define CN_FORK_MSG_SIZE (sizeof(struct cn_msg) + CN_FORK_INFO_SIZE) + +static inline void fork_connector(pid_t parent, pid_t child) +{ + static DEFINE_SPINLOCK(cn_fork_lock); + static __u32 seq; /* used to test if message is lost */ + + if (cn_fork_enable) { + struct cn_msg *msg; + + __u8 buffer[CN_FORK_MSG_SIZE]; + + msg = (struct cn_msg *)buffer; + + memcpy(&msg->id, &cb_fork_id, sizeof(msg->id)); + spin_lock(&cn_fork_lock); + msg->seq = seq++; + spin_unlock(&cn_fork_lock); + msg->ack = 0; /* not used */ + /* + * size of data is the number of characters + * printed plus one for the trailing '\0' + */ + /* just fill the data part with '\0' */ + memset(msg->data, '\0', CN_FORK_INFO_SIZE); + msg->len = scnprintf(msg->data, CN_FORK_INFO_SIZE-1, + "%i %i", parent, child) + 1; + + cn_netlink_send(msg, CN_IDX_FORK); + } +} +#else +static inline void fork_connector(pid_t parent, pid_t child) +{ + return; +} +#endif + int nr_processes(void) { int cpu; @@ -1238,6 +1280,8 @@ long do_fork(unsigned long clone_flags, if (unlikely (current->ptrace & PT_TRACE_VFORK_DONE)) ptrace_notify ((PTRACE_EVENT_VFORK_DONE << 8) | SIGTRAP); } + + fork_connector(current->pid, p->pid); } else { free_pidmap(pid); pid = PTR_ERR(p); From guillaume.thouvenin@bull.net Wed Mar 2 00:58:25 2005 Received: with ECARTIS (v1.0.0; list netdev); Wed, 02 Mar 2005 00:58:29 -0800 (PST) Received: from ecfrec.frec.bull.fr (ecfrec.frec.bull.fr [129.183.4.8]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j228wNQc007244 for ; Wed, 2 Mar 2005 00:58:23 -0800 Received: from localhost (localhost [127.0.0.1]) by ecfrec.frec.bull.fr (Postfix) with ESMTP id 92D4319D90A; Wed, 2 Mar 2005 09:58:24 +0100 (CET) Received: from ecfrec.frec.bull.fr ([127.0.0.1]) by localhost (ecfrec.frec.bull.fr [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 04185-05; Wed, 2 Mar 2005 09:58:21 +0100 (CET) Received: from ecn002.frec.bull.fr (ecn002.frec.bull.fr [129.183.4.6]) by ecfrec.frec.bull.fr (Postfix) with ESMTP id 3F59119D906; Wed, 2 Mar 2005 09:58:20 +0100 (CET) Received: from frecb000711.frec.bull.fr ([129.183.101.50]) by ecn002.frec.bull.fr (Lotus Domino Release 5.0.12) with ESMTP id 2005030210072044:376 ; Wed, 2 Mar 2005 10:07:20 +0100 Subject: Re: [Lse-tech] Re: A common layer for Accounting packages From: Guillaume Thouvenin To: Kaigai Kohei Cc: Evgeniy Polyakov , hadi@cyberus.ca, Thomas Graf , Andrew Morton , Marcelo Tosatti , "David S. Miller" , jlan@sgi.com, LSE-Tech , lkml , Netlink List , elsa-devel In-Reply-To: <42247051.7070303@ak.jp.nec.com> References: <4221E548.4000008@ak.jp.nec.com> <20050227140355.GA23055@logos.cnet> <42227AEA.6050002@ak.jp.nec.com> <1109575236.8549.14.camel@frecb000711.frec.bull.fr> <20050227233943.6cb89226.akpm@osdl.org> <1109592658.2188.924.camel@jzny.localdomain> <20050228132051.GO31837@postel.suug.ch> <1109598010.2188.994.camel@jzny.localdomain> <20050228135307.GP31837@postel.suug.ch> <1109599803.2188.1014.camel@jzny.localdomain> <20050228142551.GQ31837@postel.suug.ch> <1109604693.1072.8.camel@jzny.localdomain> <20050228191759.6f7b656e@zanzibar.2ka.mipt.ru> <1109665299.8594.55.camel@frecb000711.frec.bull.fr> <42247051.7070303@ak.jp.nec.com> Date: Wed, 02 Mar 2005 09:58:13 +0100 Message-Id: <1109753893.8422.127.camel@frecb000711.frec.bull.fr> Mime-Version: 1.0 X-Mailer: Evolution 2.0.2 X-MIMETrack: Itemize by SMTP Server on ECN002/FR/BULL(Release 5.0.12 |February 13, 2003) at 02/03/2005 10:07:20, Serialize by Router on ECN002/FR/BULL(Release 5.0.12 |February 13, 2003) at 02/03/2005 10:07:25, Serialize complete at 02/03/2005 10:07:25 Content-Transfer-Encoding: 7bit Content-Type: text/plain X-Virus-Scanned: ClamAV 0.83/737/Mon Feb 28 22:22:18 2005 on oss.sgi.com X-Virus-Scanned: by amavisd-new at frec.bull.fr X-Virus-Status: Clean X-archive-position: 2223 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: guillaume.thouvenin@bull.net Precedence: bulk X-list: netdev On Tue, 2005-03-01 at 22:38 +0900, Kaigai Kohei wrote: > > I tested without user space listeners and the cost is negligible. I will > > test with a user space listeners and see the results. I'm going to run > > the test this week after improving the mechanism that switch on/off the > > sending of the message. > > I'm also trying to mesure the process-creation/destruction performance on following three environment. > Archtechture: i686 / Distribution: Fedora Core 3 > * Kernel Preemption is DISABLE > * SMP kernel but UP-machine / Not Hyper Threading > [1] 2.6.11-rc4-mm1 normal > [2] 2.6.11-rc4-mm1 with PAGG based Process Accounting Module > [3] 2.6.11-rc4-mm1 with fork-connector notification (it's enabled) > > When 367th-fork() was called after fork-connector notification, kernel was locked up. > (User-Space-Listener has been also run until 366th-fork() notification was received) So I ran the lmbench with three different kernels with the fork connector patch I just sent. Results are attached at the end of the mail and there are three different lines which are: o First line is a linux-2.6.11-rc4-mm1-cnfork o Second line is a linux-2.6.11-rc4-mm1 o Third line is a linux-2.6.11-rc4-mm1-cnfork with a user space application. The user space application listened during 15h and received 6496 messages. Each test has been ran only once. Best regards, Guillaume --- cd results && make summary percent 2>/dev/null | more make[1]: Entering directory `/home/guill/benchmark/lmbench/lmbench-3.0-a4/results' L M B E N C H 3 . 0 S U M M A R Y ------------------------------------ (Alpha software, do not distribute) Basic system parameters ------------------------------------------------------------------------------ Host OS Description Mhz tlb cache mem scal pages line par load bytes --------- ------------- ----------------------- ---- ----- ----- ------ ---- account Linux 2.6.11- i686-pc-linux-gnu 2765 63 128 2.4900 1 account Linux 2.6.11- i686-pc-linux-gnu 2765 67 128 2.4200 1 account Linux 2.6.11- i686-pc-linux-gnu 2765 69 128 2.4400 1 Processor, Processes - times in microseconds - smaller is better ------------------------------------------------------------------------------ Host OS Mhz null null open slct sig sig fork exec sh call I/O stat clos TCP inst hndl proc proc proc --------- ------------- ---- ---- ---- ---- ---- ---- ---- ---- ---- ---- ---- account Linux 2.6.11- 2765 0.17 0.26 3.57 4.19 16.9 0.51 2.31 162. 629. 2415 account Linux 2.6.11- 2765 0.16 0.26 3.56 4.17 17.6 0.50 2.30 163. 628. 2417 account Linux 2.6.11- 2765 0.16 0.27 3.67 4.25 17.6 0.51 2.28 176. 664. 2456 Basic integer operations - times in nanoseconds - smaller is better ------------------------------------------------------------------- Host OS intgr intgr intgr intgr intgr bit add mul div mod --------- ------------- ------ ------ ------ ------ ------ account Linux 2.6.11- 0.1800 0.1700 4.9900 20.8 23.1 account Linux 2.6.11- 0.1800 0.1700 4.9900 20.8 23.1 account Linux 2.6.11- 0.1800 0.1700 4.9900 20.8 23.1 Basic float operations - times in nanoseconds - smaller is better ----------------------------------------------------------------- Host OS float float float float add mul div bogo --------- ------------- ------ ------ ------ ------ account Linux 2.6.11- 1.7300 2.4800 15.5 15.4 account Linux 2.6.11- 1.7300 2.4800 15.5 15.6 account Linux 2.6.11- 1.7400 2.5000 15.7 15.6 Basic double operations - times in nanoseconds - smaller is better ------------------------------------------------------------------ Host OS double double double double add mul div bogo --------- ------------- ------ ------ ------ ------ account Linux 2.6.11- 1.7300 2.4800 15.5 15.4 account Linux 2.6.11- 1.7300 2.4800 15.5 15.6 account Linux 2.6.11- 1.7400 2.5000 15.7 15.6 Context switching - times in microseconds - smaller is better ------------------------------------------------------------------------- Host OS 2p/0K 2p/16K 2p/64K 8p/16K 8p/64K 16p/16K 16p/64K ctxsw ctxsw ctxsw ctxsw ctxsw ctxsw ctxsw --------- ------------- ------ ------ ------ ------ ------ ------- ------- account Linux 2.6.11- 5.1300 5.2900 4.9700 3.1700 10.9 6.30000 32.6 account Linux 2.6.11- 4.9000 5.2100 5.1600 4.4700 20.3 6.48000 27.7 account Linux 2.6.11- 4.8600 5.3000 4.9200 3.5600 20.5 6.87000 31.5 *Local* Communication latencies in microseconds - smaller is better --------------------------------------------------------------------- Host OS 2p/0K Pipe AF UDP RPC/ TCP RPC/ TCP ctxsw UNIX UDP TCP conn --------- ------------- ----- ----- ---- ----- ----- ----- ----- ---- account Linux 2.6.11- 5.130 14.3 11.9 17.7 23.2 20.3 28.3 40. account Linux 2.6.11- 4.900 14.6 12.0 18.5 23.9 20.8 28.6 40. account Linux 2.6.11- 4.860 14.8 12.6 18.1 23.9 20.8 27.8 40. File & VM system latencies in microseconds - smaller is better ------------------------------------------------------------------------------- Host OS 0K File 10K File Mmap Prot Page 100fd Create Delete Create Delete Latency Fault Fault selct --------- ------------- ------ ------ ------ ------ ------- ----- ------- ----- account Linux 2.6.11- 18.9 16.1 65.6 33.5 15.4K 0.771 2.22520 16.4 account Linux 2.6.11- 18.8 16.3 64.2 33.2 15.7K 0.841 2.20690 16.5 account Linux 2.6.11- 19.2 16.4 65.4 33.5 15.7K 0.782 2.19950 16.4 *Local* Communication bandwidths in MB/s - bigger is better ----------------------------------------------------------------------------- Host OS Pipe AF TCP File Mmap Bcopy Bcopy Mem Mem UNIX reread reread (libc) (hand) read write --------- ------------- ---- ---- ---- ------ ------ ------ ------ ---- ----- account Linux 2.6.11- 664. 497. 369. 1468.8 1836.1 596.6 568.4 1819 779.7 account Linux 2.6.11- 671. 521. 338. 1481.6 1817.2 593.8 568.8 1838 783.0 account Linux 2.6.11- 667. 543. 372. 1469.4 1816.8 594.2 568.3 1818 783.0 Memory latencies in nanoseconds - smaller is better (WARNING - may not be correct, check graphs) ------------------------------------------------------------------------------ Host OS Mhz L1 $ L2 $ Main mem Rand mem Guesses --------- ------------- --- ---- ---- -------- -------- ------- account Linux 2.6.11- 2765 0.7030 6.5710 140.6 246.7 account Linux 2.6.11- 2765 0.7090 6.6350 142.4 249.5 account Linux 2.6.11- 2765 0.7110 6.6340 142.5 249.5 make[1]: Leaving directory `/home/guill/benchmark/lmbench/lmbench-3.0-a4/results' From akpm@osdl.org Wed Mar 2 01:08:30 2005 Received: with ECARTIS (v1.0.0; list netdev); Wed, 02 Mar 2005 01:08:34 -0800 (PST) Received: from smtp.osdl.org (fire.osdl.org [65.172.181.4]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j2298TwO007943 for ; Wed, 2 Mar 2005 01:08:29 -0800 Received: from shell0.pdx.osdl.net (fw.osdl.org [65.172.181.6]) by smtp.osdl.org (8.12.8/8.12.8) with ESMTP id j2296Xqi007854 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO); Wed, 2 Mar 2005 01:06:34 -0800 Received: from bix (shell0.pdx.osdl.net [10.9.0.31]) by shell0.pdx.osdl.net (8.13.1/8.11.6) with SMTP id j2296WKt028540; Wed, 2 Mar 2005 01:06:33 -0800 Date: Wed, 2 Mar 2005 01:06:14 -0800 From: Andrew Morton To: Guillaume Thouvenin Cc: kaigai@ak.jp.nec.com, johnpol@2ka.mipt.ru, hadi@cyberus.ca, tgraf@suug.ch, marcelo.tosatti@cyclades.com, davem@redhat.com, jlan@sgi.com, lse-tech@lists.sourceforge.net, linux-kernel@vger.kernel.org, netdev@oss.sgi.com, elsa-devel@lists.sourceforge.net Subject: Re: [Lse-tech] Re: A common layer for Accounting packages Message-Id: <20050302010614.2a8bb483.akpm@osdl.org> In-Reply-To: <1109753893.8422.127.camel@frecb000711.frec.bull.fr> References: <4221E548.4000008@ak.jp.nec.com> <20050227140355.GA23055@logos.cnet> <42227AEA.6050002@ak.jp.nec.com> <1109575236.8549.14.camel@frecb000711.frec.bull.fr> <20050227233943.6cb89226.akpm@osdl.org> <1109592658.2188.924.camel@jzny.localdomain> <20050228132051.GO31837@postel.suug.ch> <1109598010.2188.994.camel@jzny.localdomain> <20050228135307.GP31837@postel.suug.ch> <1109599803.2188.1014.camel@jzny.localdomain> <20050228142551.GQ31837@postel.suug.ch> <1109604693.1072.8.camel@jzny.localdomain> <20050228191759.6f7b656e@zanzibar.2ka.mipt.ru> <1109665299.8594.55.camel@frecb000711.frec.bull.fr> <42247051.7070303@ak.jp.nec.com> <1109753893.8422.127.camel@frecb000711.frec.bull.fr> X-Mailer: Sylpheed version 0.9.7 (GTK+ 1.2.10; i386-redhat-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Received-SPF: pass (domain of akpm@osdl.org designates 65.172.181.6 as permitted sender) X-MIMEDefang-Filter: osdl$Revision: 1.104 $ X-Scanned-By: MIMEDefang 2.36 X-Virus-Scanned: ClamAV 0.83/737/Mon Feb 28 22:22:18 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 2224 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: akpm@osdl.org Precedence: bulk X-list: netdev Guillaume Thouvenin wrote: > > So I ran the lmbench with three different kernels with the fork > connector patch I just sent. Results are attached at the end of the mail > and there are three different lines which are: > > o First line is a linux-2.6.11-rc4-mm1-cnfork > o Second line is a linux-2.6.11-rc4-mm1 > o Third line is a linux-2.6.11-rc4-mm1-cnfork with a user space > application. The user space application listened during 15h > and received 6496 messages. > > Each test has been ran only once. > > ... > ------------------------------------------------------------------------------ > Host OS Mhz null null open slct sig sig fork exec sh > call I/O stat clos TCP inst hndl proc proc proc > --------- ------------- ---- ---- ---- ---- ---- ---- ---- ---- ---- ---- ---- > account Linux 2.6.11- 2765 0.17 0.26 3.57 4.19 16.9 0.51 2.31 162. 629. 2415 > account Linux 2.6.11- 2765 0.16 0.26 3.56 4.17 17.6 0.50 2.30 163. 628. 2417 > account Linux 2.6.11- 2765 0.16 0.27 3.67 4.25 17.6 0.51 2.28 176. 664. 2456 This is the interesting bit, yes? 5-10% slowdown on fork is expected, but why was exec slower? What does "The user space application listened during 15h" mean? From guillaume.thouvenin@bull.net Wed Mar 2 01:25:57 2005 Received: with ECARTIS (v1.0.0; list netdev); Wed, 02 Mar 2005 01:26:02 -0800 (PST) Received: from ecfrec.frec.bull.fr (ecfrec.frec.bull.fr [129.183.4.8]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j229Ps1W008762 for ; Wed, 2 Mar 2005 01:25:55 -0800 Received: from localhost (localhost [127.0.0.1]) by ecfrec.frec.bull.fr (Postfix) with ESMTP id 214EA19D90A; Wed, 2 Mar 2005 10:25:54 +0100 (CET) Received: from ecfrec.frec.bull.fr ([127.0.0.1]) by localhost (ecfrec.frec.bull.fr [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 05917-01; Wed, 2 Mar 2005 10:25:51 +0100 (CET) Received: from ecn002.frec.bull.fr (ecn002.frec.bull.fr [129.183.4.6]) by ecfrec.frec.bull.fr (Postfix) with ESMTP id 0FFF419D90C; Wed, 2 Mar 2005 10:25:50 +0100 (CET) Received: from frecb000711.frec.bull.fr ([129.183.101.50]) by ecn002.frec.bull.fr (Lotus Domino Release 5.0.12) with ESMTP id 2005030210345090:467 ; Wed, 2 Mar 2005 10:34:50 +0100 Subject: Re: [Lse-tech] Re: A common layer for Accounting packages From: Guillaume Thouvenin To: Andrew Morton Cc: Kaigai Kohei , Evgeniy Polyakov , hadi@cyberus.ca, tgraf@suug.ch, Marcelo Tosatti , "David S. Miller" , jlan@sgi.com, LSE-Tech , lkml , Netlink List , elsa-devel In-Reply-To: <20050302010614.2a8bb483.akpm@osdl.org> References: <4221E548.4000008@ak.jp.nec.com> <20050227140355.GA23055@logos.cnet> <42227AEA.6050002@ak.jp.nec.com> <1109575236.8549.14.camel@frecb000711.frec.bull.fr> <20050227233943.6cb89226.akpm@osdl.org> <1109592658.2188.924.camel@jzny.localdomain> <20050228132051.GO31837@postel.suug.ch> <1109598010.2188.994.camel@jzny.localdomain> <20050228135307.GP31837@postel.suug.ch> <1109599803.2188.1014.camel@jzny.localdomain> <20050228142551.GQ31837@postel.suug.ch> <1109604693.1072.8.camel@jzny.localdomain> <20050228191759.6f7b656e@zanzibar.2ka.mipt.ru> <1109665299.8594.55.camel@frecb000711.frec.bull.fr> <42247051.7070303@ak.jp.nec.com> <1109753893.8422.127.camel@frecb000711.frec.bull.fr> <20050302010614.2a8bb483.akpm@osdl.org> Date: Wed, 02 Mar 2005 10:25:49 +0100 Message-Id: <1109755549.32740.8.camel@frecb000711.frec.bull.fr> Mime-Version: 1.0 X-Mailer: Evolution 2.0.2 X-MIMETrack: Itemize by SMTP Server on ECN002/FR/BULL(Release 5.0.12 |February 13, 2003) at 02/03/2005 10:34:51, Serialize by Router on ECN002/FR/BULL(Release 5.0.12 |February 13, 2003) at 02/03/2005 10:34:55, Serialize complete at 02/03/2005 10:34:55 Content-Transfer-Encoding: 7bit Content-Type: text/plain X-Virus-Scanned: ClamAV 0.83/737/Mon Feb 28 22:22:18 2005 on oss.sgi.com X-Virus-Scanned: by amavisd-new at frec.bull.fr X-Virus-Status: Clean X-archive-position: 2225 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: guillaume.thouvenin@bull.net Precedence: bulk X-list: netdev On Wed, 2005-03-02 at 01:06 -0800, Andrew Morton wrote: > Guillaume Thouvenin wrote: > > > > So I ran the lmbench with three different kernels with the fork > > connector patch I just sent. Results are attached at the end of the mail > > and there are three different lines which are: > > > > o First line is a linux-2.6.11-rc4-mm1-cnfork > > o Second line is a linux-2.6.11-rc4-mm1 > > o Third line is a linux-2.6.11-rc4-mm1-cnfork with a user space > > application. The user space application listened during 15h > > and received 6496 messages. > > > > Each test has been ran only once. > > > > ... > > ------------------------------------------------------------------------------ > > Host OS Mhz null null open slct sig sig fork exec sh > > call I/O stat clos TCP inst hndl proc proc proc > > --------- ------------- ---- ---- ---- ---- ---- ---- ---- ---- ---- ---- ---- > > account Linux 2.6.11- 2765 0.17 0.26 3.57 4.19 16.9 0.51 2.31 162. 629. 2415 > > account Linux 2.6.11- 2765 0.16 0.26 3.56 4.17 17.6 0.50 2.30 163. 628. 2417 > > account Linux 2.6.11- 2765 0.16 0.27 3.67 4.25 17.6 0.51 2.28 176. 664. 2456 > > This is the interesting bit, yes? 5-10% slowdown on fork is expected, but > why was exec slower? I can't explain it for the moment. I will run test more than once to see if this difference is still here. > What does "The user space application listened during 15h" mean? It means that I ran the user space application before the test and stop it 15 hours later (this morning for me). The test ran during 5h30mn. The user space application increments a counter to show how many processes have been created during a period of time. I have not use the user space daemon that manages group of processes because the it still uses the old mechanism (a signal sends from the do_fork()) and as I wanted to provide quick results, I used another user space application. I attache the test program (get_fork_info.c) that I'm using at the end of the mail to clearly show what it does. I will run new tests with the real user space daemon but it will be ready next week, sorry for the delay. Best regards, Guillaume --- /* * get_fork_info.c * * This program listens netlink interface to retreive information * sends by the kernel when forking. It increments a counter for * each forks and when the user hit CRL-C, it displays how many * fork occured during the period. */ #include #include #include #include #include #include #include #include #include #include #include #include #define CN_FORK_OFF 0 #define CN_FORK_ON 1 #define MESSAGE_SIZE (sizeof(struct nlmsghdr) + \ sizeof(struct cn_msg) + \ sizeof(int)) int sock; unsigned long total_p; struct timeval test_time; static inline void switch_cn_fork(int sock, int action) { char buff[128]; /* must be > MESSAGE_SIZE */ struct nlmsghdr *hdr; struct cn_msg *msg; /* Clear the buffer */ memset(buff, '\0', sizeof(buff)); /* fill the message header */ hdr = (struct nlmsghdr *) buff; hdr->nlmsg_len = MESSAGE_SIZE; hdr->nlmsg_type = NLMSG_DONE; hdr->nlmsg_flags = 0; hdr->nlmsg_seq = 0; hdr->nlmsg_pid = getpid(); /* the message */ msg = (struct cn_msg *) NLMSG_DATA(hdr); msg->id.idx = CN_IDX_FORK; msg->id.val = CN_VAL_FORK; msg->seq = 0; msg->ack = 0; msg->len = sizeof(int); msg->data[0] = action; send(sock, hdr, hdr->nlmsg_len, 0); } static void cleanup() { struct timeval tmp_time; switch_cn_fork(sock, CN_FORK_OFF); tmp_time = test_time; gettimeofday(&test_time, NULL); printf("%lu processes were created in %li seconds.\n", total_p, test_time.tv_sec - tmp_time.tv_sec); close(sock); exit(EXIT_SUCCESS); } int main() { int err; struct sockaddr_nl sa; /* information for NETLINK interface */ /* * To be able to quit the application properly we install a * signal handler that catch the CTRL-C */ signal(SIGTERM, cleanup); signal(SIGINT, cleanup); /* * Create an endpoint for communication. Use the kernel user * interface device (PF_NETLINK) which is a datagram oriented * service (SOCK_DGRAM). The protocol used is the netfilter/iptables * ULOG protocol (NETLINK_NFLOG) */ sock = socket(PF_NETLINK, SOCK_DGRAM, NETLINK_NFLOG); if (sock == -1) { perror("socket"); return -1; } sa.nl_family = AF_NETLINK; sa.nl_groups = CN_IDX_FORK; sa.nl_pid = getpid(); err = bind(sock, (struct sockaddr *) &sa, sizeof(struct sockaddr_nl)); if (err == -1) { perror("bind"); close(sock); return -1; } switch_cn_fork(sock, CN_FORK_ON); total_p = 0; gettimeofday(&test_time, NULL); for (;;) { char buff[1024]; /* it's large enough */ struct nlmsghdr *hdr; struct cn_msg *msg; int len; /* Clear the buffer */ memset(buff, '\0', sizeof(buff)); /* Listen */ len = recv(sock, buff, sizeof(buff), 0); if (len == -1) { perror("recv"); close(sock); return -1; } /* point to the message header */ hdr = (struct nlmsghdr *) buff; switch (hdr->nlmsg_type) { case NLMSG_DONE: msg = (struct cn_msg *) NLMSG_DATA(hdr); total_p++; #if 0 printf("[idx=0x%x seq=%u] %s\n", msg->id.idx, msg->seq, msg->data); #endif break; case NLMSG_ERROR: printf("NLMSG_ERROR\n"); /* Fall through */ default: break; } } /* * in fact we never reach this part of the code because there is an * infinite loop above. */ cleanup(); return 0; } From devik@cdi.cz Wed Mar 2 01:56:49 2005 Received: with ECARTIS (v1.0.0; list netdev); Wed, 02 Mar 2005 01:56:53 -0800 (PST) Received: from www1.cdi.cz (IDENT:8@www1.cdi.cz [194.213.194.49]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j229ul4k010097 for ; Wed, 2 Mar 2005 01:56:48 -0800 Received: from mail by www1.cdi.cz with spamc (Exim 4.31) id 1D6Qaz-0003q8-4Z; Wed, 02 Mar 2005 10:56:46 +0100 Received: from ip-85-160-89-87.eurotel.cz ([85.160.89.87] helo=devix) by www1.cdi.cz with asmtp (Exim 4.31) id 1D6Qas-0003ol-9e; Wed, 02 Mar 2005 10:56:41 +0100 Received: from devix ([127.0.0.1]) by devix with esmtp (Exim 3.16 #8) id 1D6Qad-0006Si-00; Wed, 02 Mar 2005 10:56:23 +0100 Message-ID: <42258DC6.9030109@cdi.cz> Date: Wed, 02 Mar 2005 10:56:22 +0100 From: Martin Devera User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.5) Gecko/20041217 X-Accept-Language: cs, en-us, en MIME-Version: 1.0 To: kaber@trash.net CC: netdev@oss.sgi.com Subject: spin_trylock in qdisc_restart, OOPS, IMQ problem ? Content-Type: multipart/mixed; boundary="------------000602010005000704040500" X-Virus-Scanned: ClamAV 0.83/737/Mon Feb 28 22:22:18 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 2226 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: devik@cdi.cz Precedence: bulk X-list: netdev This is a multi-part message in MIME format. --------------000602010005000704040500 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Hello, I just started to get oopses in 2.6.10+imq patch (after weeks of flawless operation). While debugging the problem I found some weirdness in qdisc_restart code: if (!spin_trylock(&dev->xmit_lock)) { collision: /* So, someone grabbed the driver. */ /* It may be transient configuration error, when hard_start_xmit() recurses. We detect it by checking xmit owner and drop the packet when deadloop is detected. */ Here we try to catch a case (among others) where a driver recurses from hard_start_xmit. It is ok. But on UP spin_trylock returns always "1" thus there is no longer any deadlock protection in qdisc_restart. When I turned spinlock debugging on I can now see: net/sched/sch_generic.c:114: spin_trylock(net/core/dev.c:df62cd54) already locked by net/core/netpoll.c/191 net/core/netpoll.c:208: spin_unlock(net/core/dev.c:df62cd54) not locked I've seen some notes in 2.6.11rc3 changelog from Patrick about issues similar to my OOPS (attached). Patrick, does the oops ring some bells at your side ? devik --------------000602010005000704040500 Content-Type: text/plain; name="messages" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="messages" Mar 1 19:17:07 192.168.254.1 net/sched/sch_generic.c:114: spin_trylock(net/core/dev.c:df62cd54) already locked by net/core/netpoll.c/191 Mar 1 19:17:07 192.168.254.1 net/core/netpoll.c:208: spin_unlock(net/core/dev.c:df62cd54) not locked Mar 1 21:10:13 192.168.254.1 Unable to handle kernel paging request Mar 1 21:10:33 192.168.254.1 at virtual address cb9dce34 Mar 1 21:10:53 192.168.254.1 printing eip: Mar 1 21:11:13 192.168.254.1 c03884ea Mar 1 21:11:33 192.168.254.1 *pde = 0002e067 Mar 1 21:11:53 192.168.254.1 *pte = 0b9dc000 Mar 1 21:12:13 192.168.254.1 Oops: 0000 [#1] Mar 1 21:12:33 192.168.254.1 DEBUG_PAGEALLOC Mar 1 21:12:53 192.168.254.1 Mar 1 21:13:13 192.168.254.1 Modules linked in: Mar 1 21:13:33 192.168.254.1 netconsole Mar 1 21:13:53 192.168.254.1 Mar 1 21:14:13 192.168.254.1 CPU: 0 Mar 1 21:14:33 192.168.254.1 EIP: 0060:[] Not tainted VLI Mar 1 21:14:53 192.168.254.1 EFLAGS: 00010202 (2.6.10imq) Mar 1 21:15:13 192.168.254.1 EIP is at tcp_manip_pkt+0x6a/0x109 Mar 1 21:15:33 192.168.254.1 eax: cabe8f44 ebx: ca507e38 ecx: 00000001 edx: ca507e3a Mar 1 21:15:53 192.168.254.1 esi: cb9dce24 edi: 00000014 ebp: c04c9a68 esp: c04c9a4c Mar 1 21:16:13 192.168.254.1 ds: 007b es: 007b ss: 0068 Mar 1 21:16:33 192.168.254.1 Process swapper (pid: 0, threadinfo=c04c9000 task=c03fdbe0) Mar 1 21:16:53 192.168.254.1 Mar 1 21:17:13 192.168.254.1 Stack: Mar 1 21:17:34 192.168.254.1 c04c9b68 Mar 1 21:17:54 192.168.254.1 00000044 Mar 1 21:18:14 192.168.254.1 c032387c Mar 1 21:18:34 192.168.254.1 ca507e1c Mar 1 21:18:54 192.168.254.1 c04c9b68 Mar 1 21:19:14 192.168.254.1 00000006 Mar 1 21:19:34 192.168.254.1 0000001c Mar 1 21:19:54 192.168.254.1 c04c9a8c Mar 1 21:20:14 192.168.254.1 Mar 1 21:20:34 192.168.254.1 Mar 1 21:20:54 192.168.254.1 c0387174 Mar 1 21:21:14 192.168.254.1 c04c9b68 Mar 1 21:21:34 192.168.254.1 0000001c Mar 1 21:21:54 192.168.254.1 d6751f4c Mar 1 21:22:14 192.168.254.1 00000001 Mar 1 21:22:34 192.168.254.1 d6751f4c Mar 1 21:22:54 192.168.254.1 00000000 Mar 1 21:23:14 192.168.254.1 d6751f44 Mar 1 21:23:34 192.168.254.1 Mar 1 21:23:54 192.168.254.1 Mar 1 21:24:14 192.168.254.1 c04c9abc Mar 1 21:24:34 192.168.254.1 c038757d Mar 1 21:24:54 192.168.254.1 00000006 Mar 1 21:25:14 192.168.254.1 c04c9b68 Mar 1 21:25:34 192.168.254.1 0000001c Mar 1 21:25:55 192.168.254.1 d6751f4c Mar 1 21:26:15 192.168.254.1 00000001 Mar 1 21:26:35 192.168.254.1 00000000 Mar 1 21:26:55 192.168.254.1 Mar 1 21:27:15 192.168.254.1 Call Trace: Mar 1 21:27:35 192.168.254.1 [] Mar 1 21:27:55 192.168.254.1 show_stack+0x80/0x96 Mar 1 21:28:15 192.168.254.1 Mar 1 21:28:35 192.168.254.1 [] Mar 1 21:28:55 192.168.254.1 show_registers+0x15a/0x1d1 Mar 1 21:29:15 192.168.254.1 Mar 1 21:29:35 192.168.254.1 [] Mar 1 21:29:55 192.168.254.1 die+0x152/0x2b8 Mar 1 21:30:15 192.168.254.1 Mar 1 21:30:35 192.168.254.1 [] Mar 1 21:30:55 192.168.254.1 do_page_fault+0x487/0x6be Mar 1 21:31:15 192.168.254.1 Mar 1 21:31:35 192.168.254.1 [] Mar 1 21:31:55 192.168.254.1 error_code+0x2b/0x30 Mar 1 21:32:15 192.168.254.1 Mar 1 21:32:35 192.168.254.1 [] Mar 1 21:32:55 192.168.254.1 manip_pkt+0x6c/0xf2 Mar 1 21:33:15 192.168.254.1 Mar 1 21:33:35 192.168.254.1 [] Mar 1 21:33:55 192.168.254.1 icmp_reply_translation+0x140/0x213 Mar 1 21:34:16 192.168.254.1 Mar 1 21:34:36 192.168.254.1 [] Mar 1 21:34:56 192.168.254.1 ip_nat_fn+0x203/0x237 Mar 1 21:35:16 192.168.254.1 Mar 1 21:35:36 192.168.254.1 [] Mar 1 21:35:56 192.168.254.1 nf_iterate+0x52/0x9b Mar 1 21:36:16 192.168.254.1 Mar 1 21:36:36 192.168.254.1 [] Mar 1 21:36:56 192.168.254.1 nf_hook_slow+0x63/0xfd Mar 1 21:37:16 192.168.254.1 Mar 1 21:37:36 192.168.254.1 [] Mar 1 21:37:56 192.168.254.1 ip_finish_output+0x156/0x233 Mar 1 21:38:16 192.168.254.1 Mar 1 21:38:36 192.168.254.1 [] Mar 1 21:38:56 192.168.254.1 nf_hook_slow+0xef/0xfd Mar 1 21:39:16 192.168.254.1 Mar 1 21:39:36 192.168.254.1 [] Mar 1 21:39:56 192.168.254.1 send_unreach+0x511/0x5e0 Mar 1 21:40:16 192.168.254.1 Mar 1 21:40:36 192.168.254.1 [] Mar 1 21:40:56 192.168.254.1 reject+0x3c/0x8f Mar 1 21:41:16 192.168.254.1 Mar 1 21:41:36 192.168.254.1 [] Mar 1 21:41:56 192.168.254.1 ipt_do_table+0x2e5/0x322 Mar 1 21:42:16 192.168.254.1 Mar 1 21:42:36 192.168.254.1 [] Mar 1 21:42:57 192.168.254.1 ipt_hook+0x36/0x38 Mar 1 21:43:17 192.168.254.1 Mar 1 21:43:37 192.168.254.1 [] Mar 1 21:43:57 192.168.254.1 nf_iterate+0x52/0x9b Mar 1 21:44:17 192.168.254.1 Mar 1 21:44:37 192.168.254.1 [] Mar 1 21:44:57 192.168.254.1 nf_hook_slow+0x63/0xfd Mar 1 21:45:17 192.168.254.1 Mar 1 21:45:37 192.168.254.1 [] Mar 1 21:45:57 192.168.254.1 ip_local_deliver+0x165/0x1c0 Mar 1 21:46:17 192.168.254.1 Mar 1 21:46:37 192.168.254.1 [] Mar 1 21:46:57 192.168.254.1 ip_rcv_finish+0x159/0x22a Mar 1 21:47:17 192.168.254.1 Mar 1 21:47:37 192.168.254.1 [] Mar 1 21:47:57 192.168.254.1 nf_reinject+0x153/0x1c8 Mar 1 21:48:17 192.168.254.1 Mar 1 21:48:37 192.168.254.1 [] Mar 1 21:48:57 192.168.254.1 imq_dev_xmit+0x4a/0x52 Mar 1 21:49:17 192.168.254.1 Mar 1 21:49:37 192.168.254.1 [] Mar 1 21:49:57 192.168.254.1 qdisc_restart+0xbd/0x643 Mar 1 21:50:17 192.168.254.1 Mar 1 21:50:37 192.168.254.1 [] Mar 1 21:50:57 192.168.254.1 imq_nf_queue+0x152/0x37e Mar 1 21:51:17 192.168.254.1 Mar 1 21:51:38 192.168.254.1 [] Mar 1 21:51:58 192.168.254.1 nf_queue+0x10b/0x191 Mar 1 21:52:18 192.168.254.1 Mar 1 21:52:38 192.168.254.1 [] Mar 1 21:52:58 192.168.254.1 nf_hook_slow+0x99/0xfd Mar 1 21:53:18 192.168.254.1 Mar 1 21:53:38 192.168.254.1 [] Mar 1 21:53:58 192.168.254.1 ip_rcv+0x367/0x466 Mar 1 21:54:18 192.168.254.1 Mar 1 21:54:38 192.168.254.1 [] Mar 1 21:54:58 192.168.254.1 netif_receive_skb+0x194/0x1a9 Mar 1 21:55:18 192.168.254.1 Mar 1 21:55:38 192.168.254.1 [] Mar 1 21:55:58 192.168.254.1 process_backlog+0x77/0xfe Mar 1 21:56:18 192.168.254.1 Mar 1 21:56:38 192.168.254.1 [] Mar 1 21:56:58 192.168.254.1 net_rx_action+0x6a/0xe6 Mar 1 21:57:18 192.168.254.1 Mar 1 21:57:38 192.168.254.1 [] Mar 1 21:57:58 192.168.254.1 __do_softirq+0x45/0x92 Mar 1 21:58:18 192.168.254.1 Mar 1 21:58:38 192.168.254.1 [] Mar 1 21:58:58 192.168.254.1 do_softirq+0x44/0x53 Mar 1 21:59:18 192.168.254.1 Mar 1 21:59:38 192.168.254.1 ======================= Mar 1 21:59:59 192.168.254.1 [] Mar 1 22:00:19 192.168.254.1 do_IRQ+0x61/0x98 Mar 1 22:00:39 192.168.254.1 Mar 1 22:00:59 192.168.254.1 [] Mar 1 22:01:19 192.168.254.1 common_interrupt+0x1a/0x20 Mar 1 22:01:39 192.168.254.1 Mar 1 22:01:59 192.168.254.1 [] Mar 1 22:02:19 192.168.254.1 cpu_idle+0x2a/0x38 Mar 1 22:02:39 192.168.254.1 Mar 1 22:02:59 192.168.254.1 [] Mar 1 22:03:19 192.168.254.1 start_kernel+0x162/0x19c Mar 1 22:03:39 192.168.254.1 Mar 1 22:03:59 192.168.254.1 [] Mar 1 22:04:19 192.168.254.1 0xc010019f Mar 1 22:04:39 192.168.254.1 Mar 1 22:04:59 192.168.254.1 Code: Mar 1 22:05:19 192.168.254.1 3b Mar 1 22:05:39 192.168.254.1 89 Mar 1 22:05:59 192.168.254.1 44 Mar 1 22:06:19 192.168.254.1 24 Mar 1 22:06:39 192.168.254.1 04 Mar 1 22:06:59 192.168.254.1 8b Mar 1 22:07:19 192.168.254.1 55 Mar 1 22:07:39 192.168.254.1 08 Mar 1 22:07:59 192.168.254.1 89 Mar 1 22:08:20 192.168.254.1 14 Mar 1 22:08:40 192.168.254.1 24 Mar 1 22:09:00 192.168.254.1 e8 Mar 1 22:09:20 192.168.254.1 ce Mar 1 22:09:40 192.168.254.1 ca Mar 1 22:10:00 192.168.254.1 fa Mar 1 22:10:20 192.168.254.1 ff Mar 1 22:10:40 192.168.254.1 31 Mar 1 22:11:00 192.168.254.1 d2 Mar 1 22:11:20 192.168.254.1 85 Mar 1 22:11:40 192.168.254.1 c0 Mar 1 22:12:00 192.168.254.1 74 Mar 1 22:12:20 192.168.254.1 33 Mar 1 22:12:40 192.168.254.1 8b Mar 1 22:13:00 192.168.254.1 4d Mar 1 22:13:20 192.168.254.1 08 Mar 1 22:13:40 192.168.254.1 8b Mar 1 22:14:00 192.168.254.1 01 Mar 1 22:14:20 192.168.254.1 8b Mar 1 22:14:40 192.168.254.1 4d Mar 1 22:15:00 192.168.254.1 14 Mar 1 22:15:20 192.168.254.1 03 Mar 1 22:15:40 192.168.254.1 98 Mar 1 22:16:00 192.168.254.1 a8 Mar 1 22:16:20 192.168.254.1 00 Mar 1 22:17:01 192.168.254.1 last message repeated 2 times Mar 1 22:17:21 192.168.254.1 85 Mar 1 22:17:41 192.168.254.1 c9 Mar 1 22:18:01 192.168.254.1 74 Mar 1 22:18:21 192.168.254.1 30 Mar 1 22:18:41 192.168.254.1 8d Mar 1 22:19:01 192.168.254.1 53 Mar 1 22:19:21 192.168.254.1 02 Mar 1 22:20:01 192.168.254.1 76 Mar 1 22:20:21 192.168.254.1 10 Mar 1 22:20:41 192.168.254.1 8b Mar 1 22:21:01 192.168.254.1 4d Mar 1 22:21:21 192.168.254.1 10 Mar 1 22:21:41 192.168.254.1 0f Mar 1 22:22:01 192.168.254.1 b7 Mar 1 22:22:21 192.168.254.1 02 Mar 1 22:22:41 192.168.254.1 83 Mar 1 22:23:01 192.168.254.1 ff Mar 1 22:23:21 192.168.254.1 13 Mar 1 22:23:41 192.168.254.1 66 Mar 1 22:24:01 192.168.254.1 89 Mar 1 22:24:21 192.168.254.1 45 Mar 1 22:24:41 192.168.254.1 f2 Mar 1 22:25:02 192.168.254.1 0f Mar 1 22:25:22 192.168.254.1 b7 Mar 1 22:25:42 192.168.254.1 41 Mar 1 22:26:02 192.168.254.1 04 Mar 1 22:26:22 192.168.254.1 66 Mar 1 22:26:42 192.168.254.1 Mar 1 22:27:02 192.168.254.1 Mar 1 22:27:42 192.168.254.1 Mar 1 22:53:03 h16 -- MARK -- Mar 1 23:13:03 h16 -- MARK -- Mar 1 23:33:03 h16 -- MARK -- Mar 1 23:53:03 h16 -- MARK -- Mar 2 00:13:03 h16 -- MARK -- Mar 2 00:33:03 h16 -- MARK -- Mar 2 00:53:03 h16 -- MARK -- Mar 2 01:13:03 h16 -- MARK -- Mar 2 01:14:21 192.168.254.1 eth0: link down Mar 2 01:14:41 192.168.254.1 eth0: link up, 100Mbps, full-duplex, lpa 0x41E1 Mar 2 01:33:03 h16 -- MARK -- Mar 2 01:53:03 h16 -- MARK -- Mar 2 02:13:03 h16 -- MARK -- Mar 2 02:33:03 h16 -- MARK -- Mar 2 02:53:02 h16 -- MARK -- Mar 2 03:13:02 h16 -- MARK -- Mar 2 03:33:02 h16 -- MARK -- Mar 2 03:53:02 h16 -- MARK -- Mar 2 04:13:02 h16 -- MARK -- Mar 2 04:33:02 h16 -- MARK -- Mar 2 04:53:02 h16 -- MARK -- Mar 2 05:13:02 h16 -- MARK -- Mar 2 05:33:02 h16 -- MARK -- Mar 2 05:53:02 h16 -- MARK -- Mar 2 06:13:02 h16 -- MARK -- Mar 2 06:33:02 h16 -- MARK -- Mar 2 06:53:02 h16 -- MARK -- Mar 2 07:13:02 h16 -- MARK -- Mar 2 07:33:02 h16 -- MARK -- Mar 2 07:53:02 h16 -- MARK -- Mar 2 08:13:02 h16 -- MARK -- Mar 2 08:21:58 192.168.254.1 process `named' is using obsolete setsockopt SO_BSDCOMPAT Mar 2 08:21:58 192.168.254.1 HTB: quantum of class 10010 is small. Consider r2q change. Mar 2 08:21:58 192.168.254.1 HTB: quantum of class 10010 is small. Consider r2q change. Mar 2 08:21:58 192.168.254.1 HTB: quantum of class 10030 is small. Consider r2q change. Mar 2 08:21:58 192.168.254.1 HTB: quantum of class 10030 is small. Consider r2q change. Mar 2 08:21:58 192.168.254.1 HTB: quantum of class 10040 is small. Consider r2q change. Mar 2 08:21:58 192.168.254.1 HTB: quantum of class 10040 is small. Consider r2q change. Mar 2 08:22:03 192.168.254.1 HTB: quantum of class 10100 is small. Consider r2q change. Mar 2 08:22:03 192.168.254.1 HTB: quantum of class 10100 is small. Consider r2q change. Mar 2 08:33:02 h16 -- MARK -- Mar 2 08:53:02 h16 -- MARK -- Mar 2 09:13:01 h16 -- MARK -- Mar 2 09:33:01 h16 -- MARK -- Mar 2 09:53:01 h16 -- MARK -- Mar 2 10:13:01 h16 -- MARK -- Mar 2 10:33:01 h16 -- MARK -- --------------000602010005000704040500-- From kaber@trash.net Wed Mar 2 02:28:52 2005 Received: with ECARTIS (v1.0.0; list netdev); Wed, 02 Mar 2005 02:28:58 -0800 (PST) Received: from kaber.coreworks.de ([62.206.217.67]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j22ASq95012113 for ; Wed, 2 Mar 2005 02:28:52 -0800 Received: from localhost ([127.0.0.1]) by kaber.coreworks.de with esmtp (Exim 4.44) id 1D6R5y-0001yT-PJ; Wed, 02 Mar 2005 11:28:46 +0100 Message-ID: <4225955E.7030306@trash.net> Date: Wed, 02 Mar 2005 11:28:46 +0100 From: Patrick McHardy User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.7.5) Gecko/20050106 Debian/1.7.5-1 X-Accept-Language: en MIME-Version: 1.0 To: Martin Devera CC: netdev@oss.sgi.com Subject: Re: spin_trylock in qdisc_restart, OOPS, IMQ problem ? References: <42258DC6.9030109@cdi.cz> In-Reply-To: <42258DC6.9030109@cdi.cz> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV 0.83/737/Mon Feb 28 22:22:18 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 2227 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: kaber@trash.net Precedence: bulk X-list: netdev Martin Devera wrote: > I've seen some notes in 2.6.11rc3 changelog from Patrick about > issues similar to my OOPS (attached). > Patrick, does the oops ring some bells at your side ? The fixes in 2.6.11-rc3 fixed some new bugs introduced in -rc2. This looks like a problem with non-linear skbs, this patch from Rusty may help: http://linux.bkbits.net:8080/linux-2.6/cset@41db69b71pSJFXrCtc56tffafab_JQ?nav=index.html|src/net/|src/net|src/net/ipv4|src/net/ipv4/netfilter|related/net/ipv4/netfilter/ip_nat_proto_tcp.c Regards Patrick From devik@cdi.cz Wed Mar 2 03:01:44 2005 Received: with ECARTIS (v1.0.0; list netdev); Wed, 02 Mar 2005 03:01:50 -0800 (PST) Received: from www1.cdi.cz (IDENT:8@www1.cdi.cz [194.213.194.49]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j22B1hJx015537 for ; Wed, 2 Mar 2005 03:01:43 -0800 Received: from mail by www1.cdi.cz with spamc (Exim 4.31) id 1D6Rbq-0001gk-76; Wed, 02 Mar 2005 12:01:42 +0100 Received: from ip-85-160-89-87.eurotel.cz ([85.160.89.87] helo=devix) by www1.cdi.cz with asmtp (Exim 4.31) id 1D6Rbn-0001g0-8n; Wed, 02 Mar 2005 12:01:40 +0100 Received: from devix ([127.0.0.1]) by devix with esmtp (Exim 3.16 #8) id 1D6Rbc-0006YJ-00; Wed, 02 Mar 2005 12:01:28 +0100 Message-ID: <42259D08.1060509@cdi.cz> Date: Wed, 02 Mar 2005 12:01:28 +0100 From: Martin Devera User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.5) Gecko/20041217 X-Accept-Language: cs, en-us, en MIME-Version: 1.0 To: Patrick McHardy CC: netdev@oss.sgi.com Subject: Re: spin_trylock in qdisc_restart, OOPS, IMQ problem ? References: <42258DC6.9030109@cdi.cz> <4225955E.7030306@trash.net> In-Reply-To: <4225955E.7030306@trash.net> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV 0.83/737/Mon Feb 28 22:22:18 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 2228 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: devik@cdi.cz Precedence: bulk X-list: netdev Patrick McHardy wrote: > Martin Devera wrote: > >> I've seen some notes in 2.6.11rc3 changelog from Patrick about >> issues similar to my OOPS (attached). >> Patrick, does the oops ring some bells at your side ? > > > The fixes in 2.6.11-rc3 fixed some new bugs introduced in -rc2. This > looks like a problem with non-linear skbs, this patch from Rusty may > help: > > http://linux.bkbits.net:8080/linux-2.6/cset@41db69b71pSJFXrCtc56tffafab_JQ?nav=index.html|src/net/|src/net|src/net/ipv4|src/net/ipv4/netfilter|related/net/ipv4/netfilter/ip_nat_proto_tcp.c Thanks, it seems so, I'll test it. By the way, have you an idea what is going with that spinlocking errors I described in the last mail ? Martin From akpm@osdl.org Wed Mar 2 03:05:16 2005 Received: with ECARTIS (v1.0.0; list netdev); Wed, 02 Mar 2005 03:05:22 -0800 (PST) Received: from smtp.osdl.org (fire.osdl.org [65.172.181.4]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j22B5G9B016208 for ; Wed, 2 Mar 2005 03:05:16 -0800 Received: from shell0.pdx.osdl.net (fw.osdl.org [65.172.181.6]) by smtp.osdl.org (8.12.8/8.12.8) with ESMTP id j22B59qi016888 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO) for ; Wed, 2 Mar 2005 03:05:10 -0800 Received: from bix (shell0.pdx.osdl.net [10.9.0.31]) by shell0.pdx.osdl.net (8.13.1/8.11.6) with SMTP id j22B58jS032114 for ; Wed, 2 Mar 2005 03:05:08 -0800 Date: Wed, 2 Mar 2005 03:04:50 -0800 From: Andrew Morton To: netdev@oss.sgi.com Subject: Fw: [Bugme-new] [Bug 4273] New: eepro100 driver discards (big but valid) packets Message-Id: <20050302030450.2b84b3d2.akpm@osdl.org> X-Mailer: Sylpheed version 0.9.7 (GTK+ 1.2.10; i386-redhat-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Received-SPF: pass (domain of akpm@osdl.org designates 65.172.181.6 as permitted sender) X-MIMEDefang-Filter: osdl$Revision: 1.104 $ X-Scanned-By: MIMEDefang 2.36 X-Virus-Scanned: ClamAV 0.83/737/Mon Feb 28 22:22:18 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 2229 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: akpm@osdl.org Precedence: bulk X-list: netdev Begin forwarded message: Date: Wed, 2 Mar 2005 03:00:42 -0800 From: bugme-daemon@osdl.org To: bugme-new@lists.osdl.org Subject: [Bugme-new] [Bug 4273] New: eepro100 driver discards (big but valid) packets http://bugme.osdl.org/show_bug.cgi?id=4273 Summary: eepro100 driver discards (big but valid) packets Kernel Version: 2.6.10 Status: NEW Severity: normal Owner: jgarzik@pobox.com Submitter: pmarek@cpan.org Distribution: debian unstable Hardware Environment: x86, P4 1,7GHz Software Environment: clean 2.6.10 kernel, cisco vpnclient 4.0.5, 4.0.6 Problem Description: Copied from http://www.cisco.com/en/US/products/sw/secursw/ps2308/prod_release_note09186a00802d398a.html#wp1388727 : CSCee60154 After making a VPN Client connection, some traffic types no longer work. Specifically applications that send large packets like SMTP, HTTP, and SSH. The 2.6.4 Kernel enabled a feature of certain Ethernet cards that discards packets larger than the configured MTU. Since the VPN Client lowers the MTU visible to the applications in order to add its overhead without exceeding the original MTU, the resulting packets are bigger than the newly configured MTU. Therefore the card throws out the large encrypted packets. Steps to reproduce: install vpnclient, use eepro100 driver. try https, http, cvs or something like that. ------- You are receiving this mail because: ------- You are on the CC list for the bug, or are watching someone who is. From ralf@linux-mips.org Wed Mar 2 04:14:38 2005 Received: with ECARTIS (v1.0.0; list netdev); Wed, 02 Mar 2005 04:14:52 -0800 (PST) Received: from mail.linux-mips.net (extgw-uk.mips.com [62.254.210.129]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j22CEbjq024420 for ; Wed, 2 Mar 2005 04:14:38 -0800 Received: from dea.linux-mips.net (localhost.localdomain [127.0.0.1]) by mail.linux-mips.net (8.13.1/8.13.1) with ESMTP id j22CEOVe008287 for ; Wed, 2 Mar 2005 12:14:24 GMT Received: (from ralf@localhost) by dea.linux-mips.net (8.13.1/8.13.1/Submit) id j2296wwb006891 for netdev@oss.sgi.com; Wed, 2 Mar 2005 09:06:58 GMT Date: Wed, 2 Mar 2005 09:06:58 +0000 From: Ralf Baechle To: netdev@oss.sgi.com Subject: [PATCH] Fix ROSE security hole Message-ID: <20050302090658.GA6873@linux-mips.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.4.1i X-Virus-Scanned: ClamAV 0.83/737/Mon Feb 28 22:22:18 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 2230 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: ralf@linux-mips.org Precedence: bulk X-list: netdev ROSE wasn't verifying the ndigis argument of a new route resulting in a minor security hole. Index: bk-afu/net/rose/rose_route.c =================================================================== --- bk-afu.orig/net/rose/rose_route.c 2005-02-05 22:16:25.582983368 +0000 +++ bk-afu/net/rose/rose_route.c 2005-02-05 22:16:25.585982912 +0000 @@ -727,7 +727,8 @@ } if (rose_route.mask > 10) /* Mask can't be more than 10 digits */ return -EINVAL; - + if (rose_route.ndigis > 8) /* No more than 8 digipeats */ + return -EINVAL; err = rose_add_node(&rose_route, dev); dev_put(dev); return err; From ralf@linux-mips.org Wed Mar 2 04:14:37 2005 Received: with ECARTIS (v1.0.0; list netdev); Wed, 02 Mar 2005 04:14:53 -0800 (PST) Received: from mail.linux-mips.net (extgw-uk.mips.com [62.254.210.129]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j22CEaE4024419 for ; Wed, 2 Mar 2005 04:14:37 -0800 Received: from dea.linux-mips.net (localhost.localdomain [127.0.0.1]) by mail.linux-mips.net (8.13.1/8.13.1) with ESMTP id j22CEOVg008287 for ; Wed, 2 Mar 2005 12:14:24 GMT Received: (from ralf@localhost) by dea.linux-mips.net (8.13.1/8.13.1/Submit) id j2292l09006872 for netdev@oss.sgi.com; Wed, 2 Mar 2005 09:02:47 GMT Date: Wed, 2 Mar 2005 09:02:46 +0000 From: Ralf Baechle To: netdev@oss.sgi.com Subject: [PATCH] NET/ROM locking Message-ID: <20050302090246.GA6844@linux-mips.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.4.1i X-Virus-Scanned: ClamAV 0.83/737/Mon Feb 28 22:22:18 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 2231 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: ralf@linux-mips.org Precedence: bulk X-list: netdev Fix deadlock in NET/ROM due to double locking. Index: bk-afu/net/netrom/nr_in.c =================================================================== --- bk-afu.orig/net/netrom/nr_in.c 2005-02-05 22:16:25.553987776 +0000 +++ bk-afu/net/netrom/nr_in.c 2005-02-05 22:16:25.555987472 +0000 @@ -74,7 +74,6 @@ static int nr_state1_machine(struct sock *sk, struct sk_buff *skb, int frametype) { - bh_lock_sock(sk); switch (frametype) { case NR_CONNACK: { nr_cb *nr = nr_sk(sk); @@ -103,8 +102,6 @@ default: break; } - bh_unlock_sock(sk); - return 0; } @@ -116,7 +113,6 @@ static int nr_state2_machine(struct sock *sk, struct sk_buff *skb, int frametype) { - bh_lock_sock(sk); switch (frametype) { case NR_CONNACK | NR_CHOKE_FLAG: nr_disconnect(sk, ECONNRESET); @@ -132,8 +128,6 @@ default: break; } - bh_unlock_sock(sk); - return 0; } @@ -154,7 +148,6 @@ nr = skb->data[18]; ns = skb->data[17]; - bh_lock_sock(sk); switch (frametype) { case NR_CONNREQ: nr_write_internal(sk, NR_CONNACK); @@ -265,12 +258,10 @@ default: break; } - bh_unlock_sock(sk); - return queued; } -/* Higher level upcall for a LAPB frame */ +/* Higher level upcall for a LAPB frame - called with sk locked */ int nr_process_rx_frame(struct sock *sk, struct sk_buff *skb) { nr_cb *nr = nr_sk(sk); From kaber@trash.net Wed Mar 2 04:34:21 2005 Received: with ECARTIS (v1.0.0; list netdev); Wed, 02 Mar 2005 04:34:25 -0800 (PST) Received: from kaber.coreworks.de ([62.206.217.67]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j22CYID5001534 for ; Wed, 2 Mar 2005 04:34:21 -0800 Received: from localhost ([127.0.0.1]) by kaber.coreworks.de with esmtp (Exim 4.44) id 1D6T3M-0002As-5Y; Wed, 02 Mar 2005 13:34:12 +0100 Message-ID: <4225B2C4.70902@trash.net> Date: Wed, 02 Mar 2005 13:34:12 +0100 From: Patrick McHardy User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.7.5) Gecko/20050106 Debian/1.7.5-1 X-Accept-Language: en MIME-Version: 1.0 To: Martin Devera CC: netdev@oss.sgi.com Subject: Re: spin_trylock in qdisc_restart, OOPS, IMQ problem ? References: <42258DC6.9030109@cdi.cz> <4225955E.7030306@trash.net> <42259D08.1060509@cdi.cz> In-Reply-To: <42259D08.1060509@cdi.cz> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV 0.83/737/Mon Feb 28 22:22:18 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 2232 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: kaber@trash.net Precedence: bulk X-list: netdev Martin Devera wrote: > Thanks, it seems so, I'll test it. By the way, have you an idea what is > going with that spinlocking errors I described in the last mail ? netpoll had some locking bugs with printks issued in paths where dev->xmit_lock is already held. IIRC patches to fix this were posted recently. Regards Patrick From Info@Quantum-Sci.com Wed Mar 2 05:13:38 2005 Received: with ECARTIS (v1.0.0; list netdev); Wed, 02 Mar 2005 05:13:44 -0800 (PST) Received: from xeonone.bizarre-host.com (xeonone.bizarre-host.com [70.84.110.116]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j22DDblX003036 for ; Wed, 2 Mar 2005 05:13:37 -0800 Received: from c-24-1-54-54.client.comcast.net ([24.1.54.54] helo=hydra.darkmatter.org) by xeonone.bizarre-host.com with esmtpsa (SSLv3:RC4-MD5:128) (Exim 4.44) id 1D6TfU-000623-R5; Wed, 02 Mar 2005 13:13:36 +0000 From: Quantum Scientific To: usagi-users@linux-ipv6.org Subject: Re: (usagi-users 03232) Re: support of IPv6 by NFS Date: Wed, 2 Mar 2005 07:13:32 -0600 User-Agent: KMail/1.7.1 References: <200503020721.j227Ldir012381@m5p.com> In-Reply-To: <200503020721.j227Ldir012381@m5p.com> Cc: netdev@oss.sgi.com helo: PowerMAC MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200503020713.33133.Info@Quantum-Sci.com> X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - xeonone.bizarre-host.com X-AntiAbuse: Original Domain - oss.sgi.com X-AntiAbuse: Originator/Caller UID/GID - [0 0] / [47 12] X-AntiAbuse: Sender Address Domain - Quantum-Sci.com X-Source: X-Source-Args: X-Source-Dir: X-Virus-Scanned: ClamAV 0.83/742/Tue Mar 1 17:05:59 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 2233 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: Info@Quantum-Sci.com Precedence: bulk X-list: netdev On Wednesday 02 March 2005 1:21, Elliott Mitchell wrote: > >From: Quantum Scientific > > On Tuesday 01 March 2005 19:19, Elliott Mitchell wrote: > > > Relying on your firewall is a very bad idea. There are plenty of attacks > > > you end up allowing through. Patches are a far more critical item. If > > > you are up to date on patches, the firewall isn't important as no packets > > > can harm you. A firewall is a good secondary defense, but not the primary > > > one. > > > > Please be more precise, because I can't imagine what you could be talking > > about. If everything is closed, no packets can pass -- it's that simple. > > Please detail exactly what could possibly pass an ip6tables firewall with a > > policy of DROP, and all incoming ports closed, like this: > > > > Chain INPUT (policy DROP 0 packets, 0 bytes) > > pkts bytes target prot opt in out source destination > > 0 0 ACCEPT all lo * ::/0 ::/0 > > 0 0 LOG all * * ::/0 ::/0 limit: avg 5/min burst 5 LOG flags 0 level 6 > > prefix `***Firewall6 INPUT*** ' > > 0 0 DROP all * * ::/0 ::/0 > > And it is useful having an IPv6 stack on such a machine for? You're not listening. You must be a Republican. The point I've been trying to get across to you is, with connection tracking (which the native 6-stack does not have), - you can send out; - and the response will be allowed back in, even when a is firewall *closed* to incoming as I'd illustrated. This is what connection tracking is. You can close incoming entirely. I just don't know how to say it any clearer. I think 99% of us get it. It goes without saying that one should not rely entirely on a firewall. To assert that I say this is a canard. But the *reason* one should not rely entirely on a firewall is, in case you accidentally open a hole, not because ip6tables is 'weak'! - Of course you should not run services you don't need. - Of course you should set listen to an inside interface when you can. - Of course you should keep software up to date. But you must also DROP everything else, or be completely subject to compromise. Layered security and iptables are scientifically proven. To say that properly-implemented ip6tables are not secure, is just argumentative. Of course, there's the guy who's asking how to subvert packets before they get to ip6tables processing... anybody else wonder why he wants that? Notice there's no real answer? He really knows what he's doing, and can't get through ip6tables. This will be instructive to most. > Patching is of much greater importance than even the best of firewalls. ... > A system without a firewall, but secure software is safe. A system with > a firewall, but insecure software is unsafe. Although updating is important, the above are nutty ideas. Your membership in the Flat Earth Society(tm) is confirmed. Your salary will henceforth be paid in Confederate dollars, your medical insurance revoked (it's socialist), and your retirement invested in the stock market. Remember: "War is peace. Freedom is slavery. Ignorance is strength." {goes to rent Fahrenheit 451 and The Handmaiden's Tale} > There could be a buffer overflow in the device driver. There could be an > overflow in code between the driver netfilter code. These two places are > unlikely as they're constructed carefully, but it could happen. You could > also have a hole in how your system log handling software which could be > triggered through the above firewall. Been a while since the last one, > but such holes have been found before, and that are doesn't tend to get > as much scrutiny as the kernel. In order for a buffer overflow to be of use to an attacker, he must be able to instigate it, and inject his own code... when was the last time you've heard of a NIC driver sploit? Who's going to work for weeks on this, when there are thousands of machines like yours out there, only filtering SYN. These are not risks for a properly firewalled machine. I'm getting the idea you have this opinion because you had constructed a poor firewall and been compromised. This is why I wish Shorewall would take up the mantle. Elliott, I've been hoping you are sincere in this discussion, but it now appears you are just trolling. I've had enough of you. Carl Cook From bennybbz@yahoo.fr Wed Mar 2 05:38:34 2005 Received: with ECARTIS (v1.0.0; list netdev); Wed, 02 Mar 2005 05:38:38 -0800 (PST) Received: from web26610.mail.ukl.yahoo.com (web26610.mail.ukl.yahoo.com [217.146.176.60]) by oss.sgi.com (8.13.0/8.13.0) with SMTP id j22DcXqA008534 for ; Wed, 2 Mar 2005 05:38:34 -0800 Received: (qmail 45234 invoked by uid 60001); 2 Mar 2005 13:38:28 -0000 Message-ID: <20050302133828.45232.qmail@web26610.mail.ukl.yahoo.com> Received: from [63.87.1.243] by web26610.mail.ukl.yahoo.com via HTTP; Wed, 02 Mar 2005 14:38:28 CET Date: Wed, 2 Mar 2005 14:38:28 +0100 (CET) From: BZ Benny Subject: creating a netdevice To: netdev@oss.sgi.com MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Virus-Scanned: ClamAV 0.83/742/Tue Mar 1 17:05:59 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 2234 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: bennybbz@yahoo.fr Precedence: bulk X-list: netdev Hi I want to create a network interface from the user space, is it possible? regards bennny Découvrez le nouveau Yahoo! Mail : 250 Mo d'espace de stockage pour vos mails ! Créez votre Yahoo! Mail sur http://fr.mail.yahoo.com/ From buytenh@wantstofly.org Wed Mar 2 05:48:26 2005 Received: with ECARTIS (v1.0.0; list netdev); Wed, 02 Mar 2005 05:48:31 -0800 (PST) Received: from xi.wantstofly.org (alephnull.demon.nl [212.238.201.82]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j22DmPY2009270 for ; Wed, 2 Mar 2005 05:48:26 -0800 Received: by xi.wantstofly.org (Postfix, from userid 500) id 1ECD52B0EC; Wed, 2 Mar 2005 14:48:24 +0100 (MET) Date: Wed, 2 Mar 2005 14:48:24 +0100 From: Lennert Buytenhek To: Jeff Garzik Cc: Netdev Subject: Re: Intel and TOE in the news Message-ID: <20050302134824.GA20304@xi.wantstofly.org> References: <4216B62D.6000502@pobox.com> <20050219041007.GA17896@xi.wantstofly.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20050219041007.GA17896@xi.wantstofly.org> User-Agent: Mutt/1.4.1i X-Virus-Scanned: ClamAV 0.83/742/Tue Mar 1 17:05:59 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 2235 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: buytenh@wantstofly.org Precedence: bulk X-list: netdev On Sat, Feb 19, 2005 at 05:10:07AM +0100, Lennert Buytenhek wrote: > > Intel plans to sidestep the need for separate TOE cards by building this > > technology into its server processor package - the chip itself, chipset > > and network controller. This should reduce some of the time a processor > > typically spends waiting for memory to feed back information and improve > > overall application processing speeds. > > I wonder if they could just take the network processing circuitry from > the IXP2800 (an extra 16-core (!) RISCy processor on-die, dedicated to > doing just network stuff, and a 10gbps pipe going straight into the CPU > itself) and graft it onto the Xeon. It indeed appears to be something like the IXP2000. http://www.intel.com/technology/ioacceleration/index.htm Quote from ServerNetworkIOAccel.pdf (which is otherwise content-free): Lightweight Threading [...] Rather than providing multiple hardware contexts in a processor like Hyper-Threading (HT) Technology from Intel, a single hardware context contains the network stack with multiple software-controlled threads. When a packet thread triggers a memory event a scheduler within the network stack selects an alternate packet thread and loads the CPU execution pipeline. Porcessing continues in the shadow of a memory access. [...] Stall conditions, triggered by requests to slow memory devices, are nearly eliminated. They can also DMA packet headers straight into L1/L2 ('Direct Cache Access', innovation!), just like other products have been able to do for ages now. Not much other details up yet. --L From vda@port.imtp.ilyichevsk.odessa.ua Wed Mar 2 06:03:44 2005 Received: with ECARTIS (v1.0.0; list netdev); Wed, 02 Mar 2005 06:03:49 -0800 (PST) Received: from port.imtp.ilyichevsk.odessa.ua (168.imtp.Ilyichevsk.Odessa.UA [195.66.192.168] (may be forged)) by oss.sgi.com (8.13.0/8.13.0) with SMTP id j22E3Hht010368 for ; Wed, 2 Mar 2005 06:03:36 -0800 Received: (qmail 1856 invoked by alias); 2 Mar 2005 14:03:01 -0000 Received: from unknown (195.66.192.167) by 0 (195.66.192.168) with ESMTP; 02 Mar 2005 14:03:01 -0000 From: Denis Vlasenko To: Jeff Garzik Subject: Re: Kernel 2.6 IPV6 Busted Date: Wed, 2 Mar 2005 16:02:53 +0200 User-Agent: KMail/1.5.4 Cc: "David S. Miller" , Quantum Scientific , netdev@oss.sgi.com References: <200502270928.44402.Info@Quantum-Sci.com> <200503011207.34029.vda@port.imtp.ilyichevsk.odessa.ua> <422497BA.9090606@pobox.com> In-Reply-To: <422497BA.9090606@pobox.com> MIME-Version: 1.0 Content-Type: text/plain; charset="koi8-r" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200503021602.53663.vda@port.imtp.ilyichevsk.odessa.ua> X-Virus-Scanned: ClamAV 0.83/742/Tue Mar 1 17:05:59 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 2236 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: vda@port.imtp.ilyichevsk.odessa.ua Precedence: bulk X-list: netdev On Tuesday 01 March 2005 18:26, Jeff Garzik wrote: > >>There are many very important optimizations we've had to disable > >>by default just in TCP alone because of NAT. > > > > I don't think future Internet will be safe enough to open > > corporate networks. I definitely won't do it. > > NAT firewall in front of my net is an absolute requirement > > for me. > > > > However, IPv6 in Internet won't happen tomorrow, > > no rush... > > You don't need NAT to secure a corporate network. I don't want outside world to even KNOW that I have a network behind the firewall box. I don't want them to know internal hosts' IPs. -- vda From bunk@stusta.de Wed Mar 2 06:08:42 2005 Received: with ECARTIS (v1.0.0; list netdev); Wed, 02 Mar 2005 06:08:47 -0800 (PST) Received: from mailout.stusta.mhn.de (mailout.stusta.mhn.de [141.84.69.5]) by oss.sgi.com (8.13.0/8.13.0) with SMTP id j22E8eo7011005 for ; Wed, 2 Mar 2005 06:08:41 -0800 Received: (qmail 13358 invoked from network); 2 Mar 2005 14:08:34 -0000 Received: from r063144.stusta.swh.mhn.de (10.150.63.144) by mailhub.stusta.mhn.de with SMTP; 2 Mar 2005 14:08:34 -0000 Received: by r063144.stusta.swh.mhn.de (Postfix, from userid 1000) id 01D63BB816; Wed, 2 Mar 2005 15:08:33 +0100 (CET) Date: Wed, 2 Mar 2005 15:08:33 +0100 From: Adrian Bunk To: Jeff Garzik Cc: Andrew Morton , netdev@oss.sgi.com, linux-kernel@vger.kernel.org Subject: Re: [2.6.11-rc4-mm1 patch] fix buggy IEEE80211_CRYPT_* selects Message-ID: <20050302140833.GD4608@stusta.de> References: <20050223014233.6710fd73.akpm@osdl.org> <20050226113123.GJ3311@stusta.de> <42256078.1040002@pobox.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <42256078.1040002@pobox.com> User-Agent: Mutt/1.5.6+20040907i X-Virus-Scanned: ClamAV 0.83/742/Tue Mar 1 17:05:59 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 2237 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: bunk@stusta.de Precedence: bulk X-list: netdev On Wed, Mar 02, 2005 at 01:43:04AM -0500, Jeff Garzik wrote: > Adrian Bunk wrote: > >+ select CRYPTO > > select CRYPTO_AES > > ---help--- > > Include software based cipher suites in support of IEEE 802.11i > > (aka TGi, WPA, WPA2, WPA-PSK, etc.) for use with CCMP enabled > > networks. > >@@ -54,10 +55,11 @@ > > "ieee80211_crypt_ccmp". > > > > config IEEE80211_CRYPT_TKIP > > tristate "IEEE 802.11i TKIP encryption" > > depends on IEEE80211 > >+ select CRYPTO > > select CRYPTO_MICHAEL_MIC > > > 'select CRYPTO_AES' should 'select CRYPTO' automatically, I would hope. This would result in a recursive dependency. > Jeff cu Adrian -- "Is there not promise of rain?" Ling Tan asked suddenly out of the darkness. There had been need of rain for many days. "Only a promise," Lao Er said. Pearl S. Buck - Dragon Seed From pj@sgi.com Wed Mar 2 06:53:12 2005 Received: with ECARTIS (v1.0.0; list netdev); Wed, 02 Mar 2005 06:53:21 -0800 (PST) Received: from omx1.americas.sgi.com (omx1-ext.sgi.com [192.48.179.11]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j22Er398013094 for ; Wed, 2 Mar 2005 06:53:05 -0800 Received: from nodin.corp.sgi.com (nodin.corp.sgi.com [192.26.51.193]) by omx1.americas.sgi.com (8.12.10/8.12.9/linux-outbound_gateway-1.1) with ESMTP id j22Er2xT012921 for ; Wed, 2 Mar 2005 08:53:03 -0600 Received: from cthulhu.engr.sgi.com (cthulhu.engr.sgi.com [192.26.80.2]) by nodin.corp.sgi.com (SGI-8.12.5/8.12.10/SGI_generic_relay-1.2) with ESMTP id j22Er2bT41697245 for ; Wed, 2 Mar 2005 06:53:02 -0800 (PST) Received: from vpn2 (mtv-vpn-hw-pj-2.corp.sgi.com [134.15.25.219]) by cthulhu.engr.sgi.com (SGI-8.12.5/8.12.5) with SMTP id j22Epr0g30256889; Wed, 2 Mar 2005 06:51:53 -0800 (PST) Date: Wed, 2 Mar 2005 06:51:52 -0800 From: Paul Jackson To: Guillaume Thouvenin Cc: akpm@osdl.org, linux-kernel@vger.kernel.org, johnpol@2ka.mipt.ru, elsa-devel@lists.sourceforge.net, jlan@engr.sgi.com, gh@us.ibm.com, efocht@hpce.nec.com, netdev@oss.sgi.com, kaigai@ak.jp.nec.com Subject: Re: [PATCH 2.6.11-rc4-mm1] connector: Add a fork connector Message-Id: <20050302065152.79d9fba2.pj@sgi.com> In-Reply-To: <1109753292.8422.117.camel@frecb000711.frec.bull.fr> References: <1109240677.1738.196.camel@frecb000711.frec.bull.fr> <1109753292.8422.117.camel@frecb000711.frec.bull.fr> Organization: SGI X-Mailer: Sylpheed version 1.0.0 (GTK+ 1.2.10; i686-pc-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV 0.83/742/Tue Mar 1 17:05:59 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 2238 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: pj@sgi.com Precedence: bulk X-list: netdev Guillaume wrote: > > I also run the lmbench and results are send in response to another > thread "A common layer for Accounting packages". When fork connector is > turned off the overhead is negligible. Good. If I read this code right: > > +static inline void fork_connector(pid_t parent, pid_t child) > +{ > + static DEFINE_SPINLOCK(cn_fork_lock); > + static __u32 seq; /* used to test if message is lost */ > + > + if (cn_fork_enable) { then the code executed if the fork connector is off is a call to an inline function that tests an integer, finds it zero, and returns. This is sufficiently little code that I for one would hardly even need lmbench to be comfortable that fork() wasn't impacted seriously, in the case that the fork connector is disabled. -- I won't rest till it's the best ... Programmer, Linux Scalability Paul Jackson 1.650.933.1373, 1.925.600.0401 From jeroen@unfix.org Wed Mar 2 07:29:51 2005 Received: with ECARTIS (v1.0.0; list netdev); Wed, 02 Mar 2005 07:29:56 -0800 (PST) Received: from noc.sixxs.net (postfix@noc.sixxs.net [213.197.29.32]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j22FTojx014657 for ; Wed, 2 Mar 2005 07:29:51 -0800 Received: from localhost (localhost [127.0.0.1]) by noc.sixxs.net (Postfix) with ESMTP id 8F54824061; Wed, 2 Mar 2005 16:29:44 +0100 (CET) Received: from noc.sixxs.net ([127.0.0.1]) by localhost (noc [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 14359-09; Wed, 2 Mar 2005 16:29:44 +0100 (CET) Received: from firenze.zurich.ibm.com (pat.zurich.ibm.com [195.176.20.45]) (using SSLv3 with cipher RC4-MD5 (128/128 bits)) (No client certificate requested) by noc.sixxs.net (Postfix) with ESMTP id 2444F2400D; Wed, 2 Mar 2005 16:29:44 +0100 (CET) Subject: Re: (usagi-users 03234) Re: support of IPv6 by NFS From: Jeroen Massar To: usagi-users@linux-ipv6.org Cc: netdev@oss.sgi.com In-Reply-To: <200503020713.33133.Info@Quantum-Sci.com> References: <200503020721.j227Ldir012381@m5p.com> <200503020713.33133.Info@Quantum-Sci.com> Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="=-U3/aXNwvcqoFErbsrLHf" Organization: Unfix Date: Wed, 02 Mar 2005 16:29:41 +0100 Message-Id: <1109777381.17484.206.camel@firenze.zurich.ibm.com> Mime-Version: 1.0 X-Mailer: Evolution 2.1.5 (2.1.5-1) X-Virus-Scanned: ClamAV 0.83/742/Tue Mar 1 17:05:59 2005 on oss.sgi.com X-Virus-Scanned: noc.sixxs.net - http://www.sixxs.net X-Virus-Status: Clean X-archive-position: 2239 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: jeroen@unfix.org Precedence: bulk X-list: netdev --=-U3/aXNwvcqoFErbsrLHf Content-Type: text/plain Content-Transfer-Encoding: quoted-printable On Wed, 2005-03-02 at 07:13 -0600, Quantum Scientific wrote: >On Wednesday 02 March 2005 1:21, Elliott Mitchell wrote: >> >From: Quantum Scientific >> > On Tuesday 01 March 2005 19:19, Elliott Mitchell wrote: >You're not listening. You must be a Republican. Very technical. >Of course, there's the guy who's asking how to subvert packets before they= get=20 >to ip6tables processing... anybody else wonder why he wants that? Notice= =20 >there's no real answer? He really knows what he's doing, and can't get=20 >through ip6tables. This will be instructive to most. Which guy is asking this? Everybody, at least when you are a bit into kernel programming, that you can do this at a couple of levels and all of these are inside the kernel (driver, network layers) + hardware and of course the cable itself. >=20 >> Patching is of much greater importance than even the best of firewalls. >... >> A system without a firewall, but secure software is safe. A system with >> a firewall, but insecure software is unsafe. > >Although updating is important, the above are nutty ideas. Your membershi= p in=20 >the Flat Earth Society(tm) is confirmed. Your salary will henceforth be p= aid=20 >in Confederate dollars, your medical insurance revoked (it's socialist), a= nd=20 >your retirement invested in the stock market. Remember: "War is peace. =20 >Freedom is slavery. Ignorance is strength." > {goes to rent Fahrenheit 451 and The Handmaiden's Tale} Whee, free money! :) > >> There could be a buffer overflow in the device driver. There could be an >> overflow in code between the driver netfilter code. These two places are >> unlikely as they're constructed carefully, but it could happen. You coul= d >> also have a hole in how your system log handling software which could be >> triggered through the above firewall. Been a while since the last one, >> but such holes have been found before, and that are doesn't tend to get >> as much scrutiny as the kernel. > >In order for a buffer overflow to be of use to an attacker, he must be abl= e to=20 >instigate it, and inject his own code... when was the last time you've he= ard=20 >of a NIC driver sploit? Who's going to work for weeks on this, when there= =20 >are thousands of machines like yours out there, only filtering SYN. What is bad with filtering SYN? >These=20 >are not risks for a properly firewalled machine. Ever run a PIX or FW1? Ask them how nice it was that when they learned about the magic of fragments and the nice ways you can circument them. Good that we don't have IP fragments anymore now. Still keeps TCP fragments though. Ever heard about tunneling over DNS and many other ways of circumventing firewalls? Ever read Full-Disclosure, ever been to a security conference, read a good security paper? I'd suggest you do so. Computers are not like houses, then again, maybe you can compare a firewall to a lock that you can open with a crowbar ;) > I'm getting the idea you=20 >have this opinion because you had constructed a poor firewall and been=20 >compromised. This is why I wish Shorewall would take up the mantle. I don't even use firewalling, except for dropping sources that should not exist in the first place. Then again my apps nicely behave on the correct ports and interfaces :) >Elliott, I've been hoping you are sincere in this discussion, but it now=20 >appears you are just trolling. I've had enough of you. > >Carl Cook Very nice to call someone a troll when you are named "Cook" :) Really, personal attacks don't help your non-technical arguments and trying to insult people. Btw, where are the 'back-comments' about me? Everybody knows that IPv6 is still in development, accept that, it will come, but it is not here today. Puncto. Greets, Jeroen --=-U3/aXNwvcqoFErbsrLHf Content-Type: application/pgp-signature; name=signature.asc Content-Description: This is a digitally signed message part -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.0 (GNU/Linux) Comment: Jeroen Massar / http://unfix.org/~jeroen/ iD8DBQBCJdvlKaooUjM+fCMRAntNAKCQtxcX+QIrJzSmh+VyjEWHXZsZowCfXHfd 8UdLeAFNrrRal+Lt7CbUGng= =Efpb -----END PGP SIGNATURE----- --=-U3/aXNwvcqoFErbsrLHf-- From pj@sgi.com Wed Mar 2 07:32:33 2005 Received: with ECARTIS (v1.0.0; list netdev); Wed, 02 Mar 2005 07:32:38 -0800 (PST) Received: from omx2.sgi.com (omx2-ext.sgi.com [192.48.171.19]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j22FVRw9015034 for ; Wed, 2 Mar 2005 07:31:27 -0800 Received: from cthulhu.engr.sgi.com (cthulhu.engr.sgi.com [192.26.80.2]) by omx2.sgi.com (8.12.11/8.12.9/linux-outbound_gateway-1.1) with ESMTP id j22H4K9I027162 for ; Wed, 2 Mar 2005 09:04:30 -0800 Received: from vpn2 (mtv-vpn-hw-pj-2.corp.sgi.com [134.15.25.219]) by cthulhu.engr.sgi.com (SGI-8.12.5/8.12.5) with SMTP id j22FUk0g30283417; Wed, 2 Mar 2005 07:30:46 -0800 (PST) Date: Wed, 2 Mar 2005 07:30:45 -0800 From: Paul Jackson To: Andrew Morton Cc: guillaume.thouvenin@bull.net, kaigai@ak.jp.nec.com, johnpol@2ka.mipt.ru, hadi@cyberus.ca, tgraf@suug.ch, marcelo.tosatti@cyclades.com, davem@redhat.com, jlan@sgi.com, lse-tech@lists.sourceforge.net, linux-kernel@vger.kernel.org, netdev@oss.sgi.com, elsa-devel@lists.sourceforge.net Subject: Re: [Lse-tech] Re: A common layer for Accounting packages Message-Id: <20050302073045.4dfefa11.pj@sgi.com> In-Reply-To: <20050302010614.2a8bb483.akpm@osdl.org> References: <4221E548.4000008@ak.jp.nec.com> <20050227140355.GA23055@logos.cnet> <42227AEA.6050002@ak.jp.nec.com> <1109575236.8549.14.camel@frecb000711.frec.bull.fr> <20050227233943.6cb89226.akpm@osdl.org> <1109592658.2188.924.camel@jzny.localdomain> <20050228132051.GO31837@postel.suug.ch> <1109598010.2188.994.camel@jzny.localdomain> <20050228135307.GP31837@postel.suug.ch> <1109599803.2188.1014.camel@jzny.localdomain> <20050228142551.GQ31837@postel.suug.ch> <1109604693.1072.8.camel@jzny.localdomain> <20050228191759.6f7b656e@zanzibar.2ka.mipt.ru> <1109665299.8594.55.camel@frecb000711.frec.bull.fr> <42247051.7070303@ak.jp.nec.com> <1109753893.8422.127.camel@frecb000711.frec.bull.fr> <20050302010614.2a8bb483.akpm@osdl.org> Organization: SGI X-Mailer: Sylpheed version 1.0.0 (GTK+ 1.2.10; i686-pc-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV 0.83/742/Tue Mar 1 17:05:59 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 2240 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: pj@sgi.com Precedence: bulk X-list: netdev Andrew wrote: > 5-10% slowdown on fork is expected, but > why was exec slower? Thanks for the summary, Andrew. Guillaume (or anyone else tempted to do this) - it's a good idea, when posting 100 lines of data, to summarize with a line or two of words, as Andrew did here. It is far more efficient for one writer to do this, than each of a thousand readers. Hmmm ... so why was exec slower? -- I won't rest till it's the best ... Programmer, Linux Scalability Paul Jackson 1.650.933.1373, 1.925.600.0401 From pj@sgi.com Wed Mar 2 07:51:09 2005 Received: with ECARTIS (v1.0.0; list netdev); Wed, 02 Mar 2005 07:51:19 -0800 (PST) Received: from omx1.americas.sgi.com (omx1-ext.sgi.com [192.48.179.11]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j22Fp3YT019448 for ; Wed, 2 Mar 2005 07:51:04 -0800 Received: from cthulhu.engr.sgi.com (cthulhu.engr.sgi.com [192.26.80.2]) by omx1.americas.sgi.com (8.12.10/8.12.9/linux-outbound_gateway-1.1) with ESMTP id j22Fp3xT023726 for ; Wed, 2 Mar 2005 09:51:03 -0600 Received: from vpn2 (mtv-vpn-hw-pj-2.corp.sgi.com [134.15.25.219]) by cthulhu.engr.sgi.com (SGI-8.12.5/8.12.5) with SMTP id j22Fp00g30222430; Wed, 2 Mar 2005 07:51:01 -0800 (PST) Date: Wed, 2 Mar 2005 07:50:55 -0800 From: Paul Jackson To: Guillaume Thouvenin Cc: akpm@osdl.org, linux-kernel@vger.kernel.org, johnpol@2ka.mipt.ru, elsa-devel@lists.sourceforge.net, jlan@engr.sgi.com, gh@us.ibm.com, efocht@hpce.nec.com, netdev@oss.sgi.com, kaigai@ak.jp.nec.com Subject: Re: [PATCH 2.6.11-rc4-mm1] connector: Add a fork connector Message-Id: <20050302075055.53207b1b.pj@sgi.com> In-Reply-To: <1109753292.8422.117.camel@frecb000711.frec.bull.fr> References: <1109240677.1738.196.camel@frecb000711.frec.bull.fr> <1109753292.8422.117.camel@frecb000711.frec.bull.fr> Organization: SGI X-Mailer: Sylpheed version 1.0.0 (GTK+ 1.2.10; i686-pc-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV 0.83/742/Tue Mar 1 17:05:59 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 2241 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: pj@sgi.com Precedence: bulk X-list: netdev In addition to worrying about performance and scaling, with accounting enabled or disabled, one should also try to minimize code clutter in key kernel files, such as fork.c For example, one might, instead of adding 40 lines os fork_connector() code to kernel/fork.c, instead add something like just the #include and the "fork_connector(current->pid, p->pid)" call to kernel/fork.c, where include/linux/connector.h had something like: #ifdef CONFIG_FORK_CONNECTOR static inline void fork_connector(pid_t parent, pid_t child) { if (cn_fork_enable) __fork_connector(parent, child); } #else static inline void fork_connector(pid_t parent, pid_t child) {} #endif Then bury the interesting code in the implementation of __fork_connector(), in drivers/connector/cn_fork.c or some such place. This adds a real function call in the case that cn_fork_enable is set. That code path requires more than that anyway (and it makes kernel stack backtraces more transparent). But it removes 40 lines of fork_connector detail from fork.c. And it avoids marking a 40 line routine as inline ... -- I won't rest till it's the best ... Programmer, Linux Scalability Paul Jackson 1.650.933.1373, 1.925.600.0401 From mmporter@cox.net Wed Mar 2 08:29:29 2005 Received: with ECARTIS (v1.0.0; list netdev); Wed, 02 Mar 2005 08:29:34 -0800 (PST) Received: from fed1rmmtao11.cox.net (fed1rmmtao11.cox.net [68.230.241.28]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j22GTTxY024351 for ; Wed, 2 Mar 2005 08:29:29 -0800 Received: from liberty.homelinux.org ([68.2.41.86]) by fed1rmmtao11.cox.net (InterMail vM.6.01.04.00 201-2131-118-20041027) with ESMTP id <20050302162919.VIWH22013.fed1rmmtao11.cox.net@liberty.homelinux.org>; Wed, 2 Mar 2005 11:29:19 -0500 Received: (from mmporter@localhost) by liberty.homelinux.org (8.9.3/8.9.3/Debian 8.9.3-21) id JAA31511; Wed, 2 Mar 2005 09:29:18 -0700 Date: Wed, 2 Mar 2005 09:29:18 -0700 From: Matt Porter To: Jeff Garzik Cc: netdev@oss.sgi.com, linuxppc-embedded@ozlabs.org Subject: Re: [PATCH] emac: filter illegal frame sizes Message-ID: <20050302092918.A30946@cox.net> References: <20050218101245.D11439@cox.net> <4216FD64.9020509@pobox.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <4216FD64.9020509@pobox.com>; from jgarzik@pobox.com on Sat, Feb 19, 2005 at 03:48:36AM -0500 X-Virus-Scanned: ClamAV 0.83/742/Tue Mar 1 17:05:59 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 2242 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: mporter@kernel.crashing.org Precedence: bulk X-list: netdev On Sat, Feb 19, 2005 at 03:48:36AM -0500, Jeff Garzik wrote: > Matt Porter wrote: > > Fix to drop frames that are too large for the current MTU. > > What is this fixing? > > You should be passing all frames up to the software stack. I was originally fixing the issue where the driver was only allocating rx buffers big enough for the configured MTU and got a bit overzealous. I pulled out the filtering hunks so we always allocate skbs large enough to handle a full size jumbo frame and pass everything up to the stack...new patch to follow. -Matt From mmporter@cox.net Wed Mar 2 08:32:54 2005 Received: with ECARTIS (v1.0.0; list netdev); Wed, 02 Mar 2005 08:32:59 -0800 (PST) Received: from fed1rmmtao03.cox.net (fed1rmmtao03.cox.net [68.230.241.36]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j22GWqKW025109 for ; Wed, 2 Mar 2005 08:32:54 -0800 Received: from liberty.homelinux.org ([68.2.41.86]) by fed1rmmtao03.cox.net (InterMail vM.6.01.04.00 201-2131-118-20041027) with ESMTP id <20050302163246.WPHM1282.fed1rmmtao03.cox.net@liberty.homelinux.org>; Wed, 2 Mar 2005 11:32:46 -0500 Received: (from mmporter@localhost) by liberty.homelinux.org (8.9.3/8.9.3/Debian 8.9.3-21) id JAA31553; Wed, 2 Mar 2005 09:32:45 -0700 Date: Wed, 2 Mar 2005 09:32:45 -0700 From: Matt Porter To: jgarzik@pobox.com Cc: netdev@oss.sgi.com, linuxppc-embedded@ozlabs.org Subject: [PATCH] emac: fix skb allocation for full-size jumbo frames Message-ID: <20050302093245.B30946@cox.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i X-Virus-Scanned: ClamAV 0.83/742/Tue Mar 1 17:05:59 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 2243 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: mporter@kernel.crashing.org Precedence: bulk X-list: netdev Sets jumbo frame handling based on MTU and allocates rx buffers large to handle full-size jumbo frames. Signed-off-by: Matt Porter ===== drivers/net/ibm_emac/ibm_emac_core.c 1.9 vs edited ===== --- 1.9/drivers/net/ibm_emac/ibm_emac_core.c 2005-01-20 13:25:10 -07:00 +++ edited/drivers/net/ibm_emac/ibm_emac_core.c 2005-02-18 09:23:08 -07:00 @@ -1041,7 +1056,7 @@ /* set speed (default is 10Mb) */ switch (speed) { case SPEED_1000: - mode_reg |= EMAC_M1_JUMBO_ENABLE | EMAC_M1_RFS_16K; + mode_reg |= EMAC_M1_RFS_16K; if (fep->rgmii_dev) { struct ibm_ocp_rgmii *rgmii = RGMII_PRIV(fep->rgmii_dev); @@ -1118,6 +1133,7 @@ { struct ocp_enet_private *fep = dev->priv; int old_mtu = dev->mtu; + unsigned long mode_reg; emac_t *emacp = fep->emacp; u32 em0mr0; int i, full; @@ -1160,10 +1176,17 @@ fep->rx_skb[i] = NULL; } - /* Set new rx_buffer_size and advertise new mtu */ - fep->rx_buffer_size = - new_mtu + ENET_HEADER_SIZE + ENET_FCS_SIZE; + /* Set new rx_buffer_size, jumbo cap, and advertise new mtu */ + mode_reg = in_be32(&emacp->em0mr1); + if (new_mtu > ENET_DEF_MTU_SIZE) { + mode_reg |= EMAC_M1_JUMBO_ENABLE; + fep->rx_buffer_size = EMAC_MAX_FRAME; + } else { + mode_reg &= ~EMAC_M1_JUMBO_ENABLE; + fep->rx_buffer_size = ENET_DEF_BUF_SIZE; + } dev->mtu = new_mtu; + out_be32(&emacp->em0mr1, mode_reg); /* Re-init rx skbs */ fep->rx_slot = 0; ===== drivers/net/ibm_emac/ibm_emac_core.h 1.3 vs edited ===== --- 1.3/drivers/net/ibm_emac/ibm_emac_core.h 2005-02-08 22:24:52 -07:00 +++ edited/drivers/net/ibm_emac/ibm_emac_core.h 2005-02-18 09:30:07 -07:00 @@ -77,6 +77,8 @@ #define ENET_HEADER_SIZE 14 #define ENET_FCS_SIZE 4 +#define ENET_DEF_MTU_SIZE 1500 +#define ENET_DEF_BUF_SIZE (ENET_DEF_MTU_SIZE + ENET_HEADER_SIZE + ENET_FCS_SIZE) #define EMAC_MIN_FRAME 64 #define EMAC_MAX_FRAME 9018 #define EMAC_MIN_MTU (EMAC_MIN_FRAME - ENET_HEADER_SIZE - ENET_FCS_SIZE) From akpm@osdl.org Wed Mar 2 09:19:55 2005 Received: with ECARTIS (v1.0.0; list netdev); Wed, 02 Mar 2005 09:20:01 -0800 (PST) Received: from smtp.osdl.org (fire.osdl.org [65.172.181.4]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j22HJtHN029339 for ; Wed, 2 Mar 2005 09:19:55 -0800 Received: from shell0.pdx.osdl.net (fw.osdl.org [65.172.181.6]) by smtp.osdl.org (8.12.8/8.12.8) with ESMTP id j22HJQqi016426 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO); Wed, 2 Mar 2005 09:19:27 -0800 Received: from bix (shell0.pdx.osdl.net [10.9.0.31]) by shell0.pdx.osdl.net (8.13.1/8.11.6) with SMTP id j22HJQb0013433; Wed, 2 Mar 2005 09:19:26 -0800 Date: Wed, 2 Mar 2005 09:19:07 -0800 From: Andrew Morton To: netdev@oss.sgi.com Cc: jgoerzen@complete.org Subject: Fw: [Bugme-new] [Bug 4274] New: ipv6: Unknown symbol tcp_timer_bug_msg Message-Id: <20050302091907.19bb2b2e.akpm@osdl.org> X-Mailer: Sylpheed version 0.9.7 (GTK+ 1.2.10; i386-redhat-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Received-SPF: pass (domain of akpm@osdl.org designates 65.172.181.6 as permitted sender) X-MIMEDefang-Filter: osdl$Revision: 1.104 $ X-Scanned-By: MIMEDefang 2.36 X-Virus-Scanned: ClamAV 0.83/742/Tue Mar 1 17:05:59 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 2244 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: akpm@osdl.org Precedence: bulk X-list: netdev Begin forwarded message: Date: Wed, 2 Mar 2005 09:15:18 -0800 From: bugme-daemon@osdl.org To: bugme-new@lists.osdl.org Subject: [Bugme-new] [Bug 4274] New: ipv6: Unknown symbol tcp_timer_bug_msg http://bugme.osdl.org/show_bug.cgi?id=4274 Summary: ipv6: Unknown symbol tcp_timer_bug_msg Kernel Version: 2.6.11 Status: NEW Severity: normal Owner: yoshfuji@linux-ipv6.org Submitter: jgoerzen@complete.org Distribution: Debian sid Hardware Environment: alpha Software Environment: Problem Description: modprobe ipv6 fails with: ipv6: Unknown symbol tcp_timer_bug_msg I saw this back on a previous version and submitted #3717 at the time. The patch attached to that bug worked. However, 2.6.11 appears to include that patch, and yet, I'm still getting this problem. I will attach my config file. Please let me know if you need any other information. Thanks, John Goerzen ------- You are receiving this mail because: ------- You are on the CC list for the bug, or are watching someone who is. From yoshfuji@wide.ad.jp Wed Mar 2 09:35:42 2005 Received: with ECARTIS (v1.0.0; list netdev); Wed, 02 Mar 2005 09:35:47 -0800 (PST) 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 j22HZdcd031342 for ; Wed, 2 Mar 2005 09:35:42 -0800 Received: from localhost (localhost [127.0.0.1]) by yue.st-paulia.net (Postfix) with ESMTP id EE0E833CC2; Thu, 3 Mar 2005 02:37:08 +0900 (JST) Date: Thu, 03 Mar 2005 02:37:06 +0900 (JST) Message-Id: <20050303.023706.64945563.yoshfuji@wide.ad.jp> To: akpm@osdl.org, jgoerzen@complete.org Cc: netdev@oss.sgi.com Subject: Re: [Bugme-new] [Bug 4274] New: ipv6: Unknown symbol tcp_timer_bug_msg From: YOSHIFUJI Hideaki / =?iso-2022-jp?B?GyRCNUhGIzFRTEAbKEI=?= In-Reply-To: <20050302091907.19bb2b2e.akpm@osdl.org> References: <20050302091907.19bb2b2e.akpm@osdl.org> X-URL: http://www.yoshifuji.org/%7Ehideaki/ X-Fingerprint: 90 22 65 EB 1E CF 3A D1 0B DF 80 D8 48 07 F8 94 E0 62 0E EA X-PGP-Key-URL: http://www.yoshifuji.org/%7Ehideaki/hideaki@yoshifuji.org.asc X-Mailer: Mew version 2.2 on Emacs 20.7 / Mule 4.1 (AOI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV 0.83/742/Tue Mar 1 17:05:59 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 2245 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: yoshfuji@wide.ad.jp Precedence: bulk X-list: netdev In article <20050302091907.19bb2b2e.akpm@osdl.org> (at Wed, 2 Mar 2005 09:19:07 -0800), Andrew Morton says: > modprobe ipv6 fails with: > > ipv6: Unknown symbol tcp_timer_bug_msg Please try this. Signed-off-by: Hideaki YOSHIFUJI ===== net/ipv4/tcp_timer.c 1.30 vs edited ===== --- 1.30/net/ipv4/tcp_timer.c 2005-02-23 03:45:32 +09:00 +++ edited/net/ipv4/tcp_timer.c 2005-03-03 02:26:20 +09:00 @@ -38,6 +38,7 @@ #ifdef TCP_DEBUG const char tcp_timer_bug_msg[] = KERN_DEBUG "tcpbug: unknown timer value\n"; +EXPORT_SYMBOL(tcp_timer_bug_msg); #endif /* -- Hideaki YOSHIFUJI @ USAGI Project GPG FP: 9022 65EB 1ECF 3AD1 0BDF 80D8 4807 F894 E062 0EEA From leonid.grossman@neterion.com Wed Mar 2 09:36:06 2005 Received: with ECARTIS (v1.0.0; list netdev); Wed, 02 Mar 2005 09:36:12 -0800 (PST) Received: from ns1.s2io.com (ns1.s2io.com [142.46.200.198]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j22Ha5Fd031447 for ; Wed, 2 Mar 2005 09:36:06 -0800 Received: from guinness.s2io.com (sentry.s2io.com [142.46.200.199]) by ns1.s2io.com (8.12.10/8.12.10) with ESMTP id j22HZwdG004691; Wed, 2 Mar 2005 12:35:58 -0500 (EST) Received: from lgt40 ([10.16.16.75]) by guinness.s2io.com (8.12.6/8.12.6) with ESMTP id j22HZuDD020120; Wed, 2 Mar 2005 12:35:57 -0500 (EST) Message-Id: <200503021735.j22HZuDD020120@guinness.s2io.com> From: "Leonid Grossman" To: "'Lennert Buytenhek'" , "'Jeff Garzik'" Cc: "'Netdev'" Subject: RE: Intel and TOE in the news Date: Wed, 2 Mar 2005 09:34:58 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook, Build 11.0.5510 In-Reply-To: <20050302134824.GA20304@xi.wantstofly.org> Thread-Index: AcUfLof3u/VMAHjBQ+iBWRutqs1rXAAG8VEw X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1409 X-Scanned-By: MIMEDefang 2.34 X-Virus-Scanned: ClamAV 0.83/742/Tue Mar 1 17:05:59 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 2246 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: leonid.grossman@neterion.com Precedence: bulk X-list: netdev > -----Original Message----- > From: netdev-bounce@oss.sgi.com > [mailto:netdev-bounce@oss.sgi.com] On Behalf Of Lennert Buytenhek > Sent: Wednesday, March 02, 2005 5:48 AM > To: Jeff Garzik > Cc: Netdev > Subject: Re: Intel and TOE in the news > > On Sat, Feb 19, 2005 at 05:10:07AM +0100, Lennert Buytenhek wrote: > > > > Intel plans to sidestep the need for separate TOE cards > by building > > > this technology into its server processor package - the > chip itself, > > > chipset and network controller. This should reduce some > of the time > > > a processor typically spends waiting for memory to feed back > > > information and improve overall application processing speeds. > > > > I wonder if they could just take the network processing > circuitry from > > the IXP2800 (an extra 16-core (!) RISCy processor on-die, > dedicated to > > doing just network stuff, and a 10gbps pipe going straight into the > > CPU > > itself) and graft it onto the Xeon. > > It indeed appears to be something like the IXP2000. > > http://www.intel.com/technology/ioacceleration/index.htm > > Quote from ServerNetworkIOAccel.pdf (which is otherwise content-free): > > Lightweight Threading > > [...] Rather than providing multiple hardware contexts in a > processor like Hyper-Threading (HT) Technology from Intel, a > single hardware context contains the network stack with > multiple software-controlled threads. When a packet > thread triggers a memory event a scheduler within the network > stack selects an alternate packet thread and loads the CPU > execution pipeline. Porcessing continues in the shadow of a > memory access. [...] Stall conditions, triggered by requests > to slow memory devices, are nearly eliminated. > > They can also DMA packet headers straight into L1/L2 ('Direct > Cache Access', innovation!), just like other products have > been able to do for ages now. > > Not much other details up yet. It was a good presentation, I suspect some/most of you guys may be able to get it through your company attendees. At any rate, don't worry - details will probably come out soon enough since kernel support should be a "must have" for the entire concept to work :-) On the NIC side, I suspect we will not see much in I/O AT GbE comparing to what we are already shipping as 10GbE Xframe ASIC features (header separation for potential prefetching, stateless/state aware offloads, etc.) - the feat would be to make these assists a de-facto standard (so both NIC vendors and kernel developers have motivation to support'em) and fully utilize them by integrating with the rest of the hw/OS in the system; I'm actually very happy to see Intel pushing this ... Leonid > > > --L > > From jbarnes@engr.sgi.com Wed Mar 2 09:51:10 2005 Received: with ECARTIS (v1.0.0; list netdev); Wed, 02 Mar 2005 09:51:19 -0800 (PST) Received: from omx2.sgi.com (omx2-ext.sgi.com [192.48.171.19]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j22Ho2P2032681 for ; Wed, 2 Mar 2005 09:50:02 -0800 Received: from nodin.corp.sgi.com (nodin.corp.sgi.com [192.26.51.193]) by omx2.sgi.com (8.12.11/8.12.9/linux-outbound_gateway-1.1) with ESMTP id j22JMtFf000720 for ; Wed, 2 Mar 2005 11:23:05 -0800 Received: from cthulhu.engr.sgi.com (cthulhu.engr.sgi.com [192.26.80.2]) by nodin.corp.sgi.com (SGI-8.12.5/8.12.10/SGI_generic_relay-1.2) with ESMTP id j22HnVbT34926969 for ; Wed, 2 Mar 2005 09:49:31 -0800 (PST) Received: from spamtin.engr.sgi.com (postfix@spamtin.engr.sgi.com [163.154.6.130]) by cthulhu.engr.sgi.com (SGI-8.12.5/8.12.5) with ESMTP id j22HmS0g30301410; Wed, 2 Mar 2005 09:48:28 -0800 (PST) Received: by spamtin.engr.sgi.com (Postfix, from userid 35197) id BCB9F1C08019; Wed, 2 Mar 2005 09:48:27 -0800 (PST) From: Jesse Barnes To: Paul Jackson Subject: Re: [PATCH 2.6.11-rc4-mm1] connector: Add a fork connector Date: Wed, 2 Mar 2005 09:48:26 -0800 User-Agent: KMail/1.7.2 Cc: Guillaume Thouvenin , akpm@osdl.org, linux-kernel@vger.kernel.org, johnpol@2ka.mipt.ru, elsa-devel@lists.sourceforge.net, jlan@engr.sgi.com, gh@us.ibm.com, efocht@hpce.nec.com, netdev@oss.sgi.com, kaigai@ak.jp.nec.com References: <1109240677.1738.196.camel@frecb000711.frec.bull.fr> <1109753292.8422.117.camel@frecb000711.frec.bull.fr> <20050302065152.79d9fba2.pj@sgi.com> In-Reply-To: <20050302065152.79d9fba2.pj@sgi.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200503020948.27263.jbarnes@engr.sgi.com> X-Virus-Scanned: ClamAV 0.83/742/Tue Mar 1 17:05:59 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 2247 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: jbarnes@engr.sgi.com Precedence: bulk X-list: netdev On Wednesday, March 2, 2005 6:51 am, Paul Jackson wrote: > Guillaume wrote: > > I also run the lmbench and results are send in response to another > > thread "A common layer for Accounting packages". When fork connector is > > turned off the overhead is negligible. > > Good. > > If I read this code right: > > +static inline void fork_connector(pid_t parent, pid_t child) > > +{ > > + static DEFINE_SPINLOCK(cn_fork_lock); > > + static __u32 seq; /* used to test if message is lost */ > > + > > + if (cn_fork_enable) { > > then the code executed if the fork connector is off is a call to an > inline function that tests an integer, finds it zero, and returns. > > This is sufficiently little code that I for one would hardly > even need lmbench to be comfortable that fork() wasn't impacted > seriously, in the case that the fork connector is disabled. But if it *is* enabled, it takes a global lock on every fork. That can't scale on a big multiprocessor if lots of CPUs are doing lots of forks... Jesse From rddunlap@osdl.org Wed Mar 2 10:08:39 2005 Received: with ECARTIS (v1.0.0; list netdev); Wed, 02 Mar 2005 10:08:43 -0800 (PST) Received: from smtp.osdl.org (fire.osdl.org [65.172.181.4]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j22I8cah001255 for ; Wed, 2 Mar 2005 10:08:39 -0800 Received: from shell0.pdx.osdl.net (fw.osdl.org [65.172.181.6]) by smtp.osdl.org (8.12.8/8.12.8) with ESMTP id j22I8Uqi021216 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO); Wed, 2 Mar 2005 10:08:30 -0800 Received: from gargoyle.pdx.osdl.net (gargoyle.pdx.osdl.net [172.20.1.49]) by shell0.pdx.osdl.net (8.13.1/8.11.6) with SMTP id j22I8UNH015993; Wed, 2 Mar 2005 10:08:30 -0800 Date: Wed, 2 Mar 2005 10:09:17 -0800 From: "Randy.Dunlap" To: netdev , jgarzik Cc: torvalds , akpm Subject: [PATCH] tulip/de2104x: don't mix __init & __devinit sections Message-Id: <20050302100917.4115855e.rddunlap@osdl.org> Organization: OSDL X-Mailer: Sylpheed version 0.9.12 (GTK+ 1.2.10; i386-vine-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Received-SPF: pass (domain of rddunlap@osdl.org designates 65.172.181.6 as permitted sender) X-MIMEDefang-Filter: osdl$Revision: 1.104 $ X-Scanned-By: MIMEDefang 2.36 X-Virus-Scanned: ClamAV 0.83/742/Tue Mar 1 17:05:59 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 2248 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: rddunlap@osdl.org Precedence: bulk X-list: netdev (take 2, based on Jeff's comment) tulip/de2104x: fix section usage, don't mix __init & __devinit: Error: ./drivers/net/tulip/de2104x.o .text refers to 000000000000176d R_X86_64_PC32 .init.text+0xfffffffffffffffc Error: ./drivers/net/tulip/de2104x.o .text refers to 0000000000001798 R_X86_64_PC32 .init.text+0xfffffffffffffffc Signed-off-by: Randy Dunlap diffstat:= drivers/net/tulip/de2104x.c | 2 +- 1 files changed, 1 insertion(+), 1 deletion(-) diff -Naurp ./drivers/net/tulip/de2104x.c~de2104x_sections ./drivers/net/tulip/de2104x.c --- ./drivers/net/tulip/de2104x.c~de2104x_sections 2005-02-27 12:54:05.830037144 -0800 +++ ./drivers/net/tulip/de2104x.c 2005-03-02 09:49:13.533933000 -0800 @@ -1927,7 +1927,7 @@ bad_srom: goto fill_defaults; } -static int __devinit de_init_one (struct pci_dev *pdev, +static int __init de_init_one (struct pci_dev *pdev, const struct pci_device_id *ent) { struct net_device *dev; --- From shemminger@osdl.org Wed Mar 2 10:10:28 2005 Received: with ECARTIS (v1.0.0; list netdev); Wed, 02 Mar 2005 10:10:31 -0800 (PST) Received: from smtp.osdl.org (fire.osdl.org [65.172.181.4]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j22IARv0001777 for ; Wed, 2 Mar 2005 10:10:28 -0800 Received: from shell0.pdx.osdl.net (fw.osdl.org [65.172.181.6]) by smtp.osdl.org (8.12.8/8.12.8) with ESMTP id j22IALqi021323 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO); Wed, 2 Mar 2005 10:10:21 -0800 Received: from dxpl.pdx.osdl.net (dxpl.pdx.osdl.net [172.20.1.103]) by shell0.pdx.osdl.net (8.13.1/8.11.6) with ESMTP id j22IAKHZ016065; Wed, 2 Mar 2005 10:10:21 -0800 Date: Wed, 2 Mar 2005 10:10:35 -0800 From: Stephen Hemminger To: "David S. Miller" Cc: netdev@oss.sgi.com Subject: [PATCH] remove dead skb_iter code Message-ID: <20050302101035.61786113@dxpl.pdx.osdl.net> Organization: Open Source Development Lab X-Mailer: Sylpheed-Claws 1.0.1 (GTK+ 1.2.10; x86_64-unknown-linux-gnu) X-Face: &@E+xe?c%:&e4D{>f1O<&U>2qwRREG5!}7R4;D<"NO^UI2mJ[eEOA2*3>(`Th.yP,VDPo9$ /`~cw![cmj~~jWe?AHY7D1S+\}5brN0k*NE?pPh_'_d>6;XGG[\KDRViCfumZT3@[ Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Received-SPF: pass (domain of shemminger@osdl.org designates 65.172.181.6 as permitted sender) X-MIMEDefang-Filter: osdl$Revision: 1.104 $ X-Scanned-By: MIMEDefang 2.36 X-Virus-Scanned: ClamAV 0.83/742/Tue Mar 1 17:05:59 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 2249 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: shemminger@osdl.org Precedence: bulk X-list: netdev The code iterate over skb_frags is defined but not used by any existing kernel code. Signed-off-by: Stephen Hemminger diff -Nru a/include/linux/skbuff.h b/include/linux/skbuff.h --- a/include/linux/skbuff.h 2005-03-02 10:13:14 -08:00 +++ b/include/linux/skbuff.h 2005-03-02 10:13:14 -08:00 @@ -1118,22 +1118,6 @@ extern void skb_init(void); extern void skb_add_mtu(int mtu); -struct skb_iter { - /* Iteration functions set these */ - unsigned char *data; - unsigned int len; - - /* Private to iteration */ - unsigned int nextfrag; - struct sk_buff *fraglist; -}; - -/* Keep iterating until skb_iter_next returns false. */ -extern void skb_iter_first(const struct sk_buff *skb, struct skb_iter *i); -extern int skb_iter_next(const struct sk_buff *skb, struct skb_iter *i); -/* Call this if aborting loop before !skb_iter_next */ -extern void skb_iter_abort(const struct sk_buff *skb, struct skb_iter *i); - #ifdef CONFIG_NETFILTER static inline void nf_conntrack_put(struct nf_conntrack *nfct) { diff -Nru a/net/core/skbuff.c b/net/core/skbuff.c --- a/net/core/skbuff.c 2005-03-02 10:13:14 -08:00 +++ b/net/core/skbuff.c 2005-03-02 10:13:14 -08:00 @@ -982,70 +982,6 @@ return -EFAULT; } -/* Keep iterating until skb_iter_next returns false. */ -void skb_iter_first(const struct sk_buff *skb, struct skb_iter *i) -{ - i->len = skb_headlen(skb); - i->data = (unsigned char *)skb->data; - i->nextfrag = 0; - i->fraglist = NULL; -} - -int skb_iter_next(const struct sk_buff *skb, struct skb_iter *i) -{ - /* Unmap previous, if not head fragment. */ - if (i->nextfrag) - kunmap_skb_frag(i->data); - - if (i->fraglist) { - fraglist: - /* We're iterating through fraglist. */ - if (i->nextfrag < skb_shinfo(i->fraglist)->nr_frags) { - i->data = kmap_skb_frag(&skb_shinfo(i->fraglist) - ->frags[i->nextfrag]); - i->len = skb_shinfo(i->fraglist)->frags[i->nextfrag] - .size; - i->nextfrag++; - return 1; - } - /* Fragments with fragments? Too hard! */ - BUG_ON(skb_shinfo(i->fraglist)->frag_list); - i->fraglist = i->fraglist->next; - if (!i->fraglist) - goto end; - - i->len = skb_headlen(i->fraglist); - i->data = i->fraglist->data; - i->nextfrag = 0; - return 1; - } - - if (i->nextfrag < skb_shinfo(skb)->nr_frags) { - i->data = kmap_skb_frag(&skb_shinfo(skb)->frags[i->nextfrag]); - i->len = skb_shinfo(skb)->frags[i->nextfrag].size; - i->nextfrag++; - return 1; - } - - i->fraglist = skb_shinfo(skb)->frag_list; - if (i->fraglist) - goto fraglist; - -end: - /* Bug trap for callers */ - i->data = NULL; - return 0; -} - -void skb_iter_abort(const struct sk_buff *skb, struct skb_iter *i) -{ - /* Unmap previous, if not head fragment. */ - if (i->data && i->nextfrag) - kunmap_skb_frag(i->data); - /* Bug trap for callers */ - i->data = NULL; -} - /* Checksum skb data. */ unsigned int skb_checksum(const struct sk_buff *skb, int offset, @@ -1516,6 +1452,3 @@ EXPORT_SYMBOL(skb_unlink); EXPORT_SYMBOL(skb_append); EXPORT_SYMBOL(skb_split); -EXPORT_SYMBOL(skb_iter_first); -EXPORT_SYMBOL(skb_iter_next); -EXPORT_SYMBOL(skb_iter_abort); From rddunlap@osdl.org Wed Mar 2 10:12:13 2005 Received: with ECARTIS (v1.0.0; list netdev); Wed, 02 Mar 2005 10:12:16 -0800 (PST) Received: from smtp.osdl.org (fire.osdl.org [65.172.181.4]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j22ICDfh002305 for ; Wed, 2 Mar 2005 10:12:13 -0800 Received: from shell0.pdx.osdl.net (fw.osdl.org [65.172.181.6]) by smtp.osdl.org (8.12.8/8.12.8) with ESMTP id j22IBwqi021516 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO); Wed, 2 Mar 2005 10:11:58 -0800 Received: from gargoyle.pdx.osdl.net (gargoyle.pdx.osdl.net [172.20.1.49]) by shell0.pdx.osdl.net (8.13.1/8.11.6) with SMTP id j22IBvws016205; Wed, 2 Mar 2005 10:11:57 -0800 Date: Wed, 2 Mar 2005 10:12:44 -0800 From: "Randy.Dunlap" To: timofeev@granch.ru, jgarzik Cc: netdev , torvalds , akpm Subject: [PATCH] net/wan/sbni: fix section usage Message-Id: <20050302101244.4499d97c.rddunlap@osdl.org> Organization: OSDL X-Mailer: Sylpheed version 0.9.12 (GTK+ 1.2.10; i386-vine-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Received-SPF: pass (domain of rddunlap@osdl.org designates 65.172.181.6 as permitted sender) X-MIMEDefang-Filter: osdl$Revision: 1.104 $ X-Scanned-By: MIMEDefang 2.36 X-Virus-Scanned: ClamAV 0.83/742/Tue Mar 1 17:05:59 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 2250 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: rddunlap@osdl.org Precedence: bulk X-list: netdev net/wan/sbni data reference can be initdata: Error: ./drivers/net/wan/sbni.o .data refers to 0000000000000000 R_X86_64_64 .init.data+0x0000000000000060 Error: ./drivers/net/wan/sbni.o .data refers to 0000000000000008 R_X86_64_64 .init.data+0x0000000000000140 Error: ./drivers/net/wan/sbni.o .data refers to 0000000000000010 R_X86_64_64 .init.data+0x0000000000000180 Error: ./drivers/net/wan/sbni.o .data refers to 0000000000000018 R_X86_64_64 .init.data+0x0000000000000020 Error: ./drivers/net/wan/sbni.o .data refers to 0000000000000020 R_X86_64_64 .init.data+0x00000000000001c0 Signed-off-by: Randy Dunlap diffstat:= drivers/net/wan/sbni.c | 2 +- 1 files changed, 1 insertion(+), 1 deletion(-) diff -Naurp ./drivers/net/wan/sbni.c~wan_sbni_sections ./drivers/net/wan/sbni.c --- ./drivers/net/wan/sbni.c~wan_sbni_sections 2005-02-27 12:54:05.851033952 -0800 +++ ./drivers/net/wan/sbni.c 2005-03-02 09:45:09.156084080 -0800 @@ -176,7 +176,7 @@ static u32 mac[ SBNI_MAX_NUM_CARDS ] __ #ifndef MODULE typedef u32 iarr[]; -static iarr *dest[5] = { &io, &irq, &baud, &rxl, &mac }; +static iarr __initdata *dest[5] = { &io, &irq, &baud, &rxl, &mac }; #endif /* A zero-terminated list of I/O addresses to be probed on ISA bus */ --- From Valdis.Kletnieks@vt.edu Wed Mar 2 10:14:57 2005 Received: with ECARTIS (v1.0.0; list netdev); Wed, 02 Mar 2005 10:15:01 -0800 (PST) Received: from turing-police.cc.vt.edu (turing-police.cc.vt.edu [128.173.14.107]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j22IEvEV002869 for ; Wed, 2 Mar 2005 10:14:57 -0800 Received: from turing-police.cc.vt.edu (turing-police.cc.vt.edu [127.0.0.1]) by turing-police.cc.vt.edu (8.13.3/8.13.3) with ESMTP id j22IEl9S021789; Wed, 2 Mar 2005 13:14:49 -0500 Message-Id: <200503021814.j22IEl9S021789@turing-police.cc.vt.edu> X-Mailer: exmh version 2.7.2 01/07/2005 with nmh-1.1-RC3 To: usagi-users@linux-ipv6.org Cc: netdev@oss.sgi.com Subject: Re: (usagi-users 03234) Re: support of IPv6 by NFS In-Reply-To: Your message of "Wed, 02 Mar 2005 07:13:32 CST." <200503020713.33133.Info@Quantum-Sci.com> From: Valdis.Kletnieks@vt.edu References: <200503020721.j227Ldir012381@m5p.com> <200503020713.33133.Info@Quantum-Sci.com> Mime-Version: 1.0 Content-Type: multipart/signed; boundary="==_Exmh_1109787286_6557P"; micalg=pgp-sha1; protocol="application/pgp-signature" Content-Transfer-Encoding: 7bit Date: Wed, 02 Mar 2005 13:14:47 -0500 X-Virus-Scanned: ClamAV 0.83/742/Tue Mar 1 17:05:59 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 2251 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: Valdis.Kletnieks@vt.edu Precedence: bulk X-list: netdev --==_Exmh_1109787286_6557P Content-Type: text/plain; charset=us-ascii On Wed, 02 Mar 2005 07:13:32 CST, Quantum Scientific said: > It goes without saying that one should not rely entirely on a firewall. To > assert that I say this is a canard. But the *reason* one should not rely > entirely on a firewall is, in case you accidentally open a hole, not because > ip6tables is 'weak'! Hey, the reason you're taking all the flames here is because *YOU* are the one who said that the IPv6 stuff was "unusable" because it didn't have a firewall that did connection tracking. If it's something you shouldn't be relying on, the lack of it doesn't render something (in your own words): > After a week of intensive research and full-time study, it's become clear that > IPV6 support, as it comes in standard Linux 2.6 kernels, is effectively > non-functional. So the lack of something you "should not rely on entirely" makes it "effectively non-functional". Right. --==_Exmh_1109787286_6557P Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.0 (GNU/Linux) Comment: Exmh version 2.5 07/13/2001 iD8DBQFCJgKWcC3lWbTT17ARAllKAKCY10726EyirK1MbEjEErl5VAAApQCg2iJ9 U6OqOEPvNCUp4Ygy4DR89Fc= =3mu3 -----END PGP SIGNATURE----- --==_Exmh_1109787286_6557P-- From davem@davemloft.net Wed Mar 2 10:23:02 2005 Received: with ECARTIS (v1.0.0; list netdev); Wed, 02 Mar 2005 10:23:07 -0800 (PST) Received: from cheetah.davemloft.net (mail@dsl027-180-174.sfo1.dsl.speakeasy.net [216.27.180.174]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j22IN1pd003634 for ; Wed, 2 Mar 2005 10:23:02 -0800 Received: from localhost ([127.0.0.1] helo=cheetah.davemloft.net ident=davem) by cheetah.davemloft.net with smtp (Exim 3.36 #1 (Debian)) id 1D6YSP-0005l8-00; Wed, 02 Mar 2005 10:20:25 -0800 Date: Wed, 2 Mar 2005 10:20:25 -0800 From: "David S. Miller" To: Stephen Hemminger Cc: netdev@oss.sgi.com Subject: Re: [PATCH] remove dead skb_iter code Message-Id: <20050302102025.23f479f9.davem@davemloft.net> In-Reply-To: <20050302101035.61786113@dxpl.pdx.osdl.net> References: <20050302101035.61786113@dxpl.pdx.osdl.net> X-Mailer: Sylpheed version 1.0.1 (GTK+ 1.2.10; sparc-unknown-linux-gnu) X-Face: "_;p5u5aPsO,_Vsx"^v-pEq09'CU4&Dc1$fQExov$62l60cgCc%FnIwD=.UF^a>?5'9Kn[;433QFVV9M..2eN.@4ZWPGbdi<=?[:T>y?SD(R*-3It"Vj:)"dP Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV 0.83/742/Tue Mar 1 17:05:59 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 2252 X-ecartis-version: Ecartis v1.0.0 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, 2 Mar 2005 10:10:35 -0800 Stephen Hemminger wrote: > The code iterate over skb_frags is defined but not used by any > existing kernel code. > > Signed-off-by: Stephen Hemminger Rusty and co.'s planned netfilter packet parsing code will use the iterators. Send a patch to add a comment to this effect or something as I'm tired of folks trying to remove this code. :-) From akohlsmith@mixdown.ca Wed Mar 2 10:50:19 2005 Received: with ECARTIS (v1.0.0; list netdev); Wed, 02 Mar 2005 10:50:22 -0800 (PST) Received: from gromit.mixdown.ca (otherbrotherk-fw.mixdown.ca [165.154.13.35] (may be forged)) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j22IoIHj004972 for ; Wed, 2 Mar 2005 10:50:19 -0800 Received: from localhost (localhost [127.0.0.1]) by gromit.mixdown.ca (Postfix) with ESMTP id 006AF21356E9 for ; Wed, 2 Mar 2005 13:56:41 -0500 (EST) From: Andrew Kohlsmith To: netdev@oss.sgi.com Subject: Re: 2.6.10 and HTB dequeue bug Date: Wed, 2 Mar 2005 13:50:11 -0500 User-Agent: KMail/1.8 References: <200503011403.07243.akohlsmith@mixdown.ca> <4224FEAF.2090209@tpack.net> In-Reply-To: <4224FEAF.2090209@tpack.net> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200503021350.11588.akohlsmith@mixdown.ca> X-Virus-Scanned: ClamAV 0.83/742/Tue Mar 1 17:05:59 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 2253 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: akohlsmith@mixdown.ca Precedence: bulk X-list: netdev On March 1, 2005 06:45 pm, Tommy Christensen wrote: > An overflow of q->direct_queue (in htb_enqueue) seems to offset > sch->q.qlen. Probably this is what's causing htb_dequeue to complain. Got a couple more of these in the last 12h: HTB: dequeue bug (8,204417247,204417247), report it please ! htb*g j=204417247 lj=204417247 htb*r7 m=0 htb*r6 m=0 htb*r5 m=0 htb*r4 m=0 htb*r3 m=0 htb*r2 m=0 htb*r1 m=0 htb*r0 m=0 htb*c10001 m=2 t=25845 c=25845 pq=0 df=50061 ql=0 pa=0 f: htb*c10010 m=2 t=295682 c=27708 pq=0 df=254102 ql=0 pa=0 f: htb*c10020 m=2 t=77441 c=28542 pq=0 df=13990637 ql=0 pa=0 f: htb*c10030 m=2 t=77441 c=28542 pq=0 df=50061 ql=0 pa=0 f: htb*c10040 m=2 t=303504 c=28402 pq=0 df=337098 ql=0 pa=0 f: htb*c10050 m=2 t=-122209 c=28402 pq=0 df=123725 ql=0 pa=0 f: and HTB: dequeue bug (8,204418247,204418247), report it please ! htb*g j=204418247 lj=204418247 htb*r7 m=0 htb*r6 m=0 htb*r5 m=0 htb*r4 m=0 htb*r3 m=0 htb*r2 m=0 htb*r1 m=0 htb*r0 m=0 htb*c10001 m=2 t=23769 c=23769 pq=0 df=41413 ql=0 pa=0 f: htb*c10010 m=2 t=295682 c=27708 pq=0 df=237057 ql=0 pa=0 f: htb*c10020 m=2 t=77441 c=28542 pq=0 df=15556450 ql=0 pa=0 f: htb*c10030 m=2 t=70844 c=26230 pq=0 df=41413 ql=0 pa=0 f: htb*c10040 m=2 t=303504 c=28402 pq=0 df=532505 ql=0 pa=0 f: htb*c10050 m=2 t=283166 c=26595 pq=0 df=702201 ql=0 pa=0 f: Just posting them in case they can help. The archives for this list don't seem to be showing my messages and I'm not (yet) subscribed, so please CC any replies directly. Regards, Andrew From shemminger@osdl.org Wed Mar 2 10:58:55 2005 Received: with ECARTIS (v1.0.0; list netdev); Wed, 02 Mar 2005 10:58:59 -0800 (PST) Received: from smtp.osdl.org (fire.osdl.org [65.172.181.4]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j22Iwsv8005793 for ; Wed, 2 Mar 2005 10:58:55 -0800 Received: from shell0.pdx.osdl.net (fw.osdl.org [65.172.181.6]) by smtp.osdl.org (8.12.8/8.12.8) with ESMTP id j22Iwmqi026655 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO); Wed, 2 Mar 2005 10:58:48 -0800 Received: from dxpl.pdx.osdl.net (dxpl.pdx.osdl.net [172.20.1.103]) by shell0.pdx.osdl.net (8.13.1/8.11.6) with ESMTP id j22Iwl8m018751; Wed, 2 Mar 2005 10:58:47 -0800 Date: Wed, 2 Mar 2005 10:59:02 -0800 From: Stephen Hemminger To: "David S. Miller" Cc: netdev@oss.sgi.com Subject: [PATCH] remove dead extern's in netdevice.h Message-ID: <20050302105902.72f2b983@dxpl.pdx.osdl.net> Organization: Open Source Development Lab X-Mailer: Sylpheed-Claws 1.0.1 (GTK+ 1.2.10; x86_64-unknown-linux-gnu) X-Face: &@E+xe?c%:&e4D{>f1O<&U>2qwRREG5!}7R4;D<"NO^UI2mJ[eEOA2*3>(`Th.yP,VDPo9$ /`~cw![cmj~~jWe?AHY7D1S+\}5brN0k*NE?pPh_'_d>6;XGG[\KDRViCfumZT3@[ Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Received-SPF: pass (domain of shemminger@osdl.org designates 65.172.181.6 as permitted sender) X-MIMEDefang-Filter: osdl$Revision: 1.104 $ X-Scanned-By: MIMEDefang 2.36 X-Virus-Scanned: ClamAV 0.83/742/Tue Mar 1 17:05:59 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 2254 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: shemminger@osdl.org Precedence: bulk X-list: netdev The following definitions are historical relics. Signed-off-by: Stephen Hemminger diff -Nru a/include/linux/netdevice.h b/include/linux/netdevice.h --- a/include/linux/netdevice.h 2005-03-02 10:53:22 -08:00 +++ b/include/linux/netdevice.h 2005-03-02 10:53:22 -08:00 @@ -921,8 +921,6 @@ extern void dev_mcast_init(void); extern int netdev_max_backlog; extern int weight_p; -extern unsigned long netdev_fc_xoff; -extern atomic_t netdev_dropping; extern int netdev_set_master(struct net_device *dev, struct net_device *master); extern int skb_checksum_help(struct sk_buff *skb, int inward); /* rx skb timestamps */ From sri@us.ibm.com Wed Mar 2 11:02:24 2005 Received: with ECARTIS (v1.0.0; list netdev); Wed, 02 Mar 2005 11:02:29 -0800 (PST) Received: from e31.co.us.ibm.com (e31.co.us.ibm.com [32.97.110.129]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j22J2N5Z006362 for ; Wed, 2 Mar 2005 11:02:23 -0800 Received: from westrelay02.boulder.ibm.com (westrelay02.boulder.ibm.com [9.17.195.11]) by e31.co.us.ibm.com (8.12.10/8.12.9) with ESMTP id j22J2Gua446256 for ; Wed, 2 Mar 2005 14:02:16 -0500 Received: from d03av02.boulder.ibm.com (d03av02.boulder.ibm.com [9.17.195.168]) by westrelay02.boulder.ibm.com (8.12.10/NCO/VER6.6) with ESMTP id j22J2GdB146728 for ; Wed, 2 Mar 2005 12:02:16 -0700 Received: from d03av02.boulder.ibm.com (loopback [127.0.0.1]) by d03av02.boulder.ibm.com (8.12.11/8.12.11) with ESMTP id j22J2GAx010700 for ; Wed, 2 Mar 2005 12:02:16 -0700 Received: from sig-9-65-50-149.mts.ibm.com (sig-9-65-50-149.mts.ibm.com [9.65.50.149]) by d03av02.boulder.ibm.com (8.12.11/8.12.11) with ESMTP id j22J2CMn010358; Wed, 2 Mar 2005 12:02:14 -0700 Date: Thu, 3 Mar 2005 00:32:12 +0530 (IST) From: Sridhar Samudrala X-X-Sender: sridhar@localhost.localdomain To: davem@davemloft.net cc: nhorman@redhat.com, netdev@oss.sgi.com, lksctp-developers@lists.sourceforge.net Subject: [Patch] sctp: add receive buffer accounting to sctp (fwd) Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Virus-Scanned: ClamAV 0.83/742/Tue Mar 1 17:05:59 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 2255 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: sri@us.ibm.com Precedence: bulk X-list: netdev Dave, Please apply the following SCTP patch submitted by Neil. Signed-off-by: Sridhar Samudrala Thanks Sridhar ---------- Forwarded message ---------- Date: Tue, 1 Mar 2005 13:34:06 -0500 From: nhorman@redhat.com To: lksctp-developers@lists.sourceforge.net Cc: sri@us.ibm.com Subject: [Patch] sctp: add receive buffer accounting to sctp Patch to add recieve buffer accounting to sctp. Current implmentation is open to DOS attack, which can result in lowmem exhaustion, due to chunk backlog queuing. This patch adds receive buffer accounting which drops chunks in sctp_rcv when sockets sk_rmem_alloc value exceeds sockets sk_rcvbuff value. Signed-off-by: Neil Horman sk->sk_rmem_alloc); + sock_rfree(skb); +} + +/* The ownership wrapper routine to do receive buffer accounting */ +static void sctp_rcv_set_owner_r(struct sk_buff *skb, struct sock *sk) +{ + skb_set_owner_r(skb,sk); + skb->destructor = sctp_rfree; + atomic_add(sizeof(struct sctp_chunk),&sk->sk_rmem_alloc); +} + /* * This is the routine which IP calls when receiving an SCTP packet. */ @@ -175,6 +190,11 @@ int sctp_rcv(struct sk_buff *skb) rcvr = asoc ? &asoc->base : &ep->base; sk = rcvr->sk; + if ((sk) && (atomic_read(&sk->sk_rmem_alloc) >= sk->sk_rcvbuf)) { + goto discard_release; + } + + /* SCTP seems to always need a timestamp right now (FIXME) */ if (skb->stamp.tv_sec == 0) { do_gettimeofday(&skb->stamp); @@ -195,6 +215,8 @@ int sctp_rcv(struct sk_buff *skb) goto discard_release; } + sctp_rcv_set_owner_r(skb,sk); + /* Remember what endpoint is to handle this packet. */ chunk->rcvr = rcvr; -- /*************************************************** *Neil Horman *Software Engineer *Red Hat, Inc. *nhorman@redhat.com *gpg keyid: 1024D / 0x92A74FA1 *http://pgp.mit.edu ***************************************************/ From jgarzik@pobox.com Wed Mar 2 11:12:21 2005 Received: with ECARTIS (v1.0.0; list netdev); Wed, 02 Mar 2005 11:12:26 -0800 (PST) Received: from parcelfarce.linux.theplanet.co.uk (IDENT:93@parcelfarce.linux.theplanet.co.uk [195.92.249.252]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j22JCKSr007208 for ; Wed, 2 Mar 2005 11:12:21 -0800 Received: from [69.134.152.124] (helo=[10.10.10.88]) by parcelfarce.linux.theplanet.co.uk with asmtp (TLSv1:AES256-SHA:256) (Exim 4.33) id 1D6ZGd-0001dz-5T; Wed, 02 Mar 2005 19:12:19 +0000 Message-ID: <42261004.4000501@pobox.com> Date: Wed, 02 Mar 2005 14:12:04 -0500 From: Jeff Garzik User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.3) Gecko/20040922 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Adrian Bunk CC: Andrew Morton , netdev@oss.sgi.com, linux-kernel@vger.kernel.org Subject: Re: [2.6.11-rc4-mm1 patch] fix buggy IEEE80211_CRYPT_* selects References: <20050223014233.6710fd73.akpm@osdl.org> <20050226113123.GJ3311@stusta.de> <42256078.1040002@pobox.com> <20050302140833.GD4608@stusta.de> In-Reply-To: <20050302140833.GD4608@stusta.de> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV 0.83/742/Tue Mar 1 17:05:59 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 2256 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: jgarzik@pobox.com Precedence: bulk X-list: netdev Adrian Bunk wrote: > On Wed, Mar 02, 2005 at 01:43:04AM -0500, Jeff Garzik wrote: > >>Adrian Bunk wrote: >> >>>+ select CRYPTO >>> select CRYPTO_AES >>> ---help--- >>> Include software based cipher suites in support of IEEE 802.11i >>> (aka TGi, WPA, WPA2, WPA-PSK, etc.) for use with CCMP enabled >>> networks. >>>@@ -54,10 +55,11 @@ >>> "ieee80211_crypt_ccmp". >>> >>>config IEEE80211_CRYPT_TKIP >>> tristate "IEEE 802.11i TKIP encryption" >>> depends on IEEE80211 >>>+ select CRYPTO >>> select CRYPTO_MICHAEL_MIC >> >> >>'select CRYPTO_AES' should 'select CRYPTO' automatically, I would hope. > > > This would result in a recursive dependency. No, it wouldn't. CRYPTO_AES depends on CRYPTO, which depends on nothing. Jeff From jgarzik@pobox.com Wed Mar 2 11:12:57 2005 Received: with ECARTIS (v1.0.0; list netdev); Wed, 02 Mar 2005 11:13:00 -0800 (PST) Received: from parcelfarce.linux.theplanet.co.uk (IDENT:93@parcelfarce.linux.theplanet.co.uk [195.92.249.252]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j22JCuLO007428 for ; Wed, 2 Mar 2005 11:12:56 -0800 Received: from [69.134.152.124] (helo=[10.10.10.88]) by parcelfarce.linux.theplanet.co.uk with asmtp (TLSv1:AES256-SHA:256) (Exim 4.33) id 1D6ZHC-0001eV-B3; Wed, 02 Mar 2005 19:12:54 +0000 Message-ID: <42261028.7030301@pobox.com> Date: Wed, 02 Mar 2005 14:12:40 -0500 From: Jeff Garzik User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.3) Gecko/20040922 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Denis Vlasenko CC: "David S. Miller" , Quantum Scientific , netdev@oss.sgi.com Subject: Re: Kernel 2.6 IPV6 Busted References: <200502270928.44402.Info@Quantum-Sci.com> <200503011207.34029.vda@port.imtp.ilyichevsk.odessa.ua> <422497BA.9090606@pobox.com> <200503021602.53663.vda@port.imtp.ilyichevsk.odessa.ua> In-Reply-To: <200503021602.53663.vda@port.imtp.ilyichevsk.odessa.ua> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV 0.83/742/Tue Mar 1 17:05:59 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 2257 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: jgarzik@pobox.com Precedence: bulk X-list: netdev Denis Vlasenko wrote: > On Tuesday 01 March 2005 18:26, Jeff Garzik wrote: > >>>>There are many very important optimizations we've had to disable >>>>by default just in TCP alone because of NAT. >>> >>>I don't think future Internet will be safe enough to open >>>corporate networks. I definitely won't do it. >>>NAT firewall in front of my net is an absolute requirement >>>for me. >>> >>>However, IPv6 in Internet won't happen tomorrow, >>>no rush... >> >>You don't need NAT to secure a corporate network. > > > I don't want outside world to even KNOW that I have a network > behind the firewall box. I don't want them to know > internal hosts' IPs. ...thus breaking the end-to-end connection model, and various protocols. Jeff From shemminger@osdl.org Wed Mar 2 11:26:14 2005 Received: with ECARTIS (v1.0.0; list netdev); Wed, 02 Mar 2005 11:26:19 -0800 (PST) Received: from smtp.osdl.org (fire.osdl.org [65.172.181.4]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j22JQEKg008634 for ; Wed, 2 Mar 2005 11:26:14 -0800 Received: from shell0.pdx.osdl.net (fw.osdl.org [65.172.181.6]) by smtp.osdl.org (8.12.8/8.12.8) with ESMTP id j22JQ8qi029030 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO); Wed, 2 Mar 2005 11:26:08 -0800 Received: from dxpl.pdx.osdl.net (dxpl.pdx.osdl.net [172.20.1.103]) by shell0.pdx.osdl.net (8.13.1/8.11.6) with ESMTP id j22JQ7v6020198; Wed, 2 Mar 2005 11:26:07 -0800 Date: Wed, 2 Mar 2005 11:26:22 -0800 From: Stephen Hemminger To: BZ Benny Cc: netdev@oss.sgi.com Subject: Re: creating a netdevice Message-ID: <20050302112622.33be433c@dxpl.pdx.osdl.net> In-Reply-To: <20050302133828.45232.qmail@web26610.mail.ukl.yahoo.com> References: <20050302133828.45232.qmail@web26610.mail.ukl.yahoo.com> Organization: Open Source Development Lab X-Mailer: Sylpheed-Claws 1.0.1 (GTK+ 1.2.10; x86_64-unknown-linux-gnu) X-Face: &@E+xe?c%:&e4D{>f1O<&U>2qwRREG5!}7R4;D<"NO^UI2mJ[eEOA2*3>(`Th.yP,VDPo9$ /`~cw![cmj~~jWe?AHY7D1S+\}5brN0k*NE?pPh_'_d>6;XGG[\KDRViCfumZT3@[ Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Received-SPF: pass (domain of shemminger@osdl.org designates 65.172.181.6 as permitted sender) X-MIMEDefang-Filter: osdl$Revision: 1.104 $ X-Scanned-By: MIMEDefang 2.36 X-Virus-Scanned: ClamAV 0.83/742/Tue Mar 1 17:05:59 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 2258 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: shemminger@osdl.org Precedence: bulk X-list: netdev On Wed, 2 Mar 2005 14:38:28 +0100 (CET) BZ Benny wrote: > Hi > > I want to create a network interface from the user > space, > is it possible? No, you can't create a network interface from user space. You probably want to use tun/tap or ethertap device. From jgoerzen@excelhustler.com Wed Mar 2 11:51:21 2005 Received: with ECARTIS (v1.0.0; list netdev); Wed, 02 Mar 2005 11:51:27 -0800 (PST) Received: from gatekeeper.elmer.external.excelhustler.com (gatekeeper.excelhustler.com [68.99.114.105]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j22JpLnM010182 for ; Wed, 2 Mar 2005 11:51:21 -0800 Received: from chatterbox.elmer.internal.excelhustler.com (unknown [192.168.0.12]) (using TLSv1 with cipher EDH-RSA-DES-CBC3-SHA (168/168 bits)) (Client CN "chatterbox.elmer.internal.excelhustler.com", Issuer "excelhustler.com" (not verified)) by gatekeeper.elmer.external.excelhustler.com (Postfix) with ESMTP id B010CF4735; Wed, 2 Mar 2005 13:51:13 -0600 (CST) Received: from localhost (localhost [127.0.0.1]) by chatterbox.elmer.internal.excelhustler.com (Postfix) with ESMTP id 89107B16AD; Wed, 2 Mar 2005 13:51:13 -0600 (CST) Received: from chatterbox.elmer.internal.excelhustler.com ([192.168.0.12]) by localhost (chatterbox [192.168.0.12]) (amavisd-new, port 10025) with ESMTP id 15103-05; Wed, 2 Mar 2005 13:51:11 -0600 (CST) Received: from wile.internal.excelhustler.com (wile.internal.excelhustler.com [192.168.1.34]) by chatterbox.elmer.internal.excelhustler.com (Postfix) with ESMTP id ED0EDF4733; Wed, 2 Mar 2005 13:51:10 -0600 (CST) Received: by wile.internal.excelhustler.com (Postfix, from userid 1000) id 4FB2F46001; Wed, 2 Mar 2005 13:51:10 -0600 (CST) Date: Wed, 2 Mar 2005 13:51:10 -0600 From: John Goerzen To: "YOSHIFUJI Hideaki / ?$B5HF#1QL@" Cc: akpm@osdl.org, netdev@oss.sgi.com Subject: Re: [Bugme-new] [Bug 4274] New: ipv6: Unknown symbol tcp_timer_bug_msg Message-ID: <20050302195110.GA27736@excelhustler.com> References: <20050302091907.19bb2b2e.akpm@osdl.org> <20050303.023706.64945563.yoshfuji@wide.ad.jp> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20050303.023706.64945563.yoshfuji@wide.ad.jp> User-Agent: Mutt/1.5.6+20040907i X-Virus-Scanned: ClamAV 0.83/742/Tue Mar 1 17:05:59 2005 on oss.sgi.com X-Virus-Scanned: by amavisd-new-20030616-p10 (Debian) at excelhustler.com X-Virus-Status: Clean X-archive-position: 2259 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: jgoerzen@complete.org Precedence: bulk X-list: netdev On Thu, Mar 03, 2005 at 02:37:06AM +0900, YOSHIFUJI Hideaki / ?$B5HF#1QL@ wrote: > In article <20050302091907.19bb2b2e.akpm@osdl.org> (at Wed, 2 Mar 2005 09:19:07 -0800), Andrew Morton says: > > > modprobe ipv6 fails with: > > > > ipv6: Unknown symbol tcp_timer_bug_msg > > Please try this. That fixed it. Thanks! -- John > Signed-off-by: Hideaki YOSHIFUJI > > ===== net/ipv4/tcp_timer.c 1.30 vs edited ===== > --- 1.30/net/ipv4/tcp_timer.c 2005-02-23 03:45:32 +09:00 > +++ edited/net/ipv4/tcp_timer.c 2005-03-03 02:26:20 +09:00 > @@ -38,6 +38,7 @@ > > #ifdef TCP_DEBUG > const char tcp_timer_bug_msg[] = KERN_DEBUG "tcpbug: unknown timer value\n"; > +EXPORT_SYMBOL(tcp_timer_bug_msg); > #endif > > /* > > -- > Hideaki YOSHIFUJI @ USAGI Project > GPG FP: 9022 65EB 1ECF 3AD1 0BDF 80D8 4807 F894 E062 0EEA > From davem@davemloft.net Wed Mar 2 12:21:49 2005 Received: with ECARTIS (v1.0.0; list netdev); Wed, 02 Mar 2005 12:21:55 -0800 (PST) Received: from cheetah.davemloft.net (mail@dsl027-180-174.sfo1.dsl.speakeasy.net [216.27.180.174]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j22KLnVP015020 for ; Wed, 2 Mar 2005 12:21:49 -0800 Received: from localhost ([127.0.0.1] helo=cheetah.davemloft.net ident=davem) by cheetah.davemloft.net with smtp (Exim 3.36 #1 (Debian)) id 1D6aGn-0000Z2-00; Wed, 02 Mar 2005 12:16:33 -0800 Date: Wed, 2 Mar 2005 12:16:33 -0800 From: "David S. Miller" To: John Goerzen Cc: yoshfuji@wide.ad.jp, akpm@osdl.org, netdev@oss.sgi.com Subject: Re: [Bugme-new] [Bug 4274] New: ipv6: Unknown symbol tcp_timer_bug_msg Message-Id: <20050302121633.2b28c058.davem@davemloft.net> In-Reply-To: <20050302195110.GA27736@excelhustler.com> References: <20050302091907.19bb2b2e.akpm@osdl.org> <20050303.023706.64945563.yoshfuji@wide.ad.jp> <20050302195110.GA27736@excelhustler.com> X-Mailer: Sylpheed version 1.0.1 (GTK+ 1.2.10; sparc-unknown-linux-gnu) X-Face: "_;p5u5aPsO,_Vsx"^v-pEq09'CU4&Dc1$fQExov$62l60cgCc%FnIwD=.UF^a>?5'9Kn[;433QFVV9M..2eN.@4ZWPGbdi<=?[:T>y?SD(R*-3It"Vj:)"dP Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV 0.83/742/Tue Mar 1 17:05:59 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 2260 X-ecartis-version: Ecartis v1.0.0 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, 2 Mar 2005 13:51:10 -0600 John Goerzen wrote: > On Thu, Mar 03, 2005 at 02:37:06AM +0900, YOSHIFUJI Hideaki / ?$B5HF#1QL@ wrote: > > In article <20050302091907.19bb2b2e.akpm@osdl.org> (at Wed, 2 Mar 2005 09:19:07 -0800), Andrew Morton says: > > > > > modprobe ipv6 fails with: > > > > > > ipv6: Unknown symbol tcp_timer_bug_msg > > > > Please try this. > > That fixed it. Thanks! I'll apply this patch later today, thanks everyone. From akpm@osdl.org Wed Mar 2 12:38:55 2005 Received: with ECARTIS (v1.0.0; list netdev); Wed, 02 Mar 2005 12:39:01 -0800 (PST) Received: from smtp.osdl.org (fire.osdl.org [65.172.181.4]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j22Kcttb015990 for ; Wed, 2 Mar 2005 12:38:55 -0800 Received: from shell0.pdx.osdl.net (fw.osdl.org [65.172.181.6]) by smtp.osdl.org (8.12.8/8.12.8) with ESMTP id j22Kcnqi003090 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO); Wed, 2 Mar 2005 12:38:49 -0800 Received: from bix (shell0.pdx.osdl.net [10.9.0.31]) by shell0.pdx.osdl.net (8.13.1/8.11.6) with SMTP id j22KcmNi023849; Wed, 2 Mar 2005 12:38:48 -0800 Date: Wed, 2 Mar 2005 12:38:29 -0800 From: Andrew Morton To: Jeff Garzik Cc: bunk@stusta.de, netdev@oss.sgi.com, linux-kernel@vger.kernel.org Subject: Re: [2.6.11-rc4-mm1 patch] fix buggy IEEE80211_CRYPT_* selects Message-Id: <20050302123829.51dbc44b.akpm@osdl.org> In-Reply-To: <42261004.4000501@pobox.com> References: <20050223014233.6710fd73.akpm@osdl.org> <20050226113123.GJ3311@stusta.de> <42256078.1040002@pobox.com> <20050302140833.GD4608@stusta.de> <42261004.4000501@pobox.com> X-Mailer: Sylpheed version 0.9.7 (GTK+ 1.2.10; i386-redhat-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Received-SPF: pass (domain of akpm@osdl.org designates 65.172.181.6 as permitted sender) X-MIMEDefang-Filter: osdl$Revision: 1.104 $ X-Scanned-By: MIMEDefang 2.36 X-Virus-Scanned: ClamAV 0.83/742/Tue Mar 1 17:05:59 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 2261 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: akpm@osdl.org Precedence: bulk X-list: netdev Jeff Garzik wrote: > > Adrian Bunk wrote: > > On Wed, Mar 02, 2005 at 01:43:04AM -0500, Jeff Garzik wrote: > > > >>Adrian Bunk wrote: > >> > >>>+ select CRYPTO > >>> select CRYPTO_AES > >>> ---help--- > >>> Include software based cipher suites in support of IEEE 802.11i > >>> (aka TGi, WPA, WPA2, WPA-PSK, etc.) for use with CCMP enabled > >>> networks. > >>>@@ -54,10 +55,11 @@ > >>> "ieee80211_crypt_ccmp". > >>> > >>>config IEEE80211_CRYPT_TKIP > >>> tristate "IEEE 802.11i TKIP encryption" > >>> depends on IEEE80211 > >>>+ select CRYPTO > >>> select CRYPTO_MICHAEL_MIC > >> > >> > >>'select CRYPTO_AES' should 'select CRYPTO' automatically, I would hope. > > > > > > This would result in a recursive dependency. > > No, it wouldn't. CRYPTO_AES depends on CRYPTO, which depends on nothing. > Thing is, CRYPTO_AES on only selectable on x86. So really, IEEE80211_CRYPT_CCMP should depend upon CRYPTO_AES rather than selecting it. But that confuses users. From ralf@linux-mips.org Wed Mar 2 12:48:11 2005 Received: with ECARTIS (v1.0.0; list netdev); Wed, 02 Mar 2005 12:48:14 -0800 (PST) Received: from mail.linux-mips.net (pD9562597.dip.t-dialin.net [217.86.37.151]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j22Km9ff016864 for ; Wed, 2 Mar 2005 12:48:10 -0800 Received: from fluff.linux-mips.net (localhost.localdomain [127.0.0.1]) by mail.linux-mips.net (8.13.1/8.13.1) with ESMTP id j22Km4UJ005994 for ; Wed, 2 Mar 2005 21:48:05 +0100 Received: (from ralf@localhost) by fluff.linux-mips.net (8.13.1/8.13.1/Submit) id j22KlvGn005993 for netdev@oss.sgi.com; Wed, 2 Mar 2005 21:47:57 +0100 Date: Wed, 2 Mar 2005 21:47:53 +0100 From: Ralf Baechle To: netdev@oss.sgi.com Subject: [PATCH] Sparse fixes for NETROM Message-ID: <20050302204753.GA5985@linux-mips.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.4.1i X-Virus-Scanned: ClamAV 0.83/742/Tue Mar 1 17:05:59 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 2262 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: ralf@linux-mips.org Precedence: bulk X-list: netdev Moving nr_init_timers prototype to where all the other prototypes already are. Index: bk-afu/include/net/netrom.h =================================================================== --- bk-afu.orig/include/net/netrom.h 2005-03-01 00:49:26.108296048 +0000 +++ bk-afu/include/net/netrom.h 2005-03-01 00:54:52.707645400 +0000 @@ -221,6 +221,7 @@ extern void nr_disconnect(struct sock *, int); /* nr_timer.c */ +extern void nr_init_timers(struct sock *sk); extern void nr_start_heartbeat(struct sock *); extern void nr_start_t1timer(struct sock *); extern void nr_start_t2timer(struct sock *); Index: bk-afu/net/netrom/af_netrom.c =================================================================== --- bk-afu.orig/net/netrom/af_netrom.c 2005-03-01 00:49:26.088299088 +0000 +++ bk-afu/net/netrom/af_netrom.c 2005-03-01 00:55:31.325774552 +0000 @@ -63,7 +63,6 @@ static DEFINE_SPINLOCK(nr_list_lock); static struct proto_ops nr_proto_ops; -void nr_init_timers(struct sock *sk); static struct sock *nr_alloc_sock(void) { From ralf@linux-mips.org Wed Mar 2 13:00:07 2005 Received: with ECARTIS (v1.0.0; list netdev); Wed, 02 Mar 2005 13:00:10 -0800 (PST) Received: from mail.linux-mips.net (pD9562597.dip.t-dialin.net [217.86.37.151]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j22L05Jg017935 for ; Wed, 2 Mar 2005 13:00:06 -0800 Received: from fluff.linux-mips.net (localhost.localdomain [127.0.0.1]) by mail.linux-mips.net (8.13.1/8.13.1) with ESMTP id j22L04eP006017 for ; Wed, 2 Mar 2005 22:00:04 +0100 Received: (from ralf@localhost) by fluff.linux-mips.net (8.13.1/8.13.1/Submit) id j22L04Av006016 for netdev@oss.sgi.com; Wed, 2 Mar 2005 22:00:04 +0100 Date: Wed, 2 Mar 2005 22:00:04 +0100 From: Ralf Baechle To: netdev@oss.sgi.com Subject: [PATCH] Remove rose_rx_ip Message-ID: <20050302210003.GA5997@linux-mips.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.4.1i X-Virus-Scanned: ClamAV 0.83/742/Tue Mar 1 17:05:59 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 2263 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: ralf@linux-mips.org Precedence: bulk X-list: netdev Rose_rx_ip is unused and seems it's always been since it made it into the kernel in 2.3.19. Probably directly calling ip_rcv from a non-IP stack is no longer a good idea anyway, so this should be solved differently. Index: bk-afu/net/rose/rose_dev.c =================================================================== --- bk-afu.orig/net/rose/rose_dev.c 2005-03-01 01:03:14.857307048 +0000 +++ bk-afu/net/rose/rose_dev.c 2005-03-01 01:06:30.364585424 +0000 @@ -37,38 +37,6 @@ #include #include -/* - * Only allow IP over ROSE frames through if the netrom device is up. - */ - -int rose_rx_ip(struct sk_buff *skb, struct net_device *dev) -{ - struct net_device_stats *stats = netdev_priv(dev); - -#ifdef CONFIG_INET - if (!netif_running(dev)) { - stats->rx_errors++; - return 0; - } - - stats->rx_packets++; - stats->rx_bytes += skb->len; - - skb->protocol = htons(ETH_P_IP); - - /* Spoof incoming device */ - skb->dev = dev; - skb->h.raw = skb->data; - skb->nh.raw = skb->data; - skb->pkt_type = PACKET_HOST; - - ip_rcv(skb, skb->dev, NULL); -#else - kfree_skb(skb); -#endif - return 1; -} - static int rose_header(struct sk_buff *skb, struct net_device *dev, unsigned short type, void *daddr, void *saddr, unsigned len) { From jgarzik@pobox.com Wed Mar 2 13:07:42 2005 Received: with ECARTIS (v1.0.0; list netdev); Wed, 02 Mar 2005 13:07:48 -0800 (PST) Received: from parcelfarce.linux.theplanet.co.uk (IDENT:93@parcelfarce.linux.theplanet.co.uk [195.92.249.252]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j22L7f3Z018739 for ; Wed, 2 Mar 2005 13:07:42 -0800 Received: from [69.134.152.124] (helo=[10.10.10.88]) by parcelfarce.linux.theplanet.co.uk with asmtp (TLSv1:AES256-SHA:256) (Exim 4.33) id 1D6b4G-0004XU-Hk; Wed, 02 Mar 2005 21:07:40 +0000 Message-ID: <42262B08.2040401@pobox.com> Date: Wed, 02 Mar 2005 16:07:20 -0500 From: Jeff Garzik User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.3) Gecko/20040922 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Andrew Morton CC: bunk@stusta.de, netdev@oss.sgi.com, linux-kernel@vger.kernel.org Subject: Re: [2.6.11-rc4-mm1 patch] fix buggy IEEE80211_CRYPT_* selects References: <20050223014233.6710fd73.akpm@osdl.org> <20050226113123.GJ3311@stusta.de> <42256078.1040002@pobox.com> <20050302140833.GD4608@stusta.de> <42261004.4000501@pobox.com> <20050302123829.51dbc44b.akpm@osdl.org> In-Reply-To: <20050302123829.51dbc44b.akpm@osdl.org> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV 0.83/742/Tue Mar 1 17:05:59 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 2264 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: jgarzik@pobox.com Precedence: bulk X-list: netdev Andrew Morton wrote: > Jeff Garzik wrote: > >>Adrian Bunk wrote: >> >>>On Wed, Mar 02, 2005 at 01:43:04AM -0500, Jeff Garzik wrote: >>> >>> >>>>Adrian Bunk wrote: >>>> >>>> >>>>>+ select CRYPTO >>>>> select CRYPTO_AES >>>>> ---help--- >>>>> Include software based cipher suites in support of IEEE 802.11i >>>>> (aka TGi, WPA, WPA2, WPA-PSK, etc.) for use with CCMP enabled >>>>> networks. >>>>>@@ -54,10 +55,11 @@ >>>>> "ieee80211_crypt_ccmp". >>>>> >>>>>config IEEE80211_CRYPT_TKIP >>>>> tristate "IEEE 802.11i TKIP encryption" >>>>> depends on IEEE80211 >>>>>+ select CRYPTO >>>>> select CRYPTO_MICHAEL_MIC >>>> >>>> >>>>'select CRYPTO_AES' should 'select CRYPTO' automatically, I would hope. >>> >>> >>>This would result in a recursive dependency. >> >>No, it wouldn't. CRYPTO_AES depends on CRYPTO, which depends on nothing. >> > > > Thing is, CRYPTO_AES on only selectable on x86. You're thinking about CRYPTO_AES_586. But looking at crypto/Kconfig, the dependencies are a bit weird: config CRYPTO_AES tristate "AES cipher algorithms" depends on CRYPTO && !(X86 && !X86_64) config CRYPTO_AES_586 tristate "AES cipher algorithms (i586)" depends on CRYPTO && (X86 && !X86_64) From akpm@osdl.org Wed Mar 2 13:18:45 2005 Received: with ECARTIS (v1.0.0; list netdev); Wed, 02 Mar 2005 13:18:49 -0800 (PST) Received: from smtp.osdl.org (fire.osdl.org [65.172.181.4]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j22LIhfc019657 for ; Wed, 2 Mar 2005 13:18:45 -0800 Received: from shell0.pdx.osdl.net (fw.osdl.org [65.172.181.6]) by smtp.osdl.org (8.12.8/8.12.8) with ESMTP id j22LIaqi007114 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO); Wed, 2 Mar 2005 13:18:37 -0800 Received: from bix (shell0.pdx.osdl.net [10.9.0.31]) by shell0.pdx.osdl.net (8.13.1/8.11.6) with SMTP id j22LIZWi025670; Wed, 2 Mar 2005 13:18:36 -0800 Date: Wed, 2 Mar 2005 13:18:17 -0800 From: Andrew Morton To: Jeff Garzik Cc: bunk@stusta.de, netdev@oss.sgi.com, linux-kernel@vger.kernel.org Subject: Re: [2.6.11-rc4-mm1 patch] fix buggy IEEE80211_CRYPT_* selects Message-Id: <20050302131817.2e61805f.akpm@osdl.org> In-Reply-To: <42262B08.2040401@pobox.com> References: <20050223014233.6710fd73.akpm@osdl.org> <20050226113123.GJ3311@stusta.de> <42256078.1040002@pobox.com> <20050302140833.GD4608@stusta.de> <42261004.4000501@pobox.com> <20050302123829.51dbc44b.akpm@osdl.org> <42262B08.2040401@pobox.com> X-Mailer: Sylpheed version 0.9.7 (GTK+ 1.2.10; i386-redhat-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Received-SPF: pass (domain of akpm@osdl.org designates 65.172.181.6 as permitted sender) X-MIMEDefang-Filter: osdl$Revision: 1.104 $ X-Scanned-By: MIMEDefang 2.36 X-Virus-Scanned: ClamAV 0.83/742/Tue Mar 1 17:05:59 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 2265 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: akpm@osdl.org Precedence: bulk X-list: netdev Jeff Garzik wrote: > > > Thing is, CRYPTO_AES on only selectable on x86. > > You're thinking about CRYPTO_AES_586. But looking at crypto/Kconfig, > the dependencies are a bit weird: > > config CRYPTO_AES > tristate "AES cipher algorithms" > depends on CRYPTO && !(X86 && !X86_64) > config CRYPTO_AES_586 > tristate "AES cipher algorithms (i586)" > depends on CRYPTO && (X86 && !X86_64) That's pretty broken, isn't it? Would be better to just do: config CRYPTO_AES select CRYPTO_AES_586 if (X86 && !X86_64) select CRYPTO_AES_OTHER if !(X86 && !X86_64) and hide CRYPTO_AES_586 and CRYPTO_AES_OTHER from the outside world. From hadi@cyberus.ca Wed Mar 2 13:37:01 2005 Received: with ECARTIS (v1.0.0; list netdev); Wed, 02 Mar 2005 13:37:07 -0800 (PST) Received: from mx02.cybersurf.com (mx02.cybersurf.com [209.197.145.105]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j22Lb04Q020873 for ; Wed, 2 Mar 2005 13:37:01 -0800 Received: from mail.cyberus.ca ([209.197.145.21]) by mx02.cybersurf.com with esmtp (Exim 4.30) id 1D6bWc-0003au-BU for netdev@oss.sgi.com; Wed, 02 Mar 2005 16:36:58 -0500 Received: from [24.103.99.32] (helo=[10.0.0.9]) by mail.cyberus.ca with esmtp (Exim 4.20) id 1D6bWW-0001lo-Ll; Wed, 02 Mar 2005 16:36:52 -0500 Subject: Re: [PATCH] remove dead extern's in netdevice.h From: jamal Reply-To: hadi@cyberus.ca To: Stephen Hemminger Cc: "David S. Miller" , netdev@oss.sgi.com, Jeff Garzik In-Reply-To: <20050302105902.72f2b983@dxpl.pdx.osdl.net> References: <20050302105902.72f2b983@dxpl.pdx.osdl.net> Content-Type: text/plain Organization: jamalopolous Message-Id: <1109799408.1098.193.camel@jzny.localdomain> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.2.2 Date: 02 Mar 2005 16:36:49 -0500 Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV 0.83/742/Tue Mar 1 17:05:59 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 2266 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: hadi@cyberus.ca Precedence: bulk X-list: netdev If you want to do this, you might as well kill hardware flow control. I dont remember what the last decision was when we last pinged people. Jeff? cheers, jamal On Wed, 2005-03-02 at 13:59, Stephen Hemminger wrote: > The following definitions are historical relics. > > Signed-off-by: Stephen Hemminger > > diff -Nru a/include/linux/netdevice.h b/include/linux/netdevice.h > --- a/include/linux/netdevice.h 2005-03-02 10:53:22 -08:00 > +++ b/include/linux/netdevice.h 2005-03-02 10:53:22 -08:00 > @@ -921,8 +921,6 @@ > extern void dev_mcast_init(void); > extern int netdev_max_backlog; > extern int weight_p; > -extern unsigned long netdev_fc_xoff; > -extern atomic_t netdev_dropping; > extern int netdev_set_master(struct net_device *dev, struct net_device *master); > extern int skb_checksum_help(struct sk_buff *skb, int inward); > /* rx skb timestamps */ > > From hadi@cyberus.ca Wed Mar 2 13:41:25 2005 Received: with ECARTIS (v1.0.0; list netdev); Wed, 02 Mar 2005 13:41:30 -0800 (PST) Received: from mx03.cybersurf.com (mx03.cybersurf.com [209.197.145.106]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j22LfOMY021524 for ; Wed, 2 Mar 2005 13:41:24 -0800 Received: from mail.cyberus.ca ([209.197.145.21]) by mx03.cybersurf.com with esmtp (Exim 4.30) id 1D6bat-0000bN-UM for netdev@oss.sgi.com; Wed, 02 Mar 2005 16:41:23 -0500 Received: from [24.103.99.32] (helo=[10.0.0.9]) by mail.cyberus.ca with esmtp (Exim 4.20) id 1D6baq-0002Os-KJ; Wed, 02 Mar 2005 16:41:20 -0500 Subject: Re: creating a netdevice From: jamal Reply-To: hadi@cyberus.ca To: Stephen Hemminger Cc: BZ Benny , netdev@oss.sgi.com In-Reply-To: <20050302112622.33be433c@dxpl.pdx.osdl.net> References: <20050302133828.45232.qmail@web26610.mail.ukl.yahoo.com> <20050302112622.33be433c@dxpl.pdx.osdl.net> Content-Type: text/plain Organization: jamalopolous Message-Id: <1109799677.1098.198.camel@jzny.localdomain> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.2.2 Date: 02 Mar 2005 16:41:17 -0500 Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV 0.83/742/Tue Mar 1 17:05:59 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 2267 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: hadi@cyberus.ca Precedence: bulk X-list: netdev Can you explain why you need to create a net device? Linux (and many other OSes) typically tie discovery of hardware resources to creating a network device i.e the kernel creates it for you (this is true even when the discovery is done post bootup). The only exception is things like tun/ethertap as Stephen mentions. Things like allocation of ifindices are also under the control of the OS - even when you are able to create. cheers, jamal On Wed, 2005-03-02 at 14:26, Stephen Hemminger wrote: > On Wed, 2 Mar 2005 14:38:28 +0100 (CET) > BZ Benny wrote: > > > Hi > > > > I want to create a network interface from the user > > space, > > is it possible? > > No, you can't create a network interface from user space. > You probably want to use tun/tap or ethertap device. > > From hadi@cyberus.ca Wed Mar 2 13:56:04 2005 Received: with ECARTIS (v1.0.0; list netdev); Wed, 02 Mar 2005 13:56:09 -0800 (PST) Received: from mx04.cybersurf.com (mx04.cybersurf.com [209.197.145.108]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j22Lu3nJ022435 for ; Wed, 2 Mar 2005 13:56:04 -0800 Received: from mail.cyberus.ca ([209.197.145.21]) by mx01.cybersurf.com with esmtp (Exim 4.30) id 1D6bp4-0004RR-0s for netdev@oss.sgi.com; Wed, 02 Mar 2005 16:56:02 -0500 Received: from [24.103.99.32] (helo=[10.0.0.9]) by mail.cyberus.ca with esmtp (Exim 4.20) id 1D6boz-0004KC-OE; Wed, 02 Mar 2005 16:55:58 -0500 Subject: Re: Interconnect virtual device? From: jamal Reply-To: hadi@cyberus.ca To: Ben Greear Cc: "'netdev@oss.sgi.com'" In-Reply-To: <422353C9.6050001@candelatech.com> References: <4222A8F2.6080004@candelatech.com> <1109592365.2188.914.camel@jzny.localdomain> <422353C9.6050001@candelatech.com> Content-Type: text/plain Organization: jamalopolous Message-Id: <1109800554.1091.213.camel@jzny.localdomain> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.2.2 Date: 02 Mar 2005 16:55:54 -0500 Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV 0.83/742/Tue Mar 1 17:05:59 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 2268 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: hadi@cyberus.ca Precedence: bulk X-list: netdev Not sure if i ever responded to you. On Mon, 2005-02-28 at 12:24, Ben Greear wrote: > jamal wrote: [..] > > In other words, it redirects to another device - I take it based on some > > rules. Sounds to me like the mirred action already does this (and in > > addition can mirror). > > Actually, I was thinking that either user-space or perhaps a kernel > module could use the standard methods of receiving all pkts in promisc > mode to do the bridging portion. If I force the real ethernet > interface to have no IP address, and put it into promisc mode, then > I can effectively bridge in user-space. > > When I re-insert the pkts into the stack by writing to the virtual > device, the (potentially modified) packet can be > routed and firewalled, etc just like a normal packet received from the > network. I may need to have two virtual inter-connects, one w/out > an IP that does the bridging portion, and one with an IP that actually > communicates with the rest of the kernel. In this case, the two virtuals > would be connected to each other. > > I think this could provide a way to do very customized actions on > raw packets without having to hack the kernel on an ongoing basis. > There are two ways to do this: a) You could redirect to a packet socket - a small extension needed to the redirect action (mostly mechanical details involved like keeping state of which sockets are open etc). b) My preference is to push this gentleman's PF_RING (http://www.ntop.org/ntop.html) netdevice into the kernel. He has replicated unfortunately a lot of the stuff already done by MMAPED packet socket - but i think we can forgive him since solution a) would require hacking packet socket. Reinjection of packets still needs working for that device - just as much as a few cleanups here and there. The problem is the guy is not very responsive - I have a lot of notes on his stuff if you are willing to chase him around. You can then get redirection to this device for free (for either incoming or outgoing packets); something like: tc filter add dev eth0 .... \ match ip src 10.0.0.1/32 \ action mirred egress redirect dev ring0 Assuming you have a program running on user space you should receive all packets incoming and/or outgoing on eth0. And no, you dont need the eth device to have a ip address attached. cheers, jamal From bunk@stusta.de Wed Mar 2 13:56:16 2005 Received: with ECARTIS (v1.0.0; list netdev); Wed, 02 Mar 2005 13:56:22 -0800 (PST) Received: from mailout.stusta.mhn.de (emailhub.stusta.mhn.de [141.84.69.5]) by oss.sgi.com (8.13.0/8.13.0) with SMTP id j22LuErH022449 for ; Wed, 2 Mar 2005 13:56:15 -0800 Received: (qmail 27882 invoked from network); 2 Mar 2005 21:56:08 -0000 Received: from r063144.stusta.swh.mhn.de (10.150.63.144) by mailout.stusta.mhn.de with SMTP; 2 Mar 2005 21:56:08 -0000 Received: by r063144.stusta.swh.mhn.de (Postfix, from userid 1000) id 8366AAFCF2; Wed, 2 Mar 2005 22:56:07 +0100 (CET) Date: Wed, 2 Mar 2005 22:56:07 +0100 From: Adrian Bunk To: Andrew Morton Cc: Jeff Garzik , netdev@oss.sgi.com, linux-kernel@vger.kernel.org Subject: Re: [2.6.11-rc4-mm1 patch] fix buggy IEEE80211_CRYPT_* selects Message-ID: <20050302215607.GF4608@stusta.de> References: <20050223014233.6710fd73.akpm@osdl.org> <20050226113123.GJ3311@stusta.de> <42256078.1040002@pobox.com> <20050302140833.GD4608@stusta.de> <42261004.4000501@pobox.com> <20050302123829.51dbc44b.akpm@osdl.org> <42262B08.2040401@pobox.com> <20050302131817.2e61805f.akpm@osdl.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20050302131817.2e61805f.akpm@osdl.org> User-Agent: Mutt/1.5.6+20040907i X-Virus-Scanned: ClamAV 0.83/742/Tue Mar 1 17:05:59 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 2269 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: bunk@stusta.de Precedence: bulk X-list: netdev On Wed, Mar 02, 2005 at 01:18:17PM -0800, Andrew Morton wrote: > Jeff Garzik wrote: > > > > > Thing is, CRYPTO_AES on only selectable on x86. > > > > You're thinking about CRYPTO_AES_586. But looking at crypto/Kconfig, > > the dependencies are a bit weird: > > > > config CRYPTO_AES > > tristate "AES cipher algorithms" > > depends on CRYPTO && !(X86 && !X86_64) > > config CRYPTO_AES_586 > > tristate "AES cipher algorithms (i586)" > > depends on CRYPTO && (X86 && !X86_64) > > That's pretty broken, isn't it? > > Would be better to just do: > > config CRYPTO_AES > select CRYPTO_AES_586 if (X86 && !X86_64) > select CRYPTO_AES_OTHER if !(X86 && !X86_64) > > and hide CRYPTO_AES_586 and CRYPTO_AES_OTHER from the outside world. http://www.ussg.iu.edu/hypermail/linux/kernel/0502.3/0518.html http://www.ussg.iu.edu/hypermail/linux/kernel/0502.3/0523.html cu Adrian -- "Is there not promise of rain?" Ling Tan asked suddenly out of the darkness. There had been need of rain for many days. "Only a promise," Lao Er said. Pearl S. Buck - Dragon Seed From bunk@stusta.de Wed Mar 2 13:59:10 2005 Received: with ECARTIS (v1.0.0; list netdev); Wed, 02 Mar 2005 13:59:14 -0800 (PST) Received: from mailout.stusta.mhn.de (mailout.stusta.mhn.de [141.84.69.5]) by oss.sgi.com (8.13.0/8.13.0) with SMTP id j22Lx9gI023522 for ; Wed, 2 Mar 2005 13:59:10 -0800 Received: (qmail 27977 invoked from network); 2 Mar 2005 21:59:04 -0000 Received: from r063144.stusta.swh.mhn.de (10.150.63.144) by mailhub.stusta.mhn.de with SMTP; 2 Mar 2005 21:59:04 -0000 Received: by r063144.stusta.swh.mhn.de (Postfix, from userid 1000) id 88139AFCF2; Wed, 2 Mar 2005 22:59:03 +0100 (CET) Date: Wed, 2 Mar 2005 22:59:03 +0100 From: Adrian Bunk To: Jeff Garzik , jmorris@redhat.com, davem@davemloft.net Cc: Andrew Morton , netdev@oss.sgi.com, linux-kernel@vger.kernel.org Subject: Re: [2.6.11-rc4-mm1 patch] fix buggy IEEE80211_CRYPT_* selects Message-ID: <20050302215903.GG4608@stusta.de> References: <20050223014233.6710fd73.akpm@osdl.org> <20050226113123.GJ3311@stusta.de> <42256078.1040002@pobox.com> <20050302140833.GD4608@stusta.de> <42261004.4000501@pobox.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <42261004.4000501@pobox.com> User-Agent: Mutt/1.5.6+20040907i X-Virus-Scanned: ClamAV 0.83/742/Tue Mar 1 17:05:59 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 2270 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: bunk@stusta.de Precedence: bulk X-list: netdev On Wed, Mar 02, 2005 at 02:12:04PM -0500, Jeff Garzik wrote: > Adrian Bunk wrote: > >On Wed, Mar 02, 2005 at 01:43:04AM -0500, Jeff Garzik wrote: > > > >>Adrian Bunk wrote: > >> > >>>+ select CRYPTO > >>> select CRYPTO_AES > >>> ---help--- > >>> Include software based cipher suites in support of IEEE 802.11i > >>> (aka TGi, WPA, WPA2, WPA-PSK, etc.) for use with CCMP enabled > >>> networks. > >>>@@ -54,10 +55,11 @@ > >>> "ieee80211_crypt_ccmp". > >>> > >>>config IEEE80211_CRYPT_TKIP > >>> tristate "IEEE 802.11i TKIP encryption" > >>> depends on IEEE80211 > >>>+ select CRYPTO > >>> select CRYPTO_MICHAEL_MIC > >> > >> > >>'select CRYPTO_AES' should 'select CRYPTO' automatically, I would hope. > > > > > >This would result in a recursive dependency. > > No, it wouldn't. CRYPTO_AES depends on CRYPTO, which depends on nothing. Exactly. And if CRYPTO_AES would select CRYPTO, you'd have a recursive dependency. The only possible thing would be to change all dependencies on CRYPTO to selects. This wouldn't be unlogical since the whole crypto subsystem is only a helper for other subsystems. James, any opinions on this issue? > Jeff cu Adrian -- "Is there not promise of rain?" Ling Tan asked suddenly out of the darkness. There had been need of rain for many days. "Only a promise," Lao Er said. Pearl S. Buck - Dragon Seed From pb@bieringer.de Wed Mar 2 13:59:50 2005 Received: with ECARTIS (v1.0.0; list netdev); Wed, 02 Mar 2005 13:59:57 -0800 (PST) Received: from smtp1.aerasec.de (pib.aerasec.de [195.226.187.146]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j22LxntW023816 for ; Wed, 2 Mar 2005 13:59:50 -0800 Received: from [192.168.1.2] (ppp-82-135-65-40.mnet-online.de [82.135.65.40]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by smtp1.aerasec.de (Postfix) with ESMTP id 4F706277D1; Wed, 2 Mar 2005 22:59:38 +0100 (CET) Date: Wed, 02 Mar 2005 22:59:37 +0100 From: Peter Bieringer To: Maillist USAGI-users cc: Maillist netdev Subject: ip -6 addr flush dev flushes also the autogenerated link-local address Message-ID: <001C540DBA8D9308CA5D790F@worker.muc.bieringer.de> X-Mailer: Mulberry/3.1.6 (Linux/x86) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Disposition: inline X-Virus-Scanned: ClamAV 0.83/742/Tue Mar 1 17:05:59 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 2271 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: pb@bieringer.de Precedence: bulk X-list: netdev Hi, sure one know that using ip -6 addr flush dev flushes (removes) all IPv6 addresses on a device. Unfortunately, it also removes the autogenerated link-local address. It reappears only if interface was cycled down and up, not so nice. What about an feature that the automagically generated link-local address will not be removed on "flush"? Peter -- Dr. Peter Bieringer http://www.bieringer.de/pb/ GPG/PGP Key 0x958F422D mailto: pb at bieringer dot de Deep Space 6 Co-Founder and Core Member http://www.deepspace6.net/ From SRS0+a2f250e0592827ba527c+556+infradead.org+hch@pentafluge.srs.infradead.org Wed Mar 2 14:07:40 2005 Received: with ECARTIS (v1.0.0; list netdev); Wed, 02 Mar 2005 14:07:45 -0800 (PST) Received: from pentafluge.infradead.org (pentafluge.infradead.org [213.146.154.40]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j22M7d9Y024814 for ; Wed, 2 Mar 2005 14:07:40 -0800 Received: from hch by pentafluge.infradead.org with local (Exim 4.43 #1 (Red Hat Linux)) id 1D6c0F-0006jZ-JO; Wed, 02 Mar 2005 22:07:35 +0000 Date: Wed, 2 Mar 2005 22:07:35 +0000 From: Christoph Hellwig To: "David S. Miller" Cc: Stephen Hemminger , netdev@oss.sgi.com Subject: Re: [PATCH] remove dead skb_iter code Message-ID: <20050302220735.GB25847@infradead.org> References: <20050302101035.61786113@dxpl.pdx.osdl.net> <20050302102025.23f479f9.davem@davemloft.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20050302102025.23f479f9.davem@davemloft.net> User-Agent: Mutt/1.4.1i X-SRS-Rewrite: SMTP reverse-path rewritten from by pentafluge.infradead.org See http://www.infradead.org/rpr.html X-Virus-Scanned: ClamAV 0.83/742/Tue Mar 1 17:05:59 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 2272 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: hch@infradead.org Precedence: bulk X-list: netdev On Wed, Mar 02, 2005 at 10:20:25AM -0800, David S. Miller wrote: > On Wed, 2 Mar 2005 10:10:35 -0800 > Stephen Hemminger wrote: > > > The code iterate over skb_frags is defined but not used by any > > existing kernel code. > > > > Signed-off-by: Stephen Hemminger > > Rusty and co.'s planned netfilter packet parsing code will use > the iterators. Send a patch to add a comment to this effect > or something as I'm tired of folks trying to remove this code. > :-) Maybe because the removal is right. This code is not dependent on any networking internals so it can easily live in a netfilter support module instead of bloating everyones kernels. From hadi@cyberus.ca Wed Mar 2 14:09:44 2005 Received: with ECARTIS (v1.0.0; list netdev); Wed, 02 Mar 2005 14:09:47 -0800 (PST) Received: from mx02.cybersurf.com (mx02.cybersurf.com [209.197.145.105]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j22M9hDv025278 for ; Wed, 2 Mar 2005 14:09:43 -0800 Received: from mail.cyberus.ca ([209.197.145.21]) by mx02.cybersurf.com with esmtp (Exim 4.30) id 1D6c2H-0000Z1-Bv for netdev@oss.sgi.com; Wed, 02 Mar 2005 17:09:41 -0500 Received: from [24.103.99.32] (helo=[10.0.0.9]) by mail.cyberus.ca with esmtp (Exim 4.20) id 1D6c2B-0006M4-LI; Wed, 02 Mar 2005 17:09:36 -0500 Subject: Re: ip -6 addr flush dev flushes also the autogenerated link-local address From: jamal Reply-To: hadi@cyberus.ca To: Peter Bieringer Cc: Maillist USAGI-users , Maillist netdev , Thomas Graf In-Reply-To: <001C540DBA8D9308CA5D790F@worker.muc.bieringer.de> References: <001C540DBA8D9308CA5D790F@worker.muc.bieringer.de> Content-Type: text/plain Organization: jamalopolous Message-Id: <1109801372.1098.228.camel@jzny.localdomain> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.2.2 Date: 02 Mar 2005 17:09:32 -0500 Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV 0.83/742/Tue Mar 1 17:05:59 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 2273 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: hadi@cyberus.ca Precedence: bulk X-list: netdev Is this a user space problem? I think we had something along these lines fixed recently. Thomas? cheers, jamal On Wed, 2005-03-02 at 16:59, Peter Bieringer wrote: > Hi, > > sure one know that using > > ip -6 addr flush dev > > flushes (removes) all IPv6 addresses on a device. > > Unfortunately, it also removes the autogenerated link-local address. > > It reappears only if interface was cycled down and up, not so nice. > > > What about an feature that the automagically generated link-local address > will not be removed on "flush"? > > Peter From akpm@osdl.org Wed Mar 2 14:14:22 2005 Received: with ECARTIS (v1.0.0; list netdev); Wed, 02 Mar 2005 14:14:27 -0800 (PST) Received: from smtp.osdl.org (fire.osdl.org [65.172.181.4]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j22MEMDp025940 for ; Wed, 2 Mar 2005 14:14:22 -0800 Received: from shell0.pdx.osdl.net (fw.osdl.org [65.172.181.6]) by smtp.osdl.org (8.12.8/8.12.8) with ESMTP id j22MEFqi012982 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO); Wed, 2 Mar 2005 14:14:16 -0800 Received: from akpm.pao.digeo.com (shell0.pdx.osdl.net [10.9.0.31]) by shell0.pdx.osdl.net (8.13.1/8.11.6) with SMTP id j22MEFd0028586; Wed, 2 Mar 2005 14:14:15 -0800 Date: Wed, 2 Mar 2005 14:14:15 -0800 From: Andrew Morton To: Adrian Bunk Cc: jgarzik@pobox.com, netdev@oss.sgi.com, linux-kernel@vger.kernel.org Subject: Re: [2.6.11-rc4-mm1 patch] fix buggy IEEE80211_CRYPT_* selects Message-Id: <20050302141415.517b6b08.akpm@osdl.org> In-Reply-To: <20050302215607.GF4608@stusta.de> References: <20050223014233.6710fd73.akpm@osdl.org> <20050226113123.GJ3311@stusta.de> <42256078.1040002@pobox.com> <20050302140833.GD4608@stusta.de> <42261004.4000501@pobox.com> <20050302123829.51dbc44b.akpm@osdl.org> <42262B08.2040401@pobox.com> <20050302131817.2e61805f.akpm@osdl.org> <20050302215607.GF4608@stusta.de> X-Mailer: Sylpheed version 1.0.0 (GTK+ 1.2.10; i386-vine-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Received-SPF: pass (domain of akpm@osdl.org designates 65.172.181.6 as permitted sender) X-MIMEDefang-Filter: osdl$Revision: 1.104 $ X-Scanned-By: MIMEDefang 2.36 X-Virus-Scanned: ClamAV 0.83/742/Tue Mar 1 17:05:59 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 2274 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: akpm@osdl.org Precedence: bulk X-list: netdev Adrian Bunk wrote: > > > Would be better to just do: > > > > config CRYPTO_AES > > select CRYPTO_AES_586 if (X86 && !X86_64) > > select CRYPTO_AES_OTHER if !(X86 && !X86_64) > > > > and hide CRYPTO_AES_586 and CRYPTO_AES_OTHER from the outside world. > > > http://www.ussg.iu.edu/hypermail/linux/kernel/0502.3/0518.html Please resubmit. From davem@davemloft.net Wed Mar 2 14:25:57 2005 Received: with ECARTIS (v1.0.0; list netdev); Wed, 02 Mar 2005 14:26:03 -0800 (PST) Received: from cheetah.davemloft.net (mail@dsl027-180-174.sfo1.dsl.speakeasy.net [216.27.180.174]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j22MPv4e026779 for ; Wed, 2 Mar 2005 14:25:57 -0800 Received: from localhost ([127.0.0.1] helo=cheetah.davemloft.net ident=davem) by cheetah.davemloft.net with smtp (Exim 3.36 #1 (Debian)) id 1D6cHm-0000IE-00; Wed, 02 Mar 2005 14:25:42 -0800 Date: Wed, 2 Mar 2005 14:25:42 -0800 From: "David S. Miller" To: Christoph Hellwig Cc: shemminger@osdl.org, netdev@oss.sgi.com Subject: Re: [PATCH] remove dead skb_iter code Message-Id: <20050302142542.2ae86040.davem@davemloft.net> In-Reply-To: <20050302220735.GB25847@infradead.org> References: <20050302101035.61786113@dxpl.pdx.osdl.net> <20050302102025.23f479f9.davem@davemloft.net> <20050302220735.GB25847@infradead.org> X-Mailer: Sylpheed version 1.0.1 (GTK+ 1.2.10; sparc-unknown-linux-gnu) X-Face: "_;p5u5aPsO,_Vsx"^v-pEq09'CU4&Dc1$fQExov$62l60cgCc%FnIwD=.UF^a>?5'9Kn[;433QFVV9M..2eN.@4ZWPGbdi<=?[:T>y?SD(R*-3It"Vj:)"dP Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV 0.83/742/Tue Mar 1 17:05:59 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 2275 X-ecartis-version: Ecartis v1.0.0 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, 2 Mar 2005 22:07:35 +0000 Christoph Hellwig wrote: > Maybe because the removal is right. This code is not dependent on > any networking internals so it can easily live in a netfilter support > module instead of bloating everyones kernels. Fine, I'll kill it for now. (I also happen to know that it might be used for ipv4 fragmentation tricks too, but that's also in the future). From greearb@candelatech.com Wed Mar 2 14:34:20 2005 Received: with ECARTIS (v1.0.0; list netdev); Wed, 02 Mar 2005 14:34:25 -0800 (PST) Received: from www.lanforge.com (ns1.lanforge.com [66.165.47.210]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j22MYJ1E027496 for ; Wed, 2 Mar 2005 14:34:20 -0800 Received: from [4.33.45.22] (evrtwa1-ar2-4-33-045-022.evrtwa1.dsl-verizon.net [4.33.45.22]) (authenticated bits=0) by www.lanforge.com (8.12.8/8.12.8) with ESMTP id j22MuiLH029849; Wed, 2 Mar 2005 14:56:44 -0800 Message-ID: <42263F6A.3020405@candelatech.com> Date: Wed, 02 Mar 2005 14:34:18 -0800 From: Ben Greear Organization: Candela Technologies User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.7.3) Gecko/20041020 X-Accept-Language: en-us, en MIME-Version: 1.0 To: hadi@cyberus.ca CC: "'netdev@oss.sgi.com'" Subject: Re: Interconnect virtual device? References: <4222A8F2.6080004@candelatech.com> <1109592365.2188.914.camel@jzny.localdomain> <422353C9.6050001@candelatech.com> <1109800554.1091.213.camel@jzny.localdomain> In-Reply-To: <1109800554.1091.213.camel@jzny.localdomain> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV 0.83/742/Tue Mar 1 17:05:59 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 2276 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: greearb@candelatech.com Precedence: bulk X-list: netdev jamal wrote: > There are two ways to do this: > > a) You could redirect to a packet socket - a small extension needed to > the redirect action (mostly mechanical details involved like keeping > state of which sockets are open etc). I'd rather not take this approach, as I'd like to have this functionality available in a kernel module as well as user-space. Netdevices are easy to work with in both user-space and kernel-space. > b) My preference is to push this gentleman's PF_RING > (http://www.ntop.org/ntop.html) netdevice into the kernel. He has > replicated unfortunately a lot of the stuff already done by MMAPED > packet socket - but i think we can forgive him since solution a) would > require hacking packet socket. > > Reinjection of packets still needs working for that device - just as > much as a few cleanups here and there. The problem is the guy is not > very responsive - I have a lot of notes on his stuff if you are willing > to chase him around. > You can then get redirection to this device for free (for either > incoming or outgoing packets); something like: > > tc filter add dev eth0 .... \ > match ip src 10.0.0.1/32 \ > action mirred egress redirect dev ring0 > > Assuming you have a program running on user space you should receive all > packets incoming and/or outgoing on eth0. > > And no, you dont need the eth device to have a ip address attached. Just mirror-ing will not meet my goal. I may also wish to drop packets entirely, before they ever reach any of the protocol stacks. That said, a brief glance at the ntop page leads me to believe that his packet socket might be interesting for other reasons. But, I have enough fun trying to push my own stuff into the kernel... probably won't bother trying to push his stuff in too :) Ben -- Ben Greear Candela Technologies Inc http://www.candelatech.com From jgarzik@pobox.com Wed Mar 2 14:40:35 2005 Received: with ECARTIS (v1.0.0; list netdev); Wed, 02 Mar 2005 14:40:39 -0800 (PST) Received: from parcelfarce.linux.theplanet.co.uk (IDENT:93@parcelfarce.linux.theplanet.co.uk [195.92.249.252]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j22MeYmu028186 for ; Wed, 2 Mar 2005 14:40:34 -0800 Received: from [69.134.152.124] (helo=[10.10.10.88]) by parcelfarce.linux.theplanet.co.uk with asmtp (TLSv1:AES256-SHA:256) (Exim 4.33) id 1D6cW7-00074E-Do; Wed, 02 Mar 2005 22:40:31 +0000 Message-ID: <422640CE.1040300@pobox.com> Date: Wed, 02 Mar 2005 17:40:14 -0500 From: Jeff Garzik User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.3) Gecko/20040922 X-Accept-Language: en-us, en MIME-Version: 1.0 To: hadi@cyberus.ca CC: Stephen Hemminger , "David S. Miller" , netdev@oss.sgi.com Subject: Re: [PATCH] remove dead extern's in netdevice.h References: <20050302105902.72f2b983@dxpl.pdx.osdl.net> <1109799408.1098.193.camel@jzny.localdomain> In-Reply-To: <1109799408.1098.193.camel@jzny.localdomain> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV 0.83/742/Tue Mar 1 17:05:59 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 2277 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: jgarzik@pobox.com Precedence: bulk X-list: netdev jamal wrote: > If you want to do this, you might as well kill hardware flow control. > I dont remember what the last decision was when we last pinged people. > Jeff? I'm pretty sure hw flow control is already gone... Jeff From jgarzik@pobox.com Wed Mar 2 14:42:10 2005 Received: with ECARTIS (v1.0.0; list netdev); Wed, 02 Mar 2005 14:42:15 -0800 (PST) Received: from parcelfarce.linux.theplanet.co.uk (IDENT:93@parcelfarce.linux.theplanet.co.uk [195.92.249.252]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j22Mg9TG028634 for ; Wed, 2 Mar 2005 14:42:09 -0800 Received: from [69.134.152.124] (helo=[10.10.10.88]) by parcelfarce.linux.theplanet.co.uk with asmtp (TLSv1:AES256-SHA:256) (Exim 4.33) id 1D6cXe-00077p-8N; Wed, 02 Mar 2005 22:42:06 +0000 Message-ID: <4226412E.6070403@pobox.com> Date: Wed, 02 Mar 2005 17:41:50 -0500 From: Jeff Garzik User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.3) Gecko/20040922 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Andrew Morton CC: bunk@stusta.de, netdev@oss.sgi.com, linux-kernel@vger.kernel.org Subject: Re: [2.6.11-rc4-mm1 patch] fix buggy IEEE80211_CRYPT_* selects References: <20050223014233.6710fd73.akpm@osdl.org> <20050226113123.GJ3311@stusta.de> <42256078.1040002@pobox.com> <20050302140833.GD4608@stusta.de> <42261004.4000501@pobox.com> <20050302123829.51dbc44b.akpm@osdl.org> <42262B08.2040401@pobox.com> <20050302131817.2e61805f.akpm@osdl.org> In-Reply-To: <20050302131817.2e61805f.akpm@osdl.org> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV 0.83/742/Tue Mar 1 17:05:59 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 2278 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: jgarzik@pobox.com Precedence: bulk X-list: netdev Andrew Morton wrote: > Jeff Garzik wrote: > >>>Thing is, CRYPTO_AES on only selectable on x86. >> >> You're thinking about CRYPTO_AES_586. But looking at crypto/Kconfig, >> the dependencies are a bit weird: >> >> config CRYPTO_AES >> tristate "AES cipher algorithms" >> depends on CRYPTO && !(X86 && !X86_64) >> config CRYPTO_AES_586 >> tristate "AES cipher algorithms (i586)" >> depends on CRYPTO && (X86 && !X86_64) > > > That's pretty broken, isn't it? > > Would be better to just do: > > config CRYPTO_AES > select CRYPTO_AES_586 if (X86 && !X86_64) > select CRYPTO_AES_OTHER if !(X86 && !X86_64) > > and hide CRYPTO_AES_586 and CRYPTO_AES_OTHER from the outside world. Not really that easy. For x86 we have aes aes-586 aes-via And my own personal custom-kernel preference is to use the C version of the code on my x86 and x86-64 boxes. Jeff From bunk@stusta.de Wed Mar 2 14:45:58 2005 Received: with ECARTIS (v1.0.0; list netdev); Wed, 02 Mar 2005 14:46:02 -0800 (PST) Received: from mailout.stusta.mhn.de (emailhub.stusta.mhn.de [141.84.69.5]) by oss.sgi.com (8.13.0/8.13.0) with SMTP id j22Mjv3a029364 for ; Wed, 2 Mar 2005 14:45:58 -0800 Received: (qmail 29176 invoked from network); 2 Mar 2005 22:45:51 -0000 Received: from r063144.stusta.swh.mhn.de (10.150.63.144) by mailout.stusta.mhn.de with SMTP; 2 Mar 2005 22:45:51 -0000 Received: by r063144.stusta.swh.mhn.de (Postfix, from userid 1000) id DC607AFCF2; Wed, 2 Mar 2005 23:45:50 +0100 (CET) Date: Wed, 2 Mar 2005 23:45:50 +0100 From: Adrian Bunk To: Jeff Garzik Cc: Andrew Morton , netdev@oss.sgi.com, linux-kernel@vger.kernel.org Subject: Re: [2.6.11-rc4-mm1 patch] fix buggy IEEE80211_CRYPT_* selects Message-ID: <20050302224550.GJ4608@stusta.de> References: <20050223014233.6710fd73.akpm@osdl.org> <20050226113123.GJ3311@stusta.de> <42256078.1040002@pobox.com> <20050302140833.GD4608@stusta.de> <42261004.4000501@pobox.com> <20050302123829.51dbc44b.akpm@osdl.org> <42262B08.2040401@pobox.com> <20050302131817.2e61805f.akpm@osdl.org> <4226412E.6070403@pobox.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4226412E.6070403@pobox.com> User-Agent: Mutt/1.5.6+20040907i X-Virus-Scanned: ClamAV 0.83/742/Tue Mar 1 17:05:59 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 2279 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: bunk@stusta.de Precedence: bulk X-list: netdev On Wed, Mar 02, 2005 at 05:41:50PM -0500, Jeff Garzik wrote: > Andrew Morton wrote: > >Jeff Garzik wrote: > > > >>>Thing is, CRYPTO_AES on only selectable on x86. > >> > >>You're thinking about CRYPTO_AES_586. But looking at crypto/Kconfig, > >>the dependencies are a bit weird: > >> > >>config CRYPTO_AES > >> tristate "AES cipher algorithms" > >> depends on CRYPTO && !(X86 && !X86_64) > >>config CRYPTO_AES_586 > >> tristate "AES cipher algorithms (i586)" > >> depends on CRYPTO && (X86 && !X86_64) > > > > > >That's pretty broken, isn't it? > > > >Would be better to just do: > > > >config CRYPTO_AES > > select CRYPTO_AES_586 if (X86 && !X86_64) > > select CRYPTO_AES_OTHER if !(X86 && !X86_64) > > > >and hide CRYPTO_AES_586 and CRYPTO_AES_OTHER from the outside world. > > Not really that easy. For x86 we have > > aes > aes-586 > aes-via Where is aes-via? > And my own personal custom-kernel preference is to use the C version of > the code on my x86 and x86-64 boxes. That's already not possible today. > Jeff cu Adrian -- "Is there not promise of rain?" Ling Tan asked suddenly out of the darkness. There had been need of rain for many days. "Only a promise," Lao Er said. Pearl S. Buck - Dragon Seed From jgarzik@pobox.com Wed Mar 2 14:49:42 2005 Received: with ECARTIS (v1.0.0; list netdev); Wed, 02 Mar 2005 14:49:47 -0800 (PST) Received: from parcelfarce.linux.theplanet.co.uk (IDENT:93@parcelfarce.linux.theplanet.co.uk [195.92.249.252]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j22MnfgI029987 for ; Wed, 2 Mar 2005 14:49:41 -0800 Received: from [69.134.152.124] (helo=[10.10.10.88]) by parcelfarce.linux.theplanet.co.uk with asmtp (TLSv1:AES256-SHA:256) (Exim 4.33) id 1D6cey-0007G6-42; Wed, 02 Mar 2005 22:49:40 +0000 Message-ID: <422642F6.5040102@pobox.com> Date: Wed, 02 Mar 2005 17:49:26 -0500 From: Jeff Garzik User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.3) Gecko/20040922 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Adrian Bunk CC: Andrew Morton , netdev@oss.sgi.com, linux-kernel@vger.kernel.org Subject: Re: [2.6.11-rc4-mm1 patch] fix buggy IEEE80211_CRYPT_* selects References: <20050223014233.6710fd73.akpm@osdl.org> <20050226113123.GJ3311@stusta.de> <42256078.1040002@pobox.com> <20050302140833.GD4608@stusta.de> <42261004.4000501@pobox.com> <20050302123829.51dbc44b.akpm@osdl.org> <42262B08.2040401@pobox.com> <20050302131817.2e61805f.akpm@osdl.org> <4226412E.6070403@pobox.com> <20050302224550.GJ4608@stusta.de> In-Reply-To: <20050302224550.GJ4608@stusta.de> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV 0.83/742/Tue Mar 1 17:05:59 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 2280 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: jgarzik@pobox.com Precedence: bulk X-list: netdev Adrian Bunk wrote: > On Wed, Mar 02, 2005 at 05:41:50PM -0500, Jeff Garzik wrote: > >>Andrew Morton wrote: >> >>>Jeff Garzik wrote: >>> >>> >>>>>Thing is, CRYPTO_AES on only selectable on x86. >>>> >>>>You're thinking about CRYPTO_AES_586. But looking at crypto/Kconfig, >>>>the dependencies are a bit weird: >>>> >>>>config CRYPTO_AES >>>> tristate "AES cipher algorithms" >>>> depends on CRYPTO && !(X86 && !X86_64) >>>>config CRYPTO_AES_586 >>>> tristate "AES cipher algorithms (i586)" >>>> depends on CRYPTO && (X86 && !X86_64) >>> >>> >>>That's pretty broken, isn't it? >>> >>>Would be better to just do: >>> >>>config CRYPTO_AES >>> select CRYPTO_AES_586 if (X86 && !X86_64) >>> select CRYPTO_AES_OTHER if !(X86 && !X86_64) >>> >>>and hide CRYPTO_AES_586 and CRYPTO_AES_OTHER from the outside world. >> >>Not really that easy. For x86 we have >> >> aes >> aes-586 >> aes-via > > > Where is aes-via? drivers/crypto >>And my own personal custom-kernel preference is to use the C version of >>the code on my x86 and x86-64 boxes. > > > That's already not possible today. It should be. Jeff From tgraf@suug.ch Wed Mar 2 14:55:41 2005 Received: with ECARTIS (v1.0.0; list netdev); Wed, 02 Mar 2005 14:55:47 -0800 (PST) Received: from b.mx.projectdream.org (eth0-0.arisu.projectdream.org [194.158.4.191]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j22MteI9030729 for ; Wed, 2 Mar 2005 14:55:41 -0800 Received: from postel.suug.ch (postel.suug.ch [195.134.158.23]) (using TLSv1 with cipher EDH-RSA-DES-CBC3-SHA (168/168 bits)) (No client certificate requested) by b.mx.projectdream.org (Postfix) with ESMTP id 3133488; Wed, 2 Mar 2005 23:55:16 +0100 (CET) Received: by postel.suug.ch (Postfix, from userid 10001) id 5F89B1C0EA; Wed, 2 Mar 2005 23:55:58 +0100 (CET) Date: Wed, 2 Mar 2005 23:55:58 +0100 From: Thomas Graf To: jamal Cc: Ben Greear , "'netdev@oss.sgi.com'" Subject: Re: Interconnect virtual device? Message-ID: <20050302225558.GS31837@postel.suug.ch> References: <4222A8F2.6080004@candelatech.com> <1109592365.2188.914.camel@jzny.localdomain> <422353C9.6050001@candelatech.com> <1109800554.1091.213.camel@jzny.localdomain> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1109800554.1091.213.camel@jzny.localdomain> X-Virus-Scanned: ClamAV 0.83/742/Tue Mar 1 17:05:59 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 2281 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: tgraf@suug.ch Precedence: bulk X-list: netdev > b) My preference is to push this gentleman's PF_RING > (http://www.ntop.org/ntop.html) netdevice into the kernel. He has > replicated unfortunately a lot of the stuff already done by MMAPED > packet socket - but i think we can forgive him since solution a) would > require hacking packet socket. > > Reinjection of packets still needs working for that device - just as > much as a few cleanups here and there. The problem is the guy is not > very responsive - I have a lot of notes on his stuff if you are willing > to chase him around. > You can then get redirection to this device for free (for either > incoming or outgoing packets); something like: > > tc filter add dev eth0 .... \ > match ip src 10.0.0.1/32 \ > action mirred egress redirect dev ring0 I think we talked about this once already and I do like the idea but the reinjection is at least of the same importance to me. What I'm thinking of basically gets down to two ring buffers both holding mmaped buffers. The action enqueues skbs to the first ring buffer and userspace dequeues it from there. The skb gets completely lost at this point by having it shot or just cloned if mirroring is requested. Userspace may reinject the skb again by putting it onto the second ring buffer for a kernel thread to pick up and reinject it at netif_receive_skb. Userspace may do whathever it likes as long as the checksum gets corrected, it may also fragment packets and reinject more than it originally received. Obviously for the redirect to userspace the skb must fullfil quite a lot of requirements only achievable on ingress but it would open up possibilities quite a lot. From tgraf@suug.ch Wed Mar 2 14:59:03 2005 Received: with ECARTIS (v1.0.0; list netdev); Wed, 02 Mar 2005 14:59:08 -0800 (PST) Received: from b.mx.projectdream.org (eth0-0.arisu.projectdream.org [194.158.4.191]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j22Mx2eu031353 for ; Wed, 2 Mar 2005 14:59:03 -0800 Received: from postel.suug.ch (postel.suug.ch [195.134.158.23]) (using TLSv1 with cipher EDH-RSA-DES-CBC3-SHA (168/168 bits)) (No client certificate requested) by b.mx.projectdream.org (Postfix) with ESMTP id A03A388; Wed, 2 Mar 2005 23:58:39 +0100 (CET) Received: by postel.suug.ch (Postfix, from userid 10001) id BAB831C0EA; Wed, 2 Mar 2005 23:59:22 +0100 (CET) Date: Wed, 2 Mar 2005 23:59:22 +0100 From: Thomas Graf To: "David S. Miller" Cc: Christoph Hellwig , shemminger@osdl.org, netdev@oss.sgi.com Subject: Re: [PATCH] remove dead skb_iter code Message-ID: <20050302225922.GT31837@postel.suug.ch> References: <20050302101035.61786113@dxpl.pdx.osdl.net> <20050302102025.23f479f9.davem@davemloft.net> <20050302220735.GB25847@infradead.org> <20050302142542.2ae86040.davem@davemloft.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20050302142542.2ae86040.davem@davemloft.net> X-Virus-Scanned: ClamAV 0.83/742/Tue Mar 1 17:05:59 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 2282 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: tgraf@suug.ch Precedence: bulk X-list: netdev * David S. Miller <20050302142542.2ae86040.davem@davemloft.net> 2005-03-02 14:25 > On Wed, 2 Mar 2005 22:07:35 +0000 > Christoph Hellwig wrote: > > > Maybe because the removal is right. This code is not dependent on > > any networking internals so it can easily live in a netfilter support > > module instead of bloating everyones kernels. > > Fine, I'll kill it for now. (I also happen to know that it might > be used for ipv4 fragmentation tricks too, but that's also in the > future). It will be used for the string matching API shared by netfilter and ematches. Not sure yet whether it will live in lib/ or net/netfilter though. From tgraf@suug.ch Wed Mar 2 15:13:41 2005 Received: with ECARTIS (v1.0.0; list netdev); Wed, 02 Mar 2005 15:13:45 -0800 (PST) Received: from b.mx.projectdream.org (eth0-0.arisu.projectdream.org [194.158.4.191]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j22NDewK032334 for ; Wed, 2 Mar 2005 15:13:41 -0800 Received: from postel.suug.ch (postel.suug.ch [195.134.158.23]) (using TLSv1 with cipher EDH-RSA-DES-CBC3-SHA (168/168 bits)) (No client certificate requested) by b.mx.projectdream.org (Postfix) with ESMTP id BB57888; Thu, 3 Mar 2005 00:13:17 +0100 (CET) Received: by postel.suug.ch (Postfix, from userid 10001) id 0859D1C0EA; Thu, 3 Mar 2005 00:14:00 +0100 (CET) Date: Thu, 3 Mar 2005 00:14:00 +0100 From: Thomas Graf To: jamal Cc: Peter Bieringer , Maillist USAGI-users , Maillist netdev Subject: Re: ip -6 addr flush dev flushes also the autogenerated link-local address Message-ID: <20050302231400.GU31837@postel.suug.ch> References: <001C540DBA8D9308CA5D790F@worker.muc.bieringer.de> <1109801372.1098.228.camel@jzny.localdomain> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1109801372.1098.228.camel@jzny.localdomain> X-Virus-Scanned: ClamAV 0.83/742/Tue Mar 1 17:05:59 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 2283 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: tgraf@suug.ch Precedence: bulk X-list: netdev * jamal <1109801372.1098.228.camel@jzny.localdomain> 2005-03-02 17:09 > > Is this a user space problem? I think we had something along these lines > fixed recently. Thomas? I didn't fix any of these but it's definitely a userspace problem. One can easly work around this by iterating over all scopes except for link local and provide the scope to flush. We'll have to put additional filters into print_addrinfo() if we want this to be default but I'm not even sure what the official policy should be like. Any standards on this? From yoshfuji@linux-ipv6.org Wed Mar 2 15:58:40 2005 Received: with ECARTIS (v1.0.0; list netdev); Wed, 02 Mar 2005 15:58:46 -0800 (PST) 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 j22NweUd001881 for ; Wed, 2 Mar 2005 15:58:40 -0800 Received: from localhost (localhost [127.0.0.1]) by yue.st-paulia.net (Postfix) with ESMTP id DB22533CC2; Thu, 3 Mar 2005 09:00:09 +0900 (JST) Date: Thu, 03 Mar 2005 09:00:09 +0900 (JST) Message-Id: <20050303.090009.59651076.yoshfuji@linux-ipv6.org> To: tgraf@suug.ch Cc: hadi@cyberus.ca, pb@bieringer.de, usagi-users@linux-ipv6.org, netdev@oss.sgi.com, yoshfuji@linux-ipv6.org Subject: Re: ip -6 addr flush dev flushes also the autogenerated link-local address From: YOSHIFUJI Hideaki / =?iso-2022-jp?B?GyRCNUhGIzFRTEAbKEI=?= In-Reply-To: <20050302231400.GU31837@postel.suug.ch> References: <001C540DBA8D9308CA5D790F@worker.muc.bieringer.de> <1109801372.1098.228.camel@jzny.localdomain> <20050302231400.GU31837@postel.suug.ch> Organization: USAGI Project X-URL: http://www.yoshifuji.org/%7Ehideaki/ X-Fingerprint: 9022 65EB 1ECF 3AD1 0BDF 80D8 4807 F894 E062 0EEA X-PGP-Key-URL: http://www.yoshifuji.org/%7Ehideaki/hideaki@yoshifuji.org.asc X-Face: "5$Al-.M>NJ%a'@hhZdQm:."qn~PA^gq4o*>iCFToq*bAi#4FRtx}enhuQKz7fNqQz\BYU] $~O_5m-9'}MIs`XGwIEscw;e5b>n"B_?j/AkL~i/MEaZBLP X-Mailer: Mew version 2.2 on Emacs 20.7 / Mule 4.1 (AOI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV 0.83/742/Tue Mar 1 17:05:59 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 2284 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 <20050302231400.GU31837@postel.suug.ch> (at Thu, 3 Mar 2005 00:14:00 +0100), Thomas Graf says: > * jamal <1109801372.1098.228.camel@jzny.localdomain> 2005-03-02 17:09 > > > > Is this a user space problem? I think we had something along these lines > > fixed recently. Thomas? > > I didn't fix any of these but it's definitely a userspace problem. > One can easly work around this by iterating over all scopes > except for link local and provide the scope to flush. We'll have > to put additional filters into print_addrinfo() if we want this > to be default but I'm not even sure what the official policy should > be like. Any standards on this? I believe that flush should remove all addresses including link-local. So, current behavior is correct. --yoshfuji From hadi@cyberus.ca Wed Mar 2 16:27:13 2005 Received: with ECARTIS (v1.0.0; list netdev); Wed, 02 Mar 2005 16:27:17 -0800 (PST) Received: from mx01.cybersurf.com (mx01.cybersurf.com [209.197.145.104]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j230RC8T006584 for ; Wed, 2 Mar 2005 16:27:13 -0800 Received: from mail.cyberus.ca ([209.197.145.21]) by mx01.cybersurf.com with esmtp (Exim 4.30) id 1D6eBE-0007In-Vx for netdev@oss.sgi.com; Wed, 02 Mar 2005 17:27:04 -0700 Received: from [24.103.99.32] (helo=[10.0.0.9]) by mail.cyberus.ca with esmtp (Exim 4.20) id 1D6eBI-0006oT-TH; Wed, 02 Mar 2005 19:27:09 -0500 Subject: Re: Interconnect virtual device? From: jamal Reply-To: hadi@cyberus.ca To: Ben Greear Cc: "'netdev@oss.sgi.com'" In-Reply-To: <42263F6A.3020405@candelatech.com> References: <4222A8F2.6080004@candelatech.com> <1109592365.2188.914.camel@jzny.localdomain> <422353C9.6050001@candelatech.com> <1109800554.1091.213.camel@jzny.localdomain> <42263F6A.3020405@candelatech.com> Content-Type: text/plain Organization: jamalopolous Message-Id: <1109809625.1092.239.camel@jzny.localdomain> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.2.2 Date: 02 Mar 2005 19:27:05 -0500 Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV 0.83/742/Tue Mar 1 17:05:59 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 2285 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: hadi@cyberus.ca Precedence: bulk X-list: netdev On Wed, 2005-03-02 at 17:34, Ben Greear wrote: > jamal wrote: > > > There are two ways to do this: > > > > a) You could redirect to a packet socket - a small extension needed to > > the redirect action (mostly mechanical details involved like keeping > > state of which sockets are open etc). > > I'd rather not take this approach, as I'd like to have this > functionality available in a kernel module as well as user-space. Netdevices > are easy to work with in both user-space and kernel-space. sure - you have modules and user space interface. But lets drop it here - I dont like it either because it may end up being a lot of work. > > tc filter add dev eth0 .... \ > > match ip src 10.0.0.1/32 \ > > action mirred egress redirect dev ring0 > > > > Assuming you have a program running on user space you should receive all > > packets incoming and/or outgoing on eth0. > > > > And no, you dont need the eth device to have a ip address attached. > > Just mirror-ing will not meet my goal. The above was a total redirect, not mirroring; to mirror you would say "action mirred egress mirror dev ring0" And for fun you could mirror to multiple devices if you wanted. > I may also wish to drop packets > entirely, before they ever reach any of the protocol stacks. Of course thats what the actions are for. tc packets coming on dev XXXX before stack match some header .. action drop Or to add to the fun factor: match some header ... // randomly allow every 10th packet action drop random netrand ok 10 // and redirect the lucky packet to user space action mirred egress redirect dev ring0 > That said, a brief glance at the ntop page leads me to believe that > his packet socket might be interesting for other reasons. But, I have > enough fun trying to push my own stuff into the kernel... probably > won't bother trying to push his stuff in too :) > Clearly above you are trying to reinvent whats already available. And i pointed to that gent because i think hes done a good job already - theres no point in reinventing what he already has in particular since hes spent time to debug it and hes got people using it already (he seems to be selling some product based on it). If he fails to cooperate then by all means replicating his work should be fine. cheers, jamal From hadi@cyberus.ca Wed Mar 2 16:35:15 2005 Received: with ECARTIS (v1.0.0; list netdev); Wed, 02 Mar 2005 16:35:18 -0800 (PST) Received: from mx03.cybersurf.com (mx03.cybersurf.com [209.197.145.106]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j230ZElI007304 for ; Wed, 2 Mar 2005 16:35:15 -0800 Received: from mail.cyberus.ca ([209.197.145.21]) by mx03.cybersurf.com with esmtp (Exim 4.30) id 1D6eJ9-0007bY-3Y for netdev@oss.sgi.com; Wed, 02 Mar 2005 19:35:15 -0500 Received: from [24.103.99.32] (helo=[10.0.0.9]) by mail.cyberus.ca with esmtp (Exim 4.20) id 1D6eJ1-0007sZ-PW; Wed, 02 Mar 2005 19:35:08 -0500 Subject: Re: Interconnect virtual device? From: jamal Reply-To: hadi@cyberus.ca To: Thomas Graf Cc: Ben Greear , "'netdev@oss.sgi.com'" In-Reply-To: <20050302225558.GS31837@postel.suug.ch> References: <4222A8F2.6080004@candelatech.com> <1109592365.2188.914.camel@jzny.localdomain> <422353C9.6050001@candelatech.com> <1109800554.1091.213.camel@jzny.localdomain> <20050302225558.GS31837@postel.suug.ch> Content-Type: text/plain Organization: jamalopolous Message-Id: <1109810103.1090.247.camel@jzny.localdomain> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.2.2 Date: 02 Mar 2005 19:35:03 -0500 Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV 0.83/742/Tue Mar 1 17:05:59 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 2286 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: hadi@cyberus.ca Precedence: bulk X-list: netdev On Wed, 2005-03-02 at 17:55, Thomas Graf wrote: > I think we talked about this once already and I do like the idea > but the reinjection is at least of the same importance to me. What > I'm thinking of basically gets down to two ring buffers both holding > mmaped buffers. The ring device already has the recv side direction ring, Whats needed is tx side. > The action enqueues skbs to the first ring buffer > and userspace dequeues it from there. The skb gets completely lost > at this point by having it shot or just cloned if mirroring is requested. This will happen by default i.e the mirred action will take care of buffer management and hopefully the ring device will worry about reusing those skbs. > Userspace may reinject the skb again by putting it onto the second > ring buffer for a kernel thread to pick up and reinject it at > netif_receive_skb. Userspace may do whathever it likes as long as > the checksum gets corrected, it may also fragment packets and reinject > more than it originally received. Obviously for the redirect to > userspace the skb must fullfil quite a lot of requirements only > achievable on ingress but it would open up possibilities quite a lot. One thing the PF_RING device needs is some form of metadata that can be passed to user space. PF_PACKET with MMAP has a few, but we need to do a lot more such as exposing most if not all of the skb metadata. Similarly, the direction from user space will contain details of where this packet is going to go (ingress vs egress) - PF_PACKET assumes egress only at the moment. cheers, jamal From flamingice@sourmilk.net Wed Mar 2 17:57:38 2005 Received: with ECARTIS (v1.0.0; list netdev); Wed, 02 Mar 2005 17:57:43 -0800 (PST) Received: from server8.totalchoicehosting.com (server8.totalchoicehosting.com [216.180.241.250]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j231vc2Z010315 for ; Wed, 2 Mar 2005 17:57:38 -0800 Received: from host-24-225-148-91.patmedia.net ([24.225.148.91] helo=[192.168.0.100]) by server8.totalchoicehosting.com with esmtpsa (TLSv1:RC4-MD5:128) (Exim 4.44) id 1D6fao-00011s-L6 for netdev@oss.sgi.com; Wed, 02 Mar 2005 20:57:34 -0500 From: Michael Wu To: netdev@oss.sgi.com Subject: merging adm8211 Date: Wed, 2 Mar 2005 20:57:16 -0500 User-Agent: KMail/1.7.1 MIME-Version: 1.0 Content-Type: multipart/signed; boundary="nextPart5143523.WKJVzsIpdb"; protocol="application/pgp-signature"; micalg=pgp-sha1 Content-Transfer-Encoding: 7bit Message-Id: <200503022057.24558.flamingice@sourmilk.net> X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - server8.totalchoicehosting.com X-AntiAbuse: Original Domain - oss.sgi.com X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - sourmilk.net X-Source: X-Source-Args: X-Source-Dir: X-Virus-Scanned: ClamAV 0.83/742/Tue Mar 1 17:05:59 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 2287 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: flamingice@sourmilk.net Precedence: bulk X-list: netdev --nextPart5143523.WKJVzsIpdb Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Hi, I've been looking at the recent 802.11 work in the -mm tree, and it's look= ing=20 good so far. However, it doesn't seem to have the authentication/=20 association/scanning stuff that the adm8211 needs. I remember that was=20 suppose to be done in userspace, but the current code doesn't seem to have= =20 anything like it. So.. is any work being done on it? Does that code have to be strictly in=20 userspace? I'm not sure I like having to run a daemon for only certain=20 wireless cards. I'd rather have a minimal set of 802.11 station/management= =20 functionality in the kernel for basic managed/adhoc/monitor/WEP features,=20 while restricting the use of WPA/HostAP/etc. to userspace. But, I have no=20 problems either way. I'd just like to know the current state of things and= =20 what people are working on.. Thanks, =2DMichael Wu --nextPart5143523.WKJVzsIpdb Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.6 (GNU/Linux) iD8DBQBCJm8EyWWBbDEe0UIRAlMQAKCYZ9BUkP3OKxDHdlF+VQQEkTrYxQCgtDh+ uK2NfPbpMB2rSbTYr456EoI= =pMvE -----END PGP SIGNATURE----- --nextPart5143523.WKJVzsIpdb-- From kaigai@ak.jp.nec.com Wed Mar 2 19:19:21 2005 Received: with ECARTIS (v1.0.0; list netdev); Wed, 02 Mar 2005 19:19:33 -0800 (PST) Received: from tyo201.gate.nec.co.jp (TYO201.gate.nec.co.jp [202.32.8.214]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j233JKKC014113 for ; Wed, 2 Mar 2005 19:19:21 -0800 Received: from mailgate3.nec.co.jp (mailgate53.nec.co.jp [10.7.69.160] (may be forged)) by tyo201.gate.nec.co.jp (8.11.7/3.7W01080315) with ESMTP id j233Hk705809; Thu, 3 Mar 2005 12:17:46 +0900 (JST) Received: (from root@localhost) by mailgate3.nec.co.jp (8.11.7/3.7W-MAILGATE-NEC) id j233HkR27192; Thu, 3 Mar 2005 12:17:46 +0900 (JST) Received: from mailsv.bs1.fc.nec.co.jp (venus.hpc.bs1.fc.nec.co.jp [10.34.77.164]) by mailsv4.nec.co.jp (8.11.7/3.7W-MAILSV4-NEC) with ESMTP id j233Heg27924; Thu, 3 Mar 2005 12:17:40 +0900 (JST) Received: from mailsv.linux.bs1.fc.nec.co.jp (IDENT:postfix@namesv2.linux.bs1.fc.nec.co.jp [10.34.125.2]) by mailsv.bs1.fc.nec.co.jp (8.12.10/3.7W-HPC5.2F(mailsv)04081615) with ESMTP id j2337GIK029997; Thu, 3 Mar 2005 12:07:20 +0900 (JST) Received: from [10.34.125.249] (sanma.linux.bs1.fc.nec.co.jp [10.34.125.249]) by mailsv.linux.bs1.fc.nec.co.jp (Postfix) with ESMTP id 7F04F30987; Thu, 3 Mar 2005 12:17:35 +0900 (JST) Message-ID: <42268201.80706@ak.jp.nec.com> Date: Thu, 03 Mar 2005 12:18:25 +0900 From: Kaigai Kohei User-Agent: Mozilla Thunderbird 1.0 (Windows/20041206) X-Accept-Language: ja, en-us, en MIME-Version: 1.0 To: Guillaume Thouvenin Cc: Andrew Morton , lkml , Evgeniy Polyakov , elsa-devel , Jay Lan , Gerrit Huizenga , Erich Focht , Netlink List Subject: Re: [PATCH 2.6.11-rc4-mm1] connector: Add a fork connector References: <1109240677.1738.196.camel@frecb000711.frec.bull.fr> <1109753292.8422.117.camel@frecb000711.frec.bull.fr> In-Reply-To: <1109753292.8422.117.camel@frecb000711.frec.bull.fr> Content-Type: multipart/mixed; boundary="------------060300030509070400060409" X-Virus-Scanned: ClamAV 0.83/742/Tue Mar 1 17:05:59 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 2288 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: kaigai@ak.jp.nec.com Precedence: bulk X-list: netdev This is a multi-part message in MIME format. --------------060300030509070400060409 Content-Type: text/plain; charset=ISO-2022-JP Content-Transfer-Encoding: 7bit Hello, Guillaume I tried to measure the process-creation/destruction performance on 2.6.11-rc4-mm1 plus some extensiton(Normal/with PAGG/with Fork-Connector). But I received a following messages endlessly on system console with Fork-Connector extensiton. # on IA-64 environment / When an simple fork() iteration is run in parallel. skb does not have enough length: requested msg->len=10[28], nlh->nlmsg_len=48[32], skb->len=48[must be 30]. skb does not have enough length: requested msg->len=10[28], nlh->nlmsg_len=48[32], skb->len=48[must be 30]. skb does not have enough length: requested msg->len=10[28], nlh->nlmsg_len=48[32], skb->len=48[must be 30]. : Is's generated at drivers/connector/connector.c:__cn_rx_skb(), and this warn the length of msg's payload does not fit in nlmsghdr's length. This message means netlink packet is not sent to user space. I was notified occurence of fork() by printk(). :-( The attached simple *.c file can enable/disable fork-connector and listen the fork-notification. Because It's first experimence for me to write a code to use netlink, point out a right how-to-use if there's some mistakes at user side apprication. Thanks. P.S. I can't reproduce lockup on 367th-fork() with your latest patch. Guillaume Thouvenin wrote: > ChangeLog: > > - Add parenthesis around sizeof(struct cn_msg) + CN_FORK_INFO_SIZE > in the CN_FORK_MSG_SIZE macro > - fork_cn_lock is declareed with DEFINE_SPINLOCK() > - fork_cn_lock is defined as static and local to fork_connector() > - Create a specific module cn_fork.c in drivers/connector to > register the callback. > - Improve the callback that turns on/off the fork connector > > I also run the lmbench and results are send in response to another > thread "A common layer for Accounting packages". When fork connector is > turned off the overhead is negligible. This patch works with another > small patch that fix a problem in the connector. Without it, there is a > message that says "skb does not have enough length". It will be fix in > the next -mm tree I think. > > > Thanks everyone for the comments, > Guillaume -- Linux Promotion Center, NEC KaiGai Kohei --------------060300030509070400060409 Content-Type: text/plain; name="fclisten.c" Content-Transfer-Encoding: base64 Content-Disposition: inline; filename="fclisten.c" I2luY2x1ZGUgPHN0ZGlvLmg+CiNpbmNsdWRlIDxzdGRsaWIuaD4KI2luY2x1ZGUgPHN0cmlu Zy5oPgojaW5jbHVkZSA8YXNtL3R5cGVzLmg+CiNpbmNsdWRlIDxzeXMvdHlwZXMuaD4KI2lu Y2x1ZGUgPHN5cy9zb2NrZXQuaD4KI2luY2x1ZGUgPGxpbnV4L25ldGxpbmsuaD4KCnZvaWQg dXNhZ2UoKXsKICBwdXRzKCJ1c2FnZTogZmNsaXN0ZW4gPG9ufG9mZj4iKTsKICBwdXRzKCIg IERlZmF1bHQgLT4gbGlzdGVuaW5nIGZvcmstY29ubmVjdG9yIik7CiAgcHV0cygiICBvbiAg ICAgIC0+IGZvcmstY29ubmVjdG9yIEVuYWJsZSIpOwogIHB1dHMoIiAgb2ZmICAgICAtPiBm b3JrLWNvbm5lY3RvciBEaXNhYmxlIik7CiAgZXhpdCgwKTsKfQoKI2RlZmluZSBNT0RFX0xJ U1RFTiAgKDEpCiNkZWZpbmUgTU9ERV9FTkFCTEUgICgyKQojZGVmaW5lIE1PREVfRElTQUJM RSAoMykKCnN0cnVjdCBjYl9pZAp7CiAgX191MzIgICAgICAgICAgICAgICAgICAgaWR4Owog IF9fdTMyICAgICAgICAgICAgICAgICAgIHZhbDsKfTsKCnN0cnVjdCBjbl9tc2cKewogIHN0 cnVjdCBjYl9pZCAgICAgICAgICAgIGlkOwogIF9fdTMyICAgICAgICAgICAgICAgICAgIHNl cTsKICBfX3UzMiAgICAgICAgICAgICAgICAgICBhY2s7CiAgX191MzIgICAgICAgICAgICAg ICAgICAgbGVuOyAgICAgICAgICAgIC8qIExlbmd0aCBvZiB0aGUgZm9sbG93aW5nIGRhdGEg Ki8KICBfX3U4ICAgICAgICAgICAgICAgICAgICBkYXRhWzBdOwp9OwoKCmludCBtYWluKGlu dCBhcmdjLCBjaGFyICphcmd2W10pewogIGNoYXIgYnVmWzQwOTZdOwogIGludCBtb2RlLCBz b2NrZmQsIGxlbjsKICBzdHJ1Y3Qgc29ja2FkZHJfbmwgYWQ7CiAgc3RydWN0IG5sbXNnaGRy ICpoZHIgPSAoc3RydWN0IG5sbXNnaGRyICopYnVmOwogIHN0cnVjdCBjbl9tc2cgKm1zZyA9 IChzdHJ1Y3QgY25fbXNnICopKGJ1ZitzaXplb2Yoc3RydWN0IG5sbXNnaGRyKSk7CiAgCiAg c3dpdGNoKGFyZ2MpewogIGNhc2UgMToKICAgIG1vZGUgPSBNT0RFX0xJU1RFTjsKICAgIGJy ZWFrOwogIGNhc2UgMjoKICAgIGlmIChzdHJjYXNlY21wKCJvbiIsYXJndlsxXSk9PTApIHsK ICAgICAgbW9kZSA9IE1PREVfRU5BQkxFOwogICAgfWVsc2UgaWYgKHN0cmNhc2VjbXAoIm9m ZiIsYXJndlsxXSk9PTApewogICAgICBtb2RlID0gTU9ERV9ESVNBQkxFOwogICAgfWVsc2V7 CiAgICAgIHVzYWdlKCk7CiAgICB9CiAgICBicmVhazsKICBkZWZhdWx0OgogICAgdXNhZ2Uo KTsKICAgIGJyZWFrOwogIH0KICAKICBpZiggKHNvY2tmZD1zb2NrZXQoUEZfTkVUTElOSywg U09DS19SQVcsIE5FVExJTktfTkZMT0cpKSA8IDAgKXsKICAgIGZwcmludGYoc3RkZXJyLCAi RmF1bHQgb24gc29ja2V0KCkuXG4iKTsKICAgIHJldHVybiggMSApOwogIH0KICBhZC5ubF9m YW1pbHkgPSBBRl9ORVRMSU5LOwogIGFkLm5sX3BhZCA9IDA7CiAgYWQubmxfcGlkID0gZ2V0 cGlkKCk7CiAgYWQubmxfZ3JvdXBzID0gLTE7CiAgaWYoIGJpbmQoc29ja2ZkLCAoc3RydWN0 IHNvY2thZGRyICopJmFkLCBzaXplb2YoYWQpKSApewogICAgZnByaW50ZihzdGRlcnIsICJG YXVsdCBvbiBiaW5kIHRvIG5ldGxpbmsuXG4iKTsKICAgIHJldHVybiggMiApOwogIH0KCiAg aWYgKG1vZGU9PU1PREVfTElTVEVOKSB7CiAgICB3aGlsZSgtMSl7CiAgICAgIGxlbiA9IHJl Y3Zmcm9tKHNvY2tmZCwgYnVmLCA0MDk2LCAwLCBOVUxMLCBOVUxMKTsKICAgICAgcHJpbnRm KCIlZC1ieXRlIHJlY3YgU2VxPSVkXG4iLCBsZW4sIGhkci0+bmxtc2dfc2VxKTsKICAgIH0K ICB9ZWxzZXsKICAgIGFkLm5sX2ZhbWlseSA9IEFGX05FVExJTks7CiAgICBhZC5ubF9wYWQg PSAwOwogICAgYWQubmxfcGlkID0gMDsKICAgIGFkLm5sX2dyb3VwcyA9IDE7CiAgICAKICAg IGhkci0+bmxtc2dfbGVuID0gc2l6ZW9mKHN0cnVjdCBubG1zZ2hkcikgKyBzaXplb2Yoc3Ry dWN0IGNuX21zZykgKyBzaXplb2YoaW50KTsKICAgIGhkci0+bmxtc2dfdHlwZSA9IDA7CiAg ICBoZHItPm5sbXNnX2ZsYWdzID0gMDsKICAgIGhkci0+bmxtc2dfc2VxID0gMDsKICAgIGhk ci0+bmxtc2dfcGlkID0gZ2V0cGlkKCk7CiAgICBtc2ctPmlkLmlkeCA9IDB4ZmVlZDsKICAg IG1zZy0+aWQudmFsID0gMHhiZWVmOwogICAgbXNnLT5zZXEgPSBtc2ctPmFjayA9IDA7CiAg ICBtc2ctPmxlbiA9IHNpemVvZihpbnQpOwoKICAgIGlmIChtb2RlPT1NT0RFX0VOQUJMRSl7 CiAgICAgICgqKGludCAqKShtc2ctPmRhdGEpKSA9IDE7CiAgICB9IGVsc2UgewogICAgICAo KihpbnQgKikobXNnLT5kYXRhKSkgPSAwOwogICAgfQogICAgc2VuZHRvKHNvY2tmZCwgYnVm LCBzaXplb2Yoc3RydWN0IG5sbXNnaGRyKStzaXplb2Yoc3RydWN0IGNuX21zZykrc2l6ZW9m KGludCksCgkgICAwLCAoc3RydWN0IHNvY2thZGRyICopJmFkLCBzaXplb2YoYWQpKTsKICB9 Cn0K --------------060300030509070400060409-- From johnpol@2ka.mipt.ru Wed Mar 2 21:47:40 2005 Received: with ECARTIS (v1.0.0; list netdev); Wed, 02 Mar 2005 21:47:52 -0800 (PST) Received: from 2ka.mipt.ru (relay.2ka.mipt.ru [194.85.82.65]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j235ldaO023999 for ; Wed, 2 Mar 2005 21:47:39 -0800 Received: from 2ka.mipt.ru (localhost [127.0.0.1]) by 2ka.mipt.ru (8.12.11/8.12.11) with ESMTP id j235kxPS024655; Thu, 3 Mar 2005 08:46:59 +0300 Received: (from johnpol@localhost) by 2ka.mipt.ru (8.12.11/8.12.1/Submit) id j235kub9024652; Thu, 3 Mar 2005 08:46:56 +0300 Date: Thu, 3 Mar 2005 08:46:56 +0300 From: Evgeniy Polyakov To: Kaigai Kohei Cc: Guillaume Thouvenin , Andrew Morton , lkml , elsa-devel , Jay Lan , Gerrit Huizenga , Erich Focht , Netlink List Subject: Re: [PATCH 2.6.11-rc4-mm1] connector: Add a fork connector Message-ID: <20050303084656.A15197@2ka.mipt.ru> References: <1109240677.1738.196.camel@frecb000711.frec.bull.fr> <1109753292.8422.117.camel@frecb000711.frec.bull.fr> <42268201.80706@ak.jp.nec.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5.1i In-Reply-To: <42268201.80706@ak.jp.nec.com>; from kaigai@ak.jp.nec.com on Thu, Mar 03, 2005 at 12:18:25PM +0900 X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-1.7.5 (2ka.mipt.ru [0.0.0.0]); Thu, 03 Mar 2005 08:46:59 +0300 (MSK) X-Virus-Scanned: ClamAV 0.83/742/Tue Mar 1 17:05:59 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 2289 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: johnpol@2ka.mipt.ru Precedence: bulk X-list: netdev On Thu, Mar 03, 2005 at 12:18:25PM +0900, Kaigai Kohei (kaigai@ak.jp.nec.com) wrote: > Hello, Guillaume > > I tried to measure the process-creation/destruction performance on 2.6.11-rc4-mm1 plus > some extensiton(Normal/with PAGG/with Fork-Connector). > But I received a following messages endlessly on system console with Fork-Connector extensiton. > > # on IA-64 environment / When an simple fork() iteration is run in parallel. > skb does not have enough length: requested msg->len=10[28], nlh->nlmsg_len=48[32], skb->len=48[must be 30]. > skb does not have enough length: requested msg->len=10[28], nlh->nlmsg_len=48[32], skb->len=48[must be 30]. > skb does not have enough length: requested msg->len=10[28], nlh->nlmsg_len=48[32], skb->len=48[must be 30]. > : > > Is's generated at drivers/connector/connector.c:__cn_rx_skb(), and this warn the length of msg's payload > does not fit in nlmsghdr's length. > This message means netlink packet is not sent to user space. > I was notified occurence of fork() by printk(). :-( No, lengths are correct, but skb can be dropped due to misaligned sizes check. > The attached simple *.c file can enable/disable fork-connector and listen the fork-notification. > Because It's first experimence for me to write a code to use netlink, point out a right how-to-use > if there's some mistakes at user side apprication. > > Thanks. > > P.S. I can't reproduce lockup on 367th-fork() with your latest patch. I've sent that patch to Guillaume and upstream, hopefully it will be integrated into next -mm release. > Guillaume Thouvenin wrote: > > ChangeLog: > > > > - Add parenthesis around sizeof(struct cn_msg) + CN_FORK_INFO_SIZE > > in the CN_FORK_MSG_SIZE macro > > - fork_cn_lock is declareed with DEFINE_SPINLOCK() > > - fork_cn_lock is defined as static and local to fork_connector() > > - Create a specific module cn_fork.c in drivers/connector to > > register the callback. > > - Improve the callback that turns on/off the fork connector > > > > I also run the lmbench and results are send in response to another > > thread "A common layer for Accounting packages". When fork connector is > > turned off the overhead is negligible. This patch works with another > > small patch that fix a problem in the connector. Without it, there is a > > message that says "skb does not have enough length". It will be fix in > > the next -mm tree I think. > > > > > > Thanks everyone for the comments, > > Guillaume > > -- > Linux Promotion Center, NEC > KaiGai Kohei > #include > #include > #include > #include > #include > #include > #include > > void usage(){ > puts("usage: fclisten "); > puts(" Default -> listening fork-connector"); > puts(" on -> fork-connector Enable"); > puts(" off -> fork-connector Disable"); > exit(0); > } > > #define MODE_LISTEN (1) > #define MODE_ENABLE (2) > #define MODE_DISABLE (3) > > struct cb_id > { > __u32 idx; > __u32 val; > }; > > struct cn_msg > { > struct cb_id id; > __u32 seq; > __u32 ack; > __u32 len; /* Length of the following data */ > __u8 data[0]; > }; > > > int main(int argc, char *argv[]){ > char buf[4096]; > int mode, sockfd, len; > struct sockaddr_nl ad; > struct nlmsghdr *hdr = (struct nlmsghdr *)buf; > struct cn_msg *msg = (struct cn_msg *)(buf+sizeof(struct nlmsghdr)); > > switch(argc){ > case 1: > mode = MODE_LISTEN; > break; > case 2: > if (strcasecmp("on",argv[1])==0) { > mode = MODE_ENABLE; > }else if (strcasecmp("off",argv[1])==0){ > mode = MODE_DISABLE; > }else{ > usage(); > } > break; > default: > usage(); > break; > } > > if( (sockfd=socket(PF_NETLINK, SOCK_RAW, NETLINK_NFLOG)) < 0 ){ > fprintf(stderr, "Fault on socket().\n"); > return( 1 ); > } > ad.nl_family = AF_NETLINK; > ad.nl_pad = 0; > ad.nl_pid = getpid(); > ad.nl_groups = -1; Group should be CN_FORK_IDX to receive only fork's messages. > if( bind(sockfd, (struct sockaddr *)&ad, sizeof(ad)) ){ > fprintf(stderr, "Fault on bind to netlink.\n"); > return( 2 ); > } > > if (mode==MODE_LISTEN) { > while(-1){ > len = recvfrom(sockfd, buf, 4096, 0, NULL, NULL); > printf("%d-byte recv Seq=%d\n", len, hdr->nlmsg_seq); > } > }else{ > ad.nl_family = AF_NETLINK; > ad.nl_pad = 0; > ad.nl_pid = 0; > ad.nl_groups = 1; > > hdr->nlmsg_len = sizeof(struct nlmsghdr) + sizeof(struct cn_msg) + sizeof(int); > hdr->nlmsg_type = 0; > hdr->nlmsg_flags = 0; > hdr->nlmsg_seq = 0; > hdr->nlmsg_pid = getpid(); > msg->id.idx = 0xfeed; > msg->id.val = 0xbeef; > msg->seq = msg->ack = 0; > msg->len = sizeof(int); > > if (mode==MODE_ENABLE){ > (*(int *)(msg->data)) = 1; > } else { > (*(int *)(msg->data)) = 0; > } > sendto(sockfd, buf, sizeof(struct nlmsghdr)+sizeof(struct cn_msg)+sizeof(int), > 0, (struct sockaddr *)&ad, sizeof(ad)); > } > } Later today I will post finished connector.c with the all pending patches in, and simple test program for anyone, who wants to test fork() performace with and without fork's connector enabled. Since Guillaume is busy, I will test it in my 2-way (1+1HT) CPU system. -- Evgeniy Polyakov ( s0mbre ) From jgarzik@pobox.com Wed Mar 2 21:57:23 2005 Received: with ECARTIS (v1.0.0; list netdev); Wed, 02 Mar 2005 21:57:27 -0800 (PST) Received: from parcelfarce.linux.theplanet.co.uk (IDENT:93@parcelfarce.linux.theplanet.co.uk [195.92.249.252]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j235vMEf024952 for ; Wed, 2 Mar 2005 21:57:23 -0800 Received: from [69.134.152.124] (helo=[10.10.10.88]) by parcelfarce.linux.theplanet.co.uk with asmtp (TLSv1:AES256-SHA:256) (Exim 4.33) id 1D6jKo-00007F-Uw; Thu, 03 Mar 2005 05:57:19 +0000 Message-ID: <4226A72D.6040701@pobox.com> Date: Thu, 03 Mar 2005 00:57:01 -0500 From: Jeff Garzik User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.3) Gecko/20040922 X-Accept-Language: en-us, en MIME-Version: 1.0 To: James Chapman CC: Netdev Subject: Re: [PATCH: 2.6.11-rc5 netdev-2.6] mii: add GigE support References: <421B466C.4010902@katalix.com> <421F9685.5090109@katalix.com> In-Reply-To: <421F9685.5090109@katalix.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV 0.83/742/Tue Mar 1 17:05:59 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 2290 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: jgarzik@pobox.com Precedence: bulk X-list: netdev applied, thanks From pb@bieringer.de Wed Mar 2 23:26:04 2005 Received: with ECARTIS (v1.0.0; list netdev); Wed, 02 Mar 2005 23:26:10 -0800 (PST) Received: from smtp1.aerasec.de (pib.aerasec.de [195.226.187.146]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j237Q2Wl028478 for ; Wed, 2 Mar 2005 23:26:03 -0800 Received: from ppp-82-135-65-40.mnet-online.de (ppp-82-135-65-40.mnet-online.de [82.135.65.40]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by smtp1.aerasec.de (Postfix) with ESMTP id 66419277D0; Thu, 3 Mar 2005 08:25:53 +0100 (CET) Date: Thu, 03 Mar 2005 08:25:52 +0100 From: Peter Bieringer To: usagi-users@linux-ipv6.org, netdev@oss.sgi.com Subject: Re: ip -6 addr flush dev flushes also the autogenerated link-local address Message-ID: <7C7833F5F8350E30351D9B98@gatemuc.muc.bieringer.de> In-Reply-To: <20050303.090009.59651076.yoshfuji@linux-ipv6.org> References: <001C540DBA8D9308CA5D790F@worker.muc.bieringer.de> <1109801372.1098.228.camel@jzny.localdomain> <20050302231400.GU31837@postel.suug.ch> <20050303.090009.59651076.yoshfuji@linux-ipv6.org> X-Mailer: Mulberry/3.1.6 (Linux/x86) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Disposition: inline X-Virus-Scanned: ClamAV 0.83/742/Tue Mar 1 17:05:59 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 2291 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: pb@bieringer.de Precedence: bulk X-list: netdev --On Thursday, March 03, 2005 09:00:09 AM +0900 "YOSHIFUJI Hideaki / =?iso-2022-jp?B?GyRCNUhGIzFRTEAbKEI=?=" wrote: > In article <20050302231400.GU31837@postel.suug.ch> (at Thu, 3 Mar 2005 > 00:14:00 +0100), Thomas Graf says: > >> * jamal <1109801372.1098.228.camel@jzny.localdomain> 2005-03-02 17:09 >> > >> > Is this a user space problem? I think we had something along these >> > lines fixed recently. Thomas? >> >> I didn't fix any of these but it's definitely a userspace problem. >> One can easly work around this by iterating over all scopes >> except for link local and provide the scope to flush. We'll have >> to put additional filters into print_addrinfo() if we want this >> to be default but I'm not even sure what the official policy should >> be like. Any standards on this? > > I believe that flush should remove all addresses including link-local. > So, current behavior is correct. My pitfall was that I didn't know (but Pekka told me) that "ip -6 flush" also understand scopes. So I use the suggestion given by Thomas to run through all scopes of the addresses and flush dedicated like ip -6 addr flush dev scope global ip -6 addr flush dev scope site BTW: how many scopes are currently defined? ip help shows me: SCOPE-ID := [ host | link | global | NUMBER ] What means NUMBER and why is "site" understood but not in online help? Peter -- Dr. Peter Bieringer http://www.bieringer.de/pb/ GPG/PGP Key 0x958F422D mailto: pb at bieringer dot de Deep Space 6 Co-Founder and Core Member http://www.deepspace6.net/ From jgarzik@pobox.com Wed Mar 2 23:31:28 2005 Received: with ECARTIS (v1.0.0; list netdev); Wed, 02 Mar 2005 23:31:35 -0800 (PST) Received: from parcelfarce.linux.theplanet.co.uk (IDENT:93@parcelfarce.linux.theplanet.co.uk [195.92.249.252]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j237VRdN029148 for ; Wed, 2 Mar 2005 23:31:27 -0800 Received: from [69.134.152.124] (helo=[10.10.10.88]) by parcelfarce.linux.theplanet.co.uk with asmtp (TLSv1:AES256-SHA:256) (Exim 4.33) id 1D6kns-0001wR-NV; Thu, 03 Mar 2005 07:31:26 +0000 Message-ID: <4226BD3B.9080604@pobox.com> Date: Thu, 03 Mar 2005 02:31:07 -0500 From: Jeff Garzik User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.3) Gecko/20040922 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Netdev CC: Linux Kernel , Andrew Morton Subject: netdev-2.6 queue updated Content-Type: multipart/mixed; boundary="------------080007030500060400040601" X-Virus-Scanned: ClamAV 0.83/742/Tue Mar 1 17:05:59 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 2292 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: jgarzik@pobox.com Precedence: bulk X-list: netdev This is a multi-part message in MIME format. --------------080007030500060400040601 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Added a few patches, updated for 2.6.11 release. NOTE: BK users -must- reclone netdev-2.6. Do not pull. See attached for BK info, patch URL, and changelog. --------------080007030500060400040601 Content-Type: text/plain; name="netdev-2.6.txt" Content-Transfer-Encoding: 8bit Content-Disposition: inline; filename="netdev-2.6.txt" BK users: bk pull bk://gkernel.bkbits.net/netdev-2.6 or bk pull bk://kernel.bkbits.net/jgarzik/netdev-2.6 Patch: http://www.kernel.org/pub/linux/kernel/people/jgarzik/patchkits/2.6/2.6.11-netdev1.patch.bz2 This will update the following files: drivers/net/bagetlance.c | 1368 ----- drivers/net/wireless/ieee802_11.h | 78 include/linux/dp83840.h | 41 Documentation/networking/bonding.txt | 2101 +++++---- Documentation/networking/e100.txt | 3 Documentation/networking/ixgb.txt | 9 MAINTAINERS | 11 arch/arm/mach-pxa/lubbock.c | 2 arch/arm/mach-sa1100/neponset.c | 2 drivers/net/3c503.c | 67 drivers/net/3c509.c | 4 drivers/net/3c515.c | 32 drivers/net/3c527.c | 2 drivers/net/3c59x.c | 2 drivers/net/8139cp.c | 100 drivers/net/8139too.c | 293 - drivers/net/Kconfig | 59 drivers/net/Makefile | 2 drivers/net/Space.c | 11 drivers/net/amd8111e.c | 8 drivers/net/arcnet/arc-rawmode.c | 4 drivers/net/arcnet/arc-rimi.c | 14 drivers/net/arcnet/arcnet.c | 30 drivers/net/arcnet/com20020.c | 6 drivers/net/arcnet/com90io.c | 4 drivers/net/arcnet/com90xx.c | 8 drivers/net/arcnet/rfc1051.c | 8 drivers/net/arcnet/rfc1201.c | 12 drivers/net/au1000_eth.c | 1361 ++++- drivers/net/au1000_eth.h | 55 drivers/net/b44.c | 2 drivers/net/b44.h | 14 drivers/net/bonding/bond_3ad.c | 2 drivers/net/bonding/bond_3ad.h | 1 drivers/net/bonding/bond_alb.c | 12 drivers/net/bonding/bond_main.c | 35 drivers/net/cs89x0.c | 4 drivers/net/depca.c | 4 drivers/net/dgrs.c | 6 drivers/net/dl2k.c | 2 drivers/net/e100.c | 4 drivers/net/e1000/e1000.h | 3 drivers/net/e1000/e1000_ethtool.c | 11 drivers/net/e1000/e1000_hw.c | 86 drivers/net/e1000/e1000_hw.h | 11 drivers/net/e1000/e1000_main.c | 249 - drivers/net/eepro100.c | 25 drivers/net/epic100.c | 2 drivers/net/es3210.c | 32 drivers/net/ethertap.c | 4 drivers/net/ewrk3.c | 87 drivers/net/fealnx.c | 275 - drivers/net/hamradio/6pack.c | 4 drivers/net/hamradio/baycom_epp.c | 53 drivers/net/hamradio/baycom_par.c | 8 drivers/net/hamradio/baycom_ser_fdx.c | 7 drivers/net/hamradio/baycom_ser_hdx.c | 7 drivers/net/hamradio/bpqether.c | 19 drivers/net/hamradio/dmascc.c | 2073 ++++---- drivers/net/hamradio/hdlcdrv.c | 48 drivers/net/hamradio/mkiss.c | 12 drivers/net/hamradio/yam.c | 38 drivers/net/ibm_emac/ibm_emac.h | 4 drivers/net/ibm_emac/ibm_emac_core.c | 16 drivers/net/ibm_emac/ibm_emac_core.h | 2 drivers/net/ibmlana.c | 99 drivers/net/ibmlana.h | 1 drivers/net/ioc3-eth.c | 83 drivers/net/irda/act200l-sir.c | 3 drivers/net/irda/donauboe.c | 2 drivers/net/irda/irtty-sir.c | 4 drivers/net/irda/ma600-sir.c | 12 drivers/net/irda/sir_dev.c | 4 drivers/net/irda/tekram-sir.c | 3 drivers/net/ixgb/ixgb.h | 3 drivers/net/ixgb/ixgb_ee.c | 16 drivers/net/ixgb/ixgb_ee.h | 3 drivers/net/ixgb/ixgb_ethtool.c | 5 drivers/net/ixgb/ixgb_hw.c | 2 drivers/net/ixgb/ixgb_hw.h | 2 drivers/net/ixgb/ixgb_ids.h | 2 drivers/net/ixgb/ixgb_main.c | 73 drivers/net/ixgb/ixgb_osdep.h | 2 drivers/net/ixgb/ixgb_param.c | 2 drivers/net/jazzsonic.c | 217 drivers/net/loopback.c | 2 drivers/net/lp486e.c | 8 drivers/net/meth.c | 275 - drivers/net/meth.h | 2 drivers/net/mii.c | 63 drivers/net/mv643xx_eth.c | 2689 ++++++----- drivers/net/mv643xx_eth.h | 641 +- drivers/net/natsemi.c | 13 drivers/net/ne2k-pci.c | 4 drivers/net/ni65.c | 3 drivers/net/ns83820.c | 3 drivers/net/pcmcia/ibmtr_cs.c | 7 drivers/net/pcmcia/xirc2ps_cs.c | 23 drivers/net/pcnet32.c | 47 drivers/net/ppp_deflate.c | 4 drivers/net/ppp_generic.c | 2 drivers/net/pppoe.c | 2 drivers/net/s2io.c | 173 drivers/net/s2io.h | 8 drivers/net/sb1000.c | 28 drivers/net/sb1250-mac.c | 109 drivers/net/sgiseeq.c | 70 drivers/net/shaper.c | 2 drivers/net/sis900.c | 218 drivers/net/sk98lin/skge.c | 2 drivers/net/sk_mca.c | 126 drivers/net/sk_mca.h | 19 drivers/net/skge.c | 3334 ++++++++++++++ drivers/net/skge.h | 3005 ++++++++++++ drivers/net/slhc.c | 27 drivers/net/smc-mca.c | 37 drivers/net/smc-ultra.c | 34 drivers/net/smc-ultra32.c | 30 drivers/net/smc91x.c | 275 - drivers/net/smc91x.h | 79 drivers/net/sonic.c | 4 drivers/net/sundance.c | 7 drivers/net/sungem.c | 2 drivers/net/tg3.c | 4 drivers/net/tg3.h | 14 drivers/net/tokenring/ibmtr.c | 158 drivers/net/tulip/de2104x.c | 2 drivers/net/tulip/interrupt.c | 2 drivers/net/tulip/tulip_core.c | 2 drivers/net/tun.c | 4 drivers/net/typhoon-firmware.h | 5568 ++++++++++-------------- drivers/net/typhoon.c | 254 - drivers/net/via-rhine.c | 7 drivers/net/via-velocity.c | 6 drivers/net/wan/Kconfig | 11 drivers/net/wan/cosa.c | 7 drivers/net/wan/hd6457x.c | 2 drivers/net/wan/sbni.c | 2 drivers/net/wan/z85230.c | 4 drivers/net/wd.c | 36 drivers/net/wireless/Kconfig | 2 drivers/net/wireless/Makefile | 2 drivers/net/wireless/airo.c | 25 drivers/net/wireless/airport.c | 22 drivers/net/wireless/arlan.h | 4 drivers/net/wireless/atmel.c | 165 drivers/net/wireless/atmel.h | 43 drivers/net/wireless/atmel_cs.c | 49 drivers/net/wireless/atmel_pci.c | 6 drivers/net/wireless/hermes.c | 72 drivers/net/wireless/hermes.h | 64 drivers/net/wireless/hostap/Kconfig | 104 drivers/net/wireless/hostap/Makefile | 8 drivers/net/wireless/hostap/hostap.c | 1205 +++++ drivers/net/wireless/hostap/hostap.h | 57 drivers/net/wireless/hostap/hostap_80211.h | 107 drivers/net/wireless/hostap/hostap_80211_rx.c | 1080 ++++ drivers/net/wireless/hostap/hostap_80211_tx.c | 522 ++ drivers/net/wireless/hostap/hostap_ap.c | 3259 ++++++++++++++ drivers/net/wireless/hostap/hostap_ap.h | 272 + drivers/net/wireless/hostap/hostap_common.h | 556 ++ drivers/net/wireless/hostap/hostap_config.h | 86 drivers/net/wireless/hostap/hostap_crypt.c | 167 drivers/net/wireless/hostap/hostap_crypt.h | 50 drivers/net/wireless/hostap/hostap_crypt_ccmp.c | 486 ++ drivers/net/wireless/hostap/hostap_crypt_tkip.c | 696 +++ drivers/net/wireless/hostap/hostap_crypt_wep.c | 281 + drivers/net/wireless/hostap/hostap_cs.c | 785 +++ drivers/net/wireless/hostap/hostap_download.c | 761 +++ drivers/net/wireless/hostap/hostap_hw.c | 3607 +++++++++++++++ drivers/net/wireless/hostap/hostap_info.c | 469 ++ drivers/net/wireless/hostap/hostap_ioctl.c | 3624 +++++++++++++++ drivers/net/wireless/hostap/hostap_pci.c | 452 + drivers/net/wireless/hostap/hostap_plx.c | 611 ++ drivers/net/wireless/hostap/hostap_proc.c | 466 ++ drivers/net/wireless/hostap/hostap_wlan.h | 1071 ++++ drivers/net/wireless/orinoco.c | 430 + drivers/net/wireless/orinoco.h | 37 drivers/net/wireless/orinoco_cs.c | 49 drivers/net/wireless/orinoco_pci.c | 124 drivers/net/wireless/orinoco_plx.c | 235 - drivers/net/wireless/orinoco_tmd.c | 150 drivers/net/wireless/prism54/isl_38xx.c | 12 drivers/net/wireless/prism54/isl_ioctl.c | 2 drivers/net/wireless/ray_cs.c | 5 drivers/net/wireless/strip.c | 16 drivers/net/wireless/wl3501.h | 4 include/linux/ibmtr.h | 15 include/linux/mii.h | 20 include/linux/mv643xx.h | 448 + include/linux/netdevice.h | 2 include/linux/pci_ids.h | 8 include/net/ieee80211.h | 887 +++ include/net/ieee80211_crypt.h | 86 include/net/slhc_vj.h | 3 net/Kconfig | 2 net/Makefile | 1 net/core/dev.c | 28 net/ieee80211/Kconfig | 67 net/ieee80211/Makefile | 11 net/ieee80211/ieee80211_crypt.c | 259 + net/ieee80211/ieee80211_crypt_ccmp.c | 470 ++ net/ieee80211/ieee80211_crypt_tkip.c | 708 +++ net/ieee80211/ieee80211_crypt_wep.c | 272 + net/ieee80211/ieee80211_module.c | 268 + net/ieee80211/ieee80211_rx.c | 1206 +++++ net/ieee80211/ieee80211_tx.c | 448 + net/ieee80211/ieee80211_wx.c | 471 ++ 208 files changed, 44021 insertions(+), 10816 deletions(-) through these ChangeSets: : o sundance: attempt to address high irqs due to TX overflow : o wireless: Make Atmel driver use SET_NETDEV_DEV o wireless: WEXT quality cleanups + max rssi o wireless: Clean up firmware loading in : o [netdrvr mv643xx] Big rename o [netdrvr mv643xx] Rename MV_READ => mv_read and MV_WRITE => mv_write o [netdrvr mv643xx] Additional whitespace cleanups, mostly changing spaces to tabs in comments o [netdrvr mv643xx] Run mv643xx_eth.[ch] through scripts/Lindent o [netdrvr mv643xx] Add a function to detect at runtime whether a PHY is attached to the specified port, and use it to cause the probe routine to fail when there is no PHY. o [netdrvr mv643xx] This one liner removes a spurious left paren fixing an obvious syntax error in the #ifndef MV64340_NAPI case o [netdrvr mv643xx] Add support for PHYs/boards that don't support autonegotiation o [netdrvr mv643xx] With this patch, the driver now calls netif_carrier_off/netif_carrier_on o [netdrvr mv643xx] This patch cleans up the handling of receive skb sizing : o mii: add GigE support : o ieee80211 subsystem : o e1000: Driver version white space, o e1000: Fixes related to Cable length o e1000: Report failure code when loopback o e1000: Checks for desc ring/rx data o e1000: Patch from Peter Kjellstroem -- o e1000: Fix WOL settings in 82544 based o e1000: Delay clean-up of last Tx buffer o e1000: Avoid race between e1000_watchdog o e1000: use netif_poll_{enable|disable} o e1000: Robert Olsson's fix and refinement o ixgb: Driver version, white space, other stuff o ixgb: Invalidate software cache, when EEPROM write occurs o ixgb: Robert Olsson's fix and refinement to poll o ixgb: Avoid race e1000_watchdog and ixgb_clean_tx_irq o ixgb: use netif_poll_{enable|disable} : o sis900.c net poll support : o wireless-2.6 cleanup : o [netdrvr 8139cp] add PCI ID : o Possible AMD8111e free irq issue o Possible VIA-Rhine free irq issue Adrian Bunk: o net/ieee80211/Kconfig: don't describe what gets selected o drivers/net/via-rhine.c: make a variable static const o drivers/net/sb1000.c: make some variables static o drivers/net/lp486e.c: make some code static o drivers/net/3c509.c: make 2 structs static o drivers/net/3c527.c: make a struct static o drivers/net/amd8111e.c: make 2 functions static o drivers/net/loopback.c: make a function static o drivers/net/ethertap.c: make 2 functions static o drivers/net/dgrs.c: make 3 functions static o drivers/net/depca.c: make 2 structs static o drivers/net/bonding/: make 3 functions static o drivers/net/s2io.c: cleanups o drivers/net/pppoe.c: make a struct static o drivers/net/ppp_deflate.c: make 2 structs static o drivers/net/via-velocity.c: make a function static o drivers/net/tun.c: make 2 functions static o drivers/net/tulip/interrupt.c: make a variable static o drivers/net/shaper.c: make a variable static o drivers/net/slhc.c: remove 2 functions o remove dp83840.h Alexander Viro: o hostap __user annotations o smc91x iomem annotations o 3c503 (iomem + isa-ectomy) o ibmlana part 2 (iomem annotations and isa-ectomy) o ibmlana part 1 (netdev_priv()) o sk_mca - iomem and isa-ectomy o sk_mca - netdev_priv() o ibmtr 2/2: ibmtr annotations - the rest o ibmtr 1/2: iomem annotations - trivial part o es3210 iomem annotions and isa-ectomy o ewrk3 iomem annotations + isa-ectomy o wd iomem annotations + isa-ectomy o smc-ultra32 iomem annotations + isa-ectomy o smc-ultra iomem annotations + isa-ectomy o smc-mca iomem annotations and isa-ectomy o fealnx iomem annotations, switch to io{read,write} o wireless iomem annotations and fixes, switch to io{read,write} Dale Farnsworth: o mv643xx: remove superfluous function, mv643xx_set_ethtool_ops o mv643xx: raise size of receive skbs to allow for an optional VLAN tag o [netdrvr mv643xx] Remove call to msleep() while locks are held. We don't really need to wait for the link to come up. It was a workaround to avoid a transient error message, "Virtual device %s asks to queue packet!\n", in dev_queue_xmit() when called by ic_bootp_send_if(). This happens because right after opening the network device, there is a pending PHY status change interrupt causing the driver to call netif_stop_queue(). A half second later, the link comes up and all is well. We could have moved the call to msleep() to mv643xx_eth_open() to perpetuate the workaround, but I think it's best to remove it entirely. o [netdrvr mv643xx] Ensure that we only change the Port Serial Control Reg while the port is disabled. o [netdrvr mv643xx] Add ethtool support to the mv643xx ethernet driver o [netdrvr mv643xx] Enable the mv643xx ethernet support on platforms using the MV64360 chip o [netdrvr mv643xx] Disable tcp/udp checksum offload to hardware. It generally works, but the hardware appears to generate the wrong checksum if the hw checksum generation wasn't used in the previous packet sent. o [netdrvr mv643xx] We already set ETH_TX_ENABLE_INTERRUPT whenever we set ETH_TX_LAST_DESC o [netdrvr mv643xx] Update tx_bytes statistic when using hw tcp/udp checksum generation o [netdrvr mv643xx] Call netif_carrier_off when closing the driver o [netdrvr mv643xx] Trivial. Remove repeated comment o [netdrvr mv643xx] Clear transmit l4i_chk even when the hardware ignores it o [netdrvr mv643xx] Increment tx_ring_skbs before calling eth_port_send, since o [netdrvr mv643xx] Fix handling of unaligned tiny fragments not handled by hardware Check all fragments instead of just the last. o [netdrvr mv643xx] Fix a few places I missed in the previous rename patch o [netdrvr mv643xx] This patch simplifies the mv64340_eth_set_rx_mode function without changing its behavior. o [netdrvr mv643xx] This patch makes the use of the MV64340_RX_QUEUE_FILL_ON_TASK config macro more consistent, though the macro remains undefined, since the feature still does not work properly. o [netdrvr mv643xx] This patch adds support for passing additional parameters via the platform_device interface. These additional parameters are: o [netdrvr mv643xx] This patch adds device driver model support to the mv643xx_eth driver o [netdrvr mv643xx] This patch replaces the use of the pci_map_* functions with the corresponding dma_map_* functions. o [netdrvr mv643xx] This patch fixes the code that enables hardware checksum generation o [netdrvr mv643xx] This patch removes spin delays (count to 1000000, ugh) and instead waits with udelay or msleep for hardware flags to change. o [netdrvr mv643xx] This patch removes code that is redundant or useless Daniele Venzano: o sis900: chiprev i/o cleanups o sis900: debugging output update o sis900 printk audit o sis900: version bump; remove broken URL o sis900: add infrastructure needed for standard netif messages David Dillow: o Bump version and release date o Version 03.001.008 of the Typhoon firmware, courtesy of 3Com o Fixup the version reporting to match 3Com o Use module_param() and add descriptions o Teach typhoon to use port IO on machines that need it. It will attempt to use MMIO, but if that fails (or the user asks), it will fallback to port IO. o Enable bus mastering before saving our state, or we'll only be able to load the modules one time. David Gibson: o Orinoco driver updates - cleanup PCI initialization o Orinoco driver updates - PCMCIA initialization cleanups o Orinoco driver updates - update version and changelog o Orinoco driver updates - update firmware detection o Orinoco driver updates - WEP updates o Orinoco driver updates - delay Tx wake o Orinoco driver updates - prohibit IBSS with no ESSID o Orinoco driver updates - update is_ethersnap() o Orinoco driver updates - PCMCIA initialization cleanups o Orinoco driver updates - use modern module_parm() o Orinoco driver updates - cleanup PCI initialization o Orinoco driver updates - cleanup low-level code o Orinoco driver updates - add free_orinocodev() o Orinoco driver updates - use mdelay()/ssleep() more o Orinoco driver updates - update printk()s o Orinoco driver updates - use netif_carrier_*() David T. Hollis: o Move MII-related constants from b44/tg3 drivers to linux/mii.h Domen Puncer: o net/ewrk3: replace schedule_timeout() with msleep_interruptible() o net/tekram-sir: replace schedule_timeout() with msleep() o net/ns83820: replace schedule_timeout() with msleep() o net/ni65: replace schedule_timeout() with msleep() o net/sir_dev: replace schedule_timeout() with msleep() o net/xirc2ps_cs: replace Wait() with msleep() o net/ma600-sir: replace schedule_timeout() with msleep() o net/irtty-sir: replace schedule_timeout() with msleep() o net/act2001-sir: replace schedule_timeout() with msleep() o arcnet: remove casts Don Fry: o pcnet32: 79c976 with fiber optic fix Felipe Damasio: o 8139cp net driver: add MODULE_VERSION François Romieu: o ieee80211: offset_in_page() removal o ieee80211: C99 initialization for eap_types o ieee80211: failure of ieee80211_crypto_init() o strip: use of netdev_priv o 8139cp: SG support fixes Ganesh Venkatesan: o ixgb: Documentation/networking/ixgb.txt Ian Campbell: o smc91x: power down PHY on suspend o use datacs in smc91x driver Jay Vosburgh: o bonding: Update/rewrite bonding.txt o bonding: Update kconfig description o bonding: change misleading warning o bonding: use wrappers to change mtu and MAC o net/core: move set MAC into separate function Jeff Garzik: o [wireless atmel] Add support LG LW2100N WLAN PCMCIA card o [wireless hostap] update for new pci_save_state() o [netdrvr 8139cp] TSO support John W. Linville: o sk98lin: add MODULE_DEVICE_TABLE entry Joshua Kwan: o hostap: fix Kconfig typos and missing select CRYPTO Jouni Malinen: o Host AP: Replaced MODULE_PARM with module_param* o Host AP: Replaced direct dev->priv references with netdev_priv(dev) o Host AP: Updated to use Linux wireless extensions v17 o Host AP: pci_register_driver() return value changes o Host AP: Fix netif_carrier_off() in non-client modes o Host AP: Fix PRISM2_IO_DEBUG o Host AP: Use void __iomem * with {read,write}{b,w} o Host AP: Fix card enabling after firmware download o Host AP: Do not bridge packets to unauthorized ports o Host AP: Fix compilation with PRISM2_NO_STATION_MODES defined o Host AP: Prevent STAs from associating using AP address o Host AP: Fix hw address changing for wifi# interface o Host AP: Remove ioctl debug messages o Host AP: Ignore (Re)AssocResp messages silently o Host AP: Fix interface packet counters o Host AP: Disable EAPOL TX/RX debug messages o fix hostap crypto bugs o Add HostAP wireless driver Krzysztof Halasa: o WAN drivers fix: N2, C101, PCI200SYN - quite fatal Matt Porter: o emac: fix skb allocation for full-size jumbo frames o Add PPC440SP support to IBM EMAC driver Nicolas Pitre: o smc91x: allow RX of VLAN packets Nishanth Aravamudan: o net/s2io: replace schedule_timeout() with msleep() o net/cosa: replace schedule_timeout() with msleep() o net/airo: replace schedule_timeout() with msleep()/ssleep() o net/cs89x0: replace schedule_timeout() with msleep() Olaf Kirch: o natsemi: long cable, short cable Paul Mackerras: o remove bogus exports in ppp Pavel Machek: o Fix u32 vs. pm_message_t in network device drivers o eepro100 kill obsolete ifdefs Pekka Enberg: o 8139too: use iomap for pio/mmio Ralf Bächle: o Remove unused MAXBPQDEV definition o Sparse fixes for drivers/net/hamradio o Reformat DMASCC driver o Use netdev_priv in baycom_epp driver o Use netdev_priv in baycom_ser_fdx driver o Use netdev_priv in hdlcdrv driver o Use netdev_priv in baycom_ser_hdx driver o Use netdev_priv in baycom_par driver o Use netdev_priv in bpqether driver o Use netdev_priv in mkiss driver o Use netdev_priv in YAM driver o SGI Seeq updates o SB1250 driver updates o S2IO syntax fixes o Meth driver updates o Marvell MV-64340 driver upda o Jazzsonic driver updates o IOC3 driver updates o Remove Baget network driver o Au1000 driver updates Randy Dunlap: o tulip/de2104x: don't mix __init & __devinit sections o net/wan/sbni: fix section usage o prism54: fix printk format warnings o (v2) arlan: remove gcc warning with CONFIG_PROC_FS=n o sb1000: reduce ioctl stack usage o ray_cs: reduce stack usage (sockaddr) o prism54: use NULL for pointer Rene Herman: o 8139too Interframe Gap Time Scott Feldman: o eepro100: remove ID for 82556 o e100: remove reference to NAPI config option Steffen Klassert: o Add MODULE_VERSION to the 3c515 driver o Use netdev_priv in the 3c515 driver o 8139cp - add netpoll support Stephen Hemminger: o skge driver (0.5) o 8139too: use netdev_priv o 8139cp - module_param Thierry Vignaud: o fix driver name in dl2k as returned by ETHTOOL_GDRVINFO Thomas Gleixner: o rtl8139too.c: Fix missing pci_disable_dev o rtl8139too.c: Fix missing pci_disable_dev tom watson: o drivers/net/wan/z85230.c interrupt handling fix Tony Lindgren: o Add OMAP support to smc91x Ethernet driver Xose Vazquez Perez: o 2.6 eepro100: replace and delete duplicate ids --------------080007030500060400040601-- From bennybbz@yahoo.fr Thu Mar 3 01:36:28 2005 Received: with ECARTIS (v1.0.0; list netdev); Thu, 03 Mar 2005 01:36:34 -0800 (PST) Received: from web26609.mail.ukl.yahoo.com (web26609.mail.ukl.yahoo.com [217.146.176.59]) by oss.sgi.com (8.13.0/8.13.0) with SMTP id j239aQmZ005432 for ; Thu, 3 Mar 2005 01:36:27 -0800 Received: (qmail 29851 invoked by uid 60001); 3 Mar 2005 09:36:21 -0000 Message-ID: <20050303093621.29849.qmail@web26609.mail.ukl.yahoo.com> Received: from [63.87.1.243] by web26609.mail.ukl.yahoo.com via HTTP; Thu, 03 Mar 2005 10:36:21 CET Date: Thu, 3 Mar 2005 10:36:21 +0100 (CET) From: BZ Benny Subject: Re: creating a netdevice To: netdev@oss.sgi.com In-Reply-To: <1109799677.1098.198.camel@jzny.localdomain> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Virus-Scanned: ClamAV 0.83/742/Tue Mar 1 17:05:59 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 2293 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: bennybbz@yahoo.fr Precedence: bulk X-list: netdev Hi, tanks a lot, I think that the only way for creating a netdevice without being in the kernel space its to use tuntap. I have an appli like blueZ which access to the IP layer and take paket into another network. My appli run under a PC wich play the role of an access point for other PCs in my private network. So, for driving packet from internet to my private network and vice versa I use briding utils: brctl but I have another problem. It s that my bridge br0 that i create like that #brctl addbr br0 #brctl setfd br0 0 #brctl stp br0 off #brctl addif br0 eth0 #brctl addif br0 tun0 but if I do not #ifconfig eth0 0.0.0.0 #ifconfig br0 10.160.15.128 #route add default gw 10.160.15.128 I can"t access to internet, why does br0 need an IP adress. I want to not giving him an IP adress and giving eth0 the IP address of my internet network and tun0 the IP adress of my private network. regards imad. ps: blueZ is an open source bluetooth stack which is integrated to the 2.6 kernels. --- jamal a écrit : > > Can you explain why you need to create a net device? > Linux (and many > other OSes) typically tie discovery of hardware > resources to creating a > network device i.e the kernel creates it for you > (this is true even when > the discovery is done post bootup). The only > exception is things like > tun/ethertap as Stephen mentions. Things like > allocation of ifindices > are also under the control of the OS - even when you > are able to create. > > cheers, > jamal > > > On Wed, 2005-03-02 at 14:26, Stephen Hemminger > wrote: > > On Wed, 2 Mar 2005 14:38:28 +0100 (CET) > > BZ Benny wrote: > > > > > Hi > > > > > > I want to create a network interface from the > user > > > space, > > > is it possible? > > > > No, you can't create a network interface from user > space. > > You probably want to use tun/tap or ethertap > device. > > > > > > > Découvrez le nouveau Yahoo! Mail : 250 Mo d'espace de stockage pour vos mails ! Créez votre Yahoo! Mail sur http://fr.mail.yahoo.com/ From johnpol@2ka.mipt.ru Thu Mar 3 03:46:10 2005 Received: with ECARTIS (v1.0.0; list netdev); Thu, 03 Mar 2005 03:46:19 -0800 (PST) Received: from vocord.com (dea.vocord.ru [217.67.177.50]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j23Bk9UT018597 for ; Thu, 3 Mar 2005 03:46:09 -0800 Received: from uganda.factory.vocord.ru (uganda.factory.vocord.ru [192.168.0.48]) by vocord.com (8.13.1/8.13.1) with ESMTP id j23Bj326000475; Thu, 3 Mar 2005 14:45:04 +0300 Subject: Re: [PATCH 2.6.11-rc4-mm1] connector: Add a fork connector From: Evgeniy Polyakov Reply-To: johnpol@2ka.mipt.ru To: Kaigai Kohei Cc: Guillaume Thouvenin , Andrew Morton , lkml , elsa-devel , Jay Lan , Gerrit Huizenga , Erich Focht , Netlink List In-Reply-To: <20050303084656.A15197@2ka.mipt.ru> References: <1109240677.1738.196.camel@frecb000711.frec.bull.fr> <1109753292.8422.117.camel@frecb000711.frec.bull.fr> <42268201.80706@ak.jp.nec.com> <20050303084656.A15197@2ka.mipt.ru> Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="=-Y2avb3PiOApOFwKGRSS9" Organization: MIPT Date: Thu, 03 Mar 2005 14:51:29 +0300 Message-Id: <1109850689.28266.144.camel@uganda> Mime-Version: 1.0 X-Mailer: Evolution 2.0.2 (2.0.2-3) X-Virus-Scanned: ClamAV 0.83/742/Tue Mar 1 17:05:59 2005 on oss.sgi.com X-Virus-Scanned: ClamAV 0.80/690/Fri Jan 28 15:09:45 2005 clamav-milter version 0.80j on dea.vocord.com X-Virus-Status: Clean X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-1.4 (vocord.com [192.168.0.1]); Thu, 03 Mar 2005 14:45:09 +0300 (MSK) X-archive-position: 2294 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: johnpol@2ka.mipt.ru Precedence: bulk X-list: netdev --=-Y2avb3PiOApOFwKGRSS9 Content-Type: text/plain Content-Transfer-Encoding: quoted-printable Simple program to test fork() performance. #include #include int main(int argc, char *argv[]) { int pid; int i =3D 0, max =3D 100000; struct timeval tv0, tv1; struct timezone tz; long diff; if (argc >=3D 2) max =3D atoi(argv[1]); signal(SIGCHLD, SIG_IGN); gettimeofday(&tv0, &tz); while (i++ < max) { pid =3D fork(); if (pid =3D=3D 0) { sleep(1); exit (0); } } gettimeofday(&tv1, &tz); diff =3D (tv1.tv_sec - tv0.tv_sec)*1000000 + (tv1.tv_usec - tv0.tv_= usec); printf("Average per process fork+exit time is %ld usecs [diff=3D%lu= , max=3D%d].\n", diff/max, diff, max); return 0; } Creating 10k forks 100 times. Results on 2-way SMP(1+1HT) Xeon for one fork()+exit(): 2.6.11-rc4-mm1 494 usec 2.6.11-rc4-mm1-fork-connector-no_userspace 509 usec 2.6.11-rc4-mm1-fork-connector-userspace 520 usec 5% fork() degradation(connector with userspace vs. vanilla) with fork() con= nector. On my test system global fork lock does not cost anything (tested both with and without userspace listener), but it is only 2-way(pse= udo). --=20 Evgeniy Polyakov Crash is better than data corruption -- Arthur Grabowski --=-Y2avb3PiOApOFwKGRSS9 Content-Type: application/pgp-signature; name=signature.asc Content-Description: This is a digitally signed message part -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.6 (GNU/Linux) iD8DBQBCJvpBIKTPhE+8wY0RAj0zAKCJ/A7aoAESI9UixrOG10zAsbYuXgCgj/4B aDKR9Xur0lNOTjFTzLD+OOg= =oHmK -----END PGP SIGNATURE----- --=-Y2avb3PiOApOFwKGRSS9-- From johnpol@2ka.mipt.ru Thu Mar 3 04:16:36 2005 Received: with ECARTIS (v1.0.0; list netdev); Thu, 03 Mar 2005 04:16:50 -0800 (PST) Received: from vocord.com (dea.vocord.ru [217.67.177.50]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j23CGYii020704 for ; Thu, 3 Mar 2005 04:16:34 -0800 Received: from uganda.factory.vocord.ru (uganda.factory.vocord.ru [192.168.0.48]) by vocord.com (8.13.1/8.13.1) with ESMTP id j23CEIsa002143; Thu, 3 Mar 2005 15:14:18 +0300 Subject: Re: [PATCH 2.6.11-rc4-mm1] connector: Add a fork connector From: Evgeniy Polyakov Reply-To: johnpol@2ka.mipt.ru To: Kaigai Kohei Cc: Guillaume Thouvenin , Andrew Morton , lkml , elsa-devel , Jay Lan , Gerrit Huizenga , Erich Focht , Netlink List In-Reply-To: <1109850689.28266.144.camel@uganda> References: <1109240677.1738.196.camel@frecb000711.frec.bull.fr> <1109753292.8422.117.camel@frecb000711.frec.bull.fr> <42268201.80706@ak.jp.nec.com> <20050303084656.A15197@2ka.mipt.ru> <1109850689.28266.144.camel@uganda> Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="=-04dngmqtPZ1HpTDHUoly" Organization: MIPT Date: Thu, 03 Mar 2005 15:20:44 +0300 Message-Id: <1109852444.28266.155.camel@uganda> Mime-Version: 1.0 X-Mailer: Evolution 2.0.2 (2.0.2-3) X-Virus-Scanned: ClamAV 0.83/742/Tue Mar 1 17:05:59 2005 on oss.sgi.com X-Virus-Scanned: ClamAV 0.80/690/Fri Jan 28 15:09:45 2005 clamav-milter version 0.80j on dea.vocord.com X-Virus-Status: Clean X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-1.4 (vocord.com [192.168.0.1]); Thu, 03 Mar 2005 15:14:22 +0300 (MSK) X-archive-position: 2295 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: johnpol@2ka.mipt.ru Precedence: bulk X-list: netdev --=-04dngmqtPZ1HpTDHUoly Content-Type: multipart/mixed; boundary="=-JgbT51g/LuBG3QWsxd46" --=-JgbT51g/LuBG3QWsxd46 Content-Type: text/plain Content-Transfer-Encoding: quoted-printable On Thu, 2005-03-03 at 14:51 +0300, Evgeniy Polyakov wrote: > Simple program to test fork() performance. ... In a bit more advanced version it checks for error value, but it never happend. It can also have more fine grained measurment,=20 but IMHO the picture is clear for small systems. > Creating 10k forks 100 times. > Results on 2-way SMP(1+1HT) Xeon for one fork()+exit(): >=20 > 2.6.11-rc4-mm1 494 usec Actually sometimes it drops to 480 usecs. > 2.6.11-rc4-mm1-fork-connector-no_userspace 509 usec > 2.6.11-rc4-mm1-fork-connector-userspace 520 usec >=20 > 5% fork() degradation(connector with userspace vs. vanilla) with fork() c= onnector. > On my test system global fork lock does not cost anything > (tested both with and without userspace listener), but it is only 2-way(p= seudo). connector.c used in experiments is attached. If fork connector analysis will show that global fork lock is a big bottleneck,=20 than seq counter can be replaced with per-cpu counter, but then inner header should include cpu id to properly distinguish messages. But it is totaly fork's connector area, so I will not break things. --=20 Evgeniy Polyakov Crash is better than data corruption -- Arthur Grabowski --=-JgbT51g/LuBG3QWsxd46 Content-Disposition: attachment; filename=connector.c Content-Type: text/x-csrc; name=connector.c; charset=KOI8-R Content-Transfer-Encoding: base64 LyoNCiAqIAljb25uZWN0b3IuYw0KICogDQogKiAyMDA0IENvcHlyaWdodCAoYykgRXZnZW5peSBQ b2x5YWtvdiA8am9obnBvbEAya2EubWlwdC5ydT4NCiAqIEFsbCByaWdodHMgcmVzZXJ2ZWQuDQog KiANCiAqIFRoaXMgcHJvZ3JhbSBpcyBmcmVlIHNvZnR3YXJlOyB5b3UgY2FuIHJlZGlzdHJpYnV0 ZSBpdCBhbmQvb3IgbW9kaWZ5DQogKiBpdCB1bmRlciB0aGUgdGVybXMgb2YgdGhlIEdOVSBHZW5l cmFsIFB1YmxpYyBMaWNlbnNlIGFzIHB1Ymxpc2hlZCBieQ0KICogdGhlIEZyZWUgU29mdHdhcmUg Rm91bmRhdGlvbjsgZWl0aGVyIHZlcnNpb24gMiBvZiB0aGUgTGljZW5zZSwgb3INCiAqIChhdCB5 b3VyIG9wdGlvbikgYW55IGxhdGVyIHZlcnNpb24uDQogKg0KICogVGhpcyBwcm9ncmFtIGlzIGRp c3RyaWJ1dGVkIGluIHRoZSBob3BlIHRoYXQgaXQgd2lsbCBiZSB1c2VmdWwsDQogKiBidXQgV0lU SE9VVCBBTlkgV0FSUkFOVFk7IHdpdGhvdXQgZXZlbiB0aGUgaW1wbGllZCB3YXJyYW50eSBvZg0K ICogTUVSQ0hBTlRBQklMSVRZIG9yIEZJVE5FU1MgRk9SIEEgUEFSVElDVUxBUiBQVVJQT1NFLiAg U2VlIHRoZQ0KICogR05VIEdlbmVyYWwgUHVibGljIExpY2Vuc2UgZm9yIG1vcmUgZGV0YWlscy4N CiAqDQogKiBZb3Ugc2hvdWxkIGhhdmUgcmVjZWl2ZWQgYSBjb3B5IG9mIHRoZSBHTlUgR2VuZXJh bCBQdWJsaWMgTGljZW5zZQ0KICogYWxvbmcgd2l0aCB0aGlzIHByb2dyYW07IGlmIG5vdCwgd3Jp dGUgdG8gdGhlIEZyZWUgU29mdHdhcmUNCiAqIEZvdW5kYXRpb24sIEluYy4sIDU5IFRlbXBsZSBQ bGFjZSwgU3VpdGUgMzMwLCBCb3N0b24sIE1BICAwMjExMS0xMzA3ICBVU0ENCiAqLw0KDQojaW5j bHVkZSA8bGludXgva2VybmVsLmg+DQojaW5jbHVkZSA8bGludXgvbW9kdWxlLmg+DQojaW5jbHVk ZSA8bGludXgvbGlzdC5oPg0KI2luY2x1ZGUgPGxpbnV4L3NrYnVmZi5oPg0KI2luY2x1ZGUgPGxp bnV4L25ldGxpbmsuaD4NCiNpbmNsdWRlIDxsaW51eC9tb2R1bGVwYXJhbS5oPg0KI2luY2x1ZGUg PGxpbnV4L2Nvbm5lY3Rvci5oPg0KDQojaW5jbHVkZSA8bmV0L3NvY2suaD4NCg0KTU9EVUxFX0xJ Q0VOU0UoIkdQTCIpOw0KTU9EVUxFX0FVVEhPUigiRXZnZW5peSBQb2x5YWtvdiA8am9obnBvbEAy a2EubWlwdC5ydT4iKTsNCk1PRFVMRV9ERVNDUklQVElPTigiR2VuZXJpYyB1c2Vyc3BhY2UgPC0+ IGtlcm5lbHNwYWNlIGNvbm5lY3Rvci4iKTsNCg0Kc3RhdGljIGludCB1bml0ID0gTkVUTElOS19O RkxPRzsNCnN0YXRpYyB1MzIgY25faWR4ID0gLTE7DQpzdGF0aWMgdTMyIGNuX3ZhbCA9IC0xOw0K DQptb2R1bGVfcGFyYW0odW5pdCwgaW50LCAwKTsNCm1vZHVsZV9wYXJhbShjbl9pZHgsIHVpbnQs IDApOw0KbW9kdWxlX3BhcmFtKGNuX3ZhbCwgdWludCwgMCk7DQoNCnN0YXRpYyBERUZJTkVfU1BJ TkxPQ0sobm90aWZ5X2xvY2spOw0Kc3RhdGljIExJU1RfSEVBRChub3RpZnlfbGlzdCk7DQoNCnN0 YXRpYyBzdHJ1Y3QgY25fZGV2IGNkZXY7DQoNCmludCBjbl9hbHJlYWR5X2luaXRpYWxpemVkID0g MDsNCmludCBjbl9mb3JrX2VuYWJsZSA9IDA7DQpzdHJ1Y3QgY2JfaWQgY2JfZm9ya19pZCA9IHsg Q05fSURYX0ZPUkssIENOX1ZBTF9GT1JLIH07DQoNCi8qDQogKiBtc2ctPnNlcSBhbmQgbXNnLT5h Y2sgYXJlIHVzZWQgdG8gZGV0ZXJtaW5lIG1lc3NhZ2UgZ2VuZWFsb2d5Lg0KICogV2hlbiBzb21l b25lIHNlbmRzIG1lc3NhZ2UgaXQgcHV0cyB0aGVyZSBsb2NhbGx5IHVuaXF1ZSBzZXF1ZW5jZSAN CiAqIGFuZCByYW5kb20gYWNrbm93bGVkZ2UgbnVtYmVycy4NCiAqIFNlcXVlbmNlIG51bWJlciBt YXkgYmUgY29waWVkIGludG8gbmxtc2doZHItPm5sbXNnX3NlcSB0b28uDQogKg0KICogU2VxdWVu Y2UgbnVtYmVyIGlzIGluY3JlbWVudGVkIHdpdGggZWFjaCBtZXNzYWdlIHRvIGJlIHNlbnQuDQog Kg0KICogSWYgd2UgZXhwZWN0IHJlcGx5IHRvIG91ciBtZXNzYWdlLCANCiAqIHRoZW4gc2VxdWVu Y2UgbnVtYmVyIGluIHJlY2VpdmVkIG1lc3NhZ2UgTVVTVCBiZSB0aGUgc2FtZSBhcyBpbiBvcmln aW5hbCBtZXNzYWdlLA0KICogYW5kIGFja25vd2xlZGdlIG51bWJlciBNVVNUIGJlIHRoZSBzYW1l ICsgMS4NCiAqDQogKiBJZiB3ZSByZWNlaXZlIG1lc3NhZ2UgYW5kIGl0J3Mgc2VxdWVuY2UgbnVt YmVyIGlzIG5vdCBlcXVhbCB0byBvbmUgd2UgYXJlIGV4cGVjdGluZywgDQogKiB0aGVuIGl0IGlz IG5ldyBtZXNzYWdlLg0KICogSWYgd2UgcmVjZWl2ZSBtZXNzYWdlIGFuZCBpdCdzIHNlcXVlbmNl IG51bWJlciBpcyB0aGUgc2FtZSBhcyBvbmUgd2UgYXJlIGV4cGVjdGluZywNCiAqIGJ1dCBpdCdz IGFja25vd2xlZGdlIGlzIG5vdCBlcXVhbCBhY2tub3dsZWRnZSBudW1iZXIgaW4gb3JpZ2luYWwg bWVzc2FnZSArIDEsDQogKiB0aGVuIGl0IGlzIG5ldyBtZXNzYWdlLg0KICoNCiAqLw0Kdm9pZCBj bl9uZXRsaW5rX3NlbmQoc3RydWN0IGNuX21zZyAqbXNnLCB1MzIgX19ncm91cHMpDQp7DQoJc3Ry dWN0IGNuX2NhbGxiYWNrX2VudHJ5ICpuLCAqX19jYnE7DQoJdW5zaWduZWQgaW50IHNpemU7DQoJ c3RydWN0IHNrX2J1ZmYgKnNrYiwgKnVza2I7DQoJc3RydWN0IG5sbXNnaGRyICpubGg7DQoJc3Ry dWN0IGNuX21zZyAqZGF0YTsNCglzdHJ1Y3QgY25fZGV2ICpkZXYgPSAmY2RldjsNCgl1MzIgZ3Jv dXBzID0gMDsNCglpbnQgZm91bmQgPSAwOw0KDQoJaWYgKCFfX2dyb3VwcykNCgl7DQoJCXNwaW5f bG9ja19iaCgmZGV2LT5jYmRldi0+cXVldWVfbG9jayk7DQoJCWxpc3RfZm9yX2VhY2hfZW50cnlf c2FmZShfX2NicSwgbiwgJmRldi0+Y2JkZXYtPnF1ZXVlX2xpc3QsIGNhbGxiYWNrX2VudHJ5KSB7 DQoJCQlpZiAoY25fY2JfZXF1YWwoJl9fY2JxLT5jYi0+aWQsICZtc2ctPmlkKSkgew0KCQkJCWZv dW5kID0gMTsNCgkJCQlncm91cHMgPSBfX2NicS0+Z3JvdXA7DQoJCQl9DQoJCX0NCgkJc3Bpbl91 bmxvY2tfYmgoJmRldi0+Y2JkZXYtPnF1ZXVlX2xvY2spOw0KDQoJCWlmICghZm91bmQpIHsNCgkJ CXByaW50ayhLRVJOX0VSUiAiRmFpbGVkIHRvIGZpbmQgbXVsdGljYXN0IG5ldGxpbmsgZ3JvdXAg Zm9yIGNhbGxiYWNrWzB4JXguMHgleF0uIHNlcT0ldVxuIiwNCgkJCSAgICAgICBtc2ctPmlkLmlk eCwgbXNnLT5pZC52YWwsIG1zZy0+c2VxKTsNCgkJCXJldHVybjsNCgkJfQ0KCX0NCgllbHNlDQoJ CWdyb3VwcyA9IF9fZ3JvdXBzOw0KDQoJc2l6ZSA9IE5MTVNHX1NQQUNFKHNpemVvZigqbXNnKSAr IG1zZy0+bGVuKTsNCg0KCXNrYiA9IGFsbG9jX3NrYihzaXplLCBHRlBfQVRPTUlDKTsNCglpZiAo IXNrYikgew0KCQlwcmludGsoS0VSTl9FUlIgIkZhaWxlZCB0byBhbGxvY2F0ZSBuZXcgc2tiIHdp dGggc2l6ZT0ldS5cbiIsIHNpemUpOw0KCQlyZXR1cm47DQoJfQ0KDQoJbmxoID0gTkxNU0dfUFVU KHNrYiwgMCwgbXNnLT5zZXEsIE5MTVNHX0RPTkUsIHNpemUgLSBOTE1TR19BTElHTihzaXplb2Yo Km5saCkpKTsNCg0KCWRhdGEgPSAoc3RydWN0IGNuX21zZyAqKU5MTVNHX0RBVEEobmxoKTsNCg0K CW1lbWNweShkYXRhLCBtc2csIHNpemVvZigqZGF0YSkgKyBtc2ctPmxlbik7DQojaWYgMA0KCXBy aW50aygiJXM6IGxlbj0ldSwgc2VxPSV1LCBhY2s9JXUsIGdyb3VwPSV1LlxuIiwNCgkgICAgICAg X19mdW5jX18sIG1zZy0+bGVuLCBtc2ctPnNlcSwgbXNnLT5hY2ssIGdyb3Vwcyk7DQojZW5kaWYN CgkNCglORVRMSU5LX0NCKHNrYikuZHN0X2dyb3VwcyA9IGdyb3VwczsNCg0KCXVza2IgPSBza2Jf Y2xvbmUoc2tiLCBHRlBfQVRPTUlDKTsNCglpZiAodXNrYikgew0KCQluZXRsaW5rX3VuaWNhc3Qo ZGV2LT5ubHMsIHVza2IsIDAsIDApOw0KCX0NCgkNCgluZXRsaW5rX2Jyb2FkY2FzdChkZXYtPm5s cywgc2tiLCAwLCBncm91cHMsIEdGUF9BVE9NSUMpOw0KDQoJcmV0dXJuOw0KDQpubG1zZ19mYWls dXJlOg0KCXByaW50ayhLRVJOX0VSUiAiRmFpbGVkIHRvIHNlbmQgJXUuJXVcbiIsIG1zZy0+c2Vx LCBtc2ctPmFjayk7DQoJa2ZyZWVfc2tiKHNrYik7DQoJcmV0dXJuOw0KfQ0KDQpzdGF0aWMgaW50 IGNuX2NhbGxfY2FsbGJhY2soc3RydWN0IGNuX21zZyAqbXNnLCB2b2lkICgqZGVzdHJ1Y3RfZGF0 YSkgKHZvaWQgKiksIHZvaWQgKmRhdGEpDQp7DQoJc3RydWN0IGNuX2NhbGxiYWNrX2VudHJ5ICpu LCAqX19jYnE7DQoJc3RydWN0IGNuX2RldiAqZGV2ID0gJmNkZXY7DQoJaW50IGZvdW5kID0gMDsN Cg0KCXNwaW5fbG9ja19iaCgmZGV2LT5jYmRldi0+cXVldWVfbG9jayk7DQoJbGlzdF9mb3JfZWFj aF9lbnRyeV9zYWZlKF9fY2JxLCBuLCAmZGV2LT5jYmRldi0+cXVldWVfbGlzdCwgY2FsbGJhY2tf ZW50cnkpIHsNCgkJaWYgKGNuX2NiX2VxdWFsKCZfX2NicS0+Y2ItPmlkLCAmbXNnLT5pZCkpIHsN CgkJCV9fY2JxLT5jYi0+cHJpdiA9IG1zZzsNCg0KCQkJX19jYnEtPmRkYXRhID0gZGF0YTsNCgkJ CV9fY2JxLT5kZXN0cnVjdF9kYXRhID0gZGVzdHJ1Y3RfZGF0YTsNCg0KCQkJcXVldWVfd29yayhk ZXYtPmNiZGV2LT5jbl9xdWV1ZSwgJl9fY2JxLT53b3JrKTsNCgkJCWZvdW5kID0gMTsNCgkJCWJy ZWFrOw0KCQl9DQoJfQ0KCXNwaW5fdW5sb2NrX2JoKCZkZXYtPmNiZGV2LT5xdWV1ZV9sb2NrKTsN Cg0KCXJldHVybiBmb3VuZDsNCn0NCg0Kc3RhdGljIGludCBfX2NuX3J4X3NrYihzdHJ1Y3Qgc2tf YnVmZiAqc2tiLCBzdHJ1Y3Qgbmxtc2doZHIgKm5saCkNCnsNCgl1MzIgcGlkLCB1aWQsIHNlcSwg Z3JvdXA7DQoJc3RydWN0IGNuX21zZyAqbXNnOw0KDQoJcGlkID0gTkVUTElOS19DUkVEUyhza2Ip LT5waWQ7DQoJdWlkID0gTkVUTElOS19DUkVEUyhza2IpLT51aWQ7DQoJc2VxID0gbmxoLT5ubG1z Z19zZXE7DQoJZ3JvdXAgPSBORVRMSU5LX0NCKChza2IpKS5ncm91cHM7DQoJbXNnID0gKHN0cnVj dCBjbl9tc2cgKilOTE1TR19EQVRBKG5saCk7DQoNCglpZiAoTkxNU0dfU1BBQ0UobXNnLT5sZW4g KyBzaXplb2YoKm1zZykpICE9IG5saC0+bmxtc2dfbGVuKSB7DQoJCXByaW50ayhLRVJOX0VSUiAi c2tiIGRvZXMgbm90IGhhdmUgZW5vdWdoIGxlbmd0aDogIg0KCQkJCSJyZXF1ZXN0ZWQgbXNnLT5s ZW49JXVbJXVdLCBubGgtPm5sbXNnX2xlbj0ldSwgc2tiLT5sZW49JXUuXG4iLCANCgkJCQltc2ct PmxlbiwgTkxNU0dfU1BBQ0UobXNnLT5sZW4gKyBzaXplb2YoKm1zZykpLCANCgkJCQlubGgtPm5s bXNnX2xlbiwgc2tiLT5sZW4pOw0KCQlrZnJlZV9za2Ioc2tiKTsNCgkJcmV0dXJuIC1FSU5WQUw7 DQoJfQ0KI2lmIDANCglwcmludGsoS0VSTl9JTkZPICJwaWQ9JXUsIHVpZD0ldSwgc2VxPSV1LCBn cm91cD0ldS5cbiIsDQoJICAgICAgIHBpZCwgdWlkLCBzZXEsIGdyb3VwKTsNCiNlbmRpZg0KCXJl dHVybiBjbl9jYWxsX2NhbGxiYWNrKG1zZywgKHZvaWQgKCopKHZvaWQgKikpa2ZyZWVfc2tiLCBz a2IpOw0KfQ0KDQpzdGF0aWMgdm9pZCBjbl9yeF9za2Ioc3RydWN0IHNrX2J1ZmYgKl9fc2tiKQ0K ew0KCXN0cnVjdCBubG1zZ2hkciAqbmxoOw0KCXUzMiBsZW47DQoJaW50IGVycjsNCglzdHJ1Y3Qg c2tfYnVmZiAqc2tiOw0KDQoJc2tiID0gc2tiX2dldChfX3NrYik7DQoJaWYgKCFza2IpIHsNCgkJ cHJpbnRrKEtFUk5fRVJSICJGYWlsZWQgdG8gcmVmZXJlbmNlIGFuIHNrYi5cbiIpOw0KCQlrZnJl ZV9za2IoX19za2IpOw0KCQlyZXR1cm47DQoJfQ0KI2lmIDANCglwcmludGsoS0VSTl9JTkZPDQoJ ICAgICAgICJza2I6IGxlbj0ldSwgZGF0YV9sZW49JXUsIHRydWVzaXplPSV1LCBwcm90bz0ldSwg Y2xvbmVkPSVkLCBzaGFyZWQ9JWQuXG4iLA0KCSAgICAgICBza2ItPmxlbiwgc2tiLT5kYXRhX2xl biwgc2tiLT50cnVlc2l6ZSwgc2tiLT5wcm90b2NvbCwNCgkgICAgICAgc2tiX2Nsb25lZChza2Ip LCBza2Jfc2hhcmVkKHNrYikpOw0KI2VuZGlmDQoJd2hpbGUgKHNrYi0+bGVuID49IE5MTVNHX1NQ QUNFKDApKSB7DQoJCW5saCA9IChzdHJ1Y3Qgbmxtc2doZHIgKilza2ItPmRhdGE7DQoJCWlmIChu bGgtPm5sbXNnX2xlbiA8IHNpemVvZihzdHJ1Y3QgY25fbXNnKSB8fA0KCQkgICAgc2tiLT5sZW4g PCBubGgtPm5sbXNnX2xlbiB8fA0KCQkgICAgbmxoLT5ubG1zZ19sZW4gPiBDT05ORUNUT1JfTUFY X01TR19TSVpFKSB7DQojaWYgMA0KCQkJcHJpbnRrKEtFUk5fSU5GTyAibmxtc2dfbGVuPSV1LCBz aXplb2YoKm5saCk9JXVcbiIsDQoJCQkgICAgICAgbmxoLT5ubG1zZ19sZW4sIHNpemVvZigqbmxo KSk7DQojZW5kaWYNCgkJCWtmcmVlX3NrYihza2IpOw0KCQkJYnJlYWs7DQoJCX0NCg0KCQlsZW4g PSBOTE1TR19BTElHTihubGgtPm5sbXNnX2xlbik7DQoJCWlmIChsZW4gPiBza2ItPmxlbikNCgkJ CWxlbiA9IHNrYi0+bGVuOw0KDQoJCWVyciA9IF9fY25fcnhfc2tiKHNrYiwgbmxoKTsNCgkJaWYg KGVycikgew0KI2lmIDANCgkJCWlmIChlcnIgPCAwICYmIChubGgtPm5sbXNnX2ZsYWdzICYgTkxN X0ZfQUNLKSkNCgkJCQluZXRsaW5rX2Fjayhza2IsIG5saCwgLWVycik7DQojZW5kaWYNCgkJCWJy ZWFrOw0KCQl9IGVsc2Ugew0KI2lmIDANCgkJCWlmIChubGgtPm5sbXNnX2ZsYWdzICYgTkxNX0Zf QUNLKQ0KCQkJCW5ldGxpbmtfYWNrKHNrYiwgbmxoLCAwKTsNCiNlbmRpZg0KCQkJYnJlYWs7DQoJ CX0NCgkJc2tiX3B1bGwoc2tiLCBsZW4pOw0KCX0NCgkJCQ0KCWtmcmVlX3NrYihfX3NrYik7DQp9 DQoNCnN0YXRpYyB2b2lkIGNuX2lucHV0KHN0cnVjdCBzb2NrICpzaywgaW50IGxlbikNCnsNCglz dHJ1Y3Qgc2tfYnVmZiAqc2tiOw0KDQoJd2hpbGUgKChza2IgPSBza2JfZGVxdWV1ZSgmc2stPnNr X3JlY2VpdmVfcXVldWUpKSAhPSBOVUxMKQ0KCQljbl9yeF9za2Ioc2tiKTsNCn0NCg0Kc3RhdGlj IHZvaWQgY25fbm90aWZ5KHN0cnVjdCBjYl9pZCAqaWQsIHUzMiBub3RpZnlfZXZlbnQpDQp7DQoJ c3RydWN0IGNuX2N0bF9lbnRyeSAqZW50Ow0KDQoJc3Bpbl9sb2NrX2JoKCZub3RpZnlfbG9jayk7 DQoJbGlzdF9mb3JfZWFjaF9lbnRyeShlbnQsICZub3RpZnlfbGlzdCwgbm90aWZ5X2VudHJ5KSB7 DQoJCWludCBpOw0KCQlzdHJ1Y3QgY25fbm90aWZ5X3JlcSAqcmVxOw0KCQlzdHJ1Y3QgY25fY3Rs X21zZyAqY3RsID0gZW50LT5tc2c7DQoJCWludCBhLCBiOw0KDQoJCWEgPSBiID0gMDsNCgkJDQoJ CXJlcSA9IChzdHJ1Y3QgY25fbm90aWZ5X3JlcSAqKWN0bC0+ZGF0YTsNCgkJZm9yIChpPTA7IGk8 Y3RsLT5pZHhfbm90aWZ5X251bTsgKytpLCArK3JlcSkgew0KCQkJaWYgKGlkLT5pZHggPj0gcmVx LT5maXJzdCAmJiBpZC0+aWR4IDwgcmVxLT5maXJzdCArIHJlcS0+cmFuZ2UpIHsNCgkJCQlhID0g MTsNCgkJCQlicmVhazsNCgkJCX0NCgkJfQ0KCQkNCgkJZm9yIChpPTA7IGk8Y3RsLT52YWxfbm90 aWZ5X251bTsgKytpLCArK3JlcSkgew0KCQkJaWYgKGlkLT52YWwgPj0gcmVxLT5maXJzdCAmJiBp ZC0+dmFsIDwgcmVxLT5maXJzdCArIHJlcS0+cmFuZ2UpIHsNCgkJCQliID0gMTsNCgkJCQlicmVh azsNCgkJCX0NCgkJfQ0KDQoJCWlmIChhICYmIGIpIHsNCgkJCXN0cnVjdCBjbl9tc2cgbTsNCgkJ CQ0KCQkJcHJpbnRrKEtFUk5fSU5GTyAiTm90aWZ5aW5nIGdyb3VwICV4IHdpdGggZXZlbnQgJXUg YWJvdXQgJXguJXguXG4iLCANCgkJCQkJY3RsLT5ncm91cCwgbm90aWZ5X2V2ZW50LCANCgkJCQkJ aWQtPmlkeCwgaWQtPnZhbCk7DQoNCgkJCW1lbXNldCgmbSwgMCwgc2l6ZW9mKG0pKTsNCgkJCW0u YWNrID0gbm90aWZ5X2V2ZW50Ow0KDQoJCQltZW1jcHkoJm0uaWQsIGlkLCBzaXplb2YobS5pZCkp Ow0KCQkJY25fbmV0bGlua19zZW5kKCZtLCBjdGwtPmdyb3VwKTsNCgkJfQ0KCX0NCglzcGluX3Vu bG9ja19iaCgmbm90aWZ5X2xvY2spOw0KfQ0KDQppbnQgY25fYWRkX2NhbGxiYWNrKHN0cnVjdCBj Yl9pZCAqaWQsIGNoYXIgKm5hbWUsIHZvaWQgKCpjYWxsYmFjaykgKHZvaWQgKikpDQp7DQoJaW50 IGVycjsNCglzdHJ1Y3QgY25fZGV2ICpkZXYgPSAmY2RldjsNCglzdHJ1Y3QgY25fY2FsbGJhY2sg KmNiOw0KDQoJY2IgPSBrbWFsbG9jKHNpemVvZigqY2IpLCBHRlBfS0VSTkVMKTsNCglpZiAoIWNi KSB7DQoJCXByaW50ayhLRVJOX0lORk8gIiVzOiBGYWlsZWQgdG8gYWxsb2NhdGUgbmV3IHN0cnVj dCBjbl9jYWxsYmFjay5cbiIsDQoJCSAgICAgICBkZXYtPmNiZGV2LT5uYW1lKTsNCgkJcmV0dXJu IC1FTk9NRU07DQoJfQ0KDQoJbWVtc2V0KGNiLCAwLCBzaXplb2YoKmNiKSk7DQoNCglzbnByaW50 ZihjYi0+bmFtZSwgc2l6ZW9mKGNiLT5uYW1lKSwgIiVzIiwgbmFtZSk7DQoNCgltZW1jcHkoJmNi LT5pZCwgaWQsIHNpemVvZihjYi0+aWQpKTsNCgljYi0+Y2FsbGJhY2sgPSBjYWxsYmFjazsNCg0K CWF0b21pY19zZXQoJmNiLT5yZWZjbnQsIDApOw0KDQoJZXJyID0gY25fcXVldWVfYWRkX2NhbGxi YWNrKGRldi0+Y2JkZXYsIGNiKTsNCglpZiAoZXJyKSB7DQoJCWtmcmVlKGNiKTsNCgkJcmV0dXJu IGVycjsNCgl9DQoJCQkNCgljbl9ub3RpZnkoaWQsIDApOw0KDQoJcmV0dXJuIDA7DQp9DQoNCnZv aWQgY25fZGVsX2NhbGxiYWNrKHN0cnVjdCBjYl9pZCAqaWQpDQp7DQoJc3RydWN0IGNuX2RldiAq ZGV2ID0gJmNkZXY7DQoJc3RydWN0IGNuX2NhbGxiYWNrX2VudHJ5ICpuLCAqX19jYnE7DQoNCgls aXN0X2Zvcl9lYWNoX2VudHJ5X3NhZmUoX19jYnEsIG4sICZkZXYtPmNiZGV2LT5xdWV1ZV9saXN0 LCBjYWxsYmFja19lbnRyeSkgew0KCQlpZiAoY25fY2JfZXF1YWwoJl9fY2JxLT5jYi0+aWQsIGlk KSkgew0KCQkJY25fcXVldWVfZGVsX2NhbGxiYWNrKGRldi0+Y2JkZXYsIF9fY2JxLT5jYik7DQoJ CQljbl9ub3RpZnkoaWQsIDEpOw0KCQkJYnJlYWs7DQoJCX0NCgl9DQp9DQoNCnN0YXRpYyBpbnQg Y25fY3RsX21zZ19lcXVhbHMoc3RydWN0IGNuX2N0bF9tc2cgKm0xLCBzdHJ1Y3QgY25fY3RsX21z ZyAqbTIpDQp7DQoJaW50IGk7DQoJc3RydWN0IGNuX25vdGlmeV9yZXEgKnJlcTEsICpyZXEyOw0K DQoJaWYgKG0xLT5pZHhfbm90aWZ5X251bSAhPSBtMi0+aWR4X25vdGlmeV9udW0pDQoJCXJldHVy biAwOw0KCQ0KCWlmIChtMS0+dmFsX25vdGlmeV9udW0gIT0gbTItPnZhbF9ub3RpZnlfbnVtKQ0K CQlyZXR1cm4gMDsNCgkNCglpZiAobTEtPmxlbiAhPSBtMi0+bGVuKQ0KCQlyZXR1cm4gMDsNCg0K CWlmICgobTEtPmlkeF9ub3RpZnlfbnVtICsgbTEtPnZhbF9ub3RpZnlfbnVtKSpzaXplb2YoKnJl cTEpICE9IG0xLT5sZW4pIHsNCgkJcHJpbnRrKEtFUk5fRVJSICJOb3RpZnkgZW50cnlbaWR4X251 bT0leCwgdmFsX251bT0leCwgbGVuPSV1XSBjb250YWlucyBnYXJiYWdlLiBSZW1vdmluZy5cbiIs IA0KCQkJCW0xLT5pZHhfbm90aWZ5X251bSwgbTEtPnZhbF9ub3RpZnlfbnVtLCBtMS0+bGVuKTsN CgkJcmV0dXJuIDE7DQoJfQ0KDQoJcmVxMSA9IChzdHJ1Y3QgY25fbm90aWZ5X3JlcSAqKW0xLT5k YXRhOw0KCXJlcTIgPSAoc3RydWN0IGNuX25vdGlmeV9yZXEgKiltMi0+ZGF0YTsNCgkNCglmb3Ig KGk9MDsgaTxtMS0+aWR4X25vdGlmeV9udW07ICsraSkgew0KCQlpZiAobWVtY21wKHJlcTEsIHJl cTIsIHNpemVvZigqcmVxMSkpKQ0KCQkJcmV0dXJuIDA7DQoNCgkJcmVxMSsrOw0KCQlyZXEyKys7 DQoJfQ0KDQoJZm9yIChpPTA7IGk8bTEtPnZhbF9ub3RpZnlfbnVtOyArK2kpIHsNCgkJaWYgKG1l bWNtcChyZXExLCByZXEyLCBzaXplb2YoKnJlcTEpKSkNCgkJCXJldHVybiAwOw0KDQoJCXJlcTEr KzsNCgkJcmVxMisrOw0KCX0NCg0KCXJldHVybiAxOw0KfQ0KDQpzdGF0aWMgdm9pZCBjbl9jYWxs YmFjayh2b2lkICogZGF0YSkNCnsNCglzdHJ1Y3QgY25fbXNnICptc2cgPSAoc3RydWN0IGNuX21z ZyAqKWRhdGE7DQoJc3RydWN0IGNuX2N0bF9tc2cgKmN0bDsNCglzdHJ1Y3QgY25fY3RsX2VudHJ5 ICplbnQ7DQoJdTMyIHNpemU7DQogDQoJaWYgKG1zZy0+bGVuIDwgc2l6ZW9mKCpjdGwpKSB7DQoJ CXByaW50ayhLRVJOX0VSUiAiV3JvbmcgY29ubmVjdG9yIHJlcXVlc3Qgc2l6ZSAldSwgbXVzdCBi ZSA+PSAldS5cbiIsIA0KCQkJCW1zZy0+bGVuLCBzaXplb2YoKmN0bCkpOw0KCQlyZXR1cm47DQoJ fQ0KCQ0KCWN0bCA9IChzdHJ1Y3QgY25fY3RsX21zZyAqKW1zZy0+ZGF0YTsNCg0KCXNpemUgPSBz aXplb2YoKmN0bCkgKyAoY3RsLT5pZHhfbm90aWZ5X251bSArIGN0bC0+dmFsX25vdGlmeV9udW0p KnNpemVvZihzdHJ1Y3QgY25fbm90aWZ5X3JlcSk7DQoNCglpZiAobXNnLT5sZW4gIT0gc2l6ZSkg ew0KCQlwcmludGsoS0VSTl9FUlIgIldyb25nIGNvbm5lY3RvciByZXF1ZXN0IHNpemUgJXUsIG11 c3QgYmUgPT0gJXUuXG4iLCANCgkJCQltc2ctPmxlbiwgc2l6ZSk7DQoJCXJldHVybjsNCgl9DQoN CglpZiAoY3RsLT5sZW4gKyBzaXplb2YoKmN0bCkgIT0gbXNnLT5sZW4pIHsNCgkJcHJpbnRrKEtF Uk5fRVJSICJXcm9uZyBtZXNzYWdlOiBtc2ctPmxlbj0ldSBtdXN0IGJlIGVxdWFsIHRvIGlubmVy X2xlbj0ldSBbKyV1XS5cbiIsIA0KCQkJCW1zZy0+bGVuLCBjdGwtPmxlbiwgc2l6ZW9mKCpjdGwp KTsNCgkJcmV0dXJuOw0KCX0NCg0KCS8qDQoJICogUmVtb3ZlIG5vdGlmaWNhdGlvbi4NCgkgKi8N CglpZiAoY3RsLT5ncm91cCA9PSAwKSB7DQoJCXN0cnVjdCBjbl9jdGxfZW50cnkgKm47DQoJCQ0K CQlzcGluX2xvY2tfYmgoJm5vdGlmeV9sb2NrKTsNCgkJbGlzdF9mb3JfZWFjaF9lbnRyeV9zYWZl KGVudCwgbiwgJm5vdGlmeV9saXN0LCBub3RpZnlfZW50cnkpIHsNCgkJCWlmIChjbl9jdGxfbXNn X2VxdWFscyhlbnQtPm1zZywgY3RsKSkgew0KCQkJCWxpc3RfZGVsKCZlbnQtPm5vdGlmeV9lbnRy eSk7DQoJCQkJa2ZyZWUoZW50KTsNCgkJCX0NCgkJfQ0KCQlzcGluX3VubG9ja19iaCgmbm90aWZ5 X2xvY2spOw0KDQoJCXJldHVybjsNCgl9DQoNCglzaXplICs9IHNpemVvZigqZW50KTsNCg0KCWVu dCA9IGttYWxsb2Moc2l6ZSwgR0ZQX0FUT01JQyk7DQoJaWYgKCFlbnQpIHsNCgkJcHJpbnRrKEtF Uk5fRVJSICJGYWlsZWQgdG8gYWxsb2NhdGUgJWQgYnl0ZXMgZm9yIG5ldyBub3RpZnkgZW50cnku XG4iLCBzaXplKTsNCgkJcmV0dXJuOw0KCX0NCg0KCW1lbXNldChlbnQsIDAsIHNpemUpOw0KDQoJ ZW50LT5tc2cgPSAoc3RydWN0IGNuX2N0bF9tc2cgKikoZW50ICsgMSk7DQoNCgltZW1jcHkoZW50 LT5tc2csIGN0bCwgc2l6ZSAtIHNpemVvZigqZW50KSk7DQoNCglzcGluX2xvY2tfYmgoJm5vdGlm eV9sb2NrKTsNCglsaXN0X2FkZCgmZW50LT5ub3RpZnlfZW50cnksICZub3RpZnlfbGlzdCk7DQoJ c3Bpbl91bmxvY2tfYmgoJm5vdGlmeV9sb2NrKTsNCg0KCXsNCgkJaW50IGk7DQoJCXN0cnVjdCBj bl9ub3RpZnlfcmVxICpyZXE7DQoJDQoJCXByaW50aygiTm90aWZ5IGdyb3VwICV4IGZvciBpZHg6 ICIsIGN0bC0+Z3JvdXApOw0KDQoJCXJlcSA9IChzdHJ1Y3QgY25fbm90aWZ5X3JlcSAqKWN0bC0+ ZGF0YTsNCgkJZm9yIChpPTA7IGk8Y3RsLT5pZHhfbm90aWZ5X251bTsgKytpLCArK3JlcSkgew0K CQkJcHJpbnRrKCIldS0ldSAiLCByZXEtPmZpcnN0LCByZXEtPmZpcnN0K3JlcS0+cmFuZ2UtMSk7 DQoJCX0NCgkJDQoJCXByaW50aygiXG5Ob3RpZnkgZ3JvdXAgJXggZm9yIHZhbDogIiwgY3RsLT5n cm91cCk7DQoNCgkJZm9yIChpPTA7IGk8Y3RsLT52YWxfbm90aWZ5X251bTsgKytpLCArK3JlcSkg ew0KCQkJcHJpbnRrKCIldS0ldSAiLCByZXEtPmZpcnN0LCByZXEtPmZpcnN0K3JlcS0+cmFuZ2Ut MSk7DQoJCX0NCgkJcHJpbnRrKCJcbiIpOw0KCX0NCn0NCg0Kc3RhdGljIHZvaWQgY25fZm9ya19j YWxsYmFjayh2b2lkICpkYXRhKSANCnsNCiAgICAgICBpZiAoY25fYWxyZWFkeV9pbml0aWFsaXpl ZCkNCiAgICAgICAgICAgICAgIGNuX2ZvcmtfZW5hYmxlID0gMTsNCn0NCg0Kc3RhdGljIGludCBj bl9pbml0KHZvaWQpDQp7DQoJc3RydWN0IGNuX2RldiAqZGV2ID0gJmNkZXY7DQoJaW50IGVycjsN Cg0KCWRldi0+aW5wdXQgPSBjbl9pbnB1dDsNCglkZXYtPmlkLmlkeCA9IGNuX2lkeDsNCglkZXYt PmlkLnZhbCA9IGNuX3ZhbDsNCg0KCWRldi0+bmxzID0gbmV0bGlua19rZXJuZWxfY3JlYXRlKHVu aXQsIGRldi0+aW5wdXQpOw0KCWlmICghZGV2LT5ubHMpIHsNCgkJcHJpbnRrKEtFUk5fRVJSICJG YWlsZWQgdG8gY3JlYXRlIG5ldyBuZXRsaW5rIHNvY2tldCgldSkuXG4iLA0KCQkgICAgICAgdW5p dCk7DQoJCXJldHVybiAtRUlPOw0KCX0NCg0KCWRldi0+Y2JkZXYgPSBjbl9xdWV1ZV9hbGxvY19k ZXYoImNxdWV1ZSIsIGRldi0+bmxzKTsNCglpZiAoIWRldi0+Y2JkZXYpIHsNCgkJaWYgKGRldi0+ bmxzLT5za19zb2NrZXQpDQoJCQlzb2NrX3JlbGVhc2UoZGV2LT5ubHMtPnNrX3NvY2tldCk7DQoJ CXJldHVybiAtRUlOVkFMOw0KCX0NCg0KCWVyciA9IGNuX2FkZF9jYWxsYmFjaygmZGV2LT5pZCwg ImNvbm5lY3RvciIsICZjbl9jYWxsYmFjayk7DQoJaWYgKGVycikgew0KCQljbl9xdWV1ZV9mcmVl X2RldihkZXYtPmNiZGV2KTsNCgkJaWYgKGRldi0+bmxzLT5za19zb2NrZXQpDQoJCQlzb2NrX3Jl bGVhc2UoZGV2LT5ubHMtPnNrX3NvY2tldCk7DQoJCXJldHVybiAtRUlOVkFMOw0KCX0NCgllcnIg PSBjbl9hZGRfY2FsbGJhY2soJmNiX2ZvcmtfaWQsICJjbl9mb3JrIiwgJmNuX2ZvcmtfY2FsbGJh Y2spOw0KCWlmIChlcnIpIHsNCgkJY25fZGVsX2NhbGxiYWNrKCZkZXYtPmlkKTsNCgkJY25fcXVl dWVfZnJlZV9kZXYoZGV2LT5jYmRldik7DQoJCWlmIChkZXYtPm5scy0+c2tfc29ja2V0KQ0KCQkJ c29ja19yZWxlYXNlKGRldi0+bmxzLT5za19zb2NrZXQpOw0KCQlyZXR1cm4gLUVJTlZBTDsNCgl9 DQoNCgljbl9hbHJlYWR5X2luaXRpYWxpemVkID0gMTsNCg0KCXJldHVybiAwOw0KfQ0KDQpzdGF0 aWMgdm9pZCBjbl9maW5pKHZvaWQpDQp7DQoJc3RydWN0IGNuX2RldiAqZGV2ID0gJmNkZXY7DQoN Cgljbl9kZWxfY2FsbGJhY2soJmRldi0+aWQpOw0KCWNuX3F1ZXVlX2ZyZWVfZGV2KGRldi0+Y2Jk ZXYpOw0KCWlmIChkZXYtPm5scy0+c2tfc29ja2V0KQ0KCQlzb2NrX3JlbGVhc2UoZGV2LT5ubHMt PnNrX3NvY2tldCk7DQp9DQoNCm1vZHVsZV9pbml0KGNuX2luaXQpOw0KbW9kdWxlX2V4aXQoY25f ZmluaSk7DQoNCkVYUE9SVF9TWU1CT0xfR1BMKGNuX2FkZF9jYWxsYmFjayk7DQpFWFBPUlRfU1lN Qk9MX0dQTChjbl9kZWxfY2FsbGJhY2spOw0KRVhQT1JUX1NZTUJPTF9HUEwoY25fbmV0bGlua19z ZW5kKTsNCg== --=-JgbT51g/LuBG3QWsxd46-- --=-04dngmqtPZ1HpTDHUoly Content-Type: application/pgp-signature; name=signature.asc Content-Description: This is a digitally signed message part -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.6 (GNU/Linux) iD8DBQBCJwEcIKTPhE+8wY0RAjvEAJ0Zij3TMAsXZpLlVRzgDkBbJ38p9wCcDsYG /zpUf0VjcDcxqh3HVnCnE+E= =Kw5C -----END PGP SIGNATURE----- --=-04dngmqtPZ1HpTDHUoly-- From tgraf@suug.ch Thu Mar 3 04:53:08 2005 Received: with ECARTIS (v1.0.0; list netdev); Thu, 03 Mar 2005 04:53:11 -0800 (PST) Received: from b.mx.projectdream.org (eth0-0.arisu.projectdream.org [194.158.4.191]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j23Cr7nP026069 for ; Thu, 3 Mar 2005 04:53:08 -0800 Received: from postel.suug.ch (postel.suug.ch [195.134.158.23]) (using TLSv1 with cipher EDH-RSA-DES-CBC3-SHA (168/168 bits)) (No client certificate requested) by b.mx.projectdream.org (Postfix) with ESMTP id 86FE188; Thu, 3 Mar 2005 13:52:43 +0100 (CET) Received: by postel.suug.ch (Postfix, from userid 10001) id 257B71C0EA; Thu, 3 Mar 2005 13:53:26 +0100 (CET) Date: Thu, 3 Mar 2005 13:53:25 +0100 From: Thomas Graf To: Peter Bieringer Cc: usagi-users@linux-ipv6.org, netdev@oss.sgi.com Subject: Re: ip -6 addr flush dev flushes also the autogenerated link-local address Message-ID: <20050303125325.GV31837@postel.suug.ch> References: <001C540DBA8D9308CA5D790F@worker.muc.bieringer.de> <1109801372.1098.228.camel@jzny.localdomain> <20050302231400.GU31837@postel.suug.ch> <20050303.090009.59651076.yoshfuji@linux-ipv6.org> <7C7833F5F8350E30351D9B98@gatemuc.muc.bieringer.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <7C7833F5F8350E30351D9B98@gatemuc.muc.bieringer.de> X-Virus-Scanned: ClamAV 0.83/742/Tue Mar 1 17:05:59 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 2296 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: tgraf@suug.ch Precedence: bulk X-list: netdev > BTW: how many scopes are currently defined? > > ip help shows me: > SCOPE-ID := [ host | link | global | NUMBER ] > > What means NUMBER and why is "site" understood but not in online help? The kernel hardcodes the following scopes internally: 0 {global | universe} 200 site 253 link 254 host 255 nowhere Additional names may be assigned to numbers in /etc/iproute2/rt_scopes From bunk@stusta.de Thu Mar 3 07:07:40 2005 Received: with ECARTIS (v1.0.0; list netdev); Thu, 03 Mar 2005 07:07:43 -0800 (PST) Received: from mailout.stusta.mhn.de (mailout.stusta.mhn.de [141.84.69.5]) by oss.sgi.com (8.13.0/8.13.0) with SMTP id j23F7cXh032506 for ; Thu, 3 Mar 2005 07:07:39 -0800 Received: (qmail 20489 invoked from network); 3 Mar 2005 15:07:32 -0000 Received: from r063144.stusta.swh.mhn.de (10.150.63.144) by mailhub.stusta.mhn.de with SMTP; 3 Mar 2005 15:07:32 -0000 Received: by r063144.stusta.swh.mhn.de (Postfix, from userid 1000) id E9422AFE76; Thu, 3 Mar 2005 16:07:30 +0100 (CET) Date: Thu, 3 Mar 2005 16:07:30 +0100 From: Adrian Bunk To: Jeff Garzik , jmorris@redhat.com, davem@davemloft.net Cc: Andrew Morton , netdev@oss.sgi.com, linux-kernel@vger.kernel.org Subject: How to handle the multiple aes variants on i386? Message-ID: <20050303150730.GA4608@stusta.de> References: <20050226113123.GJ3311@stusta.de> <42256078.1040002@pobox.com> <20050302140833.GD4608@stusta.de> <42261004.4000501@pobox.com> <20050302123829.51dbc44b.akpm@osdl.org> <42262B08.2040401@pobox.com> <20050302131817.2e61805f.akpm@osdl.org> <4226412E.6070403@pobox.com> <20050302224550.GJ4608@stusta.de> <422642F6.5040102@pobox.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <422642F6.5040102@pobox.com> User-Agent: Mutt/1.5.6+20040907i X-Virus-Scanned: ClamAV 0.83/743/Wed Mar 2 16:02:05 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 2297 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: bunk@stusta.de Precedence: bulk X-list: netdev On Wed, Mar 02, 2005 at 05:49:26PM -0500, Jeff Garzik wrote: > Adrian Bunk wrote: > >On Wed, Mar 02, 2005 at 05:41:50PM -0500, Jeff Garzik wrote: >... > >>Not really that easy. For x86 we have > >> > >> aes > >> aes-586 > >> aes-via > > > > > >Where is aes-via? > > drivers/crypto > > > >>And my own personal custom-kernel preference is to use the C version of > >>the code on my x86 and x86-64 boxes. > > > > > >That's already not possible today. > > It should be. OK, rethinking about it, your arguments sound reasonable. Could anyone explain, what exactly happens if multiple "aes" algorithms are compiled into the kernel? Choosing between the i386 asm and the generic versions seems easy, bug the VIA Padlock case sounds more tricky since it works only on a subset of the i386 architecture. > Jeff cu Adrian -- "Is there not promise of rain?" Ling Tan asked suddenly out of the darkness. There had been need of rain for many days. "Only a promise," Lao Er said. Pearl S. Buck - Dragon Seed From shemminger@osdl.org Thu Mar 3 09:58:23 2005 Received: with ECARTIS (v1.0.0; list netdev); Thu, 03 Mar 2005 09:58:29 -0800 (PST) Received: from smtp.osdl.org (fire.osdl.org [65.172.181.4]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j23HwMpd012357 for ; Thu, 3 Mar 2005 09:58:22 -0800 Received: from shell0.pdx.osdl.net (fw.osdl.org [65.172.181.6]) by smtp.osdl.org (8.12.8/8.12.8) with ESMTP id j23HwFqi025106 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO); Thu, 3 Mar 2005 09:58:16 -0800 Received: from dxpl.pdx.osdl.net (dxpl.pdx.osdl.net [172.20.1.103]) by shell0.pdx.osdl.net (8.13.1/8.11.6) with ESMTP id j23HwFKG011992; Thu, 3 Mar 2005 09:58:15 -0800 Date: Thu, 3 Mar 2005 09:58:32 -0800 From: Stephen Hemminger To: maxk@qualcomm.com, max_mk@yahoo.com Cc: netdev@oss.sgi.com Subject: Fw: [Bug 4279] New: When I try to start vpnc the net/core/skbuff.c:91 crash Message-ID: <20050303095832.6a084856@dxpl.pdx.osdl.net> Organization: Open Source Development Lab X-Mailer: Sylpheed-Claws 1.0.1 (GTK+ 1.2.10; x86_64-unknown-linux-gnu) X-Face: &@E+xe?c%:&e4D{>f1O<&U>2qwRREG5!}7R4;D<"NO^UI2mJ[eEOA2*3>(`Th.yP,VDPo9$ /`~cw![cmj~~jWe?AHY7D1S+\}5brN0k*NE?pPh_'_d>6;XGG[\KDRViCfumZT3@[ Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Received-SPF: pass (domain of shemminger@osdl.org designates 65.172.181.6 as permitted sender) X-MIMEDefang-Filter: osdl$Revision: 1.104 $ X-Scanned-By: MIMEDefang 2.36 X-Virus-Scanned: ClamAV 0.83/743/Wed Mar 2 16:02:05 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 2298 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 Looks like a something wrong with tun driver on 2.6.11 ------------------------ http://bugme.osdl.org/show_bug.cgi?id=4279 Summary: When I try to start vpnc the net/core/skbuff.c:91 crash Kernel Version: 2.6.11 vanilla Status: NEW Severity: blocking Owner: shemminger@osdl.org Submitter: linuxale@libero.it Distribution: FC3 Hardware Environment: Acer Travelmate 529Txv Software Environment: Problem Description: When I try to start vpnc the net/core/skbuff.c:91 crash -------------------------- Mar 3 14:43:05 localhost kernel: kernel BUG at net/core/skbuff.c:91! Mar 3 14:43:05 localhost kernel: invalid operand: 0000 [#2] Mar 3 14:43:05 localhost kernel: PREEMPT Mar 3 14:43:05 localhost kernel: Modules linked in: tun crc32 serial_cs 8250 se rial_core psmouse parport_pc lp parport autofs4 af_packet pcmcia ip_conntrack bi nfmt_misc md5 ipv6 video thermal processor fan button battery ac md usbhid usbmo use yenta_socket rsrc_nonstatic pcmcia_core ohci_hcd usbcore snd_ali5451 snd_ac9 7_codec snd_pcm snd_timer snd soundcore snd_page_alloc eepro100 mii ide_cd cdrom reiserfs dm_mod Mar 3 14:43:05 localhost kernel: CPU: 0 Mar 3 14:43:05 localhost kernel: EIP: 0060:[] Not tainted VLI Mar 3 14:43:05 localhost kernel: EFLAGS: 00010286 (2.6.11) Mar 3 14:43:05 localhost kernel: EIP is at skb_over_panic+0x3b/0x50 Mar 3 14:43:05 localhost kernel: eax: 0000002e ebx: c80ed960 ecx: c035780c edx: 00000001 Mar 3 14:43:05 localhost kernel: esi: c084be20 edi: 000000f4 ebp: 000000f4 esp: c7b07f1c Mar 3 14:43:05 localhost kernel: ds: 007b es: 007b ss: 0068 Mar 3 14:43:05 localhost kernel: Process vpnc (pid: 19368, threadinfo=c7b06000 task=d23b45a0) Mar 3 14:43:05 localhost kernel: Stack: c033b188 d90e747e 000000f4 000000f4 c03 2155c d90e748a c80ed960 000000f4 Mar 3 14:43:05 localhost kernel: d90e747e cb47d902 00080000 00000000 000 000f4 d57301a0 08057684 d90e74e8 Mar 3 14:43:05 localhost kernel: d57301a0 c7b07f6c 00000001 c7b07fac 080 57684 000000f4 c015da95 d57301a0 Mar 3 14:43:05 localhost kernel: Call Trace: Mar 3 14:43:05 localhost kernel: [] tun_chr_writev+0x15e/0x190 [tun] Mar 3 14:43:05 localhost kernel: [] tun_chr_writev+0x16a/0x190 [tun] Mar 3 14:43:05 localhost kernel: [] tun_chr_writev+0x15e/0x190 [tun] Mar 3 14:43:05 localhost kernel: [] tun_chr_write+0x38/0x40 [tun] Mar 3 14:43:05 localhost kernel: [] vfs_write+0x155/0x160 Mar 3 14:43:05 localhost kernel: [] sys_write+0x51/0x80 Mar 3 14:43:05 localhost kernel: [] sysenter_past_esp+0x52/0x75 Mar 3 14:43:05 localhost kernel: Code: c0 0f 44 c2 89 44 24 10 8b 44 24 1c 89 4 4 24 0c 8b 41 60 c7 04 24 88 b1 33 c0 89 44 24 08 8b 44 24 20 89 44 24 04 e8 e5 d7 e8 ff <0f> 0b 5b 00 13 8b 33 c0 83 c4 14 c3 89 f6 8d bc 27 00 00 00 00 From andreaf@cs.columbia.edu Thu Mar 3 10:23:54 2005 Received: with ECARTIS (v1.0.0; list netdev); Thu, 03 Mar 2005 10:23:58 -0800 (PST) Received: from cs.columbia.edu (cs.columbia.edu [128.59.16.20]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j23INsiB014034 for ; Thu, 3 Mar 2005 10:23:54 -0800 Received: from lion.cs.columbia.edu (IDENT:6Ejpbs5eCWj4Y6GQYUqYUmaRV+1I2JPr@lion.cs.columbia.edu [128.59.16.120]) by cs.columbia.edu (8.12.10/8.12.10) with ESMTP id j23INpir000646 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NOT); Thu, 3 Mar 2005 13:23:51 -0500 (EST) Received: from [128.59.19.228] (dhcp28.cs.columbia.edu [128.59.19.228]) by lion.cs.columbia.edu (8.12.9/8.12.9) with ESMTP id j23INmRm027214; Thu, 3 Mar 2005 13:23:48 -0500 Message-ID: <4227562F.5000603@cs.columbia.edu> Date: Thu, 03 Mar 2005 13:23:43 -0500 From: Andrea G Forte User-Agent: Mozilla Thunderbird 0.9 (Windows/20041103) X-Accept-Language: en-us, en MIME-Version: 1.0 To: linux-net@vger.kernel.org, netdev@oss.sgi.com Subject: arp table flushed! Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-PerlMx-Spam: Gauge=IIIIIII, Probability=7%, Report='__CT 0, __CTE 0, __CT_TEXT_PLAIN 0, __HAS_MSGID 0, __MIME_VERSION 0, __SANE_MSGID 0' X-Virus-Scanned: ClamAV 0.83/743/Wed Mar 2 16:02:05 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 2299 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: andreaf@cs.columbia.edu Precedence: bulk X-list: netdev Hi all, I wonder if you know why when I do a L3 handoff (the IP address changes) the arp table is completely flushed. So, the kernel starts to arp all over again. Do you know if there is a way to prevent the arp table from being cleaned? I tried to re-fill the entries manually (using the arp command) after I got the new IP, but the kernel ignores the whole thing and starts to arp again. Any help is much appreciated. Best regards, Andrea From shemminger@osdl.org Thu Mar 3 11:46:04 2005 Received: with ECARTIS (v1.0.0; list netdev); Thu, 03 Mar 2005 11:46:13 -0800 (PST) Received: from smtp.osdl.org (fire.osdl.org [65.172.181.4]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j23Jk2EI018352 for ; Thu, 3 Mar 2005 11:46:03 -0800 Received: from shell0.pdx.osdl.net (fw.osdl.org [65.172.181.6]) by smtp.osdl.org (8.12.8/8.12.8) with ESMTP id j23Jjrqi003419 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO); Thu, 3 Mar 2005 11:45:54 -0800 Received: from dxpl.pdx.osdl.net (dxpl.pdx.osdl.net [172.20.1.103]) by shell0.pdx.osdl.net (8.13.1/8.11.6) with ESMTP id j23Jjq04017841; Thu, 3 Mar 2005 11:45:53 -0800 Date: Thu, 3 Mar 2005 11:39:19 -0800 From: Stephen Hemminger To: Jeff Garzik Cc: netdev@oss.sgi.com Subject: [PATCH] (8/12) skge: only allow tx/rx csum on Yukon chipset Message-ID: <20050303113919.4b365d90@dxpl.pdx.osdl.net> Organization: Open Source Development Lab X-Mailer: Sylpheed-Claws 1.0.1 (GTK+ 1.2.10; x86_64-unknown-linux-gnu) X-Face: &@E+xe?c%:&e4D{>f1O<&U>2qwRREG5!}7R4;D<"NO^UI2mJ[eEOA2*3>(`Th.yP,VDPo9$ /`~cw![cmj~~jWe?AHY7D1S+\}5brN0k*NE?pPh_'_d>6;XGG[\KDRViCfumZT3@[ Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Received-SPF: pass (domain of shemminger@osdl.org designates 65.172.181.6 as permitted sender) X-MIMEDefang-Filter: osdl$Revision: 1.104 $ X-Scanned-By: MIMEDefang 2.36 X-Virus-Scanned: ClamAV 0.83/743/Wed Mar 2 16:02:05 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 2302 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 Only allow transmit and receive checksum to be set on Yukon chipsets because the Genesis chipset support probably is broken based on the comments in the sk98lin driver. Signed-off-by: Stephen Hemminger --- skge-2.6.11/drivers/net/skge.c.orig 2005-03-03 09:42:33.000000000 -0800 +++ skge-2.6.11/drivers/net/skge.c 2005-03-03 09:51:52.000000000 -0800 @@ -480,6 +480,17 @@ return ethtool_op_set_sg(dev, data); } +static int skge_set_tx_csum(struct net_device *dev, u32 data) +{ + struct skge_port *skge = netdev_priv(dev); + struct skge_hw *hw = skge->hw; + + if (hw->chip_id == CHIP_ID_GENESIS && data) + return -EOPNOTSUPP; + + return ethtool_op_set_tx_csum(dev, data); +} + static u32 skge_get_rx_csum(struct net_device *dev) { struct skge_port *skge = netdev_priv(dev); @@ -487,6 +498,7 @@ return skge->rx_csum; } +/* Only Yukon supports checksum offload. */ static int skge_set_rx_csum(struct net_device *dev, u32 data) { struct skge_port *skge = netdev_priv(dev); @@ -498,6 +510,7 @@ return 0; } +/* Only Yukon II supports TSO (not implemented yet) */ static int skge_set_tso(struct net_device *dev, u32 data) { if (data) @@ -750,7 +763,7 @@ .get_sg = ethtool_op_get_sg, .set_sg = skge_set_sg, .get_tx_csum = ethtool_op_get_tx_csum, - .set_tx_csum = ethtool_op_set_tx_csum, + .set_tx_csum = skge_set_tx_csum, .get_rx_csum = skge_get_rx_csum, .set_rx_csum = skge_set_rx_csum, .get_strings = skge_get_strings, @@ -3065,14 +3078,11 @@ dev->poll_controller = skge_netpoll; #endif dev->irq = hw->pdev->irq; - if (hw->chip_id != CHIP_ID_GENESIS) - dev->features |= NETIF_F_IP_CSUM | NETIF_F_SG; skge = netdev_priv(dev); skge->netdev = dev; skge->hw = hw; skge->msg_enable = netif_msg_init(debug, default_msg); - skge->rx_csum = 1; skge->tx_ring.count = DEFAULT_TX_RING_SIZE; skge->rx_ring.count = DEFAULT_RX_RING_SIZE; @@ -3097,6 +3107,11 @@ skge->led_blink.function = skge_blink_timer; skge->led_blink.data = (unsigned long) skge; + if (hw->chip_id != CHIP_ID_GENESIS) { + dev->features |= NETIF_F_IP_CSUM | NETIF_F_SG; + skge->rx_csum = 1; + } + /* read the mac address */ memcpy_fromio(dev->dev_addr, hw->regs + B2_MAC_1 + port*8, ETH_ALEN); From shemminger@osdl.org Thu Mar 3 11:46:04 2005 Received: with ECARTIS (v1.0.0; list netdev); Thu, 03 Mar 2005 11:46:13 -0800 (PST) Received: from smtp.osdl.org (fire.osdl.org [65.172.181.4]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j23Jk2Kg018358 for ; Thu, 3 Mar 2005 11:46:03 -0800 Received: from shell0.pdx.osdl.net (fw.osdl.org [65.172.181.6]) by smtp.osdl.org (8.12.8/8.12.8) with ESMTP id j23Jjrqi003427 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO); Thu, 3 Mar 2005 11:45:54 -0800 Received: from dxpl.pdx.osdl.net (dxpl.pdx.osdl.net [172.20.1.103]) by shell0.pdx.osdl.net (8.13.1/8.11.6) with ESMTP id j23JjrgI017853; Thu, 3 Mar 2005 11:45:53 -0800 Date: Thu, 3 Mar 2005 11:45:05 -0800 From: Stephen Hemminger To: Jeff Garzik Cc: netdev@oss.sgi.com Subject: [PATCH] (12/12) skge: change driver version Message-ID: <20050303114505.63539ab9@dxpl.pdx.osdl.net> Organization: Open Source Development Lab X-Mailer: Sylpheed-Claws 1.0.1 (GTK+ 1.2.10; x86_64-unknown-linux-gnu) X-Face: &@E+xe?c%:&e4D{>f1O<&U>2qwRREG5!}7R4;D<"NO^UI2mJ[eEOA2*3>(`Th.yP,VDPo9$ /`~cw![cmj~~jWe?AHY7D1S+\}5brN0k*NE?pPh_'_d>6;XGG[\KDRViCfumZT3@[ Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Received-SPF: pass (domain of shemminger@osdl.org designates 65.172.181.6 as permitted sender) X-MIMEDefang-Filter: osdl$Revision: 1.104 $ X-Scanned-By: MIMEDefang 2.36 X-Virus-Scanned: ClamAV 0.83/743/Wed Mar 2 16:02:05 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 2301 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 Change driver version to 0.6 Signed-off-by: Stephen Hemminger --- skge-2.6.11/drivers/net/skge.c.orig 2005-03-03 10:36:41.000000000 -0800 +++ skge-2.6.11/drivers/net/skge.c 2005-03-03 10:40:19.000000000 -0800 @@ -41,7 +41,7 @@ #include "skge.h" #define DRV_NAME "skge" -#define DRV_VERSION "0.5" +#define DRV_VERSION "0.6" #define PFX DRV_NAME " " #define DEFAULT_TX_RING_SIZE 128 From shemminger@osdl.org Thu Mar 3 11:46:04 2005 Received: with ECARTIS (v1.0.0; list netdev); Thu, 03 Mar 2005 11:46:15 -0800 (PST) Received: from smtp.osdl.org (fire.osdl.org [65.172.181.4]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j23Jk2oU018353 for ; Thu, 3 Mar 2005 11:46:03 -0800 Received: from shell0.pdx.osdl.net (fw.osdl.org [65.172.181.6]) by smtp.osdl.org (8.12.8/8.12.8) with ESMTP id j23Jjrqi003423 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO); Thu, 3 Mar 2005 11:45:53 -0800 Received: from dxpl.pdx.osdl.net (dxpl.pdx.osdl.net [172.20.1.103]) by shell0.pdx.osdl.net (8.13.1/8.11.6) with ESMTP id j23Jjrow017847; Thu, 3 Mar 2005 11:45:53 -0800 Date: Thu, 3 Mar 2005 11:43:04 -0800 From: Stephen Hemminger To: Jeff Garzik Cc: netdev@oss.sgi.com Subject: [PATCH] (10/12) skge: use lockless transmit Message-ID: <20050303114304.1d3b05f5@dxpl.pdx.osdl.net> Organization: Open Source Development Lab X-Mailer: Sylpheed-Claws 1.0.1 (GTK+ 1.2.10; x86_64-unknown-linux-gnu) X-Face: &@E+xe?c%:&e4D{>f1O<&U>2qwRREG5!}7R4;D<"NO^UI2mJ[eEOA2*3>(`Th.yP,VDPo9$ /`~cw![cmj~~jWe?AHY7D1S+\}5brN0k*NE?pPh_'_d>6;XGG[\KDRViCfumZT3@[ Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Received-SPF: pass (domain of shemminger@osdl.org designates 65.172.181.6 as permitted sender) X-MIMEDefang-Filter: osdl$Revision: 1.104 $ X-Scanned-By: MIMEDefang 2.36 X-Virus-Scanned: ClamAV 0.83/743/Wed Mar 2 16:02:05 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 2304 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 Support lockless transmit, because there is existing transmit lock. Also small declaration style fix. Signed-off-by: Stephen Hemminger --- skge-2.6.11/drivers/net/skge.c.orig 2005-03-03 10:28:11.000000000 -0800 +++ skge-2.6.11/drivers/net/skge.c 2005-03-03 10:29:41.000000000 -0800 @@ -2289,13 +2289,20 @@ struct skge_tx_desc *td; int i; u32 control, len; - u64 map; unsigned long flags; + u64 map; + unsigned long flags; skb = skb_padto(skb, ETH_ZLEN); if (!skb) return NETDEV_TX_OK; - spin_lock_irqsave(&skge->tx_lock, flags); + local_irq_save(flags); + if (!spin_trylock(&skge->tx_lock)) { + /* Collision - tell upper layer to requeue */ + local_irq_restore(flags); + return NETDEV_TX_LOCKED; + } + if (unlikely(skge->tx_avail < skb_shinfo(skb)->nr_frags +1)) { netif_stop_queue(dev); spin_unlock_irqrestore(&skge->tx_lock, flags); @@ -3089,6 +3096,7 @@ dev->poll_controller = skge_netpoll; #endif dev->irq = hw->pdev->irq; + dev->features = NETIF_F_LLTX; skge = netdev_priv(dev); skge->netdev = dev; From shemminger@osdl.org Thu Mar 3 11:45:50 2005 Received: with ECARTIS (v1.0.0; list netdev); Thu, 03 Mar 2005 11:45:56 -0800 (PST) Received: from smtp.osdl.org (fire.osdl.org [65.172.181.4]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j23JjmJe018338 for ; Thu, 3 Mar 2005 11:45:50 -0800 Received: from shell0.pdx.osdl.net (fw.osdl.org [65.172.181.6]) by smtp.osdl.org (8.12.8/8.12.8) with ESMTP id j23Jjfqi003406 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO); Thu, 3 Mar 2005 11:45:42 -0800 Received: from dxpl.pdx.osdl.net (dxpl.pdx.osdl.net [172.20.1.103]) by shell0.pdx.osdl.net (8.13.1/8.11.6) with ESMTP id j23JjfOQ017835; Thu, 3 Mar 2005 11:45:41 -0800 Date: Thu, 3 Mar 2005 11:45:57 -0800 From: Stephen Hemminger To: Jeff Garzik Cc: netdev@oss.sgi.com Subject: [PATCH] (1/12) skge: use PFX string Message-ID: <20050303114557.6373662b@dxpl.pdx.osdl.net> Organization: Open Source Development Lab X-Mailer: Sylpheed-Claws 1.0.1 (GTK+ 1.2.10; x86_64-unknown-linux-gnu) X-Face: &@E+xe?c%:&e4D{>f1O<&U>2qwRREG5!}7R4;D<"NO^UI2mJ[eEOA2*3>(`Th.yP,VDPo9$ /`~cw![cmj~~jWe?AHY7D1S+\}5brN0k*NE?pPh_'_d>6;XGG[\KDRViCfumZT3@[ Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Received-SPF: pass (domain of shemminger@osdl.org designates 65.172.181.6 as permitted sender) X-MIMEDefang-Filter: osdl$Revision: 1.104 $ X-Scanned-By: MIMEDefang 2.36 X-Virus-Scanned: ClamAV 0.83/743/Wed Mar 2 16:02:05 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 2300 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 Use the PFX string consistently for all messages Signed-off-by: Stephen Hemminger --- skge-test/drivers/net/skge.c 2005-03-02 17:37:08.000000000 -0800 +++ skge-test/drivers/net/skge.c.new 2005-03-02 17:36:57.000000000 -0800 @@ -3120,13 +3120,13 @@ static int __devinit skge_probe(struct p int err, using_dac = 0; if ((err = pci_enable_device(pdev))) { - printk(KERN_ERR "%s cannot enable PCI device\n", + printk(KERN_ERR PFX "%s cannot enable PCI device\n", pci_name(pdev)); goto err_out; } if ((err = pci_request_regions(pdev, DRV_NAME))) { - printk(KERN_ERR "%s cannot obtain PCI resources\n", + printk(KERN_ERR PFX "%s cannot obtain PCI resources\n", pci_name(pdev)); goto err_out_disable_pdev; } @@ -3136,7 +3136,7 @@ static int __devinit skge_probe(struct p if (!(err = pci_set_dma_mask(pdev, DMA_64BIT_MASK))) using_dac = 1; else if (!(err = pci_set_dma_mask(pdev, DMA_32BIT_MASK))) { - printk(KERN_ERR "%s no usable DMA configuration\n", + printk(KERN_ERR PFX "%s no usable DMA configuration\n", pci_name(pdev)); goto err_out_free_regions; } @@ -3155,7 +3155,7 @@ static int __devinit skge_probe(struct p err = -ENOMEM; hw = kmalloc(sizeof(*hw), GFP_KERNEL); if (!hw) { - printk(KERN_ERR "skge %s: cannot allocate hardware struct\n", + printk(KERN_ERR PFX "%s: cannot allocate hardware struct\n", pci_name(pdev)); goto err_out_free_regions; } @@ -3167,13 +3167,13 @@ static int __devinit skge_probe(struct p hw->regs = ioremap_nocache(pci_resource_start(pdev, 0), 0x4000); if (!hw->regs) { - printk(KERN_ERR "skge %s: cannot map device registers\n", + printk(KERN_ERR PFX "%s: cannot map device registers\n", pci_name(pdev)); goto err_out_free_hw; } if ((err = request_irq(pdev->irq, skge_intr, SA_SHIRQ, DRV_NAME, hw))) { - printk(KERN_ERR "%s: cannot assign irq %d\n", + printk(KERN_ERR PFX "%s: cannot assign irq %d\n", pci_name(pdev), pdev->irq); goto err_out_iounmap; } @@ -3194,7 +3194,7 @@ static int __devinit skge_probe(struct p dev->features |= NETIF_F_HIGHDMA; if ((err = register_netdev(dev))) { - printk(KERN_ERR "%s: cannot register net device\n", + printk(KERN_ERR PFX "%s: cannot register net device\n", pci_name(pdev)); goto err_out_free_netdev; } From shemminger@osdl.org Thu Mar 3 11:46:04 2005 Received: with ECARTIS (v1.0.0; list netdev); Thu, 03 Mar 2005 11:46:14 -0800 (PST) Received: from smtp.osdl.org (fire.osdl.org [65.172.181.4]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j23Jk1M1018351 for ; Thu, 3 Mar 2005 11:46:03 -0800 Received: from shell0.pdx.osdl.net (fw.osdl.org [65.172.181.6]) by smtp.osdl.org (8.12.8/8.12.8) with ESMTP id j23Jjrqi003421 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO); Thu, 3 Mar 2005 11:45:53 -0800 Received: from dxpl.pdx.osdl.net (dxpl.pdx.osdl.net [172.20.1.103]) by shell0.pdx.osdl.net (8.13.1/8.11.6) with ESMTP id j23JjrM1017844; Thu, 3 Mar 2005 11:45:53 -0800 Date: Thu, 3 Mar 2005 11:41:47 -0800 From: Stephen Hemminger To: Jeff Garzik Cc: netdev@oss.sgi.com Subject: [PATCH] (9/12) skge: interrupt coalecsing related fixes Message-ID: <20050303114147.1bc9ca1b@dxpl.pdx.osdl.net> Organization: Open Source Development Lab X-Mailer: Sylpheed-Claws 1.0.1 (GTK+ 1.2.10; x86_64-unknown-linux-gnu) X-Face: &@E+xe?c%:&e4D{>f1O<&U>2qwRREG5!}7R4;D<"NO^UI2mJ[eEOA2*3>(`Th.yP,VDPo9$ /`~cw![cmj~~jWe?AHY7D1S+\}5brN0k*NE?pPh_'_d>6;XGG[\KDRViCfumZT3@[ Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Received-SPF: pass (domain of shemminger@osdl.org designates 65.172.181.6 as permitted sender) X-MIMEDefang-Filter: osdl$Revision: 1.104 $ X-Scanned-By: MIMEDefang 2.36 X-Virus-Scanned: ClamAV 0.83/743/Wed Mar 2 16:02:05 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 2303 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 Avoid overflows (and 64 bit) in tha math for computing interrupt coalesce values. Turn on transmit coalescing by default. Signed-off-by: Stephen Hemminger --- skge-2.6.11/drivers/net/skge.c.orig 2005-03-03 10:22:43.000000000 -0800 +++ skge-2.6.11/drivers/net/skge.c 2005-03-03 10:26:58.000000000 -0800 @@ -553,14 +553,27 @@ return 0; } -static inline u32 skge_freq(const struct skge_hw *hw) +/* Chip internal frequency for clock calculations */ +static inline u32 hwkhz(const struct skge_hw *hw) { if (hw->chip_id == CHIP_ID_GENESIS) - return 53215000; /* or: 53.125 MHz */ + return 53215; /* or: 53.125 MHz */ else if (hw->chip_id == CHIP_ID_YUKON_EC) - return 125000000; /* or: 125.000 MHz */ + return 125000; /* or: 125.000 MHz */ else - return 78215000; /* or: 78.125 MHz */ + return 78215; /* or: 78.125 MHz */ +} + +/* Chip hz to microseconds */ +static inline u32 skge_clk2usec(const struct skge_hw *hw, u32 ticks) +{ + return (ticks * 1000) / hwkhz(hw); +} + +/* Microseconds to chip hz */ +static inline u32 skge_usecs2clk(const struct skge_hw *hw, u32 usec) +{ + return hwkhz(hw) * usec / 1000; } static int skge_get_coalesce(struct net_device *dev, @@ -574,14 +587,8 @@ ecmd->tx_coalesce_usecs = 0; if (skge_read32(hw, B2_IRQM_CTRL) & TIM_START) { - u32 msk; - u64 delay = skge_read32(hw, B2_IRQM_INI); - - pr_debug("irqm = %lld\n", delay); - delay *= USEC_PER_SEC; - - do_div(delay, skge_freq(hw)); - msk = skge_read32(hw, B2_IRQM_MSK); + u32 delay = skge_clk2usec(hw, skge_read32(hw, B2_IRQM_INI)); + u32 msk = skge_read32(hw, B2_IRQM_MSK); if (msk & rxirqmask[port]) ecmd->rx_coalesce_usecs = delay; @@ -626,10 +633,7 @@ if (msk == 0) skge_write32(hw, B2_IRQM_CTRL, TIM_STOP); else { - u64 ticks = (u64) delay * skge_freq(hw); - pr_debug("ticks * 10^6=%lld\n", ticks); - do_div(ticks, USEC_PER_SEC); - skge_write32(hw, B2_IRQM_INI, ticks); + skge_write32(hw, B2_IRQM_INI, skge_usecs2clk(hw, delay)); skge_write32(hw, B2_IRQM_CTRL, TIM_START); } return 0; @@ -3025,6 +3029,13 @@ skge_write32(hw, B0_HWE_IMSK, IS_ERR_MSK); + /* Set interrupt moderation for Transmit only + * Receive interrupts avoided by NAPI + */ + skge_write32(hw, B2_IRQM_MSK, IS_XA1_F|IS_XA2_F); + skge_write32(hw, B2_IRQM_INI, skge_usecs2clk(hw, 100)); + skge_write32(hw, B2_IRQM_CTRL, TIM_START); + hw->intr_mask = IS_HW_ERR | IS_EXT_REG | IS_PORT_1; if (isdualport(hw)) hw->intr_mask |= IS_PORT_2; From shemminger@osdl.org Thu Mar 3 11:46:12 2005 Received: with ECARTIS (v1.0.0; list netdev); Thu, 03 Mar 2005 11:46:21 -0800 (PST) Received: from smtp.osdl.org (fire.osdl.org [65.172.181.4]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j23JkApD018431 for ; Thu, 3 Mar 2005 11:46:11 -0800 Received: from shell0.pdx.osdl.net (fw.osdl.org [65.172.181.6]) by smtp.osdl.org (8.12.8/8.12.8) with ESMTP id j23Jjrqi003429 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO); Thu, 3 Mar 2005 11:45:53 -0800 Received: from dxpl.pdx.osdl.net (dxpl.pdx.osdl.net [172.20.1.103]) by shell0.pdx.osdl.net (8.13.1/8.11.6) with ESMTP id j23Jjrbv017856; Thu, 3 Mar 2005 11:45:53 -0800 Date: Thu, 3 Mar 2005 11:33:29 -0800 From: Stephen Hemminger To: Jeff Garzik Cc: netdev@oss.sgi.com Subject: [PATCH] (2/12) skge: spelling and whitespace Message-ID: <20050303113329.2a0171c3@dxpl.pdx.osdl.net> Organization: Open Source Development Lab X-Mailer: Sylpheed-Claws 1.0.1 (GTK+ 1.2.10; x86_64-unknown-linux-gnu) X-Face: &@E+xe?c%:&e4D{>f1O<&U>2qwRREG5!}7R4;D<"NO^UI2mJ[eEOA2*3>(`Th.yP,VDPo9$ /`~cw![cmj~~jWe?AHY7D1S+\}5brN0k*NE?pPh_'_d>6;XGG[\KDRViCfumZT3@[ Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Received-SPF: pass (domain of shemminger@osdl.org designates 65.172.181.6 as permitted sender) X-MIMEDefang-Filter: osdl$Revision: 1.104 $ X-Scanned-By: MIMEDefang 2.36 X-Virus-Scanned: ClamAV 0.83/743/Wed Mar 2 16:02:05 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 2305 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: shemminger@osdl.org Precedence: bulk X-list: netdev Fix spelling and whitespace issues Signed-off-by: Stephen Hemminger --- skge-2.6.11/drivers/net/skge.c.orig 2005-03-02 17:09:26.000000000 -0800 +++ skge-2.6.11/drivers/net/skge.c 2005-03-02 17:15:44.000000000 -0800 @@ -1,10 +1,10 @@ /* - * New driver for Marvell Yukon chipsent and SysKonnect Gigabit + * New driver for Marvell Yukon chipset and SysKonnect Gigabit * Ethernet adapters. Based on earlier sk98lin, e100 and - * Freebsd if_sk drivers. + * FreeBSD if_sk drivers. * * This driver intentionally does not support all the features - * of the original driver such as link failover and link management because + * of the original driver such as link fail-over and link management because * those should be done at higher levels. * * Copyright (C) 2004, Stephen Hemminger @@ -125,8 +125,7 @@ /* * Returns copy of control register region - * I/O region is divided into banks and certain regions - * are unreadable + * I/O region is divided into banks and certain regions are unreadable */ static void skge_get_regs(struct net_device *dev, struct ethtool_regs *regs, void *p) @@ -338,7 +337,7 @@ { "collisions", XM_TXF_SNG_COL, GM_TXF_SNG_COL }, { "multi_collisions", XM_TXF_MUL_COL, GM_TXF_MUL_COL }, - { "aborted", XM_TXF_ABO_COL, GM_TXF_ABO_COL}, + { "aborted", XM_TXF_ABO_COL, GM_TXF_ABO_COL }, { "late_collision", XM_TXF_LAT_COL, GM_TXF_LAT_COL }, { "fifo_underrun", XM_TXE_FIFO_UR, GM_TXE_FIFO_UR }, { "fifo_overflow", XM_RXE_FIFO_OV, GM_RXE_FIFO_OV }, From shemminger@osdl.org Thu Mar 3 11:46:17 2005 Received: with ECARTIS (v1.0.0; list netdev); Thu, 03 Mar 2005 11:46:33 -0800 (PST) Received: from smtp.osdl.org (fire.osdl.org [65.172.181.4]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j23JkEOO018460 for ; Thu, 3 Mar 2005 11:46:16 -0800 Received: from shell0.pdx.osdl.net (fw.osdl.org [65.172.181.6]) by smtp.osdl.org (8.12.8/8.12.8) with ESMTP id j23Jjrqi003431 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO); Thu, 3 Mar 2005 11:45:54 -0800 Received: from dxpl.pdx.osdl.net (dxpl.pdx.osdl.net [172.20.1.103]) by shell0.pdx.osdl.net (8.13.1/8.11.6) with ESMTP id j23JjrP9017859; Thu, 3 Mar 2005 11:45:53 -0800 Date: Thu, 3 Mar 2005 11:34:13 -0800 From: Stephen Hemminger To: Jeff Garzik Cc: netdev@oss.sgi.com Subject: [PATCH] (3/12) skge: remove unneeded include's Message-ID: <20050303113413.1bcd7476@dxpl.pdx.osdl.net> Organization: Open Source Development Lab X-Mailer: Sylpheed-Claws 1.0.1 (GTK+ 1.2.10; x86_64-unknown-linux-gnu) X-Face: &@E+xe?c%:&e4D{>f1O<&U>2qwRREG5!}7R4;D<"NO^UI2mJ[eEOA2*3>(`Th.yP,VDPo9$ /`~cw![cmj~~jWe?AHY7D1S+\}5brN0k*NE?pPh_'_d>6;XGG[\KDRViCfumZT3@[ Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Received-SPF: pass (domain of shemminger@osdl.org designates 65.172.181.6 as permitted sender) X-MIMEDefang-Filter: osdl$Revision: 1.104 $ X-Scanned-By: MIMEDefang 2.36 X-Virus-Scanned: ClamAV 0.83/743/Wed Mar 2 16:02:05 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 2308 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: shemminger@osdl.org Precedence: bulk X-list: netdev Get rid of unnecessary include's Signed-off-by: Stephen Hemminger --- skge-2.6.11/drivers/net/skge.c.orig 2005-03-02 17:15:44.000000000 -0800 +++ skge-2.6.11/drivers/net/skge.c 2005-03-02 17:17:25.000000000 -0800 @@ -30,13 +30,10 @@ #include #include #include -#include #include #include #include #include -#include -#include #include #include #include From shemminger@osdl.org Thu Mar 3 11:46:17 2005 Received: with ECARTIS (v1.0.0; list netdev); Thu, 03 Mar 2005 11:46:33 -0800 (PST) Received: from smtp.osdl.org (fire.osdl.org [65.172.181.4]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j23JkFGF018465 for ; Thu, 3 Mar 2005 11:46:16 -0800 Received: from shell0.pdx.osdl.net (fw.osdl.org [65.172.181.6]) by smtp.osdl.org (8.12.8/8.12.8) with ESMTP id j23Jjrqi003433 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO); Thu, 3 Mar 2005 11:45:55 -0800 Received: from dxpl.pdx.osdl.net (dxpl.pdx.osdl.net [172.20.1.103]) by shell0.pdx.osdl.net (8.13.1/8.11.6) with ESMTP id j23JjrD2017862; Thu, 3 Mar 2005 11:45:53 -0800 Date: Thu, 3 Mar 2005 11:35:43 -0800 From: Stephen Hemminger To: Jeff Garzik Cc: netdev@oss.sgi.com Subject: [PATCH] (4/12) skge: suspend/resume related state management Message-ID: <20050303113543.72ba7dbf@dxpl.pdx.osdl.net> Organization: Open Source Development Lab X-Mailer: Sylpheed-Claws 1.0.1 (GTK+ 1.2.10; x86_64-unknown-linux-gnu) X-Face: &@E+xe?c%:&e4D{>f1O<&U>2qwRREG5!}7R4;D<"NO^UI2mJ[eEOA2*3>(`Th.yP,VDPo9$ /`~cw![cmj~~jWe?AHY7D1S+\}5brN0k*NE?pPh_'_d>6;XGG[\KDRViCfumZT3@[ Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Received-SPF: pass (domain of shemminger@osdl.org designates 65.172.181.6 as permitted sender) X-MIMEDefang-Filter: osdl$Revision: 1.104 $ X-Scanned-By: MIMEDefang 2.36 X-Virus-Scanned: ClamAV 0.83/743/Wed Mar 2 16:02:05 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 2307 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: shemminger@osdl.org Precedence: bulk X-list: netdev Fix suspend/resume logic. On suspend, shutdown board if it is already up, and on resume only bring it up if it was up before the suspend Signed-off-by: Stephen Hemminger --- skge-2.6.11/drivers/net/skge.c.orig 2005-03-02 17:17:25.000000000 -0800 +++ skge-2.6.11/drivers/net/skge.c 2005-03-02 17:21:40.000000000 -0800 @@ -3268,11 +3268,12 @@ for(i = 0; i < 2; i++) { struct net_device *dev = hw->dev[i]; - if (dev && netif_running(dev)) { + if (dev) { struct skge_port *skge = netdev_priv(dev); - - netif_carrier_off(dev); - skge_down(dev); + if (netif_running(dev)) { + netif_carrier_off(dev); + skge_down(dev); + } netif_device_detach(dev); wol |= skge->wol; } @@ -3293,13 +3294,17 @@ pci_set_power_state(pdev, PCI_D0); pci_restore_state(pdev); + pci_enable_wake(pdev, PCI_D0, 0); skge_reset(hw); for(i = 0; i < 2; i++) { struct net_device *dev = hw->dev[i]; - if (dev && netif_running(dev)) - skge_up(dev); + if (dev) { + netif_device_attach(dev); + if(netif_running(dev)) + skge_up(dev); + } } return 0; } From shemminger@osdl.org Thu Mar 3 11:46:16 2005 Received: with ECARTIS (v1.0.0; list netdev); Thu, 03 Mar 2005 11:46:32 -0800 (PST) Received: from smtp.osdl.org (fire.osdl.org [65.172.181.4]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j23JkD8m018455 for ; Thu, 3 Mar 2005 11:46:15 -0800 Received: from shell0.pdx.osdl.net (fw.osdl.org [65.172.181.6]) by smtp.osdl.org (8.12.8/8.12.8) with ESMTP id j23Jjsqi003435 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO); Thu, 3 Mar 2005 11:45:55 -0800 Received: from dxpl.pdx.osdl.net (dxpl.pdx.osdl.net [172.20.1.103]) by shell0.pdx.osdl.net (8.13.1/8.11.6) with ESMTP id j23JjrjJ017865; Thu, 3 Mar 2005 11:45:53 -0800 Date: Thu, 3 Mar 2005 11:36:46 -0800 From: Stephen Hemminger To: Jeff Garzik Cc: netdev@oss.sgi.com Subject: [PATCH] (5/12) skge: simplify definition of wake on lan support Message-ID: <20050303113646.0872b57a@dxpl.pdx.osdl.net> Organization: Open Source Development Lab X-Mailer: Sylpheed-Claws 1.0.1 (GTK+ 1.2.10; x86_64-unknown-linux-gnu) X-Face: &@E+xe?c%:&e4D{>f1O<&U>2qwRREG5!}7R4;D<"NO^UI2mJ[eEOA2*3>(`Th.yP,VDPo9$ /`~cw![cmj~~jWe?AHY7D1S+\}5brN0k*NE?pPh_'_d>6;XGG[\KDRViCfumZT3@[ Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Received-SPF: pass (domain of shemminger@osdl.org designates 65.172.181.6 as permitted sender) X-MIMEDefang-Filter: osdl$Revision: 1.104 $ X-Scanned-By: MIMEDefang 2.36 X-Virus-Scanned: ClamAV 0.83/743/Wed Mar 2 16:02:05 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 2306 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: shemminger@osdl.org Precedence: bulk X-list: netdev Add a simple encapsulation of wake on lan support predicate. Signed-off-by: Stephen Hemminger --- skge-2.6.11/drivers/net/skge.c.orig 2005-03-02 17:22:30.000000000 -0800 +++ skge-2.6.11/drivers/net/skge.c 2005-03-02 17:24:23.000000000 -0800 @@ -147,17 +147,18 @@ } } +/* Wake on Lan only supported on Yukon chps with rev 1 or above */ +static int wol_supported(const struct skge_hw *hw) +{ + return !((hw->chip_id == CHIP_ID_GENESIS || + (hw->chip_id == CHIP_ID_YUKON && chip_rev(hw) == 0))); +} static void skge_get_wol(struct net_device *dev, struct ethtool_wolinfo *wol) { struct skge_port *skge = netdev_priv(dev); - struct skge_hw *hw = skge->hw; - if (hw->chip_id == CHIP_ID_GENESIS || - (hw->chip_id == CHIP_ID_YUKON && chip_rev(hw) == 0)) - wol->supported = 0; - else - wol->supported = WAKE_MAGIC; + wol->supported = wol_supported(skge->hw) ? WAKE_MAGIC : 0; wol->wolopts = skge->wol ? WAKE_MAGIC : 0; } @@ -169,9 +170,7 @@ if(wol->wolopts != WAKE_MAGIC && wol->wolopts != 0) return -EOPNOTSUPP; - if (wol->wolopts == WAKE_MAGIC && - ((hw->chip_id == CHIP_ID_GENESIS || - (hw->chip_id == CHIP_ID_YUKON && chip_rev(hw) == 0)))) + if (wol->wolopts == WAKE_MAGIC && !wol_supported(hw)) return -EOPNOTSUPP; skge->wol = wol->wolopts == WAKE_MAGIC; From shemminger@osdl.org Thu Mar 3 11:46:18 2005 Received: with ECARTIS (v1.0.0; list netdev); Thu, 03 Mar 2005 11:46:35 -0800 (PST) Received: from smtp.osdl.org (fire.osdl.org [65.172.181.4]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j23JkGMj018477 for ; Thu, 3 Mar 2005 11:46:17 -0800 Received: from shell0.pdx.osdl.net (fw.osdl.org [65.172.181.6]) by smtp.osdl.org (8.12.8/8.12.8) with ESMTP id j23Jjsqi003439 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO); Thu, 3 Mar 2005 11:45:55 -0800 Received: from dxpl.pdx.osdl.net (dxpl.pdx.osdl.net [172.20.1.103]) by shell0.pdx.osdl.net (8.13.1/8.11.6) with ESMTP id j23JjsOU017871; Thu, 3 Mar 2005 11:45:54 -0800 Date: Thu, 3 Mar 2005 11:38:25 -0800 From: Stephen Hemminger To: Jeff Garzik Cc: netdev@oss.sgi.com Subject: [PATCH] (7/12) skge: use array for port irq masks Message-ID: <20050303113825.10fcc6dc@dxpl.pdx.osdl.net> Organization: Open Source Development Lab X-Mailer: Sylpheed-Claws 1.0.1 (GTK+ 1.2.10; x86_64-unknown-linux-gnu) X-Face: &@E+xe?c%:&e4D{>f1O<&U>2qwRREG5!}7R4;D<"NO^UI2mJ[eEOA2*3>(`Th.yP,VDPo9$ /`~cw![cmj~~jWe?AHY7D1S+\}5brN0k*NE?pPh_'_d>6;XGG[\KDRViCfumZT3@[ Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Received-SPF: pass (domain of shemminger@osdl.org designates 65.172.181.6 as permitted sender) X-MIMEDefang-Filter: osdl$Revision: 1.104 $ X-Scanned-By: MIMEDefang 2.36 X-Virus-Scanned: ClamAV 0.83/743/Wed Mar 2 16:02:05 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 2311 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 Use array to represent the transmit and recieve irqmask per port. And rename txq to txqaddr to be more descriptive Signed-off-by: Stephen Hemminger --- skge-2.6.11/drivers/net/skge.c.orig 2005-03-02 17:39:20.000000000 -0800 +++ skge-2.6.11/drivers/net/skge.c 2005-03-03 09:40:43.000000000 -0800 @@ -107,8 +107,10 @@ static void genesis_mac_init(struct skge_hw *hw, int port); static void genesis_reset(struct skge_hw *hw, int port); -static const int txq[] = { Q_XA1, Q_XA2 }; -static const int rxq[] = { Q_R1, Q_R2 }; +static const int txqaddr[] = { Q_XA1, Q_XA2 }; +static const int rxqaddr[] = { Q_R1, Q_R2 }; +static const u32 rxirqmask[] = { IS_R1_F, IS_R2_F }; +static const u32 txirqmask[] = { IS_XA1_F, IS_XA2_F }; /* Don't need to look at whole 16K. * last interesting register is descriptor poll timer. @@ -568,11 +570,9 @@ do_div(delay, skge_freq(hw)); msk = skge_read32(hw, B2_IRQM_MSK); - if (((port == 0) && (msk & IS_R1_F)) || - ((port == 1) && (msk & IS_R2_F))) + if (msk & rxirqmask[port]) ecmd->rx_coalesce_usecs = delay; - if (((port == 0) && (msk & IS_XA1_F)) || - ((port == 1) && (msk & IS_XA1_F))) + if (msk & txirqmask[port]) ecmd->tx_coalesce_usecs = delay; } @@ -590,22 +590,22 @@ u32 delay = 25; if (ecmd->rx_coalesce_usecs == 0) - msk &= ~(port == 0 ? IS_R1_F : IS_R2_F); + msk &= ~rxirqmask[port]; else if (ecmd->rx_coalesce_usecs < 25 || ecmd->rx_coalesce_usecs > 33333) return -EINVAL; else { - msk |= port == 0 ? IS_R1_F : IS_R2_F; + msk |= rxirqmask[port]; delay = ecmd->rx_coalesce_usecs; } if (ecmd->tx_coalesce_usecs == 0) - msk &= ~((port == 0) ? IS_XA1_F : IS_XA2_F); + msk &= ~txirqmask[port]; else if (ecmd->tx_coalesce_usecs < 25 || ecmd->tx_coalesce_usecs > 33333) return -EINVAL; else { - msk |= (port == 0) ? IS_XA1_F : IS_XA2_F; + msk |= txirqmask[port]; delay = min(delay, ecmd->rx_coalesce_usecs); } @@ -2174,16 +2174,16 @@ chunk = hw->ram_size / (isdualport(hw) ? 4 : 2); ram_addr = hw->ram_offset + 2 * chunk * port; - skge_ramset(hw, rxq[port], ram_addr, chunk); - skge_qset(skge, rxq[port], skge->rx_ring.to_clean); + skge_ramset(hw, rxqaddr[port], ram_addr, chunk); + skge_qset(skge, rxqaddr[port], skge->rx_ring.to_clean); BUG_ON(skge->tx_ring.to_use != skge->tx_ring.to_clean); - skge_ramset(hw, txq[port], ram_addr+chunk, chunk); - skge_qset(skge, txq[port], skge->tx_ring.to_use); + skge_ramset(hw, txqaddr[port], ram_addr+chunk, chunk); + skge_qset(skge, txqaddr[port], skge->tx_ring.to_use); /* Start receiver BMU */ wmb(); - skge_write8(hw, Q_ADDR(rxq[port], Q_CSR), CSR_START | CSR_IRQ_CL_F); + skge_write8(hw, Q_ADDR(rxqaddr[port], Q_CSR), CSR_START | CSR_IRQ_CL_F); pr_debug("skge_up completed\n"); return 0; @@ -2212,8 +2212,8 @@ del_timer_sync(&skge->link_check); /* Stop transmitter */ - skge_write8(hw, Q_ADDR(txq[port], Q_CSR), CSR_STOP); - skge_write32(hw, RB_ADDR(txq[port], RB_CTRL), + skge_write8(hw, Q_ADDR(txqaddr[port], Q_CSR), CSR_STOP); + skge_write32(hw, RB_ADDR(txqaddr[port], RB_CTRL), RB_RST_SET|RB_DIS_OP_MD); if (hw->chip_id == CHIP_ID_GENESIS) @@ -2230,16 +2230,16 @@ skge_write32(hw, SKGEMAC_REG(port, TXA_LIM_INI), 0L); /* Reset PCI FIFO */ - skge_write32(hw, Q_ADDR(txq[port], Q_CSR), CSR_SET_RESET); - skge_write32(hw, RB_ADDR(txq[port], RB_CTRL), RB_RST_SET); + skge_write32(hw, Q_ADDR(txqaddr[port], Q_CSR), CSR_SET_RESET); + skge_write32(hw, RB_ADDR(txqaddr[port], RB_CTRL), RB_RST_SET); /* Reset the RAM Buffer async Tx queue */ skge_write8(hw, RB_ADDR(port == 0 ? Q_XA1 : Q_XA2, RB_CTRL), RB_RST_SET); /* stop receiver */ - skge_write8(hw, Q_ADDR(rxq[port], Q_CSR), CSR_STOP); + skge_write8(hw, Q_ADDR(rxqaddr[port], Q_CSR), CSR_STOP); skge_write32(hw, RB_ADDR(port ? Q_R2 : Q_R1, RB_CTRL), RB_RST_SET|RB_DIS_OP_MD); - skge_write32(hw, Q_ADDR(rxq[port], Q_CSR), CSR_SET_RESET); + skge_write32(hw, Q_ADDR(rxqaddr[port], Q_CSR), CSR_SET_RESET); if (hw->chip_id == CHIP_ID_GENESIS) { skge_write8(hw, SKGEMAC_REG(port, TX_MFF_CTRL2), MFF_RST_SET); @@ -2348,7 +2348,7 @@ td->control = BMU_OWN | BMU_SW | BMU_STF | control | len; wmb(); - skge_write8(hw, Q_ADDR(txq[skge->port], Q_CSR), CSR_START); + skge_write8(hw, Q_ADDR(txqaddr[skge->port], Q_CSR), CSR_START); if (netif_msg_tx_queued(skge)) printk(KERN_DEBUG "%s: tx queued, slot %d, len %d\n", @@ -2406,7 +2406,7 @@ if (netif_msg_timer(skge)) printk(KERN_DEBUG PFX "%s: tx timeout\n", dev->name); - skge_write8(skge->hw, Q_ADDR(txq[skge->port], Q_CSR), CSR_STOP); + skge_write8(skge->hw, Q_ADDR(txqaddr[skge->port], Q_CSR), CSR_STOP); skge_tx_clean(skge); } @@ -2609,7 +2609,7 @@ /* restart receiver */ wmb(); - skge_write8(hw, Q_ADDR(rxq[skge->port], Q_CSR), + skge_write8(hw, Q_ADDR(rxqaddr[skge->port], Q_CSR), CSR_START | CSR_IRQ_CL_F); if (done) { @@ -2650,7 +2650,7 @@ ++skge->tx_avail; } ring->to_clean = e; - skge_write8(hw, Q_ADDR(txq[skge->port], Q_CSR), CSR_IRQ_CL_F); + skge_write8(hw, Q_ADDR(txqaddr[skge->port], Q_CSR), CSR_IRQ_CL_F); if (skge->tx_avail > MAX_SKB_FRAGS + 1) netif_wake_queue(dev); From shemminger@osdl.org Thu Mar 3 11:46:17 2005 Received: with ECARTIS (v1.0.0; list netdev); Thu, 03 Mar 2005 11:46:34 -0800 (PST) Received: from smtp.osdl.org (fire.osdl.org [65.172.181.4]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j23JkFWF018471 for ; Thu, 3 Mar 2005 11:46:16 -0800 Received: from shell0.pdx.osdl.net (fw.osdl.org [65.172.181.6]) by smtp.osdl.org (8.12.8/8.12.8) with ESMTP id j23Jjrqi003425 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO); Thu, 3 Mar 2005 11:45:54 -0800 Received: from dxpl.pdx.osdl.net (dxpl.pdx.osdl.net [172.20.1.103]) by shell0.pdx.osdl.net (8.13.1/8.11.6) with ESMTP id j23JjrGc017850; Thu, 3 Mar 2005 11:45:53 -0800 Date: Thu, 3 Mar 2005 11:44:21 -0800 From: Stephen Hemminger To: Jeff Garzik Cc: netdev@oss.sgi.com Subject: [PATCH] (11/12) skge: fix race with receive interrupt and NAPI Message-ID: <20050303114421.5ce264b6@dxpl.pdx.osdl.net> Organization: Open Source Development Lab X-Mailer: Sylpheed-Claws 1.0.1 (GTK+ 1.2.10; x86_64-unknown-linux-gnu) X-Face: &@E+xe?c%:&e4D{>f1O<&U>2qwRREG5!}7R4;D<"NO^UI2mJ[eEOA2*3>(`Th.yP,VDPo9$ /`~cw![cmj~~jWe?AHY7D1S+\}5brN0k*NE?pPh_'_d>6;XGG[\KDRViCfumZT3@[ Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Received-SPF: pass (domain of shemminger@osdl.org designates 65.172.181.6 as permitted sender) X-MIMEDefang-Filter: osdl$Revision: 1.104 $ X-Scanned-By: MIMEDefang 2.36 X-Virus-Scanned: ClamAV 0.83/743/Wed Mar 2 16:02:05 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 2309 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 Avoid possible race with receive interrupt and NAPI. Move code for chip specific mac interrupt out of main path. Signed-off-by: Stephen Hemminger --- skge-2.6.11/drivers/net/skge.c.orig 2005-03-03 10:30:59.000000000 -0800 +++ skge-2.6.11/drivers/net/skge.c 2005-03-03 10:32:58.000000000 -0800 @@ -2709,6 +2709,14 @@ skge_write8(hw, B2_TST_CTRL1, TST_CFG_WRITE_OFF); } +static void skge_mac_intr(struct skge_hw *hw, int port) +{ + if (hw->chip_id == CHIP_ID_GENESIS) + genesis_mac_intr(hw, port); + else + yukon_mac_intr(hw, port); +} + /* Handle device specific framing and timeout interrupts */ static void skge_error_irq(struct skge_hw *hw) { @@ -2816,14 +2824,18 @@ status &= hw->intr_mask; - if (status & IS_R1_F) { + if ((status & IS_R1_F) && netif_rx_schedule_prep(hw->dev[0])) { + status &= ~IS_R1_F; hw->intr_mask &= ~IS_R1_F; - netif_rx_schedule(hw->dev[0]); + skge_write32(hw, B0_IMSK, hw->intr_mask); + __netif_rx_schedule(hw->dev[0]); } - if (status & IS_R2_F) { + if ((status & IS_R2_F) && netif_rx_schedule_prep(hw->dev[1])) { + status &= ~IS_R2_F; hw->intr_mask &= ~IS_R2_F; - netif_rx_schedule(hw->dev[1]); + skge_write32(hw, B0_IMSK, hw->intr_mask); + __netif_rx_schedule(hw->dev[1]); } if (status & IS_XA1_F) @@ -2832,19 +2844,11 @@ if (status & IS_XA2_F) skge_tx_intr(hw->dev[1]); - if (hw->chip_id == CHIP_ID_GENESIS) { - if (status & IS_MAC1) - genesis_mac_intr(hw, 0); - - if (status & IS_MAC2) - genesis_mac_intr(hw, 1); - } else { - if (status & IS_MAC1) - yukon_mac_intr(hw, 0); - - if (status & IS_MAC2) - yukon_mac_intr(hw, 1); - } + if (status & IS_MAC1) + skge_mac_intr(hw, 0); + + if (status & IS_MAC2) + skge_mac_intr(hw, 1); if (status & IS_HW_ERR) skge_error_irq(hw); @@ -2853,7 +2857,9 @@ hw->intr_mask &= ~IS_EXT_REG; tasklet_schedule(&hw->ext_tasklet); } - skge_write32(hw, B0_IMSK, hw->intr_mask); + + if (status) + skge_write32(hw, B0_IMSK, hw->intr_mask); return IRQ_HANDLED; } From shemminger@osdl.org Thu Mar 3 11:46:18 2005 Received: with ECARTIS (v1.0.0; list netdev); Thu, 03 Mar 2005 11:46:34 -0800 (PST) Received: from smtp.osdl.org (fire.osdl.org [65.172.181.4]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j23JkFO8018472 for ; Thu, 3 Mar 2005 11:46:17 -0800 Received: from shell0.pdx.osdl.net (fw.osdl.org [65.172.181.6]) by smtp.osdl.org (8.12.8/8.12.8) with ESMTP id j23Jjsqi003436 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO); Thu, 3 Mar 2005 11:45:55 -0800 Received: from dxpl.pdx.osdl.net (dxpl.pdx.osdl.net [172.20.1.103]) by shell0.pdx.osdl.net (8.13.1/8.11.6) with ESMTP id j23Jjrmg017868; Thu, 3 Mar 2005 11:45:53 -0800 Date: Thu, 3 Mar 2005 11:37:40 -0800 From: Stephen Hemminger To: Jeff Garzik Cc: netdev@oss.sgi.com Subject: [PATCH] (6/12) skge: use chip MIB stats for packet and byte counts Message-ID: <20050303113740.692bf69e@dxpl.pdx.osdl.net> Organization: Open Source Development Lab X-Mailer: Sylpheed-Claws 1.0.1 (GTK+ 1.2.10; x86_64-unknown-linux-gnu) X-Face: &@E+xe?c%:&e4D{>f1O<&U>2qwRREG5!}7R4;D<"NO^UI2mJ[eEOA2*3>(`Th.yP,VDPo9$ /`~cw![cmj~~jWe?AHY7D1S+\}5brN0k*NE?pPh_'_d>6;XGG[\KDRViCfumZT3@[ Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Received-SPF: pass (domain of shemminger@osdl.org designates 65.172.181.6 as permitted sender) X-MIMEDefang-Filter: osdl$Revision: 1.104 $ X-Scanned-By: MIMEDefang 2.36 X-Virus-Scanned: ClamAV 0.83/743/Wed Mar 2 16:02:05 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 2310 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 Use the chip MIB statistics to implement the packet and byte counts. Signed-off-by: Stephen Hemminger --- skge-2.6.11/drivers/net/skge.c.orig 2005-03-02 17:25:25.000000000 -0800 +++ skge-2.6.11/drivers/net/skge.c 2005-03-02 17:29:30.000000000 -0800 @@ -361,6 +361,31 @@ yukon_get_stats(skge, data); } +/* Use hardware MIB variables for critical path statistics and + * transmit feedback not reported at interrupt. + * Other errors are accounted for in interrupt handler. + */ +static struct net_device_stats *skge_get_stats(struct net_device *dev) +{ + struct skge_port *skge = netdev_priv(dev); + u64 data[ARRAY_SIZE(skge_stats)]; + + if (skge->hw->chip_id == CHIP_ID_GENESIS) + genesis_get_stats(skge, data); + else + yukon_get_stats(skge, data); + + skge->net_stats.tx_bytes = data[0]; + skge->net_stats.rx_bytes = data[1]; + skge->net_stats.tx_packets = data[2] + data[4] + data[6]; + skge->net_stats.rx_packets = data[3] + data[5] + data[7]; + skge->net_stats.multicast = data[5] + data[7]; + skge->net_stats.collisions = data[10]; + skge->net_stats.tx_aborted_errors = data[12]; + + return &skge->net_stats; +} + static void skge_get_strings(struct net_device *dev, u32 stringset, u8 *data) { int i; @@ -2336,9 +2361,6 @@ netif_stop_queue(dev); } - skge->net_stats.tx_packets++; - skge->net_stats.tx_bytes += skb->len; - dev->trans_start = jiffies; spin_unlock_irqrestore(&skge->tx_lock, flags); @@ -2572,8 +2594,6 @@ } dev->last_rx = jiffies; - skge->net_stats.rx_packets++; - skge->net_stats.rx_bytes += skb->len; netif_receive_skb(skb); ++work_done; @@ -2825,15 +2845,6 @@ } #endif -/* TODO: use MIB counters instead?? */ -static struct net_device_stats *skge_get_stats(struct net_device *dev) -{ - struct skge_port *skge = netdev_priv(dev); - - return &skge->net_stats; -} - - static int skge_set_mac_address(struct net_device *dev, void *p) { struct skge_port *skge = netdev_priv(dev); From dsd@gentoo.org Thu Mar 3 12:18:49 2005 Received: with ECARTIS (v1.0.0; list netdev); Thu, 03 Mar 2005 12:18:52 -0800 (PST) Received: from curlew.cs.man.ac.uk (curlew.cs.man.ac.uk [130.88.13.7]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j23KImvP026541 for ; Thu, 3 Mar 2005 12:18:49 -0800 Received: from rp015a.halls.manchester.ac.uk ([130.88.180.15]) by curlew.cs.man.ac.uk with esmtp (Exim 4.20) id 1D6wmU-000Giv-7V; Thu, 03 Mar 2005 20:18:46 +0000 Message-ID: <42277195.8@gentoo.org> Date: Thu, 03 Mar 2005 20:20:37 +0000 From: Daniel Drake User-Agent: Mozilla Thunderbird 1.0 (X11/20041209) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Jeff Garzik CC: Netdev , Linux Kernel , Andrew Morton , philipp.gortan@tttech.com Subject: Re: netdev-2.6 queue updated References: <4226BD3B.9080604@pobox.com> In-Reply-To: <4226BD3B.9080604@pobox.com> X-Enigmail-Version: 0.89.5.0 X-Enigmail-Supports: pgp-inline, pgp-mime Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Scanner: exiscan for exim4 (http://duncanthrax.net/exiscan/) *1D6wmU-000Giv-7V*SsS820ehW9w* X-Virus-Scanned: ClamAV 0.83/743/Wed Mar 2 16:02:05 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 2312 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: dsd@gentoo.org Precedence: bulk X-list: netdev Jeff Garzik wrote: > : > o [netdrvr 8139cp] add PCI ID This one seems to be already present in 2.6.11 under a different name (PCI_DEVICE_ID_TTTECH_MC322). Also, the corresponding entry in pci_ids.h is not in the order of the file. Daniel From shemminger@osdl.org Thu Mar 3 12:38:13 2005 Received: with ECARTIS (v1.0.0; list netdev); Thu, 03 Mar 2005 12:38:17 -0800 (PST) Received: from smtp.osdl.org (fire.osdl.org [65.172.181.4]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j23KcCl6031251 for ; Thu, 3 Mar 2005 12:38:12 -0800 Received: from shell0.pdx.osdl.net (fw.osdl.org [65.172.181.6]) by smtp.osdl.org (8.12.8/8.12.8) with ESMTP id j23Kbuqi008089 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO); Thu, 3 Mar 2005 12:37:56 -0800 Received: from dxpl.pdx.osdl.net (dxpl.pdx.osdl.net [172.20.1.103]) by shell0.pdx.osdl.net (8.13.1/8.11.6) with ESMTP id j23Kbt9o020530; Thu, 3 Mar 2005 12:37:55 -0800 Date: Thu, 3 Mar 2005 12:38:11 -0800 From: Stephen Hemminger To: Injong Rhee , John Heffner , "David S. Miller" , Yee-Ting Li , Baruch Even Cc: netdev@oss.sgi.com Subject: netif_rx packet dumping Message-ID: <20050303123811.4d934249@dxpl.pdx.osdl.net> Organization: Open Source Development Lab X-Mailer: Sylpheed-Claws 1.0.1 (GTK+ 1.2.10; x86_64-unknown-linux-gnu) X-Face: &@E+xe?c%:&e4D{>f1O<&U>2qwRREG5!}7R4;D<"NO^UI2mJ[eEOA2*3>(`Th.yP,VDPo9$ /`~cw![cmj~~jWe?AHY7D1S+\}5brN0k*NE?pPh_'_d>6;XGG[\KDRViCfumZT3@[ Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Received-SPF: pass (domain of shemminger@osdl.org designates 65.172.181.6 as permitted sender) X-MIMEDefang-Filter: osdl$Revision: 1.104 $ X-Scanned-By: MIMEDefang 2.36 X-Virus-Scanned: ClamAV 0.83/743/Wed Mar 2 16:02:05 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 2313 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 Both BIC TCP 1.1 and TCP-H include patches to disable the queue throttling behaviour of netif_rx. The existing throttling algorithm causes all packets to be dumped (until queue emptys) when the packet backlog reaches netdev_max_backog. I suppose this is some kind of DoS prevention mechanism. The problem is that this dumping action creates mulitple packet loss that forces TCP back to slow start. But, all this is really moot for the case of any reasonably high speed device because of NAPI. netif_rx is not even used for any device that uses NAPI. The NAPI code path uses net_receive_skb and the receive queue management is done by the receive scheduling (dev->quota) of the rx_scheduler. My question is why did BIC TCP and TCP-H turn off the throttling? Was it because they were/are using older 2.4 devices without NAPI. From mpm@selenic.com Thu Mar 3 12:46:41 2005 Received: with ECARTIS (v1.0.0; list netdev); Thu, 03 Mar 2005 12:46:57 -0800 (PST) Received: from waste.org (waste.org [216.27.176.166]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j23KkevB031969 for ; Thu, 3 Mar 2005 12:46:40 -0800 Received: from moop (mail@[10.0.0.2]) by waste.org (8.13.2/8.13.2/Debian-1) with ESMTP id j23KkVm1001603; Thu, 3 Mar 2005 14:46:31 -0600 Received: from moop ([127.0.0.1] ident=oxymoron) by moop with esmtp (Exim 3.36 #1 (Debian)) id 1D6xDL-0003OF-03; Thu, 03 Mar 2005 14:46:31 -0600 From: Matt Mackall To: Jeff Garzik X-PatchBomber: http://selenic.com/scripts/mailpatches Cc: netdev@oss.sgi.com, Jeff Moyer In-Reply-To: <3.454130102@selenic.com> Message-Id: <4.454130102@selenic.com> Subject: [PATCH 3/7] netpoll: add netpoll point to net_device Date: Thu, 03 Mar 2005 14:46:31 -0600 X-Virus-Scanned: ClamAV 0.83/743/Wed Mar 2 16:02:05 2005 on oss.sgi.com X-Virus-Scanned: by amavisd-new X-Virus-Status: Clean X-archive-position: 2318 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: mpm@selenic.com Precedence: bulk X-list: netdev Add struct netpoll pointer to struct netdevice Move netpoll rx flags to netpoll struct Stop traversing rx_list and get np pointer from skb->dev->np Remove now unneeded rx_list Signed-off-by: Matt Mackall Index: rc4/include/linux/netdevice.h =================================================================== --- rc4.orig/include/linux/netdevice.h 2005-02-17 22:32:12.000000000 -0600 +++ rc4/include/linux/netdevice.h 2005-02-17 22:32:20.000000000 -0600 @@ -41,7 +41,7 @@ struct divert_blk; struct vlan_group; struct ethtool_ops; - +struct netpoll; /* source back-compat hooks */ #define SET_ETHTOOL_OPS(netdev,ops) \ ( (netdev)->ethtool_ops = (ops) ) @@ -471,7 +471,7 @@ int (*neigh_setup)(struct net_device *dev, struct neigh_parms *); int (*accept_fastpath)(struct net_device *, struct dst_entry*); #ifdef CONFIG_NETPOLL - int netpoll_rx; + struct netpoll *np; #endif #ifdef CONFIG_NET_POLL_CONTROLLER void (*poll_controller)(struct net_device *dev); Index: rc4/net/core/netpoll.c =================================================================== --- rc4.orig/net/core/netpoll.c 2005-02-17 22:32:19.000000000 -0600 +++ rc4/net/core/netpoll.c 2005-02-17 22:39:59.000000000 -0600 @@ -35,9 +35,6 @@ static int nr_skbs; static struct sk_buff *skbs; -static DEFINE_SPINLOCK(rx_list_lock); -static LIST_HEAD(rx_list); - static atomic_t trapped; static DEFINE_SPINLOCK(netpoll_poll_lock); @@ -84,13 +81,13 @@ queue = &__get_cpu_var(softnet_data); if (test_bit(__LINK_STATE_RX_SCHED, &np->dev->state) && !list_empty(&queue->poll_list)) { - np->dev->netpoll_rx |= NETPOLL_RX_DROP; + np->rx_flags |= NETPOLL_RX_DROP; atomic_inc(&trapped); np->dev->poll(np->dev, &budget); atomic_dec(&trapped); - np->dev->netpoll_rx &= ~NETPOLL_RX_DROP; + np->rx_flags &= ~NETPOLL_RX_DROP; } spin_unlock_irqrestore(&netpoll_poll_lock, flags); } @@ -279,18 +276,7 @@ int size, type = ARPOP_REPLY, ptype = ETH_P_ARP; u32 sip, tip; struct sk_buff *send_skb; - unsigned long flags; - struct list_head *p; - struct netpoll *np = NULL; - - spin_lock_irqsave(&rx_list_lock, flags); - list_for_each(p, &rx_list) { - np = list_entry(p, struct netpoll, rx_list); - if ( np->dev == skb->dev ) - break; - np = NULL; - } - spin_unlock_irqrestore(&rx_list_lock, flags); + struct netpoll *np = skb->dev->np; if (!np) return; @@ -373,10 +359,10 @@ int proto, len, ulen; struct iphdr *iph; struct udphdr *uh; - struct netpoll *np; - struct list_head *p; - unsigned long flags; + struct netpoll *np = skb->dev->np; + if (!np->rx_hook) + goto out; if (skb->dev->type != ARPHRD_ETHER) goto out; @@ -420,30 +406,19 @@ goto out; if (checksum_udp(skb, uh, ulen, iph->saddr, iph->daddr) < 0) goto out; + if (np->local_ip && np->local_ip != ntohl(iph->daddr)) + goto out; + if (np->remote_ip && np->remote_ip != ntohl(iph->saddr)) + goto out; + if (np->local_port && np->local_port != ntohs(uh->dest)) + goto out; - spin_lock_irqsave(&rx_list_lock, flags); - list_for_each(p, &rx_list) { - np = list_entry(p, struct netpoll, rx_list); - if (np->dev && np->dev != skb->dev) - continue; - if (np->local_ip && np->local_ip != ntohl(iph->daddr)) - continue; - if (np->remote_ip && np->remote_ip != ntohl(iph->saddr)) - continue; - if (np->local_port && np->local_port != ntohs(uh->dest)) - continue; - - spin_unlock_irqrestore(&rx_list_lock, flags); - - if (np->rx_hook) - np->rx_hook(np, ntohs(uh->source), - (char *)(uh+1), - ulen - sizeof(struct udphdr)); + np->rx_hook(np, ntohs(uh->source), + (char *)(uh+1), + ulen - sizeof(struct udphdr)); - kfree_skb(skb); - return 1; - } - spin_unlock_irqrestore(&rx_list_lock, flags); + kfree_skb(skb); + return 1; out: if (atomic_read(&trapped)) { @@ -574,6 +549,10 @@ np->name, np->dev_name); return -1; } + + np->dev = ndev; + ndev->np = np; + if (!ndev->poll_controller) { printk(KERN_ERR "%s: %s doesn't support polling, aborting.\n", np->name, np->dev_name); @@ -639,36 +618,22 @@ np->name, HIPQUAD(np->local_ip)); } - np->dev = ndev; - - if(np->rx_hook) { - unsigned long flags; - - np->dev->netpoll_rx = NETPOLL_RX_ENABLED; - - spin_lock_irqsave(&rx_list_lock, flags); - list_add(&np->rx_list, &rx_list); - spin_unlock_irqrestore(&rx_list_lock, flags); - } + if(np->rx_hook) + np->rx_flags = NETPOLL_RX_ENABLED; return 0; + release: + ndev->np = NULL; + np->dev = NULL; dev_put(ndev); return -1; } void netpoll_cleanup(struct netpoll *np) { - if (np->rx_hook) { - unsigned long flags; - - spin_lock_irqsave(&rx_list_lock, flags); - list_del(&np->rx_list); - spin_unlock_irqrestore(&rx_list_lock, flags); - } - if (np->dev) - np->dev->netpoll_rx = 0; + np->dev->np = NULL; dev_put(np->dev); np->dev = NULL; } Index: rc4/include/linux/netpoll.h =================================================================== --- rc4.orig/include/linux/netpoll.h 2005-02-17 22:32:19.000000000 -0600 +++ rc4/include/linux/netpoll.h 2005-02-17 22:39:59.000000000 -0600 @@ -16,11 +16,11 @@ struct netpoll { struct net_device *dev; char dev_name[16], *name; + int rx_flags; void (*rx_hook)(struct netpoll *, int, char *, int); u32 local_ip, remote_ip; u16 local_port, remote_port; unsigned char local_mac[6], remote_mac[6]; - struct list_head rx_list; }; void netpoll_poll(struct netpoll *np); @@ -35,7 +35,7 @@ #ifdef CONFIG_NETPOLL static inline int netpoll_rx(struct sk_buff *skb) { - return skb->dev->netpoll_rx && __netpoll_rx(skb); + return skb->dev->np && skb->dev->np->rx_flags && __netpoll_rx(skb); } #else #define netpoll_rx(a) 0 From mpm@selenic.com Thu Mar 3 12:46:41 2005 Received: with ECARTIS (v1.0.0; list netdev); Thu, 03 Mar 2005 12:46:56 -0800 (PST) Received: from waste.org (waste.org [216.27.176.166]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j23KkeuB031970 for ; Thu, 3 Mar 2005 12:46:40 -0800 Received: from moop (mail@[10.0.0.2]) by waste.org (8.13.2/8.13.2/Debian-1) with ESMTP id j23KkVgW001590; Thu, 3 Mar 2005 14:46:31 -0600 Received: from moop ([127.0.0.1] ident=oxymoron) by moop with esmtp (Exim 3.36 #1 (Debian)) id 1D6xDL-0003OF-00; Thu, 03 Mar 2005 14:46:31 -0600 From: Matt Mackall To: Jeff Garzik X-PatchBomber: http://selenic.com/scripts/mailpatches Cc: netdev@oss.sgi.com, Jeff Moyer Message-Id: <1.454130102@selenic.com> Subject: [PATCH 0/7] netpoll: recursion fixes, queueing, and cleanups Date: Thu, 03 Mar 2005 14:46:31 -0600 X-Virus-Scanned: ClamAV 0.83/743/Wed Mar 2 16:02:05 2005 on oss.sgi.com X-Virus-Scanned: by amavisd-new X-Virus-Status: Clean X-archive-position: 2314 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: mpm@selenic.com Precedence: bulk X-list: netdev This patch series against 2.6.11 fixes up some recursion deadlocks in netpoll and adds support for fallback to queueing. Various cleanups along the way. Holds up under load testing via ipt_LOG on a dual Opteron with tg3. Please apply. From mpm@selenic.com Thu Mar 3 12:46:43 2005 Received: with ECARTIS (v1.0.0; list netdev); Thu, 03 Mar 2005 12:46:58 -0800 (PST) Received: from waste.org (waste.org [216.27.176.166]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j23KkfQY031973 for ; Thu, 3 Mar 2005 12:46:41 -0800 Received: from moop (mail@[10.0.0.2]) by waste.org (8.13.2/8.13.2/Debian-1) with ESMTP id j23KkWVT001625; Thu, 3 Mar 2005 14:46:32 -0600 Received: from moop ([127.0.0.1] ident=oxymoron) by moop with esmtp (Exim 3.36 #1 (Debian)) id 1D6xDM-0003OF-03; Thu, 03 Mar 2005 14:46:32 -0600 From: Matt Mackall To: Jeff Garzik X-PatchBomber: http://selenic.com/scripts/mailpatches Cc: netdev@oss.sgi.com, Jeff Moyer In-Reply-To: <7.454130102@selenic.com> Message-Id: <8.454130102@selenic.com> Subject: [PATCH 7/7] netpoll: avoid kfree_skb on packets with destructo Date: Thu, 03 Mar 2005 14:46:32 -0600 X-Virus-Scanned: ClamAV 0.83/743/Wed Mar 2 16:02:05 2005 on oss.sgi.com X-Virus-Scanned: by amavisd-new X-Virus-Status: Clean X-archive-position: 2320 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: mpm@selenic.com Precedence: bulk X-list: netdev Packets that have destructors should not be zapped here as that might produce additional printk warnings via netconsole. Signed-off-by: Matt Mackall Index: np/net/core/netpoll.c =================================================================== --- np.orig/net/core/netpoll.c 2005-03-03 14:16:29.579809668 -0600 +++ np/net/core/netpoll.c 2005-03-03 14:17:21.167652225 -0600 @@ -192,7 +192,8 @@ static void zap_completion_queue(void) while (clist != NULL) { struct sk_buff *skb = clist; clist = clist->next; - __kfree_skb(skb); + if(!skb->destructor) + __kfree_skb(skb); } } From mpm@selenic.com Thu Mar 3 12:46:41 2005 Received: with ECARTIS (v1.0.0; list netdev); Thu, 03 Mar 2005 12:46:57 -0800 (PST) Received: from waste.org (waste.org [216.27.176.166]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j23KkeLG031967 for ; Thu, 3 Mar 2005 12:46:40 -0800 Received: from moop (mail@[10.0.0.2]) by waste.org (8.13.2/8.13.2/Debian-1) with ESMTP id j23KkVnb001595; Thu, 3 Mar 2005 14:46:31 -0600 Received: from moop ([127.0.0.1] ident=oxymoron) by moop with esmtp (Exim 3.36 #1 (Debian)) id 1D6xDL-0003OF-02; Thu, 03 Mar 2005 14:46:31 -0600 From: Matt Mackall To: Jeff Garzik X-PatchBomber: http://selenic.com/scripts/mailpatches Cc: netdev@oss.sgi.com, Jeff Moyer In-Reply-To: <2.454130102@selenic.com> Message-Id: <3.454130102@selenic.com> Subject: [PATCH 2/7] netpoll: filter inlines Date: Thu, 03 Mar 2005 14:46:31 -0600 X-Virus-Scanned: ClamAV 0.83/743/Wed Mar 2 16:02:05 2005 on oss.sgi.com X-Virus-Scanned: by amavisd-new X-Virus-Status: Clean X-archive-position: 2315 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: mpm@selenic.com Precedence: bulk X-list: netdev Add netpoll rx helpers Move skb_free for rx into __netpoll_rx Signed-off-by: Matt Mackall Index: rc4bk2/net/core/netpoll.c =================================================================== --- rc4bk2.orig/net/core/netpoll.c 2005-02-14 10:34:12.000000000 -0800 +++ rc4bk2/net/core/netpoll.c 2005-02-14 17:10:34.000000000 -0800 @@ -368,7 +368,7 @@ netpoll_send_skb(np, send_skb); } -int netpoll_rx(struct sk_buff *skb) +int __netpoll_rx(struct sk_buff *skb) { int proto, len, ulen; struct iphdr *iph; @@ -440,12 +440,18 @@ (char *)(uh+1), ulen - sizeof(struct udphdr)); + kfree_skb(skb); return 1; } spin_unlock_irqrestore(&rx_list_lock, flags); out: - return atomic_read(&trapped); + if (atomic_read(&trapped)) { + kfree_skb(skb); + return 1; + } + + return 0; } int netpoll_parse_options(struct netpoll *np, char *opt) Index: rc4bk2/include/linux/netpoll.h =================================================================== --- rc4bk2.orig/include/linux/netpoll.h 2005-02-14 10:34:08.000000000 -0800 +++ rc4bk2/include/linux/netpoll.h 2005-02-14 17:10:34.000000000 -0800 @@ -30,7 +30,15 @@ int netpoll_trap(void); void netpoll_set_trap(int trap); void netpoll_cleanup(struct netpoll *np); -int netpoll_rx(struct sk_buff *skb); +int __netpoll_rx(struct sk_buff *skb); +#ifdef CONFIG_NETPOLL +static inline int netpoll_rx(struct sk_buff *skb) +{ + return skb->dev->netpoll_rx && __netpoll_rx(skb); +} +#else +#define netpoll_rx(a) 0 +#endif #endif Index: rc4bk2/net/core/dev.c =================================================================== --- rc4bk2.orig/net/core/dev.c 2005-02-14 10:34:12.000000000 -0800 +++ rc4bk2/net/core/dev.c 2005-02-14 17:10:34.000000000 -0800 @@ -1427,13 +1427,10 @@ struct softnet_data *queue; unsigned long flags; -#ifdef CONFIG_NETPOLL - if (skb->dev->netpoll_rx && netpoll_rx(skb)) { - kfree_skb(skb); + /* if netpoll wants it, pretend we never saw it */ + if (netpoll_rx(skb)) return NET_RX_DROP; - } -#endif - + if (!skb->stamp.tv_sec) net_timestamp(&skb->stamp); @@ -1629,12 +1626,9 @@ int ret = NET_RX_DROP; unsigned short type; -#ifdef CONFIG_NETPOLL - if (skb->dev->netpoll_rx && skb->dev->poll && netpoll_rx(skb)) { - kfree_skb(skb); + /* if we've gotten here through NAPI, check netpoll */ + if (skb->dev->poll && netpoll_rx(skb)) return NET_RX_DROP; - } -#endif if (!skb->stamp.tv_sec) net_timestamp(&skb->stamp); From mpm@selenic.com Thu Mar 3 12:46:41 2005 Received: with ECARTIS (v1.0.0; list netdev); Thu, 03 Mar 2005 12:46:57 -0800 (PST) Received: from waste.org (waste.org [216.27.176.166]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j23KkeWu031968 for ; Thu, 3 Mar 2005 12:46:40 -0800 Received: from moop (mail@[10.0.0.2]) by waste.org (8.13.2/8.13.2/Debian-1) with ESMTP id j23KkV1B001592; Thu, 3 Mar 2005 14:46:31 -0600 Received: from moop ([127.0.0.1] ident=oxymoron) by moop with esmtp (Exim 3.36 #1 (Debian)) id 1D6xDL-0003OF-01; Thu, 03 Mar 2005 14:46:31 -0600 From: Matt Mackall To: Jeff Garzik X-PatchBomber: http://selenic.com/scripts/mailpatches Cc: netdev@oss.sgi.com, Jeff Moyer In-Reply-To: <1.454130102@selenic.com> Message-Id: <2.454130102@selenic.com> Subject: [PATCH 1/7] netpoll: shorten carrier detect timeout Date: Thu, 03 Mar 2005 14:46:31 -0600 X-Virus-Scanned: ClamAV 0.83/743/Wed Mar 2 16:02:05 2005 on oss.sgi.com X-Virus-Scanned: by amavisd-new X-Virus-Status: Clean X-archive-position: 2316 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: mpm@selenic.com Precedence: bulk X-list: netdev Shorten carrier detect timeout to 4 seconds. Signed-off-by: Matt Mackall Index: np/net/core/netpoll.c =================================================================== --- np.orig/net/core/netpoll.c 2005-03-03 14:13:38.700080023 -0600 +++ np/net/core/netpoll.c 2005-03-03 14:16:21.980600535 -0600 @@ -593,7 +593,7 @@ int netpoll_setup(struct netpoll *np) rtnl_shunlock(); atleast = jiffies + HZ/10; - atmost = jiffies + 10*HZ; + atmost = jiffies + 4*HZ; while (!netif_carrier_ok(ndev)) { if (time_after(jiffies, atmost)) { printk(KERN_NOTICE @@ -606,7 +606,7 @@ int netpoll_setup(struct netpoll *np) if (time_before(jiffies, atleast)) { printk(KERN_NOTICE "%s: carrier detect appears flaky," - " waiting 10 seconds\n", + " waiting 4 seconds\n", np->name); while (time_before(jiffies, atmost)) cond_resched(); From mpm@selenic.com Thu Mar 3 12:46:43 2005 Received: with ECARTIS (v1.0.0; list netdev); Thu, 03 Mar 2005 12:46:58 -0800 (PST) Received: from waste.org (waste.org [216.27.176.166]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j23Kkf6u031974 for ; Thu, 3 Mar 2005 12:46:41 -0800 Received: from moop (mail@[10.0.0.2]) by waste.org (8.13.2/8.13.2/Debian-1) with ESMTP id j23KkWOv001608; Thu, 3 Mar 2005 14:46:32 -0600 Received: from moop ([127.0.0.1] ident=oxymoron) by moop with esmtp (Exim 3.36 #1 (Debian)) id 1D6xDM-0003OF-00; Thu, 03 Mar 2005 14:46:32 -0600 From: Matt Mackall To: Jeff Garzik X-PatchBomber: http://selenic.com/scripts/mailpatches Cc: netdev@oss.sgi.com, Jeff Moyer In-Reply-To: <4.454130102@selenic.com> Message-Id: <5.454130102@selenic.com> Subject: [PATCH 4/7] netpoll: fix ->poll() locking Date: Thu, 03 Mar 2005 14:46:32 -0600 X-Virus-Scanned: ClamAV 0.83/743/Wed Mar 2 16:02:05 2005 on oss.sgi.com X-Virus-Scanned: by amavisd-new X-Virus-Status: Clean X-archive-position: 2321 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: mpm@selenic.com Precedence: bulk X-list: netdev Introduce a per-client poll lock and flag. The lock assures we never have more than one caller in dev->poll(). The flag provides recursion avoidance on UP where the lock disappears. Signed-off-by: Matt Mackall Index: rc4/net/core/netpoll.c =================================================================== --- rc4.orig/net/core/netpoll.c 2005-02-17 22:39:59.000000000 -0600 +++ rc4/net/core/netpoll.c 2005-02-17 22:40:02.000000000 -0600 @@ -36,7 +36,6 @@ static struct sk_buff *skbs; static atomic_t trapped; -static DEFINE_SPINLOCK(netpoll_poll_lock); #define NETPOLL_RX_ENABLED 1 #define NETPOLL_RX_DROP 2 @@ -63,8 +62,15 @@ } /* - * Check whether delayed processing was scheduled for our current CPU, - * and then manually invoke NAPI polling to pump data off the card. + * Check whether delayed processing was scheduled for our NIC. If so, + * we attempt to grab the poll lock and use ->poll() to pump the card. + * If this fails, either we've recursed in ->poll() or it's already + * running on another CPU. + * + * Note: we don't mask interrupts with this lock because we're using + * trylock here and interrupts are already disabled in the softirq + * case. Further, we test the poll_owner to avoid recursion on UP + * systems where the lock doesn't exist. * * In cases where there is bi-directional communications, reading only * one message at a time can lead to packets being dropped by the @@ -74,13 +80,10 @@ static void poll_napi(struct netpoll *np) { int budget = 16; - unsigned long flags; - struct softnet_data *queue; - spin_lock_irqsave(&netpoll_poll_lock, flags); - queue = &__get_cpu_var(softnet_data); if (test_bit(__LINK_STATE_RX_SCHED, &np->dev->state) && - !list_empty(&queue->poll_list)) { + np->poll_owner != __smp_processor_id() && + spin_trylock(&np->poll_lock)) { np->rx_flags |= NETPOLL_RX_DROP; atomic_inc(&trapped); @@ -88,8 +91,8 @@ atomic_dec(&trapped); np->rx_flags &= ~NETPOLL_RX_DROP; + spin_unlock(&np->poll_lock); } - spin_unlock_irqrestore(&netpoll_poll_lock, flags); } void netpoll_poll(struct netpoll *np) @@ -194,6 +197,12 @@ return; } + /* avoid ->poll recursion */ + if(np->poll_owner == __smp_processor_id()) { + __kfree_skb(skb); + return; + } + spin_lock(&np->dev->xmit_lock); np->dev->xmit_lock_owner = smp_processor_id(); @@ -542,6 +551,9 @@ struct net_device *ndev = NULL; struct in_device *in_dev; + np->poll_lock = SPIN_LOCK_UNLOCKED; + np->poll_owner = -1; + if (np->dev_name) ndev = dev_get_by_name(np->dev_name); if (!ndev) { Index: rc4/include/linux/netpoll.h =================================================================== --- rc4.orig/include/linux/netpoll.h 2005-02-17 22:39:59.000000000 -0600 +++ rc4/include/linux/netpoll.h 2005-02-17 22:40:02.000000000 -0600 @@ -21,6 +21,8 @@ u32 local_ip, remote_ip; u16 local_port, remote_port; unsigned char local_mac[6], remote_mac[6]; + spinlock_t poll_lock; + int poll_owner; }; void netpoll_poll(struct netpoll *np); @@ -37,8 +39,27 @@ { return skb->dev->np && skb->dev->np->rx_flags && __netpoll_rx(skb); } + +static inline void netpoll_poll_lock(struct net_device *dev) +{ + if (dev->np) { + spin_lock(&dev->np->poll_lock); + dev->np->poll_owner = __smp_processor_id(); + } +} + +static inline void netpoll_poll_unlock(struct net_device *dev) +{ + if (dev->np) { + spin_unlock(&dev->np->poll_lock); + dev->np->poll_owner = -1; + } +} + #else #define netpoll_rx(a) 0 +#define netpoll_poll_lock(a) +#define netpoll_poll_unlock(a) #endif #endif Index: rc4/net/core/dev.c =================================================================== --- rc4.orig/net/core/dev.c 2005-02-17 22:39:59.000000000 -0600 +++ rc4/net/core/dev.c 2005-02-17 22:40:02.000000000 -0600 @@ -1775,8 +1775,10 @@ dev = list_entry(queue->poll_list.next, struct net_device, poll_list); + netpoll_poll_lock(dev); if (dev->quota <= 0 || dev->poll(dev, &budget)) { + netpoll_poll_unlock(dev); local_irq_disable(); list_del(&dev->poll_list); list_add_tail(&dev->poll_list, &queue->poll_list); @@ -1785,6 +1787,7 @@ else dev->quota = dev->weight; } else { + netpoll_poll_unlock(dev); dev_put(dev); local_irq_disable(); } From mpm@selenic.com Thu Mar 3 12:46:43 2005 Received: with ECARTIS (v1.0.0; list netdev); Thu, 03 Mar 2005 12:46:58 -0800 (PST) Received: from waste.org (waste.org [216.27.176.166]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j23KkfuX031972 for ; Thu, 3 Mar 2005 12:46:41 -0800 Received: from moop (mail@[10.0.0.2]) by waste.org (8.13.2/8.13.2/Debian-1) with ESMTP id j23KkWQ4001620; Thu, 3 Mar 2005 14:46:32 -0600 Received: from moop ([127.0.0.1] ident=oxymoron) by moop with esmtp (Exim 3.36 #1 (Debian)) id 1D6xDM-0003OF-02; Thu, 03 Mar 2005 14:46:32 -0600 From: Matt Mackall To: Jeff Garzik X-PatchBomber: http://selenic.com/scripts/mailpatches Cc: netdev@oss.sgi.com, Jeff Moyer In-Reply-To: <6.454130102@selenic.com> Message-Id: <7.454130102@selenic.com> Subject: [PATCH 6/7] netpoll: handle xmit_lock recursion similarly Date: Thu, 03 Mar 2005 14:46:32 -0600 X-Virus-Scanned: ClamAV 0.83/743/Wed Mar 2 16:02:05 2005 on oss.sgi.com X-Virus-Scanned: by amavisd-new X-Virus-Status: Clean X-archive-position: 2319 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: mpm@selenic.com Precedence: bulk X-list: netdev Handle possible recursion on xmit_lock while we're at it. Signed-off-by: Matt Mackall Index: rc4/net/core/netpoll.c =================================================================== --- rc4.orig/net/core/netpoll.c 2005-02-17 22:40:05.000000000 -0600 +++ rc4/net/core/netpoll.c 2005-02-17 22:40:07.000000000 -0600 @@ -247,8 +247,9 @@ return; } - /* avoid ->poll recursion */ - if(np->poll_owner == __smp_processor_id()) { + /* avoid recursion */ + if(np->poll_owner == __smp_processor_id() || + np->dev->xmit_lock_owner == __smp_processor_id()) { if (np->drop) np->drop(skb); else From mpm@selenic.com Thu Mar 3 12:46:43 2005 Received: with ECARTIS (v1.0.0; list netdev); Thu, 03 Mar 2005 12:46:57 -0800 (PST) Received: from waste.org (waste.org [216.27.176.166]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j23KkfMs031975 for ; Thu, 3 Mar 2005 12:46:41 -0800 Received: from moop (mail@[10.0.0.2]) by waste.org (8.13.2/8.13.2/Debian-1) with ESMTP id j23KkWm6001615; Thu, 3 Mar 2005 14:46:32 -0600 Received: from moop ([127.0.0.1] ident=oxymoron) by moop with esmtp (Exim 3.36 #1 (Debian)) id 1D6xDM-0003OF-01; Thu, 03 Mar 2005 14:46:32 -0600 From: Matt Mackall To: Jeff Garzik X-PatchBomber: http://selenic.com/scripts/mailpatches Cc: netdev@oss.sgi.com, Jeff Moyer In-Reply-To: <5.454130102@selenic.com> Message-Id: <6.454130102@selenic.com> Subject: [PATCH 5/7] netpoll: add optional dropping and queueing support Date: Thu, 03 Mar 2005 14:46:32 -0600 X-Virus-Scanned: ClamAV 0.83/743/Wed Mar 2 16:02:05 2005 on oss.sgi.com X-Virus-Scanned: by amavisd-new X-Virus-Status: Clean X-archive-position: 2317 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: mpm@selenic.com Precedence: bulk X-list: netdev This adds a callback for packets we can't deliver immediately and a helper function for clients to queue such packets to the device post-interrupt. Netconsole is modified to use the queueing function for best-effort delivery. Signed-off-by: Matt Mackall Index: rc4/drivers/net/netconsole.c =================================================================== --- rc4.orig/drivers/net/netconsole.c 2005-02-17 22:39:29.000000000 -0600 +++ rc4/drivers/net/netconsole.c 2005-02-17 22:40:05.000000000 -0600 @@ -60,6 +60,7 @@ .local_port = 6665, .remote_port = 6666, .remote_mac = {0xff, 0xff, 0xff, 0xff, 0xff, 0xff}, + .drop = netpoll_queue, }; static int configured = 0; Index: rc4/net/core/netpoll.c =================================================================== --- rc4.orig/net/core/netpoll.c 2005-02-17 22:40:02.000000000 -0600 +++ rc4/net/core/netpoll.c 2005-02-17 22:40:05.000000000 -0600 @@ -19,6 +19,7 @@ #include #include #include +#include #include #include #include @@ -28,13 +29,18 @@ * message gets out even in extreme OOM situations. */ -#define MAX_SKBS 32 #define MAX_UDP_CHUNK 1460 +#define MAX_SKBS 32 +#define MAX_QUEUE_DEPTH (MAX_SKBS / 2) static DEFINE_SPINLOCK(skb_list_lock); static int nr_skbs; static struct sk_buff *skbs; +static DEFINE_SPINLOCK(queue_lock); +static int queue_depth; +static struct sk_buff *queue_head, *queue_tail; + static atomic_t trapped; #define NETPOLL_RX_ENABLED 1 @@ -46,6 +52,50 @@ static void zap_completion_queue(void); +static void queue_process(void *p) +{ + unsigned long flags; + struct sk_buff *skb; + + while (queue_head) { + spin_lock_irqsave(&queue_lock, flags); + + skb = queue_head; + queue_head = skb->next; + if (skb == queue_tail) + queue_head = NULL; + + queue_depth--; + + spin_unlock_irqrestore(&queue_lock, flags); + + dev_queue_xmit(skb); + } +} + +static DECLARE_WORK(send_queue, queue_process, NULL); + +void netpoll_queue(struct sk_buff *skb) +{ + unsigned long flags; + + if (queue_depth == MAX_QUEUE_DEPTH) { + __kfree_skb(skb); + return; + } + + spin_lock_irqsave(&queue_lock, flags); + if (!queue_head) + queue_head = skb; + else + queue_tail->next = skb; + queue_tail = skb; + queue_depth++; + spin_unlock_irqrestore(&queue_lock, flags); + + schedule_work(&send_queue); +} + static int checksum_udp(struct sk_buff *skb, struct udphdr *uh, unsigned short ulen, u32 saddr, u32 daddr) { @@ -199,7 +249,10 @@ /* avoid ->poll recursion */ if(np->poll_owner == __smp_processor_id()) { - __kfree_skb(skb); + if (np->drop) + np->drop(skb); + else + __kfree_skb(skb); return; } @@ -275,6 +328,8 @@ memcpy(eth->h_source, np->local_mac, 6); memcpy(eth->h_dest, np->remote_mac, 6); + skb->dev = np->dev; + netpoll_send_skb(np, skb); } Index: rc4/include/linux/netpoll.h =================================================================== --- rc4.orig/include/linux/netpoll.h 2005-02-17 22:40:02.000000000 -0600 +++ rc4/include/linux/netpoll.h 2005-02-17 22:40:05.000000000 -0600 @@ -18,6 +18,7 @@ char dev_name[16], *name; int rx_flags; void (*rx_hook)(struct netpoll *, int, char *, int); + void (*drop)(struct sk_buff *skb); u32 local_ip, remote_ip; u16 local_port, remote_port; unsigned char local_mac[6], remote_mac[6]; @@ -33,6 +34,7 @@ void netpoll_set_trap(int trap); void netpoll_cleanup(struct netpoll *np); int __netpoll_rx(struct sk_buff *skb); +void netpoll_queue(struct sk_buff *skb); #ifdef CONFIG_NETPOLL static inline int netpoll_rx(struct sk_buff *skb) From davem@davemloft.net Thu Mar 3 12:56:45 2005 Received: with ECARTIS (v1.0.0; list netdev); Thu, 03 Mar 2005 12:56:49 -0800 (PST) Received: from cheetah.davemloft.net (mail@dsl027-180-174.sfo1.dsl.speakeasy.net [216.27.180.174]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j23KuiOa004571 for ; Thu, 3 Mar 2005 12:56:44 -0800 Received: from localhost ([127.0.0.1] helo=cheetah.davemloft.net ident=davem) by cheetah.davemloft.net with smtp (Exim 3.36 #1 (Debian)) id 1D6xMS-0007mT-00; Thu, 03 Mar 2005 12:55:56 -0800 Date: Thu, 3 Mar 2005 12:55:56 -0800 From: "David S. Miller" To: Stephen Hemminger Cc: rhee@eos.ncsu.edu, jheffner@psc.edu, Yee-Ting.Li@nuim.ie, baruch@ev-en.org, netdev@oss.sgi.com Subject: Re: netif_rx packet dumping Message-Id: <20050303125556.6850cfe5.davem@davemloft.net> In-Reply-To: <20050303123811.4d934249@dxpl.pdx.osdl.net> References: <20050303123811.4d934249@dxpl.pdx.osdl.net> X-Mailer: Sylpheed version 1.0.1 (GTK+ 1.2.10; sparc-unknown-linux-gnu) X-Face: "_;p5u5aPsO,_Vsx"^v-pEq09'CU4&Dc1$fQExov$62l60cgCc%FnIwD=.UF^a>?5'9Kn[;433QFVV9M..2eN.@4ZWPGbdi<=?[:T>y?SD(R*-3It"Vj:)"dP Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV 0.83/743/Wed Mar 2 16:02:05 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 2322 X-ecartis-version: Ecartis v1.0.0 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, 3 Mar 2005 12:38:11 -0800 Stephen Hemminger wrote: > The existing throttling algorithm causes all packets to be dumped > (until queue emptys) when the packet backlog reaches > netdev_max_backog. I suppose this is some kind of DoS prevention > mechanism. The problem is that this dumping action creates mulitple > packet loss that forces TCP back to slow start. > > But, all this is really moot for the case of any reasonably high speed > device because of NAPI. netif_rx is not even used for any device that > uses NAPI. The NAPI code path uses net_receive_skb and the receive > queue management is done by the receive scheduling (dev->quota) of the > rx_scheduler. Even without NAPI, netif_rx() ends up using the quota etc. machanisms when the queue gets processed via process_backlog(). ksoftirqd should handle cpu starvation issues at a higher level. I think it is therefore safe to remove the netif_max_backlog stuff altogether. "300" is such a non-sense setting, especially for gigabit drivers which aren't using NAPI for whatever reason. It's even low for a system with 2 100Mbit devices. From davem@davemloft.net Thu Mar 3 13:00:56 2005 Received: with ECARTIS (v1.0.0; list netdev); Thu, 03 Mar 2005 13:01:00 -0800 (PST) Received: from cheetah.davemloft.net (mail@dsl027-180-174.sfo1.dsl.speakeasy.net [216.27.180.174]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j23L0uYm008313 for ; Thu, 3 Mar 2005 13:00:56 -0800 Received: from localhost ([127.0.0.1] helo=cheetah.davemloft.net ident=davem) by cheetah.davemloft.net with smtp (Exim 3.36 #1 (Debian)) id 1D6xQu-0007qN-00; Thu, 03 Mar 2005 13:00:32 -0800 Date: Thu, 3 Mar 2005 13:00:31 -0800 From: "David S. Miller" To: Matt Mackall Cc: jgarzik@pobox.com, netdev@oss.sgi.com, jmoyer@redhat.com Subject: Re: [PATCH 7/7] netpoll: avoid kfree_skb on packets with destructo Message-Id: <20050303130031.066f0862.davem@davemloft.net> In-Reply-To: <8.454130102@selenic.com> References: <7.454130102@selenic.com> <8.454130102@selenic.com> X-Mailer: Sylpheed version 1.0.1 (GTK+ 1.2.10; sparc-unknown-linux-gnu) X-Face: "_;p5u5aPsO,_Vsx"^v-pEq09'CU4&Dc1$fQExov$62l60cgCc%FnIwD=.UF^a>?5'9Kn[;433QFVV9M..2eN.@4ZWPGbdi<=?[:T>y?SD(R*-3It"Vj:)"dP Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV 0.83/743/Wed Mar 2 16:02:05 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 2323 X-ecartis-version: Ecartis v1.0.0 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, 03 Mar 2005 14:46:32 -0600 Matt Mackall wrote: > Packets that have destructors should not be zapped here as that might > produce additional printk warnings via netconsole. > > Signed-off-by: Matt Mackall Then where will they be freed, eh? :-) This patch adds an SKB leak. Since you've NULL'd out the list, any SKB skipped will never be freed up at all. From shemminger@osdl.org Thu Mar 3 13:02:00 2005 Received: with ECARTIS (v1.0.0; list netdev); Thu, 03 Mar 2005 13:02:03 -0800 (PST) Received: from smtp.osdl.org (fire.osdl.org [65.172.181.4]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j23L1xVh008745 for ; Thu, 3 Mar 2005 13:01:59 -0800 Received: from shell0.pdx.osdl.net (fw.osdl.org [65.172.181.6]) by smtp.osdl.org (8.12.8/8.12.8) with ESMTP id j23L1eqi010146 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO); Thu, 3 Mar 2005 13:01:41 -0800 Received: from dxpl.pdx.osdl.net (dxpl.pdx.osdl.net [172.20.1.103]) by shell0.pdx.osdl.net (8.13.1/8.11.6) with ESMTP id j23L1ekE021927; Thu, 3 Mar 2005 13:01:40 -0800 Date: Thu, 3 Mar 2005 13:01:57 -0800 From: Stephen Hemminger To: "David S. Miller" Cc: rhee@eos.ncsu.edu, jheffner@psc.edu, Yee-Ting.Li@nuim.ie, baruch@ev-en.org, netdev@oss.sgi.com Subject: Re: netif_rx packet dumping Message-ID: <20050303130157.5afa4fcb@dxpl.pdx.osdl.net> In-Reply-To: <20050303125556.6850cfe5.davem@davemloft.net> References: <20050303123811.4d934249@dxpl.pdx.osdl.net> <20050303125556.6850cfe5.davem@davemloft.net> Organization: Open Source Development Lab X-Mailer: Sylpheed-Claws 1.0.1 (GTK+ 1.2.10; x86_64-unknown-linux-gnu) X-Face: &@E+xe?c%:&e4D{>f1O<&U>2qwRREG5!}7R4;D<"NO^UI2mJ[eEOA2*3>(`Th.yP,VDPo9$ /`~cw![cmj~~jWe?AHY7D1S+\}5brN0k*NE?pPh_'_d>6;XGG[\KDRViCfumZT3@[ Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Received-SPF: pass (domain of shemminger@osdl.org designates 65.172.181.6 as permitted sender) X-MIMEDefang-Filter: osdl$Revision: 1.104 $ X-Scanned-By: MIMEDefang 2.36 X-Virus-Scanned: ClamAV 0.83/743/Wed Mar 2 16:02:05 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 2324 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: shemminger@osdl.org Precedence: bulk X-list: netdev On Thu, 3 Mar 2005 12:55:56 -0800 "David S. Miller" wrote: > On Thu, 3 Mar 2005 12:38:11 -0800 > Stephen Hemminger wrote: > > > The existing throttling algorithm causes all packets to be dumped > > (until queue emptys) when the packet backlog reaches > > netdev_max_backog. I suppose this is some kind of DoS prevention > > mechanism. The problem is that this dumping action creates mulitple > > packet loss that forces TCP back to slow start. > > > > But, all this is really moot for the case of any reasonably high speed > > device because of NAPI. netif_rx is not even used for any device that > > uses NAPI. The NAPI code path uses net_receive_skb and the receive > > queue management is done by the receive scheduling (dev->quota) of the > > rx_scheduler. > > Even without NAPI, netif_rx() ends up using the quota etc. machanisms > when the queue gets processed via process_backlog(). > > ksoftirqd should handle cpu starvation issues at a higher level. > > I think it is therefore safe to remove the netif_max_backlog stuff > altogether. "300" is such a non-sense setting, especially for gigabit > drivers which aren't using NAPI for whatever reason. It's even low > for a system with 2 100Mbit devices. Okay, already have patchset to clean out the sample_stats and other leftovers so I'll add it to the tail of that. From jgarzik@pobox.com Thu Mar 3 13:17:40 2005 Received: with ECARTIS (v1.0.0; list netdev); Thu, 03 Mar 2005 13:17:45 -0800 (PST) Received: from parcelfarce.linux.theplanet.co.uk (IDENT:93@parcelfarce.linux.theplanet.co.uk [195.92.249.252]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j23LHd1q009973 for ; Thu, 3 Mar 2005 13:17:39 -0800 Received: from [69.134.152.124] (helo=[10.10.10.88]) by parcelfarce.linux.theplanet.co.uk with asmtp (TLSv1:AES256-SHA:256) (Exim 4.33) id 1D6xhR-0002T4-6C; Thu, 03 Mar 2005 21:17:37 +0000 Message-ID: <42277ED6.4020707@pobox.com> Date: Thu, 03 Mar 2005 16:17:10 -0500 From: Jeff Garzik User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.3) Gecko/20040922 X-Accept-Language: en-us, en MIME-Version: 1.0 To: "David S. Miller" CC: Matt Mackall , netdev@oss.sgi.com, jmoyer@redhat.com Subject: Re: [PATCH 7/7] netpoll: avoid kfree_skb on packets with destructo References: <7.454130102@selenic.com> <8.454130102@selenic.com> <20050303130031.066f0862.davem@davemloft.net> In-Reply-To: <20050303130031.066f0862.davem@davemloft.net> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV 0.83/743/Wed Mar 2 16:02:05 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 2325 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: jgarzik@pobox.com Precedence: bulk X-list: netdev David S. Miller wrote: > On Thu, 03 Mar 2005 14:46:32 -0600 > Matt Mackall wrote: > > >>Packets that have destructors should not be zapped here as that might >>produce additional printk warnings via netconsole. >> >>Signed-off-by: Matt Mackall > > > Then where will they be freed, eh? :-) > > This patch adds an SKB leak. Since you've NULL'd out the list, any > SKB skipped will never be freed up at all. Heh, I was just writing this same message. On a related note... David, I would prefer if you merged up the netpoll stuff, since it touches mainly net/* Is that cool w/ you? Jeff From hadi@cyberus.ca Thu Mar 3 13:18:18 2005 Received: with ECARTIS (v1.0.0; list netdev); Thu, 03 Mar 2005 13:18:23 -0800 (PST) Received: from mx03.cybersurf.com (mx03.cybersurf.com [209.197.145.106]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j23LIHqB010158 for ; Thu, 3 Mar 2005 13:18:18 -0800 Received: from mail.cyberus.ca ([209.197.145.21]) by mx03.cybersurf.com with esmtp (Exim 4.30) id 1D6xi5-00076M-S6 for netdev@oss.sgi.com; Thu, 03 Mar 2005 16:18:17 -0500 Received: from [24.103.99.32] (helo=[10.0.0.9]) by mail.cyberus.ca with esmtp (Exim 4.20) id 1D6xi0-0007gu-D8; Thu, 03 Mar 2005 16:18:12 -0500 Subject: Re: netif_rx packet dumping From: jamal Reply-To: hadi@cyberus.ca To: "David S. Miller" Cc: Stephen Hemminger , rhee@eos.ncsu.edu, jheffner@psc.edu, Yee-Ting.Li@nuim.ie, baruch@ev-en.org, netdev@oss.sgi.com In-Reply-To: <20050303125556.6850cfe5.davem@davemloft.net> References: <20050303123811.4d934249@dxpl.pdx.osdl.net> <20050303125556.6850cfe5.davem@davemloft.net> Content-Type: text/plain Organization: jamalopolous Message-Id: <1109884688.1090.282.camel@jzny.localdomain> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.2.2 Date: 03 Mar 2005 16:18:08 -0500 Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV 0.83/743/Wed Mar 2 16:02:05 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 2326 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: hadi@cyberus.ca Precedence: bulk X-list: netdev On Thu, 2005-03-03 at 15:55, David S. Miller wrote: > On Thu, 3 Mar 2005 12:38:11 -0800 > Stephen Hemminger wrote: > > > The existing throttling algorithm causes all packets to be dumped > > (until queue emptys) when the packet backlog reaches > > netdev_max_backog. I suppose this is some kind of DoS prevention > > mechanism. The problem is that this dumping action creates mulitple > > packet loss that forces TCP back to slow start. > > > > But, all this is really moot for the case of any reasonably high speed > > device because of NAPI. netif_rx is not even used for any device that > > uses NAPI. The NAPI code path uses net_receive_skb and the receive > > queue management is done by the receive scheduling (dev->quota) of the > > rx_scheduler. > > Even without NAPI, netif_rx() ends up using the quota etc. machanisms > when the queue gets processed via process_backlog(). > > ksoftirqd should handle cpu starvation issues at a higher level. > > I think it is therefore safe to remove the netif_max_backlog stuff > altogether. "300" is such a non-sense setting, especially for gigabit > drivers which aren't using NAPI for whatever reason. It's even low > for a system with 2 100Mbit devices. A couple of issues with this - the rx softirq uses netif_max_backlog as a contraint on how long to run before yielding. Could probably fix by having a different variable. It may be fair to decouple those two in any case. - if you dont put a restriction on how many netif_rx packets get queued then it is more than likely you will run into an OOM case for non-NAPI drivers under interupt overload. Could probably resolve this by increasing the backlog size to several TCP window sizes (handwaving: 2?). What would be the optimal TCP window size in these big fat pipes assuming real low RTT? I would say whoever is worried about this should use a NAPI driver; otherwise you dont deserve that pipe! cheers, jamal From shemminger@osdl.org Thu Mar 3 13:22:16 2005 Received: with ECARTIS (v1.0.0; list netdev); Thu, 03 Mar 2005 13:22:21 -0800 (PST) Received: from smtp.osdl.org (fire.osdl.org [65.172.181.4]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j23LMFlx011207 for ; Thu, 3 Mar 2005 13:22:15 -0800 Received: from shell0.pdx.osdl.net (fw.osdl.org [65.172.181.6]) by smtp.osdl.org (8.12.8/8.12.8) with ESMTP id j23LLRqi011818 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO); Thu, 3 Mar 2005 13:21:28 -0800 Received: from dxpl.pdx.osdl.net (dxpl.pdx.osdl.net [172.20.1.103]) by shell0.pdx.osdl.net (8.13.1/8.11.6) with ESMTP id j23LLR3o022978; Thu, 3 Mar 2005 13:21:27 -0800 Date: Thu, 3 Mar 2005 13:21:43 -0800 From: Stephen Hemminger To: hadi@cyberus.ca Cc: "David S. Miller" , rhee@eos.ncsu.edu, jheffner@psc.edu, Yee-Ting.Li@nuim.ie, baruch@ev-en.org, netdev@oss.sgi.com Subject: Re: netif_rx packet dumping Message-ID: <20050303132143.7eef517c@dxpl.pdx.osdl.net> In-Reply-To: <1109884688.1090.282.camel@jzny.localdomain> References: <20050303123811.4d934249@dxpl.pdx.osdl.net> <20050303125556.6850cfe5.davem@davemloft.net> <1109884688.1090.282.camel@jzny.localdomain> Organization: Open Source Development Lab X-Mailer: Sylpheed-Claws 1.0.1 (GTK+ 1.2.10; x86_64-unknown-linux-gnu) X-Face: &@E+xe?c%:&e4D{>f1O<&U>2qwRREG5!}7R4;D<"NO^UI2mJ[eEOA2*3>(`Th.yP,VDPo9$ /`~cw![cmj~~jWe?AHY7D1S+\}5brN0k*NE?pPh_'_d>6;XGG[\KDRViCfumZT3@[ Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Received-SPF: pass (domain of shemminger@osdl.org designates 65.172.181.6 as permitted sender) X-MIMEDefang-Filter: osdl$Revision: 1.104 $ X-Scanned-By: MIMEDefang 2.36 X-Virus-Scanned: ClamAV 0.83/743/Wed Mar 2 16:02:05 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 2327 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: shemminger@osdl.org Precedence: bulk X-list: netdev On 03 Mar 2005 16:18:08 -0500 jamal wrote: > On Thu, 2005-03-03 at 15:55, David S. Miller wrote: > > On Thu, 3 Mar 2005 12:38:11 -0800 > > Stephen Hemminger wrote: > > > > > The existing throttling algorithm causes all packets to be dumped > > > (until queue emptys) when the packet backlog reaches > > > netdev_max_backog. I suppose this is some kind of DoS prevention > > > mechanism. The problem is that this dumping action creates mulitple > > > packet loss that forces TCP back to slow start. > > > > > > But, all this is really moot for the case of any reasonably high speed > > > device because of NAPI. netif_rx is not even used for any device that > > > uses NAPI. The NAPI code path uses net_receive_skb and the receive > > > queue management is done by the receive scheduling (dev->quota) of the > > > rx_scheduler. > > > > Even without NAPI, netif_rx() ends up using the quota etc. machanisms > > when the queue gets processed via process_backlog(). > > > > ksoftirqd should handle cpu starvation issues at a higher level. > > > > I think it is therefore safe to remove the netif_max_backlog stuff > > altogether. "300" is such a non-sense setting, especially for gigabit > > drivers which aren't using NAPI for whatever reason. It's even low > > for a system with 2 100Mbit devices. > > A couple of issues with this > - the rx softirq uses netif_max_backlog as a contraint on how long to > run before yielding. Could probably fix by having a different variable. > It may be fair to decouple those two in any case. > - if you dont put a restriction on how many netif_rx packets get queued > then it is more than likely you will run into an OOM case for non-NAPI > drivers under interupt overload. Could probably resolve this by > increasing the backlog size to several TCP window sizes (handwaving: > 2?). What would be the optimal TCP window size in these big fat pipes > assuming real low RTT? > > I would say whoever is worried about this should use a NAPI driver; > otherwise you dont deserve that pipe! My plan is to keep netif_max_backlog but bump it up to something bigger by default. Maybe even autosize it based on memory available. But get rid of the "dump till empty" behaviour that screws over TCP. From hadi@cyberus.ca Thu Mar 3 13:24:34 2005 Received: with ECARTIS (v1.0.0; list netdev); Thu, 03 Mar 2005 13:24:38 -0800 (PST) Received: from mx03.cybersurf.com (mx03.cybersurf.com [209.197.145.106]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j23LOYDW011821 for ; Thu, 3 Mar 2005 13:24:34 -0800 Received: from mail.cyberus.ca ([209.197.145.21]) by mx03.cybersurf.com with esmtp (Exim 4.30) id 1D6xoA-0001vv-Qa for netdev@oss.sgi.com; Thu, 03 Mar 2005 16:24:34 -0500 Received: from [24.103.99.32] (helo=[10.0.0.9]) by mail.cyberus.ca with esmtp (Exim 4.20) id 1D6xo6-0000A6-Kx; Thu, 03 Mar 2005 16:24:30 -0500 Subject: Re: netif_rx packet dumping From: jamal Reply-To: hadi@cyberus.ca To: Stephen Hemminger Cc: "David S. Miller" , rhee@eos.ncsu.edu, jheffner@psc.edu, Yee-Ting.Li@nuim.ie, baruch@ev-en.org, netdev@oss.sgi.com In-Reply-To: <20050303132143.7eef517c@dxpl.pdx.osdl.net> References: <20050303123811.4d934249@dxpl.pdx.osdl.net> <20050303125556.6850cfe5.davem@davemloft.net> <1109884688.1090.282.camel@jzny.localdomain> <20050303132143.7eef517c@dxpl.pdx.osdl.net> Content-Type: text/plain Organization: jamalopolous Message-Id: <1109885065.1098.285.camel@jzny.localdomain> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.2.2 Date: 03 Mar 2005 16:24:25 -0500 Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV 0.83/743/Wed Mar 2 16:02:05 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 2328 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: hadi@cyberus.ca Precedence: bulk X-list: netdev On Thu, 2005-03-03 at 16:21, Stephen Hemminger wrote: > My plan is to keep netif_max_backlog but bump it up to something bigger > by default. Maybe even autosize it based on memory available. But > get rid of the "dump till empty" behaviour that screws over TCP. Ok, this does sound more reasonable. Out of curiosity, are packets being dropped at the socket queue? Why is "dump till empty" behaviour screwing over TCP. cheers, jamal From baruch@ev-en.org Thu Mar 3 13:27:27 2005 Received: with ECARTIS (v1.0.0; list netdev); Thu, 03 Mar 2005 13:27:31 -0800 (PST) Received: from galon.ev-en.org (rrcs-24-123-59-149.central.biz.rr.com [24.123.59.149]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j23LRQ2r012464 for ; Thu, 3 Mar 2005 13:27:27 -0800 Received: by galon.ev-en.org (Postfix, from userid 105) id 49E7011A697; Thu, 3 Mar 2005 23:27:18 +0200 (IST) Received: from [10.220.3.66] (hamilton.nuim.ie [149.157.192.252]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by galon.ev-en.org (Postfix) with ESMTP id 1FBFD11A5E3; Thu, 3 Mar 2005 23:27:02 +0200 (IST) Message-ID: <42278122.6000000@ev-en.org> Date: Thu, 03 Mar 2005 21:26:58 +0000 From: Baruch Even User-Agent: Debian Thunderbird 1.0 (X11/20050116) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Stephen Hemminger Cc: Injong Rhee , John Heffner , "David S. Miller" , Yee-Ting Li , netdev@oss.sgi.com Subject: Re: netif_rx packet dumping References: <20050303123811.4d934249@dxpl.pdx.osdl.net> In-Reply-To: <20050303123811.4d934249@dxpl.pdx.osdl.net> X-Enigmail-Version: 0.90.0.0 X-Enigmail-Supports: pgp-inline, pgp-mime Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV 0.83/743/Wed Mar 2 16:02:05 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 2329 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: baruch@ev-en.org Precedence: bulk X-list: netdev Stephen Hemminger wrote: > Both BIC TCP 1.1 and TCP-H include patches to disable the queue > throttling behaviour of netif_rx. The existing throttling algorithm > causes all packets to be dumped (until queue emptys) when the packet > backlog reaches netdev_max_backog. I suppose this is some kind of DoS > prevention mechanism. The problem is that this dumping action creates > mulitple packet loss that forces TCP back to slow start. > > But, all this is really moot for the case of any reasonably high speed > device because of NAPI. netif_rx is not even used for any device that uses NAPI. > The NAPI code path uses net_receive_skb and the receive queue management is done > by the receive scheduling (dev->quota) of the rx_scheduler. > > My question is why did BIC TCP and TCP-H turn off the throttling? > Was it because they were/are using older 2.4 devices without NAPI. NAPI was not used because it caused skews in the performance, I haven't tested it myself, just passing hearsay. I have patches for the SACK processing to improve performance which should reduce the problems with the queues, but they are for 2.6.6 and forward porting them to 2.6.11 is quite a bit of work (too much was changed in conflicting areas). I hope to get to work on this soon. The bad effect of the queue throttling was mostly the killed ack clock and the fact that recovery was only when timeout happened. Preferably only the packets that don't fit should be dropped, but the queue emptying should not be waited for. Baruch From davem@davemloft.net Thu Mar 3 13:29:31 2005 Received: with ECARTIS (v1.0.0; list netdev); Thu, 03 Mar 2005 13:29:36 -0800 (PST) Received: from cheetah.davemloft.net (mail@dsl027-180-174.sfo1.dsl.speakeasy.net [216.27.180.174]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j23LTVsC013094 for ; Thu, 3 Mar 2005 13:29:31 -0800 Received: from localhost ([127.0.0.1] helo=cheetah.davemloft.net ident=davem) by cheetah.davemloft.net with smtp (Exim 3.36 #1 (Debian)) id 1D6xsY-00081y-00; Thu, 03 Mar 2005 13:29:06 -0800 Date: Thu, 3 Mar 2005 13:29:06 -0800 From: "David S. Miller" To: Jeff Garzik Cc: mpm@selenic.com, netdev@oss.sgi.com, jmoyer@redhat.com Subject: Re: [PATCH 7/7] netpoll: avoid kfree_skb on packets with destructo Message-Id: <20050303132906.2b5d597f.davem@davemloft.net> In-Reply-To: <42277ED6.4020707@pobox.com> References: <7.454130102@selenic.com> <8.454130102@selenic.com> <20050303130031.066f0862.davem@davemloft.net> <42277ED6.4020707@pobox.com> X-Mailer: Sylpheed version 1.0.1 (GTK+ 1.2.10; sparc-unknown-linux-gnu) X-Face: "_;p5u5aPsO,_Vsx"^v-pEq09'CU4&Dc1$fQExov$62l60cgCc%FnIwD=.UF^a>?5'9Kn[;433QFVV9M..2eN.@4ZWPGbdi<=?[:T>y?SD(R*-3It"Vj:)"dP Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV 0.83/743/Wed Mar 2 16:02:05 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 2330 X-ecartis-version: Ecartis v1.0.0 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, 03 Mar 2005 16:17:10 -0500 Jeff Garzik wrote: > Heh, I was just writing this same message. > > On a related note... David, I would prefer if you merged up the netpoll > stuff, since it touches mainly net/* > > Is that cool w/ you? No problem. I still don't like this code in that it adds a locking penalty to everyone just by virtue of enabling netpoll. We've worked so hard with things like NETIF_F_LLTX to eliminate locking, so this would be a huge step backwards. From oxymoron@waste.org Thu Mar 3 13:32:34 2005 Received: with ECARTIS (v1.0.0; list netdev); Thu, 03 Mar 2005 13:32:38 -0800 (PST) Received: from waste.org (waste.org [216.27.176.166]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j23LWYmL013719 for ; Thu, 3 Mar 2005 13:32:34 -0800 Received: from waste.org (localhost [127.0.0.1]) by waste.org (8.13.2/8.13.2/Debian-1) with ESMTP id j23LWSaM006250 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Thu, 3 Mar 2005 15:32:28 -0600 Received: (from oxymoron@localhost) by waste.org (8.13.2/8.13.2/Submit) id j23LWSsW006247; Thu, 3 Mar 2005 15:32:28 -0600 Date: Thu, 3 Mar 2005 13:32:28 -0800 From: Matt Mackall To: "David S. Miller" Cc: jgarzik@pobox.com, netdev@oss.sgi.com, jmoyer@redhat.com Subject: Re: [PATCH 7/7] netpoll: avoid kfree_skb on packets with destructo Message-ID: <20050303213228.GU3120@waste.org> References: <7.454130102@selenic.com> <8.454130102@selenic.com> <20050303130031.066f0862.davem@davemloft.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20050303130031.066f0862.davem@davemloft.net> User-Agent: Mutt/1.5.6+20040907i X-Virus-Scanned: ClamAV 0.83/743/Wed Mar 2 16:02:05 2005 on oss.sgi.com X-Virus-Scanned: by amavisd-new X-Virus-Status: Clean X-archive-position: 2331 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: mpm@selenic.com Precedence: bulk X-list: netdev On Thu, Mar 03, 2005 at 01:00:31PM -0800, David S. Miller wrote: > On Thu, 03 Mar 2005 14:46:32 -0600 > Matt Mackall wrote: > > > Packets that have destructors should not be zapped here as that might > > produce additional printk warnings via netconsole. > > > > Signed-off-by: Matt Mackall > > Then where will they be freed, eh? :-) > > This patch adds an SKB leak. Since you've NULL'd out the list, any > SKB skipped will never be freed up at all. Doh. Plain as day. How's this look? Packets that have destructors should not be zapped here as that might produce additional printk warnings via netconsole. Signed-off-by: Matt Mackall Index: np/net/core/netpoll.c =================================================================== --- np.orig/net/core/netpoll.c 2005-03-03 14:16:29.579809668 -0600 +++ np/net/core/netpoll.c 2005-03-03 15:26:38.826754614 -0600 @@ -192,7 +192,10 @@ static void zap_completion_queue(void) while (clist != NULL) { struct sk_buff *skb = clist; clist = clist->next; - __kfree_skb(skb); + if(skb->destructor) + dev_kfree_skb_any(skb); /* put this one back */ + else + __kfree_skb(skb); } } -- Mathematics is the supreme nostalgia of our time. From davem@davemloft.net Thu Mar 3 13:33:22 2005 Received: with ECARTIS (v1.0.0; list netdev); Thu, 03 Mar 2005 13:33:27 -0800 (PST) Received: from cheetah.davemloft.net (mail@dsl027-180-174.sfo1.dsl.speakeasy.net [216.27.180.174]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j23LXMQb014082 for ; Thu, 3 Mar 2005 13:33:22 -0800 Received: from localhost ([127.0.0.1] helo=cheetah.davemloft.net ident=davem) by cheetah.davemloft.net with smtp (Exim 3.36 #1 (Debian)) id 1D6xvx-00085M-00; Thu, 03 Mar 2005 13:32:37 -0800 Date: Thu, 3 Mar 2005 13:32:37 -0800 From: "David S. Miller" To: hadi@cyberus.ca Cc: shemminger@osdl.org, rhee@eos.ncsu.edu, jheffner@psc.edu, Yee-Ting.Li@nuim.ie, baruch@ev-en.org, netdev@oss.sgi.com Subject: Re: netif_rx packet dumping Message-Id: <20050303133237.5d64578f.davem@davemloft.net> In-Reply-To: <1109885065.1098.285.camel@jzny.localdomain> References: <20050303123811.4d934249@dxpl.pdx.osdl.net> <20050303125556.6850cfe5.davem@davemloft.net> <1109884688.1090.282.camel@jzny.localdomain> <20050303132143.7eef517c@dxpl.pdx.osdl.net> <1109885065.1098.285.camel@jzny.localdomain> X-Mailer: Sylpheed version 1.0.1 (GTK+ 1.2.10; sparc-unknown-linux-gnu) X-Face: "_;p5u5aPsO,_Vsx"^v-pEq09'CU4&Dc1$fQExov$62l60cgCc%FnIwD=.UF^a>?5'9Kn[;433QFVV9M..2eN.@4ZWPGbdi<=?[:T>y?SD(R*-3It"Vj:)"dP Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV 0.83/743/Wed Mar 2 16:02:05 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 2332 X-ecartis-version: Ecartis v1.0.0 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 03 Mar 2005 16:24:25 -0500 jamal wrote: > Ok, this does sound more reasonable. Out of curiosity, are packets being > dropped at the socket queue? Why is "dump till empty" behaviour screwing > over TCP. Because it does the same thing tail-drop in routers do. It makes everything back off a lot and go into slow start. If we'd just drop 1 packet per flow or something like that (so it could be fixed with a quick fast retransmit), TCP would avoid regressing into slow start. You say "use a NAPI driver", but netif_rx() _IS_ a NAPI driver. process_backlog() adheres to quotas and every other stabilizing effect NAPI drivers use, the only missing part is the RX interrupt disabling. We should eliminate the max backlog thing completely. There is no need for it. From garzik@havoc.gtf.org Thu Mar 3 13:33:59 2005 Received: with ECARTIS (v1.0.0; list netdev); Thu, 03 Mar 2005 13:34:03 -0800 (PST) Received: from bastet.signetmail.com (atlmail.prod.rxgsys.com [64.74.124.160]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j23LXxS7014431 for ; Thu, 3 Mar 2005 13:33:59 -0800 Received: from localhost (localhost.localdomain [127.0.0.1]) by bastet.signetmail.com (RXG Elite Mail Server) with ESMTP id B6EBFA87A3; Thu, 3 Mar 2005 16:28:29 -0500 (EST) Received: from bastet.signetmail.com ([127.0.0.1]) by localhost (atlmail.prod.rxgsys.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 18031-04; Thu, 3 Mar 2005 16:28:25 -0500 (EST) Received: from havoc.gtf.org (havoc.gtf.org [63.115.148.101]) by bastet.signetmail.com (RXG Elite Mail Server) with ESMTP id 48588A87A0; Thu, 3 Mar 2005 16:28:22 -0500 (EST) Received: from havoc.gtf.org (havoc.gtf.org [127.0.0.1]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by havoc.gtf.org (Postfix) with ESMTP id 4E08E1C0A858; Thu, 3 Mar 2005 16:33:42 -0500 (EST) Received: (from garzik@localhost) by havoc.gtf.org (8.13.1/8.13.1/Submit) id j23LXfXh021149; Thu, 3 Mar 2005 16:33:41 -0500 Date: Thu, 3 Mar 2005 16:33:41 -0500 From: Jeff Garzik To: "David S. Miller" Cc: mpm@selenic.com, netdev@oss.sgi.com, jmoyer@redhat.com Subject: Re: [PATCH 7/7] netpoll: avoid kfree_skb on packets with destructo Message-ID: <20050303213341.GA21135@havoc.gtf.org> References: <7.454130102@selenic.com> <8.454130102@selenic.com> <20050303130031.066f0862.davem@davemloft.net> <42277ED6.4020707@pobox.com> <20050303132906.2b5d597f.davem@davemloft.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20050303132906.2b5d597f.davem@davemloft.net> User-Agent: Mutt/1.4.1i X-Virus-Scanned: ClamAV 0.83/743/Wed Mar 2 16:02:05 2005 on oss.sgi.com X-Virus-Scanned: by EMS at localhost.localdomain X-Virus-Status: Clean X-archive-position: 2333 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: jgarzik@pobox.com Precedence: bulk X-list: netdev On Thu, Mar 03, 2005 at 01:29:06PM -0800, David S. Miller wrote: > On Thu, 03 Mar 2005 16:17:10 -0500 > Jeff Garzik wrote: > > > Heh, I was just writing this same message. > > > > On a related note... David, I would prefer if you merged up the netpoll > > stuff, since it touches mainly net/* > > > > Is that cool w/ you? > > No problem. I still don't like this code in that it adds a locking > penalty to everyone just by virtue of enabling netpoll. We've worked > so hard with things like NETIF_F_LLTX to eliminate locking, so this > would be a huge step backwards. Agreed. Jeff From davem@davemloft.net Thu Mar 3 13:37:32 2005 Received: with ECARTIS (v1.0.0; list netdev); Thu, 03 Mar 2005 13:37:38 -0800 (PST) Received: from cheetah.davemloft.net (mail@dsl027-180-174.sfo1.dsl.speakeasy.net [216.27.180.174]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j23LbW4R015966 for ; Thu, 3 Mar 2005 13:37:32 -0800 Received: from localhost ([127.0.0.1] helo=cheetah.davemloft.net ident=davem) by cheetah.davemloft.net with smtp (Exim 3.36 #1 (Debian)) id 1D6y0B-00086k-00; Thu, 03 Mar 2005 13:36:59 -0800 Date: Thu, 3 Mar 2005 13:36:59 -0800 From: "David S. Miller" To: Baruch Even Cc: shemminger@osdl.org, rhee@eos.ncsu.edu, jheffner@psc.edu, Yee-Ting.Li@nuim.ie, netdev@oss.sgi.com Subject: Re: netif_rx packet dumping Message-Id: <20050303133659.0d224e61.davem@davemloft.net> In-Reply-To: <42278122.6000000@ev-en.org> References: <20050303123811.4d934249@dxpl.pdx.osdl.net> <42278122.6000000@ev-en.org> X-Mailer: Sylpheed version 1.0.1 (GTK+ 1.2.10; sparc-unknown-linux-gnu) X-Face: "_;p5u5aPsO,_Vsx"^v-pEq09'CU4&Dc1$fQExov$62l60cgCc%FnIwD=.UF^a>?5'9Kn[;433QFVV9M..2eN.@4ZWPGbdi<=?[:T>y?SD(R*-3It"Vj:)"dP Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV 0.83/743/Wed Mar 2 16:02:05 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 2335 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: davem@davemloft.net Precedence: bulk X-list: netdev Content-Length: 937 Lines: 19 On Thu, 03 Mar 2005 21:26:58 +0000 Baruch Even wrote: > I have patches for the SACK processing to improve performance which > should reduce the problems with the queues, but they are for 2.6.6 and > forward porting them to 2.6.11 is quite a bit of work (too much was > changed in conflicting areas). I hope to get to work on this soon. Please split up your patches properly this time. Last time you split up the patches, there was common changes in several of the patch files. It looked like you just hand edited the patches in order to split up the changes, or something like that, and it's very error prone and made review impossible. And I'm not accepting your changes if you're going to still add all that linked list stuff to the generic struct sk_buff. Adding anything new to sk_buff is going to make it straddle more L2 cache lines on ia64 and other 64-bit systems and that totally kills performance. From jgarzik@pobox.com Thu Mar 3 13:37:52 2005 Received: with ECARTIS (v1.0.0; list netdev); Thu, 03 Mar 2005 13:37:57 -0800 (PST) Received: from parcelfarce.linux.theplanet.co.uk (IDENT:93@parcelfarce.linux.theplanet.co.uk [195.92.249.252]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j23LbpZQ016115 for ; Thu, 3 Mar 2005 13:37:52 -0800 Received: from [69.134.152.124] (helo=[10.10.10.88]) by parcelfarce.linux.theplanet.co.uk with asmtp (TLSv1:AES256-SHA:256) (Exim 4.33) id 1D6y10-0002lO-DH; Thu, 03 Mar 2005 21:37:50 +0000 Message-ID: <4227839E.7010208@pobox.com> Date: Thu, 03 Mar 2005 16:37:34 -0500 From: Jeff Garzik User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.3) Gecko/20040922 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Stephen Hemminger CC: netdev@oss.sgi.com Subject: Re: [PATCH] (1/12) skge: use PFX string References: <20050303114557.6373662b@dxpl.pdx.osdl.net> In-Reply-To: <20050303114557.6373662b@dxpl.pdx.osdl.net> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV 0.83/743/Wed Mar 2 16:02:05 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 2336 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: jgarzik@pobox.com Precedence: bulk X-list: netdev Content-Length: 365 Lines: 16 Applied patches 1-12, but comments follow. Also, a procedural comment: Please place the "1/12" number _inside_ square brackets, like so: [PATCH 1/12] skge: use PFX string Reason: Everything inside the brackets is converted to the constant string "[PATCH]". With your submission, I had to hand-edit 12 comments, removing the "x/12" from each one. Jeff From oxymoron@waste.org Thu Mar 3 13:39:17 2005 Received: with ECARTIS (v1.0.0; list netdev); Thu, 03 Mar 2005 13:39:21 -0800 (PST) Received: from waste.org (waste.org [216.27.176.166]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j23LdH7W017034 for ; Thu, 3 Mar 2005 13:39:17 -0800 Received: from waste.org (localhost [127.0.0.1]) by waste.org (8.13.2/8.13.2/Debian-1) with ESMTP id j23LdB34006739 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Thu, 3 Mar 2005 15:39:11 -0600 Received: (from oxymoron@localhost) by waste.org (8.13.2/8.13.2/Submit) id j23LdBCJ006736; Thu, 3 Mar 2005 15:39:11 -0600 Date: Thu, 3 Mar 2005 13:39:11 -0800 From: Matt Mackall To: "David S. Miller" Cc: Jeff Garzik , netdev@oss.sgi.com, jmoyer@redhat.com Subject: Re: [PATCH 7/7] netpoll: avoid kfree_skb on packets with destructo Message-ID: <20050303213911.GV3120@waste.org> References: <7.454130102@selenic.com> <8.454130102@selenic.com> <20050303130031.066f0862.davem@davemloft.net> <42277ED6.4020707@pobox.com> <20050303132906.2b5d597f.davem@davemloft.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20050303132906.2b5d597f.davem@davemloft.net> User-Agent: Mutt/1.5.6+20040907i X-Virus-Scanned: ClamAV 0.83/743/Wed Mar 2 16:02:05 2005 on oss.sgi.com X-Virus-Scanned: by amavisd-new X-Virus-Status: Clean X-archive-position: 2337 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: mpm@selenic.com Precedence: bulk X-list: netdev Content-Length: 893 Lines: 24 On Thu, Mar 03, 2005 at 01:29:06PM -0800, David S. Miller wrote: > On Thu, 03 Mar 2005 16:17:10 -0500 > Jeff Garzik wrote: > > > Heh, I was just writing this same message. > > > > On a related note... David, I would prefer if you merged up the netpoll > > stuff, since it touches mainly net/* > > > > Is that cool w/ you? > > No problem. I still don't like this code in that it adds a locking > penalty to everyone just by virtue of enabling netpoll. We've worked > so hard with things like NETIF_F_LLTX to eliminate locking, so this > would be a huge step backwards. The lock only happens if CONFIG_NETPOLL=y _and_ a netpoll client (eg netconsole) is registered on the device in question. I'm certainly open to ideas that improve upon that, but everything I've come up with is equivalent in cost to a lock. -- Mathematics is the supreme nostalgia of our time. From jgarzik@pobox.com Thu Mar 3 13:41:24 2005 Received: with ECARTIS (v1.0.0; list netdev); Thu, 03 Mar 2005 13:41:28 -0800 (PST) Received: from parcelfarce.linux.theplanet.co.uk (IDENT:93@parcelfarce.linux.theplanet.co.uk [195.92.249.252]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j23LfN3D017649 for ; Thu, 3 Mar 2005 13:41:23 -0800 Received: from [69.134.152.124] (helo=[10.10.10.88]) by parcelfarce.linux.theplanet.co.uk with asmtp (TLSv1:AES256-SHA:256) (Exim 4.33) id 1D6y4Q-0002oz-IZ; Thu, 03 Mar 2005 21:41:22 +0000 Message-ID: <42278470.2070807@pobox.com> Date: Thu, 03 Mar 2005 16:41:04 -0500 From: Jeff Garzik User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.3) Gecko/20040922 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Stephen Hemminger CC: netdev@oss.sgi.com Subject: Re: [PATCH] (3/12) skge: remove unneeded include's References: <20050303113413.1bcd7476@dxpl.pdx.osdl.net> In-Reply-To: <20050303113413.1bcd7476@dxpl.pdx.osdl.net> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV 0.83/743/Wed Mar 2 16:02:05 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 2338 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: jgarzik@pobox.com Precedence: bulk X-list: netdev Content-Length: 464 Lines: 15 Stephen Hemminger wrote: > Get rid of unnecessary include's > > Signed-off-by: Stephen Hemminger > > --- skge-2.6.11/drivers/net/skge.c.orig 2005-03-02 17:15:44.000000000 -0800 > +++ skge-2.6.11/drivers/net/skge.c 2005-03-02 17:17:25.000000000 -0800 > @@ -30,13 +30,10 @@ > #include > #include > #include > -#include Why is this one is unnecessary? From davem@davemloft.net Thu Mar 3 13:41:43 2005 Received: with ECARTIS (v1.0.0; list netdev); Thu, 03 Mar 2005 13:41:48 -0800 (PST) Received: from cheetah.davemloft.net (mail@dsl027-180-174.sfo1.dsl.speakeasy.net [216.27.180.174]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j23Lfhx7017798 for ; Thu, 3 Mar 2005 13:41:43 -0800 Received: from localhost ([127.0.0.1] helo=cheetah.davemloft.net ident=davem) by cheetah.davemloft.net with smtp (Exim 3.36 #1 (Debian)) id 1D6y4N-0008AO-00; Thu, 03 Mar 2005 13:41:19 -0800 Date: Thu, 3 Mar 2005 13:41:19 -0800 From: "David S. Miller" To: Matt Mackall Cc: jgarzik@pobox.com, netdev@oss.sgi.com, jmoyer@redhat.com Subject: Re: [PATCH 7/7] netpoll: avoid kfree_skb on packets with destructo Message-Id: <20050303134119.64a24678.davem@davemloft.net> In-Reply-To: <20050303213911.GV3120@waste.org> References: <7.454130102@selenic.com> <8.454130102@selenic.com> <20050303130031.066f0862.davem@davemloft.net> <42277ED6.4020707@pobox.com> <20050303132906.2b5d597f.davem@davemloft.net> <20050303213911.GV3120@waste.org> X-Mailer: Sylpheed version 1.0.1 (GTK+ 1.2.10; sparc-unknown-linux-gnu) X-Face: "_;p5u5aPsO,_Vsx"^v-pEq09'CU4&Dc1$fQExov$62l60cgCc%FnIwD=.UF^a>?5'9Kn[;433QFVV9M..2eN.@4ZWPGbdi<=?[:T>y?SD(R*-3It"Vj:)"dP Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV 0.83/743/Wed Mar 2 16:02:05 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 2339 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: davem@davemloft.net Precedence: bulk X-list: netdev Content-Length: 459 Lines: 12 On Thu, 3 Mar 2005 13:39:11 -0800 Matt Mackall wrote: > The lock only happens if CONFIG_NETPOLL=y _and_ a netpoll client (eg > netconsole) is registered on the device in question. I actually missed that condition. This is less intrusive then. I'm actually ok with these changes therefore. I'll merge these patches in (with the SKB leak fix of course) and will push upstream once we work out how 2.6.x development is going to process :-) From baruch@ev-en.org Thu Mar 3 13:45:43 2005 Received: with ECARTIS (v1.0.0; list netdev); Thu, 03 Mar 2005 13:45:46 -0800 (PST) Received: from galon.ev-en.org (rrcs-24-123-59-149.central.biz.rr.com [24.123.59.149]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j23LjgIS018797 for ; Thu, 3 Mar 2005 13:45:42 -0800 Received: by galon.ev-en.org (Postfix, from userid 105) id 6479411A6C5; Thu, 3 Mar 2005 23:45:29 +0200 (IST) Received: from [10.220.3.66] (hamilton.nuim.ie [149.157.192.252]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by galon.ev-en.org (Postfix) with ESMTP id 7679E11A5E3; Thu, 3 Mar 2005 23:44:54 +0200 (IST) Message-ID: <42278554.2090902@ev-en.org> Date: Thu, 03 Mar 2005 21:44:52 +0000 From: Baruch Even User-Agent: Debian Thunderbird 1.0 (X11/20050116) X-Accept-Language: en-us, en MIME-Version: 1.0 To: "David S. Miller" Cc: shemminger@osdl.org, rhee@eos.ncsu.edu, jheffner@psc.edu, Yee-Ting.Li@nuim.ie, netdev@oss.sgi.com Subject: Re: netif_rx packet dumping References: <20050303123811.4d934249@dxpl.pdx.osdl.net> <42278122.6000000@ev-en.org> <20050303133659.0d224e61.davem@davemloft.net> In-Reply-To: <20050303133659.0d224e61.davem@davemloft.net> X-Enigmail-Version: 0.90.0.0 X-Enigmail-Supports: pgp-inline, pgp-mime Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV 0.83/743/Wed Mar 2 16:02:05 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 2340 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: baruch@ev-en.org Precedence: bulk X-list: netdev Content-Length: 1478 Lines: 34 David S. Miller wrote: > On Thu, 03 Mar 2005 21:26:58 +0000 > Baruch Even wrote: > > >>I have patches for the SACK processing to improve performance which >>should reduce the problems with the queues, but they are for 2.6.6 and >>forward porting them to 2.6.11 is quite a bit of work (too much was >>changed in conflicting areas). I hope to get to work on this soon. > > Please split up your patches properly this time. Last time you > split up the patches, there was common changes in several of the > patch files. It looked like you just hand edited the patches in > order to split up the changes, or something like that, and it's > very error prone and made review impossible. That was before my time, I've cleaned that up since then. > And I'm not accepting your changes if you're going to still add all > that linked list stuff to the generic struct sk_buff. Adding anything > new to sk_buff is going to make it straddle more L2 cache lines on > ia64 and other 64-bit systems and that totally kills performance. That's a bit more of a problem, that's the exact performance improvement we are trying to add! The current linked list goes over all the packets, the linked list we add is for the packets that were not SACKed. The idea being that it is a lot faster since there are a lot less packets not SACKed compared to packets already SACKed (or never mentioned in SACKs). If you have a way around this I'd be happy to hear it. Baruch From SRS0+3adda190aff1262ee5ac+557+infradead.org+hch@pentafluge.srs.infradead.org Thu Mar 3 13:51:24 2005 Received: with ECARTIS (v1.0.0; list netdev); Thu, 03 Mar 2005 13:51:30 -0800 (PST) Received: from pentafluge.infradead.org (pentafluge.infradead.org [213.146.154.40]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j23LpN48019837 for ; Thu, 3 Mar 2005 13:51:24 -0800 Received: from hch by pentafluge.infradead.org with local (Exim 4.43 #1 (Red Hat Linux)) id 1D6yE0-0004Cy-Pr; Thu, 03 Mar 2005 21:51:16 +0000 Date: Thu, 3 Mar 2005 21:51:16 +0000 From: Christoph Hellwig To: Jeff Garzik Cc: Stephen Hemminger , netdev@oss.sgi.com Subject: Re: [PATCH] (3/12) skge: remove unneeded include's Message-ID: <20050303215116.GA16132@infradead.org> References: <20050303113413.1bcd7476@dxpl.pdx.osdl.net> <42278470.2070807@pobox.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <42278470.2070807@pobox.com> User-Agent: Mutt/1.4.1i X-SRS-Rewrite: SMTP reverse-path rewritten from by pentafluge.infradead.org See http://www.infradead.org/rpr.html X-Virus-Scanned: ClamAV 0.83/743/Wed Mar 2 16:02:05 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 2341 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: hch@infradead.org Precedence: bulk X-list: netdev Content-Length: 641 Lines: 20 On Thu, Mar 03, 2005 at 04:41:04PM -0500, Jeff Garzik wrote: > Stephen Hemminger wrote: > >Get rid of unnecessary include's > > > >Signed-off-by: Stephen Hemminger > > > >--- skge-2.6.11/drivers/net/skge.c.orig 2005-03-02 > >17:15:44.000000000 -0800 > >+++ skge-2.6.11/drivers/net/skge.c 2005-03-02 17:17:25.000000000 -0800 > >@@ -30,13 +30,10 @@ > > #include > > #include > > #include > >-#include > > Why is this one is unnecessary? Becasue the driver is using the pci_ variants of the dma mapping routines, which are in pci.h From ak@muc.de Thu Mar 3 13:54:27 2005 Received: with ECARTIS (v1.0.0; list netdev); Thu, 03 Mar 2005 13:54:32 -0800 (PST) Received: from one.firstfloor.org (one.firstfloor.org [213.235.205.2]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j23LsQI9020518 for ; Thu, 3 Mar 2005 13:54:27 -0800 Received: by one.firstfloor.org (Postfix, from userid 502) id 3ED09D033E; Thu, 3 Mar 2005 22:54:24 +0100 (CET) To: Baruch Even Cc: shemminger@osdl.org, rhee@eos.ncsu.edu, jheffner@psc.edu, Yee-Ting.Li@nuim.ie, netdev@oss.sgi.com Subject: Re: netif_rx packet dumping References: <20050303123811.4d934249@dxpl.pdx.osdl.net> <42278122.6000000@ev-en.org> <20050303133659.0d224e61.davem@davemloft.net> <42278554.2090902@ev-en.org> From: Andi Kleen Date: Thu, 03 Mar 2005 22:54:24 +0100 In-Reply-To: <42278554.2090902@ev-en.org> (Baruch Even's message of "Thu, 03 Mar 2005 21:44:52 +0000") Message-ID: User-Agent: Gnus/5.110002 (No Gnus v0.2) Emacs/21.3 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Virus-Scanned: ClamAV 0.83/743/Wed Mar 2 16:02:05 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 2342 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: ak@muc.de Precedence: bulk X-list: netdev Content-Length: 178 Lines: 8 Baruch Even writes: > > If you have a way around this I'd be happy to hear it. There may be free space left over in skb->cb that you can use for this. -Andi From shemminger@osdl.org Thu Mar 3 13:55:03 2005 Received: with ECARTIS (v1.0.0; list netdev); Thu, 03 Mar 2005 13:55:09 -0800 (PST) Received: from smtp.osdl.org (fire.osdl.org [65.172.181.4]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j23Lt1Lj020767 for ; Thu, 3 Mar 2005 13:55:02 -0800 Received: from shell0.pdx.osdl.net (fw.osdl.org [65.172.181.6]) by smtp.osdl.org (8.12.8/8.12.8) with ESMTP id j23Ls0qi018914 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO); Thu, 3 Mar 2005 13:54:00 -0800 Received: from dxpl.pdx.osdl.net (dxpl.pdx.osdl.net [172.20.1.103]) by shell0.pdx.osdl.net (8.13.1/8.11.6) with ESMTP id j23Ls0ka024837; Thu, 3 Mar 2005 13:54:00 -0800 Date: Thu, 3 Mar 2005 13:54:16 -0800 From: Stephen Hemminger To: "David S. Miller" Cc: hadi@cyberus.ca, rhee@eos.ncsu.edu, jheffner@psc.edu, Yee-Ting.Li@nuim.ie, baruch@ev-en.org, netdev@oss.sgi.com Subject: Re: netif_rx packet dumping Message-ID: <20050303135416.0d6e7708@dxpl.pdx.osdl.net> In-Reply-To: <20050303133237.5d64578f.davem@davemloft.net> References: <20050303123811.4d934249@dxpl.pdx.osdl.net> <20050303125556.6850cfe5.davem@davemloft.net> <1109884688.1090.282.camel@jzny.localdomain> <20050303132143.7eef517c@dxpl.pdx.osdl.net> <1109885065.1098.285.camel@jzny.localdomain> <20050303133237.5d64578f.davem@davemloft.net> Organization: Open Source Development Lab X-Mailer: Sylpheed-Claws 1.0.1 (GTK+ 1.2.10; x86_64-unknown-linux-gnu) X-Face: &@E+xe?c%:&e4D{>f1O<&U>2qwRREG5!}7R4;D<"NO^UI2mJ[eEOA2*3>(`Th.yP,VDPo9$ /`~cw![cmj~~jWe?AHY7D1S+\}5brN0k*NE?pPh_'_d>6;XGG[\KDRViCfumZT3@[ Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Received-SPF: pass (domain of shemminger@osdl.org designates 65.172.181.6 as permitted sender) X-MIMEDefang-Filter: osdl$Revision: 1.104 $ X-Scanned-By: MIMEDefang 2.36 X-Virus-Scanned: ClamAV 0.83/743/Wed Mar 2 16:02:05 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 2343 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: shemminger@osdl.org Precedence: bulk X-list: netdev Content-Length: 1121 Lines: 29 On Thu, 3 Mar 2005 13:32:37 -0800 "David S. Miller" wrote: > On 03 Mar 2005 16:24:25 -0500 > jamal wrote: > > > Ok, this does sound more reasonable. Out of curiosity, are packets being > > dropped at the socket queue? Why is "dump till empty" behaviour screwing > > over TCP. > > Because it does the same thing tail-drop in routers do. > It makes everything back off a lot and go into slow start. > If we'd just drop 1 packet per flow or something like that > (so it could be fixed with a quick fast retransmit), TCP > would avoid regressing into slow start. Maybe a simple Random Exponential Drop (RED) would be more friendly. > You say "use a NAPI driver", but netif_rx() _IS_ a NAPI driver. > process_backlog() adheres to quotas and every other stabilizing > effect NAPI drivers use, the only missing part is the RX interrupt > disabling. > > We should eliminate the max backlog thing completely. There is > no need for it. Still need some bound, because if process_backlog is running slower than the net; then the queue could grow till memory exhausted from skbuff's. From davem@davemloft.net Thu Mar 3 13:57:57 2005 Received: with ECARTIS (v1.0.0; list netdev); Thu, 03 Mar 2005 13:58:00 -0800 (PST) Received: from cheetah.davemloft.net (mail@dsl027-180-174.sfo1.dsl.speakeasy.net [216.27.180.174]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j23LvuP0021788 for ; Thu, 3 Mar 2005 13:57:56 -0800 Received: from localhost ([127.0.0.1] helo=cheetah.davemloft.net ident=davem) by cheetah.davemloft.net with smtp (Exim 3.36 #1 (Debian)) id 1D6yJq-0008Gb-00; Thu, 03 Mar 2005 13:57:18 -0800 Date: Thu, 3 Mar 2005 13:57:18 -0800 From: "David S. Miller" To: Baruch Even Cc: shemminger@osdl.org, rhee@eos.ncsu.edu, jheffner@psc.edu, Yee-Ting.Li@nuim.ie, netdev@oss.sgi.com Subject: Re: netif_rx packet dumping Message-Id: <20050303135718.2e1a0170.davem@davemloft.net> In-Reply-To: <42278554.2090902@ev-en.org> References: <20050303123811.4d934249@dxpl.pdx.osdl.net> <42278122.6000000@ev-en.org> <20050303133659.0d224e61.davem@davemloft.net> <42278554.2090902@ev-en.org> X-Mailer: Sylpheed version 1.0.1 (GTK+ 1.2.10; sparc-unknown-linux-gnu) X-Face: "_;p5u5aPsO,_Vsx"^v-pEq09'CU4&Dc1$fQExov$62l60cgCc%FnIwD=.UF^a>?5'9Kn[;433QFVV9M..2eN.@4ZWPGbdi<=?[:T>y?SD(R*-3It"Vj:)"dP Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV 0.83/743/Wed Mar 2 16:02:05 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 2344 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: davem@davemloft.net Precedence: bulk X-list: netdev Content-Length: 748 Lines: 20 On Thu, 03 Mar 2005 21:44:52 +0000 Baruch Even wrote: > The current linked list goes over all the packets, the linked list we > add is for the packets that were not SACKed. The idea being that it is a > lot faster since there are a lot less packets not SACKed compared to > packets already SACKed (or never mentioned in SACKs). > > If you have a way around this I'd be happy to hear it. I'm sure you can find a way to steal sizeof(void *) from "struct tcp_skb_cb" :-) It is currently 36 bytes on both 32-bit and 64-bit platforms. This means if you can squeeze out 4 bytes (so that it fits in the skb->cb[] 40 byte area), you can fit a pointer in there for the linked list stuff. I'll try to brain storm on this as well. From hadi@cyberus.ca Thu Mar 3 14:01:46 2005 Received: with ECARTIS (v1.0.0; list netdev); Thu, 03 Mar 2005 14:01:51 -0800 (PST) Received: from mx03.cybersurf.com (mx03.cybersurf.com [209.197.145.106]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j23M1jQ9022621 for ; Thu, 3 Mar 2005 14:01:45 -0800 Received: from mail.cyberus.ca ([209.197.145.21]) by mx03.cybersurf.com with esmtp (Exim 4.30) id 1D6yO9-0001tu-W8 for netdev@oss.sgi.com; Thu, 03 Mar 2005 17:01:45 -0500 Received: from [24.103.99.32] (helo=[10.0.0.9]) by mail.cyberus.ca with esmtp (Exim 4.20) id 1D6yO5-0005q4-BB; Thu, 03 Mar 2005 17:01:41 -0500 Subject: Re: netif_rx packet dumping From: jamal Reply-To: hadi@cyberus.ca To: "David S. Miller" Cc: shemminger@osdl.org, rhee@eos.ncsu.edu, jheffner@psc.edu, Yee-Ting.Li@nuim.ie, baruch@ev-en.org, netdev@oss.sgi.com In-Reply-To: <20050303133237.5d64578f.davem@davemloft.net> References: <20050303123811.4d934249@dxpl.pdx.osdl.net> <20050303125556.6850cfe5.davem@davemloft.net> <1109884688.1090.282.camel@jzny.localdomain> <20050303132143.7eef517c@dxpl.pdx.osdl.net> <1109885065.1098.285.camel@jzny.localdomain> <20050303133237.5d64578f.davem@davemloft.net> Content-Type: text/plain Organization: jamalopolous Message-Id: <1109887297.1098.329.camel@jzny.localdomain> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.2.2 Date: 03 Mar 2005 17:01:37 -0500 Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV 0.83/743/Wed Mar 2 16:02:05 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 2345 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: hadi@cyberus.ca Precedence: bulk X-list: netdev Content-Length: 1478 Lines: 36 On Thu, 2005-03-03 at 16:32, David S. Miller wrote: > On 03 Mar 2005 16:24:25 -0500 > jamal wrote: > > > Ok, this does sound more reasonable. Out of curiosity, are packets being > > dropped at the socket queue? Why is "dump till empty" behaviour screwing > > over TCP. > > Because it does the same thing tail-drop in routers do. > It makes everything back off a lot and go into slow start. > If we'd just drop 1 packet per flow or something like that > (so it could be fixed with a quick fast retransmit), TCP > would avoid regressing into slow start. > > You say "use a NAPI driver", but netif_rx() _IS_ a NAPI driver. > process_backlog() adheres to quotas and every other stabilizing > effect NAPI drivers use, the only missing part is the RX interrupt > disabling. > Thats true; but it's the RX interrupt disabling that worries me. And the fact that memory is finite. Let me throw some worst case scenarios: In the (ahem) "old" days when 100Mbps was hip, 148kpps (translate to about 1-2 interupts per packet) you pretty much fill that queue pretty quickly before it is processed. You could say the pentium-2 class used then was "slow" - but it is probably same compute capacity as most of the embedded systems out there today. On Gige we are talking about queueing upto 100K packets per ethx. I realize i am using unreasonable worst case but it becomes eventually a choice of when to stop accepting packets in order to maintain sanity. cheers, jamal From jheffner@psc.edu Thu Mar 3 14:02:58 2005 Received: with ECARTIS (v1.0.0; list netdev); Thu, 03 Mar 2005 14:03:01 -0800 (PST) Received: from mailer2.psc.edu (mailer2.psc.edu [128.182.66.106]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j23M2vXG023151 for ; Thu, 3 Mar 2005 14:02:58 -0800 Received: from tesla.psc.edu (tesla.psc.edu [128.182.61.233]) by mailer2.psc.edu (8.13.3/8.13.3) with ESMTP id j23M2okE002494 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 3 Mar 2005 17:02:50 -0500 (EST) Received: from tesla.psc.edu (localhost.psc.edu [127.0.0.1]) by tesla.psc.edu (8.12.11/8.12.10) with ESMTP id j23M2d6N023485; Thu, 3 Mar 2005 17:02:39 -0500 Received: from localhost (jheffner@localhost) by tesla.psc.edu (8.12.11/8.12.11/Submit) with ESMTP id j23M2duA023482; Thu, 3 Mar 2005 17:02:39 -0500 X-Authentication-Warning: tesla.psc.edu: jheffner owned process doing -bs Date: Thu, 3 Mar 2005 17:02:39 -0500 (EST) From: John Heffner To: Stephen Hemminger cc: "David S. Miller" , hadi@cyberus.ca, rhee@eos.ncsu.edu, Yee-Ting.Li@nuim.ie, baruch@ev-en.org, netdev@oss.sgi.com Subject: Re: netif_rx packet dumping In-Reply-To: <20050303135416.0d6e7708@dxpl.pdx.osdl.net> Message-ID: References: <20050303123811.4d934249@dxpl.pdx.osdl.net> <20050303125556.6850cfe5.davem@davemloft.net> <1109884688.1090.282.camel@jzny.localdomain> <20050303132143.7eef517c@dxpl.pdx.osdl.net> <1109885065.1098.285.camel@jzny.localdomain> <20050303133237.5d64578f.davem@davemloft.net> <20050303135416.0d6e7708@dxpl.pdx.osdl.net> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Scanned-By: MIMEDefang 2.49 on 128.182.66.106 X-Virus-Scanned: ClamAV 0.83/743/Wed Mar 2 16:02:05 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 2346 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: jheffner@psc.edu Precedence: bulk X-list: netdev Content-Length: 983 Lines: 26 On Thu, 3 Mar 2005, Stephen Hemminger wrote: > On Thu, 3 Mar 2005 13:32:37 -0800 > "David S. Miller" wrote: > > > On 03 Mar 2005 16:24:25 -0500 > > jamal wrote: > > > > > Ok, this does sound more reasonable. Out of curiosity, are packets being > > > dropped at the socket queue? Why is "dump till empty" behaviour screwing > > > over TCP. > > > > Because it does the same thing tail-drop in routers do. > > It makes everything back off a lot and go into slow start. > > If we'd just drop 1 packet per flow or something like that > > (so it could be fixed with a quick fast retransmit), TCP > > would avoid regressing into slow start. > > Maybe a simple Random Exponential Drop (RED) would be more friendly. That would probably not be appropriate. This queue is only for absorbing micro-scale bursts. It should not hold any data in steady state like a router queue can. The receive window can handle the macro scale flow control. -John From hadi@cyberus.ca Thu Mar 3 14:03:14 2005 Received: with ECARTIS (v1.0.0; list netdev); Thu, 03 Mar 2005 14:03:17 -0800 (PST) Received: from mx04.cybersurf.com (mx04.cybersurf.com [209.197.145.108]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j23M3D0e023226 for ; Thu, 3 Mar 2005 14:03:14 -0800 Received: from mail.cyberus.ca ([209.197.145.21]) by mx01.cybersurf.com with esmtp (Exim 4.30) id 1D6yPX-0008EU-La for netdev@oss.sgi.com; Thu, 03 Mar 2005 17:03:11 -0500 Received: from [24.103.99.32] (helo=[10.0.0.9]) by mail.cyberus.ca with esmtp (Exim 4.20) id 1D6yPW-000618-B0; Thu, 03 Mar 2005 17:03:10 -0500 Subject: Re: netif_rx packet dumping From: jamal Reply-To: hadi@cyberus.ca To: Baruch Even Cc: Stephen Hemminger , Injong Rhee , John Heffner , "David S. Miller" , Yee-Ting Li , netdev@oss.sgi.com In-Reply-To: <42278122.6000000@ev-en.org> References: <20050303123811.4d934249@dxpl.pdx.osdl.net> <42278122.6000000@ev-en.org> Content-Type: text/plain Organization: jamalopolous Message-Id: <1109887386.1092.333.camel@jzny.localdomain> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.2.2 Date: 03 Mar 2005 17:03:06 -0500 Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV 0.83/743/Wed Mar 2 16:02:05 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 2347 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: hadi@cyberus.ca Precedence: bulk X-list: netdev Content-Length: 632 Lines: 16 On Thu, 2005-03-03 at 16:26, Baruch Even wrote: > NAPI was not used because it caused skews in the performance, I haven't > tested it myself, just passing hearsay. It will help to post on this list when such issues are noticed. It could be a simple a driver bug: such a the one posted on by Lennert 2 days ago on e1000 NAPI - such a bug could have had serious repurcasions on TCP because it sat on packets in DMA occasionally upto 2 seconds. Seems like that bug has been sitting there for a long time. What kernel version? What kind of skews? Is it possible you tell this person to repeat the tests with 2.6.11? cheers, jamal From davem@davemloft.net Thu Mar 3 14:05:13 2005 Received: with ECARTIS (v1.0.0; list netdev); Thu, 03 Mar 2005 14:05:18 -0800 (PST) Received: from cheetah.davemloft.net (mail@dsl027-180-174.sfo1.dsl.speakeasy.net [216.27.180.174]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j23M5Dmw024238 for ; Thu, 3 Mar 2005 14:05:13 -0800 Received: from localhost ([127.0.0.1] helo=cheetah.davemloft.net ident=davem) by cheetah.davemloft.net with smtp (Exim 3.36 #1 (Debian)) id 1D6yQn-0008ID-00; Thu, 03 Mar 2005 14:04:29 -0800 Date: Thu, 3 Mar 2005 14:04:29 -0800 From: "David S. Miller" To: Andi Kleen Cc: baruch@ev-en.org, shemminger@osdl.org, rhee@eos.ncsu.edu, jheffner@psc.edu, Yee-Ting.Li@nuim.ie, netdev@oss.sgi.com Subject: Re: netif_rx packet dumping Message-Id: <20050303140429.1aac962e.davem@davemloft.net> In-Reply-To: References: <20050303123811.4d934249@dxpl.pdx.osdl.net> <42278122.6000000@ev-en.org> <20050303133659.0d224e61.davem@davemloft.net> <42278554.2090902@ev-en.org> X-Mailer: Sylpheed version 1.0.1 (GTK+ 1.2.10; sparc-unknown-linux-gnu) X-Face: "_;p5u5aPsO,_Vsx"^v-pEq09'CU4&Dc1$fQExov$62l60cgCc%FnIwD=.UF^a>?5'9Kn[;433QFVV9M..2eN.@4ZWPGbdi<=?[:T>y?SD(R*-3It"Vj:)"dP Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV 0.83/743/Wed Mar 2 16:02:05 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 2348 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: davem@davemloft.net Precedence: bulk X-list: netdev Content-Length: 354 Lines: 13 On Thu, 03 Mar 2005 22:54:24 +0100 Andi Kleen wrote: > Baruch Even writes: > > > > If you have a way around this I'd be happy to hear it. > > There may be free space left over in skb->cb that you can use > for this. There is 4 bytes, enough for 32-bit but not 64-bit platforms. Also, see my other reply to his posting. From baruch@ev-en.org Thu Mar 3 14:14:47 2005 Received: with ECARTIS (v1.0.0; list netdev); Thu, 03 Mar 2005 14:14:51 -0800 (PST) Received: from galon.ev-en.org (rrcs-24-123-59-149.central.biz.rr.com [24.123.59.149]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j23MEk7E025291 for ; Thu, 3 Mar 2005 14:14:46 -0800 Received: by galon.ev-en.org (Postfix, from userid 105) id B82E511A697; Fri, 4 Mar 2005 00:14:40 +0200 (IST) Received: from [10.220.3.66] (hamilton.nuim.ie [149.157.192.252]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by galon.ev-en.org (Postfix) with ESMTP id E670711A5E3; Fri, 4 Mar 2005 00:14:36 +0200 (IST) Message-ID: <42278C4B.2030701@ev-en.org> Date: Thu, 03 Mar 2005 22:14:35 +0000 From: Baruch Even User-Agent: Debian Thunderbird 1.0 (X11/20050116) X-Accept-Language: en-us, en MIME-Version: 1.0 To: "David S. Miller" Cc: shemminger@osdl.org, rhee@eos.ncsu.edu, jheffner@psc.edu, Yee-Ting.Li@nuim.ie, netdev@oss.sgi.com Subject: Re: netif_rx packet dumping References: <20050303123811.4d934249@dxpl.pdx.osdl.net> <42278122.6000000@ev-en.org> <20050303133659.0d224e61.davem@davemloft.net> <42278554.2090902@ev-en.org> <20050303135718.2e1a0170.davem@davemloft.net> In-Reply-To: <20050303135718.2e1a0170.davem@davemloft.net> X-Enigmail-Version: 0.90.0.0 X-Enigmail-Supports: pgp-inline, pgp-mime Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV 0.83/743/Wed Mar 2 16:02:05 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 2349 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: baruch@ev-en.org Precedence: bulk X-list: netdev Content-Length: 1036 Lines: 27 David S. Miller wrote: > On Thu, 03 Mar 2005 21:44:52 +0000 > Baruch Even wrote: > > >>The current linked list goes over all the packets, the linked list we >>add is for the packets that were not SACKed. The idea being that it is a >>lot faster since there are a lot less packets not SACKed compared to >>packets already SACKed (or never mentioned in SACKs). >> >>If you have a way around this I'd be happy to hear it. > > I'm sure you can find a way to steal sizeof(void *) from > "struct tcp_skb_cb" :-) > > It is currently 36 bytes on both 32-bit and 64-bit platforms. > This means if you can squeeze out 4 bytes (so that it fits > in the skb->cb[] 40 byte area), you can fit a pointer in there > for the linked list stuff. Stephen has a patch to move some of the extra congestion control data to their own struct, that would free some space for me :-) I'll need to take a look at this again, the original patch actually increased the number of bytes for the cb from 40 to get some extra space. Baruch From hadi@cyberus.ca Thu Mar 3 14:27:00 2005 Received: with ECARTIS (v1.0.0; list netdev); Thu, 03 Mar 2005 14:27:03 -0800 (PST) Received: from mx04.cybersurf.com (mx04.cybersurf.com [209.197.145.108]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j23MQxKc026162 for ; Thu, 3 Mar 2005 14:26:59 -0800 Received: from mail.cyberus.ca ([209.197.145.21]) by mx01.cybersurf.com with esmtp (Exim 4.30) id 1D6ymX-000284-7o for netdev@oss.sgi.com; Thu, 03 Mar 2005 17:26:57 -0500 Received: from [24.103.99.32] (helo=[10.0.0.9]) by mail.cyberus.ca with esmtp (Exim 4.20) id 1D6ymV-00013Q-AP; Thu, 03 Mar 2005 17:26:55 -0500 Subject: Re: netif_rx packet dumping From: jamal Reply-To: hadi@cyberus.ca To: John Heffner Cc: Stephen Hemminger , "David S. Miller" , rhee@eos.ncsu.edu, Yee-Ting.Li@nuim.ie, baruch@ev-en.org, netdev@oss.sgi.com In-Reply-To: References: <20050303123811.4d934249@dxpl.pdx.osdl.net> <20050303125556.6850cfe5.davem@davemloft.net> <1109884688.1090.282.camel@jzny.localdomain> <20050303132143.7eef517c@dxpl.pdx.osdl.net> <1109885065.1098.285.camel@jzny.localdomain> <20050303133237.5d64578f.davem@davemloft.net> <20050303135416.0d6e7708@dxpl.pdx.osdl.net> Content-Type: text/plain Organization: jamalopolous Message-Id: <1109888811.1092.352.camel@jzny.localdomain> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.2.2 Date: 03 Mar 2005 17:26:51 -0500 Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV 0.83/743/Wed Mar 2 16:02:05 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 2350 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: hadi@cyberus.ca Precedence: bulk X-list: netdev Content-Length: 946 Lines: 22 On Thu, 2005-03-03 at 17:02, John Heffner wrote: > On Thu, 3 Mar 2005, Stephen Hemminger wrote: > > Maybe a simple Random Exponential Drop (RED) would be more friendly. > > That would probably not be appropriate. This queue is only for absorbing > micro-scale bursts. It should not hold any data in steady state like a > router queue can. The receive window can handle the macro scale flow > control. recall this is a queue that is potentially shared by many many flows from potentially many many interfaces i.e it deals with many many micro-scale bursts. Clearly, the best approach is to have lots and lots of memmory and to make that queue real huge so it can cope with all of them all the time. We dont have that luxury - If you restrict the queue size, you will have to drop packets... Which ones? Probably simplest solution is to leave it as is right now and just adjust the contraints based on your system memmory etc. cheers, jamal From baruch@ev-en.org Thu Mar 3 14:31:43 2005 Received: with ECARTIS (v1.0.0; list netdev); Thu, 03 Mar 2005 14:31:46 -0800 (PST) Received: from galon.ev-en.org (rrcs-24-123-59-149.central.biz.rr.com [24.123.59.149]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j23MVg6x026805 for ; Thu, 3 Mar 2005 14:31:43 -0800 Received: by galon.ev-en.org (Postfix, from userid 105) id B599E11A697; Fri, 4 Mar 2005 00:31:36 +0200 (IST) Received: from [10.220.3.66] (hamilton.nuim.ie [149.157.192.252]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by galon.ev-en.org (Postfix) with ESMTP id E7E3E11A5E3; Fri, 4 Mar 2005 00:31:30 +0200 (IST) Message-ID: <42279040.5050003@ev-en.org> Date: Thu, 03 Mar 2005 22:31:28 +0000 From: Baruch Even User-Agent: Debian Thunderbird 1.0 (X11/20050116) X-Accept-Language: en-us, en MIME-Version: 1.0 To: hadi@cyberus.ca Cc: Stephen Hemminger , Injong Rhee , John Heffner , "David S. Miller" , Yee-Ting Li , netdev@oss.sgi.com Subject: Re: netif_rx packet dumping References: <20050303123811.4d934249@dxpl.pdx.osdl.net> <42278122.6000000@ev-en.org> <1109887386.1092.333.camel@jzny.localdomain> In-Reply-To: <1109887386.1092.333.camel@jzny.localdomain> X-Enigmail-Version: 0.90.0.0 X-Enigmail-Supports: pgp-inline, pgp-mime Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV 0.83/743/Wed Mar 2 16:02:05 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 2351 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: baruch@ev-en.org Precedence: bulk X-list: netdev Content-Length: 862 Lines: 21 jamal wrote: > On Thu, 2005-03-03 at 16:26, Baruch Even wrote: > > >>NAPI was not used because it caused skews in the performance, I haven't >>tested it myself, just passing hearsay. > > It will help to post on this list when such issues are noticed. > It could be a simple a driver bug: such a the one posted on by Lennert 2 > days ago on e1000 NAPI - such a bug could have had serious repurcasions > on TCP because it sat on packets in DMA occasionally upto 2 seconds. > Seems like that bug has been sitting there for a long time. > What kernel version? What kind of skews? > Is it possible you tell this person to repeat the tests with 2.6.11? I have asked around but there is no hard data to substantiate the claim at this time. And since then all tests were done non-NAPI style. Kernel versions were probably 2.4.23 or some other 2.4 kernel. Baruch From shemminger@osdl.org Thu Mar 3 15:16:41 2005 Received: with ECARTIS (v1.0.0; list netdev); Thu, 03 Mar 2005 15:16:47 -0800 (PST) Received: from smtp.osdl.org (fire.osdl.org [65.172.181.4]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j23NGd9A031834 for ; Thu, 3 Mar 2005 15:16:41 -0800 Received: from shell0.pdx.osdl.net (fw.osdl.org [65.172.181.6]) by smtp.osdl.org (8.12.8/8.12.8) with ESMTP id j23NFoqi026383 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO); Thu, 3 Mar 2005 15:15:51 -0800 Received: from dxpl.pdx.osdl.net (dxpl.pdx.osdl.net [172.20.1.103]) by shell0.pdx.osdl.net (8.13.1/8.11.6) with ESMTP id j23NFoJs029579; Thu, 3 Mar 2005 15:15:50 -0800 Date: Thu, 3 Mar 2005 15:16:06 -0800 From: Stephen Hemminger To: hadi@cyberus.ca Cc: John Heffner , "David S. Miller" , rhee@eos.ncsu.edu, Yee-Ting.Li@nuim.ie, baruch@ev-en.org, netdev@oss.sgi.com Subject: Re: netif_rx packet dumping Message-ID: <20050303151606.3587394f@dxpl.pdx.osdl.net> In-Reply-To: <1109888811.1092.352.camel@jzny.localdomain> References: <20050303123811.4d934249@dxpl.pdx.osdl.net> <20050303125556.6850cfe5.davem@davemloft.net> <1109884688.1090.282.camel@jzny.localdomain> <20050303132143.7eef517c@dxpl.pdx.osdl.net> <1109885065.1098.285.camel@jzny.localdomain> <20050303133237.5d64578f.davem@davemloft.net> <20050303135416.0d6e7708@dxpl.pdx.osdl.net> <1109888811.1092.352.camel@jzny.localdomain> Organization: Open Source Development Lab X-Mailer: Sylpheed-Claws 1.0.1 (GTK+ 1.2.10; x86_64-unknown-linux-gnu) X-Face: &@E+xe?c%:&e4D{>f1O<&U>2qwRREG5!}7R4;D<"NO^UI2mJ[eEOA2*3>(`Th.yP,VDPo9$ /`~cw![cmj~~jWe?AHY7D1S+\}5brN0k*NE?pPh_'_d>6;XGG[\KDRViCfumZT3@[ Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Received-SPF: pass (domain of shemminger@osdl.org designates 65.172.181.6 as permitted sender) X-MIMEDefang-Filter: osdl$Revision: 1.104 $ X-Scanned-By: MIMEDefang 2.36 X-Virus-Scanned: ClamAV 0.83/743/Wed Mar 2 16:02:05 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 2352 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: shemminger@osdl.org Precedence: bulk X-list: netdev Content-Length: 1271 Lines: 27 On 03 Mar 2005 17:26:51 -0500 jamal wrote: > On Thu, 2005-03-03 at 17:02, John Heffner wrote: > > On Thu, 3 Mar 2005, Stephen Hemminger wrote: > > > Maybe a simple Random Exponential Drop (RED) would be more friendly. > > > > That would probably not be appropriate. This queue is only for absorbing > > micro-scale bursts. It should not hold any data in steady state like a > > router queue can. The receive window can handle the macro scale flow > > control. > > recall this is a queue that is potentially shared by many many flows > from potentially many many interfaces i.e it deals with many many > micro-scale bursts. > Clearly, the best approach is to have lots and lots of memmory and to > make that queue real huge so it can cope with all of them all the time. > We dont have that luxury - If you restrict the queue size, you will have > to drop packets... Which ones? > Probably simplest solution is to leave it as is right now and just > adjust the contraints based on your system memmory etc. Another alternative would be some form of adaptive threshold, something like adaptive drop tail described in this paper. http://www.ee.cityu.edu.hk/~gchen/pdf/ITC18.pdf Since netif_rx is running at interrupt time, it has to be simple/quick. From fubar@us.ibm.com Thu Mar 3 15:33:25 2005 Received: with ECARTIS (v1.0.0; list netdev); Thu, 03 Mar 2005 15:33:31 -0800 (PST) Received: from e2.ny.us.ibm.com (e2.ny.us.ibm.com [32.97.182.142]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j23NXNd2001299 for ; Thu, 3 Mar 2005 15:33:25 -0800 Received: from d01relay02.pok.ibm.com (d01relay02.pok.ibm.com [9.56.227.234]) by e2.ny.us.ibm.com (8.12.11/8.12.11) with ESMTP id j23NXEGE030477 for ; Thu, 3 Mar 2005 18:33:14 -0500 Received: from d01av02.pok.ibm.com (d01av02.pok.ibm.com [9.56.224.216]) by d01relay02.pok.ibm.com (8.12.10/NCO/VER6.6) with ESMTP id j23NXEjD071300 for ; Thu, 3 Mar 2005 18:33:14 -0500 Received: from d01av02.pok.ibm.com (loopback [127.0.0.1]) by d01av02.pok.ibm.com (8.12.11/8.12.11) with ESMTP id j23NXELC004540 for ; Thu, 3 Mar 2005 18:33:14 -0500 Received: from death.nxdomain.ibm.com (sig-9-65-48-220.mts.ibm.com [9.65.48.220]) by d01av02.pok.ibm.com (8.12.11/8.12.11) with ESMTP id j23NXD4s004512; Thu, 3 Mar 2005 18:33:14 -0500 Received: from death.nxdomain.ibm.com (localhost [127.0.0.1]) by death.nxdomain.ibm.com (8.12.8/8.12.8) with ESMTP id j23NXCNn017691; Thu, 3 Mar 2005 15:33:12 -0800 Received: from death (fubar@localhost) by death.nxdomain.ibm.com (8.12.8/8.12.8/Submit) with ESMTP id j23NXBh3017684; Thu, 3 Mar 2005 15:33:11 -0800 Message-Id: <200503032333.j23NXBh3017684@death.nxdomain.ibm.com> To: netdev@oss.sgi.com Cc: Olaf Kirch Subject: [PATCH REPOST 2.6.11-rc4-netdev1] bonding: don't drop non-VLAN traffic X-Mailer: MH-E 7.82; nmh 1.0.4; GNU Emacs 21.3.1 Date: Thu, 03 Mar 2005 15:33:11 -0800 From: Jay Vosburgh X-Virus-Scanned: ClamAV 0.83/743/Wed Mar 2 16:02:05 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 2353 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: fubar@us.ibm.com Precedence: bulk X-list: netdev Content-Length: 1667 Lines: 49 Change the bonding driver to not drop non-VLAN traffic when a VLAN is configured above it. Originally fixed by Olaf Kirch ; I changed his patch slightly to update comments. -J --- -Jay Vosburgh, IBM Linux Technology Center, fubar@us.ibm.com Signed-off-by: Jay Vosburgh --- linux-2.6.11-rc4-netdev1-virgin/drivers/net/bonding/bond_main.c 2005-02-15 11:31:40.000000000 -0800 +++ linux-2.6.11-rc4-netdev1/drivers/net/bonding/bond_main.c 2005-02-15 16:09:10.000000000 -0800 @@ -793,29 +793,20 @@ * @skb: hw accel VLAN tagged skb to transmit * @slave_dev: slave that is supposed to xmit this skbuff * - * When the bond gets an skb to tarnsmit that is + * When the bond gets an skb to transmit that is * already hardware accelerated VLAN tagged, and it * needs to relay this skb to a slave that is not * hw accel capable, the skb needs to be "unaccelerated", * i.e. strip the hwaccel tag and re-insert it as part * of the payload. - * - * Assumption - once a VLAN device is created over the bond device, all - * packets are going to be hardware accelerated VLAN tagged since the IP - * binding is done over the VLAN device */ int bond_dev_queue_xmit(struct bonding *bond, struct sk_buff *skb, struct net_device *slave_dev) { unsigned short vlan_id; - int res; if (!list_empty(&bond->vlan_list) && - !(slave_dev->features & NETIF_F_HW_VLAN_TX)) { - res = vlan_get_tag(skb, &vlan_id); - if (res) { - return -EINVAL; - } - + !(slave_dev->features & NETIF_F_HW_VLAN_TX) && + vlan_get_tag(skb, &vlan_id) == 0) { skb->dev = slave_dev; skb = vlan_put_tag(skb, vlan_id); if (!skb) { From jgarzik@pobox.com Thu Mar 3 15:37:57 2005 Received: with ECARTIS (v1.0.0; list netdev); Thu, 03 Mar 2005 15:38:01 -0800 (PST) Received: from parcelfarce.linux.theplanet.co.uk (IDENT:93@parcelfarce.linux.theplanet.co.uk [195.92.249.252]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j23NbuKV002052 for ; Thu, 3 Mar 2005 15:37:56 -0800 Received: from [69.134.152.124] (helo=[10.10.10.88]) by parcelfarce.linux.theplanet.co.uk with asmtp (TLSv1:AES256-SHA:256) (Exim 4.33) id 1D6zt8-0005GN-TA; Thu, 03 Mar 2005 23:37:51 +0000 Message-ID: <42279FB6.6090105@pobox.com> Date: Thu, 03 Mar 2005 18:37:26 -0500 From: Jeff Garzik User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.3) Gecko/20040922 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Jay Vosburgh CC: netdev@oss.sgi.com, Olaf Kirch Subject: Re: [PATCH REPOST 2.6.11-rc4-netdev1] bonding: don't drop non-VLAN traffic References: <200503032333.j23NXBh3017684@death.nxdomain.ibm.com> In-Reply-To: <200503032333.j23NXBh3017684@death.nxdomain.ibm.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV 0.83/743/Wed Mar 2 16:02:05 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 2354 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: jgarzik@pobox.com Precedence: bulk X-list: netdev Content-Length: 326 Lines: 12 Jay Vosburgh wrote: > Change the bonding driver to not drop non-VLAN traffic when a > VLAN is configured above it. Originally fixed by Olaf Kirch > ; I changed his patch slightly to update comments. Does this go on top of, or underneath, your pile of bonding patches that I merged into netdev-2.6? Jeff From hadi@cyberus.ca Thu Mar 3 15:40:16 2005 Received: with ECARTIS (v1.0.0; list netdev); Thu, 03 Mar 2005 15:40:21 -0800 (PST) Received: from mx02.cybersurf.com (mx02.cybersurf.com [209.197.145.105]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j23NeFtP002632 for ; Thu, 3 Mar 2005 15:40:15 -0800 Received: from mail.cyberus.ca ([209.197.145.21]) by mx02.cybersurf.com with esmtp (Exim 4.30) id 1D6zvR-0001GC-IR for netdev@oss.sgi.com; Thu, 03 Mar 2005 18:40:13 -0500 Received: from [24.103.99.32] (helo=[10.0.0.9]) by mail.cyberus.ca with esmtp (Exim 4.20) id 1D6zvO-0002Do-AS; Thu, 03 Mar 2005 18:40:10 -0500 Subject: Re: netif_rx packet dumping From: jamal Reply-To: hadi@cyberus.ca To: Stephen Hemminger Cc: John Heffner , "David S. Miller" , rhee@eos.ncsu.edu, Yee-Ting.Li@nuim.ie, baruch@ev-en.org, netdev@oss.sgi.com In-Reply-To: <20050303151606.3587394f@dxpl.pdx.osdl.net> References: <20050303123811.4d934249@dxpl.pdx.osdl.net> <20050303125556.6850cfe5.davem@davemloft.net> <1109884688.1090.282.camel@jzny.localdomain> <20050303132143.7eef517c@dxpl.pdx.osdl.net> <1109885065.1098.285.camel@jzny.localdomain> <20050303133237.5d64578f.davem@davemloft.net> <20050303135416.0d6e7708@dxpl.pdx.osdl.net> <1109888811.1092.352.camel@jzny.localdomain> <20050303151606.3587394f@dxpl.pdx.osdl.net> Content-Type: text/plain Organization: jamalopolous Message-Id: <1109893205.1091.364.camel@jzny.localdomain> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.2.2 Date: 03 Mar 2005 18:40:06 -0500 Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV 0.83/743/Wed Mar 2 16:02:05 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 2355 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: hadi@cyberus.ca Precedence: bulk X-list: netdev Content-Length: 2173 Lines: 46 On Thu, 2005-03-03 at 18:16, Stephen Hemminger wrote: > On 03 Mar 2005 17:26:51 -0500 > jamal wrote: > > > On Thu, 2005-03-03 at 17:02, John Heffner wrote: > > > On Thu, 3 Mar 2005, Stephen Hemminger wrote: > > > > Maybe a simple Random Exponential Drop (RED) would be more friendly. > > > > > > That would probably not be appropriate. This queue is only for absorbing > > > micro-scale bursts. It should not hold any data in steady state like a > > > router queue can. The receive window can handle the macro scale flow > > > control. > > > > recall this is a queue that is potentially shared by many many flows > > from potentially many many interfaces i.e it deals with many many > > micro-scale bursts. > > Clearly, the best approach is to have lots and lots of memmory and to > > make that queue real huge so it can cope with all of them all the time. > > We dont have that luxury - If you restrict the queue size, you will have > > to drop packets... Which ones? > > Probably simplest solution is to leave it as is right now and just > > adjust the contraints based on your system memmory etc. > > Another alternative would be some form of adaptive threshold, > something like adaptive drop tail described in this paper. > http://www.ee.cityu.edu.hk/~gchen/pdf/ITC18.pdf > > Since netif_rx is running at interrupt time, it has to be simple/quick. Note we do have some form of "detection" in place which mauntains history via EWMA through get_sample_stats(). This essentially tells you if the average queue size is growing and how fast i.e a first order differential. The idea was for drivers to use this information to back off and not hit netif_rx() for a period of time. You could use that scheme to kick in and adjust the backlog - i think that would be a cheap effort (if you decouple it from rx softirq). This would be much simpler than the scheme described in the paper. I think to really make progress though, you need to "cheaply" recognize things at a flow level. You dont have to be very accurate, something like a bloom filter with timers to clear state would do fine. But thats more work than above suggestion. cheers, jamal From baruch@ev-en.org Thu Mar 3 15:48:24 2005 Received: with ECARTIS (v1.0.0; list netdev); Thu, 03 Mar 2005 15:48:30 -0800 (PST) Received: from galon.ev-en.org (rrcs-24-123-59-149.central.biz.rr.com [24.123.59.149]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j23NmNg5003339 for ; Thu, 3 Mar 2005 15:48:24 -0800 Received: by galon.ev-en.org (Postfix, from userid 105) id A6FF711A697; Fri, 4 Mar 2005 01:48:17 +0200 (IST) Received: from [10.220.3.66] (hamilton.nuim.ie [149.157.192.252]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by galon.ev-en.org (Postfix) with ESMTP id 5BCAE11A5E3; Fri, 4 Mar 2005 01:48:14 +0200 (IST) Message-ID: <4227A23C.5050300@ev-en.org> Date: Thu, 03 Mar 2005 23:48:12 +0000 From: Baruch Even User-Agent: Debian Thunderbird 1.0 (X11/20050116) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Stephen Hemminger Cc: hadi@cyberus.ca, John Heffner , "David S. Miller" , rhee@eos.ncsu.edu, Yee-Ting.Li@nuim.ie, netdev@oss.sgi.com Subject: Re: netif_rx packet dumping References: <20050303123811.4d934249@dxpl.pdx.osdl.net> <20050303125556.6850cfe5.davem@davemloft.net> <1109884688.1090.282.camel@jzny.localdomain> <20050303132143.7eef517c@dxpl.pdx.osdl.net> <1109885065.1098.285.camel@jzny.localdomain> <20050303133237.5d64578f.davem@davemloft.net> <20050303135416.0d6e7708@dxpl.pdx.osdl.net> <1109888811.1092.352.camel@jzny.localdomain> <20050303151606.3587394f@dxpl.pdx.osdl.net> In-Reply-To: <20050303151606.3587394f@dxpl.pdx.osdl.net> X-Enigmail-Version: 0.90.0.0 X-Enigmail-Supports: pgp-inline, pgp-mime Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV 0.83/743/Wed Mar 2 16:02:05 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 2356 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: baruch@ev-en.org Precedence: bulk X-list: netdev Content-Length: 1711 Lines: 41 Stephen Hemminger wrote: > On 03 Mar 2005 17:26:51 -0500 > jamal wrote: > >>On Thu, 2005-03-03 at 17:02, John Heffner wrote: >> >>>On Thu, 3 Mar 2005, Stephen Hemminger wrote: >>> >>>>Maybe a simple Random Exponential Drop (RED) would be more friendly. >>> >>>That would probably not be appropriate. This queue is only for absorbing >>>micro-scale bursts. It should not hold any data in steady state like a >>>router queue can. The receive window can handle the macro scale flow >>>control. >> >>recall this is a queue that is potentially shared by many many flows >>from potentially many many interfaces i.e it deals with many many >>micro-scale bursts. >>Clearly, the best approach is to have lots and lots of memmory and to >>make that queue real huge so it can cope with all of them all the time. >>We dont have that luxury - If you restrict the queue size, you will have >>to drop packets... Which ones? >>Probably simplest solution is to leave it as is right now and just >>adjust the contraints based on your system memmory etc. > > Another alternative would be some form of adaptive threshold, > something like adaptive drop tail described in this paper. > http://www.ee.cityu.edu.hk/~gchen/pdf/ITC18.pdf What is the purpose of all of these schemes? The queue is there to handle short bursts of packets when the network stack cannot handle it. The bad behaviour was the throttling of the queue, the smart schemes are not going to make it that much better if the hardware/software can't keep up. Even adding more memory to the queue is not going to make a big difference, it will just delay the inevitable end and add some more queueing latency to the connections. Baruch From jheffner@psc.edu Thu Mar 3 15:49:06 2005 Received: with ECARTIS (v1.0.0; list netdev); Thu, 03 Mar 2005 15:49:10 -0800 (PST) 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 j23Nn5UT003601 for ; Thu, 3 Mar 2005 15:49:06 -0800 Received: from tesla.psc.edu (tesla.psc.edu [128.182.61.233]) by mailer1.psc.edu (8.13.3/8.13.3) with ESMTP id j23Nmoeu009361 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 3 Mar 2005 18:48:50 -0500 (EST) Received: from tesla.psc.edu (localhost.psc.edu [127.0.0.1]) by tesla.psc.edu (8.12.11/8.12.10) with ESMTP id j23Nmo42024901; Thu, 3 Mar 2005 18:48:50 -0500 Received: from localhost (jheffner@localhost) by tesla.psc.edu (8.12.11/8.12.11/Submit) with ESMTP id j23NmoaF024898; Thu, 3 Mar 2005 18:48:50 -0500 X-Authentication-Warning: tesla.psc.edu: jheffner owned process doing -bs Date: Thu, 3 Mar 2005 18:48:50 -0500 (EST) From: John Heffner To: Stephen Hemminger cc: hadi@cyberus.ca, "David S. Miller" , rhee@eos.ncsu.edu, Yee-Ting.Li@nuim.ie, baruch@ev-en.org, netdev@oss.sgi.com Subject: Re: netif_rx packet dumping In-Reply-To: <20050303151606.3587394f@dxpl.pdx.osdl.net> Message-ID: References: <20050303123811.4d934249@dxpl.pdx.osdl.net> <20050303125556.6850cfe5.davem@davemloft.net> <1109884688.1090.282.camel@jzny.localdomain> <20050303132143.7eef517c@dxpl.pdx.osdl.net> <1109885065.1098.285.camel@jzny.localdomain> <20050303133237.5d64578f.davem@davemloft.net> <20050303135416.0d6e7708@dxpl.pdx.osdl.net> <1109888811.1092.352.camel@jzny.localdomain> <20050303151606.3587394f@dxpl.pdx.osdl.net> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Scanned-By: MIMEDefang 2.49 on 128.182.58.100 X-Virus-Scanned: ClamAV 0.83/743/Wed Mar 2 16:02:05 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 2357 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: jheffner@psc.edu Precedence: bulk X-list: netdev Content-Length: 714 Lines: 17 On Thu, 3 Mar 2005, Stephen Hemminger wrote: > Another alternative would be some form of adaptive threshold, > something like adaptive drop tail described in this paper. > http://www.ee.cityu.edu.hk/~gchen/pdf/ITC18.pdf > > Since netif_rx is running at interrupt time, it has to be simple/quick. All these AQM schemes are trying to solve a fundamentally different problem. With TCP at least, the only congestion experienced at this point will be transient, so you do not want to send any congestion signals (drop packets) if you can avoid it at all. Making the limit as high as you can tolerate seems like the best thing to me. I am a bit worried that removing the throttling *is* a DOS risk though. -John From fubar@us.ibm.com Thu Mar 3 16:02:21 2005 Received: with ECARTIS (v1.0.0; list netdev); Thu, 03 Mar 2005 16:02:26 -0800 (PST) Received: from e32.co.us.ibm.com (e32.co.us.ibm.com [32.97.110.130]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j2402EQ8004901 for ; Thu, 3 Mar 2005 16:02:21 -0800 Received: from westrelay02.boulder.ibm.com (westrelay02.boulder.ibm.com [9.17.195.11]) by e32.co.us.ibm.com (8.12.10/8.12.9) with ESMTP id j240285j485144 for ; Thu, 3 Mar 2005 19:02:08 -0500 Received: from d03av02.boulder.ibm.com (d03av02.boulder.ibm.com [9.17.195.168]) by westrelay02.boulder.ibm.com (8.12.10/NCO/VER6.6) with ESMTP id j24028Ps103790 for ; Thu, 3 Mar 2005 17:02:08 -0700 Received: from d03av02.boulder.ibm.com (loopback [127.0.0.1]) by d03av02.boulder.ibm.com (8.12.11/8.12.11) with ESMTP id j24028RK013623 for ; Thu, 3 Mar 2005 17:02:08 -0700 Received: from death.nxdomain.ibm.com (sig-9-65-48-220.mts.ibm.com [9.65.48.220]) by d03av02.boulder.ibm.com (8.12.11/8.12.11) with ESMTP id j24027nG013597; Thu, 3 Mar 2005 17:02:08 -0700 Received: from death.nxdomain.ibm.com (localhost [127.0.0.1]) by death.nxdomain.ibm.com (8.12.8/8.12.8) with ESMTP id j24026Nn017878; Thu, 3 Mar 2005 16:02:06 -0800 Received: from death (fubar@localhost) by death.nxdomain.ibm.com (8.12.8/8.12.8/Submit) with ESMTP id j24025P6017871; Thu, 3 Mar 2005 16:02:05 -0800 Message-Id: <200503040002.j24025P6017871@death.nxdomain.ibm.com> To: Jeff Garzik cc: netdev@oss.sgi.com, Olaf Kirch Subject: Re: [PATCH REPOST 2.6.11-rc4-netdev1] bonding: don't drop non-VLAN traffic In-Reply-To: Message from Jeff Garzik of "Thu, 03 Mar 2005 18:37:26 EST." <42279FB6.6090105@pobox.com> X-Mailer: MH-E 7.82; nmh 1.0.4; GNU Emacs 21.3.1 Date: Thu, 03 Mar 2005 16:02:04 -0800 From: Jay Vosburgh X-Virus-Scanned: ClamAV 0.83/743/Wed Mar 2 16:02:05 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 2358 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: fubar@us.ibm.com Precedence: bulk X-list: netdev Content-Length: 324 Lines: 12 Jeff Garzik wrote: >Does this go on top of, or underneath, your pile of bonding patches >that I merged into netdev-2.6? On top of. I just checked it, and it applies ok for me to 2.6.11 plus your netdev1 patch from this morning. -J --- -Jay Vosburgh, IBM Linux Technology Center, fubar@us.ibm.com From jgarzik@pobox.com Thu Mar 3 16:34:24 2005 Received: with ECARTIS (v1.0.0; list netdev); Thu, 03 Mar 2005 16:34:35 -0800 (PST) Received: from parcelfarce.linux.theplanet.co.uk (IDENT:93@parcelfarce.linux.theplanet.co.uk [195.92.249.252]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j240YKT6009643 for ; Thu, 3 Mar 2005 16:34:23 -0800 Received: from [69.134.152.124] (helo=[10.10.10.88]) by parcelfarce.linux.theplanet.co.uk with asmtp (TLSv1:AES256-SHA:256) (Exim 4.33) id 1D70lm-0006Ig-TF; Fri, 04 Mar 2005 00:34:20 +0000 Message-ID: <4227ACED.4090006@pobox.com> Date: Thu, 03 Mar 2005 19:33:49 -0500 From: Jeff Garzik User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.3) Gecko/20040922 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Marcelo Tosatti CC: Netdev Subject: [BK PATCHES] 2.4.x net driver updates Content-Type: multipart/mixed; boundary="------------020202080705050805050400" X-Virus-Scanned: ClamAV 0.83/743/Wed Mar 2 16:02:05 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 2359 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: jgarzik@pobox.com Precedence: bulk X-list: netdev Content-Length: 29465 Lines: 917 This is a multi-part message in MIME format. --------------020202080705050805050400 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit --------------020202080705050805050400 Content-Type: text/plain; name="changelog.txt" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="changelog.txt" Please do a bk pull bk://gkernel.bkbits.net/net-drivers-2.4 This will update the following files: drivers/net/e1000/e1000.h | 3 drivers/net/e1000/e1000_ethtool.c | 11 - drivers/net/e1000/e1000_hw.c | 86 ++++++------- drivers/net/e1000/e1000_hw.h | 12 + drivers/net/e1000/e1000_main.c | 251 ++++++++++++++++++++++++++++++++++---- drivers/net/tulip/21142.c | 2 drivers/net/tulip/eeprom.c | 1 drivers/net/tulip/interrupt.c | 2 drivers/net/tulip/media.c | 1 drivers/net/tulip/pnic.c | 1 drivers/net/tulip/pnic2.c | 2 drivers/net/tulip/timer.c | 1 drivers/net/tulip/tulip.h | 15 ++ drivers/net/tulip/tulip_core.c | 2 14 files changed, 312 insertions(+), 78 deletions(-) through these ChangeSets: : o e1000: Driver version white space, o e1000: Fixes related to Cable length o e1000: Report failure code when loopback o e1000: Checks for desc ring/rx data o e1000: Patch from Peter Kjellstroem -- o e1000: Fix WOL settings in 82544 based o e1000: Delay clean-up of last Tx buffer o e1000: Avoid race between e1000_watchdog o e1000: 2 use netif_poll_{enable|disable} o e1000: 1 Robert Olsson's fix and John W. Linville: o tulip: make tulip_stop_rxtx() wait for DMA to fully stop --------------020202080705050805050400 Content-Type: text/plain; name="patch" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="patch" diff -Nru a/drivers/net/e1000/e1000.h b/drivers/net/e1000/e1000.h --- a/drivers/net/e1000/e1000.h 2005-03-03 19:33:21 -05:00 +++ b/drivers/net/e1000/e1000.h 2005-03-03 19:33:21 -05:00 @@ -140,6 +140,7 @@ #define E1000_RX_BUFFER_WRITE 16 /* Must be power of 2 */ #define AUTO_ALL_MODES 0 +#define E1000_EEPROM_82544_APM 0x0004 #define E1000_EEPROM_APME 0x0400 #ifndef E1000_MASTER_SLAVE @@ -211,6 +212,7 @@ /* TX */ struct e1000_desc_ring tx_ring; + struct e1000_buffer previous_buffer_info; spinlock_t tx_lock; uint32_t txd_cmd; uint32_t tx_int_delay; @@ -224,6 +226,7 @@ uint32_t tx_fifo_size; atomic_t tx_fifo_stall; boolean_t pcix_82544; + boolean_t detect_tx_hung; /* RX */ struct e1000_desc_ring rx_ring; diff -Nru a/drivers/net/e1000/e1000_ethtool.c b/drivers/net/e1000/e1000_ethtool.c --- a/drivers/net/e1000/e1000_ethtool.c 2005-03-03 19:33:21 -05:00 +++ b/drivers/net/e1000/e1000_ethtool.c 2005-03-03 19:33:21 -05:00 @@ -1309,7 +1309,7 @@ struct e1000_desc_ring *txdr = &adapter->test_tx_ring; struct e1000_desc_ring *rxdr = &adapter->test_rx_ring; struct pci_dev *pdev = adapter->pdev; - int i; + int i, ret_val; E1000_WRITE_REG(&adapter->hw, RDT, rxdr->count - 1); @@ -1329,11 +1329,12 @@ rxdr->buffer_info[i].length, PCI_DMA_FROMDEVICE); - if (!e1000_check_lbtest_frame(rxdr->buffer_info[i++].skb, 1024)) - return 0; - } while (i < 64); + ret_val = e1000_check_lbtest_frame(rxdr->buffer_info[i].skb, + 1024); + i++; + } while (ret_val != 0 && i < 64); - return 13; + return ret_val; } static int diff -Nru a/drivers/net/e1000/e1000_hw.c b/drivers/net/e1000/e1000_hw.c --- a/drivers/net/e1000/e1000_hw.c 2005-03-03 19:33:21 -05:00 +++ b/drivers/net/e1000/e1000_hw.c 2005-03-03 19:33:21 -05:00 @@ -1573,7 +1573,8 @@ if(mii_status_reg & MII_SR_LINK_STATUS) break; msec_delay(100); } - if((i == 0) && (hw->phy_type == e1000_phy_m88)) { + if((i == 0) && + (hw->phy_type == e1000_phy_m88)) { /* We didn't get link. Reset the DSP and wait again for link. */ ret_val = e1000_phy_reset_dsp(hw); if(ret_val) { @@ -2504,7 +2505,7 @@ } } - ret_val = e1000_read_phy_reg_ex(hw, IGP01E1000_PHY_PAGE_SELECT & reg_addr, + ret_val = e1000_read_phy_reg_ex(hw, MAX_PHY_REG_ADDRESS & reg_addr, phy_data); return ret_val; @@ -2610,7 +2611,7 @@ } } - ret_val = e1000_write_phy_reg_ex(hw, IGP01E1000_PHY_PAGE_SELECT & reg_addr, + ret_val = e1000_write_phy_reg_ex(hw, MAX_PHY_REG_ADDRESS & reg_addr, phy_data); return ret_val; @@ -2956,8 +2957,7 @@ /* Check polarity status */ ret_val = e1000_check_polarity(hw, &polarity); if(ret_val) - return ret_val; - + return ret_val; phy_info->cable_polarity = polarity; ret_val = e1000_read_phy_reg(hw, M88E1000_PHY_SPEC_STATUS, &phy_data); @@ -2967,9 +2967,9 @@ phy_info->mdix_mode = (phy_data & M88E1000_PSSR_MDIX) >> M88E1000_PSSR_MDIX_SHIFT; - if(phy_data & M88E1000_PSSR_1000MBS) { - /* Cable Length Estimation and Local/Remote Receiver Informatoion - * are only valid at 1000 Mbps + if ((phy_data & M88E1000_PSSR_SPEED) == M88E1000_PSSR_1000MBS) { + /* Cable Length Estimation and Local/Remote Receiver Information + * are only valid at 1000 Mbps. */ phy_info->cable_length = ((phy_data & M88E1000_PSSR_CABLE_LENGTH) >> M88E1000_PSSR_CABLE_LENGTH_SHIFT); @@ -4641,41 +4641,44 @@ { uint32_t status; - if(hw->mac_type < e1000_82543) { + switch (hw->mac_type) { + case e1000_82542_rev2_0: + case e1000_82542_rev2_1: hw->bus_type = e1000_bus_type_unknown; hw->bus_speed = e1000_bus_speed_unknown; hw->bus_width = e1000_bus_width_unknown; - return; - } - - status = E1000_READ_REG(hw, STATUS); - hw->bus_type = (status & E1000_STATUS_PCIX_MODE) ? - e1000_bus_type_pcix : e1000_bus_type_pci; + break; + default: + status = E1000_READ_REG(hw, STATUS); + hw->bus_type = (status & E1000_STATUS_PCIX_MODE) ? + e1000_bus_type_pcix : e1000_bus_type_pci; - if(hw->device_id == E1000_DEV_ID_82546EB_QUAD_COPPER) { - hw->bus_speed = (hw->bus_type == e1000_bus_type_pci) ? - e1000_bus_speed_66 : e1000_bus_speed_120; - } else if(hw->bus_type == e1000_bus_type_pci) { - hw->bus_speed = (status & E1000_STATUS_PCI66) ? - e1000_bus_speed_66 : e1000_bus_speed_33; - } else { - switch (status & E1000_STATUS_PCIX_SPEED) { - case E1000_STATUS_PCIX_SPEED_66: - hw->bus_speed = e1000_bus_speed_66; - break; - case E1000_STATUS_PCIX_SPEED_100: - hw->bus_speed = e1000_bus_speed_100; - break; - case E1000_STATUS_PCIX_SPEED_133: - hw->bus_speed = e1000_bus_speed_133; - break; - default: - hw->bus_speed = e1000_bus_speed_reserved; - break; + if(hw->device_id == E1000_DEV_ID_82546EB_QUAD_COPPER) { + hw->bus_speed = (hw->bus_type == e1000_bus_type_pci) ? + e1000_bus_speed_66 : e1000_bus_speed_120; + } else if(hw->bus_type == e1000_bus_type_pci) { + hw->bus_speed = (status & E1000_STATUS_PCI66) ? + e1000_bus_speed_66 : e1000_bus_speed_33; + } else { + switch (status & E1000_STATUS_PCIX_SPEED) { + case E1000_STATUS_PCIX_SPEED_66: + hw->bus_speed = e1000_bus_speed_66; + break; + case E1000_STATUS_PCIX_SPEED_100: + hw->bus_speed = e1000_bus_speed_100; + break; + case E1000_STATUS_PCIX_SPEED_133: + hw->bus_speed = e1000_bus_speed_133; + break; + default: + hw->bus_speed = e1000_bus_speed_reserved; + break; + } } + hw->bus_width = (status & E1000_STATUS_BUS64) ? + e1000_bus_width_64 : e1000_bus_width_32; + break; } - hw->bus_width = (status & E1000_STATUS_BUS64) ? - e1000_bus_width_64 : e1000_bus_width_32; } /****************************************************************************** * Reads a value from one of the devices registers using port I/O (as opposed @@ -4740,6 +4743,7 @@ uint16_t agc_value = 0; uint16_t cur_agc, min_agc = IGP01E1000_AGC_LENGTH_TABLE_SIZE; uint16_t i, phy_data; + uint16_t cable_length; DEBUGFUNC("e1000_get_cable_length"); @@ -4751,10 +4755,11 @@ &phy_data); if(ret_val) return ret_val; + cable_length = (phy_data & M88E1000_PSSR_CABLE_LENGTH) >> + M88E1000_PSSR_CABLE_LENGTH_SHIFT; /* Convert the enum value to ranged values */ - switch((phy_data & M88E1000_PSSR_CABLE_LENGTH) >> - M88E1000_PSSR_CABLE_LENGTH_SHIFT) { + switch (cable_length) { case e1000_cable_length_50: *min_length = 0; *max_length = e1000_igp_cable_length_50; @@ -4921,8 +4926,7 @@ return ret_val; hw->speed_downgraded = (phy_data & IGP01E1000_PLHR_SS_DOWNGRADE) ? 1 : 0; - } - else if(hw->phy_type == e1000_phy_m88) { + } else if(hw->phy_type == e1000_phy_m88) { ret_val = e1000_read_phy_reg(hw, M88E1000_PHY_SPEC_STATUS, &phy_data); if(ret_val) diff -Nru a/drivers/net/e1000/e1000_hw.h b/drivers/net/e1000/e1000_hw.h --- a/drivers/net/e1000/e1000_hw.h 2005-03-03 19:33:21 -05:00 +++ b/drivers/net/e1000/e1000_hw.h 2005-03-03 19:33:21 -05:00 @@ -36,7 +36,6 @@ #include "e1000_osdep.h" - /* Forward declarations of structures used by the shared code */ struct e1000_hw; struct e1000_hw_stats; @@ -370,6 +369,7 @@ #define E1000_DEV_ID_82546GB_SERDES 0x107B #define E1000_DEV_ID_82546GB_PCIE 0x108A #define E1000_DEV_ID_82547EI 0x1019 + #define NODE_ADDRESS_SIZE 6 #define ETH_LENGTH_OF_ADDRESS 6 @@ -1735,6 +1735,9 @@ #define PHY_1000T_STATUS 0x0A /* 1000Base-T Status Reg */ #define PHY_EXT_STATUS 0x0F /* Extended Status Reg */ +#define MAX_PHY_REG_ADDRESS 0x1F /* 5 bit address bus (0-0x1F) */ +#define MAX_PHY_MULTI_PAGE_REG 0xF /* Registers equal on all pages */ + /* M88E1000 Specific Registers */ #define M88E1000_PHY_SPEC_CTRL 0x10 /* PHY Specific Control Register */ #define M88E1000_PHY_SPEC_STATUS 0x11 /* PHY Specific Status Register */ @@ -1795,8 +1798,7 @@ #define IGP01E1000_ANALOG_REGS_PAGE 0x20C0 -#define MAX_PHY_REG_ADDRESS 0x1F /* 5 bit address bus (0-0x1F) */ -#define MAX_PHY_MULTI_PAGE_REG 0xF /*Registers that are equal on all pages*/ + /* PHY Control Register */ #define MII_CR_SPEED_SELECT_MSB 0x0040 /* bits 6,13: 10=1000, 01=100, 00=10 */ #define MII_CR_COLL_TEST_ENABLE 0x0080 /* Collision test enable */ @@ -2099,7 +2101,11 @@ #define IGP01E1000_ANALOG_FUSE_FINE_1 0x0080 #define IGP01E1000_ANALOG_FUSE_FINE_10 0x0500 + /* Bit definitions for valid PHY IDs. */ +/* I = Integrated + * E = External + */ #define M88E1000_E_PHY_ID 0x01410C50 #define M88E1000_I_PHY_ID 0x01410C30 #define M88E1011_I_PHY_ID 0x01410C20 diff -Nru a/drivers/net/e1000/e1000_main.c b/drivers/net/e1000/e1000_main.c --- a/drivers/net/e1000/e1000_main.c 2005-03-03 19:33:21 -05:00 +++ b/drivers/net/e1000/e1000_main.c 2005-03-03 19:33:21 -05:00 @@ -34,6 +34,14 @@ * - if_mii support and associated kcompat for older kernels * - More errlogging support from Jon Mason * - Fix TSO issues on PPC64 machines -- Jon Mason + * 5.7.1 12/16/04 + * - Resurrect 82547EI/GI related fix in e1000_intr to avoid deadlocks. This + * fix was removed as it caused system instability. The suspected cause of + * this is the called to e1000_irq_disable in e1000_intr. Inlined the + * required piece of e1000_irq_disable into e1000_intr. + * 5.7.0 12/10/04 + * - include fix to the condition that determines when to quit NAPI - Robert Olsson + * - use netif_poll_{disable/enable} to synchronize between NAPI and i/f up/down * 5.6.5 11/01/04 * - Enabling NETIF_F_SG without checksum offload is illegal - John Mason @@ -41,8 +49,13 @@ * - Remove redundant initialization - Jamal Hadi * - Reset buffer_info->dma in tx resource cleanup logic * 5.6.2 10/12/04 + * - Avoid filling tx_ring completely - shemminger@osdl.org + * - Replace schedule_timeout() with msleep()/msleep_interruptible() - + * nacc@us.ibm.com * - Sparse cleanup - shemminger@osdl.org * - Fix tx resource cleanup logic + * - LLTX support - ak@suse.de and hadi@cyberus.ca + * - {set, get}_wol is now symmetric for 82545EM adapters */ char e1000_driver_name[] = "e1000"; @@ -52,7 +65,7 @@ #else #define DRIVERNAPI "-NAPI" #endif -char e1000_driver_version[] = "5.6.10.1-k1"DRIVERNAPI; +char e1000_driver_version[] = "5.7.6-k1"DRIVERNAPI; char e1000_copyright[] = "Copyright (c) 1999-2004 Intel Corporation."; /* e1000_pci_tbl - PCI Device ID Table @@ -76,6 +89,7 @@ INTEL_E1000_ETHERNET_DEVICE(0x1011), INTEL_E1000_ETHERNET_DEVICE(0x1012), INTEL_E1000_ETHERNET_DEVICE(0x1013), + INTEL_E1000_ETHERNET_DEVICE(0x1014), INTEL_E1000_ETHERNET_DEVICE(0x1015), INTEL_E1000_ETHERNET_DEVICE(0x1016), INTEL_E1000_ETHERNET_DEVICE(0x1017), @@ -303,6 +317,9 @@ mod_timer(&adapter->watchdog_timer, jiffies); e1000_irq_enable(adapter); +#ifdef CONFIG_E1000_NAPI + netif_poll_enable(netdev); +#endif return 0; } @@ -316,6 +333,10 @@ del_timer_sync(&adapter->tx_fifo_stall_timer); del_timer_sync(&adapter->watchdog_timer); del_timer_sync(&adapter->phy_info_timer); + +#ifdef CONFIG_E1000_NAPI + netif_poll_disable(netdev); +#endif adapter->link_speed = 0; adapter->link_duplex = 0; netif_carrier_off(netdev); @@ -409,6 +430,7 @@ int i; int err; uint16_t eeprom_data; + uint16_t eeprom_apme_mask = E1000_EEPROM_APME; if((err = pci_enable_device(pdev))) return err; @@ -505,9 +527,6 @@ } #ifdef NETIF_F_TSO - /* Disbaled for now until root-cause is found for - * hangs reported against non-IA archs. TSO can be - * enabled using ethtool -K eth tso on */ if((adapter->hw.mac_type >= e1000_82544) && (adapter->hw.mac_type != e1000_82547)) netdev->features |= NETIF_F_TSO; @@ -576,6 +595,11 @@ case e1000_82542_rev2_1: case e1000_82543: break; + case e1000_82544: + e1000_read_eeprom(&adapter->hw, + EEPROM_INIT_CONTROL2_REG, 1, &eeprom_data); + eeprom_apme_mask = E1000_EEPROM_82544_APM; + break; case e1000_82546: case e1000_82546_rev_3: if((E1000_READ_REG(&adapter->hw, STATUS) & E1000_STATUS_FUNC_1) @@ -590,7 +614,7 @@ EEPROM_INIT_CONTROL3_PORT_A, 1, &eeprom_data); break; } - if(eeprom_data & E1000_EEPROM_APME) + if(eeprom_data & eeprom_apme_mask) adapter->wol |= E1000_WUFC_MAG; /* reset the hardware with the new settings */ @@ -797,6 +821,31 @@ } /** + * e1000_check_64k_bound - check that memory doesn't cross 64kB boundary + * @adapter: address of board private structure + * @begin: address of beginning of memory + * @end: address of end of memory + **/ +static inline boolean_t +e1000_check_64k_bound(struct e1000_adapter *adapter, + void *start, unsigned long len) +{ + unsigned long begin = (unsigned long) start; + unsigned long end = begin + len; + + /* first rev 82545 and 82546 need to not allow any memory + * write location to cross a 64k boundary due to errata 23 */ + if (adapter->hw.mac_type == e1000_82545 || + adapter->hw.mac_type == e1000_82546 ) { + + /* check buffer doesn't cross 64kB */ + return ((begin ^ (end - 1)) >> 16) != 0 ? FALSE : TRUE; + } + + return TRUE; +} + +/** * e1000_setup_tx_resources - allocate Tx resources (Descriptors) * @adapter: board private structure * @@ -826,11 +875,42 @@ txdr->desc = pci_alloc_consistent(pdev, txdr->size, &txdr->dma); if(!txdr->desc) { +setup_tx_desc_die: DPRINTK(PROBE, ERR, "Unable to Allocate Memory for the Transmit descriptor ring\n"); vfree(txdr->buffer_info); return -ENOMEM; } + + /* fix for errata 23, cant cross 64kB boundary */ + if (!e1000_check_64k_bound(adapter, txdr->desc, txdr->size)) { + void *olddesc = txdr->desc; + dma_addr_t olddma = txdr->dma; + DPRINTK(TX_ERR,ERR,"txdr align check failed: %u bytes at %p\n", + txdr->size, txdr->desc); + /* try again, without freeing the previous */ + txdr->desc = pci_alloc_consistent(pdev, txdr->size, &txdr->dma); + /* failed allocation, critial failure */ + if(!txdr->desc) { + pci_free_consistent(pdev, txdr->size, olddesc, olddma); + goto setup_tx_desc_die; + } + + if (!e1000_check_64k_bound(adapter, txdr->desc, txdr->size)) { + /* give up */ + pci_free_consistent(pdev, txdr->size, + txdr->desc, txdr->dma); + pci_free_consistent(pdev, txdr->size, olddesc, olddma); + DPRINTK(PROBE, ERR, + "Unable to Allocate aligned Memory for the Transmit" + " descriptor ring\n"); + vfree(txdr->buffer_info); + return -ENOMEM; + } else { + /* free old, move on with the new one since its okay */ + pci_free_consistent(pdev, txdr->size, olddesc, olddma); + } + } memset(txdr->desc, 0, txdr->size); txdr->next_to_use = 0; @@ -948,11 +1028,43 @@ rxdr->desc = pci_alloc_consistent(pdev, rxdr->size, &rxdr->dma); if(!rxdr->desc) { +setup_rx_desc_die: DPRINTK(PROBE, ERR, - "Unable to Allocate Memory for the Recieve descriptor ring\n"); + "Unble to Allocate Memory for the Recieve descriptor ring\n"); vfree(rxdr->buffer_info); return -ENOMEM; } + + /* fix for errata 23, cant cross 64kB boundary */ + if (!e1000_check_64k_bound(adapter, rxdr->desc, rxdr->size)) { + void *olddesc = rxdr->desc; + dma_addr_t olddma = rxdr->dma; + DPRINTK(RX_ERR,ERR, + "rxdr align check failed: %u bytes at %p\n", + rxdr->size, rxdr->desc); + /* try again, without freeing the previous */ + rxdr->desc = pci_alloc_consistent(pdev, rxdr->size, &rxdr->dma); + /* failed allocation, critial failure */ + if(!rxdr->desc) { + pci_free_consistent(pdev, rxdr->size, olddesc, olddma); + goto setup_rx_desc_die; + } + + if (!e1000_check_64k_bound(adapter, rxdr->desc, rxdr->size)) { + /* give up */ + pci_free_consistent(pdev, rxdr->size, + rxdr->desc, rxdr->dma); + pci_free_consistent(pdev, rxdr->size, olddesc, olddma); + DPRINTK(PROBE, ERR, + "Unable to Allocate aligned Memory for the" + " Receive descriptor ring\n"); + vfree(rxdr->buffer_info); + return -ENOMEM; + } else { + /* free old, move on with the new one since its okay */ + pci_free_consistent(pdev, rxdr->size, olddesc, olddma); + } + } memset(rxdr->desc, 0, rxdr->size); rxdr->next_to_clean = 0; @@ -1086,6 +1198,7 @@ struct e1000_buffer *buffer_info) { struct pci_dev *pdev = adapter->pdev; + if(buffer_info->dma) { pci_unmap_page(pdev, buffer_info->dma, @@ -1114,6 +1227,11 @@ /* Free all the Tx ring sk_buffs */ + if (likely(adapter->previous_buffer_info.skb != NULL)) { + e1000_unmap_and_free_tx_resource(adapter, + &adapter->previous_buffer_info); + } + for(i = 0; i < tx_ring->count; i++) { buffer_info = &tx_ring->buffer_info[i]; e1000_unmap_and_free_tx_resource(adapter, buffer_info); @@ -1415,7 +1533,6 @@ struct e1000_adapter *adapter = (struct e1000_adapter *) data; struct net_device *netdev = adapter->netdev; struct e1000_desc_ring *txdr = &adapter->tx_ring; - unsigned int i; uint32_t link; e1000_check_for_link(&adapter->hw); @@ -1495,12 +1612,8 @@ /* Cause software interrupt to ensure rx ring is cleaned */ E1000_WRITE_REG(&adapter->hw, ICS, E1000_ICS_RXDMT0); - /* Early detection of hung controller */ - i = txdr->next_to_clean; - if(txdr->buffer_info[i].dma && - time_after(jiffies, txdr->buffer_info[i].time_stamp + HZ) && - !(E1000_READ_REG(&adapter->hw, STATUS) & E1000_STATUS_TXOFF)) - netif_stop_queue(netdev); + /* Force detection of hung controller every watchdog period*/ + adapter->detect_tx_hung = TRUE; /* Reset the timer */ mod_timer(&adapter->watchdog_timer, jiffies + 2 * HZ); @@ -2132,10 +2245,28 @@ __netif_rx_schedule(netdev); } #else + /* Writing IMC and IMS is needed for 82547. + Due to Hub Link bus being occupied, an interrupt + de-assertion message is not able to be sent. + When an interrupt assertion message is generated later, + two messages are re-ordered and sent out. + That causes APIC to think 82547 is in de-assertion + state, while 82547 is in assertion state, resulting + in dead lock. Writing IMC forces 82547 into + de-assertion state. + */ + if(hw->mac_type == e1000_82547 || hw->mac_type == e1000_82547_rev_2){ + atomic_inc(&adapter->irq_sem); + E1000_WRITE_REG(&adapter->hw, IMC, ~0); + } + for(i = 0; i < E1000_MAX_INTR; i++) if(unlikely(!e1000_clean_rx_irq(adapter) & !e1000_clean_tx_irq(adapter))) break; + + if(hw->mac_type == e1000_82547 || hw->mac_type == e1000_82547_rev_2) + e1000_irq_enable(adapter); #endif return IRQ_HANDLED; @@ -2155,24 +2286,21 @@ int tx_cleaned; int work_done = 0; - if (!netif_carrier_ok(netdev)) - goto quit_polling; - tx_cleaned = e1000_clean_tx_irq(adapter); e1000_clean_rx_irq(adapter, &work_done, work_to_do); *budget -= work_done; netdev->quota -= work_done; - /* if no Rx and Tx cleanup work was done, exit the polling mode */ - if(!tx_cleaned || (work_done < work_to_do) || + /* if no Tx and not enough Rx work done, exit the polling mode */ + if((!tx_cleaned && (work_done < work_to_do)) || !netif_running(netdev)) { -quit_polling: netif_rx_complete(netdev); + netif_rx_complete(netdev); e1000_irq_enable(adapter); return 0; } - return (work_done >= work_to_do); + return 1; } #endif @@ -2196,11 +2324,34 @@ eop_desc = E1000_TX_DESC(*tx_ring, eop); while(eop_desc->upper.data & cpu_to_le32(E1000_TXD_STAT_DD)) { + /* pre-mature writeback of Tx descriptors */ + /* clear (free buffers and unmap pci_mapping) */ + /* previous_buffer_info */ + if (likely(adapter->previous_buffer_info.skb != NULL)) { + e1000_unmap_and_free_tx_resource(adapter, + &adapter->previous_buffer_info); + } + for(cleaned = FALSE; !cleaned; ) { tx_desc = E1000_TX_DESC(*tx_ring, i); buffer_info = &tx_ring->buffer_info[i]; + cleaned = (i == eop); + + /* pre-mature writeback of Tx descriptors */ + /* save the cleaning of the this for the */ + /* next iteration */ + if (cleaned) { + memcpy(&adapter->previous_buffer_info, + buffer_info, + sizeof(struct e1000_buffer)); + memset(buffer_info, + 0, + sizeof(struct e1000_buffer)); + } else { + e1000_unmap_and_free_tx_resource(adapter, + buffer_info); + } - e1000_unmap_and_free_tx_resource(adapter, buffer_info); tx_desc->buffer_addr = 0; tx_desc->lower.data = 0; tx_desc->upper.data = 0; @@ -2222,6 +2373,16 @@ netif_wake_queue(netdev); spin_unlock(&adapter->tx_lock); + + if(adapter->detect_tx_hung) { + /* detect a transmit hang in hardware, this serializes the + * check with the clearing of time_stamp and movement of i */ + adapter->detect_tx_hung = FALSE; + if(tx_ring->buffer_info[i].dma && + time_after(jiffies, tx_ring->buffer_info[i].time_stamp + HZ) && + !(E1000_READ_REG(&adapter->hw, STATUS) & E1000_STATUS_TXOFF)) + netif_stop_queue(netdev); + } return cleaned; } @@ -2389,20 +2550,43 @@ struct e1000_buffer *buffer_info; struct sk_buff *skb; int reserve_len = 2; - unsigned int i; + unsigned int i, bufsz; i = rx_ring->next_to_use; buffer_info = &rx_ring->buffer_info[i]; while(!buffer_info->skb) { + bufsz = adapter->rx_buffer_len + reserve_len; - skb = dev_alloc_skb(adapter->rx_buffer_len + reserve_len); - + skb = dev_alloc_skb(bufsz); if(unlikely(!skb)) { /* Better luck next round */ break; } + /* fix for errata 23, cant cross 64kB boundary */ + if (!e1000_check_64k_bound(adapter, skb->data, bufsz)) { + struct sk_buff *oldskb = skb; + DPRINTK(RX_ERR,ERR, + "skb align check failed: %u bytes at %p\n", + bufsz, skb->data); + /* try again, without freeing the previous */ + skb = dev_alloc_skb(bufsz); + if (!skb) { + dev_kfree_skb(oldskb); + break; + } + if (!e1000_check_64k_bound(adapter, skb->data, bufsz)) { + /* give up */ + dev_kfree_skb(skb); + dev_kfree_skb(oldskb); + break; /* while !buffer_info->skb */ + } else { + /* move on with the new one */ + dev_kfree_skb(oldskb); + } + } + /* Make buffer alignment 2 beyond a 16 byte boundary * this will result in a 16 byte aligned IP header after * the 14 byte MAC header is removed @@ -2417,6 +2601,25 @@ skb->data, adapter->rx_buffer_len, PCI_DMA_FROMDEVICE); + + /* fix for errata 23, cant cross 64kB boundary */ + if(!e1000_check_64k_bound(adapter, + (void *)(unsigned long)buffer_info->dma, + adapter->rx_buffer_len)) { + DPRINTK(RX_ERR,ERR, + "dma align check failed: %u bytes at %ld\n", + adapter->rx_buffer_len, (unsigned long)buffer_info->dma); + + dev_kfree_skb(skb); + buffer_info->skb = NULL; + + pci_unmap_single(pdev, + buffer_info->dma, + adapter->rx_buffer_len, + PCI_DMA_FROMDEVICE); + + break; /* while !buffer_info->skb */ + } rx_desc = E1000_RX_DESC(*rx_ring, i); rx_desc->buffer_addr = cpu_to_le64(buffer_info->dma); diff -Nru a/drivers/net/tulip/21142.c b/drivers/net/tulip/21142.c --- a/drivers/net/tulip/21142.c 2005-03-03 19:33:21 -05:00 +++ b/drivers/net/tulip/21142.c 2005-03-03 19:33:21 -05:00 @@ -14,8 +14,8 @@ */ -#include "tulip.h" #include +#include "tulip.h" #include diff -Nru a/drivers/net/tulip/eeprom.c b/drivers/net/tulip/eeprom.c --- a/drivers/net/tulip/eeprom.c 2005-03-03 19:33:21 -05:00 +++ b/drivers/net/tulip/eeprom.c 2005-03-03 19:33:21 -05:00 @@ -14,6 +14,7 @@ */ +#include #include "tulip.h" #include #include diff -Nru a/drivers/net/tulip/interrupt.c b/drivers/net/tulip/interrupt.c --- a/drivers/net/tulip/interrupt.c 2005-03-03 19:33:21 -05:00 +++ b/drivers/net/tulip/interrupt.c 2005-03-03 19:33:21 -05:00 @@ -14,10 +14,10 @@ */ +#include #include "tulip.h" #include #include -#include int tulip_rx_copybreak; diff -Nru a/drivers/net/tulip/media.c b/drivers/net/tulip/media.c --- a/drivers/net/tulip/media.c 2005-03-03 19:33:21 -05:00 +++ b/drivers/net/tulip/media.c 2005-03-03 19:33:21 -05:00 @@ -18,6 +18,7 @@ #include #include #include +#include #include "tulip.h" diff -Nru a/drivers/net/tulip/pnic.c b/drivers/net/tulip/pnic.c --- a/drivers/net/tulip/pnic.c 2005-03-03 19:33:21 -05:00 +++ b/drivers/net/tulip/pnic.c 2005-03-03 19:33:21 -05:00 @@ -15,6 +15,7 @@ */ #include +#include #include "tulip.h" diff -Nru a/drivers/net/tulip/pnic2.c b/drivers/net/tulip/pnic2.c --- a/drivers/net/tulip/pnic2.c 2005-03-03 19:33:21 -05:00 +++ b/drivers/net/tulip/pnic2.c 2005-03-03 19:33:21 -05:00 @@ -76,8 +76,8 @@ -#include "tulip.h" #include +#include "tulip.h" #include diff -Nru a/drivers/net/tulip/timer.c b/drivers/net/tulip/timer.c --- a/drivers/net/tulip/timer.c 2005-03-03 19:33:21 -05:00 +++ b/drivers/net/tulip/timer.c 2005-03-03 19:33:21 -05:00 @@ -14,6 +14,7 @@ */ +#include #include "tulip.h" diff -Nru a/drivers/net/tulip/tulip.h b/drivers/net/tulip/tulip.h --- a/drivers/net/tulip/tulip.h 2005-03-03 19:33:21 -05:00 +++ b/drivers/net/tulip/tulip.h 2005-03-03 19:33:21 -05:00 @@ -146,6 +146,9 @@ TxIntr = 0x01, }; +/* bit mask for CSR5 TX/RX process state */ +#define CSR5_TS 0x00700000 +#define CSR5_RS 0x000e0000 enum tulip_mode_bits { TxThreshold = (1 << 22), @@ -484,9 +487,19 @@ u32 csr6 = inl(ioaddr + CSR6); if (csr6 & RxTx) { + unsigned i=1300/10; outl(csr6 & ~RxTx, ioaddr + CSR6); barrier(); - (void) inl(ioaddr + CSR6); /* mmio sync */ + /* wait until in-flight frame completes. + * Max time @ 10BT: 1500*8b/10Mbps == 1200us (+ 100us margin) + * Typically expect this loop to end in < 50us on 100BT. + */ + while (--i && (inl(ioaddr + CSR5) & (CSR5_TS|CSR5_RS))) + udelay(10); + + if (!i) + printk (KERN_DEBUG "%s: tulip_stop_rxtx() failed\n", + tp->pdev->slot_name); } } diff -Nru a/drivers/net/tulip/tulip_core.c b/drivers/net/tulip/tulip_core.c --- a/drivers/net/tulip/tulip_core.c 2005-03-03 19:33:21 -05:00 +++ b/drivers/net/tulip/tulip_core.c 2005-03-03 19:33:21 -05:00 @@ -20,8 +20,8 @@ #include #include -#include "tulip.h" #include +#include "tulip.h" #include #include #include --------------020202080705050805050400-- From greearb@candelatech.com Thu Mar 3 17:02:49 2005 Received: with ECARTIS (v1.0.0; list netdev); Thu, 03 Mar 2005 17:02:56 -0800 (PST) Received: from www.lanforge.com (ns1.lanforge.com [66.165.47.210]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j2412n72011204 for ; Thu, 3 Mar 2005 17:02:49 -0800 Received: from [4.33.45.22] (evrtwa1-ar2-4-33-045-022.evrtwa1.dsl-verizon.net [4.33.45.22]) (authenticated bits=0) by www.lanforge.com (8.12.8/8.12.8) with ESMTP id j241PMLH025363 for ; Thu, 3 Mar 2005 17:25:22 -0800 Message-ID: <4227B3B8.6060900@candelatech.com> Date: Thu, 03 Mar 2005 17:02:48 -0800 From: Ben Greear Organization: Candela Technologies User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.7.3) Gecko/20041020 X-Accept-Language: en-us, en MIME-Version: 1.0 To: "'netdev@oss.sgi.com'" Subject: setsockopt: SO_PRIORITY and IP_TOS Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV 0.83/743/Wed Mar 2 16:02:05 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 2360 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: greearb@candelatech.com Precedence: bulk X-list: netdev Content-Length: 640 Lines: 23 With regard to 2.6.11-rc4 (and probably others). I just noticed something that struck me as a bit strange. Might be per design though... If you set the IP_TOS and then the SO_PRIORITY for a socket, the TOS is what you set it to, and so is the priority. However, if you set the PRIORITY (to 55, in my case) and then set the IP_TOS (to 3, in my case), then the priority will be re-set to 0. My opinion is that setting the IP_TOS should not affect the priority, especially if it has already been specifically set on that socket. Thanks, Ben -- Ben Greear Candela Technologies Inc http://www.candelatech.com From tgraf@suug.ch Thu Mar 3 17:19:47 2005 Received: with ECARTIS (v1.0.0; list netdev); Thu, 03 Mar 2005 17:19:53 -0800 (PST) Received: from b.mx.projectdream.org (eth0-0.arisu.projectdream.org [194.158.4.191]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j241Jk3P012388 for ; Thu, 3 Mar 2005 17:19:47 -0800 Received: from postel.suug.ch (postel.suug.ch [195.134.158.23]) (using TLSv1 with cipher EDH-RSA-DES-CBC3-SHA (168/168 bits)) (No client certificate requested) by b.mx.projectdream.org (Postfix) with ESMTP id 3138195; Fri, 4 Mar 2005 02:19:20 +0100 (CET) Received: by postel.suug.ch (Postfix, from userid 10001) id 6D0191C0EA; Fri, 4 Mar 2005 02:20:03 +0100 (CET) Date: Fri, 4 Mar 2005 02:20:03 +0100 From: Thomas Graf To: "David S. Miller" Cc: netdev@oss.sgi.com Subject: [PATCH] [NET]: Fix deletion of local addresses only varying in prefix length Message-ID: <20050304012003.GA31837@postel.suug.ch> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline X-Virus-Scanned: ClamAV 0.83/743/Wed Mar 2 16:02:05 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 2361 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: tgraf@suug.ch Precedence: bulk X-list: netdev Content-Length: 1208 Lines: 31 The deletion of local addresses via netlink doesn't take the prefix length into account resulting in the deletion of the address that was added first given multiple addresses exist only varying in the prefix length. tgr:axs ~ ip -4 addr show dev lo 1: lo: mtu 16436 qdisc noqueue inet 127.0.0.1/8 scope host lo inet 1.1.1.1/1 scope global lo inet 1.1.1.1/2 scope global lo tgr:axs ~ ip addr del 1.1.1.1/2 dev lo tgr:axs ~ ip -4 addr show dev lo 1: lo: mtu 16436 qdisc noqueue inet 127.0.0.1/8 scope host lo inet 1.1.1.1/2 scope global lo Signed-off-by: Thomas Graf --- linux-2.6.11.orig/net/ipv4/devinet.c 2005-03-04 00:45:05.000000000 +0100 +++ linux-2.6.11/net/ipv4/devinet.c 2005-03-04 01:55:54.000000000 +0100 @@ -396,8 +396,9 @@ for (ifap = &in_dev->ifa_list; (ifa = *ifap) != NULL; ifap = &ifa->ifa_next) { if ((rta[IFA_LOCAL - 1] && + (ifm->ifa_prefixlen != ifa->ifa_prefixlen || memcmp(RTA_DATA(rta[IFA_LOCAL - 1]), - &ifa->ifa_local, 4)) || + &ifa->ifa_local, 4))) || (rta[IFA_LABEL - 1] && rtattr_strcmp(rta[IFA_LABEL - 1], ifa->ifa_label)) || (rta[IFA_ADDRESS - 1] && From buytenh@wantstofly.org Thu Mar 3 17:42:29 2005 Received: with ECARTIS (v1.0.0; list netdev); Thu, 03 Mar 2005 17:42:34 -0800 (PST) Received: from xi.wantstofly.org (alephnull.demon.nl [212.238.201.82]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j241gS1f013650 for ; Thu, 3 Mar 2005 17:42:29 -0800 Received: by xi.wantstofly.org (Postfix, from userid 500) id DDBD52B0F1; Fri, 4 Mar 2005 02:42:27 +0100 (MET) Date: Fri, 4 Mar 2005 02:42:27 +0100 From: Lennert Buytenhek To: John Heffner Cc: Stephen Hemminger , hadi@cyberus.ca, "David S. Miller" , rhee@eos.ncsu.edu, Yee-Ting.Li@nuim.ie, baruch@ev-en.org, netdev@oss.sgi.com Subject: Re: netif_rx packet dumping Message-ID: <20050304014227.GB28874@xi.wantstofly.org> References: <20050303125556.6850cfe5.davem@davemloft.net> <1109884688.1090.282.camel@jzny.localdomain> <20050303132143.7eef517c@dxpl.pdx.osdl.net> <1109885065.1098.285.camel@jzny.localdomain> <20050303133237.5d64578f.davem@davemloft.net> <20050303135416.0d6e7708@dxpl.pdx.osdl.net> <1109888811.1092.352.camel@jzny.localdomain> <20050303151606.3587394f@dxpl.pdx.osdl.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.1i X-Virus-Scanned: ClamAV 0.83/743/Wed Mar 2 16:02:05 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 2362 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: buytenh@wantstofly.org Precedence: bulk X-list: netdev Content-Length: 1077 Lines: 24 On Thu, Mar 03, 2005 at 06:48:50PM -0500, John Heffner wrote: > > Another alternative would be some form of adaptive threshold, > > something like adaptive drop tail described in this paper. > > http://www.ee.cityu.edu.hk/~gchen/pdf/ITC18.pdf > > > > Since netif_rx is running at interrupt time, it has to be simple/quick. > > All these AQM schemes are trying to solve a fundamentally different > problem. With TCP at least, the only congestion experienced at this point > will be transient, so you do not want to send any congestion signals (drop > packets) if you can avoid it at all. Making the limit as high as you can > tolerate seems like the best thing to me. If the traffic does not terminate locally (f.e. when doing routing), an insanely large queue has more disadvantages than advantages. If you're routing those exact same TCP packets on the way to their final destination, you run the risk of not sending out any congestion signals in the cases where you should, making your forwarding latency skyrocket (punishing all the other flows) in the process. --L From tgraf@suug.ch Thu Mar 3 18:29:29 2005 Received: with ECARTIS (v1.0.0; list netdev); Thu, 03 Mar 2005 18:29:35 -0800 (PST) Received: from b.mx.projectdream.org (eth0-0.arisu.projectdream.org [194.158.4.191]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j242TSi1016031 for ; Thu, 3 Mar 2005 18:29:29 -0800 Received: from postel.suug.ch (postel.suug.ch [195.134.158.23]) (using TLSv1 with cipher EDH-RSA-DES-CBC3-SHA (168/168 bits)) (No client certificate requested) by b.mx.projectdream.org (Postfix) with ESMTP id 1E78A86; Fri, 4 Mar 2005 03:29:01 +0100 (CET) Received: by postel.suug.ch (Postfix, from userid 10001) id 8C4801C0EA; Fri, 4 Mar 2005 03:29:40 +0100 (CET) Date: Fri, 4 Mar 2005 03:29:40 +0100 From: Thomas Graf To: "David S. Miller" Cc: netdev@oss.sgi.com Subject: [PATCH 1/2] [NEIGH]: rtnetlink neighbour cleanups Message-ID: <20050304022940.GB31837@postel.suug.ch> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline X-Virus-Scanned: ClamAV 0.83/743/Wed Mar 2 16:02:05 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 2363 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: tgraf@suug.ch Precedence: bulk X-list: netdev Content-Length: 3276 Lines: 119 Signed-off-by: Thomas Graf --- linux-2.6.11.orig/net/core/neighbour.c 2005-03-04 00:45:05.000000000 +0100 +++ linux-2.6.11/net/core/neighbour.c 2005-03-04 02:25:26.000000000 +0100 @@ -1430,6 +1430,7 @@ read_lock(&neigh_tbl_lock); for (tbl = neigh_tables; tbl; tbl = tbl->next) { + struct rtattr *dst_attr = nda[NDA_DST - 1]; struct neighbour *n; if (tbl->family != ndm->ndm_family) @@ -1437,20 +1438,18 @@ read_unlock(&neigh_tbl_lock); err = -EINVAL; - if (!nda[NDA_DST - 1] || - nda[NDA_DST - 1]->rta_len != RTA_LENGTH(tbl->key_len)) + if (!dst_attr || RTA_PAYLOAD(dst_attr) < tbl->key_len) goto out_dev_put; if (ndm->ndm_flags & NTF_PROXY) { - err = pneigh_delete(tbl, - RTA_DATA(nda[NDA_DST - 1]), dev); + err = pneigh_delete(tbl, RTA_DATA(dst_attr), dev); goto out_dev_put; } if (!dev) goto out; - n = neigh_lookup(tbl, RTA_DATA(nda[NDA_DST - 1]), dev); + n = neigh_lookup(tbl, RTA_DATA(dst_attr), dev); if (n) { err = neigh_update(n, NULL, NUD_FAILED, NEIGH_UPDATE_F_OVERRIDE| @@ -1482,6 +1481,8 @@ read_lock(&neigh_tbl_lock); for (tbl = neigh_tables; tbl; tbl = tbl->next) { + struct rtattr *lladdr_attr = nda[NDA_LLADDR - 1]; + struct rtattr *dst_attr = nda[NDA_DST - 1]; int override = 1; struct neighbour *n; @@ -1490,48 +1491,49 @@ read_unlock(&neigh_tbl_lock); err = -EINVAL; - if (!nda[NDA_DST - 1] || - nda[NDA_DST - 1]->rta_len != RTA_LENGTH(tbl->key_len)) + if (!dst_attr || RTA_PAYLOAD(dst_attr) < tbl->key_len) goto out_dev_put; + if (ndm->ndm_flags & NTF_PROXY) { err = -ENOBUFS; - if (pneigh_lookup(tbl, - RTA_DATA(nda[NDA_DST - 1]), dev, 1)) + if (pneigh_lookup(tbl, RTA_DATA(dst_attr), dev, 1)) err = 0; goto out_dev_put; } + err = -EINVAL; if (!dev) goto out; - if (nda[NDA_LLADDR - 1] && - nda[NDA_LLADDR - 1]->rta_len != RTA_LENGTH(dev->addr_len)) + if (lladdr_attr && RTA_PAYLOAD(lladdr_attr) < dev->addr_len) goto out_dev_put; - err = 0; - n = neigh_lookup(tbl, RTA_DATA(nda[NDA_DST - 1]), dev); + + n = neigh_lookup(tbl, RTA_DATA(dst_attr), dev); if (n) { - if (nlh->nlmsg_flags & NLM_F_EXCL) + if (nlh->nlmsg_flags & NLM_F_EXCL) { err = -EEXIST; + neigh_release(n); + goto out_dev_put; + } + override = nlh->nlmsg_flags & NLM_F_REPLACE; - } else if (!(nlh->nlmsg_flags & NLM_F_CREATE)) + } else if (!(nlh->nlmsg_flags & NLM_F_CREATE)) { err = -ENOENT; - else { - n = __neigh_lookup_errno(tbl, RTA_DATA(nda[NDA_DST - 1]), - dev); + goto out_dev_put; + } else { + n = __neigh_lookup_errno(tbl, RTA_DATA(dst_attr), dev); if (IS_ERR(n)) { err = PTR_ERR(n); - n = NULL; + goto out_dev_put; } } - if (!err) { - err = neigh_update(n, nda[NDA_LLADDR - 1] ? - RTA_DATA(nda[NDA_LLADDR - 1]) : - NULL, - ndm->ndm_state, - (override ? NEIGH_UPDATE_F_OVERRIDE : 0) | - NEIGH_UPDATE_F_ADMIN); - } - if (n) - neigh_release(n); + + err = neigh_update(n, + lladdr_attr ? RTA_DATA(lladdr_attr) : NULL, + ndm->ndm_state, + (override ? NEIGH_UPDATE_F_OVERRIDE : 0) | + NEIGH_UPDATE_F_ADMIN); + + neigh_release(n); goto out_dev_put; } From tgraf@suug.ch Thu Mar 3 18:31:01 2005 Received: with ECARTIS (v1.0.0; list netdev); Thu, 03 Mar 2005 18:31:05 -0800 (PST) Received: from b.mx.projectdream.org (eth0-0.arisu.projectdream.org [194.158.4.191]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j242V1mv016450 for ; Thu, 3 Mar 2005 18:31:01 -0800 Received: from postel.suug.ch (postel.suug.ch [195.134.158.23]) (using TLSv1 with cipher EDH-RSA-DES-CBC3-SHA (168/168 bits)) (No client certificate requested) by b.mx.projectdream.org (Postfix) with ESMTP id 8A59886; Fri, 4 Mar 2005 03:30:38 +0100 (CET) Received: by postel.suug.ch (Postfix, from userid 10001) id E4BEE1C0EA; Fri, 4 Mar 2005 03:31:21 +0100 (CET) Date: Fri, 4 Mar 2005 03:31:21 +0100 From: Thomas Graf To: "David S. Miller" Cc: netdev@oss.sgi.com Subject: [PATCH 2/2] [NEIGH]: Provide number of probes to userspace Message-ID: <20050304023121.GC31837@postel.suug.ch> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline X-Virus-Scanned: ClamAV 0.83/743/Wed Mar 2 16:02:05 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 2364 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: tgraf@suug.ch Precedence: bulk X-list: netdev Content-Length: 1161 Lines: 36 Provides number of probes done so far to userspace, quite useful for debugging. Signed-off-by: Thomas Graf --- linux-2.6.11.orig/include/linux/rtnetlink.h 2005-03-04 00:45:01.000000000 +0100 +++ linux-2.6.11/include/linux/rtnetlink.h 2005-03-04 02:26:25.000000000 +0100 @@ -446,6 +446,7 @@ NDA_DST, NDA_LLADDR, NDA_CACHEINFO, + NDA_PROBES, __NDA_MAX }; --- linux-2.6.11.orig/net/core/neighbour.c 2005-03-04 02:26:20.000000000 +0100 +++ linux-2.6.11/net/core/neighbour.c 2005-03-04 02:26:25.000000000 +0100 @@ -1554,6 +1554,7 @@ unsigned char *b = skb->tail; struct nda_cacheinfo ci; int locked = 0; + u32 probes; struct nlmsghdr *nlh = NLMSG_PUT(skb, pid, seq, event, sizeof(struct ndmsg)); struct ndmsg *ndm = NLMSG_DATA(nlh); @@ -1573,9 +1574,11 @@ ci.ndm_confirmed = now - n->confirmed; ci.ndm_updated = now - n->updated; ci.ndm_refcnt = atomic_read(&n->refcnt) - 1; + probes = atomic_read(&n->probes); read_unlock_bh(&n->lock); locked = 0; RTA_PUT(skb, NDA_CACHEINFO, sizeof(ci), &ci); + RTA_PUT(skb, NDA_PROBES, sizeof(probes), &probes); nlh->nlmsg_len = skb->tail - b; return skb->len; From tgraf@suug.ch Thu Mar 3 18:35:05 2005 Received: with ECARTIS (v1.0.0; list netdev); Thu, 03 Mar 2005 18:35:10 -0800 (PST) Received: from b.mx.projectdream.org (eth0-0.arisu.projectdream.org [194.158.4.191]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j242Z4im017211 for ; Thu, 3 Mar 2005 18:35:04 -0800 Received: from postel.suug.ch (postel.suug.ch [195.134.158.23]) (using TLSv1 with cipher EDH-RSA-DES-CBC3-SHA (168/168 bits)) (No client certificate requested) by b.mx.projectdream.org (Postfix) with ESMTP id 0A40686; Fri, 4 Mar 2005 03:34:38 +0100 (CET) Received: by postel.suug.ch (Postfix, from userid 10001) id 6C16D1C0EA; Fri, 4 Mar 2005 03:35:20 +0100 (CET) Date: Fri, 4 Mar 2005 03:35:20 +0100 From: Thomas Graf To: Stephen Hemminger Cc: netdev@oss.sgi.com Subject: [PATCH] iproute2 updates Message-ID: <20050304023520.GD31837@postel.suug.ch> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline X-Virus-Scanned: ClamAV 0.83/743/Wed Mar 2 16:02:05 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 2365 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: tgraf@suug.ch Precedence: bulk X-list: netdev Content-Length: 7471 Lines: 319 Stephen, You may pull the following changes from bk://tgr.bkbits.net/iproute2-tgr-fix o [NETEM] Fix off by one o update local header file copies o [NEIGH] print number of probes done so far (statistics mode only) # This is a BitKeeper generated diff -Nru style patch. # # ChangeSet # 2005/03/04 02:41:20+01:00 tgraf@suug.ch # [NETEM] Fix off by one # # tc/q_netem.c # 2005/03/04 02:41:20+01:00 tgraf@suug.ch +1 -1 # [NETEM] Fix off by one # diff -Nru a/tc/q_netem.c b/tc/q_netem.c --- a/tc/q_netem.c 2005-03-04 03:21:01 +01:00 +++ b/tc/q_netem.c 2005-03-04 03:21:01 +01:00 @@ -243,7 +243,7 @@ memcpy(&qopt, RTA_DATA(opt), sizeof(qopt)); if (len > 0) { - struct rtattr *tb[TCA_NETEM_MAX]; + struct rtattr *tb[TCA_NETEM_MAX+1]; parse_rtattr(tb, TCA_NETEM_MAX, RTA_DATA(opt) + sizeof(qopt), len); # This is a BitKeeper generated diff -Nru style patch. # # ChangeSet # 2005/03/04 02:53:35+01:00 tgraf@suug.ch # update local header file copies # # include/linux/tcp.h # 2005/03/04 02:53:35+01:00 tgraf@suug.ch +2 -0 # update local header file copies # # include/linux/pkt_sched.h # 2005/03/04 02:53:35+01:00 tgraf@suug.ch +27 -7 # update local header file copies # # include/linux/pkt_cls.h # 2005/03/04 02:53:35+01:00 tgraf@suug.ch +6 -3 # update local header file copies # # include/linux/netlink.h # 2005/03/04 02:53:35+01:00 tgraf@suug.ch +1 -0 # update local header file copies # # include/linux/gen_stats.h # 2005/03/04 02:53:35+01:00 tgraf@suug.ch +5 -0 # update local header file copies # diff -Nru a/include/linux/gen_stats.h b/include/linux/gen_stats.h --- a/include/linux/gen_stats.h 2005-03-04 03:21:09 +01:00 +++ b/include/linux/gen_stats.h 2005-03-04 03:21:09 +01:00 @@ -14,6 +14,7 @@ #define TCA_STATS_MAX (__TCA_STATS_MAX - 1) /** + * struct gnet_stats_basic - byte/packet throughput statistics * @bytes: number of seen bytes * @packets: number of seen packets */ @@ -24,6 +25,7 @@ }; /** + * struct gnet_stats_rate_est - rate estimator * @bps: current byte rate * @pps: current packet rate */ @@ -34,10 +36,12 @@ }; /** + * struct gnet_stats_queue - queuing statistics * @qlen: queue length * @backlog: backlog size of queue * @drops: number of dropped packets * @requeues: number of requeues + * @overlimits: number of enqueues over the limit */ struct gnet_stats_queue { @@ -49,6 +53,7 @@ }; /** + * struct gnet_estimator - rate estimator configuration * @interval: sampling period * @ewma_log: the log of measurement window weight */ diff -Nru a/include/linux/netlink.h b/include/linux/netlink.h --- a/include/linux/netlink.h 2005-03-04 03:21:09 +01:00 +++ b/include/linux/netlink.h 2005-03-04 03:21:09 +01:00 @@ -16,6 +16,7 @@ #define NETLINK_ROUTE6 11 /* af_inet6 route comm channel */ #define NETLINK_IP6_FW 13 #define NETLINK_DNRTMSG 14 /* DECnet routing messages */ +#define NETLINK_KOBJECT_UEVENT 15 /* Kernel messages to userspace */ #define NETLINK_TAPBASE 16 /* 16 to 31 are ethertap */ #define MAX_LINKS 32 diff -Nru a/include/linux/pkt_cls.h b/include/linux/pkt_cls.h --- a/include/linux/pkt_cls.h 2005-03-04 03:21:09 +01:00 +++ b/include/linux/pkt_cls.h 2005-03-04 03:21:09 +01:00 @@ -136,9 +136,9 @@ struct tcf_t { - __u32 install; - __u32 lastuse; - __u32 expires; + __u64 install; + __u64 lastuse; + __u64 expires; }; struct tc_cnt @@ -253,6 +253,7 @@ TCA_RSVP_SRC, TCA_RSVP_PINFO, TCA_RSVP_POLICE, + TCA_RSVP_ACT, __TCA_RSVP_MAX }; @@ -284,6 +285,7 @@ TCA_ROUTE4_FROM, TCA_ROUTE4_IIF, TCA_ROUTE4_POLICE, + TCA_ROUTE4_ACT, __TCA_ROUTE4_MAX }; @@ -315,6 +317,7 @@ TCA_TCINDEX_FALL_THROUGH, TCA_TCINDEX_CLASSID, TCA_TCINDEX_POLICE, + TCA_TCINDEX_ACT, __TCA_TCINDEX_MAX }; diff -Nru a/include/linux/pkt_sched.h b/include/linux/pkt_sched.h --- a/include/linux/pkt_sched.h 2005-03-04 03:21:09 +01:00 +++ b/include/linux/pkt_sched.h 2005-03-04 03:21:09 +01:00 @@ -117,8 +117,11 @@ TCA_TBF_PARMS, TCA_TBF_RTAB, TCA_TBF_PTAB, + __TCA_TBF_MAX, }; +#define TCA_TBF_MAX (__TCA_TBF_MAX - 1) + /* TEQL section */ @@ -151,8 +154,11 @@ TCA_RED_UNSPEC, TCA_RED_PARMS, TCA_RED_STAB, + __TCA_RED_MAX, }; +#define TCA_RED_MAX (__TCA_RED_MAX - 1) + struct tc_red_qopt { __u32 limit; /* HARD maximal queue length (bytes) */ @@ -183,8 +189,11 @@ TCA_GRED_PARMS, TCA_GRED_STAB, TCA_GRED_DPS, + __TCA_GRED_MAX, }; +#define TCA_GRED_MAX (__TCA_GRED_MAX - 1) + #define TCA_SET_OFF TCA_GRED_PARMS struct tc_gred_qopt { @@ -249,7 +258,11 @@ TCA_HTB_INIT, TCA_HTB_CTAB, TCA_HTB_RTAB, + __TCA_HTB_MAX, }; + +#define TCA_HTB_MAX (__TCA_HTB_MAX - 1) + struct tc_htb_xstats { __u32 lends; @@ -287,9 +300,12 @@ TCA_HFSC_RSC, TCA_HFSC_FSC, TCA_HFSC_USC, - TCA_HFSC_MAX = TCA_HFSC_USC + __TCA_HFSC_MAX, }; +#define TCA_HFSC_MAX (__TCA_HFSC_MAX - 1) + + /* CBQ section */ #define TC_CBQ_MAXPRIO 8 @@ -370,9 +386,10 @@ TCA_CBQ_RATE, TCA_CBQ_RTAB, TCA_CBQ_POLICE, + __TCA_CBQ_MAX, }; -#define TCA_CBQ_MAX TCA_CBQ_POLICE +#define TCA_CBQ_MAX (__TCA_CBQ_MAX - 1) /* dsmark section */ @@ -382,10 +399,11 @@ TCA_DSMARK_DEFAULT_INDEX, TCA_DSMARK_SET_TC_INDEX, TCA_DSMARK_MASK, - TCA_DSMARK_VALUE + TCA_DSMARK_VALUE, + __TCA_DSMARK_MAX, }; -#define TCA_DSMARK_MAX TCA_DSMARK_VALUE +#define TCA_DSMARK_MAX (__TCA_DSMARK_MAX - 1) /* ATM section */ @@ -396,10 +414,11 @@ TCA_ATM_HDR, /* LL header */ TCA_ATM_EXCESS, /* excess traffic class (0 for CLP) */ TCA_ATM_ADDR, /* PVC address (for output only) */ - TCA_ATM_STATE /* VC state (ATM_VS_*; for output only) */ + TCA_ATM_STATE, /* VC state (ATM_VS_*; for output only) */ + __TCA_ATM_MAX, }; -#define TCA_ATM_MAX TCA_ATM_STATE +#define TCA_ATM_MAX (__TCA_ATM_MAX - 1) /* Network emulator */ @@ -408,9 +427,10 @@ TCA_NETEM_UNSPEC, TCA_NETEM_CORR, TCA_NETEM_DELAY_DIST, + __TCA_NETEM_MAX, }; -#define TCA_NETEM_MAX TCA_NETEM_DELAY_DIST +#define TCA_NETEM_MAX (__TCA_NETEM_MAX - 1) struct tc_netem_qopt { diff -Nru a/include/linux/tcp.h b/include/linux/tcp.h --- a/include/linux/tcp.h 2005-03-04 03:21:09 +01:00 +++ b/include/linux/tcp.h 2005-03-04 03:21:09 +01:00 @@ -186,6 +186,8 @@ __u32 tcpi_rcv_rtt; __u32 tcpi_rcv_space; + + __u32 tcpi_total_retrans; }; #endif /* _LINUX_TCP_H */ # This is a BitKeeper generated diff -Nru style patch. # # ChangeSet # 2005/03/04 03:14:42+01:00 tgraf@suug.ch # [NEIGH] print number of probes done so far (statistics mode only) # # ip/ipneigh.c # 2005/03/04 03:14:42+01:00 tgraf@suug.ch +5 -0 # print number of probes done in statistics mode # # include/linux/rtnetlink.h # 2005/03/04 03:14:42+01:00 tgraf@suug.ch +1 -0 # update local header file copy # diff -Nru a/include/linux/rtnetlink.h b/include/linux/rtnetlink.h --- a/include/linux/rtnetlink.h 2005-03-04 03:21:15 +01:00 +++ b/include/linux/rtnetlink.h 2005-03-04 03:21:15 +01:00 @@ -446,6 +446,7 @@ NDA_DST, NDA_LLADDR, NDA_CACHEINFO, + NDA_PROBES, __NDA_MAX }; diff -Nru a/ip/ipneigh.c b/ip/ipneigh.c --- a/ip/ipneigh.c 2005-03-04 03:21:15 +01:00 +++ b/ip/ipneigh.c 2005-03-04 03:21:15 +01:00 @@ -287,6 +287,11 @@ ci->ndm_confirmed/hz, ci->ndm_updated/hz); } + if (tb[NDA_PROBES] && show_stats) { + __u32 p = *(__u32 *) RTA_DATA(tb[NDA_PROBES]); + fprintf(fp, " probes %u", p); + } + if (r->ndm_state) { int nud = r->ndm_state; fprintf(fp, " "); From yoshfuji@linux-ipv6.org Thu Mar 3 18:44:24 2005 Received: with ECARTIS (v1.0.0; list netdev); Thu, 03 Mar 2005 18:44:29 -0800 (PST) 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 j242iMlp018012 for ; Thu, 3 Mar 2005 18:44:24 -0800 Received: from localhost (localhost [127.0.0.1]) by yue.st-paulia.net (Postfix) with ESMTP id 3CCB733CC2; Fri, 4 Mar 2005 11:45:53 +0900 (JST) Date: Fri, 04 Mar 2005 11:45:50 +0900 (JST) Message-Id: <20050304.114550.47830081.yoshfuji@linux-ipv6.org> To: tgraf@suug.ch, davem@davemloft.net Cc: netdev@oss.sgi.com Subject: Re: [PATCH 1/2] [NEIGH]: rtnetlink neighbour cleanups From: YOSHIFUJI Hideaki / =?iso-2022-jp?B?GyRCNUhGIzFRTEAbKEI=?= In-Reply-To: <20050304022940.GB31837@postel.suug.ch> References: <20050304022940.GB31837@postel.suug.ch> Organization: USAGI Project X-URL: http://www.yoshifuji.org/%7Ehideaki/ X-Fingerprint: 9022 65EB 1ECF 3AD1 0BDF 80D8 4807 F894 E062 0EEA X-PGP-Key-URL: http://www.yoshifuji.org/%7Ehideaki/hideaki@yoshifuji.org.asc X-Face: "5$Al-.M>NJ%a'@hhZdQm:."qn~PA^gq4o*>iCFToq*bAi#4FRtx}enhuQKz7fNqQz\BYU] $~O_5m-9'}MIs`XGwIEscw;e5b>n"B_?j/AkL~i/MEaZBLP X-Mailer: Mew version 2.2 on Emacs 20.7 / Mule 4.1 (AOI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV 0.83/743/Wed Mar 2 16:02:05 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 2366 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: yoshfuji@linux-ipv6.org Precedence: bulk X-list: netdev Content-Length: 234 Lines: 6 In article <20050304022940.GB31837@postel.suug.ch> (at Fri, 4 Mar 2005 03:29:40 +0100), Thomas Graf says: > Signed-off-by: Thomas Graf Acked-by: Hideaki YOSHIFUJI --yoshfuji From yoshfuji@linux-ipv6.org Thu Mar 3 19:08:42 2005 Received: with ECARTIS (v1.0.0; list netdev); Thu, 03 Mar 2005 19:08:51 -0800 (PST) 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 j2438fYf019365 for ; Thu, 3 Mar 2005 19:08:41 -0800 Received: from localhost (localhost [127.0.0.1]) by yue.st-paulia.net (Postfix) with ESMTP id 1C2DA33CC2; Fri, 4 Mar 2005 12:10:12 +0900 (JST) Date: Fri, 04 Mar 2005 12:10:10 +0900 (JST) Message-Id: <20050304.121010.06175310.yoshfuji@linux-ipv6.org> To: davem@davemloft.net Cc: netdev@oss.sgi.com, yoshfuji@linux-ipv6.org Subject: [BK PATCH] IPV6 Updates 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-Virus-Scanned: ClamAV 0.83/743/Wed Mar 2 16:02:05 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 2367 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: yoshfuji@linux-ipv6.org Precedence: bulk X-list: netdev Content-Length: 57261 Lines: 1782 Hello. Please pull the following changesets available at: bk://bk.skbuff.net:20612/linux-2.6-inet6-01a_v6ready2/ After all, we can pass IPv6 Ready Logo Phase 1,2 Self Test2 without FAILs. HEADLINES --------- ChangeSet@1.2080, 2005-03-03 14:35:45+09:00, yoshfuji@linux-ipv6.org [IPV6] NDISC: Fix space calculation for link-layer address options. ChangeSet@1.2081, 2005-03-03 14:35:57+09:00, yoshfuji@linux-ipv6.org [IPV6] NDISC: Save space for ndisc_options{}. ChangeSet@1.2082, 2005-03-03 14:36:11+09:00, yoshfuji@linux-ipv6.org [IPV6] NDISC: Make ndisc_opt_lladdr_data() and check length inside. ChangeSet@1.2083, 2005-03-03 14:36:24+09:00, yoshfuji@linux-ipv6.org [IPV6] ROUTE: Add gc_min_interval_ms sysctl. ChangeSet@1.2084, 2005-03-03 14:36:36+09:00, yoshfuji@linux-ipv6.org [IPV6] NDISC: Ensure to notify up-to-date link information. ChangeSet@1.2085, 2005-03-03 14:36:49+09:00, yoshfuji@linux-ipv6.org [NET] NEIGHBOUR: Add hook for sysctl strategy. ChangeSet@1.2086, 2005-03-03 14:37:02+09:00, yoshfuji@linux-ipv6.org [IPV6] NDISC: NEWLINK notification on change of Reachable Time ChangeSet@1.2087, 2005-03-03 14:37:14+09:00, yoshfuji@linux-ipv6.org [IPV6] NDISC: Recompute Reachable Time on change of Base Reachable Time. ChangeSet@1.2088, 2005-03-03 14:37:28+09:00, yoshfuji@linux-ipv6.org [NET] NEIGHBOUR: Add retrans_time_ms and reachable_time_ms sysctls. ChangeSet@1.2089, 2005-03-03 14:37:40+09:00, yoshfuji@linux-ipv6.org [IPV6] NDISC: Deprecate base_reachable_time and retrans_timer. ChangeSet@1.2090, 2005-03-03 14:37:53+09:00, yoshfuji@linux-ipv6.org [IPV6] ROUTE: Keep cache entries for a while. ChangeSet@1.2091, 2005-03-03 14:38:06+09:00, yoshfuji@linux-ipv6.org [IPV6] NDISC: Ensure to send redirects. ChangeSet@1.2092, 2005-03-03 14:38:18+09:00, yoshfuji@linux-ipv6.org [IPV6] NDISC: Ensure to send redirects even if we don't know target's lladdr. ChangeSet@1.2093, 2005-03-03 14:38:31+09:00, yoshfuji@linux-ipv6.org [IPV6] Always add a fragment header after receiving TOO BIG w/ pmtu < 1280. ChangeSet@1.2094, 2005-03-03 14:38:44+09:00, yoshfuji@linux-ipv6.org [IPV6] Ensure to use interface hoplimit by default. ChangeSet@1.2095, 2005-03-03 14:38:57+09:00, yoshfuji@linux-ipv6.org [IPV6] Unify common functions to compare ipv6 prefixes. ChangeSet@1.2096, 2005-03-03 14:39:10+09:00, yoshfuji@linux-ipv6.org [IPV6] ADDRCONF: Update prefix route on address deletion. ChangeSet@1.2097, 2005-03-03 14:39:22+09:00, yoshfuji@linux-ipv6.org [IPV6] Mature enough, no longer EXPERIMENTAL. ChangeSet@1.2098, 2005-03-03 14:39:35+09:00, yoshfuji@linux-ipv6.org [NET] Don't use magic number for sysctl table definition. DIFFSTATS --------- net/ipv6/README | 8 - net/ipv6/addrconf.c | 62 ----------- net/ipv6/route.c | 9 - Documentation/filesystems/proc.txt | 21 ++- include/linux/ip.h | 1 include/linux/rtnetlink.h | 1 include/linux/sysctl.h | 12 +- include/net/addrconf.h | 2 include/net/dst.h | 9 + include/net/ipv6.h | 26 ++++ include/net/ndisc.h | 14 +- include/net/neighbour.h | 3 net/Kconfig | 23 +--- net/core/neighbour.c | 53 ++++++++- net/ipv4/arp.c | 2 net/ipv4/devinet.c | 6 - net/ipv6/addrconf.c | 13 -- net/ipv6/anycast.c | 30 ----- net/ipv6/icmp.c | 4 net/ipv6/ip6_fib.c | 38 ------- net/ipv6/ip6_output.c | 12 +- net/ipv6/ndisc.c | 197 +++++++++++++++++++++++++++---------- net/ipv6/netfilter/Kconfig | 4 net/ipv6/raw.c | 2 net/ipv6/route.c | 117 ++++++++++----------- net/ipv6/udp.c | 2 26 files changed, 361 insertions(+), 310 deletions(-) CHANGESETS ---------- ChangeSet@1.2080, 2005-03-03 14:35:45+09:00, yoshfuji@linux-ipv6.org [IPV6] NDISC: Fix space calculation for link-layer address options. Signed-off-by: Hideaki YOSHIFUJI diff -Nru a/net/ipv6/ndisc.c b/net/ipv6/ndisc.c --- a/net/ipv6/ndisc.c 2005-03-03 16:32:44 +09:00 +++ b/net/ipv6/ndisc.c 2005-03-03 16:32:44 +09:00 @@ -183,6 +183,11 @@ } } +static inline int ndisc_opt_addr_space(struct net_device *dev) +{ + return NDISC_OPT_SPACE(dev->addr_len + ndisc_addr_option_pad(dev->type)); +} + static u8 *ndisc_fill_addr_option(u8 *opt, int type, void *data, int data_len, unsigned short addr_type) { @@ -439,7 +444,7 @@ if (inc_opt) { if (dev->addr_len) - len += NDISC_OPT_SPACE(dev->addr_len); + len += ndisc_opt_addr_space(dev); else inc_opt = 0; } @@ -532,7 +537,7 @@ len = sizeof(struct icmp6hdr) + sizeof(struct in6_addr); send_llinfo = dev->addr_len && !ipv6_addr_any(saddr); if (send_llinfo) - len += NDISC_OPT_SPACE(dev->addr_len); + len += ndisc_opt_addr_space(dev); skb = sock_alloc_send_skb(sk, MAX_HEADER + len + LL_RESERVED_SPACE(dev), 1, &err); @@ -608,7 +613,7 @@ len = sizeof(struct icmp6hdr); if (dev->addr_len) - len += NDISC_OPT_SPACE(dev->addr_len); + len += ndisc_opt_addr_space(dev); skb = sock_alloc_send_skb(sk, MAX_HEADER + len + LL_RESERVED_SPACE(dev), 1, &err); @@ -744,7 +749,7 @@ lladdr = (u8*)(ndopts.nd_opts_src_lladdr + 1) + ndisc_addr_option_pad(dev->type); lladdrlen = ndopts.nd_opts_src_lladdr->nd_opt_len << 3; - if (lladdrlen != NDISC_OPT_SPACE(dev->addr_len)) { + if (lladdrlen != ndisc_opt_addr_space(dev)) { ND_PRINTK2(KERN_WARNING "ICMPv6 NS: invalid link-layer address length\n"); return; @@ -902,7 +907,7 @@ lladdr = (u8*)(ndopts.nd_opts_tgt_lladdr + 1) + ndisc_addr_option_pad(dev->type); lladdrlen = ndopts.nd_opts_tgt_lladdr->nd_opt_len << 3; - if (lladdrlen != NDISC_OPT_SPACE(dev->addr_len)) { + if (lladdrlen != ndisc_opt_addr_space(dev)) { ND_PRINTK2(KERN_WARNING "ICMPv6 NA: invalid link-layer address length\n"); return; @@ -997,7 +1002,7 @@ lladdr = (u8 *)(ndopts.nd_opts_src_lladdr + 1) + ndisc_addr_option_pad(skb->dev->type); lladdrlen = ndopts.nd_opts_src_lladdr->nd_opt_len << 3; - if (lladdrlen != NDISC_OPT_SPACE(skb->dev->addr_len)) + if (lladdrlen != ndisc_opt_addr_space(skb->dev)) goto out; } @@ -1171,7 +1176,7 @@ lladdr = (u8*)((ndopts.nd_opts_src_lladdr)+1) + ndisc_addr_option_pad(skb->dev->type); lladdrlen = ndopts.nd_opts_src_lladdr->nd_opt_len << 3; - if (lladdrlen != NDISC_OPT_SPACE(skb->dev->addr_len)) { + if (lladdrlen != ndisc_opt_addr_space(skb->dev)) { ND_PRINTK2(KERN_WARNING "ICMPv6 RA: invalid link-layer address length\n"); goto out; @@ -1294,7 +1299,7 @@ lladdr = (u8*)(ndopts.nd_opts_tgt_lladdr + 1) + ndisc_addr_option_pad(skb->dev->type); lladdrlen = ndopts.nd_opts_tgt_lladdr->nd_opt_len << 3; - if (lladdrlen != NDISC_OPT_SPACE(skb->dev->addr_len)) { + if (lladdrlen != ndisc_opt_addr_space(skb->dev)) { ND_PRINTK2(KERN_WARNING "ICMPv6 Redirect: invalid link-layer address length\n"); in6_dev_put(in6_dev); @@ -1367,7 +1372,7 @@ if (dev->addr_len) { if (neigh->nud_state&NUD_VALID) { - len += NDISC_OPT_SPACE(dev->addr_len); + len += ndisc_opt_addr_space(dev); } else { /* If nexthop is not valid, do not redirect! We will make it later, when will be sure, ChangeSet@1.2081, 2005-03-03 14:35:57+09:00, yoshfuji@linux-ipv6.org [IPV6] NDISC: Save space for ndisc_options{}. Pointed out by Krishna Kumar . Also, size of structure is now adjusted automatically. Signed-off-by: Hideaki YOSHIFUJI diff -Nru a/include/net/ndisc.h b/include/net/ndisc.h --- a/include/net/ndisc.h 2005-03-03 16:32:49 +09:00 +++ b/include/net/ndisc.h 2005-03-03 16:32:49 +09:00 @@ -15,11 +15,15 @@ * ndisc options */ -#define ND_OPT_SOURCE_LL_ADDR 1 -#define ND_OPT_TARGET_LL_ADDR 2 -#define ND_OPT_PREFIX_INFO 3 -#define ND_OPT_REDIRECT_HDR 4 -#define ND_OPT_MTU 5 +enum { + __ND_OPT_PREFIX_INFO_END = 0, + ND_OPT_SOURCE_LL_ADDR = 1, /* RFC2461 */ + ND_OPT_TARGET_LL_ADDR = 2, /* RFC2461 */ + ND_OPT_PREFIX_INFO = 3, /* RFC2461 */ + ND_OPT_REDIRECT_HDR = 4, /* RFC2461 */ + ND_OPT_MTU = 5, /* RFC2461 */ + __ND_OPT_MAX +}; #define MAX_RTR_SOLICITATION_DELAY HZ diff -Nru a/net/ipv6/ndisc.c b/net/ipv6/ndisc.c --- a/net/ipv6/ndisc.c 2005-03-03 16:32:49 +09:00 +++ b/net/ipv6/ndisc.c 2005-03-03 16:32:49 +09:00 @@ -156,14 +156,13 @@ /* ND options */ struct ndisc_options { - struct nd_opt_hdr *nd_opt_array[7]; - struct nd_opt_hdr *nd_opt_piend; + struct nd_opt_hdr *nd_opt_array[__ND_OPT_MAX]; }; #define nd_opts_src_lladdr nd_opt_array[ND_OPT_SOURCE_LL_ADDR] #define nd_opts_tgt_lladdr nd_opt_array[ND_OPT_TARGET_LL_ADDR] #define nd_opts_pi nd_opt_array[ND_OPT_PREFIX_INFO] -#define nd_opts_pi_end nd_opt_piend +#define nd_opts_pi_end nd_opt_array[__ND_OPT_PREFIX_INFO_END] #define nd_opts_rh nd_opt_array[ND_OPT_REDIRECT_HDR] #define nd_opts_mtu nd_opt_array[ND_OPT_MTU] ChangeSet@1.2082, 2005-03-03 14:36:11+09:00, yoshfuji@linux-ipv6.org [IPV6] NDISC: Make ndisc_opt_lladdr_data() and check length inside. What we should do is to check lladdrlen and get pointer for link-layer address option. Since we know lladdrlen == dev->addr_len, we can check inside. Singned-off-by: Hideaki YOSHIFUJI diff -Nru a/net/ipv6/ndisc.c b/net/ipv6/ndisc.c --- a/net/ipv6/ndisc.c 2005-03-03 16:32:53 +09:00 +++ b/net/ipv6/ndisc.c 2005-03-03 16:32:53 +09:00 @@ -271,6 +271,17 @@ return ndopts; } +static inline u8 *ndisc_opt_addr_data(struct nd_opt_hdr *p, + struct net_device *dev) +{ + u8 *lladdr = (u8 *)(p + 1); + int lladdrlen = p->nd_opt_len << 3; + int prepad = ndisc_addr_option_pad(dev->type); + if (lladdrlen != NDISC_OPT_SPACE(dev->addr_len + prepad)) + return NULL; + return (lladdr + prepad); +} + int ndisc_mc_map(struct in6_addr *addr, char *buf, struct net_device *dev, int dir) { switch (dev->type) { @@ -708,7 +719,6 @@ struct in6_addr *saddr = &skb->nh.ipv6h->saddr; struct in6_addr *daddr = &skb->nh.ipv6h->daddr; u8 *lladdr = NULL; - int lladdrlen = 0; u32 ndoptlen = skb->tail - msg->opt; struct ndisc_options ndopts; struct net_device *dev = skb->dev; @@ -745,10 +755,8 @@ } if (ndopts.nd_opts_src_lladdr) { - lladdr = (u8*)(ndopts.nd_opts_src_lladdr + 1) + - ndisc_addr_option_pad(dev->type); - lladdrlen = ndopts.nd_opts_src_lladdr->nd_opt_len << 3; - if (lladdrlen != ndisc_opt_addr_space(dev)) { + lladdr = ndisc_opt_addr_data(ndopts.nd_opts_src_lladdr, dev); + if (!lladdr) { ND_PRINTK2(KERN_WARNING "ICMPv6 NS: invalid link-layer address length\n"); return; @@ -871,7 +879,6 @@ struct in6_addr *saddr = &skb->nh.ipv6h->saddr; struct in6_addr *daddr = &skb->nh.ipv6h->daddr; u8 *lladdr = NULL; - int lladdrlen = 0; u32 ndoptlen = skb->tail - msg->opt; struct ndisc_options ndopts; struct net_device *dev = skb->dev; @@ -903,10 +910,8 @@ return; } if (ndopts.nd_opts_tgt_lladdr) { - lladdr = (u8*)(ndopts.nd_opts_tgt_lladdr + 1) + - ndisc_addr_option_pad(dev->type); - lladdrlen = ndopts.nd_opts_tgt_lladdr->nd_opt_len << 3; - if (lladdrlen != ndisc_opt_addr_space(dev)) { + lladdr = ndisc_opt_addr_data(ndopts.nd_opts_tgt_lladdr, dev); + if (!lladdr) { ND_PRINTK2(KERN_WARNING "ICMPv6 NA: invalid link-layer address length\n"); return; @@ -967,7 +972,6 @@ struct in6_addr *saddr = &skb->nh.ipv6h->saddr; struct ndisc_options ndopts; u8 *lladdr = NULL; - int lladdrlen = 0; if (skb->len < sizeof(*rs_msg)) return; @@ -998,10 +1002,9 @@ } if (ndopts.nd_opts_src_lladdr) { - lladdr = (u8 *)(ndopts.nd_opts_src_lladdr + 1) + - ndisc_addr_option_pad(skb->dev->type); - lladdrlen = ndopts.nd_opts_src_lladdr->nd_opt_len << 3; - if (lladdrlen != ndisc_opt_addr_space(skb->dev)) + lladdr = ndisc_opt_addr_data(ndopts.nd_opts_src_lladdr, + skb->dev); + if (!lladdr) goto out; } @@ -1170,12 +1173,10 @@ skb->dev, 1); if (neigh) { u8 *lladdr = NULL; - int lladdrlen; if (ndopts.nd_opts_src_lladdr) { - lladdr = (u8*)((ndopts.nd_opts_src_lladdr)+1) + - ndisc_addr_option_pad(skb->dev->type); - lladdrlen = ndopts.nd_opts_src_lladdr->nd_opt_len << 3; - if (lladdrlen != ndisc_opt_addr_space(skb->dev)) { + lladdr = ndisc_opt_addr_data(ndopts.nd_opts_src_lladdr, + skb->dev); + if (!lladdr) { ND_PRINTK2(KERN_WARNING "ICMPv6 RA: invalid link-layer address length\n"); goto out; @@ -1240,7 +1241,6 @@ struct ndisc_options ndopts; int optlen; u8 *lladdr = NULL; - int lladdrlen; if (!(ipv6_addr_type(&skb->nh.ipv6h->saddr) & IPV6_ADDR_LINKLOCAL)) { ND_PRINTK2(KERN_WARNING @@ -1295,10 +1295,9 @@ return; } if (ndopts.nd_opts_tgt_lladdr) { - lladdr = (u8*)(ndopts.nd_opts_tgt_lladdr + 1) + - ndisc_addr_option_pad(skb->dev->type); - lladdrlen = ndopts.nd_opts_tgt_lladdr->nd_opt_len << 3; - if (lladdrlen != ndisc_opt_addr_space(skb->dev)) { + lladdr = ndisc_opt_addr_data(ndopts.nd_opts_tgt_lladdr, + skb->dev); + if (!lladdr) { ND_PRINTK2(KERN_WARNING "ICMPv6 Redirect: invalid link-layer address length\n"); in6_dev_put(in6_dev); ChangeSet@1.2083, 2005-03-03 14:36:24+09:00, yoshfuji@linux-ipv6.org [IPV6] ROUTE: Add gc_min_interval_ms sysctl. Signed-off-by: Hideaki YOSHIFUJI diff -Nru a/include/linux/sysctl.h b/include/linux/sysctl.h --- a/include/linux/sysctl.h 2005-03-03 16:32:58 +09:00 +++ b/include/linux/sysctl.h 2005-03-03 16:32:58 +09:00 @@ -455,7 +455,8 @@ NET_IPV6_ROUTE_GC_INTERVAL=6, NET_IPV6_ROUTE_GC_ELASTICITY=7, NET_IPV6_ROUTE_MTU_EXPIRES=8, - NET_IPV6_ROUTE_MIN_ADVMSS=9 + NET_IPV6_ROUTE_MIN_ADVMSS=9, + NET_IPV6_ROUTE_GC_MIN_INTERVAL_MS=10 }; enum { diff -Nru a/net/ipv6/route.c b/net/ipv6/route.c --- a/net/ipv6/route.c 2005-03-03 16:32:58 +09:00 +++ b/net/ipv6/route.c 2005-03-03 16:32:58 +09:00 @@ -2080,6 +2080,15 @@ .proc_handler = &proc_dointvec_jiffies, .strategy = &sysctl_jiffies, }, + { + .ctl_name = NET_IPV6_ROUTE_GC_MIN_INTERVAL_MS, + .procname = "gc_min_interval_ms", + .data = &ip6_rt_gc_min_interval, + .maxlen = sizeof(int), + .mode = 0644, + .proc_handler = &proc_dointvec_ms_jiffies, + .strategy = &sysctl_ms_jiffies, + }, { .ctl_name = 0 } }; ChangeSet@1.2084, 2005-03-03 14:36:36+09:00, yoshfuji@linux-ipv6.org [IPV6] NDISC: Ensure to notify up-to-date link information. Signed-off-by: Hideaki YOSHIFUJI diff -Nru a/net/ipv6/ndisc.c b/net/ipv6/ndisc.c --- a/net/ipv6/ndisc.c 2005-03-03 16:33:03 +09:00 +++ b/net/ipv6/ndisc.c 2005-03-03 16:33:03 +09:00 @@ -1540,13 +1540,16 @@ { struct net_device *dev = ctl->extra1; struct inet6_dev *idev; + int ret; + + ret = proc_dointvec(ctl, write, filp, buffer, lenp, ppos); - if (write && dev && (idev = in6_dev_get(dev)) != NULL) { + if (write && ret == 0 && dev && (idev = in6_dev_get(dev)) != NULL) { idev->tstamp = jiffies; inet6_ifinfo_notify(RTM_NEWLINK, idev); in6_dev_put(idev); } - return proc_dointvec(ctl, write, filp, buffer, lenp, ppos); + return ret; } #endif ChangeSet@1.2085, 2005-03-03 14:36:49+09:00, yoshfuji@linux-ipv6.org [NET] NEIGHBOUR: Add hook for sysctl strategy. Signed-off-by: Hideaki YOSHIFUJI diff -Nru a/include/net/neighbour.h b/include/net/neighbour.h --- a/include/net/neighbour.h 2005-03-03 16:33:07 +09:00 +++ b/include/net/neighbour.h 2005-03-03 16:33:07 +09:00 @@ -274,7 +274,8 @@ struct neigh_parms *p, int p_id, int pdev_id, char *p_name, - proc_handler *proc_handler); + proc_handler *proc_handler, + ctl_handler *strategy); extern void neigh_sysctl_unregister(struct neigh_parms *p); static inline void __neigh_parms_put(struct neigh_parms *parms) diff -Nru a/net/core/neighbour.c b/net/core/neighbour.c --- a/net/core/neighbour.c 2005-03-03 16:33:07 +09:00 +++ b/net/core/neighbour.c 2005-03-03 16:33:07 +09:00 @@ -2200,7 +2200,7 @@ int neigh_sysctl_register(struct net_device *dev, struct neigh_parms *p, int p_id, int pdev_id, char *p_name, - proc_handler *handler) + proc_handler *handler, ctl_handler *strategy) { struct neigh_sysctl_table *t = kmalloc(sizeof(*t), GFP_KERNEL); const char *dev_name_source = NULL; @@ -2214,8 +2214,9 @@ t->neigh_vars[1].data = &p->ucast_probes; t->neigh_vars[2].data = &p->app_probes; t->neigh_vars[3].data = &p->retrans_time; - if (handler) { + if (handler || strategy) { t->neigh_vars[3].proc_handler = handler; + t->neigh_vars[3].strategy = strategy; t->neigh_vars[3].extra1 = dev; } t->neigh_vars[4].data = &p->base_reachable_time; diff -Nru a/net/ipv4/arp.c b/net/ipv4/arp.c --- a/net/ipv4/arp.c 2005-03-03 16:33:07 +09:00 +++ b/net/ipv4/arp.c 2005-03-03 16:33:07 +09:00 @@ -1243,7 +1243,7 @@ arp_proc_init(); #ifdef CONFIG_SYSCTL neigh_sysctl_register(NULL, &arp_tbl.parms, NET_IPV4, - NET_IPV4_NEIGH, "ipv4", NULL); + NET_IPV4_NEIGH, "ipv4", NULL, NULL); #endif register_netdevice_notifier(&arp_netdev_notifier); } diff -Nru a/net/ipv4/devinet.c b/net/ipv4/devinet.c --- a/net/ipv4/devinet.c 2005-03-03 16:33:07 +09:00 +++ b/net/ipv4/devinet.c 2005-03-03 16:33:07 +09:00 @@ -153,7 +153,7 @@ dev_hold(dev); #ifdef CONFIG_SYSCTL neigh_sysctl_register(dev, in_dev->arp_parms, NET_IPV4, - NET_IPV4_NEIGH, "ipv4", NULL); + NET_IPV4_NEIGH, "ipv4", NULL, NULL); #endif /* Account for reference dev->ip_ptr */ @@ -992,7 +992,7 @@ devinet_sysctl_unregister(&in_dev->cnf); neigh_sysctl_unregister(in_dev->arp_parms); neigh_sysctl_register(dev, in_dev->arp_parms, NET_IPV4, - NET_IPV4_NEIGH, "ipv4", NULL); + NET_IPV4_NEIGH, "ipv4", NULL, NULL); devinet_sysctl_register(in_dev, &in_dev->cnf); #endif break; diff -Nru a/net/ipv6/addrconf.c b/net/ipv6/addrconf.c --- a/net/ipv6/addrconf.c 2005-03-03 16:33:07 +09:00 +++ b/net/ipv6/addrconf.c 2005-03-03 16:33:07 +09:00 @@ -391,7 +391,9 @@ ndev->tstamp = jiffies; #ifdef CONFIG_SYSCTL neigh_sysctl_register(dev, ndev->nd_parms, NET_IPV6, - NET_IPV6_NEIGH, "ipv6", &ndisc_ifinfo_sysctl_change); + NET_IPV6_NEIGH, "ipv6", + &ndisc_ifinfo_sysctl_change, + NULL); addrconf_sysctl_register(ndev, &ndev->cnf); #endif } @@ -1982,7 +1984,10 @@ if (idev) { addrconf_sysctl_unregister(&idev->cnf); neigh_sysctl_unregister(idev->nd_parms); - neigh_sysctl_register(dev, idev->nd_parms, NET_IPV6, NET_IPV6_NEIGH, "ipv6", &ndisc_ifinfo_sysctl_change); + neigh_sysctl_register(dev, idev->nd_parms, + NET_IPV6, NET_IPV6_NEIGH, "ipv6", + &ndisc_ifinfo_sysctl_change, + NULL); addrconf_sysctl_register(idev, &idev->cnf); } #endif diff -Nru a/net/ipv6/ndisc.c b/net/ipv6/ndisc.c --- a/net/ipv6/ndisc.c 2005-03-03 16:33:07 +09:00 +++ b/net/ipv6/ndisc.c 2005-03-03 16:33:07 +09:00 @@ -1584,7 +1584,7 @@ #ifdef CONFIG_SYSCTL neigh_sysctl_register(NULL, &nd_tbl.parms, NET_IPV6, NET_IPV6_NEIGH, - "ipv6", &ndisc_ifinfo_sysctl_change); + "ipv6", &ndisc_ifinfo_sysctl_change, NULL); #endif register_netdevice_notifier(&ndisc_netdev_notifier); ChangeSet@1.2086, 2005-03-03 14:37:02+09:00, yoshfuji@linux-ipv6.org [IPV6] NDISC: NEWLINK notification on change of Reachable Time Signed-off-by: Hideaki YOSHIFUJI diff -Nru a/net/core/neighbour.c b/net/core/neighbour.c --- a/net/core/neighbour.c 2005-03-03 16:33:12 +09:00 +++ b/net/core/neighbour.c 2005-03-03 16:33:12 +09:00 @@ -2215,9 +2215,14 @@ t->neigh_vars[2].data = &p->app_probes; t->neigh_vars[3].data = &p->retrans_time; if (handler || strategy) { + /* RetransTime */ t->neigh_vars[3].proc_handler = handler; t->neigh_vars[3].strategy = strategy; t->neigh_vars[3].extra1 = dev; + /* ReachableTime */ + t->neigh_vars[4].proc_handler = handler; + t->neigh_vars[4].strategy = strategy; + t->neigh_vars[4].extra1 = dev; } t->neigh_vars[4].data = &p->base_reachable_time; t->neigh_vars[5].data = &p->delay_probe_time; diff -Nru a/net/ipv6/ndisc.c b/net/ipv6/ndisc.c --- a/net/ipv6/ndisc.c 2005-03-03 16:33:12 +09:00 +++ b/net/ipv6/ndisc.c 2005-03-03 16:33:12 +09:00 @@ -1542,7 +1542,17 @@ struct inet6_dev *idev; int ret; - ret = proc_dointvec(ctl, write, filp, buffer, lenp, ppos); + switch (ctl->ctl_name) { + case NET_NEIGH_RETRANS_TIME: + ret = proc_dointvec(ctl, write, filp, buffer, lenp, ppos); + break; + case NET_NEIGH_REACHABLE_TIME: + ret = proc_dointvec_jiffies(ctl, write, + filp, buffer, lenp, ppos); + break; + default: + ret = -1; + } if (write && ret == 0 && dev && (idev = in6_dev_get(dev)) != NULL) { idev->tstamp = jiffies; @@ -1551,6 +1561,36 @@ } return ret; } + +int ndisc_ifinfo_sysctl_strategy(ctl_table *ctl, int __user *name, int nlen, + void __user *oldval, size_t __user *oldlenp, + void __user *newval, size_t newlen, + void **context) +{ + struct net_device *dev = ctl->extra1; + struct inet6_dev *idev; + int ret; + + switch (ctl->ctl_name) { + case NET_NEIGH_REACHABLE_TIME: + ret = sysctl_jiffies(ctl, name, nlen, + oldval, oldlenp, newval, newlen, + context); + break; + default: + ret = 0; + } + + if (newval && newlen && ret > 0 && + dev && (idev = in6_dev_get(dev)) != NULL) { + idev->tstamp = jiffies; + inet6_ifinfo_notify(RTM_NEWLINK, idev); + in6_dev_put(idev); + } + + return ret; +} + #endif int __init ndisc_init(struct net_proto_family *ops) @@ -1584,7 +1624,9 @@ #ifdef CONFIG_SYSCTL neigh_sysctl_register(NULL, &nd_tbl.parms, NET_IPV6, NET_IPV6_NEIGH, - "ipv6", &ndisc_ifinfo_sysctl_change, NULL); + "ipv6", + &ndisc_ifinfo_sysctl_change, + &ndisc_ifinfo_sysctl_strategy); #endif register_netdevice_notifier(&ndisc_netdev_notifier); ChangeSet@1.2087, 2005-03-03 14:37:14+09:00, yoshfuji@linux-ipv6.org [IPV6] NDISC: Recompute Reachable Time on change of Base Reachable Time. Signed-off-by: Hideaki YOSHIFUJI diff -Nru a/net/ipv6/ndisc.c b/net/ipv6/ndisc.c --- a/net/ipv6/ndisc.c 2005-03-03 16:33:17 +09:00 +++ b/net/ipv6/ndisc.c 2005-03-03 16:33:17 +09:00 @@ -1555,6 +1555,8 @@ } if (write && ret == 0 && dev && (idev = in6_dev_get(dev)) != NULL) { + if (ctl->ctl_name == NET_NEIGH_REACHABLE_TIME) + idev->nd_parms->reachable_time = neigh_rand_reach_time(idev->nd_parms->base_reachable_time); idev->tstamp = jiffies; inet6_ifinfo_notify(RTM_NEWLINK, idev); in6_dev_put(idev); @@ -1583,6 +1585,8 @@ if (newval && newlen && ret > 0 && dev && (idev = in6_dev_get(dev)) != NULL) { + if (ctl->ctl_name == NET_NEIGH_REACHABLE_TIME) + idev->nd_parms->reachable_time = neigh_rand_reach_time(idev->nd_parms->base_reachable_time); idev->tstamp = jiffies; inet6_ifinfo_notify(RTM_NEWLINK, idev); in6_dev_put(idev); ChangeSet@1.2088, 2005-03-03 14:37:28+09:00, yoshfuji@linux-ipv6.org [NET] NEIGHBOUR: Add retrans_time_ms and reachable_time_ms sysctls. Signed-off-by: Hideaki YOSHIFUJI diff -Nru a/Documentation/filesystems/proc.txt b/Documentation/filesystems/proc.txt --- a/Documentation/filesystems/proc.txt 2005-03-03 16:33:21 +09:00 +++ b/Documentation/filesystems/proc.txt 2005-03-03 16:33:21 +09:00 @@ -1754,18 +1754,25 @@ In the interface directories you'll find the following entries: -base_reachable_time -------------------- +base_reachable_time, base_reachable_time_ms +------------------------------------------- A base value used for computing the random reachable time value as specified in RFC2461. -retrans_time ------------- +Expression of base_reachable_time is in seconds. +Expression of base_reachable_time_ms is in milliseconds. -The time, expressed in jiffies (1/100 sec), between retransmitted Neighbor -Solicitation messages. Used for address resolution and to determine if a -neighbor is unreachable. +retrans_time, retrans_time_ms +----------------------------- + +The time between retransmitted Neighbor Solicitation messages. +Used for address resolution and to determine if a neighbor is +unreachable. + +Expression of retrans_time is in 1/100 seconds (for IPv4) or in jiffies +(for IPv6). +Expression of retrans_time_ms is in milliseconds. unres_qlen ---------- diff -Nru a/include/linux/sysctl.h b/include/linux/sysctl.h --- a/include/linux/sysctl.h 2005-03-03 16:33:21 +09:00 +++ b/include/linux/sysctl.h 2005-03-03 16:33:21 +09:00 @@ -501,7 +501,10 @@ NET_NEIGH_GC_INTERVAL=13, NET_NEIGH_GC_THRESH1=14, NET_NEIGH_GC_THRESH2=15, - NET_NEIGH_GC_THRESH3=16 + NET_NEIGH_GC_THRESH3=16, + NET_NEIGH_RETRANS_TIME_MS=17, + NET_NEIGH_REACHABLE_TIME_MS=18, + __NET_NEIGH_MAX }; /* /proc/sys/net/ipx */ diff -Nru a/net/core/neighbour.c b/net/core/neighbour.c --- a/net/core/neighbour.c 2005-03-03 16:33:21 +09:00 +++ b/net/core/neighbour.c 2005-03-03 16:33:21 +09:00 @@ -2047,7 +2047,7 @@ static struct neigh_sysctl_table { struct ctl_table_header *sysctl_header; - ctl_table neigh_vars[17]; + ctl_table neigh_vars[__NET_NEIGH_MAX]; ctl_table neigh_dev[2]; ctl_table neigh_neigh_dir[2]; ctl_table neigh_proto_dir[2]; @@ -2170,6 +2170,22 @@ .mode = 0644, .proc_handler = &proc_dointvec, }, + { + .ctl_name = NET_NEIGH_RETRANS_TIME_MS, + .procname = "retrans_time_ms", + .maxlen = sizeof(int), + .mode = 0644, + .proc_handler = &proc_dointvec_ms_jiffies, + .strategy = &sysctl_ms_jiffies, + }, + { + .ctl_name = NET_NEIGH_REACHABLE_TIME_MS, + .procname = "base_reachable_time_ms", + .maxlen = sizeof(int), + .mode = 0644, + .proc_handler = &proc_dointvec_ms_jiffies, + .strategy = &sysctl_ms_jiffies, + }, }, .neigh_dev = { { @@ -2214,16 +2230,6 @@ t->neigh_vars[1].data = &p->ucast_probes; t->neigh_vars[2].data = &p->app_probes; t->neigh_vars[3].data = &p->retrans_time; - if (handler || strategy) { - /* RetransTime */ - t->neigh_vars[3].proc_handler = handler; - t->neigh_vars[3].strategy = strategy; - t->neigh_vars[3].extra1 = dev; - /* ReachableTime */ - t->neigh_vars[4].proc_handler = handler; - t->neigh_vars[4].strategy = strategy; - t->neigh_vars[4].extra1 = dev; - } t->neigh_vars[4].data = &p->base_reachable_time; t->neigh_vars[5].data = &p->delay_probe_time; t->neigh_vars[6].data = &p->gc_staletime; @@ -2233,16 +2239,41 @@ t->neigh_vars[10].data = &p->proxy_delay; t->neigh_vars[11].data = &p->locktime; - dev_name_source = t->neigh_dev[0].procname; if (dev) { dev_name_source = dev->name; t->neigh_dev[0].ctl_name = dev->ifindex; - memset(&t->neigh_vars[12], 0, sizeof(ctl_table)); + t->neigh_vars[12].procname = NULL; + t->neigh_vars[13].procname = NULL; + t->neigh_vars[14].procname = NULL; + t->neigh_vars[15].procname = NULL; } else { + dev_name_source = t->neigh_dev[0].procname; t->neigh_vars[12].data = (int *)(p + 1); t->neigh_vars[13].data = (int *)(p + 1) + 1; t->neigh_vars[14].data = (int *)(p + 1) + 2; t->neigh_vars[15].data = (int *)(p + 1) + 3; + } + + t->neigh_vars[16].data = &p->retrans_time; + t->neigh_vars[17].data = &p->base_reachable_time; + + if (handler || strategy) { + /* RetransTime */ + t->neigh_vars[3].proc_handler = handler; + t->neigh_vars[3].strategy = strategy; + t->neigh_vars[3].extra1 = dev; + /* ReachableTime */ + t->neigh_vars[4].proc_handler = handler; + t->neigh_vars[4].strategy = strategy; + t->neigh_vars[4].extra1 = dev; + /* RetransTime (in milliseconds)*/ + t->neigh_vars[16].proc_handler = handler; + t->neigh_vars[16].strategy = strategy; + t->neigh_vars[16].extra1 = dev; + /* ReachableTime (in milliseconds) */ + t->neigh_vars[17].proc_handler = handler; + t->neigh_vars[17].strategy = strategy; + t->neigh_vars[17].extra1 = dev; } dev_name = net_sysctl_strdup(dev_name_source); diff -Nru a/net/ipv6/ndisc.c b/net/ipv6/ndisc.c --- a/net/ipv6/ndisc.c 2005-03-03 16:33:21 +09:00 +++ b/net/ipv6/ndisc.c 2005-03-03 16:33:21 +09:00 @@ -1550,12 +1550,18 @@ ret = proc_dointvec_jiffies(ctl, write, filp, buffer, lenp, ppos); break; + case NET_NEIGH_RETRANS_TIME_MS: + case NET_NEIGH_REACHABLE_TIME_MS: + ret = proc_dointvec_ms_jiffies(ctl, write, + filp, buffer, lenp, ppos); + break; default: ret = -1; } if (write && ret == 0 && dev && (idev = in6_dev_get(dev)) != NULL) { - if (ctl->ctl_name == NET_NEIGH_REACHABLE_TIME) + if (ctl->ctl_name == NET_NEIGH_REACHABLE_TIME || + ctl->ctl_name == NET_NEIGH_REACHABLE_TIME_MS) idev->nd_parms->reachable_time = neigh_rand_reach_time(idev->nd_parms->base_reachable_time); idev->tstamp = jiffies; inet6_ifinfo_notify(RTM_NEWLINK, idev); @@ -1579,13 +1585,20 @@ oldval, oldlenp, newval, newlen, context); break; + case NET_NEIGH_RETRANS_TIME_MS: + case NET_NEIGH_REACHABLE_TIME_MS: + ret = sysctl_ms_jiffies(ctl, name, nlen, + oldval, oldlenp, newval, newlen, + context); + break; default: ret = 0; } if (newval && newlen && ret > 0 && dev && (idev = in6_dev_get(dev)) != NULL) { - if (ctl->ctl_name == NET_NEIGH_REACHABLE_TIME) + if (ctl->ctl_name == NET_NEIGH_REACHABLE_TIME || + ctl->ctl_name == NET_NEIGH_REACHABLE_TIME_MS) idev->nd_parms->reachable_time = neigh_rand_reach_time(idev->nd_parms->base_reachable_time); idev->tstamp = jiffies; inet6_ifinfo_notify(RTM_NEWLINK, idev); ChangeSet@1.2089, 2005-03-03 14:37:40+09:00, yoshfuji@linux-ipv6.org [IPV6] NDISC: Deprecate base_reachable_time and retrans_timer. Signed-off-by: Hideaki YOSHIFUJI diff -Nru a/Documentation/filesystems/proc.txt b/Documentation/filesystems/proc.txt --- a/Documentation/filesystems/proc.txt 2005-03-03 16:33:26 +09:00 +++ b/Documentation/filesystems/proc.txt 2005-03-03 16:33:26 +09:00 @@ -1760,7 +1760,7 @@ A base value used for computing the random reachable time value as specified in RFC2461. -Expression of base_reachable_time is in seconds. +Expression of base_reachable_time, which is deprecated, is in seconds. Expression of base_reachable_time_ms is in milliseconds. retrans_time, retrans_time_ms @@ -1770,8 +1770,8 @@ Used for address resolution and to determine if a neighbor is unreachable. -Expression of retrans_time is in 1/100 seconds (for IPv4) or in jiffies -(for IPv6). +Expression of retrans_time, which is deprecated, is in 1/100 seconds (for +IPv4) or in jiffies (for IPv6). Expression of retrans_time_ms is in milliseconds. unres_qlen diff -Nru a/net/ipv6/ndisc.c b/net/ipv6/ndisc.c --- a/net/ipv6/ndisc.c 2005-03-03 16:33:26 +09:00 +++ b/net/ipv6/ndisc.c 2005-03-03 16:33:26 +09:00 @@ -1536,12 +1536,35 @@ }; #ifdef CONFIG_SYSCTL +static void ndisc_warn_deprecated_sysctl(struct ctl_table *ctl, + const char *func, const char *dev_name) +{ + static char warncomm[TASK_COMM_LEN]; + static int warned; + if (strcmp(warncomm, current->comm) && warned < 5) { + strcpy(warncomm, current->comm); + printk(KERN_WARNING + "process `%s' is using deprecated sysctl (%s) " + "net.ipv6.neigh.%s.%s; " + "Use net.ipv6.neigh.%s.%s_ms " + "instead.\n", + warncomm, func, + dev_name, ctl->procname, + dev_name, ctl->procname); + warned++; + } +} + int ndisc_ifinfo_sysctl_change(struct ctl_table *ctl, int write, struct file * filp, void __user *buffer, size_t *lenp, loff_t *ppos) { struct net_device *dev = ctl->extra1; struct inet6_dev *idev; int ret; - + + if (ctl->ctl_name == NET_NEIGH_RETRANS_TIME || + ctl->ctl_name == NET_NEIGH_REACHABLE_TIME) + ndisc_warn_deprecated_sysctl(ctl, "syscall", dev ? dev->name : "default"); + switch (ctl->ctl_name) { case NET_NEIGH_RETRANS_TIME: ret = proc_dointvec(ctl, write, filp, buffer, lenp, ppos); @@ -1578,6 +1601,10 @@ struct net_device *dev = ctl->extra1; struct inet6_dev *idev; int ret; + + if (ctl->ctl_name == NET_NEIGH_RETRANS_TIME || + ctl->ctl_name == NET_NEIGH_REACHABLE_TIME) + ndisc_warn_deprecated_sysctl(ctl, "procfs", dev ? dev->name : "default"); switch (ctl->ctl_name) { case NET_NEIGH_REACHABLE_TIME: ChangeSet@1.2090, 2005-03-03 14:37:53+09:00, yoshfuji@linux-ipv6.org [IPV6] ROUTE: Keep cache entries for a while. GC always removed most cache entries and a fresh redirect entry might be removed immideately. Signed-off-by: Hideaki YOSHIFUJI diff -Nru a/net/ipv6/ip6_fib.c b/net/ipv6/ip6_fib.c --- a/net/ipv6/ip6_fib.c 2005-03-03 16:33:31 +09:00 +++ b/net/ipv6/ip6_fib.c 2005-03-03 16:33:31 +09:00 @@ -1211,7 +1211,7 @@ { if (dummy != ~0UL) { spin_lock_bh(&fib6_gc_lock); - gc_args.timeout = (int)dummy; + gc_args.timeout = dummy ? (int)dummy : ip6_rt_gc_interval; } else { local_bh_disable(); if (!spin_trylock(&fib6_gc_lock)) { diff -Nru a/net/ipv6/ndisc.c b/net/ipv6/ndisc.c --- a/net/ipv6/ndisc.c 2005-03-03 16:33:31 +09:00 +++ b/net/ipv6/ndisc.c 2005-03-03 16:33:31 +09:00 @@ -1518,11 +1518,11 @@ switch (event) { case NETDEV_CHANGEADDR: neigh_changeaddr(&nd_tbl, dev); - fib6_run_gc(0); + fib6_run_gc(~0UL); break; case NETDEV_DOWN: neigh_ifdown(&nd_tbl, dev); - fib6_run_gc(0); + fib6_run_gc(~0UL); break; default: break; diff -Nru a/net/ipv6/route.c b/net/ipv6/route.c --- a/net/ipv6/route.c 2005-03-03 16:33:31 +09:00 +++ b/net/ipv6/route.c 2005-03-03 16:33:31 +09:00 @@ -1993,9 +1993,7 @@ { if (write) { proc_dointvec(ctl, write, filp, buffer, lenp, ppos); - if (flush_delay < 0) - flush_delay = 0; - fib6_run_gc((unsigned long)flush_delay); + fib6_run_gc(flush_delay <= 0 ? ~0UL : (unsigned long)flush_delay); return 0; } else return -EINVAL; ChangeSet@1.2091, 2005-03-03 14:38:06+09:00, yoshfuji@linux-ipv6.org [IPV6] NDISC: Ensure to send redirects. rt6_lookup() is inappropriate because it cannot lookup route to the source node of the original packet if we don't have specific route to it. Signed-off-by: Hideaki YOSHIFUJI diff -Nru a/net/ipv6/ndisc.c b/net/ipv6/ndisc.c --- a/net/ipv6/ndisc.c 2005-03-03 16:33:35 +09:00 +++ b/net/ipv6/ndisc.c 2005-03-03 16:33:35 +09:00 @@ -1344,10 +1344,9 @@ ndisc_flow_init(&fl, NDISC_REDIRECT, &saddr_buf, &skb->nh.ipv6h->saddr); - rt = rt6_lookup(&skb->nh.ipv6h->saddr, NULL, dev->ifindex, 1); - if (rt == NULL) + dst = ip6_route_output(NULL, &fl); + if (dst == NULL) return; - dst = &rt->u.dst; err = xfrm_lookup(&dst, &fl, NULL, 0); if (err) { ChangeSet@1.2092, 2005-03-03 14:38:18+09:00, yoshfuji@linux-ipv6.org [IPV6] NDISC: Ensure to send redirects even if we don't know target's lladdr. diff -Nru a/net/ipv6/ndisc.c b/net/ipv6/ndisc.c --- a/net/ipv6/ndisc.c 2005-03-03 16:33:40 +09:00 +++ b/net/ipv6/ndisc.c 2005-03-03 16:33:40 +09:00 @@ -1332,6 +1332,7 @@ int rd_len; int err; int hlen; + u8 ha_buf[MAX_ADDR_LEN], *ha = NULL; dev = skb->dev; @@ -1368,16 +1369,14 @@ } if (dev->addr_len) { - if (neigh->nud_state&NUD_VALID) { - len += ndisc_opt_addr_space(dev); - } else { - /* If nexthop is not valid, do not redirect! - We will make it later, when will be sure, - that it is alive. - */ - dst_release(dst); - return; - } + read_lock_bh(&neigh->lock); + if (neigh->nud_state & NUD_VALID) { + memcpy(ha_buf, neigh->ha, dev->addr_len); + read_unlock_bh(&neigh->lock); + ha = ha_buf; + len += ndisc_opt_addr_space(dev); + } else + read_unlock_bh(&neigh->lock); } rd_len = min_t(unsigned int, @@ -1422,8 +1421,8 @@ * include target_address option */ - if (dev->addr_len) - opt = ndisc_fill_addr_option(opt, ND_OPT_TARGET_LL_ADDR, neigh->ha, + if (ha) + opt = ndisc_fill_addr_option(opt, ND_OPT_TARGET_LL_ADDR, ha, dev->addr_len, dev->type); /* ChangeSet@1.2093, 2005-03-03 14:38:31+09:00, yoshfuji@linux-ipv6.org [IPV6] Always add a fragment header after receiving TOO BIG w/ pmtu < 1280. According to RFC2460, PMTU is set to the IPv6 Minimum Link MTU (1280) and a fragment header should always be included after a node receiving Too Big message reporting PMTU is less than the IPv6 Minimum Link MTU (1280). Signed-off-by: Hideaki YOSHIFUJI diff -Nru a/include/linux/ip.h b/include/linux/ip.h --- a/include/linux/ip.h 2005-03-03 16:33:45 +09:00 +++ b/include/linux/ip.h 2005-03-03 16:33:45 +09:00 @@ -152,6 +152,7 @@ }; #define IPCORK_OPT 1 /* ip-options has been held in ipcork.opt */ +#define IPCORK_ALLFRAG 2 /* always fragment (for ipv6 for now) */ static inline struct inet_sock *inet_sk(const struct sock *sk) { diff -Nru a/include/linux/rtnetlink.h b/include/linux/rtnetlink.h --- a/include/linux/rtnetlink.h 2005-03-03 16:33:45 +09:00 +++ b/include/linux/rtnetlink.h 2005-03-03 16:33:45 +09:00 @@ -346,6 +346,7 @@ #define RTAX_FEATURE_ECN 0x00000001 #define RTAX_FEATURE_SACK 0x00000002 #define RTAX_FEATURE_TIMESTAMP 0x00000004 +#define RTAX_FEATURE_ALLFRAG 0x00000008 struct rta_session { diff -Nru a/include/net/dst.h b/include/net/dst.h --- a/include/net/dst.h 2005-03-03 16:33:45 +09:00 +++ b/include/net/dst.h 2005-03-03 16:33:45 +09:00 @@ -124,6 +124,15 @@ return mtu; } +static inline u32 +dst_allfrag(const struct dst_entry *dst) +{ + int ret = dst_path_metric(dst, RTAX_FEATURES) & RTAX_FEATURE_ALLFRAG; + /* Yes, _exactly_. This is paranoia. */ + barrier(); + return ret; +} + static inline int dst_metric_locked(struct dst_entry *dst, int metric) { diff -Nru a/net/ipv6/ip6_output.c b/net/ipv6/ip6_output.c --- a/net/ipv6/ip6_output.c 2005-03-03 16:33:45 +09:00 +++ b/net/ipv6/ip6_output.c 2005-03-03 16:33:45 +09:00 @@ -147,7 +147,7 @@ int ip6_output(struct sk_buff *skb) { - if (skb->len > dst_pmtu(skb->dst)) + if (skb->len > dst_pmtu(skb->dst) || dst_allfrag(skb->dst)) return ip6_fragment(skb, ip6_output2); else return ip6_output2(skb); @@ -848,6 +848,8 @@ inet->cork.fl = *fl; np->cork.hop_limit = hlimit; inet->cork.fragsize = mtu = dst_pmtu(&rt->u.dst); + if (dst_allfrag(&rt->u.dst)) + inet->cork.flags |= IPCORK_ALLFRAG; inet->cork.length = 0; sk->sk_sndmsg_page = NULL; sk->sk_sndmsg_off = 0; @@ -899,7 +901,7 @@ while (length > 0) { /* Check if the remaining data fits into current packet. */ - copy = mtu - skb->len; + copy = (inet->cork.length <= mtu && !(inet->cork.flags & IPCORK_ALLFRAG) ? mtu : maxfraglen) - skb->len; if (copy < length) copy = maxfraglen - skb->len; @@ -924,7 +926,7 @@ * we know we need more fragment(s). */ datalen = length + fraggap; - if (datalen > mtu - fragheaderlen) + if (datalen > (inet->cork.length <= mtu && !(inet->cork.flags & IPCORK_ALLFRAG) ? mtu : maxfraglen) - fragheaderlen) datalen = maxfraglen - fragheaderlen; fraglen = datalen + fragheaderlen; @@ -1158,6 +1160,7 @@ if (np->cork.rt) { dst_release(&np->cork.rt->u.dst); np->cork.rt = NULL; + inet->cork.flags &= ~IPCORK_ALLFRAG; } memset(&inet->cork.fl, 0, sizeof(inet->cork.fl)); return err; @@ -1185,6 +1188,7 @@ if (np->cork.rt) { dst_release(&np->cork.rt->u.dst); np->cork.rt = NULL; + inet->cork.flags &= ~IPCORK_ALLFRAG; } memset(&inet->cork.fl, 0, sizeof(inet->cork.fl)); } diff -Nru a/net/ipv6/route.c b/net/ipv6/route.c --- a/net/ipv6/route.c 2005-03-03 16:33:45 +09:00 +++ b/net/ipv6/route.c 2005-03-03 16:33:45 +09:00 @@ -628,8 +628,10 @@ if (mtu < dst_pmtu(dst) && rt6->rt6i_dst.plen == 128) { rt6->rt6i_flags |= RTF_MODIFIED; - if (mtu < IPV6_MIN_MTU) + if (mtu < IPV6_MIN_MTU) { mtu = IPV6_MIN_MTU; + dst->metrics[RTAX_FEATURES-1] |= RTAX_FEATURE_ALLFRAG; + } dst->metrics[RTAX_MTU-1] = mtu; } } @@ -1164,26 +1166,26 @@ struct net_device *dev, u32 pmtu) { struct rt6_info *rt, *nrt; - - if (pmtu < IPV6_MIN_MTU) { - if (net_ratelimit()) - printk(KERN_DEBUG "rt6_pmtu_discovery: invalid MTU value %d\n", - pmtu); - /* According to RFC1981, the PMTU is set to the IPv6 minimum - link MTU if the node receives a Packet Too Big message - reporting next-hop MTU that is less than the IPv6 minimum MTU. - */ - pmtu = IPV6_MIN_MTU; - } + int allfrag = 0; rt = rt6_lookup(daddr, saddr, dev->ifindex, 0); - if (rt == NULL) return; if (pmtu >= dst_pmtu(&rt->u.dst)) goto out; + if (pmtu < IPV6_MIN_MTU) { + /* + * According to RFC2460, PMTU is set to the IPv6 Minimum Link + * MTU (1280) and a fragment header should always be included + * after a node receiving Too Big message reporting PMTU is + * less than the IPv6 Minimum Link MTU. + */ + pmtu = IPV6_MIN_MTU; + allfrag = 1; + } + /* New mtu received -> path was valid. They are sent only in response to data packets, so that this nexthop apparently is reachable. --ANK @@ -1197,6 +1199,8 @@ */ if (rt->rt6i_flags & RTF_CACHE) { rt->u.dst.metrics[RTAX_MTU-1] = pmtu; + if (allfrag) + rt->u.dst.metrics[RTAX_FEATURES-1] |= RTAX_FEATURE_ALLFRAG; dst_set_expires(&rt->u.dst, ip6_rt_mtu_expires); rt->rt6i_flags |= RTF_MODIFIED|RTF_EXPIRES; goto out; @@ -1211,6 +1215,8 @@ nrt = rt6_cow(rt, daddr, saddr); if (!nrt->u.dst.error) { nrt->u.dst.metrics[RTAX_MTU-1] = pmtu; + if (allfrag) + nrt->u.dst.metrics[RTAX_FEATURES-1] |= RTAX_FEATURE_ALLFRAG; /* According to RFC 1981, detecting PMTU increase shouldn't be happened within 5 mins, the recommended timer is 10 mins. Here this route expiration time is set to ip6_rt_mtu_expires @@ -1232,6 +1238,8 @@ dst_set_expires(&nrt->u.dst, ip6_rt_mtu_expires); nrt->rt6i_flags |= RTF_DYNAMIC|RTF_CACHE|RTF_EXPIRES; nrt->u.dst.metrics[RTAX_MTU-1] = pmtu; + if (allfrag) + nrt->u.dst.metrics[RTAX_FEATURES-1] |= RTAX_FEATURE_ALLFRAG; ip6_ins_rt(nrt, NULL, NULL); } ChangeSet@1.2094, 2005-03-03 14:38:44+09:00, yoshfuji@linux-ipv6.org [IPV6] Ensure to use interface hoplimit by default. Signed-off-by: Hideaki YOSHIFUJI diff -Nru a/include/net/addrconf.h b/include/net/addrconf.h --- a/include/net/addrconf.h 2005-03-03 16:33:49 +09:00 +++ b/include/net/addrconf.h 2005-03-03 16:33:49 +09:00 @@ -102,6 +102,8 @@ extern void addrconf_prefix_rcv(struct net_device *dev, u8 *opt, int len); +extern int ipv6_get_hoplimit(struct net_device *dev); + /* * anycast prototypes (anycast.c) */ diff -Nru a/net/ipv6/icmp.c b/net/ipv6/icmp.c --- a/net/ipv6/icmp.c 2005-03-03 16:33:49 +09:00 +++ b/net/ipv6/icmp.c 2005-03-03 16:33:49 +09:00 @@ -381,6 +381,8 @@ hlimit = np->hop_limit; if (hlimit < 0) hlimit = dst_metric(dst, RTAX_HOPLIMIT); + if (hlimit < 0) + hlimit = ipv6_get_hoplimit(dst->dev); msg.skb = skb; msg.offset = skb->nh.raw - skb->data; @@ -467,6 +469,8 @@ hlimit = np->hop_limit; if (hlimit < 0) hlimit = dst_metric(dst, RTAX_HOPLIMIT); + if (hlimit < 0) + hlimit = ipv6_get_hoplimit(dst->dev); idev = in6_dev_get(skb->dev); diff -Nru a/net/ipv6/ip6_output.c b/net/ipv6/ip6_output.c --- a/net/ipv6/ip6_output.c 2005-03-03 16:33:49 +09:00 +++ b/net/ipv6/ip6_output.c 2005-03-03 16:33:49 +09:00 @@ -253,6 +253,8 @@ hlimit = np->hop_limit; if (hlimit < 0) hlimit = dst_metric(dst, RTAX_HOPLIMIT); + if (hlimit < 0) + hlimit = ipv6_get_hoplimit(dst->dev); hdr->payload_len = htons(seg_len); hdr->nexthdr = proto; diff -Nru a/net/ipv6/ndisc.c b/net/ipv6/ndisc.c --- a/net/ipv6/ndisc.c 2005-03-03 16:33:49 +09:00 +++ b/net/ipv6/ndisc.c 2005-03-03 16:33:49 +09:00 @@ -1128,8 +1128,11 @@ if (rt) rt->rt6i_expires = jiffies + (HZ * lifetime); - if (ra_msg->icmph.icmp6_hop_limit) + if (ra_msg->icmph.icmp6_hop_limit) { in6_dev->cnf.hop_limit = ra_msg->icmph.icmp6_hop_limit; + if (rt) + rt->u.dst.metrics[RTAX_HOPLIMIT-1] = ra_msg->icmph.icmp6_hop_limit; + } /* * Update Reachable Time and Retrans Timer diff -Nru a/net/ipv6/raw.c b/net/ipv6/raw.c --- a/net/ipv6/raw.c 2005-03-03 16:33:49 +09:00 +++ b/net/ipv6/raw.c 2005-03-03 16:33:49 +09:00 @@ -756,6 +756,8 @@ hlimit = np->hop_limit; if (hlimit < 0) hlimit = dst_metric(dst, RTAX_HOPLIMIT); + if (hlimit < 0) + hlimit = ipv6_get_hoplimit(dst->dev); } if (msg->msg_flags&MSG_CONFIRM) diff -Nru a/net/ipv6/route.c b/net/ipv6/route.c --- a/net/ipv6/route.c 2005-03-03 16:33:49 +09:00 +++ b/net/ipv6/route.c 2005-03-03 16:33:49 +09:00 @@ -771,7 +771,7 @@ return mtu; } -static int ipv6_get_hoplimit(struct net_device *dev) +int ipv6_get_hoplimit(struct net_device *dev) { int hoplimit = ipv6_devconf.hop_limit; struct inet6_dev *idev; @@ -967,15 +967,8 @@ } } - if (rt->u.dst.metrics[RTAX_HOPLIMIT-1] == 0) { - if (ipv6_addr_is_multicast(&rt->rt6i_dst.addr)) - rt->u.dst.metrics[RTAX_HOPLIMIT-1] = - IPV6_DEFAULT_MCASTHOPS; - else - rt->u.dst.metrics[RTAX_HOPLIMIT-1] = - ipv6_get_hoplimit(dev); - } - + if (rt->u.dst.metrics[RTAX_HOPLIMIT-1] == 0) + rt->u.dst.metrics[RTAX_HOPLIMIT-1] = -1; if (!rt->u.dst.metrics[RTAX_MTU-1]) rt->u.dst.metrics[RTAX_MTU-1] = ipv6_get_mtu(dev); if (!rt->u.dst.metrics[RTAX_ADVMSS-1]) @@ -1414,7 +1407,7 @@ rt->rt6i_idev = idev; rt->u.dst.metrics[RTAX_MTU-1] = ipv6_get_mtu(rt->rt6i_dev); rt->u.dst.metrics[RTAX_ADVMSS-1] = ipv6_advmss(dst_pmtu(&rt->u.dst)); - rt->u.dst.metrics[RTAX_HOPLIMIT-1] = ipv6_get_hoplimit(rt->rt6i_dev); + rt->u.dst.metrics[RTAX_HOPLIMIT-1] = -1; rt->u.dst.obsolete = -1; rt->rt6i_flags = RTF_UP | RTF_NONEXTHOP; diff -Nru a/net/ipv6/udp.c b/net/ipv6/udp.c --- a/net/ipv6/udp.c 2005-03-03 16:33:49 +09:00 +++ b/net/ipv6/udp.c 2005-03-03 16:33:49 +09:00 @@ -811,6 +811,8 @@ hlimit = np->hop_limit; if (hlimit < 0) hlimit = dst_metric(dst, RTAX_HOPLIMIT); + if (hlimit < 0) + hlimit = ipv6_get_hoplimit(dst->dev); } if (msg->msg_flags&MSG_CONFIRM) ChangeSet@1.2095, 2005-03-03 14:38:57+09:00, yoshfuji@linux-ipv6.org [IPV6] Unify common functions to compare ipv6 prefixes. Signed-off-by: Hideaki YOSHIFUJI diff -Nru a/include/net/ipv6.h b/include/net/ipv6.h --- a/include/net/ipv6.h 2005-03-03 16:33:54 +09:00 +++ b/include/net/ipv6.h 2005-03-03 16:33:54 +09:00 @@ -305,6 +305,32 @@ a1->s6_addr32[3] == a2->s6_addr32[3]); } +static inline int __ipv6_prefix_equal(const u32 *a1, const u32 *a2, + unsigned int prefixlen) +{ + unsigned pdw, pbi; + + /* check complete u32 in prefix */ + pdw = prefixlen >> 5; + if (pdw && memcmp(a1, a2, pdw << 2)) + return 0; + + /* check incomplete u32 in prefix */ + pbi = prefixlen & 0x1f; + if (pbi && ((a1[pdw] ^ a2[pdw]) & htonl((0xffffffff) << (32 - pbi)))) + return 0; + + return 1; +} + +static inline int ipv6_prefix_equal(const struct in6_addr *a1, + const struct in6_addr *a2, + unsigned int prefixlen) +{ + return __ipv6_prefix_equal(a1->s6_addr32, a2->s6_addr32, + prefixlen); +} + static inline int ipv6_addr_any(const struct in6_addr *a) { return ((a->s6_addr32[0] | a->s6_addr32[1] | diff -Nru a/net/ipv6/anycast.c b/net/ipv6/anycast.c --- a/net/ipv6/anycast.c 2005-03-03 16:33:54 +09:00 +++ b/net/ipv6/anycast.c 2005-03-03 16:33:54 +09:00 @@ -48,32 +48,6 @@ /* Big ac list lock for all the sockets */ static DEFINE_RWLOCK(ipv6_sk_ac_lock); -/* XXX ip6_addr_match() and ip6_onlink() really belong in net/core.c */ - -static int -ip6_addr_match(struct in6_addr *addr1, struct in6_addr *addr2, int prefix) -{ - __u32 mask; - int i; - - if (prefix > 128 || prefix < 0) - return 0; - if (prefix == 0) - return 1; - for (i=0; i<4; ++i) { - if (prefix >= 32) - mask = ~0; - else - mask = htonl(~0 << (32 - prefix)); - if ((addr1->s6_addr32[i] ^ addr2->s6_addr32[i]) & mask) - return 0; - prefix -= 32; - if (prefix <= 0) - break; - } - return 1; -} - static int ip6_onlink(struct in6_addr *addr, struct net_device *dev) { @@ -87,8 +61,8 @@ if (idev) { read_lock_bh(&idev->lock); for (ifa=idev->addr_list; ifa; ifa=ifa->if_next) { - onlink = ip6_addr_match(addr, &ifa->addr, - ifa->prefix_len); + onlink = ipv6_prefix_equal(addr, &ifa->addr, + ifa->prefix_len); if (onlink) break; } diff -Nru a/net/ipv6/ip6_fib.c b/net/ipv6/ip6_fib.c --- a/net/ipv6/ip6_fib.c 2005-03-03 16:33:54 +09:00 +++ b/net/ipv6/ip6_fib.c 2005-03-03 16:33:54 +09:00 @@ -117,36 +117,6 @@ */ /* - * compare "prefix length" bits of an address - */ - -static __inline__ int addr_match(void *token1, void *token2, int prefixlen) -{ - __u32 *a1 = token1; - __u32 *a2 = token2; - int pdw; - int pbi; - - pdw = prefixlen >> 5; /* num of whole __u32 in prefix */ - pbi = prefixlen & 0x1f; /* num of bits in incomplete u32 in prefix */ - - if (pdw) - if (memcmp(a1, a2, pdw << 2)) - return 0; - - if (pbi) { - __u32 mask; - - mask = htonl((0xffffffff) << (32 - pbi)); - - if ((a1[pdw] ^ a2[pdw]) & mask) - return 0; - } - - return 1; -} - -/* * test bit */ @@ -261,7 +231,7 @@ * Prefix match */ if (plen < fn->fn_bit || - !addr_match(&key->addr, addr, fn->fn_bit)) + !ipv6_prefix_equal(&key->addr, addr, fn->fn_bit)) goto insert_above; /* @@ -667,7 +637,7 @@ key = (struct rt6key *) ((u8 *) fn->leaf + args->offset); - if (addr_match(&key->addr, args->addr, key->plen)) + if (ipv6_prefix_equal(&key->addr, args->addr, key->plen)) return fn; } @@ -718,7 +688,7 @@ * Prefix match */ if (plen < fn->fn_bit || - !addr_match(&key->addr, addr, fn->fn_bit)) + !ipv6_prefix_equal(&key->addr, addr, fn->fn_bit)) return NULL; if (plen == fn->fn_bit) ChangeSet@1.2096, 2005-03-03 14:39:10+09:00, yoshfuji@linux-ipv6.org [IPV6] ADDRCONF: Update prefix route on address deletion. We did not delete prefix route on deletion of corresponding permanent address while we add prefix route on addition of permanent address. This was confusing. With this changeset, we purge prefix route or convert it to dynamic one, if appropriate. Signed-off-by: Hideaki YOSHIFUJI diff -Nru a/net/ipv6/addrconf.c b/net/ipv6/addrconf.c --- a/net/ipv6/addrconf.c 2005-03-03 16:33:59 +09:00 +++ b/net/ipv6/addrconf.c 2005-03-03 16:33:59 +09:00 @@ -591,6 +591,8 @@ struct inet6_ifaddr *ifa, **ifap; struct inet6_dev *idev = ifp->idev; int hash; + int deleted = 0, onlink = 0; + unsigned long expires = jiffies; hash = ipv6_addr_hash(&ifp->addr); @@ -633,7 +635,31 @@ *ifap = ifa->if_next; __in6_ifa_put(ifp); ifa->if_next = NULL; - break; + if (!(ifp->flags & IFA_F_PERMANENT) || onlink > 0) + break; + deleted = 1; + } else if (ifp->flags & IFA_F_PERMANENT) { + if (ipv6_prefix_equal(&ifa->addr, &ifp->addr, + ifp->prefix_len)) { + if (ifa->flags & IFA_F_PERMANENT) { + onlink = 1; + if (deleted) + break; + } else { + unsigned long lifetime; + + if (!onlink) + onlink = -1; + + spin_lock(&ifa->lock); + lifetime = min_t(unsigned long, + ifa->valid_lft, 0x7fffffffUL/HZ); + if (time_before(expires, + ifa->tstamp + lifetime * HZ)) + expires = ifa->tstamp + lifetime * HZ; + spin_unlock(&ifa->lock); + } + } } } write_unlock_bh(&idev->lock); @@ -643,6 +669,40 @@ notifier_call_chain(&inet6addr_chain,NETDEV_DOWN,ifp); addrconf_del_timer(ifp); + + /* + * Purge or update corresponding prefix + * + * 1) we don't purge prefix here if address was not permanent. + * prefix is managed by its own lifetime. + * 2) if there're no addresses, delete prefix. + * 3) if there're still other permanent address(es), + * corresponding prefix is still permanent. + * 4) otherwise, update prefix lifetime to the + * longest valid lifetime among the corresponding + * addresses on the device. + * Note: subsequent RA will update lifetime. + * + * --yoshfuji + */ + if ((ifp->flags & IFA_F_PERMANENT) && onlink < 1) { + struct in6_addr prefix; + struct rt6_info *rt; + + ipv6_addr_prefix(&prefix, &ifp->addr, ifp->prefix_len); + rt = rt6_lookup(&prefix, NULL, ifp->idev->dev->ifindex, 1); + + if (rt && ((rt->rt6i_flags & (RTF_GATEWAY | RTF_DEFAULT)) == 0)) { + if (onlink == 0) { + ip6_del_rt(rt, NULL, NULL); + rt = NULL; + } else if (!(rt->rt6i_flags & RTF_EXPIRES)) { + rt->rt6i_expires = expires; + rt->rt6i_flags |= RTF_EXPIRES; + } + } + dst_release(&rt->u.dst); + } in6_ifa_put(ifp); } ChangeSet@1.2097, 2005-03-03 14:39:22+09:00, yoshfuji@linux-ipv6.org [IPV6] Mature enough, no longer EXPERIMENTAL. Now we can pass IPv6 Ready Logo Phase 1 and Phase 2 Self Tests. Signed-off-by: Hideaki YOSHIFUJI diff -Nru a/net/Kconfig b/net/Kconfig --- a/net/Kconfig 2005-03-03 16:34:03 +09:00 +++ b/net/Kconfig 2005-03-03 16:34:03 +09:00 @@ -107,27 +107,22 @@ # IPv6 as module will cause a CRASH if you try to unload it config IPV6 - tristate "The IPv6 protocol (EXPERIMENTAL)" - depends on INET && EXPERIMENTAL + tristate "The IPv6 protocol" + depends on INET select CRYPTO if IPV6_PRIVACY select CRYPTO_MD5 if IPV6_PRIVACY ---help--- - This is experimental support for the IP version 6 (formerly called - IPng "IP next generation"). You will still be able to do - regular IPv4 networking as well. + This is complemental support for the IP version 6. + You will still be able to do traditional IPv4 networking as well. - Features of this new protocol include: expanded address space, - authentication and privacy, and seamless interoperability with the - current version of IP (IP version 4). For general information about - IPv6, see ; - for specific information about IPv6 under Linux read the HOWTO at - and the file net/ipv6/README - in the kernel source. + For general information about IPv6, see + . + For Linux IPv6 development information, see . + For specific information about IPv6 under Linux, read the HOWTO at + . To compile this protocol support as a module, choose M here: the module will be called ipv6. - - It is safe to say N here for now. source "net/ipv6/Kconfig" diff -Nru a/net/ipv6/README b/net/ipv6/README --- a/net/ipv6/README 2005-03-03 16:34:03 +09:00 +++ /dev/null Wed Dec 31 16:00:00 196900 @@ -1,8 +0,0 @@ -To join in the work on Linux IPv6 send mail to: - - majordomo@oss.sgi.com - -and in the body of the message include: - -subscribe netdev - diff -Nru a/net/ipv6/netfilter/Kconfig b/net/ipv6/netfilter/Kconfig --- a/net/ipv6/netfilter/Kconfig 2005-03-03 16:34:03 +09:00 +++ b/net/ipv6/netfilter/Kconfig 2005-03-03 16:34:03 +09:00 @@ -2,8 +2,8 @@ # IP netfilter configuration # -menu "IPv6: Netfilter Configuration" - depends on INET && IPV6 && NETFILTER +menu "IPv6: Netfilter Configuration (EXPERIMENTAL)" + depends on INET && IPV6 && NETFILTER && EXPERIMENTAL #tristate 'Connection tracking (required for masq/NAT)' CONFIG_IP6_NF_CONNTRACK #if [ "$CONFIG_IP6_NF_CONNTRACK" != "n" ]; then ChangeSet@1.2098, 2005-03-03 14:39:35+09:00, yoshfuji@linux-ipv6.org [NET] Don't use magic number for sysctl table definition. Signed-off-by: Hideaki YOSHIFUJI diff -Nru a/include/linux/sysctl.h b/include/linux/sysctl.h --- a/include/linux/sysctl.h 2005-03-03 16:34:08 +09:00 +++ b/include/linux/sysctl.h 2005-03-03 16:34:08 +09:00 @@ -398,6 +398,7 @@ NET_IPV4_CONF_FORCE_IGMP_VERSION=17, NET_IPV4_CONF_ARP_ANNOUNCE=18, NET_IPV4_CONF_ARP_IGNORE=19, + __NET_IPV4_CONF_MAX }; /* /proc/sys/net/ipv4/netfilter */ @@ -476,7 +477,8 @@ NET_IPV6_REGEN_MAX_RETRY=14, NET_IPV6_MAX_DESYNC_FACTOR=15, NET_IPV6_MAX_ADDRESSES=16, - NET_IPV6_FORCE_MLD_VERSION=17 + NET_IPV6_FORCE_MLD_VERSION=17, + __NET_IPV6_MAX }; /* /proc/sys/net/ipv6/icmp */ diff -Nru a/net/ipv4/devinet.c b/net/ipv4/devinet.c --- a/net/ipv4/devinet.c 2005-03-03 16:34:08 +09:00 +++ b/net/ipv4/devinet.c 2005-03-03 16:34:08 +09:00 @@ -1212,7 +1212,7 @@ static struct devinet_sysctl_table { struct ctl_table_header *sysctl_header; - ctl_table devinet_vars[20]; + ctl_table devinet_vars[__NET_IPV4_CONF_MAX]; ctl_table devinet_dev[2]; ctl_table devinet_conf_dir[2]; ctl_table devinet_proto_dir[2]; diff -Nru a/net/ipv6/addrconf.c b/net/ipv6/addrconf.c --- a/net/ipv6/addrconf.c 2005-03-03 16:34:08 +09:00 +++ b/net/ipv6/addrconf.c 2005-03-03 16:34:08 +09:00 @@ -3212,7 +3212,7 @@ static struct addrconf_sysctl_table { struct ctl_table_header *sysctl_header; - ctl_table addrconf_vars[18]; + ctl_table addrconf_vars[__NET_IPV6_MAX]; ctl_table addrconf_dev[2]; ctl_table addrconf_conf_dir[2]; ctl_table addrconf_proto_dir[2]; -- Hideaki YOSHIFUJI @ USAGI Project GPG FP: 9022 65EB 1ECF 3AD1 0BDF 80D8 4807 F894 E062 0EEA From jheffner@psc.edu Thu Mar 3 19:11:05 2005 Received: with ECARTIS (v1.0.0; list netdev); Thu, 03 Mar 2005 19:11:10 -0800 (PST) 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 j243B4J6019943 for ; Thu, 3 Mar 2005 19:11:05 -0800 Received: from tesla.psc.edu (tesla.psc.edu [128.182.61.233]) by mailer1.psc.edu (8.13.3/8.13.3) with ESMTP id j243AuTG029181 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 3 Mar 2005 22:10:56 -0500 (EST) Received: from tesla.psc.edu (localhost.psc.edu [127.0.0.1]) by tesla.psc.edu (8.12.11/8.12.10) with ESMTP id j243AuBV028540; Thu, 3 Mar 2005 22:10:56 -0500 Received: from localhost (jheffner@localhost) by tesla.psc.edu (8.12.11/8.12.11/Submit) with ESMTP id j243AtFu028537; Thu, 3 Mar 2005 22:10:56 -0500 X-Authentication-Warning: tesla.psc.edu: jheffner owned process doing -bs Date: Thu, 3 Mar 2005 22:10:55 -0500 (EST) From: John Heffner To: Lennert Buytenhek cc: Stephen Hemminger , baruch@ev-en.org, netdev@oss.sgi.com Subject: Re: netif_rx packet dumping In-Reply-To: <20050304014227.GB28874@xi.wantstofly.org> Message-ID: References: <20050303125556.6850cfe5.davem@davemloft.net> <1109884688.1090.282.camel@jzny.localdomain> <20050303132143.7eef517c@dxpl.pdx.osdl.net> <1109885065.1098.285.camel@jzny.localdomain> <20050303133237.5d64578f.davem@davemloft.net> <20050303135416.0d6e7708@dxpl.pdx.osdl.net> <1109888811.1092.352.camel@jzny.localdomain> <20050303151606.3587394f@dxpl.pdx.osdl.net> <20050304014227.GB28874@xi.wantstofly.org> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Scanned-By: MIMEDefang 2.49 on 128.182.58.100 X-Virus-Scanned: ClamAV 0.83/743/Wed Mar 2 16:02:05 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 2368 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: jheffner@psc.edu Precedence: bulk X-list: netdev Content-Length: 1471 Lines: 31 On Fri, 4 Mar 2005, Lennert Buytenhek wrote: > On Thu, Mar 03, 2005 at 06:48:50PM -0500, John Heffner wrote: > > > All these AQM schemes are trying to solve a fundamentally different > > problem. With TCP at least, the only congestion experienced at this point > > will be transient, so you do not want to send any congestion signals (drop > > packets) if you can avoid it at all. Making the limit as high as you can > > tolerate seems like the best thing to me. > > If the traffic does not terminate locally (f.e. when doing routing), > an insanely large queue has more disadvantages than advantages. > > If you're routing those exact same TCP packets on the way to their > final destination, you run the risk of not sending out any congestion > signals in the cases where you should, making your forwarding latency > skyrocket (punishing all the other flows) in the process. Yes. In "as high as you can tolerate" latency is implicit. :) This is just as true whether forwarding or not. Offhand I'd say 10 ms is a good number (bursts should be shorter than this, but it's not too much latency). The forwarding case where you actually need congestion control, as opposed to absorbing bursts, is pretty gross. If you have a router (more likely firewall) whose bottleneck is the CPU, then you're operating entirely in you input queue. Yuck. In such a situation, if you don't want user processes to get starved, you need to do throttling => bad for TCP. -John From buytenh@wantstofly.org Thu Mar 3 19:31:09 2005 Received: with ECARTIS (v1.0.0; list netdev); Thu, 03 Mar 2005 19:31:13 -0800 (PST) Received: from xi.wantstofly.org (alephnull.demon.nl [212.238.201.82]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j243V8mq021306 for ; Thu, 3 Mar 2005 19:31:09 -0800 Received: by xi.wantstofly.org (Postfix, from userid 500) id 7752A2B0EC; Fri, 4 Mar 2005 04:31:07 +0100 (MET) Date: Fri, 4 Mar 2005 04:31:07 +0100 From: Lennert Buytenhek To: John Heffner Cc: Stephen Hemminger , baruch@ev-en.org, netdev@oss.sgi.com Subject: Re: netif_rx packet dumping Message-ID: <20050304033107.GD29058@xi.wantstofly.org> References: <20050303132143.7eef517c@dxpl.pdx.osdl.net> <1109885065.1098.285.camel@jzny.localdomain> <20050303133237.5d64578f.davem@davemloft.net> <20050303135416.0d6e7708@dxpl.pdx.osdl.net> <1109888811.1092.352.camel@jzny.localdomain> <20050303151606.3587394f@dxpl.pdx.osdl.net> <20050304014227.GB28874@xi.wantstofly.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.1i X-Virus-Scanned: ClamAV 0.83/743/Wed Mar 2 16:02:05 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 2370 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: buytenh@wantstofly.org Precedence: bulk X-list: netdev Content-Length: 836 Lines: 20 On Thu, Mar 03, 2005 at 10:10:55PM -0500, John Heffner wrote: > The forwarding case where you actually need congestion control, as > opposed to absorbing bursts, is pretty gross. If you have a router > (more likely firewall) whose bottleneck is the CPU, then you're > operating entirely in you input queue. Yuck. Yes. This does happen under DoS (or just if your hardware is plain underspec'ed), and even though you can't really avoid interrupt livelock and starving userland processes when you're using a non-NAPI driver (which is what we're talking about here), you don't want to go OOM as well. Removing the backlog is a problem also for the non-forwarding case -- you don't want someone to be able to OOM your server just by flooding it with enough packets. ("Wait, I can't drop those, those might be legitimate ACKs!") --L From yoshfuji@linux-ipv6.org Thu Mar 3 19:30:59 2005 Received: with ECARTIS (v1.0.0; list netdev); Thu, 03 Mar 2005 19:31:04 -0800 (PST) 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 j243UwVv021269 for ; Thu, 3 Mar 2005 19:30:58 -0800 Received: from localhost (localhost [127.0.0.1]) by yue.st-paulia.net (Postfix) with ESMTP id BC88133CC2; Fri, 4 Mar 2005 12:32:29 +0900 (JST) Date: Fri, 04 Mar 2005 12:32:28 +0900 (JST) Message-Id: <20050304.123228.08284664.yoshfuji@linux-ipv6.org> To: tgraf@suug.ch, davem@davemloft.net Cc: netdev@oss.sgi.com Subject: Re: [PATCH 2/2] [NEIGH]: Provide number of probes to userspace From: YOSHIFUJI Hideaki / =?iso-2022-jp?B?GyRCNUhGIzFRTEAbKEI=?= In-Reply-To: <20050304023121.GC31837@postel.suug.ch> References: <20050304023121.GC31837@postel.suug.ch> Organization: USAGI Project X-URL: http://www.yoshifuji.org/%7Ehideaki/ X-Fingerprint: 9022 65EB 1ECF 3AD1 0BDF 80D8 4807 F894 E062 0EEA X-PGP-Key-URL: http://www.yoshifuji.org/%7Ehideaki/hideaki@yoshifuji.org.asc X-Face: "5$Al-.M>NJ%a'@hhZdQm:."qn~PA^gq4o*>iCFToq*bAi#4FRtx}enhuQKz7fNqQz\BYU] $~O_5m-9'}MIs`XGwIEscw;e5b>n"B_?j/AkL~i/MEaZBLP X-Mailer: Mew version 2.2 on Emacs 20.7 / Mule 4.1 (AOI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV 0.83/743/Wed Mar 2 16:02:05 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 2369 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: yoshfuji@linux-ipv6.org Precedence: bulk X-list: netdev Content-Length: 461 Lines: 14 In article <20050304023121.GC31837@postel.suug.ch> (at Fri, 4 Mar 2005 03:31:21 +0100), Thomas Graf says: > Provides number of probes done so far to userspace, quite useful for debugging. > > Signed-off-by: Thomas Graf It might be useful to provide probe count per state; e.g. in INCOMPLETE: probes in PROBLE : probes - (ucast_probes + app_probes) However, we can do this in userspace. Not strong opinion. --yoshfuji From hadi@cyberus.ca Thu Mar 3 19:46:14 2005 Received: with ECARTIS (v1.0.0; list netdev); Thu, 03 Mar 2005 19:46:19 -0800 (PST) Received: from mx03.cybersurf.com (mx03.cybersurf.com [209.197.145.106]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j243kD5w022870 for ; Thu, 3 Mar 2005 19:46:13 -0800 Received: from mail.cyberus.ca ([209.197.145.21]) by mx03.cybersurf.com with esmtp (Exim 4.30) id 1D73lP-0004dH-IG for netdev@oss.sgi.com; Thu, 03 Mar 2005 22:46:07 -0500 Received: from [24.103.99.32] (helo=[10.0.0.9]) by mail.cyberus.ca with esmtp (Exim 4.20) id 1D73lJ-0000bs-4e; Thu, 03 Mar 2005 22:46:01 -0500 Subject: Re: netif_rx packet dumping From: jamal Reply-To: hadi@cyberus.ca To: Baruch Even Cc: Stephen Hemminger , John Heffner , "David S. Miller" , rhee@eos.ncsu.edu, Yee-Ting.Li@nuim.ie, netdev@oss.sgi.com In-Reply-To: <4227A23C.5050300@ev-en.org> References: <20050303123811.4d934249@dxpl.pdx.osdl.net> <20050303125556.6850cfe5.davem@davemloft.net> <1109884688.1090.282.camel@jzny.localdomain> <20050303132143.7eef517c@dxpl.pdx.osdl.net> <1109885065.1098.285.camel@jzny.localdomain> <20050303133237.5d64578f.davem@davemloft.net> <20050303135416.0d6e7708@dxpl.pdx.osdl.net> <1109888811.1092.352.camel@jzny.localdomain> <20050303151606.3587394f@dxpl.pdx.osdl.net> <4227A23C.5050300@ev-en.org> Content-Type: text/plain Organization: jamalopolous Message-Id: <1109907956.1092.476.camel@jzny.localdomain> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.2.2 Date: 03 Mar 2005 22:45:56 -0500 Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV 0.83/743/Wed Mar 2 16:02:05 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 2371 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: hadi@cyberus.ca Precedence: bulk X-list: netdev Content-Length: 901 Lines: 25 On Thu, 2005-03-03 at 18:48, Baruch Even wrote: > > The queue is there to handle short bursts of packets when the network > stack cannot handle it. The bad behaviour was the throttling of the > queue, Can you explain a little more? Why does the the throttling cause any bad behavior thats any different from the queue being full? In both cases, packets arriving during that transient will be dropped. > the smart schemes are not going to make it that much better if > the hardware/software can't keep up. consider that this queue could be shared by as many as a few thousand unrelated TCP flows - not just one. It is also used for packets being forwarded. If you factor that the system has to react to protect itself then these schemes may make sense. The best place to do it is really in hardware, but the closer to the hardware as possible is the next besr possible spot. cheers, jamal From hadi@cyberus.ca Thu Mar 3 19:49:22 2005 Received: with ECARTIS (v1.0.0; list netdev); Thu, 03 Mar 2005 19:49:25 -0800 (PST) Received: from mx01.cybersurf.com (mx01.cybersurf.com [209.197.145.104]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j243nLTc023640 for ; Thu, 3 Mar 2005 19:49:22 -0800 Received: from mail.cyberus.ca ([209.197.145.21]) by mx01.cybersurf.com with esmtp (Exim 4.30) id 1D73oP-0006oA-HF for netdev@oss.sgi.com; Thu, 03 Mar 2005 20:49:13 -0700 Received: from [24.103.99.32] (helo=[10.0.0.9]) by mail.cyberus.ca with esmtp (Exim 4.20) id 1D73oU-0000zV-Lu; Thu, 03 Mar 2005 22:49:18 -0500 Subject: Re: [PATCH] iproute2 updates From: jamal Reply-To: hadi@cyberus.ca To: Thomas Graf Cc: Stephen Hemminger , netdev@oss.sgi.com In-Reply-To: <20050304023520.GD31837@postel.suug.ch> References: <20050304023520.GD31837@postel.suug.ch> Content-Type: text/plain Organization: jamalopolous Message-Id: <1109908154.1091.486.camel@jzny.localdomain> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.2.2 Date: 03 Mar 2005 22:49:14 -0500 Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV 0.83/743/Wed Mar 2 16:02:05 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 2372 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: hadi@cyberus.ca Precedence: bulk X-list: netdev Content-Length: 531 Lines: 17 On Thu, 2005-03-03 at 21:35, Thomas Graf wrote: > Stephen, > > You may pull the following changes from bk://tgr.bkbits.net/iproute2-tgr-fix Other than NPROBES change, shouldnt the other changes be reflective of whats in the kernel? This is the cost of keeping private headers. My suggestions would be to let Steve on every major release to just sync the header files. cheers, jamal PS:- Also on you 1/2 changes - I notice one bug fix, the rest seems cosmetic - what does that buy you? Does it make the code more readable etc? From hadi@cyberus.ca Thu Mar 3 19:52:25 2005 Received: with ECARTIS (v1.0.0; list netdev); Thu, 03 Mar 2005 19:52:30 -0800 (PST) Received: from mx04.cybersurf.com (mx04.cybersurf.com [209.197.145.108]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j243qOow024264 for ; Thu, 3 Mar 2005 19:52:25 -0800 Received: from mail.cyberus.ca ([209.197.145.21]) by mx01.cybersurf.com with esmtp (Exim 4.30) id 1D73rU-0003cj-3G for netdev@oss.sgi.com; Thu, 03 Mar 2005 22:52:24 -0500 Received: from [24.103.99.32] (helo=[10.0.0.9]) by mail.cyberus.ca with esmtp (Exim 4.20) id 1D73rP-0001GI-Oy; Thu, 03 Mar 2005 22:52:20 -0500 Subject: Re: [PATCH 2/2] [NEIGH]: Provide number of probes to userspace From: jamal Reply-To: hadi@cyberus.ca To: YOSHIFUJI Hideaki / =?UTF-8?Q?=E5=90=89=E8=97=A4=E8=8B=B1?= =?UTF-8?Q?=E6=98=8E?= Cc: tgraf@suug.ch, "David S. Miller" , netdev@oss.sgi.com In-Reply-To: <20050304.123228.08284664.yoshfuji@linux-ipv6.org> References: <20050304023121.GC31837@postel.suug.ch> <20050304.123228.08284664.yoshfuji@linux-ipv6.org> Content-Type: text/plain; charset=UTF-8 Organization: jamalopolous Message-Id: <1109908335.1092.493.camel@jzny.localdomain> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.2.2 Date: 03 Mar 2005 22:52:15 -0500 Content-Transfer-Encoding: 8bit X-Virus-Scanned: ClamAV 0.83/743/Wed Mar 2 16:02:05 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 2373 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: hadi@cyberus.ca Precedence: bulk X-list: netdev Content-Length: 614 Lines: 18 On Thu, 2005-03-03 at 22:32, YOSHIFUJI Hideaki / å‰è—¤è‹±æ˜Ž wrote: > In article <20050304023121.GC31837@postel.suug.ch> (at Fri, 4 Mar 2005 03:31:21 +0100), Thomas Graf says: > > > Provides number of probes done so far to userspace, quite useful for debugging. > > > > Signed-off-by: Thomas Graf > > It might be useful to provide probe count per state; e.g. > in INCOMPLETE: probes > in PROBLE : probes - (ucast_probes + app_probes) > However, we can do this in userspace. I think this will be overkill (its like maintaining history of all the states). cheers, jamal From jgarzik@pobox.com Thu Mar 3 19:59:08 2005 Received: with ECARTIS (v1.0.0; list netdev); Thu, 03 Mar 2005 19:59:16 -0800 (PST) Received: from parcelfarce.linux.theplanet.co.uk (IDENT:93@parcelfarce.linux.theplanet.co.uk [195.92.249.252]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j243x633025319 for ; Thu, 3 Mar 2005 19:59:07 -0800 Received: from [69.134.152.124] (helo=[10.10.10.88]) by parcelfarce.linux.theplanet.co.uk with asmtp (TLSv1:AES256-SHA:256) (Exim 4.33) id 1D73xx-0002Hw-1Y; Fri, 04 Mar 2005 03:59:05 +0000 Message-ID: <4227DCE9.2040604@pobox.com> Date: Thu, 03 Mar 2005 22:58:33 -0500 From: Jeff Garzik User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.3) Gecko/20040922 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Netdev CC: Linux Kernel , ionut@badula.org Subject: [PATCH, RFT] starfire net driver update Content-Type: multipart/mixed; boundary="------------070300050900020608080705" X-Virus-Scanned: ClamAV 0.83/743/Wed Mar 2 16:02:05 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 2374 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: jgarzik@pobox.com Precedence: bulk X-list: netdev Content-Length: 23496 Lines: 786 This is a multi-part message in MIME format. --------------070300050900020608080705 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit The starfire net driver was just updated to include the firmware that Adaptec kindly GPL'd for us a while ago. The firmware is needed to enable zero-copy. Can someone with this card give it a test, to make sure all is still working? Particularly, if you could test an application that uses sendfile(2) [zero-copy], that would be useful. Jeff --------------070300050900020608080705 Content-Type: text/plain; name="patch" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="patch" # # ChangeSet # 2005/03/03 22:53:40-05:00 jgarzik@pobox.com # [netdrvr starfire] Add GPL'd firmware, remove compat code # # Contributed by Ion Badulescu , # further fixed up by me. # diff -Nru a/drivers/net/starfire.c b/drivers/net/starfire.c --- a/drivers/net/starfire.c 2005-03-03 22:53:54 -05:00 +++ b/drivers/net/starfire.c 2005-03-03 22:53:54 -05:00 @@ -2,7 +2,7 @@ /* Written 1998-2000 by Donald Becker. - Current maintainer is Ion Badulescu . Please + Current maintainer is Ion Badulescu . Please send all bug reports to me, and not to Donald Becker, as this code has been heavily modified from Donald's original version. @@ -129,12 +129,18 @@ - put the chip to a D3 slumber on driver unload - added config option to enable/disable NAPI -TODO: bugfixes (no bugs known as of right now) + LK1.4.2 (Ion Badulescu) + - finally added firmware (GPL'ed by Adaptec) + - removed compatibility code for 2.2.x + +TODO: - fix forced speed/duplexing code (broken a long time ago, when + somebody converted the driver to use the generic MII code) + - fix VLAN support */ #define DRV_NAME "starfire" -#define DRV_VERSION "1.03+LK1.4.1" -#define DRV_RELDATE "February 10, 2002" +#define DRV_VERSION "1.03+LK1.4.2" +#define DRV_RELDATE "January 19, 2005" #include #include @@ -145,25 +151,15 @@ #include #include #include +#include +#include +#include +#include #include /* Processor type for cache alignment. */ #include #include -/* - * Adaptec's license for their drivers (which is where I got the - * firmware files) does not allow one to redistribute them. Thus, we can't - * include the firmware with this driver. - * - * However, should a legal-to-distribute firmware become available, - * the driver developer would need only to obtain the firmware in the - * form of a C header file. - * Once that's done, the #undef below must be changed into a #define - * for this driver to really use the firmware. Note that Rx/Tx - * hardware TCP checksumming is not possible without the firmware. - * - * WANTED: legal firmware to include with this GPL'd driver. - */ -#undef HAS_FIRMWARE +#include "starfire_firmware.h" /* * The current frame processor firmware fails to checksum a fragment * of length 1. If and when this is fixed, the #define below can be removed. @@ -172,13 +168,7 @@ /* * Define this if using the driver with the zero-copy patch */ -#if defined(HAS_FIRMWARE) && defined(MAX_SKB_FRAGS) #define ZEROCOPY -#endif - -#ifdef HAS_FIRMWARE -#include "starfire_firmware.h" -#endif /* HAS_FIRMWARE */ #if defined(CONFIG_VLAN_8021Q) || defined(CONFIG_VLAN_8021Q_MODULE) #define VLAN_SUPPORT @@ -202,11 +192,7 @@ The Starfire has a 512 element hash table based on the Ethernet CRC. */ static int multicast_filter_limit = 512; /* Whether to do TCP/UDP checksums in hardware */ -#ifdef HAS_FIRMWARE static int enable_hw_cksum = 1; -#else -static int enable_hw_cksum = 0; -#endif #define PKT_BUF_SZ 1536 /* Size of each temporary Rx buffer.*/ /* @@ -291,43 +277,15 @@ #define RX_DESC_ADDR_SIZE RxDescAddr32bit #endif -#ifdef MAX_SKB_FRAGS #define skb_first_frag_len(skb) skb_headlen(skb) #define skb_num_frags(skb) (skb_shinfo(skb)->nr_frags + 1) -#else /* not MAX_SKB_FRAGS */ -#define skb_first_frag_len(skb) (skb->len) -#define skb_num_frags(skb) 1 -#endif /* not MAX_SKB_FRAGS */ - -/* 2.2.x compatibility code */ -#if LINUX_VERSION_CODE < 0x20300 - -#include "starfire-kcomp22.h" - -#else /* LINUX_VERSION_CODE > 0x20300 */ - -#include -#include -#include - -#include - -#define init_tx_timer(dev, func, timeout) \ - dev->tx_timeout = func; \ - dev->watchdog_timeo = timeout; -#define kick_tx_timer(dev, func, timeout) - -#define netif_start_if(dev) -#define netif_stop_if(dev) - -#define PCI_SLOT_NAME(pci_dev) pci_name(pci_dev) - -#endif /* LINUX_VERSION_CODE > 0x20300 */ #ifdef HAVE_NETDEV_POLL #define init_poll(dev) \ +do { \ dev->poll = &netdev_poll; \ - dev->weight = max_interrupt_work; + dev->weight = max_interrupt_work; \ +} while (0) #define netdev_rx(dev, ioaddr) \ do { \ u32 intr_enable; \ @@ -341,7 +299,7 @@ /* Paranoia check */ \ intr_enable = readl(ioaddr + IntrEnable); \ if (intr_enable & (IntrRxDone | IntrRxEmpty)) { \ - printk("%s: interrupt while in polling mode!\n", dev->name); \ + printk(KERN_INFO "%s: interrupt while in polling mode!\n", dev->name); \ intr_enable &= ~(IntrRxDone | IntrRxEmpty); \ writel(intr_enable, ioaddr + IntrEnable); \ } \ @@ -371,6 +329,7 @@ MODULE_AUTHOR("Donald Becker "); MODULE_DESCRIPTION("Adaptec Starfire Ethernet driver"); MODULE_LICENSE("GPL"); +MODULE_VERSION(DRV_VERSION); module_param(max_interrupt_work, int, 0); module_param(mtu, int, 0); @@ -425,7 +384,7 @@ minimum-length padding. It does not use the completion queue consumer index, but instead checks for non-zero status entries. -For receive this driver uses type 0/1/2/3 receive descriptors. The driver +For receive this driver uses type 2/3 receive descriptors. The driver allocates full frame size skbuffs for the Rx ring buffers, so all frames should fit in a single descriptor. The driver does not use the completion queue consumer index, but instead checks for non-zero status entries. @@ -476,7 +435,7 @@ */ - + enum chip_capability_flags {CanHaveMII=1, }; @@ -670,7 +629,6 @@ u32 timestamp; }; /* XXX: this is ugly and I'm not sure it's worth the trouble -Ion */ -#ifdef HAS_FIRMWARE #ifdef VLAN_SUPPORT typedef struct full_rx_done_desc rx_done_desc; #define RxComplType RxComplType3 @@ -678,15 +636,6 @@ typedef struct csum_rx_done_desc rx_done_desc; #define RxComplType RxComplType2 #endif /* not VLAN_SUPPORT */ -#else /* not HAS_FIRMWARE */ -#ifdef VLAN_SUPPORT -typedef struct basic_rx_done_desc rx_done_desc; -#define RxComplType RxComplType1 -#else /* not VLAN_SUPPORT */ -typedef struct short_rx_done_desc rx_done_desc; -#define RxComplType RxComplType0 -#endif /* not VLAN_SUPPORT */ -#endif /* not HAS_FIRMWARE */ enum rx_done_bits { RxOK=0x20000000, RxFIFOErr=0x10000000, RxBufQ2=0x08000000, @@ -898,13 +847,10 @@ /* enable MWI -- it vastly improves Rx performance on sparc64 */ pci_set_mwi(pdev); -#ifdef MAX_SKB_FRAGS - dev->features |= NETIF_F_SG; -#endif /* MAX_SKB_FRAGS */ #ifdef ZEROCOPY /* Starfire can do TCP/UDP checksumming */ if (enable_hw_cksum) - dev->features |= NETIF_F_IP_CSUM; + dev->features |= NETIF_F_IP_CSUM | NETIF_F_SG; #endif /* ZEROCOPY */ #ifdef VLAN_SUPPORT dev->features |= NETIF_F_HW_VLAN_RX | NETIF_F_HW_VLAN_FILTER; @@ -1008,7 +954,8 @@ /* The chip-specific entries in the device structure. */ dev->open = &netdev_open; dev->hard_start_xmit = &start_tx; - init_tx_timer(dev, tx_timeout, TX_TIMEOUT); + dev->tx_timeout = tx_timeout; + dev->watchdog_timeo = TX_TIMEOUT; init_poll(dev); dev->stop = &netdev_close; dev->get_stats = &get_stats; @@ -1039,7 +986,7 @@ if ((mdio_read(dev, phy, MII_BMCR) & BMCR_RESET) == 0) break; if (boguscnt == 0) { - printk("%s: PHY reset never completed!\n", dev->name); + printk("%s: PHY#%d reset never completed!\n", dev->name, phy); continue; } mii_status = mdio_read(dev, phy, MII_BMSR); @@ -1110,6 +1057,7 @@ size_t tx_done_q_size, rx_done_q_size, tx_ring_size, rx_ring_size; /* Do we ever need to reset the chip??? */ + retval = request_irq(dev->irq, &intr_handler, SA_SHIRQ, dev->name, dev); if (retval) return retval; @@ -1211,7 +1159,6 @@ writel(np->intr_timer_ctrl, ioaddr + IntrTimerCtrl); - netif_start_if(dev); netif_start_queue(dev); if (debug > 1) @@ -1238,13 +1185,11 @@ writel(ETH_P_8021Q, ioaddr + VlanType); #endif /* VLAN_SUPPORT */ -#ifdef HAS_FIRMWARE /* Load Rx/Tx firmware into the frame processors */ for (i = 0; i < FIRMWARE_RX_SIZE * 2; i++) writel(firmware_rx[i], ioaddr + RxGfpMem + i * 4); for (i = 0; i < FIRMWARE_TX_SIZE * 2; i++) writel(firmware_tx[i], ioaddr + TxGfpMem + i * 4); -#endif /* HAS_FIRMWARE */ if (enable_hw_cksum) /* Enable the Rx and Tx units, and the Rx/Tx frame processors. */ writel(TxEnable|TxGFPEnable|RxEnable|RxGFPEnable, ioaddr + GenCtrl); @@ -1378,8 +1323,6 @@ u32 status; int i; - kick_tx_timer(dev, tx_timeout, TX_TIMEOUT); - /* * be cautious here, wrapping the queue has weird semantics * and we may not have enough slots even when it seems we do. @@ -1404,7 +1347,7 @@ } if (has_bad_length) - skb_checksum_help(skb); + skb_checksum_help(skb, 0); } #endif /* ZEROCOPY && HAS_BROKEN_FIRMWARE */ @@ -1433,12 +1376,10 @@ np->tx_info[entry].mapping = pci_map_single(np->pci_dev, skb->data, skb_first_frag_len(skb), PCI_DMA_TODEVICE); } else { -#ifdef MAX_SKB_FRAGS skb_frag_t *this_frag = &skb_shinfo(skb)->frags[i - 1]; status |= this_frag->size; np->tx_info[entry].mapping = pci_map_single(np->pci_dev, page_address(this_frag->page) + this_frag->page_offset, this_frag->size, PCI_DMA_TODEVICE); -#endif /* MAX_SKB_FRAGS */ } np->tx_ring[entry].addr = cpu_to_dma(np->tx_info[entry].mapping); @@ -1531,7 +1472,6 @@ np->tx_info[entry].mapping = 0; np->dirty_tx += np->tx_info[entry].used_slots; entry = (entry + np->tx_info[entry].used_slots) % TX_RING_SIZE; -#ifdef MAX_SKB_FRAGS { int i; for (i = 0; i < skb_shinfo(skb)->nr_frags; i++) { @@ -1543,7 +1483,7 @@ entry++; } } -#endif /* MAX_SKB_FRAGS */ + dev_kfree_skb_irq(skb); } np->tx_done_q[np->tx_done].status = 0; @@ -1603,7 +1543,7 @@ if (debug > 4) printk(KERN_DEBUG " netdev_rx() status of %d was %#8.8x.\n", np->rx_done, desc_status); if (!(desc_status & RxOK)) { - /* There was a error. */ + /* There was an error. */ if (debug > 2) printk(KERN_DEBUG " netdev_rx() Rx error was %#8.8x.\n", desc_status); np->stats.rx_errors++; @@ -1656,11 +1596,10 @@ #endif skb->protocol = eth_type_trans(skb, dev); -#if defined(HAS_FIRMWARE) || defined(VLAN_SUPPORT) +#ifdef VLAN_SUPPORT if (debug > 4) printk(KERN_DEBUG " netdev_rx() status2 of %d was %#4.4x.\n", np->rx_done, le16_to_cpu(desc->status2)); #endif -#ifdef HAS_FIRMWARE if (le16_to_cpu(desc->status2) & 0x0100) { skb->ip_summed = CHECKSUM_UNNECESSARY; np->stats.rx_compressed++; @@ -1679,7 +1618,6 @@ skb->csum = le16_to_cpu(desc->csum); printk(KERN_DEBUG "%s: checksum_hw, status2 = %#x\n", dev->name, le16_to_cpu(desc->status2)); } -#endif /* HAS_FIRMWARE */ #ifdef VLAN_SUPPORT if (np->vlgrp && le16_to_cpu(desc->status2) & 0x0200) { if (debug > 4) @@ -1900,9 +1838,6 @@ } -/* Chips may use the upper or lower CRC bits, and may reverse and/or invert - them. Select the endian-ness that results in minimal calculations. -*/ static void set_rx_mode(struct net_device *dev) { struct netdev_private *np = netdev_priv(dev); @@ -1969,6 +1904,8 @@ memset(mc_filter, 0, sizeof(mc_filter)); for (i = 0, mclist = dev->mc_list; mclist && i < dev->mc_count; i++, mclist = mclist->next) { + /* The chip uses the upper 9 CRC bits + as index into the hash table */ int bit_nr = ether_crc_le(ETH_ALEN, mclist->dmi_addr) >> 23; __u32 *fptr = (__u32 *) &mc_filter[(bit_nr >> 4) & ~1]; @@ -2001,7 +1938,7 @@ struct netdev_private *np = netdev_priv(dev); strcpy(info->driver, DRV_NAME); strcpy(info->version, DRV_VERSION); - strcpy(info->bus_info, PCI_SLOT_NAME(np->pci_dev)); + strcpy(info->bus_info, pci_name(np->pci_dev)); } static int get_settings(struct net_device *dev, struct ethtool_cmd *ecmd) @@ -2083,7 +2020,6 @@ int i; netif_stop_queue(dev); - netif_stop_if(dev); if (debug > 1) { printk(KERN_DEBUG "%s: Shutting down ethercard, Intr status %#8.8x.\n", @@ -2184,7 +2120,13 @@ /* when a module, this is printed whether or not devices are found in probe */ #ifdef MODULE printk(version); +#ifdef HAVE_NETDEV_POLL + printk(KERN_INFO DRV_NAME ": polling (NAPI) enabled\n"); +#else + printk(KERN_INFO DRV_NAME ": polling (NAPI) disabled\n"); #endif +#endif + #ifndef ADDR_64BITS /* we can do this test only at run-time... sigh */ if (sizeof(dma_addr_t) == sizeof(u64)) { @@ -2192,10 +2134,6 @@ return -ENODEV; } #endif /* not ADDR_64BITS */ -#ifndef HAS_FIRMWARE - /* unconditionally disable hw cksums if firmware is not present */ - enable_hw_cksum = 0; -#endif /* not HAS_FIRMWARE */ return pci_module_init (&starfire_driver); } diff -Nru a/drivers/net/starfire_firmware.h b/drivers/net/starfire_firmware.h --- /dev/null Wed Dec 31 16:00:00 196900 +++ b/drivers/net/starfire_firmware.h 2005-03-03 22:53:54 -05:00 @@ -0,0 +1,346 @@ +/* + * Copyright 2003 Adaptec, Inc. + * + * Please read the following license before using the Adaptec Software + * ("Program"). If you do not agree to the license terms, do not use the + * Program: + * + * You agree to be bound by version 2 of the General Public License ("GPL") + * dated June 1991, which can be found at http://www.fsf.org/licenses/gpl.html. + * If the link is broken, write to Free Software Foundation, 59 Temple Place, + * Boston, Massachusetts 02111-1307. + * + * BECAUSE THE PROGRAM IS LICENSED FREE OF CHARGE IT IS LICENSED "AS IS" AND + * THERE IS NO WARRANTY FOR THE PROGRAM, INCLUDING BUT NOT LIMITED TO THE + * IMPLIED WARRANTIES OF MERCHANTIBILITY OR FITNESS FOR A PARTICULAR PURPOSE + * (TO THE EXTENT PERMITTED BY APPLICABLE LAW). USE OF THE PROGRAM IS AT YOUR + * OWN RISK. IN NO EVENT WILL ADAPTEC OR ITS LICENSORS BE LIABLE TO YOU FOR + * DAMAGES, INCLUDING ANY GENERAL, SPECIAL, INCIDENTAL OR CONSEQUENTIAL DAMAGES + * ARISING OUT OF THE USE OR INABILITY TO USE THE PROGRAM. + * + */ + +static const u32 firmware_rx[] = { + 0x010003dc, 0x00000000, + 0x04000421, 0x00000086, + 0x80000015, 0x0000180e, + 0x81000015, 0x00006664, + 0x1a0040ab, 0x00000b06, + 0x14200011, 0x00000000, + 0x14204022, 0x0000aaaa, + 0x14204022, 0x00000300, + 0x14204022, 0x00000000, + 0x1a0040ab, 0x00000b14, + 0x14200011, 0x00000000, + 0x83000015, 0x00000002, + 0x04000021, 0x00000000, + 0x00000010, 0x00000000, + 0x04000421, 0x00000087, + 0x00000010, 0x00000000, + 0x00000010, 0x00000000, + 0x00008015, 0x00000000, + 0x0000003e, 0x00000000, + 0x00000010, 0x00000000, + 0x82000015, 0x00004000, + 0x009e8050, 0x00000000, + 0x03008015, 0x00000000, + 0x86008015, 0x00000000, + 0x82000015, 0x00008000, + 0x0100001c, 0x00000000, + 0x000050a0, 0x0000010c, + 0x4e20d011, 0x00006008, + 0x1420d012, 0x00004008, + 0x0000f090, 0x00007000, + 0x0000c8b0, 0x00003000, + 0x00004040, 0x00000000, + 0x00108015, 0x00000000, + 0x00a2c150, 0x00004000, + 0x00a400b0, 0x00000014, + 0x00000020, 0x00000000, + 0x2500400d, 0x00002525, + 0x00047220, 0x00003100, + 0x00934070, 0x00000000, + 0x00000020, 0x00000000, + 0x00924460, 0x00000184, + 0x2b20c011, 0x00000000, + 0x0000c420, 0x00000540, + 0x36014018, 0x0000422d, + 0x14200011, 0x00000000, + 0x00924460, 0x00000183, + 0x3200001f, 0x00000034, + 0x02ac0015, 0x00000002, + 0x00a60110, 0x00000008, + 0x42200011, 0x00000000, + 0x00924060, 0x00000103, + 0x0000001e, 0x00000000, + 0x00000020, 0x00000100, + 0x0000001e, 0x00000000, + 0x00924460, 0x00000086, + 0x00004080, 0x00000000, + 0x0092c070, 0x00000000, + 0x00924060, 0x00000100, + 0x0000c890, 0x00005000, + 0x00a6c110, 0x00000000, + 0x00b0c090, 0x00000012, + 0x021c0015, 0x00000000, + 0x3200001f, 0x00000034, + 0x00924460, 0x00000510, + 0x44210011, 0x00000000, + 0x42000011, 0x00000000, + 0x83000015, 0x00000040, + 0x00924460, 0x00000508, + 0x45014018, 0x00004545, + 0x00808050, 0x00000000, + 0x62208012, 0x00000000, + 0x82000015, 0x00000800, + 0x15200011, 0x00000000, + 0x00000010, 0x00000000, + 0x00000010, 0x00000000, + 0x00000010, 0x00000000, + 0x00000010, 0x00000000, + 0x00000010, 0x00000000, + 0x80000015, 0x0000eea4, + 0x81000015, 0x0000005f, + 0x00000060, 0x00000000, + 0x00004120, 0x00000000, + 0x00004a00, 0x00004000, + 0x00924460, 0x00000190, + 0x5601401a, 0x00005956, + 0x14000011, 0x00000000, + 0x00934050, 0x00000018, + 0x00930050, 0x00000018, + 0x3601403a, 0x0000002d, + 0x000643a9, 0x00000000, + 0x0000c420, 0x00000140, + 0x5601401a, 0x00005956, + 0x14000011, 0x00000000, + 0x00000010, 0x00000000, + 0x00000010, 0x00000000, + 0x000642a9, 0x00000000, + 0x00024420, 0x00000183, + 0x5601401a, 0x00005956, + 0x82000015, 0x00002000, + 0x15200011, 0x00000000, + 0x82000015, 0x00000010, + 0x15200011, 0x00000000, + 0x82000015, 0x00000010, + 0x15200011, 0x00000000, +}; /* 104 Rx instructions */ +#define FIRMWARE_RX_SIZE 104 + +static const u32 firmware_tx[] = { + 0x010003dc, 0x00000000, + 0x04000421, 0x00000086, + 0x80000015, 0x0000180e, + 0x81000015, 0x00006664, + 0x1a0040ab, 0x00000b06, + 0x14200011, 0x00000000, + 0x14204022, 0x0000aaaa, + 0x14204022, 0x00000300, + 0x14204022, 0x00000000, + 0x1a0040ab, 0x00000b14, + 0x14200011, 0x00000000, + 0x83000015, 0x00000002, + 0x04000021, 0x00000000, + 0x00000010, 0x00000000, + 0x04000421, 0x00000087, + 0x00000010, 0x00000000, + 0x00000010, 0x00000000, + 0x00008015, 0x00000000, + 0x0000003e, 0x00000000, + 0x00000010, 0x00000000, + 0x82000015, 0x00004000, + 0x009e8050, 0x00000000, + 0x03008015, 0x00000000, + 0x86008015, 0x00000000, + 0x82000015, 0x00008000, + 0x0100001c, 0x00000000, + 0x000050a0, 0x0000010c, + 0x4e20d011, 0x00006008, + 0x1420d012, 0x00004008, + 0x0000f090, 0x00007000, + 0x0000c8b0, 0x00003000, + 0x00004040, 0x00000000, + 0x00108015, 0x00000000, + 0x00a2c150, 0x00004000, + 0x00a400b0, 0x00000014, + 0x00000020, 0x00000000, + 0x2500400d, 0x00002525, + 0x00047220, 0x00003100, + 0x00934070, 0x00000000, + 0x00000020, 0x00000000, + 0x00924460, 0x00000184, + 0x2b20c011, 0x00000000, + 0x0000c420, 0x00000540, + 0x36014018, 0x0000422d, + 0x14200011, 0x00000000, + 0x00924460, 0x00000183, + 0x3200001f, 0x00000034, + 0x02ac0015, 0x00000002, + 0x00a60110, 0x00000008, + 0x42200011, 0x00000000, + 0x00924060, 0x00000103, + 0x0000001e, 0x00000000, + 0x00000020, 0x00000100, + 0x0000001e, 0x00000000, + 0x00924460, 0x00000086, + 0x00004080, 0x00000000, + 0x0092c070, 0x00000000, + 0x00924060, 0x00000100, + 0x0000c890, 0x00005000, + 0x00a6c110, 0x00000000, + 0x00b0c090, 0x00000012, + 0x021c0015, 0x00000000, + 0x3200001f, 0x00000034, + 0x00924460, 0x00000510, + 0x44210011, 0x00000000, + 0x42000011, 0x00000000, + 0x83000015, 0x00000040, + 0x00924460, 0x00000508, + 0x45014018, 0x00004545, + 0x00808050, 0x00000000, + 0x62208012, 0x00000000, + 0x82000015, 0x00000800, + 0x15200011, 0x00000000, + 0x00000010, 0x00000000, + 0x00000010, 0x00000000, + 0x00000010, 0x00000000, + 0x00000010, 0x00000000, + 0x00000010, 0x00000000, + 0x80000015, 0x0000eea4, + 0x81000015, 0x0000005f, + 0x00000060, 0x00000000, + 0x00004120, 0x00000000, + 0x00004a00, 0x00004000, + 0x00924460, 0x00000190, + 0x5601401a, 0x00005956, + 0x14000011, 0x00000000, + 0x00934050, 0x00000018, + 0x00930050, 0x00000018, + 0x3601403a, 0x0000002d, + 0x000643a9, 0x00000000, + 0x0000c420, 0x00000140, + 0x5601401a, 0x00005956, + 0x14000011, 0x00000000, + 0x00000010, 0x00000000, + 0x00000010, 0x00000000, + 0x000642a9, 0x00000000, + 0x00024420, 0x00000183, + 0x5601401a, 0x00005956, + 0x82000015, 0x00002000, + 0x15200011, 0x00000000, + 0x82000015, 0x00000010, + 0x15200011, 0x00000000, + 0x82000015, 0x00000010, + 0x15200011, 0x00000000, +}; /* 104 Tx instructions */ +#define FIRMWARE_TX_SIZE 104 +#if 0 +static const u32 firmware_wol[] = { + 0x010003dc, 0x00000000, + 0x19000421, 0x00000087, + 0x80000015, 0x00001a1a, + 0x81000015, 0x00001a1a, + 0x1a0040ab, 0x00000b06, + 0x15200011, 0x00000000, + 0x15204022, 0x0000aaaa, + 0x15204022, 0x00000300, + 0x15204022, 0x00000000, + 0x1a0040ab, 0x00000b15, + 0x15200011, 0x00000000, + 0x83000015, 0x00000002, + 0x04000021, 0x00000000, + 0x00000010, 0x00000000, + 0x04000421, 0x00000087, + 0x00000010, 0x00000000, + 0x00000010, 0x00000000, + 0x00008015, 0x00000000, + 0x0000003e, 0x00000000, + 0x00000010, 0x00000000, + 0x00000010, 0x00000000, + 0x82000015, 0x00004000, + 0x82000015, 0x00008000, + 0x0000000c, 0x00000000, + 0x00000010, 0x00000000, + 0x00004080, 0x00000100, + 0x1f20c011, 0x00001122, + 0x2720f011, 0x00003011, + 0x19200071, 0x00000000, + 0x1a200051, 0x00000000, + 0x00000010, 0x00000000, + 0x00000010, 0x00000000, + 0x1d2040a4, 0x00003344, + 0x1d2040a2, 0x00005566, + 0x000040a0, 0x00000100, + 0x00108050, 0x00000001, + 0x1a208012, 0x00000006, + 0x82000015, 0x00008080, + 0x010003dc, 0x00000000, + 0x1d2040a4, 0x00002233, + 0x1d2040a4, 0x00004455, + 0x2d208011, 0x00000005, + 0x1d2040a4, 0x00006611, + 0x00108050, 0x00000001, + 0x27200011, 0x00000000, + 0x1d2050a4, 0x00006600, + 0x82000015, 0x00008080, + 0x010003dc, 0x00000000, + 0x00000050, 0x00000000, + 0x1b200031, 0x00000000, + 0x0000001e, 0x00000000, + 0x0000001e, 0x00000000, + 0x0000001e, 0x00000000, + 0x0000001e, 0x00000000, + 0x00924460, 0x00000086, + 0x00004080, 0x00000000, + 0x0092c070, 0x00000000, + 0x00924060, 0x00000100, + 0x0000c890, 0x00005000, + 0x00a6c110, 0x00000000, + 0x00b0c090, 0x00000012, + 0x021c0015, 0x00000000, + 0x3200001f, 0x00000034, + 0x00924460, 0x00000510, + 0x44210011, 0x00000000, + 0x42000011, 0x00000000, + 0x83000015, 0x00000040, + 0x00924460, 0x00000508, + 0x476a0012, 0x00000100, + 0x83000015, 0x00000008, + 0x16200011, 0x00000000, + 0x001e8050, 0x00000000, + 0x001e8050, 0x00000000, + 0x00808050, 0x00000000, + 0x03008015, 0x00000000, + 0x62208012, 0x00000000, + 0x82000015, 0x00000800, + 0x16200011, 0x00000000, + 0x80000015, 0x0000eea4, + 0x81000015, 0x0000005f, + 0x00000020, 0x00000000, + 0x00004120, 0x00000000, + 0x00004a00, 0x00004000, + 0x00924460, 0x00000190, + 0x5c01401a, 0x0000595c, + 0x15000011, 0x00000000, + 0x00934050, 0x00000018, + 0x00930050, 0x00000018, + 0x3601403a, 0x0000002d, + 0x00064029, 0x00000000, + 0x0000c420, 0x00000140, + 0x5c01401a, 0x0000595c, + 0x15000011, 0x00000000, + 0x00000010, 0x00000000, + 0x00000010, 0x00000000, + 0x00064029, 0x00000000, + 0x00024420, 0x00000183, + 0x5c01401a, 0x0000595c, + 0x82000015, 0x00002000, + 0x16200011, 0x00000000, + 0x82000015, 0x00000010, + 0x16200011, 0x00000000, + 0x82000015, 0x00000010, + 0x16200011, 0x00000000, +}; /* 104 WoL instructions */ +#define FIRMWARE_WOL_SIZE 104 +#endif --------------070300050900020608080705-- From jgarzik@pobox.com Thu Mar 3 21:11:35 2005 Received: with ECARTIS (v1.0.0; list netdev); Thu, 03 Mar 2005 21:11:40 -0800 (PST) Received: from parcelfarce.linux.theplanet.co.uk (IDENT:93@parcelfarce.linux.theplanet.co.uk [195.92.249.252]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j245BYe9000877 for ; Thu, 3 Mar 2005 21:11:35 -0800 Received: from [69.134.152.124] (helo=[10.10.10.88]) by parcelfarce.linux.theplanet.co.uk with asmtp (TLSv1:AES256-SHA:256) (Exim 4.33) id 1D7565-0003Sw-7p; Fri, 04 Mar 2005 05:11:33 +0000 Message-ID: <4227EDEC.3040606@pobox.com> Date: Fri, 04 Mar 2005 00:11:08 -0500 From: Jeff Garzik User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.3) Gecko/20040922 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Daniel Drake CC: Netdev , Linux Kernel , Andrew Morton , philipp.gortan@tttech.com Subject: Re: netdev-2.6 queue updated References: <4226BD3B.9080604@pobox.com> <42277195.8@gentoo.org> In-Reply-To: <42277195.8@gentoo.org> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV 0.83/743/Wed Mar 2 16:02:05 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 2375 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: jgarzik@pobox.com Precedence: bulk X-list: netdev Content-Length: 354 Lines: 17 Daniel Drake wrote: > Jeff Garzik wrote: > >> : >> o [netdrvr 8139cp] add PCI ID > > > This one seems to be already present in 2.6.11 under a different name > (PCI_DEVICE_ID_TTTECH_MC322). Also, the corresponding entry in pci_ids.h > is not in the order of the file. BitKeeper will fix that up at merge time. Jeff From dcbw@redhat.com Thu Mar 3 21:54:03 2005 Received: with ECARTIS (v1.0.0; list netdev); Thu, 03 Mar 2005 21:54:08 -0800 (PST) Received: from mx1.redhat.com (mx1.redhat.com [66.187.233.31]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j245s0Jr006719 for ; Thu, 3 Mar 2005 21:54:03 -0800 Received: from int-mx1.corp.redhat.com (int-mx1.corp.redhat.com [172.16.52.254]) by mx1.redhat.com (8.12.11/8.12.11) with ESMTP id j245rwig011996; Fri, 4 Mar 2005 00:53:58 -0500 Received: from mail.boston.redhat.com (mail.boston.redhat.com [172.16.76.12]) by int-mx1.corp.redhat.com (8.11.6/8.11.6) with ESMTP id j245rwK08328; Fri, 4 Mar 2005 00:53:58 -0500 Received: from dcbw.boston.redhat.com (dcbw.boston.redhat.com [172.16.80.23]) by mail.boston.redhat.com (8.12.8/8.12.8) with ESMTP id j245rwiD026083; Fri, 4 Mar 2005 00:53:58 -0500 Subject: resend: [PATCH 2.6.11+netdev] wireless: airo WEXT and quality corrections From: Dan Williams To: netdev@oss.sgi.com Cc: jgarzik@pobox.com, breed@users.sourceforge.net, davem@davemloft.net Content-Type: text/plain Date: Fri, 04 Mar 2005 00:53:57 -0500 Message-Id: <1109915637.14225.2.camel@dcbw.boston.redhat.com> Mime-Version: 1.0 X-Mailer: Evolution 2.0.2 (2.0.2-4) Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV 0.83/743/Wed Mar 2 16:02:05 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 2376 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: dcbw@redhat.com Precedence: bulk X-list: netdev Content-Length: 10327 Lines: 314 This patch brings the airo driver into line with the current WEXT specification of signal quality. It also fixes the values used to determine signal quality and level for MPI & PCMCIA 350 cards. It turns out that BSSListRid.rssi was actually in dBm for 350 series cards, and that we can use the normalized signal strength reported by the card as our "quality" value, on a scale of 0 - 100. Since signal level values are in dBm for this driver, max_qual->level MUST be 0, as specified in the WEXT spec. This patch also uses the IW_QUAL constants new in WEXT version 17. Signed-off-by: Dan Williams --- a/drivers/net/wireless/airo.c 2005-02-10 18:36:58.000000000 -0500 +++ a/drivers/net/wireless/airo.c 2005-02-11 15:45:19.000000000 -0500 @@ -754,7 +754,7 @@ u8 zero; u8 ssidLen; u8 ssid[32]; - u16 rssi; + u16 dBm; #define CAP_ESS (1<<0) #define CAP_IBSS (1<<1) #define CAP_PRIVACY (1<<4) @@ -1125,6 +1125,9 @@ static int encapsulate(struct airo_info *ai, etherHead *pPacket, MICBuffer *buffer, int len); static int decapsulate(struct airo_info *ai, MICBuffer *mic, etherHead *pPacket, u16 payLen); +static u8 airo_rssi_to_dbm (tdsRssiEntry *rssi_rid, u8 rssi); +static u8 airo_dbm_to_pct (tdsRssiEntry *rssi_rid, u8 dbm); + #include #endif @@ -1714,6 +1717,7 @@ list->fh.dwell = le16_to_cpu(list->fh.dwell); list->dsChannel = le16_to_cpu(list->dsChannel); list->atimWindow = le16_to_cpu(list->atimWindow); + list->dBm = le16_to_cpu(list->dBm); return rc; } @@ -3248,7 +3252,10 @@ wstats.level = 0x100 - apriv->rssi[hdr.rssi[1]].rssidBm; else wstats.level = (hdr.rssi[1] + 321) / 2; - wstats.updated = 3; + wstats.noise = apriv->wstats.qual.noise; + wstats.updated = IW_QUAL_LEVEL_UPDATED + | IW_QUAL_QUAL_UPDATED + | IW_QUAL_NOISE_UPDATED; /* Update spy records */ wireless_spy_update(dev, sa, &wstats); } @@ -3591,7 +3598,10 @@ wstats.level = 0x100 - ai->rssi[hdr.rssi[1]].rssidBm; else wstats.level = (hdr.rssi[1] + 321) / 2; - wstats.updated = 3; + wstats.noise = ai->wstats.qual.noise; + wstats.updated = IW_QUAL_QUAL_UPDATED + | IW_QUAL_LEVEL_UPDATED + | IW_QUAL_NOISE_UPDATED; /* Update spy records */ wireless_spy_update(ai->dev, sa, &wstats); } @@ -3682,7 +3692,7 @@ status = PC4500_readrid(ai,RID_RSSI,&rssi_rid,sizeof(rssi_rid),lock); if ( status == SUCCESS ) { if (ai->rssi || (ai->rssi = kmalloc(512, GFP_KERNEL)) != NULL) - memcpy(ai->rssi, (u8*)&rssi_rid + 2, 512); + memcpy(ai->rssi, (u8*)&rssi_rid + 2, 512); /* Skip RID length member */ } else { if (ai->rssi) { @@ -5351,7 +5361,7 @@ (int)BSSList_rid.bssid[5], (int)BSSList_rid.ssidLen, BSSList_rid.ssid, - (int)BSSList_rid.rssi); + (int)BSSList_rid.dBm); ptr += sprintf(ptr, " channel = %d %s %s %s %s\n", (int)BSSList_rid.dsChannel, BSSList_rid.cap & CAP_ESS ? "ESS" : "", @@ -5596,6 +5606,29 @@ * would not work at all... - Jean II */ +static u8 airo_rssi_to_dbm (tdsRssiEntry *rssi_rid, u8 rssi) +{ + if( !rssi_rid ) + return 0; + + return (0x100 - rssi_rid[rssi].rssidBm); +} + +static u8 airo_dbm_to_pct (tdsRssiEntry *rssi_rid, u8 dbm) +{ + int i; + + if( !rssi_rid ) + return 0; + + for( i = 0; i < 256; i++ ) + if (rssi_rid[i].rssidBm == dbm) + return rssi_rid[i].rssipct; + + return 0; +} + + static int airo_get_quality (StatusRid *status_rid, CapabilityRid *cap_rid) { int quality = 0; @@ -6446,11 +6479,29 @@ } range->num_frequency = k; + range->sensitivity = 65535; + /* Hum... Should put the right values there */ - range->max_qual.qual = airo_get_max_quality(&cap_rid); - range->max_qual.level = 0x100 - 120; /* -120 dBm */ + if (local->rssi) + range->max_qual.qual = 100; /* % */ + else + range->max_qual.qual = airo_get_max_quality(&cap_rid); + range->max_qual.level = 0; /* 0 means we use dBm */ range->max_qual.noise = 0; - range->sensitivity = 65535; + range->max_qual.updated = 0; + + /* Experimental measurements - boundary 11/5.5 Mb/s */ + /* Note : with or without the (local->rssi), results + * are somewhat different. - Jean II */ + if (local->rssi) { + range->avg_qual.qual = 50; /* % */ + range->avg_qual.level = 186; /* -70 dBm */ + } else { + range->avg_qual.qual = airo_get_avg_quality(&cap_rid); + range->avg_qual.level = 176; /* -80 dBm */ + } + range->avg_qual.noise = 0; + range->avg_qual.updated = 0; for(i = 0 ; i < 8 ; i++) { range->bitrate[i] = cap_rid.supportedRates[i] * 500000; @@ -6511,15 +6562,6 @@ range->max_retry = 65535; range->min_r_time = 1024; range->max_r_time = 65535 * 1024; - /* Experimental measurements - boundary 11/5.5 Mb/s */ - /* Note : with or without the (local->rssi), results - * are somewhat different. - Jean II */ - range->avg_qual.qual = airo_get_avg_quality(&cap_rid); - if (local->rssi) - range->avg_qual.level = 186; /* -70 dBm */ - else - range->avg_qual.level = 176; /* -80 dBm */ - range->avg_qual.noise = 0; /* Event capability (kernel + driver) */ range->event_capa[0] = (IW_EVENT_CAPA_K_0 | @@ -6679,12 +6721,18 @@ loseSync = 0; memcpy(address[i].sa_data, BSSList.bssid, ETH_ALEN); address[i].sa_family = ARPHRD_ETHER; - if (local->rssi) - qual[i].level = 0x100 - local->rssi[BSSList.rssi].rssidBm; - else - qual[i].level = (BSSList.rssi + 321) / 2; - qual[i].qual = qual[i].noise = 0; - qual[i].updated = 2; + if (local->rssi) { + qual[i].level = 0x100 - BSSList.dBm; + qual[i].qual = airo_dbm_to_pct( local->rssi, BSSList.dBm ); + qual[i].updated = IW_QUAL_QUAL_UPDATED; + } else { + qual[i].level = (BSSList.dBm + 321) / 2; + qual[i].qual = 0; + qual[i].updated = IW_QUAL_QUAL_INVALID; + } + qual[i].noise = local->wstats.qual.noise; + qual[i].updated |= IW_QUAL_LEVEL_UPDATED + | IW_QUAL_NOISE_UPDATED; if (BSSList.index == 0xffff) break; } @@ -6763,7 +6811,7 @@ static inline char *airo_translate_scan(struct net_device *dev, char *current_ev, char *end_buf, - BSSListRid *list) + BSSListRid *bss) { struct airo_info *ai = dev->priv; struct iw_event iwe; /* Temporary buffer */ @@ -6774,22 +6822,22 @@ /* First entry *MUST* be the AP MAC address */ iwe.cmd = SIOCGIWAP; iwe.u.ap_addr.sa_family = ARPHRD_ETHER; - memcpy(iwe.u.ap_addr.sa_data, list->bssid, ETH_ALEN); + memcpy(iwe.u.ap_addr.sa_data, bss->bssid, ETH_ALEN); current_ev = iwe_stream_add_event(current_ev, end_buf, &iwe, IW_EV_ADDR_LEN); /* Other entries will be displayed in the order we give them */ /* Add the ESSID */ - iwe.u.data.length = list->ssidLen; + iwe.u.data.length = bss->ssidLen; if(iwe.u.data.length > 32) iwe.u.data.length = 32; iwe.cmd = SIOCGIWESSID; iwe.u.data.flags = 1; - current_ev = iwe_stream_add_point(current_ev, end_buf, &iwe, list->ssid); + current_ev = iwe_stream_add_point(current_ev, end_buf, &iwe, bss->ssid); /* Add mode */ iwe.cmd = SIOCGIWMODE; - capabilities = le16_to_cpu(list->cap); + capabilities = le16_to_cpu(bss->cap); if(capabilities & (CAP_ESS | CAP_IBSS)) { if(capabilities & CAP_ESS) iwe.u.mode = IW_MODE_MASTER; @@ -6800,19 +6848,25 @@ /* Add frequency */ iwe.cmd = SIOCGIWFREQ; - iwe.u.freq.m = le16_to_cpu(list->dsChannel); + iwe.u.freq.m = le16_to_cpu(bss->dsChannel); iwe.u.freq.m = frequency_list[iwe.u.freq.m] * 100000; iwe.u.freq.e = 1; current_ev = iwe_stream_add_event(current_ev, end_buf, &iwe, IW_EV_FREQ_LEN); /* Add quality statistics */ iwe.cmd = IWEVQUAL; - if (ai->rssi) - iwe.u.qual.level = 0x100 - ai->rssi[list->rssi].rssidBm; - else - iwe.u.qual.level = (list->rssi + 321) / 2; - iwe.u.qual.noise = 0; - iwe.u.qual.qual = 0; + if (ai->rssi) { + iwe.u.qual.level = 0x100 - bss->dBm; + iwe.u.qual.qual = airo_dbm_to_pct( ai->rssi, bss->dBm ); + iwe.u.qual.updated = IW_QUAL_QUAL_UPDATED; + } else { + iwe.u.qual.level = (bss->dBm + 321) / 2; + iwe.u.qual.qual = 0; + iwe.u.qual.updated = IW_QUAL_QUAL_INVALID; + } + iwe.u.qual.noise = ai->wstats.qual.noise; + iwe.u.qual.updated |= IW_QUAL_LEVEL_UPDATED + | IW_QUAL_NOISE_UPDATED; current_ev = iwe_stream_add_event(current_ev, end_buf, &iwe, IW_EV_QUAL_LEN); /* Add encryption capability */ @@ -6822,7 +6876,7 @@ else iwe.u.data.flags = IW_ENCODE_DISABLED; iwe.u.data.length = 0; - current_ev = iwe_stream_add_point(current_ev, end_buf, &iwe, list->ssid); + current_ev = iwe_stream_add_point(current_ev, end_buf, &iwe, bss->ssid); /* Rate : stuffing multiple values in a single event require a bit * more of magic - Jean II */ @@ -6834,10 +6888,10 @@ /* Max 8 values */ for(i = 0 ; i < 8 ; i++) { /* NULL terminated */ - if(list->rates[i] == 0) + if(bss->rates[i] == 0) break; /* Bit rate given in 500 kb/s units (+ 0x80) */ - iwe.u.bitrate.value = ((list->rates[i] & 0x7f) * 500000); + iwe.u.bitrate.value = ((bss->rates[i] & 0x7f) * 500000); /* Add new value to event */ current_val = iwe_stream_add_value(current_ev, current_val, end_buf, &iwe, IW_EV_PARAM_LEN); } @@ -7156,18 +7210,22 @@ /* The status */ local->wstats.status = status_rid.mode; - /* Signal quality and co. But where is the noise level ??? */ - local->wstats.qual.qual = airo_get_quality(&status_rid, &cap_rid); - if (local->rssi) - local->wstats.qual.level = 0x100 - local->rssi[status_rid.sigQuality].rssidBm; - else + /* Signal quality and co */ + if (local->rssi) { + local->wstats.qual.level = airo_rssi_to_dbm( local->rssi, status_rid.sigQuality ); + /* normalizedSignalStrength appears to be a percentage */ + local->wstats.qual.qual = status_rid.normalizedSignalStrength; + } else { local->wstats.qual.level = (status_rid.normalizedSignalStrength + 321) / 2; + local->wstats.qual.qual = airo_get_quality(&status_rid, &cap_rid); + } + local->wstats.qual.updated = IW_QUAL_QUAL_UPDATED | IW_QUAL_LEVEL_UPDATED; if (status_rid.len >= 124) { - local->wstats.qual.noise = 256 - status_rid.noisedBm; - local->wstats.qual.updated = 7; + local->wstats.qual.noise = 0x100 - status_rid.noisedBm; + local->wstats.qual.updated |= IW_QUAL_NOISE_UPDATED; } else { local->wstats.qual.noise = 0; - local->wstats.qual.updated = 3; + local->wstats.qual.updated |= IW_QUAL_NOISE_INVALID; } /* Packets discarded in the wireless adapter due to wireless From galak@freescale.com Thu Mar 3 23:55:15 2005 Received: with ECARTIS (v1.0.0; list netdev); Thu, 03 Mar 2005 23:55:20 -0800 (PST) Received: from az33egw02.freescale.net (az33egw02.freescale.net [192.88.158.103]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j247tFbK016874 for ; Thu, 3 Mar 2005 23:55:15 -0800 Received: from az33smr02.freescale.net (az33smr02.freescale.net [10.64.34.200]) by az33egw02.freescale.net (8.12.11/az33egw02) with ESMTP id j247uM8r025953; Fri, 4 Mar 2005 00:56:22 -0700 (MST) Received: from postal.somerset.sps.mot.com ([163.12.132.5]) by az33smr02.freescale.net (8.13.1/8.13.0) with ESMTP id j247uGBG017221; Fri, 4 Mar 2005 01:56:17 -0600 (CST) Received: from blarg.somerset.sps.mot.com (blarg.somerset.sps.mot.com [163.12.112.65]) by postal.somerset.sps.mot.com (8.11.0/8.11.0) with ESMTP id j247tDi15932; Fri, 4 Mar 2005 01:55:13 -0600 (CST) Received: from blarg.somerset.sps.mot.com (localhost.localdomain [127.0.0.1]) by blarg.somerset.sps.mot.com (8.12.11/8.11.0) with ESMTP id j247tCqm016135; Fri, 4 Mar 2005 01:55:12 -0600 Received: from localhost (galak@localhost) by blarg.somerset.sps.mot.com (8.12.11/8.12.11/Submit) with ESMTP id j247tB5G016132; Fri, 4 Mar 2005 01:55:12 -0600 X-Authentication-Warning: blarg.somerset.sps.mot.com: galak owned process doing -bs Date: Fri, 4 Mar 2005 01:55:11 -0600 (CST) From: Kumar Gala X-X-Sender: galak@blarg.somerset.sps.mot.com To: jgarzik@pobox.com cc: linuxppc-embedded@ozlabs.org, netdev@oss.sgi.com Subject: [PATCH] gianfar: Update Marvell PHY name Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Virus-Scanned: ClamAV 0.83/743/Wed Mar 2 16:02:05 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 2377 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: galak@freescale.com Precedence: bulk X-list: netdev Content-Length: 641 Lines: 20 Jeff, This patch updates the name identifier to list both of the Marvell PHYs that are supported. Signed-off-by: Kumar Gala --- diff -Nru a/drivers/net/gianfar_phy.c b/drivers/net/gianfar_phy.c --- a/drivers/net/gianfar_phy.c 2005-03-02 14:20:27 -06:00 +++ b/drivers/net/gianfar_phy.c 2005-03-02 14:20:27 -06:00 @@ -572,7 +572,7 @@ static struct phy_info phy_info_marvell = { .phy_id = 0x01410c00, .phy_id_mask = 0xffffff00, - .name = "Marvell 88E1101", + .name = "Marvell 88E1101/88E1111", .features = MII_GBIT_FEATURES, .config_aneg = &marvell_config_aneg, .read_status = &marvell_read_status, From herbert@gondor.apana.org.au Fri Mar 4 00:32:40 2005 Received: with ECARTIS (v1.0.0; list netdev); Fri, 04 Mar 2005 00:32:48 -0800 (PST) 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 j248WdSd022489 for ; Fri, 4 Mar 2005 00:32:40 -0800 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 1D78E5-0002AS-00; Fri, 04 Mar 2005 19:32:01 +1100 Received: from herbert by gondolin.me.apana.org.au with local (Exim 3.36 #1 (Debian)) id 1D78DN-0002te-00; Fri, 04 Mar 2005 19:31:17 +1100 From: Herbert Xu To: tgraf@suug.ch (Thomas Graf) Subject: Re: [PATCH] [NET]: Fix deletion of local addresses only varying in prefix length Cc: davem@davemloft.net, netdev@oss.sgi.com Organization: Core In-Reply-To: <20050304012003.GA31837@postel.suug.ch> X-Newsgroups: apana.lists.os.linux.netdev User-Agent: tin/1.7.4-20040225 ("Benbecula") (UNIX) (Linux/2.4.27-hx-1-686-smp (i686)) Message-Id: Date: Fri, 04 Mar 2005 19:31:17 +1100 X-Virus-Scanned: ClamAV 0.83/743/Wed Mar 2 16:02:05 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 2378 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: herbert@gondor.apana.org.au Precedence: bulk X-list: netdev Content-Length: 1012 Lines: 28 Thomas Graf wrote: > The deletion of local addresses via netlink doesn't take the > prefix length into account resulting in the deletion of > the address that was added first given multiple addresses > exist only varying in the prefix length. This has the potential of breaking user-space scripts. For example, this won't work anymore: ip a a dev eth0 192.168.0.1/24 ip a d dev eth0 192.168.0.1 > tgr:axs ~ ip -4 addr show dev lo > 1: lo: mtu 16436 qdisc noqueue > inet 127.0.0.1/8 scope host lo > inet 1.1.1.1/1 scope global lo > inet 1.1.1.1/2 scope global lo Do we really need to handle this case? If we do then would it be better to consider ifa_prefixlen only when there are multiple addresses present which match but differ by prefix length? Cheers, -- Visit Openswan at http://www.openswan.org/ Email: Herbert Xu ~{PmV>HI~} Home Page: http://gondor.apana.org.au/~herbert/ PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt From baruch@ev-en.org Fri Mar 4 00:47:50 2005 Received: with ECARTIS (v1.0.0; list netdev); Fri, 04 Mar 2005 00:47:55 -0800 (PST) Received: from galon.ev-en.org (rrcs-24-123-59-149.central.biz.rr.com [24.123.59.149]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j248lmOL023595 for ; Fri, 4 Mar 2005 00:47:49 -0800 Received: by galon.ev-en.org (Postfix, from userid 105) id CC25711A697; Fri, 4 Mar 2005 10:47:40 +0200 (IST) Received: from [10.220.3.66] (hamilton.nuim.ie [149.157.192.252]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by galon.ev-en.org (Postfix) with ESMTP id F41D111A5E3; Fri, 4 Mar 2005 10:47:25 +0200 (IST) Message-ID: <42282098.8010506@ev-en.org> Date: Fri, 04 Mar 2005 08:47:20 +0000 From: Baruch Even User-Agent: Debian Thunderbird 1.0 (X11/20050116) X-Accept-Language: en-us, en MIME-Version: 1.0 To: hadi@cyberus.ca Cc: Stephen Hemminger , John Heffner , "David S. Miller" , rhee@eos.ncsu.edu, Yee-Ting.Li@nuim.ie, netdev@oss.sgi.com Subject: Re: netif_rx packet dumping References: <20050303123811.4d934249@dxpl.pdx.osdl.net> <20050303125556.6850cfe5.davem@davemloft.net> <1109884688.1090.282.camel@jzny.localdomain> <20050303132143.7eef517c@dxpl.pdx.osdl.net> <1109885065.1098.285.camel@jzny.localdomain> <20050303133237.5d64578f.davem@davemloft.net> <20050303135416.0d6e7708@dxpl.pdx.osdl.net> <1109888811.1092.352.camel@jzny.localdomain> <20050303151606.3587394f@dxpl.pdx.osdl.net> <4227A23C.5050300@ev-en.org> <1109907956.1092.476.camel@jzny.localdomain> In-Reply-To: <1109907956.1092.476.camel@jzny.localdomain> X-Enigmail-Version: 0.90.0.0 X-Enigmail-Supports: pgp-inline, pgp-mime Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV 0.83/743/Wed Mar 2 16:02:05 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 2379 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: baruch@ev-en.org Precedence: bulk X-list: netdev Content-Length: 2026 Lines: 46 jamal wrote: > On Thu, 2005-03-03 at 18:48, Baruch Even wrote: > > >>The queue is there to handle short bursts of packets when the network >>stack cannot handle it. The bad behaviour was the throttling of the >>queue, > > > Can you explain a little more? Why does the the throttling cause any > bad behavior thats any different from the queue being full? In both > cases, packets arriving during that transient will be dropped. If you have 300 packets in the queue and the throttling kicks in you now drop ALL packets until the queue is empty, this will normally take some time, during all of this time you are dropping all the ACKs that are coming in, you lose SACK information and potentially you leave no packet in flight so that the next packet will be sent only due to retransmit timer waking up, at which point your congestion control algorithm starts from cwnd=1. You can look at the report http://hamilton.ie/net/LinuxHighSpeed.pdf for some graphs of the effects. >>the smart schemes are not going to make it that much better if >>the hardware/software can't keep up. > > consider that this queue could be shared by as many as a few thousand > unrelated TCP flows - not just one. It is also used for packets being > forwarded. If you factor that the system has to react to protect itself > then these schemes may make sense. The best place to do it is really in > hardware, but the closer to the hardware as possible is the next besr > possible spot. Actually the problem we had was with TCP end-system performance problems, compared to them the router problem is more limited since it only needs to do a lookup on a hash, tree or whatever and not a linked list of several thousand packets. I'd prefer avoiding an AFQ scheme in the incoming queue, if you do add one, please make it configurable so I can disable it. The drop-tail behaviour is good enough for me. Remember that an AFQ needs to drop packets long before the queue is full so there will likely be more losses involved. Baruch From akpm@osdl.org Fri Mar 4 04:37:50 2005 Received: with ECARTIS (v1.0.0; list netdev); Fri, 04 Mar 2005 04:37:57 -0800 (PST) Received: from smtp.osdl.org (fire.osdl.org [65.172.181.4]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j24Cbn8P011939 for ; Fri, 4 Mar 2005 04:37:50 -0800 Received: from shell0.pdx.osdl.net (fw.osdl.org [65.172.181.6]) by smtp.osdl.org (8.12.8/8.12.8) with ESMTP id j24Cbcqi022204 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO); Fri, 4 Mar 2005 04:37:42 -0800 Received: from localhost.localdomain (shell0.pdx.osdl.net [10.9.0.31]) by shell0.pdx.osdl.net (8.13.1/8.11.6) with ESMTP id j24Cbb69026470; Fri, 4 Mar 2005 04:37:37 -0800 Message-Id: <200503041237.j24Cbb69026470@shell0.pdx.osdl.net> Subject: [patch 1/3] fix buggy IEEE80211_CRYPT_* selects To: davem@davemloft.net Cc: jgarzik@pobox.com, netdev@oss.sgi.com, akpm@osdl.org, bunk@stusta.de From: akpm@osdl.org Date: Fri, 04 Mar 2005 04:37:16 -0800 Received-SPF: pass (domain of akpm@osdl.org designates 65.172.181.6 as permitted sender) X-MIMEDefang-Filter: osdl$Revision: 1.104 $ X-Scanned-By: MIMEDefang 2.36 X-Virus-Scanned: ClamAV 0.83/745/Fri Mar 4 03:16:06 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 2380 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: akpm@osdl.org Precedence: bulk X-list: netdev Content-Length: 2831 Lines: 74 From: Adrian Bunk Some of the options that needlessly wrote in their help text which options they do select (patch already sent) didn't obey the most important rule of select If you select something, you have to ensure that the dependencies of what you do select are fulfilled. resulting in the following compile error: <-- snip --> ... LD .tmp_vmlinux1 crypto/built-in.o(.init.text+0x31b): In function `aes_init': : undefined reference to `crypto_register_alg' crypto/built-in.o(.init.text+0x326): In function `michael_mic_init': : undefined reference to `crypto_register_alg' crypto/built-in.o(.exit.text+0x6): In function `aes_fini': : undefined reference to `crypto_unregister_alg' crypto/built-in.o(.exit.text+0x16): In function `michael_mic_exit': : undefined reference to `crypto_unregister_alg' net/built-in.o(.text+0x5ba52): In function `ieee80211_ccmp_init': : undefined reference to `crypto_alloc_tfm' net/built-in.o(.text+0x5ba94): In function `ieee80211_ccmp_init': : undefined reference to `crypto_free_tfm' net/built-in.o(.text+0x5bab7): In function `ieee80211_ccmp_deinit': : undefined reference to `crypto_free_tfm' net/built-in.o(.text+0x5c5c2): In function `ieee80211_tkip_init': : undefined reference to `crypto_alloc_tfm' net/built-in.o(.text+0x5c5d5): In function `ieee80211_tkip_init': : undefined reference to `crypto_alloc_tfm' net/built-in.o(.text+0x5c623): In function `ieee80211_tkip_init': : undefined reference to `crypto_free_tfm' net/built-in.o(.text+0x5c62a): In function `ieee80211_tkip_init': : undefined reference to `crypto_free_tfm' net/built-in.o(.text+0x5c65e): In function `ieee80211_tkip_deinit': : undefined reference to `crypto_free_tfm' net/built-in.o(.text+0x5c665): In function `ieee80211_tkip_deinit': : undefined reference to `crypto_free_tfm' make: *** [.tmp_vmlinux1] Error 1 <-- snip --> This patch adds the missing selects of CRYPTO. Signed-off-by: Andrew Morton --- 25-akpm/net/ieee80211/Kconfig | 2 ++ 1 files changed, 2 insertions(+) diff -puN net/ieee80211/Kconfig~fix-buggy-ieee80211_crypt_-selects net/ieee80211/Kconfig --- 25/net/ieee80211/Kconfig~fix-buggy-ieee80211_crypt_-selects 2005-02-28 14:49:54.000000000 -0800 +++ 25-akpm/net/ieee80211/Kconfig 2005-02-28 14:49:54.000000000 -0800 @@ -44,6 +44,7 @@ config IEEE80211_CRYPT_WEP config IEEE80211_CRYPT_CCMP tristate "IEEE 802.11i CCMP support" depends on IEEE80211 + select CRYPTO select CRYPTO_AES ---help--- Include software based cipher suites in support of IEEE 802.11i @@ -56,6 +57,7 @@ config IEEE80211_CRYPT_CCMP config IEEE80211_CRYPT_TKIP tristate "IEEE 802.11i TKIP encryption" depends on IEEE80211 + select CRYPTO select CRYPTO_MICHAEL_MIC ---help--- Include software based cipher suites in support of IEEE 802.11i _ From akpm@osdl.org Fri Mar 4 04:37:54 2005 Received: with ECARTIS (v1.0.0; list netdev); Fri, 04 Mar 2005 04:38:01 -0800 (PST) Received: from smtp.osdl.org (fire.osdl.org [65.172.181.4]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j24Cbsaw011947 for ; Fri, 4 Mar 2005 04:37:54 -0800 Received: from shell0.pdx.osdl.net (fw.osdl.org [65.172.181.6]) by smtp.osdl.org (8.12.8/8.12.8) with ESMTP id j24Cbeqi022210 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO); Fri, 4 Mar 2005 04:37:42 -0800 Received: from localhost.localdomain (shell0.pdx.osdl.net [10.9.0.31]) by shell0.pdx.osdl.net (8.13.1/8.11.6) with ESMTP id j24Cbdbm026482; Fri, 4 Mar 2005 04:37:39 -0800 Message-Id: <200503041237.j24Cbdbm026482@shell0.pdx.osdl.net> Subject: [patch 3/3] x25_create initializing socket data twice To: davem@davemloft.net Cc: jgarzik@pobox.com, netdev@oss.sgi.com, akpm@osdl.org, herbert@13thfloor.at From: akpm@osdl.org Date: Fri, 04 Mar 2005 04:37:19 -0800 Received-SPF: pass (domain of akpm@osdl.org designates 65.172.181.6 as permitted sender) X-MIMEDefang-Filter: osdl$Revision: 1.104 $ X-Scanned-By: MIMEDefang 2.36 X-Virus-Scanned: ClamAV 0.83/745/Fri Mar 4 03:16:06 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 2381 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: akpm@osdl.org Precedence: bulk X-list: netdev Content-Length: 1000 Lines: 31 From: Herbert Poetzl x25_create() [net/x25/af_x25.c] is calling sock_init_data() twice ... once indirectly via x25_alloc_socket() and a second time directly via sock_init_data(sock, sk); while this might not look as critical as it seems, it can easily break stuff which assumes that sock_init_data() isn't called twice on the same socket. Signed-off-by: Andrew Morton --- /dev/null | 0 25-akpm/net/x25/af_x25.c | 1 - 2 files changed, 1 deletion(-) diff -puN net/x25/af_x25.c~x25_create-initializing-socket-data-twice net/x25/af_x25.c --- 25/net/x25/af_x25.c~x25_create-initializing-socket-data-twice 2005-03-02 19:22:48.000000000 -0800 +++ 25-akpm/net/x25/af_x25.c 2005-03-02 19:22:48.000000000 -0800 @@ -490,7 +490,6 @@ static int x25_create(struct socket *soc x25 = x25_sk(sk); - sock_init_data(sock, sk); sk_set_owner(sk, THIS_MODULE); x25_init_timers(sk); diff -L net/x25/af_x25.c.orig -puN /dev/null /dev/null _ From akpm@osdl.org Fri Mar 4 04:38:03 2005 Received: with ECARTIS (v1.0.0; list netdev); Fri, 04 Mar 2005 04:38:10 -0800 (PST) Received: from smtp.osdl.org (fire.osdl.org [65.172.181.4]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j24Cc3CM011971 for ; Fri, 4 Mar 2005 04:38:03 -0800 Received: from shell0.pdx.osdl.net (fw.osdl.org [65.172.181.6]) by smtp.osdl.org (8.12.8/8.12.8) with ESMTP id j24Cbdqi022206 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO); Fri, 4 Mar 2005 04:37:45 -0800 Received: from localhost.localdomain (shell0.pdx.osdl.net [10.9.0.31]) by shell0.pdx.osdl.net (8.13.1/8.11.6) with ESMTP id j24CbcGP026476; Fri, 4 Mar 2005 04:37:38 -0800 Message-Id: <200503041237.j24CbcGP026476@shell0.pdx.osdl.net> Subject: [patch 2/3] ENI155P error handling fix To: davem@davemloft.net Cc: jgarzik@pobox.com, netdev@oss.sgi.com, akpm@osdl.org, takis@lumumba.luc.ac.be From: akpm@osdl.org Date: Fri, 04 Mar 2005 04:37:17 -0800 Received-SPF: pass (domain of akpm@osdl.org designates 65.172.181.6 as permitted sender) X-MIMEDefang-Filter: osdl$Revision: 1.104 $ X-Scanned-By: MIMEDefang 2.36 X-Virus-Scanned: ClamAV 0.83/745/Fri Mar 4 03:16:06 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 2382 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: akpm@osdl.org Precedence: bulk X-list: netdev Content-Length: 2894 Lines: 94 From: Panagiotis Issaris In the ENI155P device driver in six possible failure cases the requested irq is not being released. In three of the above possible failure cases additionally there seems to be a memory leak. Signed-off-by: Andrew Morton --- 25-akpm/drivers/atm/eni.c | 27 ++++++++++++++++++--------- 1 files changed, 18 insertions(+), 9 deletions(-) diff -puN drivers/atm/eni.c~eni155p-error-handling-fix drivers/atm/eni.c --- 25/drivers/atm/eni.c~eni155p-error-handling-fix Wed Mar 2 15:16:35 2005 +++ 25-akpm/drivers/atm/eni.c Wed Mar 2 15:16:36 2005 @@ -59,7 +59,6 @@ * - doesn't support OAM cells * - eni_put_free may hang if not putting memory fragments that _complete_ * 2^n block (never happens in real life, though) - * - keeps IRQ even if initialization fails */ @@ -1802,22 +1801,22 @@ static int __devinit eni_start(struct at if (request_irq(eni_dev->irq,&eni_int,SA_SHIRQ,DEV_LABEL,dev)) { printk(KERN_ERR DEV_LABEL "(itf %d): IRQ%d is already in use\n", dev->number,eni_dev->irq); - return -EAGAIN; + error = -EAGAIN; + goto out; } - /* @@@ should release IRQ on error */ pci_set_master(eni_dev->pci_dev); if ((error = pci_write_config_word(eni_dev->pci_dev,PCI_COMMAND, PCI_COMMAND_MEMORY | PCI_COMMAND_MASTER | (eni_dev->asic ? PCI_COMMAND_PARITY | PCI_COMMAND_SERR : 0)))) { printk(KERN_ERR DEV_LABEL "(itf %d): can't enable memory+" "master (0x%02x)\n",dev->number,error); - return error; + goto free_irq; } if ((error = pci_write_config_byte(eni_dev->pci_dev,PCI_TONGA_CTRL, END_SWAP_DMA))) { printk(KERN_ERR DEV_LABEL "(itf %d): can't set endian swap " "(0x%02x)\n",dev->number,error); - return error; + goto free_irq; } /* determine addresses of internal tables */ eni_dev->vci = eni_dev->ram; @@ -1839,7 +1838,8 @@ static int __devinit eni_start(struct at if (!eni_dev->free_list) { printk(KERN_ERR DEV_LABEL "(itf %d): couldn't get free page\n", dev->number); - return -ENOMEM; + error = -ENOMEM; + goto free_irq; } eni_dev->free_len = 0; eni_put_free(eni_dev,buf,buffer_mem); @@ -1855,17 +1855,26 @@ static int __devinit eni_start(struct at */ eni_out(0xffffffff,MID_IE); error = start_tx(dev); - if (error) return error; + if (error) goto free_list; error = start_rx(dev); - if (error) return error; + if (error) goto free_list; error = dev->phy->start(dev); - if (error) return error; + if (error) goto free_list; eni_out(eni_in(MID_MC_S) | (1 << MID_INT_SEL_SHIFT) | MID_TX_LOCK_MODE | MID_DMA_ENABLE | MID_TX_ENABLE | MID_RX_ENABLE, MID_MC_S); /* Tonga uses SBus INTReq1 */ (void) eni_in(MID_ISA); /* clear Midway interrupts */ return 0; + +free_list: + kfree(eni_dev->free_list); + +free_irq: + free_irq(eni_dev->irq, eni_dev); + +out: + return error; } _ From tgraf@suug.ch Fri Mar 4 05:14:00 2005 Received: with ECARTIS (v1.0.0; list netdev); Fri, 04 Mar 2005 05:14:06 -0800 (PST) Received: from b.mx.projectdream.org (eth0-0.arisu.projectdream.org [194.158.4.191]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j24DDxtY015080 for ; Fri, 4 Mar 2005 05:14:00 -0800 Received: from postel.suug.ch (postel.suug.ch [195.134.158.23]) (using TLSv1 with cipher EDH-RSA-DES-CBC3-SHA (168/168 bits)) (No client certificate requested) by b.mx.projectdream.org (Postfix) with ESMTP id C67FA82; Fri, 4 Mar 2005 14:13:36 +0100 (CET) Received: by postel.suug.ch (Postfix, from userid 10001) id 980891C0EA; Fri, 4 Mar 2005 14:14:19 +0100 (CET) Date: Fri, 4 Mar 2005 14:14:19 +0100 From: Thomas Graf To: Herbert Xu Cc: davem@davemloft.net, netdev@oss.sgi.com Subject: Re: [PATCH] [NET]: Fix deletion of local addresses only varying in prefix length Message-ID: <20050304131419.GE31837@postel.suug.ch> References: <20050304012003.GA31837@postel.suug.ch> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-Virus-Scanned: ClamAV 0.83/745/Fri Mar 4 03:16:06 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 2383 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: tgraf@suug.ch Precedence: bulk X-list: netdev Content-Length: 1966 Lines: 48 * Herbert Xu 2005-03-04 19:31 > Thomas Graf wrote: > > The deletion of local addresses via netlink doesn't take the > > prefix length into account resulting in the deletion of > > the address that was added first given multiple addresses > > exist only varying in the prefix length. > > This has the potential of breaking user-space scripts. For example, > this won't work anymore: > > ip a a dev eth0 192.168.0.1/24 > ip a d dev eth0 192.168.0.1 Yes I know. > > > tgr:axs ~ ip -4 addr show dev lo > > 1: lo: mtu 16436 qdisc noqueue > > inet 127.0.0.1/8 scope host lo > > inet 1.1.1.1/1 scope global lo > > inet 1.1.1.1/2 scope global lo > > Do we really need to handle this case? If we do then would it be better > to consider ifa_prefixlen only when there are multiple addresses present > which match but differ by prefix length? I do not agree but I might have a better idea. Let's change iproute2 to provide a prefixlength of 0 if no prefix was specified and only compare the prefixes if it is non zero. This allows for accurate deletion, no scripts will break (except for really really broken ones). Given there are multiple matching addresses only varying in prefix length and no prefix was specified the first one will get deleted but this is well defined. --- linux-2.6.11.orig/net/ipv4/devinet.c 2005-03-04 14:08:14.000000000 +0100 +++ linux-2.6.11/net/ipv4/devinet.c 2005-03-04 14:06:33.000000000 +0100 @@ -396,8 +396,10 @@ for (ifap = &in_dev->ifa_list; (ifa = *ifap) != NULL; ifap = &ifa->ifa_next) { if ((rta[IFA_LOCAL - 1] && + ((ifm->ifa_prefixlen && + ifm->ifa_prefixlen != ifa->ifa_prefixlen) || memcmp(RTA_DATA(rta[IFA_LOCAL - 1]), - &ifa->ifa_local, 4)) || + &ifa->ifa_local, 4))) || (rta[IFA_LABEL - 1] && rtattr_strcmp(rta[IFA_LABEL - 1], ifa->ifa_label)) || (rta[IFA_ADDRESS - 1] && From tgraf@suug.ch Fri Mar 4 05:26:36 2005 Received: with ECARTIS (v1.0.0; list netdev); Fri, 04 Mar 2005 05:26:42 -0800 (PST) Received: from b.mx.projectdream.org (eth0-0.arisu.projectdream.org [194.158.4.191]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j24DQZVU016024 for ; Fri, 4 Mar 2005 05:26:35 -0800 Received: from postel.suug.ch (postel.suug.ch [195.134.158.23]) (using TLSv1 with cipher EDH-RSA-DES-CBC3-SHA (168/168 bits)) (No client certificate requested) by b.mx.projectdream.org (Postfix) with ESMTP id 867FB82; Fri, 4 Mar 2005 14:26:11 +0100 (CET) Received: by postel.suug.ch (Postfix, from userid 10001) id 982731C0EA; Fri, 4 Mar 2005 14:26:53 +0100 (CET) Date: Fri, 4 Mar 2005 14:26:53 +0100 From: Thomas Graf To: jamal Cc: Stephen Hemminger , netdev@oss.sgi.com Subject: Re: [PATCH] iproute2 updates Message-ID: <20050304132653.GF31837@postel.suug.ch> References: <20050304023520.GD31837@postel.suug.ch> <1109908154.1091.486.camel@jzny.localdomain> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1109908154.1091.486.camel@jzny.localdomain> X-Virus-Scanned: ClamAV 0.83/745/Fri Mar 4 03:16:06 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 2384 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: tgraf@suug.ch Precedence: bulk X-list: netdev Content-Length: 1255 Lines: 26 * jamal <1109908154.1091.486.camel@jzny.localdomain> 2005-03-03 22:49 > On Thu, 2005-03-03 at 21:35, Thomas Graf wrote: > > Stephen, > > > > You may pull the following changes from bk://tgr.bkbits.net/iproute2-tgr-fix > > Other than NPROBES change, shouldnt the other changes be reflective of > whats in the kernel? This is the cost of keeping private headers. My > suggestions would be to let Steve on every major release to just sync > the header files. Well, these are not exact copies, all the __KERNEL__ stuff is missing, a few CONFIG ifdefs must be cut out and a few extra bits such as u32 mark structures. I updated them because some of the structures were outdated. I do not care how it is done but it required an update. > PS:- Also on you 1/2 changes - I notice one bug fix, the rest seems > cosmetic - what does that buy you? Does it make the code more readable > etc? Yes, it improves readability a lot, I first thought the neighbour code had a bug until I read the code bit by bit from the top and there was quite some logic in it that one wouldn't expect such as parallel code paths for errors and normal execution. I replacted the rta_len checks with RTA_PAYLOAD and adapted the logic to be like the rest of the rtnetlink handle code. From tgraf@suug.ch Fri Mar 4 05:30:23 2005 Received: with ECARTIS (v1.0.0; list netdev); Fri, 04 Mar 2005 05:30:29 -0800 (PST) Received: from b.mx.projectdream.org (eth0-0.arisu.projectdream.org [194.158.4.191]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j24DUMOp016668 for ; Fri, 4 Mar 2005 05:30:23 -0800 Received: from postel.suug.ch (postel.suug.ch [195.134.158.23]) (using TLSv1 with cipher EDH-RSA-DES-CBC3-SHA (168/168 bits)) (No client certificate requested) by b.mx.projectdream.org (Postfix) with ESMTP id E178B82; Fri, 4 Mar 2005 14:29:59 +0100 (CET) Received: by postel.suug.ch (Postfix, from userid 10001) id 1F9FC1C0EA; Fri, 4 Mar 2005 14:30:43 +0100 (CET) Date: Fri, 4 Mar 2005 14:30:42 +0100 From: Thomas Graf To: Herbert Xu Cc: davem@davemloft.net, netdev@oss.sgi.com Subject: Re: [PATCH] [NET]: Fix deletion of local addresses only varying in prefix length Message-ID: <20050304133042.GG31837@postel.suug.ch> References: <20050304012003.GA31837@postel.suug.ch> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-Virus-Scanned: ClamAV 0.83/745/Fri Mar 4 03:16:06 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 2385 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: tgraf@suug.ch Precedence: bulk X-list: netdev Content-Length: 394 Lines: 7 * Herbert Xu 2005-03-04 19:31 > Do we really need to handle this case? If we do then would it be better > to consider ifa_prefixlen only when there are multiple addresses present > which match but differ by prefix length? One argument that would speak for the original patch is that IPv6 already handles it this way so it would be more consistent. From shemminger@osdl.org Fri Mar 4 08:43:20 2005 Received: with ECARTIS (v1.0.0; list netdev); Fri, 04 Mar 2005 08:43:27 -0800 (PST) Received: from smtp.osdl.org (fire.osdl.org [65.172.181.4]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j24GhJAn027023 for ; Fri, 4 Mar 2005 08:43:20 -0800 Received: from shell0.pdx.osdl.net (fw.osdl.org [65.172.181.6]) by smtp.osdl.org (8.12.8/8.12.8) with ESMTP id j24Gggqi010468 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO); Fri, 4 Mar 2005 08:42:42 -0800 Received: from dxpl.pdx.osdl.net (dxpl.pdx.osdl.net [172.20.1.103]) by shell0.pdx.osdl.net (8.13.1/8.11.6) with ESMTP id j24GgdpE003886; Fri, 4 Mar 2005 08:42:42 -0800 Date: Fri, 4 Mar 2005 08:42:56 -0800 From: Stephen Hemminger To: Thomas Graf Cc: jamal , netdev@oss.sgi.com Subject: Re: [PATCH] iproute2 updates Message-ID: <20050304084256.03550238@dxpl.pdx.osdl.net> In-Reply-To: <20050304132653.GF31837@postel.suug.ch> References: <20050304023520.GD31837@postel.suug.ch> <1109908154.1091.486.camel@jzny.localdomain> <20050304132653.GF31837@postel.suug.ch> Organization: Open Source Development Lab X-Mailer: Sylpheed-Claws 1.0.1 (GTK+ 1.2.10; x86_64-unknown-linux-gnu) X-Face: &@E+xe?c%:&e4D{>f1O<&U>2qwRREG5!}7R4;D<"NO^UI2mJ[eEOA2*3>(`Th.yP,VDPo9$ /`~cw![cmj~~jWe?AHY7D1S+\}5brN0k*NE?pPh_'_d>6;XGG[\KDRViCfumZT3@[ Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Received-SPF: pass (domain of shemminger@osdl.org designates 65.172.181.6 as permitted sender) X-MIMEDefang-Filter: osdl$Revision: 1.104 $ X-Scanned-By: MIMEDefang 2.36 X-Virus-Scanned: ClamAV 0.83/745/Fri Mar 4 03:16:06 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 2386 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: shemminger@osdl.org Precedence: bulk X-list: netdev Content-Length: 884 Lines: 20 On Fri, 4 Mar 2005 14:26:53 +0100 Thomas Graf wrote: > * jamal <1109908154.1091.486.camel@jzny.localdomain> 2005-03-03 22:49 > > On Thu, 2005-03-03 at 21:35, Thomas Graf wrote: > > > Stephen, > > > > > > You may pull the following changes from bk://tgr.bkbits.net/iproute2-tgr-fix > > > > Other than NPROBES change, shouldnt the other changes be reflective of > > whats in the kernel? This is the cost of keeping private headers. My > > suggestions would be to let Steve on every major release to just sync > > the header files. > > Well, these are not exact copies, all the __KERNEL__ stuff is missing, a > few CONFIG ifdefs must be cut out and a few extra bits such as u32 mark > structures. I updated them because some of the structures were outdated. > I do not care how it is done but it required an update. I'll clone the 2.6.11 headers in the next update. From jgarzik@pobox.com Fri Mar 4 09:33:54 2005 Received: with ECARTIS (v1.0.0; list netdev); Fri, 04 Mar 2005 09:34:01 -0800 (PST) Received: from parcelfarce.linux.theplanet.co.uk (IDENT:93@parcelfarce.linux.theplanet.co.uk [195.92.249.252]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j24HXr4C029329 for ; Fri, 4 Mar 2005 09:33:54 -0800 Received: from [69.134.152.124] (helo=[10.10.10.88]) by parcelfarce.linux.theplanet.co.uk with asmtp (TLSv1:AES256-SHA:256) (Exim 4.33) id 1D7GgQ-0008Nd-Pi; Fri, 04 Mar 2005 17:33:51 +0000 Message-ID: <42289BDF.1080409@pobox.com> Date: Fri, 04 Mar 2005 12:33:19 -0500 From: Jeff Garzik User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.3) Gecko/20040922 X-Accept-Language: en-us, en MIME-Version: 1.0 To: akpm@osdl.org CC: davem@davemloft.net, netdev@oss.sgi.com, bunk@stusta.de Subject: Re: [patch 1/3] fix buggy IEEE80211_CRYPT_* selects References: <200503041237.j24Cbb69026470@shell0.pdx.osdl.net> In-Reply-To: <200503041237.j24Cbb69026470@shell0.pdx.osdl.net> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV 0.83/745/Fri Mar 4 03:16:06 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 2387 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: jgarzik@pobox.com Precedence: bulk X-list: netdev Content-Length: 1236 Lines: 36 akpm@osdl.org wrote: > From: Adrian Bunk > > Some of the options that needlessly wrote in their help text which options > they do select (patch already sent) didn't obey the most important rule of > select > > If you select something, you have to ensure that the dependencies > of what you do select are fulfilled. > diff -puN net/ieee80211/Kconfig~fix-buggy-ieee80211_crypt_-selects net/ieee80211/Kconfig > --- 25/net/ieee80211/Kconfig~fix-buggy-ieee80211_crypt_-selects 2005-02-28 14:49:54.000000000 -0800 > +++ 25-akpm/net/ieee80211/Kconfig 2005-02-28 14:49:54.000000000 -0800 > @@ -44,6 +44,7 @@ config IEEE80211_CRYPT_WEP > config IEEE80211_CRYPT_CCMP > tristate "IEEE 802.11i CCMP support" > depends on IEEE80211 > + select CRYPTO > select CRYPTO_AES > ---help--- > Include software based cipher suites in support of IEEE 802.11i > @@ -56,6 +57,7 @@ config IEEE80211_CRYPT_CCMP > config IEEE80211_CRYPT_TKIP > tristate "IEEE 802.11i TKIP encryption" > depends on IEEE80211 > + select CRYPTO > select CRYPTO_MICHAEL_MIC > ---help--- You are resending the old patch that is incorrect. We don't need multiple selects, CRYPTO_AES and CRYPTO_MICHAEL_MIC should pull things in. Jeff From maxk@qualcomm.com Fri Mar 4 10:05:29 2005 Received: with ECARTIS (v1.0.0; list netdev); Fri, 04 Mar 2005 10:05:36 -0800 (PST) Received: from ithilien.qualcomm.com (ithilien.qualcomm.com [129.46.51.59]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j24I5SN6031168 for ; Fri, 4 Mar 2005 10:05:29 -0800 Received: from magus.qualcomm.com (magus.qualcomm.com [129.46.61.148]) by ithilien.qualcomm.com (8.12.10/8.12.5/1.0) with ESMTP id j24I5DXO017855; Fri, 4 Mar 2005 10:05:14 -0800 (PST) Received: from [129.46.90.158] (workie.qualcomm.com [129.46.90.158]) by magus.qualcomm.com (8.12.10/8.12.5/1.0) with ESMTP id j24I58fX006018; Fri, 4 Mar 2005 10:05:09 -0800 (PST) Message-ID: <4228A354.8020904@qualcomm.com> Date: Fri, 04 Mar 2005 10:05:08 -0800 From: Max Krasnyansky User-Agent: Mozilla Thunderbird 0.9 (X11/20041127) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Stephen Hemminger CC: netdev@oss.sgi.com Subject: Re: Fw: [Bug 4279] New: When I try to start vpnc the net/core/skbuff.c:91 crash References: <20050303095832.6a084856@dxpl.pdx.osdl.net> In-Reply-To: <20050303095832.6a084856@dxpl.pdx.osdl.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-PMX-Version: 4.7.0.111621 X-Virus-Scanned: ClamAV 0.83/745/Fri Mar 4 03:16:06 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 2388 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: maxk@qualcomm.com Precedence: bulk X-list: netdev Content-Length: 233 Lines: 9 Hi Stephen, > Looks like a something wrong with tun driver on 2.6.11 Thanks for forwarding this. I'll take a look at it. As far as I remember nothing really changed in the TUN write logic. Must be some other changes broke it. Max From kaber@trash.net Fri Mar 4 10:49:03 2005 Received: with ECARTIS (v1.0.0; list netdev); Fri, 04 Mar 2005 10:49:09 -0800 (PST) Received: from kaber.coreworks.de ([62.206.217.67]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j24In2nb001079 for ; Fri, 4 Mar 2005 10:49:03 -0800 Received: from localhost ([127.0.0.1]) by kaber.coreworks.de with esmtp (Exim 4.50) id 1D7Hqy-0003rL-10; Fri, 04 Mar 2005 19:48:48 +0100 Message-ID: <4228AD8F.4020000@trash.net> Date: Fri, 04 Mar 2005 19:48:47 +0100 From: Patrick McHardy User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.7.5) Gecko/20050106 Debian/1.7.5-1 X-Accept-Language: en MIME-Version: 1.0 To: Max Krasnyansky CC: Stephen Hemminger , netdev@oss.sgi.com Subject: Re: Fw: [Bug 4279] New: When I try to start vpnc the net/core/skbuff.c:91 crash References: <20050303095832.6a084856@dxpl.pdx.osdl.net> <4228A354.8020904@qualcomm.com> In-Reply-To: <4228A354.8020904@qualcomm.com> Content-Type: multipart/mixed; boundary="------------010705000600020206010600" X-Virus-Scanned: ClamAV 0.83/745/Fri Mar 4 03:16:06 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 2389 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: kaber@trash.net Precedence: bulk X-list: netdev Content-Length: 1741 Lines: 62 This is a multi-part message in MIME format. --------------010705000600020206010600 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Max Krasnyansky wrote: > Hi Stephen, > >> Looks like a something wrong with tun driver on 2.6.11 > > Thanks for forwarding this. I'll take a look at it. > As far as I remember nothing really changed in the TUN write logic. > Must be some other changes broke it. This check is wrong, gcc optimizes it away: if ((len -= sizeof(pi)) > len) return -EINVAL; This could be responsible for the BUG. If len is 2 or 3 and TUN_NO_PI isn't set it underflows. alloc_skb() allocates len + 2, which is 0 or 1 byte. skb_reserve tries to reserve 2 bytes and things explode in skb_put. Regards Patrick --------------010705000600020206010600 Content-Type: text/plain; name="x" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="x" # This is a BitKeeper generated diff -Nru style patch. # # ChangeSet # 2005/03/04 19:41:29+01:00 kaber@coreworks.de # [TUN]: Fix check for underflow # # Signed-off-by: Patrick McHardy # # drivers/net/tun.c # 2005/03/04 19:41:20+01:00 kaber@coreworks.de +1 -1 # [TUN]: Fix check for underflow # # Signed-off-by: Patrick McHardy # diff -Nru a/drivers/net/tun.c b/drivers/net/tun.c --- a/drivers/net/tun.c 2005-03-04 19:41:56 +01:00 +++ b/drivers/net/tun.c 2005-03-04 19:41:56 +01:00 @@ -229,7 +229,7 @@ size_t len = count; if (!(tun->flags & TUN_NO_PI)) { - if ((len -= sizeof(pi)) > len) + if ((len -= sizeof(pi)) > count) return -EINVAL; if(memcpy_fromiovec((void *)&pi, iv, sizeof(pi))) --------------010705000600020206010600-- From razzor@kopf-tisch.de Fri Mar 4 11:37:06 2005 Received: with ECARTIS (v1.0.0; list netdev); Fri, 04 Mar 2005 11:37:13 -0800 (PST) Received: from mail.innovalan.de (urtyp.innovalan.de [81.2.162.90]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j24Jb5k3004913 for ; Fri, 4 Mar 2005 11:37:06 -0800 Received: by mail.innovalan.de (Postfix, from userid 1004) id 92B3219A835; Fri, 4 Mar 2005 20:37:07 +0100 (CET) Received: from coruscant (pD9E3386D.dip.t-dialin.net [217.227.56.109]) by mail.innovalan.de (Postfix) with ESMTP id EF5D319A7E6 for ; Fri, 4 Mar 2005 20:37:06 +0100 (CET) Date: Fri, 4 Mar 2005 20:37:51 +0100 From: Olaf Rempel To: netdev@oss.sgi.com Subject: [2.6.11 PATCH] /proc/net/stat/* cleanup Message-ID: <20050304203751.379dc6a6@coruscant> X-Mailer: Sylpheed-Claws 0.9.13 (GTK+ 1.2.10; i686-pc-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Bogosity: Ham, tests=bogofilter, spamicity=0.000000, version=0.92.8 X-Virus-Status: Clean X-Virus-Checker-Version: clamassassin 1.2.0 with ClamAV 0.83/744/Fri Mar 4 04:01:45 2005 signatures 29.744 X-Virus-Scanned: ClamAV 0.83/745/Fri Mar 4 03:16:06 2005 on oss.sgi.com X-archive-position: 2390 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: razzor@kopf-tisch.de Precedence: bulk X-list: netdev Content-Length: 1848 Lines: 36 hi list in /proc/net/stat/[arp|ndisc]_cache the value "forced_gc_goal_miss" has no associated member in struct neigh_statistics. in /proc/net/stat/rt_cache the value "in_slow_mc" was printed, but without header (16 header-names, 17 values) patch is against vanilla 2.6.11 Olaf diff -uN linux-2.6.11/net/core/neighbour.c.org linux-2.6.11/net/core/neighbour.c --- linux-2.6.11/net/core/neighbour.c.org 2005-03-04 20:03:01.000000000 +0100 +++ linux-2.6.11/net/core/neighbour.c 2005-03-04 20:04:17.000000000 +0100 @@ -1948,7 +1948,7 @@ struct neigh_statistics *st = v; if (v == SEQ_START_TOKEN) { - seq_printf(seq, "entries allocs destroys hash_grows lookups hits res_failed rcv_probes_mcast rcv_probes_ucast periodic_gc_runs forced_gc_runs forced_gc_goal_miss\n"); + seq_printf(seq, "entries allocs destroys hash_grows lookups hits res_failed rcv_probes_mcast rcv_probes_ucast periodic_gc_runs forced_gc_runs\n"); return 0; } diff -uN linux-2.6.11/net/ipv4/route.c.org linux-2.6.11/net/ipv4/route.c --- linux-2.6.11/net/ipv4/route.c.org 2005-03-04 19:45:54.000000000 +0100 +++ linux-2.6.11/net/ipv4/route.c 2005-03-04 19:47:58.000000000 +0100 @@ -393,7 +393,7 @@ struct rt_cache_stat *st = v; if (v == SEQ_START_TOKEN) { - seq_printf(seq, "entries in_hit in_slow_tot in_no_route in_brd in_martian_dst in_martian_src out_hit out_slow_tot out_slow_mc gc_total gc_ignored gc_goal_miss gc_dst_overflow in_hlist_search out_hlist_search\n"); + seq_printf(seq, "entries in_hit in_slow_tot in_slow_mc in_no_route in_brd in_martian_dst in_martian_src out_hit out_slow_tot out_slow_mc gc_total gc_ignored gc_goal_miss gc_dst_overflow in_hlist_search out_hlist_search\n"); return 0; } From edgar.iglesias@axis.com Fri Mar 4 11:45:34 2005 Received: with ECARTIS (v1.0.0; list netdev); Fri, 04 Mar 2005 11:45:41 -0800 (PST) Received: from miranda.se.axis.com (miranda.se.axis.com [193.13.178.2]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j24JjX8C005960 for ; Fri, 4 Mar 2005 11:45:33 -0800 Received: from edgar.se.axis.com (edgar.se.axis.com [10.92.151.1]) by miranda.se.axis.com (8.12.9/8.12.9/Debian-5local0.1) with ESMTP id j24JjPIq022552 for ; Fri, 4 Mar 2005 20:45:25 +0100 Received: (qmail 1595 invoked from network); 4 Mar 2005 20:44:01 +0100 Received: from unknown (HELO iglesias.se.axis.com) (10.92.151.9) by edgar.se.axis.com with SMTP; 4 Mar 2005 20:44:01 +0100 Received: by iglesias.se.axis.com (sSMTP sendmail emulation); Fri, 4 Mar 2005 20:52:39 +0100 Date: Fri, 4 Mar 2005 20:52:39 +0100 From: Edgar E Iglesias To: jamal Cc: John Heffner , Stephen Hemminger , "David S. Miller" , rhee@eos.ncsu.edu, Yee-Ting.Li@nuim.ie, baruch@ev-en.org, netdev@oss.sgi.com Subject: Re: netif_rx packet dumping Message-ID: <20050304195239.GA13262@iglesias.dyn.ee> References: <20050303123811.4d934249@dxpl.pdx.osdl.net> <20050303125556.6850cfe5.davem@davemloft.net> <1109884688.1090.282.camel@jzny.localdomain> <20050303132143.7eef517c@dxpl.pdx.osdl.net> <1109885065.1098.285.camel@jzny.localdomain> <20050303133237.5d64578f.davem@davemloft.net> <20050303135416.0d6e7708@dxpl.pdx.osdl.net> <1109888811.1092.352.camel@jzny.localdomain> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1109888811.1092.352.camel@jzny.localdomain> User-Agent: Mutt/1.5.6i X-Virus-Scanned: ClamAV 0.83/745/Fri Mar 4 03:16:06 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 2391 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: edgar.iglesias@axis.com Precedence: bulk X-list: netdev Content-Length: 1917 Lines: 43 On Thu, Mar 03, 2005 at 05:26:51PM -0500, jamal wrote: > On Thu, 2005-03-03 at 17:02, John Heffner wrote: > > On Thu, 3 Mar 2005, Stephen Hemminger wrote: > > > Maybe a simple Random Exponential Drop (RED) would be more friendly. > > > > That would probably not be appropriate. This queue is only for absorbing > > micro-scale bursts. It should not hold any data in steady state like a > > router queue can. The receive window can handle the macro scale flow > > control. > > recall this is a queue that is potentially shared by many many flows > from potentially many many interfaces i.e it deals with many many > micro-scale bursts. > Clearly, the best approach is to have lots and lots of memmory and to > make that queue real huge so it can cope with all of them all the time. > We dont have that luxury - If you restrict the queue size, you will have > to drop packets... Which ones? > Probably simplest solution is to leave it as is right now and just > adjust the contraints based on your system memmory etc. > Why not have smaller queues but per interface? this would avoid introducing too much latency and keep memory consumption low but scale as we add more interfaces. It would also provide some kind of fair queueing between the interfaces to avoid highspeed nics to starve lowspeed ones. Queue length would still be an issue though, should somehow be related to interface rate and acceptable introduced latency. Regarding RED and other more sophisticated algorithms, I assume this is up to the ingress qdisc to take care of. What the queues before the ingress qdiscs should do, is to avoid introducing too much latency. In my opinion, low latency or high burst tolerance should be the choice of the admin, like for egress. I am not very familiar with the linux code, so I may be completly wrong here... Regards -- Programmer Edgar E Iglesias 46.46.272.1946 From shemminger@osdl.org Fri Mar 4 11:55:05 2005 Received: with ECARTIS (v1.0.0; list netdev); Fri, 04 Mar 2005 11:55:11 -0800 (PST) Received: from smtp.osdl.org (fire.osdl.org [65.172.181.4]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j24Jt4kk006713 for ; Fri, 4 Mar 2005 11:55:05 -0800 Received: from shell0.pdx.osdl.net (fw.osdl.org [65.172.181.6]) by smtp.osdl.org (8.12.8/8.12.8) with ESMTP id j24Js5qi028675 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO); Fri, 4 Mar 2005 11:54:06 -0800 Received: from dxpl.pdx.osdl.net (dxpl.pdx.osdl.net [172.20.1.103]) by shell0.pdx.osdl.net (8.13.1/8.11.6) with ESMTP id j24Js5BY013580; Fri, 4 Mar 2005 11:54:05 -0800 Date: Fri, 4 Mar 2005 11:54:22 -0800 From: Stephen Hemminger To: Edgar E Iglesias Cc: jamal , John Heffner , "David S. Miller" , rhee@eos.ncsu.edu, Yee-Ting.Li@nuim.ie, baruch@ev-en.org, netdev@oss.sgi.com Subject: Re: netif_rx packet dumping Message-ID: <20050304115422.2640cf91@dxpl.pdx.osdl.net> In-Reply-To: <20050304195239.GA13262@iglesias.dyn.ee> References: <20050303123811.4d934249@dxpl.pdx.osdl.net> <20050303125556.6850cfe5.davem@davemloft.net> <1109884688.1090.282.camel@jzny.localdomain> <20050303132143.7eef517c@dxpl.pdx.osdl.net> <1109885065.1098.285.camel@jzny.localdomain> <20050303133237.5d64578f.davem@davemloft.net> <20050303135416.0d6e7708@dxpl.pdx.osdl.net> <1109888811.1092.352.camel@jzny.localdomain> <20050304195239.GA13262@iglesias.dyn.ee> Organization: Open Source Development Lab X-Mailer: Sylpheed-Claws 1.0.1 (GTK+ 1.2.10; x86_64-unknown-linux-gnu) X-Face: &@E+xe?c%:&e4D{>f1O<&U>2qwRREG5!}7R4;D<"NO^UI2mJ[eEOA2*3>(`Th.yP,VDPo9$ /`~cw![cmj~~jWe?AHY7D1S+\}5brN0k*NE?pPh_'_d>6;XGG[\KDRViCfumZT3@[ Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Received-SPF: pass (domain of shemminger@osdl.org designates 65.172.181.6 as permitted sender) X-MIMEDefang-Filter: osdl$Revision: 1.104 $ X-Scanned-By: MIMEDefang 2.36 X-Virus-Scanned: ClamAV 0.83/745/Fri Mar 4 03:16:06 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 2392 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: shemminger@osdl.org Precedence: bulk X-list: netdev Content-Length: 2085 Lines: 45 On Fri, 4 Mar 2005 20:52:39 +0100 Edgar E Iglesias wrote: > On Thu, Mar 03, 2005 at 05:26:51PM -0500, jamal wrote: > > On Thu, 2005-03-03 at 17:02, John Heffner wrote: > > > On Thu, 3 Mar 2005, Stephen Hemminger wrote: > > > > Maybe a simple Random Exponential Drop (RED) would be more friendly. > > > > > > That would probably not be appropriate. This queue is only for absorbing > > > micro-scale bursts. It should not hold any data in steady state like a > > > router queue can. The receive window can handle the macro scale flow > > > control. > > > > recall this is a queue that is potentially shared by many many flows > > from potentially many many interfaces i.e it deals with many many > > micro-scale bursts. > > Clearly, the best approach is to have lots and lots of memmory and to > > make that queue real huge so it can cope with all of them all the time. > > We dont have that luxury - If you restrict the queue size, you will have > > to drop packets... Which ones? > > Probably simplest solution is to leave it as is right now and just > > adjust the contraints based on your system memmory etc. > > > > Why not have smaller queues but per interface? this would avoid > introducing too much latency and keep memory consumption low > but scale as we add more interfaces. It would also provide some > kind of fair queueing between the interfaces to avoid highspeed > nics to starve lowspeed ones. That would require locking and effectively turn every device into a NAPI device. > Queue length would still be an issue though, should somehow be > related to interface rate and acceptable introduced latency. > > Regarding RED and other more sophisticated algorithms, I assume > this is up to the ingress qdisc to take care of. What the queues > before the ingress qdiscs should do, is to avoid introducing > too much latency. In my opinion, low latency or high burst > tolerance should be the choice of the admin, like for egress. > All this happens at a much lower level before the ingress qdisc (which is optional) gets involved. From linux-netdev@gmane.org Fri Mar 4 12:02:48 2005 Received: with ECARTIS (v1.0.0; list netdev); Fri, 04 Mar 2005 12:03:25 -0800 (PST) Received: from ciao.gmane.org (main.gmane.org [80.91.229.2]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j24K2l8K007675 for ; Fri, 4 Mar 2005 12:02:47 -0800 Received: from list by ciao.gmane.org with local (Exim 4.43) id 1D7Iry-0002n9-Mj for netdev@oss.sgi.com; Fri, 04 Mar 2005 20:53:54 +0100 Received: from 69.15.40.50 ([69.15.40.50]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Fri, 04 Mar 2005 20:53:54 +0100 Received: from lunz by 69.15.40.50 with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Fri, 04 Mar 2005 20:53:54 +0100 X-Injected-Via-Gmane: http://gmane.org/ To: netdev@oss.sgi.com From: Jason Lunz Subject: Re: netif_rx packet dumping Date: Fri, 4 Mar 2005 19:49:33 +0000 (UTC) Organization: PBR Streetgang Message-ID: References: <20050303123811.4d934249@dxpl.pdx.osdl.net> <20050303125556.6850cfe5.davem@davemloft.net> <1109884688.1090.282.camel@jzny.localdomain> <20050303132143.7eef517c@dxpl.pdx.osdl.net> <1109885065.1098.285.camel@jzny.localdomain> <20050303133237.5d64578f.davem@davemloft.net> <20050303135416.0d6e7708@dxpl.pdx.osdl.net> X-Complaints-To: usenet@sea.gmane.org X-Gmane-NNTP-Posting-Host: 69.15.40.50 User-Agent: slrn/0.9.8.1 (Debian) X-Gmane-MailScanner: Found to be clean X-Gmane-MailScanner: Found to be clean X-MailScanner-From: linux-netdev@m.gmane.org X-MailScanner-To: netdev@oss.sgi.com X-Virus-Scanned: ClamAV 0.83/745/Fri Mar 4 03:16:06 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 2393 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: lunz@falooley.org Precedence: bulk X-list: netdev Content-Length: 424 Lines: 13 shemminger@osdl.org said: >> We should eliminate the max backlog thing completely. There is >> no need for it. > > Still need some bound, because if process_backlog is running slower > than the net; then the queue could grow till memory exhausted from > skbuff's. yes. I eliminated netdev_max_backlog long ago in an experiment with a 2.4 kernel, and it became quite easy to consume huge amounts of kernel memory. Jason From herbert@gondor.apana.org.au Fri Mar 4 12:41:09 2005 Received: with ECARTIS (v1.0.0; list netdev); Fri, 04 Mar 2005 12:41:19 -0800 (PST) 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 j24Kf8uj014135 for ; Fri, 4 Mar 2005 12:41:09 -0800 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 1D7JbK-0005Gj-00; Sat, 05 Mar 2005 07:40:46 +1100 Received: from herbert by gondolin.me.apana.org.au with local (Exim 3.36 #1 (Debian)) id 1D7Jaa-0003pu-00; Sat, 05 Mar 2005 07:40:00 +1100 Date: Sat, 5 Mar 2005 07:40:00 +1100 To: Thomas Graf Cc: davem@davemloft.net, netdev@oss.sgi.com Subject: Re: [PATCH] [NET]: Fix deletion of local addresses only varying in prefix length Message-ID: <20050304204000.GA14725@gondor.apana.org.au> References: <20050304012003.GA31837@postel.suug.ch> <20050304131419.GE31837@postel.suug.ch> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20050304131419.GE31837@postel.suug.ch> User-Agent: Mutt/1.5.6+20040907i From: Herbert Xu X-Virus-Scanned: ClamAV 0.83/745/Fri Mar 4 03:16:06 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 2394 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: herbert@gondor.apana.org.au Precedence: bulk X-list: netdev Content-Length: 759 Lines: 18 On Fri, Mar 04, 2005 at 02:14:19PM +0100, Thomas Graf wrote: > > I do not agree but I might have a better idea. Let's change iproute2 > to provide a prefixlength of 0 if no prefix was specified and only > compare the prefixes if it is non zero. This allows for accurate > deletion, no scripts will break (except for really really broken ones). > Given there are multiple matching addresses only varying in prefix > length and no prefix was specified the first one will get deleted but > this is well defined. Yep this is a good solution. Cheers, -- Visit Openswan at http://www.openswan.org/ Email: Herbert Xu ~{PmV>HI~} Home Page: http://gondor.apana.org.au/~herbert/ PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt From herbert@gondor.apana.org.au Fri Mar 4 12:46:42 2005 Received: with ECARTIS (v1.0.0; list netdev); Fri, 04 Mar 2005 12:46:52 -0800 (PST) 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 j24KkeRg014822 for ; Fri, 4 Mar 2005 12:46:41 -0800 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 1D7Jgp-0005Kb-00; Sat, 05 Mar 2005 07:46:27 +1100 Received: from herbert by gondolin.me.apana.org.au with local (Exim 3.36 #1 (Debian)) id 1D7JgZ-0006xS-00; Sat, 05 Mar 2005 07:46:11 +1100 Date: Sat, 5 Mar 2005 07:46:11 +1100 To: Thomas Graf Cc: davem@davemloft.net, netdev@oss.sgi.com Subject: Re: [PATCH] [NET]: Fix deletion of local addresses only varying in prefix length Message-ID: <20050304204611.GA26736@gondor.apana.org.au> References: <20050304012003.GA31837@postel.suug.ch> <20050304131419.GE31837@postel.suug.ch> <20050304204000.GA14725@gondor.apana.org.au> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20050304204000.GA14725@gondor.apana.org.au> User-Agent: Mutt/1.5.6+20040907i From: Herbert Xu X-Virus-Scanned: ClamAV 0.83/745/Fri Mar 4 03:16:06 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 2395 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: herbert@gondor.apana.org.au Precedence: bulk X-list: netdev Content-Length: 1047 Lines: 23 On Sat, Mar 05, 2005 at 07:40:00AM +1100, herbert wrote: > On Fri, Mar 04, 2005 at 02:14:19PM +0100, Thomas Graf wrote: > > > > I do not agree but I might have a better idea. Let's change iproute2 > > to provide a prefixlength of 0 if no prefix was specified and only > > compare the prefixes if it is non zero. This allows for accurate > > deletion, no scripts will break (except for really really broken ones). > > Given there are multiple matching addresses only varying in prefix > > length and no prefix was specified the first one will get deleted but > > this is well defined. > > Yep this is a good solution. There is one hitch though. iproute2 probably uses the same function to parse the address used in adding as well as deleting addresses. So you'll need to be careful to only do this for the case of deleting. Cheers, -- Visit Openswan at http://www.openswan.org/ Email: Herbert Xu ~{PmV>HI~} Home Page: http://gondor.apana.org.au/~herbert/ PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt From shemminger@osdl.org Fri Mar 4 13:27:57 2005 Received: with ECARTIS (v1.0.0; list netdev); Fri, 04 Mar 2005 13:28:02 -0800 (PST) Received: from smtp.osdl.org (fire.osdl.org [65.172.181.4]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j24LRvuC016767 for ; Fri, 4 Mar 2005 13:27:57 -0800 Received: from shell0.pdx.osdl.net (fw.osdl.org [65.172.181.6]) by smtp.osdl.org (8.12.8/8.12.8) with ESMTP id j24LRmqi004644 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO); Fri, 4 Mar 2005 13:27:49 -0800 Received: from dxpl.pdx.osdl.net (dxpl.pdx.osdl.net [172.20.1.103]) by shell0.pdx.osdl.net (8.13.1/8.11.6) with ESMTP id j24LRmiB018591; Fri, 4 Mar 2005 13:27:48 -0800 Date: Fri, 4 Mar 2005 13:28:04 -0800 From: Stephen Hemminger To: Francois Romieu Cc: netdev@oss.sgi.com Subject: r8169: panic on 2.6.11 Message-ID: <20050304132804.270cf05b@dxpl.pdx.osdl.net> Organization: Open Source Development Lab X-Mailer: Sylpheed-Claws 1.0.1 (GTK+ 1.2.10; x86_64-unknown-linux-gnu) X-Face: &@E+xe?c%:&e4D{>f1O<&U>2qwRREG5!}7R4;D<"NO^UI2mJ[eEOA2*3>(`Th.yP,VDPo9$ /`~cw![cmj~~jWe?AHY7D1S+\}5brN0k*NE?pPh_'_d>6;XGG[\KDRViCfumZT3@[ Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Received-SPF: pass (domain of shemminger@osdl.org designates 65.172.181.6 as permitted sender) X-MIMEDefang-Filter: osdl$Revision: 1.104 $ X-Scanned-By: MIMEDefang 2.36 X-Virus-Scanned: ClamAV 0.83/745/Fri Mar 4 03:16:06 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 2396 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: shemminger@osdl.org Precedence: bulk X-list: netdev Content-Length: 2112 Lines: 49 I was intentionally over stressing r8169 without NAPI to test out an alternative version of netif_rx, and discovered the following bug. Looks like a problem in r8169. I was using pktgen to overwhelm the r8169 from a fast machine. eth0: Too much work at interrupt! eth0: Too much work at interrupt! ------------[ cut here ]------------ kernel BUG at net/core/skbuff.c:91! invalid operand: 0000 [#1] PREEMPT Modules linked in: i810 md5 ipv6 autofs4 sunrpc reiserfs video button battery adCPU: 0 EIP: 0060:[] Not tainted VLI EFLAGS: 00010296 (2.6.11-netrx) EIP is at skb_over_panic+0x38/0x50 eax: 0000002e ebx: d7144000 ecx: 00000000 edx: c036cf40 esi: c02cee94 edi: 00000000 ebp: c036cf58 esp: c036cf3c ds: 007b es: 007b ss: 0068 Process swapper (pid: 0, threadinfo=c036c000 task=c02f8b20) Stack: c02e38f8 d8856a10 00001fec 00001fec d7144000 d39fe6a0 00000036 c036cf94 d8856a15 00000002 c1378b20 d8856a30 00001fec d395b360 00000100 00109f36 d7144220 d7144000 d39fe6a0 00000001 d881cc00 d7144000 c036cfbc d8856b4d Call Trace: [] show_stack+0x7a/0x90 [] show_registers+0x149/0x1c0 [] die+0xdd/0x170 [] do_invalid_op+0xa5/0xb0 [] error_code+0x2b/0x30 [] rtl8169_rx_interrupt+0x365/0x380 [r8169] [] rtl8169_interrupt+0xed/0x140 [r8169] [] handle_IRQ_event+0x35/0x70 [] __do_IRQ+0xbe/0x150 [] do_IRQ+0x41/0x70 ======================= [] common_interrupt+0x1a/0x20 [] ip_route_input_slow+0x6d/0x9f0 [] ip_rcv+0x380/0x480 [] netif_receive_skb+0x1e5/0x220 [] process_backlog+0x7e/0x100 [] net_rx_action+0x65/0xf0 [] __do_softirq+0x42/0xa0 [] do_softirq+0x44/0x60 ======================= [] irq_exit+0x38/0x40 [] do_IRQ+0x48/0x70 [] common_interrupt+0x1a/0x20 [] need_resched+0x1f/0x21 Code: c0 89 5d f8 8b 58 18 89 54 24 0c 85 db 0f 44 de 89 5c 24 10 8b 40 60 89 4 <0>Kernel panic - not syncing: Fatal exception in interrupt From edgar.iglesias@axis.com Fri Mar 4 13:34:17 2005 Received: with ECARTIS (v1.0.0; list netdev); Fri, 04 Mar 2005 13:34:29 -0800 (PST) Received: from miranda.se.axis.com (miranda.se.axis.com [193.13.178.2]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j24LYGss017667 for ; Fri, 4 Mar 2005 13:34:16 -0800 Received: from edgar.se.axis.com (edgar.se.axis.com [10.92.151.1]) by miranda.se.axis.com (8.12.9/8.12.9/Debian-5local0.1) with ESMTP id j24LY9Iq031552 for ; Fri, 4 Mar 2005 22:34:09 +0100 Received: (qmail 4128 invoked from network); 4 Mar 2005 22:32:44 +0100 Received: from unknown (HELO iglesias.se.axis.com) (10.92.151.9) by edgar.se.axis.com with SMTP; 4 Mar 2005 22:32:44 +0100 Received: by iglesias.se.axis.com (sSMTP sendmail emulation); Fri, 4 Mar 2005 22:41:22 +0100 Date: Fri, 4 Mar 2005 22:41:22 +0100 From: Edgar E Iglesias To: Stephen Hemminger Cc: Edgar E Iglesias , jamal , John Heffner , "David S. Miller" , rhee@eos.ncsu.edu, Yee-Ting.Li@nuim.ie, baruch@ev-en.org, netdev@oss.sgi.com Subject: Re: netif_rx packet dumping Message-ID: <20050304214122.GB13262@iglesias.dyn.ee> References: <20050303125556.6850cfe5.davem@davemloft.net> <1109884688.1090.282.camel@jzny.localdomain> <20050303132143.7eef517c@dxpl.pdx.osdl.net> <1109885065.1098.285.camel@jzny.localdomain> <20050303133237.5d64578f.davem@davemloft.net> <20050303135416.0d6e7708@dxpl.pdx.osdl.net> <1109888811.1092.352.camel@jzny.localdomain> <20050304195239.GA13262@iglesias.dyn.ee> <20050304115422.2640cf91@dxpl.pdx.osdl.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20050304115422.2640cf91@dxpl.pdx.osdl.net> User-Agent: Mutt/1.5.6i X-Virus-Scanned: ClamAV 0.83/745/Fri Mar 4 03:16:06 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 2397 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: edgar.iglesias@axis.com Precedence: bulk X-list: netdev Content-Length: 3195 Lines: 67 On Fri, Mar 04, 2005 at 11:54:22AM -0800, Stephen Hemminger wrote: > On Fri, 4 Mar 2005 20:52:39 +0100 > Edgar E Iglesias wrote: > > > On Thu, Mar 03, 2005 at 05:26:51PM -0500, jamal wrote: > > > On Thu, 2005-03-03 at 17:02, John Heffner wrote: > > > > On Thu, 3 Mar 2005, Stephen Hemminger wrote: > > > > > Maybe a simple Random Exponential Drop (RED) would be more friendly. > > > > > > > > That would probably not be appropriate. This queue is only for absorbing > > > > micro-scale bursts. It should not hold any data in steady state like a > > > > router queue can. The receive window can handle the macro scale flow > > > > control. > > > > > > recall this is a queue that is potentially shared by many many flows > > > from potentially many many interfaces i.e it deals with many many > > > micro-scale bursts. > > > Clearly, the best approach is to have lots and lots of memmory and to > > > make that queue real huge so it can cope with all of them all the time. > > > We dont have that luxury - If you restrict the queue size, you will have > > > to drop packets... Which ones? > > > Probably simplest solution is to leave it as is right now and just > > > adjust the contraints based on your system memmory etc. > > > > > > > Why not have smaller queues but per interface? this would avoid > > introducing too much latency and keep memory consumption low > > but scale as we add more interfaces. It would also provide some > > kind of fair queueing between the interfaces to avoid highspeed > > nics to starve lowspeed ones. > > That would require locking and effectively turn every device > into a NAPI device. > Oh ok, then why not a weightend algorithm, like we do when we feed netif_receive_skb to give fairness among CPUs, but this time for netif_rx input to give fairness among intefaces. The total queuelen would be the length of the total weights and grow as more interfaces are added. When each interface's quota is reached it begins to drop. The individual weights could be chosen based on interface rates. A simple WRR would do. This may (compared to the current queue) cost cpu cycles though... > > Queue length would still be an issue though, should somehow be > > related to interface rate and acceptable introduced latency. > > > > Regarding RED and other more sophisticated algorithms, I assume > > this is up to the ingress qdisc to take care of. What the queues > > before the ingress qdiscs should do, is to avoid introducing > > too much latency. In my opinion, low latency or high burst > > tolerance should be the choice of the admin, like for egress. > > > > All this happens at a much lower level before the ingress qdisc > (which is optional) gets involved. Exactly, this is why we should not introduce latency. Latency should be a choice for upper layers. When ingress qdiscs are disabled its acceptable (I guess) to have a default behavior with some kind of balanced tradeoff, but when qdiscs are enabled a 300 skb list could become a problem introducing latency. Some applications would like to signal congestion much earlier. -- Programmer Edgar E Iglesias 46.46.272.1946 From jgarzik@pobox.com Fri Mar 4 13:37:57 2005 Received: with ECARTIS (v1.0.0; list netdev); Fri, 04 Mar 2005 13:38:02 -0800 (PST) Received: from parcelfarce.linux.theplanet.co.uk (IDENT:93@parcelfarce.linux.theplanet.co.uk [195.92.249.252]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j24LbukI018406 for ; Fri, 4 Mar 2005 13:37:57 -0800 Received: from [69.134.152.124] (helo=[10.10.10.88]) by parcelfarce.linux.theplanet.co.uk with asmtp (TLSv1:AES256-SHA:256) (Exim 4.33) id 1D7KUb-0008Qs-9P; Fri, 04 Mar 2005 21:37:53 +0000 Message-ID: <4228D523.2070703@pobox.com> Date: Fri, 04 Mar 2005 16:37:39 -0500 From: Jeff Garzik User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.3) Gecko/20040922 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Stephen Hemminger CC: Francois Romieu , netdev@oss.sgi.com Subject: Re: r8169: panic on 2.6.11 References: <20050304132804.270cf05b@dxpl.pdx.osdl.net> In-Reply-To: <20050304132804.270cf05b@dxpl.pdx.osdl.net> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV 0.83/745/Fri Mar 4 03:16:06 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 2398 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: jgarzik@pobox.com Precedence: bulk X-list: netdev Content-Length: 635 Lines: 21 Stephen Hemminger wrote: > I was intentionally over stressing r8169 without NAPI to test out > an alternative version of netif_rx, and discovered the following bug. > Looks like a problem in r8169. I was using pktgen to overwhelm the r8169 > from a fast machine. Does 2.6.10 fail in a similar manner? > eth0: Too much work at interrupt! > eth0: Too much work at interrupt! > ------------[ cut here ]------------ > kernel BUG at net/core/skbuff.c:91! Any idea what this BUG actually means? Since it's in skb_over_panic(), a function designed to do nothing but BUG(), that doesn't tell us a whole lot about the callsite. Jeff From romieu@fr.zoreil.com Fri Mar 4 13:40:31 2005 Received: with ECARTIS (v1.0.0; list netdev); Fri, 04 Mar 2005 13:40:36 -0800 (PST) Received: from fr.zoreil.com (electric-eye.fr.zoreil.com [213.41.134.224]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j24LeTUA018974 for ; Fri, 4 Mar 2005 13:40:30 -0800 Received: from electric-eye.fr.zoreil.com (localhost.localdomain [127.0.0.1]) by fr.zoreil.com (8.13.1/8.12.1) with ESMTP id j24LdGCR006636; Fri, 4 Mar 2005 22:39:16 +0100 Received: (from romieu@localhost) by electric-eye.fr.zoreil.com (8.13.1/8.13.1/Submit) id j24LdBe5006635; Fri, 4 Mar 2005 22:39:11 +0100 Date: Fri, 4 Mar 2005 22:39:11 +0100 From: Francois Romieu To: Stephen Hemminger Cc: netdev@oss.sgi.com Subject: Re: r8169: panic on 2.6.11 Message-ID: <20050304213911.GA1148@electric-eye.fr.zoreil.com> References: <20050304132804.270cf05b@dxpl.pdx.osdl.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20050304132804.270cf05b@dxpl.pdx.osdl.net> User-Agent: Mutt/1.4.1i X-Organisation: Land of Sunshine Inc. X-Virus-Scanned: ClamAV 0.83/745/Fri Mar 4 03:16:06 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 2399 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: romieu@fr.zoreil.com Precedence: bulk X-list: netdev Content-Length: 311 Lines: 10 Stephen Hemminger : > I was intentionally over stressing r8169 without NAPI to test out > an alternative version of netif_rx, and discovered the following bug. > Looks like a problem in r8169. I was using pktgen to overwhelm the r8169 > from a fast machine. Thanks. I'm on it. -- Ueimor From romieu@fr.zoreil.com Fri Mar 4 13:52:30 2005 Received: with ECARTIS (v1.0.0; list netdev); Fri, 04 Mar 2005 13:52:41 -0800 (PST) Received: from fr.zoreil.com (electric-eye.fr.zoreil.com [213.41.134.224]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j24LqTLU019810 for ; Fri, 4 Mar 2005 13:52:30 -0800 Received: from electric-eye.fr.zoreil.com (localhost.localdomain [127.0.0.1]) by fr.zoreil.com (8.13.1/8.12.1) with ESMTP id j24LooDW007057; Fri, 4 Mar 2005 22:50:50 +0100 Received: (from romieu@localhost) by electric-eye.fr.zoreil.com (8.13.1/8.13.1/Submit) id j24Loi0V007056; Fri, 4 Mar 2005 22:50:44 +0100 Date: Fri, 4 Mar 2005 22:50:44 +0100 From: Francois Romieu To: Jeff Garzik Cc: Stephen Hemminger , netdev@oss.sgi.com Subject: Re: r8169: panic on 2.6.11 Message-ID: <20050304215044.GB1148@electric-eye.fr.zoreil.com> References: <20050304132804.270cf05b@dxpl.pdx.osdl.net> <4228D523.2070703@pobox.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4228D523.2070703@pobox.com> User-Agent: Mutt/1.4.1i X-Organisation: Land of Sunshine Inc. X-Virus-Scanned: ClamAV 0.83/745/Fri Mar 4 03:16:06 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 2400 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: romieu@fr.zoreil.com Precedence: bulk X-list: netdev Content-Length: 404 Lines: 12 Jeff Garzik : [...] > Any idea what this BUG actually means? Since it's in skb_over_panic(), > a function designed to do nothing but BUG(), that doesn't tell us a > whole lot about the callsite. I have been reported that the driver is not protected against oversized frames since 2.6.10 at least... I've just got an instant reboot on the sparc box while testing it :o/ -- Ueimor From bunk@stusta.de Fri Mar 4 14:10:25 2005 Received: with ECARTIS (v1.0.0; list netdev); Fri, 04 Mar 2005 14:10:30 -0800 (PST) Received: from mailout.stusta.mhn.de (emailhub.stusta.mhn.de [141.84.69.5]) by oss.sgi.com (8.13.0/8.13.0) with SMTP id j24MAL3k021076 for ; Fri, 4 Mar 2005 14:10:24 -0800 Received: (qmail 7557 invoked from network); 4 Mar 2005 22:10:15 -0000 Received: from r063144.stusta.swh.mhn.de (10.150.63.144) by mailhub.stusta.mhn.de with SMTP; 4 Mar 2005 22:10:15 -0000 Received: by r063144.stusta.swh.mhn.de (Postfix, from userid 1000) id 07EB7AFBF2; Fri, 4 Mar 2005 23:10:15 +0100 (CET) Date: Fri, 4 Mar 2005 23:10:15 +0100 From: Adrian Bunk To: Jeff Garzik , Herbert Xu Cc: akpm@osdl.org, davem@davemloft.net, netdev@oss.sgi.com Subject: Re: [patch 1/3] fix buggy IEEE80211_CRYPT_* selects Message-ID: <20050304221014.GJ3327@stusta.de> References: <200503041237.j24Cbb69026470@shell0.pdx.osdl.net> <42289BDF.1080409@pobox.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <42289BDF.1080409@pobox.com> User-Agent: Mutt/1.5.6+20040907i X-Virus-Scanned: ClamAV 0.83/745/Fri Mar 4 03:16:06 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 2401 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: bunk@stusta.de Precedence: bulk X-list: netdev Content-Length: 1926 Lines: 55 On Fri, Mar 04, 2005 at 12:33:19PM -0500, Jeff Garzik wrote: > akpm@osdl.org wrote: > >From: Adrian Bunk > > > >Some of the options that needlessly wrote in their help text which options > >they do select (patch already sent) didn't obey the most important rule of > >select > > > > If you select something, you have to ensure that the dependencies > > of what you do select are fulfilled. > > >diff -puN net/ieee80211/Kconfig~fix-buggy-ieee80211_crypt_-selects > >net/ieee80211/Kconfig > >--- 25/net/ieee80211/Kconfig~fix-buggy-ieee80211_crypt_-selects 2005-02-28 > >14:49:54.000000000 -0800 > >+++ 25-akpm/net/ieee80211/Kconfig 2005-02-28 14:49:54.000000000 -0800 > >@@ -44,6 +44,7 @@ config IEEE80211_CRYPT_WEP > > config IEEE80211_CRYPT_CCMP > > tristate "IEEE 802.11i CCMP support" > > depends on IEEE80211 > >+ select CRYPTO > > select CRYPTO_AES > > ---help--- > > Include software based cipher suites in support of IEEE 802.11i > >@@ -56,6 +57,7 @@ config IEEE80211_CRYPT_CCMP > > config IEEE80211_CRYPT_TKIP > > tristate "IEEE 802.11i TKIP encryption" > > depends on IEEE80211 > >+ select CRYPTO > > select CRYPTO_MICHAEL_MIC > > ---help--- > > > You are resending the old patch that is incorrect. We don't need > multiple selects, CRYPTO_AES and CRYPTO_MICHAEL_MIC should pull things in. As I already said, this implies that options like CRYPTO_AES and CRYPTO_MICHAEL_MIC can no longer depend on CRYPTO. It's possible to change the crypto options in a way that CRYPTO is selected as required but no longer directly selectable (and I could send such a patch), but that's a decision of the crypto maintainers. > Jeff cu Adrian -- "Is there not promise of rain?" Ling Tan asked suddenly out of the darkness. There had been need of rain for many days. "Only a promise," Lao Er said. Pearl S. Buck - Dragon Seed From jgarzik@pobox.com Fri Mar 4 14:21:44 2005 Received: with ECARTIS (v1.0.0; list netdev); Fri, 04 Mar 2005 14:21:49 -0800 (PST) Received: from parcelfarce.linux.theplanet.co.uk (IDENT:93@parcelfarce.linux.theplanet.co.uk [195.92.249.252]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j24MLhwI021923 for ; Fri, 4 Mar 2005 14:21:44 -0800 Received: from [69.134.152.124] (helo=[10.10.10.88]) by parcelfarce.linux.theplanet.co.uk with asmtp (TLSv1:AES256-SHA:256) (Exim 4.33) id 1D7LAz-00027P-T4; Fri, 04 Mar 2005 22:21:42 +0000 Message-ID: <4228DF62.4000205@pobox.com> Date: Fri, 04 Mar 2005 17:21:22 -0500 From: Jeff Garzik User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.3) Gecko/20040922 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Adrian Bunk CC: Herbert Xu , akpm@osdl.org, davem@davemloft.net, netdev@oss.sgi.com Subject: Re: [patch 1/3] fix buggy IEEE80211_CRYPT_* selects References: <200503041237.j24Cbb69026470@shell0.pdx.osdl.net> <42289BDF.1080409@pobox.com> <20050304221014.GJ3327@stusta.de> In-Reply-To: <20050304221014.GJ3327@stusta.de> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV 0.83/745/Fri Mar 4 03:16:06 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 2402 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: jgarzik@pobox.com Precedence: bulk X-list: netdev Content-Length: 1776 Lines: 53 Adrian Bunk wrote: > On Fri, Mar 04, 2005 at 12:33:19PM -0500, Jeff Garzik wrote: > >>akpm@osdl.org wrote: >> >>>From: Adrian Bunk >>> >>>Some of the options that needlessly wrote in their help text which options >>>they do select (patch already sent) didn't obey the most important rule of >>>select >>> >>> If you select something, you have to ensure that the dependencies >>> of what you do select are fulfilled. >> >>>diff -puN net/ieee80211/Kconfig~fix-buggy-ieee80211_crypt_-selects >>>net/ieee80211/Kconfig >>>--- 25/net/ieee80211/Kconfig~fix-buggy-ieee80211_crypt_-selects 2005-02-28 >>>14:49:54.000000000 -0800 >>>+++ 25-akpm/net/ieee80211/Kconfig 2005-02-28 14:49:54.000000000 -0800 >>>@@ -44,6 +44,7 @@ config IEEE80211_CRYPT_WEP >>>config IEEE80211_CRYPT_CCMP >>> tristate "IEEE 802.11i CCMP support" >>> depends on IEEE80211 >>>+ select CRYPTO >>> select CRYPTO_AES >>> ---help--- >>> Include software based cipher suites in support of IEEE 802.11i >>>@@ -56,6 +57,7 @@ config IEEE80211_CRYPT_CCMP >>>config IEEE80211_CRYPT_TKIP >>> tristate "IEEE 802.11i TKIP encryption" >>> depends on IEEE80211 >>>+ select CRYPTO >>> select CRYPTO_MICHAEL_MIC >>> ---help--- >> >> >>You are resending the old patch that is incorrect. We don't need >>multiple selects, CRYPTO_AES and CRYPTO_MICHAEL_MIC should pull things in. > > > As I already said, this implies that options like CRYPTO_AES and > CRYPTO_MICHAEL_MIC can no longer depend on CRYPTO. No. Because CRYPTO_AES and CRYPTO_MICHAEL_MIC __obviously__ depend on CRYPTO, it should select CRYPTO automatically given the existing entries. Otherwise, we must start specifying dependency chains in every damn Kconfig entry, which is completely illogical and a maintenance nightmare. Jeff From shemminger@osdl.org Fri Mar 4 14:53:13 2005 Received: with ECARTIS (v1.0.0; list netdev); Fri, 04 Mar 2005 14:53:19 -0800 (PST) Received: from smtp.osdl.org (fire.osdl.org [65.172.181.4]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j24MrDJh023620 for ; Fri, 4 Mar 2005 14:53:13 -0800 Received: from shell0.pdx.osdl.net (fw.osdl.org [65.172.181.6]) by smtp.osdl.org (8.12.8/8.12.8) with ESMTP id j24Mr0qi012915 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO); Fri, 4 Mar 2005 14:53:01 -0800 Received: from dxpl.pdx.osdl.net (dxpl.pdx.osdl.net [172.20.1.103]) by shell0.pdx.osdl.net (8.13.1/8.11.6) with ESMTP id j24Mr0O1023481; Fri, 4 Mar 2005 14:53:00 -0800 Date: Fri, 4 Mar 2005 14:53:17 -0800 From: Stephen Hemminger To: Francois Romieu Cc: netdev@oss.sgi.com Subject: Re: r8169: panic on 2.6.11 Message-ID: <20050304145317.772859da@dxpl.pdx.osdl.net> In-Reply-To: <20050304221826.GA1028@electric-eye.fr.zoreil.com> References: <20050304132804.270cf05b@dxpl.pdx.osdl.net> <4228D523.2070703@pobox.com> <20050304215044.GB1148@electric-eye.fr.zoreil.com> <20050304135922.0b0a3911@dxpl.pdx.osdl.net> <20050304221826.GA1028@electric-eye.fr.zoreil.com> Organization: Open Source Development Lab X-Mailer: Sylpheed-Claws 1.0.1 (GTK+ 1.2.10; x86_64-unknown-linux-gnu) X-Face: &@E+xe?c%:&e4D{>f1O<&U>2qwRREG5!}7R4;D<"NO^UI2mJ[eEOA2*3>(`Th.yP,VDPo9$ /`~cw![cmj~~jWe?AHY7D1S+\}5brN0k*NE?pPh_'_d>6;XGG[\KDRViCfumZT3@[ Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Received-SPF: pass (domain of shemminger@osdl.org designates 65.172.181.6 as permitted sender) X-MIMEDefang-Filter: osdl$Revision: 1.104 $ X-Scanned-By: MIMEDefang 2.36 X-Virus-Scanned: ClamAV 0.83/745/Fri Mar 4 03:16:06 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 2403 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: shemminger@osdl.org Precedence: bulk X-list: netdev Content-Length: 801 Lines: 25 On Fri, 4 Mar 2005 23:18:26 +0100 Francois Romieu wrote: > Stephen Hemminger : > [...] > > My pktgen script is below. > > Sends lots of small packets. > > Ok, so I have two issues... > > It could help to know if it was the NAPI or the IRQ verison of the driver > which crashed + rough estimate of the expected pkts/s count during such test. NAPI is not enabled, it is the IRQ version. Hitting Added instrumentation:. skb=0xd1e28380 len=8172 head=d1e32000 data=d1e32012 tail=d1e33ffe end=d1e32620 Looks like the board is running back-to-back packets together, MTU is 1500. No Jumbo frames exist on my little network and the gigabit switch (Netgear) won't even take them. Probably a chip bug. Need to add a check for len > mtu before processing? From romieu@fr.zoreil.com Fri Mar 4 15:04:30 2005 Received: with ECARTIS (v1.0.0; list netdev); Fri, 04 Mar 2005 15:04:34 -0800 (PST) Received: from fr.zoreil.com (electric-eye.fr.zoreil.com [213.41.134.224]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j24N4Tvq025106 for ; Fri, 4 Mar 2005 15:04:30 -0800 Received: from electric-eye.fr.zoreil.com (localhost.localdomain [127.0.0.1]) by fr.zoreil.com (8.13.1/8.12.1) with ESMTP id j24N2JhP008548; Sat, 5 Mar 2005 00:02:19 +0100 Received: (from romieu@localhost) by electric-eye.fr.zoreil.com (8.13.1/8.13.1/Submit) id j24N2Eu6008547; Sat, 5 Mar 2005 00:02:14 +0100 Date: Sat, 5 Mar 2005 00:02:14 +0100 From: Francois Romieu To: Stephen Hemminger Cc: netdev@oss.sgi.com Subject: Re: r8169: panic on 2.6.11 Message-ID: <20050304230214.GC1148@electric-eye.fr.zoreil.com> References: <20050304132804.270cf05b@dxpl.pdx.osdl.net> <4228D523.2070703@pobox.com> <20050304215044.GB1148@electric-eye.fr.zoreil.com> <20050304135922.0b0a3911@dxpl.pdx.osdl.net> <20050304221826.GA1028@electric-eye.fr.zoreil.com> <20050304145317.772859da@dxpl.pdx.osdl.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20050304145317.772859da@dxpl.pdx.osdl.net> User-Agent: Mutt/1.4.1i X-Organisation: Land of Sunshine Inc. X-Virus-Scanned: ClamAV 0.83/745/Fri Mar 4 03:16:06 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 2404 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: romieu@fr.zoreil.com Precedence: bulk X-list: netdev Content-Length: 1840 Lines: 56 Stephen Hemminger : [...] > NAPI is not enabled, it is the IRQ version. Hitting > > Added instrumentation:. > > skb=0xd1e28380 len=8172 head=d1e32000 data=d1e32012 tail=d1e33ffe end=d1e32620 > > Looks like the board is running back-to-back packets together, MTU is 1500. > No Jumbo frames exist on my little network and the gigabit switch (Netgear) won't > even take them. Probably a chip bug. /me scratches head: play with the interframe gap ? > Need to add a check for len > mtu before processing? Please. diff -puN drivers/net/r8169.c~r8169-470 drivers/net/r8169.c --- linux-2.6.11/drivers/net/r8169.c~r8169-470 2005-03-04 22:51:35.038710839 +0100 +++ linux-2.6.11-fr/drivers/net/r8169.c 2005-03-04 23:16:29.422289316 +0100 @@ -2194,6 +2194,7 @@ rtl8169_rx_interrupt(struct net_device * int pkt_size = (status & 0x00001FFF) - 4; void (*pci_action)(struct pci_dev *, dma_addr_t, size_t, int) = pci_dma_sync_single_for_device; + static int show_size = 0; rtl8169_rx_csum(skb, desc); @@ -2210,6 +2211,24 @@ rtl8169_rx_interrupt(struct net_device * pci_action(tp->pci_dev, le64_to_cpu(desc->addr), tp->rx_buf_sz, PCI_DMA_FROMDEVICE); + if (pkt_size >= tp->rx_buf_sz) { + show_size = 1; + pkt_size = tp->rx_buf_sz; + } + + if (show_size) { + printk(KERN_INFO "%s: pkt_size=%d\n", dev->name, + pkt_size); + printk(KERN_INFO "%s: opts1= %08x\n", dev->name, + desc->opts1); + printk(KERN_INFO "%s: opts2= %08x\n", dev->name, + desc->opts2); + printk(KERN_INFO "%s: addrl= %08x\n", dev->name, + (u32)desc->addr); + printk(KERN_INFO "%s: addrh= %08x\n", dev->name, + (u32)(desc->addr >> 32)); + } + skb->dev = dev; skb_put(skb, pkt_size); skb->protocol = eth_type_trans(skb, dev); _ From bunk@stusta.de Fri Mar 4 15:07:28 2005 Received: with ECARTIS (v1.0.0; list netdev); Fri, 04 Mar 2005 15:07:31 -0800 (PST) Received: from mailout.stusta.mhn.de (emailhub.stusta.mhn.de [141.84.69.5]) by oss.sgi.com (8.13.0/8.13.0) with SMTP id j24N7Q5v025755 for ; Fri, 4 Mar 2005 15:07:27 -0800 Received: (qmail 9997 invoked from network); 4 Mar 2005 23:07:19 -0000 Received: from r063144.stusta.swh.mhn.de (10.150.63.144) by mailout.stusta.mhn.de with SMTP; 4 Mar 2005 23:07:19 -0000 Received: by r063144.stusta.swh.mhn.de (Postfix, from userid 1000) id C6184AFBF2; Sat, 5 Mar 2005 00:07:18 +0100 (CET) Date: Sat, 5 Mar 2005 00:07:18 +0100 From: Adrian Bunk To: Jeff Garzik Cc: Herbert Xu , akpm@osdl.org, davem@davemloft.net, netdev@oss.sgi.com Subject: Re: [patch 1/3] fix buggy IEEE80211_CRYPT_* selects Message-ID: <20050304230718.GL3327@stusta.de> References: <200503041237.j24Cbb69026470@shell0.pdx.osdl.net> <42289BDF.1080409@pobox.com> <20050304221014.GJ3327@stusta.de> <4228DF62.4000205@pobox.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4228DF62.4000205@pobox.com> User-Agent: Mutt/1.5.6+20040907i X-Virus-Scanned: ClamAV 0.83/745/Fri Mar 4 03:16:06 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 2405 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: bunk@stusta.de Precedence: bulk X-list: netdev Content-Length: 3580 Lines: 126 On Fri, Mar 04, 2005 at 05:21:22PM -0500, Jeff Garzik wrote: > Adrian Bunk wrote: > >On Fri, Mar 04, 2005 at 12:33:19PM -0500, Jeff Garzik wrote: > > > >>akpm@osdl.org wrote: > >> > >>>From: Adrian Bunk > >>> > >>>Some of the options that needlessly wrote in their help text which > >>>options > >>>they do select (patch already sent) didn't obey the most important rule > >>>of > >>>select > >>> > >>>If you select something, you have to ensure that the dependencies > >>>of what you do select are fulfilled. > >> > >>>diff -puN net/ieee80211/Kconfig~fix-buggy-ieee80211_crypt_-selects > >>>net/ieee80211/Kconfig > >>>--- 25/net/ieee80211/Kconfig~fix-buggy-ieee80211_crypt_-selects > >>>2005-02-28 14:49:54.000000000 -0800 > >>>+++ 25-akpm/net/ieee80211/Kconfig 2005-02-28 14:49:54.000000000 -0800 > >>>@@ -44,6 +44,7 @@ config IEEE80211_CRYPT_WEP > >>>config IEEE80211_CRYPT_CCMP > >>> tristate "IEEE 802.11i CCMP support" > >>> depends on IEEE80211 > >>>+ select CRYPTO > >>> select CRYPTO_AES > >>> ---help--- > >>> Include software based cipher suites in support of IEEE 802.11i > >>>@@ -56,6 +57,7 @@ config IEEE80211_CRYPT_CCMP > >>>config IEEE80211_CRYPT_TKIP > >>> tristate "IEEE 802.11i TKIP encryption" > >>> depends on IEEE80211 > >>>+ select CRYPTO > >>> select CRYPTO_MICHAEL_MIC > >>> ---help--- > >> > >> > >>You are resending the old patch that is incorrect. We don't need > >>multiple selects, CRYPTO_AES and CRYPTO_MICHAEL_MIC should pull things in. > > > > > >As I already said, this implies that options like CRYPTO_AES and > >CRYPTO_MICHAEL_MIC can no longer depend on CRYPTO. > > No. Because CRYPTO_AES and CRYPTO_MICHAEL_MIC __obviously__ depend on > CRYPTO, it should select CRYPTO automatically given the existing entries. > > Otherwise, we must start specifying dependency chains in every damn > Kconfig entry, which is completely illogical and a maintenance nightmare. The way kconfig currently works, you have to ensure that the dependencies of what you select are fulfilled. And handling dependencies as select chains creates some subtle problems: Consider the following example: config A tristate "foo" depends on !B && (C || D) config E tristate "bar" select B config F tristate "42" select A With: A=n B=y C=n D=n E=y What values of the variables A-E do you expect exactly if the user turns on F? Or even better, the code in question as a example due to the current confusing CRYPTO_AES dependencies (discussed in another thread and will be solved): config IEEE80211_CRYPT_CCMP tristate "IEEE 802.11i CCMP support" depends on IEEE80211 select CRYPTO_AES config CRYPTO_AES tristate "AES cipher algorithms" depends on CRYPTO && !(X86 && !X86_64) On i386, should your "select CRYPTO_AES" set X86=n or X86_64=y ? This would create even nastier bugs if it was hidden somewhere in a dependency chain. Some people say that you mustn't select an user-visible option - this way you avoid any such problems. This would mean you weren't allowed to select CRYPTO or CRYPTO_AES or CRYPTO_MICHAEL_MIC. I'm less dogmatic regarding this because I care more about the usability of the kernel config system than about such rules, but what you want is simply not possible in a reasonable way. > Jeff cu Adrian -- "Is there not promise of rain?" Ling Tan asked suddenly out of the darkness. There had been need of rain for many days. "Only a promise," Lao Er said. Pearl S. Buck - Dragon Seed From rddunlap@osdl.org Fri Mar 4 15:21:27 2005 Received: with ECARTIS (v1.0.0; list netdev); Fri, 04 Mar 2005 15:21:33 -0800 (PST) Received: from smtp.osdl.org (fire.osdl.org [65.172.181.4]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j24NLRSF026777 for ; Fri, 4 Mar 2005 15:21:27 -0800 Received: from shell0.pdx.osdl.net (fw.osdl.org [65.172.181.6]) by smtp.osdl.org (8.12.8/8.12.8) with ESMTP id j24NL4qi015345 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO); Fri, 4 Mar 2005 15:21:04 -0800 Received: from gargoyle.pdx.osdl.net (gargoyle.pdx.osdl.net [172.20.1.49]) by shell0.pdx.osdl.net (8.13.1/8.11.6) with SMTP id j24NL4of024829; Fri, 4 Mar 2005 15:21:04 -0800 Date: Fri, 4 Mar 2005 15:21:05 -0800 From: "Randy.Dunlap" To: chas@cmf.nrl.navy.mil, akpm Cc: netdev Subject: [PATCH] atm/zatm: fix section references Message-Id: <20050304152105.20b50328.rddunlap@osdl.org> Organization: OSDL X-Mailer: Sylpheed version 0.9.12 (GTK+ 1.2.10; i386-vine-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Received-SPF: pass (domain of rddunlap@osdl.org designates 65.172.181.6 as permitted sender) X-MIMEDefang-Filter: osdl$Revision: 1.104 $ X-Scanned-By: MIMEDefang 2.36 X-Virus-Scanned: ClamAV 0.83/745/Fri Mar 4 03:16:06 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 2407 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: rddunlap@osdl.org Precedence: bulk X-list: netdev Content-Length: 2436 Lines: 73 atm/zatm: fix text section references to __init text and __initdata; they should be __devinit instead of __init; Error: ./drivers/atm/zatm.o .text refers to 0000000000001abb R_X86_64_PC32 .init.text+0x0000000000000154 Error: ./drivers/atm/zatm.o .text refers to 0000000000001ad3 R_X86_64_PC32 .init.text+0x0000000000000154 Signed-off-by: Randy Dunlap diffstat:= drivers/atm/zatm.c | 12 ++++++------ 1 files changed, 6 insertions(+), 6 deletions(-) diff -Naurp ./drivers/atm/zatm.c~atm_zatm_sections ./drivers/atm/zatm.c --- ./drivers/atm/zatm.c~atm_zatm_sections 2005-03-01 23:37:50.000000000 -0800 +++ ./drivers/atm/zatm.c 2005-03-04 13:16:50.000000000 -0800 @@ -1090,7 +1090,7 @@ static irqreturn_t zatm_int(int irq,void /*----------------------------- (E)EPROM access -----------------------------*/ -static void __init eprom_set(struct zatm_dev *zatm_dev,unsigned long value, +static void __devinit eprom_set(struct zatm_dev *zatm_dev,unsigned long value, unsigned short cmd) { int error; @@ -1101,7 +1101,7 @@ static void __init eprom_set(struct zatm } -static unsigned long __init eprom_get(struct zatm_dev *zatm_dev, +static unsigned long __devinit eprom_get(struct zatm_dev *zatm_dev, unsigned short cmd) { unsigned int value; @@ -1114,7 +1114,7 @@ static unsigned long __init eprom_get(st } -static void __init eprom_put_bits(struct zatm_dev *zatm_dev, +static void __devinit eprom_put_bits(struct zatm_dev *zatm_dev, unsigned long data,int bits,unsigned short cmd) { unsigned long value; @@ -1129,7 +1129,7 @@ static void __init eprom_put_bits(struct } -static void __init eprom_get_byte(struct zatm_dev *zatm_dev, +static void __devinit eprom_get_byte(struct zatm_dev *zatm_dev, unsigned char *byte,unsigned short cmd) { int i; @@ -1145,7 +1145,7 @@ static void __init eprom_get_byte(struct } -static unsigned char __init eprom_try_esi(struct atm_dev *dev, +static unsigned char __devinit eprom_try_esi(struct atm_dev *dev, unsigned short cmd,int offset,int swap) { unsigned char buf[ZEPROM_SIZE]; @@ -1166,7 +1166,7 @@ static unsigned char __init eprom_try_es } -static void __init eprom_get_esi(struct atm_dev *dev) +static void __devinit eprom_get_esi(struct atm_dev *dev) { if (eprom_try_esi(dev,ZEPROM_V1_REG,ZEPROM_V1_ESI_OFF,1)) return; (void) eprom_try_esi(dev,ZEPROM_V2_REG,ZEPROM_V2_ESI_OFF,0); --- From rddunlap@osdl.org Fri Mar 4 15:21:27 2005 Received: with ECARTIS (v1.0.0; list netdev); Fri, 04 Mar 2005 15:21:33 -0800 (PST) Received: from smtp.osdl.org (fire.osdl.org [65.172.181.4]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j24NLQnF026776 for ; Fri, 4 Mar 2005 15:21:27 -0800 Received: from shell0.pdx.osdl.net (fw.osdl.org [65.172.181.6]) by smtp.osdl.org (8.12.8/8.12.8) with ESMTP id j24NL4qi015341 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO); Fri, 4 Mar 2005 15:21:04 -0800 Received: from gargoyle.pdx.osdl.net (gargoyle.pdx.osdl.net [172.20.1.49]) by shell0.pdx.osdl.net (8.13.1/8.11.6) with SMTP id j24NL3rV024823; Fri, 4 Mar 2005 15:21:04 -0800 Date: Fri, 4 Mar 2005 15:19:37 -0800 From: "Randy.Dunlap" To: chas@cmf.nrl.navy.mil Cc: netdev , akpm Subject: [PATCH] atm/lanai: fix section references Message-Id: <20050304151937.68eb11c0.rddunlap@osdl.org> Organization: OSDL X-Mailer: Sylpheed version 0.9.12 (GTK+ 1.2.10; i386-vine-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Received-SPF: pass (domain of rddunlap@osdl.org designates 65.172.181.6 as permitted sender) X-MIMEDefang-Filter: osdl$Revision: 1.104 $ X-Scanned-By: MIMEDefang 2.36 X-Virus-Scanned: ClamAV 0.83/745/Fri Mar 4 03:16:06 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 2406 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: rddunlap@osdl.org Precedence: bulk X-list: netdev Content-Length: 3858 Lines: 110 atm/lanai: fix text section references to __init text; they should be __devinit instead of __init; Error: ./drivers/atm/lanai.o .text refers to 0000000000002105 R_X86_64_PC32 .init.text+0x0000000000000021 Error: ./drivers/atm/lanai.o .text refers to 0000000000002116 R_X86_64_PC32 .init.text+0x0000000000000021 Error: ./drivers/atm/lanai.o .text refers to 0000000000002132 R_X86_64_PC32 .init.text+0x0000000000000021 Signed-off-by: Randy Dunlap diffstat:= drivers/atm/lanai.c | 20 ++++++++++---------- 1 files changed, 10 insertions(+), 10 deletions(-) diff -Naurp ./drivers/atm/lanai.c~atm_lanai_sections ./drivers/atm/lanai.c --- ./drivers/atm/lanai.c~atm_lanai_sections 2005-03-01 23:37:50.000000000 -0800 +++ ./drivers/atm/lanai.c 2005-03-04 13:44:45.000000000 -0800 @@ -566,7 +566,7 @@ static int __init sram_test_word( return -EIO; } -static int __init sram_test_pass(const struct lanai_dev *lanai, u32 pattern) +static int __devinit sram_test_pass(const struct lanai_dev *lanai, u32 pattern) { int offset, result = 0; for (offset = 0; offset < SRAM_BYTES && result == 0; offset += 4) @@ -574,7 +574,7 @@ static int __init sram_test_pass(const s return result; } -static int __init sram_test_and_clear(const struct lanai_dev *lanai) +static int __devinit sram_test_and_clear(const struct lanai_dev *lanai) { #ifdef FULL_MEMORY_TEST int result; @@ -860,7 +860,7 @@ static inline void aal0_buffer_free(stru #ifndef READ_EEPROM /* Stub functions to use if EEPROM reading is disabled */ -static int __init eeprom_read(struct lanai_dev *lanai) +static int __devinit eeprom_read(struct lanai_dev *lanai) { printk(KERN_INFO DEV_LABEL "(itf %d): *NOT* reading EEPROM\n", lanai->number); @@ -868,7 +868,7 @@ static int __init eeprom_read(struct lan return 0; } -static int __init eeprom_validate(struct lanai_dev *lanai) +static int __devinit eeprom_validate(struct lanai_dev *lanai) { lanai->serialno = 0; lanai->magicno = EEPROM_MAGIC_VALUE; @@ -877,7 +877,7 @@ static int __init eeprom_validate(struct #else /* READ_EEPROM */ -static int __init eeprom_read(struct lanai_dev *lanai) +static int __devinit eeprom_read(struct lanai_dev *lanai) { int i, address; u8 data; @@ -953,7 +953,7 @@ static inline u32 eeprom_be4(const struc } /* Checksum/validate EEPROM contents */ -static int __init eeprom_validate(struct lanai_dev *lanai) +static int __devinit eeprom_validate(struct lanai_dev *lanai) { int i, s; u32 v; @@ -1449,7 +1449,7 @@ static void vcc_rx_aal0(struct lanai_dev #include #endif -static int __init vcc_table_allocate(struct lanai_dev *lanai) +static int __devinit vcc_table_allocate(struct lanai_dev *lanai) { #ifdef VCCTABLE_GETFREEPAGE APRINTK((lanai->num_vci) * sizeof(struct lanai_vcc *) <= PAGE_SIZE, @@ -1596,7 +1596,7 @@ static void lanai_reset(struct lanai_dev /* * Allocate service buffer and tell card about it */ -static int __init service_buffer_allocate(struct lanai_dev *lanai) +static int __devinit service_buffer_allocate(struct lanai_dev *lanai) { lanai_buf_allocate(&lanai->service, SERVICE_ENTRIES * 4, 8, lanai->pci); @@ -1952,7 +1952,7 @@ static int check_board_id_and_rev(const /* -------------------- PCI INITIALIZATION/SHUTDOWN: */ -static int __init lanai_pci_start(struct lanai_dev *lanai) +static int __devinit lanai_pci_start(struct lanai_dev *lanai) { struct pci_dev *pci = lanai->pci; int result; @@ -2148,7 +2148,7 @@ static inline void lanai_cbr_shutdown(st /* -------------------- OPERATIONS: */ /* setup a newly detected device */ -static int __init lanai_dev_open(struct atm_dev *atmdev) +static int __devinit lanai_dev_open(struct atm_dev *atmdev) { struct lanai_dev *lanai = (struct lanai_dev *) atmdev->dev_data; unsigned long raw_base; --- From rddunlap@osdl.org Fri Mar 4 15:21:35 2005 Received: with ECARTIS (v1.0.0; list netdev); Fri, 04 Mar 2005 15:21:40 -0800 (PST) Received: from smtp.osdl.org (fire.osdl.org [65.172.181.4]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j24NLYeZ026793 for ; Fri, 4 Mar 2005 15:21:35 -0800 Received: from shell0.pdx.osdl.net (fw.osdl.org [65.172.181.6]) by smtp.osdl.org (8.12.8/8.12.8) with ESMTP id j24NL4qi015343 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO); Fri, 4 Mar 2005 15:21:04 -0800 Received: from gargoyle.pdx.osdl.net (gargoyle.pdx.osdl.net [172.20.1.49]) by shell0.pdx.osdl.net (8.13.1/8.11.6) with SMTP id j24NL4lx024826; Fri, 4 Mar 2005 15:21:04 -0800 Date: Fri, 4 Mar 2005 15:19:56 -0800 From: "Randy.Dunlap" To: myxie@debian.org, chas@cmf.nrl.navy.mil Cc: netdev , akpm Subject: [PATCH] atm/ambassador: fix init section references Message-Id: <20050304151956.5725d408.rddunlap@osdl.org> Organization: OSDL X-Mailer: Sylpheed version 0.9.12 (GTK+ 1.2.10; i386-vine-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Received-SPF: pass (domain of rddunlap@osdl.org designates 65.172.181.6 as permitted sender) X-MIMEDefang-Filter: osdl$Revision: 1.104 $ X-Scanned-By: MIMEDefang 2.36 X-Virus-Scanned: ClamAV 0.83/745/Fri Mar 4 03:16:06 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 2408 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: rddunlap@osdl.org Precedence: bulk X-list: netdev Content-Length: 5652 Lines: 150 atm/ambassador: fix text section references to __init text and __initdata; The biggest negative about this AFAIK is that it makes ucode_data non-initdata, and that moves about 8 KB of data from .init.data to .data. Similarly, .text increases by approx. 1300 bytes (on x86-32). Error: ./drivers/atm/ambassador.o .text refers to 0000000000002a07 R_X86_64_PC32 .init.text+0x0000000000000149 Error: ./drivers/atm/ambassador.o .text refers to 0000000000002a45 R_X86_64_32S .init.data+0x0000000000000040 Error: ./drivers/atm/ambassador.o .text refers to 0000000000002a7c R_X86_64_PC32 .init.data+0x0000000000000020 Error: ./drivers/atm/ambassador.o .text refers to 0000000000002a83 R_X86_64_PC32 .init.data+0x000000000000001c Error: ./drivers/atm/ambassador.o .text refers to 0000000000002b40 R_X86_64_PC32 .init.text+0x0000000000000149 Error: ./drivers/atm/ambassador.o .text refers to 0000000000002bbc R_X86_64_PC32 .init.text+0x0000000000000149 Error: ./drivers/atm/ambassador.o .text refers to 0000000000002c0f R_X86_64_32S .init.data+0x0000000000000024 Error: ./drivers/atm/ambassador.o .text refers to 0000000000002c17 R_X86_64_32S .init.data+0x0000000000000020 Error: ./drivers/atm/ambassador.o .text refers to 0000000000002c3c R_X86_64_PC32 .init.data+0xfffffffffffffffc Error: ./drivers/atm/ambassador.o .text refers to 0000000000002c6a R_X86_64_PC32 .init.text+0x0000000000000149 Error: ./drivers/atm/ambassador.o .text refers to 0000000000002c77 R_X86_64_32S .init.data+0x0000000000000040 Signed-off-by: Randy Dunlap diffstat:= drivers/atm/ambassador.c | 28 ++++++++++++++-------------- 1 files changed, 14 insertions(+), 14 deletions(-) diff -Naurp ./drivers/atm/ambassador.c~atm_ambass_sections ./drivers/atm/ambassador.c --- ./drivers/atm/ambassador.c~atm_ambass_sections 2005-03-01 23:37:48.000000000 -0800 +++ ./drivers/atm/ambassador.c 2005-03-04 14:31:49.000000000 -0800 @@ -296,16 +296,16 @@ static inline void __init show_version ( #endif #define UCODE2(x) #x -static u32 __initdata ucode_start = +static u32 __devinitdata ucode_start = #include UCODE(start) ; -static region __initdata ucode_regions[] = { +static region __devinitdata ucode_regions[] = { #include UCODE(regions) { 0, 0 } }; -static u32 __initdata ucode_data[] = { +static u32 __devinitdata ucode_data[] = { #include UCODE(data) 0xdeadbeef }; @@ -1539,7 +1539,7 @@ static void do_housekeeping (unsigned lo /********** creation of communication queues **********/ -static int __init create_queues (amb_dev * dev, unsigned int cmds, +static int __devinit create_queues (amb_dev * dev, unsigned int cmds, unsigned int txs, unsigned int * rxs, unsigned int * rx_buffer_sizes) { unsigned char pool; @@ -1769,7 +1769,7 @@ static int decode_loader_result (loader return res; } -static int __init do_loader_command (volatile loader_block * lb, +static int __devinit do_loader_command (volatile loader_block * lb, const amb_dev * dev, loader_command cmd) { unsigned long timeout; @@ -1825,7 +1825,7 @@ static int __init do_loader_command (vol /* loader: determine loader version */ -static int __init get_loader_version (loader_block * lb, +static int __devinit get_loader_version (loader_block * lb, const amb_dev * dev, u32 * version) { int res; @@ -1841,7 +1841,7 @@ static int __init get_loader_version (lo /* loader: write memory data blocks */ -static int __init loader_write (loader_block * lb, +static int __devinit loader_write (loader_block * lb, const amb_dev * dev, const u32 * data, u32 address, unsigned int count) { unsigned int i; @@ -1860,7 +1860,7 @@ static int __init loader_write (loader_b /* loader: verify memory data blocks */ -static int __init loader_verify (loader_block * lb, +static int __devinit loader_verify (loader_block * lb, const amb_dev * dev, const u32 * data, u32 address, unsigned int count) { unsigned int i; @@ -1885,7 +1885,7 @@ static int __init loader_verify (loader_ /* loader: start microcode */ -static int __init loader_start (loader_block * lb, +static int __devinit loader_start (loader_block * lb, const amb_dev * dev, u32 address) { PRINTD (DBG_FLOW|DBG_LOAD, "loader_start"); @@ -1961,7 +1961,7 @@ static int amb_reset (amb_dev * dev, int /********** transfer and start the microcode **********/ -static int __init ucode_init (loader_block * lb, amb_dev * dev) { +static int __devinit ucode_init (loader_block * lb, amb_dev * dev) { unsigned int i = 0; unsigned int total = 0; const u32 * pointer = ucode_data; @@ -2011,7 +2011,7 @@ static inline u32 bus_addr(void * addr) return cpu_to_be32 (virt_to_bus (addr)); } -static int __init amb_talk (amb_dev * dev) { +static int __devinit amb_talk (amb_dev * dev) { adap_talk_block a; unsigned char pool; unsigned long timeout; @@ -2058,7 +2058,7 @@ static int __init amb_talk (amb_dev * de } // get microcode version -static void __init amb_ucode_version (amb_dev * dev) { +static void __devinit amb_ucode_version (amb_dev * dev) { u32 major; u32 minor; command cmd; @@ -2085,7 +2085,7 @@ static u8 bit_swap (u8 byte) } // get end station address -static void __init amb_esi (amb_dev * dev, u8 * esi) { +static void __devinit amb_esi (amb_dev * dev, u8 * esi) { u32 lower4; u16 upper2; command cmd; @@ -2131,7 +2131,7 @@ static void fixup_plx_window (amb_dev *d return; } -static int __init amb_init (amb_dev * dev) +static int __devinit amb_init (amb_dev * dev) { loader_block lb; --- From jdmason@us.ibm.com Fri Mar 4 15:29:11 2005 Received: with ECARTIS (v1.0.0; list netdev); Fri, 04 Mar 2005 15:29:15 -0800 (PST) Received: from e3.ny.us.ibm.com (e3.ny.us.ibm.com [32.97.182.143]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j24NTBhT028502 for ; Fri, 4 Mar 2005 15:29:11 -0800 Received: from d01relay04.pok.ibm.com (d01relay04.pok.ibm.com [9.56.227.236]) by e3.ny.us.ibm.com (8.12.11/8.12.11) with ESMTP id j24NT5iV029733 for ; Fri, 4 Mar 2005 18:29:05 -0500 Received: from d01av04.pok.ibm.com (d01av04.pok.ibm.com [9.56.224.64]) by d01relay04.pok.ibm.com (8.12.10/NCO/VER6.6) with ESMTP id j24NT5LE239428 for ; Fri, 4 Mar 2005 18:29:05 -0500 Received: from d01av04.pok.ibm.com (loopback [127.0.0.1]) by d01av04.pok.ibm.com (8.12.11/8.12.11) with ESMTP id j24NT5nY003562 for ; Fri, 4 Mar 2005 18:29:05 -0500 Received: from [9.48.62.169] ([9.48.62.169]) by d01av04.pok.ibm.com (8.12.11/8.12.11) with ESMTP id j24NT47i003543; Fri, 4 Mar 2005 18:29:05 -0500 From: Jon Mason Organization: IBM To: Francois Romieu Subject: Re: r8169: panic on 2.6.11 Date: Fri, 4 Mar 2005 17:28:53 -0600 User-Agent: KMail/1.7.2 Cc: Stephen Hemminger , netdev@oss.sgi.com References: <20050304132804.270cf05b@dxpl.pdx.osdl.net> <20050304145317.772859da@dxpl.pdx.osdl.net> <20050304230214.GC1148@electric-eye.fr.zoreil.com> In-Reply-To: <20050304230214.GC1148@electric-eye.fr.zoreil.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200503041728.54026.jdmason@us.ibm.com> X-Virus-Scanned: ClamAV 0.83/745/Fri Mar 4 03:16:06 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 2409 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: jdmason@us.ibm.com Precedence: bulk X-list: netdev Content-Length: 2129 Lines: 64 On Friday 04 March 2005 05:02 pm, Francois Romieu wrote: > Stephen Hemminger : > [...] > > > NAPI is not enabled, it is the IRQ version. Hitting > > > > Added instrumentation:. > > > > skb=0xd1e28380 len=8172 head=d1e32000 data=d1e32012 tail=d1e33ffe > > end=d1e32620 > > > > Looks like the board is running back-to-back packets together, MTU is > > 1500. No Jumbo frames exist on my little network and the gigabit switch > > (Netgear) won't even take them. Probably a chip bug. > > /me scratches head: play with the interframe gap ? > > > Need to add a check for len > mtu before processing? > > Please. > > diff -puN drivers/net/r8169.c~r8169-470 drivers/net/r8169.c > --- linux-2.6.11/drivers/net/r8169.c~r8169-470 2005-03-04 > 22:51:35.038710839 +0100 +++ linux-2.6.11-fr/drivers/net/r8169.c 2005-03-04 > 23:16:29.422289316 +0100 @@ -2194,6 +2194,7 @@ rtl8169_rx_interrupt(struct > net_device * > int pkt_size = (status & 0x00001FFF) - 4; > void (*pci_action)(struct pci_dev *, dma_addr_t, > size_t, int) = pci_dma_sync_single_for_device; > + static int show_size = 0; > > rtl8169_rx_csum(skb, desc); > > @@ -2210,6 +2211,24 @@ rtl8169_rx_interrupt(struct net_device * > pci_action(tp->pci_dev, le64_to_cpu(desc->addr), > tp->rx_buf_sz, PCI_DMA_FROMDEVICE); > > + if (pkt_size >= tp->rx_buf_sz) { > + show_size = 1; > + pkt_size = tp->rx_buf_sz; > + } Shouldn't the above be dev->mtu (instead of tp->rx_buf_sz), otherwise there won't be enough room for ethernet header, CRC, etc. > + > + if (show_size) { > + printk(KERN_INFO "%s: pkt_size=%d\n", dev->name, > + pkt_size); > + printk(KERN_INFO "%s: opts1= %08x\n", dev->name, > + desc->opts1); > + printk(KERN_INFO "%s: opts2= %08x\n", dev->name, > + desc->opts2); > + printk(KERN_INFO "%s: addrl= %08x\n", dev->name, > + (u32)desc->addr); > + printk(KERN_INFO "%s: addrh= %08x\n", dev->name, > + (u32)(desc->addr >> 32)); > + } > + > skb->dev = dev; > skb_put(skb, pkt_size); > skb->protocol = eth_type_trans(skb, dev); > > _ From herbert@gondor.apana.org.au Fri Mar 4 15:33:09 2005 Received: with ECARTIS (v1.0.0; list netdev); Fri, 04 Mar 2005 15:33:16 -0800 (PST) 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 j24NX82B029133 for ; Fri, 4 Mar 2005 15:33:08 -0800 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 1D7MHr-0007Hb-00; Sat, 05 Mar 2005 10:32:51 +1100 Received: from herbert by gondolin.me.apana.org.au with local (Exim 3.36 #1 (Debian)) id 1D7MHE-00078g-00; Sat, 05 Mar 2005 10:32:12 +1100 Date: Sat, 5 Mar 2005 10:32:12 +1100 To: Thomas Graf Cc: davem@davemloft.net, netdev@oss.sgi.com Subject: Re: [PATCH] [NET]: Fix deletion of local addresses only varying in prefix length Message-ID: <20050304233212.GA27421@gondor.apana.org.au> References: <20050304012003.GA31837@postel.suug.ch> <20050304131419.GE31837@postel.suug.ch> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20050304131419.GE31837@postel.suug.ch> User-Agent: Mutt/1.5.6+20040907i From: Herbert Xu X-Virus-Scanned: ClamAV 0.83/745/Fri Mar 4 03:16:06 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 2410 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: herbert@gondor.apana.org.au Precedence: bulk X-list: netdev Content-Length: 990 Lines: 23 On Fri, Mar 04, 2005 at 02:14:19PM +0100, Thomas Graf wrote: > > I do not agree but I might have a better idea. Let's change iproute2 > to provide a prefixlength of 0 if no prefix was specified and only > compare the prefixes if it is non zero. This allows for accurate A bigger problem with this approach is that we don't have a magical way of getting people to upgrade their ip(8) binary. To do this safely, we'll need a way of indicating that the ip(8) binary is setting the prefixlen in the way you propose. Perhaps this can be done using a new IFA payload type. Alternatively you can use the value of /32 to indicate a wildcard match instead of /0. After all, /0 has a specific meaning in this context so it's just as arbitrary to choose /0 as opposed to /32. Cheers, -- Visit Openswan at http://www.openswan.org/ Email: Herbert Xu ~{PmV>HI~} Home Page: http://gondor.apana.org.au/~herbert/ PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt From alessandro.suardi@gmail.com Fri Mar 4 15:39:33 2005 Received: with ECARTIS (v1.0.0; list netdev); Fri, 04 Mar 2005 15:39:39 -0800 (PST) Received: from rproxy.gmail.com (rproxy.gmail.com [64.233.170.200]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j24NdW4q029783 for ; Fri, 4 Mar 2005 15:39:32 -0800 Received: by rproxy.gmail.com with SMTP id r35so696476rna for ; Fri, 04 Mar 2005 15:39:32 -0800 (PST) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:reply-to:to:subject:in-reply-to:mime-version:content-type:content-transfer-encoding:references; b=U588urwbqaMGQBJ19wBEtrq46l9fTh4P69l4E+wUN6paBzSqz+bsRZRW4E6r3S4qHoFOhEc87jM658U6VeyxIGuuW81N7D+LEqKuHE0nYfT84/j8WGhYgB2HzNlzgo+QZIuiAyY68IvcflazaoZ4jKiGJO52vVFi6O4Vyav6x40= Received: by 10.38.59.80 with SMTP id h80mr25237rna; Fri, 04 Mar 2005 15:39:32 -0800 (PST) Received: by 10.38.13.15 with HTTP; Fri, 4 Mar 2005 15:39:31 -0800 (PST) Message-ID: <5a4c581d0503041539e1ab137@mail.gmail.com> Date: Sat, 5 Mar 2005 00:39:31 +0100 From: Alessandro Suardi Reply-To: Alessandro Suardi To: linux-kernel@vger.kernel.org, netdev@oss.sgi.com Subject: Fwd: non-fatal oops with EIP at skb_release_data, available for debugging In-Reply-To: <5a4c581d05030412482a596ee5@mail.gmail.com> Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit References: <5a4c581d05030412482a596ee5@mail.gmail.com> X-Virus-Scanned: ClamAV 0.83/745/Fri Mar 4 03:16:06 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 2411 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: alessandro.suardi@gmail.com Precedence: bulk X-list: netdev Content-Length: 2714 Lines: 75 Hmm, doesn't seem this ever made the lkml, no idea why... CC'ing netdev in case someone can spot anything interesting The machine (running FC3) is still up and running after the oops. ---------- Forwarded message ---------- From: Alessandro Suardi Date: Fri, 4 Mar 2005 21:48:18 +0100 Subject: non-fatal oops with EIP at skb_release_data, available for debugging To: Linux Kernel Mailing List This is my K7-800, 256MB RAM machine running as ed2k/bittorrent 24/7 box... metacity died, but the windows are still alive (and working) so if someone wants to get more info about it, just ping me... [root@donkey ~]# cat /proc/version Linux version 2.6.11-rc3-bk8 (asuardi@donkey) (gcc version 3.4.2 20041017 (Red Hat 3.4.2-6.fc3)) #1 Sat Feb 12 00:01:28 CET 2005 [root@donkey ~]# lsmod Module Size Used by loop 15368 - nls_iso8859_1 3840 - parport_pc 29444 - parport 24704 - 8139too 24896 - floppy 57392 - From the dmesg ring: kernel BUG at include/linux/mm.h:343! invalid operand: 0000 [#1] PREEMPT Modules linked in: loop nls_iso8859_1 parport_pc parport 8139too floppy CPU: 0 EIP: 0060:[] Not tainted VLI EFLAGS: 00210256 (2.6.11-rc3-bk8) EIP is at skb_release_data+0x92/0xa0 eax: 00000000 ebx: 00000000 ecx: cca36f80 edx: c11a97c0 esi: c4205f20 edi: c4205f20 ebp: cd149dcc esp: cd149dc4 ds: 007b es: 007b ss: 0068 Process metacity (pid: 2109, threadinfo=cd148000 task=ce8935d0) Stack: c4205f20 00000000 cd149dd8 c02da6bb c6e9a0c0 cd149df8 c02da737 c5134250 00000000 c4205f20 c5134250 c4205f20 c5134250 cd149e4c c02feba6 00000000 00000040 cc68c454 00000000 00000001 cc68c444 cd148000 00000001 00000000 Call Trace: [] show_stack+0x7a/0x90 [] show_registers+0x14d/0x1c0 [] die+0xe4/0x180 [] do_invalid_op+0xa3/0xb0 [] error_code+0x2b/0x30 [] kfree_skbmem+0xb/0x20 [] __kfree_skb+0x67/0xf0 [] tcp_recvmsg+0x5f6/0x710 [] sock_common_recvmsg+0x46/0x60 [] sock_aio_read+0xee/0x100 [] do_sync_read+0x97/0xf0 [] vfs_read+0x91/0x120 [] sys_read+0x3d/0x70 [] sysenter_past_esp+0x52/0x75 Code: c9 e9 03 e5 e5 ff 8d 76 00 5b 5e c9 c3 89 d0 e8 c5 f2 e5 ff eb cf 89 f0 e8 0c ff ff ff 5b 8b 86 98 00 00 00 5e c9 e9 de e4 e5 ff <0f> 0b 57 01 ab c5 35 c0 eb a5 8d 74 26 00 55 89 e5 53 89 c3 e8 Thanks, --alessandro "There is no distance that I don't see I do have a will - No limit to my reach" (Wallflowers, "Empire In My Mind") From shemminger@osdl.org Fri Mar 4 15:49:01 2005 Received: with ECARTIS (v1.0.0; list netdev); Fri, 04 Mar 2005 15:49:11 -0800 (PST) Received: from smtp.osdl.org (fire.osdl.org [65.172.181.4]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j24NmuOg030465 for ; Fri, 4 Mar 2005 15:49:01 -0800 Received: from shell0.pdx.osdl.net (fw.osdl.org [65.172.181.6]) by smtp.osdl.org (8.12.8/8.12.8) with ESMTP id j24Nmlqi017727 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO); Fri, 4 Mar 2005 15:48:48 -0800 Received: from dxpl.pdx.osdl.net (dxpl.pdx.osdl.net [172.20.1.103]) by shell0.pdx.osdl.net (8.13.1/8.11.6) with ESMTP id j24Nmlhv026594; Fri, 4 Mar 2005 15:48:47 -0800 Date: Fri, 4 Mar 2005 15:49:03 -0800 From: Stephen Hemminger To: Francois Romieu Cc: Jon Mason , netdev@oss.sgi.com Subject: Re: r8169: panic on 2.6.11 Message-ID: <20050304154903.7b7e0fb1@dxpl.pdx.osdl.net> In-Reply-To: <200503041728.54026.jdmason@us.ibm.com> References: <20050304132804.270cf05b@dxpl.pdx.osdl.net> <20050304145317.772859da@dxpl.pdx.osdl.net> <20050304230214.GC1148@electric-eye.fr.zoreil.com> <200503041728.54026.jdmason@us.ibm.com> Organization: Open Source Development Lab X-Mailer: Sylpheed-Claws 1.0.1 (GTK+ 1.2.10; x86_64-unknown-linux-gnu) X-Face: &@E+xe?c%:&e4D{>f1O<&U>2qwRREG5!}7R4;D<"NO^UI2mJ[eEOA2*3>(`Th.yP,VDPo9$ /`~cw![cmj~~jWe?AHY7D1S+\}5brN0k*NE?pPh_'_d>6;XGG[\KDRViCfumZT3@[ Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Received-SPF: pass (domain of shemminger@osdl.org designates 65.172.181.6 as permitted sender) X-MIMEDefang-Filter: osdl$Revision: 1.104 $ X-Scanned-By: MIMEDefang 2.36 X-Virus-Scanned: ClamAV 0.83/745/Fri Mar 4 03:16:06 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 2412 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: shemminger@osdl.org Precedence: bulk X-list: netdev Content-Length: 12076 Lines: 244 I am really killing this poor beast, the target is a 1.2 Ghz Celeron and it is trying to handle 1,000,000 packets/sec (from tg3 Opteron) Added this and took out "too much work at interrupt message" --- drivers/net/r8169.c.orig 2005-03-04 13:19:08.000000000 -0800 +++ drivers/net/r8169.c 2005-03-04 15:41:30.000000000 -0800 @@ -2210,6 +2210,16 @@ pci_action(tp->pci_dev, le64_to_cpu(desc->addr), tp->rx_buf_sz, PCI_DMA_FROMDEVICE); + if (pkt_size > tp->rx_buf_sz) { + printk(KERN_WARNING "%s: status=%x opts=%x opts2 =%x addr=%x:%x\n", + dev->name, status, desc->opts1, + desc->opts2, + (u32) (desc->addr >> 32), + (u32) desc->addr); + + goto ditch; + } + skb->dev = dev; skb_put(skb, pkt_size); skb->protocol = eth_type_trans(skb, dev); @@ -2222,6 +2232,7 @@ tp->stats.rx_packets++; } + ditch: cur_rx++; rx_left--; } And got this (before it died): eth0: status=803ff0 opts=803ff0 opts2=0 addr=0:106ad012 eth0: status=803ff0 opts=803ff0 opts2=0 addr=0:15194812 eth0: status=803ff0 opts=803ff0 opts2=0 addr=0:15194012 eth0: status=803ff0 opts=803ff0 opts2=0 addr=0:9efb812 eth0: status=803ff0 opts=803ff0 opts2=0 addr=0:9efb012 eth0: status=803ff0 opts=803ff0 opts2=0 addr=0:10215812 eth0: status=803ff0 opts=803ff0 opts2=0 addr=0:10215012 eth0: status=803ff0 opts=803ff0 opts2=0 addr=0:8de2812 eth0: status=803ff0 opts=803ff0 opts2=0 addr=0:8de2012 eth0: status=10803ff0 opts=10803ff0 opts2=0 addr=0:1559a812 eth0: status=20803ff0 opts=20803ff0 opts2=0 addr=0:10782012 eth0: status=803ff0 opts=803ff0 opts2=0 addr=0:b7f3812 eth0: status=803ff0 opts=803ff0 opts2=0 addr=0:b7f3012 eth0: status=803ff0 opts=803ff0 opts2=0 addr=0:15125812 eth0: status=20803ff0 opts=20803ff0 opts2=0 addr=0:9ef9812 eth0: status=803ff0 opts=803ff0 opts2=0 addr=0:9ef9012 eth0: status=803ff0 opts=803ff0 opts2=0 addr=0:15707812 eth0: status=803ff0 opts=803ff0 opts2=0 addr=0:15707012 eth0: status=803ff0 opts=803ff0 opts2=0 addr=0:588c812 eth0: status=803ff0 opts=803ff0 opts2=0 addr=0:588c012 eth0: status=803ff0 opts=803ff0 opts2=0 addr=0:15120812 eth0: status=803ff0 opts=803ff0 opts2=0 addr=0:15120012 eth0: status=803ff0 opts=803ff0 opts2=0 addr=0:12b2c812 eth0: status=803ff0 opts=803ff0 opts2=0 addr=0:12b2c012 eth0: status=10803ff0 opts=10803ff0 opts2=0 addr=0:6561812 eth0: status=20803ff0 opts=20803ff0 opts2=0 addr=0:6561012 eth0: status=803ff0 opts=803ff0 opts2=0 addr=0:13bea812 eth0: status=803ff0 opts=803ff0 opts2=0 addr=0:13bea012 eth0: status=803ff0 opts=803ff0 opts2=0 addr=0:112b4812 eth0: status=803ff0 opts=803ff0 opts2=0 addr=0:112b4012 eth0: status=803ff0 opts=803ff0 opts2=0 addr=0:157d7812 eth0: status=803ff0 opts=803ff0 opts2=0 addr=0:157d7012 eth0: status=803ff0 opts=803ff0 opts2=0 addr=0:39a5812 eth0: status=803ff0 opts=803ff0 opts2=0 addr=0:39a5012 eth0: status=803ff0 opts=803ff0 opts2=0 addr=0:58c3812 eth0: status=10803ff0 opts=10803ff0 opts2=0 addr=0:58c3012 eth0: status=20803ff0 opts=20803ff0 opts2=0 addr=0:1582f812 eth0: status=803ff0 opts=803ff0 opts2=0 addr=0:1582f012 eth0: status=803ff0 opts=803ff0 opts2=0 addr=0:116f6812 eth0: status=803ff0 opts=803ff0 opts2=0 addr=0:116f6012 eth0: status=803ff0 opts=803ff0 opts2=0 addr=0:109f0812 eth0: status=803ff0 opts=803ff0 opts2=0 addr=0:109f0012 eth0: status=803ff0 opts=803ff0 opts2=0 addr=0:13b82812 eth0: status=803ff0 opts=803ff0 opts2=0 addr=0:13b82012 eth0: status=803ff0 opts=803ff0 opts2=0 addr=0:ce31812 eth0: status=803ff0 opts=803ff0 opts2=0 addr=0:ce31012 eth0: status=10803ff0 opts=10803ff0 opts2=0 addr=0:29d3812 eth0: status=20803ff0 opts=20803ff0 opts2=0 addr=0:29d3012 eth0: status=803ff0 opts=803ff0 opts2=0 addr=0:b3b4812 eth0: status=803ff0 opts=803ff0 opts2=0 addr=0:b3b4012 eth0: status=803ff0 opts=803ff0 opts2=0 addr=0:5a73812 eth0: status=803ff0 opts=803ff0 opts2=0 addr=0:5a73012 eth0: status=803ff0 opts=803ff0 opts2=0 addr=0:d288812 eth0: status=803ff0 opts=803ff0 opts2=0 addr=0:d288012 eth0: status=803ff0 opts=803ff0 opts2=0 addr=0:107e3812 eth0: status=803ff0 opts=803ff0 opts2=0 addr=0:107e3012 eth0: status=803ff0 opts=803ff0 opts2=0 addr=0:15198812 eth0: status=10803ff0 opts=10803ff0 opts2=0 addr=0:15198012 eth0: status=20803ff0 opts=20803ff0 opts2=0 addr=0:16654812 eth0: status=803ff0 opts=803ff0 opts2=0 addr=0:16654012 eth0: status=803ff0 opts=803ff0 opts2=0 addr=0:16741812 eth0: status=803ff0 opts=803ff0 opts2=0 addr=0:16741012 eth0: status=803ff0 opts=803ff0 opts2=0 addr=0:b911812 eth0: status=803ff0 opts=803ff0 opts2=0 addr=0:b911012 eth0: status=803ff0 opts=803ff0 opts2=0 addr=0:12e5d812 eth0: status=24829808 opts=24829808 opts2=0 addr=0:a6ee012 eth0: status=4829808 opts=4829808 opts2=0 addr=0:127ff812 eth0: status=4829808 opts=4829808 opts2=0 addr=0:127ff012 eth0: status=14829808 opts=14829808 opts2=0 addr=0:16b84812 eth0: status=20802842 opts=20802842 opts2=0 addr=0:16b84012 eth0: status=802842 opts=802842 opts2=0 addr=0:125d1812 eth0: status=802842 opts=802842 opts2=0 addr=0:125d1012 eth0: status=802842 opts=802842 opts2=0 addr=0:11104812 eth0: status=802842 opts=802842 opts2=0 addr=0:11104012 eth0: status=802842 opts=802842 opts2=0 addr=0:636a812 eth0: status=10802842 opts=10802842 opts2=0 addr=0:636a012 eth0: status=20803ff0 opts=20803ff0 opts2=0 addr=0:138d5812 eth0: status=803ff0 opts=803ff0 opts2=0 addr=0:138d5012 eth0: status=803ff0 opts=803ff0 opts2=0 addr=0:11cb0812 eth0: status=803ff0 opts=803ff0 opts2=0 addr=0:11cb0012 eth0: status=803ff0 opts=803ff0 opts2=0 addr=0:88a4812 eth0: status=803ff0 opts=803ff0 opts2=0 addr=0:88a4012 eth0: status=803ff0 opts=803ff0 opts2=0 addr=0:1082a812 eth0: status=803ff0 opts=803ff0 opts2=0 addr=0:1082a012 eth0: status=803ff0 opts=803ff0 opts2=0 addr=0:168af812 eth0: status=803ff0 opts=803ff0 opts2=0 addr=0:168af012 eth0: status=10803ff0 opts=10803ff0 opts2=0 addr=0:1660f812 eth0: status=20803ff0 opts=20803ff0 opts2=0 addr=0:112c3012 eth0: status=803ff0 opts=803ff0 opts2=0 addr=0:c3e0812 eth0: status=803ff0 opts=803ff0 opts2=0 addr=0:c3e0012 eth0: status=803ff0 opts=803ff0 opts2=0 addr=0:1f7e812 eth0: status=803ff0 opts=803ff0 opts2=0 addr=0:1f7e012 eth0: status=803ff0 opts=803ff0 opts2=0 addr=0:2f5c812 eth0: status=803ff0 opts=803ff0 opts2=0 addr=0:2f5c012 eth0: status=803ff0 opts=803ff0 opts2=0 addr=0:132f6812 eth0: status=803ff0 opts=803ff0 opts2=0 addr=0:132f6012 eth0: status=803ff0 opts=803ff0 opts2=0 addr=0:c74a812 eth0: status=10803ff0 opts=10803ff0 opts2=0 addr=0:c74a012 eth0: status=20803ff0 opts=20803ff0 opts2=0 addr=0:11140812 eth0: status=803ff0 opts=803ff0 opts2=0 addr=0:11140012 eth0: status=803ff0 opts=803ff0 opts2=0 addr=0:127be812 eth0: status=803ff0 opts=803ff0 opts2=0 addr=0:127be012 eth0: status=803ff0 opts=803ff0 opts2=0 addr=0:16475812 eth0: status=803ff0 opts=803ff0 opts2=0 addr=0:16475012 eth0: status=803ff0 opts=803ff0 opts2=0 addr=0:114d7812 eth0: status=803ff0 opts=803ff0 opts2=0 addr=0:114d7012 eth0: status=803ff0 opts=803ff0 opts2=0 addr=0:87a3812 eth0: status=803ff0 opts=803ff0 opts2=0 addr=0:87a3012 eth0: status=10803ff0 opts=10803ff0 opts2=0 addr=0:11abb812 eth0: status=20803ff0 opts=20803ff0 opts2=0 addr=0:11c68012 eth0: status=803ff0 opts=803ff0 opts2=0 addr=0:8968812 eth0: status=803ff0 opts=803ff0 opts2=0 addr=0:8968012 eth0: status=803ff0 opts=803ff0 opts2=0 addr=0:5588812 eth0: status=803ff0 opts=803ff0 opts2=0 addr=0:5588012 eth0: status=803ff0 opts=803ff0 opts2=0 addr=0:14f77812 eth0: status=803ff0 opts=803ff0 opts2=0 addr=0:14f77012 eth0: status=803ff0 opts=803ff0 opts2=0 addr=0:8951812 eth0: status=803ff0 opts=803ff0 opts2=0 addr=0:8951012 eth0: status=803ff0 opts=803ff0 opts2=0 addr=0:5a6f812 eth0: status=10803ff0 opts=10803ff0 opts2=0 addr=0:5a6f012 eth0: status=20803ff0 opts=20803ff0 opts2=0 addr=0:12acc012 eth0: status=803ff0 opts=803ff0 opts2=0 addr=0:8e90812 eth0: status=803ff0 opts=803ff0 opts2=0 addr=0:8e90012 eth0: status=803ff0 opts=803ff0 opts2=0 addr=0:9d53812 eth0: status=803ff0 opts=803ff0 opts2=0 addr=0:9d53012 eth0: status=803ff0 opts=803ff0 opts2=0 addr=0:1390a812 eth0: status=803ff0 opts=803ff0 opts2=0 addr=0:1390a012 eth0: status=803ff0 opts=803ff0 opts2=0 addr=0:8952812 eth0: status=803ff0 opts=803ff0 opts2=0 addr=0:8952012 eth0: status=803ff0 opts=803ff0 opts2=0 addr=0:11a76812 eth0: status=10803ff0 opts=10803ff0 opts2=0 addr=0:11a76012 eth0: status=20803ff0 opts=20803ff0 opts2=0 addr=0:11167812 eth0: status=803ff0 opts=803ff0 opts2=0 addr=0:11167012 eth0: status=803ff0 opts=803ff0 opts2=0 addr=0:11548812 eth0: status=803ff0 opts=803ff0 opts2=0 addr=0:11548012 eth0: status=803ff0 opts=803ff0 opts2=0 addr=0:16428812 eth0: status=803ff0 opts=803ff0 opts2=0 addr=0:16428012 eth0: status=803ff0 opts=803ff0 opts2=0 addr=0:8762812 eth0: status=803ff0 opts=803ff0 opts2=0 addr=0:8762012 eth0: status=803ff0 opts=803ff0 opts2=0 addr=0:14139812 eth0: status=803ff0 opts=803ff0 opts2=0 addr=0:14139012 eth0: status=10803ff0 opts=10803ff0 opts2=0 addr=0:1157c812 eth0: status=20803ff0 opts=20803ff0 opts2=0 addr=0:8dcd012 eth0: status=803ff0 opts=803ff0 opts2=0 addr=0:8de8812 eth0: status=803ff0 opts=803ff0 opts2=0 addr=0:8de8012 eth0: status=803ff0 opts=803ff0 opts2=0 addr=0:8f08812 eth0: status=803ff0 opts=803ff0 opts2=0 addr=0:8f08012 eth0: status=803ff0 opts=803ff0 opts2=0 addr=0:116a4812 eth0: status=803ff0 opts=803ff0 opts2=0 addr=0:116a4012 eth0: status=803ff0 opts=803ff0 opts2=0 addr=0:11b98812 eth0: status=803ff0 opts=803ff0 opts2=0 addr=0:11b98012 eth0: status=803ff0 opts=803ff0 opts2=0 addr=0:8cf4812 eth0: status=10803ff0 opts=10803ff0 opts2=0 addr=0:8cf4012 Unable to handle kernel paging request at virtual address 4228b92f printing eip: c011772d *pde = 00000000 Oops: 0002 [#1] PREEMPT Modules linked in: r8169 i810 md5 ipv6 autofs4 sunrpc reiserfs video button battery ac 813dCPU: 0 EIP: 0060:[] Not tainted VLI EFLAGS: 00010003 (2.6.11-netrx) EIP is at scheduler_tick+0x3d/0x2c0 eax: 4228b927 ebx: c036c000 ecx: 000f4240 edx: 000f44af esi: d785ba40 edi: c036cf18 ebp: c036ceb0 esp: c036ce9c ds: 007b es: 007b ss: 0068 Process '.(B'.(B@ (pid: 1109979719, threadinfo=c036c000 task=d785ba40) Stack: 00000046 00000000 c036cf18 00000000 c036cf18 c036cec4 c010712a c02fd300 00000000 c036cf18 c036cee0 c0137cc5 00000000 00000000 00000000 c033ea40 c036c000 c036cf00 c0137dbe c036c000 c02fd300 c036cf18 000000e2 00000000 Call Trace: [] show_stack+0x7a/0x90 [] show_registers+0x149/0x1c0 [] die+0xdd/0x170 [] do_page_fault+0x453/0x675 [] error_code+0x2b/0x30 [] timer_interrupt+0x4a/0x120 [] handle_IRQ_event+0x35/0x70 [] __do_IRQ+0xbe/0x150 [] do_IRQ+0x5f/0x70 [] common_interrupt+0x1a/0x20 [] rtl8169_interrupt+0xdd/0x130 [r8169] [] handle_IRQ_event+0x35/0x70 [] __do_IRQ+0xbe/0x150 [] do_IRQ+0x41/0x70 ======================= [] common_interrupt+0x1a/0x20 [] ip_route_input_slow+0x39c/0x9f0 [] ip_rcv+0x380/0x480 [] netif_receive_skb+0x1e5/0x220 [] process_backlog+0x7e/0x100 [] net_rx_action+0x65/0xf0 [] __do_softirq+0x42/0xa0 [] do_softirq+0x44/0x60 ======================= [] irq_exit+0x38/0x40 [] do_IRQ+0x48/0x70 [] common_interrupt+0x1a/0x20 [] schedule_timeout+0x57/0xb0 [] ep_poll+0x10c/0x190 [] sys_epoll_wait+0x92/0xa0 [] sysenter_past_esp+0x52/0x75 Code: 7d fc 21 e3 8b 33 e8 03 71 ff ff 39 35 80 ef 36 c0 a3 74 ef 36 c0 89 15 78 ef 36 c0 <0>Kernel panic - not syncing: Fatal exception in interrupt From romieu@fr.zoreil.com Fri Mar 4 16:00:31 2005 Received: with ECARTIS (v1.0.0; list netdev); Fri, 04 Mar 2005 16:00:35 -0800 (PST) Received: from fr.zoreil.com (electric-eye.fr.zoreil.com [213.41.134.224]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j2500U7J031617 for ; Fri, 4 Mar 2005 16:00:31 -0800 Received: from electric-eye.fr.zoreil.com (localhost.localdomain [127.0.0.1]) by fr.zoreil.com (8.13.1/8.12.1) with ESMTP id j24Nw9LG009556; Sat, 5 Mar 2005 00:58:09 +0100 Received: (from romieu@localhost) by electric-eye.fr.zoreil.com (8.13.1/8.13.1/Submit) id j24Nw4vE009555; Sat, 5 Mar 2005 00:58:04 +0100 Date: Sat, 5 Mar 2005 00:58:04 +0100 From: Francois Romieu To: Jon Mason Cc: Stephen Hemminger , netdev@oss.sgi.com Subject: Re: r8169: panic on 2.6.11 Message-ID: <20050304235804.GD1148@electric-eye.fr.zoreil.com> References: <20050304132804.270cf05b@dxpl.pdx.osdl.net> <20050304145317.772859da@dxpl.pdx.osdl.net> <20050304230214.GC1148@electric-eye.fr.zoreil.com> <200503041728.54026.jdmason@us.ibm.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200503041728.54026.jdmason@us.ibm.com> User-Agent: Mutt/1.4.1i X-Organisation: Land of Sunshine Inc. X-Virus-Scanned: ClamAV 0.83/745/Fri Mar 4 03:16:06 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 2413 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: romieu@fr.zoreil.com Precedence: bulk X-list: netdev Content-Length: 707 Lines: 22 Jon Mason : [...] > > @@ -2210,6 +2211,24 @@ rtl8169_rx_interrupt(struct net_device * > > pci_action(tp->pci_dev, le64_to_cpu(desc->addr), > > tp->rx_buf_sz, PCI_DMA_FROMDEVICE); > > > > + if (pkt_size >= tp->rx_buf_sz) { > > + show_size = 1; > > + pkt_size = tp->rx_buf_sz; > > + } > > Shouldn't the above be dev->mtu (instead of tp->rx_buf_sz), otherwise there > won't be enough room for ethernet header, CRC, etc. There is no room left in the buffer. I want it to be translated into the biggest skb_put() possible. tp->rx_buf_sz already account the headers (see rtl8169_set_rxbufsize), no ? At worst it is possible we are a bit pessimistic imho. -- Ueimor From tgraf@suug.ch Fri Mar 4 16:28:54 2005 Received: with ECARTIS (v1.0.0; list netdev); Fri, 04 Mar 2005 16:28:59 -0800 (PST) Received: from b.mx.projectdream.org (eth0-0.arisu.projectdream.org [194.158.4.191]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j250SrAU006339 for ; Fri, 4 Mar 2005 16:28:54 -0800 Received: from postel.suug.ch (postel.suug.ch [195.134.158.23]) (using TLSv1 with cipher EDH-RSA-DES-CBC3-SHA (168/168 bits)) (No client certificate requested) by b.mx.projectdream.org (Postfix) with ESMTP id 4528C86; Sat, 5 Mar 2005 01:28:29 +0100 (CET) Received: by postel.suug.ch (Postfix, from userid 10001) id CF4761C0EA; Sat, 5 Mar 2005 01:29:10 +0100 (CET) Date: Sat, 5 Mar 2005 01:29:10 +0100 From: Thomas Graf To: Herbert Xu Cc: davem@davemloft.net, netdev@oss.sgi.com Subject: Re: [PATCH] [NET]: Fix deletion of local addresses only varying in prefix length Message-ID: <20050305002910.GJ31837@postel.suug.ch> References: <20050304012003.GA31837@postel.suug.ch> <20050304131419.GE31837@postel.suug.ch> <20050304233212.GA27421@gondor.apana.org.au> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20050304233212.GA27421@gondor.apana.org.au> X-Virus-Scanned: ClamAV 0.83/745/Fri Mar 4 03:16:06 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 2414 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: tgraf@suug.ch Precedence: bulk X-list: netdev Content-Length: 1176 Lines: 23 * Herbert Xu <20050304233212.GA27421@gondor.apana.org.au> 2005-03-05 10:32 > On Fri, Mar 04, 2005 at 02:14:19PM +0100, Thomas Graf wrote: > > > > I do not agree but I might have a better idea. Let's change iproute2 > > to provide a prefixlength of 0 if no prefix was specified and only > > compare the prefixes if it is non zero. This allows for accurate > > A bigger problem with this approach is that we don't have a magical > way of getting people to upgrade their ip(8) binary. > > To do this safely, we'll need a way of indicating that the ip(8) binary > is setting the prefixlen in the way you propose. Perhaps this can be > done using a new IFA payload type. > > Alternatively you can use the value of /32 to indicate a wildcard match > instead of /0. After all, /0 has a specific meaning in this context so > it's just as arbitrary to choose /0 as opposed to /32. I've been thinking about this since yesterday and the best solution I came up so far is to encode it in one of the yet unused bits in the prefixlength field. After all we're only using 5bits of it. What i'm thinking of in particular is to encode it as in 1 bit wildcard flag 5 bits prefix length. From tgraf@suug.ch Fri Mar 4 16:31:29 2005 Received: with ECARTIS (v1.0.0; list netdev); Fri, 04 Mar 2005 16:31:32 -0800 (PST) Received: from b.mx.projectdream.org (eth0-0.arisu.projectdream.org [194.158.4.191]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j250VS9S006971 for ; Fri, 4 Mar 2005 16:31:29 -0800 Received: from postel.suug.ch (postel.suug.ch [195.134.158.23]) (using TLSv1 with cipher EDH-RSA-DES-CBC3-SHA (168/168 bits)) (No client certificate requested) by b.mx.projectdream.org (Postfix) with ESMTP id 4C33986; Sat, 5 Mar 2005 01:31:06 +0100 (CET) Received: by postel.suug.ch (Postfix, from userid 10001) id 7A4F41C0EA; Sat, 5 Mar 2005 01:31:49 +0100 (CET) Date: Sat, 5 Mar 2005 01:31:49 +0100 From: Thomas Graf To: Herbert Xu Cc: davem@davemloft.net, netdev@oss.sgi.com Subject: Re: [PATCH] [NET]: Fix deletion of local addresses only varying in prefix length Message-ID: <20050305003149.GK31837@postel.suug.ch> References: <20050304012003.GA31837@postel.suug.ch> <20050304131419.GE31837@postel.suug.ch> <20050304233212.GA27421@gondor.apana.org.au> <20050305002910.GJ31837@postel.suug.ch> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20050305002910.GJ31837@postel.suug.ch> X-Virus-Scanned: ClamAV 0.83/745/Fri Mar 4 03:16:06 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 2415 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: tgraf@suug.ch Precedence: bulk X-list: netdev Content-Length: 348 Lines: 7 > I've been thinking about this since yesterday and the best solution I > came up so far is to encode it in one of the yet unused bits in > the prefixlength field. After all we're only using 5bits of it. What > i'm thinking of in particular is to encode it as in 1 bit wildcard > flag 5 bits prefix length. 6 bits i meant of course, silly me. ;-> From romieu@fr.zoreil.com Fri Mar 4 16:40:33 2005 Received: with ECARTIS (v1.0.0; list netdev); Fri, 04 Mar 2005 16:40:43 -0800 (PST) Received: from fr.zoreil.com (electric-eye.fr.zoreil.com [213.41.134.224]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j250eVYs007751 for ; Fri, 4 Mar 2005 16:40:32 -0800 Received: from electric-eye.fr.zoreil.com (localhost.localdomain [127.0.0.1]) by fr.zoreil.com (8.13.1/8.12.1) with ESMTP id j250bfUD010279; Sat, 5 Mar 2005 01:37:41 +0100 Received: (from romieu@localhost) by electric-eye.fr.zoreil.com (8.13.1/8.13.1/Submit) id j250ba2v010278; Sat, 5 Mar 2005 01:37:36 +0100 Date: Sat, 5 Mar 2005 01:37:35 +0100 From: Francois Romieu To: Stephen Hemminger Cc: Jon Mason , netdev@oss.sgi.com Subject: Re: r8169: panic on 2.6.11 Message-ID: <20050305003735.GE1148@electric-eye.fr.zoreil.com> References: <20050304132804.270cf05b@dxpl.pdx.osdl.net> <20050304145317.772859da@dxpl.pdx.osdl.net> <20050304230214.GC1148@electric-eye.fr.zoreil.com> <200503041728.54026.jdmason@us.ibm.com> <20050304154903.7b7e0fb1@dxpl.pdx.osdl.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20050304154903.7b7e0fb1@dxpl.pdx.osdl.net> User-Agent: Mutt/1.4.1i X-Organisation: Land of Sunshine Inc. X-Virus-Scanned: ClamAV 0.83/745/Fri Mar 4 03:16:06 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 2416 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: romieu@fr.zoreil.com Precedence: bulk X-list: netdev Content-Length: 1728 Lines: 58 Stephen Hemminger : [...] > Added this and took out "too much work at interrupt message" Ok (leaks but see below). > And got this (before it died): > > eth0: status=803ff0 opts=803ff0 opts2=0 addr=0:106ad012 ^^^^^^ 3ff0 would be a ~16k packet. The high weight byte is missing: the descriptor would be strictly somewhere between the first descriptor and the last descriptor for the packet. opts=80xxxx -> FIFO overflow (*bulb flashes*) The code does not look pretty there. Can you add something like the patch below on top of your current patch (untested but you get the idea): diff -puN drivers/net/r8169.c~r8169-480 drivers/net/r8169.c --- linux-2.6.11/drivers/net/r8169.c~r8169-480 2005-03-05 00:16:58.575516900 +0100 +++ linux-2.6.11-fr/drivers/net/r8169.c 2005-03-05 01:32:20.122261946 +0100 @@ -240,6 +241,7 @@ enum RTL8169_register_content { RxOK = 0x01, /* RxStatusDesc */ + RxOVF = 0x00800000, RxRES = 0x00200000, RxCRC = 0x00080000, RxRUNT = 0x00100000, @@ -2181,13 +2183,14 @@ rtl8169_rx_interrupt(struct net_device * if (status & DescOwn) break; - if (status & RxRES) { + if (status & (RxRES | RxOVF)) { printk(KERN_INFO "%s: Rx ERROR!!!\n", dev->name); tp->stats.rx_errors++; if (status & (RxRWT | RxRUNT)) tp->stats.rx_length_errors++; if (status & RxCRC) tp->stats.rx_crc_errors++; + rtl8169_return_to_asic(tp->RxDescArray + entry, tp->rx_buf_sz); } else { struct RxDesc *desc = tp->RxDescArray + entry; struct sk_buff *skb = tp->Rx_skbuff[entry]; _ /me goes to bed. Out of curiosity it would be interesting to see how non-PREEMPT and NAPI behaves (the rings are surely too small). -- Ueimor From kaber@trash.net Fri Mar 4 16:47:21 2005 Received: with ECARTIS (v1.0.0; list netdev); Fri, 04 Mar 2005 16:47:25 -0800 (PST) Received: from kaber.coreworks.de ([62.206.217.67]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j250lK7h008571 for ; Fri, 4 Mar 2005 16:47:21 -0800 Received: from localhost ([127.0.0.1]) by kaber.coreworks.de with esmtp (Exim 4.50) id 1D7NRK-00054n-Bq; Sat, 05 Mar 2005 01:46:42 +0100 Message-ID: <42290172.7020403@trash.net> Date: Sat, 05 Mar 2005 01:46:42 +0100 From: Patrick McHardy User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.7.5) Gecko/20050106 Debian/1.7.5-1 X-Accept-Language: en MIME-Version: 1.0 To: Thomas Graf CC: Herbert Xu , davem@davemloft.net, netdev@oss.sgi.com Subject: Re: [PATCH] [NET]: Fix deletion of local addresses only varying in prefix length References: <20050304012003.GA31837@postel.suug.ch> <20050304131419.GE31837@postel.suug.ch> <20050304233212.GA27421@gondor.apana.org.au> <20050305002910.GJ31837@postel.suug.ch> In-Reply-To: <20050305002910.GJ31837@postel.suug.ch> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV 0.83/745/Fri Mar 4 03:16:06 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 2417 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: kaber@trash.net Precedence: bulk X-list: netdev Content-Length: 495 Lines: 13 Thomas Graf wrote: > I've been thinking about this since yesterday and the best solution I > came up so far is to encode it in one of the yet unused bits in > the prefixlength field. After all we're only using 5bits of it. What > i'm thinking of in particular is to encode it as in 1 bit wildcard > flag 5 bits prefix length. I think that would be ok. Unrelated to this: for IFA_ADDRESS we don't do an exact match, perhaps we should also do this for IFA_LOCAL for consistency. Regards Patrick From herbert@gondor.apana.org.au Fri Mar 4 16:59:58 2005 Received: with ECARTIS (v1.0.0; list netdev); Fri, 04 Mar 2005 17:00:05 -0800 (PST) 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 j250xvQG009709 for ; Fri, 4 Mar 2005 16:59:58 -0800 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 1D7Ndr-0007tW-00; Sat, 05 Mar 2005 11:59:39 +1100 Received: from herbert by gondolin.me.apana.org.au with local (Exim 3.36 #1 (Debian)) id 1D7NdP-0007Eh-00; Sat, 05 Mar 2005 11:59:11 +1100 Date: Sat, 5 Mar 2005 11:59:11 +1100 To: Thomas Graf Cc: davem@davemloft.net, netdev@oss.sgi.com Subject: Re: [PATCH] [NET]: Fix deletion of local addresses only varying in prefix length Message-ID: <20050305005911.GA27804@gondor.apana.org.au> References: <20050304012003.GA31837@postel.suug.ch> <20050304131419.GE31837@postel.suug.ch> <20050304233212.GA27421@gondor.apana.org.au> <20050305002910.GJ31837@postel.suug.ch> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20050305002910.GJ31837@postel.suug.ch> User-Agent: Mutt/1.5.6+20040907i From: Herbert Xu X-Virus-Scanned: ClamAV 0.83/745/Fri Mar 4 03:16:06 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 2418 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: herbert@gondor.apana.org.au Precedence: bulk X-list: netdev Content-Length: 677 Lines: 17 On Sat, Mar 05, 2005 at 01:29:10AM +0100, Thomas Graf wrote: > > I've been thinking about this since yesterday and the best solution I > came up so far is to encode it in one of the yet unused bits in > the prefixlength field. After all we're only using 5bits of it. What > i'm thinking of in particular is to encode it as in 1 bit wildcard > flag 5 bits prefix length. That's sound fine as long as we treat the current ip(8) prefix length as a wild card. Cheers, -- Visit Openswan at http://www.openswan.org/ Email: Herbert Xu ~{PmV>HI~} Home Page: http://gondor.apana.org.au/~herbert/ PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt From herbert@gondor.apana.org.au Fri Mar 4 17:03:41 2005 Received: with ECARTIS (v1.0.0; list netdev); Fri, 04 Mar 2005 17:03:44 -0800 (PST) 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 j2513dDv010318 for ; Fri, 4 Mar 2005 17:03:40 -0800 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 1D7NhV-0007wp-00; Sat, 05 Mar 2005 12:03:25 +1100 Received: from herbert by gondolin.me.apana.org.au with local (Exim 3.36 #1 (Debian)) id 1D7NhP-0007Fe-00; Sat, 05 Mar 2005 12:03:19 +1100 Date: Sat, 5 Mar 2005 12:03:19 +1100 To: Patrick McHardy Cc: Thomas Graf , davem@davemloft.net, netdev@oss.sgi.com Subject: Re: [PATCH] [NET]: Fix deletion of local addresses only varying in prefix length Message-ID: <20050305010319.GB27804@gondor.apana.org.au> References: <20050304012003.GA31837@postel.suug.ch> <20050304131419.GE31837@postel.suug.ch> <20050304233212.GA27421@gondor.apana.org.au> <20050305002910.GJ31837@postel.suug.ch> <42290172.7020403@trash.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <42290172.7020403@trash.net> User-Agent: Mutt/1.5.6+20040907i From: Herbert Xu X-Virus-Scanned: ClamAV 0.83/745/Fri Mar 4 03:16:06 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 2419 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: herbert@gondor.apana.org.au Precedence: bulk X-list: netdev Content-Length: 830 Lines: 23 On Sat, Mar 05, 2005 at 01:46:42AM +0100, Patrick McHardy wrote: > > I think that would be ok. Unrelated to this: for IFA_ADDRESS we don't > do an exact match, perhaps we should also do this for IFA_LOCAL for > consistency. You mean that we do do an exact match for IFA_ADDRESS? Yes that's exactly what Thomas is trying to fix for IFA_LOCAL. The only problem is that people may have come to depend on the "wildcard" match behaviour of IFA_LOCAL, i.e.: ip a a dev eth0 192.168.0.1/24 ip a d dev eth0 192.168.0.1 His proposal of encoding a wildcard bit in IFA_LOCAL's prefix length should solve the problem. Cheers, -- Visit Openswan at http://www.openswan.org/ Email: Herbert Xu ~{PmV>HI~} Home Page: http://gondor.apana.org.au/~herbert/ PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt From kaber@trash.net Fri Mar 4 17:11:57 2005 Received: with ECARTIS (v1.0.0; list netdev); Fri, 04 Mar 2005 17:12:01 -0800 (PST) Received: from kaber.coreworks.de ([62.206.217.67]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j251Bvb9011058 for ; Fri, 4 Mar 2005 17:11:57 -0800 Received: from localhost ([127.0.0.1]) by kaber.coreworks.de with esmtp (Exim 4.50) id 1D7NpA-0003PP-5a; Sat, 05 Mar 2005 02:11:20 +0100 Message-ID: <42290738.6050605@trash.net> Date: Sat, 05 Mar 2005 02:11:20 +0100 From: Patrick McHardy User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.7.5) Gecko/20050106 Debian/1.7.5-1 X-Accept-Language: en MIME-Version: 1.0 To: Herbert Xu CC: Thomas Graf , davem@davemloft.net, netdev@oss.sgi.com Subject: Re: [PATCH] [NET]: Fix deletion of local addresses only varying in prefix length References: <20050304012003.GA31837@postel.suug.ch> <20050304131419.GE31837@postel.suug.ch> <20050304233212.GA27421@gondor.apana.org.au> <20050305002910.GJ31837@postel.suug.ch> <42290172.7020403@trash.net> <20050305010319.GB27804@gondor.apana.org.au> In-Reply-To: <20050305010319.GB27804@gondor.apana.org.au> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV 0.83/745/Fri Mar 4 03:16:06 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 2420 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: kaber@trash.net Precedence: bulk X-list: netdev Content-Length: 590 Lines: 17 Herbert Xu wrote: > On Sat, Mar 05, 2005 at 01:46:42AM +0100, Patrick McHardy wrote: > >>I think that would be ok. Unrelated to this: for IFA_ADDRESS we don't >>do an exact match, perhaps we should also do this for IFA_LOCAL for >>consistency. > > > You mean that we do do an exact match for IFA_ADDRESS? No, I meant that IFA_ADDRESS matches on exact prefixlen, but uses inet_ifa_match() for comparing the addresses. In any case we should keep the behaviour that no given prefix is a wildcard, but if a prefix is given we could do something similar as for IFA_ADDRESS. Regards Patrick From tgraf@suug.ch Fri Mar 4 17:20:33 2005 Received: with ECARTIS (v1.0.0; list netdev); Fri, 04 Mar 2005 17:20:38 -0800 (PST) Received: from b.mx.projectdream.org (eth0-0.arisu.projectdream.org [194.158.4.191]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j251KXjF011848 for ; Fri, 4 Mar 2005 17:20:33 -0800 Received: from postel.suug.ch (postel.suug.ch [195.134.158.23]) (using TLSv1 with cipher EDH-RSA-DES-CBC3-SHA (168/168 bits)) (No client certificate requested) by b.mx.projectdream.org (Postfix) with ESMTP id 7850C86; Sat, 5 Mar 2005 02:20:08 +0100 (CET) Received: by postel.suug.ch (Postfix, from userid 10001) id DFDF11C0EA; Sat, 5 Mar 2005 02:20:49 +0100 (CET) Date: Sat, 5 Mar 2005 02:20:49 +0100 From: Thomas Graf To: Patrick McHardy Cc: Herbert Xu , davem@davemloft.net, netdev@oss.sgi.com Subject: Re: [PATCH] [NET]: Fix deletion of local addresses only varying in prefix length Message-ID: <20050305012049.GL31837@postel.suug.ch> References: <20050304012003.GA31837@postel.suug.ch> <20050304131419.GE31837@postel.suug.ch> <20050304233212.GA27421@gondor.apana.org.au> <20050305002910.GJ31837@postel.suug.ch> <42290172.7020403@trash.net> <20050305010319.GB27804@gondor.apana.org.au> <42290738.6050605@trash.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <42290738.6050605@trash.net> X-Virus-Scanned: ClamAV 0.83/745/Fri Mar 4 03:16:06 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 2421 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: tgraf@suug.ch Precedence: bulk X-list: netdev Content-Length: 873 Lines: 21 * Patrick McHardy <42290738.6050605@trash.net> 2005-03-05 02:11 > Herbert Xu wrote: > >On Sat, Mar 05, 2005 at 01:46:42AM +0100, Patrick McHardy wrote: > > > >>I think that would be ok. Unrelated to this: for IFA_ADDRESS we don't > >>do an exact match, perhaps we should also do this for IFA_LOCAL for > >>consistency. > > > > > >You mean that we do do an exact match for IFA_ADDRESS? > > No, I meant that IFA_ADDRESS matches on exact prefixlen, but uses > inet_ifa_match() for comparing the addresses. In any case we should > keep the behaviour that no given prefix is a wildcard, but if a > prefix is given we could do something similar as for IFA_ADDRESS. This will change the behaviour and makes my work completely useless. Assuming one adds 1.1.1.1/24, 1.1.1.2/24 and then deletes 1.1.1.2/24 one would expect 1.1.1.2/24 to be deleted but that wouldn't be the case. From kaber@trash.net Fri Mar 4 17:29:21 2005 Received: with ECARTIS (v1.0.0; list netdev); Fri, 04 Mar 2005 17:29:24 -0800 (PST) Received: from kaber.coreworks.de ([62.206.217.67]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j251TKXw012599 for ; Fri, 4 Mar 2005 17:29:21 -0800 Received: from localhost ([127.0.0.1]) by kaber.coreworks.de with esmtp (Exim 4.50) id 1D7O5z-0004o4-Oy; Sat, 05 Mar 2005 02:28:43 +0100 Message-ID: <42290B4B.6080300@trash.net> Date: Sat, 05 Mar 2005 02:28:43 +0100 From: Patrick McHardy User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.7.5) Gecko/20050106 Debian/1.7.5-1 X-Accept-Language: en MIME-Version: 1.0 To: Thomas Graf CC: Herbert Xu , davem@davemloft.net, netdev@oss.sgi.com Subject: Re: [PATCH] [NET]: Fix deletion of local addresses only varying in prefix length References: <20050304012003.GA31837@postel.suug.ch> <20050304131419.GE31837@postel.suug.ch> <20050304233212.GA27421@gondor.apana.org.au> <20050305002910.GJ31837@postel.suug.ch> <42290172.7020403@trash.net> <20050305010319.GB27804@gondor.apana.org.au> <42290738.6050605@trash.net> <20050305012049.GL31837@postel.suug.ch> In-Reply-To: <20050305012049.GL31837@postel.suug.ch> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV 0.83/745/Fri Mar 4 03:16:06 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 2422 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: kaber@trash.net Precedence: bulk X-list: netdev Content-Length: 298 Lines: 13 Thomas Graf wrote: > This will change the behaviour and makes my work completely useless. > > Assuming one adds 1.1.1.1/24, 1.1.1.2/24 and then deletes 1.1.1.2/24 > one would expect 1.1.1.2/24 to be deleted but that wouldn't be the > case. True, that would be pretty stupid :) Regards Patrick From jdmason@us.ibm.com Fri Mar 4 21:04:06 2005 Received: with ECARTIS (v1.0.0; list netdev); Fri, 04 Mar 2005 21:04:12 -0800 (PST) Received: from e3.ny.us.ibm.com (e3.ny.us.ibm.com [32.97.182.143]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j2553vLU025042 for ; Fri, 4 Mar 2005 21:04:06 -0800 Received: from d01relay02.pok.ibm.com (d01relay02.pok.ibm.com [9.56.227.234]) by e3.ny.us.ibm.com (8.12.11/8.12.11) with ESMTP id j2553q6G009515 for ; Sat, 5 Mar 2005 00:03:52 -0500 Received: from d01av04.pok.ibm.com (d01av04.pok.ibm.com [9.56.224.64]) by d01relay02.pok.ibm.com (8.12.10/NCO/VER6.6) with ESMTP id j2553qqw059298 for ; Sat, 5 Mar 2005 00:03:52 -0500 Received: from d01av04.pok.ibm.com (loopback [127.0.0.1]) by d01av04.pok.ibm.com (8.12.11/8.12.11) with ESMTP id j2553pxR022315 for ; Sat, 5 Mar 2005 00:03:52 -0500 Received: from [9.48.62.169] ([9.48.62.169]) by d01av04.pok.ibm.com (8.12.11/8.12.11) with ESMTP id j2553pjl022304; Sat, 5 Mar 2005 00:03:51 -0500 From: Jon Mason Organization: IBM To: Francois Romieu Subject: Re: r8169: panic on 2.6.11 Date: Fri, 4 Mar 2005 23:03:50 -0600 User-Agent: KMail/1.7.2 Cc: Stephen Hemminger , netdev@oss.sgi.com References: <20050304132804.270cf05b@dxpl.pdx.osdl.net> <20050304154903.7b7e0fb1@dxpl.pdx.osdl.net> <20050305003735.GE1148@electric-eye.fr.zoreil.com> In-Reply-To: <20050305003735.GE1148@electric-eye.fr.zoreil.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200503042303.50055.jdmason@us.ibm.com> X-Virus-Scanned: ClamAV 0.83/745/Fri Mar 4 03:16:06 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 2423 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: jdmason@us.ibm.com Precedence: bulk X-list: netdev Content-Length: 2545 Lines: 75 I tested the patch below on amd64, and have found a problem. My adapter always has the FOVF bit set, so the adapter never pings. After looking at the opts1 register output of my adapter and Steven's, I noticed something weird. For every packet, I am getting opts1 = 0x3481c040. Now, compare this to opts=803ff0 from Steven's last test. It appears that the upper 8 bits have been lost. These are the FirstSegment and LastSegment indicators (which should always be True for < 8191). This looks alot like some of the funky behavior that I was seeing with my > 8191 jumbo frames patch. What size packets are being sent accross the wire? On Friday 04 March 2005 06:37 pm, Francois Romieu wrote: > Stephen Hemminger : > [...] > > > Added this and took out "too much work at interrupt message" > > Ok (leaks but see below). > > > And got this (before it died): > > > > eth0: status=803ff0 opts=803ff0 opts2=0 addr=0:106ad012 > > ^^^^^^ > 3ff0 would be a ~16k packet. The high weight byte is > missing: the descriptor would be strictly somewhere between > the first descriptor and the last descriptor for the packet. > > opts=80xxxx -> FIFO overflow (*bulb flashes*) > > The code does not look pretty there. > > Can you add something like the patch below on top of your > current patch (untested but you get the idea): > > diff -puN drivers/net/r8169.c~r8169-480 drivers/net/r8169.c > --- linux-2.6.11/drivers/net/r8169.c~r8169-480 2005-03-05 > 00:16:58.575516900 +0100 +++ linux-2.6.11-fr/drivers/net/r8169.c 2005-03-05 > 01:32:20.122261946 +0100 @@ -240,6 +241,7 @@ enum RTL8169_register_content > { > RxOK = 0x01, > > /* RxStatusDesc */ > + RxOVF = 0x00800000, > RxRES = 0x00200000, > RxCRC = 0x00080000, > RxRUNT = 0x00100000, > @@ -2181,13 +2183,14 @@ rtl8169_rx_interrupt(struct net_device * > > if (status & DescOwn) > break; > - if (status & RxRES) { > + if (status & (RxRES | RxOVF)) { > printk(KERN_INFO "%s: Rx ERROR!!!\n", dev->name); > tp->stats.rx_errors++; > if (status & (RxRWT | RxRUNT)) > tp->stats.rx_length_errors++; > if (status & RxCRC) > tp->stats.rx_crc_errors++; > + rtl8169_return_to_asic(tp->RxDescArray + entry, tp->rx_buf_sz); > } else { > struct RxDesc *desc = tp->RxDescArray + entry; > struct sk_buff *skb = tp->Rx_skbuff[entry]; > > _ > > /me goes to bed. > > Out of curiosity it would be interesting to see how non-PREEMPT and NAPI > behaves (the rings are surely too small). > > -- > Ueimor From galak@freescale.com Fri Mar 4 21:14:02 2005 Received: with ECARTIS (v1.0.0; list netdev); Fri, 04 Mar 2005 21:14:08 -0800 (PST) Received: from de01egw02.freescale.net (de01egw02.freescale.net [192.88.165.103]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j255DtoY025917 for ; Fri, 4 Mar 2005 21:14:02 -0800 Received: from de01smr01.am.mot.com (de01smr01.freescale.net [10.208.0.31]) by de01egw02.freescale.net (8.12.11/de01egw02) with ESMTP id j255E2HO003364; Fri, 4 Mar 2005 22:14:02 -0700 (MST) Received: from postal.somerset.sps.mot.com ([163.12.132.5]) by de01smr01.am.mot.com (8.13.1/8.13.0) with ESMTP id j255EUON005764; Fri, 4 Mar 2005 23:14:30 -0600 (CST) Received: from blarg.somerset.sps.mot.com (blarg.somerset.sps.mot.com [163.12.112.65]) by postal.somerset.sps.mot.com (8.11.0/8.11.0) with ESMTP id j255D2i14324; Fri, 4 Mar 2005 23:13:02 -0600 (CST) Received: from blarg.somerset.sps.mot.com (localhost.localdomain [127.0.0.1]) by blarg.somerset.sps.mot.com (8.12.11/8.11.0) with ESMTP id j255D2cc023582; Fri, 4 Mar 2005 23:13:02 -0600 Received: from localhost (galak@localhost) by blarg.somerset.sps.mot.com (8.12.11/8.12.11/Submit) with ESMTP id j255D0dx023579; Fri, 4 Mar 2005 23:13:01 -0600 X-Authentication-Warning: blarg.somerset.sps.mot.com: galak owned process doing -bs Date: Fri, 4 Mar 2005 23:12:59 -0600 (CST) From: Kumar Gala X-X-Sender: galak@blarg.somerset.sps.mot.com To: jgarzik@pobox.com cc: jaka@activetools.si, linux-kernel@vger.kernel.org, linuxppc-embedded@ozlabs.org, netdev@oss.sgi.com Subject: [PATCH] initialize a spin lock in gianfar driver Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Virus-Scanned: ClamAV 0.83/745/Fri Mar 4 03:16:06 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 2424 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: galak@freescale.com Precedence: bulk X-list: netdev Content-Length: 573 Lines: 20 Initialize the mdio_lock spin lock in mii_info struct, which is otherwise accessed prior to initialization. Signed-off-by: Jaka Mocnik Signed-off-by: Kumar Gala --- diff -Nru a/drivers/net/gianfar.c b/drivers/net/gianfar.c --- a/drivers/net/gianfar.c 2005-03-04 23:03:27 -06:00 +++ b/drivers/net/gianfar.c 2005-03-04 23:03:27 -06:00 @@ -377,6 +377,8 @@ ADVERTISED_1000baseT_Full); mii_info->autoneg = 1; + spin_lock_init(&mii_info->mdio_lock); + mii_info->mii_id = priv->einfo->phyid; mii_info->dev = dev; From akpm@osdl.org Fri Mar 4 22:21:25 2005 Received: with ECARTIS (v1.0.0; list netdev); Fri, 04 Mar 2005 22:21:32 -0800 (PST) Received: from smtp.osdl.org (fire.osdl.org [65.172.181.4]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j256LO8n028697 for ; Fri, 4 Mar 2005 22:21:24 -0800 Received: from shell0.pdx.osdl.net (fw.osdl.org [65.172.181.6]) by smtp.osdl.org (8.12.8/8.12.8) with ESMTP id j256LHqi015218 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO); Fri, 4 Mar 2005 22:21:17 -0800 Received: from bix (shell0.pdx.osdl.net [10.9.0.31]) by shell0.pdx.osdl.net (8.13.1/8.11.6) with SMTP id j256LEnX010201; Fri, 4 Mar 2005 22:21:16 -0800 Date: Fri, 4 Mar 2005 22:20:52 -0800 From: Andrew Morton To: netdev@oss.sgi.com Cc: Alessandro Suardi Subject: Fw: non-fatal oops with EIP at skb_release_data, available for debugging Message-Id: <20050304222052.2f41771f.akpm@osdl.org> X-Mailer: Sylpheed version 0.9.7 (GTK+ 1.2.10; i386-redhat-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Received-SPF: pass (domain of akpm@osdl.org designates 65.172.181.6 as permitted sender) X-MIMEDefang-Filter: osdl$Revision: 1.104 $ X-Scanned-By: MIMEDefang 2.36 X-Virus-Scanned: ClamAV 0.83/745/Fri Mar 4 03:16:06 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 2425 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: akpm@osdl.org Precedence: bulk X-list: netdev Content-Length: 2799 Lines: 78 We did a put_page() on a zero-ref page. Begin forwarded message: Date: Fri, 4 Mar 2005 21:48:18 +0100 From: Alessandro Suardi To: Linux Kernel Mailing List Subject: non-fatal oops with EIP at skb_release_data, available for debugging This is my K7-800, 256MB RAM machine running as ed2k/bittorrent 24/7 box... metacity died, but the windows are still alive (and working) so if someone wants to get more info about it, just ping me... [root@donkey ~]# cat /proc/version Linux version 2.6.11-rc3-bk8 (asuardi@donkey) (gcc version 3.4.2 20041017 (Red Hat 3.4.2-6.fc3)) #1 Sat Feb 12 00:01:28 CET 2005 [root@donkey ~]# lsmod Module Size Used by loop 15368 - nls_iso8859_1 3840 - parport_pc 29444 - parport 24704 - 8139too 24896 - floppy 57392 - >From the dmesg ring: kernel BUG at include/linux/mm.h:343! invalid operand: 0000 [#1] PREEMPT Modules linked in: loop nls_iso8859_1 parport_pc parport 8139too floppy CPU: 0 EIP: 0060:[] Not tainted VLI EFLAGS: 00210256 (2.6.11-rc3-bk8) EIP is at skb_release_data+0x92/0xa0 eax: 00000000 ebx: 00000000 ecx: cca36f80 edx: c11a97c0 esi: c4205f20 edi: c4205f20 ebp: cd149dcc esp: cd149dc4 ds: 007b es: 007b ss: 0068 Process metacity (pid: 2109, threadinfo=cd148000 task=ce8935d0) Stack: c4205f20 00000000 cd149dd8 c02da6bb c6e9a0c0 cd149df8 c02da737 c5134250 00000000 c4205f20 c5134250 c4205f20 c5134250 cd149e4c c02feba6 00000000 00000040 cc68c454 00000000 00000001 cc68c444 cd148000 00000001 00000000 Call Trace: [] show_stack+0x7a/0x90 [] show_registers+0x14d/0x1c0 [] die+0xe4/0x180 [] do_invalid_op+0xa3/0xb0 [] error_code+0x2b/0x30 [] kfree_skbmem+0xb/0x20 [] __kfree_skb+0x67/0xf0 [] tcp_recvmsg+0x5f6/0x710 [] sock_common_recvmsg+0x46/0x60 [] sock_aio_read+0xee/0x100 [] do_sync_read+0x97/0xf0 [] vfs_read+0x91/0x120 [] sys_read+0x3d/0x70 [] sysenter_past_esp+0x52/0x75 Code: c9 e9 03 e5 e5 ff 8d 76 00 5b 5e c9 c3 89 d0 e8 c5 f2 e5 ff eb cf 89 f0 e8 0c ff ff ff 5b 8b 86 98 00 00 00 5e c9 e9 de e4 e5 ff <0f> 0b 57 01 ab c5 35 c0 eb a5 8d 74 26 00 55 89 e5 53 89 c3 e8 Thanks, --alessandro "There is no distance that I don't see I do have a will - No limit to my reach" (Wallflowers, "Empire In My Mind") - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/ From shemminger@osdl.org Fri Mar 4 22:34:21 2005 Received: with ECARTIS (v1.0.0; list netdev); Fri, 04 Mar 2005 22:34:30 -0800 (PST) Received: from smtp.osdl.org (fire.osdl.org [65.172.181.4]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j256YLVY029552 for ; Fri, 4 Mar 2005 22:34:21 -0800 Received: from [192.168.0.106] (063-170-215-071.dslnorthwest.net [63.170.215.71]) (authenticated bits=0) by smtp.osdl.org (8.12.8/8.12.8) with ESMTP id j256YEqi016187 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NO); Fri, 4 Mar 2005 22:34:15 -0800 Message-ID: <422952E8.6010801@osdl.org> Date: Fri, 04 Mar 2005 22:34:16 -0800 From: Stephen Hemminger User-Agent: Mozilla Thunderbird 1.0 (Windows/20041206) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Jon Mason CC: netdev@oss.sgi.com Subject: Re: r8169: panic on 2.6.11 References: <20050304132804.270cf05b@dxpl.pdx.osdl.net> <20050304154903.7b7e0fb1@dxpl.pdx.osdl.net> <20050305003735.GE1148@electric-eye.fr.zoreil.com> <200503042303.50055.jdmason@us.ibm.com> In-Reply-To: <200503042303.50055.jdmason@us.ibm.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-MIMEDefang-Filter: osdl$Revision: 1.104 $ X-Scanned-By: MIMEDefang 2.36 X-Virus-Scanned: ClamAV 0.83/745/Fri Mar 4 03:16:06 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 2426 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: shemminger@osdl.org Precedence: bulk X-list: netdev Content-Length: 1005 Lines: 24 The packet burst is 10 million 64 byte packets. Could be the sender or switch causing merging, but I suspect the r8169 on the slow receiver. Details are: # cat /proc/net/pktgen/eth0 Params: count 10000000 min_pkt_size: 60 max_pkt_size: 60 frags: 0 delay: 0 clone_skb: 1000000 ifname: eth0 flows: 0 flowlen: 0 dst_min: 172.2.251.143 dst_max: src_min: src_max: src_mac: 00:0D:60:53:08:18 dst_mac: 00:09:5B:BD:B1:F9 udp_src_min: 9 udp_src_max: 9 udp_dst_min: 9 udp_dst_max: 9 src_mac_count: 0 dst_mac_count: 0 Flags: Current: pkts-sofar: 10000000 errors: 6374336 started: 1109979805822722us stopped: 1109979815051630us idle: 166364us seq_num: 10000011 cur_dst_mac_offset: 0 cur_src_mac_offset: 0 cur_saddr: 0x670114ac cur_daddr: 0x8ffb02ac cur_udp_dst: 9 cur_udp_src: 9 flows: 0 Result: OK: 9228908(c9062544+d166364) usec, 10000000 (60byte,0frags) 1083551pps 520Mb/sec (520104480bps) errors: 6374336 From herbert@gondor.apana.org.au Sat Mar 5 00:48:35 2005 Received: with ECARTIS (v1.0.0; list netdev); Sat, 05 Mar 2005 00:48:39 -0800 (PST) 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 j258mXfJ005471 for ; Sat, 5 Mar 2005 00:48:34 -0800 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 1D7UxF-0001aL-00; Sat, 05 Mar 2005 19:48:09 +1100 Received: from herbert by gondolin.me.apana.org.au with local (Exim 3.36 #1 (Debian)) id 1D7Uwv-0003Ju-00; Sat, 05 Mar 2005 19:47:49 +1100 From: Herbert Xu To: akpm@osdl.org Subject: Re: [patch 3/3] x25_create initializing socket data twice Cc: davem@davemloft.net, jgarzik@pobox.com, netdev@oss.sgi.com, akpm@osdl.org, herbert@13thfloor.at Organization: Core In-Reply-To: <200503041237.j24Cbdbm026482@shell0.pdx.osdl.net> X-Newsgroups: apana.lists.os.linux.netdev User-Agent: tin/1.7.4-20040225 ("Benbecula") (UNIX) (Linux/2.4.27-hx-1-686-smp (i686)) Message-Id: Date: Sat, 05 Mar 2005 19:47:49 +1100 X-Virus-Scanned: ClamAV 0.83/745/Fri Mar 4 03:16:06 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 2428 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: herbert@gondor.apana.org.au Precedence: bulk X-list: netdev Content-Length: 710 Lines: 17 akpm@osdl.org wrote: > > x25_create() [net/x25/af_x25.c] is calling sock_init_data() twice ... once > indirectly via x25_alloc_socket() and a second time directly via > sock_init_data(sock, sk); > > while this might not look as critical as it seems, it can easily break > stuff which assumes that sock_init_data() isn't called twice on the same > socket. As someone pointed out on LKML, this is broken since the sock_init_data in x25_alloc_socket() is called with the first argument set to NULL. -- Visit Openswan at http://www.openswan.org/ Email: Herbert Xu ~{PmV>HI~} Home Page: http://gondor.apana.org.au/~herbert/ PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt From herbert@gondor.apana.org.au Sat Mar 5 00:48:23 2005 Received: with ECARTIS (v1.0.0; list netdev); Sat, 05 Mar 2005 00:48:31 -0800 (PST) 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 j258mKuU005458 for ; Sat, 5 Mar 2005 00:48:21 -0800 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 1D7Ux2-0001aG-00; Sat, 05 Mar 2005 19:47:56 +1100 Received: from herbert by gondolin.me.apana.org.au with local (Exim 3.36 #1 (Debian)) id 1D7Uun-0003J5-00; Sat, 05 Mar 2005 19:45:37 +1100 Date: Sat, 5 Mar 2005 19:45:37 +1100 To: Andrew Morton Cc: netdev@oss.sgi.com, mangus@deprecated.it, jgarzik@pobox.com, webvenza@libero.it Subject: Re: Fw: [Bugme-new] [Bug 4223] New: sis900 kernel oop at boot Message-ID: <20050305084537.GA12678@gondor.apana.org.au> References: <20050217134440.44f591e2.akpm@osdl.org> Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="CE+1k2dSO48ffgeK" Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.6+20040907i From: Herbert Xu X-Virus-Scanned: ClamAV 0.83/745/Fri Mar 4 03:16:06 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 2427 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: herbert@gondor.apana.org.au Precedence: bulk X-list: netdev Content-Length: 6604 Lines: 208 --CE+1k2dSO48ffgeK Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Hi: Here is the version that moves the necessary code above register_netdev instead of using init. It's against netdev-2.6. > Feb 15 18:26:20 saturno kernel: Unable to handle kernel NULL pointer > dereference at virtual address 0000000e > Feb 15 18:26:20 saturno kernel: printing eip: > Feb 15 18:26:20 saturno kernel: e1113417 > Feb 15 18:26:20 saturno kernel: *pde = 00000000 > Feb 15 18:26:20 saturno kernel: Oops: 0000 [#1] > Feb 15 18:26:20 saturno kernel: PREEMPT > Feb 15 18:26:20 saturno kernel: Modules linked in: sis900 nvidia 8250_pci 8250 > serial_core psmouse > Feb 15 18:26:20 saturno kernel: CPU: 0 > Feb 15 18:26:20 saturno kernel: EIP: 0060:[] Tainted: P > VLI > Feb 15 18:26:20 saturno kernel: EFLAGS: 00010296 (2.6.10-M7) > Feb 15 18:26:20 saturno kernel: EIP is at sis900_check_mode+0x17/0xa0 [sis900] OK, this happened because we got preempted before sis900_mii_probe finished setting the sis_priv->mii. Theoretically this can happen with SMP as well but I suppose the number of SMP machines with sis900 is fairly small. Anyway, the fix is to make sure that sis900_mii_probe is done before the device can be opened. This patch does it by moving the setup before register_netdevice. Since the netdev name is not available before register_netdev, I've changed the relevant printk's to use pci_name instead. Note that one of those printk's may be called after register_netdev as well. Signed-off-by: Herbert Xu Cheers, -- Visit Openswan at http://www.openswan.org/ Email: Herbert Xu ~{PmV>HI~} Home Page: http://gondor.apana.org.au/~herbert/ PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt --CE+1k2dSO48ffgeK Content-Type: text/plain; charset=us-ascii Content-Disposition: attachment; filename=p ===== drivers/net/sis900.c 1.69 vs edited ===== --- 1.69/drivers/net/sis900.c 2005-03-03 17:34:44 +11:00 +++ edited/drivers/net/sis900.c 2005-03-05 19:32:29 +11:00 @@ -245,7 +245,7 @@ signature = (u16) read_eeprom(ioaddr, EEPROMSignature); if (signature == 0xffff || signature == 0x0000) { printk (KERN_WARNING "%s: Error EERPOM read %x\n", - net_dev->name, signature); + pci_name(pci_dev), signature); return 0; } @@ -277,7 +277,8 @@ if (!isa_bridge) isa_bridge = pci_get_device(PCI_VENDOR_ID_SI, 0x0018, isa_bridge); if (!isa_bridge) { - printk(KERN_WARNING "%s: Can not find ISA bridge\n", net_dev->name); + printk(KERN_WARNING "%s: Can not find ISA bridge\n", + pci_name(pci_dev)); return 0; } pci_read_config_byte(isa_bridge, 0x48, ®); @@ -396,6 +397,7 @@ long ioaddr; int i, ret; char *card_name = card_names[pci_id->driver_data]; + const char *dev_name = pci_name(pci_dev); /* when built into the kernel, we only print version if device is found */ #ifndef MODULE @@ -473,17 +475,13 @@ sis_priv->msg_enable = sis900_debug; else sis_priv->msg_enable = SIS900_DEF_MSG; - - ret = register_netdev(net_dev); - if (ret) - goto err_unmap_rx; /* Get Mac address according to the chip revision */ pci_read_config_byte(pci_dev, PCI_CLASS_REVISION, &(sis_priv->chipset_rev)); if(netif_msg_probe(sis_priv)) printk(KERN_DEBUG "%s: detected revision %2.2x, " "trying to get MAC address...\n", - net_dev->name, sis_priv->chipset_rev); + dev_name, sis_priv->chipset_rev); ret = 0; if (sis_priv->chipset_rev == SIS630E_900_REV) @@ -496,9 +494,9 @@ ret = sis900_get_mac_addr(pci_dev, net_dev); if (ret == 0) { - printk(KERN_WARNING "%s: Cannot read MAC address.\n", net_dev->name); + printk(KERN_WARNING "%s: Cannot read MAC address.\n", dev_name); ret = -ENODEV; - goto err_out_unregister; + goto err_unmap_rx; } /* 630ET : set the mii access mode as software-mode */ @@ -507,9 +505,10 @@ /* probe for mii transceiver */ if (sis900_mii_probe(net_dev) == 0) { - printk(KERN_WARNING "%s: Error probing MII device.\n", net_dev->name); + printk(KERN_WARNING "%s: Error probing MII device.\n", + dev_name); ret = -ENODEV; - goto err_out_unregister; + goto err_unmap_rx; } /* save our host bridge revision */ @@ -519,6 +518,10 @@ pci_dev_put(dev); } + ret = register_netdev(net_dev); + if (ret) + goto err_unmap_rx; + /* print some information about our NIC */ printk(KERN_INFO "%s: %s at %#lx, IRQ %d, ", net_dev->name, card_name, ioaddr, net_dev->irq); @@ -528,8 +531,6 @@ return 0; - err_out_unregister: - unregister_netdev(net_dev); err_unmap_rx: pci_free_consistent(pci_dev, RX_TOTAL_SIZE, sis_priv->rx_ring, sis_priv->rx_ring_dma); @@ -556,6 +557,7 @@ static int __init sis900_mii_probe(struct net_device * net_dev) { struct sis900_private * sis_priv = net_dev->priv; + const char *dev_name = pci_name(sis_priv->pci_dev); u16 poll_bit = MII_STAT_LINK, status = 0; unsigned long timeout = jiffies + 5 * HZ; int phy_addr; @@ -576,7 +578,7 @@ if (netif_msg_probe(sis_priv)) printk(KERN_DEBUG "%s: MII at address %d" " not accessible\n", - net_dev->name, phy_addr); + dev_name, phy_addr); continue; } @@ -609,7 +611,7 @@ (mii_status & (MII_STAT_CAN_TX_FDX | MII_STAT_CAN_TX)) ? LAN : HOME; printk(KERN_INFO "%s: %s transceiver found " "at address %d.\n", - net_dev->name, + dev_name, mii_chip_table[i].name, phy_addr); break; @@ -617,14 +619,13 @@ if( !mii_chip_table[i].phy_id1 ) { printk(KERN_INFO "%s: Unknown PHY transceiver found at address %d.\n", - net_dev->name, phy_addr); + dev_name, phy_addr); mii_phy->phy_types = UNKNOWN; } } if (sis_priv->mii == NULL) { - printk(KERN_INFO "%s: No MII transceivers found!\n", - net_dev->name); + printk(KERN_INFO "%s: No MII transceivers found!\n", dev_name); return 0; } @@ -649,7 +650,7 @@ poll_bit ^= (mdio_read(net_dev, sis_priv->cur_phy, MII_STATUS) & poll_bit); if (time_after_eq(jiffies, timeout)) { printk(KERN_WARNING "%s: reset phy and link down now\n", - net_dev->name); + dev_name); return -ETIME; } } @@ -718,7 +719,7 @@ sis_priv->mii = default_phy; sis_priv->cur_phy = default_phy->phy_addr; printk(KERN_INFO "%s: Using transceiver found at address %d as default\n", - net_dev->name,sis_priv->cur_phy); + pci_name(sis_priv->pci_dev), sis_priv->cur_phy); } status = mdio_read(net_dev, sis_priv->cur_phy, MII_CONTROL); --CE+1k2dSO48ffgeK-- From webvenza@libero.it Sat Mar 5 05:37:29 2005 Received: with ECARTIS (v1.0.0; list netdev); Sat, 05 Mar 2005 05:37:35 -0800 (PST) Received: from localhost.localdomain (foobar@adsl-ull-59-137.44-151.net24.it [151.44.137.59]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j25DbRVp021724 for ; Sat, 5 Mar 2005 05:37:28 -0800 Received: from localhost.localdomain (localhost.localdomain [127.0.0.1]) by localhost.localdomain (Postfix) with ESMTP id B62F81ED97; Sat, 5 Mar 2005 14:40:11 +0100 (CET) MIME-Version: 1.0 Content-Type: multipart/mixed; charset="us-ascii"; boundary="===============0651636773==" Content-Transfer-Encoding: 7bit User-Agent: Python patchbomber v. 0.0.0.0.0.1 Message-ID: <20050305134011.23638.68926@localhost.localdomain> Subject: [PATCH 1/1] More ethtool support for sis900 From: Daniele Venzano To: netdev@oss.sgi.com, jgarzik@pobox.com Date: Sat, 5 Mar 2005 14:40:11 +0100 (CET) X-Virus-Scanned: ClamAV 0.83/748/Fri Mar 4 14:19:11 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 2429 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: webvenza@libero.it Precedence: bulk X-list: netdev Content-Length: 3671 Lines: 124 This is a MIME message, see the first attachment for the text and the second for the patch --===============0651636773== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Add support for using generic mii interface Add support for the following ethtool ops: - get_link - get_settings - set_settings - nway_reset Signed-off-by: Daniele Venzano --===============0651636773== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Index: sis900.c =================================================================== --- a/drivers/net/sis900.c (revision 95) +++ b/drivers/net/sis900.c (revision 97) @@ -161,6 +161,7 @@ struct mii_phy * mii; struct mii_phy * first_mii; /* record the first mii structure */ unsigned int cur_phy; + struct mii_if_info mii_info; struct timer_list timer; /* Link status detection timer. */ u8 autong_complete; /* 1: auto-negotiate complete */ @@ -199,7 +200,7 @@ static int sis900_mii_probe (struct net_device * net_dev); static void sis900_init_rxfilter (struct net_device * net_dev); static u16 read_eeprom(long ioaddr, int location); -static u16 mdio_read(struct net_device *net_dev, int phy_id, int location); +static int mdio_read(struct net_device *net_dev, int phy_id, int location); static void mdio_write(struct net_device *net_dev, int phy_id, int location, int val); static void sis900_timer(unsigned long data); static void sis900_check_mode (struct net_device *net_dev, struct mii_phy *mii_phy); @@ -468,7 +469,13 @@ sis_priv->msg_enable = sis900_debug; else sis_priv->msg_enable = SIS900_DEF_MSG; - + + sis_priv->mii_info.dev = net_dev; + sis_priv->mii_info.mdio_read = mdio_read; + sis_priv->mii_info.mdio_write = mdio_write; + sis_priv->mii_info.phy_id_mask = 0x1f; + sis_priv->mii_info.reg_num_mask = 0x1f; + ret = register_netdev(net_dev); if (ret) goto err_unmap_rx; @@ -507,6 +514,8 @@ goto err_out_unregister; } + sis_priv->mii_info.phy_id = sis_priv->cur_phy; + /* save our host bridge revision */ dev = pci_get_device(PCI_VENDOR_ID_SI, PCI_DEVICE_ID_SI_630, NULL); if (dev) { @@ -843,7 +852,7 @@ * Please see SiS7014 or ICS spec */ -static u16 mdio_read(struct net_device *net_dev, int phy_id, int location) +static int mdio_read(struct net_device *net_dev, int phy_id, int location) { long mdio_addr = net_dev->base_addr + mear; int mii_cmd = MIIread|(phy_id<msg_enable = value; } +static u32 sis900_get_link(struct net_device *net_dev) +{ + struct sis900_private *sis_priv = net_dev->priv; + return mii_link_ok(&sis_priv->mii_info); +} + +static int sis900_get_settings(struct net_device *net_dev, + struct ethtool_cmd *cmd) +{ + struct sis900_private *sis_priv = net_dev->priv; + mii_ethtool_gset(&sis_priv->mii_info, cmd); + return 0; +} + +static int sis900_set_settings(struct net_device *net_dev, + struct ethtool_cmd *cmd) +{ + struct sis900_private *sis_priv = net_dev->priv; + return mii_ethtool_sset(&sis_priv->mii_info, cmd); +} + +static int sis900_nway_reset(struct net_device *net_dev) +{ + struct sis900_private *sis_priv = net_dev->priv; + return mii_nway_restart(&sis_priv->mii_info); +} + static struct ethtool_ops sis900_ethtool_ops = { .get_drvinfo = sis900_get_drvinfo, .get_msglevel = sis900_get_msglevel, .set_msglevel = sis900_set_msglevel, + .get_link = sis900_get_link, + .get_settings = sis900_get_settings, + .set_settings = sis900_set_settings, + .nway_reset = sis900_nway_reset, }; /** --===============0651636773==-- From rich@phekda.gotadsl.co.uk Sat Mar 5 05:51:22 2005 Received: with ECARTIS (v1.0.0; list netdev); Sat, 05 Mar 2005 05:51:33 -0800 (PST) Received: from smtp.nildram.co.uk (smtp.nildram.co.uk [195.112.4.54]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j25DpL9T022849 for ; Sat, 5 Mar 2005 05:51:21 -0800 Received: from katrina.int.phekda.gotadsl.co.uk (82-133-64-63.dyn.gotadsl.co.uk [82.133.64.63]) by smtp.nildram.co.uk (Postfix) with ESMTP id EFC172BCEFF; Sat, 5 Mar 2005 13:51:17 +0000 (GMT) Received: from [192.168.1.4] (katrina.int.phekda.gotadsl.co.uk [192.168.1.4]) by katrina.int.phekda.gotadsl.co.uk (Postfix) with ESMTP id 6326A381DC; Sat, 5 Mar 2005 13:53:36 +0000 (GMT) Message-ID: <4229B9E0.2050205@phekda.gotadsl.co.uk> Date: Sat, 05 Mar 2005 13:53:36 +0000 From: Richard Dawe User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.3) Gecko/20041020 X-Accept-Language: en, de, fr MIME-Version: 1.0 To: Ben Greear Cc: Jeff Garzik , Jon Mason , Francois Romieu , netdev@oss.sgi.com Subject: Re: [PATCH]: r8169: Expose hardware stats via ethtool References: <42208D83.80803@phekda.gotadsl.co.uk> <20050226181213.GA13230@electric-eye.fr.zoreil.com> <42224F76.9000602@phekda.gotadsl.co.uk> <200502272031.12291.jdmason@us.ibm.com> <422288EC.9010502@pobox.com> <42229B16.6000006@candelatech.com> In-Reply-To: <42229B16.6000006@candelatech.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV 0.83/748/Fri Mar 4 14:19:11 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 2430 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: rich@phekda.gotadsl.co.uk Precedence: bulk X-list: netdev Content-Length: 680 Lines: 29 Hello. Ben Greear wrote: > Jeff Garzik wrote: > >> Jon Mason wrote: >> >>> I think I've found a (very hackish) way around the bad stats error. >>> Tested on amd64, and "solves" the problem. >> >> >> >> Seems to me, we should instead find a way to avoid calling the stats >> function if !netif_running() > > > Are the stats valid in the hardware if you start it, stop it, and then > read them? They don't seem to be. I get the same kind of garbage before starting as I do after I've started and stopped it. Bye, Rich =] -- Richard Dawe [ http://homepages.nildram.co.uk/~phekda/richdawe/ ] "You can't evaluate a man by logic alone." -- McCoy, "I, Mudd", Star Trek From kaber@trash.net Sat Mar 5 05:59:08 2005 Received: with ECARTIS (v1.0.0; list netdev); Sat, 05 Mar 2005 05:59:12 -0800 (PST) Received: from kaber.coreworks.de ([62.206.217.67]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j25Dx7nE023537 for ; Sat, 5 Mar 2005 05:59:07 -0800 Received: from localhost ([127.0.0.1]) by kaber.coreworks.de with esmtp (Exim 4.50) id 1D7Zo7-0000o9-D3; Sat, 05 Mar 2005 14:59:03 +0100 Message-ID: <4229BB27.30009@trash.net> Date: Sat, 05 Mar 2005 14:59:03 +0100 From: Patrick McHardy User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.7.5) Gecko/20050106 Debian/1.7.5-1 X-Accept-Language: en MIME-Version: 1.0 To: "David S. Miller" CC: netdev@oss.sgi.com Subject: [PATCH 2/3 XFRM]: Always reroute in tunnel mode Content-Type: multipart/mixed; boundary="------------080900080003050705020402" X-Virus-Scanned: ClamAV 0.83/748/Fri Mar 4 14:19:11 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 2432 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: kaber@trash.net Precedence: bulk X-list: netdev Content-Length: 3408 Lines: 108 This is a multi-part message in MIME format. --------------080900080003050705020402 Content-Type: text/plain; charset=ISO-8859-15; format=flowed Content-Transfer-Encoding: 7bit --------------080900080003050705020402 Content-Type: text/x-patch; name="02.diff" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="02.diff" # This is a BitKeeper generated diff -Nru style patch. # # ChangeSet # 2005/03/05 01:58:51+01:00 kaber@coreworks.de # [XFRM]: Always reroute in tunnel mode # # Tunnel mode packets are rerouted if the tunnel destination # address is different from the original destination address, # otherwise the old route is used. This is inconsistent, the # old route might have been selected for a given output device # or using routing by tos/fwmark. Always choose a new route # in tunnel mode. # # Signed-off-by: Patrick McHardy # # net/ipv6/xfrm6_policy.c # 2005/03/05 01:58:41+01:00 kaber@coreworks.de +3 -1 # [XFRM]: Always reroute in tunnel mode # # Tunnel mode packets are rerouted if the tunnel destination # address is different from the original destination address, # otherwise the old route is used. This is inconsistent, the # old route might have been selected for a given output device # or using routing by tos/fwmark. Always choose a new route # in tunnel mode. # # Signed-off-by: Patrick McHardy # # net/ipv4/xfrm4_policy.c # 2005/03/05 01:58:41+01:00 kaber@coreworks.de +3 -1 # [XFRM]: Always reroute in tunnel mode # # Tunnel mode packets are rerouted if the tunnel destination # address is different from the original destination address, # otherwise the old route is used. This is inconsistent, the # old route might have been selected for a given output device # or using routing by tos/fwmark. Always choose a new route # in tunnel mode. # # Signed-off-by: Patrick McHardy # diff -Nru a/net/ipv4/xfrm4_policy.c b/net/ipv4/xfrm4_policy.c --- a/net/ipv4/xfrm4_policy.c 2005-03-05 13:03:32 +01:00 +++ b/net/ipv4/xfrm4_policy.c 2005-03-05 13:03:32 +01:00 @@ -59,6 +59,7 @@ int err; int header_len = 0; int trailer_len = 0; + int tunnel = 0; dst = dst_prev = NULL; @@ -81,12 +82,13 @@ if (xfrm[i]->props.mode) { remote = xfrm[i]->id.daddr.a4; local = xfrm[i]->props.saddr.a4; + tunnel = 1; } header_len += xfrm[i]->props.header_len; trailer_len += xfrm[i]->props.trailer_len; } - if (remote != fl->fl4_dst) { + if (tunnel) { struct flowi fl_tunnel = { .nl_u = { .ip4_u = { .daddr = remote, .saddr = local } diff -Nru a/net/ipv6/xfrm6_policy.c b/net/ipv6/xfrm6_policy.c --- a/net/ipv6/xfrm6_policy.c 2005-03-05 13:03:32 +01:00 +++ b/net/ipv6/xfrm6_policy.c 2005-03-05 13:03:32 +01:00 @@ -76,6 +76,7 @@ int err = 0; int header_len = 0; int trailer_len = 0; + int tunnel = 0; dst = dst_prev = NULL; @@ -98,12 +99,13 @@ if (xfrm[i]->props.mode) { remote = (struct in6_addr*)&xfrm[i]->id.daddr; local = (struct in6_addr*)&xfrm[i]->props.saddr; + tunnel = 1; } header_len += xfrm[i]->props.header_len; trailer_len += xfrm[i]->props.trailer_len; } - if (!ipv6_addr_equal(remote, &fl->fl6_dst)) { + if (tunnel) { struct flowi fl_tunnel; memset(&fl_tunnel, 0, sizeof(fl_tunnel)); --------------080900080003050705020402-- From kaber@trash.net Sat Mar 5 05:59:03 2005 Received: with ECARTIS (v1.0.0; list netdev); Sat, 05 Mar 2005 05:59:10 -0800 (PST) Received: from kaber.coreworks.de ([62.206.217.67]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j25Dx2HP023536 for ; Sat, 5 Mar 2005 05:59:03 -0800 Received: from localhost ([127.0.0.1]) by kaber.coreworks.de with esmtp (Exim 4.50) id 1D7Zo2-0000o3-I8; Sat, 05 Mar 2005 14:58:58 +0100 Message-ID: <4229BB22.50107@trash.net> Date: Sat, 05 Mar 2005 14:58:58 +0100 From: Patrick McHardy User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.7.5) Gecko/20050106 Debian/1.7.5-1 X-Accept-Language: en MIME-Version: 1.0 To: "David S. Miller" CC: Maillist netdev Subject: [PATCH 1/3 XFRM]: Fix ICMP tempsel Content-Type: multipart/mixed; boundary="------------020409020007020805000402" X-Virus-Scanned: ClamAV 0.83/748/Fri Mar 4 14:19:11 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 2431 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: kaber@trash.net Precedence: bulk X-list: netdev Content-Length: 2209 Lines: 71 This is a multi-part message in MIME format. --------------020409020007020805000402 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Hi Dave, there was a lot of discussion going on last time I posted these patches, these are the patches everyone agreed on. They are based on your 2.6.12 tree. --------------020409020007020805000402 Content-Type: text/x-patch; name="01.diff" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="01.diff" # This is a BitKeeper generated diff -Nru style patch. # # ChangeSet # 2005/03/05 01:57:26+01:00 kaber@coreworks.de # [XFRM]: Fix ICMP tempsel # # Signed-off-by: Patrick McHardy # # net/ipv6/xfrm6_state.c # 2005/03/05 01:57:18+01:00 kaber@coreworks.de +2 -2 # [XFRM]: Fix ICMP tempsel # # Signed-off-by: Patrick McHardy # # net/ipv4/xfrm4_state.c # 2005/03/05 01:57:18+01:00 kaber@coreworks.de +2 -2 # [XFRM]: Fix ICMP tempsel # # Signed-off-by: Patrick McHardy # diff -Nru a/net/ipv4/xfrm4_state.c b/net/ipv4/xfrm4_state.c --- a/net/ipv4/xfrm4_state.c 2005-03-05 13:03:27 +01:00 +++ b/net/ipv4/xfrm4_state.c 2005-03-05 13:03:27 +01:00 @@ -20,9 +20,9 @@ { x->sel.daddr.a4 = fl->fl4_dst; x->sel.saddr.a4 = fl->fl4_src; - x->sel.dport = fl->fl_ip_dport; + x->sel.dport = xfrm_flowi_dport(fl); x->sel.dport_mask = ~0; - x->sel.sport = fl->fl_ip_sport; + x->sel.sport = xfrm_flowi_sport(fl); x->sel.sport_mask = ~0; x->sel.prefixlen_d = 32; x->sel.prefixlen_s = 32; diff -Nru a/net/ipv6/xfrm6_state.c b/net/ipv6/xfrm6_state.c --- a/net/ipv6/xfrm6_state.c 2005-03-05 13:03:27 +01:00 +++ b/net/ipv6/xfrm6_state.c 2005-03-05 13:03:27 +01:00 @@ -27,9 +27,9 @@ * to current session. */ ipv6_addr_copy((struct in6_addr *)&x->sel.daddr, &fl->fl6_dst); ipv6_addr_copy((struct in6_addr *)&x->sel.saddr, &fl->fl6_src); - x->sel.dport = fl->fl_ip_dport; + x->sel.dport = xfrm_flowi_dport(fl); x->sel.dport_mask = ~0; - x->sel.sport = fl->fl_ip_sport; + x->sel.sport = xfrm_flowi_sport(fl); x->sel.sport_mask = ~0; x->sel.prefixlen_d = 128; x->sel.prefixlen_s = 128; --------------020409020007020805000402-- From kaber@trash.net Sat Mar 5 05:59:31 2005 Received: with ECARTIS (v1.0.0; list netdev); Sat, 05 Mar 2005 05:59:35 -0800 (PST) Received: from kaber.coreworks.de ([62.206.217.67]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j25DxU5b023821 for ; Sat, 5 Mar 2005 05:59:31 -0800 Received: from localhost ([127.0.0.1]) by kaber.coreworks.de with esmtp (Exim 4.50) id 1D7ZoU-0000oD-SD; Sat, 05 Mar 2005 14:59:26 +0100 Message-ID: <4229BB3E.8020203@trash.net> Date: Sat, 05 Mar 2005 14:59:26 +0100 From: Patrick McHardy User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.7.5) Gecko/20050106 Debian/1.7.5-1 X-Accept-Language: en MIME-Version: 1.0 To: "David S. Miller" CC: Maillist netdev Subject: [PATCH 3/3 XFRM]: Fix invalid key for lookup of cached bundles Content-Type: multipart/mixed; boundary="------------060402090104070606010006" X-Virus-Scanned: ClamAV 0.83/748/Fri Mar 4 14:19:11 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 2433 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: kaber@trash.net Precedence: bulk X-list: netdev Content-Length: 2814 Lines: 83 This is a multi-part message in MIME format. --------------060402090104070606010006 Content-Type: text/plain; charset=ISO-8859-15; format=flowed Content-Transfer-Encoding: 7bit --------------060402090104070606010006 Content-Type: text/x-patch; name="03.diff" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="03.diff" # This is a BitKeeper generated diff -Nru style patch. # # ChangeSet # 2005/03/05 13:01:49+01:00 kaber@coreworks.de # [XFRM4]: Fix invalid key for lookup of cached bundles # # __xfrm4_find_bundle() uses a different key than routing for # looking up cached bundles. When the original route was # reused in transport mode it is used even if fwmark/tos # don't match. Also compare tos/fwmark for transport mode # bundles. # # net/ipv4/xfrm4_policy.c # 2005/03/05 13:01:41+01:00 kaber@coreworks.de +8 -0 # [XFRM4]: Fix invalid key for lookup of cached bundles # # __xfrm4_find_bundle() uses a different key than routing for # looking up cached bundles. When the original route was # reused in transport mode it is used even if fwmark/tos # don't match. Also compare tos/fwmark for transport mode # bundles. # # include/net/dst.h # 2005/03/05 13:01:41+01:00 kaber@coreworks.de +1 -0 # [XFRM4]: Fix invalid key for lookup of cached bundles # # __xfrm4_find_bundle() uses a different key than routing for # looking up cached bundles. When the original route was # reused in transport mode it is used even if fwmark/tos # don't match. Also compare tos/fwmark for transport mode # bundles. # diff -Nru a/include/net/dst.h b/include/net/dst.h --- a/include/net/dst.h 2005-03-05 13:03:37 +01:00 +++ b/include/net/dst.h 2005-03-05 13:03:37 +01:00 @@ -48,6 +48,7 @@ #define DST_NOXFRM 2 #define DST_NOPOLICY 4 #define DST_NOHASH 8 +#define DST_XFRM_TUNNEL 16 unsigned long lastuse; unsigned long expires; diff -Nru a/net/ipv4/xfrm4_policy.c b/net/ipv4/xfrm4_policy.c --- a/net/ipv4/xfrm4_policy.c 2005-03-05 13:03:37 +01:00 +++ b/net/ipv4/xfrm4_policy.c 2005-03-05 13:03:37 +01:00 @@ -33,6 +33,13 @@ if (xdst->u.rt.fl.oif == fl->oif && /*XXX*/ xdst->u.rt.fl.fl4_dst == fl->fl4_dst && xdst->u.rt.fl.fl4_src == fl->fl4_src && + (dst->path->flags & DST_XFRM_TUNNEL || + (!(xdst->u.rt.fl.fl4_tos ^ fl->fl4_tos) & + (IPTOS_RT_MASK|RTO_ONLINK) +#ifdef CONFIG_IP_ROUTE_FWMARK + && xdst->u.rt.fl.fl4_fwmark == fl->fl4_fwmark +#endif + )) && xfrm_bundle_ok(xdst, fl, AF_INET)) { dst_clone(dst); break; @@ -97,6 +104,7 @@ err = xfrm_dst_lookup((struct xfrm_dst**)&rt, &fl_tunnel, AF_INET); if (err) goto error; + rt->u.dst.flags |= DST_XFRM_TUNNEL; } else { dst_hold(&rt->u.dst); } --------------060402090104070606010006-- From pedro.fortuna@gmail.com Sat Mar 5 06:09:00 2005 Received: with ECARTIS (v1.0.0; list netdev); Sat, 05 Mar 2005 06:09:07 -0800 (PST) Received: from rproxy.gmail.com (rproxy.gmail.com [64.233.170.197]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j25E8xik025837 for ; Sat, 5 Mar 2005 06:09:00 -0800 Received: by rproxy.gmail.com with SMTP id c51so760073rne for ; Sat, 05 Mar 2005 06:08:56 -0800 (PST) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:reply-to:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:references; b=WOT5+p0GVln2m7tdFzGy21QKOQ3iIBONwtT2N0nWQO/wBrHPW8J5y6/n2Yc2ftB9HevSh5vvNooh1tGCx6k4DnSPyDhp1Fa86xf9yxwNsC2QaoG40msz6yLSf14Zgi9KNsH2DA1wHQnxQlsx9pyrIosJzHr/DZa6FTSWnp8WBS0= Received: by 10.11.99.36 with SMTP id w36mr252708cwb; Sat, 05 Mar 2005 06:08:56 -0800 (PST) Received: by 10.11.99.66 with HTTP; Sat, 5 Mar 2005 06:08:56 -0800 (PST) Message-ID: Date: Sat, 5 Mar 2005 14:08:56 +0000 From: Pedro Fortuna Reply-To: Pedro Fortuna To: Asim Shankar Subject: Re: filtering packtes before OS takes care about them Cc: netdev@oss.sgi.com In-Reply-To: <7bca1cb50502281209798e8a00@mail.gmail.com> Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit References: <09766A6E64A068419B362367800D50C0B58A17@moritz.faps.uni-erlangen.de> <7bca1cb50502281209798e8a00@mail.gmail.com> X-Virus-Scanned: ClamAV 0.83/748/Fri Mar 4 14:19:11 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 2434 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: pedro.fortuna@gmail.com Precedence: bulk X-list: netdev Content-Length: 1393 Lines: 34 Asim, I wasnt able to compile your packet_type_test.c :( I even tried your scripts (i.e. make-native.sh and make-uml.sh), which seem to me that proceeded to compile the example against the kernel source (which I have installed and in place), but all I got was a huge list of errors and warnings, and no .o compiled in the end. ./make-native.sh modules ./make-uml.sh modules I used ubuntu 4.10 with kernel 2.6.8.1-3 and kernel source 2.6.8.1. Any clues? Thanks. -Pedro Fortuna On Mon, 28 Feb 2005 14:09:56 -0600, Asim Shankar wrote: > > i need a possibility to catch IP4 packets (from ethernet devices) before OS' netmodules (IP, UDP, TCP, ICMP, ARP, ROUTE, NETFILTER ...) takes care about them and > > * to delete them from input buffer such that OS' netmodules can't receive them > > * to modify packet headers and move packets to interface related output buffers > > * to keep them in input buffers such that OS' netmodules can take care about them. > > You can process packets even before ip_rcv() gets them by registering > your own packet handler (struct packet_type) using dev_add_pack(). I > have a small sample at: > http://limnos.csrd.uiuc.edu/notes/code-samples/samples/kernel/packet_type/packet_type_test.c > This may not be the cleanest way, but it isn't that dirty either. > > Also see: > http://www.phrack.org/show.php?p=55&a=12 > > -- Asim > > From buytenh@wantstofly.org Sat Mar 5 06:12:28 2005 Received: with ECARTIS (v1.0.0; list netdev); Sat, 05 Mar 2005 06:12:34 -0800 (PST) Received: from xi.wantstofly.org (alephnull.demon.nl [212.238.201.82]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j25ECQHp026445 for ; Sat, 5 Mar 2005 06:12:27 -0800 Received: by xi.wantstofly.org (Postfix, from userid 500) id 590522B0EC; Sat, 5 Mar 2005 15:12:25 +0100 (MET) Date: Sat, 5 Mar 2005 15:12:25 +0100 From: Lennert Buytenhek To: shemminger@osdl.org, netdev@oss.sgi.com Subject: [leo@yuriev.ru: [PATCH] ethernet-bridge: update skb->priority in case forwarded frame has VLAN-header] Message-ID: <20050305141225.GA5180@xi.wantstofly.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.4.1i X-Virus-Scanned: ClamAV 0.83/748/Fri Mar 4 14:19:11 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 2435 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: buytenh@wantstofly.org Precedence: bulk X-list: netdev Content-Length: 3312 Lines: 97 ----- Forwarded message from Leo Yuriev ----- From: Leo Yuriev To: Lennert Buytenhek , Alexey Kuznetsov Cc: linux-kernel@vger.kernel.org Subject: [PATCH] ethernet-bridge: update skb->priority in case forwarded frame has VLAN-header Kernel 2.6 (2.6.11) When ethernet-bridge forward a packet and such ethernet-frame has VLAN-tag, bridge should update skb->prioriry for properly QoS handling. This small patch does this. Currently vlan_TCI-priority directly mapped to skb->priority, but this looks enough. Patch-by: Leo Yuriev -- net/bridge/br_input.c.orig 2005-03-02 10:37:50.000000000 +0300 +++ net/bridge/br_input.c 2005-03-05 16:11:00.000000000 +0300 @@ -5,6 +5,10 @@ * Authors: * Lennert Buytenhek * + * Changes: + * 03/Mar/2005: Leo Yuriev + * Update skb->priority for packets with VLAN-tag. + * * $Id: br_input.c,v 1.10 2001/12/24 04:50:20 davem Exp $ * * This program is free software; you can redistribute it and/or @@ -17,6 +21,9 @@ #include #include #include +#ifdef CONFIG_NET_SCHED +# include +#endif /* CONFIG_NET_SCHED*/ #include "br_private.h" const unsigned char bridge_ula[6] = { 0x01, 0x80, 0xc2, 0x00, 0x00, 0x00 }; @@ -45,6 +52,40 @@ static void br_pass_frame_up(struct net_ br_pass_frame_up_finish); } + +#ifdef CONFIG_NET_SCHED +/* + * Leo Yuriev: Just update skb->priority for properly QoS handling in case + * frame in the skb is contain VLAN-header. + * + * SANITY NOTE: We are referencing to the VLAN_HDR frields, which MAY be + * stored UNALIGNED in the memory. + * According to Dave Miller & Alexey, it will always be aligned, + * so there doesn't need to be any of the unaligned stuff. + * + */ +static __inline__ void br_update_skb_priority_if_vlan(struct sk_buff *skb) +{ + unsigned short vlan_TCI; + struct vlan_hdr *vhdr; + + if (skb->protocol == __constant_htons(ETH_P_8021Q)) { + vhdr = (struct vlan_hdr *)(skb->data); + /* vlan_TCI = ntohs(get_unaligned(&vhdr->h_vlan_TCI)); */ + vlan_TCI = ntohs(vhdr->h_vlan_TCI); +#ifdef VLAN_DEBUG + printk(VLAN_DBG "%s: skb: %p vlan_id: %hx\n", + __FUNCTION__, skb, (vlan_TCI & VLAN_VID_MASK)); +#endif + /* + * We map VLAN_TCI priority (0..7) to skb->priority (0..15) + * most similarly e.g. 0->0, 1->1, .., 7->7 + */ + skb->priority = (vlan_TCI >> 13) & 7; + } +} +#endif /* CONFIG_NET_SCHED */ + /* note: already called with rcu_read_lock (preempt_disabled) */ int br_handle_frame_finish(struct sk_buff *skb) { @@ -54,6 +95,10 @@ int br_handle_frame_finish(struct sk_buf struct net_bridge_fdb_entry *dst; int passedup = 0; +#ifdef CONFIG_NET_SCHED + br_update_skb_priority_if_vlan(skb); +#endif /* CONFIG_NET_SCHED*/ + if (br->dev->flags & IFF_PROMISC) { struct sk_buff *skb2; ----- End forwarded message ----- From zdenek@rcn.com Sat Mar 5 06:34:27 2005 Received: with ECARTIS (v1.0.0; list netdev); Sat, 05 Mar 2005 06:34:30 -0800 (PST) Received: from smtp01.mrf.mail.rcn.net (smtp01.mrf.mail.rcn.net [207.172.4.60]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j25EYQoN027487 for ; Sat, 5 Mar 2005 06:34:27 -0800 Received: from 209-150-50-115.c3-0.nwt-ubr3.sbo-nwt.ma.cable.rcn.com ([209.150.50.115] helo=funex) by smtp01.mrf.mail.rcn.net with smtp (Exim 3.35 #7) id 1D7aML-0007Wp-00; Sat, 05 Mar 2005 09:34:25 -0500 X-Sender: zdenek@pop.rcn.com X-Mailer: QUALCOMM Windows Eudora Pro Version 4.0 Date: Sat, 05 Mar 2005 09:31:32 -0500 To: netdev@oss.sgi.com, linux-net@vger.kernel.org From: Zdenek Radouch Subject: Do you know the linux TCP stack? Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Message-Id: X-Virus-Scanned: ClamAV 0.83/748/Fri Mar 4 14:19:11 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 2436 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: zdenek@rcn.com Precedence: bulk X-list: netdev Content-Length: 781 Lines: 20 I ran out of ideas. Can't find the answers in any docs, and I don't have time to read and analyze the source right now. I will hire you to help me; I need the following to be done in my net device driver: With the ARP disabled (this is well documented so I believe I've done that), while queueing the physical output, I need to get hold of the IP address of where the packet is being sent. Yes, I mean IP address, not Ethernet address, and yes this is not the destination addresses in the IP header. If you can do it, and are interested in helping me, please send me a note, with your hourly consulting rate, or a suggestion of how you'd like to be compensated for the work. Of course, if you'd like to just send me an answer, that would be fine, too. :-) Thanks. -Zdenek From rich@phekda.gotadsl.co.uk Sat Mar 5 06:49:45 2005 Received: with ECARTIS (v1.0.0; list netdev); Sat, 05 Mar 2005 06:49:50 -0800 (PST) Received: from smtp.nildram.co.uk (smtp.nildram.co.uk [195.112.4.54]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j25EnjOh028541 for ; Sat, 5 Mar 2005 06:49:45 -0800 Received: from katrina.int.phekda.gotadsl.co.uk (82-133-65-53.dyn.gotadsl.co.uk [82.133.65.53]) by smtp.nildram.co.uk (Postfix) with ESMTP id E28902BAF39; Sat, 5 Mar 2005 14:49:41 +0000 (GMT) Received: from [192.168.1.4] (katrina.int.phekda.gotadsl.co.uk [192.168.1.4]) by katrina.int.phekda.gotadsl.co.uk (Postfix) with ESMTP id 4B1E2381DC; Sat, 5 Mar 2005 14:52:00 +0000 (GMT) Message-ID: <4229C785.806@phekda.gotadsl.co.uk> Date: Sat, 05 Mar 2005 14:51:49 +0000 From: Richard Dawe User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.3) Gecko/20041020 X-Accept-Language: en, de, fr MIME-Version: 1.0 To: Francois Romieu Cc: Linux netdev Subject: [PATCH]: r8169: prototype parameter name consistency Content-Type: multipart/mixed; boundary="------------040507070404080307080909" X-Virus-Scanned: ClamAV 0.83/748/Fri Mar 4 14:19:11 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 2437 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: rich@phekda.gotadsl.co.uk Precedence: bulk X-list: netdev Content-Length: 1478 Lines: 38 This is a multi-part message in MIME format. --------------040507070404080307080909 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Hello. Attached is a minor clean-up for consistency in the parameter names for a couple of prototypes in the r8169 driver. Bye, Rich =] Signed-Off-By: Richard Dawe --------------040507070404080307080909 Content-Type: text/plain; name="r8169-proto-consistency.patch" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="r8169-proto-consistency.patch" --- linux-2.6.11/drivers/net/r8169.c.orig 2005-03-02 07:38:09.000000000 +0000 +++ linux-2.6.11/drivers/net/r8169.c 2005-03-05 14:41:29.000000000 +0000 @@ -433,10 +433,10 @@ static void rtl8169_hw_start(struct net_ static int rtl8169_close(struct net_device *dev); static void rtl8169_set_rx_mode(struct net_device *dev); static void rtl8169_tx_timeout(struct net_device *dev); -static struct net_device_stats *rtl8169_get_stats(struct net_device *netdev); +static struct net_device_stats *rtl8169_get_stats(struct net_device *dev); static int rtl8169_rx_interrupt(struct net_device *, struct rtl8169_private *, void __iomem *); -static int rtl8169_change_mtu(struct net_device *netdev, int new_mtu); +static int rtl8169_change_mtu(struct net_device *dev, int new_mtu); static void rtl8169_down(struct net_device *dev); #ifdef CONFIG_R8169_NAPI --------------040507070404080307080909-- From domen@coderock.org Sat Mar 5 07:47:35 2005 Received: with ECARTIS (v1.0.0; list netdev); Sat, 05 Mar 2005 07:47:47 -0800 (PST) Received: from trashy.coderock.org (postfix@coderock.org [193.77.147.115]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j25FlYFv031262 for ; Sat, 5 Mar 2005 07:47:35 -0800 Received: by trashy.coderock.org (Postfix, from userid 780) id 5D4041F202; Sat, 5 Mar 2005 16:47:30 +0100 (CET) Received: from localhost (localhost [127.0.0.1]) by trashy.coderock.org (Postfix) with ESMTP id 7038C1F07A; Sat, 5 Mar 2005 16:47:29 +0100 (CET) Received: from localhost.localdomain (localhost [127.0.0.1]) by trashy.coderock.org (Postfix) with ESMTP id 66FDA1EE1E; Sat, 5 Mar 2005 16:47:26 +0100 (CET) Subject: [patch 1/1] net/ltpc: replace schedule_timeout() with ssleep()/msleep() To: acme@conectiva.com.br Cc: netdev@oss.sgi.com, domen@coderock.org, nacc@us.ibm.com, janitor@sternwelten.at From: domen@coderock.org Date: Sat, 05 Mar 2005 16:47:25 +0100 Message-Id: <20050305154726.66FDA1EE1E@trashy.coderock.org> X-Virus-Scanned: ClamAV 0.83/748/Fri Mar 4 14:19:11 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 2438 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: domen@coderock.org Precedence: bulk X-list: netdev Content-Length: 1284 Lines: 41 Use ssleep() / msleep() [as appropriate] instead of schedule_timeout() to guarantee the task delays as expected. Signed-off-by: Nishanth Aravamudan Acked-by: Arnaldo Carvalho de Melo Signed-off-by: Maximilian Attems Signed-off-by: Domen Puncer --- kj-domen/drivers/net/appletalk/ltpc.c | 6 ++---- 1 files changed, 2 insertions(+), 4 deletions(-) diff -puN drivers/net/appletalk/ltpc.c~msleep+ssleep-drivers_net_appletalk_ltpc drivers/net/appletalk/ltpc.c --- kj/drivers/net/appletalk/ltpc.c~msleep+ssleep-drivers_net_appletalk_ltpc 2005-03-05 16:09:41.000000000 +0100 +++ kj-domen/drivers/net/appletalk/ltpc.c 2005-03-05 16:09:41.000000000 +0100 @@ -1109,8 +1109,7 @@ struct net_device * __init ltpc_probe(vo inb_p(io+1); inb_p(io+3); - set_current_state(TASK_UNINTERRUPTIBLE); - schedule_timeout(2*HZ/100); + msleep(20); inb_p(io+0); inb_p(io+2); @@ -1120,8 +1119,7 @@ struct net_device * __init ltpc_probe(vo inb_p(io+5); /* enable dma */ inb_p(io+6); /* tri-state interrupt line */ - set_current_state(TASK_UNINTERRUPTIBLE); - schedule_timeout(HZ); + ssleep(1); /* now, figure out which dma channel we're using, unless it's already been specified */ _ From pb@bieringer.de Sat Mar 5 08:02:05 2005 Received: with ECARTIS (v1.0.0; list netdev); Sat, 05 Mar 2005 08:02:11 -0800 (PST) Received: from smtp1.aerasec.de (pib.aerasec.de [195.226.187.146]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j25G247D032363 for ; Sat, 5 Mar 2005 08:02:05 -0800 Received: from [192.168.1.2] (ppp-82-135-6-168.mnet-online.de [82.135.6.168]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by smtp1.aerasec.de (Postfix) with ESMTP id B8256277FF for ; Sat, 5 Mar 2005 17:01:55 +0100 (CET) Date: Sat, 05 Mar 2005 17:01:53 +0100 From: Peter Bieringer To: Maillist netdev Subject: ip6t_LOG.c: patch killing spaces on ouput of IPv4 address on TUNNEL= Message-ID: X-Mailer: Mulberry/3.1.6 (Linux/x86) MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="==========FB26CE9DD55CAE312C21==========" X-Virus-Scanned: ClamAV 0.83/748/Fri Mar 4 14:19:11 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 2439 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: pb@bieringer.de Precedence: bulk X-list: netdev Content-Length: 2810 Lines: 69 --==========FB26CE9DD55CAE312C21========== Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Disposition: inline Hi, I'm still wondering that this was never fixed since 3 years: --- linux-2.6.11/net/ipv6/netfilter/ip6t_LOG.c.orig 2005-03-05 16:39:41.390675372 +0100 +++ linux-2.6.11/net/ipv6/netfilter/ip6t_LOG.c 2005-03-05 16:56:53.975208199 +0100 @@ -404,10 +404,10 @@ printk("TUNNEL="); p = skb->mac.raw + 12; for (i = 0; i < 4; i++,p++) - printk("%3d%s", *p, + printk("%d%s", *p, i == 3 ? "->" : "."); for (i = 0; i < 4; i++,p++) - printk("%3d%c", *p, + printk("%d%c", *p, i == 3 ? ' ' : '.'); } } This will fix the really not nice output like shown below and avoid simple parsers for becoming in trouble: Mar 5 16:47:31 host kernel: FW6-default-DROP-extIN: IN=sit1 OUT= MAC=01:23:45:67:89:ab->01:23:45:47:89:ac TUNNEL=123.123. 0.123-> 12.123. 6.123 ^^^^^^^^^^^^^^^ ^^^^^^^^^^^^^^^ SRC=fe80:0000:0000:0000:0000:0000:0123:4567 DST=ff3e:0012:3456:789a:0000:0000:0000:1234 LEN=72 TC=0 HOPLIMIT=1 FLOWLBL=0 PROTO=ICMPv6 TYPE=131 CODE=0 I've nowhere else in netfilter log lines such empty space in IPv4 addresses See also: Here, at least trailing "0" were printed. Peter -- Dr. Peter Bieringer http://www.bieringer.de/pb/ GPG/PGP Key 0x958F422D mailto: pb at bieringer dot de Deep Space 6 Co-Founder and Core Member http://www.deepspace6.net/ --==========FB26CE9DD55CAE312C21========== Content-Type: application/octet-stream; name="ip6t_LOG.c.diff" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="ip6t_LOG.c.diff"; size=490 LS0tIGxpbnV4LTIuNi4xMS9uZXQvaXB2Ni9uZXRmaWx0ZXIvaXA2dF9MT0cuYy5vcmlnCTIwMDUt MDMtMDUgMTY6Mzk6NDEuMzkwNjc1MzcyICswMTAwCisrKyBsaW51eC0yLjYuMTEvbmV0L2lwdjYv bmV0ZmlsdGVyL2lwNnRfTE9HLmMJMjAwNS0wMy0wNSAxNjo1Njo1My45NzUyMDgxOTkgKzAxMDAK QEAgLTQwNCwxMCArNDA0LDEwIEBACiAJCQkgICAgcHJpbnRrKCJUVU5ORUw9Iik7CiAJCQkgICAg cCA9IHNrYi0+bWFjLnJhdyArIDEyOwogCQkJICAgIGZvciAoaSA9IDA7IGkgPCA0OyBpKysscCsr KQotCQkJCXByaW50aygiJTNkJXMiLCAqcCwKKwkJCQlwcmludGsoIiVkJXMiLCAqcCwKIAkJCQkJ aSA9PSAzID8gIi0+IiA6ICIuIik7CiAJCQkgICAgZm9yIChpID0gMDsgaSA8IDQ7IGkrKyxwKysp Ci0JCQkJcHJpbnRrKCIlM2QlYyIsICpwLAorCQkJCXByaW50aygiJWQlYyIsICpwLAogCQkJCQlp ID09IDMgPyAnICcgOiAnLicpOwogCQkJICB9CiAJCQl9Cg== --==========FB26CE9DD55CAE312C21==========-- From kaber@trash.net Sat Mar 5 08:08:54 2005 Received: with ECARTIS (v1.0.0; list netdev); Sat, 05 Mar 2005 08:08:59 -0800 (PST) Received: from kaber.coreworks.de ([62.206.217.67]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j25G8rxU000725 for ; Sat, 5 Mar 2005 08:08:53 -0800 Received: from localhost ([127.0.0.1]) by kaber.coreworks.de with esmtp (Exim 4.50) id 1D7bpf-0001cB-Ve; Sat, 05 Mar 2005 17:08:48 +0100 Message-ID: <4229D98F.9010008@trash.net> Date: Sat, 05 Mar 2005 17:08:47 +0100 From: Patrick McHardy User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.7.5) Gecko/20050106 Debian/1.7.5-1 X-Accept-Language: en MIME-Version: 1.0 To: Lennert Buytenhek CC: shemminger@osdl.org, netdev@oss.sgi.com, leo@yuriev.ru Subject: Re: [leo@yuriev.ru: [PATCH] ethernet-bridge: update skb->priority in case forwarded frame has VLAN-header] References: <20050305141225.GA5180@xi.wantstofly.org> In-Reply-To: <20050305141225.GA5180@xi.wantstofly.org> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV 0.83/748/Fri Mar 4 14:19:11 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 2440 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: kaber@trash.net Precedence: bulk X-list: netdev Content-Length: 973 Lines: 28 Lennert Buytenhek wrote: > ----- Forwarded message from Leo Yuriev ----- > > From: Leo Yuriev > To: Lennert Buytenhek , > Alexey Kuznetsov > Cc: linux-kernel@vger.kernel.org > Subject: [PATCH] ethernet-bridge: update skb->priority in case forwarded frame has VLAN-header > > Kernel 2.6 (2.6.11) > > When ethernet-bridge forward a packet and such ethernet-frame has > VLAN-tag, bridge should update skb->prioriry for properly QoS > handling. > > This small patch does this. Currently vlan_TCI-priority directly > mapped to skb->priority, but this looks enough. > > Patch-by: Leo Yuriev It needs to verify the tag is present and accessible using pskb_may_pull(). But I think an ebtables target similar to the iptables CLASSIFY target is a better place for this. It could allow setting skb->priority to an arbitary value or derive it from vlan priority or IP tos. Regards Patrick From tgraf@suug.ch Sat Mar 5 08:23:07 2005 Received: with ECARTIS (v1.0.0; list netdev); Sat, 05 Mar 2005 08:23:11 -0800 (PST) Received: from b.mx.projectdream.org (eth0-0.arisu.projectdream.org [194.158.4.191]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j25GN66D005308 for ; Sat, 5 Mar 2005 08:23:06 -0800 Received: from postel.suug.ch (postel.suug.ch [195.134.158.23]) (using TLSv1 with cipher EDH-RSA-DES-CBC3-SHA (168/168 bits)) (No client certificate requested) by b.mx.projectdream.org (Postfix) with ESMTP id AC11E8A; Sat, 5 Mar 2005 17:22:40 +0100 (CET) Received: by postel.suug.ch (Postfix, from userid 10001) id 316331C0EA; Sat, 5 Mar 2005 17:23:23 +0100 (CET) Date: Sat, 5 Mar 2005 17:23:23 +0100 From: Thomas Graf To: Herbert Xu Cc: davem@davemloft.net, netdev@oss.sgi.com Subject: Re: [PATCH] [NET]: Fix deletion of local addresses only varying in prefix length Message-ID: <20050305162323.GM31837@postel.suug.ch> References: <20050304012003.GA31837@postel.suug.ch> <20050304131419.GE31837@postel.suug.ch> <20050304233212.GA27421@gondor.apana.org.au> <20050305002910.GJ31837@postel.suug.ch> <20050305005911.GA27804@gondor.apana.org.au> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20050305005911.GA27804@gondor.apana.org.au> X-Virus-Scanned: ClamAV 0.83/748/Fri Mar 4 14:19:11 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 2441 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: tgraf@suug.ch Precedence: bulk X-list: netdev Content-Length: 966 Lines: 20 * Herbert Xu <20050305005911.GA27804@gondor.apana.org.au> 2005-03-05 11:59 > On Sat, Mar 05, 2005 at 01:29:10AM +0100, Thomas Graf wrote: > > > > I've been thinking about this since yesterday and the best solution I > > came up so far is to encode it in one of the yet unused bits in > > the prefixlength field. After all we're only using 5bits of it. What > > i'm thinking of in particular is to encode it as in 1 bit wildcard > > flag 5 bits prefix length. > > That's sound fine as long as we treat the current ip(8) prefix length > as a wild card. Although we should keep the behaviour of ip a a 1.1.1.1/24; ip a d 1.1.1.1, what about ip a a 1.1.1.1/24; ip a d 1.1.1.1/16? I think the latter should not result in a deletion. We could achieve this by checking the prefix length if either the exact-match flag is set or the prefixlength is != 32. This is of course quite minor and only affects old iproute2 versions in combination with newer kernels. Thougts? From guffens@auto.ucl.ac.be Sat Mar 5 08:34:38 2005 Received: with ECARTIS (v1.0.0; list netdev); Sat, 05 Mar 2005 08:34:42 -0800 (PST) Received: from sprbodj.inma.ucl.ac.be (sprbodj.inma.ucl.ac.be [130.104.239.239]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j25GYbtG006200 for ; Sat, 5 Mar 2005 08:34:38 -0800 Received: from [192.168.0.20] (unknown [213.189.171.127]) by sprbodj.inma.ucl.ac.be (Postfix) with ESMTP id 1BBE219C8533; Sat, 5 Mar 2005 17:34:34 +0100 (CET) Message-ID: <4229DF97.2040500@auto.ucl.ac.be> Date: Sat, 05 Mar 2005 17:34:31 +0100 From: Vincent Guffens User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.3) Gecko/20040913 X-Accept-Language: en MIME-Version: 1.0 To: Zdenek Radouch Cc: netdev@oss.sgi.com, linux-net@vger.kernel.org Subject: Re: Do you know the linux TCP stack? References: In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-ucl-inma-MailScanner-Information: Please contact the ISP for more information X-ucl-inma-MailScanner: Found to be clean X-MailScanner-From: guffens@auto.ucl.ac.be X-Virus-Scanned: ClamAV 0.83/748/Fri Mar 4 14:19:11 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 2442 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: guffens@auto.ucl.ac.be Precedence: bulk X-list: netdev Content-Length: 1142 Lines: 29 Zdenek Radouch wrote: > I ran out of ideas. Can't find the answers in any docs, > and I don't have time to read and analyze the source right now. > > I will hire you to help me; I need the following to be done in > my net device driver: > > With the ARP disabled (this is well documented so I believe I've done that), > while queueing the physical output, I need to get hold of the IP address > of where the packet is being sent. Yes, I mean IP address, not > Ethernet address, and yes this is not the destination addresses in > the IP header. can you not use the routing table ? In a normal setup, either the network part of your destination IP matches the network part of a directly connected network and the address your are looking for is the destination IP in the packet or it does not match and the next IP is the IP of the gateway found by routing. Is it what you are looking for ? -- Vincent Guffens PhD Student UCL/CESAME tel: +32 10 47 80 30 Value your freedom, or you will lose it, teaches history. "Don't bother us with politics," respond those who don't want to learn. -- Richard M. Stallman From zdenek@rcn.com Sat Mar 5 09:14:23 2005 Received: with ECARTIS (v1.0.0; list netdev); Sat, 05 Mar 2005 09:14:28 -0800 (PST) Received: from smtp06.mrf.mail.rcn.net (smtp06.mrf.mail.rcn.net [207.172.4.65]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j25HEMWc008638 for ; Sat, 5 Mar 2005 09:14:23 -0800 Received: from 209-150-50-115.c3-0.nwt-ubr3.sbo-nwt.ma.cable.rcn.com ([209.150.50.115] helo=funex) by smtp06.mrf.mail.rcn.net with smtp (Exim 3.35 #7) id 1D7cr7-0006TO-00; Sat, 05 Mar 2005 12:14:22 -0500 X-Sender: zdenek@pop.rcn.com X-Mailer: QUALCOMM Windows Eudora Pro Version 4.0 Date: Sat, 05 Mar 2005 12:11:29 -0500 To: netdev@oss.sgi.com, linux-net@vger.kernel.org From: Zdenek Radouch Subject: Re: Do you know the linux TCP stack? In-Reply-To: <4229DF97.2040500@auto.ucl.ac.be> References: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Message-Id: X-Virus-Scanned: ClamAV 0.83/748/Fri Mar 4 14:19:11 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 2443 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: zdenek@rcn.com Precedence: bulk X-list: netdev Content-Length: 2218 Lines: 55 That's correct. The routing has already been done (I'm about to queue the packet to the hardware), and all I need is to find the IP address that came out of the routing function. As you said, the address may or may not be the one in the IP header. So how do I get hold of it? In the BSD stack, this address is part of the transmit API, but under Linux that does not seem to be the case. To illustrate this further, my hardware uses the interface IP addreses also for the physical layer (instead of Ethernet addresses). Before I send the packet I need to fill the physical header. This would normally be done by ARP, but in my case the IP to physical is an identity mapping. I just have no clue how to implement it under a stack/API that seems to target mainly the Ethernet model. -Zdenek At 05:34 PM 3/5/05 +0100, Vincent Guffens wrote: >Zdenek Radouch wrote: >> I ran out of ideas. Can't find the answers in any docs, >> and I don't have time to read and analyze the source right now. >> >> I will hire you to help me; I need the following to be done in >> my net device driver: >> >> With the ARP disabled (this is well documented so I believe I've done that), >> while queueing the physical output, I need to get hold of the IP address >> of where the packet is being sent. Yes, I mean IP address, not >> Ethernet address, and yes this is not the destination addresses in >> the IP header. > >can you not use the routing table ? In a normal setup, either the >network part of your destination IP matches the network part of a >directly connected network and the address your are looking for is the >destination IP in the packet or it does not match and the next IP is the > IP of the gateway found by routing. > >Is it what you are looking for ? > > >-- > Vincent Guffens > PhD Student UCL/CESAME > tel: +32 10 47 80 30 >Value your freedom, or you will lose it, teaches history. >"Don't bother us with politics," respond those who don't want to learn. > -- Richard M. Stallman >- >To unsubscribe from this list: send the line "unsubscribe linux-net" in >the body of a message to majordomo@vger.kernel.org >More majordomo info at http://vger.kernel.org/majordomo-info.html > From tgraf@suug.ch Sat Mar 5 09:22:38 2005 Received: with ECARTIS (v1.0.0; list netdev); Sat, 05 Mar 2005 09:22:43 -0800 (PST) Received: from b.mx.projectdream.org (eth0-0.arisu.projectdream.org [194.158.4.191]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j25HMbrm009379 for ; Sat, 5 Mar 2005 09:22:37 -0800 Received: from postel.suug.ch (postel.suug.ch [195.134.158.23]) (using TLSv1 with cipher EDH-RSA-DES-CBC3-SHA (168/168 bits)) (No client certificate requested) by b.mx.projectdream.org (Postfix) with ESMTP id 6B01287 for ; Sat, 5 Mar 2005 18:22:14 +0100 (CET) Received: by postel.suug.ch (Postfix, from userid 10001) id 5AD0C1C0EA; Sat, 5 Mar 2005 18:22:57 +0100 (CET) Date: Sat, 5 Mar 2005 18:22:57 +0100 From: Thomas Graf To: netdev@oss.sgi.com Subject: [RFC] neighbour tables configuration via rtnetlink Message-ID: <20050305172257.GN31837@postel.suug.ch> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline X-Virus-Scanned: ClamAV 0.83/748/Fri Mar 4 14:19:11 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 2444 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: tgraf@suug.ch Precedence: bulk X-list: netdev Content-Length: 7401 Lines: 241 Hi, I have need to change multiple neighbour table parameters as a atomic operation which lead me to make it available via rtnetlink. I started with the patch below which extends the existing RTM_*NEIGH commands by a flag NTF_TABLES changing the context from entries to the tables itself. I regard this as quite hacky, the alternative would be to add a new RTM operation set, i.e. RTM_*NEIGHTBL or alike. It's only dumping for now but I plan to also allow modification of parameters. One of the problem that arises is the fact that the interface identifier, to differ the various parameters sets, is stored in the sysctl table which would introduce quite a nasty depedency. Before I go ahead, putting more effort into it, what is our preferred interface for network configuration? My personal preference is to make everything available via netlink with the long term plan to extend it with distributive remote configuration protocol in userspace. If so, shall we continue to push everything into rtnetlink regardless of the association to routing? The only drawback of the currently "overloaded" rtnetlink is the rtnl semaphore which has grown into something like the BKL for networking. I'm not aware of any performance problems or other issues because of this except for the module loading over nfs. Does anyone? Thoughts? diff -Nru linux-2.6.11-rc3-bk3.orig/include/linux/rtnetlink.h linux-2.6.11-rc3-bk3/include/linux/rtnetlink.h --- linux-2.6.11-rc3-bk3.orig/include/linux/rtnetlink.h 2005-02-11 04:04:22.000000000 +0100 +++ linux-2.6.11-rc3-bk3/include/linux/rtnetlink.h 2005-02-11 02:02:52.000000000 +0100 @@ -459,6 +459,7 @@ * Neighbor Cache Entry Flags */ +#define NTF_TABLES 0x01 /* Dump neighbour tables */ #define NTF_PROXY 0x08 /* == ATF_PUBL */ #define NTF_ROUTER 0x80 @@ -487,6 +488,71 @@ __u32 ndm_refcnt; }; +enum { + NDTA_UNSPEC, + NDTA_TABLE, + NDTA_PARAMS, + NDTA_STATS, + __NDTA_MAX +}; +#define NDTA_MAX (__NDTA_MAX - 1) + +/***** + * Neighbour Tables Access + *****/ + +struct nd_table_stats +{ + __u64 ndts_allocs; + __u64 ndts_destroys; + __u64 ndts_hash_grows; + __u64 ndts_res_failed; + __u64 ndts_lookups; + __u64 ndts_hits; + __u64 ndts_rcv_probes_mcast; + __u64 ndts_rcv_probes_ucast; + __u64 ndts_periodic_gc_runs; + __u64 ndts_forced_gc_runs; +}; + +struct ndt_params +{ + __u32 ndtp_refcnt; + __u32 ndtp_base_reachable_time; + __u32 ndtp_reachable_time; + __u32 ndtp_retrans_time; + __u32 ndtp_gc_staletime; + __u32 ndtp_delay_probe_time; + __u32 ndtp_queue_len; + __u32 ndtp_app_probes; + __u32 ndtp_ucast_probes; + __u32 ndtp_mcast_probes; + __u32 ndtp_anycast_delay; + __u32 ndtp_proxy_delay; + __u32 ndtp_proxy_qlen; + __u32 ndtp_locktime; +}; + +#define NDT_TBLNAMSIZ 16 + +struct nd_table +{ + char ndt_id[NDT_TBLNAMSIZ]; + __u16 ndt_key_len; + __u16 ndt_entry_size; + __u16 ndt_gc_interval; + __u16 ndt_gc_thresh1; + __u16 ndt_gc_thresh2; + __u16 ndt_gc_thresh3; + __u32 ndt_entries; + __u32 ndt_last_flush; + __u32 ndt_last_rand; + __u32 ndt_hash_rnd; + __u32 ndt_hash_mask; + __u32 ndt_hash_chain_gc; + __u32 ndt_proxy_qlen; +}; + /**** * General form of address family dependent message. ****/ diff -Nru linux-2.6.11-rc3-bk3.orig/net/core/neighbour.c linux-2.6.11-rc3-bk3/net/core/neighbour.c --- linux-2.6.11-rc3-bk3.orig/net/core/neighbour.c 2005-02-11 04:04:22.000000000 +0100 +++ linux-2.6.11-rc3-bk3/net/core/neighbour.c 2005-02-11 02:00:26.000000000 +0100 @@ -1623,13 +1623,109 @@ return rc; } +static int neigh_dump_table_meta(struct neigh_table *tbl, struct sk_buff *skb, + struct netlink_callback *cb) +{ + int i, locked = 0; + unsigned char *b = skb->tail; + struct nd_table ndtbl; + struct nd_table_stats st; + struct neigh_parms *p; + struct rtattr *rta; + int pid = NETLINK_CB(cb->skb).pid; + struct nlmsghdr *nlh = NLMSG_PUT(skb, pid, cb->nlh->nlmsg_seq, + RTM_NEWNEIGH, sizeof(struct ndmsg)); + struct ndmsg *ndm = NLMSG_DATA(nlh); + + nlh->nlmsg_flags = pid ? NLM_F_MULTI : 0; + ndm->ndm_flags = NTF_TABLES; + ndm->ndm_type = 0; + ndm->ndm_state = 0; + ndm->ndm_ifindex = 0; + + read_lock_bh(&tbl->lock); + locked = 1; + + ndm->ndm_family = tbl->family; + ndtbl.ndt_key_len = tbl->key_len; + ndtbl.ndt_entry_size = tbl->entry_size; + ndtbl.ndt_gc_interval = tbl->gc_interval; + ndtbl.ndt_gc_thresh1 = tbl->gc_thresh1; + ndtbl.ndt_gc_thresh1 = tbl->gc_thresh2; + ndtbl.ndt_gc_thresh1 = tbl->gc_thresh3; + ndtbl.ndt_entries = atomic_read(&tbl->entries); + ndtbl.ndt_last_flush = tbl->last_flush; + ndtbl.ndt_last_rand = tbl->last_rand; + ndtbl.ndt_hash_rnd = tbl->hash_rnd; + ndtbl.ndt_hash_mask = tbl->hash_mask; + ndtbl.ndt_hash_chain_gc = tbl->hash_chain_gc; + ndtbl.ndt_proxy_qlen = tbl->proxy_queue.qlen; + + strncpy(ndtbl.ndt_id, tbl->id, sizeof(ndtbl.ndt_id)); + RTA_PUT(skb, NDTA_TABLE, sizeof(ndtbl), &ndtbl); + + st.ndts_allocs = tbl->stats->allocs; + st.ndts_destroys = tbl->stats->destroys; + st.ndts_hash_grows = tbl->stats->hash_grows; + st.ndts_res_failed = tbl->stats->res_failed; + st.ndts_lookups = tbl->stats->lookups; + st.ndts_hits = tbl->stats->hits; + st.ndts_rcv_probes_mcast = tbl->stats->rcv_probes_mcast; + st.ndts_rcv_probes_ucast = tbl->stats->rcv_probes_ucast; + st.ndts_periodic_gc_runs = tbl->stats->periodic_gc_runs; + st.ndts_forced_gc_runs = tbl->stats->forced_gc_runs; + RTA_PUT(skb, NDTA_STATS, sizeof(st), &st); + + rta = (struct rtattr *) skb->tail; + RTA_PUT(skb, NDTA_PARAMS, 0, NULL); + + for (p = &tbl->parms, i = 1; p ; p = p->next, i++) { + struct ndt_params pa; + + /* FIXME: ifindex from sysctl table should be included + * here to allow userspace to differ each parameter set */ + + pa.ndtp_refcnt = atomic_read(&p->refcnt); + pa.ndtp_base_reachable_time = p->base_reachable_time; + pa.ndtp_reachable_time = p->reachable_time; + pa.ndtp_retrans_time = p->retrans_time; + pa.ndtp_gc_staletime = p->gc_staletime; + pa.ndtp_delay_probe_time = p->delay_probe_time; + pa.ndtp_queue_len = p->queue_len; + pa.ndtp_app_probes = p->app_probes; + pa.ndtp_ucast_probes = p->ucast_probes; + pa.ndtp_mcast_probes = p->mcast_probes; + pa.ndtp_anycast_delay = p->anycast_delay; + pa.ndtp_proxy_delay = p->proxy_delay; + pa.ndtp_proxy_qlen = p->proxy_qlen; + pa.ndtp_locktime = p->locktime; + RTA_PUT(skb, i, sizeof(pa), &pa); + } + + rta->rta_len = (skb->tail - (unsigned char *) rta); + + read_unlock_bh(&tbl->lock); + locked = 0; + + nlh->nlmsg_len = skb->tail - b; + return skb->len; + +nlmsg_failure: +rtattr_failure: + if (locked) + read_unlock_bh(&tbl->lock); + skb_trim(skb, b - skb->data); + return -1; +} + int neigh_dump_info(struct sk_buff *skb, struct netlink_callback *cb) { struct neigh_table *tbl; - int t, family, s_t; + int t, family, s_t, flags; read_lock(&neigh_tbl_lock); family = ((struct rtgenmsg *)NLMSG_DATA(cb->nlh))->rtgen_family; + flags = ((struct ndmsg *)NLMSG_DATA(cb->nlh))->ndm_flags; s_t = cb->args[0]; for (tbl = neigh_tables, t = 0; tbl; tbl = tbl->next, t++) { @@ -1638,8 +1734,13 @@ if (t > s_t) memset(&cb->args[1], 0, sizeof(cb->args) - sizeof(cb->args[0])); - if (neigh_dump_table(tbl, skb, cb) < 0) - break; + if (flags & NTF_TABLES) { + if (neigh_dump_table_meta(tbl, skb, cb) < 0) + break; + } else { + if (neigh_dump_table(tbl, skb, cb) < 0) + break; + } } read_unlock(&neigh_tbl_lock); From webmaster@rapidforum.com Sat Mar 5 09:57:09 2005 Received: with ECARTIS (v1.0.0; list netdev); Sat, 05 Mar 2005 09:57:14 -0800 (PST) Received: from rapidforum.com (www.rapidforum.com [80.237.244.2]) by oss.sgi.com (8.13.0/8.13.0) with SMTP id j25Hv7Gd011075 for ; Sat, 5 Mar 2005 09:57:08 -0800 Received: (qmail 32725 invoked by uid 1004); 5 Mar 2005 17:57:06 -0000 Received: from p3ee04e2f.dip0.t-ipconnect.de (HELO ?62.224.78.47?) (62.224.78.47) by www.rapidforum.com with SMTP; 5 Mar 2005 17:57:06 -0000 Message-ID: <4229F2EC.8090103@rapidforum.com> Date: Sat, 05 Mar 2005 18:57:00 +0100 From: Christian Schmid User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.8a3) Gecko/20040817 X-Accept-Language: de, en MIME-Version: 1.0 To: netdev@oss.sgi.com Subject: Still bug-hunting Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV 0.83/748/Fri Mar 4 14:19:11 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 2445 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: webmaster@rapidforum.com Precedence: bulk X-list: netdev Content-Length: 669 Lines: 14 Hello. I have found out that the slow-down issue with many sockets is a memory problem now. Not that I do not have enough but the vm isnt able to reclaim fast-enough. Problem temporarily solved by setting lower_zone_protection to 1024. Still I wonder why /proc/net/sockstat shows this: sockets: used 1637 TCP: inuse 1761 orphan 179 tw 3743 alloc 1761 mem 54224 The send-buffer is set to 128 and the rcv-buffer to 16 so theoretically it should be 1637*144=235728 so I assume the buffers are allocated dynamically when they are really needed... I suppose the slow-down wouldnt appear if the buffers are allocated statically. Is there any way to check this? Chris From jgarzik@pobox.com Sat Mar 5 10:28:30 2005 Received: with ECARTIS (v1.0.0; list netdev); Sat, 05 Mar 2005 10:28:35 -0800 (PST) Received: from parcelfarce.linux.theplanet.co.uk (parcelfarce.linux.theplanet.co.uk [195.92.249.252]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j25ISTom012431 for ; Sat, 5 Mar 2005 10:28:29 -0800 Received: from [69.134.152.124] (helo=[10.10.10.88]) by parcelfarce.linux.theplanet.co.uk with asmtp (TLSv1:AES256-SHA:256) (Exim 4.33) id 1D7e0k-0006vB-KU; Sat, 05 Mar 2005 18:28:22 +0000 Message-ID: <4229FA32.4000401@pobox.com> Date: Sat, 05 Mar 2005 13:28:02 -0500 From: Jeff Garzik User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.3) Gecko/20040922 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Daniele Venzano CC: netdev@oss.sgi.com Subject: Re: [PATCH 1/1] More ethtool support for sis900 References: <20050305134011.23638.68926@localhost.localdomain> In-Reply-To: <20050305134011.23638.68926@localhost.localdomain> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV 0.83/748/Fri Mar 4 14:19:11 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 2446 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: jgarzik@pobox.com Precedence: bulk X-list: netdev Content-Length: 3354 Lines: 107 Daniele Venzano wrote: > > Add support for using generic mii interface > Add support for the following ethtool ops: > - get_link > - get_settings > - set_settings > - nway_reset > > > > Signed-off-by: Daniele Venzano > > > ------------------------------------------------------------------------ > > Index: sis900.c > =================================================================== > --- a/drivers/net/sis900.c (revision 95) > +++ b/drivers/net/sis900.c (revision 97) > @@ -161,6 +161,7 @@ > struct mii_phy * mii; > struct mii_phy * first_mii; /* record the first mii structure */ > unsigned int cur_phy; > + struct mii_if_info mii_info; > > struct timer_list timer; /* Link status detection timer. */ > u8 autong_complete; /* 1: auto-negotiate complete */ > @@ -199,7 +200,7 @@ > static int sis900_mii_probe (struct net_device * net_dev); > static void sis900_init_rxfilter (struct net_device * net_dev); > static u16 read_eeprom(long ioaddr, int location); > -static u16 mdio_read(struct net_device *net_dev, int phy_id, int location); > +static int mdio_read(struct net_device *net_dev, int phy_id, int location); > static void mdio_write(struct net_device *net_dev, int phy_id, int location, int val); > static void sis900_timer(unsigned long data); > static void sis900_check_mode (struct net_device *net_dev, struct mii_phy *mii_phy); > @@ -468,7 +469,13 @@ > sis_priv->msg_enable = sis900_debug; > else > sis_priv->msg_enable = SIS900_DEF_MSG; > - > + > + sis_priv->mii_info.dev = net_dev; > + sis_priv->mii_info.mdio_read = mdio_read; > + sis_priv->mii_info.mdio_write = mdio_write; > + sis_priv->mii_info.phy_id_mask = 0x1f; > + sis_priv->mii_info.reg_num_mask = 0x1f; > + > ret = register_netdev(net_dev); > if (ret) > goto err_unmap_rx; > @@ -507,6 +514,8 @@ > goto err_out_unregister; > } > > + sis_priv->mii_info.phy_id = sis_priv->cur_phy; > + > /* save our host bridge revision */ > dev = pci_get_device(PCI_VENDOR_ID_SI, PCI_DEVICE_ID_SI_630, NULL); > if (dev) { > @@ -843,7 +852,7 @@ > * Please see SiS7014 or ICS spec > */ > > -static u16 mdio_read(struct net_device *net_dev, int phy_id, int location) > +static int mdio_read(struct net_device *net_dev, int phy_id, int location) > { > long mdio_addr = net_dev->base_addr + mear; > int mii_cmd = MIIread|(phy_id< @@ -1943,10 +1952,41 @@ > sis_priv->msg_enable = value; > } > > +static u32 sis900_get_link(struct net_device *net_dev) > +{ > + struct sis900_private *sis_priv = net_dev->priv; > + return mii_link_ok(&sis_priv->mii_info); > +} > + > +static int sis900_get_settings(struct net_device *net_dev, > + struct ethtool_cmd *cmd) > +{ > + struct sis900_private *sis_priv = net_dev->priv; > + mii_ethtool_gset(&sis_priv->mii_info, cmd); > + return 0; > +} > + > +static int sis900_set_settings(struct net_device *net_dev, > + struct ethtool_cmd *cmd) > +{ > + struct sis900_private *sis_priv = net_dev->priv; > + return mii_ethtool_sset(&sis_priv->mii_info, cmd); > +} > + > +static int sis900_nway_reset(struct net_device *net_dev) > +{ > + struct sis900_private *sis_priv = net_dev->priv; > + return mii_nway_restart(&sis_priv->mii_info); > +} I should think you want locking for these, as is present in other drivers... Jeff From davem@davemloft.net Sat Mar 5 10:30:20 2005 Received: with ECARTIS (v1.0.0; list netdev); Sat, 05 Mar 2005 10:30:25 -0800 (PST) Received: from cheetah.davemloft.net (mail@dsl027-180-174.sfo1.dsl.speakeasy.net [216.27.180.174]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j25IUJrb012863 for ; Sat, 5 Mar 2005 10:30:20 -0800 Received: from localhost ([127.0.0.1] helo=cheetah.davemloft.net ident=davem) by cheetah.davemloft.net with smtp (Exim 3.36 #1 (Debian)) id 1D7e1e-0006Qe-00; Sat, 05 Mar 2005 10:29:18 -0800 Date: Sat, 5 Mar 2005 10:29:18 -0800 From: "David S. Miller" To: Christian Schmid Cc: netdev@oss.sgi.com Subject: Re: Still bug-hunting Message-Id: <20050305102918.15fd422c.davem@davemloft.net> In-Reply-To: <4229F2EC.8090103@rapidforum.com> References: <4229F2EC.8090103@rapidforum.com> X-Mailer: Sylpheed version 1.0.1 (GTK+ 1.2.10; sparc-unknown-linux-gnu) X-Face: "_;p5u5aPsO,_Vsx"^v-pEq09'CU4&Dc1$fQExov$62l60cgCc%FnIwD=.UF^a>?5'9Kn[;433QFVV9M..2eN.@4ZWPGbdi<=?[:T>y?SD(R*-3It"Vj:)"dP Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV 0.83/748/Fri Mar 4 14:19:11 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 2447 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: davem@davemloft.net Precedence: bulk X-list: netdev Content-Length: 214 Lines: 6 On Sat, 05 Mar 2005 18:57:00 +0100 Christian Schmid wrote: > I have found out that the slow-down issue with many sockets is a memory problem now. Thanks for the test case we asked for. From herbert@gondor.apana.org.au Sat Mar 5 10:31:13 2005 Received: with ECARTIS (v1.0.0; list netdev); Sat, 05 Mar 2005 10:31:20 -0800 (PST) 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 j25IVBMh013277 for ; Sat, 5 Mar 2005 10:31:12 -0800 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 1D7e36-0004y2-00; Sun, 06 Mar 2005 05:30:48 +1100 Received: from herbert by gondolin.me.apana.org.au with local (Exim 3.36 #1 (Debian)) id 1D7e2T-0006st-00; Sun, 06 Mar 2005 05:30:09 +1100 Date: Sun, 6 Mar 2005 05:30:09 +1100 To: Thomas Graf Cc: davem@davemloft.net, netdev@oss.sgi.com Subject: Re: [PATCH] [NET]: Fix deletion of local addresses only varying in prefix length Message-ID: <20050305183009.GA26438@gondor.apana.org.au> References: <20050304012003.GA31837@postel.suug.ch> <20050304131419.GE31837@postel.suug.ch> <20050304233212.GA27421@gondor.apana.org.au> <20050305002910.GJ31837@postel.suug.ch> <20050305005911.GA27804@gondor.apana.org.au> <20050305162323.GM31837@postel.suug.ch> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20050305162323.GM31837@postel.suug.ch> User-Agent: Mutt/1.5.6+20040907i From: Herbert Xu X-Virus-Scanned: ClamAV 0.83/748/Fri Mar 4 14:19:11 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 2448 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: herbert@gondor.apana.org.au Precedence: bulk X-list: netdev Content-Length: 773 Lines: 17 On Sat, Mar 05, 2005 at 05:23:23PM +0100, Thomas Graf wrote: > > Although we should keep the behaviour of ip a a 1.1.1.1/24; ip a d > 1.1.1.1, what about ip a a 1.1.1.1/24; ip a d 1.1.1.1/16? I think the > latter should not result in a deletion. We could achieve this by checking > the prefix length if either the exact-match flag is set or the > prefixlength is != 32. This is of course quite minor and only affects > old iproute2 versions in combination with newer kernels. It's fine by me as long as the code doesn't get too complex because of it. Cheers, -- Visit Openswan at http://www.openswan.org/ Email: Herbert Xu ~{PmV>HI~} Home Page: http://gondor.apana.org.au/~herbert/ PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt From ak@muc.de Sat Mar 5 10:34:29 2005 Received: with ECARTIS (v1.0.0; list netdev); Sat, 05 Mar 2005 10:34:34 -0800 (PST) Received: from one.firstfloor.org (one.firstfloor.org [213.235.205.2]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j25IYQDC014130 for ; Sat, 5 Mar 2005 10:34:29 -0800 Received: by one.firstfloor.org (Postfix, from userid 502) id D9529D033E; Sat, 5 Mar 2005 19:34:22 +0100 (CET) To: Zdenek Radouch Cc: netdev@oss.sgi.com Subject: Re: Do you know the linux TCP stack? References: From: Andi Kleen Date: Sat, 05 Mar 2005 19:34:22 +0100 In-Reply-To: (Zdenek Radouch's message of "Sat, 05 Mar 2005 09:31:32 -0500") Message-ID: User-Agent: Gnus/5.110002 (No Gnus v0.2) Emacs/21.3 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Virus-Scanned: ClamAV 0.83/748/Fri Mar 4 14:19:11 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 2449 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: ak@muc.de Precedence: bulk X-list: netdev Content-Length: 486 Lines: 13 Zdenek Radouch writes: > > If you can do it, and are interested in helping me, please send me > a note, with your hourly consulting rate, or a suggestion of how > you'd like to be compensated for the work. Of course, if you'd > like to just send me an answer, that would be fine, too. :-) ((struct rtentry *)(skb->dst))->rt_spec_dst You would need to make sure the packet is IP first, and even then it may fail (e.g. injected IP packet from a packet socket) -Andi From davem@davemloft.net Sat Mar 5 10:40:34 2005 Received: with ECARTIS (v1.0.0; list netdev); Sat, 05 Mar 2005 10:40:37 -0800 (PST) Received: from cheetah.davemloft.net (mail@dsl027-180-174.sfo1.dsl.speakeasy.net [216.27.180.174]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j25IeXp2014901 for ; Sat, 5 Mar 2005 10:40:33 -0800 Received: from localhost ([127.0.0.1] helo=cheetah.davemloft.net ident=davem) by cheetah.davemloft.net with smtp (Exim 3.36 #1 (Debian)) id 1D7eBV-0006Uo-00; Sat, 05 Mar 2005 10:39:29 -0800 Date: Sat, 5 Mar 2005 10:39:29 -0800 From: "David S. Miller" To: Zdenek Radouch Cc: netdev@oss.sgi.com, linux-net@vger.kernel.org Subject: Re: Do you know the linux TCP stack? Message-Id: <20050305103929.46255b6c.davem@davemloft.net> In-Reply-To: References: X-Mailer: Sylpheed version 1.0.1 (GTK+ 1.2.10; sparc-unknown-linux-gnu) X-Face: "_;p5u5aPsO,_Vsx"^v-pEq09'CU4&Dc1$fQExov$62l60cgCc%FnIwD=.UF^a>?5'9Kn[;433QFVV9M..2eN.@4ZWPGbdi<=?[:T>y?SD(R*-3It"Vj:)"dP Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV 0.83/748/Fri Mar 4 14:19:11 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 2450 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: davem@davemloft.net Precedence: bulk X-list: netdev Content-Length: 124 Lines: 5 The routing entry used is in "skb->dst", cast it to a "struct rtentry *" and look at the contents. $5000.00USD please :-) From olof@austin.ibm.com Sat Mar 5 10:42:22 2005 Received: with ECARTIS (v1.0.0; list netdev); Sat, 05 Mar 2005 10:42:27 -0800 (PST) Received: from e5.ny.us.ibm.com (e5.ny.us.ibm.com [32.97.182.145]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j25IgLMM015366 for ; Sat, 5 Mar 2005 10:42:22 -0800 Received: from d01relay02.pok.ibm.com (d01relay02.pok.ibm.com [9.56.227.234]) by e5.ny.us.ibm.com (8.12.11/8.12.11) with ESMTP id j25IgGIs024764 for ; Sat, 5 Mar 2005 13:42:16 -0500 Received: from d01av01.pok.ibm.com (d01av01.pok.ibm.com [9.56.224.215]) by d01relay02.pok.ibm.com (8.12.10/NCO/VER6.6) with ESMTP id j25IgG5M061560 for ; Sat, 5 Mar 2005 13:42:16 -0500 Received: from d01av01.pok.ibm.com (loopback [127.0.0.1]) by d01av01.pok.ibm.com (8.12.11/8.12.11) with ESMTP id j25IgFmf014911 for ; Sat, 5 Mar 2005 13:42:16 -0500 Received: from localhost.localdomain (ppc64.austin.ibm.com [9.53.94.54]) by d01av01.pok.ibm.com (8.12.11/8.12.11) with ESMTP id j25IgFIm014907; Sat, 5 Mar 2005 13:42:15 -0500 Received: by localhost.localdomain (Postfix, from userid 1000) id B50E120526; Sat, 5 Mar 2005 12:38:58 -0600 (CST) Date: Sat, 5 Mar 2005 12:40:56 -0600 To: rl@hellgate.ch Cc: netdev@oss.sgi.com, jgarzik@pobox.com, akpm@osdl.org Subject: [PATCH] [VIA RHINE] older chips oops on shutdown Message-ID: <20050305184056.GA11056@austin.ibm.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.5.6+20040523i From: olof@austin.ibm.com (Olof Johansson) X-Virus-Scanned: ClamAV 0.83/748/Fri Mar 4 14:19:11 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 2451 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: olof@austin.ibm.com Precedence: bulk X-list: netdev Content-Length: 2971 Lines: 83 Hi, Kernel 2.6.11, hardware is a MSI KT333-based board with an XP1800. I'm oopsing on shutdown on a machine that has a Via Rhine adapter in it: Unable to handle kernel paging request at virtual address e0803003 printing eip: c01f262c *pde = 014dc067 *pte = 00000000 Oops: 0000 [#1] Modules linked in: cpufreq_userspace cpufreq_powersave cpufreq_ondemand CPU: 0 EIP: 0060:[] Not tainted VLI EFLAGS: 00010292 (2.6.11) EIP is at ioread8+0x2c/0x40 eax: e0803003 ebx: e0803003 ecx: c026b430 edx: e0803003 esi: dff90260 edi: e0802f80 ebp: dd117e74 esp: dd117e74 ds: 007b es: 007b ss: 0068 Process reboot (pid: 5769, threadinfo=dd117000 task=dfafa080) Stack: dd117e8c c026b490 dff90040 c151ccd4 c044a1a8 b7fdc078 dd117ea4 c0253ad9 c151ccd4 00000042 fee1dead 00000001 dd117fbc c012461c c04d72a8 00000001 00000000 00010800 00000000 dd117ed8 c013b40b dffe7380 00030800 00000000 Call Trace: [] show_stack+0x7f/0xa0 [] show_registers+0x15a/0x1c0 [] die+0xce/0x150 [] do_page_fault+0x356/0x692 [] error_code+0x2b/0x30 [] rhine_shutdown+0x60/0x140 [] device_shutdown+0x89/0x8b [] sys_reboot+0xac/0x200 [] sysenter_past_esp+0x52/0x75 Code: 3d ff ff 03 00 89 c2 89 e5 77 20 66 31 c0 3d 00 00 01 00 75 0c 81 e2 ff ff 00 00 ec 0f b6 c0 c9 c3 0f 0b 37 00 7b 65 3b c0 eb ea <0f> b6 00 eb ec eb 0d 90 90 90 90 90 90 90 90 90 90 90 90 90 55 Seems like it is the ioread8 in: /* Hit power state D3 (sleep) */ iowrite8(ioread8(ioaddr + StickyHW) | 0x03, ioaddr + StickyHW); that fails. StickyHW is 0x83. lspci says: 0000:00:07.0 Ethernet controller: VIA Technologies, Inc. VT86C100A [Rhine] (rev 06) Flags: bus master, medium devsel, latency 32, IRQ 18 I/O ports at ec00 [size=128] Memory at dfffff80 (32-bit, non-prefetchable) [size=128] In other words, it's trying to read outside of the I/O range (0x80), which matches the fauling address. I'm guessing my chip revision doesn't support WOL, it's a crappy noname card. It does seem as if rhine_power_init checks quirks for rqWOL before touching any registers. Should rhine_shutdown do the same? Proposed patch below, which resolves the problem on my system. -Olof --- Check to make sure WOL is supported before setting it up in rhine_shutdown. Signed-off-by: Olof Johansson Index: linux-2.6.11/drivers/net/via-rhine.c =================================================================== --- linux-2.6.11.orig/drivers/net/via-rhine.c 2005-03-02 01:38:32.000000000 -0600 +++ linux-2.6.11/drivers/net/via-rhine.c 2005-03-05 12:25:34.000000000 -0600 @@ -1899,6 +1899,9 @@ struct rhine_private *rp = netdev_priv(dev); void __iomem *ioaddr = rp->base; + if (!(rp->quirks & rqWOL)) + return; /* Nothing to do for non-WOL adapters */ + rhine_power_init(dev); /* Make sure we use pattern 0, 1 and not 4, 5 */ From jgarzik@pobox.com Sat Mar 5 10:44:36 2005 Received: with ECARTIS (v1.0.0; list netdev); Sat, 05 Mar 2005 10:44:41 -0800 (PST) Received: from parcelfarce.linux.theplanet.co.uk (IDENT:93@parcelfarce.linux.theplanet.co.uk [195.92.249.252]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j25IiZTi015997 for ; Sat, 5 Mar 2005 10:44:35 -0800 Received: from [69.134.152.124] (helo=[10.10.10.88]) by parcelfarce.linux.theplanet.co.uk with asmtp (TLSv1:AES256-SHA:256) (Exim 4.33) id 1D7eGN-0007LQ-PZ; Sat, 05 Mar 2005 18:44:32 +0000 Message-ID: <4229FDFC.3010501@pobox.com> Date: Sat, 05 Mar 2005 13:44:12 -0500 From: Jeff Garzik User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.3) Gecko/20040922 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Netdev CC: Linux Kernel Subject: [BK PATCHES] 2.6.x net driver updates Content-Type: multipart/mixed; boundary="------------080400060202040209030506" X-Virus-Scanned: ClamAV 0.83/748/Fri Mar 4 14:19:11 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 2452 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: jgarzik@pobox.com Precedence: bulk X-list: netdev Content-Length: 3549 Lines: 102 This is a multi-part message in MIME format. --------------080400060202040209030506 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Just sent this to Andrew/Linus. The patch was too large (500K) to send to mailing lists. --------------080400060202040209030506 Content-Type: text/plain; name="changelog.txt" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="changelog.txt" Please do a bk pull bk://gkernel.bkbits.net/net-drivers-2.6 This will update the following files: Documentation/networking/e100.txt | 3 arch/arm/mach-pxa/lubbock.c | 2 arch/arm/mach-sa1100/neponset.c | 2 drivers/net/Kconfig | 17 drivers/net/e1000/e1000.h | 3 drivers/net/e1000/e1000_ethtool.c | 11 drivers/net/e1000/e1000_hw.c | 86 drivers/net/e1000/e1000_hw.h | 11 drivers/net/e1000/e1000_main.c | 249 + drivers/net/eepro100.c | 9 drivers/net/ixgb/ixgb.h | 3 drivers/net/ixgb/ixgb_ee.c | 16 drivers/net/ixgb/ixgb_ee.h | 3 drivers/net/ixgb/ixgb_ethtool.c | 5 drivers/net/ixgb/ixgb_hw.c | 2 drivers/net/ixgb/ixgb_hw.h | 2 drivers/net/ixgb/ixgb_ids.h | 2 drivers/net/ixgb/ixgb_main.c | 73 drivers/net/ixgb/ixgb_osdep.h | 2 drivers/net/ixgb/ixgb_param.c | 2 drivers/net/smc91x.c | 275 + drivers/net/smc91x.h | 79 drivers/net/tulip/de2104x.c | 2 drivers/net/typhoon-firmware.h | 5568 +++++++++++++++++--------------------- drivers/net/typhoon.c | 244 + drivers/net/wan/sbni.c | 2 26 files changed, 3304 insertions(+), 3369 deletions(-) through these ChangeSets: : o e1000: Driver version white space, o e1000: Fixes related to Cable length o e1000: Report failure code when loopback o e1000: Checks for desc ring/rx data o e1000: Patch from Peter Kjellstroem -- o e1000: Fix WOL settings in 82544 based o e1000: Delay clean-up of last Tx buffer o e1000: Avoid race between e1000_watchdog o e1000: use netif_poll_{enable|disable} o e1000: Robert Olsson's fix and refinement o ixgb: Driver version, white space, other stuff o ixgb: Invalidate software cache, when EEPROM write occurs o ixgb: Robert Olsson's fix and refinement to poll o ixgb: Avoid race e1000_watchdog and ixgb_clean_tx_irq o ixgb: use netif_poll_{enable|disable} Alexander Viro: o smc91x iomem annotations David Dillow: o Bump version and release date o Version 03.001.008 of the Typhoon firmware, courtesy of 3Com o Fixup the version reporting to match 3Com o Use module_param() and add descriptions o Teach typhoon to use port IO on machines that need it. It will attempt to use MMIO, but if that fails (or the user asks), it will fallback to port IO. o Enable bus mastering before saving our state, or we'll only be able to load the modules one time. Ian Campbell: o smc91x: power down PHY on suspend o use datacs in smc91x driver Nicolas Pitre: o smc91x: allow RX of VLAN packets Randy Dunlap: o tulip/de2104x: don't mix __init & __devinit sections o net/wan/sbni: fix section usage Scott Feldman: o eepro100: remove ID for 82556 o e100: remove reference to NAPI config option Tony Lindgren: o Add OMAP support to smc91x Ethernet driver Xose Vazquez Perez: o 2.6 eepro100: replace and delete duplicate ids --------------080400060202040209030506-- From webmaster@rapidforum.com Sat Mar 5 10:55:01 2005 Received: with ECARTIS (v1.0.0; list netdev); Sat, 05 Mar 2005 10:55:07 -0800 (PST) Received: from rapidforum.com (www.rapidforum.com [80.237.244.2]) by oss.sgi.com (8.13.0/8.13.0) with SMTP id j25Isw5x016980 for ; Sat, 5 Mar 2005 10:54:59 -0800 Received: (qmail 3426 invoked by uid 1004); 5 Mar 2005 18:54:56 -0000 Received: from p3ee04e2f.dip0.t-ipconnect.de (HELO ?62.224.78.47?) (62.224.78.47) by www.rapidforum.com with SMTP; 5 Mar 2005 18:54:56 -0000 Message-ID: <422A0079.4080806@rapidforum.com> Date: Sat, 05 Mar 2005 19:54:49 +0100 From: Christian Schmid User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.8a3) Gecko/20040817 X-Accept-Language: de, en MIME-Version: 1.0 To: "David S. Miller" CC: netdev@oss.sgi.com Subject: Re: Still bug-hunting References: <4229F2EC.8090103@rapidforum.com> <20050305102918.15fd422c.davem@davemloft.net> <4229FC15.3070408@rapidforum.com> <20050305104854.45106335.davem@davemloft.net> In-Reply-To: <20050305104854.45106335.davem@davemloft.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV 0.83/748/Fri Mar 4 14:19:11 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 2453 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: webmaster@rapidforum.com Precedence: bulk X-list: netdev Content-Length: 713 Lines: 19 You as an expert should know that this is no one-liner. It is a very complex server with multiplexing and forking like Apache. I dont feel like writing an apache-like program just for testing. I hope you understand that I prefered investing my time in acutally searching the bug and now its found. Now I hope that you can fix it or at least tell me your ideas. David S. Miller wrote: > On Sat, 05 Mar 2005 19:36:05 +0100 > Christian Schmid wrote: > > >>Sorry? What do you mean? > > > I'm being sarcastic in that you didn't provide the test > case we asked you to provide so we could reproduce the > many-socket slowdown too and help you figure out what > was going wrong. > > From davem@davemloft.net Sat Mar 5 10:58:08 2005 Received: with ECARTIS (v1.0.0; list netdev); Sat, 05 Mar 2005 10:58:12 -0800 (PST) Received: from cheetah.davemloft.net (mail@dsl027-180-174.sfo1.dsl.speakeasy.net [216.27.180.174]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j25Iw7Qd017639 for ; Sat, 5 Mar 2005 10:58:07 -0800 Received: from localhost ([127.0.0.1] helo=cheetah.davemloft.net ident=davem) by cheetah.davemloft.net with smtp (Exim 3.36 #1 (Debian)) id 1D7eSY-0006Zh-00; Sat, 05 Mar 2005 10:57:06 -0800 Date: Sat, 5 Mar 2005 10:57:06 -0800 From: "David S. Miller" To: Christian Schmid Cc: netdev@oss.sgi.com Subject: Re: Still bug-hunting Message-Id: <20050305105706.2c8a6975.davem@davemloft.net> In-Reply-To: <422A0079.4080806@rapidforum.com> References: <4229F2EC.8090103@rapidforum.com> <20050305102918.15fd422c.davem@davemloft.net> <4229FC15.3070408@rapidforum.com> <20050305104854.45106335.davem@davemloft.net> <422A0079.4080806@rapidforum.com> X-Mailer: Sylpheed version 1.0.1 (GTK+ 1.2.10; sparc-unknown-linux-gnu) X-Face: "_;p5u5aPsO,_Vsx"^v-pEq09'CU4&Dc1$fQExov$62l60cgCc%FnIwD=.UF^a>?5'9Kn[;433QFVV9M..2eN.@4ZWPGbdi<=?[:T>y?SD(R*-3It"Vj:)"dP Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV 0.83/748/Fri Mar 4 14:19:11 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 2454 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: davem@davemloft.net Precedence: bulk X-list: netdev Content-Length: 920 Lines: 20 On Sat, 05 Mar 2005 19:54:49 +0100 Christian Schmid wrote: > You as an expert should know that this is no one-liner. It is a very complex server with > multiplexing and forking like Apache. I dont feel like writing an apache-like program just for > testing. I hope you understand that I prefered investing my time in acutally searching the bug and > now its found. Now I hope that you can fix it or at least tell me your ideas. You could give us the program you actually used, no writing necessary. Obviously you had this program, else you wouldn't have anything to report at all. There's nothing "to write", you have it already by implication. Instead, you told us "do something like this, or that" and lots of vague statements and brief incomplete code snippets, then expect us to figure out how the magic beans work and fix your problem. And you want respect and help from us? :-) From asimshankar@gmail.com Sat Mar 5 10:58:30 2005 Received: with ECARTIS (v1.0.0; list netdev); Sat, 05 Mar 2005 10:58:34 -0800 (PST) Received: from wproxy.gmail.com (wproxy.gmail.com [64.233.184.193]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j25IwTQw017770 for ; Sat, 5 Mar 2005 10:58:29 -0800 Received: by wproxy.gmail.com with SMTP id 71so985465wri for ; Sat, 05 Mar 2005 10:58:24 -0800 (PST) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:reply-to:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:references; b=NWpp5HfX4wsziii1IinyDvMTgpBw9kakQckD6xEMq2M7bqJar3reZGd1eLNDb1XO1Mai+4jlsJb+w1AVXR9VYfqUVavo2BCPgM34xIVoXevdD5RfIMDOoagU9d5Uc5DRG53Pk/htn8V4TLDEGR7gWY58bRh7ENCbkI5jY/YE6Ho= Received: by 10.54.79.13 with SMTP id c13mr38143wrb; Sat, 05 Mar 2005 10:58:23 -0800 (PST) Received: by 10.54.24.42 with HTTP; Sat, 5 Mar 2005 10:58:23 -0800 (PST) Message-ID: <7bca1cb505030510586aeb96c1@mail.gmail.com> Date: Sat, 5 Mar 2005 12:58:23 -0600 From: Asim Shankar Reply-To: Asim Shankar To: Pedro Fortuna Subject: Re: filtering packtes before OS takes care about them Cc: netdev@oss.sgi.com In-Reply-To: Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit References: <09766A6E64A068419B362367800D50C0B58A17@moritz.faps.uni-erlangen.de> <7bca1cb50502281209798e8a00@mail.gmail.com> X-Virus-Scanned: ClamAV 0.83/748/Fri Mar 4 14:19:11 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 2455 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: asimshankar@gmail.com Precedence: bulk X-list: netdev Content-Length: 268 Lines: 11 > I wasnt able to compile your packet_type_test.c : > all I got was a huge list of errors > and warnings, and no .o compiled in the end. Can you send the specific errors you got? And is the kernel sources present in /lib/modules/`uname -r`/build? Regards, -- Asim From webmaster@rapidforum.com Sat Mar 5 11:07:08 2005 Received: with ECARTIS (v1.0.0; list netdev); Sat, 05 Mar 2005 11:07:12 -0800 (PST) Received: from rapidforum.com (www.rapidforum.com [80.237.244.2]) by oss.sgi.com (8.13.0/8.13.0) with SMTP id j25J77kT018879 for ; Sat, 5 Mar 2005 11:07:07 -0800 Received: (qmail 4096 invoked by uid 1004); 5 Mar 2005 19:07:06 -0000 Received: from p3ee04e2f.dip0.t-ipconnect.de (HELO ?62.224.78.47?) (62.224.78.47) by www.rapidforum.com with SMTP; 5 Mar 2005 19:07:06 -0000 Message-ID: <422A0354.3080800@rapidforum.com> Date: Sat, 05 Mar 2005 20:07:00 +0100 From: Christian Schmid User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.8a3) Gecko/20040817 X-Accept-Language: de, en MIME-Version: 1.0 To: "David S. Miller" CC: netdev@oss.sgi.com Subject: Re: Still bug-hunting References: <4229F2EC.8090103@rapidforum.com> <20050305102918.15fd422c.davem@davemloft.net> <4229FC15.3070408@rapidforum.com> <20050305104854.45106335.davem@davemloft.net> <422A0079.4080806@rapidforum.com> <20050305105706.2c8a6975.davem@davemloft.net> In-Reply-To: <20050305105706.2c8a6975.davem@davemloft.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV 0.83/748/Fri Mar 4 14:19:11 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 2456 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: webmaster@rapidforum.com Precedence: bulk X-list: netdev Content-Length: 1357 Lines: 30 Actually we are a company and the big ones decided to buy new servers to work-around this bug. This is a common technique in companies. I say this sucks and thats why I experienced in our production system in order to give linux something back by reporting and helping to fix a bug which only appears on big systems. I do not understand why you start flaming at me. David S. Miller wrote: > On Sat, 05 Mar 2005 19:54:49 +0100 > Christian Schmid wrote: > > >>You as an expert should know that this is no one-liner. It is a very complex server with >>multiplexing and forking like Apache. I dont feel like writing an apache-like program just for >>testing. I hope you understand that I prefered investing my time in acutally searching the bug and >>now its found. Now I hope that you can fix it or at least tell me your ideas. > > > You could give us the program you actually used, no writing > necessary. Obviously you had this program, else you wouldn't > have anything to report at all. > > There's nothing "to write", you have it already by implication. > > Instead, you told us "do something like this, or that" and lots > of vague statements and brief incomplete code snippets, then > expect us to figure out how the magic beans work and fix your > problem. > > And you want respect and help from us? :-) > > From pedro.fortuna@gmail.com Sat Mar 5 11:36:39 2005 Received: with ECARTIS (v1.0.0; list netdev); Sat, 05 Mar 2005 11:36:43 -0800 (PST) Received: from rproxy.gmail.com (rproxy.gmail.com [64.233.170.203]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j25JacBp021526 for ; Sat, 5 Mar 2005 11:36:39 -0800 Received: by rproxy.gmail.com with SMTP id c51so800272rne for ; Sat, 05 Mar 2005 11:36:38 -0800 (PST) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:reply-to:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:references; b=YbPo+cEP8bRf6AlwfULk8sj3PPPk39H4cAfcmpsyuNx0vEEsvcIWeduKmcWD/fOf8DBCw8tudfwQ3tFtw2veTV8LJ2egRGHaKRa4mIpvs2d/yQNvpbSMuQYFXrrhIm93MfzxJgebZB15YRUlktwq9HgRvL+YvsShR/trog2S5ys= Received: by 10.11.116.41 with SMTP id o41mr268532cwc; Sat, 05 Mar 2005 11:36:38 -0800 (PST) Received: by 10.11.99.66 with HTTP; Sat, 5 Mar 2005 11:36:38 -0800 (PST) Message-ID: Date: Sat, 5 Mar 2005 19:36:38 +0000 From: Pedro Fortuna Reply-To: Pedro Fortuna To: Asim Shankar Subject: Re: filtering packtes before OS takes care about them Cc: netdev@oss.sgi.com In-Reply-To: <7bca1cb505030510586aeb96c1@mail.gmail.com> Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit References: <09766A6E64A068419B362367800D50C0B58A17@moritz.faps.uni-erlangen.de> <7bca1cb50502281209798e8a00@mail.gmail.com> <7bca1cb505030510586aeb96c1@mail.gmail.com> X-Virus-Scanned: ClamAV 0.83/748/Fri Mar 4 14:19:11 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 2457 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: pedro.fortuna@gmail.com Precedence: bulk X-list: netdev Content-Length: 881 Lines: 29 Hello Asim, I tried again but this time in Fedora Core 3 (kernel 2.6.10-1.760_FC3) and it went flawlessly. I have a look into your example and also into the Phrack article you mentioned and now I'm ready to begin some tests towards what I want to implement. It's absolutly clear you can fetch (and modify) packets before they are delivered to the TCP/IP stack with a custom packet_type function, but is it also possible to intercept just before they are passed to the network driver? Thanks, -Pedro Fortuna On Sat, 5 Mar 2005 12:58:23 -0600, Asim Shankar wrote: > > I wasnt able to compile your packet_type_test.c : > > all I got was a huge list of errors > > and warnings, and no .o compiled in the end. > > Can you send the specific errors you got? > And is the kernel sources present in > /lib/modules/`uname -r`/build? > > Regards, > > -- Asim > From greearb@candelatech.com Sat Mar 5 11:44:39 2005 Received: with ECARTIS (v1.0.0; list netdev); Sat, 05 Mar 2005 11:44:45 -0800 (PST) Received: from www.lanforge.com (ns1.lanforge.com [66.165.47.210]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j25Jid2i022191 for ; Sat, 5 Mar 2005 11:44:39 -0800 Received: from [4.33.45.22] (evrtwa1-ar2-4-33-045-022.evrtwa1.dsl-verizon.net [4.33.45.22]) (authenticated bits=0) by www.lanforge.com (8.12.8/8.12.8) with ESMTP id j25K7JLH023158; Sat, 5 Mar 2005 12:07:20 -0800 Message-ID: <422A0C21.3050709@candelatech.com> Date: Sat, 05 Mar 2005 11:44:33 -0800 From: Ben Greear Organization: Candela Technologies User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.7.3) Gecko/20041020 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Patrick McHardy CC: Lennert Buytenhek , shemminger@osdl.org, netdev@oss.sgi.com, leo@yuriev.ru Subject: Re: [leo@yuriev.ru: [PATCH] ethernet-bridge: update skb->priority in case forwarded frame has VLAN-header] References: <20050305141225.GA5180@xi.wantstofly.org> <4229D98F.9010008@trash.net> In-Reply-To: <4229D98F.9010008@trash.net> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV 0.83/748/Fri Mar 4 14:19:11 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 2458 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: greearb@candelatech.com Precedence: bulk X-list: netdev Content-Length: 1413 Lines: 47 Patrick McHardy wrote: > Lennert Buytenhek wrote: > >> ----- Forwarded message from Leo Yuriev ----- >> >> From: Leo Yuriev >> To: Lennert Buytenhek , >> Alexey Kuznetsov >> Cc: linux-kernel@vger.kernel.org >> Subject: [PATCH] ethernet-bridge: update skb->priority in case >> forwarded frame has VLAN-header >> >> Kernel 2.6 (2.6.11) >> >> When ethernet-bridge forward a packet and such ethernet-frame has >> VLAN-tag, bridge should update skb->prioriry for properly QoS >> handling. >> >> This small patch does this. Currently vlan_TCI-priority directly >> mapped to skb->priority, but this looks enough. >> >> Patch-by: Leo Yuriev > > > It needs to verify the tag is present and accessible using > pskb_may_pull(). But I think an ebtables target similar to the iptables > CLASSIFY target is a better place for this. It could allow setting > skb->priority to an arbitary value or derive it from vlan priority or IP > tos. The VLAN code has it's own (user-configurable) mapping from skb->priority to .1q priority, and .1q priority to skb->priority. You might want to clone or somehow use the .1q mapping logic to allow something other than just a straight .1q -> skb->priority mapping. Ben > > Regards > Patrick > -- Ben Greear Candela Technologies Inc http://www.candelatech.com From tgraf@suug.ch Sat Mar 5 11:56:53 2005 Received: with ECARTIS (v1.0.0; list netdev); Sat, 05 Mar 2005 11:56:58 -0800 (PST) Received: from b.mx.projectdream.org (eth0-0.arisu.projectdream.org [194.158.4.191]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j25Juqor022965 for ; Sat, 5 Mar 2005 11:56:52 -0800 Received: from postel.suug.ch (postel.suug.ch [195.134.158.23]) (using TLSv1 with cipher EDH-RSA-DES-CBC3-SHA (168/168 bits)) (No client certificate requested) by b.mx.projectdream.org (Postfix) with ESMTP id 6206987; Sat, 5 Mar 2005 20:56:29 +0100 (CET) Received: by postel.suug.ch (Postfix, from userid 10001) id 3DD3E1C0EA; Sat, 5 Mar 2005 20:57:12 +0100 (CET) Date: Sat, 5 Mar 2005 20:57:12 +0100 From: Thomas Graf To: Christian Schmid Cc: "David S. Miller" , netdev@oss.sgi.com Subject: Re: Still bug-hunting Message-ID: <20050305195712.GO31837@postel.suug.ch> References: <4229F2EC.8090103@rapidforum.com> <20050305102918.15fd422c.davem@davemloft.net> <4229FC15.3070408@rapidforum.com> <20050305104854.45106335.davem@davemloft.net> <422A0079.4080806@rapidforum.com> <20050305105706.2c8a6975.davem@davemloft.net> <422A0354.3080800@rapidforum.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <422A0354.3080800@rapidforum.com> X-Virus-Scanned: ClamAV 0.83/748/Fri Mar 4 14:19:11 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 2459 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: tgraf@suug.ch Precedence: bulk X-list: netdev Content-Length: 919 Lines: 14 * Christian Schmid <422A0354.3080800@rapidforum.com> 2005-03-05 20:07 > Actually we are a company and the big ones decided to buy new servers to > work-around this bug. This is a common technique in companies. I say this > sucks and thats why I experienced in our production system in order to give > linux something back by reporting and helping to fix a bug which only > appears on big systems. I do not understand why you start flaming at me. It's quite simple, provide a test case and someone will start looking into the problem (given there is one). The information you provided so far is quite vague, it would be pure luck to spot the bug. You have do understand that looking into such a bug may cost dozens of hours or days if it can't be reproduced by the person. Nobody does this without at least very strong evidences that the bug actually exists and your appereance so far didn't help too much I guess. From webmaster@rapidforum.com Sat Mar 5 12:04:20 2005 Received: with ECARTIS (v1.0.0; list netdev); Sat, 05 Mar 2005 12:04:24 -0800 (PST) Received: from rapidforum.com (www.rapidforum.com [80.237.244.2]) by oss.sgi.com (8.13.0/8.13.0) with SMTP id j25K4JbZ023751 for ; Sat, 5 Mar 2005 12:04:19 -0800 Received: (qmail 7040 invoked by uid 1004); 5 Mar 2005 20:04:19 -0000 Received: from p3ee04e2f.dip0.t-ipconnect.de (HELO ?62.224.78.47?) (62.224.78.47) by www.rapidforum.com with SMTP; 5 Mar 2005 20:04:19 -0000 Message-ID: <422A10BC.2060706@rapidforum.com> Date: Sat, 05 Mar 2005 21:04:12 +0100 From: Christian Schmid User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.8a3) Gecko/20040817 X-Accept-Language: de, en MIME-Version: 1.0 To: Thomas Graf CC: "David S. Miller" , netdev@oss.sgi.com Subject: Re: Still bug-hunting References: <4229F2EC.8090103@rapidforum.com> <20050305102918.15fd422c.davem@davemloft.net> <4229FC15.3070408@rapidforum.com> <20050305104854.45106335.davem@davemloft.net> <422A0079.4080806@rapidforum.com> <20050305105706.2c8a6975.davem@davemloft.net> <422A0354.3080800@rapidforum.com> <20050305195712.GO31837@postel.suug.ch> In-Reply-To: <20050305195712.GO31837@postel.suug.ch> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV 0.83/748/Fri Mar 4 14:19:11 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 2460 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: webmaster@rapidforum.com Precedence: bulk X-list: netdev Content-Length: 1124 Lines: 20 Thomas Graf wrote: > * Christian Schmid <422A0354.3080800@rapidforum.com> 2005-03-05 20:07 > >>Actually we are a company and the big ones decided to buy new servers to >>work-around this bug. This is a common technique in companies. I say this >>sucks and thats why I experienced in our production system in order to give >>linux something back by reporting and helping to fix a bug which only >>appears on big systems. I do not understand why you start flaming at me. > > > It's quite simple, provide a test case and someone will start looking > into the problem (given there is one). The information you provided so far > is quite vague, it would be pure luck to spot the bug. You have do > understand that looking into such a bug may cost dozens of hours or days if > it can't be reproduced by the person. Nobody does this without at least very > strong evidences that the bug actually exists and your appereance so > far didn't help too much I guess. I just asked for a way how to change the dynamic memory-allocation for buffers to a static one. I dont think that this is much work and is a quite direct task. From romieu@fr.zoreil.com Sat Mar 5 12:36:36 2005 Received: with ECARTIS (v1.0.0; list netdev); Sat, 05 Mar 2005 12:36:41 -0800 (PST) Received: from fr.zoreil.com (electric-eye.fr.zoreil.com [213.41.134.224]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j25KaYJ9028569 for ; Sat, 5 Mar 2005 12:36:35 -0800 Received: from electric-eye.fr.zoreil.com (localhost.localdomain [127.0.0.1]) by fr.zoreil.com (8.13.1/8.12.1) with ESMTP id j25KWNZ3025323; Sat, 5 Mar 2005 21:32:23 +0100 Received: (from romieu@localhost) by electric-eye.fr.zoreil.com (8.13.1/8.13.1/Submit) id j25KWHAM025322; Sat, 5 Mar 2005 21:32:17 +0100 Date: Sat, 5 Mar 2005 21:32:17 +0100 From: Francois Romieu To: Christian Schmid Cc: Thomas Graf , "David S. Miller" , netdev@oss.sgi.com Subject: Re: Still bug-hunting Message-ID: <20050305203216.GA25116@electric-eye.fr.zoreil.com> References: <4229F2EC.8090103@rapidforum.com> <20050305102918.15fd422c.davem@davemloft.net> <4229FC15.3070408@rapidforum.com> <20050305104854.45106335.davem@davemloft.net> <422A0079.4080806@rapidforum.com> <20050305105706.2c8a6975.davem@davemloft.net> <422A0354.3080800@rapidforum.com> <20050305195712.GO31837@postel.suug.ch> <422A10BC.2060706@rapidforum.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <422A10BC.2060706@rapidforum.com> User-Agent: Mutt/1.4.1i X-Organisation: Land of Sunshine Inc. X-Virus-Scanned: ClamAV 0.83/748/Fri Mar 4 14:19:11 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 2461 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: romieu@fr.zoreil.com Precedence: bulk X-list: netdev Content-Length: 278 Lines: 10 Christian Schmid : [...] > I just asked for a way how to change the dynamic memory-allocation for > buffers to a static one. I dont think that this is much work and is a quite > direct task. Simple answer: rewrite alloc_skb and friends. -- Ueimor From webmaster@rapidforum.com Sat Mar 5 12:40:33 2005 Received: with ECARTIS (v1.0.0; list netdev); Sat, 05 Mar 2005 12:40:36 -0800 (PST) Received: from rapidforum.com (www.rapidforum.com [80.237.244.2]) by oss.sgi.com (8.13.0/8.13.0) with SMTP id j25KeVDk029173 for ; Sat, 5 Mar 2005 12:40:32 -0800 Received: (qmail 8869 invoked by uid 1004); 5 Mar 2005 20:40:31 -0000 Received: from p3ee04e2f.dip0.t-ipconnect.de (HELO ?62.224.78.47?) (62.224.78.47) by www.rapidforum.com with SMTP; 5 Mar 2005 20:40:31 -0000 Message-ID: <422A1939.9000200@rapidforum.com> Date: Sat, 05 Mar 2005 21:40:25 +0100 From: Christian Schmid User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.8a3) Gecko/20040817 X-Accept-Language: de, en MIME-Version: 1.0 To: Francois Romieu CC: Thomas Graf , "David S. Miller" , netdev@oss.sgi.com Subject: Re: Still bug-hunting References: <4229F2EC.8090103@rapidforum.com> <20050305102918.15fd422c.davem@davemloft.net> <4229FC15.3070408@rapidforum.com> <20050305104854.45106335.davem@davemloft.net> <422A0079.4080806@rapidforum.com> <20050305105706.2c8a6975.davem@davemloft.net> <422A0354.3080800@rapidforum.com> <20050305195712.GO31837@postel.suug.ch> <422A10BC.2060706@rapidforum.com> <20050305203216.GA25116@electric-eye.fr.zoreil.com> In-Reply-To: <20050305203216.GA25116@electric-eye.fr.zoreil.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV 0.83/748/Fri Mar 4 14:19:11 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 2462 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: webmaster@rapidforum.com Precedence: bulk X-list: netdev Content-Length: 497 Lines: 20 In less-rude words: "No, this is not easy. No way, sorry." Thank you for this information. I have sent very detailed bug-reports to LKML. Maybe you have read already. Francois Romieu wrote: > Christian Schmid : > [...] > >>I just asked for a way how to change the dynamic memory-allocation for >>buffers to a static one. I dont think that this is much work and is a quite >>direct task. > > > Simple answer: rewrite alloc_skb and friends. > > -- > Ueimor > > From romieu@fr.zoreil.com Sat Mar 5 12:44:29 2005 Received: with ECARTIS (v1.0.0; list netdev); Sat, 05 Mar 2005 12:44:34 -0800 (PST) Received: from fr.zoreil.com (electric-eye.fr.zoreil.com [213.41.134.224]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j25KiRaL029774 for ; Sat, 5 Mar 2005 12:44:28 -0800 Received: from electric-eye.fr.zoreil.com (localhost.localdomain [127.0.0.1]) by fr.zoreil.com (8.13.1/8.12.1) with ESMTP id j25KhuqZ025583; Sat, 5 Mar 2005 21:43:57 +0100 Received: (from romieu@localhost) by electric-eye.fr.zoreil.com (8.13.1/8.13.1/Submit) id j25KhplM025582; Sat, 5 Mar 2005 21:43:51 +0100 Date: Sat, 5 Mar 2005 21:43:51 +0100 From: Francois Romieu To: Richard Dawe Cc: Linux netdev Subject: Re: [PATCH]: r8169: prototype parameter name consistency Message-ID: <20050305204351.GB25116@electric-eye.fr.zoreil.com> References: <4229C785.806@phekda.gotadsl.co.uk> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4229C785.806@phekda.gotadsl.co.uk> User-Agent: Mutt/1.4.1i X-Organisation: Land of Sunshine Inc. X-Virus-Scanned: ClamAV 0.83/748/Fri Mar 4 14:19:11 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 2463 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: romieu@fr.zoreil.com Precedence: bulk X-list: netdev Content-Length: 190 Lines: 9 Richard Dawe : [...] > Attached is a minor clean-up for consistency in the parameter names for > a couple of prototypes in the r8169 driver. Queued. -- Ueimor From yoshfuji@linux-ipv6.org Sat Mar 5 12:47:01 2005 Received: with ECARTIS (v1.0.0; list netdev); Sat, 05 Mar 2005 12:47:06 -0800 (PST) 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 j25Kl0rW030318 for ; Sat, 5 Mar 2005 12:47:01 -0800 Received: from localhost (localhost [127.0.0.1]) by yue.st-paulia.net (Postfix) with ESMTP id 09D0833CC2; Sun, 6 Mar 2005 05:48:32 +0900 (JST) Date: Sun, 06 Mar 2005 05:48:31 +0900 (JST) Message-Id: <20050306.054831.84878104.yoshfuji@linux-ipv6.org> To: kaber@trash.net, davem@davemloft.net Cc: netdev@oss.sgi.com Subject: Re: [PATCH 1/3 XFRM]: Fix ICMP tempsel From: YOSHIFUJI Hideaki / =?iso-2022-jp?B?GyRCNUhGIzFRTEAbKEI=?= In-Reply-To: <4229BB22.50107@trash.net> References: <4229BB22.50107@trash.net> Organization: USAGI Project X-URL: http://www.yoshifuji.org/%7Ehideaki/ X-Fingerprint: 9022 65EB 1ECF 3AD1 0BDF 80D8 4807 F894 E062 0EEA X-PGP-Key-URL: http://www.yoshifuji.org/%7Ehideaki/hideaki@yoshifuji.org.asc X-Face: "5$Al-.M>NJ%a'@hhZdQm:."qn~PA^gq4o*>iCFToq*bAi#4FRtx}enhuQKz7fNqQz\BYU] $~O_5m-9'}MIs`XGwIEscw;e5b>n"B_?j/AkL~i/MEaZBLP X-Mailer: Mew version 2.2 on Emacs 20.7 / Mule 4.1 (AOI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV 0.83/748/Fri Mar 4 14:19:11 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 2464 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: yoshfuji@linux-ipv6.org Precedence: bulk X-list: netdev Content-Length: 341 Lines: 9 In article <4229BB22.50107@trash.net> (at Sat, 05 Mar 2005 14:58:58 +0100), Patrick McHardy says: > there was a lot of discussion going on last time I posted these > patches, these are the patches everyone agreed on. They are based > on your 2.6.12 tree. Acked-by: Hideaki YOSHIFUJI --yoshfuji From webvenza@libero.it Sat Mar 5 12:54:41 2005 Received: with ECARTIS (v1.0.0; list netdev); Sat, 05 Mar 2005 12:54:46 -0800 (PST) Received: from gateway.milesteg.arr (foobar@adsl-ull-59-137.44-151.net24.it [151.44.137.59]) by oss.sgi.com (8.13.0/8.13.0) with SMTP id j25Ksd11031041 for ; Sat, 5 Mar 2005 12:54:40 -0800 Received: (qmail 32075 invoked from network); 5 Mar 2005 20:54:38 -0000 Received: from unknown (HELO ?192.168.0.205?) (192.168.0.205) by gateway.milesteg.arr with SMTP; 5 Mar 2005 20:54:38 -0000 In-Reply-To: <4229FA32.4000401@pobox.com> References: <20050305134011.23638.68926@localhost.localdomain> <4229FA32.4000401@pobox.com> Mime-Version: 1.0 (Apple Message framework v619.2) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <02a49476862ae18433e5b80aafa616fd@libero.it> Content-Transfer-Encoding: 7bit Cc: netdev@oss.sgi.com From: Daniele Venzano Subject: Re: [PATCH 1/1] More ethtool support for sis900 Date: Sat, 5 Mar 2005 21:53:37 +0100 To: Jeff Garzik X-Mailer: Apple Mail (2.619.2) X-Virus-Scanned: ClamAV 0.83/748/Fri Mar 4 14:19:11 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 2465 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: webvenza@libero.it Precedence: bulk X-list: netdev Content-Length: 834 Lines: 27 On 05/mar/05, at 19:28, Jeff Garzik wrote: >> +static int sis900_set_settings(struct net_device *net_dev, >> + struct ethtool_cmd *cmd) >> +{ >> + struct sis900_private *sis_priv = net_dev->priv; >> + return mii_ethtool_sset(&sis_priv->mii_info, cmd); >> +} >> + >> +static int sis900_nway_reset(struct net_device *net_dev) >> +{ >> + struct sis900_private *sis_priv = net_dev->priv; >> + return mii_nway_restart(&sis_priv->mii_info); >> +} > > I should think you want locking for these, as is present in other > drivers... I saw the locking, but I couldn't come up with a reason for it. Is it needed because of kernel wide preemption ? I don't like copying blindly and the documentation for the mii interface is a bit lacking... Will follow up with a new patch in a few minutes... -- Daniele Venzano http://www.brownhat.org From webvenza@libero.it Sat Mar 5 13:05:01 2005 Received: with ECARTIS (v1.0.0; list netdev); Sat, 05 Mar 2005 13:05:07 -0800 (PST) Received: from localhost.localdomain (foobar@adsl-ull-59-137.44-151.net24.it [151.44.137.59]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j25L4x45031907 for ; Sat, 5 Mar 2005 13:05:00 -0800 Received: from localhost.localdomain (localhost.localdomain [127.0.0.1]) by localhost.localdomain (Postfix) with ESMTP id A622F24641; Sat, 5 Mar 2005 22:07:45 +0100 (CET) MIME-Version: 1.0 Content-Type: multipart/mixed; charset="us-ascii"; boundary="===============1998021209==" Content-Transfer-Encoding: 7bit User-Agent: Python patchbomber v. 0.0.0.0.0.1 Message-ID: <20050305210745.6763.6618@localhost.localdomain> Subject: [PATCH 1/1] More ethtool support for sis900 (with locking) From: Daniele Venzano To: netdev@oss.sgi.com, jgarzik@pobox.com Date: Sat, 5 Mar 2005 22:07:45 +0100 (CET) X-Virus-Scanned: ClamAV 0.83/748/Fri Mar 4 14:19:11 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 2466 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: webvenza@libero.it Precedence: bulk X-list: netdev Content-Length: 3839 Lines: 130 This is a MIME message, see the first attachment for the text and the second for the patch --===============1998021209== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Add support for using generic mii interface Add support for the following ethtool ops: - get_link - get_settings - set_settings - nway_reset Signed-off-by: Daniele Venzano --===============1998021209== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Index: sis900.c =================================================================== --- a/drivers/net/sis900.c (revision 95) +++ b/drivers/net/sis900.c (revision 98) @@ -161,6 +161,7 @@ struct mii_phy * mii; struct mii_phy * first_mii; /* record the first mii structure */ unsigned int cur_phy; + struct mii_if_info mii_info; struct timer_list timer; /* Link status detection timer. */ u8 autong_complete; /* 1: auto-negotiate complete */ @@ -199,7 +200,7 @@ static int sis900_mii_probe (struct net_device * net_dev); static void sis900_init_rxfilter (struct net_device * net_dev); static u16 read_eeprom(long ioaddr, int location); -static u16 mdio_read(struct net_device *net_dev, int phy_id, int location); +static int mdio_read(struct net_device *net_dev, int phy_id, int location); static void mdio_write(struct net_device *net_dev, int phy_id, int location, int val); static void sis900_timer(unsigned long data); static void sis900_check_mode (struct net_device *net_dev, struct mii_phy *mii_phy); @@ -468,7 +469,13 @@ sis_priv->msg_enable = sis900_debug; else sis_priv->msg_enable = SIS900_DEF_MSG; - + + sis_priv->mii_info.dev = net_dev; + sis_priv->mii_info.mdio_read = mdio_read; + sis_priv->mii_info.mdio_write = mdio_write; + sis_priv->mii_info.phy_id_mask = 0x1f; + sis_priv->mii_info.reg_num_mask = 0x1f; + ret = register_netdev(net_dev); if (ret) goto err_unmap_rx; @@ -507,6 +514,8 @@ goto err_out_unregister; } + sis_priv->mii_info.phy_id = sis_priv->cur_phy; + /* save our host bridge revision */ dev = pci_get_device(PCI_VENDOR_ID_SI, PCI_DEVICE_ID_SI_630, NULL); if (dev) { @@ -843,7 +852,7 @@ * Please see SiS7014 or ICS spec */ -static u16 mdio_read(struct net_device *net_dev, int phy_id, int location) +static int mdio_read(struct net_device *net_dev, int phy_id, int location) { long mdio_addr = net_dev->base_addr + mear; int mii_cmd = MIIread|(phy_id<msg_enable = value; } +static u32 sis900_get_link(struct net_device *net_dev) +{ + struct sis900_private *sis_priv = net_dev->priv; + return mii_link_ok(&sis_priv->mii_info); +} + +static int sis900_get_settings(struct net_device *net_dev, + struct ethtool_cmd *cmd) +{ + struct sis900_private *sis_priv = net_dev->priv; + spin_lock_irq(&sis_priv->lock); + mii_ethtool_gset(&sis_priv->mii_info, cmd); + spin_unlock_irq(&sis_priv->lock); + return 0; +} + +static int sis900_set_settings(struct net_device *net_dev, + struct ethtool_cmd *cmd) +{ + struct sis900_private *sis_priv = net_dev->priv; + int rt; + spin_lock_irq(&sis_priv->lock); + rt = mii_ethtool_sset(&sis_priv->mii_info, cmd); + spin_unlock_irq(&sis_priv->lock); + return rt; +} + +static int sis900_nway_reset(struct net_device *net_dev) +{ + struct sis900_private *sis_priv = net_dev->priv; + return mii_nway_restart(&sis_priv->mii_info); +} + static struct ethtool_ops sis900_ethtool_ops = { .get_drvinfo = sis900_get_drvinfo, .get_msglevel = sis900_get_msglevel, .set_msglevel = sis900_set_msglevel, + .get_link = sis900_get_link, + .get_settings = sis900_get_settings, + .set_settings = sis900_set_settings, + .nway_reset = sis900_nway_reset, }; /** --===============1998021209==-- From romieu@fr.zoreil.com Sat Mar 5 13:24:35 2005 Received: with ECARTIS (v1.0.0; list netdev); Sat, 05 Mar 2005 13:24:41 -0800 (PST) Received: from fr.zoreil.com (electric-eye.fr.zoreil.com [213.41.134.224]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j25LOXUb000408 for ; Sat, 5 Mar 2005 13:24:34 -0800 Received: from electric-eye.fr.zoreil.com (localhost.localdomain [127.0.0.1]) by fr.zoreil.com (8.13.1/8.12.1) with ESMTP id j25LMBWZ026384; Sat, 5 Mar 2005 22:22:11 +0100 Received: (from romieu@localhost) by electric-eye.fr.zoreil.com (8.13.1/8.13.1/Submit) id j25LM5S0026383; Sat, 5 Mar 2005 22:22:05 +0100 Date: Sat, 5 Mar 2005 22:22:05 +0100 From: Francois Romieu To: Christian Schmid Cc: Thomas Graf , "David S. Miller" , netdev@oss.sgi.com Subject: Re: Still bug-hunting Message-ID: <20050305212205.GC25116@electric-eye.fr.zoreil.com> References: <20050305102918.15fd422c.davem@davemloft.net> <4229FC15.3070408@rapidforum.com> <20050305104854.45106335.davem@davemloft.net> <422A0079.4080806@rapidforum.com> <20050305105706.2c8a6975.davem@davemloft.net> <422A0354.3080800@rapidforum.com> <20050305195712.GO31837@postel.suug.ch> <422A10BC.2060706@rapidforum.com> <20050305203216.GA25116@electric-eye.fr.zoreil.com> <422A1939.9000200@rapidforum.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <422A1939.9000200@rapidforum.com> User-Agent: Mutt/1.4.1i X-Organisation: Land of Sunshine Inc. X-Virus-Scanned: ClamAV 0.83/748/Fri Mar 4 14:19:11 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 2467 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: romieu@fr.zoreil.com Precedence: bulk X-list: netdev Content-Length: 507 Lines: 16 Christian Schmid : > In less-rude words: "No, this is not easy. No way, sorry." If you can not distinguish a factual answer from a flame, it is time to take a break. [...] > Thank you for this information. I have sent very detailed bug-reports to > LKML. Maybe you have read already. Just done so but I fail to see if you provided N. Piggin with the data he requested. Anyway, I can return to more basic issues since he and the others will do a better job than me. -- Ueimor From romieu@fr.zoreil.com Sat Mar 5 13:32:29 2005 Received: with ECARTIS (v1.0.0; list netdev); Sat, 05 Mar 2005 13:32:33 -0800 (PST) Received: from fr.zoreil.com (electric-eye.fr.zoreil.com [213.41.134.224]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j25LWRT2001096 for ; Sat, 5 Mar 2005 13:32:28 -0800 Received: from electric-eye.fr.zoreil.com (localhost.localdomain [127.0.0.1]) by fr.zoreil.com (8.13.1/8.12.1) with ESMTP id j25LShNB026523; Sat, 5 Mar 2005 22:28:43 +0100 Received: (from romieu@localhost) by electric-eye.fr.zoreil.com (8.13.1/8.13.1/Submit) id j25LScBS026522; Sat, 5 Mar 2005 22:28:38 +0100 Date: Sat, 5 Mar 2005 22:28:38 +0100 From: Francois Romieu To: Daniele Venzano Cc: netdev@oss.sgi.com, jgarzik@pobox.com Subject: Re: [PATCH 1/1] More ethtool support for sis900 (with locking) Message-ID: <20050305212838.GD25116@electric-eye.fr.zoreil.com> References: <20050305210745.6763.6618@localhost.localdomain> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20050305210745.6763.6618@localhost.localdomain> User-Agent: Mutt/1.4.1i X-Organisation: Land of Sunshine Inc. X-Virus-Scanned: ClamAV 0.83/748/Fri Mar 4 14:19:11 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 2468 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: romieu@fr.zoreil.com Precedence: bulk X-list: netdev Content-Length: 550 Lines: 22 Daniele Venzano : [...] > Index: sis900.c > =================================================================== > --- a/drivers/net/sis900.c (revision 95) > +++ b/drivers/net/sis900.c (revision 98) [...] > @@ -1943,10 +1952,47 @@ > sis_priv->msg_enable = value; > } > > +static u32 sis900_get_link(struct net_device *net_dev) > +{ > + struct sis900_private *sis_priv = net_dev->priv; Any reason to not use netdev_priv() ? I would not mind an empty line between the declaration of variables and the actual code. -- Ueimor From ahu@outpost.ds9a.nl Sat Mar 5 14:04:39 2005 Received: with ECARTIS (v1.0.0; list netdev); Sat, 05 Mar 2005 14:04:45 -0800 (PST) Received: from outpost.ds9a.nl (postfix@outpost.ds9a.nl [213.244.168.210]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j25M4ckA002431 for ; Sat, 5 Mar 2005 14:04:39 -0800 Received: by outpost.ds9a.nl (Postfix, from userid 1000) id 2AFA83F66; Sat, 5 Mar 2005 23:04:30 +0100 (CET) Date: Sat, 5 Mar 2005 23:04:30 +0100 From: bert hubert To: netdev@oss.sgi.com Subject: bridge between ppp and ethernet - 1 IP address and assign it to another host Message-ID: <20050305220429.GA9335@outpost.ds9a.nl> Mail-Followup-To: bert hubert , netdev@oss.sgi.com Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.3.28i X-Virus-Scanned: ClamAV 0.83/748/Fri Mar 4 14:19:11 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 2469 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: ahu@ds9a.nl Precedence: bulk X-list: netdev Content-Length: 1023 Lines: 28 Hi people, I have an application that wants a Real IP Address, but for a variety of good reasons, I can't connect the machine to the internet directly. So, I need this: DSL - Linux - Windows PC Where I need the Windows PC to think it has the real single IP addres assigned to me by the DSL provider. I run PPTP on the Linux box, which should not touch traffic for that IP address. Now I know that several DSL routers are capable of this stunt, so we should be able to do this too. But how? Linux is pretty stubborn in routing packets for its own IP address elsewhere (rightfully so). I previously spent some time on this with a lot of SNAT/DNAT trickery but it is not very pleasing, nor did it work. What we're trying to do is a lot like building a bridge between ethernet and ppp, but not quite. Anybody have ideas? If we find something I'll post it on http://lartc.org. -- http://www.PowerDNS.com Open source, database driven DNS Software http://netherlabs.nl Open and Closed source services From kaber@trash.net Sat Mar 5 16:09:39 2005 Received: with ECARTIS (v1.0.0; list netdev); Sat, 05 Mar 2005 16:09:45 -0800 (PST) Received: from kaber.coreworks.de ([62.206.217.67]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j2609d9J006099 for ; Sat, 5 Mar 2005 16:09:39 -0800 Received: from localhost ([127.0.0.1]) by kaber.coreworks.de with esmtp (Exim 4.50) id 1D7jKq-0000tH-E1; Sun, 06 Mar 2005 01:09:28 +0100 Message-ID: <422A4A38.4040303@trash.net> Date: Sun, 06 Mar 2005 01:09:28 +0100 From: Patrick McHardy User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.7.5) Gecko/20050106 Debian/1.7.5-1 X-Accept-Language: en MIME-Version: 1.0 To: Matt Mackall CC: Jeff Garzik , netdev@oss.sgi.com, Jeff Moyer Subject: Re: [PATCH 1/7] netpoll: shorten carrier detect timeout References: <2.454130102@selenic.com> In-Reply-To: <2.454130102@selenic.com> Content-Type: multipart/mixed; boundary="------------020409060805070303080608" X-Virus-Scanned: ClamAV 0.83/748/Fri Mar 4 14:19:11 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 2470 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: kaber@trash.net Precedence: bulk X-list: netdev Content-Length: 1578 Lines: 54 This is a multi-part message in MIME format. --------------020409060805070303080608 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Matt Mackall wrote: > Shorten carrier detect timeout to 4 seconds. The carrier detection looks partially broken to me. The current logic detects an instantly available carrier as flaky because netif_carrier_ok() takes less than 1/10s. This patch does what I assume is intended, make sure the carrier is stable for 1/10s. Signed-off-by: Patrick McHardy --------------020409060805070303080608 Content-Type: text/plain; name="x" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="x" ===== net/core/netpoll.c 1.27 vs edited ===== --- 1.27/net/core/netpoll.c 2005-01-26 06:32:56 +01:00 +++ edited/net/core/netpoll.c 2005-03-06 01:07:16 +01:00 @@ -592,8 +592,7 @@ } rtnl_shunlock(); - atleast = jiffies + HZ/10; - atmost = jiffies + 10*HZ; + atmost = jiffies + 4*HZ; while (!netif_carrier_ok(ndev)) { if (time_after(jiffies, atmost)) { printk(KERN_NOTICE @@ -604,9 +603,15 @@ cond_resched(); } + atleast = jiffies + HZ/10; + while (netif_carrier_ok(ndev)) { + if (time_after(jiffies, atleast)) + break; + cond_resched(); + } if (time_before(jiffies, atleast)) { printk(KERN_NOTICE "%s: carrier detect appears flaky," - " waiting 10 seconds\n", + " waiting 4 seconds\n", np->name); while (time_before(jiffies, atmost)) cond_resched(); --------------020409060805070303080608-- From romieu@fr.zoreil.com Sat Mar 5 16:16:30 2005 Received: with ECARTIS (v1.0.0; list netdev); Sat, 05 Mar 2005 16:16:34 -0800 (PST) Received: from fr.zoreil.com (electric-eye.fr.zoreil.com [213.41.134.224]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j260GSM3006728 for ; Sat, 5 Mar 2005 16:16:29 -0800 Received: from electric-eye.fr.zoreil.com (localhost.localdomain [127.0.0.1]) by fr.zoreil.com (8.13.1/8.12.1) with ESMTP id j260FpkX029465; Sun, 6 Mar 2005 01:15:51 +0100 Received: (from romieu@localhost) by electric-eye.fr.zoreil.com (8.13.1/8.13.1/Submit) id j260Fk38029464; Sun, 6 Mar 2005 01:15:46 +0100 Date: Sun, 6 Mar 2005 01:15:46 +0100 From: Francois Romieu To: Daniele Venzano Cc: Jeff Garzik , netdev@oss.sgi.com Subject: Re: [PATCH 1/1] More ethtool support for sis900 Message-ID: <20050306001546.GE25116@electric-eye.fr.zoreil.com> References: <20050305134011.23638.68926@localhost.localdomain> <4229FA32.4000401@pobox.com> <02a49476862ae18433e5b80aafa616fd@libero.it> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <02a49476862ae18433e5b80aafa616fd@libero.it> User-Agent: Mutt/1.4.1i X-Organisation: Land of Sunshine Inc. X-Virus-Scanned: ClamAV 0.83/748/Fri Mar 4 14:19:11 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 2471 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: romieu@fr.zoreil.com Precedence: bulk X-list: netdev Content-Length: 437 Lines: 14 Daniele Venzano : [...] > I saw the locking, but I couldn't come up with a reason for it. Is it > needed because of kernel wide preemption ? Usually you do not want simultaneous accesses to the mii interface (link events, Tx timeout recovery or so). From a quick glance at the sis900 driver, I would expect the lock to protect against sis900_timer() (assuming you add a simple spinlock to it as well). -- Ueimor From oxymoron@waste.org Sat Mar 5 16:20:22 2005 Received: with ECARTIS (v1.0.0; list netdev); Sat, 05 Mar 2005 16:20:25 -0800 (PST) Received: from waste.org (waste.org [216.27.176.166]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j260KLPB010722 for ; Sat, 5 Mar 2005 16:20:21 -0800 Received: from waste.org (localhost [127.0.0.1]) by waste.org (8.13.2/8.13.2/Debian-1) with ESMTP id j260KFVT031289 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Sat, 5 Mar 2005 18:20:15 -0600 Received: (from oxymoron@localhost) by waste.org (8.13.2/8.13.2/Submit) id j260KFFo031286; Sat, 5 Mar 2005 18:20:15 -0600 Date: Sat, 5 Mar 2005 16:20:15 -0800 From: Matt Mackall To: Patrick McHardy Cc: Jeff Garzik , netdev@oss.sgi.com, Jeff Moyer Subject: Re: [PATCH 1/7] netpoll: shorten carrier detect timeout Message-ID: <20050306002015.GD3120@waste.org> References: <2.454130102@selenic.com> <422A4A38.4040303@trash.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <422A4A38.4040303@trash.net> User-Agent: Mutt/1.5.6+20040907i X-Virus-Scanned: ClamAV 0.83/748/Fri Mar 4 14:19:11 2005 on oss.sgi.com X-Virus-Scanned: by amavisd-new X-Virus-Status: Clean X-archive-position: 2472 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: mpm@selenic.com Precedence: bulk X-list: netdev Content-Length: 608 Lines: 16 On Sun, Mar 06, 2005 at 01:09:28AM +0100, Patrick McHardy wrote: > Matt Mackall wrote: > >Shorten carrier detect timeout to 4 seconds. > > The carrier detection looks partially broken to me. The current logic > detects an instantly available carrier as flaky because > netif_carrier_ok() takes less than 1/10s. This patch does what > I assume is intended, make sure the carrier is stable for 1/10s. Looks ok, but I've been meaning to change the second loop to something like msleep(). Did you try this with a card that otherwise goes into the wait? -- Mathematics is the supreme nostalgia of our time. From kaber@trash.net Sat Mar 5 17:01:11 2005 Received: with ECARTIS (v1.0.0; list netdev); Sat, 05 Mar 2005 17:01:15 -0800 (PST) Received: from kaber.coreworks.de ([62.206.217.67]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j2611AxP012791 for ; Sat, 5 Mar 2005 17:01:11 -0800 Received: from localhost ([127.0.0.1]) by kaber.coreworks.de with esmtp (Exim 4.50) id 1D7k8j-0001pN-5u; Sun, 06 Mar 2005 02:01:01 +0100 Message-ID: <422A564D.4080809@trash.net> Date: Sun, 06 Mar 2005 02:01:01 +0100 From: Patrick McHardy User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.7.5) Gecko/20050106 Debian/1.7.5-1 X-Accept-Language: en MIME-Version: 1.0 To: Matt Mackall CC: Jeff Garzik , netdev@oss.sgi.com, Jeff Moyer Subject: Re: [PATCH 1/7] netpoll: shorten carrier detect timeout References: <2.454130102@selenic.com> <422A4A38.4040303@trash.net> <20050306002015.GD3120@waste.org> In-Reply-To: <20050306002015.GD3120@waste.org> Content-Type: multipart/mixed; boundary="------------000108030807050108000103" X-Virus-Scanned: ClamAV 0.83/748/Fri Mar 4 14:19:11 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 2473 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: kaber@trash.net Precedence: bulk X-list: netdev Content-Length: 2721 Lines: 96 This is a multi-part message in MIME format. --------------000108030807050108000103 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Matt Mackall wrote: > On Sun, Mar 06, 2005 at 01:09:28AM +0100, Patrick McHardy wrote: >> >>The carrier detection looks partially broken to me. The current logic >>detects an instantly available carrier as flaky because >>netif_carrier_ok() takes less than 1/10s. This patch does what >>I assume is intended, make sure the carrier is stable for 1/10s. > > > Looks ok, but I've been meaning to change the second loop to something > like msleep(). How about this one ? I also removed oflags, reading it outside of the locked section was racy. > Did you try this with a card that otherwise goes into the wait? Yes, I tried with sk98lin. I don't have a card here that actually supports netpoll. Signed-off-by: Patrick McHardy --------------000108030807050108000103 Content-Type: text/plain; name="x" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="x" ===== net/core/netpoll.c 1.27 vs edited ===== --- 1.27/net/core/netpoll.c 2005-01-26 06:32:56 +01:00 +++ edited/net/core/netpoll.c 2005-03-06 01:58:48 +01:00 @@ -18,6 +18,7 @@ #include #include #include +#include #include #include #include @@ -575,16 +576,14 @@ } if (!netif_running(ndev)) { - unsigned short oflags; unsigned long atmost, atleast; + long left; printk(KERN_INFO "%s: device %s not up yet, forcing it\n", np->name, np->dev_name); - oflags = ndev->flags; - rtnl_shlock(); - if (dev_change_flags(ndev, oflags | IFF_UP) < 0) { + if (dev_change_flags(ndev, ndev->flags | IFF_UP) < 0) { printk(KERN_ERR "%s: failed to open %s\n", np->name, np->dev_name); rtnl_shunlock(); @@ -592,8 +591,7 @@ } rtnl_shunlock(); - atleast = jiffies + HZ/10; - atmost = jiffies + 10*HZ; + atmost = jiffies + 4*HZ; while (!netif_carrier_ok(ndev)) { if (time_after(jiffies, atmost)) { printk(KERN_NOTICE @@ -604,12 +602,16 @@ cond_resched(); } + atleast = jiffies + HZ/10; + while (netif_carrier_ok(ndev) && time_before(jiffies, atleast)) + cond_resched(); if (time_before(jiffies, atleast)) { printk(KERN_NOTICE "%s: carrier detect appears flaky," - " waiting 10 seconds\n", + " waiting 4 seconds\n", np->name); - while (time_before(jiffies, atmost)) - cond_resched(); + left = atmost - jiffies; + if (left > 0) + msleep(jiffies_to_msecs(left)); } } --------------000108030807050108000103-- From pedro.fortuna@gmail.com Sat Mar 5 18:04:58 2005 Received: with ECARTIS (v1.0.0; list netdev); Sat, 05 Mar 2005 18:05:02 -0800 (PST) Received: from rproxy.gmail.com (rproxy.gmail.com [64.233.170.199]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j2624vrZ015845 for ; Sat, 5 Mar 2005 18:04:58 -0800 Received: by rproxy.gmail.com with SMTP id y7so904145rne for ; Sat, 05 Mar 2005 18:04:57 -0800 (PST) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:reply-to:to:subject:in-reply-to:mime-version:content-type:content-transfer-encoding:references; b=SV82JuT3fyol41YGGpk06C4xgInmFMdyXjQQi1FGFekAkvBI1ARFffL0F8szFOU+M/Y/QCFwAGZQT6uTQxtzDpKoWf3tXjwpYOB2QSVoHWGvmfaO+BSFVQppoFa4YHadLVb4/0X2vMkqRM0w1WG1geHYCYXte9nBpxo9FB5SOh4= Received: by 10.11.99.50 with SMTP id w50mr276028cwb; Sat, 05 Mar 2005 18:04:57 -0800 (PST) Received: by 10.11.99.66 with HTTP; Sat, 5 Mar 2005 18:04:57 -0800 (PST) Message-ID: Date: Sun, 6 Mar 2005 02:04:57 +0000 From: Pedro Fortuna Reply-To: Pedro Fortuna To: Asim Shankar Subject: Re: filtering packtes before OS takes care about them In-Reply-To: <7bca1cb50503051729e3273d3@mail.gmail.com> Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit References: <09766A6E64A068419B362367800D50C0B58A17@moritz.faps.uni-erlangen.de> <7bca1cb50502281209798e8a00@mail.gmail.com> <7bca1cb505030510586aeb96c1@mail.gmail.com> <7bca1cb50503051729e3273d3@mail.gmail.com> X-Virus-Scanned: ClamAV 0.83/748/Fri Mar 4 14:19:11 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 2474 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: pedro.fortuna@gmail.com Precedence: bulk X-list: netdev Content-Length: 1751 Lines: 52 Thanks for you help Asim :) On Sat, 5 Mar 2005 19:29:34 -0600, Asim Shankar wrote: > Hi Pedro, > > Yeah, it should be able to cover all outgoing packets as well. > Basically, all struct packet_type{}s with the type field set to > htons(ETH_P_ALL) are also called on outgoing packets (see > dev_queue_xmit_nit() called by dev_queue_xmit() in net/core/dev.c) > > Though as I mentioned earlier, I'm not sure if this will *always* > happen (i.e., if outgoing packets *always* go through > dev_queue_xmit()). Someone more knowledgeable may have to answer that. > > Best of luck and let me know if you have any trouble, > Regards, > > -- Asim > > On Sat, 5 Mar 2005 19:36:38 +0000, Pedro Fortuna > wrote: > > Hello Asim, > > I tried again but this time in Fedora Core 3 (kernel 2.6.10-1.760_FC3) > > and it went flawlessly. > > I have a look into your example and also into the Phrack article you > > mentioned and now I'm ready to begin some tests towards what I want to > > implement. > > > > It's absolutly clear you can fetch (and modify) packets before they > > are delivered to the TCP/IP stack with a custom packet_type function, > > but is it also possible to intercept just before they are passed to > > the network driver? > > > > Thanks, > > -Pedro Fortuna > > > > > > On Sat, 5 Mar 2005 12:58:23 -0600, Asim Shankar wrote: > > > > I wasnt able to compile your packet_type_test.c : > > > > all I got was a huge list of errors > > > > and warnings, and no .o compiled in the end. > > > > > > Can you send the specific errors you got? > > > And is the kernel sources present in > > > /lib/modules/`uname -r`/build? > > > > > > Regards, > > > > > > -- Asim > > > > > > From zdenek@rcn.com Sat Mar 5 18:23:23 2005 Received: with ECARTIS (v1.0.0; list netdev); Sat, 05 Mar 2005 18:23:28 -0800 (PST) Received: from smtp06.mrf.mail.rcn.net (smtp06.mrf.mail.rcn.net [207.172.4.65]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j262NNgL016946 for ; Sat, 5 Mar 2005 18:23:23 -0800 Received: from 209-150-50-115.c3-0.nwt-ubr3.sbo-nwt.ma.cable.rcn.com ([209.150.50.115] helo=funex) by smtp06.mrf.mail.rcn.net with smtp (Exim 3.35 #7) id 1D7lQN-0002gz-00; Sat, 05 Mar 2005 21:23:19 -0500 X-Sender: zdenek@pop.rcn.com X-Mailer: QUALCOMM Windows Eudora Pro Version 4.0 Date: Sat, 05 Mar 2005 21:20:25 -0500 To: netdev@oss.sgi.com, linux-net@vger.kernel.org From: Zdenek Radouch Subject: Do you know the TCP stack? (127.x.x.x routing) Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Message-Id: X-Virus-Scanned: ClamAV 0.83/748/Fri Mar 4 14:19:11 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 2475 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: zdenek@rcn.com Precedence: bulk X-list: netdev Content-Length: 2277 Lines: 46 How can I disable the stack processing for the 127 net? Can someone estimate the amount of work needed to do that, and/or point me to the relevant piece of code? That is, I'd like to treat the 127 net the same as all other network numbers. Since that is not the case in the current stack, I want to remove or disable whatever processing there is. I am using 2.4 kernel. Here is a long version and a rationale. I need a truly private network on a device that serves as a router in someone else's network. (The device itself has an internal network). As far as I know, there is no provision for this within the existing network numbering scheme. Obviously, the architects of the current numbering scheme did not think one could build a router with more than a single card. Unfortunately, routers are being built today with intelligent line cards, and there is nothing simpler that the IP/socket based IPC between Ethernet-connected cards. The problem is immediately obvious: one can't use any legal address for the internal network, since it may collide with an external network the device is handling. And since the device can be routing non-Internet addresses, the "reserved" numbers are as unusable as the normal ones. The only solution I've seen on routers running BSD stack is to subnet the 127 net, and use one of the subnets for the internal network. Unfortunately, this does not work with the Linux stack, because the 127 net is treated (for good reasons I suppose) as a special net. What I need is to remove whatever special processing there is, so that the net can be treated as any other net. Then I could, for example, attach 127.0.0.1/16 to the "lo" device, and 127.1.0.0/16 would be my internal net, thus keeping the standard 127.0.0.1 address for the localhost, and having a truly private internal network. So, that's all fine, except for the fact that I am not familiar with the Linux stack code. I do need this done, so as a first step I'd like to get a feeling for the scope of the required modification and an estimated effort to do this. As with my previous problem, if it turns out that this is a non-trivial effort, I will gladly arrange a short-term contract for someone in order to be adequately compensated for the work. Thanks. -Zdenek From random@72616e646f6d20323030342d30342d31360a.nosense.org Sat Mar 5 21:01:17 2005 Received: with ECARTIS (v1.0.0; list netdev); Sat, 05 Mar 2005 21:01:22 -0800 (PST) Received: from ubu.nosense.org (166.cust13.sa.dsl.ozemail.com.au [210.84.236.166]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j2651GGK027784 for ; Sat, 5 Mar 2005 21:01:17 -0800 Received: from ubu.nosense.org (ubu.nosense.org [127.0.0.1]) by ubu.nosense.org (Postfix) with SMTP id 22A8A62AAE; Sun, 6 Mar 2005 15:31:09 +1030 (CST) Date: Sun, 6 Mar 2005 15:31:08 +1030 From: Mark Smith To: ahu@ds9a.nl Cc: netdev@oss.sgi.com Subject: bridge between ppp and ethernet - 1 IP address and assign it to another host Message-Id: <20050306153108.20430b58.random@72616e646f6d20323030342d30342d31360a.nosense.org> X-Mailer: Sylpheed version 1.0.0beta1 (GTK+ 1.2.10; i686-pc-linux-gnu) X-Location: Adelaide, Australia Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV 0.83/748/Fri Mar 4 14:19:11 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 2476 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: random@72616e646f6d20323030342d30342d31360a.nosense.org Precedence: bulk X-list: netdev Content-Length: 406 Lines: 19 Hi Ben, (sorry for not preserving the message thread id, I'm not subscribed to netdev) "What we're trying to do is a lot like building a bridge between ethernet and ppp, but not quite." I've thought doing this sort of thing would be quite useful, in particular if the Linux box could also perform firewalling on the "bridged" traffic. Regards, Mark. -- The Internet's nature is peer to peer. From davem@davemloft.net Sat Mar 5 21:46:48 2005 Received: with ECARTIS (v1.0.0; list netdev); Sat, 05 Mar 2005 21:46:52 -0800 (PST) Received: from cheetah.davemloft.net (mail@dsl027-180-174.sfo1.dsl.speakeasy.net [216.27.180.174]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j265km2C030096 for ; Sat, 5 Mar 2005 21:46:48 -0800 Received: from localhost ([127.0.0.1] helo=cheetah.davemloft.net ident=davem) by cheetah.davemloft.net with smtp (Exim 3.36 #1 (Debian)) id 1D7oaA-0001SD-00 for ; Sat, 05 Mar 2005 21:45:38 -0800 Date: Sat, 5 Mar 2005 21:45:38 -0800 From: "David S. Miller" To: netdev@oss.sgi.com Subject: net-2.6.12 Message-Id: <20050305214538.05dfc3cf.davem@davemloft.net> X-Mailer: Sylpheed version 1.0.1 (GTK+ 1.2.10; sparc-unknown-linux-gnu) X-Face: "_;p5u5aPsO,_Vsx"^v-pEq09'CU4&Dc1$fQExov$62l60cgCc%FnIwD=.UF^a>?5'9Kn[;433QFVV9M..2eN.@4ZWPGbdi<=?[:T>y?SD(R*-3It"Vj:)"dP Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV 0.83/748/Fri Mar 4 14:19:11 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 2477 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: davem@davemloft.net Precedence: bulk X-list: netdev Content-Length: 447 Lines: 14 I just pushed all of that work to Linus, this tree is at: bk://kernel.bkbits.net/davem/net-2.6 I'll start working on the backlog which has accumulated over the past few days starting tomorrow. Today was mega-merge day since I have a bunch of VM layer API changes and Sparc64 bug fixes to push to Linus today as well. So, there is no need to resend any patches. Either it's in the that tree I pushed to Linus, or I'll get to it tomorrow :-) From herbert@gondor.apana.org.au Sun Mar 6 01:17:00 2005 Received: with ECARTIS (v1.0.0; list netdev); Sun, 06 Mar 2005 01:17:08 -0800 (PST) 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 j269Gwdd011909 for ; Sun, 6 Mar 2005 01:17:00 -0800 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 1D7rot-0000fP-00; Sun, 06 Mar 2005 20:13:03 +1100 Received: from herbert by gondolin.me.apana.org.au with local (Exim 3.36 #1 (Debian)) id 1D7rlY-0008K0-00; Sun, 06 Mar 2005 20:09:36 +1100 Date: Sun, 6 Mar 2005 20:09:36 +1100 To: Adrian Bunk Cc: Jeff Garzik , akpm@osdl.org, davem@davemloft.net, netdev@oss.sgi.com Subject: Re: [patch 1/3] fix buggy IEEE80211_CRYPT_* selects Message-ID: <20050306090936.GA31890@gondor.apana.org.au> References: <200503041237.j24Cbb69026470@shell0.pdx.osdl.net> <42289BDF.1080409@pobox.com> <20050304221014.GJ3327@stusta.de> <4228DF62.4000205@pobox.com> <20050304230718.GL3327@stusta.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20050304230718.GL3327@stusta.de> User-Agent: Mutt/1.5.6+20040907i From: Herbert Xu X-Virus-Scanned: ClamAV 0.83/748/Fri Mar 4 14:19:11 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 2478 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: herbert@gondor.apana.org.au Precedence: bulk X-list: netdev Content-Length: 557 Lines: 15 On Sat, Mar 05, 2005 at 12:07:18AM +0100, Adrian Bunk wrote: > > The way kconfig currently works, you have to ensure that the > dependencies of what you select are fulfilled. Yes Adrian's right. In the other places where we select CRYPTO symbols, we always make sure that CRYPTO itself is selected. See net/ipv4/Kconfig for example. Cheers, -- Visit Openswan at http://www.openswan.org/ Email: Herbert Xu ~{PmV>HI~} Home Page: http://gondor.apana.org.au/~herbert/ PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt From mj+f-060305+netdev=oss.sgi.com@ucw.cz Sun Mar 6 01:56:45 2005 Received: with ECARTIS (v1.0.0; list netdev); Sun, 06 Mar 2005 01:56:52 -0800 (PST) Received: from albireo.ucw.cz (postfix@albireo.ucw.cz [84.242.65.67]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j269uiLG014705 for ; Sun, 6 Mar 2005 01:56:45 -0800 Received: by albireo.ucw.cz (Postfix, from userid 1000) id BDE977C341; Sun, 6 Mar 2005 10:56:42 +0100 (CET) Date: Sun, 6 Mar 2005 10:56:42 +0100 From: Martin Mares To: Zdenek Radouch Cc: netdev@oss.sgi.com, linux-net@vger.kernel.org Subject: Re: Do you know the TCP stack? (127.x.x.x routing) Message-ID: <20050306095642.GA1352@ucw.cz> References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.3.28i X-Virus-Scanned: ClamAV 0.83/748/Fri Mar 4 14:19:11 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 2479 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: mj@ucw.cz Precedence: bulk X-list: netdev Content-Length: 526 Lines: 19 Hello! > Unfortunately, this does not work with the Linux stack, because the > 127 net is treated (for good reasons I suppose) as a special net. Is it really? I've just tried ip addr del 127.0.0.1/8 dev lo ip addr add 127.0.0.1/24 dev lo and `ping 127.1.2.3' is then happily sent along the default route. Have a nice fortnight -- Martin `MJ' Mares http://atrey.karlin.mff.cuni.cz/~mj/ Faculty of Math and Physics, Charles University, Prague, Czech Rep., Earth Only dead fish swim with the stream. From webvenza@libero.it Sun Mar 6 02:02:38 2005 Received: with ECARTIS (v1.0.0; list netdev); Sun, 06 Mar 2005 02:02:43 -0800 (PST) Received: from gateway.milesteg.arr (foobar@adsl-ull-59-137.44-151.net24.it [151.44.137.59]) by oss.sgi.com (8.13.0/8.13.0) with SMTP id j26A2bJw015633 for ; Sun, 6 Mar 2005 02:02:38 -0800 Received: (qmail 23945 invoked from network); 6 Mar 2005 10:02:35 -0000 Received: from unknown (HELO ?192.168.0.205?) (192.168.0.205) by gateway.milesteg.arr with SMTP; 6 Mar 2005 10:02:35 -0000 In-Reply-To: <20050305212838.GD25116@electric-eye.fr.zoreil.com> References: <20050305210745.6763.6618@localhost.localdomain> <20050305212838.GD25116@electric-eye.fr.zoreil.com> Mime-Version: 1.0 (Apple Message framework v619.2) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <15e3c357f5586727c04c81a091cb809c@libero.it> Content-Transfer-Encoding: 7bit Cc: netdev@oss.sgi.com, Jeff Garzik From: Daniele Venzano Subject: Re: [PATCH 1/1] More ethtool support for sis900 (with locking) Date: Sun, 6 Mar 2005 11:01:32 +0100 To: Francois Romieu X-Mailer: Apple Mail (2.619.2) X-Virus-Scanned: ClamAV 0.83/748/Fri Mar 4 14:19:11 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 2480 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: webvenza@libero.it Precedence: bulk X-list: netdev Content-Length: 948 Lines: 34 On 05/mar/05, at 22:28, Francois Romieu wrote: > Daniele Venzano : > [...] >> Index: sis900.c >> =================================================================== >> --- a/drivers/net/sis900.c (revision 95) >> +++ b/drivers/net/sis900.c (revision 98) > [...] >> @@ -1943,10 +1952,47 @@ >> sis_priv->msg_enable = value; >> } >> >> +static u32 sis900_get_link(struct net_device *net_dev) >> +{ >> + struct sis900_private *sis_priv = net_dev->priv; > > Any reason to not use netdev_priv() ? I'm keeping the style of the rest of the driver, when more pressing issues (wol, netconsole, weird behaviour in suspend/resume) are solved I'll convert the whole source to netdev_priv(). > I would not mind an empty line between the declaration of variables > and the actual code. It seemed to me a waste of space, as the functions are so small and obvious. Thanks for the feedback. -- Daniele Venzano http://www.brownhat.org From webvenza@libero.it Sun Mar 6 02:05:00 2005 Received: with ECARTIS (v1.0.0; list netdev); Sun, 06 Mar 2005 02:05:04 -0800 (PST) Received: from gateway.milesteg.arr (foobar@adsl-ull-59-137.44-151.net24.it [151.44.137.59]) by oss.sgi.com (8.13.0/8.13.0) with SMTP id j26A4wRG016253 for ; Sun, 6 Mar 2005 02:04:59 -0800 Received: (qmail 24044 invoked from network); 6 Mar 2005 10:04:57 -0000 Received: from unknown (HELO ?192.168.0.205?) (192.168.0.205) by gateway.milesteg.arr with SMTP; 6 Mar 2005 10:04:57 -0000 In-Reply-To: <20050306001546.GE25116@electric-eye.fr.zoreil.com> References: <20050305134011.23638.68926@localhost.localdomain> <4229FA32.4000401@pobox.com> <02a49476862ae18433e5b80aafa616fd@libero.it> <20050306001546.GE25116@electric-eye.fr.zoreil.com> Mime-Version: 1.0 (Apple Message framework v619.2) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: Content-Transfer-Encoding: 7bit Cc: netdev@oss.sgi.com From: Daniele Venzano Subject: Re: [PATCH 1/1] More ethtool support for sis900 Date: Sun, 6 Mar 2005 11:03:54 +0100 To: Francois Romieu X-Mailer: Apple Mail (2.619.2) X-Virus-Scanned: ClamAV 0.83/748/Fri Mar 4 14:19:11 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 2481 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: webvenza@libero.it Precedence: bulk X-list: netdev Content-Length: 578 Lines: 22 On 06/mar/05, at 01:15, Francois Romieu wrote: > Daniele Venzano : > [...] >> I saw the locking, but I couldn't come up with a reason for it. Is it >> needed because of kernel wide preemption ? > > Usually you do not want simultaneous accesses to the mii interface > (link events, Tx timeout recovery or so). > > From a quick glance at the sis900 driver, I would expect the lock to > protect against sis900_timer() (assuming you add a simple spinlock to > it as well). Yes, that makes sense. Will do. Thanks. -- Daniele Venzano http://www.brownhat.org From herbert@gondor.apana.org.au Sun Mar 6 02:30:40 2005 Received: with ECARTIS (v1.0.0; list netdev); Sun, 06 Mar 2005 02:30:47 -0800 (PST) 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 j26AUcER018048 for ; Sun, 6 Mar 2005 02:30:39 -0800 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 1D7t1T-00015x-00; Sun, 06 Mar 2005 21:30:07 +1100 Received: from herbert by gondolin.me.apana.org.au with local (Exim 3.36 #1 (Debian)) id 1D7t0w-0008Qa-00; Sun, 06 Mar 2005 21:29:34 +1100 From: Herbert Xu To: kaber@trash.net (Patrick McHardy) Subject: Re: [PATCH 3/3 XFRM]: Fix invalid key for lookup of cached bundles Cc: davem@davemloft.net, netdev@oss.sgi.com Organization: Core In-Reply-To: <4229BB3E.8020203@trash.net> X-Newsgroups: apana.lists.os.linux.netdev User-Agent: tin/1.7.4-20040225 ("Benbecula") (UNIX) (Linux/2.4.27-hx-1-686-smp (i686)) Message-Id: Date: Sun, 06 Mar 2005 21:29:34 +1100 X-Virus-Scanned: ClamAV 0.83/748/Fri Mar 4 14:19:11 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 2482 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: herbert@gondor.apana.org.au Precedence: bulk X-list: netdev Content-Length: 823 Lines: 24 Patrick McHardy wrote: > > @@ -97,6 +104,7 @@ > err = xfrm_dst_lookup((struct xfrm_dst**)&rt, &fl_tunnel, AF_INET); > if (err) > goto error; > + rt->u.dst.flags |= DST_XFRM_TUNNEL; This line doesn't look right. rt is an entry in the IPv4 routing cache, right? If so why should its flags change when some bundle is created? After all, it could also be used at the bottom of a transport mode bundle. Besides, I think IPv4 routing cache entry will never show up at the top of a bundle anyway which means that this flags value will never be read in the find_bundle function. Cheers, -- Visit Openswan at http://www.openswan.org/ Email: Herbert Xu ~{PmV>HI~} Home Page: http://gondor.apana.org.au/~herbert/ PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt From domen@coderock.org Sun Mar 6 02:32:44 2005 Received: with ECARTIS (v1.0.0; list netdev); Sun, 06 Mar 2005 02:32:49 -0800 (PST) Received: from trashy.coderock.org (postfix@coderock.org [193.77.147.115]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j26AWggb018528 for ; Sun, 6 Mar 2005 02:32:43 -0800 Received: by trashy.coderock.org (Postfix, from userid 780) id 5E48E1F203; Sun, 6 Mar 2005 11:32:41 +0100 (CET) Received: from localhost (localhost [127.0.0.1]) by trashy.coderock.org (Postfix) with ESMTP id A9AD41F1F0; Sun, 6 Mar 2005 11:32:40 +0100 (CET) Received: from localhost.localdomain (localhost [127.0.0.1]) by trashy.coderock.org (Postfix) with ESMTP id 86F181E46E; Sun, 6 Mar 2005 11:32:38 +0100 (CET) Subject: [patch 01/26] list_for_each: net-ipv6-ip6_fib.c To: jgarzik@pobox.com Cc: netdev@oss.sgi.com, domen@coderock.org, janitor@sternwelten.at From: domen@coderock.org Date: Sun, 06 Mar 2005 11:32:38 +0100 Message-Id: <20050306103238.86F181E46E@trashy.coderock.org> X-Virus-Scanned: ClamAV 0.83/748/Fri Mar 4 14:19:11 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 2483 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: domen@coderock.org Precedence: bulk X-list: netdev Content-Length: 853 Lines: 28 s/for/list_for_each/ Compile tested. Signed-off-by: Domen Puncer Signed-off-by: Maximilian Attems Signed-off-by: Domen Puncer --- kj-domen/net/ipv6/ip6_fib.c | 2 +- 1 files changed, 1 insertion(+), 1 deletion(-) diff -puN net/ipv6/ip6_fib.c~list-for-each-drivers_net_ipv6_ip6_fib net/ipv6/ip6_fib.c --- kj/net/ipv6/ip6_fib.c~list-for-each-drivers_net_ipv6_ip6_fib 2005-03-05 16:09:09.000000000 +0100 +++ kj-domen/net/ipv6/ip6_fib.c 2005-03-05 16:09:09.000000000 +0100 @@ -99,7 +99,7 @@ struct fib6_walker_t fib6_walker_list = .next = &fib6_walker_list, }; -#define FOR_WALKERS(w) for ((w)=fib6_walker_list.next; (w) != &fib6_walker_list; (w)=(w)->next) +#define FOR_WALKERS(w) list_for_each((w), &fib6_walker_list) static __inline__ u32 fib6_new_sernum(void) { _ From domen@coderock.org Sun Mar 6 02:32:47 2005 Received: with ECARTIS (v1.0.0; list netdev); Sun, 06 Mar 2005 02:32:51 -0800 (PST) Received: from trashy.coderock.org (postfix@coderock.org [193.77.147.115]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j26AWkNq018549 for ; Sun, 6 Mar 2005 02:32:46 -0800 Received: by trashy.coderock.org (Postfix, from userid 780) id 6731A1F204; Sun, 6 Mar 2005 11:32:45 +0100 (CET) Received: from localhost (localhost [127.0.0.1]) by trashy.coderock.org (Postfix) with ESMTP id 7DA981F1F0; Sun, 6 Mar 2005 11:32:44 +0100 (CET) Received: from localhost.localdomain (localhost [127.0.0.1]) by trashy.coderock.org (Postfix) with ESMTP id AF5E41E46E; Sun, 6 Mar 2005 11:32:41 +0100 (CET) Subject: [patch 02/26] list_for_each: drivers-net-tulip-de4x5.c To: jgarzik@pobox.com Cc: netdev@oss.sgi.com, domen@coderock.org, janitor@sternwelten.at From: domen@coderock.org Date: Sun, 06 Mar 2005 11:32:41 +0100 Message-Id: <20050306103241.AF5E41E46E@trashy.coderock.org> X-Virus-Scanned: ClamAV 0.83/748/Fri Mar 4 14:19:11 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 2484 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: domen@coderock.org Precedence: bulk X-list: netdev Content-Length: 1081 Lines: 31 s/for/list_for_each/ Compile tested. Signed-off-by: Domen Puncer Signed-off-by: Maximilian Attems Signed-off-by: Domen Puncer --- kj-domen/drivers/net/tulip/de4x5.c | 4 ++-- 1 files changed, 2 insertions(+), 2 deletions(-) diff -puN drivers/net/tulip/de4x5.c~list-for-each-drivers_net_tulip_de4x5 drivers/net/tulip/de4x5.c --- kj/drivers/net/tulip/de4x5.c~list-for-each-drivers_net_tulip_de4x5 2005-03-05 16:09:10.000000000 +0100 +++ kj-domen/drivers/net/tulip/de4x5.c 2005-03-05 16:09:10.000000000 +0100 @@ -2143,9 +2143,9 @@ srom_search(struct net_device *dev, stru u_long iobase = 0; /* Clear upper 32 bits in Alphas */ int i, j, cfrv; struct de4x5_private *lp = netdev_priv(dev); - struct list_head *walk = &pdev->bus_list; + struct list_head *walk; - for (walk = walk->next; walk != &pdev->bus_list; walk = walk->next) { + list_for_each(walk, &pdev->bus_list) { struct pci_dev *this_dev = pci_dev_b(walk); /* Skip the pci_bus list entry */ _ From domen@coderock.org Sun Mar 6 02:32:51 2005 Received: with ECARTIS (v1.0.0; list netdev); Sun, 06 Mar 2005 02:32:57 -0800 (PST) Received: from trashy.coderock.org (postfix@coderock.org [193.77.147.115]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j26AWoNP018585 for ; Sun, 6 Mar 2005 02:32:50 -0800 Received: by trashy.coderock.org (Postfix, from userid 780) id 6307E1F204; Sun, 6 Mar 2005 11:32:49 +0100 (CET) Received: from localhost (localhost [127.0.0.1]) by trashy.coderock.org (Postfix) with ESMTP id 47FB21E46E; Sun, 6 Mar 2005 11:32:48 +0100 (CET) Received: from localhost.localdomain (localhost [127.0.0.1]) by trashy.coderock.org (Postfix) with ESMTP id F31E91F202; Sun, 6 Mar 2005 11:32:44 +0100 (CET) Subject: [patch 03/26] net/3c505: replace schedule_timeout() with msleep() To: jgarzik@pobox.com Cc: netdev@oss.sgi.com, domen@coderock.org, nacc@us.ibm.com, pb@nexus.co.uk, janitor@sternwelten.at From: domen@coderock.org Date: Sun, 06 Mar 2005 11:32:44 +0100 Message-Id: <20050306103244.F31E91F202@trashy.coderock.org> X-Virus-Scanned: ClamAV 0.83/748/Fri Mar 4 14:19:11 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 2485 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: domen@coderock.org Precedence: bulk X-list: netdev Content-Length: 1368 Lines: 41 Use msleep() instead of schedule_timeout() to guarantee the task delays as expected. Signed-off-by: Nishanth Aravamudan Acked-by: Phil Blundell Signed-off-by: Maximilian Attems Signed-off-by: Domen Puncer --- kj-domen/drivers/net/3c505.c | 6 ++---- 1 files changed, 2 insertions(+), 4 deletions(-) diff -puN drivers/net/3c505.c~msleep-drivers_net_3c505 drivers/net/3c505.c --- kj/drivers/net/3c505.c~msleep-drivers_net_3c505 2005-03-05 16:09:22.000000000 +0100 +++ kj-domen/drivers/net/3c505.c 2005-03-05 16:09:22.000000000 +0100 @@ -1317,8 +1317,7 @@ static int __init elp_sense(struct net_d if (orig_HSR & DIR) { /* If HCR.DIR is up, we pull it down. HSR.DIR should follow. */ outb(0, dev->base_addr + PORT_CONTROL); - set_current_state(TASK_UNINTERRUPTIBLE); - schedule_timeout(30*HZ/100); + msleep(300); if (inb_status(addr) & DIR) { if (elp_debug > 0) printk(notfound_msg, 2); @@ -1327,8 +1326,7 @@ static int __init elp_sense(struct net_d } else { /* If HCR.DIR is down, we pull it up. HSR.DIR should follow. */ outb(DIR, dev->base_addr + PORT_CONTROL); - set_current_state(TASK_UNINTERRUPTIBLE); - schedule_timeout(30*HZ/100); + msleep(300); if (!(inb_status(addr) & DIR)) { if (elp_debug > 0) printk(notfound_msg, 3); _ From domen@coderock.org Sun Mar 6 02:32:56 2005 Received: with ECARTIS (v1.0.0; list netdev); Sun, 06 Mar 2005 02:33:01 -0800 (PST) Received: from trashy.coderock.org (postfix@coderock.org [193.77.147.115]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j26AWt5u018692 for ; Sun, 6 Mar 2005 02:32:55 -0800 Received: by trashy.coderock.org (Postfix, from userid 780) id 1489F1F205; Sun, 6 Mar 2005 11:32:53 +0100 (CET) Received: from localhost (localhost [127.0.0.1]) by trashy.coderock.org (Postfix) with ESMTP id 36E591F202; Sun, 6 Mar 2005 11:32:53 +0100 (CET) Received: from localhost.localdomain (localhost [127.0.0.1]) by trashy.coderock.org (Postfix) with ESMTP id 7C3A21F1F0; Sun, 6 Mar 2005 11:32:48 +0100 (CET) Subject: [patch 04/26] net/ixgb_osdep: replace schedule_timeout() with msleep() To: jgarzik@pobox.com Cc: netdev@oss.sgi.com, domen@coderock.org, nacc@us.ibm.com, janitor@sternwelten.at From: domen@coderock.org Date: Sun, 06 Mar 2005 11:32:48 +0100 Message-Id: <20050306103248.7C3A21F1F0@trashy.coderock.org> X-Virus-Scanned: ClamAV 0.83/748/Fri Mar 4 14:19:11 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 2486 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: domen@coderock.org Precedence: bulk X-list: netdev Content-Length: 1227 Lines: 37 Use msleep() instead of schedule_timeout() to guarantee the task delays as expected. I was told earlier that the in_interrupt() check is not necessary. It would be nice to get some verification of this (i.e. the driver functions the same without it). Signed-off-by: Nishanth Aravamudan Signed-off-by: Maximilian Attems Signed-off-by: Domen Puncer --- kj-domen/drivers/net/ixgb/ixgb_osdep.h | 8 +------- 1 files changed, 1 insertion(+), 7 deletions(-) diff -puN drivers/net/ixgb/ixgb_osdep.h~msleep-drivers_net_ixgb_ixgb_osdep drivers/net/ixgb/ixgb_osdep.h --- kj/drivers/net/ixgb/ixgb_osdep.h~msleep-drivers_net_ixgb_ixgb_osdep 2005-03-05 16:09:27.000000000 +0100 +++ kj-domen/drivers/net/ixgb/ixgb_osdep.h 2005-03-05 16:09:27.000000000 +0100 @@ -41,13 +41,7 @@ #include #ifndef msec_delay -#define msec_delay(x) do { if(in_interrupt()) { \ - /* Don't mdelay in interrupt context! */ \ - BUG(); \ - } else { \ - set_current_state(TASK_UNINTERRUPTIBLE); \ - schedule_timeout((x * HZ)/1000 + 2); \ - } } while(0) +#define msec_delay(x) msleep(x) #endif #define PCI_COMMAND_REGISTER PCI_COMMAND _ From domen@coderock.org Sun Mar 6 02:33:02 2005 Received: with ECARTIS (v1.0.0; list netdev); Sun, 06 Mar 2005 02:33:07 -0800 (PST) Received: from trashy.coderock.org (postfix@coderock.org [193.77.147.115]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j26AWwX3018788 for ; Sun, 6 Mar 2005 02:33:01 -0800 Received: by trashy.coderock.org (Postfix, from userid 780) id E93631F204; Sun, 6 Mar 2005 11:32:57 +0100 (CET) Received: from localhost (localhost [127.0.0.1]) by trashy.coderock.org (Postfix) with ESMTP id DA7011F202; Sun, 6 Mar 2005 11:32:56 +0100 (CET) Received: from localhost.localdomain (localhost [127.0.0.1]) by trashy.coderock.org (Postfix) with ESMTP id B55FA1E46E; Sun, 6 Mar 2005 11:32:51 +0100 (CET) Subject: [patch 05/26] net/ixgb_ethtool: replace schedule_timeout() with msleep_interruptible() To: jgarzik@pobox.com Cc: netdev@oss.sgi.com, domen@coderock.org, nacc@us.ibm.com, janitor@sternwelten.at From: domen@coderock.org Date: Sun, 06 Mar 2005 11:32:51 +0100 Message-Id: <20050306103251.B55FA1E46E@trashy.coderock.org> X-Virus-Scanned: ClamAV 0.83/748/Fri Mar 4 14:19:11 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 2487 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: domen@coderock.org Precedence: bulk X-list: netdev Content-Length: 1083 Lines: 32 Use msleep_interruptible() instead of schedule_timeout() to guarantee the task delays as expected. Signed-off-by: Nishanth Aravamudan Signed-off-by: Maximilian Attems Signed-off-by: Domen Puncer --- kj-domen/drivers/net/ixgb/ixgb_ethtool.c | 4 ++-- 1 files changed, 2 insertions(+), 2 deletions(-) diff -puN drivers/net/ixgb/ixgb_ethtool.c~msleep_interruptible-drivers_net_ixgb_ixgb_ethtool drivers/net/ixgb/ixgb_ethtool.c --- kj/drivers/net/ixgb/ixgb_ethtool.c~msleep_interruptible-drivers_net_ixgb_ixgb_ethtool 2005-03-05 16:09:32.000000000 +0100 +++ kj-domen/drivers/net/ixgb/ixgb_ethtool.c 2005-03-05 16:09:32.000000000 +0100 @@ -617,9 +617,9 @@ ixgb_phys_id(struct net_device *netdev, set_current_state(TASK_INTERRUPTIBLE); if(data) - schedule_timeout(data * HZ); + msleep_interruptible(data * 1000); else - schedule_timeout(MAX_SCHEDULE_TIMEOUT); + msleep_interruptible(jiffies_to_msecs(MAX_SCHEDULE_TIMEOUT)); del_timer_sync(&adapter->blink_timer); ixgb_led_off(&adapter->hw); _ From domen@coderock.org Sun Mar 6 02:33:07 2005 Received: with ECARTIS (v1.0.0; list netdev); Sun, 06 Mar 2005 02:33:11 -0800 (PST) Received: from trashy.coderock.org (postfix@coderock.org [193.77.147.115]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j26AX3dZ018884 for ; Sun, 6 Mar 2005 02:33:05 -0800 Received: by trashy.coderock.org (Postfix, from userid 780) id 6F9AF1F204; Sun, 6 Mar 2005 11:33:02 +0100 (CET) Received: from localhost (localhost [127.0.0.1]) by trashy.coderock.org (Postfix) with ESMTP id EB93B1F202; Sun, 6 Mar 2005 11:33:00 +0100 (CET) Received: from localhost.localdomain (localhost [127.0.0.1]) by trashy.coderock.org (Postfix) with ESMTP id E5EDD1F1F0; Sun, 6 Mar 2005 11:32:54 +0100 (CET) Subject: [patch 06/26] net/pcnet32: replace schedule_timeout() with msleep_interruptible() To: jgarzik@pobox.com Cc: netdev@oss.sgi.com, domen@coderock.org, nacc@us.ibm.com, janitor@sternwelten.at From: domen@coderock.org Date: Sun, 06 Mar 2005 11:32:54 +0100 Message-Id: <20050306103254.E5EDD1F1F0@trashy.coderock.org> X-Virus-Scanned: ClamAV 0.83/748/Fri Mar 4 14:19:11 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 2488 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: domen@coderock.org Precedence: bulk X-list: netdev Content-Length: 972 Lines: 29 Use msleep_interruptible() instead of schedule_timeout() to guarantee the task delays as expected. Signed-off-by: Nishanth Aravamudan Signed-off-by: Maximilian Attems Signed-off-by: Domen Puncer --- kj-domen/drivers/net/pcnet32.c | 2 +- 1 files changed, 1 insertion(+), 1 deletion(-) diff -puN drivers/net/pcnet32.c~msleep_interruptible-drivers_net_pcnet32 drivers/net/pcnet32.c --- kj/drivers/net/pcnet32.c~msleep_interruptible-drivers_net_pcnet32 2005-03-05 16:09:33.000000000 +0100 +++ kj-domen/drivers/net/pcnet32.c 2005-03-05 16:09:33.000000000 +0100 @@ -847,7 +847,7 @@ static int pcnet32_phys_id(struct net_de if ((!data) || (data > (u32)(MAX_SCHEDULE_TIMEOUT / HZ))) data = (u32)(MAX_SCHEDULE_TIMEOUT / HZ); - schedule_timeout(data * HZ); + msleep_interruptible(data * 1000); del_timer_sync(&lp->blink_timer); /* Restore the original value of the bcrs */ _ From domen@coderock.org Sun Mar 6 02:33:17 2005 Received: with ECARTIS (v1.0.0; list netdev); Sun, 06 Mar 2005 02:33:23 -0800 (PST) Received: from trashy.coderock.org (postfix@coderock.org [193.77.147.115]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j26AXFO4019108 for ; Sun, 6 Mar 2005 02:33:15 -0800 Received: by trashy.coderock.org (Postfix, from userid 780) id B83951F23B; Sun, 6 Mar 2005 11:33:13 +0100 (CET) Received: from localhost (localhost [127.0.0.1]) by trashy.coderock.org (Postfix) with ESMTP id CEECE1F204; Sun, 6 Mar 2005 11:33:11 +0100 (CET) Received: from localhost.localdomain (localhost [127.0.0.1]) by trashy.coderock.org (Postfix) with ESMTP id 6FC481E46E; Sun, 6 Mar 2005 11:32:58 +0100 (CET) Subject: [patch 07/26] net/cycx_drv: replace delay_cycx() with msleep_interruptible() To: jgarzik@pobox.com Cc: netdev@oss.sgi.com, domen@coderock.org, nacc@us.ibm.com, acme@conectiva.com.br, janitor@sternwelten.at From: domen@coderock.org Date: Sun, 06 Mar 2005 11:32:57 +0100 Message-Id: <20050306103258.6FC481E46E@trashy.coderock.org> X-Virus-Scanned: ClamAV 0.83/748/Fri Mar 4 14:19:11 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 2489 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: domen@coderock.org Precedence: bulk X-list: netdev Content-Length: 3123 Lines: 105 Use msleep_interruptible() instead of delay_cycx() to guarantee the task delays as expected. Remove the prototype and definition of delay_cycx(). Signed-off-by: Nishanth Aravamudan Acked-by: Arnaldo Carvalho de Melo Signed-off-by: Maximilian Attems Signed-off-by: Domen Puncer --- kj-domen/drivers/net/wan/cycx_drv.c | 24 ++++++++---------------- 1 files changed, 8 insertions(+), 16 deletions(-) diff -puN drivers/net/wan/cycx_drv.c~msleep_interruptible-drivers_net_wan_cycx_drv drivers/net/wan/cycx_drv.c --- kj/drivers/net/wan/cycx_drv.c~msleep_interruptible-drivers_net_wan_cycx_drv 2005-03-05 16:09:34.000000000 +0100 +++ kj-domen/drivers/net/wan/cycx_drv.c 2005-03-05 16:09:34.000000000 +0100 @@ -56,7 +56,7 @@ #include /* for jiffies, HZ, etc. */ #include /* API definitions */ #include /* CYCX firmware module definitions */ -#include /* udelay */ +#include /* udelay, msleep */ #include /* read[wl], write[wl], ioremap, iounmap */ #define MOD_VERSION 0 @@ -74,7 +74,6 @@ static int reset_cyc2x(void __iomem *add static int detect_cyc2x(void __iomem *addr); /* Miscellaneous functions */ -static void delay_cycx(int sec); static int get_option_index(long *optlist, long optval); static u16 checksum(u8 *buf, u32 len); @@ -259,7 +258,7 @@ static int memory_exists(void __iomem *a if (readw(addr + 0x10) == TEST_PATTERN) return 1; - delay_cycx(1); + msleep_interruptible(1000); } return 0; @@ -316,7 +315,7 @@ static void cycx_reset_boot(void __iomem /* 80186 was in hold, go */ writeb(0, addr + START_CPU); - delay_cycx(1); + msleep_interruptible(1000); } /* Load data.bin file through boot (reset) interface. */ @@ -462,13 +461,13 @@ static int load_cyc2x(struct cycx_hw *hw cycx_reset_boot(hw->dpmbase, reset_image, img_hdr->reset_size); /* reset is waiting for boot */ writew(GEN_POWER_ON, pt_cycld); - delay_cycx(1); + msleep_interruptible(1000); for (j = 0 ; j < 3 ; j++) if (!readw(pt_cycld)) goto reset_loaded; else - delay_cycx(1); + msleep_interruptible(1000); } printk(KERN_ERR "%s: reset not started.\n", modname); @@ -495,7 +494,7 @@ reset_loaded: /* Arthur Ganzert's tip: wait a while after the firmware loading... seg abr 26 17:17:12 EST 1999 - acme */ - delay_cycx(7); + msleep_interruptible(7000); printk(KERN_INFO "%s: firmware loaded!\n", modname); /* enable interrupts */ @@ -547,20 +546,13 @@ static int get_option_index(long *optlis static int reset_cyc2x(void __iomem *addr) { writeb(0, addr + RST_ENABLE); - delay_cycx(2); + msleep_interruptible(2000); writeb(0, addr + RST_DISABLE); - delay_cycx(2); + msleep_interruptible(2000); return memory_exists(addr); } -/* Delay */ -static void delay_cycx(int sec) -{ - set_current_state(TASK_INTERRUPTIBLE); - schedule_timeout(sec * HZ); -} - /* Calculate 16-bit CRC using CCITT polynomial. */ static u16 checksum(u8 *buf, u32 len) { _ From domen@coderock.org Sun Mar 6 02:33:22 2005 Received: with ECARTIS (v1.0.0; list netdev); Sun, 06 Mar 2005 02:33:30 -0800 (PST) Received: from trashy.coderock.org (postfix@coderock.org [193.77.147.115]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j26AXKfm019247 for ; Sun, 6 Mar 2005 02:33:21 -0800 Received: by trashy.coderock.org (Postfix, from userid 780) id B30611F23B; Sun, 6 Mar 2005 11:33:19 +0100 (CET) Received: from localhost (localhost [127.0.0.1]) by trashy.coderock.org (Postfix) with ESMTP id 9AF3B1F205; Sun, 6 Mar 2005 11:33:17 +0100 (CET) Received: from localhost.localdomain (localhost [127.0.0.1]) by trashy.coderock.org (Postfix) with ESMTP id EF37B1F203; Sun, 6 Mar 2005 11:33:01 +0100 (CET) Subject: [patch 08/26] janitor: net/e1000: remove pci_find_device To: jgarzik@pobox.com Cc: netdev@oss.sgi.com, domen@coderock.org, sfeldma@pobox.com, janitor@sternwelten.at From: domen@coderock.org Date: Sun, 06 Mar 2005 11:33:01 +0100 Message-Id: <20050306103301.EF37B1F203@trashy.coderock.org> X-Virus-Scanned: ClamAV 0.83/748/Fri Mar 4 14:19:11 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 2490 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: domen@coderock.org Precedence: bulk X-list: netdev Content-Length: 3248 Lines: 108 Removing pci_find_device required removing driver's custom reboot notifier which walked the device list and replace it with standard driver ->shutdown method. Compiled and tested. Signed-off-by: Scott Feldman Signed-off-by: Maximilian Attems Signed-off-by: Domen Puncer --- kj-domen/drivers/net/e1000/e1000_main.c | 38 ++++++++------------------------ 1 files changed, 10 insertions(+), 28 deletions(-) diff -puN drivers/net/e1000/e1000_main.c~remove-pci-find-device-drivers_net_e1000_e1000_main drivers/net/e1000/e1000_main.c --- kj/drivers/net/e1000/e1000_main.c~remove-pci-find-device-drivers_net_e1000_e1000_main 2005-03-05 16:09:43.000000000 +0100 +++ kj-domen/drivers/net/e1000/e1000_main.c 2005-03-05 16:09:43.000000000 +0100 @@ -165,7 +165,7 @@ static void e1000_vlan_rx_add_vid(struct static void e1000_vlan_rx_kill_vid(struct net_device *netdev, uint16_t vid); static void e1000_restore_vlan(struct e1000_adapter *adapter); -static int e1000_notify_reboot(struct notifier_block *, unsigned long event, void *ptr); +static void e1000_shutdown(struct device *dev); static int e1000_suspend(struct pci_dev *pdev, uint32_t state); #ifdef CONFIG_PM static int e1000_resume(struct pci_dev *pdev); @@ -176,12 +176,6 @@ static int e1000_resume(struct pci_dev * static void e1000_netpoll (struct net_device *netdev); #endif -struct notifier_block e1000_notifier_reboot = { - .notifier_call = e1000_notify_reboot, - .next = NULL, - .priority = 0 -}; - /* Exported from other modules */ extern void e1000_check_options(struct e1000_adapter *adapter); @@ -194,8 +188,11 @@ static struct pci_driver e1000_driver = /* Power Managment Hooks */ #ifdef CONFIG_PM .suspend = e1000_suspend, - .resume = e1000_resume + .resume = e1000_resume, #endif + .driver = { + .shutdown = e1000_shutdown, + } }; MODULE_AUTHOR("Intel Corporation, "); @@ -216,17 +213,12 @@ MODULE_PARM_DESC(debug, "Debug level (0= static int __init e1000_init_module(void) { - int ret; printk(KERN_INFO "%s - version %s\n", e1000_driver_string, e1000_driver_version); printk(KERN_INFO "%s\n", e1000_copyright); - ret = pci_module_init(&e1000_driver); - if(ret >= 0) { - register_reboot_notifier(&e1000_notifier_reboot); - } - return ret; + return pci_module_init(&e1000_driver); } module_init(e1000_init_module); @@ -241,7 +233,6 @@ module_init(e1000_init_module); static void __exit e1000_exit_module(void) { - unregister_reboot_notifier(&e1000_notifier_reboot); pci_unregister_driver(&e1000_driver); } @@ -2783,21 +2774,12 @@ e1000_set_spd_dplx(struct e1000_adapter return 0; } -static int -e1000_notify_reboot(struct notifier_block *nb, unsigned long event, void *p) +static +void e1000_shutdown(struct device *dev) { - struct pci_dev *pdev = NULL; + struct pci_dev *pdev = container_of(dev, struct pci_dev, dev); - switch(event) { - case SYS_DOWN: - case SYS_HALT: - case SYS_POWER_OFF: - while((pdev = pci_find_device(PCI_ANY_ID, PCI_ANY_ID, pdev))) { - if(pci_dev_driver(pdev) == &e1000_driver) - e1000_suspend(pdev, 3); - } - } - return NOTIFY_DONE; + e1000_suspend(pdev, 3); } static int _ From domen@coderock.org Sun Mar 6 02:33:23 2005 Received: with ECARTIS (v1.0.0; list netdev); Sun, 06 Mar 2005 02:33:31 -0800 (PST) Received: from trashy.coderock.org (postfix@coderock.org [193.77.147.115]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j26AXM6j019283 for ; Sun, 6 Mar 2005 02:33:23 -0800 Received: by trashy.coderock.org (Postfix, from userid 780) id 8D4581F205; Sun, 6 Mar 2005 11:33:21 +0100 (CET) Received: from localhost (localhost [127.0.0.1]) by trashy.coderock.org (Postfix) with ESMTP id 38C301F208; Sun, 6 Mar 2005 11:33:18 +0100 (CET) Received: from localhost.localdomain (localhost [127.0.0.1]) by trashy.coderock.org (Postfix) with ESMTP id 5110C1F1F0; Sun, 6 Mar 2005 11:33:05 +0100 (CET) Subject: [patch 09/26] janitor: net/gt96100eth: pci_find_device to pci_get_device To: jgarzik@pobox.com Cc: netdev@oss.sgi.com, domen@coderock.org, sfeldma@pobox.com, janitor@sternwelten.at From: domen@coderock.org Date: Sun, 06 Mar 2005 11:33:04 +0100 Message-Id: <20050306103305.5110C1F1F0@trashy.coderock.org> X-Virus-Scanned: ClamAV 0.83/748/Fri Mar 4 14:19:11 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 2491 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: domen@coderock.org Precedence: bulk X-list: netdev Content-Length: 1524 Lines: 46 Replace pci_find_device with pci_get_device/pci_dev_put to plug race with pci_find_device. Signed-off-by: Scott Feldman Signed-off-by: Maximilian Attems Signed-off-by: Domen Puncer --- kj-domen/drivers/net/gt96100eth.c | 6 ++++-- 1 files changed, 4 insertions(+), 2 deletions(-) diff -puN drivers/net/gt96100eth.c~remove-pci-find-device-drivers_net_gt96100eth drivers/net/gt96100eth.c --- kj/drivers/net/gt96100eth.c~remove-pci-find-device-drivers_net_gt96100eth 2005-03-05 16:09:43.000000000 +0100 +++ kj-domen/drivers/net/gt96100eth.c 2005-03-05 16:09:43.000000000 +0100 @@ -615,9 +615,9 @@ static int gt96100_init_module(void) /* * Stupid probe because this really isn't a PCI device */ - if (!(pci = pci_find_device(PCI_VENDOR_ID_MARVELL, + if (!(pci = pci_get_device(PCI_VENDOR_ID_MARVELL, PCI_DEVICE_ID_MARVELL_GT96100, NULL)) && - !(pci = pci_find_device(PCI_VENDOR_ID_MARVELL, + !(pci = pci_get_device(PCI_VENDOR_ID_MARVELL, PCI_DEVICE_ID_MARVELL_GT96100A, NULL))) { printk(KERN_ERR __FILE__ ": GT96100 not found!\n"); return -ENODEV; @@ -627,12 +627,14 @@ static int gt96100_init_module(void) if (cpuConfig & (1<<12)) { printk(KERN_ERR __FILE__ ": must be in Big Endian mode!\n"); + pci_dev_put(pci); return -ENODEV; } for (i=0; i < NUM_INTERFACES; i++) retval |= gt96100_probe1(pci, i); + pci_dev_put(pci); return retval; } _ From domen@coderock.org Sun Mar 6 02:33:32 2005 Received: with ECARTIS (v1.0.0; list netdev); Sun, 06 Mar 2005 02:33:38 -0800 (PST) Received: from trashy.coderock.org (postfix@coderock.org [193.77.147.115]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j26AXTsg019425 for ; Sun, 6 Mar 2005 02:33:30 -0800 Received: by trashy.coderock.org (Postfix, from userid 780) id 1257E1F23D; Sun, 6 Mar 2005 11:33:28 +0100 (CET) Received: from localhost (localhost [127.0.0.1]) by trashy.coderock.org (Postfix) with ESMTP id 828671F208; Sun, 6 Mar 2005 11:33:27 +0100 (CET) Received: from localhost.localdomain (localhost [127.0.0.1]) by trashy.coderock.org (Postfix) with ESMTP id 3155B1E46E; Sun, 6 Mar 2005 11:33:12 +0100 (CET) Subject: [patch 11/26] janitor: net/tg3: pci_find_device to pci_dev_present To: jgarzik@pobox.com Cc: netdev@oss.sgi.com, domen@coderock.org, sfeldma@pobox.com, janitor@sternwelten.at From: domen@coderock.org Date: Sun, 06 Mar 2005 11:33:11 +0100 Message-Id: <20050306103312.3155B1E46E@trashy.coderock.org> X-Virus-Scanned: ClamAV 0.83/748/Fri Mar 4 14:19:11 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 2492 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: domen@coderock.org Precedence: bulk X-list: netdev Content-Length: 2084 Lines: 56 Replace pci_find_device with pci_dev_present. Compile tested. Signed-off-by: Scott Feldman Signed-off-by: Maximilian Attems Signed-off-by: Domen Puncer --- kj-domen/drivers/net/tg3.c | 24 ++++++++++++++---------- 1 files changed, 14 insertions(+), 10 deletions(-) diff -puN drivers/net/tg3.c~remove-pci-find-device-drivers_net_tg3 drivers/net/tg3.c --- kj/drivers/net/tg3.c~remove-pci-find-device-drivers_net_tg3 2005-03-05 16:09:45.000000000 +0100 +++ kj-domen/drivers/net/tg3.c 2005-03-05 16:09:45.000000000 +0100 @@ -7829,6 +7829,19 @@ static int __devinit tg3_is_sun_570X(str static int __devinit tg3_get_invariants(struct tg3 *tp) { + static struct pci_device_id write_reorder_chipsets[] = { + { PCI_DEVICE(PCI_VENDOR_ID_INTEL, + PCI_DEVICE_ID_INTEL_82801AA_8) }, + { PCI_DEVICE(PCI_VENDOR_ID_INTEL, + PCI_DEVICE_ID_INTEL_82801AB_8) }, + { PCI_DEVICE(PCI_VENDOR_ID_INTEL, + PCI_DEVICE_ID_INTEL_82801BA_11) }, + { PCI_DEVICE(PCI_VENDOR_ID_INTEL, + PCI_DEVICE_ID_INTEL_82801BA_6) }, + { PCI_DEVICE(PCI_VENDOR_ID_AMD, + PCI_DEVICE_ID_AMD_FE_GATE_700C) }, + { }, + }; u32 misc_ctrl_reg; u32 cacheline_sz_reg; u32 pci_state_reg, grc_misc_cfg; @@ -7847,16 +7860,7 @@ static int __devinit tg3_get_invariants( * every mailbox register write to force the writes to be * posted to the chip in order. */ - if (pci_find_device(PCI_VENDOR_ID_INTEL, - PCI_DEVICE_ID_INTEL_82801AA_8, NULL) || - pci_find_device(PCI_VENDOR_ID_INTEL, - PCI_DEVICE_ID_INTEL_82801AB_8, NULL) || - pci_find_device(PCI_VENDOR_ID_INTEL, - PCI_DEVICE_ID_INTEL_82801BA_11, NULL) || - pci_find_device(PCI_VENDOR_ID_INTEL, - PCI_DEVICE_ID_INTEL_82801BA_6, NULL) || - pci_find_device(PCI_VENDOR_ID_AMD, - PCI_DEVICE_ID_AMD_FE_GATE_700C, NULL)) + if (pci_dev_present(write_reorder_chipsets)) tp->tg3_flags |= TG3_FLAG_MBOX_WRITE_REORDER; /* Force memory write invalidate off. If we leave it on, _ From domen@coderock.org Sun Mar 6 02:33:35 2005 Received: with ECARTIS (v1.0.0; list netdev); Sun, 06 Mar 2005 02:33:42 -0800 (PST) Received: from trashy.coderock.org (postfix@coderock.org [193.77.147.115]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j26AXWKM019478 for ; Sun, 6 Mar 2005 02:33:33 -0800 Received: by trashy.coderock.org (Postfix, from userid 780) id 03E971F23E; Sun, 6 Mar 2005 11:33:31 +0100 (CET) Received: from localhost (localhost [127.0.0.1]) by trashy.coderock.org (Postfix) with ESMTP id 2C8BC1F208; Sun, 6 Mar 2005 11:33:30 +0100 (CET) Received: from localhost.localdomain (localhost [127.0.0.1]) by trashy.coderock.org (Postfix) with ESMTP id B504E1F204; Sun, 6 Mar 2005 11:33:15 +0100 (CET) Subject: [patch 12/26] net/farsync: add set_current_state() before schedule_timeout() To: jgarzik@pobox.com Cc: netdev@oss.sgi.com, domen@coderock.org, nacc@us.ibm.com, janitor@sternwelten.at From: domen@coderock.org Date: Sun, 06 Mar 2005 11:33:15 +0100 Message-Id: <20050306103315.B504E1F204@trashy.coderock.org> X-Virus-Scanned: ClamAV 0.83/748/Fri Mar 4 14:19:11 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 2493 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: domen@coderock.org Precedence: bulk X-list: netdev Content-Length: 1001 Lines: 29 Insert set_current_state() before schedule_timeout() so the function delays as expected. Without the addition, schedule_timeout() will return immediately. Signed-off-by: Nishanth Aravamudan Signed-off-by: Maximilian Attems Signed-off-by: Domen Puncer --- kj-domen/drivers/net/wan/farsync.c | 1 + 1 files changed, 1 insertion(+) diff -puN drivers/net/wan/farsync.c~set_current_state-drivers_net_wan_farsync drivers/net/wan/farsync.c --- kj/drivers/net/wan/farsync.c~set_current_state-drivers_net_wan_farsync 2005-03-05 16:09:48.000000000 +0100 +++ kj-domen/drivers/net/wan/farsync.c 2005-03-05 16:09:48.000000000 +0100 @@ -981,6 +981,7 @@ fst_issue_cmd(struct fst_port_info *port /* Wait for any previous command to complete */ while (mbval > NAK) { spin_unlock_irqrestore(&card->card_lock, flags); + set_current_state(TASK_UNINTERRUPTIBLE); schedule_timeout(1); spin_lock_irqsave(&card->card_lock, flags); _ From domen@coderock.org Sun Mar 6 02:33:42 2005 Received: with ECARTIS (v1.0.0; list netdev); Sun, 06 Mar 2005 02:33:49 -0800 (PST) Received: from trashy.coderock.org (postfix@coderock.org [193.77.147.115]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j26AXfja019653 for ; Sun, 6 Mar 2005 02:33:41 -0800 Received: by trashy.coderock.org (Postfix, from userid 780) id 0B3501F23E; Sun, 6 Mar 2005 11:33:39 +0100 (CET) Received: from localhost (localhost [127.0.0.1]) by trashy.coderock.org (Postfix) with ESMTP id 409301F208; Sun, 6 Mar 2005 11:33:38 +0100 (CET) Received: from localhost.localdomain (localhost [127.0.0.1]) by trashy.coderock.org (Postfix) with ESMTP id 857041F203; Sun, 6 Mar 2005 11:33:22 +0100 (CET) Subject: [patch 14/26] net/slip: replace schedule_timeout() with msleep() To: jgarzik@pobox.com Cc: netdev@oss.sgi.com, domen@coderock.org, nacc@us.ibm.com From: domen@coderock.org Date: Sun, 06 Mar 2005 11:33:22 +0100 Message-Id: <20050306103322.857041F203@trashy.coderock.org> X-Virus-Scanned: ClamAV 0.83/748/Fri Mar 4 14:19:11 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 2494 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: domen@coderock.org Precedence: bulk X-list: netdev Content-Length: 1146 Lines: 40 Use msleep() instead of schedule_timeout() to guarantee the task delays as expected. While the original code does use TASK_INTERRUPTIBLE, it does not check for signals, so I believe msleep() is more appropriate. Signed-off-by: Nishanth Aravamudan Signed-off-by: Domen Puncer --- kj-domen/drivers/net/slip.c | 7 +++---- 1 files changed, 3 insertions(+), 4 deletions(-) diff -puN drivers/net/slip.c~msleep-drivers_net_slip drivers/net/slip.c --- kj/drivers/net/slip.c~msleep-drivers_net_slip 2005-03-05 16:10:49.000000000 +0100 +++ kj-domen/drivers/net/slip.c 2005-03-05 16:10:49.000000000 +0100 @@ -75,6 +75,7 @@ #include #include #include +#include #include "slip.h" #ifdef CONFIG_INET #include @@ -1395,10 +1396,8 @@ static void __exit slip_exit(void) /* First of all: check for active disciplines and hangup them. */ do { - if (busy) { - set_current_state(TASK_INTERRUPTIBLE); - schedule_timeout(HZ / 10); - } + if (busy) + msleep(100); busy = 0; for (i = 0; i < slip_maxdev; i++) { _ From domen@coderock.org Sun Mar 6 02:33:51 2005 Received: with ECARTIS (v1.0.0; list netdev); Sun, 06 Mar 2005 02:33:58 -0800 (PST) Received: from trashy.coderock.org (postfix@coderock.org [193.77.147.115]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j26AXn7j019808 for ; Sun, 6 Mar 2005 02:33:49 -0800 Received: by trashy.coderock.org (Postfix, from userid 780) id 83B341F205; Sun, 6 Mar 2005 11:33:47 +0100 (CET) Received: from localhost (localhost [127.0.0.1]) by trashy.coderock.org (Postfix) with ESMTP id A476C1F23C; Sun, 6 Mar 2005 11:33:45 +0100 (CET) Received: from localhost.localdomain (localhost [127.0.0.1]) by trashy.coderock.org (Postfix) with ESMTP id B5BDF1F205; Sun, 6 Mar 2005 11:33:25 +0100 (CET) Subject: [patch 15/26] net/skethtool: remove duplicate delay To: jgarzik@pobox.com Cc: netdev@oss.sgi.com, domen@coderock.org, nacc@us.ibm.com From: domen@coderock.org Date: Sun, 06 Mar 2005 11:33:25 +0100 Message-Id: <20050306103325.B5BDF1F205@trashy.coderock.org> X-Virus-Scanned: ClamAV 0.83/748/Fri Mar 4 14:19:11 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 2497 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: domen@coderock.org Precedence: bulk X-list: netdev Content-Length: 1007 Lines: 30 Please consider applying. Remove an unnecessary second (and identical) delay. schedule_timeout() does not need to be called, as msleep_interruptible() already delayed the task. Signed-off-by: Nishanth Aravamudan Signed-off-by: Domen Puncer --- kj-domen/drivers/net/sk98lin/skethtool.c | 3 --- 1 files changed, 3 deletions(-) diff -puN drivers/net/sk98lin/skethtool.c~remove_duplicate_delay-drivers_net_sk98lin_skethtool drivers/net/sk98lin/skethtool.c --- kj/drivers/net/sk98lin/skethtool.c~remove_duplicate_delay-drivers_net_sk98lin_skethtool 2005-03-05 16:11:09.000000000 +0100 +++ kj-domen/drivers/net/sk98lin/skethtool.c 2005-03-05 16:11:09.000000000 +0100 @@ -437,9 +437,6 @@ static int locateDevice(struct net_devic pAC->LedsOn = 0; mod_timer(&pAC->BlinkTimer, jiffies); msleep_interruptible(data * 1000); - - set_current_state(TASK_INTERRUPTIBLE); - schedule_timeout(data * HZ); del_timer_sync(&pAC->BlinkTimer); toggleLeds(pNet, 0); _ From domen@coderock.org Sun Mar 6 02:34:06 2005 Received: with ECARTIS (v1.0.0; list netdev); Sun, 06 Mar 2005 02:34:13 -0800 (PST) Received: from trashy.coderock.org (postfix@coderock.org [193.77.147.115]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j26AY3wO020118 for ; Sun, 6 Mar 2005 02:34:04 -0800 Received: by trashy.coderock.org (Postfix, from userid 780) id 9C65B1F23E; Sun, 6 Mar 2005 11:34:02 +0100 (CET) Received: from localhost (localhost [127.0.0.1]) by trashy.coderock.org (Postfix) with ESMTP id 95D591E46E; Sun, 6 Mar 2005 11:34:00 +0100 (CET) Received: from localhost.localdomain (localhost [127.0.0.1]) by trashy.coderock.org (Postfix) with ESMTP id 3B60B1F202; Sun, 6 Mar 2005 11:33:37 +0100 (CET) Subject: [patch 18/26] net/8139too: remove interruptible_sleep_on_timeout() usage To: jgarzik@pobox.com Cc: netdev@oss.sgi.com, domen@coderock.org, nacc@us.ibm.com From: domen@coderock.org Date: Sun, 06 Mar 2005 11:33:36 +0100 Message-Id: <20050306103337.3B60B1F202@trashy.coderock.org> X-Virus-Scanned: ClamAV 0.83/748/Fri Mar 4 14:19:11 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 2500 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: domen@coderock.org Precedence: bulk X-list: netdev Content-Length: 1945 Lines: 52 One thing I would have preferred using here is use wait_event*(), but there is no condition. However, try_to_freeze(PF_FREEZE) could be used as one, if the return condition matters -- it can return 0 or 1, from what I understand. If the intent is to loop until the task is "frozen," then I can revise the patch to use wait_event_interruptible_timeout(). Replace deprecated interruptible_sleep_on_timeout() function calls with direct wait-queue usage. I did not find the direct wake_up_interruptible() function call in this file for the wait-queue, but that may not be an issue. Patch is compile-tested. Signed-off-by: Nishanth Aravamudan Signed-off-by: Domen Puncer --- kj-domen/drivers/net/8139too.c | 6 +++++- 1 files changed, 5 insertions(+), 1 deletion(-) diff -puN drivers/net/8139too.c~int_sleep_on-drivers_net_8139too drivers/net/8139too.c --- kj/drivers/net/8139too.c~int_sleep_on-drivers_net_8139too 2005-03-05 16:12:09.000000000 +0100 +++ kj-domen/drivers/net/8139too.c 2005-03-05 16:12:09.000000000 +0100 @@ -108,6 +108,7 @@ #include #include #include +#include #include #include #include @@ -1612,6 +1613,7 @@ static inline void rtl8139_thread_iter ( static int rtl8139_thread (void *data) { + DEFINE_WAIT(wait); struct net_device *dev = data; struct rtl8139_private *tp = dev->priv; unsigned long timeout; @@ -1622,7 +1624,9 @@ static int rtl8139_thread (void *data) while (1) { timeout = next_tick; do { - timeout = interruptible_sleep_on_timeout (&tp->thr_wait, timeout); + prepare_to_wait(&tp->thr_wait, &wait, TASK_INTERRUPTIBLE); + timeout = schedule_timeout(timeout); + finish_wait(&tp->thr_wait, &wait); /* make swsusp happy with our thread */ try_to_freeze(PF_FREEZE); } while (!signal_pending (current) && (timeout > 0)); _ From domen@coderock.org Sun Mar 6 02:33:40 2005 Received: with ECARTIS (v1.0.0; list netdev); Sun, 06 Mar 2005 02:33:50 -0800 (PST) Received: from trashy.coderock.org (postfix@coderock.org [193.77.147.115]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j26AXb7D019580 for ; Sun, 6 Mar 2005 02:33:38 -0800 Received: by trashy.coderock.org (Postfix, from userid 780) id B12C81F23D; Sun, 6 Mar 2005 11:33:36 +0100 (CET) Received: from localhost (localhost [127.0.0.1]) by trashy.coderock.org (Postfix) with ESMTP id 960A51F208; Sun, 6 Mar 2005 11:33:34 +0100 (CET) Received: from localhost.localdomain (localhost [127.0.0.1]) by trashy.coderock.org (Postfix) with ESMTP id 090EF1F202; Sun, 6 Mar 2005 11:33:09 +0100 (CET) Subject: [patch 10/26] janitor: net/ixgb: remove pci_find_device To: jgarzik@pobox.com Cc: netdev@oss.sgi.com, domen@coderock.org, sfeldma@pobox.com, janitor@sternwelten.at From: domen@coderock.org Date: Sun, 06 Mar 2005 11:33:08 +0100 Message-Id: <20050306103309.090EF1F202@trashy.coderock.org> X-Virus-Scanned: ClamAV 0.83/748/Fri Mar 4 14:19:11 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 2495 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: domen@coderock.org Precedence: bulk X-list: netdev Content-Length: 4108 Lines: 140 Removing pci_find_device required removing driver's custom reboot notifier which walked the device list and then called the suspend func. But, the suspend func isn't even hooked up to the driver's PM ->suspend hook! So it's vestigial (cut- and-paste from e1000). If ixgb ever implements PM hooks, and there is a need to call ->suspend during shutdown, then ->shutdown can be implemented. The need would be something like Wake-on-LAN (10GbE?) arming. Until then, all this code needs to go. Compile tested. Signed-off-by: Scott Feldman Signed-off-by: Maximilian Attems Signed-off-by: Domen Puncer --- kj-domen/drivers/net/ixgb/ixgb_main.c | 69 ---------------------------------- 1 files changed, 1 insertion(+), 68 deletions(-) diff -puN drivers/net/ixgb/ixgb_main.c~remove-pci-find-device-drivers_net_ixgb_ixgb_main drivers/net/ixgb/ixgb_main.c --- kj/drivers/net/ixgb/ixgb_main.c~remove-pci-find-device-drivers_net_ixgb_ixgb_main 2005-03-05 16:09:44.000000000 +0100 +++ kj-domen/drivers/net/ixgb/ixgb_main.c 2005-03-05 16:09:44.000000000 +0100 @@ -116,21 +116,11 @@ static void ixgb_vlan_rx_add_vid(struct static void ixgb_vlan_rx_kill_vid(struct net_device *netdev, uint16_t vid); static void ixgb_restore_vlan(struct ixgb_adapter *adapter); -static int ixgb_notify_reboot(struct notifier_block *, unsigned long event, - void *ptr); -static int ixgb_suspend(struct pci_dev *pdev, uint32_t state); - #ifdef CONFIG_NET_POLL_CONTROLLER /* for netdump / net console */ static void ixgb_netpoll(struct net_device *dev); #endif -struct notifier_block ixgb_notifier_reboot = { - .notifier_call = ixgb_notify_reboot, - .next = NULL, - .priority = 0 -}; - /* Exported from other modules */ extern void ixgb_check_options(struct ixgb_adapter *adapter); @@ -140,9 +130,6 @@ static struct pci_driver ixgb_driver = { .id_table = ixgb_pci_tbl, .probe = ixgb_probe, .remove = __devexit_p(ixgb_remove), - /* Power Managment Hooks */ - .suspend = NULL, - .resume = NULL }; MODULE_AUTHOR("Intel Corporation, "); @@ -165,17 +152,12 @@ MODULE_LICENSE("GPL"); static int __init ixgb_init_module(void) { - int ret; printk(KERN_INFO "%s - version %s\n", ixgb_driver_string, ixgb_driver_version); printk(KERN_INFO "%s\n", ixgb_copyright); - ret = pci_module_init(&ixgb_driver); - if(ret >= 0) { - register_reboot_notifier(&ixgb_notifier_reboot); - } - return ret; + return pci_module_init(&ixgb_driver); } module_init(ixgb_init_module); @@ -190,7 +172,6 @@ module_init(ixgb_init_module); static void __exit ixgb_exit_module(void) { - unregister_reboot_notifier(&ixgb_notifier_reboot); pci_unregister_driver(&ixgb_driver); } @@ -2072,54 +2053,6 @@ ixgb_restore_vlan(struct ixgb_adapter *a } } -/** - * ixgb_notify_reboot - handles OS notification of reboot event. - * @param nb notifier block, unused - * @param event Event being passed to driver to act upon - * @param p A pointer to our net device - **/ -static int -ixgb_notify_reboot(struct notifier_block *nb, unsigned long event, void *p) -{ - struct pci_dev *pdev = NULL; - - switch(event) { - case SYS_DOWN: - case SYS_HALT: - case SYS_POWER_OFF: - while ((pdev = pci_find_device(PCI_ANY_ID, PCI_ANY_ID, pdev))) { - if (pci_dev_driver(pdev) == &ixgb_driver) - ixgb_suspend(pdev, 3); - } - } - return NOTIFY_DONE; -} - -/** - * ixgb_suspend - driver suspend function called from notify. - * @param pdev pci driver structure used for passing to - * @param state power state to enter - **/ -static int -ixgb_suspend(struct pci_dev *pdev, uint32_t state) -{ - struct net_device *netdev = pci_get_drvdata(pdev); - struct ixgb_adapter *adapter = netdev->priv; - - netif_device_detach(netdev); - - if(netif_running(netdev)) - ixgb_down(adapter, TRUE); - - pci_save_state(pdev); - - state = (state > 0) ? 3 : 0; - pci_set_power_state(pdev, state); - msec_delay(200); - - return 0; -} - #ifdef CONFIG_NET_POLL_CONTROLLER /* * Polling 'interrupt' - used by things like netconsole to send skbs _ From domen@coderock.org Sun Mar 6 02:33:51 2005 Received: with ECARTIS (v1.0.0; list netdev); Sun, 06 Mar 2005 02:33:57 -0800 (PST) Received: from trashy.coderock.org (postfix@coderock.org [193.77.147.115]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j26AXmdj019806 for ; Sun, 6 Mar 2005 02:33:49 -0800 Received: by trashy.coderock.org (Postfix, from userid 780) id 683791F240; Sun, 6 Mar 2005 11:33:47 +0100 (CET) Received: from localhost (localhost [127.0.0.1]) by trashy.coderock.org (Postfix) with ESMTP id 1E01F1F23B; Sun, 6 Mar 2005 11:33:45 +0100 (CET) Received: from localhost.localdomain (localhost [127.0.0.1]) by trashy.coderock.org (Postfix) with ESMTP id 0A45D1F1F0; Sun, 6 Mar 2005 11:33:19 +0100 (CET) Subject: [patch 13/26] net/airo: replace schedule_timeout() with msleep()/ssleep() To: jgarzik@pobox.com Cc: netdev@oss.sgi.com, domen@coderock.org, nacc@us.ibm.com From: domen@coderock.org Date: Sun, 06 Mar 2005 11:33:18 +0100 Message-Id: <20050306103319.0A45D1F1F0@trashy.coderock.org> X-Virus-Scanned: ClamAV 0.83/748/Fri Mar 4 14:19:11 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 2496 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: domen@coderock.org Precedence: bulk X-list: netdev Content-Length: 3037 Lines: 96 Use msleep()/ssleep() instead of schedule_timeout() to guarantee the task delays as expected. Signed-off-by: Nishanth Aravamudan Signed-off-by: Domen Puncer --- kj-domen/drivers/net/wireless/airo.c | 25 +++++++++---------------- 1 files changed, 9 insertions(+), 16 deletions(-) diff -puN drivers/net/wireless/airo.c~msleep_ssleep-drivers_net_wireless_airo drivers/net/wireless/airo.c --- kj/drivers/net/wireless/airo.c~msleep_ssleep-drivers_net_wireless_airo 2005-03-05 16:10:27.000000000 +0100 +++ kj-domen/drivers/net/wireless/airo.c 2005-03-05 16:10:27.000000000 +0100 @@ -1698,9 +1698,8 @@ static int readBSSListRid(struct airo_in issuecommand(ai, &cmd, &rsp); up(&ai->sem); /* Let the command take effect */ - set_current_state (TASK_INTERRUPTIBLE); ai->task = current; - schedule_timeout (3*HZ); + ssleep(3); ai->task = NULL; } rc = PC4500_readrid(ai, first ? RID_BSSLISTFIRST : RID_BSSLISTNEXT, @@ -2685,11 +2684,9 @@ int reset_card( struct net_device *dev , return -1; waitbusy (ai); OUT4500(ai,COMMAND,CMD_SOFTRESET); - set_current_state (TASK_UNINTERRUPTIBLE); - schedule_timeout (HZ/5); + msleep(200); waitbusy (ai); - set_current_state (TASK_UNINTERRUPTIBLE); - schedule_timeout (HZ/5); + msleep(200); if (lock) up(&ai->sem); return 0; @@ -5516,12 +5513,12 @@ static int airo_pci_resume(struct pci_de } else { OUT4500(ai, EVACK, EV_AWAKEN); OUT4500(ai, EVACK, EV_AWAKEN); - schedule_timeout(HZ/10); + msleep(100); } set_bit (FLAG_COMMIT, &ai->flags); disable_MAC(ai, 0); - schedule_timeout (HZ/5); + msleep(200); if (ai->SSID) { writeSsidRid(ai, ai->SSID, 0); kfree(ai->SSID); @@ -7470,8 +7467,7 @@ int cmdreset(struct airo_info *ai) { OUT4500(ai,COMMAND,CMD_SOFTRESET); - set_current_state (TASK_UNINTERRUPTIBLE); - schedule_timeout (HZ); /* WAS 600 12/7/00 */ + ssleep(1); /* WAS 600 12/7/00 */ if(!waitbusy (ai)){ printk(KERN_INFO "Waitbusy hang AFTER RESET\n"); @@ -7498,8 +7494,7 @@ int setflashmode (struct airo_info *ai) OUT4500(ai, SWS3, FLASH_COMMAND); OUT4500(ai, COMMAND,0); } - set_current_state (TASK_UNINTERRUPTIBLE); - schedule_timeout (HZ/2); /* 500ms delay */ + msleep(500); /* 500ms delay */ if(!waitbusy(ai)) { clear_bit (FLAG_FLASHING, &ai->flags); @@ -7609,8 +7604,7 @@ int flashputbuf(struct airo_info *ai){ int flashrestart(struct airo_info *ai,struct net_device *dev){ int i,status; - set_current_state (TASK_UNINTERRUPTIBLE); - schedule_timeout (HZ); /* Added 12/7/00 */ + ssleep(1); /* Added 12/7/00 */ clear_bit (FLAG_FLASHING, &ai->flags); if (test_bit(FLAG_MPI, &ai->flags)) { status = mpi_init_descriptors(ai); @@ -7625,8 +7619,7 @@ int flashrestart(struct airo_info *ai,st ( ai, 2312, i >= MAX_FIDS / 2 ); } - set_current_state (TASK_UNINTERRUPTIBLE); - schedule_timeout (HZ); /* Added 12/7/00 */ + ssleep(1); /* Added 12/7/00 */ return status; } #endif /* CISCO_EXT */ _ From domen@coderock.org Sun Mar 6 02:34:02 2005 Received: with ECARTIS (v1.0.0; list netdev); Sun, 06 Mar 2005 02:34:07 -0800 (PST) Received: from trashy.coderock.org (postfix@coderock.org [193.77.147.115]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j26AXxXH020040 for ; Sun, 6 Mar 2005 02:34:00 -0800 Received: by trashy.coderock.org (Postfix, from userid 780) id BFAA41F240; Sun, 6 Mar 2005 11:33:58 +0100 (CET) Received: from localhost (localhost [127.0.0.1]) by trashy.coderock.org (Postfix) with ESMTP id 89B9B1F23B; Sun, 6 Mar 2005 11:33:56 +0100 (CET) Received: from localhost.localdomain (localhost [127.0.0.1]) by trashy.coderock.org (Postfix) with ESMTP id 9BCC41E46E; Sun, 6 Mar 2005 11:33:29 +0100 (CET) Subject: [patch 16/26] net/sb1000: replace nicedelay() with ssleep() To: jgarzik@pobox.com Cc: netdev@oss.sgi.com, domen@coderock.org, nacc@us.ibm.com From: domen@coderock.org Date: Sun, 06 Mar 2005 11:33:29 +0100 Message-Id: <20050306103329.9BCC41E46E@trashy.coderock.org> X-Virus-Scanned: ClamAV 0.83/748/Fri Mar 4 14:19:11 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 2499 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: domen@coderock.org Precedence: bulk X-list: netdev Content-Length: 2662 Lines: 74 Use ssleep() instead of nicedelay() to guarantee the task delays as expected. Remove the prototype and definition of nicedelay(). This is a very weird function, because it is called to sleep in terms of usecs, but always sleeps for 1 second, completely ignoring the parameter. I have gone ahead and followed suit, just sleeping for a second in all cases, but maybe someone with the hardware could tell me if perhaps the paramter *should* matter. Additionally, nicedelay() is called in TASK_INTERRUPTIBLE state, but doesn't deal with signals in case these longer delays do not complete, so I believe ssleep() is more appropriate. Signed-off-by: Nishanth Aravamudan Signed-off-by: Domen Puncer --- kj-domen/drivers/net/sb1000.c | 14 +++----------- 1 files changed, 3 insertions(+), 11 deletions(-) diff -puN drivers/net/sb1000.c~ssleep-drivers_net_sb1000 drivers/net/sb1000.c --- kj/drivers/net/sb1000.c~ssleep-drivers_net_sb1000 2005-03-05 16:11:16.000000000 +0100 +++ kj-domen/drivers/net/sb1000.c 2005-03-05 16:11:16.000000000 +0100 @@ -90,7 +90,6 @@ static int sb1000_close(struct net_devic /* SB1000 hardware routines to be used during open/configuration phases */ -static inline void nicedelay(unsigned long usecs); static inline int card_wait_for_busy_clear(const int ioaddr[], const char* name); static inline int card_wait_for_ready(const int ioaddr[], const char* name, @@ -254,13 +253,6 @@ static struct pnp_driver sb1000_driver = const int TimeOutJiffies = (875 * HZ) / 100; -static inline void nicedelay(unsigned long usecs) -{ - current->state = TASK_INTERRUPTIBLE; - schedule_timeout(HZ); - return; -} - /* Card Wait For Busy Clear (cannot be used during an interrupt) */ static inline int card_wait_for_busy_clear(const int ioaddr[], const char* name) @@ -475,7 +467,7 @@ sb1000_reset(const int ioaddr[], const c udelay(1000); outb(0x0, port); inb(port); - nicedelay(60000); + ssleep(1); outb(0x4, port); inb(port); udelay(1000); @@ -537,7 +529,7 @@ sb1000_activate(const int ioaddr[], cons const unsigned char Command0[6] = {0x80, 0x11, 0x00, 0x00, 0x00, 0x00}; const unsigned char Command1[6] = {0x80, 0x16, 0x00, 0x00, 0x00, 0x00}; - nicedelay(50000); + ssleep(1); if ((status = card_send_command(ioaddr, name, Command0, st))) return status; if ((status = card_send_command(ioaddr, name, Command1, st))) @@ -944,7 +936,7 @@ sb1000_open(struct net_device *dev) /* initialize sb1000 */ if ((status = sb1000_reset(ioaddr, name))) return status; - nicedelay(200000); + ssleep(1); if ((status = sb1000_check_CRC(ioaddr, name))) return status; _ From domen@coderock.org Sun Mar 6 02:33:59 2005 Received: with ECARTIS (v1.0.0; list netdev); Sun, 06 Mar 2005 02:34:04 -0800 (PST) Received: from trashy.coderock.org (postfix@coderock.org [193.77.147.115]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j26AXvcA019970 for ; Sun, 6 Mar 2005 02:33:57 -0800 Received: by trashy.coderock.org (Postfix, from userid 780) id DEA4A1F23E; Sun, 6 Mar 2005 11:33:55 +0100 (CET) Received: from localhost (localhost [127.0.0.1]) by trashy.coderock.org (Postfix) with ESMTP id D3A261F23B; Sun, 6 Mar 2005 11:33:53 +0100 (CET) Received: from localhost.localdomain (localhost [127.0.0.1]) by trashy.coderock.org (Postfix) with ESMTP id 385001F204; Sun, 6 Mar 2005 11:33:33 +0100 (CET) Subject: [patch 17/26] net/shaper: replace sleep_on() with wait_event() To: jgarzik@pobox.com Cc: netdev@oss.sgi.com, domen@coderock.org, nacc@us.ibm.com From: domen@coderock.org Date: Sun, 06 Mar 2005 11:33:32 +0100 Message-Id: <20050306103333.385001F204@trashy.coderock.org> X-Virus-Scanned: ClamAV 0.83/748/Fri Mar 4 14:19:11 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 2498 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: domen@coderock.org Precedence: bulk X-list: netdev Content-Length: 1191 Lines: 45 Use wait_event() instead of the deprecated sleep_on(). Move the in_interrupt() check outside loop, as I do not believe the process context should change once execution has begun. Patch is compile-tested. Signed-off-by: Nishanth Aravamudan Signed-off-by: Domen Puncer --- kj-domen/drivers/net/shaper.c | 12 ++++-------- 1 files changed, 4 insertions(+), 8 deletions(-) diff -puN drivers/net/shaper.c~sleep_on-drivers_net_shaper drivers/net/shaper.c --- kj/drivers/net/shaper.c~sleep_on-drivers_net_shaper 2005-03-05 16:11:49.000000000 +0100 +++ kj-domen/drivers/net/shaper.c 2005-03-05 16:11:49.000000000 +0100 @@ -83,6 +83,7 @@ #include #include #include +#include #include #include @@ -109,14 +110,9 @@ static int shaper_lock(struct shaper *sh /* * Lock in an interrupt must fail */ - while (test_and_set_bit(0, &sh->locked)) - { - if (!in_interrupt()) - sleep_on(&sh->wait_queue); - else - return 0; - - } + if (in_interrupt()) + return 0; + wait_event(sh->wait_queue, !test_and_set_bit(0, &sh->locked)); return 1; } _ From domen@coderock.org Sun Mar 6 02:34:10 2005 Received: with ECARTIS (v1.0.0; list netdev); Sun, 06 Mar 2005 02:34:17 -0800 (PST) Received: from trashy.coderock.org (postfix@coderock.org [193.77.147.115]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j26AY7ad020197 for ; Sun, 6 Mar 2005 02:34:08 -0800 Received: by trashy.coderock.org (Postfix, from userid 780) id 591A71F240; Sun, 6 Mar 2005 11:34:06 +0100 (CET) Received: from localhost (localhost [127.0.0.1]) by trashy.coderock.org (Postfix) with ESMTP id BA3881F202; Sun, 6 Mar 2005 11:34:04 +0100 (CET) Received: from localhost.localdomain (localhost [127.0.0.1]) by trashy.coderock.org (Postfix) with ESMTP id 11A721F208; Sun, 6 Mar 2005 11:33:44 +0100 (CET) Subject: [patch 20/26] drivers/net/arcnet/*: convert to pci_register_driver To: jgarzik@pobox.com Cc: netdev@oss.sgi.com, domen@coderock.org, c.lucas@ifrance.com From: domen@coderock.org Date: Sun, 06 Mar 2005 11:33:43 +0100 Message-Id: <20050306103344.11A721F208@trashy.coderock.org> X-Virus-Scanned: ClamAV 0.83/748/Fri Mar 4 14:19:11 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 2501 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: domen@coderock.org Precedence: bulk X-list: netdev Content-Length: 914 Lines: 25 convert from pci_module_init to pci_register_driver (from:http://kerneljanitors.org/TODO). Signed-off-by: Christophe Lucas Signed-off-by: Domen Puncer --- kj-domen/drivers/net/arcnet/com20020-pci.c | 2 +- 1 files changed, 1 insertion(+), 1 deletion(-) diff -puN drivers/net/arcnet/com20020-pci.c~pci_register_driver-drivers_net_arcnet drivers/net/arcnet/com20020-pci.c --- kj/drivers/net/arcnet/com20020-pci.c~pci_register_driver-drivers_net_arcnet 2005-03-05 16:12:35.000000000 +0100 +++ kj-domen/drivers/net/arcnet/com20020-pci.c 2005-03-05 16:12:35.000000000 +0100 @@ -177,7 +177,7 @@ static struct pci_driver com20020pci_dri static int __init com20020pci_init(void) { BUGLVL(D_NORMAL) printk(VERSION); - return pci_module_init(&com20020pci_driver); + return pci_register_driver(&com20020pci_driver); } static void __exit com20020pci_cleanup(void) _ From domen@coderock.org Sun Mar 6 02:34:17 2005 Received: with ECARTIS (v1.0.0; list netdev); Sun, 06 Mar 2005 02:34:22 -0800 (PST) Received: from trashy.coderock.org (postfix@coderock.org [193.77.147.115]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j26AYEb5020336 for ; Sun, 6 Mar 2005 02:34:14 -0800 Received: by trashy.coderock.org (Postfix, from userid 780) id 594861F23D; Sun, 6 Mar 2005 11:34:13 +0100 (CET) Received: from localhost (localhost [127.0.0.1]) by trashy.coderock.org (Postfix) with ESMTP id 764581F202; Sun, 6 Mar 2005 11:34:11 +0100 (CET) Received: from localhost.localdomain (localhost [127.0.0.1]) by trashy.coderock.org (Postfix) with ESMTP id 652131F23F; Sun, 6 Mar 2005 11:33:47 +0100 (CET) Subject: [patch 21/26] drivers/net/skfp/*: convert to pci_register_driver To: jgarzik@pobox.com Cc: netdev@oss.sgi.com, domen@coderock.org, c.lucas@ifrance.com From: domen@coderock.org Date: Sun, 06 Mar 2005 11:33:46 +0100 Message-Id: <20050306103347.652131F23F@trashy.coderock.org> X-Virus-Scanned: ClamAV 0.83/748/Fri Mar 4 14:19:11 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 2502 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: domen@coderock.org Precedence: bulk X-list: netdev Content-Length: 819 Lines: 25 convert from pci_module_init to pci_register_driver (from:http://kerneljanitors.org/TODO). Signed-off-by: Christophe Lucas Signed-off-by: Domen Puncer --- kj-domen/drivers/net/skfp/skfddi.c | 2 +- 1 files changed, 1 insertion(+), 1 deletion(-) diff -puN drivers/net/skfp/skfddi.c~pci_register_driver-drivers_net_skfp drivers/net/skfp/skfddi.c --- kj/drivers/net/skfp/skfddi.c~pci_register_driver-drivers_net_skfp 2005-03-05 16:12:37.000000000 +0100 +++ kj-domen/drivers/net/skfp/skfddi.c 2005-03-05 16:12:37.000000000 +0100 @@ -2281,7 +2281,7 @@ static struct pci_driver skfddi_pci_driv static int __init skfd_init(void) { - return pci_module_init(&skfddi_pci_driver); + return pci_register_driver(&skfddi_pci_driver); } static void __exit skfd_exit(void) _ From domen@coderock.org Sun Mar 6 02:34:31 2005 Received: with ECARTIS (v1.0.0; list netdev); Sun, 06 Mar 2005 02:34:40 -0800 (PST) Received: from trashy.coderock.org (postfix@coderock.org [193.77.147.115]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j26AYSMs020639 for ; Sun, 6 Mar 2005 02:34:28 -0800 Received: by trashy.coderock.org (Postfix, from userid 780) id 1E74E1F204; Sun, 6 Mar 2005 11:34:26 +0100 (CET) Received: from localhost (localhost [127.0.0.1]) by trashy.coderock.org (Postfix) with ESMTP id 519BF1F202; Sun, 6 Mar 2005 11:34:25 +0100 (CET) Received: from localhost.localdomain (localhost [127.0.0.1]) by trashy.coderock.org (Postfix) with ESMTP id A40731F1F0; Sun, 6 Mar 2005 11:33:50 +0100 (CET) Subject: [patch 22/26] drivers/net/tulip/*: convert to pci_register_driver To: jgarzik@pobox.com Cc: netdev@oss.sgi.com, domen@coderock.org, c.lucas@ifrance.com From: domen@coderock.org Date: Sun, 06 Mar 2005 11:33:50 +0100 Message-Id: <20050306103350.A40731F1F0@trashy.coderock.org> X-Virus-Scanned: ClamAV 0.83/748/Fri Mar 4 14:19:11 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 2504 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: domen@coderock.org Precedence: bulk X-list: netdev Content-Length: 3773 Lines: 90 convert from pci_module_init to pci_register_driver (from:http://kerneljanitors.org/TODO). Signed-off-by: Christophe Lucas Signed-off-by: Domen Puncer --- kj-domen/drivers/net/tulip/de2104x.c | 2 +- kj-domen/drivers/net/tulip/de4x5.c | 2 +- kj-domen/drivers/net/tulip/dmfe.c | 2 +- kj-domen/drivers/net/tulip/tulip_core.c | 2 +- kj-domen/drivers/net/tulip/winbond-840.c | 2 +- kj-domen/drivers/net/tulip/xircom_tulip_cb.c | 2 +- 6 files changed, 6 insertions(+), 6 deletions(-) diff -puN drivers/net/tulip/de2104x.c~pci_register_driver-drivers_net_tulip drivers/net/tulip/de2104x.c --- kj/drivers/net/tulip/de2104x.c~pci_register_driver-drivers_net_tulip 2005-03-05 16:12:39.000000000 +0100 +++ kj-domen/drivers/net/tulip/de2104x.c 2005-03-05 16:12:39.000000000 +0100 @@ -2175,7 +2175,7 @@ static int __init de_init (void) #ifdef MODULE printk("%s", version); #endif - return pci_module_init (&de_driver); + return pci_register_driver (&de_driver); } static void __exit de_exit (void) diff -puN drivers/net/tulip/de4x5.c~pci_register_driver-drivers_net_tulip drivers/net/tulip/de4x5.c --- kj/drivers/net/tulip/de4x5.c~pci_register_driver-drivers_net_tulip 2005-03-05 16:12:39.000000000 +0100 +++ kj-domen/drivers/net/tulip/de4x5.c 2005-03-05 16:12:39.000000000 +0100 @@ -5754,7 +5754,7 @@ static int __init de4x5_module_init (voi int err = 0; #ifdef CONFIG_PCI - err = pci_module_init (&de4x5_pci_driver); + err = pci_register_driver(&de4x5_pci_driver); #endif #ifdef CONFIG_EISA err |= eisa_driver_register (&de4x5_eisa_driver); diff -puN drivers/net/tulip/dmfe.c~pci_register_driver-drivers_net_tulip drivers/net/tulip/dmfe.c --- kj/drivers/net/tulip/dmfe.c~pci_register_driver-drivers_net_tulip 2005-03-05 16:12:39.000000000 +0100 +++ kj-domen/drivers/net/tulip/dmfe.c 2005-03-05 16:12:39.000000000 +0100 @@ -2042,7 +2042,7 @@ static int __init dmfe_init_module(void) if (HPNA_NoiseFloor > 15) HPNA_NoiseFloor = 0; - rc = pci_module_init(&dmfe_driver); + rc = pci_register_driver(&dmfe_driver); if (rc < 0) return rc; diff -puN drivers/net/tulip/tulip_core.c~pci_register_driver-drivers_net_tulip drivers/net/tulip/tulip_core.c --- kj/drivers/net/tulip/tulip_core.c~pci_register_driver-drivers_net_tulip 2005-03-05 16:12:39.000000000 +0100 +++ kj-domen/drivers/net/tulip/tulip_core.c 2005-03-05 16:12:39.000000000 +0100 @@ -1844,7 +1844,7 @@ static int __init tulip_init (void) tulip_max_interrupt_work = max_interrupt_work; /* probe for and init boards */ - return pci_module_init (&tulip_driver); + return pci_register_driver (&tulip_driver); } diff -puN drivers/net/tulip/winbond-840.c~pci_register_driver-drivers_net_tulip drivers/net/tulip/winbond-840.c --- kj/drivers/net/tulip/winbond-840.c~pci_register_driver-drivers_net_tulip 2005-03-05 16:12:39.000000000 +0100 +++ kj-domen/drivers/net/tulip/winbond-840.c 2005-03-05 16:12:39.000000000 +0100 @@ -1704,7 +1704,7 @@ static struct pci_driver w840_driver = { static int __init w840_init(void) { printk(version); - return pci_module_init(&w840_driver); + return pci_register_driver(&w840_driver); } static void __exit w840_exit(void) diff -puN drivers/net/tulip/xircom_tulip_cb.c~pci_register_driver-drivers_net_tulip drivers/net/tulip/xircom_tulip_cb.c --- kj/drivers/net/tulip/xircom_tulip_cb.c~pci_register_driver-drivers_net_tulip 2005-03-05 16:12:39.000000000 +0100 +++ kj-domen/drivers/net/tulip/xircom_tulip_cb.c 2005-03-05 16:12:39.000000000 +0100 @@ -1727,7 +1727,7 @@ static int __init xircom_init(void) #ifdef MODULE printk(version); #endif - return pci_module_init(&xircom_driver); + return pci_register_driver(&xircom_driver); } _ From domen@coderock.org Sun Mar 6 02:35:04 2005 Received: with ECARTIS (v1.0.0; list netdev); Sun, 06 Mar 2005 02:35:11 -0800 (PST) Received: from trashy.coderock.org (postfix@coderock.org [193.77.147.115]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j26AYxQB021239 for ; Sun, 6 Mar 2005 02:35:01 -0800 Received: by trashy.coderock.org (Postfix, from userid 780) id A93061F203; Sun, 6 Mar 2005 11:34:58 +0100 (CET) Received: from localhost (localhost [127.0.0.1]) by trashy.coderock.org (Postfix) with ESMTP id F37361E46E; Sun, 6 Mar 2005 11:34:56 +0100 (CET) Received: from localhost.localdomain (localhost [127.0.0.1]) by trashy.coderock.org (Postfix) with ESMTP id 7D2BE1F203; Sun, 6 Mar 2005 11:33:40 +0100 (CET) Subject: [patch 19/26] drivers/net/*: convert to pci_register_driver To: jgarzik@pobox.com Cc: netdev@oss.sgi.com, domen@coderock.org, c.lucas@ifrance.com From: domen@coderock.org Date: Sun, 06 Mar 2005 11:33:40 +0100 Message-Id: <20050306103340.7D2BE1F203@trashy.coderock.org> X-Virus-Scanned: ClamAV 0.83/748/Fri Mar 4 14:19:11 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 2508 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: domen@coderock.org Precedence: bulk X-list: netdev Content-Length: 18613 Lines: 454 convert from pci_module_init to pci_register_driver (from:http://kerneljanitors.org/TODO). Signed-off-by: Christophe Lucas Signed-off-by: Domen Puncer --- kj-domen/drivers/net/3c59x.c | 2 +- kj-domen/drivers/net/8139cp.c | 2 +- kj-domen/drivers/net/8139too.c | 2 +- kj-domen/drivers/net/acenic.c | 2 +- kj-domen/drivers/net/amd8111e.c | 2 +- kj-domen/drivers/net/b44.c | 2 +- kj-domen/drivers/net/defxx.c | 2 +- kj-domen/drivers/net/dl2k.c | 2 +- kj-domen/drivers/net/e100.c | 2 +- kj-domen/drivers/net/eepro100.c | 2 +- kj-domen/drivers/net/epic100.c | 2 +- kj-domen/drivers/net/fealnx.c | 2 +- kj-domen/drivers/net/forcedeth.c | 2 +- kj-domen/drivers/net/hp100.c | 2 +- kj-domen/drivers/net/ioc3-eth.c | 2 +- kj-domen/drivers/net/natsemi.c | 2 +- kj-domen/drivers/net/ne2k-pci.c | 2 +- kj-domen/drivers/net/ns83820.c | 2 +- kj-domen/drivers/net/pci-skeleton.c | 2 +- kj-domen/drivers/net/pcnet32.c | 2 +- kj-domen/drivers/net/r8169.c | 2 +- kj-domen/drivers/net/rrunner.c | 2 +- kj-domen/drivers/net/s2io.c | 2 +- kj-domen/drivers/net/saa9730.c | 2 +- kj-domen/drivers/net/sis900.c | 2 +- kj-domen/drivers/net/starfire.c | 2 +- kj-domen/drivers/net/sundance.c | 2 +- kj-domen/drivers/net/sungem.c | 2 +- kj-domen/drivers/net/tc35815.c | 2 +- kj-domen/drivers/net/tg3.c | 2 +- kj-domen/drivers/net/typhoon.c | 2 +- kj-domen/drivers/net/via-rhine.c | 2 +- kj-domen/drivers/net/via-velocity.c | 2 +- kj-domen/drivers/net/yellowfin.c | 2 +- 34 files changed, 34 insertions(+), 34 deletions(-) diff -puN drivers/net/3c59x.c~pci_register_driver-drivers_net drivers/net/3c59x.c --- kj/drivers/net/3c59x.c~pci_register_driver-drivers_net 2005-03-05 16:12:33.000000000 +0100 +++ kj-domen/drivers/net/3c59x.c 2005-03-05 16:12:33.000000000 +0100 @@ -3308,7 +3308,7 @@ static int __init vortex_init (void) { int pci_rc, eisa_rc; - pci_rc = pci_module_init(&vortex_driver); + pci_rc = pci_register_driver(&vortex_driver); eisa_rc = vortex_eisa_init(); if (pci_rc == 0) diff -puN drivers/net/8139cp.c~pci_register_driver-drivers_net drivers/net/8139cp.c --- kj/drivers/net/8139cp.c~pci_register_driver-drivers_net 2005-03-05 16:12:33.000000000 +0100 +++ kj-domen/drivers/net/8139cp.c 2005-03-05 16:12:33.000000000 +0100 @@ -1893,7 +1893,7 @@ static int __init cp_init (void) #ifdef MODULE printk("%s", version); #endif - return pci_module_init (&cp_driver); + return pci_register_driver (&cp_driver); } static void __exit cp_exit (void) diff -puN drivers/net/8139too.c~pci_register_driver-drivers_net drivers/net/8139too.c --- kj/drivers/net/8139too.c~pci_register_driver-drivers_net 2005-03-05 16:12:33.000000000 +0100 +++ kj-domen/drivers/net/8139too.c 2005-03-05 16:12:33.000000000 +0100 @@ -2655,7 +2655,7 @@ static int __init rtl8139_init_module (v printk (KERN_INFO RTL8139_DRIVER_NAME "\n"); #endif - return pci_module_init (&rtl8139_pci_driver); + return pci_register_driver (&rtl8139_pci_driver); } diff -puN drivers/net/acenic.c~pci_register_driver-drivers_net drivers/net/acenic.c --- kj/drivers/net/acenic.c~pci_register_driver-drivers_net 2005-03-05 16:12:33.000000000 +0100 +++ kj-domen/drivers/net/acenic.c 2005-03-05 16:12:33.000000000 +0100 @@ -729,7 +729,7 @@ static struct pci_driver acenic_pci_driv static int __init acenic_init(void) { - return pci_module_init(&acenic_pci_driver); + return pci_register_driver(&acenic_pci_driver); } static void __exit acenic_exit(void) diff -puN drivers/net/amd8111e.c~pci_register_driver-drivers_net drivers/net/amd8111e.c --- kj/drivers/net/amd8111e.c~pci_register_driver-drivers_net 2005-03-05 16:12:33.000000000 +0100 +++ kj-domen/drivers/net/amd8111e.c 2005-03-05 16:12:33.000000000 +0100 @@ -2152,7 +2152,7 @@ static struct pci_driver amd8111e_driver static int __init amd8111e_init(void) { - return pci_module_init(&amd8111e_driver); + return pci_register_driver(&amd8111e_driver); } static void __exit amd8111e_cleanup(void) diff -puN drivers/net/b44.c~pci_register_driver-drivers_net drivers/net/b44.c --- kj/drivers/net/b44.c~pci_register_driver-drivers_net 2005-03-05 16:12:33.000000000 +0100 +++ kj-domen/drivers/net/b44.c 2005-03-05 16:12:33.000000000 +0100 @@ -1959,7 +1959,7 @@ static struct pci_driver b44_driver = { static int __init b44_init(void) { - return pci_module_init(&b44_driver); + return pci_register_driver(&b44_driver); } static void __exit b44_cleanup(void) diff -puN drivers/net/defxx.c~pci_register_driver-drivers_net drivers/net/defxx.c --- kj/drivers/net/defxx.c~pci_register_driver-drivers_net 2005-03-05 16:12:33.000000000 +0100 +++ kj-domen/drivers/net/defxx.c 2005-03-05 16:12:33.000000000 +0100 @@ -3430,7 +3430,7 @@ static int __init dfx_init(void) { int rc_pci, rc_eisa; - rc_pci = pci_module_init(&dfx_driver); + rc_pci = pci_register_driver(&dfx_driver); if (rc_pci >= 0) dfx_have_pci = 1; rc_eisa = dfx_eisa_init(); diff -puN drivers/net/dl2k.c~pci_register_driver-drivers_net drivers/net/dl2k.c --- kj/drivers/net/dl2k.c~pci_register_driver-drivers_net 2005-03-05 16:12:33.000000000 +0100 +++ kj-domen/drivers/net/dl2k.c 2005-03-05 16:12:33.000000000 +0100 @@ -1848,7 +1848,7 @@ static struct pci_driver rio_driver = { static int __init rio_init (void) { - return pci_module_init (&rio_driver); + return pci_register_driver (&rio_driver); } static void __exit diff -puN drivers/net/e100.c~pci_register_driver-drivers_net drivers/net/e100.c --- kj/drivers/net/e100.c~pci_register_driver-drivers_net 2005-03-05 16:12:33.000000000 +0100 +++ kj-domen/drivers/net/e100.c 2005-03-05 16:12:33.000000000 +0100 @@ -2362,7 +2362,7 @@ static int __init e100_init_module(void) printk(KERN_INFO PFX "%s, %s\n", DRV_DESCRIPTION, DRV_VERSION); printk(KERN_INFO PFX "%s\n", DRV_COPYRIGHT); } - return pci_module_init(&e100_driver); + return pci_register_driver(&e100_driver); } static void __exit e100_cleanup_module(void) diff -puN drivers/net/eepro100.c~pci_register_driver-drivers_net drivers/net/eepro100.c --- kj/drivers/net/eepro100.c~pci_register_driver-drivers_net 2005-03-05 16:12:33.000000000 +0100 +++ kj-domen/drivers/net/eepro100.c 2005-03-05 16:12:33.000000000 +0100 @@ -2406,7 +2406,7 @@ static int __init eepro100_init_module(v #ifdef MODULE printk(version); #endif - return pci_module_init(&eepro100_driver); + return pci_register_driver(&eepro100_driver); } static void __exit eepro100_cleanup_module(void) diff -puN drivers/net/epic100.c~pci_register_driver-drivers_net drivers/net/epic100.c --- kj/drivers/net/epic100.c~pci_register_driver-drivers_net 2005-03-05 16:12:33.000000000 +0100 +++ kj-domen/drivers/net/epic100.c 2005-03-05 16:12:33.000000000 +0100 @@ -1673,7 +1673,7 @@ static int __init epic_init (void) version, version2, version3); #endif - return pci_module_init (&epic_driver); + return pci_register_driver (&epic_driver); } diff -puN drivers/net/fealnx.c~pci_register_driver-drivers_net drivers/net/fealnx.c --- kj/drivers/net/fealnx.c~pci_register_driver-drivers_net 2005-03-05 16:12:33.000000000 +0100 +++ kj-domen/drivers/net/fealnx.c 2005-03-05 16:12:33.000000000 +0100 @@ -2010,7 +2010,7 @@ static int __init fealnx_init(void) printk(version); #endif - return pci_module_init(&fealnx_driver); + return pci_register_driver(&fealnx_driver); } static void __exit fealnx_exit(void) diff -puN drivers/net/forcedeth.c~pci_register_driver-drivers_net drivers/net/forcedeth.c --- kj/drivers/net/forcedeth.c~pci_register_driver-drivers_net 2005-03-05 16:12:33.000000000 +0100 +++ kj-domen/drivers/net/forcedeth.c 2005-03-05 16:12:33.000000000 +0100 @@ -2211,7 +2211,7 @@ static struct pci_driver driver = { static int __init init_nic(void) { printk(KERN_INFO "forcedeth.c: Reverse Engineered nForce ethernet driver. Version %s.\n", FORCEDETH_VERSION); - return pci_module_init(&driver); + return pci_register_driver(&driver); } static void __exit exit_nic(void) diff -puN drivers/net/hp100.c~pci_register_driver-drivers_net drivers/net/hp100.c --- kj/drivers/net/hp100.c~pci_register_driver-drivers_net 2005-03-05 16:12:33.000000000 +0100 +++ kj-domen/drivers/net/hp100.c 2005-03-05 16:12:33.000000000 +0100 @@ -3075,7 +3075,7 @@ static int __init hp100_module_init(void goto out2; #endif #ifdef CONFIG_PCI - err = pci_module_init(&hp100_pci_driver); + err = pci_register_driver(&hp100_pci_driver); if (err && err != -ENODEV) goto out3; #endif diff -puN drivers/net/ioc3-eth.c~pci_register_driver-drivers_net drivers/net/ioc3-eth.c --- kj/drivers/net/ioc3-eth.c~pci_register_driver-drivers_net 2005-03-05 16:12:33.000000000 +0100 +++ kj-domen/drivers/net/ioc3-eth.c 2005-03-05 16:12:33.000000000 +0100 @@ -1299,7 +1299,7 @@ static struct pci_driver ioc3_driver = { static int __init ioc3_init_module(void) { - return pci_module_init(&ioc3_driver); + return pci_register_driver(&ioc3_driver); } static void __exit ioc3_cleanup_module(void) diff -puN drivers/net/natsemi.c~pci_register_driver-drivers_net drivers/net/natsemi.c --- kj/drivers/net/natsemi.c~pci_register_driver-drivers_net 2005-03-05 16:12:33.000000000 +0100 +++ kj-domen/drivers/net/natsemi.c 2005-03-05 16:12:33.000000000 +0100 @@ -3260,7 +3260,7 @@ static int __init natsemi_init_mod (void printk(version); #endif - return pci_module_init (&natsemi_driver); + return pci_register_driver (&natsemi_driver); } static void __exit natsemi_exit_mod (void) diff -puN drivers/net/ne2k-pci.c~pci_register_driver-drivers_net drivers/net/ne2k-pci.c --- kj/drivers/net/ne2k-pci.c~pci_register_driver-drivers_net 2005-03-05 16:12:33.000000000 +0100 +++ kj-domen/drivers/net/ne2k-pci.c 2005-03-05 16:12:33.000000000 +0100 @@ -699,7 +699,7 @@ static int __init ne2k_pci_init(void) #ifdef MODULE printk(version); #endif - return pci_module_init (&ne2k_driver); + return pci_register_driver (&ne2k_driver); } diff -puN drivers/net/ns83820.c~pci_register_driver-drivers_net drivers/net/ns83820.c --- kj/drivers/net/ns83820.c~pci_register_driver-drivers_net 2005-03-05 16:12:33.000000000 +0100 +++ kj-domen/drivers/net/ns83820.c 2005-03-05 16:12:33.000000000 +0100 @@ -2195,7 +2195,7 @@ static struct pci_driver driver = { static int __init ns83820_init(void) { printk(KERN_INFO "ns83820.c: National Semiconductor DP83820 10/100/1000 driver.\n"); - return pci_module_init(&driver); + return pci_register_driver(&driver); } static void __exit ns83820_exit(void) diff -puN drivers/net/pci-skeleton.c~pci_register_driver-drivers_net drivers/net/pci-skeleton.c --- kj/drivers/net/pci-skeleton.c~pci_register_driver-drivers_net 2005-03-05 16:12:33.000000000 +0100 +++ kj-domen/drivers/net/pci-skeleton.c 2005-03-05 16:12:33.000000000 +0100 @@ -1963,7 +1963,7 @@ static int __init netdrv_init_module (vo #ifdef MODULE printk(version); #endif - return pci_module_init (&netdrv_pci_driver); + return pci_register_driver (&netdrv_pci_driver); } diff -puN drivers/net/pcnet32.c~pci_register_driver-drivers_net drivers/net/pcnet32.c --- kj/drivers/net/pcnet32.c~pci_register_driver-drivers_net 2005-03-05 16:12:33.000000000 +0100 +++ kj-domen/drivers/net/pcnet32.c 2005-03-05 16:12:33.000000000 +0100 @@ -2304,7 +2304,7 @@ static int __init pcnet32_init_module(vo tx_start = tx_start_pt; /* find the PCI devices */ - if (!pci_module_init(&pcnet32_driver)) + if (!pci_register_driver(&pcnet32_driver)) pcnet32_have_pci = 1; /* should we find any remaining VLbus devices ? */ diff -puN drivers/net/r8169.c~pci_register_driver-drivers_net drivers/net/r8169.c --- kj/drivers/net/r8169.c~pci_register_driver-drivers_net 2005-03-05 16:12:33.000000000 +0100 +++ kj-domen/drivers/net/r8169.c 2005-03-05 16:12:33.000000000 +0100 @@ -2507,7 +2507,7 @@ static struct pci_driver rtl8169_pci_dri static int __init rtl8169_init_module(void) { - return pci_module_init(&rtl8169_pci_driver); + return pci_register_driver(&rtl8169_pci_driver); } static void __exit diff -puN drivers/net/rrunner.c~pci_register_driver-drivers_net drivers/net/rrunner.c --- kj/drivers/net/rrunner.c~pci_register_driver-drivers_net 2005-03-05 16:12:33.000000000 +0100 +++ kj-domen/drivers/net/rrunner.c 2005-03-05 16:12:33.000000000 +0100 @@ -1738,7 +1738,7 @@ static struct pci_driver rr_driver = { static int __init rr_init_module(void) { - return pci_module_init(&rr_driver); + return pci_register_driver(&rr_driver); } static void __exit rr_cleanup_module(void) diff -puN drivers/net/s2io.c~pci_register_driver-drivers_net drivers/net/s2io.c --- kj/drivers/net/s2io.c~pci_register_driver-drivers_net 2005-03-05 16:12:33.000000000 +0100 +++ kj-domen/drivers/net/s2io.c 2005-03-05 16:12:33.000000000 +0100 @@ -4954,7 +4954,7 @@ static void __devexit s2io_rem_nic(struc int __init s2io_starter(void) { - return pci_module_init(&s2io_driver); + return pci_register_driver(&s2io_driver); } /** diff -puN drivers/net/saa9730.c~pci_register_driver-drivers_net drivers/net/saa9730.c --- kj/drivers/net/saa9730.c~pci_register_driver-drivers_net 2005-03-05 16:12:33.000000000 +0100 +++ kj-domen/drivers/net/saa9730.c 2005-03-05 16:12:33.000000000 +0100 @@ -1168,7 +1168,7 @@ static struct pci_driver saa9730_driver static int __init saa9730_init(void) { - return pci_module_init(&saa9730_driver); + return pci_register_driver(&saa9730_driver); } static void __exit saa9730_cleanup(void) diff -puN drivers/net/sis900.c~pci_register_driver-drivers_net drivers/net/sis900.c --- kj/drivers/net/sis900.c~pci_register_driver-drivers_net 2005-03-05 16:12:33.000000000 +0100 +++ kj-domen/drivers/net/sis900.c 2005-03-05 16:12:33.000000000 +0100 @@ -2299,7 +2299,7 @@ static int __init sis900_init_module(voi printk(version); #endif - return pci_module_init(&sis900_pci_driver); + return pci_register_driver(&sis900_pci_driver); } static void __exit sis900_cleanup_module(void) diff -puN drivers/net/starfire.c~pci_register_driver-drivers_net drivers/net/starfire.c --- kj/drivers/net/starfire.c~pci_register_driver-drivers_net 2005-03-05 16:12:33.000000000 +0100 +++ kj-domen/drivers/net/starfire.c 2005-03-05 16:12:33.000000000 +0100 @@ -2196,7 +2196,7 @@ static int __init starfire_init (void) /* unconditionally disable hw cksums if firmware is not present */ enable_hw_cksum = 0; #endif /* not HAS_FIRMWARE */ - return pci_module_init (&starfire_driver); + return pci_register_driver (&starfire_driver); } diff -puN drivers/net/sundance.c~pci_register_driver-drivers_net drivers/net/sundance.c --- kj/drivers/net/sundance.c~pci_register_driver-drivers_net 2005-03-05 16:12:33.000000000 +0100 +++ kj-domen/drivers/net/sundance.c 2005-03-05 16:12:33.000000000 +0100 @@ -1770,7 +1770,7 @@ static int __init sundance_init(void) #ifdef MODULE printk(version); #endif - return pci_module_init(&sundance_driver); + return pci_register_driver(&sundance_driver); } static void __exit sundance_exit(void) diff -puN drivers/net/sungem.c~pci_register_driver-drivers_net drivers/net/sungem.c --- kj/drivers/net/sungem.c~pci_register_driver-drivers_net 2005-03-05 16:12:33.000000000 +0100 +++ kj-domen/drivers/net/sungem.c 2005-03-05 16:12:33.000000000 +0100 @@ -3062,7 +3062,7 @@ static struct pci_driver gem_driver = { static int __init gem_init(void) { - return pci_module_init(&gem_driver); + return pci_register_driver(&gem_driver); } static void __exit gem_cleanup(void) diff -puN drivers/net/tc35815.c~pci_register_driver-drivers_net drivers/net/tc35815.c --- kj/drivers/net/tc35815.c~pci_register_driver-drivers_net 2005-03-05 16:12:33.000000000 +0100 +++ kj-domen/drivers/net/tc35815.c 2005-03-05 16:12:33.000000000 +0100 @@ -1725,7 +1725,7 @@ static struct pci_driver tc35815_driver static int __init tc35815_init_module(void) { - return pci_module_init(&tc35815_driver); + return pci_register_driver(&tc35815_driver); } static void __exit tc35815_cleanup_module(void) diff -puN drivers/net/tg3.c~pci_register_driver-drivers_net drivers/net/tg3.c --- kj/drivers/net/tg3.c~pci_register_driver-drivers_net 2005-03-05 16:12:33.000000000 +0100 +++ kj-domen/drivers/net/tg3.c 2005-03-05 16:12:33.000000000 +0100 @@ -9037,7 +9037,7 @@ static struct pci_driver tg3_driver = { static int __init tg3_init(void) { - return pci_module_init(&tg3_driver); + return pci_register_driver(&tg3_driver); } static void __exit tg3_cleanup(void) diff -puN drivers/net/typhoon.c~pci_register_driver-drivers_net drivers/net/typhoon.c --- kj/drivers/net/typhoon.c~pci_register_driver-drivers_net 2005-03-05 16:12:33.000000000 +0100 +++ kj-domen/drivers/net/typhoon.c 2005-03-05 16:12:33.000000000 +0100 @@ -2580,7 +2580,7 @@ static struct pci_driver typhoon_driver static int __init typhoon_init(void) { - return pci_module_init(&typhoon_driver); + return pci_register_driver(&typhoon_driver); } static void __exit diff -puN drivers/net/via-rhine.c~pci_register_driver-drivers_net drivers/net/via-rhine.c --- kj/drivers/net/via-rhine.c~pci_register_driver-drivers_net 2005-03-05 16:12:33.000000000 +0100 +++ kj-domen/drivers/net/via-rhine.c 2005-03-05 16:12:33.000000000 +0100 @@ -2016,7 +2016,7 @@ static int __init rhine_init(void) #ifdef MODULE printk(version); #endif - return pci_module_init(&rhine_driver); + return pci_register_driver(&rhine_driver); } diff -puN drivers/net/via-velocity.c~pci_register_driver-drivers_net drivers/net/via-velocity.c --- kj/drivers/net/via-velocity.c~pci_register_driver-drivers_net 2005-03-05 16:12:33.000000000 +0100 +++ kj-domen/drivers/net/via-velocity.c 2005-03-05 16:12:33.000000000 +0100 @@ -2244,7 +2244,7 @@ static int __init velocity_init_module(v int ret; velocity_register_notifier(); - ret = pci_module_init(&velocity_driver); + ret = pci_register_driver(&velocity_driver); if (ret < 0) velocity_unregister_notifier(); return ret; diff -puN drivers/net/yellowfin.c~pci_register_driver-drivers_net drivers/net/yellowfin.c --- kj/drivers/net/yellowfin.c~pci_register_driver-drivers_net 2005-03-05 16:12:33.000000000 +0100 +++ kj-domen/drivers/net/yellowfin.c 2005-03-05 16:12:33.000000000 +0100 @@ -1474,7 +1474,7 @@ static int __init yellowfin_init (void) #ifdef MODULE printk(version); #endif - return pci_module_init (&yellowfin_driver); + return pci_register_driver (&yellowfin_driver); } _ From domen@coderock.org Sun Mar 6 02:34:33 2005 Received: with ECARTIS (v1.0.0; list netdev); Sun, 06 Mar 2005 02:34:41 -0800 (PST) Received: from trashy.coderock.org (postfix@coderock.org [193.77.147.115]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j26AYToL020670 for ; Sun, 6 Mar 2005 02:34:29 -0800 Received: by trashy.coderock.org (Postfix, from userid 780) id 49E1B1F202; Sun, 6 Mar 2005 11:34:28 +0100 (CET) Received: from localhost (localhost [127.0.0.1]) by trashy.coderock.org (Postfix) with ESMTP id 6C72B1F205; Sun, 6 Mar 2005 11:34:26 +0100 (CET) Received: from localhost.localdomain (localhost [127.0.0.1]) by trashy.coderock.org (Postfix) with ESMTP id 3D0BD1F204; Sun, 6 Mar 2005 11:33:54 +0100 (CET) Subject: [patch 23/26] drivers/net/wan/*: convert to pci_register_driver To: jgarzik@pobox.com Cc: netdev@oss.sgi.com, domen@coderock.org, c.lucas@ifrance.com From: domen@coderock.org Date: Sun, 06 Mar 2005 11:33:53 +0100 Message-Id: <20050306103354.3D0BD1F204@trashy.coderock.org> X-Virus-Scanned: ClamAV 0.83/748/Fri Mar 4 14:19:11 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 2505 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: domen@coderock.org Precedence: bulk X-list: netdev Content-Length: 3132 Lines: 77 convert from pci_module_init to pci_register_driver (from:http://kerneljanitors.org/TODO). Signed-off-by: Christophe Lucas Signed-off-by: Domen Puncer --- kj-domen/drivers/net/wan/dscc4.c | 2 +- kj-domen/drivers/net/wan/farsync.c | 2 +- kj-domen/drivers/net/wan/pc300_drv.c | 2 +- kj-domen/drivers/net/wan/pci200syn.c | 2 +- kj-domen/drivers/net/wan/wanxl.c | 2 +- 5 files changed, 5 insertions(+), 5 deletions(-) diff -puN drivers/net/wan/dscc4.c~pci_register_driver-drivers_net_wan drivers/net/wan/dscc4.c --- kj/drivers/net/wan/dscc4.c~pci_register_driver-drivers_net_wan 2005-03-05 16:12:41.000000000 +0100 +++ kj-domen/drivers/net/wan/dscc4.c 2005-03-05 16:12:41.000000000 +0100 @@ -2062,7 +2062,7 @@ static struct pci_driver dscc4_driver = static int __init dscc4_init_module(void) { - return pci_module_init(&dscc4_driver); + return pci_register_driver(&dscc4_driver); } static void __exit dscc4_cleanup_module(void) diff -puN drivers/net/wan/farsync.c~pci_register_driver-drivers_net_wan drivers/net/wan/farsync.c --- kj/drivers/net/wan/farsync.c~pci_register_driver-drivers_net_wan 2005-03-05 16:12:41.000000000 +0100 +++ kj-domen/drivers/net/wan/farsync.c 2005-03-05 16:12:41.000000000 +0100 @@ -2699,7 +2699,7 @@ fst_init(void) for (i = 0; i < FST_MAX_CARDS; i++) fst_card_array[i] = NULL; spin_lock_init(&fst_work_q_lock); - return pci_module_init(&fst_driver); + return pci_register_driver(&fst_driver); } static void __exit diff -puN drivers/net/wan/pc300_drv.c~pci_register_driver-drivers_net_wan drivers/net/wan/pc300_drv.c --- kj/drivers/net/wan/pc300_drv.c~pci_register_driver-drivers_net_wan 2005-03-05 16:12:41.000000000 +0100 +++ kj-domen/drivers/net/wan/pc300_drv.c 2005-03-05 16:12:41.000000000 +0100 @@ -3674,7 +3674,7 @@ static struct pci_driver cpc_driver = { static int __init cpc_init(void) { - return pci_module_init(&cpc_driver); + return pci_register_driver(&cpc_driver); } static void __exit cpc_cleanup_module(void) diff -puN drivers/net/wan/pci200syn.c~pci_register_driver-drivers_net_wan drivers/net/wan/pci200syn.c --- kj/drivers/net/wan/pci200syn.c~pci_register_driver-drivers_net_wan 2005-03-05 16:12:41.000000000 +0100 +++ kj-domen/drivers/net/wan/pci200syn.c 2005-03-05 16:12:41.000000000 +0100 @@ -468,7 +468,7 @@ static int __init pci200_init_module(voi printk(KERN_ERR "pci200syn: Invalid PCI clock frequency\n"); return -EINVAL; } - return pci_module_init(&pci200_pci_driver); + return pci_register_driver(&pci200_pci_driver); } diff -puN drivers/net/wan/wanxl.c~pci_register_driver-drivers_net_wan drivers/net/wan/wanxl.c --- kj/drivers/net/wan/wanxl.c~pci_register_driver-drivers_net_wan 2005-03-05 16:12:41.000000000 +0100 +++ kj-domen/drivers/net/wan/wanxl.c 2005-03-05 16:12:41.000000000 +0100 @@ -827,7 +827,7 @@ static int __init wanxl_init_module(void #ifdef MODULE printk(KERN_INFO "%s\n", version); #endif - return pci_module_init(&wanxl_pci_driver); + return pci_register_driver(&wanxl_pci_driver); } static void __exit wanxl_cleanup_module(void) _ From domen@coderock.org Sun Mar 6 02:34:26 2005 Received: with ECARTIS (v1.0.0; list netdev); Sun, 06 Mar 2005 02:34:31 -0800 (PST) Received: from trashy.coderock.org (postfix@coderock.org [193.77.147.115]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j26AYMe8020515 for ; Sun, 6 Mar 2005 02:34:22 -0800 Received: by trashy.coderock.org (Postfix, from userid 780) id 6271E1F23C; Sun, 6 Mar 2005 11:34:21 +0100 (CET) Received: from localhost (localhost [127.0.0.1]) by trashy.coderock.org (Postfix) with ESMTP id EB64F1F202; Sun, 6 Mar 2005 11:34:19 +0100 (CET) Received: from localhost.localdomain (localhost [127.0.0.1]) by trashy.coderock.org (Postfix) with ESMTP id 7A7A51F23C; Sun, 6 Mar 2005 11:33:57 +0100 (CET) Subject: [patch 24/26] drivers/net/wan/lmc/*: convert to pci_register_driver To: jgarzik@pobox.com Cc: netdev@oss.sgi.com, domen@coderock.org, c.lucas@ifrance.com From: domen@coderock.org Date: Sun, 06 Mar 2005 11:33:57 +0100 Message-Id: <20050306103357.7A7A51F23C@trashy.coderock.org> X-Virus-Scanned: ClamAV 0.83/748/Fri Mar 4 14:19:11 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 2503 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: domen@coderock.org Precedence: bulk X-list: netdev Content-Length: 839 Lines: 25 convert from pci_module_init to pci_register_driver (from:http://kerneljanitors.org/TODO). Signed-off-by: Christophe Lucas Signed-off-by: Domen Puncer --- kj-domen/drivers/net/wan/lmc/lmc_main.c | 2 +- 1 files changed, 1 insertion(+), 1 deletion(-) diff -puN drivers/net/wan/lmc/lmc_main.c~pci_register_driver-drivers_net_wan_lmc drivers/net/wan/lmc/lmc_main.c --- kj/drivers/net/wan/lmc/lmc_main.c~pci_register_driver-drivers_net_wan_lmc 2005-03-05 16:12:42.000000000 +0100 +++ kj-domen/drivers/net/wan/lmc/lmc_main.c 2005-03-05 16:12:42.000000000 +0100 @@ -1794,7 +1794,7 @@ static struct pci_driver lmc_driver = { static int __init init_lmc(void) { - return pci_module_init(&lmc_driver); + return pci_register_driver(&lmc_driver); } static void __exit exit_lmc(void) _ From domen@coderock.org Sun Mar 6 02:34:59 2005 Received: with ECARTIS (v1.0.0; list netdev); Sun, 06 Mar 2005 02:35:07 -0800 (PST) Received: from trashy.coderock.org (postfix@coderock.org [193.77.147.115]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j26AYtKD021184 for ; Sun, 6 Mar 2005 02:34:57 -0800 Received: by trashy.coderock.org (Postfix, from userid 780) id E6C661F205; Sun, 6 Mar 2005 11:34:54 +0100 (CET) Received: from localhost (localhost [127.0.0.1]) by trashy.coderock.org (Postfix) with ESMTP id 605DB1F1F0; Sun, 6 Mar 2005 11:34:53 +0100 (CET) Received: from localhost.localdomain (localhost [127.0.0.1]) by trashy.coderock.org (Postfix) with ESMTP id 12D9C1E46E; Sun, 6 Mar 2005 11:34:04 +0100 (CET) Subject: [patch 26/26] drivers/net/: Use the DMA_{64,32}BIT_MASK constants To: jgarzik@pobox.com Cc: netdev@oss.sgi.com, domen@coderock.org, tklauser@nuerscht.ch From: domen@coderock.org Date: Sun, 06 Mar 2005 11:34:03 +0100 Message-Id: <20050306103404.12D9C1E46E@trashy.coderock.org> X-Virus-Scanned: ClamAV 0.83/748/Fri Mar 4 14:19:11 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 2507 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: domen@coderock.org Precedence: bulk X-list: netdev Content-Length: 10948 Lines: 251 Use the DMA_{64,32}BIT_MASK constants from dma-mapping.h when calling pci_set_dma_mask() or pci_set_consistent_dma_mask() [Merged multiple patches, I can send split ones if desired -domen] Signed-off-by: Tobias Klauser Signed-off-by: Domen Puncer --- kj-domen/drivers/net/8139cp.c | 8 ++++---- kj-domen/drivers/net/acenic.c | 4 ++-- kj-domen/drivers/net/e100.c | 2 +- kj-domen/drivers/net/hp100.c | 2 +- kj-domen/drivers/net/ns83820.c | 4 ++-- kj-domen/drivers/net/s2io.c | 6 +++--- kj-domen/drivers/net/sk98lin/skge.c | 4 ++-- kj-domen/drivers/net/sungem.c | 4 ++-- kj-domen/drivers/net/tg3.c | 6 +++--- kj-domen/drivers/net/tlan.c | 2 +- kj-domen/drivers/net/tulip/dmfe.c | 2 +- kj-domen/drivers/net/tulip/winbond-840.c | 2 +- kj-domen/drivers/net/via-rhine.c | 2 +- kj-domen/drivers/net/wan/wanxl.c | 4 ++-- 14 files changed, 26 insertions(+), 26 deletions(-) diff -puN drivers/net/8139cp.c~dma_mask-drivers_net drivers/net/8139cp.c --- kj/drivers/net/8139cp.c~dma_mask-drivers_net 2005-03-05 16:13:20.000000000 +0100 +++ kj-domen/drivers/net/8139cp.c 2005-03-05 16:13:20.000000000 +0100 @@ -1702,19 +1702,19 @@ static int cp_init_one (struct pci_dev * /* Configure DMA attributes. */ if ((sizeof(dma_addr_t) > 4) && - !pci_set_consistent_dma_mask(pdev, 0xffffffffffffffffULL) && - !pci_set_dma_mask(pdev, 0xffffffffffffffffULL)) { + !pci_set_consistent_dma_mask(pdev, DMA_64BIT_MASK) && + !pci_set_dma_mask(pdev, DMA_64BIT_MASK)) { pci_using_dac = 1; } else { pci_using_dac = 0; - rc = pci_set_dma_mask(pdev, 0xffffffffULL); + rc = pci_set_dma_mask(pdev, DMA_32BIT_MASK); if (rc) { printk(KERN_ERR PFX "No usable DMA configuration, " "aborting.\n"); goto err_out_res; } - rc = pci_set_consistent_dma_mask(pdev, 0xffffffffULL); + rc = pci_set_consistent_dma_mask(pdev, DMA_32BIT_MASK); if (rc) { printk(KERN_ERR PFX "No usable consistent DMA configuration, " "aborting.\n"); diff -puN drivers/net/acenic.c~dma_mask-drivers_net drivers/net/acenic.c --- kj/drivers/net/acenic.c~dma_mask-drivers_net 2005-03-05 16:13:20.000000000 +0100 +++ kj-domen/drivers/net/acenic.c 2005-03-05 16:13:20.000000000 +0100 @@ -1167,9 +1167,9 @@ static int __devinit ace_init(struct net /* * Configure DMA attributes. */ - if (!pci_set_dma_mask(pdev, 0xffffffffffffffffULL)) { + if (!pci_set_dma_mask(pdev, DMA_64BIT_MASK)) { ap->pci_using_dac = 1; - } else if (!pci_set_dma_mask(pdev, 0xffffffffULL)) { + } else if (!pci_set_dma_mask(pdev, DMA_32BIT_MASK)) { ap->pci_using_dac = 0; } else { ecode = -ENODEV; diff -puN drivers/net/e100.c~dma_mask-drivers_net drivers/net/e100.c --- kj/drivers/net/e100.c~dma_mask-drivers_net 2005-03-05 16:13:20.000000000 +0100 +++ kj-domen/drivers/net/e100.c 2005-03-05 16:13:20.000000000 +0100 @@ -2201,7 +2201,7 @@ static int __devinit e100_probe(struct p goto err_out_disable_pdev; } - if((err = pci_set_dma_mask(pdev, 0xFFFFFFFFULL))) { + if((err = pci_set_dma_mask(pdev, DMA_32BIT_MASK))) { DPRINTK(PROBE, ERR, "No usable DMA configuration, aborting.\n"); goto err_out_free_res; } diff -puN drivers/net/hp100.c~dma_mask-drivers_net drivers/net/hp100.c --- kj/drivers/net/hp100.c~dma_mask-drivers_net 2005-03-05 16:13:20.000000000 +0100 +++ kj-domen/drivers/net/hp100.c 2005-03-05 16:13:20.000000000 +0100 @@ -562,7 +562,7 @@ static int __devinit hp100_probe1(struct * Also, we can have EISA Busmaster cards (not tested), * so beware !!! - Jean II */ if((bus == HP100_BUS_PCI) && - (pci_set_dma_mask(pci_dev, 0xffffffff))) { + (pci_set_dma_mask(pci_dev, DMA_32BIT_MASK))) { /* Gracefully fallback to shared memory */ goto busmasterfail; } diff -puN drivers/net/ns83820.c~dma_mask-drivers_net drivers/net/ns83820.c --- kj/drivers/net/ns83820.c~dma_mask-drivers_net 2005-03-05 16:13:20.000000000 +0100 +++ kj-domen/drivers/net/ns83820.c 2005-03-05 16:13:20.000000000 +0100 @@ -1841,9 +1841,9 @@ static int __devinit ns83820_init_one(st int using_dac = 0; /* See if we can set the dma mask early on; failure is fatal. */ - if (TRY_DAC && !pci_set_dma_mask(pci_dev, 0xffffffffffffffffULL)) { + if (TRY_DAC && !pci_set_dma_mask(pci_dev, DMA_64BIT_MASK)) { using_dac = 1; - } else if (!pci_set_dma_mask(pci_dev, 0xffffffff)) { + } else if (!pci_set_dma_mask(pci_dev, DMA_32BIT_MASK)) { using_dac = 0; } else { printk(KERN_WARNING "ns83820.c: pci_set_dma_mask failed!\n"); diff -puN drivers/net/s2io.c~dma_mask-drivers_net drivers/net/s2io.c --- kj/drivers/net/s2io.c~dma_mask-drivers_net 2005-03-05 16:13:20.000000000 +0100 +++ kj-domen/drivers/net/s2io.c 2005-03-05 16:13:20.000000000 +0100 @@ -4615,19 +4615,19 @@ s2io_init_nic(struct pci_dev *pdev, cons return ret; } - if (!pci_set_dma_mask(pdev, 0xffffffffffffffffULL)) { + if (!pci_set_dma_mask(pdev, DMA_64BIT_MASK)) { DBG_PRINT(INIT_DBG, "s2io_init_nic: Using 64bit DMA\n"); dma_flag = TRUE; if (pci_set_consistent_dma_mask - (pdev, 0xffffffffffffffffULL)) { + (pdev, DMA_64BIT_MASK)) { DBG_PRINT(ERR_DBG, "Unable to obtain 64bit DMA for \ consistent allocations\n"); pci_disable_device(pdev); return -ENOMEM; } - } else if (!pci_set_dma_mask(pdev, 0xffffffffUL)) { + } else if (!pci_set_dma_mask(pdev, DMA_32BIT_MASK)) { DBG_PRINT(INIT_DBG, "s2io_init_nic: Using 32bit DMA\n"); } else { pci_disable_device(pdev); diff -puN drivers/net/sk98lin/skge.c~dma_mask-drivers_net drivers/net/sk98lin/skge.c --- kj/drivers/net/sk98lin/skge.c~dma_mask-drivers_net 2005-03-05 16:13:20.000000000 +0100 +++ kj-domen/drivers/net/sk98lin/skge.c 2005-03-05 16:13:20.000000000 +0100 @@ -4912,8 +4912,8 @@ static int __devinit skge_probe_one(stru goto out; /* Configure DMA attributes. */ - if (pci_set_dma_mask(pdev, (u64) 0xffffffffffffffffULL) && - pci_set_dma_mask(pdev, (u64) 0xffffffff)) + if (pci_set_dma_mask(pdev, DMA_64BIT_MASK) && + pci_set_dma_mask(pdev, DMA_32BIT_MASK)) goto out_disable_device; diff -puN drivers/net/sungem.c~dma_mask-drivers_net drivers/net/sungem.c --- kj/drivers/net/sungem.c~dma_mask-drivers_net 2005-03-05 16:13:20.000000000 +0100 +++ kj-domen/drivers/net/sungem.c 2005-03-05 16:13:20.000000000 +0100 @@ -2816,10 +2816,10 @@ static int __devinit gem_init_one(struct */ if (pdev->vendor == PCI_VENDOR_ID_SUN && pdev->device == PCI_DEVICE_ID_SUN_GEM && - !pci_set_dma_mask(pdev, (u64) 0xffffffffffffffffULL)) { + !pci_set_dma_mask(pdev, DMA_64BIT_MASK)) { pci_using_dac = 1; } else { - err = pci_set_dma_mask(pdev, (u64) 0xffffffff); + err = pci_set_dma_mask(pdev, DMA_32BIT_MASK); if (err) { printk(KERN_ERR PFX "No usable DMA configuration, " "aborting.\n"); diff -puN drivers/net/tg3.c~dma_mask-drivers_net drivers/net/tg3.c --- kj/drivers/net/tg3.c~dma_mask-drivers_net 2005-03-05 16:13:20.000000000 +0100 +++ kj-domen/drivers/net/tg3.c 2005-03-05 16:13:20.000000000 +0100 @@ -8667,17 +8667,17 @@ static int __devinit tg3_init_one(struct } /* Configure DMA attributes. */ - err = pci_set_dma_mask(pdev, 0xffffffffffffffffULL); + err = pci_set_dma_mask(pdev, DMA_64BIT_MASK); if (!err) { pci_using_dac = 1; - err = pci_set_consistent_dma_mask(pdev, 0xffffffffffffffffULL); + err = pci_set_consistent_dma_mask(pdev, DMA_64BIT_MASK); if (err < 0) { printk(KERN_ERR PFX "Unable to obtain 64 bit DMA " "for consistent allocations\n"); goto err_out_free_res; } } else { - err = pci_set_dma_mask(pdev, 0xffffffffULL); + err = pci_set_dma_mask(pdev, DMA_32BIT_MASK); if (err) { printk(KERN_ERR PFX "No usable DMA configuration, " "aborting.\n"); diff -puN drivers/net/tlan.c~dma_mask-drivers_net drivers/net/tlan.c --- kj/drivers/net/tlan.c~dma_mask-drivers_net 2005-03-05 16:13:20.000000000 +0100 +++ kj-domen/drivers/net/tlan.c 2005-03-05 16:13:20.000000000 +0100 @@ -555,7 +555,7 @@ static int __devinit TLan_probe1(struct priv->adapter = &board_info[ent->driver_data]; - rc = pci_set_dma_mask(pdev, 0xFFFFFFFF); + rc = pci_set_dma_mask(pdev, DMA_32BIT_MASK); if (rc) { printk(KERN_ERR "TLAN: No suitable PCI mapping available.\n"); goto err_out_free_dev; diff -puN drivers/net/tulip/dmfe.c~dma_mask-drivers_net drivers/net/tulip/dmfe.c --- kj/drivers/net/tulip/dmfe.c~dma_mask-drivers_net 2005-03-05 16:13:20.000000000 +0100 +++ kj-domen/drivers/net/tulip/dmfe.c 2005-03-05 16:13:20.000000000 +0100 @@ -354,7 +354,7 @@ static int __devinit dmfe_init_one (stru SET_MODULE_OWNER(dev); SET_NETDEV_DEV(dev, &pdev->dev); - if (pci_set_dma_mask(pdev, 0xffffffff)) { + if (pci_set_dma_mask(pdev, DMA_32BIT_MASK)) { printk(KERN_WARNING DRV_NAME ": 32-bit PCI DMA not available.\n"); err = -ENODEV; goto err_out_free; diff -puN drivers/net/tulip/winbond-840.c~dma_mask-drivers_net drivers/net/tulip/winbond-840.c --- kj/drivers/net/tulip/winbond-840.c~dma_mask-drivers_net 2005-03-05 16:13:20.000000000 +0100 +++ kj-domen/drivers/net/tulip/winbond-840.c 2005-03-05 16:13:20.000000000 +0100 @@ -394,7 +394,7 @@ static int __devinit w840_probe1 (struct irq = pdev->irq; - if (pci_set_dma_mask(pdev,0xFFFFffff)) { + if (pci_set_dma_mask(pdev, DMA_32BIT_MASK)) { printk(KERN_WARNING "Winbond-840: Device %s disabled due to DMA limitations.\n", pci_name(pdev)); return -EIO; diff -puN drivers/net/via-rhine.c~dma_mask-drivers_net drivers/net/via-rhine.c --- kj/drivers/net/via-rhine.c~dma_mask-drivers_net 2005-03-05 16:13:20.000000000 +0100 +++ kj-domen/drivers/net/via-rhine.c 2005-03-05 16:13:20.000000000 +0100 @@ -740,7 +740,7 @@ static int __devinit rhine_init_one(stru goto err_out; /* this should always be supported */ - rc = pci_set_dma_mask(pdev, 0xffffffff); + rc = pci_set_dma_mask(pdev, DMA_32BIT_MASK); if (rc) { printk(KERN_ERR "32-bit PCI DMA addresses not supported by " "the card!?\n"); diff -puN drivers/net/wan/wanxl.c~dma_mask-drivers_net drivers/net/wan/wanxl.c --- kj/drivers/net/wan/wanxl.c~dma_mask-drivers_net 2005-03-05 16:13:20.000000000 +0100 +++ kj-domen/drivers/net/wan/wanxl.c 2005-03-05 16:13:20.000000000 +0100 @@ -630,8 +630,8 @@ static int __devinit wanxl_pci_init_one( /* FIXME when PCI/DMA subsystems are fixed. We set both dma_mask and consistent_dma_mask back to 32 bits to indicate the card can do 32-bit DMA addressing */ - if (pci_set_consistent_dma_mask(pdev, 0xFFFFFFFF) || - pci_set_dma_mask(pdev, 0xFFFFFFFF)) { + if (pci_set_consistent_dma_mask(pdev, DMA_32BIT_MASK) || + pci_set_dma_mask(pdev, DMA_32BIT_MASK)) { printk(KERN_ERR "wanXL: No usable DMA configuration\n"); wanxl_pci_remove_one(pdev); return -EIO; _ From domen@coderock.org Sun Mar 6 02:34:41 2005 Received: with ECARTIS (v1.0.0; list netdev); Sun, 06 Mar 2005 02:34:47 -0800 (PST) Received: from trashy.coderock.org (postfix@coderock.org [193.77.147.115]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j26AYZZY020804 for ; Sun, 6 Mar 2005 02:34:39 -0800 Received: by trashy.coderock.org (Postfix, from userid 780) id 82B8F1F23B; Sun, 6 Mar 2005 11:34:34 +0100 (CET) Received: from localhost (localhost [127.0.0.1]) by trashy.coderock.org (Postfix) with ESMTP id 540561F1F0; Sun, 6 Mar 2005 11:34:33 +0100 (CET) Received: from localhost.localdomain (localhost [127.0.0.1]) by trashy.coderock.org (Postfix) with ESMTP id B58BC1F23B; Sun, 6 Mar 2005 11:34:00 +0100 (CET) Subject: [patch 25/26] drivers/net/wireless/*: convert to pci_register_driver To: jgarzik@pobox.com Cc: netdev@oss.sgi.com, domen@coderock.org, c.lucas@ifrance.com From: domen@coderock.org Date: Sun, 06 Mar 2005 11:34:00 +0100 Message-Id: <20050306103400.B58BC1F23B@trashy.coderock.org> X-Virus-Scanned: ClamAV 0.83/748/Fri Mar 4 14:19:11 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 2506 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: domen@coderock.org Precedence: bulk X-list: netdev Content-Length: 2851 Lines: 64 convert from pci_module_init to pci_register_driver (from:http://kerneljanitors.org/TODO). Signed-off-by: Christophe Lucas Signed-off-by: Domen Puncer --- kj-domen/drivers/net/wireless/atmel_pci.c | 2 +- kj-domen/drivers/net/wireless/orinoco_pci.c | 2 +- kj-domen/drivers/net/wireless/orinoco_plx.c | 2 +- kj-domen/drivers/net/wireless/orinoco_tmd.c | 2 +- 4 files changed, 4 insertions(+), 4 deletions(-) diff -puN drivers/net/wireless/atmel_pci.c~pci_register_driver-drivers_net_wireless drivers/net/wireless/atmel_pci.c --- kj/drivers/net/wireless/atmel_pci.c~pci_register_driver-drivers_net_wireless 2005-03-05 16:12:43.000000000 +0100 +++ kj-domen/drivers/net/wireless/atmel_pci.c 2005-03-05 16:12:43.000000000 +0100 @@ -79,7 +79,7 @@ static void __devexit atmel_pci_remove(s static int __init atmel_init_module(void) { - return pci_module_init(&atmel_driver); + return pci_register_driver(&atmel_driver); } static void __exit atmel_cleanup_module(void) diff -puN drivers/net/wireless/orinoco_pci.c~pci_register_driver-drivers_net_wireless drivers/net/wireless/orinoco_pci.c --- kj/drivers/net/wireless/orinoco_pci.c~pci_register_driver-drivers_net_wireless 2005-03-05 16:12:43.000000000 +0100 +++ kj-domen/drivers/net/wireless/orinoco_pci.c 2005-03-05 16:12:43.000000000 +0100 @@ -393,7 +393,7 @@ MODULE_LICENSE("Dual MPL/GPL"); static int __init orinoco_pci_init(void) { printk(KERN_DEBUG "%s\n", version); - return pci_module_init(&orinoco_pci_driver); + return pci_register_driver(&orinoco_pci_driver); } static void __exit orinoco_pci_exit(void) diff -puN drivers/net/wireless/orinoco_plx.c~pci_register_driver-drivers_net_wireless drivers/net/wireless/orinoco_plx.c --- kj/drivers/net/wireless/orinoco_plx.c~pci_register_driver-drivers_net_wireless 2005-03-05 16:12:43.000000000 +0100 +++ kj-domen/drivers/net/wireless/orinoco_plx.c 2005-03-05 16:12:43.000000000 +0100 @@ -347,7 +347,7 @@ MODULE_LICENSE("Dual MPL/GPL"); static int __init orinoco_plx_init(void) { printk(KERN_DEBUG "%s\n", version); - return pci_module_init(&orinoco_plx_driver); + return pci_register_driver(&orinoco_plx_driver); } static void __exit orinoco_plx_exit(void) diff -puN drivers/net/wireless/orinoco_tmd.c~pci_register_driver-drivers_net_wireless drivers/net/wireless/orinoco_tmd.c --- kj/drivers/net/wireless/orinoco_tmd.c~pci_register_driver-drivers_net_wireless 2005-03-05 16:12:43.000000000 +0100 +++ kj-domen/drivers/net/wireless/orinoco_tmd.c 2005-03-05 16:12:43.000000000 +0100 @@ -213,7 +213,7 @@ MODULE_LICENSE("Dual MPL/GPL"); static int __init orinoco_tmd_init(void) { printk(KERN_DEBUG "%s\n", version); - return pci_module_init(&orinoco_tmd_driver); + return pci_register_driver(&orinoco_tmd_driver); } static void __exit orinoco_tmd_exit(void) _ From kaber@trash.net Sun Mar 6 02:54:46 2005 Received: with ECARTIS (v1.0.0; list netdev); Sun, 06 Mar 2005 02:54:51 -0800 (PST) Received: from kaber.coreworks.de ([62.206.217.67]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j26Asj2k002398 for ; Sun, 6 Mar 2005 02:54:46 -0800 Received: from localhost ([127.0.0.1]) by kaber.coreworks.de with esmtp (Exim 4.50) id 1D7tOh-0000yO-Ig; Sun, 06 Mar 2005 11:54:07 +0100 Message-ID: <422AE14F.6000805@trash.net> Date: Sun, 06 Mar 2005 11:54:07 +0100 From: Patrick McHardy User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.7.5) Gecko/20050106 Debian/1.7.5-1 X-Accept-Language: en MIME-Version: 1.0 To: Herbert Xu CC: davem@davemloft.net, netdev@oss.sgi.com Subject: Re: [PATCH 3/3 XFRM]: Fix invalid key for lookup of cached bundles References: In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV 0.83/748/Fri Mar 4 14:19:11 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 2509 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: kaber@trash.net Precedence: bulk X-list: netdev Content-Length: 915 Lines: 29 Herbert Xu wrote: > Patrick McHardy wrote: > >>@@ -97,6 +104,7 @@ >> err = xfrm_dst_lookup((struct xfrm_dst**)&rt, &fl_tunnel, AF_INET); >> if (err) >> goto error; >>+ rt->u.dst.flags |= DST_XFRM_TUNNEL; > > > This line doesn't look right. rt is an entry in the IPv4 routing > cache, right? If so why should its flags change when some bundle is > created? > > After all, it could also be used at the bottom of a transport mode bundle. Oops, that is correct of course. I wanted to kill the ugly int *is_tunnel argument to xfrm_bundle_ok() in my last patch, but I need to look for a different way. > Besides, I think IPv4 routing cache entry will never show up at the top of > a bundle anyway which means that this flags value will never be read in > the find_bundle function. At least that part was correct, __xfrm4_find_bundle() uses dst->path->flags in my patch. Thanks, Patrick From laforge@gnumonks.org Sun Mar 6 03:02:31 2005 Received: with ECARTIS (v1.0.0; list netdev); Sun, 06 Mar 2005 03:02:37 -0800 (PST) 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 j26B2UG9003493 for ; Sun, 6 Mar 2005 03:02:31 -0800 Received: from sunbeam.hmw-consulting.de ([83.236.178.203] helo=sunbeam.gnumonks.org) by ganesha.gnumonks.org with asmtp (TLS-1.0:RSA_AES_128_CBC_SHA:16) (Exim 4.34) id 1D7tWm-0001SP-7e; Sun, 06 Mar 2005 12:02:28 +0100 Received: from laforge by sunbeam.gnumonks.org with local (Exim 4.50) id 1D7tWj-0002tq-BW; Sun, 06 Mar 2005 12:02:25 +0100 Date: Sun, 6 Mar 2005 12:02:25 +0100 From: Harald Welte To: Quantum Scientific Cc: netdev@oss.sgi.com, usagi-users@linux-ipv6.org Subject: Re: support of IPv6 by NFS Message-ID: <20050306110225.GV30487@sunbeam.de.gnumonks.org> References: <42243F8D.5030302@bull.net> <200503010744.38339.Info@Quantum-Sci.com> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="5G50dybFf3pRZKd7" Content-Disposition: inline In-Reply-To: <200503010744.38339.Info@Quantum-Sci.com> User-Agent: Mutt/1.5.6+20040907i X-Virus-Scanned: ClamAV 0.83/748/Fri Mar 4 14:19:11 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 2510 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: laforge@gnumonks.org Precedence: bulk X-list: netdev Content-Length: 1607 Lines: 43 --5G50dybFf3pRZKd7 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Tue, Mar 01, 2005 at 07:44:37AM -0600, Quantum Scientific wrote: > Also one must become an ip6tables expert in order to have a reasonably se= cure=20 > firewall, because ip6tables and 6tables are dead, and Shorewall does not= =20 > support IPV6 security for some reason. Another deterrant. I have to oppose that statement. ip6tables is not dead, it's alive. We're even at the brink of submitting nf_conntrack, the new connection tracking engine that covers ipv4 and ipv6, to the mainline kernel. I'm running a number of ipv6 packet filters, and as of now we are not aware of any known issues or bugs in the current ip6tables code base. --=20 - Harald Welte http://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 "Privacy in residential applications is a desirable marketing option." (ETSI EN 300 175-7 Ch. A6) --5G50dybFf3pRZKd7 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) iD8DBQFCKuNBXaXGVTD0i/8RAjhEAKCZ4czid+6Xh03ONG47WLYgM8taCgCfWb14 SmFPlkNWE5FPhkbVRpgvGiw= =feZj -----END PGP SIGNATURE----- --5G50dybFf3pRZKd7-- From laforge@gnumonks.org Sun Mar 6 03:04:45 2005 Received: with ECARTIS (v1.0.0; list netdev); Sun, 06 Mar 2005 03:04:51 -0800 (PST) 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 j26B4j4V004091 for ; Sun, 6 Mar 2005 03:04:45 -0800 Received: from sunbeam.hmw-consulting.de ([83.236.178.203] helo=sunbeam.gnumonks.org) by ganesha.gnumonks.org with asmtp (TLS-1.0:RSA_AES_128_CBC_SHA:16) (Exim 4.34) id 1D7tYx-0001V4-UP; Sun, 06 Mar 2005 12:04:44 +0100 Received: from laforge by sunbeam.gnumonks.org with local (Exim 4.50) id 1D7tYw-0002uC-IL; Sun, 06 Mar 2005 12:04:42 +0100 Date: Sun, 6 Mar 2005 12:04:42 +0100 From: Harald Welte To: Jeroen Massar Cc: usagi-users@linux-ipv6.org, netdev@oss.sgi.com Subject: Re: (usagi-users 03222) Re: support of IPv6 by NFS Message-ID: <20050306110442.GW30487@sunbeam.de.gnumonks.org> References: <42243F8D.5030302@bull.net> <200503010744.38339.Info@Quantum-Sci.com> <1109689712.17484.6.camel@firenze.zurich.ibm.com> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="4SRTEifjNkXp0Rce" Content-Disposition: inline In-Reply-To: <1109689712.17484.6.camel@firenze.zurich.ibm.com> User-Agent: Mutt/1.5.6+20040907i X-Virus-Scanned: ClamAV 0.83/748/Fri Mar 4 14:19:11 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 2511 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: laforge@gnumonks.org Precedence: bulk X-list: netdev Content-Length: 1762 Lines: 51 --4SRTEifjNkXp0Rce Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Tue, Mar 01, 2005 at 04:08:32PM +0100, Jeroen Massar wrote: > >My experience is that IPV6 is extremely difficult to figure out how > >to set up securely, for the time being, due to lack of > >connection-sharing. >=20 > NAT is not a firewall. Get that into your brain. oh, that was what he meant. I wasn't familiar with the term 'connection sharing'. =20 I've stated numerous time that IPv6<->IPv6 NAT will only end up in netfilter/iptables over my dead body. IPv4<->IPv6 NAT-PT is a different issue, obviously. btw, the IETF BEHAVE group is actually demanding that a NAT device does not NAT ipv6 traffic!! > And indeed there is no Linux firewalling code yet, in the mainstream > that can do connection tracking.=20 still, ip6_conntrack is shipped by commercial distributions like SuSE... --=20 - Harald Welte http://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 "Privacy in residential applications is a desirable marketing option." (ETSI EN 300 175-7 Ch. A6) --4SRTEifjNkXp0Rce 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) iD8DBQFCKuPKXaXGVTD0i/8RAkXpAKCVDXCOwmaEXub7uAgGPhlIWkdrnQCfUj+A Cc7FKaz+Qj06mRT1hWs/mD0= =J3xa -----END PGP SIGNATURE----- --4SRTEifjNkXp0Rce-- From laforge@gnumonks.org Sun Mar 6 03:21:11 2005 Received: with ECARTIS (v1.0.0; list netdev); Sun, 06 Mar 2005 03:21:17 -0800 (PST) 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 j26BLAv5005414 for ; Sun, 6 Mar 2005 03:21:11 -0800 Received: from sunbeam.hmw-consulting.de ([83.236.178.203] helo=sunbeam.gnumonks.org) by ganesha.gnumonks.org with asmtp (TLS-1.0:RSA_AES_128_CBC_SHA:16) (Exim 4.34) id 1D7tor-0001yS-4T; Sun, 06 Mar 2005 12:21:09 +0100 Received: from laforge by sunbeam.gnumonks.org with local (Exim 4.50) id 1D7tom-0002wJ-NM; Sun, 06 Mar 2005 12:21:04 +0100 Date: Sun, 6 Mar 2005 12:21:04 +0100 From: Harald Welte To: jamal Cc: patrick mcmanus , "netdev@oss.sgi.com" Subject: Re: Intel and TOE in the news Message-ID: <20050306112104.GX30487@sunbeam.de.gnumonks.org> References: <20050221132844.GU31837@postel.suug.ch> <1108994621.1089.158.camel@jzny.localdomain> <20050221141714.GV31837@postel.suug.ch> <1108996313.1090.178.camel@jzny.localdomain> <20050221153443.GW31837@postel.suug.ch> <1109000925.1076.3.camel@jzny.localdomain> <20050221164006.GY31837@postel.suug.ch> <1109005385.1074.68.camel@jzny.localdomain> <1109016740.25476.2.camel@mcmanus.datapower.com> <1109020362.1077.134.camel@jzny.localdomain> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="Tcb1KvpfnM4LxW2s" Content-Disposition: inline In-Reply-To: <1109020362.1077.134.camel@jzny.localdomain> User-Agent: Mutt/1.5.6+20040907i X-Virus-Scanned: ClamAV 0.83/748/Fri Mar 4 14:19:11 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 2512 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: laforge@gnumonks.org Precedence: bulk X-list: netdev Content-Length: 1596 Lines: 45 --Tcb1KvpfnM4LxW2s Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Sorry for my late catch-up, didn't have time to read all mailinglists for some time. On Mon, Feb 21, 2005 at 04:12:42PM -0500, jamal wrote: > CSA is essentially a direct link to the Northbridge System Controller > (or MCH); there are some speacilized motherboards that have this > feature.=20 It's actually becoming more and more common. But there are only MCH's with a single CSA port, so you will never benefit from it if you need more than one port. Like everything intel seems to do (i've read about everything I could find about their recent press releases), they concentrate on the end host case, not packet forwarding :( --=20 - Harald Welte http://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 "Privacy in residential applications is a desirable marketing option." (ETSI EN 300 175-7 Ch. A6) --Tcb1KvpfnM4LxW2s 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) iD8DBQFCKuegXaXGVTD0i/8RAudCAJ936W3c7kJ93mPm0BKKff4V4fVadgCeLMXF d+dSLUpr2RP2bI+X+ibTVh8= =nTDy -----END PGP SIGNATURE----- --Tcb1KvpfnM4LxW2s-- From kaber@trash.net Sun Mar 6 04:35:02 2005 Received: with ECARTIS (v1.0.0; list netdev); Sun, 06 Mar 2005 04:35:07 -0800 (PST) Received: from kaber.coreworks.de ([62.206.217.67]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j26CZ1fk019373 for ; Sun, 6 Mar 2005 04:35:02 -0800 Received: from localhost ([127.0.0.1]) by kaber.coreworks.de with esmtp (Exim 4.50) id 1D7uxk-0003V5-Mo; Sun, 06 Mar 2005 13:34:24 +0100 Message-ID: <422AF8D0.3010905@trash.net> Date: Sun, 06 Mar 2005 13:34:24 +0100 From: Patrick McHardy User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.7.5) Gecko/20050106 Debian/1.7.5-1 X-Accept-Language: en MIME-Version: 1.0 To: Herbert Xu CC: davem@davemloft.net, netdev@oss.sgi.com Subject: Re: [PATCH 3/3 XFRM]: Fix invalid key for lookup of cached bundles References: In-Reply-To: Content-Type: multipart/mixed; boundary="------------040302070806030602040204" X-Virus-Scanned: ClamAV 0.83/748/Fri Mar 4 14:19:11 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 2513 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: kaber@trash.net Precedence: bulk X-list: netdev Content-Length: 2776 Lines: 80 This is a multi-part message in MIME format. --------------040302070806030602040204 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Herbert Xu wrote: > Patrick McHardy wrote: > >>@@ -97,6 +104,7 @@ >> err = xfrm_dst_lookup((struct xfrm_dst**)&rt, &fl_tunnel, AF_INET); >> if (err) >> goto error; >>+ rt->u.dst.flags |= DST_XFRM_TUNNEL; > > > This line doesn't look right. rt is an entry in the IPv4 routing > cache, right? If so why should its flags change when some bundle is > created? How about this one ? It keeps the DST_XFRM_TUNNEL flag and sets it on the first xfrm_dst in a bundle. I know it doesn't really belong there, but the alternatives are walking through the bundle an additional time or having xfrm_bundle_ok() return if it is a tunnel-mode bundle, but in that case we can only compare tos etc after the call to xfrm_bundle_ok(), which is rather expensive. I also moved the oif check to the checks performed only in transport mode, this reduces the number of cached bundles in tunnel mode to one per src/dst if the selector isn't narrower than that. Signed-off-by: Patrick McHardy --------------040302070806030602040204 Content-Type: text/plain; name="x" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="x" ===== include/net/dst.h 1.26 vs edited ===== --- 1.26/include/net/dst.h 2005-02-15 23:23:10 +01:00 +++ edited/include/net/dst.h 2005-03-06 12:50:54 +01:00 @@ -48,6 +48,7 @@ #define DST_NOXFRM 2 #define DST_NOPOLICY 4 #define DST_NOHASH 8 +#define DST_XFRM_TUNNEL 16 unsigned long lastuse; unsigned long expires; ===== net/ipv4/xfrm4_policy.c 1.15 vs edited ===== --- 1.15/net/ipv4/xfrm4_policy.c 2005-03-05 01:58:41 +01:00 +++ edited/net/ipv4/xfrm4_policy.c 2005-03-06 13:26:44 +01:00 @@ -30,9 +30,15 @@ read_lock_bh(&policy->lock); for (dst = policy->bundles; dst; dst = dst->next) { struct xfrm_dst *xdst = (struct xfrm_dst*)dst; - if (xdst->u.rt.fl.oif == fl->oif && /*XXX*/ - xdst->u.rt.fl.fl4_dst == fl->fl4_dst && + if (xdst->u.rt.fl.fl4_dst == fl->fl4_dst && xdst->u.rt.fl.fl4_src == fl->fl4_src && + (dst->flags & DST_XFRM_TUNNEL || + (!(xdst->u.rt.fl.fl4_tos ^ fl->fl4_tos) & + (IPTOS_RT_MASK|RTO_ONLINK) && +#ifdef CONFIG_IP_ROUTE_FWMARK + xdst->u.rt.fl.fl4_fwmark == fl->fl4_fwmark && +#endif + xdst->u.rt.fl.oif == fl->oif)) && xfrm_bundle_ok(xdst, fl, AF_INET)) { dst_clone(dst); break; @@ -97,6 +103,7 @@ err = xfrm_dst_lookup((struct xfrm_dst**)&rt, &fl_tunnel, AF_INET); if (err) goto error; + dst->flags |= DST_XFRM_TUNNEL; } else { dst_hold(&rt->u.dst); } --------------040302070806030602040204-- From webmaster@rapidforum.com Sun Mar 6 06:10:22 2005 Received: with ECARTIS (v1.0.0; list netdev); Sun, 06 Mar 2005 06:10:26 -0800 (PST) Received: from rapidforum.com (www.rapidforum.com [80.237.244.2]) by oss.sgi.com (8.13.0/8.13.0) with SMTP id j26EAL8H026554 for ; Sun, 6 Mar 2005 06:10:22 -0800 Received: (qmail 17396 invoked by uid 1004); 6 Mar 2005 14:10:21 -0000 Received: from p3ee0455d.dip0.t-ipconnect.de (HELO ?62.224.69.93?) (62.224.69.93) by www.rapidforum.com with SMTP; 6 Mar 2005 14:10:21 -0000 Message-ID: <422B0F46.5030404@rapidforum.com> Date: Sun, 06 Mar 2005 15:10:14 +0100 From: Christian Schmid User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.8a3) Gecko/20040817 X-Accept-Language: de, en MIME-Version: 1.0 To: netdev@oss.sgi.com Subject: Idea Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV 0.83/748/Fri Mar 4 14:19:11 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 2514 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: webmaster@rapidforum.com Precedence: bulk X-list: netdev Content-Length: 250 Lines: 7 Hello. OK its not easy to change the dynamic allocation to static one. But when did it change? I have noticed than in 2.6.10-rc2 the memory was linear and it was listed in /proc/slabinfo and in 2.6.10 it wasnt anymore. Did it change there? Chris From jeroen@unfix.org Sun Mar 6 07:40:23 2005 Received: with ECARTIS (v1.0.0; list netdev); Sun, 06 Mar 2005 07:40:27 -0800 (PST) Received: from purgatory.unfix.org (postfix@213-136-24-43.adsl.bit.nl [213.136.24.43]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j26FeMB0000744 for ; Sun, 6 Mar 2005 07:40:22 -0800 Received: from firenze.zurich.ibm.com (pat.zurich.ibm.com [195.176.20.45]) (using SSLv3 with cipher RC4-MD5 (128/128 bits)) (No client certificate requested) by purgatory.unfix.org (Postfix) with ESMTP id D6F278009; Sun, 6 Mar 2005 16:40:15 +0100 (CET) Subject: Re: (usagi-users 03249) Re: support of IPv6 by NFS From: Jeroen Massar To: usagi-users@linux-ipv6.org Cc: netdev@oss.sgi.com In-Reply-To: <20050306110442.GW30487@sunbeam.de.gnumonks.org> References: <42243F8D.5030302@bull.net> <200503010744.38339.Info@Quantum-Sci.com> <1109689712.17484.6.camel@firenze.zurich.ibm.com> <20050306110442.GW30487@sunbeam.de.gnumonks.org> Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="=-pC7KyXYB44plltdaJnHI" Organization: Unfix Date: Sun, 06 Mar 2005 16:40:13 +0100 Message-Id: <1110123613.24625.48.camel@firenze.zurich.ibm.com> Mime-Version: 1.0 X-Mailer: Evolution 2.1.5 (2.1.5-1) X-Virus-Scanned: ClamAV 0.83/748/Fri Mar 4 14:19:11 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 2515 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: jeroen@unfix.org Precedence: bulk X-list: netdev Content-Length: 2107 Lines: 63 --=-pC7KyXYB44plltdaJnHI Content-Type: text/plain Content-Transfer-Encoding: quoted-printable On Sun, 2005-03-06 at 12:04 +0100, Harald Welte wrote: >On Tue, Mar 01, 2005 at 04:08:32PM +0100, Jeroen Massar wrote: >> >My experience is that IPV6 is extremely difficult to figure out how >> >to set up securely, for the time being, due to lack of >> >connection-sharing. >>=20 >> NAT is not a firewall. Get that into your brain. > >oh, that was what he meant. I wasn't familiar with the term 'connection >sharing'. =20 That is the Windows term for it ;) >I've stated numerous time that IPv6<->IPv6 NAT will only end up in >netfilter/iptables over my dead body. Hmmm..... then I guess that I'll have to kill you at some point ;) But I'll leave it to printing out a kernel source and throwing it on your casket in a year or 100 or so. >IPv4<->IPv6 NAT-PT is a different issue, obviously. > >btw, the IETF BEHAVE group is actually demanding that a NAT device does >not NAT ipv6 traffic!! Doing the NAT as in the 'connection sharing', or better said, "rewriting source/dest addresses and packet contents" is evil. But the other method for which we are going to use a "translation of addresses", but on both sides will be very interesting and will cost you your dead body . >> And indeed there is no Linux firewalling code yet, in the mainstream >> that can do connection tracking.=20 > >still, ip6_conntrack is shipped by commercial distributions like SuSE... There is nothing wrong with connection tracking as that can be used for checking if a certain packet is allowed to come back into the firewall or not, one of the basic principles of stateful firewalling Greets, Jeroen --=-pC7KyXYB44plltdaJnHI Content-Type: application/pgp-signature; name=signature.asc Content-Description: This is a digitally signed message part -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.0 (GNU/Linux) Comment: Jeroen Massar / http://unfix.org/~jeroen/ iD8DBQBCKyRdKaooUjM+fCMRAqe5AJ9+1cBxSpto5AE7bXgfEquJS6mIjwCfTqO8 6eMpfRgnxJbSqfGc18SQyYk= =uq9A -----END PGP SIGNATURE----- --=-pC7KyXYB44plltdaJnHI-- From yoshfuji@linux-ipv6.org Sun Mar 6 08:39:14 2005 Received: with ECARTIS (v1.0.0; list netdev); Sun, 06 Mar 2005 08:39:20 -0800 (PST) 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 j26GdDsx008817 for ; Sun, 6 Mar 2005 08:39:14 -0800 Received: from localhost (localhost [127.0.0.1]) by yue.st-paulia.net (Postfix) with ESMTP id 390AF33CC2; Mon, 7 Mar 2005 01:40:46 +0900 (JST) Date: Mon, 07 Mar 2005 01:40:40 +0900 (JST) Message-Id: <20050307.014040.48352532.yoshfuji@linux-ipv6.org> To: domen@coderock.org Cc: jgarzik@pobox.com, netdev@oss.sgi.com, janitor@sternwelten.at, yoshfuji@linux-ipv6.org Subject: Re: [patch 01/26] list_for_each: net-ipv6-ip6_fib.c From: YOSHIFUJI Hideaki / =?iso-2022-jp?B?GyRCNUhGIzFRTEAbKEI=?= In-Reply-To: <20050306103238.86F181E46E@trashy.coderock.org> References: <20050306103238.86F181E46E@trashy.coderock.org> Organization: USAGI Project X-URL: http://www.yoshifuji.org/%7Ehideaki/ X-Fingerprint: 9022 65EB 1ECF 3AD1 0BDF 80D8 4807 F894 E062 0EEA X-PGP-Key-URL: http://www.yoshifuji.org/%7Ehideaki/hideaki@yoshifuji.org.asc X-Face: "5$Al-.M>NJ%a'@hhZdQm:."qn~PA^gq4o*>iCFToq*bAi#4FRtx}enhuQKz7fNqQz\BYU] $~O_5m-9'}MIs`XGwIEscw;e5b>n"B_?j/AkL~i/MEaZBLP X-Mailer: Mew version 2.2 on Emacs 20.7 / Mule 4.1 (AOI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV 0.83/748/Fri Mar 4 14:19:11 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 2516 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: yoshfuji@linux-ipv6.org Precedence: bulk X-list: netdev Content-Length: 711 Lines: 20 In article <20050306103238.86F181E46E@trashy.coderock.org> (at Sun, 06 Mar 2005 11:32:38 +0100), domen@coderock.org says: > s/for/list_for_each/ > Compile tested. : > +++ kj-domen/net/ipv6/ip6_fib.c 2005-03-05 16:09:09.000000000 +0100 > @@ -99,7 +99,7 @@ struct fib6_walker_t fib6_walker_list = > .next = &fib6_walker_list, > }; > > -#define FOR_WALKERS(w) for ((w)=fib6_walker_list.next; (w) != &fib6_walker_list; (w)=(w)->next) > +#define FOR_WALKERS(w) list_for_each((w), &fib6_walker_list) > > static __inline__ u32 fib6_new_sernum(void) > { Please don't. fib6_walker_list is not for fib6_walker_t but list_head. (Or, why don't you convert fib6_walker_t to use list_head families?) --yoshfuji From dhatarattha@route-add.net Sun Mar 6 08:59:25 2005 Received: with ECARTIS (v1.0.0; list netdev); Sun, 06 Mar 2005 08:59:30 -0800 (PST) Received: from dns2.EurNetCity.NET (dns2.EURNetCity.net [80.68.196.9]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j26GxMIS010741 for ; Sun, 6 Mar 2005 08:59:24 -0800 Received: from brillante.route-add.net (postfix@brillante.route-add.net [80.68.194.26] (may be forged)) by dns2.EurNetCity.NET (8.11.6p2-20030924/8.11.6) with SMTP id j26GieV06621; Sun, 6 Mar 2005 17:44:46 +0100 Received: from sole.localdomain (sole.localdomain [192.168.1.6]) by brillante.route-add.net (Postfix) with ESMTP id 12CA21031; Sun, 6 Mar 2005 17:59:04 +0100 (CET) Received: from [127.0.0.1] (ambapali@localhost [127.0.0.1]) by sole.localdomain (8.12.10+Sun/8.12.10) with ESMTP id j26Gwf9Q000735; Sun, 6 Mar 2005 17:58:44 +0100 (CET) Message-ID: <422B36BE.90809@route-add.net> Date: Sun, 06 Mar 2005 17:58:38 +0100 From: Alessandro Selli User-Agent: Mozilla/5.0 (X11; U; SunOS sun4u; en-US; rv:1.7.5) Gecko/20050105 X-Accept-Language: en-us, en MIME-Version: 1.0 To: netdev@oss.sgi.com Cc: linux-kernel@vger.kernel.org Subject: Vanilla kernel >=2.4.28-rc2 incompatibility with ADSL modem Dlink DSL-G300+ Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-EurNetCity-MailScanner-Information: Please contact the ISP for more information X-EurNetCity-MailScanner: Found to be clean X-MailScanner-From: dhatarattha@route-add.net X-Virus-Scanned: ClamAV 0.83/748/Fri Mar 4 14:19:11 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 2517 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: dhatarattha@route-add.net Precedence: bulk X-list: netdev Content-Length: 2299 Lines: 46 Hello, I found a problem having to to with the plain vanilla 2.4.28-rc2 and 2.4.29 kernels when I try to use a Dlink DSL-300G+ ethernet ADSL modem on a SS5 machine. The domain "route-add.net" is running on a Sun SparcStation 5 machine, equipped with a Micro-SPARCII, 85 MHz processor. This machine has beeing running the domain (web, smtp, ssh, imap, telnet, gopher, finger, auth/ident, dns) for a year. The machine has two "le" (10 base T) ethernet ports, one is connected to the ADSL modem, the other to the LAN. The OS is Debian stable (Woody, 3.0). The kernel is a plain vanilla one, downloaded from ftp.it.kernel.org/pub/linux/kernel/v2.4 with no patches applied to it. The problem showed up after updating to kernel 2.4.28: the ADSL connection would never outlive the fifteenth minute. Even though the modem still sensed the ADSL carrier and could be reached into its web-based internal control panel over the same ethernet connection that served the data exchanged with the ISP, after fifteen minutes it could first reach the ISP gateway the connection failed and no packets could be neither sent nor received with any host outside the LAN. The connection would be available again after a period varying from a few minutes to several hours, three quarters of an hour on the average. A script that was let running from Jannuary 18th to February 3rd (data from Jannuary 29th was lost) produced the following data: http://route-add.net/ping-noping.txt ("riuscito" = success, "fallito" = failed) http://route-add.net/ping-noping_18012005-28012005.txt http://route-add.net/ping-noping_07012005-17012005.txt ("persa" = lost [connection], "tornata" = [coonection is] back) I tried changing the wiring, I swapped the ethernet ports the LAN and ADSL modem where connected to, I swapped the modem with an identical one from a colleague of mine, I upgraded to kernel 2.4.29 all to no avail. I then tried the 2.4.28-rc{1,2,3} kernels, and I found the 2.4.28-rc1 not to exhibit the problem, that manifests itself on the 2.4.28-rc{2,3} kernels. The problem is sparc-specific, a PC with the very same configuration (Debian stable, plain vanilla kernels etc.) did not suffer any connection drops. -- Alessandro Selli Tel: 340.839.73.05 http://alessandro.route-add.net From zdenek@rcn.com Sun Mar 6 09:04:46 2005 Received: with ECARTIS (v1.0.0; list netdev); Sun, 06 Mar 2005 09:04:50 -0800 (PST) Received: from smtp02.mrf.mail.rcn.net (smtp02.mrf.mail.rcn.net [207.172.4.61]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j26H4kRA011543 for ; Sun, 6 Mar 2005 09:04:46 -0800 Received: from 209-150-50-115.c3-0.nwt-ubr3.sbo-nwt.ma.cable.rcn.com ([209.150.50.115] helo=funex) by smtp02.mrf.mail.rcn.net with smtp (Exim 3.35 #7) id 1D7zBN-0004hX-00; Sun, 06 Mar 2005 12:04:45 -0500 X-Sender: zdenek@pop.rcn.com X-Mailer: QUALCOMM Windows Eudora Pro Version 4.0 Date: Sun, 06 Mar 2005 12:01:50 -0500 To: Martin Mares From: Zdenek Radouch Subject: Re: Do you know the TCP stack? (127.x.x.x routing) Cc: netdev@oss.sgi.com, linux-net@vger.kernel.org In-Reply-To: <20050306095642.GA1352@ucw.cz> References: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Message-Id: X-Virus-Scanned: ClamAV 0.83/748/Fri Mar 4 14:19:11 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 2518 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: zdenek@rcn.com Precedence: bulk X-list: netdev Content-Length: 2633 Lines: 83 At 10:56 AM 3/6/05 +0100, Martin Mares wrote: >Hello! > >> Unfortunately, this does not work with the Linux stack, because the >> 127 net is treated (for good reasons I suppose) as a special net. > >Is it really? Well, at least it looks that way to me: svfx:~# netstat -rn Kernel IP routing table Destination Gateway Genmask Flags MSS Window irtt Iface 192.168.13.0 0.0.0.0 255.255.255.0 U 0 0 0 eth0 0.0.0.0 192.168.13.254 0.0.0.0 UG 0 0 0 eth0 svfx:~# Hmmm, I don't seem to have the loopback interface... This table implies that 127.0.0.1 should go out via eth0 to a gateway 192.168.13.264. That's hard to believe. svfx:~# ping -c 1 127.0.0.1 PING 127.0.0.1 (127.0.0.1): 56 data bytes 64 bytes from 127.0.0.1: icmp_seq=0 ttl=255 time=0.2 ms --- 127.0.0.1 ping statistics --- 1 packets transmitted, 1 packets received, 0% packet loss round-trip min/avg/max = 0.2/0.2/0.2 ms Looks like I do have the loopback interface after all. It just seems to be hidden, i.e., it actually is treated in a special way by one of the entities I am perusing. Let's see if I can delete the route anyway. svfx:~# route del -net 127.0.0.0 netmask 255.0.0.0 dev lo SIOCDELRT: No such process svfx:~# Looks like I can't, maybe it's not there? >I've just tried > > ip addr del 127.0.0.1/8 dev lo > ip addr add 127.0.0.1/24 dev lo > >and `ping 127.1.2.3' is then happily sent along the default route. > I don't have iproute around, so I will install it now. ... and try your method: svfx:~# ip addr del 127.0.0.1/8 dev lo Cannot send dump request: Connection refused svfx:~# That actually looks like some compatibility issue if I had to guess. I never used the iproute tools, so I'll ignore that for now. [Anyone knows what this means?] Something just crossed my mind - maybe the 127 processing and/or the netstat/route/iproute tools are in flux, i.e., being changed in a major way to the point that I really need to pay attention to what kernel I am running. I have done the above tests on my "stable" machine, which runs 2.2.20 (common Debian stable release). I'll go and retest everything on my embedded target which is running the 2.4.25 kernel. Can someone comment on the stability of the tools in question or any implementation changes in this area that would explain the above behavior? But point well taken, perhaps I just need a bit more imagination when I'm testing these things. It may very well work, it just may look like it does not. Thanks for the suggestions! Regards, -Zdenek From alex@pilosoft.com Sun Mar 6 09:22:52 2005 Received: with ECARTIS (v1.0.0; list netdev); Sun, 06 Mar 2005 09:22:55 -0800 (PST) Received: from bawx.pilosoft.com ([66.250.55.42]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j26HMpJW013014 for ; Sun, 6 Mar 2005 09:22:51 -0800 Received: from bawx.pilosoft.com (localhost [127.0.0.1]) by bawx.pilosoft.com (8.12.5/8.12.5) with ESMTP id j26HC5iP012233; Sun, 6 Mar 2005 12:12:05 -0500 Received: from localhost (alex@localhost) by bawx.pilosoft.com (8.12.5/8.12.5/Submit) with ESMTP id j26HC5qr012229; Sun, 6 Mar 2005 12:12:05 -0500 X-Authentication-Warning: bawx.pilosoft.com: alex owned process doing -bs Date: Sun, 6 Mar 2005 12:12:05 -0500 (EST) From: alex@pilosoft.com To: Zdenek Radouch cc: Martin Mares , , Subject: Re: Do you know the TCP stack? (127.x.x.x routing) In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Virus-Scanned: ClamAV 0.83/748/Fri Mar 4 14:19:11 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 2519 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: alex@pilosoft.com Precedence: bulk X-list: netdev Content-Length: 1212 Lines: 28 On Sun, 6 Mar 2005, Zdenek Radouch wrote: > seems to be hidden, i.e., it actually is treated in a special way > by one of the entities I am perusing. > Let's see if I can delete the route anyway. > > svfx:~# route del -net 127.0.0.0 netmask 255.0.0.0 dev lo > SIOCDELRT: No such process > svfx:~# > > That actually looks like some compatibility issue if I had to guess. > I never used the iproute tools, so I'll ignore that for now. > [Anyone knows what this means?] > and/or the netstat/route/iproute tools are in flux, i.e., being changed > in a major way to the point that I really need to pay attention to what > kernel I am running. I have done the above tests on my "stable" > machine, which runs 2.2.20 (common Debian stable release). I'll go and > retest everything on my embedded target which is running the 2.4.25 > kernel. That's like testing on a yugo. Make sure after upgrading to 2.4, you also get iproute2 toolchain. > Can someone comment on the stability of the tools in question > or any implementation changes in this area that would explain > the above behavior? On 2.4.27, once you delete 127.x address from the interface, traffic will go as expected to another route... From tgraf@suug.ch Sun Mar 6 09:31:33 2005 Received: with ECARTIS (v1.0.0; list netdev); Sun, 06 Mar 2005 09:31:37 -0800 (PST) Received: from b.mx.projectdream.org (eth0-0.arisu.projectdream.org [194.158.4.191]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j26HVWCt013897 for ; Sun, 6 Mar 2005 09:31:33 -0800 Received: from postel.suug.ch (postel.suug.ch [195.134.158.23]) (using TLSv1 with cipher EDH-RSA-DES-CBC3-SHA (168/168 bits)) (No client certificate requested) by b.mx.projectdream.org (Postfix) with ESMTP id 3E9578A; Sun, 6 Mar 2005 18:31:05 +0100 (CET) Received: by postel.suug.ch (Postfix, from userid 10001) id 6439A1C0EA; Sun, 6 Mar 2005 18:31:45 +0100 (CET) Date: Sun, 6 Mar 2005 18:31:45 +0100 From: Thomas Graf To: Zdenek Radouch Cc: Martin Mares , netdev@oss.sgi.com, linux-net@vger.kernel.org Subject: Re: Do you know the TCP stack? (127.x.x.x routing) Message-ID: <20050306173145.GQ31837@postel.suug.ch> References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-Virus-Scanned: ClamAV 0.83/748/Fri Mar 4 14:19:11 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 2520 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: tgraf@suug.ch Precedence: bulk X-list: netdev Content-Length: 726 Lines: 16 > Hmmm, I don't seem to have the loopback interface... > This table implies that 127.0.0.1 should go out via eth0 > to a gateway 192.168.13.264. That's hard to believe. It's in the local table tgr:axs ~ ip route list dev lo table local broadcast 127.255.255.255 proto kernel scope link src 127.0.0.1 broadcast 127.0.0.0 proto kernel scope link src 127.0.0.1 local 127.0.0.1 proto kernel scope host src 127.0.0.1 local 127.0.0.0/8 proto kernel scope host src 127.0.0.1 tgr:axs ~ ip route del 127.0.0.1 dev lo table local tgr:axs ~ ip route del 127.0.0.0/8 dev lo table local tgr:axs ~ ip route get 127.0.0.1 127.0.0.1 via 192.168.23.13 dev eth0 src 192.168.23.1 cache mtu 1500 advmss 1460 metric10 64 From kaber@trash.net Sun Mar 6 09:56:36 2005 Received: with ECARTIS (v1.0.0; list netdev); Sun, 06 Mar 2005 09:56:41 -0800 (PST) Received: from kaber.coreworks.de ([62.206.217.67]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j26HuZSo015715 for ; Sun, 6 Mar 2005 09:56:36 -0800 Received: from localhost ([127.0.0.1]) by kaber.coreworks.de with esmtp (Exim 4.50) id 1D7zyw-00063C-16; Sun, 06 Mar 2005 18:55:58 +0100 Date: Sun, 6 Mar 2005 18:55:58 +0100 (CET) From: Patrick McHardy X-X-Sender: kaber@kaber.coreworks.de To: Herbert Xu cc: davem@davemloft.net, netdev@oss.sgi.com Subject: Re: [PATCH 3/3 XFRM]: Fix invalid key for lookup of cached bundles In-Reply-To: <422AF8D0.3010905@trash.net> Message-ID: References: <422AF8D0.3010905@trash.net> MIME-Version: 1.0 Content-Type: MULTIPART/MIXED; BOUNDARY="279739137-1600102413-1110131758=:23235" X-Virus-Scanned: ClamAV 0.83/748/Fri Mar 4 14:19:11 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 2521 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: kaber@trash.net Precedence: bulk X-list: netdev Content-Length: 3270 Lines: 61 This message is in MIME format. The first part should be readable text, while the remaining parts are likely unreadable without MIME-aware tools. --279739137-1600102413-1110131758=:23235 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Fixed a missing pair of parentheses - ! has precedence over bitwise AND. On Sun, 6 Mar 2005, Patrick McHardy wrote: > How about this one ? It keeps the DST_XFRM_TUNNEL flag and sets it on > the first xfrm_dst in a bundle. I know it doesn't really belong there, > but the alternatives are walking through the bundle an additional time > or having xfrm_bundle_ok() return if it is a tunnel-mode bundle, but in > that case we can only compare tos etc after the call to > xfrm_bundle_ok(), which is rather expensive. I also moved the oif check > to the checks performed only in transport mode, this reduces the number > of cached bundles in tunnel mode to one per src/dst if the selector > isn't narrower than that. > > Signed-off-by: Patrick McHardy --279739137-1600102413-1110131758=:23235 Content-Type: TEXT/PLAIN; charset=US-ASCII; name=x Content-Transfer-Encoding: BASE64 Content-ID: Content-Description: Content-Disposition: attachment; filename=x PT09PT0gaW5jbHVkZS9uZXQvZHN0LmggMS4yNiB2cyBlZGl0ZWQgPT09PT0N Ci0tLSAxLjI2L2luY2x1ZGUvbmV0L2RzdC5oCTIwMDUtMDItMTUgMjM6MjM6 MTAgKzAxOjAwDQorKysgZWRpdGVkL2luY2x1ZGUvbmV0L2RzdC5oCTIwMDUt MDMtMDYgMTI6NTA6NTQgKzAxOjAwDQpAQCAtNDgsNiArNDgsNyBAQA0KICNk ZWZpbmUgRFNUX05PWEZSTQkJMg0KICNkZWZpbmUgRFNUX05PUE9MSUNZCQk0 DQogI2RlZmluZSBEU1RfTk9IQVNICQk4DQorI2RlZmluZSBEU1RfWEZSTV9U VU5ORUwJCTE2DQogCXVuc2lnbmVkIGxvbmcJCWxhc3R1c2U7DQogCXVuc2ln bmVkIGxvbmcJCWV4cGlyZXM7DQogDQo9PT09PSBuZXQvaXB2NC94ZnJtNF9w b2xpY3kuYyAxLjE1IHZzIGVkaXRlZCA9PT09PQ0KLS0tIDEuMTUvbmV0L2lw djQveGZybTRfcG9saWN5LmMJMjAwNS0wMy0wNSAwMTo1ODo0MSArMDE6MDAN CisrKyBlZGl0ZWQvbmV0L2lwdjQveGZybTRfcG9saWN5LmMJMjAwNS0wMy0w NiAxODo0OToyMyArMDE6MDANCkBAIC0zMCw5ICszMCwxNSBAQA0KIAlyZWFk X2xvY2tfYmgoJnBvbGljeS0+bG9jayk7DQogCWZvciAoZHN0ID0gcG9saWN5 LT5idW5kbGVzOyBkc3Q7IGRzdCA9IGRzdC0+bmV4dCkgew0KIAkJc3RydWN0 IHhmcm1fZHN0ICp4ZHN0ID0gKHN0cnVjdCB4ZnJtX2RzdCopZHN0Ow0KLQkJ aWYgKHhkc3QtPnUucnQuZmwub2lmID09IGZsLT5vaWYgJiYJLypYWFgqLw0K LQkJICAgIHhkc3QtPnUucnQuZmwuZmw0X2RzdCA9PSBmbC0+Zmw0X2RzdCAm Jg0KKwkJaWYgKHhkc3QtPnUucnQuZmwuZmw0X2RzdCA9PSBmbC0+Zmw0X2Rz dCAmJg0KIAkgICAgCSAgICB4ZHN0LT51LnJ0LmZsLmZsNF9zcmMgPT0gZmwt PmZsNF9zcmMgJiYNCisJCSAgICAoZHN0LT5mbGFncyAmIERTVF9YRlJNX1RV Tk5FTCB8fA0KKwkJICAgICAoISgoeGRzdC0+dS5ydC5mbC5mbDRfdG9zIF4g ZmwtPmZsNF90b3MpICYgDQorCQkgICAgICAgICAgICAgICAgICAgKElQVE9T X1JUX01BU0t8UlRPX09OTElOSykpICYmDQorI2lmZGVmIENPTkZJR19JUF9S T1VURV9GV01BUksNCisJCSAgICAgIHhkc3QtPnUucnQuZmwuZmw0X2Z3bWFy ayA9PSBmbC0+Zmw0X2Z3bWFyayAmJg0KKyNlbmRpZg0KKwkJICAgICAgeGRz dC0+dS5ydC5mbC5vaWYgPT0gZmwtPm9pZikpICYmDQogCQkgICAgeGZybV9i dW5kbGVfb2soeGRzdCwgZmwsIEFGX0lORVQpKSB7DQogCQkJZHN0X2Nsb25l KGRzdCk7DQogCQkJYnJlYWs7DQpAQCAtOTcsNiArMTAzLDcgQEANCiAJCWVy ciA9IHhmcm1fZHN0X2xvb2t1cCgoc3RydWN0IHhmcm1fZHN0KiopJnJ0LCAm ZmxfdHVubmVsLCBBRl9JTkVUKTsNCiAJCWlmIChlcnIpDQogCQkJZ290byBl cnJvcjsNCisJCWRzdC0+ZmxhZ3MgfD0gRFNUX1hGUk1fVFVOTkVMOw0KIAl9 IGVsc2Ugew0KIAkJZHN0X2hvbGQoJnJ0LT51LmRzdCk7DQogCX0NCg== --279739137-1600102413-1110131758=:23235-- From jgarzik@pobox.com Sun Mar 6 10:01:20 2005 Received: with ECARTIS (v1.0.0; list netdev); Sun, 06 Mar 2005 10:01:25 -0800 (PST) Received: from parcelfarce.linux.theplanet.co.uk (IDENT:93@parcelfarce.linux.theplanet.co.uk [195.92.249.252]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j26I1Jjr016609 for ; Sun, 6 Mar 2005 10:01:20 -0800 Received: from [69.134.152.124] (helo=[10.10.10.88]) by parcelfarce.linux.theplanet.co.uk with asmtp (TLSv1:AES256-SHA:256) (Exim 4.33) id 1D8044-0001xn-IM; Sun, 06 Mar 2005 18:01:16 +0000 Message-ID: <422B4552.5000504@pobox.com> Date: Sun, 06 Mar 2005 13:00:50 -0500 From: Jeff Garzik User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.3) Gecko/20040922 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Herbert Xu CC: Adrian Bunk , akpm@osdl.org, davem@davemloft.net, netdev@oss.sgi.com Subject: Re: [patch 1/3] fix buggy IEEE80211_CRYPT_* selects References: <200503041237.j24Cbb69026470@shell0.pdx.osdl.net> <42289BDF.1080409@pobox.com> <20050304221014.GJ3327@stusta.de> <4228DF62.4000205@pobox.com> <20050304230718.GL3327@stusta.de> <20050306090936.GA31890@gondor.apana.org.au> In-Reply-To: <20050306090936.GA31890@gondor.apana.org.au> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV 0.83/748/Fri Mar 4 14:19:11 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 2522 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: jgarzik@pobox.com Precedence: bulk X-list: netdev Content-Length: 614 Lines: 21 Herbert Xu wrote: > On Sat, Mar 05, 2005 at 12:07:18AM +0100, Adrian Bunk wrote: > >>The way kconfig currently works, you have to ensure that the >>dependencies of what you select are fulfilled. > > > Yes Adrian's right. In the other places where we select CRYPTO > symbols, we always make sure that CRYPTO itself is selected. See > net/ipv4/Kconfig for example. I would rather fix Kconfig. If we are selecting X_1 -- which explicitly depends on X -- when Kconfig should automatically select X. It is completely illogical to duplicate a dependency chain each time you wish to select a symbol. Jeff From baruch@ev-en.org Sun Mar 6 11:06:33 2005 Received: with ECARTIS (v1.0.0; list netdev); Sun, 06 Mar 2005 11:06:37 -0800 (PST) Received: from galon.ev-en.org (rrcs-24-123-59-149.central.biz.rr.com [24.123.59.149]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j26J6W09020916 for ; Sun, 6 Mar 2005 11:06:32 -0800 Received: by galon.ev-en.org (Postfix, from userid 105) id C89C211A6C5; Sun, 6 Mar 2005 21:06:26 +0200 (IST) Received: from [10.220.3.66] (hamilton.nuim.ie [149.157.192.252]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by galon.ev-en.org (Postfix) with ESMTP id EA3A711A696; Sun, 6 Mar 2005 21:06:24 +0200 (IST) Message-ID: <422B54AF.4060401@ev-en.org> Date: Sun, 06 Mar 2005 19:06:23 +0000 From: Baruch Even User-Agent: Debian Thunderbird 1.0 (X11/20050116) X-Accept-Language: en-us, en MIME-Version: 1.0 To: netdev@oss.sgi.com Subject: ixgb problem X-Enigmail-Version: 0.90.0.0 X-Enigmail-Supports: pgp-inline, pgp-mime Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV 0.83/748/Fri Mar 4 14:19:11 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 2523 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: baruch@ev-en.org Precedence: bulk X-list: netdev Content-Length: 994 Lines: 27 Hello, I'm trying to get a high-speed network setup and am having a problem with the ixgb driver. The setup I'm running is: s1 -- Cisco -- s2 s1 and s2 are identical Dell 1U servers, each having two onboard 1GbE cards, one extra 1GbE card and one 10GbE card. The GbE are all copper and the 10GbE is fiber. The Cisco is a 6503 with a 10GbE line card with two ports. It also has a 1GbE line card used to connect to another set of machines. I'm running a test of iperf with a window of 16MB, at first the performance shows about 3.2Gbps rate (which sucks by itself, but that's another issue), after some time, usually 30-40 seconds, but sometimes 100 seconds, the performance drops to almost nothing, about 60Kbps. I have tried it on 2.6.11 and 2.6.11 with the latest snapshot of Jeff Garzik net drivers (2.6.11-netdev1.patch.bz2). It happens in both of them. I have tried with an without NAPI, there is no noticeable change. Is it known? What can I do to help debug this? Baruch From bunk@stusta.de Sun Mar 6 11:10:38 2005 Received: with ECARTIS (v1.0.0; list netdev); Sun, 06 Mar 2005 11:10:45 -0800 (PST) Received: from mailout.stusta.mhn.de (mailout.stusta.mhn.de [141.84.69.5]) by oss.sgi.com (8.13.0/8.13.0) with SMTP id j26JAbrX021632 for ; Sun, 6 Mar 2005 11:10:37 -0800 Received: (qmail 3457 invoked from network); 6 Mar 2005 19:10:31 -0000 Received: from r063144.stusta.swh.mhn.de (10.150.63.144) by mailout.stusta.mhn.de with SMTP; 6 Mar 2005 19:10:31 -0000 Received: by r063144.stusta.swh.mhn.de (Postfix, from userid 1000) id 323D9BBFC0; Sun, 6 Mar 2005 20:10:30 +0100 (CET) Date: Sun, 6 Mar 2005 20:10:29 +0100 From: Adrian Bunk To: Jeff Garzik Cc: Herbert Xu , akpm@osdl.org, davem@davemloft.net, netdev@oss.sgi.com Subject: Re: [patch 1/3] fix buggy IEEE80211_CRYPT_* selects Message-ID: <20050306191029.GM5070@stusta.de> References: <200503041237.j24Cbb69026470@shell0.pdx.osdl.net> <42289BDF.1080409@pobox.com> <20050304221014.GJ3327@stusta.de> <4228DF62.4000205@pobox.com> <20050304230718.GL3327@stusta.de> <20050306090936.GA31890@gondor.apana.org.au> <422B4552.5000504@pobox.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <422B4552.5000504@pobox.com> User-Agent: Mutt/1.5.6+20040907i X-Virus-Scanned: ClamAV 0.83/748/Fri Mar 4 14:19:11 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 2524 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: bunk@stusta.de Precedence: bulk X-list: netdev Content-Length: 1182 Lines: 37 On Sun, Mar 06, 2005 at 01:00:50PM -0500, Jeff Garzik wrote: > Herbert Xu wrote: > >On Sat, Mar 05, 2005 at 12:07:18AM +0100, Adrian Bunk wrote: > > > >>The way kconfig currently works, you have to ensure that the > >>dependencies of what you select are fulfilled. > > > > > >Yes Adrian's right. In the other places where we select CRYPTO > >symbols, we always make sure that CRYPTO itself is selected. See > >net/ipv4/Kconfig for example. > > I would rather fix Kconfig. If we are selecting X_1 -- which explicitly > depends on X -- when Kconfig should automatically select X. > > It is completely illogical to duplicate a dependency chain each time you > wish to select a symbol. I asked about the first example of my last email: What values of the variables A-E do you expect exactly if the user turns on F? If you expect this to work, which unambiguous solution do you propose for this example? > Jeff cu Adrian -- "Is there not promise of rain?" Ling Tan asked suddenly out of the darkness. There had been need of rain for many days. "Only a promise," Lao Er said. Pearl S. Buck - Dragon Seed From willy@gardiol.org Sun Mar 6 11:10:49 2005 Received: with ECARTIS (v1.0.0; list netdev); Sun, 06 Mar 2005 11:10:55 -0800 (PST) Received: from smtpa2.aruba.it (smtpa2.aruba.it [62.149.128.207] (may be forged)) by oss.sgi.com (8.13.0/8.13.0) with SMTP id j26JAlDT021677 for ; Sun, 6 Mar 2005 11:10:48 -0800 Received: (qmail 8552 invoked by uid 511); 6 Mar 2005 19:10:36 -0000 Received: from willy@gardiol.org by smtpa2.aruba.it by uid 503 with qmail-scanner-1.20 (avp(2004-04-15). Clear:RC:0(213.140.6.110):. Processed in 0.176408 secs); 06 Mar 2005 19:10:36 -0000 Received: from unknown (HELO ?41.5.1.42?) (willy@gardiol.org@213.140.6.110) by smtpa2.aruba.it with SMTP; 6 Mar 2005 19:10:36 -0000 From: Willy Gardiol Reply-To: willy@gardiol.org To: Francois Romieu Subject: Re: The 8169 driver: issue with cross cable Date: Sun, 6 Mar 2005 20:10:31 +0100 User-Agent: KMail/1.7.2 References: <200502192011.25428.willy@gardiol.org> <200503061252.01160.willy@gardiol.org> <20050306160358.GA2712@electric-eye.fr.zoreil.com> In-Reply-To: <20050306160358.GA2712@electric-eye.fr.zoreil.com> Cc: netdev@oss.sgi.com MIME-Version: 1.0 Content-Type: multipart/signed; boundary="nextPart2467067.H2hRe7lfqc"; protocol="application/pgp-signature"; micalg=pgp-sha1 Content-Transfer-Encoding: 7bit Message-Id: <200503062010.36453.willy@gardiol.org> X-Virus-Scanned: ClamAV 0.83/748/Fri Mar 4 14:19:11 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 2525 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: willy@gardiol.org Precedence: bulk X-list: netdev Content-Length: 21418 Lines: 350 --nextPart2467067.H2hRe7lfqc Content-Type: multipart/mixed; boundary="Boundary-01=_nW1KCXe4ne1T/mi" Content-Transfer-Encoding: 7bit Content-Disposition: inline --Boundary-01=_nW1KCXe4ne1T/mi Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline No luck. Summary: =2D 2.6.11 plain: works, still has the hung bug =2D 2.6.11-mm1 + 2 patches: client system does not boot (unable to mount re= mote=20 nfs root) =2D 2.6.11 plain with the two patches: again, unable to mount remote nfs ro= ot =2D 2.6.11 with all patches you send me, included your two patches: again,= =20 unable to mount remote nfs root. Attached, the bzipped .config i used for the server and for the root=20 (identical for all kernels) Just an addendum, the problem seems to arise only when i use two r8169, if = i=20 have a r8169 and 1 8139too things seems to work fine. bye Alle Sunday 06 March 2005 17:03, hai scritto: > Willy Gardiol : > [...] > > > So, i had not been able to test the r8169 with the patched 2.6.11. > > > > Always ready to help... > > Can you try: > - 2.6.11 + r8169-470.patch + r8169-480.patch > - 2.6.11-mm1 + r8169-470.patch + r8169-480.patch > > Even if the kernel do not work, I'd welcome their compressed .config. > > -- > Ueimor =2D-=20 !=20 Willy Gardiol - willy@gardiol.org www.gardiol.org +39 3492800983 Use linux for MY freedom.=20 Your freedom may come as a side effect. "Cari fratelli dell'altra sponda cantammo in coro gi=F9 sulla terra amammo in cento l'identica donna partimmo in mille per la stessa guerra. Questo ricordo non vi consoli quando si muore si muore soli." (Il Testamento, Fabrizio De Andr=E8) --Boundary-01=_nW1KCXe4ne1T/mi Content-Type: application/x-bzip2; name="client-config.bz2" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="client-config.bz2" QlpoOTFBWSZTWc1ZJW4ACF3fgGAQWOf/+j////C////gYCEcAABNu4AA9YnlT7GAI7ncZ9aqwAGN 2HcapL2928XodJ1r1kvS81Dptm7nMu5gEJQdecztbS7enKEl7ze7md123XfZyPvb3DUxATRpiAmI mghpPU01PEmaI2T1T1NG1D1BpoQAmgIIjKnlNNNAAAAAAAxBAgk9JT8mpNlPFHqBiPQjRtQAyNAB JpJCEmCnk0aU0wIDQ0GQZGhgjIaDakmhRiYmaJpkwIxDENGmhpkYQGmQSIghoTII0Ek2hqammgAA APUAHX+9+4PqYfgCraBelyKJDE04mJbRYCIoKKo2k1lxqStzMU+8/DpDdDt1sz/KpX/llTXJxx2W 4kdJKlQu4SEabJKsVnxP34ayrSlYv0p9KYwfubPde0h1aUt7O7VTSaYLKqYowqUSLFG5mCBWRbRX 4Mw8tZshULbBSVKk0NyxahhliqsxEStGYxMrhStQue9krNK6taZmeVK6Td2SGMmrblBykDLWNRYL CCyGLWg4YZGltub5k0xZA0hFkHGFHWrlY2rCKEFmmooVBeWXTpBVjlxrisWCqVkihFiuWYkxIKFF ZjFhVAgoEPcQkq6dNqxUsLjcy4JM9/WGhWXUM3msXRZpiFW58GamM32K6NCyshWVLmDbrMxRpu7M zTkpWuKGMorWZkxUyrzuFuGrU0I20xY031cbowNZodatqKKxgoKFco3KNuTMy2VmY5tlHUrbpVRl tuGBbbcrkKJlwokaiNCIIQUDJSghZzYqWPvreseTcU+BWeyfjXsqO4h9/1/kEntymnQnEurkr4xR SgpQUBAm9xxwen5xN/1NVxJA+rvP+xTvo4G5/dqu/71FSAd1Tyw9rvcgfEpgxIJNPp38XNZTd40+ fxanNFiJNkN2cIjPFnJC6GF96e7HyUb8uXLHTfNV91GG9YRsgDqhXrYdKIfTlKx9/Jyf41NxCe+f FcCjz18I/wT3tXulpXaFT568gU2HghWfhu12BuYdkHprDl5+r5egefTbovpj+mtoIvmx/38pQvLx eZecPcgsm3wup+/kkCdO78fpPJzkPTCU6mytV5QoMmPWhH8ro3GIWl54LHzO3+1TYGnyYyO1FuBm 7Y7v1Zt+Vz7OT4N2gLtbATpOu3bXlevOjwiZc7t1srKsq6QQQWXB0XPJfCw7bZFk7g5XuCUeGX/T LKrRGHJWHJtYDMp4X54Cy22h5ltHJVh4QudmzG7ZsvawC6TSLemP66HQ0Ri+b239jiahtaszaw3p T8oa8t7yTMctjBIYsyzFrzGg2t/riLGNa7czY3ofONRYCbbxXt53R0gH29LrOdsXq6XmQ1cjmc6B C4ZzatHSYsuy27PC9b+Djz2drkvJc1tvWcOVJZ2TaDdIFEtGU4XoybBAs0Tft47UY62vF7anJmUa NxnARFzUpw2GMWyOdxYZzY1eO8JmLd3bQGGerEoI5UZG9M4JTJzoBlITfEWb8QDoVJphOEZHanCM ccJ5mUEB4wKPPRNE7Lkvrekq07qW5h8tMx0v6+Ovh6vV+xH5G32KAUoKA9nknu9nwnB/ajBytgLf N0FAKUFAO5e+Lh+dQZpZL38tWJ4vDbjKtAkeTxifxZXs+OGhPv576bWL3EAIOHRJXcBBI125adBz udMQ780aoxknxF1kR/KfbB1x8e33sEhQdtaesl91su7j0DcK9e5wzDvfbkxhegQmAbgIpHZ6quZX qWLS5kPhOVdmmjugrqtmLJJNK4taWSRkOyZ6wKelqROMBWeHegyh4h6DNafp9021pVbpuln7A3dM ez0eGXi8Jj+D8fdF3TIlT6y+Qlhl9GDEEvfJqaS/T/Y6UMWOP02EMNWhTm9ST0AL7X4sHlAWJbSr xX98dWtLv2qxIseXtgIFr1lcy2KrMQcPA3i9s/y8UcQ9z4l0+RxTNc6WkrH46yHjRxwPCyvcSvsg PkSzOx/VkSyR6lzL19UjE0Qm4K7MwAAYjUVZVtxXC/sF/E4Ft3veyvyytkqDQ591vOjxjygQlqDi nj3yIY8QstBFZrvaANfmwTG3M+RrzyXI2vuMLdqB8g6tZBb7cY48278azeuqeuOvXST8BU8cmZU5 UpmljNczbtdlryk2r8m5Vdgbk2JpAY4cVd0suRGA4Y9HOwUd9gte3UZ1ooWgwVn463+lq5lXMP5+ /ctT17yHwsL58ztn5H67WnRVyvQVhh+Ou2BzaKtFWelPi7jeVHtMVor+hSiqgCQIQQC8QZyMGc6P s0ZkU07kYgbeVvSk+ZZuDCMhnx+/2nXRbdtLh2Nn7dpq3iM34HEkUW4ZiVxepoHz42Uz1q3md7Xq qWbwRAKddvLc83gDU0BqUAHWMlaIt8CsMfAdwCprv159OQvRYc6s6hdKxswaj3g1g1kR78OQ5usW zniyVtnpeoYSkApq/Zf7rH/guwthp1wATsqYQiaDPtz0X17ysUlq+vD5emBQvO/1eV7r5jXJ87Xl c4PX0uW/Z7tE6456R6QGU8pimZw78owbyiWWFt7UXavK6iYcxLAdnLtc0trJ2PfOu7uJ3W1ZlSx4 vjQSK/fVeBZvcKYZtwW606yN25jBK+a462cyezS0jhxBN2Ndbs1BzaLIjzt4kzjC5y4MhC1ODayD sk9OsGCtbBLnZPgJvB8g7wnjwy7dzcmMsxYvdfIbFbZAIK87cW6O6vrI+Iz1XO3SjotDe7PJVBfZ loDBvbhdPS/EzATx9M5Yj729N3vAn5d/fakc9dxyToQ703fgt0IUzDioes8+JyiL0pWE2j3nCSuz fBaaAMTYK6lJRWzLS45dPsX+FtJUWKGVkZ924WkDt8ve5JG2wHnt1id8/DEO5PRSCUuO4N38QeMi t/q5j2kSJEWSLMIRbKaaUo5IMdbJHhh9XV3+DP2pfQG0kNoYYOIolqfNU4rJrK80KD9jjUcUEYId jGQyjNtzKxoaw6AiVHiJDYiMNdcWOm4loQKKJGoqCg0U4qK0UVXJYIJd+puFgnAdXui0MxWXPcNr q8v8GFdR1wU3WIDFK9Y4AdLgFEIHlQM7kX2xp4VNM0IWLNxReBRRzRQvcdg+G2GQB00+J7eT38Og flz0lcZ7qqo4PPgPD+jfz4us/pnlSGWa7xBzBCElRNa85C9aHy+S5dzKzkh2sgb+CBUiet7U4WQO SQ7kCqSgaOGkhdGB/TyB+z7K+ueKRkPsfSPh1yj8L7+Bx0ii6wFcWFUlxD7NqhprPzKsahlEn7tB GIlkdoc2kuXLfuHnOnwbxkniWOdYID7+PKhVdA4XOZ3FMq5L3goYHVOVkJaJWu/pCUKRFg3vMI3u C9sIoYwarowTsNRXOI6bVCjYmm2m3G+ITXEFUkD85AMBZTBah5EAJ4pSc/WJpxh4emQ3X6igIsER QUVBSKEURGMFBQRBBVYsjEWKQYosRESDFIxAUFILFBFSIxZFYqxgIsEVSLIkFEEkWMYiKgsGKiAj IsQUFBVERSIjFggLAUUYqiRVkRWRQUiixFYsgLFkFFERRQVWMRWKoyIwUQZEFEVgLAEQUFgoiiix VUiixEWCiqKqoMUSREBZFiDGMWQRURYkUGKCIIIILEYIMUWRRURRVVZFCCLIgjBEYgsWKqMRIrGK ICo02hjGMPSUGGWa6/NVuFGhHWFmzw6Nd3VdTaRJclECTfSXwzD072XYzrd84009t5WThVoLIGs5 ylEG2WpgpUY2TMSkQ67Qui/JoKFEyFmvqsgbVjrwuYevG5TxSs4r9W841pidGgnlYyIRnIKFhtya ql7X5MdKWs7SbfoKuMWhpHHHhwWK2Y76PjtQpKwNPIAcQa7yglJuhBVpI+6UkQTSB5/XOeH46YvQ PRpCIYmNJZhpT6E1KQVLQFzco5vYbDapidtC1cPOwqyxZxsPz3LzrB7WL0qug0HZNe+fpelwYbJ2 uqYo9NIKbU72Hg4xfNk9DJ2Mu9hbduuh0EMfNJtpQCPKoKuuyIkttAXvVeB5oJd5wnCGwhxmXlXj Q3sXzyM2TMqy+qLjEj9Mcli66nSuijyrEYUx7znO+9PTbkiskRPreFfRYg8PKhufomknM46MZ5WQ DB0AsFNFp7pozv6vIOYIDLE+bhFiZyotvt70JR4CDC2t2uOdF4pnvUKgadSIXC7hlDkqG9fA4E5D YukdJMwQW1sakhGmCueZACniBC0O1tDlZJCQyuEbQdGubenteKU0WM1plxYuNqkUa6gIBEIFRQBz RJbhVcS9KJyXeremOr8JtrDZuYOi2HY1b7s3fdkNd3viB56zqU7bThVBsRm0Ya65ILKNJAQUWm+X c/XmBIjB0YIz0g75zOg7COkHEWEEaBC2MpQu0pR8gT7ViFZcz4vn2wqZ8gNkhQ9zGyhfAMqiVIm5 AAJJpq54qMNMVM9DcrUVHCniAD2ZVioz3zgRLPf0zk2xeVRHh9rHWusBf0hjPEp09dLynMqLasOW rAEHEJEoTWCFeQHwKBRQixi2AzFK8Lr08upRyvO+9gG2UoQS/FfhXCjtCKUOfMJGLFmbjgAOm4MP mLjD5gaVs7d1Id/LbdOdCQWQCc6WRZFIATdJCpAIKEkk9jIQJ5e2h26fSPDgmS8wrW2z2mHj1WR7 H0NOvRwImMnNQkif1SStDWToNSMz9bInvpFuyeTlBZFIFSYFyPpR4TFgkEzU4bnngadriRUU6PF1 ZYk4uzZ5goWkN0ANlJxIdS2Te0aM0GN+hEG8hVjOyQDIXQpXakYTkNq9czTyoIRtpPS+CnIzSuIL YyiIBztr6scHUtqJPACgCKF1SKPw8i9Djztp0pkdCQhV6sKfSqBITYIAFv3E1Hrz0Jppw1HIFa6O QUEtra6UXdF2ePU0S6Pv1aubIqOOHZgjcY1WN+/5WOrvFZc9pi4TFIbY9lQG6VYxhwaGTgrlHptR asVGenWEl6D2wlFZjnJYhGr6qlwUZhIRRwifIUW/bW0O96Txrx34Bxd1UuBuFE4UbwJiwjF00gRU jo+CgUmhRlVQeeYGDKGMzIso+jfK4uybFVSEDupe0HcqA/SJa4yQkpd1+5pjHeBb1GEpAx+DCznx O8wdnkXIIGCyc4LPpavLSbz9aRQLC5ACJWB21s+8Gd4gj0RgxK3qDz0PorWgpRFZQg4x7wqOF74b s5gQixbRG1Mw3QwRKGD2NJQN1bHRsyRsiCYPxHM3cD1roK+ltK81WokcB+AgRJ4h5LTV2oQpQR7E Km8I19FFrwde2viltMHFyAEeHudgYupn6RpFusizYgw1DzZDlqwrhzx0t25Un1MKE3VQzKZ67xtV eOgPeW9euejn6FA6ZVQ2VBeZ124bFI7M3vBcS2EKYHedhebUeIFAlZJIP37qsbFSUSxyNEami5la 7oqWGh/W0HR3OOigB8N15MnlxmhohYFGaZ4xI3O0s3kcBxwggYWozswK9hjpIeSkZGlSel415klU cv8rQvVQbMlHLCd4gPTHa27evRSqut406B8MC2eWs2J94OkmYIug7wnGyDITSka7IpjIgxMxKer1 ycUo6khpgCwOGQduLfP0HdNccyC92PHK73XFkqKLAUONyASSZDAjOmqsqlOlCoxtlkhFXDCd94fB AgarW2ZBElCBac/VrZEdJxA3lCzN8dGlfP29b7WB9fvDKSkGwGl/qMLs9Jhfc/Tp2MUohTM48Un2 lkcrWPRK3vQfebDVoFENeuejhsaSMsSJ649MsP53s2eTcVg9uCDIxCul9sFWtOgSsOI5meGZsJVO XzBlOMorSOfu505aAEkudNsigqtHYPpXnEqihumRJN02mItamLkTQJ8u4EE1lXoZokBsgMckRHRh wblTRFivXg899XjKTebXGYNllwRAj3utFpfddzPx6mtjhnqDMQRMQNt2lttjKtNNDKyo40T2S9Xh uZ8N7+/r274C6xkZStJm3aB37c605W9nVdXVhDtQaGJmiILqdSDHMIM2ucUtRcuNI6tRBHmn6pA2 aE3laklciE2sdzBzToWkKU4PPgq35xYNPprGg1xCKnJONjrZATCcN8B4qubyMm2uWUbOyJ2UlrwR RYVrw5A53cGhmRndib1YgMEK0ZcMYdYnIM5RqECeZpHnCmncIAtAHxUt3TllkseVZ1msc70jBQHk rB1C+O6BI/TwPPbEq8BA801Zwz1XNr1Y3bzeTy+neskXhjfpl8ukwaSrtF/lwZtbMub0hYshfE84 PeZdmWcPowjXBZZX8tQjFdaQTCJ4tQ4Y8OcVMEOnNcIYgJlZ2IJD56KsBEKVREqu/xxeR1M6F6M5 sdHCgmDigQOiUvUp9iTO6ZF3CefvJGY0D0WZw9qRUgJSAbRVhvGlaB29NtoNIS3X4ws6e15m3x8p 5soz2UEhQ6hHqvY2NIKBrvOU4CL0b1OlVB5uDQWTb24CzswKRrQMJhZ+ddKgEhTMEZMSKl/EUc/X 17FKO/WNNILPojkXDvOoIw0dWISWnm/QuU0oZhGckeYPK/1+OsqiDRpIOJhfNIzvBrQ2K1Guhbx0 mTyQEZ9/aUkGKuEJFemdTq9GQ+L5DRUYeNRenEKjvBlooQZDqkkZw3pHpIXp+P66B5aQBcSsyPgX jiSneoIJDrTWnBmWN346kLivIYbMdIbLW2ZGozW7gSsMn5gViYKt9o5dNY+X4MoMYhD1OMIukiZI HK4haNC4YUPRmLgoZlCButOL0VIsTLTtKhkBA8hAMdYkSSwirdyz7Lc9QeTrF4PEN8wflUMKCXVT pOulwd3eO82+JFY7zY1cOyq+l6t2jskjg1QjKQyzDso0BPSMwiqPPsHeetpggo8Nd4LPCDHFd2Kl xRVG9hC8VOYpfV08knx9VW2sGG2mcFKqkLw1eKRDnc3CxaDmMTlZ3ocvpcoc7tP5v+wOEKx3fNxD YlqRRnxXZPNWeXWnLUnOllLb70PqmN75w7ruqJlxoQjqvgjSQImmK5byjdvTQNZmw+KGeQHfTS61 zIdr6TRoypMwQqjcESM7EOOORY40GRsp/Dapzx88FDJa5EOeBtI5uQlE6uXqewa698FQZvxXKVOQ fmSZ66cXZRRkNkRKr0mpSvXWu53iOwA2sZ6s5tCACWJKoxIwkyzhRfK5U2zVwvTQMpqkuKRp2llx WkawDI2OqejBkImpg07H0rzTe9LHVpRPOjVSmAt+ICMcyVo4VWQJQxAuFWMcWRs7sYjNAbTxaAhB 65tU7Nxwaqh2w+6Nq4DFGXj4lvQrOmZQXXG5FD1l5FxPw9APXTPrcU5LYAoDh7Ez6yaTMb5rewgY 6WT9tXYYWAYKqKUCmf3Cnz6bJfwRrmUN6v06SFwSUx3+IhvdteGuolDyD3nX4UqEX3sNpKo9ylJ6 iE5zwQvukjDK721lZ57a8jFGC2XdHX4jMtn7Ul7sgevT7xdAqhVYfjn2Z+p6GW9Z+tLNJEhrxtrr Qg7QbvvOVmFk6Am7yJk0pe9eZ7UDUGH3OsrjqM4A3iJF4XLI4c8uwZ1Uhjdl+DqhXRWBBOrlnyYp CZs7IkpmGqoYjqzcYagDIy8OL8Hjctin0ryJHjtwfl2tXk7X0jvlvxf7HTKjGyrAJqFDA0HG+yv1 YTDrANhoc2KELEbC9OINvqs0tpFapAe1oAhtobSplxfGK96Rro5xQC5rHL4ZLVkzA7awVDrtMlsj 5prJBVwXvx6wutheMaMA8G6cVgM73nDiWR8zdHIoQg+XquCPre12O3LdYVQFeYKEETS/misiiWHD mHmmcKm9QhEQAXW8NC2R7EeaK9ks9x7FzCrASxUKUkqwQRpZzlvd5xUVUVFEXGaSWlIHq9W519m9 11fOMwrxVSK4yWIe0Z3jEFqUvuCisWlFDraTcLxq7DFgeIhvQvvG18WLFtpJedqVpkg+YpdUidbK xBIEp1ZlUTQ3OpcYVODB1cEX0FQyKbE087OgngyQMiYpJhR1jBaCGzILt7tsRMhI0zN9aCPZoFZi TdX04n3pprC244krzhZx0OL9cz5+BNGqNJbYEIatHlUJAyZry28FcGQ6Emk6zdQguDBM3F3IIW05 5SctZpoeAINl9JEKgGpTLq3svssYgumbS1+UxJAJBsqh0VP7yUj0rxjxHYpdWqOd5JKRl07BisGb bqGj9YSEa8yGBZRRERBLME5FZM8oSAws7WoDbQDYUagCxdqNPe/ilLPHeemxZ4rJFbzmw42zL0Ek pYTZu92UpmaBNGXWAqXnCb4WqsikQMnGKicraz7qaTcJGCiMLDEKYo07EqcHtZ/FpBjUqyiYsFWC oBchIE2GVShxlaG330pORzvfWp0LGnEJIpttNo1cShcCzG0Wy5r0IIG9rgaRXF+Nt1IlgMDvHr8/ hX4fVR/T9/eIjkn/nj9oFdcQb/qhn7XXZLhoX2U5Q+mZmrlGSiGYELeM1eQHmoI6z8SnRdAQu5o4 g4TElfyoMz1Hxah9GNx3hIv7hVSgltgfTf76Zca2o6H6PKlas0BFRYvFrdfmB232ZxJ/VJNjQlP7 Od34sAOLzguR+y5QmS4dfQ/5xSse1NFgs1HQ3+cqAOgnNjgdHLb32eO238NsUu6y+gyowbaZGUTl S5V3dYasx0MKwzvl4uIZHVWKpqpOp394S8yNoNXfEZLBe2sFPChZA0UT0qafBk5+u7pwzsSq5Q6o EhA3ne3wmX4Zpl1sfongQWAor0nlOUZ7t6ZU1awo8hi/T8fwVo0LUnGWUkbhl+P580dICOxQgly1 sxqfmR4TxIJb5e8923Fh6Ukgh2XNdq9MfGtPN45osZHC5Mz5abAvyQ/f8P29W9ECQgz+wM/aM/dX FkK28jBkABSJgb0Mp9exrWhg0YZqIEmIHTp6S7X4Ms2l63UuHkDt08tdJtUuMM3mfa8iaAUOmnPl l7QVmmAkH1/i1O3RkEXLm2/Nm6S15anLIL0ILDC0jlWKG2xZoOWTx24nTaE4cOfx7wJBBZUQZ3YS XNKwmOi9fPx6Vmh/R9eDvX7de9cVt/Dzi3VvskMiVZ5NQQuFzlgBFa84qvaAPDxyFIu7+9SmKZbQ hRdpWoCQISYpwUySsP47h0WKj2TR/atmNzlK5v46oAnzDGnhCDm2QQGjWh1WWM3e0JtMbygie0x9 3r/H1rufndKGGj0hfFLJdWVJPv+rbGwVck0ziw9z1nJ79QDdGBB6qPq972HjvWKeSHTKi9t7NXTs by4tMb7+rtTZwrVUNv9J+JzhnKBIQPWsbO1To1Skr/FoEhB7vrTK59GbauHjD7L5QROEAexMNAI0 ABiQIWTAQoMzBnTSYrx/JFbIEhBBVmSpNpvQeY3crJAN5smwBpSwoV9vzI+9yJXDByKgBkUT7om+ 9T15yW+HNJrBqV8ICg6zDB9qKIhp9ug7/6K69Pt4DxGw2k2m20m0jclVxZfiuPn2VrW9PK4XikmA lPdAIIoZ7DirHNCqvhofa6rEyPGAkilOs2a5MSW6fs4+EB6epQE//F3JFOFCQzVklbg= --Boundary-01=_nW1KCXe4ne1T/mi Content-Type: application/x-bzip2; name="server-config.bz2" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="server-config.bz2" QlpoOTFBWSZTWbfs9TgACEjfgEAQWOf/+j////C////gYCA8AABbWAAe9n2xQeuvXRerzVdNU+AA lt6dcqpo9ddUaPV23Ge29PRQN2DoO5gHe3LQOa503O27e86et6yn3vfWe6873Ne+jG3vhqYgJiaZ AjJogJpGTKDyMoxppMmgBpogNCaNQEaakam9UekAAA0APUAGIIQE0p+hpNKeT1GpoGhppoNNGgNA ASaSRJhNU9T0ZUeU8p7RTQ2oD1AA0NAekPUGKTEJ6kxpPJDGoZNBkybRAAaANAEiICAQhoJCTyRp 6g0NAAAADp8PiH9mfJFFWA8aGJAUxLaLKmMxFIxy0rMcVKhWH2R7IYh260z+ipfsaxT6dv9crs7P BbiCpphWVheySBGmySqKzd+OGsq0tR+u/W4ju31vUh157VzL3Ok0zGqmKMKhUixdY3BArJbVY0a1 xCoW2CkrUG2LWZS4y2WYmDiVmZSFQUG1yZbgVPJCsxFigpa20aotTSQqTLaMMygYyNrLViwgoTFr QcMMjbbRYYzGCwUAUDEMYVkC/d1cqNKsJq2QFlayVhumnGCq6zDIxQVQDEIomWXKCxFZjFFlbQIV kgepAl1bXTasVlu3r1cc1mztcwZM9msMdKzMDN5rNFmhRatueWtGjTKcbdGilbcwa3hhXDZldm6q hBQMSXHHF9DNJitZZUULVy5bhotTQlblRR31daaOtXRrHDJlcMypg5lsrMxw2yjpa3ThRxwxWguX MVSjAqVhh492p18fh39NHv3yT+ZXezD1Q61HeQ+39z9uNE4JpLr/CW9IopSlKCgGeBxxcnIfps23 +VTYs58NX+xR9oAaP791+wi5APCj0bztCxA9TDo7opp8/XzOVN3hu+336nFEZ6rSbsOCUIIKWIqQ 5Fj+0tVexH/pr/D09LeXwfnGg5lygHBAwIOsdCMgH25Uufh1dRf15Gqv7dOXGuhS6jasCJzuRRKW hV/PlTmDwadkKPuza7E0cxIwemrncv09Py8h+n2+fHVn1TP57TBF9O783Fh93Fnv9zZYfqxC/XGf xWE9bfCWhe55tq/750k5xVleSC9M7/vRejoi4vzI6dDDoVP+3Q2DY9Wbk25MFuBm4rfNfLeTocnw bzhK2BaCQKFIU3a/pgvOzwiZ9eiL0trW8MXPodCxc4dLloRW5iuO7I5DKTy6XX7a3Z4DqF46I2cn Ew1HXbXPItlVdXQOK11d4JauBalzrHmozyfN1slz1RUZc8Mfnod5ojF7Obh1cTUNrVmbWG9KfGl3 C96EmI05YoOSLai846s57fDQPcw27IaM6mOLYiQJsq4d/WfOXHPc5Fe/fo4+rlrWnVsYLYWGMcG1 g5U8TIbORzKZIV7KtWjpsWXaU9cqaMhwcuu73R6szZgt1C3rpXWkXUBXFBleq3zWIFmicd3XvRjo 16UbblmtObBZbLmlTGLGrw2uoYrfhDK5MxtdXBbbo21wrvs5YrXAxJ14rWtecpsabNkdkEjOs2PL F+TrodHIzmu+4ZZdM5IbPNMySXf66efpD+5H6e1HGQSQQMuSLTl04ZZL0ThCQQ1PkIJIID6dD6yS 6pgxr8vTtzbzVE5Mt+8Ptht6qzl9cKLTrp9/lC/MD2ggEgl/46dDUpSZF4d3Y09pnQQ0zRqjGSfE TiN/4T/2XT3/yuExUd1PQknjPv38tyIEQBCY9p0JSIfyCyNQ/DVeQc5vy+EED+XOJ0ishkmrlPLh 1tMuSMu+IIGyLHrSGYFmb2RdFfTeIwtQYxDtIyTP9zVyh5pOStGdOOf6D32IPr8vwp79/k1n7ndL mSr/yEfrpQEVs7ZpX5/5Acs/IYYsCqs4IwniAfD7MH2QEeKuE/d9L+0cVkzMQCEcsul97ZOM3sWF sJiT0bMfczNtlsmN5z3K4910LWaxjqbqtOE1AudMpvyyr2IU7DEULK8Js3ckmX2c3aUxWIz+Ietu 3SCd5pscFwtsxkwxIZCct6vGXJTRJ2s1+fJeIYjTrBgLz8UCvxEtKlAhnCgGMLXtJ+f0hVK0O6ds yn21e/jrZ6WSOmjKjDKU5rh/TXZlI0y5Nnk7CEnsZyMnOTdoMiA5cUb2hJA+3ZjLAcSFCe1WEFGq 4gFb80RosRJt37UDmakYG6+V9ObpJ4R8lxhcdC0BrnFmOnO5jM2ka4Q7LXqTqwtQULAS8KiACAtz ZzKODWrGMzQ4rdeyyL+tkVkl+ZRYpVMf37QlS6LphLs0ca5HgKMUougjF3HrcB9OPhcX/ePl9Uwu z9bjYLj45949bgeYkhIDnXW3FPyXiPEBXPfjYXIsZYYTfgKNpdVjXvBrBrI+/s5Do6C2dZ3QleRR BA1wC5uamwqnT5nY7owbNsI22sCDwxBm/h83ju9keOrrOKcfWGQfd5X8LjgO0OEXxOC+rWi+srn3 I/I+VTocsyzNoNmyvx095RjObq3fcTdfpvvGnRZbrdgbM0jM63sas1PWHYVj+mVmsexINiUXdpOi wn8655XYsurCC7ryLulm67uDNpXZCFtGQvk6/7YZZnBrTwauA6MMS5Qgpc/FMmap3O1nLtHo14qa FRzCWaxAVR1nYrOzrlruqdnh1YxMh0jCfCxmqgwsy7B7ziTHg+t94is8fbxGlfH126dWnDhvzSxQ iM3FdRGcVF1seykC+taKFOstDv2WfIBiSwEj12Hf3f2p6hgcTqswxCYC/PwmQ7tMeTzt86BI4cgP Rf3CdVN8O7jnSCUttGz2YcLCa9Up+ZEiBFrMAhFsTQ0pRzBr3sI9WH4Vj7GT3m2QbBLU6ojrY+Kg 6we/HUHzt4Pt47mmlIihWO3R9XxGmiGEqCxzMOR6kmPLe9jjQnsUqom6lxo4h7pLTVPV6PWCBDHf z7SNUVPGDNIt23VHNBbnroG1qM/mYvrZEQYJTPVppApbHHJBBMAQCpQDDnuzbU8s12a74nxiPHaD tmCPY7/TbDAlyJ+Ed7cg5wHlhRFOmpaqGDzyUMuDLdzQ/pB6zJpKxiDmCLoaQlUa26yKT65LKVZm GuGILHZgQxDPZ6suhYYHLCGkQzliBcMX8/QB9fukJ0eC53k2hsqS7VaW3qKoRZYCfFRQIk3j8ncw 8V8xpOhmL34kqrMjc8fgyxpb6MxVYljhjQ87c0wwENs1GgRlWJa9qtAHYTE8I/VpNKzsPbQp/AdN k1pdLQYBqjlg2jchRbSI53qKiTTBtxxzuEjCG3dPxcJSdDZxoUuwFjHDh5/HcePjm3X0ueB+9WIs ERQUVgxZGAoMSCgiCCqIsjEWLIiiiIqLEBikYgKCkFiMURiyKxUQYKIsEiqLIgrBSLBVBEGIioqw RBWCIJEGKqqxYCqRQBiwVRFYIoKCAKKMVWRVkRRgoLBBEViyAsUkURFEQVWMRWKKgKaSgxixUVUY hBQUFCAwRFUVVYojJFkWRYgxjFkEVGLGCgxQRGKCjGALBUZFICKKKIoIwYkVjFEBUVWCIxMnewNW Va/T0VXCBMosM9aQu7suxtIkuSgCVePSYh1a1eniyO9jSy62+OLKzhUoLYGYm88MJjHMvI1sapUr exIadulnze5hyYHUvG+u8B6Y8t+y4n45aKd695fXynGtMvaKGEcEPvuAKwboryxKA9dFbbb342eO vJ2vtIyzjapB1nW76kk6WGnF0IM7XYWggQSkZDAeDEkMKwwUrjd1yjOjA8EQRDQxpLAZ+xFCYKbw sE8XsPfFTTWStNXjAqyxaRsP283naD3sXpU5GekQvjPqffiuAYcR4cddNPJM6070lYvoYTtZz2sL btzodUMfwxVKQDPiES+wlbrcdMPwd/bJeL1pMdY8+OK+i1cTX36DNUzmXyUXilIjYwG5vfB9Fdkg CLxlTiUqT6v22el46f15ORGYCDsWLQRg3NZxf6lQ5AadJby3jjSmAoaWQYCtinPwQGmDAdRAY1nt YIkGaaQTHdkCiwIg6bWa3HfdtVyHB5lGNbEYOiS3Fj4ovY8GeCwjx2uaJJX23xaSgTrsWsyO6hAl Q9nHNZiYzPCNPapUhcLtoR7+2JZI3kFsZPLO+puAiwiqgD03WPEUM4WXMmCf2tvTXuuea91PhVKE anqd/DOHyxs78Rqx52k2KeI0VE7FrxGjIzilBi8mi95xA7C9mSQDU5dp+3cRoIyasEYzBeIx6xV0 ZXo7YWK3ZPrTFd5xb3DSTDr44+7MLz7hH0zg/OFh/daXamBACSrBv5gj3iukWphV+I9bUVGQE9QA fLq0UeH9RAAhCWZgTicQMr7NXvbjlcK3ZVFMPstfhhgdUI1m5gxIeBlXh7sKFkHLEk2d2kvgPuYS pY2IkDar626UlToaCuW5uAcqQQTrlaDpwUDDtvEIqVZsPoSkAONxMPqL6EB9SNkOFxd9ab7zhzwk gpAJypSKRYQiMJJOxCIIaBMYgAbQlgYJCR4RueB2fw3pTUzArW2z1sPNzsDnzxM3RqBeyoP4cIWT WeRyYgO9gjxXMx4B4HKCXYIgUCrzCQaC+MTgbHEeO6n5/RYqaF/fNc0yxzEaeQoWkNwAbKTmQ7Fs 51kNBks8+wqnhICFsIRxBbAsBiOqObaCIoVAcuLJovCyi1qEgGd9faIh9y2wk9VAEWLqY9Ll6ded 880yc9qBKLd2FfqokkhLj0MwfGnqYXB4nNGlppwqI2Hjtt1XPdPtNvXCWydPXxOGa1HAluNe0EMf Hr+WVXvLp+ENUB4SSCyLgJQTpiKpheJs+2UGVMsfL7tCA8vtyGkTL45RBr8wbjUyFy6oJfozGPLS NsBauT6a7ahYulgxgBC0XPzFRcKUg+KUbqMeD9tCrxVlVQbQoyhpmZFledWtqRtiJmHrSZcB6Ja7 HpzAr38xb+Hidsw5+jg3GaJrMtOgxLU4PLtqFUVDMESGwlRG9E8n7lWKSFiAES8TwvJrRh4UpoKF 42senX6rWcVCuoXz8Qj+mY08R38gVeSRmLXbtI9yh3UbAhbvOhCLw9BeuFYiVwgoD5HKkIAeV833 HFsv7F4nD7BAiUxH5irtQhygfyQqbwXZt5UXxB38bae1bzsdXISQer3O6TS7mfMaRbvIssQasMsh qwfTwU74omV2zCbi3gjDCIGJVxZKJ5dtQHYx0z0K/xNWKGaiKxAvvyvO27MPWYvkNdz3k4hAWhqs ECJIioQv0GCfLW5JCUGoRBtlU7VXGzRi5YaGfleDl9dZyDOd8ulcp2p06FHjZrfXLR1tdN9+Bh4a gZ3g7sCvcbpIeCkYNKzt7YnszvJAdEx+TXlZOWSLwwnph9a6b9TNc8h9NBXtfSbEv1JbbctDF0Jm 8I46IFULixikxKfe4ZPZgwUEkowBtBdpDreIjnv0q+2gjaaRh4piEoY2NoGw0qkAJKRSgAa1KMxI 69SVGNssIRR7TKkKc8y+xQSsUtkghKEkog02gyaMFLBiaFgGGhisKRK7O6KSzBa9QLOIY4A1v+O7 hYZ5Jhff6x66uPRCiJ2rPynbstZ8pZ+qD9JLDLQEQw99BtjSRfaRPTzm/xTcfxsBY+ODMmTSFhL9 NSr0jhM1gfMzy1lqadusTd7THb7+2nZiAEl1vCuMVGqSU4z42vpoaPU5wt11ktOxpxuzCF6hReM+ nFxJbIOmI0z2I1I5YdEljhFivbo8+ONcEdSXJvqcruZhiPjC0xfg85rj3+J04Hchyaniyqgmm41h ieiPTzbZ9HJtaiBqApCMyubtLkVPHaDDMjavODNB3MCRLrYbO7ykjBoSc9QIy11r2vQH31mjUQR5 r98pbtCb1tSSuCBtta9Gp9jvXovIV9+58XPUveHbaq01e0Go+oRUwy9TdpA5C7jwO6mxYgLO2INo TLQcSBFAs9HbNJQeJkWiqV2zAjN4EQ1exHrppMLkzaMxY0EL4wvTfR59xKMhTe9Pq0JasKRnpvtR EAl0yPPkAY82o53W8QIah23UKlK5gwzyxNt2dmG3bSYdj0u2YoWdmNml4SYO2tUL3nvk9p5pGWuP eAn62OrrTb1agKV6tRKjRlnzN1RQD33upQS1KL6MkegYgSmUJEbbu9BidWBa53+aZCv3QVpmW4WF vLk0qxbtGxMfrMZc2ZCf1A9MsbQNmiydM7dGwUki1iw4RKV5ZRA5bbA0hLmJ7IUV9d2/FzHoehA6 kcQVBB+3aFy8lTVOZWdYiB8HJocF7DnUXTXnmKcKCJXqGFAs/A4qEMwogRRuscMl/o8zd8w/BNs0 iozdHIcOs6iDRpAKN67kzNgxeTo8weV/p9QuqAatJB2pCPtSNbwb0OClVye/UYPYgIz495EBTUIQ kV5yyplrm1xooM8M9NkevUIrxY02UIyMsJI0i5DfrIXp+5K+zQAWEquPgXpBM7MSUh2pprWnYyXX pv1KinJQ4gpiHtSGy9d2fM7DNsOBK7msJWGVb7R1befp+DEGrRrtoi3TEiYIHJ1AaNI6YUfrGtwU MxCBupTq9F4Kk3pIx3lg4CI5kgZ8uO6ySCtNoXSaTPgqPwbcqTFUHhC5veHeiwgDw1+s30kCkGYu RtcnoCJEQMZSIc421x5urPTk4nCZC31mfKScGrZ7QAq1RTyTfradipApKG8Vul9VXQWCUYBeFcbS vNSGmkbZinYn0h6fKcuLsONt6wikFTqZGbRVS0cjICiSjS2pI6xRdWIk77NP7X/MOkKwez7XENib A2PZt1oItgoJgq1WCJEt7lQSv3et4tOk1rKxgDqg5uFEAb3g5ymbudVBPOep+VJ5+uiUWZuPxQxg R67aXXGSHa8qdIhGYKDaZs1YY5pMMqMqM67i160GRlT+O1WPt1+HYoYWxhQyToF2uQkROznY+Q22 roVQzfmtZU3D9RjX16sykYGyIJVeZqUr3KcDfcSbW2mDpoSJaQqDSDKTTVbemCptm4Xp0GJqhS8+ AllkUIJOg2mBzUsI73wpnOM1KdEaozADHNAa3aOZhgJQcEsiADmcqPnQCMWqghhvduEmiFp3UNeV avQ3YXfJSK34oy8feXTAhd2zLpbJqvsL2FTy8weumneI3yWwBQCFjgNFCbq0wiPEm1xdwkFUsiWV PPwbV+C8IIXHvjd4BOkpkkmSKpJFyiEkoPUj2EX6NrdWhejQ8E9ad/arhF+FhqaqPgUsj1wECGDx ChQXIhiNwTaizmvQbKNS2OyO3zGbZ96T+Ecske/VRchVCqQPeuiPgc2rn4yZEQfExA26133klqRY IShIc8kwRQqQHXtCAi7y014hXC8F0nsO21ZDEhUtEYZIELlLiFFYzjNdqMMmBBO6Szo0U2YAjcpL 9JQETaFMOjFqHhIyoMw9828OuClDPXS2iyPzZo/IaQker7N8xg5WZBhABWIMJQHcNNMTXykIDdiN FGo3zu17kMdzwc6e2lCns/GFwYiUgJpCCGhtJ9+eF0cobANg9NqvpqxzRsaUcYBWQoBxl3E3CsCq A1EHOZTmimgDaMkAyYmiwsZa6Tffm/MEXhMBZFCANHBFSOa74+O/0z+gscsFgVbtPyw6G55SgefP RqEYUAfI6SIQfmdoNaEC2CpYYyxGyOKNBM4cGQC8+DnJ2nCoqoqKIvBmkl2wlJVNpfrn6vcK81U3 3faSrAAcRxjzMFqT0CeazaiKHe0nKvFRi0OzhvJ0+LaVMltpJ4jSbShVAPCuRKq6srEJOtdcag8w YIiBZg2Q5NDwcwqTEjOsmxKh7t49+9EbZuiUts3+4oaVi9o0ObdURH4dpZ4g3Ym0lvodSBqAleAF swAMLCyQ2ZGZqxqYXjGB0GEtM326dSuXGr9MaBrTrExsXTxGZ7Vig+57Xm9IxSBG46rrY20GVnXG eq54omT14lDEd9iqASIG/YRaDfBllItMje1q8fFxUgW7FCNf3q6HbwrnOGu5Xx0CAbJyw5a3GlLb RAdLFmeGzdXjXnKFSomERBPnvmAi4W8XYIiXSL2gBtoBsKNQBYw1G3WPSlqvQl/HvOlbSHbbgkEl w5YTVu2zKa86IWJ96ksm9b0eO0qGdCJKkQ9+A866i/pw1oIHZZqsMDMLTzWFMLlW77R5XqS9XEwY NiKsW7QCGzFCh3qxnrppOCuknBQ6ZOus1ceN5LMyt4WLc4ohB6RdHal8Z845e1HOeuru59Z9dWkS s/XjXGoNgwP+dhjM8leZtaf+MZHtQxitI3qIZPltLorwV9QFvj8CdVdSBEJ7o4g4YC9X+gGaRsPW zj3kEm9nFwDbtNC5IdJAd27x3b8pqoFXiEcQRUXdqttbr8DtvsJwA6MJdtRw/kvu6OQb7pvLgfqt oTLh38o/GKVj9k0WCxUerZ/851IcgSG14s5G+MfVtt+zYqgyZ4CytLMG45aGUTvrNXhC9Wo6mFY6 Uv9HEM7KyGCq4WE0p4hazI2g1QGSAvfV6nBXaMsMcektd7Qg18wuGZHWA3QkhBZZce7zS0xlzY+m d8gsFgvKeE7IM9nPOeqxUKPI0f6/j+KtoWmm2MSEaBj8v1dqOkB4KFCXMY2Nk8iO064ASzi5g7gu IDQkkEd6UCO1PS3EqrzXKWMWjNIBfRSAEcwYruDJMlPAEkggVsQCHwEMZmhdrMgRKAFbjVvUyw7u zWtDFasM1ECTIDr19pd77GUml63KXeQPJl8uUVoXF6+Zt9pE1qRU5ZeGdPcTcUQkj9mpv3IIsrG2 9SYa8tTe4rUILDREIcw2mwqVIVAvK8VujNQV3Of12QkhBYKIEHEpHBZKIJprtk1jB+HfQWh6q+pk mN9/EW6t9tAMiVd7LSZ3C0gQvP20XFgPT82c9vx/EVCn4CEV/i+eyEoQGeGeE9Mzr5T73l46R+J5 T9Vpx7t/H54AZ40RjhEA3lRQHKOOAJ2qZyVEJIJooVtMvnr+XiOwPv8JKzk8rPxa3J3p2b6PL2qi kVcJsnZYev7Rxfn1JN1IQenC5nl5enZ89rEfFhRVV+Z69t07G8uLTH25rRaVX/OfczjU6kkhAej3 cnLUzK/xaEkIPl96aXPuZvq4e2r8fZBE6iA8kw0kI0ABgCQsMEkQZ1WaQ6dfsg2shJCCCrMKkXnJ 8V2o9UHHfNl20012NXP3/qSFsFKYDAQIcARuzOZ2Ru2Je1JZgFCfnuNx9D5Nz5d0U8fl6z3fAPZ3 fR4Tt7cRZFiqRQnUMk4UPlOnb2AUpTbmdDx4hc0ScJaACa03oMfRXcD09yDsQpg+oAgE0WLO7fSe lFO2hovOG5dRCX+LuSKcKEhb9nqcAA== --Boundary-01=_nW1KCXe4ne1T/mi-- --nextPart2467067.H2hRe7lfqc Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.6 (GNU/Linux) iD8DBQBCK1WsvgbSPju7wvkRAh2LAJ0aBORd1e10P1OFcHzuWYk0ZYHkdwCdE4KW dAKgAleI30E87MPkQ/sVN7E= =H1XF -----END PGP SIGNATURE----- --nextPart2467067.H2hRe7lfqc-- From jgarzik@pobox.com Sun Mar 6 11:14:07 2005 Received: with ECARTIS (v1.0.0; list netdev); Sun, 06 Mar 2005 11:14:12 -0800 (PST) Received: from parcelfarce.linux.theplanet.co.uk (IDENT:93@parcelfarce.linux.theplanet.co.uk [195.92.249.252]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j26JE6Nt022839 for ; Sun, 6 Mar 2005 11:14:07 -0800 Received: from [69.134.152.124] (helo=[10.10.10.88]) by parcelfarce.linux.theplanet.co.uk with asmtp (TLSv1:AES256-SHA:256) (Exim 4.33) id 1D81CX-00044Q-Kp; Sun, 06 Mar 2005 19:14:05 +0000 Message-ID: <422B566B.3040801@pobox.com> Date: Sun, 06 Mar 2005 14:13:47 -0500 From: Jeff Garzik User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.3) Gecko/20040922 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Adrian Bunk CC: Herbert Xu , akpm@osdl.org, davem@davemloft.net, netdev@oss.sgi.com Subject: Re: [patch 1/3] fix buggy IEEE80211_CRYPT_* selects References: <200503041237.j24Cbb69026470@shell0.pdx.osdl.net> <42289BDF.1080409@pobox.com> <20050304221014.GJ3327@stusta.de> <4228DF62.4000205@pobox.com> <20050304230718.GL3327@stusta.de> <20050306090936.GA31890@gondor.apana.org.au> <422B4552.5000504@pobox.com> <20050306191029.GM5070@stusta.de> In-Reply-To: <20050306191029.GM5070@stusta.de> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV 0.83/748/Fri Mar 4 14:19:11 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 2526 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: jgarzik@pobox.com Precedence: bulk X-list: netdev Content-Length: 1071 Lines: 37 Adrian Bunk wrote: > On Sun, Mar 06, 2005 at 01:00:50PM -0500, Jeff Garzik wrote: > >>Herbert Xu wrote: >> >>>On Sat, Mar 05, 2005 at 12:07:18AM +0100, Adrian Bunk wrote: >>> >>> >>>>The way kconfig currently works, you have to ensure that the >>>>dependencies of what you select are fulfilled. >>> >>> >>>Yes Adrian's right. In the other places where we select CRYPTO >>>symbols, we always make sure that CRYPTO itself is selected. See >>>net/ipv4/Kconfig for example. >> >>I would rather fix Kconfig. If we are selecting X_1 -- which explicitly >>depends on X -- when Kconfig should automatically select X. >> >>It is completely illogical to duplicate a dependency chain each time you >>wish to select a symbol. > > > I asked about the first example of my last email: > What values of the variables A-E do you expect exactly if the user > turns on F? > > If you expect this to work, which unambiguous solution do you propose > for this example? If that information is missing, it should re-prompt the user, as it does for a few other cases. Jeff From garzik@havoc.gtf.org Sun Mar 6 11:15:37 2005 Received: with ECARTIS (v1.0.0; list netdev); Sun, 06 Mar 2005 11:15:41 -0800 (PST) Received: from bastet.signetmail.com (atlmail.prod.rxgsys.com [64.74.124.160]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j26JFbcr023380 for ; Sun, 6 Mar 2005 11:15:37 -0800 Received: from localhost (localhost.localdomain [127.0.0.1]) by bastet.signetmail.com (RXG Elite Mail Server) with ESMTP id 9021AA879A; Sun, 6 Mar 2005 14:09:47 -0500 (EST) Received: from bastet.signetmail.com ([127.0.0.1]) by localhost (atlmail.prod.rxgsys.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 22542-09; Sun, 6 Mar 2005 14:09:46 -0500 (EST) Received: from havoc.gtf.org (havoc.gtf.org [63.115.148.101]) by bastet.signetmail.com (RXG Elite Mail Server) with ESMTP id 46192A8798; Sun, 6 Mar 2005 14:09:44 -0500 (EST) Received: from havoc.gtf.org (havoc.gtf.org [127.0.0.1]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by havoc.gtf.org (Postfix) with ESMTP id 2A7401C0A85A; Sun, 6 Mar 2005 14:15:31 -0500 (EST) Received: (from garzik@localhost) by havoc.gtf.org (8.13.1/8.13.1/Submit) id j26JFRZD009653; Sun, 6 Mar 2005 14:15:27 -0500 Date: Sun, 6 Mar 2005 14:15:27 -0500 From: Jeff Garzik To: Baruch Even Cc: netdev@oss.sgi.com Subject: Re: ixgb problem Message-ID: <20050306191527.GA9610@havoc.gtf.org> References: <422B54AF.4060401@ev-en.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <422B54AF.4060401@ev-en.org> User-Agent: Mutt/1.4.1i X-Virus-Scanned: ClamAV 0.83/748/Fri Mar 4 14:19:11 2005 on oss.sgi.com X-Virus-Scanned: by EMS at localhost.localdomain X-Virus-Status: Clean X-archive-position: 2527 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: jgarzik@pobox.com Precedence: bulk X-list: netdev Content-Length: 481 Lines: 14 On Sun, Mar 06, 2005 at 07:06:23PM +0000, Baruch Even wrote: > I'm running a test of iperf with a window of 16MB, at first the > performance shows about 3.2Gbps rate (which sucks by itself, but that's > another issue), after some time, usually 30-40 seconds, but sometimes > 100 seconds, the performance drops to almost nothing, about 60Kbps. If you could get sysrq-p and sysrq-t output, that would be useful. Also, check and see what your CPU load is, at the time. Jeff From willy@gardiol.org Sun Mar 6 11:29:13 2005 Received: with ECARTIS (v1.0.0; list netdev); Sun, 06 Mar 2005 11:29:17 -0800 (PST) Received: from smtpa1.aruba.it (smtpa1.aruba.it [62.149.128.206] (may be forged)) by oss.sgi.com (8.13.0/8.13.0) with SMTP id j26JTB4G024548 for ; Sun, 6 Mar 2005 11:29:12 -0800 Received: (qmail 22665 invoked by uid 511); 6 Mar 2005 19:29:04 -0000 Received: from willy@gardiol.org by smtpa1.aruba.it by uid 503 with qmail-scanner-1.20 (avp(2004-04-15). Clear:RC:0(213.140.6.110):. Processed in 0.036965 secs); 06 Mar 2005 19:29:04 -0000 Received: from unknown (HELO ?41.5.1.42?) (willy@gardiol.org@213.140.6.110) by smtpa1.aruba.it with SMTP; 6 Mar 2005 19:29:04 -0000 From: Willy Gardiol Reply-To: willy@gardiol.org To: Francois Romieu Subject: Re: The 8169 driver: issue with cross cable Date: Sun, 6 Mar 2005 20:29:01 +0100 User-Agent: KMail/1.7.2 References: <200502192011.25428.willy@gardiol.org> <200503061252.01160.willy@gardiol.org> <20050306160358.GA2712@electric-eye.fr.zoreil.com> In-Reply-To: <20050306160358.GA2712@electric-eye.fr.zoreil.com> Cc: netdev@oss.sgi.com MIME-Version: 1.0 Content-Type: multipart/signed; boundary="nextPart2338345.tWyRzniHhu"; protocol="application/pgp-signature"; micalg=pgp-sha1 Content-Transfer-Encoding: 7bit Message-Id: <200503062029.04189.willy@gardiol.org> X-Virus-Scanned: ClamAV 0.83/748/Fri Mar 4 14:19:11 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 2528 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: willy@gardiol.org Precedence: bulk X-list: netdev Content-Length: 1263 Lines: 58 --nextPart2338345.tWyRzniHhu Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline I must correct myself, the problem persist even if i use only one r8169. Ju= st,=20 it is less frequent. bye Alle Sunday 06 March 2005 17:03, hai scritto: > Willy Gardiol : > [...] > > > So, i had not been able to test the r8169 with the patched 2.6.11. > > > > Always ready to help... > > Can you try: > - 2.6.11 + r8169-470.patch + r8169-480.patch > - 2.6.11-mm1 + r8169-470.patch + r8169-480.patch > > Even if the kernel do not work, I'd welcome their compressed .config. > > -- > Ueimor =2D-=20 !=20 Willy Gardiol - willy@gardiol.org www.gardiol.org +39 3492800983 Use linux for MY freedom.=20 Your freedom may come as a side effect. "La guerra non far=E0 mai finire=20 alcuna guerra, nel migliore dei casi sar=E0 stata una guerra in pi=F9." Gino Strada, Buskash=EC --nextPart2338345.tWyRzniHhu Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.6 (GNU/Linux) iD8DBQBCK1oAvgbSPju7wvkRAqz0AKDVXga8YcaeY7pw0mK8Pj8u3dWu2wCgjCDf CIIqSSa7pifkcwCQJIVyeH8= =63Zc -----END PGP SIGNATURE----- --nextPart2338345.tWyRzniHhu-- From zdenek@rcn.com Sun Mar 6 11:51:28 2005 Received: with ECARTIS (v1.0.0; list netdev); Sun, 06 Mar 2005 11:51:31 -0800 (PST) Received: from smtp01.mrf.mail.rcn.net (smtp01.mrf.mail.rcn.net [207.172.4.60]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j26JpSC2026214 for ; Sun, 6 Mar 2005 11:51:28 -0800 Received: from 209-150-50-115.c3-0.nwt-ubr3.sbo-nwt.ma.cable.rcn.com ([209.150.50.115] helo=funex) by smtp01.mrf.mail.rcn.net with smtp (Exim 3.35 #7) id 1D81mg-0002rz-00; Sun, 06 Mar 2005 14:51:26 -0500 X-Sender: zdenek@pop.rcn.com X-Mailer: QUALCOMM Windows Eudora Pro Version 4.0 Date: Sun, 06 Mar 2005 14:48:31 -0500 To: Thomas Graf From: Zdenek Radouch Subject: Re: Do you know the TCP stack? (127.x.x.x routing) Cc: Martin Mares , netdev@oss.sgi.com, linux-net@vger.kernel.org In-Reply-To: <20050306173145.GQ31837@postel.suug.ch> References: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Message-Id: X-Virus-Scanned: ClamAV 0.83/748/Fri Mar 4 14:19:11 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 2529 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: zdenek@rcn.com Precedence: bulk X-list: netdev Content-Length: 1405 Lines: 37 OK, I think I am getting the picture. 1) looks like what I need may be possible, at least as far as some kernels are concerned. It's not clear that 2.4.25 will work. 2) I only have to perform close to magic in locating the "right" tools that happen to work on a "right" kernel release. 3) Clearly the route processing is in flux, at least within the releases I am dealing with, so I need to be careful interpreting what I see, and I should avoid making any inferences. There is no doubt that the 127.x net is treated in a special way. If I have to believe what I just learned, then the 127 routes are in a "local" table, a table on which the "route" utility by definition does not operate! On the 2.4.25 machine I cannot get any of the "ip" commands to execute without an error: $ ip route del 127.0.0.1 dev lo table local ip: either "to" is duplicate, or "table" is a garbage. Since there was no "to" on the command line I suspect the busybox crap to be doing something very bad. I'll look at that. To summarize, it appears that I can subnet the 127 net by appropriately manipulating one or two kernel routing tables, if I can find the right tools to do that. If the tools don't work, then getting the tools to work would be the necessary modifications I would have to make on my machines to get the job done. I'd like to thank everyone for their help. Regards, -Zdenek From ak@muc.de Sun Mar 6 12:19:29 2005 Received: with ECARTIS (v1.0.0; list netdev); Sun, 06 Mar 2005 12:19:33 -0800 (PST) Received: from one.firstfloor.org (one.firstfloor.org [213.235.205.2]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j26KJSDq031504 for ; Sun, 6 Mar 2005 12:19:28 -0800 Received: by one.firstfloor.org (Postfix, from userid 502) id D40C5D033E; Sun, 6 Mar 2005 21:19:25 +0100 (CET) To: Zdenek Radouch Cc: Martin Mares , netdev@oss.sgi.com, linux-net@vger.kernel.org Subject: Re: Do you know the TCP stack? (127.x.x.x routing) References: <20050306173145.GQ31837@postel.suug.ch> From: Andi Kleen Date: Sun, 06 Mar 2005 21:19:25 +0100 In-Reply-To: (Zdenek Radouch's message of "Sun, 06 Mar 2005 14:48:31 -0500") Message-ID: User-Agent: Gnus/5.110002 (No Gnus v0.2) Emacs/21.3 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Virus-Scanned: ClamAV 0.83/748/Fri Mar 4 14:19:11 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 2530 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: ak@muc.de Precedence: bulk X-list: netdev Content-Length: 1229 Lines: 37 Zdenek Radouch writes: > OK, I think I am getting the picture. > > 1) looks like what I need may be possible, at least as far as > some kernels are concerned. It's not clear that 2.4.25 will work. > > 2) I only have to perform close to magic in locating the "right" > tools that happen to work on a "right" kernel release. iproute2 has been the tool of choice since Linux 2.2. ifconfig/route and the old ioctl interface have been only there for compatibility and show only a small subset of the full functionality. That has been true for many many years. > > 3) Clearly the route processing is in flux, at least within the > releases I am dealing with, so I need to be careful interpreting > what I see, and I should avoid making any inferences. I don't think that's true. Routing hasn't changed much for a long time. > > There is no doubt that the 127.x net is treated in a special > way. If I have to believe what I just learned, then the 127 It is. 127.* is hardcoded in the routing engine and e.g. it won't accept outside packets with a loopback address. Most likely it's enough to change the "LOOPBACK" macro to allow parts of the Class A to be used for other purposes. -Andi From alex@pilosoft.com Sun Mar 6 12:29:58 2005 Received: with ECARTIS (v1.0.0; list netdev); Sun, 06 Mar 2005 12:30:01 -0800 (PST) Received: from bawx.pilosoft.com ([66.250.55.42]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j26KTvQ1032452 for ; Sun, 6 Mar 2005 12:29:57 -0800 Received: from bawx.pilosoft.com (localhost [127.0.0.1]) by bawx.pilosoft.com (8.12.5/8.12.5) with ESMTP id j26KJBiP012491; Sun, 6 Mar 2005 15:19:11 -0500 Received: from localhost (alex@localhost) by bawx.pilosoft.com (8.12.5/8.12.5/Submit) with ESMTP id j26KJBW2012487; Sun, 6 Mar 2005 15:19:11 -0500 X-Authentication-Warning: bawx.pilosoft.com: alex owned process doing -bs Date: Sun, 6 Mar 2005 15:19:11 -0500 (EST) From: alex@pilosoft.com To: Zdenek Radouch cc: netdev@oss.sgi.com, Subject: Re: Do you know the TCP stack? (127.x.x.x routing) In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Virus-Scanned: ClamAV 0.83/748/Fri Mar 4 14:19:11 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 2531 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: alex@pilosoft.com Precedence: bulk X-list: netdev Content-Length: 1786 Lines: 43 On Sun, 6 Mar 2005, Zdenek Radouch wrote: > > 1) looks like what I need may be possible, at least as far as > some kernels are concerned. It's not clear that 2.4.25 will work. It is clear it will. > 2) I only have to perform close to magic in locating the "right" > tools that happen to work on a "right" kernel release. Not really. Recent (as in, in past 3 years) tools and recent (as in, in past 3 years) kernel. > > 3) Clearly the route processing is in flux, at least within the > releases I am dealing with, so I need to be careful interpreting > what I see, and I should avoid making any inferences. No, not really. > > There is no doubt that the 127.x net is treated in a special way. If I > have to believe what I just learned, then the 127 routes are in a > "local" table, a table on which the "route" utility by definition does > not operate! On the 2.4.25 machine I cannot get any of the "ip" > commands to execute without an error: 'Route' utility is by definition deprecated. > $ ip route del 127.0.0.1 dev lo table local > ip: either "to" is duplicate, or "table" is a garbage. [root@bawx2 ~]# ip route del 127.0.0.1 dev lo table local [root@bawx2 ~]# And don't forget to delete the /8 route as well. > Since there was no "to" on the command line I suspect the busybox crap > to be doing something very bad. I'll look at that. Don't try to use broken tools (busyboxed iproute2). Test with known-good iproute2. > To summarize, it appears that I can subnet the 127 net by appropriately > manipulating one or two kernel routing tables, if I can find the right > tools to do that. If the tools don't work, then getting the tools to > work would be the necessary modifications I would have to make on my > machines to get the job done. -alex From tgraf@suug.ch Sun Mar 6 12:45:02 2005 Received: with ECARTIS (v1.0.0; list netdev); Sun, 06 Mar 2005 12:45:07 -0800 (PST) Received: from b.mx.projectdream.org (eth0-0.arisu.projectdream.org [194.158.4.191]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j26KixwI001098 for ; Sun, 6 Mar 2005 12:45:02 -0800 Received: from postel.suug.ch (postel.suug.ch [195.134.158.23]) (using TLSv1 with cipher EDH-RSA-DES-CBC3-SHA (168/168 bits)) (No client certificate requested) by b.mx.projectdream.org (Postfix) with ESMTP id 72E7684; Sun, 6 Mar 2005 21:44:35 +0100 (CET) Received: by postel.suug.ch (Postfix, from userid 10001) id 7E7D91C0EA; Sun, 6 Mar 2005 21:45:16 +0100 (CET) Date: Sun, 6 Mar 2005 21:45:16 +0100 From: Thomas Graf To: Andi Kleen Cc: Zdenek Radouch , Martin Mares , netdev@oss.sgi.com, linux-net@vger.kernel.org Subject: Re: Do you know the TCP stack? (127.x.x.x routing) Message-ID: <20050306204516.GR31837@postel.suug.ch> References: <20050306173145.GQ31837@postel.suug.ch> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-Virus-Scanned: ClamAV 0.83/748/Fri Mar 4 14:19:11 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 2532 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: tgraf@suug.ch Precedence: bulk X-list: netdev Content-Length: 593 Lines: 14 * Andi Kleen 2005-03-06 21:19 > Zdenek Radouch writes: > > > > There is no doubt that the 127.x net is treated in a special > > way. If I have to believe what I just learned, then the 127 > > It is. 127.* is hardcoded in the routing engine and e.g. > it won't accept outside packets with a loopback address. > > Most likely it's enough to change the "LOOPBACK" macro to allow > parts of the Class A to be used for other purposes. Yes, it will work around the martian route and arp checks but will probably break quite a few usersapce applications. From baruch@ev-en.org Sun Mar 6 12:56:16 2005 Received: with ECARTIS (v1.0.0; list netdev); Sun, 06 Mar 2005 12:56:25 -0800 (PST) Received: from galon.ev-en.org (rrcs-24-123-59-149.central.biz.rr.com [24.123.59.149]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j26KuFwI002039 for ; Sun, 6 Mar 2005 12:56:15 -0800 Received: by galon.ev-en.org (Postfix, from userid 105) id 2B2DF11A6C5; Sun, 6 Mar 2005 22:56:09 +0200 (IST) Received: from [10.220.3.66] (hamilton.nuim.ie [149.157.192.252]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by galon.ev-en.org (Postfix) with ESMTP id E792B11A696; Sun, 6 Mar 2005 22:55:45 +0200 (IST) Message-ID: <422B6E4D.7040402@ev-en.org> Date: Sun, 06 Mar 2005 20:55:41 +0000 From: Baruch Even User-Agent: Debian Thunderbird 1.0 (X11/20050116) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Jeff Garzik Cc: netdev@oss.sgi.com Subject: Re: ixgb problem References: <422B54AF.4060401@ev-en.org> <20050306191527.GA9610@havoc.gtf.org> In-Reply-To: <20050306191527.GA9610@havoc.gtf.org> X-Enigmail-Version: 0.90.0.0 X-Enigmail-Supports: pgp-inline, pgp-mime Content-Type: multipart/mixed; boundary="------------070500030203030802020608" X-Virus-Scanned: ClamAV 0.83/748/Fri Mar 4 14:19:11 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 2533 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: baruch@ev-en.org Precedence: bulk X-list: netdev Content-Length: 60110 Lines: 2631 This is a multi-part message in MIME format. --------------070500030203030802020608 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Jeff Garzik wrote: > On Sun, Mar 06, 2005 at 07:06:23PM +0000, Baruch Even wrote: > >>I'm running a test of iperf with a window of 16MB, at first the >>performance shows about 3.2Gbps rate (which sucks by itself, but that's >>another issue), after some time, usually 30-40 seconds, but sometimes >>100 seconds, the performance drops to almost nothing, about 60Kbps. > > If you could get sysrq-p and sysrq-t output, that would be useful. Attached. sysrq-p seems to be empty though. sysrq.log is from s1 - sender sysrq2.log is from s2 - receiver > Also, check and see what your CPU load is, at the time. It goes from 60% system to 0% system when the problem appears. user is around 2-3% most of the time, it's just iperf generating packets. Baruch --------------070500030203030802020608 Content-Type: text/x-log; name="sysrq.log" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline; filename="sysrq.log" =FF=FD=03=FF=FB=03=FF=FB=01 Debian GNU/Linux 3.1 source1ng ttyS0 source1ng login: SysRq : Show State =00 sibling =00 task PC pid father child younger older =00init S C04FE040 5016 1 0 2 (NOTLB= ) =00dffa1e80 00000082 c14f2aa0 c04fe040 00000246 c0151c95 00000246 0000000= 0=20 =00 c04485a0 00000246 c04485a0 dffa1e94 c044a61c c044a374 00000000 = f737bc80=20 =00 000f42ec c14f2c08 000b696a dffa1e94 0000000b 00000000 c03d9bde = dffa1e94=20 =00Call Trace: =00 [] cache_grow+0x175/0x350 =00 [] schedule_timeout+0x8e/0xe0 =00 [] process_timeout+0x0/0x10 =00 [] do_select+0x28a/0x470 =00 [] __pollwait+0x0/0xd0 =00 [] sys_select+0x2db/0x5b0 =00 [] syscall_call+0x7/0xb =00ksoftirqd/0 S C04FE040 6736 2 1 3 (L-TLB= ) =00dffa3fb0 00000046 c14f2550 c04fe040 dff84114 dff84000 000b0034 c0124d7= 0=20 =00 dc538700 000f42e7 def0daa0 004dd1e0 dc538700 000f42e7 00000000 = df6cfc00=20 =00 000f42e7 c14f26b8 dffa2000 dffa1f50 00000000 c0124d70 c0124df3 = c14f2550=20 =00Call Trace: =00 [] ksoftirqd+0x0/0xa0 =00 [] ksoftirqd+0x0/0xa0 =00 [] ksoftirqd+0x83/0xa0 =00 [] kthread+0xaa/0xb0 =00 [] kthread+0x0/0xb0 =00 [] kernel_thread_helper+0x5/0x18 =00events/0 S C04FE040 6732 3 1 4 2 (L-TLB= ) =00dffa7f38 00000046 c14f2000 c04fe040 c14da6e0 c14da6c8 00000001 0000000= 3=20 =00 dffa7f38 00000086 c14da6c8 00000246 00000001 00000000 00000000 = f6eb7140=20 =00 000f42ec c14f2168 00000000 c14da680 c14da6a8 dffa7f94 c0135825 = 00000000=20 =00Call Trace: =00 [] worker_thread+0x435/0x460 =00 [] default_wake_function+0x0/0x20 =00 [] default_wake_function+0x0/0x20 =00 [] worker_thread+0x0/0x460 =00 [] kthread+0xaa/0xb0 =00 [] kthread+0x0/0xb0 =00 [] kernel_thread_helper+0x5/0x18 =00khelper S C04FE040 7192 4 1 9 3 (L-TLB= ) =00dffadf38 00000046 c14f8aa0 c04fe040 c14da5e0 c14da5c8 00000001 0000000= 3=20 =00 dffadf38 00000086 c14da5c8 00000246 00000001 deb07aa0 00000000 = 6d152880=20 =00 000f4206 c14f8c08 dea7dd64 c14da580 c14da5a8 dffadf94 c0135825 = 00000000=20 =00Call Trace: =00 [] worker_thread+0x435/0x460 =00 [] default_wake_function+0x0/0x20 =00 [] default_wake_function+0x0/0x20 =00 [] worker_thread+0x0/0x460 =00 [] kthread+0xaa/0xb0 =00 [] kthread+0x0/0xb0 =00 [] kernel_thread_helper+0x5/0x18 =00kthread S C04FE040 7240 9 1 17 173 4 (L-TLB= ) =00dffaff38 00000046 c14f8550 c04fe040 dff82de0 dff82dc8 00000001 0000000= 3=20 =00 dffaff38 00000086 dff82dc8 00000246 00000001 c1596aa0 00000000 = 45e62540=20 =00 000f41fa c14f86b8 dffa1ed4 dff82d80 dff82da8 dffaff94 c0135825 = 00000000=20 =00Call Trace: =00 [] worker_thread+0x435/0x460 =00 [] default_wake_function+0x0/0x20 =00 [] default_wake_function+0x0/0x20 =00 [] worker_thread+0x0/0x460 =00 [] kthread+0xaa/0xb0 =00 [] kthread+0x0/0xb0 =00 [] kernel_thread_helper+0x5/0x18 =00kacpid S C04FE040 7828 17 9 106 (L-TLB= ) =00dff09f38 00000046 c14f8000 c04fe040 00000000 dff08000 dff08000 c14f800= 0=20 =00 00010000 c0130e30 00010000 00000246 00000296 dff4aaa0 00000000 = 36b32780=20 =00 000f41fa c14f8168 dff08000 dff82280 dff822a8 dff09f94 c0135825 = 00000011=20 =00Call Trace: =00 [] do_sigaction+0x2e0/0x690 =00 [] worker_thread+0x435/0x460 =00 [] default_wake_function+0x0/0x20 =00 [] default_wake_function+0x0/0x20 =00 [] worker_thread+0x0/0x460 =00 [] kthread+0xaa/0xb0 =00 [] kthread+0x0/0xb0 =00 [] kernel_thread_helper+0x5/0x18 =00kblockd/0 S C04FE040 7368 106 9 171 17 (L-TLB= ) =00c1563f38 00000046 dff4aaa0 c04fe040 dff514e0 dff514c8 00000001 0000000= 3=20 =00 c1563f38 00000086 dff514c8 00000246 00000001 00000000 00000000 = d3413280=20 =00 000f42e1 dff4ac08 dfc4b988 dff51480 dff514a8 c1563f94 c0135825 = 00000000=20 =00Call Trace: =00 [] worker_thread+0x435/0x460 =00 [] default_wake_function+0x0/0x20 =00 [] default_wake_function+0x0/0x20 =00 [] worker_thread+0x0/0x460 =00 [] kthread+0xaa/0xb0 =00 [] kthread+0x0/0xb0 =00 [] kernel_thread_helper+0x5/0x18 =00pdflush S C04FE040 7876 171 9 172 106 (L-TLB= ) =00c15b7f68 00000046 dff4a550 c04fe040 c04fe088 000f41fa c04fe040 c14f855= 0=20 =00 c15b7f58 c15b7f68 00000086 00000286 c04fe040 dff4a000 00000000 = 45e62540=20 =00 000f41fa dff4a6b8 c15b7fb0 c15b7fa4 c15b6000 c014f760 c014f279 = c04fe088=20 =00Call Trace: =00 [] pdflush+0x0/0x30 =00 [] __pdflush+0x139/0x620 =00 [] pdflush+0x26/0x30 =00 [] pdflush+0x0/0x30 =00 [] kthread+0xaa/0xb0 =00 [] kthread+0x0/0xb0 =00 [] kernel_thread_helper+0x5/0x18 =00pdflush S C04FE040 6440 172 9 174 171 (L-TLB= ) =00c15b9f68 00000046 dff4a000 c04fe040 00000000 c15b9f1c 00000400 0000000= 0=20 =00 00000000 00000000 00000000 00000000 00000005 c15b9fa4 00000000 = 4db3bd80=20 =00 000f42ec dff4a168 c15b9fb0 c15b9fa4 c15b8000 c014f760 c014f279 = 00000000=20 =00Call Trace: =00 [] pdflush+0x0/0x30 =00 [] __pdflush+0x139/0x620 =00 [] pdflush+0x26/0x30 =00 [] pdflush+0x0/0x30 =00 [] kthread+0xaa/0xb0 =00 [] kthread+0x0/0xb0 =00 [] kernel_thread_helper+0x5/0x18 =00aio/0 S C04FE088 7828 174 9 172 (L-TLB= ) =00c15cdf38 00000046 c14f8aa0 c04fe088 000f41fa c15cc000 c15cc000 c159655= 0=20 =00 00010000 c0130e30 00010000 469d4040 000f41fa c14f8aa0 00000000 = 469d4040=20 =00 000f41fa c15966b8 c15cc000 c1589980 c15899a8 c15cdf94 c0135825 = 00000011=20 =00Call Trace: =00 [] do_sigaction+0x2e0/0x690 =00 [] worker_thread+0x435/0x460 =00 [] default_wake_function+0x0/0x20 =00 [] default_wake_function+0x0/0x20 =00 [] worker_thread+0x0/0x460 =00 [] kthread+0xaa/0xb0 =00 [] kthread+0x0/0xb0 =00 [] kernel_thread_helper+0x5/0x18 =00kswapd0 S C04FE040 7824 173 1 761 9 (L-TLB= ) =00c15cbf88 00000046 c1596aa0 c04fe040 00000296 c14f40ac c15ca000 c15ca00= 0=20 =00 c011fb20 c0449640 00000246 00000068 c15ca000 c14f2aa0 00000000 = 45e62540=20 =00 000f41fa c1596c08 c15ca000 00000000 c044a66c c044a220 c0157685 = c03f19dd=20 =00Call Trace: =00 [] reparent_to_init+0x100/0x170 =00 [] kswapd+0xf5/0x110 =00 [] autoremove_wake_function+0x0/0x60 =00 [] autoremove_wake_function+0x0/0x60 =00 [] kswapd+0x0/0x110 =00 [] kernel_thread_helper+0x5/0x18 =00kseriod S C04FE040 7912 761 1 802 173 (L-TLB= ) =00c15dff8c 00000046 c1596000 c04fe040 00000292 c1599cac c15de000 c15de00= 0=20 =00 00000296 00000000 00000246 c011fd3a c15de000 c14f2aa0 00000000 = 5dcceb80=20 =00 000f41fa c1596168 c15dffc0 ffffe000 c15de000 c15dffcc c02a268e = 0000000f=20 =00Call Trace: =00 [] allow_signal+0xea/0x210 =00 [] serio_thread+0xce/0x130 =00 [] autoremove_wake_function+0x0/0x60 =00 [] ret_from_fork+0x6/0x14 =00 [] autoremove_wake_function+0x0/0x60 =00 [] serio_thread+0x0/0x130 =00 [] kernel_thread_helper+0x5/0x18 =00scsi_eh_0 S C04FE040 7812 802 1 819 761 (L-TLB= ) =00dfc71f28 00000046 dfc46aa0 c04fe040 c0117ac2 c14f2aa0 c04fe088 000f41f= b=20 =00 c04fe040 c14f2aa0 dfc71f20 dfc71f30 00000082 c14f2aa0 00000000 = d3d1d240=20 =00 000f41fb dfc46c08 dfc71fb8 dfc71fc0 00000246 dfc46aa0 c03d7b1c = dfc71f58=20 =00Call Trace: =00 [] activate_task+0x62/0x80 =00 [] __down_interruptible+0x13c/0x334 =00 [] __wake_up_common+0x41/0x70 =00 [] default_wake_function+0x0/0x20 =00 [] __down_failed_interruptible+0x7/0xc =00 [] .text.lock.scsi_error+0x3b/0x43 =00 [] scsi_error_handler+0x0/0x150 =00 [] kernel_thread_helper+0x5/0x18 =00kjournald S C04FE040 6528 819 1 1779 802 (L-TLB= ) =00dfc93f34 00000046 dfc46550 c04fe040 dfc8acbc dfc8aca4 00000001 0000000= 3=20 =00 dfc93f34 00000282 00000246 00000003 00000001 00000000 00000000 = 0ab35d40=20 =00 000f42e9 dfc466b8 dfc8ac00 00000000 00000001 dfc8ace4 c020e2de = 00000000=20 =00Call Trace: =00 [] kjournald+0x4de/0x6c0 =00 [] autoremove_wake_function+0x0/0x60 =00 [] autoremove_wake_function+0x0/0x60 =00 [] commit_timeout+0x0/0x10 =00 [] kjournald+0x0/0x6c0 =00 [] kernel_thread_helper+0x5/0x18 =00dhclient S C04FE040 6576 1779 1 1790 819 (NOTLB= ) =00dfb2de80 00000082 dfb2b000 c04fe040 00000000 00000001 00000000 0000000= 0=20 =00 c04485a0 00000246 c04485a0 dfb2de94 00000246 dfb2baa0 00000000 = 1159e1c0=20 =00 000f4206 dfb2b168 028f5f41 dfb2de94 00000007 00000000 c03d9bde = dfb2de94=20 =00Call Trace: =00 [] schedule_timeout+0x8e/0xe0 =00 [] process_timeout+0x0/0x10 =00 [] sock_poll+0x29/0x40 =00 [] do_select+0x28a/0x470 =00 [] do_page_fault+0x1bc/0x5e9 =00 [] __pollwait+0x0/0xd0 =00 [] sys_select+0x2db/0x5b0 =00 [] syscall_call+0x7/0xb =00portmap S C04FE040 6556 1790 1 1848 1779 (NOTLB= ) =00df40def0 00000082 dfb2baa0 c04fe040 c025064c 00000246 df9da080 df40dfa= 0=20 =00 df7df918 c014cc3f 00000246 c018c29c df781080 dfba6000 00000000 = 5e8a0380=20 =00 000f4206 dfb2bc08 00000000 7fffffff df40df68 7fffffff c03d9c2a = df7df718=20 =00Call Trace: =00 [] copy_to_user+0x6c/0x80 =00 [] __get_free_pages+0x1f/0x40 =00 [] __pollwait+0x8c/0xd0 =00 [] schedule_timeout+0xda/0xe0 =00 [] sock_destroy_inode+0x1b/0x20 =00 [] sock_poll+0x29/0x40 =00 [] do_pollfd+0x5b/0xa0 =00 [] do_poll+0xa8/0xd0 =00 [] sys_poll+0x161/0x240 =00 [] __pollwait+0x0/0xd0 =00 [] syscall_call+0x7/0xb =00syslogd S C04FE040 6228 1848 1 1851 1790 (NOTLB= ) =00df3bbe80 00000082 dfd75550 c04fe040 00000246 c044a374 00000000 0000000= 0=20 =00 000000d0 c014cac3 c044a61c c044a374 000000d0 00000001 00000000 = af55a300=20 =00 000f42ec dfd756b8 00000000 7fffffff 00000001 00000000 c03d9c2a = 00000246=20 =00Call Trace: =00 [] __alloc_pages+0x2f3/0x450 =00 [] schedule_timeout+0xda/0xe0 =00 [] __get_free_pages+0x1f/0x40 =00 [] __pollwait+0x8c/0xd0 =00 [] datagram_poll+0x2b/0xd0 =00 [] sock_poll+0x29/0x40 =00 [] do_select+0x28a/0x470 =00 [] do_signal+0xc9/0x130 =00 [] __pollwait+0x0/0xd0 =00 [] sys_select+0x2db/0x5b0 =00 [] syscall_call+0x7/0xb =00klogd R running 6576 1851 1 1880 1848 (NOTLB)= =00acpid S C04FE040 6608 1880 1 1910 1851 (NOTLB= ) =00df421ef0 00000082 dfb2b550 c04fe040 c044a374 00000000 00000000 000000d= 0=20 =00 c014cac3 c044a61c c044a374 000000d0 00000001 00000000 00000000 = 2e8eb040=20 =00 000f4206 dfb2b6b8 00000000 7fffffff df421f68 7fffffff c03d9c2a = dfb53800=20 =00Call Trace: =00 [] __alloc_pages+0x2f3/0x450 =00 [] schedule_timeout+0xda/0xe0 =00 [] unix_poll+0x2b/0xb0 =00 [] sock_poll+0x29/0x40 =00 [] do_pollfd+0x5b/0xa0 =00 [] do_poll+0xa8/0xd0 =00 [] sys_poll+0x161/0x240 =00 [] __pollwait+0x0/0xd0 =00 [] syscall_call+0x7/0xb =00exim4 S C04FE040 6576 1910 1 1915 1880 (NOTLB= ) =00ded1de80 00000082 dfd75000 c04fe040 c044a61c c044a374 000000d0 0000000= 1=20 =00 00000000 00000000 00000001 00000000 dfd75000 00000010 00000000 = 44ca3780=20 =00 000f4206 dfd75168 00000000 7fffffff 00000001 00000000 c03d9c2a = c018c29c=20 =00Call Trace: =00 [] schedule_timeout+0xda/0xe0 =00 [] __pollwait+0x8c/0xd0 =00 [] tcp_poll+0x2d/0x190 =00 [] release_task+0x17c/0x260 =00 [] sock_poll+0x29/0x40 =00 [] do_select+0x28a/0x470 =00 [] do_page_fault+0x1bc/0x5e9 =00 [] __pollwait+0x0/0xd0 =00 [] sys_select+0x2db/0x5b0 =00 [] sys_waitpid+0x25/0x29 =00 [] syscall_call+0x7/0xb =00inetd S C04FE040 6576 1915 1 1919 1910 (NOTLB= ) =00dfbebe80 00000082 dfba6550 c04fe040 c044a61c c044a374 000000d0 0000000= 1=20 =00 00000000 00000000 00000001 00000000 00000246 00000010 0003d090 = 4182fbc0=20 =00 000f4206 dfba66b8 00000000 7fffffff 00000009 00000000 c03d9c2a = c03503eb=20 =00Call Trace: =00 [] schedule_timeout+0xda/0xe0 =00 [] datagram_poll+0x2b/0xd0 =00 [] tcp_poll+0x2d/0x190 =00 [] sock_poll+0x29/0x40 =00 [] do_select+0x28a/0x470 =00 [] do_page_fault+0x1bc/0x5e9 =00 [] __pollwait+0x0/0xd0 =00 [] sys_select+0x2db/0x5b0 =00 [] syscall_call+0x7/0xb =00lpd S C04FE040 6576 1919 1 1927 1915 (NOTLB= ) =00dedf3e80 00000082 dfba6aa0 c04fe040 00000246 c044a374 00000000 0000000= 0=20 =00 000000d0 c014cac3 c044a61c c044a374 000000d0 00000001 00000000 = 46fecac0=20 =00 000f4206 dfba6c08 00000000 7fffffff 00000006 00000000 c03d9c2a = 00000246=20 =00Call Trace: =00 [] __alloc_pages+0x2f3/0x450 =00 [] schedule_timeout+0xda/0xe0 =00 [] __get_free_pages+0x1f/0x40 =00 [] __pollwait+0x8c/0xd0 =00 [] unix_poll+0x2b/0xb0 =00 [] sock_poll+0x29/0x40 =00 [] do_select+0x28a/0x470 =00 [] notify_change+0x19f/0x25a =00 [] __pollwait+0x0/0xd0 =00 [] sys_select+0x2db/0x5b0 =00 [] syscall_call+0x7/0xb =00sshd S C04FE040 6576 1927 1 2017 1933 1919 (NOTLB= ) =00ded91e80 00000082 c17a7000 c04fe040 c044a61c c044a374 000000d0 0000000= 1=20 =00 00000000 00000000 00000001 00000000 c17a7000 deaa2aa0 00000000 = 5efcddc0=20 =00 000f42af c17a7168 00000000 7fffffff 00000004 00000000 c03d9c2a = c018c29c=20 =00Call Trace: =00 [] schedule_timeout+0xda/0xe0 =00 [] __pollwait+0x8c/0xd0 =00 [] tcp_poll+0x2d/0x190 =00 [] sock_poll+0x29/0x40 =00 [] do_select+0x28a/0x470 =00 [] clear_inode+0x5f/0xf0 =00 [] __pollwait+0x0/0xd0 =00 [] sys_select+0x2db/0x5b0 =00 [] syscall_call+0x7/0xb =00rpc.statd S C04FE040 6364 1933 1 1936 1927 (NOTLB= ) =00def75e80 00000082 dfba6000 c04fe040 00000000 00000001 00000000 dfba600= 0=20 =00 00000010 c044a61c 00000000 00000000 00000246 def26080 00000000 = 5e8a0380=20 =00 000f4206 dfba6168 00000000 7fffffff 00000007 00000000 c03d9c2a = c03503eb=20 =00Call Trace: =00 [] schedule_timeout+0xda/0xe0 =00 [] datagram_poll+0x2b/0xd0 =00 [] tcp_poll+0x2d/0x190 =00 [] sys_recvfrom+0x102/0x120 =00 [] sock_poll+0x29/0x40 =00 [] do_select+0x28a/0x470 =00 [] clear_inode+0x5f/0xf0 =00 [] __pollwait+0x0/0xd0 =00 [] sys_select+0x2db/0x5b0 =00 [] syscall_call+0x7/0xb =00ntpd S C04FE040 6092 1936 1 1941 1933 (NOTLB= ) =00de8e7e80 00000082 def0daa0 c04fe040 00000000 00000001 00000000 def0daa= 0=20 =00 00000010 c044a61c 00000000 bffffa10 00000246 de9ea680 00000000 = fc0bb2c0=20 =00 000f42ec def0dc08 00000000 7fffffff 00000009 00000000 c03d9c2a = c03503eb=20 =00Call Trace: =00 [] schedule_timeout+0xda/0xe0 =00 [] datagram_poll+0x2b/0xd0 =00 [] udp_poll+0x22/0x230 =00 [] sock_poll+0x29/0x40 =00 [] do_select+0x28a/0x470 =00 [] do_signal+0xc9/0x130 =00 [] __pollwait+0x0/0xd0 =00 [] sys_select+0x2db/0x5b0 =00 [] syscall_call+0x7/0xb =00atd S C04FE040 6576 1941 1 1944 1936 (NOTLB= ) =00dea2bf30 00000082 def0d550 c04fe040 c011614c dfa28c80 df9bcb1c 0000000= 0=20 =00 c04485a0 00000246 c04485a0 dea2bf44 dea2bfc4 00000000 00000000 = 61572d40=20 =00 000f4206 def0d6b8 003329f2 dea2bf44 000f41a7 00000e10 c03d9bde = dea2bf44=20 =00Call Trace: =00 [] do_page_fault+0x1bc/0x5e9 =00 [] schedule_timeout+0x8e/0xe0 =00 [] process_timeout+0x0/0x10 =00 [] sys_nanosleep+0xde/0x170 =00 [] syscall_call+0x7/0xb =00cron S C04FE040 6712 1944 1 1950 1941 (NOTLB= ) =00dea2df30 00000082 def0d000 c04fe040 00000060 00000803 00000000 0000000= 0=20 =00 c04485a0 00000246 c04485a0 dea2df44 00000000 00000000 00000000 = afb9f600=20 =00 000f42df def0d168 000b6183 dea2df44 000f41a7 0000003c c03d9bde = dea2df44=20 =00Call Trace: =00 [] schedule_timeout+0x8e/0xe0 =00 [] process_timeout+0x0/0x10 =00 [] sys_nanosleep+0xde/0x170 =00 [] syscall_call+0x7/0xb =00getty S C04FE040 6608 1950 1 1951 1944 (NOTLB= ) =00df8bde4c 00000082 c17a7aa0 c04fe040 00000000 00000001 0000001c 0000000= 0=20 =00 deb78220 00000000 00000008 00000202 00000203 c17a7550 00000000 = a6c7aa80=20 =00 000f4206 c17a7c08 df6be000 7fffffff 7fffffff 00000000 c03d9c2a = 00001961=20 =00Call Trace: =00 [] schedule_timeout+0xda/0xe0 =00 [] vgacon_cursor+0x16d/0x400 =00 [] set_cursor+0x6a/0x90 =00 [] read_chan+0xd0b/0xe40 =00 [] default_wake_function+0x0/0x20 =00 [] default_wake_function+0x0/0x20 =00 [] tty_write+0xb3/0x280 =00 [] tty_read+0xec/0x110 =00 [] vfs_read+0xae/0x130 =00 [] sys_read+0x51/0x80 =00 [] syscall_call+0x7/0xb =00getty S C04FE040 6980 1951 1 1952 1950 (NOTLB= ) =00df8cfe4c 00000082 c17a7550 c04fe040 00000000 00000001 0000001c 0000000= 0=20 =00 deb78220 00000000 00000008 00000202 00000203 dfc46000 00000000 = a6c7aa80=20 =00 000f4206 c17a76b8 de8ea000 7fffffff 7fffffff 00000000 c03d9c2a = 00000008=20 =00Call Trace: =00 [] schedule_timeout+0xda/0xe0 =00 [] do_con_write+0x266/0x680 =00 [] acquire_console_sem+0x2a/0x50 =00 [] read_chan+0xd0b/0xe40 =00 [] default_wake_function+0x0/0x20 =00 [] default_wake_function+0x0/0x20 =00 [] tty_write+0xb3/0x280 =00 [] tty_read+0xec/0x110 =00 [] vfs_read+0xae/0x130 =00 [] sys_read+0x51/0x80 =00 [] syscall_call+0x7/0xb =00getty S C04FE040 6980 1952 1 1953 1951 (NOTLB= ) =00ded2fe4c 00000082 dfc46000 c04fe040 00000000 00000001 0000001c 0000000= 0=20 =00 deb78220 00000000 00000008 00000202 00000203 dea4b550 00000000 = a6c7aa80=20 =00 000f4206 dfc46168 df6ac000 7fffffff 7fffffff 00000000 c03d9c2a = 00000008=20 =00Call Trace: =00 [] schedule_timeout+0xda/0xe0 =00 [] do_con_write+0x266/0x680 =00 [] acquire_console_sem+0x2a/0x50 =00 [] read_chan+0xd0b/0xe40 =00 [] default_wake_function+0x0/0x20 =00 [] default_wake_function+0x0/0x20 =00 [] tty_write+0xb3/0x280 =00 [] tty_read+0xec/0x110 =00 [] vfs_read+0xae/0x130 =00 [] sys_read+0x51/0x80 =00 [] syscall_call+0x7/0xb =00getty S C04FE088 6980 1953 1 1954 1952 (NOTLB= ) =00dea7fe4c 00000082 dea4b000 c04fe088 000f4206 00000001 0000001c 0000000= 0=20 =00 deb78220 00000000 00000008 a957cb40 000f4206 dea4b000 00000000 = a957cb40=20 =00 000f4206 dea4bc08 deb79000 7fffffff 7fffffff 00000000 c03d9c2a = 00000008=20 =00Call Trace: =00 [] schedule_timeout+0xda/0xe0 =00 [] do_con_write+0x266/0x680 =00 [] acquire_console_sem+0x2a/0x50 =00 [] read_chan+0xd0b/0xe40 =00 [] default_wake_function+0x0/0x20 =00 [] default_wake_function+0x0/0x20 =00 [] tty_write+0xb3/0x280 =00 [] tty_read+0xec/0x110 =00 [] vfs_read+0xae/0x130 =00 [] sys_read+0x51/0x80 =00 [] syscall_call+0x7/0xb =00getty S C04FE040 6980 1954 1 1955 1953 (NOTLB= ) =00de9c3e4c 00000082 dea4b550 c04fe040 00000000 00000001 0000001c 0000000= 0=20 =00 deb78220 00000000 00000008 00000202 00000203 dea22aa0 00000000 = a6c7aa80=20 =00 000f4206 dea4b6b8 deaa3000 7fffffff 7fffffff 00000000 c03d9c2a = 00000008=20 =00Call Trace: =00 [] schedule_timeout+0xda/0xe0 =00 [] do_con_write+0x266/0x680 =00 [] acquire_console_sem+0x2a/0x50 =00 [] read_chan+0xd0b/0xe40 =00 [] default_wake_function+0x0/0x20 =00 [] default_wake_function+0x0/0x20 =00 [] tty_write+0xb3/0x280 =00 [] tty_read+0xec/0x110 =00 [] vfs_read+0xae/0x130 =00 [] sys_read+0x51/0x80 =00 [] syscall_call+0x7/0xb =00getty S C04FE040 6980 1955 1 1956 1954 (NOTLB= ) =00dea7de4c 00000082 dea4b000 c04fe040 00000000 00000001 0000001c 0000000= 0=20 =00 deb78220 00000000 00000008 00000202 00000203 00000034 00000000 = a957cb40=20 =00 000f4206 dea4b168 deb2e000 7fffffff 7fffffff 00000000 c03d9c2a = 00000008=20 =00Call Trace: =00 [] schedule_timeout+0xda/0xe0 =00 [] do_con_write+0x266/0x680 =00 [] acquire_console_sem+0x2a/0x50 =00 [] read_chan+0xd0b/0xe40 =00 [] default_wake_function+0x0/0x20 =00 [] default_wake_function+0x0/0x20 =00 [] tty_write+0xb3/0x280 =00 [] tty_read+0xec/0x110 =00 [] vfs_read+0xae/0x130 =00 [] sys_read+0x51/0x80 =00 [] syscall_call+0x7/0xb =00getty S C04FE040 6964 1956 1 1955 (NOTLB= ) =00dea87e4c 00000082 dea22aa0 c04fe040 00100100 00200200 000aa653 1d244b3= c=20 =00 00000000 00000005 c03eed36 00000202 00000203 00000034 00000000 = 8067fac0=20 =00 000f42e2 dea22c08 dfc6b000 7fffffff 7fffffff 00000000 c03d9c2a = 00000001=20 =00Call Trace: =00 [] schedule_timeout+0xda/0xe0 =00 [] zap_pmd_range+0x53/0x70 =00 [] uart_write+0x15c/0x1e0 =00 [] read_chan+0xd0b/0xe40 =00 [] default_wake_function+0x0/0x20 =00 [] default_wake_function+0x0/0x20 =00 [] tty_write+0xb3/0x280 =00 [] tty_read+0xec/0x110 =00 [] vfs_read+0xae/0x130 =00 [] sys_read+0x51/0x80 =00 [] syscall_call+0x7/0xb =00sshd S C04FE040 6400 2017 1927 2019 2021 (NOTLB= ) =00deb2de80 00000082 dea22000 c04fe040 00000282 de434080 00000246 c0488cf= 8=20 =00 c0488ce0 00000001 00000003 deb2de8c 00000086 de524550 00000000 = 8866a740=20 =00 000f42e6 dea22168 00000000 7fffffff 00000008 00000000 c03d9c2a = deafca80=20 =00Call Trace: =00 [] schedule_timeout+0xda/0xe0 =00 [] normal_poll+0x11c/0x16b =00 [] tty_poll+0x89/0xc0 =00 [] sock_poll+0x29/0x40 =00 [] do_select+0x28a/0x470 =00 [] __pollwait+0x0/0xd0 =00 [] sys_select+0x2db/0x5b0 =00 [] do_IRQ+0x3b/0x70 =00 [] syscall_call+0x7/0xb =00bash S C04FE040 6496 2019 2017 2025 (NOTLB= ) =00deb69f1c 00000082 dea22550 c04fe040 01200011 c17a9680 c17a96ac deb6364= c=20 =00 dea22550 c011614c c17a9680 00000246 080e8080 00000001 00000000 = d13c6500=20 =00 000f42e5 dea226b8 dea225f0 dea22550 fffffe00 dea225f0 c0123157 = ffffffff=20 =00Call Trace: =00 [] do_page_fault+0x1bc/0x5e9 =00 [] do_wait+0x197/0x4f0 =00 [] session_of_pgrp+0x1e/0x90 =00 [] default_wake_function+0x0/0x20 =00 [] do_ioctl+0x58/0x80 =00 [] default_wake_function+0x0/0x20 =00 [] sys_rt_sigprocmask+0xaa/0x2a0 =00 [] sys_wait4+0x3d/0x50 =00 [] sys_waitpid+0x25/0x29 =00 [] syscall_call+0x7/0xb =00sshd S C04FE088 6176 2021 1927 2023 2017 (NOTLB= ) =00debfde80 00000082 deaa2550 c04fe088 000f42ed 00000030 00000246 c0488cf= 8=20 =00 c0488ce0 00000001 00000003 10e84640 000f42ed deaa2550 00000000 = 10e84640=20 =00 000f42ed deaa2c08 00000000 7fffffff 00000008 00000000 c03d9c2a = deb74080=20 =00Call Trace: =00 [] schedule_timeout+0xda/0xe0 =00 [] normal_poll+0x11c/0x16b =00 [] tty_poll+0x89/0xc0 =00 [] sock_poll+0x29/0x40 =00 [] do_select+0x28a/0x470 =00 [] __pollwait+0x0/0xd0 =00 [] sys_select+0x2db/0x5b0 =00 [] syscall_call+0x7/0xb =00bash R running 6520 2023 2021 (NOTLB)= =00iperf S C04FE040 6224 2025 2019 2026 (NOTLB= ) =00de523e60 00000082 deaa2000 c04fe040 c14dd180 df376f80 000000d0 c0151c9= 5=20 =00 c14dd180 df376f80 00000001 000000d0 004fa025 de524aa0 00000000 = d5870700=20 =00 000f42e5 deaa2168 00000000 7fffffff de522000 08056158 c03d9c2a = 08056000=20 =00Call Trace: =00 [] cache_grow+0x175/0x350 =00 [] schedule_timeout+0xda/0xe0 =00 [] find_extend_vma+0x29/0x90 =00 [] queue_me+0x8f/0x1c0 =00 [] get_futex_key+0x45/0x360 =00 [] futex_wait+0x171/0x1f0 =00 [] default_wake_function+0x0/0x20 =00 [] do_fork+0x199/0x1ef =00 [] default_wake_function+0x0/0x20 =00 [] mprotect_fixup+0x180/0x1e0 =00 [] do_futex+0x48/0xa0 =00 [] sys_futex+0xee/0x100 =00 [] sys_clone+0x3c/0x40 =00 [] syscall_call+0x7/0xb =00iperf S C04FE040 6860 2026 2019 2027 2025 (NOTLB= ) =00de625e60 00000082 de524aa0 c04fe040 000f42e6 df376f00 000000d0 c0151c9= 5=20 =00 c14dd180 df376f00 00000001 8866a740 000f42e6 de524550 00000000 = 8866a740=20 =00 000f42e6 de524c08 00000000 7fffffff de624000 08058298 c03d9c2a = 08058000=20 =00Call Trace: =00 [] cache_grow+0x175/0x350 =00 [] schedule_timeout+0xda/0xe0 =00 [] find_extend_vma+0x29/0x90 =00 [] queue_me+0x8f/0x1c0 =00 [] get_futex_key+0x45/0x360 =00 [] futex_wait+0x171/0x1f0 =00 [] default_wake_function+0x0/0x20 =00 [] default_wake_function+0x0/0x20 =00 [] do_futex+0x48/0xa0 =00 [] sys_futex+0xee/0x100 =00 [] sys_clone+0x3c/0x40 =00 [] syscall_call+0x7/0xb =00iperf S C04FE040 6296 2027 2019 2026 (NOTLB= ) =00de627d20 00000082 de524550 c04fe040 00000000 00000000 00000246 0000000= 0=20 =00 de524550 00000010 c044a61c 00000000 000000d0 def0daa0 000f4240 = df6cfc00=20 =00 000f42e7 de5246b8 de434080 7fffffff de627da4 00000000 c03d9c2a = 000000d0=20 =00Call Trace: =00 [] schedule_timeout+0xda/0xe0 =00 [] cache_grow+0x175/0x350 =00 [] __do_softirq+0x7b/0x90 =00 [] cache_alloc_refill+0x1fd/0x320 =00 [] sk_stream_wait_memory+0x16f/0x1e0 =00 [] autoremove_wake_function+0x0/0x60 =00 [] autoremove_wake_function+0x0/0x60 =00 [] copy_from_user+0x6c/0xa0 =00 [] tcp_sendmsg+0xbf0/0x1080 =00 [] inet_sendmsg+0x4d/0x60 =00 [] sock_aio_write+0xf6/0x120 =00 [] scheduler_tick+0xfd/0x3f0 =00 [] do_sync_write+0xb7/0xf0 =00 [] __do_softirq+0x7b/0x90 =00 [] do_IRQ+0x3b/0x70 =00 [] autoremove_wake_function+0x0/0x60 =00 [] vfs_write+0x118/0x130 =00 [] sys_write+0x51/0x80 =00 [] syscall_call+0x7/0xb =00SysRq : Show Regs =00 Debian GNU/Linux 3.1 source1ng ttyS0 source1ng login: SysRq : Show Regs --------------070500030203030802020608 Content-Type: text/x-log; name="sysrq2.log" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline; filename="sysrq2.log" =FF=FD=03=FF=FB=03=FF=FB=01SysRq : Show Regs =00SysRq : Show State =00 sibling =00 task PC pid father child younger older =00init S C04FE040 5016 1 0 2 (NOTLB= ) =00dffa1e80 00000082 c14f2aa0 c04fe040 00000246 c0151c95 00000246 0000000= 0=20 =00 c04485a0 00000246 c04485a0 dffa1e94 c044a61c c044a374 00000000 = e6b479c0=20 =00 000f4328 c14f2c08 000f56f7 dffa1e94 0000000b 00000000 c03d9bde = dffa1e94=20 =00Call Trace: =00 [] cache_grow+0x175/0x350 =00 [] schedule_timeout+0x8e/0xe0 =00 [] process_timeout+0x0/0x10 =00 [] do_select+0x28a/0x470 =00 [] __pollwait+0x0/0xd0 =00 [] sys_select+0x2db/0x5b0 =00 [] syscall_call+0x7/0xb =00ksoftirqd/0 S C04FE040 7856 2 1 3 (L-TLB= ) =00dffa3fb0 00000046 c14f2550 c04fe040 dfa9a970 00000000 c050f448 0000000= 7=20 =00 c01371ff c0449948 c0449970 c050ffc0 c0124c60 00000000 00000000 = cfa63480=20 =00 000f41fc c14f26b8 dffa2000 dffa1f50 00000000 c0124d70 c0124df3 = c14f2550=20 =00Call Trace: =00 [] rcu_process_callbacks+0x3f/0x50 =00 [] tasklet_action+0x40/0x60 =00 [] ksoftirqd+0x0/0xa0 =00 [] ksoftirqd+0x83/0xa0 =00 [] kthread+0xaa/0xb0 =00 [] kthread+0x0/0xb0 =00 [] kernel_thread_helper+0x5/0x18 =00events/0 S C04FE088 6724 3 1 4 2 (L-TLB= ) =00dffa7f38 00000046 dff4a000 c04fe088 000f4328 c14da6c8 00000001 0000000= 3=20 =00 dffa7f38 00000086 c14da6c8 e6b479c0 000f4328 dff4a000 00000000 = e6b479c0=20 =00 000f4328 c14f2168 00000000 c14da680 c14da6a8 dffa7f94 c0135825 = 00000000=20 =00Call Trace: =00 [] worker_thread+0x435/0x460 =00 [] default_wake_function+0x0/0x20 =00 [] default_wake_function+0x0/0x20 =00 [] worker_thread+0x0/0x460 =00 [] kthread+0xaa/0xb0 =00 [] kthread+0x0/0xb0 =00 [] kernel_thread_helper+0x5/0x18 =00khelper S C04FE040 7192 4 1 9 3 (L-TLB= ) =00dffadf38 00000046 c14f8aa0 c04fe040 c14da5e0 c14da5c8 00000001 0000000= 3=20 =00 dffadf38 00000086 c14da5c8 00000246 00000001 de6f4aa0 00000000 = 499dae00=20 =00 000f4205 c14f8c08 de5c3d64 c14da580 c14da5a8 dffadf94 c0135825 = 00000000=20 =00Call Trace: =00 [] worker_thread+0x435/0x460 =00 [] default_wake_function+0x0/0x20 =00 [] default_wake_function+0x0/0x20 =00 [] worker_thread+0x0/0x460 =00 [] kthread+0xaa/0xb0 =00 [] kthread+0x0/0xb0 =00 [] kernel_thread_helper+0x5/0x18 =00kthread S C04FE040 7240 9 1 17 173 4 (L-TLB= ) =00dffaff38 00000046 c14f8550 c04fe040 dff82de0 dff82dc8 00000001 0000000= 3=20 =00 dffaff38 00000086 dff82dc8 00000246 00000001 c1596aa0 00000000 = 4599da00=20 =00 000f41fa c14f86b8 dffa1ed4 dff82d80 dff82da8 dffaff94 c0135825 = 00000000=20 =00Call Trace: =00 [] worker_thread+0x435/0x460 =00 [] default_wake_function+0x0/0x20 =00 [] default_wake_function+0x0/0x20 =00 [] worker_thread+0x0/0x460 =00 [] kthread+0xaa/0xb0 =00 [] kthread+0x0/0xb0 =00 [] kernel_thread_helper+0x5/0x18 =00kacpid S C04FE040 7828 17 9 106 (L-TLB= ) =00dff09f38 00000046 c14f8000 c04fe040 00000000 dff08000 dff08000 c14f800= 0=20 =00 00010000 c0130e30 00010000 00000246 00000296 c14f2aa0 00000000 = 3666dc40=20 =00 000f41fa c14f8168 dff08000 dff82280 dff822a8 dff09f94 c0135825 = 00000011=20 =00Call Trace: =00 [] do_sigaction+0x2e0/0x690 =00 [] worker_thread+0x435/0x460 =00 [] default_wake_function+0x0/0x20 =00 [] default_wake_function+0x0/0x20 =00 [] worker_thread+0x0/0x460 =00 [] kthread+0xaa/0xb0 =00 [] kthread+0x0/0xb0 =00 [] kernel_thread_helper+0x5/0x18 =00kblockd/0 S C04FE040 7164 106 9 171 17 (L-TLB= ) =00c1563f38 00000046 dff4aaa0 c04fe040 dff514e0 dff514c8 00000001 0000000= 3=20 =00 c1563f38 00000086 dff514c8 00000246 00000001 00000000 00000000 = 92d65c80=20 =00 000f4326 dff4ac08 dfc4a988 dff51480 dff514a8 c1563f94 c0135825 = 00000000=20 =00Call Trace: =00 [] worker_thread+0x435/0x460 =00 [] default_wake_function+0x0/0x20 =00 [] default_wake_function+0x0/0x20 =00 [] worker_thread+0x0/0x460 =00 [] kthread+0xaa/0xb0 =00 [] kthread+0x0/0xb0 =00 [] kernel_thread_helper+0x5/0x18 =00pdflush S C04FE040 7876 171 9 172 106 (L-TLB= ) =00c15b7f68 00000046 dff4a550 c04fe040 c04fe088 000f41fa c04fe040 c14f855= 0=20 =00 c15b7f58 c15b7f68 00000086 00000286 c04fe040 dff4a000 00000000 = 4599da00=20 =00 000f41fa dff4a6b8 c15b7fb0 c15b7fa4 c15b6000 c014f760 c014f279 = c04fe088=20 =00Call Trace: =00 [] pdflush+0x0/0x30 =00 [] __pdflush+0x139/0x620 =00 [] pdflush+0x26/0x30 =00 [] pdflush+0x0/0x30 =00 [] kthread+0xaa/0xb0 =00 [] kthread+0x0/0xb0 =00 [] kernel_thread_helper+0x5/0x18 =00pdflush S C04FE088 6440 172 9 174 171 (L-TLB= ) =00c15b9f68 00000046 c14f2aa0 c04fe088 000f4328 c15b9f1c 000003f2 0000000= e=20 =00 00000000 00000000 00000000 e6b479c0 000f4328 c14f2aa0 00000000 = e6b479c0=20 =00 000f4328 dff4a168 c15b9fb0 c15b9fa4 c15b8000 c014f760 c014f279 = 00000000=20 =00Call Trace: =00 [] pdflush+0x0/0x30 =00 [] __pdflush+0x139/0x620 =00 [] pdflush+0x26/0x30 =00 [] pdflush+0x0/0x30 =00 [] kthread+0xaa/0xb0 =00 [] kthread+0x0/0xb0 =00 [] kernel_thread_helper+0x5/0x18 =00aio/0 S C04FE088 7828 174 9 172 (L-TLB= ) =00c15cdf38 00000046 c14f8aa0 c04fe088 000f41fa c15cc000 c15cc000 c159655= 0=20 =00 00010000 c0130e30 00010000 4641b2c0 000f41fa c14f8aa0 00000000 = 4641b2c0=20 =00 000f41fa c15966b8 c15cc000 c1589980 c15899a8 c15cdf94 c0135825 = 00000011=20 =00Call Trace: =00 [] do_sigaction+0x2e0/0x690 =00 [] worker_thread+0x435/0x460 =00 [] default_wake_function+0x0/0x20 =00 [] default_wake_function+0x0/0x20 =00 [] worker_thread+0x0/0x460 =00 [] kthread+0xaa/0xb0 =00 [] kthread+0x0/0xb0 =00 [] kernel_thread_helper+0x5/0x18 =00kswapd0 S C04FE040 7824 173 1 761 9 (L-TLB= ) =00c15cbf88 00000046 c1596aa0 c04fe040 00000296 c14f40ac c15ca000 c15ca00= 0=20 =00 c011fb20 c0449640 00000246 00000068 c15ca000 c14f2aa0 00000000 = 4599da00=20 =00 000f41fa c1596c08 c15ca000 00000000 c044a66c c044a220 c0157685 = c03f19dd=20 =00Call Trace: =00 [] reparent_to_init+0x100/0x170 =00 [] kswapd+0xf5/0x110 =00 [] autoremove_wake_function+0x0/0x60 =00 [] autoremove_wake_function+0x0/0x60 =00 [] kswapd+0x0/0x110 =00 [] kernel_thread_helper+0x5/0x18 =00kseriod S C04FE040 7912 761 1 802 173 (L-TLB= ) =00c15dff8c 00000046 c1596000 c04fe040 00000292 c1599cac c15de000 c15de00= 0=20 =00 00000296 00000000 00000246 c011fd3a c15de000 c14f2aa0 00000000 = 5d80a040=20 =00 000f41fa c1596168 c15dffc0 ffffe000 c15de000 c15dffcc c02a268e = 0000000f=20 =00Call Trace: =00 [] allow_signal+0xea/0x210 =00 [] serio_thread+0xce/0x130 =00 [] autoremove_wake_function+0x0/0x60 =00 [] ret_from_fork+0x6/0x14 =00 [] autoremove_wake_function+0x0/0x60 =00 [] serio_thread+0x0/0x130 =00 [] kernel_thread_helper+0x5/0x18 =00scsi_eh_0 S C04FE040 7812 802 1 819 761 (L-TLB= ) =00dfc71f28 00000046 dfc45aa0 c04fe040 c0117ac2 c14f2aa0 c04fe088 000f41f= b=20 =00 c04fe040 c14f2aa0 dfc71f20 dfc71f30 00000082 c14f2aa0 00000000 = c4158040=20 =00 000f41fb dfc45c08 dfc71fb8 dfc71fc0 00000246 dfc45aa0 c03d7b1c = dfc71f58=20 =00Call Trace: =00 [] activate_task+0x62/0x80 =00 [] __down_interruptible+0x13c/0x334 =00 [] __wake_up_common+0x41/0x70 =00 [] default_wake_function+0x0/0x20 =00 [] __down_failed_interruptible+0x7/0xc =00 [] .text.lock.scsi_error+0x3b/0x43 =00 [] scsi_error_handler+0x0/0x150 =00 [] kernel_thread_helper+0x5/0x18 =00kjournald S C04FE040 6528 819 1 1671 802 (L-TLB= ) =00dfc93f34 00000046 dfc45550 c04fe040 dfc89cbc dfc89ca4 00000001 0000000= 3=20 =00 dfc93f34 00000282 00000246 00000003 00000001 00000000 00000000 = 1e032280=20 =00 000f4326 dfc456b8 dfc89c00 00000000 00000001 dfc89ce4 c020e2de = 00000000=20 =00Call Trace: =00 [] kjournald+0x4de/0x6c0 =00 [] autoremove_wake_function+0x0/0x60 =00 [] autoremove_wake_function+0x0/0x60 =00 [] commit_timeout+0x0/0x10 =00 [] kjournald+0x0/0x6c0 =00 [] kernel_thread_helper+0x5/0x18 =00dhclient S C04FE040 6576 1671 1 1682 819 (NOTLB= ) =00dfbd9e80 00000082 df850000 c04fe040 00000000 00000001 00000000 0000000= 0=20 =00 c04485a0 00000246 c04485a0 dfbd9e94 00000246 c17cdc80 00000000 = 2ee9be00=20 =00 000f4205 df850168 028f4f50 dfbd9e94 00000007 00000000 c03d9bde = dfbd9e94=20 =00Call Trace: =00 [] schedule_timeout+0x8e/0xe0 =00 [] process_timeout+0x0/0x10 =00 [] sock_poll+0x29/0x40 =00 [] do_select+0x28a/0x470 =00 [] do_page_fault+0x1bc/0x5e9 =00 [] __pollwait+0x0/0xd0 =00 [] sys_select+0x2db/0x5b0 =00 [] syscall_call+0x7/0xb =00portmap S C04FE040 6556 1682 1 1739 1671 (NOTLB= ) =00dfbb7ef0 00000082 dfba7000 c04fe040 c025064c 00000246 dfb0db80 dfbb7fa= 0=20 =00 df6a7918 c014cc3f 00000246 c018c29c df031080 dea45000 00000000 = 3dc12e40=20 =00 000f4205 dfba7168 00000000 7fffffff dfbb7f68 7fffffff c03d9c2a = df6a7718=20 =00Call Trace: =00 [] copy_to_user+0x6c/0x80 =00 [] __get_free_pages+0x1f/0x40 =00 [] __pollwait+0x8c/0xd0 =00 [] schedule_timeout+0xda/0xe0 =00 [] sock_destroy_inode+0x1b/0x20 =00 [] sock_poll+0x29/0x40 =00 [] do_pollfd+0x5b/0xa0 =00 [] do_poll+0xa8/0xd0 =00 [] sys_poll+0x161/0x240 =00 [] __pollwait+0x0/0xd0 =00 [] syscall_call+0x7/0xb =00syslogd S C04FE040 6444 1739 1 1742 1682 (NOTLB= ) =00deecde80 00000082 dfad9550 c04fe040 00000246 c044a374 00000000 0000000= 0=20 =00 000000d0 c014cac3 c044a61c c044a374 000000d0 00000001 00000000 = c5074280=20 =00 000f4328 dfad96b8 00000000 7fffffff 00000001 00000000 c03d9c2a = 00000246=20 =00Call Trace: =00 [] __alloc_pages+0x2f3/0x450 =00 [] schedule_timeout+0xda/0xe0 =00 [] __get_free_pages+0x1f/0x40 =00 [] __pollwait+0x8c/0xd0 =00 [] datagram_poll+0x2b/0xd0 =00 [] sock_poll+0x29/0x40 =00 [] do_select+0x28a/0x470 =00 [] do_signal+0xc9/0x130 =00 [] __pollwait+0x0/0xd0 =00 [] sys_select+0x2db/0x5b0 =00 [] syscall_call+0x7/0xb =00klogd R running 6448 1742 1 1771 1739 (NOTLB)= =00acpid S C04FE040 6704 1771 1 1801 1742 (NOTLB= ) =00dfb3def0 00000082 dfad9000 c04fe040 c044a374 00000000 00000000 000000d= 0=20 =00 c014cac3 c044a61c c044a374 000000d0 00000001 00000000 00000000 = 0acaea80=20 =00 000f4205 dfad9168 00000000 7fffffff dfb3df68 7fffffff c03d9c2a = dfb53800=20 =00Call Trace: =00 [] __alloc_pages+0x2f3/0x450 =00 [] schedule_timeout+0xda/0xe0 =00 [] unix_poll+0x2b/0xb0 =00 [] sock_poll+0x29/0x40 =00 [] do_pollfd+0x5b/0xa0 =00 [] do_poll+0xa8/0xd0 =00 [] sys_poll+0x161/0x240 =00 [] __pollwait+0x0/0xd0 =00 [] syscall_call+0x7/0xb =00exim4 S C04FE040 6576 1801 1 1806 1771 (NOTLB= ) =00dea21e80 00000082 dfba7550 c04fe040 c044a61c c044a374 000000d0 0000000= 1=20 =00 00000000 00000000 00000001 00000000 dfba7550 00000010 00000000 = 248ab680=20 =00 000f4205 dfba76b8 00000000 7fffffff 00000001 00000000 c03d9c2a = c018c29c=20 =00Call Trace: =00 [] schedule_timeout+0xda/0xe0 =00 [] __pollwait+0x8c/0xd0 =00 [] tcp_poll+0x2d/0x190 =00 [] release_task+0x17c/0x260 =00 [] sock_poll+0x29/0x40 =00 [] do_select+0x28a/0x470 =00 [] do_page_fault+0x1bc/0x5e9 =00 [] __pollwait+0x0/0xd0 =00 [] sys_select+0x2db/0x5b0 =00 [] sys_waitpid+0x25/0x29 =00 [] syscall_call+0x7/0xb =00inetd S C04FE040 6576 1806 1 1811 1801 (NOTLB= ) =00dfafbe80 00000082 dfad9aa0 c04fe040 c044a61c c044a374 000000d0 0000000= 1=20 =00 00000000 00000000 00000001 00000000 00000246 dea45550 00051615 = 20c968c0=20 =00 000f4205 dfad9c08 00000000 7fffffff 00000009 00000000 c03d9c2a = c03503eb=20 =00Call Trace: =00 [] schedule_timeout+0xda/0xe0 =00 [] datagram_poll+0x2b/0xd0 =00 [] tcp_poll+0x2d/0x190 =00 [] sock_poll+0x29/0x40 =00 [] do_select+0x28a/0x470 =00 [] do_page_fault+0x1bc/0x5e9 =00 [] __pollwait+0x0/0xd0 =00 [] sys_select+0x2db/0x5b0 =00 [] syscall_call+0x7/0xb =00lpd S C04FE040 6576 1811 1 1825 1806 (NOTLB= ) =00de9ffe80 00000082 dfba7aa0 c04fe040 00000246 c044a374 00000000 0000000= 0=20 =00 000000d0 c014cac3 c044a61c c044a374 000000d0 00000001 00000000 = 2663bc40=20 =00 000f4205 dfba7c08 00000000 7fffffff 00000006 00000000 c03d9c2a = 00000246=20 =00Call Trace: =00 [] __alloc_pages+0x2f3/0x450 =00 [] schedule_timeout+0xda/0xe0 =00 [] __get_free_pages+0x1f/0x40 =00 [] __pollwait+0x8c/0xd0 =00 [] unix_poll+0x2b/0xb0 =00 [] sock_poll+0x29/0x40 =00 [] do_select+0x28a/0x470 =00 [] notify_change+0x19f/0x25a =00 [] __pollwait+0x0/0xd0 =00 [] sys_select+0x2db/0x5b0 =00 [] syscall_call+0x7/0xb =00sshd S C04FE040 6576 1825 1 1915 1831 1811 (NOTLB= ) =00dea93e80 00000082 dea45aa0 c04fe040 c044a61c c044a374 000000d0 0000000= 1=20 =00 00000000 00000000 00000001 00000000 dea45aa0 00000010 00000000 = ce8a2dc0=20 =00 000f431b dea45c08 00000000 7fffffff 00000004 00000000 c03d9c2a = c018c29c=20 =00Call Trace: =00 [] schedule_timeout+0xda/0xe0 =00 [] __pollwait+0x8c/0xd0 =00 [] tcp_poll+0x2d/0x190 =00 [] sock_poll+0x29/0x40 =00 [] do_select+0x28a/0x470 =00 [] clear_inode+0x5f/0xf0 =00 [] __pollwait+0x0/0xd0 =00 [] sys_select+0x2db/0x5b0 =00 [] syscall_call+0x7/0xb =00rpc.statd S C04FE040 6472 1831 1 1834 1825 (NOTLB= ) =00de457e80 00000082 dea45000 c04fe040 00000000 00000001 00000000 dea4500= 0=20 =00 00000010 c044a61c 00000000 00000000 00000246 de47fe80 00022e09 = 3dd07080=20 =00 000f4205 dea45168 00000000 7fffffff 00000007 00000000 c03d9c2a = c03503eb=20 =00Call Trace: =00 [] schedule_timeout+0xda/0xe0 =00 [] datagram_poll+0x2b/0xd0 =00 [] tcp_poll+0x2d/0x190 =00 [] sys_recvfrom+0x102/0x120 =00 [] sock_poll+0x29/0x40 =00 [] do_select+0x28a/0x470 =00 [] scheduler_tick+0xfd/0x3f0 =00 [] __pollwait+0x0/0xd0 =00 [] sys_select+0x2db/0x5b0 =00 [] do_IRQ+0x3b/0x70 =00 [] syscall_call+0x7/0xb =00ntpd S C04FE040 6492 1834 1 1839 1831 (NOTLB= ) =00de4f9e80 00000082 de47eaa0 c04fe040 00000000 00000001 00000000 de47eaa= 0=20 =00 00000010 c044a61c 00000000 bffffa10 00000246 dfa50980 00000000 = 24284980=20 =00 000f4329 de47ec08 00000000 7fffffff 00000009 00000000 c03d9c2a = c03503eb=20 =00Call Trace: =00 [] schedule_timeout+0xda/0xe0 =00 [] datagram_poll+0x2b/0xd0 =00 [] udp_poll+0x22/0x230 =00 [] sock_poll+0x29/0x40 =00 [] do_select+0x28a/0x470 =00 [] do_signal+0xc9/0x130 =00 [] __pollwait+0x0/0xd0 =00 [] sys_select+0x2db/0x5b0 =00 [] syscall_call+0x7/0xb =00atd S C04FE040 6576 1839 1 1842 1834 (NOTLB= ) =00de5cbf30 00000082 de47e550 c04fe040 c011614c df84e080 dfbad074 0000000= 0=20 =00 c04485a0 00000246 c04485a0 de5cbf44 de5cbfc4 00000000 00000000 = 40420cc0=20 =00 000f4205 de47e6b8 00331700 de5cbf44 000f41a7 00000e10 c03d9bde = de5cbf44=20 =00Call Trace: =00 [] do_page_fault+0x1bc/0x5e9 =00 [] schedule_timeout+0x8e/0xe0 =00 [] process_timeout+0x0/0x10 =00 [] sys_nanosleep+0xde/0x170 =00 [] syscall_call+0x7/0xb =00cron S C04FE040 6712 1842 1 1848 1839 (NOTLB= ) =00de66df30 00000082 de47e000 c04fe040 00000060 00000803 00000000 0000000= 0=20 =00 c04485a0 00000246 c04485a0 de66df44 00000000 00000000 00000000 = e0704e80=20 =00 000f4324 de47e168 000fea55 de66df44 000f41a7 0000003c c03d9bde = de66df44=20 =00Call Trace: =00 [] schedule_timeout+0x8e/0xe0 =00 [] process_timeout+0x0/0x10 =00 [] sys_nanosleep+0xde/0x170 =00 [] syscall_call+0x7/0xb =00getty S C04FE040 6608 1848 1 1849 1842 (NOTLB= ) =00df85de4c 00000082 df850aa0 c04fe040 00000000 00000001 0000001c 0000000= 0=20 =00 de6f2a30 00000000 00000008 00000202 00000203 00000207 00000000 = 836eb480=20 =00 000f4205 df850c08 de684000 7fffffff 7fffffff 00000000 c03d9c2a = 00001961=20 =00Call Trace: =00 [] schedule_timeout+0xda/0xe0 =00 [] vgacon_cursor+0x16d/0x400 =00 [] set_cursor+0x6a/0x90 =00 [] read_chan+0xd0b/0xe40 =00 [] default_wake_function+0x0/0x20 =00 [] default_wake_function+0x0/0x20 =00 [] tty_write+0xb3/0x280 =00 [] tty_read+0xec/0x110 =00 [] vfs_read+0xae/0x130 =00 [] sys_read+0x51/0x80 =00 [] syscall_call+0x7/0xb =00getty S C04FE040 6980 1849 1 1850 1848 (NOTLB= ) =00df85fe4c 00000082 df850550 c04fe040 00000000 00000001 0000001c 0000000= 0=20 =00 de6f2a30 00000000 00000008 00000202 00000203 00000034 00000000 = 8519f380=20 =00 000f4205 df8506b8 de689000 7fffffff 7fffffff 00000000 c03d9c2a = 00000008=20 =00Call Trace: =00 [] schedule_timeout+0xda/0xe0 =00 [] do_con_write+0x266/0x680 =00 [] acquire_console_sem+0x2a/0x50 =00 [] read_chan+0xd0b/0xe40 =00 [] default_wake_function+0x0/0x20 =00 [] default_wake_function+0x0/0x20 =00 [] tty_write+0xb3/0x280 =00 [] tty_read+0xec/0x110 =00 [] vfs_read+0xae/0x130 =00 [] sys_read+0x51/0x80 =00 [] syscall_call+0x7/0xb =00getty S C04FE040 6980 1850 1 1851 1849 (NOTLB= ) =00deae5e4c 00000082 dea45550 c04fe040 00000000 00000001 0000001c 0000000= 0=20 =00 de6f2a30 00000000 00000008 00000202 00000203 00000034 00000000 = 8556fc80=20 =00 000f4205 dea456b8 de68f000 7fffffff 7fffffff 00000000 c03d9c2a = 00000008=20 =00Call Trace: =00 [] schedule_timeout+0xda/0xe0 =00 [] do_con_write+0x266/0x680 =00 [] acquire_console_sem+0x2a/0x50 =00 [] read_chan+0xd0b/0xe40 =00 [] default_wake_function+0x0/0x20 =00 [] default_wake_function+0x0/0x20 =00 [] tty_write+0xb3/0x280 =00 [] tty_read+0xec/0x110 =00 [] vfs_read+0xae/0x130 =00 [] sys_read+0x51/0x80 =00 [] syscall_call+0x7/0xb =00getty S C04FE500 6576 1851 1 1852 1850 (NOTLB= ) =00de67fe4c 00000082 de647550 c04fe500 000f4205 00000001 0000001c 0000000= 0=20 =00 de6f2a30 00000000 00000008 85940580 000f4205 de647550 00000000 = 85940580=20 =00 000f4205 de647c08 de688000 7fffffff 7fffffff 00000000 c03d9c2a = 00000008=20 =00Call Trace: =00 [] schedule_timeout+0xda/0xe0 =00 [] do_con_write+0x266/0x680 =00 [] acquire_console_sem+0x2a/0x50 =00 [] read_chan+0xd0b/0xe40 =00 [] default_wake_function+0x0/0x20 =00 [] default_wake_function+0x0/0x20 =00 [] tty_write+0xb3/0x280 =00 [] tty_read+0xec/0x110 =00 [] vfs_read+0xae/0x130 =00 [] sys_read+0x51/0x80 =00 [] syscall_call+0x7/0xb =00getty S C04FE040 6980 1852 1 1853 1851 (NOTLB= ) =00de50be4c 00000082 de647550 c04fe040 00000000 00000001 0000001c 0000000= 0=20 =00 de6f2a30 00000000 00000008 00000202 00000203 00000034 00000000 = 85940580=20 =00 000f4205 de6476b8 de6a5000 7fffffff 7fffffff 00000000 c03d9c2a = 00000008=20 =00Call Trace: =00 [] schedule_timeout+0xda/0xe0 =00 [] do_con_write+0x266/0x680 =00 [] acquire_console_sem+0x2a/0x50 =00 [] read_chan+0xd0b/0xe40 =00 [] default_wake_function+0x0/0x20 =00 [] default_wake_function+0x0/0x20 =00 [] tty_write+0xb3/0x280 =00 [] tty_read+0xec/0x110 =00 [] vfs_read+0xae/0x130 =00 [] sys_read+0x51/0x80 =00 [] syscall_call+0x7/0xb =00getty S C04FE040 6980 1853 1 1854 1852 (NOTLB= ) =00de5c3e4c 00000082 de647000 c04fe040 00000000 00000001 0000001c 0000000= 0=20 =00 de6f2a30 00000000 00000008 00000202 00000203 00000034 00000000 = 863bde40=20 =00 000f4205 de647168 de6ba000 7fffffff 7fffffff 00000000 c03d9c2a = 00000008=20 =00Call Trace: =00 [] schedule_timeout+0xda/0xe0 =00 [] do_con_write+0x266/0x680 =00 [] acquire_console_sem+0x2a/0x50 =00 [] read_chan+0xd0b/0xe40 =00 [] default_wake_function+0x0/0x20 =00 [] default_wake_function+0x0/0x20 =00 [] tty_write+0xb3/0x280 =00 [] tty_read+0xec/0x110 =00 [] vfs_read+0xae/0x130 =00 [] sys_read+0x51/0x80 =00 [] syscall_call+0x7/0xb =00getty S C04FE040 6964 1854 1 1853 (NOTLB= ) =00de667e4c 00000082 de643aa0 c04fe040 00100100 00200200 fffc2af7 1d244b3= c=20 =00 00000000 00000005 c03eed36 00000202 00000203 00000034 00000000 = 86976bc0=20 =00 000f4205 de643c08 dfc6a000 7fffffff 7fffffff 00000000 c03d9c2a = 00000001=20 =00Call Trace: =00 [] schedule_timeout+0xda/0xe0 =00 [] zap_pmd_range+0x53/0x70 =00 [] uart_write+0x15c/0x1e0 =00 [] read_chan+0xd0b/0xe40 =00 [] default_wake_function+0x0/0x20 =00 [] default_wake_function+0x0/0x20 =00 [] tty_read+0xec/0x110 =00 [] vfs_read+0xae/0x130 =00 [] sys_read+0x51/0x80 =00 [] syscall_call+0x7/0xb =00sshd S C04FE040 6400 1915 1825 1917 1923 (NOTLB= ) =00de74de80 00000082 de643000 c04fe040 00000282 00000060 00000246 c0488cf= 8=20 =00 c0488ce0 00000001 00000003 de74de8c 00000086 c0488ce0 00000000 = 2f5bf100=20 =00 000f4327 de643168 00000000 7fffffff 00000008 00000000 c03d9c2a = de6e6580=20 =00Call Trace: =00 [] schedule_timeout+0xda/0xe0 =00 [] normal_poll+0x11c/0x16b =00 [] tty_poll+0x89/0xc0 =00 [] sock_poll+0x29/0x40 =00 [] do_select+0x28a/0x470 =00 [] __pollwait+0x0/0xd0 =00 [] sys_select+0x2db/0x5b0 =00 [] syscall_call+0x7/0xb =00bash S C04FE040 6616 1917 1915 1919 (NOTLB= ) =00de749f1c 00000082 de643550 c04fe040 01200011 df838c80 df838cac de7375f= 4=20 =00 de643550 c011614c df838c80 00000246 080ed208 00000001 00000000 = 77e2f880=20 =00 000f42e4 de6436b8 de6435f0 de643550 fffffe00 de6435f0 c0123157 = ffffffff=20 =00Call Trace: =00 [] do_page_fault+0x1bc/0x5e9 =00 [] do_wait+0x197/0x4f0 =00 [] session_of_pgrp+0x1e/0x90 =00 [] default_wake_function+0x0/0x20 =00 [] do_ioctl+0x58/0x80 =00 [] default_wake_function+0x0/0x20 =00 [] sys_rt_sigprocmask+0xaa/0x2a0 =00 [] sys_wait4+0x3d/0x50 =00 [] sys_waitpid+0x25/0x29 =00 [] syscall_call+0x7/0xb =00iperf S C04FE040 6224 1919 1917 1920 (NOTLB= ) =00de7fde60 00000082 de7fbaa0 c04fe040 dfd465bc 000000a9 000000d0 c0151c9= 5=20 =00 c14dd180 dee72d80 00000001 df838080 00000001 c014833e 00000000 = 7c1e5840=20 =00 000f42e4 de7fbc08 00000000 7fffffff de7fc000 080581a0 c03d9c2a = 08058000=20 =00Call Trace: =00 [] cache_grow+0x175/0x350 =00 [] filemap_nopage+0x1ee/0x3b0 =00 [] schedule_timeout+0xda/0xe0 =00 [] find_extend_vma+0x29/0x90 =00 [] queue_me+0x8f/0x1c0 =00 [] get_futex_key+0x45/0x360 =00 [] futex_wait+0x171/0x1f0 =00 [] default_wake_function+0x0/0x20 =00 [] default_wake_function+0x0/0x20 =00 [] do_futex+0x48/0xa0 =00 [] process_timeout+0x0/0x10 =00 [] sys_futex+0xee/0x100 =00 [] syscall_call+0x7/0xb =00iperf S C04FE040 6756 1920 1917 1921 1919 (NOTLB= ) =00de12fde8 00000082 de7fb550 c04fe040 de03cc80 00000246 00000018 0000020= 2=20 =00 c044a374 00000000 00000000 000000d0 c014cac3 de7fb000 00000000 = d0e0d780=20 =00 000f42e5 de7fb6b8 de7fb550 7fffffff de12e000 7fffffff c03d9c2a = c044a61c=20 =00Call Trace: =00 [] __alloc_pages+0x2f3/0x450 =00 [] schedule_timeout+0xda/0xe0 =00 [] cache_grow+0x175/0x350 =00 [] wait_for_connect+0xe7/0xf0 =00 [] autoremove_wake_function+0x0/0x60 =00 [] sock_alloc_inode+0x19/0xc0 =00 [] autoremove_wake_function+0x0/0x60 =00 [] tcp_accept+0x5c/0x110 =00 [] new_inode+0x1a/0x1d0 =00 [] inet_accept+0x35/0xc0 =00 [] sys_accept+0x95/0x140 =00 [] do_fork+0x199/0x1ef =00 [] mprotect_fixup+0x180/0x1e0 =00 [] copy_from_user+0x6c/0xa0 =00 [] sys_socketcall+0xd5/0x260 =00 [] syscall_call+0x7/0xb =00iperf S C04FE040 6340 1921 1917 1922 1920 (NOTLB= ) =00de141d30 00000082 de7fb000 c04fe040 dd249054 000005a8 08058370 000005a= 8=20 =00 c025064c 08058370 dd249054 030c10ac 040d10ac c039cf41 00000000 = 397eef00=20 =00 000f4329 de7fb168 de037580 7fffffff 00000000 de141db0 c03d9c2a = 00000000=20 =00Call Trace: =00 [] copy_to_user+0x6c/0x80 =00 [] tcp_v4_send_check+0x51/0xf0 =00 [] schedule_timeout+0xda/0xe0 =00 [] kfree_skbmem+0x24/0x30 =00 [] __kfree_skb+0x60/0xe0 =00 [] sk_wait_data+0xbb/0xd0 =00 [] autoremove_wake_function+0x0/0x60 =00 [] autoremove_wake_function+0x0/0x60 =00 [] tcp_recvmsg+0x352/0x710 =00 [] sock_common_recvmsg+0x58/0x80 =00 [] sock_aio_read+0xf6/0x110 =00 [] do_sync_read+0xb7/0xf0 =00 [] tty_write+0xb3/0x280 =00 [] autoremove_wake_function+0x0/0x60 =00 [] write_chan+0x0/0x230 =00 [] vfs_read+0x118/0x130 =00 [] sys_read+0x51/0x80 =00 [] syscall_call+0x7/0xb =00iperf S C04FE040 7612 1922 1917 1921 (NOTLB= ) =00de143e60 00000082 de045aa0 c04fe040 00000000 00000000 00000000 0000000= 0=20 =00 00000000 00000000 00000000 00000000 00000000 00000000 00000000 = d0f019c0=20 =00 000f42e5 de045c08 00000000 7fffffff de142000 08062420 c03d9c2a = 08062000=20 =00Call Trace: =00 [] schedule_timeout+0xda/0xe0 =00 [] find_extend_vma+0x29/0x90 =00 [] queue_me+0x8f/0x1c0 =00 [] get_futex_key+0x45/0x360 =00 [] futex_wait+0x171/0x1f0 =00 [] default_wake_function+0x0/0x20 =00 [] default_wake_function+0x0/0x20 =00 [] do_futex+0x48/0xa0 =00 [] sys_futex+0xee/0x100 =00 [] schedule_tail+0x1e/0x70 =00 [] syscall_call+0x7/0xb =00sshd S C04FE088 6736 1923 1825 1925 1915 (NOTLB= ) =00ddb57e80 00000082 de045550 c04fe088 000f4329 00000030 00000246 c0488cf= 8=20 =00 c0488ce0 00000001 00000003 3fdf9fc0 000f4329 de045550 00000000 = 3fdf9fc0=20 =00 000f4329 de045168 00000000 7fffffff 00000008 00000000 c03d9c2a = de01e180=20 =00Call Trace: =00 [] schedule_timeout+0xda/0xe0 =00 [] normal_poll+0x11c/0x16b =00 [] tty_poll+0x89/0xc0 =00 [] sock_poll+0x29/0x40 =00 [] do_select+0x28a/0x470 =00 [] __pollwait+0x0/0xd0 =00 [] sys_select+0x2db/0x5b0 =00 [] syscall_call+0x7/0xb =00bash R running 6892 1925 1923 (NOTLB)= =00SysRq : Show Regs --------------070500030203030802020608-- From bunk@stusta.de Sun Mar 6 12:58:03 2005 Received: with ECARTIS (v1.0.0; list netdev); Sun, 06 Mar 2005 12:58:08 -0800 (PST) Received: from mailout.stusta.mhn.de (mailout.stusta.mhn.de [141.84.69.5]) by oss.sgi.com (8.13.0/8.13.0) with SMTP id j26Kw1jl002501 for ; Sun, 6 Mar 2005 12:58:02 -0800 Received: (qmail 5890 invoked from network); 6 Mar 2005 20:57:55 -0000 Received: from r063144.stusta.swh.mhn.de (10.150.63.144) by mailhub.stusta.mhn.de with SMTP; 6 Mar 2005 20:57:55 -0000 Received: by r063144.stusta.swh.mhn.de (Postfix, from userid 1000) id 98CC5BB614; Sun, 6 Mar 2005 21:57:54 +0100 (CET) Date: Sun, 6 Mar 2005 21:57:54 +0100 From: Adrian Bunk To: davem@davemloft.net Cc: netdev@oss.sgi.com, linux-kernel@vger.kernel.org Subject: [2.6 patch] net/802/fc.c: #if 0 fc_type_trans Message-ID: <20050306205754.GO5070@stusta.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.5.6+20040907i X-Virus-Scanned: ClamAV 0.83/748/Fri Mar 4 14:19:11 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 2534 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: bunk@stusta.de Precedence: bulk X-list: netdev Content-Length: 1430 Lines: 57 The only user of fc_type_trans (drivers/net/fc/iph5526.c) is BROKEN in 2.6 and removed in -mm. Signed-off-by: Adrian Bunk --- include/linux/fcdevice.h | 2 -- net/802/fc.c | 2 ++ 2 files changed, 2 insertions(+), 2 deletions(-) --- linux-2.6.11-mm1-full/include/linux/fcdevice.h.old 2005-03-06 21:40:36.000000000 +0100 +++ linux-2.6.11-mm1-full/include/linux/fcdevice.h 2005-03-06 21:41:07.000000000 +0100 @@ -24,12 +24,10 @@ #define _LINUX_FCDEVICE_H #include #ifdef __KERNEL__ -extern unsigned short fc_type_trans(struct sk_buff *skb, struct net_device *dev); - extern struct net_device *alloc_fcdev(int sizeof_priv); #endif #endif /* _LINUX_FCDEVICE_H */ --- linux-2.6.11-mm1-full/net/802/fc.c.old 2005-03-06 21:41:12.000000000 +0100 +++ linux-2.6.11-mm1-full/net/802/fc.c 2005-03-06 21:41:35.000000000 +0100 @@ -94,12 +94,13 @@ return arp_find(fch->daddr, skb); #else return 0; #endif } +#if 0 unsigned short fc_type_trans(struct sk_buff *skb, struct net_device *dev) { struct fch_hdr *fch = (struct fch_hdr *)skb->data; struct fcllc *fcllc; @@ -127,12 +128,13 @@ skb_pull(skb, sizeof (struct fcllc)); return fcllc->ethertype; } return ntohs(ETH_P_802_2); } +#endif /* 0 */ static void fc_setup(struct net_device *dev) { dev->hard_header = fc_header; dev->rebuild_header = fc_rebuild_header; From yoshfuji@linux-ipv6.org Sun Mar 6 12:59:06 2005 Received: with ECARTIS (v1.0.0; list netdev); Sun, 06 Mar 2005 12:59:11 -0800 (PST) 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 j26Kx5iY003159 for ; Sun, 6 Mar 2005 12:59:06 -0800 Received: from localhost (localhost [127.0.0.1]) by yue.st-paulia.net (Postfix) with ESMTP id A178933CC2; Mon, 7 Mar 2005 06:00:40 +0900 (JST) Date: Mon, 07 Mar 2005 06:00:38 +0900 (JST) Message-Id: <20050307.060038.16434779.yoshfuji@linux-ipv6.org> To: domen@coderock.org Cc: jgarzik@pobox.com, netdev@oss.sgi.com, janitor@sternwelten.at, yoshfuji@linux-ipv6.org Subject: Re: [patch 01/26] list_for_each: net-ipv6-ip6_fib.c From: YOSHIFUJI Hideaki / =?iso-2022-jp?B?GyRCNUhGIzFRTEAbKEI=?= In-Reply-To: <20050307.014040.48352532.yoshfuji@linux-ipv6.org> References: <20050306103238.86F181E46E@trashy.coderock.org> <20050307.014040.48352532.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-Virus-Scanned: ClamAV 0.83/748/Fri Mar 4 14:19:11 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 2535 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: yoshfuji@linux-ipv6.org Precedence: bulk X-list: netdev Content-Length: 567 Lines: 14 In article <20050307.014040.48352532.yoshfuji@linux-ipv6.org> (at Mon, 07 Mar 2005 01:40:40 +0900 (JST)), YOSHIFUJI Hideaki / $B5HF#1QL@(B says: > > > > -#define FOR_WALKERS(w) for ((w)=fib6_walker_list.next; (w) != &fib6_walker_list; (w)=(w)->next) > > +#define FOR_WALKERS(w) list_for_each((w), &fib6_walker_list) > > > > static __inline__ u32 fib6_new_sernum(void) > > { > > Please don't. fib6_walker_list is not for fib6_walker_t but list_head. Sorry, I meant: list_for_each is not for fib6_walker_t but list_head. --yoshfuji From herbert@gondor.apana.org.au Sun Mar 6 13:15:10 2005 Received: with ECARTIS (v1.0.0; list netdev); Sun, 06 Mar 2005 13:15:17 -0800 (PST) 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 j26LF8MR004329 for ; Sun, 6 Mar 2005 13:15:09 -0800 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 1D832E-0005Ku-00; Mon, 07 Mar 2005 08:11:34 +1100 Received: from herbert by gondolin.me.apana.org.au with local (Exim 3.36 #1 (Debian)) id 1D830L-0000qP-00; Mon, 07 Mar 2005 08:09:37 +1100 Date: Mon, 7 Mar 2005 08:09:37 +1100 To: Jeff Garzik Cc: Adrian Bunk , akpm@osdl.org, davem@davemloft.net, netdev@oss.sgi.com Subject: Re: [patch 1/3] fix buggy IEEE80211_CRYPT_* selects Message-ID: <20050306210937.GA3233@gondor.apana.org.au> References: <200503041237.j24Cbb69026470@shell0.pdx.osdl.net> <42289BDF.1080409@pobox.com> <20050304221014.GJ3327@stusta.de> <4228DF62.4000205@pobox.com> <20050304230718.GL3327@stusta.de> <20050306090936.GA31890@gondor.apana.org.au> <422B4552.5000504@pobox.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <422B4552.5000504@pobox.com> User-Agent: Mutt/1.5.6+20040907i From: Herbert Xu X-Virus-Scanned: ClamAV 0.83/748/Fri Mar 4 14:19:11 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 2536 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: herbert@gondor.apana.org.au Precedence: bulk X-list: netdev Content-Length: 546 Lines: 14 On Sun, Mar 06, 2005 at 01:00:50PM -0500, Jeff Garzik wrote: > > I would rather fix Kconfig. If we are selecting X_1 -- which explicitly > depends on X -- when Kconfig should automatically select X. That would be nice to have. However, until such a patch is integrated we need to write Kconfig entries that work properly. Cheers, -- Visit Openswan at http://www.openswan.org/ Email: Herbert Xu ~{PmV>HI~} Home Page: http://gondor.apana.org.au/~herbert/ PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt From ak@muc.de Sun Mar 6 13:30:50 2005 Received: with ECARTIS (v1.0.0; list netdev); Sun, 06 Mar 2005 13:30:55 -0800 (PST) Received: from colin2.muc.de (qmailr@colin2.muc.de [193.149.48.15]) by oss.sgi.com (8.13.0/8.13.0) with SMTP id j26LUmZk005366 for ; Sun, 6 Mar 2005 13:30:49 -0800 Received: (qmail 66515 invoked by uid 3709); 6 Mar 2005 21:30:47 -0000 Date: 6 Mar 2005 22:30:47 +0100 Date: Sun, 6 Mar 2005 22:30:47 +0100 From: Andi Kleen To: Thomas Graf Cc: Zdenek Radouch , Martin Mares , netdev@oss.sgi.com, linux-net@vger.kernel.org Subject: Re: Do you know the TCP stack? (127.x.x.x routing) Message-ID: <20050306213047.GA65970@muc.de> References: <20050306173145.GQ31837@postel.suug.ch> <20050306204516.GR31837@postel.suug.ch> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20050306204516.GR31837@postel.suug.ch> User-Agent: Mutt/1.4.1i X-Virus-Scanned: ClamAV 0.83/748/Fri Mar 4 14:19:11 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 2537 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: ak@muc.de Precedence: bulk X-list: netdev Content-Length: 799 Lines: 20 On Sun, Mar 06, 2005 at 09:45:16PM +0100, Thomas Graf wrote: > * Andi Kleen 2005-03-06 21:19 > > Zdenek Radouch writes: > > > > > > There is no doubt that the 127.x net is treated in a special > > > way. If I have to believe what I just learned, then the 127 > > > > It is. 127.* is hardcoded in the routing engine and e.g. > > it won't accept outside packets with a loopback address. > > > > Most likely it's enough to change the "LOOPBACK" macro to allow > > parts of the Class A to be used for other purposes. > > Yes, it will work around the martian route and arp checks but > will probably break quite a few usersapce applications. Unlikely. glibc has an own LOOPBACK() and all modern distributions use separate kernel/user headers anyways. -Andi From tgraf@suug.ch Sun Mar 6 13:49:52 2005 Received: with ECARTIS (v1.0.0; list netdev); Sun, 06 Mar 2005 13:49:57 -0800 (PST) Received: from b.mx.projectdream.org (eth0-0.arisu.projectdream.org [194.158.4.191]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j26Lnqsm006602 for ; Sun, 6 Mar 2005 13:49:52 -0800 Received: from postel.suug.ch (postel.suug.ch [195.134.158.23]) (using TLSv1 with cipher EDH-RSA-DES-CBC3-SHA (168/168 bits)) (No client certificate requested) by b.mx.projectdream.org (Postfix) with ESMTP id 0241C84; Sun, 6 Mar 2005 22:49:28 +0100 (CET) Received: by postel.suug.ch (Postfix, from userid 10001) id 768991C0EA; Sun, 6 Mar 2005 22:50:11 +0100 (CET) Date: Sun, 6 Mar 2005 22:50:11 +0100 From: Thomas Graf To: Andi Kleen Cc: Zdenek Radouch , Martin Mares , netdev@oss.sgi.com, linux-net@vger.kernel.org Subject: Re: Do you know the TCP stack? (127.x.x.x routing) Message-ID: <20050306215011.GS31837@postel.suug.ch> References: <20050306173145.GQ31837@postel.suug.ch> <20050306204516.GR31837@postel.suug.ch> <20050306213047.GA65970@muc.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20050306213047.GA65970@muc.de> X-Virus-Scanned: ClamAV 0.83/748/Fri Mar 4 14:19:11 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 2538 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: tgraf@suug.ch Precedence: bulk X-list: netdev Content-Length: 983 Lines: 19 * Andi Kleen <20050306213047.GA65970@muc.de> 2005-03-06 22:30 > On Sun, Mar 06, 2005 at 09:45:16PM +0100, Thomas Graf wrote: > > Yes, it will work around the martian route and arp checks but > > will probably break quite a few usersapce applications. > > Unlikely. glibc has an own LOOPBACK() and all modern distributions > use separate kernel/user headers anyways. I was rather referring to the reduced loopback scope. I'm aware of at least 3 applications that make extensive use of big portions of the scope to multiplex streams and they depend on LOOPBACK() to make sure the addresses they use will be looped back. I agree that userspace has its own LOOPBACK macro in most cases but this is exactly the problem, it may result in userspace assuming certain addreses to be regarded as loopback by the kernel when they won't. This of course heavily depends on how the LOOPBACK macro is changed. I just wanted to point out that it may affect userspace under certain circumstances. From zdenek@rcn.com Sun Mar 6 13:54:52 2005 Received: with ECARTIS (v1.0.0; list netdev); Sun, 06 Mar 2005 13:54:57 -0800 (PST) Received: from smtp04.mrf.mail.rcn.net (smtp04.mrf.mail.rcn.net [207.172.4.63]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j26Lspoc007222 for ; Sun, 6 Mar 2005 13:54:52 -0800 Received: from 209-150-50-115.c3-0.nwt-ubr3.sbo-nwt.ma.cable.rcn.com (HELO funex) (209.150.50.115) by smtp04.mrf.mail.rcn.net with SMTP; 06 Mar 2005 16:53:51 -0500 Message-Id: <3sp35g$7hpm0@smtp04.mrf.mail.rcn.net> X-IronPort-AV: i="3.90,139,1107752400"; d="scan'208"; a="7923392:sNHT20275364" X-Sender: zdenek@pop.rcn.com X-Mailer: QUALCOMM Windows Eudora Pro Version 4.0 Date: Sun, 06 Mar 2005 16:50:55 -0500 To: Thomas Graf , Andi Kleen From: Zdenek Radouch Subject: Re: Do you know the TCP stack? (127.x.x.x routing) Cc: Martin Mares , netdev@oss.sgi.com, linux-net@vger.kernel.org In-Reply-To: <20050306204516.GR31837@postel.suug.ch> References: <20050306173145.GQ31837@postel.suug.ch> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" X-Virus-Scanned: ClamAV 0.83/748/Fri Mar 4 14:19:11 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 2539 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: zdenek@rcn.com Precedence: bulk X-list: netdev Content-Length: 1666 Lines: 47 OK. We've gone a full circle, [except for a few digressions along the lines of me not knowing that while the rest of the world still uses 'route', under linux it has long been deprecated] you seem to be agreeing with my original guess that subnetting the 127 net may not be trivial, and that it may require some kernel hacking. So my original questions still stand: 1) How could one remove the special kernel treatment of the 127 net? [so that "lo" gets 127.0.0.1/16 and "foo" gets 127.1.0.1/16, and so that the "foo" interface can actually receive packets? 2) If it does require kernel hacking, would you like to do it for me? (as I had said, as a contract) >> it won't accept outside packets with a loopback address. Not accepting packets with with a loopback address is one thing, not accepting any 127.0.0.0/8 packets is entirely something else. Couldn't that whole 127 thing be ripped out of the kernel? Why couldn't the "lo" interface be treated as any other interface? -Zdenek At 09:45 PM 3/6/05 +0100, Thomas Graf wrote: >* Andi Kleen 2005-03-06 21:19 >> Zdenek Radouch writes: >> > >> > There is no doubt that the 127.x net is treated in a special >> > way. If I have to believe what I just learned, then the 127 >> >> It is. 127.* is hardcoded in the routing engine and e.g. >> it won't accept outside packets with a loopback address. >> >> Most likely it's enough to change the "LOOPBACK" macro to allow >> parts of the Class A to be used for other purposes. > >Yes, it will work around the martian route and arp checks but >will probably break quite a few usersapce applications. > From domen@coderock.org Sun Mar 6 14:11:14 2005 Received: with ECARTIS (v1.0.0; list netdev); Sun, 06 Mar 2005 14:11:19 -0800 (PST) Received: from trashy.coderock.org (postfix@coderock.org [193.77.147.115]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j26MBCl2008469 for ; Sun, 6 Mar 2005 14:11:13 -0800 Received: by trashy.coderock.org (Postfix, from userid 780) id 6DD2D1EFA4; Sun, 6 Mar 2005 23:11:08 +0100 (CET) Received: from localhost (localhost [127.0.0.1]) by trashy.coderock.org (Postfix) with ESMTP id 6E5721ED3D; Sun, 6 Mar 2005 23:11:07 +0100 (CET) Received: from localhost (coderock.org [193.77.147.115]) by trashy.coderock.org (Postfix) with ESMTP id C34E91EC90; Sun, 6 Mar 2005 23:11:02 +0100 (CET) Date: Sun, 6 Mar 2005 23:11:01 +0100 From: Domen Puncer To: "YOSHIFUJI Hideaki / ?$B5HF#1QL@" Cc: jgarzik@pobox.com, netdev@oss.sgi.com, janitor@sternwelten.at Subject: Re: [patch 01/26] list_for_each: net-ipv6-ip6_fib.c Message-ID: <20050306221101.GB32564@nd47.coderock.org> References: <20050306103238.86F181E46E@trashy.coderock.org> <20050307.014040.48352532.yoshfuji@linux-ipv6.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20050307.014040.48352532.yoshfuji@linux-ipv6.org> User-Agent: Mutt/1.4.2.1i X-Virus-Scanned: ClamAV 0.83/748/Fri Mar 4 14:19:11 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 2540 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: domen@coderock.org Precedence: bulk X-list: netdev Content-Length: 3310 Lines: 105 On 07/03/05 01:40 +0900, YOSHIFUJI Hideaki / ?$B5HF#1QL@ wrote: > In article <20050306103238.86F181E46E@trashy.coderock.org> (at Sun, 06 Mar 2005 11:32:38 +0100), domen@coderock.org says: > > > s/for/list_for_each/ > > Compile tested. > : > > +++ kj-domen/net/ipv6/ip6_fib.c 2005-03-05 16:09:09.000000000 +0100 > > @@ -99,7 +99,7 @@ struct fib6_walker_t fib6_walker_list = > > .next = &fib6_walker_list, > > }; > > > > -#define FOR_WALKERS(w) for ((w)=fib6_walker_list.next; (w) != &fib6_walker_list; (w)=(w)->next) > > +#define FOR_WALKERS(w) list_for_each((w), &fib6_walker_list) > > > > static __inline__ u32 fib6_new_sernum(void) > > { > > Please don't. fib6_walker_list is not for fib6_walker_t but list_head. > (Or, why don't you convert fib6_walker_t to use list_head families?) Makes sense. How about this compile tested patch: Convert to use lists from list.h. Signed-off-by: Domen Puncer diff -purNX dontdiff c/net/ipv6/ip6_fib.c a/net/ipv6/ip6_fib.c --- c/net/ipv6/ip6_fib.c 2005-03-02 10:32:13.000000000 +0100 +++ a/net/ipv6/ip6_fib.c 2005-03-06 23:02:54.000000000 +0100 @@ -95,12 +95,9 @@ static __u32 rt_sernum; static struct timer_list ip6_fib_timer = TIMER_INITIALIZER(fib6_run_gc, 0, 0); struct fib6_walker_t fib6_walker_list = { - .prev = &fib6_walker_list, - .next = &fib6_walker_list, + .head = LIST_HEAD_INIT(fib6_walker_list.head), }; -#define FOR_WALKERS(w) for ((w)=fib6_walker_list.next; (w) != &fib6_walker_list; (w)=(w)->next) - static __inline__ u32 fib6_new_sernum(void) { u32 n = ++rt_sernum; @@ -849,7 +846,7 @@ static struct fib6_node * fib6_repair_tr #endif read_lock(&fib6_walker_lock); - FOR_WALKERS(w) { + list_for_each_entry(w, &fib6_walker_list.head, head) { if (child == NULL) { if (w->root == fn) { w->root = w->node = NULL; @@ -904,7 +901,7 @@ static void fib6_del_route(struct fib6_n /* Adjust walkers */ read_lock(&fib6_walker_lock); - FOR_WALKERS(w) { + list_for_each_entry(w, &fib6_walker_list.head, head) { if (w->state == FWS_C && w->leaf == rt) { RT6_TRACE("walker %p adjusted by delroute\n", w); w->leaf = rt->u.next; diff -purNX dontdiff c/include/net/ip6_fib.h a/include/net/ip6_fib.h --- c/include/net/ip6_fib.h 2005-01-22 02:48:35.000000000 +0100 +++ a/include/net/ip6_fib.h 2005-03-06 23:03:14.000000000 +0100 @@ -21,6 +21,7 @@ #include #include #include +#include struct rt6_info; @@ -80,7 +81,7 @@ struct rt6_info struct fib6_walker_t { - struct fib6_walker_t *prev, *next; + struct list_head head; struct fib6_node *root, *node; struct rt6_info *leaf; unsigned char state; @@ -95,19 +96,14 @@ extern rwlock_t fib6_walker_lock; static inline void fib6_walker_link(struct fib6_walker_t *w) { write_lock_bh(&fib6_walker_lock); - w->next = fib6_walker_list.next; - w->prev = &fib6_walker_list; - w->next->prev = w; - w->prev->next = w; + list_add(&w->head, &fib6_walker_list.head); write_unlock_bh(&fib6_walker_lock); } static inline void fib6_walker_unlink(struct fib6_walker_t *w) { write_lock_bh(&fib6_walker_lock); - w->next->prev = w->prev; - w->prev->next = w->next; - w->prev = w->next = w; + list_del_init(&w->head); write_unlock_bh(&fib6_walker_lock); } From domen@coderock.org Sun Mar 6 14:21:19 2005 Received: with ECARTIS (v1.0.0; list netdev); Sun, 06 Mar 2005 14:21:23 -0800 (PST) Received: from trashy.coderock.org (postfix@coderock.org [193.77.147.115]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j26MLIaL009291 for ; Sun, 6 Mar 2005 14:21:19 -0800 Received: by trashy.coderock.org (Postfix, from userid 780) id DD0E91F1FF; Sun, 6 Mar 2005 23:21:17 +0100 (CET) Received: from localhost (localhost [127.0.0.1]) by trashy.coderock.org (Postfix) with ESMTP id F1C7B1EDA4; Sun, 6 Mar 2005 23:21:16 +0100 (CET) Received: from localhost.localdomain (localhost [127.0.0.1]) by trashy.coderock.org (Postfix) with ESMTP id C65C11ED3D; Sun, 6 Mar 2005 23:21:11 +0100 (CET) Subject: [patch 2/5] net/aarp: replace schedule_timeout() with msleep() To: davem@redhat.com Cc: netdev@oss.sgi.com, domen@coderock.org, nacc@us.ibm.com From: domen@coderock.org Date: Sun, 06 Mar 2005 23:21:11 +0100 Message-Id: <20050306222111.C65C11ED3D@trashy.coderock.org> X-Virus-Scanned: ClamAV 0.83/748/Fri Mar 4 14:19:11 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 2542 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: domen@coderock.org Precedence: bulk X-list: netdev Content-Length: 1455 Lines: 48 Use msleep() instead of schedule_timeout() to guarantee the task delays as expected. The current code is not wrong, but it does not account for early return due to signals, so I think msleep() should be appropriate. Signed-off-by: Nishanth Aravamudan Signed-off-by: Domen Puncer --- kj-domen/net/appletalk/aarp.c | 7 +++---- 1 files changed, 3 insertions(+), 4 deletions(-) diff -puN net/appletalk/aarp.c~msleep-net_appletalk_aarp net/appletalk/aarp.c --- kj/net/appletalk/aarp.c~msleep-net_appletalk_aarp 2005-03-05 16:10:58.000000000 +0100 +++ kj-domen/net/appletalk/aarp.c 2005-03-05 16:10:58.000000000 +0100 @@ -35,6 +35,7 @@ #include #include #include +#include #include #include #include @@ -462,8 +463,7 @@ void aarp_probe_network(struct atalk_ifa aarp_send_probe(atif->dev, &atif->address); /* Defer 1/10th */ - current->state = TASK_INTERRUPTIBLE; - schedule_timeout(HZ / 10); + msleep(100); if (atif->status & ATIF_PROBE_FAIL) break; @@ -510,9 +510,8 @@ int aarp_proxy_probe_network(struct atal aarp_send_probe(atif->dev, sa); /* Defer 1/10th */ - current->state = TASK_INTERRUPTIBLE; write_unlock_bh(&aarp_lock); - schedule_timeout(HZ / 10); + msleep(100); write_lock_bh(&aarp_lock); if (entry->status & ATIF_PROBE_FAIL) _ From domen@coderock.org Sun Mar 6 14:21:24 2005 Received: with ECARTIS (v1.0.0; list netdev); Sun, 06 Mar 2005 14:21:28 -0800 (PST) Received: from trashy.coderock.org (postfix@coderock.org [193.77.147.115]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j26MLNIU009329 for ; Sun, 6 Mar 2005 14:21:23 -0800 Received: by trashy.coderock.org (Postfix, from userid 780) id 299701F1FF; Sun, 6 Mar 2005 23:21:22 +0100 (CET) Received: from localhost (localhost [127.0.0.1]) by trashy.coderock.org (Postfix) with ESMTP id F1C331EDA4; Sun, 6 Mar 2005 23:21:20 +0100 (CET) Received: from localhost.localdomain (localhost [127.0.0.1]) by trashy.coderock.org (Postfix) with ESMTP id 2A8E21EC90; Sun, 6 Mar 2005 23:21:15 +0100 (CET) Subject: [patch 3/5] net/svcsock: replace schedule_timeout() with msleep() To: davem@redhat.com Cc: netdev@oss.sgi.com, domen@coderock.org, nacc@us.ibm.com From: domen@coderock.org Date: Sun, 06 Mar 2005 23:21:14 +0100 Message-Id: <20050306222115.2A8E21EC90@trashy.coderock.org> X-Virus-Scanned: ClamAV 0.83/748/Fri Mar 4 14:19:11 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 2543 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: domen@coderock.org Precedence: bulk X-list: netdev Content-Length: 1215 Lines: 38 Use msleep() instead of schedule_timeout() to guarantee the task delays as expected. The code, as is, is not wrong; however I see two reasons to use msleep(): 1) consistency across the kernel; and 2) milliseconds are far more human-comprehensible than jiffies. Signed-off-by: Nishanth Aravamudan Signed-off-by: Domen Puncer --- kj-domen/net/sunrpc/svcsock.c | 4 ++-- 1 files changed, 2 insertions(+), 2 deletions(-) diff -puN net/sunrpc/svcsock.c~msleep-net_sunrpc_svcsock net/sunrpc/svcsock.c --- kj/net/sunrpc/svcsock.c~msleep-net_sunrpc_svcsock 2005-03-05 16:10:59.000000000 +0100 +++ kj-domen/net/sunrpc/svcsock.c 2005-03-05 16:10:59.000000000 +0100 @@ -31,6 +31,7 @@ #include #include #include +#include #include #include #include @@ -1167,8 +1168,7 @@ svc_recv(struct svc_serv *serv, struct s while (rqstp->rq_arghi < pages) { struct page *p = alloc_page(GFP_KERNEL); if (!p) { - set_current_state(TASK_UNINTERRUPTIBLE); - schedule_timeout(HZ/2); + msleep(500); continue; } rqstp->rq_argpages[rqstp->rq_arghi++] = p; _ From domen@coderock.org Sun Mar 6 14:21:16 2005 Received: with ECARTIS (v1.0.0; list netdev); Sun, 06 Mar 2005 14:21:21 -0800 (PST) Received: from trashy.coderock.org (postfix@coderock.org [193.77.147.115]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j26MLFQi009279 for ; Sun, 6 Mar 2005 14:21:15 -0800 Received: by trashy.coderock.org (Postfix, from userid 780) id 702AC1F1F0; Sun, 6 Mar 2005 23:21:13 +0100 (CET) Received: from localhost (localhost [127.0.0.1]) by trashy.coderock.org (Postfix) with ESMTP id 19DC01EDA4; Sun, 6 Mar 2005 23:21:11 +0100 (CET) Received: from localhost.localdomain (localhost [127.0.0.1]) by trashy.coderock.org (Postfix) with ESMTP id 782C61EC90; Sun, 6 Mar 2005 23:21:08 +0100 (CET) Subject: [patch 1/5] ebtables.c - vfree() checking cleanups To: davem@redhat.com Cc: netdev@oss.sgi.com, domen@coderock.org, jlamanna@gmail.com From: domen@coderock.org Date: Sun, 06 Mar 2005 23:21:07 +0100 Message-Id: <20050306222108.782C61EC90@trashy.coderock.org> X-Virus-Scanned: ClamAV 0.83/748/Fri Mar 4 14:19:11 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 2541 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: domen@coderock.org Precedence: bulk X-list: netdev Content-Length: 2169 Lines: 80 ebtables.c vfree() checking cleanups. Signed-off by: James Lamanna Signed-off-by: Domen Puncer --- kj-domen/net/bridge/netfilter/ebtables.c | 21 +++++++-------------- 1 files changed, 7 insertions(+), 14 deletions(-) diff -puN net/bridge/netfilter/ebtables.c~vfree-net_bridge_netfilter_ebtables net/bridge/netfilter/ebtables.c --- kj/net/bridge/netfilter/ebtables.c~vfree-net_bridge_netfilter_ebtables 2005-03-05 16:10:40.000000000 +0100 +++ kj-domen/net/bridge/netfilter/ebtables.c 2005-03-05 16:10:40.000000000 +0100 @@ -858,8 +858,7 @@ static int translate_table(struct ebt_re if (repl->valid_hooks & (1 << i)) if (check_chainloops(newinfo->hook_entry[i], cl_s, udc_cnt, i, newinfo->entries)) { - if (cl_s) - vfree(cl_s); + vfree(cl_s); return -EINVAL; } @@ -882,8 +881,7 @@ static int translate_table(struct ebt_re EBT_ENTRY_ITERATE(newinfo->entries, newinfo->entries_size, ebt_cleanup_entry, &i); } - if (cl_s) - vfree(cl_s); + vfree(cl_s); return ret; } @@ -1029,8 +1027,7 @@ static int do_replace(void __user *user, } vfree(table); - if (counterstmp) - vfree(counterstmp); + vfree(counterstmp); return ret; free_unlock: @@ -1039,8 +1036,7 @@ free_iterate: EBT_ENTRY_ITERATE(newinfo->entries, newinfo->entries_size, ebt_cleanup_entry, NULL); free_counterstmp: - if (counterstmp) - vfree(counterstmp); + vfree(counterstmp); /* can be initialized in translate_table() */ if (newinfo->chainstack) { for (i = 0; i < NR_CPUS; i++) @@ -1048,11 +1044,9 @@ free_counterstmp: vfree(newinfo->chainstack); } free_entries: - if (newinfo->entries) - vfree(newinfo->entries); + vfree(newinfo->entries); free_newinfo: - if (newinfo) - vfree(newinfo); + vfree(newinfo); return ret; } @@ -1212,8 +1206,7 @@ void ebt_unregister_table(struct ebt_tab down(&ebt_mutex); LIST_DELETE(&ebt_tables, table); up(&ebt_mutex); - if (table->private->entries) - vfree(table->private->entries); + vfree(table->private->entries); if (table->private->chainstack) { for (i = 0; i < NR_CPUS; i++) vfree(table->private->chainstack[i]); _ From domen@coderock.org Sun Mar 6 14:21:29 2005 Received: with ECARTIS (v1.0.0; list netdev); Sun, 06 Mar 2005 14:21:34 -0800 (PST) Received: from trashy.coderock.org (postfix@coderock.org [193.77.147.115]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j26MLS8W009420 for ; Sun, 6 Mar 2005 14:21:29 -0800 Received: by trashy.coderock.org (Postfix, from userid 780) id BEC981EFA4; Sun, 6 Mar 2005 23:21:27 +0100 (CET) Received: from localhost (localhost [127.0.0.1]) by trashy.coderock.org (Postfix) with ESMTP id 0017D1EC90; Sun, 6 Mar 2005 23:21:26 +0100 (CET) Received: from localhost.localdomain (localhost [127.0.0.1]) by trashy.coderock.org (Postfix) with ESMTP id 7D8791EFA4; Sun, 6 Mar 2005 23:21:21 +0100 (CET) Subject: [patch 5/5] net/clnt: remove sleep_on*() usage To: davem@redhat.com Cc: netdev@oss.sgi.com, domen@coderock.org, nacc@us.ibm.com From: domen@coderock.org Date: Sun, 06 Mar 2005 23:21:21 +0100 Message-Id: <20050306222121.7D8791EFA4@trashy.coderock.org> X-Virus-Scanned: ClamAV 0.83/748/Fri Mar 4 14:19:11 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 2545 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: domen@coderock.org Precedence: bulk X-list: netdev Content-Length: 1410 Lines: 46 Directly use wait-queues instead of the deprecated sleep_on_timeout(). Since the sleep in this function is unconditional, wait_event_timeout() does not appear to be appropriate. Patch is compile-tested. Signed-off-by: Nishanth Aravamudan Signed-off-by: Domen Puncer --- kj-domen/net/sunrpc/clnt.c | 6 +++++- 1 files changed, 5 insertions(+), 1 deletion(-) diff -puN net/sunrpc/clnt.c~sleep_on-net_sunrpc_clnt net/sunrpc/clnt.c --- kj/net/sunrpc/clnt.c~sleep_on-net_sunrpc_clnt 2005-03-05 16:13:14.000000000 +0100 +++ kj-domen/net/sunrpc/clnt.c 2005-03-05 16:13:14.000000000 +0100 @@ -28,6 +28,7 @@ #include #include #include +#include #include #include @@ -222,6 +223,7 @@ out_no_clnt: int rpc_shutdown_client(struct rpc_clnt *clnt) { + DEFINE_WAIT(wait); dprintk("RPC: shutting down %s client for %s, tasks=%d\n", clnt->cl_protname, clnt->cl_server, atomic_read(&clnt->cl_users)); @@ -231,7 +233,9 @@ rpc_shutdown_client(struct rpc_clnt *cln clnt->cl_oneshot = 0; clnt->cl_dead = 0; rpc_killall_tasks(clnt); - sleep_on_timeout(&destroy_wait, 1*HZ); + prepare_to_wait(&destroy_wait, &wait, TASK_UNINTERRUPTIBLE); + schedule_timeout(HZ); + finish_wait(&destroy_wait, &wait); } if (atomic_read(&clnt->cl_users) < 0) { _ From domen@coderock.org Sun Mar 6 14:21:26 2005 Received: with ECARTIS (v1.0.0; list netdev); Sun, 06 Mar 2005 14:21:32 -0800 (PST) Received: from trashy.coderock.org (postfix@coderock.org [193.77.147.115]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j26MLPmA009370 for ; Sun, 6 Mar 2005 14:21:26 -0800 Received: by trashy.coderock.org (Postfix, from userid 780) id DE6561F1F0; Sun, 6 Mar 2005 23:21:24 +0100 (CET) Received: from localhost (localhost [127.0.0.1]) by trashy.coderock.org (Postfix) with ESMTP id EA6C01EC90; Sun, 6 Mar 2005 23:21:23 +0100 (CET) Received: from localhost.localdomain (localhost [127.0.0.1]) by trashy.coderock.org (Postfix) with ESMTP id 401D11ED3D; Sun, 6 Mar 2005 23:21:18 +0100 (CET) Subject: [patch 4/5] net/ipv6/ip6_flowlabel.c: copy_to_user return code To: davem@redhat.com Cc: netdev@oss.sgi.com, domen@coderock.org, yrgrknmxpzlk@gawab.com From: domen@coderock.org Date: Sun, 06 Mar 2005 23:21:17 +0100 Message-Id: <20050306222118.401D11ED3D@trashy.coderock.org> X-Virus-Scanned: ClamAV 0.83/748/Fri Mar 4 14:19:11 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 2544 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: domen@coderock.org Precedence: bulk X-list: netdev Content-Length: 1024 Lines: 33 compile warning cleanup - handle copy_to/from_user error returns Signed-off-by: Stephen Biggs Signed-off-by: Domen Puncer --- kj-domen/net/ipv6/ip6_flowlabel.c | 10 +++++++--- 1 files changed, 7 insertions(+), 3 deletions(-) diff -puN net/ipv6/ip6_flowlabel.c~return_code-net_ipv6_ip6_flowlabel net/ipv6/ip6_flowlabel.c --- kj/net/ipv6/ip6_flowlabel.c~return_code-net_ipv6_ip6_flowlabel 2005-03-05 16:13:10.000000000 +0100 +++ kj-domen/net/ipv6/ip6_flowlabel.c 2005-03-05 16:13:10.000000000 +0100 @@ -537,9 +537,13 @@ release: goto done; /* Do not check for fault */ - if (!freq.flr_label) - copy_to_user(&((struct in6_flowlabel_req __user *) optval)->flr_label, - &fl->label, sizeof(fl->label)); + if (!freq.flr_label) { + if (copy_to_user(&((struct in6_flowlabel_req __user *)optval)->flr_label, + &fl->label, sizeof(fl->label))) { + err = -EFAULT; + goto done; + } + } sfl1->fl = fl; sfl1->next = np->ipv6_fl_list; _ From domen@coderock.org Sun Mar 6 14:21:46 2005 Received: with ECARTIS (v1.0.0; list netdev); Sun, 06 Mar 2005 14:21:55 -0800 (PST) Received: from trashy.coderock.org (postfix@coderock.org [193.77.147.115]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j26MLich009772 for ; Sun, 6 Mar 2005 14:21:45 -0800 Received: by trashy.coderock.org (Postfix, from userid 780) id AC6A91F1F0; Sun, 6 Mar 2005 23:21:43 +0100 (CET) Received: from localhost (localhost [127.0.0.1]) by trashy.coderock.org (Postfix) with ESMTP id DBBDB1ED3D; Sun, 6 Mar 2005 23:21:42 +0100 (CET) Received: from localhost.localdomain (localhost [127.0.0.1]) by trashy.coderock.org (Postfix) with ESMTP id 6ACE51EC90; Sun, 6 Mar 2005 23:21:40 +0100 (CET) Subject: [patch 1/2] net/orinoco_plx: replace schedule_timeout() with ssleep() To: proski@gnu.org Cc: hermes@gibson.dropbear.id.au, netdev@oss.sgi.com, domen@coderock.org, nacc@us.ibm.com, janitor@sternwelten.at From: domen@coderock.org Date: Sun, 06 Mar 2005 23:21:40 +0100 Message-Id: <20050306222140.6ACE51EC90@trashy.coderock.org> X-Virus-Scanned: ClamAV 0.83/748/Fri Mar 4 14:19:11 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 2546 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: domen@coderock.org Precedence: bulk X-list: netdev Content-Length: 1109 Lines: 38 Use ssleep() instead of schedule_timeout() to guarantee the task delays as expected. Signed-off-by: Nishanth Aravamudan Signed-off-by: Maximilian Attems Signed-off-by: Domen Puncer --- kj-domen/drivers/net/wireless/orinoco_plx.c | 4 ++-- 1 files changed, 2 insertions(+), 2 deletions(-) diff -puN drivers/net/wireless/orinoco_plx.c~ssleep-drivers_net_wireless_orinoco_plx drivers/net/wireless/orinoco_plx.c --- kj/drivers/net/wireless/orinoco_plx.c~ssleep-drivers_net_wireless_orinoco_plx 2005-03-05 16:09:49.000000000 +0100 +++ kj-domen/drivers/net/wireless/orinoco_plx.c 2005-03-05 16:09:49.000000000 +0100 @@ -136,6 +136,7 @@ #include #include #include +#include #include @@ -352,8 +353,7 @@ static int __init orinoco_plx_init(void) static void __exit orinoco_plx_exit(void) { pci_unregister_driver(&orinoco_plx_driver); - current->state = TASK_UNINTERRUPTIBLE; - schedule_timeout(HZ); + ssleep(1); } module_init(orinoco_plx_init); _ From domen@coderock.org Sun Mar 6 14:21:50 2005 Received: with ECARTIS (v1.0.0; list netdev); Sun, 06 Mar 2005 14:21:56 -0800 (PST) Received: from trashy.coderock.org (postfix@coderock.org [193.77.147.115]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j26MLn1S009886 for ; Sun, 6 Mar 2005 14:21:49 -0800 Received: by trashy.coderock.org (Postfix, from userid 780) id 233241EFA4; Sun, 6 Mar 2005 23:21:48 +0100 (CET) Received: from localhost (localhost [127.0.0.1]) by trashy.coderock.org (Postfix) with ESMTP id 534021ED3D; Sun, 6 Mar 2005 23:21:47 +0100 (CET) Received: from localhost.localdomain (localhost [127.0.0.1]) by trashy.coderock.org (Postfix) with ESMTP id A91211EFA4; Sun, 6 Mar 2005 23:21:43 +0100 (CET) Subject: [patch 2/2] net/orinoco_tmd: replace schedule_timeout() with ssleep() To: proski@gnu.org Cc: hermes@gibson.dropbear.id.au, netdev@oss.sgi.com, domen@coderock.org, nacc@us.ibm.com, janitor@sternwelten.at From: domen@coderock.org Date: Sun, 06 Mar 2005 23:21:43 +0100 Message-Id: <20050306222143.A91211EFA4@trashy.coderock.org> X-Virus-Scanned: ClamAV 0.83/748/Fri Mar 4 14:19:11 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 2547 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: domen@coderock.org Precedence: bulk X-list: netdev Content-Length: 1107 Lines: 38 Use ssleep() instead of schedule_timeout() to guarantee the task delays as expected. Signed-off-by: Nishanth Aravamudan Signed-off-by: Maximilian Attems Signed-off-by: Domen Puncer --- kj-domen/drivers/net/wireless/orinoco_tmd.c | 4 ++-- 1 files changed, 2 insertions(+), 2 deletions(-) diff -puN drivers/net/wireless/orinoco_tmd.c~ssleep-drivers_net_wireless_orinoco_tmd drivers/net/wireless/orinoco_tmd.c --- kj/drivers/net/wireless/orinoco_tmd.c~ssleep-drivers_net_wireless_orinoco_tmd 2005-03-05 16:09:50.000000000 +0100 +++ kj-domen/drivers/net/wireless/orinoco_tmd.c 2005-03-05 16:09:50.000000000 +0100 @@ -72,6 +72,7 @@ #include #include #include +#include #include @@ -218,8 +219,7 @@ static int __init orinoco_tmd_init(void) static void __exit orinoco_tmd_exit(void) { pci_unregister_driver(&orinoco_tmd_driver); - current->state = TASK_UNINTERRUPTIBLE; - schedule_timeout(HZ); + ssleep(1); } module_init(orinoco_tmd_init); _ From domen@coderock.org Sun Mar 6 14:24:01 2005 Received: with ECARTIS (v1.0.0; list netdev); Sun, 06 Mar 2005 14:24:05 -0800 (PST) Received: from trashy.coderock.org (postfix@coderock.org [193.77.147.115]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j26MNx0G012489 for ; Sun, 6 Mar 2005 14:24:00 -0800 Received: by trashy.coderock.org (Postfix, from userid 780) id 054531F205; Sun, 6 Mar 2005 23:23:57 +0100 (CET) Received: from localhost (localhost [127.0.0.1]) by trashy.coderock.org (Postfix) with ESMTP id C322A1EDA4; Sun, 6 Mar 2005 23:23:56 +0100 (CET) Received: from localhost.localdomain (localhost [127.0.0.1]) by trashy.coderock.org (Postfix) with ESMTP id 514491EC90; Sun, 6 Mar 2005 23:23:52 +0100 (CET) Subject: [patch 1/3] net/islpci_dev: replace schedule_timeout() with msleep() To: prism54-private@prism54.org Cc: netdev@oss.sgi.com, domen@coderock.org, nacc@us.ibm.com, janitor@sternwelten.at From: domen@coderock.org Date: Sun, 06 Mar 2005 23:23:51 +0100 Message-Id: <20050306222352.514491EC90@trashy.coderock.org> X-Virus-Scanned: ClamAV 0.83/748/Fri Mar 4 14:19:11 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 2548 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: domen@coderock.org Precedence: bulk X-list: netdev Content-Length: 1022 Lines: 31 Use msleep() instead of schedule_timeout() to guarantee the task delays as expected. Also set_current_state() is inserted before schedule_timeout(). Signed-off-by: Nishanth Aravamudan Signed-off-by: Maximilian Attems Signed-off-by: Domen Puncer --- kj-domen/drivers/net/wireless/prism54/islpci_dev.c | 3 +-- 1 files changed, 1 insertion(+), 2 deletions(-) diff -puN drivers/net/wireless/prism54/islpci_dev.c~msleep-drivers_net_wireless_prism54_islpci_dev drivers/net/wireless/prism54/islpci_dev.c --- kj/drivers/net/wireless/prism54/islpci_dev.c~msleep-drivers_net_wireless_prism54_islpci_dev 2005-03-05 16:09:30.000000000 +0100 +++ kj-domen/drivers/net/wireless/prism54/islpci_dev.c 2005-03-05 16:09:30.000000000 +0100 @@ -438,8 +438,7 @@ prism54_bring_down(islpci_private *priv) wmb(); /* wait a while for the device to reset */ - set_current_state(TASK_UNINTERRUPTIBLE); - schedule_timeout(50*HZ/1000); + msleep(50); return 0; } _ From domen@coderock.org Sun Mar 6 14:24:06 2005 Received: with ECARTIS (v1.0.0; list netdev); Sun, 06 Mar 2005 14:24:13 -0800 (PST) Received: from trashy.coderock.org (postfix@coderock.org [193.77.147.115]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j26MO4RK012605 for ; Sun, 6 Mar 2005 14:24:05 -0800 Received: by trashy.coderock.org (Postfix, from userid 780) id B59A51F205; Sun, 6 Mar 2005 23:24:03 +0100 (CET) Received: from localhost (localhost [127.0.0.1]) by trashy.coderock.org (Postfix) with ESMTP id 972DE1EDA4; Sun, 6 Mar 2005 23:24:02 +0100 (CET) Received: from localhost.localdomain (localhost [127.0.0.1]) by trashy.coderock.org (Postfix) with ESMTP id 6686C1ED3D; Sun, 6 Mar 2005 23:23:55 +0100 (CET) Subject: [patch 2/3] drivers/net/wireless/prism54/islpci_hotplug: Use the DMA_{64, 32}BIT_MASK constants To: prism54-private@prism54.org Cc: netdev@oss.sgi.com, domen@coderock.org, tklauser@nuerscht.ch From: domen@coderock.org Date: Sun, 06 Mar 2005 23:23:55 +0100 Message-Id: <20050306222355.6686C1ED3D@trashy.coderock.org> X-Virus-Scanned: ClamAV 0.83/748/Fri Mar 4 14:19:11 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 2549 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: domen@coderock.org Precedence: bulk X-list: netdev Content-Length: 1031 Lines: 25 Use the DMA_{64,32}BIT_MASK constants from dma-mapping.h when calling pci_set_dma_mask() or pci_set_consistent_dma_mask() Signed-off-by: Tobias Klauser Signed-off-by: Domen Puncer --- kj-domen/drivers/net/wireless/prism54/islpci_hotplug.c | 2 +- 1 files changed, 1 insertion(+), 1 deletion(-) diff -puN drivers/net/wireless/prism54/islpci_hotplug.c~dma_mask-drivers_net_wireless_prism54_islpci_hotplug drivers/net/wireless/prism54/islpci_hotplug.c --- kj/drivers/net/wireless/prism54/islpci_hotplug.c~dma_mask-drivers_net_wireless_prism54_islpci_hotplug 2005-03-05 16:12:02.000000000 +0100 +++ kj-domen/drivers/net/wireless/prism54/islpci_hotplug.c 2005-03-05 16:12:02.000000000 +0100 @@ -125,7 +125,7 @@ prism54_probe(struct pci_dev *pdev, cons } /* enable PCI DMA */ - if (pci_set_dma_mask(pdev, 0xffffffff)) { + if (pci_set_dma_mask(pdev, DMA_32BIT_MASK)) { printk(KERN_ERR "%s: 32-bit PCI DMA not supported", DRV_NAME); goto do_pci_disable_device; } _ From domen@coderock.org Sun Mar 6 14:24:09 2005 Received: with ECARTIS (v1.0.0; list netdev); Sun, 06 Mar 2005 14:24:16 -0800 (PST) Received: from trashy.coderock.org (postfix@coderock.org [193.77.147.115]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j26MO7dI012658 for ; Sun, 6 Mar 2005 14:24:07 -0800 Received: by trashy.coderock.org (Postfix, from userid 780) id 1D1261F203; Sun, 6 Mar 2005 23:24:06 +0100 (CET) Received: from localhost (localhost [127.0.0.1]) by trashy.coderock.org (Postfix) with ESMTP id 246B71ED3D; Sun, 6 Mar 2005 23:24:05 +0100 (CET) Received: from localhost.localdomain (localhost [127.0.0.1]) by trashy.coderock.org (Postfix) with ESMTP id 752961EC90; Sun, 6 Mar 2005 23:23:58 +0100 (CET) Subject: [patch 3/3] drivers/net/wireless/prism54/*: convert to pci_register_driver To: prism54-private@prism54.org Cc: netdev@oss.sgi.com, domen@coderock.org, c.lucas@ifrance.com From: domen@coderock.org Date: Sun, 06 Mar 2005 23:23:58 +0100 Message-Id: <20050306222358.752961EC90@trashy.coderock.org> X-Virus-Scanned: ClamAV 0.83/748/Fri Mar 4 14:19:11 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 2550 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: domen@coderock.org Precedence: bulk X-list: netdev Content-Length: 951 Lines: 25 convert from pci_module_init to pci_register_driver (from:http://kerneljanitors.org/TODO). Signed-off-by: Christophe Lucas Signed-off-by: Domen Puncer --- kj-domen/drivers/net/wireless/prism54/islpci_hotplug.c | 2 +- 1 files changed, 1 insertion(+), 1 deletion(-) diff -puN drivers/net/wireless/prism54/islpci_hotplug.c~pci_register_driver-drivers_net_wireless_prism54 drivers/net/wireless/prism54/islpci_hotplug.c --- kj/drivers/net/wireless/prism54/islpci_hotplug.c~pci_register_driver-drivers_net_wireless_prism54 2005-03-05 16:12:44.000000000 +0100 +++ kj-domen/drivers/net/wireless/prism54/islpci_hotplug.c 2005-03-05 16:12:44.000000000 +0100 @@ -315,7 +315,7 @@ prism54_module_init(void) __bug_on_wrong_struct_sizes (); - return pci_module_init(&prism54_driver); + return pci_register_driver(&prism54_driver); } /* by the time prism54_module_exit() terminates, as a postcondition _ From yoshfuji@linux-ipv6.org Sun Mar 6 14:30:43 2005 Received: with ECARTIS (v1.0.0; list netdev); Sun, 06 Mar 2005 14:30:48 -0800 (PST) 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 j26MUgPI014557 for ; Sun, 6 Mar 2005 14:30:43 -0800 Received: from localhost (localhost [127.0.0.1]) by yue.st-paulia.net (Postfix) with ESMTP id BF29E33CC2; Mon, 7 Mar 2005 07:32:14 +0900 (JST) Date: Mon, 07 Mar 2005 07:32:13 +0900 (JST) Message-Id: <20050307.073213.32943613.yoshfuji@linux-ipv6.org> To: domen@coderock.org Cc: davem@davemloft.com, netdev@oss.sgi.com, yrgrknmxpzlk@gawab.com, yoshfuji@linux-ipv6.org Subject: Re: [patch 4/5] net/ipv6/ip6_flowlabel.c: copy_to_user return code From: YOSHIFUJI Hideaki / =?iso-2022-jp?B?GyRCNUhGIzFRTEAbKEI=?= In-Reply-To: <20050306222118.401D11ED3D@trashy.coderock.org> References: <20050306222118.401D11ED3D@trashy.coderock.org> Organization: USAGI Project X-URL: http://www.yoshifuji.org/%7Ehideaki/ X-Fingerprint: 9022 65EB 1ECF 3AD1 0BDF 80D8 4807 F894 E062 0EEA X-PGP-Key-URL: http://www.yoshifuji.org/%7Ehideaki/hideaki@yoshifuji.org.asc X-Face: "5$Al-.M>NJ%a'@hhZdQm:."qn~PA^gq4o*>iCFToq*bAi#4FRtx}enhuQKz7fNqQz\BYU] $~O_5m-9'}MIs`XGwIEscw;e5b>n"B_?j/AkL~i/MEaZBLP X-Mailer: Mew version 2.2 on Emacs 20.7 / Mule 4.1 (AOI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV 0.83/748/Fri Mar 4 14:19:11 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 2551 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: yoshfuji@linux-ipv6.org Precedence: bulk X-list: netdev Content-Length: 474 Lines: 16 In article <20050306222118.401D11ED3D@trashy.coderock.org> (at Sun, 06 Mar 2005 23:21:17 +0100), domen@coderock.org says: > > compile warning cleanup - handle copy_to/from_user error > returns Wrong. You introduce a leak. > /* Do not check for fault */ > - if (!freq.flr_label) > - copy_to_user(&((struct in6_flowlabel_req __user *) optval)->flr_label, > - &fl->label, sizeof(fl->label)); Don't you see the comment: "Do not check for fault?" --yoshfuji From yoshfuji@linux-ipv6.org Sun Mar 6 14:37:11 2005 Received: with ECARTIS (v1.0.0; list netdev); Sun, 06 Mar 2005 14:37:17 -0800 (PST) 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 j26MbASU015229 for ; Sun, 6 Mar 2005 14:37:11 -0800 Received: from localhost (localhost [127.0.0.1]) by yue.st-paulia.net (Postfix) with ESMTP id 6304433CC2; Mon, 7 Mar 2005 07:38:44 +0900 (JST) Date: Mon, 07 Mar 2005 07:38:43 +0900 (JST) Message-Id: <20050307.073843.09980515.yoshfuji@linux-ipv6.org> To: domen@coderock.org Cc: davem@davemloft.com, netdev@oss.sgi.com, yrgrknmxpzlk@gawab.com, yoshfuji@linux-ipv6.org Subject: Re: [patch 4/5] net/ipv6/ip6_flowlabel.c: copy_to_user return code From: YOSHIFUJI Hideaki / =?iso-2022-jp?B?GyRCNUhGIzFRTEAbKEI=?= In-Reply-To: <20050307.073213.32943613.yoshfuji@linux-ipv6.org> References: <20050306222118.401D11ED3D@trashy.coderock.org> <20050307.073213.32943613.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-Virus-Scanned: ClamAV 0.83/748/Fri Mar 4 14:19:11 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 2552 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: yoshfuji@linux-ipv6.org Precedence: bulk X-list: netdev Content-Length: 571 Lines: 16 In article <20050307.073213.32943613.yoshfuji@linux-ipv6.org> (at Mon, 07 Mar 2005 07:32:13 +0900 (JST)), YOSHIFUJI Hideaki / $B5HF#1QL@(B says: > In article <20050306222118.401D11ED3D@trashy.coderock.org> (at Sun, 06 Mar 2005 23:21:17 +0100), domen@coderock.org says: > > > > > compile warning cleanup - handle copy_to/from_user error > > returns > > Wrong. You introduce a leak. Ah, sorry, not really, but I still think it is wrong: fl_intern() insert it to hash, and then you freed up the memory. I believe this is wrong. --yoshfuji From jgarzik@pobox.com Sun Mar 6 15:39:12 2005 Received: with ECARTIS (v1.0.0; list netdev); Sun, 06 Mar 2005 15:39:34 -0800 (PST) Received: from parcelfarce.linux.theplanet.co.uk (IDENT:93@parcelfarce.linux.theplanet.co.uk [195.92.249.252]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j26Nd92C017554 for ; Sun, 6 Mar 2005 15:39:10 -0800 Received: from [69.134.152.124] (helo=[10.10.10.88]) by parcelfarce.linux.theplanet.co.uk with asmtp (TLSv1:AES256-SHA:256) (Exim 4.33) id 1D85Kr-00030v-Dv; Sun, 06 Mar 2005 23:39:08 +0000 Message-ID: <422B947B.5080504@pobox.com> Date: Sun, 06 Mar 2005 18:38:35 -0500 From: Jeff Garzik User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.3) Gecko/20040922 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Andrew Morton , Linus Torvalds CC: Netdev , Linux Kernel Subject: [BK PATCHES] 2.6.x net driver updates Content-Type: multipart/mixed; boundary="------------030602010205090106010908" X-Virus-Scanned: ClamAV 0.83/748/Fri Mar 4 14:19:11 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 2553 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: jgarzik@pobox.com Precedence: bulk X-list: netdev Content-Length: 156405 Lines: 5338 This is a multi-part message in MIME format. --------------030602010205090106010908 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Mostly fixes / MIPS update. --------------030602010205090106010908 Content-Type: text/plain; name="changelog.txt" Content-Transfer-Encoding: 8bit Content-Disposition: inline; filename="changelog.txt" Please do a bk pull bk://gkernel.bkbits.net/net-drivers-2.6 This will update the following files: drivers/net/bagetlance.c | 1368 ----------------------------------- Documentation/networking/ixgb.txt | 9 MAINTAINERS | 4 drivers/net/Kconfig | 14 drivers/net/Makefile | 1 drivers/net/Space.c | 11 drivers/net/amd8111e.c | 2 drivers/net/au1000_eth.c | 1361 ++++++++++++++++++++++++++++------ drivers/net/au1000_eth.h | 55 - drivers/net/dl2k.c | 2 drivers/net/gianfar.c | 2 drivers/net/ibm_emac/ibm_emac.h | 4 drivers/net/ibm_emac/ibm_emac_core.c | 16 drivers/net/ibm_emac/ibm_emac_core.h | 2 drivers/net/ioc3-eth.c | 82 +- drivers/net/jazzsonic.c | 217 +++-- drivers/net/meth.c | 275 +++---- drivers/net/meth.h | 2 drivers/net/mv643xx_eth.c | 2 drivers/net/pcnet32.c | 47 - drivers/net/s2io.c | 45 - drivers/net/sb1250-mac.c | 109 +- drivers/net/sgiseeq.c | 70 + drivers/net/sk98lin/skge.c | 2 drivers/net/sonic.c | 4 drivers/net/wan/Kconfig | 11 drivers/net/wan/hd6457x.c | 2 drivers/net/wan/z85230.c | 4 include/linux/pci_ids.h | 5 29 files changed, 1720 insertions(+), 2008 deletions(-) through these ChangeSets: : o Possible AMD8111e free irq issue Don Fry: o pcnet32: 79c976 with fiber optic fix Ganesh Venkatesan: o ixgb: Documentation/networking/ixgb.txt John W. Linville: o sk98lin: add MODULE_DEVICE_TABLE entry Krzysztof Halasa: o WAN drivers fix: N2, C101, PCI200SYN - quite fatal Kumar Gala: o initialize a spin lock in gianfar driver Matt Porter: o emac: fix skb allocation for full-size jumbo frames o Add PPC440SP support to IBM EMAC driver Ralf Bächle: o SGI Seeq updates o SB1250 driver updates o S2IO syntax fixes o Meth driver updates o Marvell MV-64340 driver upda o Jazzsonic driver updates o IOC3 driver updates o Remove Baget network driver o Au1000 driver updates Thierry Vignaud: o fix driver name in dl2k as returned by ETHTOOL_GDRVINFO tom watson: o drivers/net/wan/z85230.c interrupt handling fix --------------030602010205090106010908 Content-Type: text/plain; name="patch" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="patch" diff -Nru a/Documentation/networking/ixgb.txt b/Documentation/networking/ixgb.txt --- a/Documentation/networking/ixgb.txt 2005-03-06 18:36:50 -05:00 +++ b/Documentation/networking/ixgb.txt 2005-03-06 18:36:50 -05:00 @@ -1,7 +1,7 @@ Linux* Base Driver for the Intel(R) PRO/10GbE Family of Adapters ================================================================ -September 13, 2004 +November 17, 2004 Contents @@ -18,8 +18,7 @@ =============== This file describes the Linux* Base Driver for the Intel(R) PRO/10GbE Family -of Adapters, version 1.0.x. This driver includes support for Itanium(TM)2 and -EM64T systems. +of Adapters, version 1.0.x. For questions related to hardware requirements, refer to the documentation supplied with your Intel PRO/10GbE adapter. All hardware requirements listed @@ -71,8 +70,8 @@ Ethernet PAUSE frames. RxDescriptors -Valid Range: 64-4096 -Default Value: 1024 +Valid Range: 64-512 +Default Value: 512 This value is the number of receive descriptors allocated by the driver. Increasing this value allows the driver to buffer more incoming packets. Each descriptor is 16 bytes. A receive buffer is also allocated for diff -Nru a/MAINTAINERS b/MAINTAINERS --- a/MAINTAINERS 2005-03-06 18:36:50 -05:00 +++ b/MAINTAINERS 2005-03-06 18:36:50 -05:00 @@ -910,10 +910,10 @@ W: http://www.icp-vortex.com/ S: Supported -GENERIC HDLC DRIVER, N2 AND C101 DRIVERS +GENERIC HDLC DRIVER, N2, C101, PCI200SYN and WANXL DRIVERS P: Krzysztof Halasa M: khc@pm.waw.pl -W: http://hq.pm.waw.pl/hdlc/ +W: http://www.kernel.org/pub/linux/utils/net/hdlc/ S: Maintained HAYES ESP SERIAL DRIVER diff -Nru a/drivers/net/Kconfig b/drivers/net/Kconfig --- a/drivers/net/Kconfig 2005-03-06 18:36:50 -05:00 +++ b/drivers/net/Kconfig 2005-03-06 18:36:50 -05:00 @@ -445,7 +445,7 @@ config MIPS_JAZZ_SONIC tristate "MIPS JAZZ onboard SONIC Ethernet support" - depends on NET_ETHERNET && MIPS_JAZZ + depends on NET_ETHERNET && MACH_JAZZ help This is the driver for the onboard card of MIPS Magnum 4000, Acer PICA, Olivetti M700-10 and a few other identical OEM systems. @@ -470,7 +470,7 @@ config SGI_IOC3_ETH bool "SGI IOC3 Ethernet" - depends on NET_ETHERNET && SGI_IP27 + depends on NET_ETHERNET && PCI && SGI_IP27 select CRC32 select MII help @@ -1763,14 +1763,6 @@ DEC (now Compaq) based on the AMD Lance chipset, including the DEPCA series. (This chipset is better known via the NE2100 cards.) -config BAGETLANCE - tristate "Baget AMD LANCE support" - depends on NET_ETHERNET && BAGET_MIPS - help - Say Y to enable kernel support for AMD Lance Ethernet cards on the - MIPS-32-based Baget embedded system. This chipset is better known - via the NE2100 cards. - config 68360_ENET bool "Motorola 68360 ethernet controller" depends on M68360 @@ -2077,7 +2069,7 @@ config MV643XX_ETH tristate "MV-643XX Ethernet support" - depends on MOMENCO_OCELOT_C || MOMENCO_JAGUAR_ATX + depends on MOMENCO_OCELOT_C || MOMENCO_JAGUAR_ATX || MOMENCO_OCELOT_3 help This driver supports the gigabit Ethernet on the Marvell MV643XX chipset which is used in the Momenco Ocelot C and Jaguar ATX. diff -Nru a/drivers/net/Makefile b/drivers/net/Makefile --- a/drivers/net/Makefile 2005-03-06 18:36:50 -05:00 +++ b/drivers/net/Makefile 2005-03-06 18:36:50 -05:00 @@ -162,7 +162,6 @@ obj-$(CONFIG_MIPS_GT96100ETH) += gt96100eth.o obj-$(CONFIG_MIPS_AU1X00_ENET) += au1000_eth.o obj-$(CONFIG_SGI_IOC3_ETH) += ioc3-eth.o -obj-$(CONFIG_BAGETLANCE) += bagetlance.o obj-$(CONFIG_DECLANCE) += declance.o obj-$(CONFIG_ATARILANCE) += atarilance.o obj-$(CONFIG_ATARI_BIONET) += atari_bionet.o diff -Nru a/drivers/net/Space.c b/drivers/net/Space.c --- a/drivers/net/Space.c 2005-03-06 18:36:50 -05:00 +++ b/drivers/net/Space.c 2005-03-06 18:36:50 -05:00 @@ -302,16 +302,6 @@ {NULL, 0}, }; -static struct devprobe2 mips_probes[] __initdata = { -#ifdef CONFIG_MIPS_JAZZ_SONIC - {sonic_probe, 0}, -#endif -#ifdef CONFIG_BAGETLANCE /* Lance-based Baget ethernet boards */ - {bagetlance_probe, 0}, -#endif - {NULL, 0}, -}; - /* * Unified ethernet device probe, segmented per architecture and * per bus interface. This drives the legacy devices only for now. @@ -325,7 +315,6 @@ return; (void)( probe_list2(unit, m68k_probes, base_addr == 0) && - probe_list2(unit, mips_probes, base_addr == 0) && probe_list2(unit, eisa_probes, base_addr == 0) && probe_list2(unit, mca_probes, base_addr == 0) && probe_list2(unit, isa_probes, base_addr == 0) && diff -Nru a/drivers/net/amd8111e.c b/drivers/net/amd8111e.c --- a/drivers/net/amd8111e.c 2005-03-06 18:36:50 -05:00 +++ b/drivers/net/amd8111e.c 2005-03-06 18:36:50 -05:00 @@ -1381,6 +1381,8 @@ if(amd8111e_restart(dev)){ spin_unlock_irq(&lp->lock); + if (dev->irq) + free_irq(dev->irq, dev); return -ENOMEM; } /* Start ipg timer */ diff -Nru a/drivers/net/au1000_eth.c b/drivers/net/au1000_eth.c --- a/drivers/net/au1000_eth.c 2005-03-06 18:36:50 -05:00 +++ b/drivers/net/au1000_eth.c 2005-03-06 18:36:50 -05:00 @@ -1,10 +1,19 @@ /* - * Alchemy Semi Au1000 ethernet driver * - * Copyright 2001 MontaVista Software Inc. + * Alchemy Au1x00 ethernet driver + * + * Copyright 2001,2002,2003 MontaVista Software Inc. + * Copyright 2002 TimeSys Corp. + * Added ethtool/mii-tool support, + * Copyright 2004 Matt Porter + * Update: 2004 Bjoern Riemer, riemer@fokus.fraunhofer.de + * or riemer@riemer-nt.de: fixed the link beat detection with + * ioctls (SIOCGMIIPHY) * Author: MontaVista Software, Inc. * ppopov@mvista.com or source@mvista.com * + * ######################################################################## + * * This program is free software; you can distribute it and/or modify it * under the terms of the GNU General Public License (Version 2) as * published by the Free Software Foundation. @@ -17,46 +26,59 @@ * You should have received a copy of the GNU General Public License along * with this program; if not, write to the Free Software Foundation, Inc., * 59 Temple Place - Suite 330, Boston MA 02111-1307, USA. + * + * ######################################################################## + * + * */ -#include #include #include +#include #include #include #include #include #include +#include #include #include #include #include #include #include +#include +#include #include #include -#include -#include - #include #include #include -#include +#include +#include +#include #include "au1000_eth.h" #ifdef AU1000_ETH_DEBUG -static int au1000_debug = 10; +static int au1000_debug = 5; #else static int au1000_debug = 3; #endif +#define DRV_NAME "au1000eth" +#define DRV_VERSION "1.5" +#define DRV_AUTHOR "Pete Popov " +#define DRV_DESC "Au1xxx on-chip Ethernet driver" + +MODULE_AUTHOR(DRV_AUTHOR); +MODULE_DESCRIPTION(DRV_DESC); +MODULE_LICENSE("GPL"); + // prototypes -static void *dma_alloc(size_t, dma_addr_t *); -static void dma_free(void *, size_t); static void hard_stop(struct net_device *); static void enable_rx_tx(struct net_device *dev); -static int __init au1000_probe1(long, int, int); +static struct net_device * au1000_probe(u32 ioaddr, int irq, int port_num); static int au1000_init(struct net_device *); static int au1000_open(struct net_device *); static int au1000_close(struct net_device *); @@ -78,8 +100,7 @@ // externs extern void ack_rise_edge_irq(unsigned int); extern int get_ethernet_addr(char *ethernet_addr); -extern inline void str2eaddr(unsigned char *ea, unsigned char *str); -extern inline unsigned char str2hexnum(unsigned char c); +extern void str2eaddr(unsigned char *ea, unsigned char *str); extern char * __init prom_getcmdline(void); /* @@ -97,29 +118,6 @@ * complete immediately. */ - -/* - * Base address and interrupt of the Au1xxx ethernet macs - */ -static struct { - unsigned int port; - int irq; -} au1000_iflist[NUM_INTERFACES] = { - {AU1000_ETH0_BASE, AU1000_ETH0_IRQ}, - {AU1000_ETH1_BASE, AU1000_ETH1_IRQ} - }, - au1500_iflist[NUM_INTERFACES] = { - {AU1500_ETH0_BASE, AU1000_ETH0_IRQ}, - {AU1500_ETH1_BASE, AU1000_ETH1_IRQ} - }, - au1100_iflist[NUM_INTERFACES] = { - {AU1000_ETH0_BASE, AU1000_ETH0_IRQ}, - {0, 0} - }; - -static char version[] __devinitdata = - "au1000eth.c:1.0 ppopov@mvista.com\n"; - /* These addresses are only used if yamon doesn't tell us what * the mac address is, and the mac address is not passed on the * command line. @@ -135,18 +133,36 @@ #define cpu_to_dma32 cpu_to_be32 #define dma32_to_cpu be32_to_cpu +struct au1000_private *au_macs[NUM_ETH_INTERFACES]; /* FIXME * All of the PHY code really should be detached from the MAC * code. */ +/* Default advertise */ +#define GENMII_DEFAULT_ADVERTISE \ + ADVERTISED_10baseT_Half | ADVERTISED_10baseT_Full | \ + ADVERTISED_100baseT_Half | ADVERTISED_100baseT_Full | \ + ADVERTISED_Autoneg + +#define GENMII_DEFAULT_FEATURES \ + SUPPORTED_10baseT_Half | SUPPORTED_10baseT_Full | \ + SUPPORTED_100baseT_Half | SUPPORTED_100baseT_Full | \ + SUPPORTED_Autoneg + +static char *phy_link[] = +{ "unknown", + "10Base2", "10BaseT", + "AUI", + "100BaseT", "100BaseTX", "100BaseFX" +}; + int bcm_5201_init(struct net_device *dev, int phy_addr) { s16 data; /* Stop auto-negotiation */ - //printk("bcm_5201_init\n"); data = mdio_read(dev, phy_addr, MII_CONTROL); mdio_write(dev, phy_addr, MII_CONTROL, data & ~MII_CNTL_AUTO); @@ -161,17 +177,8 @@ data |= MII_CNTL_RST_AUTO | MII_CNTL_AUTO; mdio_write(dev, phy_addr, MII_CONTROL, data); - /* Enable TX LED instead of FDX */ - data = mdio_read(dev, phy_addr, MII_INT); - data &= ~MII_FDX_LED; - mdio_write(dev, phy_addr, MII_INT, data); - - /* Enable TX LED instead of FDX */ - data = mdio_read(dev, phy_addr, MII_INT); - data &= ~MII_FDX_LED; - mdio_write(dev, phy_addr, MII_INT, data); - - if (au1000_debug > 4) dump_mii(dev, phy_addr); + if (au1000_debug > 4) + dump_mii(dev, phy_addr); return 0; } @@ -179,7 +186,6 @@ { s16 mii_control, timeout; - //printk("bcm_5201_reset\n"); mii_control = mdio_read(dev, phy_addr, MII_CONTROL); mdio_write(dev, phy_addr, MII_CONTROL, mii_control | MII_CNTL_RESET); mdelay(1); @@ -242,12 +248,16 @@ printk("lsi_80227_init\n"); /* restart auto-negotiation */ - mdio_write(dev, phy_addr, 0, 0x3200); - + mdio_write(dev, phy_addr, MII_CONTROL, + MII_CNTL_F100 | MII_CNTL_AUTO | MII_CNTL_RST_AUTO); // | MII_CNTL_FDX); mdelay(1); /* set up LEDs to correct display */ +#ifdef CONFIG_MIPS_MTX1 + mdio_write(dev, phy_addr, 17, 0xff80); +#else mdio_write(dev, phy_addr, 17, 0xffc0); +#endif if (au1000_debug > 4) dump_mii(dev, phy_addr); @@ -294,9 +304,9 @@ mii_data = mdio_read(dev, aup->phy_addr, MII_STATUS); if (mii_data & MII_STAT_LINK) { *link = 1; - mii_data = mdio_read(dev, aup->phy_addr, MII_LSI_STAT); - if (mii_data & MII_LSI_STAT_SPD) { - if (mii_data & MII_LSI_STAT_FDX) { + mii_data = mdio_read(dev, aup->phy_addr, MII_LSI_PHY_STAT); + if (mii_data & MII_LSI_PHY_STAT_SPD) { + if (mii_data & MII_LSI_PHY_STAT_FDX) { *speed = IF_PORT_100BASEFX; dev->if_port = IF_PORT_100BASEFX; } @@ -337,12 +347,396 @@ return 0; } +int am79c874_init(struct net_device *dev, int phy_addr) +{ + s16 data; + + /* 79c874 has quit resembled bit assignments to BCM5201 */ + if (au1000_debug > 4) + printk("am79c847_init\n"); + + /* Stop auto-negotiation */ + data = mdio_read(dev, phy_addr, MII_CONTROL); + mdio_write(dev, phy_addr, MII_CONTROL, data & ~MII_CNTL_AUTO); + + /* Set advertisement to 10/100 and Half/Full duplex + * (full capabilities) */ + data = mdio_read(dev, phy_addr, MII_ANADV); + data |= MII_NWAY_TX | MII_NWAY_TX_FDX | MII_NWAY_T_FDX | MII_NWAY_T; + mdio_write(dev, phy_addr, MII_ANADV, data); + + /* Restart auto-negotiation */ + data = mdio_read(dev, phy_addr, MII_CONTROL); + data |= MII_CNTL_RST_AUTO | MII_CNTL_AUTO; + + mdio_write(dev, phy_addr, MII_CONTROL, data); + + if (au1000_debug > 4) dump_mii(dev, phy_addr); + return 0; +} + +int am79c874_reset(struct net_device *dev, int phy_addr) +{ + s16 mii_control, timeout; + + if (au1000_debug > 4) + printk("am79c874_reset\n"); + + mii_control = mdio_read(dev, phy_addr, MII_CONTROL); + mdio_write(dev, phy_addr, MII_CONTROL, mii_control | MII_CNTL_RESET); + mdelay(1); + for (timeout = 100; timeout > 0; --timeout) { + mii_control = mdio_read(dev, phy_addr, MII_CONTROL); + if ((mii_control & MII_CNTL_RESET) == 0) + break; + mdelay(1); + } + if (mii_control & MII_CNTL_RESET) { + printk(KERN_ERR "%s PHY reset timeout !\n", dev->name); + return -1; + } + return 0; +} + +int +am79c874_status(struct net_device *dev, int phy_addr, u16 *link, u16 *speed) +{ + u16 mii_data; + struct au1000_private *aup; + + // printk("am79c874_status\n"); + if (!dev) { + printk(KERN_ERR "am79c874_status error: NULL dev\n"); + return -1; + } + + aup = (struct au1000_private *) dev->priv; + mii_data = mdio_read(dev, aup->phy_addr, MII_STATUS); + + if (mii_data & MII_STAT_LINK) { + *link = 1; + mii_data = mdio_read(dev, aup->phy_addr, MII_AMD_PHY_STAT); + if (mii_data & MII_AMD_PHY_STAT_SPD) { + if (mii_data & MII_AMD_PHY_STAT_FDX) { + *speed = IF_PORT_100BASEFX; + dev->if_port = IF_PORT_100BASEFX; + } + else { + *speed = IF_PORT_100BASETX; + dev->if_port = IF_PORT_100BASETX; + } + } + else { + *speed = IF_PORT_10BASET; + dev->if_port = IF_PORT_10BASET; + } + + } + else { + *link = 0; + *speed = 0; + dev->if_port = IF_PORT_UNKNOWN; + } + return 0; +} + +int lxt971a_init(struct net_device *dev, int phy_addr) +{ + if (au1000_debug > 4) + printk("lxt971a_init\n"); + + /* restart auto-negotiation */ + mdio_write(dev, phy_addr, MII_CONTROL, + MII_CNTL_F100 | MII_CNTL_AUTO | MII_CNTL_RST_AUTO | MII_CNTL_FDX); + + /* set up LEDs to correct display */ + mdio_write(dev, phy_addr, 20, 0x0422); + + if (au1000_debug > 4) + dump_mii(dev, phy_addr); + return 0; +} + +int lxt971a_reset(struct net_device *dev, int phy_addr) +{ + s16 mii_control, timeout; + + if (au1000_debug > 4) { + printk("lxt971a_reset\n"); + dump_mii(dev, phy_addr); + } + + mii_control = mdio_read(dev, phy_addr, MII_CONTROL); + mdio_write(dev, phy_addr, MII_CONTROL, mii_control | MII_CNTL_RESET); + mdelay(1); + for (timeout = 100; timeout > 0; --timeout) { + mii_control = mdio_read(dev, phy_addr, MII_CONTROL); + if ((mii_control & MII_CNTL_RESET) == 0) + break; + mdelay(1); + } + if (mii_control & MII_CNTL_RESET) { + printk(KERN_ERR "%s PHY reset timeout !\n", dev->name); + return -1; + } + return 0; +} + +int +lxt971a_status(struct net_device *dev, int phy_addr, u16 *link, u16 *speed) +{ + u16 mii_data; + struct au1000_private *aup; + + if (!dev) { + printk(KERN_ERR "lxt971a_status error: NULL dev\n"); + return -1; + } + aup = (struct au1000_private *) dev->priv; + + mii_data = mdio_read(dev, aup->phy_addr, MII_STATUS); + if (mii_data & MII_STAT_LINK) { + *link = 1; + mii_data = mdio_read(dev, aup->phy_addr, MII_INTEL_PHY_STAT); + if (mii_data & MII_INTEL_PHY_STAT_SPD) { + if (mii_data & MII_INTEL_PHY_STAT_FDX) { + *speed = IF_PORT_100BASEFX; + dev->if_port = IF_PORT_100BASEFX; + } + else { + *speed = IF_PORT_100BASETX; + dev->if_port = IF_PORT_100BASETX; + } + } + else { + *speed = IF_PORT_10BASET; + dev->if_port = IF_PORT_10BASET; + } + + } + else { + *link = 0; + *speed = 0; + dev->if_port = IF_PORT_UNKNOWN; + } + return 0; +} + +int ks8995m_init(struct net_device *dev, int phy_addr) +{ + s16 data; + +// printk("ks8995m_init\n"); + /* Stop auto-negotiation */ + data = mdio_read(dev, phy_addr, MII_CONTROL); + mdio_write(dev, phy_addr, MII_CONTROL, data & ~MII_CNTL_AUTO); + + /* Set advertisement to 10/100 and Half/Full duplex + * (full capabilities) */ + data = mdio_read(dev, phy_addr, MII_ANADV); + data |= MII_NWAY_TX | MII_NWAY_TX_FDX | MII_NWAY_T_FDX | MII_NWAY_T; + mdio_write(dev, phy_addr, MII_ANADV, data); + + /* Restart auto-negotiation */ + data = mdio_read(dev, phy_addr, MII_CONTROL); + data |= MII_CNTL_RST_AUTO | MII_CNTL_AUTO; + mdio_write(dev, phy_addr, MII_CONTROL, data); + + if (au1000_debug > 4) dump_mii(dev, phy_addr); + + return 0; +} + +int ks8995m_reset(struct net_device *dev, int phy_addr) +{ + s16 mii_control, timeout; + +// printk("ks8995m_reset\n"); + mii_control = mdio_read(dev, phy_addr, MII_CONTROL); + mdio_write(dev, phy_addr, MII_CONTROL, mii_control | MII_CNTL_RESET); + mdelay(1); + for (timeout = 100; timeout > 0; --timeout) { + mii_control = mdio_read(dev, phy_addr, MII_CONTROL); + if ((mii_control & MII_CNTL_RESET) == 0) + break; + mdelay(1); + } + if (mii_control & MII_CNTL_RESET) { + printk(KERN_ERR "%s PHY reset timeout !\n", dev->name); + return -1; + } + return 0; +} + +int ks8995m_status(struct net_device *dev, int phy_addr, u16 *link, u16 *speed) +{ + u16 mii_data; + struct au1000_private *aup; + + if (!dev) { + printk(KERN_ERR "ks8995m_status error: NULL dev\n"); + return -1; + } + aup = (struct au1000_private *) dev->priv; + + mii_data = mdio_read(dev, aup->phy_addr, MII_STATUS); + if (mii_data & MII_STAT_LINK) { + *link = 1; + mii_data = mdio_read(dev, aup->phy_addr, MII_AUX_CNTRL); + if (mii_data & MII_AUX_100) { + if (mii_data & MII_AUX_FDX) { + *speed = IF_PORT_100BASEFX; + dev->if_port = IF_PORT_100BASEFX; + } + else { + *speed = IF_PORT_100BASETX; + dev->if_port = IF_PORT_100BASETX; + } + } + else { + *speed = IF_PORT_10BASET; + dev->if_port = IF_PORT_10BASET; + } + + } + else { + *link = 0; + *speed = 0; + dev->if_port = IF_PORT_UNKNOWN; + } + return 0; +} + +int +smsc_83C185_init (struct net_device *dev, int phy_addr) +{ + s16 data; + + if (au1000_debug > 4) + printk("smsc_83C185_init\n"); + + /* Stop auto-negotiation */ + data = mdio_read(dev, phy_addr, MII_CONTROL); + mdio_write(dev, phy_addr, MII_CONTROL, data & ~MII_CNTL_AUTO); + + /* Set advertisement to 10/100 and Half/Full duplex + * (full capabilities) */ + data = mdio_read(dev, phy_addr, MII_ANADV); + data |= MII_NWAY_TX | MII_NWAY_TX_FDX | MII_NWAY_T_FDX | MII_NWAY_T; + mdio_write(dev, phy_addr, MII_ANADV, data); + + /* Restart auto-negotiation */ + data = mdio_read(dev, phy_addr, MII_CONTROL); + data |= MII_CNTL_RST_AUTO | MII_CNTL_AUTO; + + mdio_write(dev, phy_addr, MII_CONTROL, data); + + if (au1000_debug > 4) dump_mii(dev, phy_addr); + return 0; +} + +int +smsc_83C185_reset (struct net_device *dev, int phy_addr) +{ + s16 mii_control, timeout; + + if (au1000_debug > 4) + printk("smsc_83C185_reset\n"); + + mii_control = mdio_read(dev, phy_addr, MII_CONTROL); + mdio_write(dev, phy_addr, MII_CONTROL, mii_control | MII_CNTL_RESET); + mdelay(1); + for (timeout = 100; timeout > 0; --timeout) { + mii_control = mdio_read(dev, phy_addr, MII_CONTROL); + if ((mii_control & MII_CNTL_RESET) == 0) + break; + mdelay(1); + } + if (mii_control & MII_CNTL_RESET) { + printk(KERN_ERR "%s PHY reset timeout !\n", dev->name); + return -1; + } + return 0; +} + +int +smsc_83C185_status (struct net_device *dev, int phy_addr, u16 *link, u16 *speed) +{ + u16 mii_data; + struct au1000_private *aup; + + if (!dev) { + printk(KERN_ERR "smsc_83C185_status error: NULL dev\n"); + return -1; + } + + aup = (struct au1000_private *) dev->priv; + mii_data = mdio_read(dev, aup->phy_addr, MII_STATUS); + + if (mii_data & MII_STAT_LINK) { + *link = 1; + mii_data = mdio_read(dev, aup->phy_addr, 0x1f); + if (mii_data & (1<<3)) { + if (mii_data & (1<<4)) { + *speed = IF_PORT_100BASEFX; + dev->if_port = IF_PORT_100BASEFX; + } + else { + *speed = IF_PORT_100BASETX; + dev->if_port = IF_PORT_100BASETX; + } + } + else { + *speed = IF_PORT_10BASET; + dev->if_port = IF_PORT_10BASET; + } + } + else { + *link = 0; + *speed = 0; + dev->if_port = IF_PORT_UNKNOWN; + } + return 0; +} + + +#ifdef CONFIG_MIPS_BOSPORUS +int stub_init(struct net_device *dev, int phy_addr) +{ + //printk("PHY stub_init\n"); + return 0; +} + +int stub_reset(struct net_device *dev, int phy_addr) +{ + //printk("PHY stub_reset\n"); + return 0; +} + +int +stub_status(struct net_device *dev, int phy_addr, u16 *link, u16 *speed) +{ + //printk("PHY stub_status\n"); + *link = 1; + /* hmmm, revisit */ + *speed = IF_PORT_100BASEFX; + dev->if_port = IF_PORT_100BASEFX; + return 0; +} +#endif + struct phy_ops bcm_5201_ops = { bcm_5201_init, bcm_5201_reset, bcm_5201_status, }; +struct phy_ops am79c874_ops = { + am79c874_init, + am79c874_reset, + am79c874_status, +}; + struct phy_ops am79c901_ops = { am79c901_init, am79c901_reset, @@ -355,26 +749,89 @@ lsi_80227_status, }; +struct phy_ops lxt971a_ops = { + lxt971a_init, + lxt971a_reset, + lxt971a_status, +}; + +struct phy_ops ks8995m_ops = { + ks8995m_init, + ks8995m_reset, + ks8995m_status, +}; + +struct phy_ops smsc_83C185_ops = { + smsc_83C185_init, + smsc_83C185_reset, + smsc_83C185_status, +}; + +#ifdef CONFIG_MIPS_BOSPORUS +struct phy_ops stub_ops = { + stub_init, + stub_reset, + stub_status, +}; +#endif + static struct mii_chip_info { const char * name; u16 phy_id0; u16 phy_id1; struct phy_ops *phy_ops; + int dual_phy; } mii_chip_table[] = { - {"Broadcom BCM5201 10/100 BaseT PHY", 0x0040, 0x6212, &bcm_5201_ops }, - {"AMD 79C901 HomePNA PHY", 0x0000, 0x35c8, &am79c901_ops }, - {"LSI 80227 10/100 BaseT PHY", 0x0016, 0xf840, &lsi_80227_ops }, - {"Broadcom BCM5221 10/100 BaseT PHY", 0x0040, 0x61e4, &bcm_5201_ops }, + {"Broadcom BCM5201 10/100 BaseT PHY",0x0040,0x6212, &bcm_5201_ops,0}, + {"Broadcom BCM5221 10/100 BaseT PHY",0x0040,0x61e4, &bcm_5201_ops,0}, + {"Broadcom BCM5222 10/100 BaseT PHY",0x0040,0x6322, &bcm_5201_ops,1}, + {"AMD 79C901 HomePNA PHY",0x0000,0x35c8, &am79c901_ops,0}, + {"AMD 79C874 10/100 BaseT PHY",0x0022,0x561b, &am79c874_ops,0}, + {"LSI 80227 10/100 BaseT PHY",0x0016,0xf840, &lsi_80227_ops,0}, + {"Intel LXT971A Dual Speed PHY",0x0013,0x78e2, &lxt971a_ops,0}, + {"Kendin KS8995M 10/100 BaseT PHY",0x0022,0x1450, &ks8995m_ops,0}, + {"SMSC LAN83C185 10/100 BaseT PHY",0x0007,0xc0a3, &smsc_83C185_ops,0}, +#ifdef CONFIG_MIPS_BOSPORUS + {"Stub", 0x1234, 0x5678, &stub_ops }, +#endif {0,}, }; static int mdio_read(struct net_device *dev, int phy_id, int reg) { struct au1000_private *aup = (struct au1000_private *) dev->priv; + volatile u32 *mii_control_reg; + volatile u32 *mii_data_reg; u32 timedout = 20; u32 mii_control; - while (aup->mac->mii_control & MAC_MII_BUSY) { + #ifdef CONFIG_BCM5222_DUAL_PHY + /* First time we probe, it's for the mac0 phy. + * Since we haven't determined yet that we have a dual phy, + * aup->mii->mii_control_reg won't be setup and we'll + * default to the else statement. + * By the time we probe for the mac1 phy, the mii_control_reg + * will be setup to be the address of the mac0 phy control since + * both phys are controlled through mac0. + */ + if (aup->mii && aup->mii->mii_control_reg) { + mii_control_reg = aup->mii->mii_control_reg; + mii_data_reg = aup->mii->mii_data_reg; + } + else if (au_macs[0]->mii && au_macs[0]->mii->mii_control_reg) { + /* assume both phys are controlled through mac0 */ + mii_control_reg = au_macs[0]->mii->mii_control_reg; + mii_data_reg = au_macs[0]->mii->mii_data_reg; + } + else + #endif + { + /* default control and data reg addresses */ + mii_control_reg = &aup->mac->mii_control; + mii_data_reg = &aup->mac->mii_data; + } + + while (*mii_control_reg & MAC_MII_BUSY) { mdelay(1); if (--timedout == 0) { printk(KERN_ERR "%s: read_MII busy timeout!!\n", @@ -386,10 +843,10 @@ mii_control = MAC_SET_MII_SELECT_REG(reg) | MAC_SET_MII_SELECT_PHY(phy_id) | MAC_MII_READ; - aup->mac->mii_control = mii_control; + *mii_control_reg = mii_control; timedout = 20; - while (aup->mac->mii_control & MAC_MII_BUSY) { + while (*mii_control_reg & MAC_MII_BUSY) { mdelay(1); if (--timedout == 0) { printk(KERN_ERR "%s: mdio_read busy timeout!!\n", @@ -397,16 +854,36 @@ return -1; } } - return (int)aup->mac->mii_data; + return (int)*mii_data_reg; } static void mdio_write(struct net_device *dev, int phy_id, int reg, u16 value) { struct au1000_private *aup = (struct au1000_private *) dev->priv; + volatile u32 *mii_control_reg; + volatile u32 *mii_data_reg; u32 timedout = 20; u32 mii_control; - while (aup->mac->mii_control & MAC_MII_BUSY) { + #ifdef CONFIG_BCM5222_DUAL_PHY + if (aup->mii && aup->mii->mii_control_reg) { + mii_control_reg = aup->mii->mii_control_reg; + mii_data_reg = aup->mii->mii_data_reg; + } + else if (au_macs[0]->mii && au_macs[0]->mii->mii_control_reg) { + /* assume both phys are controlled through mac0 */ + mii_control_reg = au_macs[0]->mii->mii_control_reg; + mii_data_reg = au_macs[0]->mii->mii_data_reg; + } + else + #endif + { + /* default control and data reg addresses */ + mii_control_reg = &aup->mac->mii_control; + mii_data_reg = &aup->mac->mii_data; + } + + while (*mii_control_reg & MAC_MII_BUSY) { mdelay(1); if (--timedout == 0) { printk(KERN_ERR "%s: mdio_write busy timeout!!\n", @@ -418,8 +895,8 @@ mii_control = MAC_SET_MII_SELECT_REG(reg) | MAC_SET_MII_SELECT_PHY(phy_id) | MAC_MII_WRITE; - aup->mac->mii_data = value; - aup->mac->mii_control = mii_control; + *mii_data_reg = value; + *mii_control_reg = mii_control; } @@ -437,12 +914,13 @@ } } -static int __init mii_probe (struct net_device * dev) +static int mii_probe (struct net_device * dev) { struct au1000_private *aup = (struct au1000_private *) dev->priv; int phy_addr; - - aup->mii = NULL; +#ifdef CONFIG_MIPS_BOSPORUS + int phy_found=0; +#endif /* search for total of 32 possible mii phy addresses */ for (phy_addr = 0; phy_addr < 32; phy_addr++) { @@ -450,9 +928,17 @@ u16 phy_id0, phy_id1; int i; + #ifdef CONFIG_BCM5222_DUAL_PHY + /* Mask the already found phy, try next one */ + if (au_macs[0]->mii && au_macs[0]->mii->mii_control_reg) { + if (au_macs[0]->phy_addr == phy_addr) + continue; + } + #endif + mii_status = mdio_read(dev, phy_addr, MII_STATUS); if (mii_status == 0xffff || mii_status == 0x0000) - /* the mii is not accessible, try next one */ + /* the mii is not accessable, try next one */ continue; phy_id0 = mdio_read(dev, phy_addr, MII_PHY_ID0); @@ -462,6 +948,66 @@ for (i = 0; mii_chip_table[i].phy_id1; i++) { if (phy_id0 == mii_chip_table[i].phy_id0 && phy_id1 == mii_chip_table[i].phy_id1) { + struct mii_phy * mii_phy = aup->mii; + + printk(KERN_INFO "%s: %s at phy address %d\n", + dev->name, mii_chip_table[i].name, + phy_addr); +#ifdef CONFIG_MIPS_BOSPORUS + phy_found = 1; +#endif + mii_phy->chip_info = mii_chip_table+i; + aup->phy_addr = phy_addr; + aup->want_autoneg = 1; + aup->phy_ops = mii_chip_table[i].phy_ops; + aup->phy_ops->phy_init(dev,phy_addr); + + // Check for dual-phy and then store required + // values and set indicators. We need to do + // this now since mdio_{read,write} need the + // control and data register addresses. + #ifdef CONFIG_BCM5222_DUAL_PHY + if ( mii_chip_table[i].dual_phy) { + + /* assume both phys are controlled + * through MAC0. Board specific? */ + + /* sanity check */ + if (!au_macs[0] || !au_macs[0]->mii) + return -1; + aup->mii->mii_control_reg = (u32 *) + &au_macs[0]->mac->mii_control; + aup->mii->mii_data_reg = (u32 *) + &au_macs[0]->mac->mii_data; + } + #endif + goto found; + } + } + } +found: + +#ifdef CONFIG_MIPS_BOSPORUS + /* This is a workaround for the Micrel/Kendin 5 port switch + The second MAC doesn't see a PHY connected... so we need to + trick it into thinking we have one. + + If this kernel is run on another Au1500 development board + the stub will be found as well as the actual PHY. However, + the last found PHY will be used... usually at Addr 31 (Db1500). + */ + if ( (!phy_found) ) + { + u16 phy_id0, phy_id1; + int i; + + phy_id0 = 0x1234; + phy_id1 = 0x5678; + + /* search our mii table for the current mii */ + for (i = 0; mii_chip_table[i].phy_id1; i++) { + if (phy_id0 == mii_chip_table[i].phy_id0 && + phy_id1 == mii_chip_table[i].phy_id1) { struct mii_phy * mii_phy; printk(KERN_INFO "%s: %s at phy address %d\n", @@ -471,31 +1017,39 @@ GFP_KERNEL); if (mii_phy) { mii_phy->chip_info = mii_chip_table+i; - mii_phy->phy_addr = phy_addr; + aup->phy_addr = phy_addr; mii_phy->next = aup->mii; aup->phy_ops = mii_chip_table[i].phy_ops; aup->mii = mii_phy; aup->phy_ops->phy_init(dev,phy_addr); } else { - printk(KERN_ERR "%s: out of memory\n", + printk(KERN_ERR "%s: out of memory\n", dev->name); return -1; } - /* the current mii is on our mii_info_table, - try next address */ + mii_phy->chip_info = mii_chip_table+i; + aup->phy_addr = phy_addr; + aup->phy_ops = mii_chip_table[i].phy_ops; + aup->phy_ops->phy_init(dev,phy_addr); break; } } } + if (aup->mac_id == 0) { + /* the Bosporus phy responds to addresses 0-5 but + * 5 is the correct one. + */ + aup->phy_addr = 5; + } +#endif - if (aup->mii == NULL) { - printk(KERN_ERR "%s: No MII transceivers found!\n", dev->name); + if (aup->mii->chip_info == NULL) { + printk(KERN_ERR "%s: Au1x No MII transceivers found!\n", + dev->name); return -1; } - /* use last PHY */ - aup->phy_addr = aup->mii->phy_addr; printk(KERN_INFO "%s: Using %s as default\n", dev->name, aup->mii->chip_info->name); @@ -516,7 +1070,6 @@ if (pDB) { aup->pDBfree = pDB->pnext; } - //printk("GetFreeDB: %x\n", pDB); return pDB; } @@ -528,35 +1081,6 @@ aup->pDBfree = pDB; } - -/* - DMA memory allocation, derived from pci_alloc_consistent. - However, the Au1000 data cache is coherent (when programmed - so), therefore we return KSEG0 address, not KSEG1. -*/ -static void *dma_alloc(size_t size, dma_addr_t * dma_handle) -{ - void *ret; - int gfp = GFP_ATOMIC | GFP_DMA; - - ret = (void *) __get_free_pages(gfp, get_order(size)); - - if (ret != NULL) { - memset(ret, 0, size); - *dma_handle = virt_to_bus(ret); - ret = (void *)KSEG0ADDR(ret); - } - return ret; -} - - -static void dma_free(void *vaddr, size_t size) -{ - vaddr = (void *)KSEG0ADDR(vaddr); - free_pages((unsigned long) vaddr, get_order(size)); -} - - static void enable_rx_tx(struct net_device *dev) { struct au1000_private *aup = (struct au1000_private *) dev->priv; @@ -582,6 +1106,7 @@ static void reset_mac(struct net_device *dev) { + int i; u32 flags; struct au1000_private *aup = (struct au1000_private *) dev->priv; @@ -590,13 +1115,32 @@ dev->name, (unsigned)aup); spin_lock_irqsave(&aup->lock, flags); - del_timer(&aup->timer); + if (aup->timer.function == &au1000_timer) {/* check if timer initted */ + del_timer(&aup->timer); + } + hard_stop(dev); - *aup->enable = MAC_EN_CLOCK_ENABLE; - au_sync_delay(2); - *aup->enable = 0; - au_sync_delay(2); + #ifdef CONFIG_BCM5222_DUAL_PHY + if (aup->mac_id != 0) { + #endif + /* If BCM5222, we can't leave MAC0 in reset because then + * we can't access the dual phy for ETH1 */ + *aup->enable = MAC_EN_CLOCK_ENABLE; + au_sync_delay(2); + *aup->enable = 0; + au_sync_delay(2); + #ifdef CONFIG_BCM5222_DUAL_PHY + } + #endif aup->tx_full = 0; + for (i = 0; i < NUM_RX_DMA; i++) { + /* reset control bits */ + aup->rx_dma_ring[i]->buff_stat &= ~0xf; + } + for (i = 0; i < NUM_TX_DMA; i++) { + /* reset control bits */ + aup->tx_dma_ring[i]->buff_stat &= ~0xf; + } spin_unlock_irqrestore(&aup->lock, flags); } @@ -611,93 +1155,348 @@ { int i; - for (i=0; irx_dma_ring[i] = (volatile rx_dma_t *) (rx_base + sizeof(rx_dma_t)*i); } - for (i=0; itx_dma_ring[i] = (volatile tx_dma_t *) (tx_base + sizeof(tx_dma_t)*i); } } +static struct { + int port; + u32 base_addr; + u32 macen_addr; + int irq; + struct net_device *dev; +} iflist[2]; + +static int num_ifs; + +/* + * Setup the base address and interupt of the Au1xxx ethernet macs + * based on cpu type and whether the interface is enabled in sys_pinfunc + * register. The last interface is enabled if SYS_PF_NI2 (bit 4) is 0. + */ static int __init au1000_init_module(void) { - int i; - int prid; - int base_addr, irq; + struct cpuinfo_mips *c = ¤t_cpu_data; + int ni = (int)((au_readl(SYS_PINFUNC) & (u32)(SYS_PF_NI2)) >> 4); + struct net_device *dev; + int i, found_one = 0; - prid = read_c0_prid(); - for (i=0; icputype) { +#ifdef CONFIG_SOC_AU1000 + case CPU_AU1000: + num_ifs = 2 - ni; + iflist[0].base_addr = AU1000_ETH0_BASE; + iflist[1].base_addr = AU1000_ETH1_BASE; + iflist[0].macen_addr = AU1000_MAC0_ENABLE; + iflist[1].macen_addr = AU1000_MAC1_ENABLE; + iflist[0].irq = AU1000_MAC0_DMA_INT; + iflist[1].irq = AU1000_MAC1_DMA_INT; + break; +#endif +#ifdef CONFIG_SOC_AU1100 + case CPU_AU1100: + num_ifs = 1 - ni; + iflist[0].base_addr = AU1100_ETH0_BASE; + iflist[0].macen_addr = AU1100_MAC0_ENABLE; + iflist[0].irq = AU1100_MAC0_DMA_INT; + break; +#endif +#ifdef CONFIG_SOC_AU1500 + case CPU_AU1500: + num_ifs = 2 - ni; + iflist[0].base_addr = AU1500_ETH0_BASE; + iflist[1].base_addr = AU1500_ETH1_BASE; + iflist[0].macen_addr = AU1500_MAC0_ENABLE; + iflist[1].macen_addr = AU1500_MAC1_ENABLE; + iflist[0].irq = AU1500_MAC0_DMA_INT; + iflist[1].irq = AU1500_MAC1_DMA_INT; + break; +#endif +#ifdef CONFIG_SOC_AU1550 + case CPU_AU1550: + num_ifs = 2 - ni; + iflist[0].base_addr = AU1550_ETH0_BASE; + iflist[1].base_addr = AU1550_ETH1_BASE; + iflist[0].macen_addr = AU1550_MAC0_ENABLE; + iflist[1].macen_addr = AU1550_MAC1_ENABLE; + iflist[0].irq = AU1550_MAC0_DMA_INT; + iflist[1].irq = AU1550_MAC1_DMA_INT; + break; +#endif + default: + num_ifs = 0; + } + for(i = 0; i < num_ifs; i++) { + dev = au1000_probe(iflist[i].base_addr, iflist[i].irq, i); + iflist[i].dev = dev; + if (dev) + found_one++; + } + if (!found_one) + return -ENODEV; + return 0; +} + +static int au1000_setup_aneg(struct net_device *dev, u32 advertise) +{ + struct au1000_private *aup = (struct au1000_private *)dev->priv; + u16 ctl, adv; + + /* Setup standard advertise */ + adv = mdio_read(dev, aup->phy_addr, MII_ADVERTISE); + adv &= ~(ADVERTISE_ALL | ADVERTISE_100BASE4); + if (advertise & ADVERTISED_10baseT_Half) + adv |= ADVERTISE_10HALF; + if (advertise & ADVERTISED_10baseT_Full) + adv |= ADVERTISE_10FULL; + if (advertise & ADVERTISED_100baseT_Half) + adv |= ADVERTISE_100HALF; + if (advertise & ADVERTISED_100baseT_Full) + adv |= ADVERTISE_100FULL; + mdio_write(dev, aup->phy_addr, MII_ADVERTISE, adv); + + /* Start/Restart aneg */ + ctl = mdio_read(dev, aup->phy_addr, MII_BMCR); + ctl |= (BMCR_ANENABLE | BMCR_ANRESTART); + mdio_write(dev, aup->phy_addr, MII_BMCR, ctl); + + return 0; +} + +static int au1000_setup_forced(struct net_device *dev, int speed, int fd) +{ + struct au1000_private *aup = (struct au1000_private *)dev->priv; + u16 ctl; + + ctl = mdio_read(dev, aup->phy_addr, MII_BMCR); + ctl &= ~(BMCR_FULLDPLX | BMCR_SPEED100 | BMCR_ANENABLE); + + /* First reset the PHY */ + mdio_write(dev, aup->phy_addr, MII_BMCR, ctl | BMCR_RESET); + + /* Select speed & duplex */ + switch (speed) { + case SPEED_10: + break; + case SPEED_100: + ctl |= BMCR_SPEED100; + break; + case SPEED_1000: + default: + return -EINVAL; + } + if (fd == DUPLEX_FULL) + ctl |= BMCR_FULLDPLX; + mdio_write(dev, aup->phy_addr, MII_BMCR, ctl); + + return 0; +} + + +static void +au1000_start_link(struct net_device *dev, struct ethtool_cmd *cmd) +{ + struct au1000_private *aup = (struct au1000_private *)dev->priv; + u32 advertise; + int autoneg; + int forced_speed; + int forced_duplex; + + /* Default advertise */ + advertise = GENMII_DEFAULT_ADVERTISE; + autoneg = aup->want_autoneg; + forced_speed = SPEED_100; + forced_duplex = DUPLEX_FULL; + + /* Setup link parameters */ + if (cmd) { + if (cmd->autoneg == AUTONEG_ENABLE) { + advertise = cmd->advertising; + autoneg = 1; } else { - printk(KERN_ERR "au1000 eth: unknown Processor ID\n"); - return -ENODEV; - } - // check for valid entries, au1100 only has one entry - if (base_addr && irq) { - if (au1000_probe1(base_addr, irq, i) != 0) - return -ENODEV; + autoneg = 0; + + forced_speed = cmd->speed; + forced_duplex = cmd->duplex; } } + + /* Configure PHY & start aneg */ + aup->want_autoneg = autoneg; + if (autoneg) + au1000_setup_aneg(dev, advertise); + else + au1000_setup_forced(dev, forced_speed, forced_duplex); + mod_timer(&aup->timer, jiffies + HZ); +} + +static int au1000_get_settings(struct net_device *dev, struct ethtool_cmd *cmd) +{ + struct au1000_private *aup = (struct au1000_private *)dev->priv; + u16 link, speed; + + cmd->supported = GENMII_DEFAULT_FEATURES; + cmd->advertising = GENMII_DEFAULT_ADVERTISE; + cmd->port = PORT_MII; + cmd->transceiver = XCVR_EXTERNAL; + cmd->phy_address = aup->phy_addr; + spin_lock_irq(&aup->lock); + cmd->autoneg = aup->want_autoneg; + aup->phy_ops->phy_status(dev, aup->phy_addr, &link, &speed); + if ((speed == IF_PORT_100BASETX) || (speed == IF_PORT_100BASEFX)) + cmd->speed = SPEED_100; + else if (speed == IF_PORT_10BASET) + cmd->speed = SPEED_10; + if (link && (dev->if_port == IF_PORT_100BASEFX)) + cmd->duplex = DUPLEX_FULL; + else + cmd->duplex = DUPLEX_HALF; + spin_unlock_irq(&aup->lock); return 0; } -static int __init -au1000_probe1(long ioaddr, int irq, int port_num) +static int au1000_set_settings(struct net_device *dev, struct ethtool_cmd *cmd) +{ + struct au1000_private *aup = (struct au1000_private *)dev->priv; + unsigned long features = GENMII_DEFAULT_FEATURES; + + if (!capable(CAP_NET_ADMIN)) + return -EPERM; + + if (cmd->autoneg != AUTONEG_ENABLE && cmd->autoneg != AUTONEG_DISABLE) + return -EINVAL; + if (cmd->autoneg == AUTONEG_ENABLE && cmd->advertising == 0) + return -EINVAL; + if (cmd->duplex != DUPLEX_HALF && cmd->duplex != DUPLEX_FULL) + return -EINVAL; + if (cmd->autoneg == AUTONEG_DISABLE) + switch (cmd->speed) { + case SPEED_10: + if (cmd->duplex == DUPLEX_HALF && + (features & SUPPORTED_10baseT_Half) == 0) + return -EINVAL; + if (cmd->duplex == DUPLEX_FULL && + (features & SUPPORTED_10baseT_Full) == 0) + return -EINVAL; + break; + case SPEED_100: + if (cmd->duplex == DUPLEX_HALF && + (features & SUPPORTED_100baseT_Half) == 0) + return -EINVAL; + if (cmd->duplex == DUPLEX_FULL && + (features & SUPPORTED_100baseT_Full) == 0) + return -EINVAL; + break; + default: + return -EINVAL; + } + else if ((features & SUPPORTED_Autoneg) == 0) + return -EINVAL; + + spin_lock_irq(&aup->lock); + au1000_start_link(dev, cmd); + spin_unlock_irq(&aup->lock); + return 0; +} + +static int au1000_nway_reset(struct net_device *dev) +{ + struct au1000_private *aup = (struct au1000_private *)dev->priv; + + if (!aup->want_autoneg) + return -EINVAL; + spin_lock_irq(&aup->lock); + au1000_start_link(dev, NULL); + spin_unlock_irq(&aup->lock); + return 0; +} + +static void +au1000_get_drvinfo(struct net_device *dev, struct ethtool_drvinfo *info) +{ + struct au1000_private *aup = (struct au1000_private *)dev->priv; + + strcpy(info->driver, DRV_NAME); + strcpy(info->version, DRV_VERSION); + info->fw_version[0] = '\0'; + sprintf(info->bus_info, "%s %d", DRV_NAME, aup->mac_id); + info->regdump_len = 0; +} + +static u32 au1000_get_link(struct net_device *dev) +{ + return netif_carrier_ok(dev); +} + +static struct ethtool_ops au1000_ethtool_ops = { + .get_settings = au1000_get_settings, + .set_settings = au1000_set_settings, + .get_drvinfo = au1000_get_drvinfo, + .nway_reset = au1000_nway_reset, + .get_link = au1000_get_link +}; + +static struct net_device * +au1000_probe(u32 ioaddr, int irq, int port_num) { - struct net_device *dev; static unsigned version_printed = 0; struct au1000_private *aup = NULL; - int i, retval = 0; + struct net_device *dev = NULL; db_dest_t *pDB, *pDBfree; char *pmac, *argptr; char ethaddr[6]; + int i, err; - if (!request_region(PHYSADDR(ioaddr), MAC_IOSIZE, "Au1000 ENET")) - return -ENODEV; + if (!request_mem_region(CPHYSADDR(ioaddr), MAC_IOSIZE, "Au1x00 ENET")) + return NULL; - if (version_printed++ == 0) - printk(version); - - retval = -ENOMEM; + if (version_printed++ == 0) + printk("%s version %s %s\n", DRV_NAME, DRV_VERSION, DRV_AUTHOR); dev = alloc_etherdev(sizeof(struct au1000_private)); if (!dev) { printk (KERN_ERR "au1000 eth: alloc_etherdev failed\n"); - goto out; + return NULL; } - SET_MODULE_OWNER(dev); + if ((err = register_netdev(dev))) { + printk(KERN_ERR "Au1x_eth Cannot register net device err %d\n", + err); + free_netdev(dev); + return NULL; + } - printk("%s: Au1xxx ethernet found at 0x%lx, irq %d\n", - dev->name, ioaddr, irq); + printk("%s: Au1x Ethernet found at 0x%x, irq %d\n", + dev->name, ioaddr, irq); aup = dev->priv; /* Allocate the data buffers */ - aup->vaddr = (u32)dma_alloc(MAX_BUF_SIZE * - (NUM_TX_BUFFS+NUM_RX_BUFFS), &aup->dma_addr); - if (!aup->vaddr) - goto out1; + /* Snooping works fine with eth on all au1xxx */ + aup->vaddr = (u32)dma_alloc_noncoherent(NULL, + MAX_BUF_SIZE * (NUM_TX_BUFFS+NUM_RX_BUFFS), + &aup->dma_addr, + 0); + if (!aup->vaddr) { + free_netdev(dev); + release_mem_region(CPHYSADDR(ioaddr), MAC_IOSIZE); + return NULL; + } /* aup->mac is the base address of the MAC's registers */ aup->mac = (volatile mac_reg_t *)((unsigned long)ioaddr); /* Setup some variables for quick register address access */ - switch (ioaddr) { - case AU1000_ETH0_BASE: - case AU1500_ETH0_BASE: + if (ioaddr == iflist[0].base_addr) + { /* check env variables first */ if (!get_ethernet_addr(ethaddr)) { - memcpy(au1000_mac_addr, ethaddr, sizeof(dev->dev_addr)); + memcpy(au1000_mac_addr, ethaddr, sizeof(au1000_mac_addr)); } else { /* Check command line */ argptr = prom_getcmdline(); @@ -708,38 +1507,32 @@ } else { str2eaddr(ethaddr, pmac + strlen("ethaddr=")); memcpy(au1000_mac_addr, ethaddr, - sizeof(dev->dev_addr)); + sizeof(au1000_mac_addr)); } } - if (ioaddr == AU1000_ETH0_BASE) - aup->enable = (volatile u32 *) - ((unsigned long)AU1000_MAC0_ENABLE); - else aup->enable = (volatile u32 *) - ((unsigned long)AU1500_MAC0_ENABLE); - memcpy(dev->dev_addr, au1000_mac_addr, sizeof(dev->dev_addr)); + ((unsigned long)iflist[0].macen_addr); + memcpy(dev->dev_addr, au1000_mac_addr, sizeof(au1000_mac_addr)); setup_hw_rings(aup, MAC0_RX_DMA_ADDR, MAC0_TX_DMA_ADDR); - break; - case AU1000_ETH1_BASE: - case AU1500_ETH1_BASE: - if (ioaddr == AU1000_ETH1_BASE) - aup->enable = (volatile u32 *) - ((unsigned long)AU1000_MAC1_ENABLE); + aup->mac_id = 0; + au_macs[0] = aup; + } else + if (ioaddr == iflist[1].base_addr) + { aup->enable = (volatile u32 *) - ((unsigned long)AU1500_MAC1_ENABLE); - memcpy(dev->dev_addr, au1000_mac_addr, sizeof(dev->dev_addr)); + ((unsigned long)iflist[1].macen_addr); + memcpy(dev->dev_addr, au1000_mac_addr, sizeof(au1000_mac_addr)); dev->dev_addr[4] += 0x10; setup_hw_rings(aup, MAC1_RX_DMA_ADDR, MAC1_TX_DMA_ADDR); - break; - default: + aup->mac_id = 1; + au_macs[1] = aup; + } + else + { printk(KERN_ERR "%s: bad ioaddr\n", dev->name); - break; - } - aup->phy_addr = PHY_ADDRESS; - /* bring the device out of reset, otherwise probing the mii * will hang */ *aup->enable = MAC_EN_CLOCK_ENABLE; @@ -748,15 +1541,22 @@ MAC_EN_RESET2 | MAC_EN_CLOCK_ENABLE; au_sync_delay(2); - retval = mii_probe(dev); - if (retval) - goto out2; + aup->mii = kmalloc(sizeof(struct mii_phy), GFP_KERNEL); + if (!aup->mii) { + printk(KERN_ERR "%s: out of memory\n", dev->name); + goto err_out; + } + aup->mii->mii_control_reg = 0; + aup->mii->mii_data_reg = 0; + + if (mii_probe(dev) != 0) { + goto err_out; + } - retval = -EINVAL; pDBfree = NULL; /* setup the data buffer descriptors and attach a buffer to each one */ pDB = aup->db; - for (i=0; i<(NUM_TX_BUFFS+NUM_RX_BUFFS); i++) { + for (i = 0; i < (NUM_TX_BUFFS+NUM_RX_BUFFS); i++) { pDB->pnext = pDBfree; pDBfree = pDB; pDB->vaddr = (u32 *)((unsigned)aup->vaddr + MAX_BUF_SIZE*i); @@ -765,15 +1565,19 @@ } aup->pDBfree = pDBfree; - for (i=0; irx_dma_ring[i]->buff_stat = (unsigned)pDB->dma_addr; aup->rx_db_inuse[i] = pDB; } - for (i=0; itx_dma_ring[i]->buff_stat = (unsigned)pDB->dma_addr; aup->tx_dma_ring[i]->len = 0; aup->tx_db_inuse[i] = pDB; @@ -788,6 +1592,7 @@ dev->get_stats = au1000_get_stats; dev->set_multicast_list = &set_rx_mode; dev->do_ioctl = &au1000_ioctl; + SET_ETHTOOL_OPS(dev, &au1000_ethtool_ops); dev->set_config = &au1000_set_config; dev->tx_timeout = au1000_tx_timeout; dev->watchdog_timeo = ETH_TX_TIMEOUT; @@ -798,23 +1603,32 @@ */ reset_mac(dev); - retval = register_netdev(dev); - if (retval) - goto out2; - return 0; + return dev; -out2: - dma_free(aup->vaddr, MAX_BUF_SIZE * (NUM_TX_BUFFS+NUM_RX_BUFFS)); -out1: +err_out: + /* here we should have a valid dev plus aup-> register addresses + * so we can reset the mac properly.*/ + reset_mac(dev); + if (aup->mii) + kfree(aup->mii); + for (i = 0; i < NUM_RX_DMA; i++) { + if (aup->rx_db_inuse[i]) + ReleaseDB(aup, aup->rx_db_inuse[i]); + } + for (i = 0; i < NUM_TX_DMA; i++) { + if (aup->tx_db_inuse[i]) + ReleaseDB(aup, aup->tx_db_inuse[i]); + } + dma_free_noncoherent(NULL, + MAX_BUF_SIZE * (NUM_TX_BUFFS+NUM_RX_BUFFS), + (void *)aup->vaddr, + aup->dma_addr); + unregister_netdev(dev); free_netdev(dev); -out: - release_region(PHYSADDR(ioaddr), MAC_IOSIZE); - printk(KERN_ERR "%s: au1000_probe1 failed. Returns %d\n", - dev->name, retval); - return retval; + release_mem_region(CPHYSADDR(ioaddr), MAC_IOSIZE); + return NULL; } - /* * Initialize the interface. * @@ -832,7 +1646,8 @@ u32 control; u16 link, speed; - if (au1000_debug > 4) printk("%s: au1000_init\n", dev->name); + if (au1000_debug > 4) + printk("%s: au1000_init\n", dev->name); spin_lock_irqsave(&aup->lock, flags); @@ -852,7 +1667,7 @@ aup->mac->mac_addr_low = dev->dev_addr[3]<<24 | dev->dev_addr[2]<<16 | dev->dev_addr[1]<<8 | dev->dev_addr[0]; - for (i=0; irx_dma_ring[i]->buff_stat |= RX_DMA_ENABLE; } au_sync(); @@ -865,7 +1680,13 @@ if (link && (dev->if_port == IF_PORT_100BASEFX)) { control |= MAC_FULL_DUPLEX; } + + /* fix for startup without cable */ + if (!link) + dev->flags &= ~IFF_RUNNING; + aup->mac->control = control; + aup->mac->vlan1_tag = 0x8100; /* activate vlan support */ au_sync(); spin_unlock_irqrestore(&aup->lock, flags); @@ -949,6 +1770,7 @@ return retval; } + init_timer(&aup->timer); /* used in ioctl() */ aup->timer.expires = RUN_AT((3*HZ)); aup->timer.data = (unsigned long)dev; aup->timer.function = &au1000_timer; /* timer handler */ @@ -968,22 +1790,49 @@ if (au1000_debug > 4) printk("%s: close: dev=%p\n", dev->name, dev); + reset_mac(dev); + spin_lock_irqsave(&aup->lock, flags); /* stop the device */ - if (netif_device_present(dev)) - netif_stop_queue(dev); + netif_stop_queue(dev); /* disable the interrupt */ free_irq(dev->irq, dev); spin_unlock_irqrestore(&aup->lock, flags); - reset_mac(dev); return 0; } static void __exit au1000_cleanup_module(void) { + int i, j; + struct net_device *dev; + struct au1000_private *aup; + + for (i = 0; i < num_ifs; i++) { + dev = iflist[i].dev; + if (dev) { + aup = (struct au1000_private *) dev->priv; + unregister_netdev(dev); + if (aup->mii) + kfree(aup->mii); + for (j = 0; j < NUM_RX_DMA; j++) { + if (aup->rx_db_inuse[j]) + ReleaseDB(aup, aup->rx_db_inuse[j]); + } + for (j = 0; j < NUM_TX_DMA; j++) { + if (aup->tx_db_inuse[j]) + ReleaseDB(aup, aup->tx_db_inuse[j]); + } + dma_free_noncoherent(NULL, + MAX_BUF_SIZE * (NUM_TX_BUFFS+NUM_RX_BUFFS), + (void *)aup->vaddr, + aup->dma_addr); + free_netdev(dev); + release_mem_region(CPHYSADDR(iflist[i].base_addr), MAC_IOSIZE); + } + } } @@ -1028,9 +1877,8 @@ ptxd = aup->tx_dma_ring[aup->tx_tail]; while (ptxd->buff_stat & TX_T_DONE) { - update_tx_stats(dev, ptxd->status, aup->tx_len[aup->tx_tail] & 0x3ff); + update_tx_stats(dev, ptxd->status, ptxd->len & 0x3ff); ptxd->buff_stat &= ~TX_T_DONE; - aup->tx_len[aup->tx_tail] = 0; ptxd->len = 0; au_sync(); @@ -1056,7 +1904,7 @@ db_dest_t *pDB; int i; - if (au1000_debug > 4) + if (au1000_debug > 5) printk("%s: tx: aup %x len=%d, data=%p, head %d\n", dev->name, (unsigned)aup, skb->len, skb->data, aup->tx_head); @@ -1070,8 +1918,7 @@ return 1; } else if (buff_stat & TX_T_DONE) { - update_tx_stats(dev, ptxd->status, aup->tx_len[aup->tx_head] & 0x3ff); - aup->tx_len[aup->tx_head] = 0; + update_tx_stats(dev, ptxd->status, ptxd->len & 0x3ff); ptxd->len = 0; } @@ -1082,17 +1929,15 @@ pDB = aup->tx_db_inuse[aup->tx_head]; memcpy((void *)pDB->vaddr, skb->data, skb->len); - if (skb->len < MAC_MIN_PKT_SIZE) { - for (i=skb->len; ilen < ETH_ZLEN) { + for (i=skb->len; ivaddr)[i] = 0; } - aup->tx_len[aup->tx_head] = MAC_MIN_PKT_SIZE; - ptxd->len = MAC_MIN_PKT_SIZE; + ptxd->len = ETH_ZLEN; } - else { - aup->tx_len[aup->tx_head] = skb->len; + else ptxd->len = skb->len; - } + ptxd->buff_stat = pDB->dma_addr | TX_DMA_ENABLE; au_sync(); dev_kfree_skb(skb); @@ -1137,8 +1982,9 @@ volatile rx_dma_t *prxd; u32 buff_stat, status; db_dest_t *pDB; + u32 frmlen; - if (au1000_debug > 4) + if (au1000_debug > 5) printk("%s: au1000_rx head %d\n", dev->name, aup->rx_head); prxd = aup->rx_dma_ring[aup->rx_head]; @@ -1150,7 +1996,9 @@ if (!(status & RX_ERROR)) { /* good frame */ - skb = dev_alloc_skb((status & RX_FRAME_LEN_MASK) + 2); + frmlen = (status & RX_FRAME_LEN_MASK); + frmlen -= 4; /* Remove FCS */ + skb = dev_alloc_skb(frmlen + 2); if (skb == NULL) { printk(KERN_ERR "%s: Memory squeeze, dropping packet.\n", @@ -1160,9 +2008,9 @@ } skb->dev = dev; skb_reserve(skb, 2); /* 16 byte IP header align */ - eth_copy_and_sum(skb, (unsigned char *)pDB->vaddr, - status & RX_FRAME_LEN_MASK, 0); - skb_put(skb, status & RX_FRAME_LEN_MASK); + eth_copy_and_sum(skb, + (unsigned char *)pDB->vaddr, frmlen, 0); + skb_put(skb, frmlen); skb->protocol = eth_type_trans(skb, dev); netif_rx(skb); /* pass the packet to upper layers */ } @@ -1206,17 +2054,20 @@ /* * Au1000 interrupt service routine. */ -irqreturn_t au1000_interrupt(int irq, void *dev_id, struct pt_regs *regs) +static irqreturn_t au1000_interrupt(int irq, void *dev_id, struct pt_regs *regs) { struct net_device *dev = (struct net_device *) dev_id; if (dev == NULL) { printk(KERN_ERR "%s: isr: null dev ptr\n", dev->name); - return IRQ_NONE; + return IRQ_RETVAL(1); } - au1000_tx_ack(dev); + + /* Handle RX interrupts first to minimize chance of overrun */ + au1000_rx(dev); - return IRQ_HANDLED; + au1000_tx_ack(dev); + return IRQ_RETVAL(1); } @@ -1233,6 +2084,23 @@ netif_wake_queue(dev); } + +static unsigned const ethernet_polynomial = 0x04c11db7U; +static inline u32 ether_crc(int length, unsigned char *data) +{ + int crc = -1; + + while(--length >= 0) { + unsigned char current_octet = *data++; + int bit; + for (bit = 0; bit < 8; bit++, current_octet >>= 1) + crc = (crc << 1) ^ + ((crc < 0) ^ (current_octet & 1) ? + ethernet_polynomial : 0); + } + return crc; +} + static void set_rx_mode(struct net_device *dev) { struct au1000_private *aup = (struct au1000_private *) dev->priv; @@ -1256,8 +2124,8 @@ mc_filter[1] = mc_filter[0] = 0; for (i = 0, mclist = dev->mc_list; mclist && i < dev->mc_count; i++, mclist = mclist->next) { - set_bit(ether_crc_le(ETH_ALEN, mclist->dmi_addr)>>26, - mc_filter); + set_bit(ether_crc(ETH_ALEN, mclist->dmi_addr)>>26, + (long *)mc_filter); } aup->mac->multi_hash_high = mc_filter[1]; aup->mac->multi_hash_low = mc_filter[0]; @@ -1269,28 +2137,28 @@ static int au1000_ioctl(struct net_device *dev, struct ifreq *rq, int cmd) { + struct au1000_private *aup = (struct au1000_private *)dev->priv; u16 *data = (u16 *)&rq->ifr_ifru; - /* fixme */ switch(cmd) { - case SIOCGMIIPHY: /* Get the address of the PHY in use. */ - data[0] = PHY_ADDRESS; - return 0; - - case SIOCGMIIREG: /* Read the specified MII register. */ - //data[3] = mdio_read(ioaddr, data[0], data[1]); - return 0; - - case SIOCSMIIREG: /* Write the specified MII register */ - if (!capable(CAP_NET_ADMIN)) - return -EPERM; - - //mdio_write(ioaddr, data[0], data[1], data[2]); - return 0; - - default: - return -EOPNOTSUPP; + case SIOCDEVPRIVATE: /* Get the address of the PHY in use. */ + case SIOCGMIIPHY: + if (!netif_running(dev)) return -EINVAL; + data[0] = aup->phy_addr; + case SIOCDEVPRIVATE+1: /* Read the specified MII register. */ + case SIOCGMIIREG: + data[3] = mdio_read(dev, data[0], data[1]); + return 0; + case SIOCDEVPRIVATE+2: /* Write the specified MII register */ + case SIOCSMIIREG: + if (!capable(CAP_NET_ADMIN)) + return -EPERM; + mdio_write(dev, data[0], data[1],data[2]); + return 0; + default: + return -EOPNOTSUPP; } + } @@ -1352,7 +2220,6 @@ /* set Speed to 100Mbps, Half Duplex */ /* disable auto negotiation and enable 100MBit Mode */ control = mdio_read(dev, aup->phy_addr, MII_CONTROL); - printk("read control %x\n", control); control &= ~(MII_CNTL_AUTO | MII_CNTL_FDX); control |= MII_CNTL_F100; mdio_write(dev, aup->phy_addr, MII_CONTROL, control); diff -Nru a/drivers/net/au1000_eth.h b/drivers/net/au1000_eth.h --- a/drivers/net/au1000_eth.h 2005-03-06 18:36:50 -05:00 +++ b/drivers/net/au1000_eth.h 2005-03-06 18:36:50 -05:00 @@ -1,10 +1,13 @@ /* - * Alchemy Semi Au1000 ethernet driver include file + * + * Alchemy Au1x00 ethernet driver include file * * Author: Pete Popov * * Copyright 2001 MontaVista Software Inc. * + * ######################################################################## + * * This program is free software; you can distribute it and/or modify it * under the terms of the GNU General Public License (Version 2) as * published by the Free Software Foundation. @@ -17,14 +20,16 @@ * You should have received a copy of the GNU General Public License along * with this program; if not, write to the Free Software Foundation, Inc., * 59 Temple Place - Suite 330, Boston MA 02111-1307, USA. + * + * ######################################################################## + * + * */ -#include -#define NUM_INTERFACES 2 #define MAC_IOSIZE 0x10000 -#define NUM_RX_DMA 4 /* Au1000 has 4 rx hardware descriptors */ -#define NUM_TX_DMA 4 /* Au1000 has 4 tx hardware descriptors */ +#define NUM_RX_DMA 4 /* Au1x00 has 4 rx hardware descriptors */ +#define NUM_TX_DMA 4 /* Au1x00 has 4 tx hardware descriptors */ #define NUM_RX_BUFFS 4 #define NUM_TX_BUFFS 4 @@ -33,12 +38,6 @@ #define ETH_TX_TIMEOUT HZ/4 #define MAC_MIN_PKT_SIZE 64 -#if defined(CONFIG_MIPS_PB1000) || defined(CONFIG_MIPS_PB1500) || defined(CONFIG_MIPS_PB1100) -#define PHY_ADDRESS 0 -#define PHY_CONTROL_DEFAULT 0x3000 -#define PHY_CONTROL_REG_ADDR 0 -#endif - #define MULTICAST_FILTER_LIMIT 64 /* FIXME @@ -54,11 +53,13 @@ #define MII_ANLPAR 0x0005 #define MII_AEXP 0x0006 #define MII_ANEXT 0x0007 -#define MII_LSI_CONFIG 0x0011 -#define MII_LSI_STAT 0x0012 -#define MII_AUX_CNTRL 0x0018 -#define MII_INT 0x001A +#define MII_LSI_PHY_CONFIG 0x0011 +/* Status register */ +#define MII_LSI_PHY_STAT 0x0012 +#define MII_AMD_PHY_STAT MII_LSI_PHY_STAT +#define MII_INTEL_PHY_STAT 0x0011 +#define MII_AUX_CNTRL 0x0018 /* mii registers specific to AMD 79C901 */ #define MII_STATUS_SUMMARY = 0x0018 @@ -121,23 +122,30 @@ #define MII_STSSUM_AUTO 0x0002 #define MII_STSSUM_SPD 0x0001 -/* lsi status register */ - -#define MII_LSI_STAT_FDX 0x0040 -#define MII_LSI_STAT_SPD 0x0080 +/* lsi phy status register */ +#define MII_LSI_PHY_STAT_FDX 0x0040 +#define MII_LSI_PHY_STAT_SPD 0x0080 + +/* amd phy status register */ +#define MII_AMD_PHY_STAT_FDX 0x0800 +#define MII_AMD_PHY_STAT_SPD 0x0400 + +/* intel phy status register */ +#define MII_INTEL_PHY_STAT_FDX 0x0200 +#define MII_INTEL_PHY_STAT_SPD 0x4000 /* Auxilliary Control/Status Register */ #define MII_AUX_FDX 0x0001 #define MII_AUX_100 0x0002 #define MII_AUX_F100 0x0004 #define MII_AUX_ANEG 0x0008 -#define MII_FDX_LED 0x8000 typedef struct mii_phy { struct mii_phy * next; struct mii_chip_info * chip_info; - int phy_addr; u16 status; + u32 *mii_control_reg; + u32 *mii_data_reg; } mii_phy_t; struct phy_ops { @@ -197,7 +205,6 @@ db_dest_t db[NUM_RX_BUFFS+NUM_TX_BUFFS]; volatile rx_dma_t *rx_dma_ring[NUM_RX_DMA]; volatile tx_dma_t *tx_dma_ring[NUM_TX_DMA]; - int tx_len[NUM_TX_DMA]; db_dest_t *rx_db_inuse[NUM_RX_DMA]; db_dest_t *tx_db_inuse[NUM_TX_DMA]; u32 rx_head; @@ -205,6 +212,7 @@ u32 tx_tail; u32 tx_full; + int mac_id; mii_phy_t *mii; struct phy_ops *phy_ops; @@ -218,9 +226,10 @@ u8 *hash_table; u32 hash_mode; u32 intr_work_done; /* number of Rx and Tx pkts processed in the isr */ - u32 phy_addr; /* PHY address */ + int phy_addr; /* phy address */ u32 options; /* User-settable misc. driver options. */ u32 drv_flags; + int want_autoneg; struct net_device_stats stats; struct timer_list timer; spinlock_t lock; /* Serialise access to device */ diff -Nru a/drivers/net/bagetlance.c b/drivers/net/bagetlance.c --- a/drivers/net/bagetlance.c 2005-03-06 18:36:50 -05:00 +++ /dev/null Wed Dec 31 16:00:00 196900 @@ -1,1368 +0,0 @@ -/* - * bagetlance.c: Ethernet driver for VME Lance cards on Baget/MIPS - * This code stealed and adopted from linux/drivers/net/atarilance.c - * See that for author info - * - * Copyright (C) 1998 Gleb Raiko & Vladimir Roganov - */ - -/* - * Driver code for Baget/Lance taken from atarilance.c, which also - * works well in case of Besta. Most significant changes made here - * related with 16BIT-only access to A24 space. - */ - -static char *version = "bagetlance.c: v1.1 11/10/98\n"; - -#include -#include -#include -#include -#include -#include -#include -#include -#include -#include -#include -#include - -#include -#include -#include - -#define BAGET_LANCE_IRQ BAGET_IRQ_MASK(0xdf) - -/* - * Define following if you don't need 16BIT-only access to Lance memory - * (Normally BAGET needs it) - */ -#undef NORMAL_MEM_ACCESS - -/* Debug level: - * 0 = silent, print only serious errors - * 1 = normal, print error messages - * 2 = debug, print debug infos - * 3 = debug, print even more debug infos (packet data) - */ - -#define LANCE_DEBUG 1 - -#ifdef LANCE_DEBUG -static int lance_debug = LANCE_DEBUG; -#else -static int lance_debug = 1; -#endif -MODULE_PARM(lance_debug, "i"); -MODULE_PARM_DESC(lance_debug, "Lance debug level (0-3)"); -MODULE_LICENSE("GPL"); - -/* Print debug messages on probing? */ -#undef LANCE_DEBUG_PROBE - -#define DPRINTK(n,a) \ - do { \ - if (lance_debug >= n) \ - printk a; \ - } while( 0 ) - -#ifdef LANCE_DEBUG_PROBE -# define PROBE_PRINT(a) printk a -#else -# define PROBE_PRINT(a) -#endif - -/* These define the number of Rx and Tx buffers as log2. (Only powers - * of two are valid) - * Much more rx buffers (32) are reserved than tx buffers (8), since receiving - * is more time critical then sending and packets may have to remain in the - * board's memory when main memory is low. - */ - -/* Baget Lance has 64K on-board memory, so it looks we can't increase - buffer quantity (40*1.5K is about 64K) */ - -#define TX_LOG_RING_SIZE 3 -#define RX_LOG_RING_SIZE 5 - -/* These are the derived values */ - -#define TX_RING_SIZE (1 << TX_LOG_RING_SIZE) -#define TX_RING_LEN_BITS (TX_LOG_RING_SIZE << 5) -#define TX_RING_MOD_MASK (TX_RING_SIZE - 1) - -#define RX_RING_SIZE (1 << RX_LOG_RING_SIZE) -#define RX_RING_LEN_BITS (RX_LOG_RING_SIZE << 5) -#define RX_RING_MOD_MASK (RX_RING_SIZE - 1) - -/* The LANCE Rx and Tx ring descriptors. */ -struct lance_rx_head { - volatile unsigned short base; /* Low word of base addr */ -#ifdef NORMAL_MEM_ACCESS - /* Following two fields are joined into one short to guarantee - 16BIT access to Baget lance registers */ - volatile unsigned char flag; - unsigned char base_hi; /* High word of base addr (unused) */ -#else -/* Following macros are used as replecements to 8BIT fields */ -#define GET_FLAG(h) (((h)->flag_base_hi >> 8) & 0xff) -#define SET_FLAG(h,f) (h)->flag_base_hi = ((h)->flag_base_hi & 0xff) | \ - (((unsigned)(f)) << 8) - volatile unsigned short flag_base_hi; -#endif - volatile short buf_length; /* This length is 2s complement! */ - volatile short msg_length; /* This length is "normal". */ -}; - - -struct lance_tx_head { - volatile unsigned short base; /* Low word of base addr */ -#ifdef NORMAL_MEM_ACCESS -/* See comments above about 8BIT-access Baget A24-space problems */ - volatile unsigned char flag; - unsigned char base_hi; /* High word of base addr (unused) */ -#else - volatile unsigned short flag_base_hi; -#endif - volatile short length; /* Length is 2s complement! */ - volatile short misc; -}; - -struct ringdesc { - volatile unsigned short adr_lo; /* Low 16 bits of address */ -#ifdef NORMAL_MEM_ACCESS -/* See comments above about 8BIT-access Bage A24-space problems */ - unsigned char len; /* Length bits */ - unsigned char adr_hi; /* High 8 bits of address (unused) */ -#else - volatile unsigned short len_adr_hi; -#endif -}; - -/* The LANCE initialization block, described in databook. */ -struct lance_init_block { - unsigned short mode; /* Pre-set mode */ - unsigned char hwaddr[6]; /* Physical ethernet address */ - unsigned filter[2]; /* Multicast filter (unused). */ - /* Receive and transmit ring base, along with length bits. */ - struct ringdesc rx_ring; - struct ringdesc tx_ring; -}; - -/* The whole layout of the Lance shared memory */ -struct lance_memory { - struct lance_init_block init; - struct lance_tx_head tx_head[TX_RING_SIZE]; - struct lance_rx_head rx_head[RX_RING_SIZE]; - char packet_area[0]; /* packet data follow after the - * init block and the ring - * descriptors and are located - * at runtime */ -}; - -/* RieblCard specifics: - * The original TOS driver for these cards reserves the area from offset - * 0xee70 to 0xeebb for storing configuration data. Of interest to us is the - * Ethernet address there, and the magic for verifying the data's validity. - * The reserved area isn't touch by packet buffers. Furthermore, offset 0xfffe - * is reserved for the interrupt vector number. - */ -#define RIEBL_RSVD_START 0xee70 -#define RIEBL_RSVD_END 0xeec0 -#define RIEBL_MAGIC 0x09051990 -#define RIEBL_MAGIC_ADDR ((unsigned long *)(((char *)MEM) + 0xee8a)) -#define RIEBL_HWADDR_ADDR ((unsigned char *)(((char *)MEM) + 0xee8e)) -#define RIEBL_IVEC_ADDR ((unsigned short *)(((char *)MEM) + 0xfffe)) - -/* This is a default address for the old RieblCards without a battery - * that have no ethernet address at boot time. 00:00:36:04 is the - * prefix for Riebl cards, the 00:00 at the end is arbitrary. - */ - -static unsigned char OldRieblDefHwaddr[6] = { - 0x00, 0x00, 0x36, 0x04, 0x00, 0x00 -}; - -/* I/O registers of the Lance chip */ - -struct lance_ioreg { -/* base+0x0 */ volatile unsigned short data; -/* base+0x2 */ volatile unsigned short addr; - unsigned char _dummy1[3]; -/* base+0x7 */ volatile unsigned char ivec; - unsigned char _dummy2[5]; -/* base+0xd */ volatile unsigned char eeprom; - unsigned char _dummy3; -/* base+0xf */ volatile unsigned char mem; -}; - -/* Types of boards this driver supports */ - -enum lance_type { - OLD_RIEBL, /* old Riebl card without battery */ - NEW_RIEBL, /* new Riebl card with battery */ - PAM_CARD /* PAM card with EEPROM */ -}; - -static char *lance_names[] = { - "Riebl-Card (without battery)", - "Riebl-Card (with battery)", - "PAM intern card" -}; - -/* The driver's private device structure */ - -struct lance_private { - enum lance_type cardtype; - struct lance_ioreg *iobase; - struct lance_memory *mem; - int cur_rx, cur_tx; /* The next free ring entry */ - int dirty_tx; /* Ring entries to be freed. */ - /* copy function */ - void *(*memcpy_f)( void *, const void *, size_t ); - struct net_device_stats stats; -/* These two must be longs for set_bit() */ - long tx_full; - long lock; -}; - -/* I/O register access macros */ - -#define MEM lp->mem -#define DREG IO->data -#define AREG IO->addr -#define REGA(a) ( AREG = (a), DREG ) - -/* Definitions for packet buffer access: */ -#define PKT_BUF_SZ 1544 -/* Get the address of a packet buffer corresponding to a given buffer head */ -#define PKTBUF_ADDR(head) (((unsigned char *)(MEM)) + (head)->base) - -/* Possible memory/IO addresses for probing */ - -struct lance_addr { - unsigned long memaddr; - unsigned long ioaddr; - int slow_flag; -} lance_addr_list[] = { - { BAGET_LANCE_MEM_BASE, BAGET_LANCE_IO_BASE, 1 } /* Baget Lance */ -}; - -#define N_LANCE_ADDR (sizeof(lance_addr_list)/sizeof(*lance_addr_list)) - - -#define LANCE_HI_BASE (0xff & (BAGET_LANCE_MEM_BASE >> 16)) - -/* Definitions for the Lance */ - -/* tx_head flags */ -#define TMD1_ENP 0x01 /* end of packet */ -#define TMD1_STP 0x02 /* start of packet */ -#define TMD1_DEF 0x04 /* deferred */ -#define TMD1_ONE 0x08 /* one retry needed */ -#define TMD1_MORE 0x10 /* more than one retry needed */ -#define TMD1_ERR 0x40 /* error summary */ -#define TMD1_OWN 0x80 /* ownership (set: chip owns) */ - -#define TMD1_OWN_CHIP TMD1_OWN -#define TMD1_OWN_HOST 0 - -/* tx_head misc field */ -#define TMD3_TDR 0x03FF /* Time Domain Reflectometry counter */ -#define TMD3_RTRY 0x0400 /* failed after 16 retries */ -#define TMD3_LCAR 0x0800 /* carrier lost */ -#define TMD3_LCOL 0x1000 /* late collision */ -#define TMD3_UFLO 0x4000 /* underflow (late memory) */ -#define TMD3_BUFF 0x8000 /* buffering error (no ENP) */ - -/* rx_head flags */ -#define RMD1_ENP 0x01 /* end of packet */ -#define RMD1_STP 0x02 /* start of packet */ -#define RMD1_BUFF 0x04 /* buffer error */ -#define RMD1_CRC 0x08 /* CRC error */ -#define RMD1_OFLO 0x10 /* overflow */ -#define RMD1_FRAM 0x20 /* framing error */ -#define RMD1_ERR 0x40 /* error summary */ -#define RMD1_OWN 0x80 /* ownership (set: ship owns) */ - -#define RMD1_OWN_CHIP RMD1_OWN -#define RMD1_OWN_HOST 0 - -/* register names */ -#define CSR0 0 /* mode/status */ -#define CSR1 1 /* init block addr (low) */ -#define CSR2 2 /* init block addr (high) */ -#define CSR3 3 /* misc */ -#define CSR8 8 /* address filter */ -#define CSR15 15 /* promiscuous mode */ - -/* CSR0 */ -/* (R=readable, W=writeable, S=set on write, C=clear on write) */ -#define CSR0_INIT 0x0001 /* initialize (RS) */ -#define CSR0_STRT 0x0002 /* start (RS) */ -#define CSR0_STOP 0x0004 /* stop (RS) */ -#define CSR0_TDMD 0x0008 /* transmit demand (RS) */ -#define CSR0_TXON 0x0010 /* transmitter on (R) */ -#define CSR0_RXON 0x0020 /* receiver on (R) */ -#define CSR0_INEA 0x0040 /* interrupt enable (RW) */ -#define CSR0_INTR 0x0080 /* interrupt active (R) */ -#define CSR0_IDON 0x0100 /* initialization done (RC) */ -#define CSR0_TINT 0x0200 /* transmitter interrupt (RC) */ -#define CSR0_RINT 0x0400 /* receiver interrupt (RC) */ -#define CSR0_MERR 0x0800 /* memory error (RC) */ -#define CSR0_MISS 0x1000 /* missed frame (RC) */ -#define CSR0_CERR 0x2000 /* carrier error (no heartbeat :-) (RC) */ -#define CSR0_BABL 0x4000 /* babble: tx-ed too many bits (RC) */ -#define CSR0_ERR 0x8000 /* error (RC) */ - -/* CSR3 */ -#define CSR3_BCON 0x0001 /* byte control */ -#define CSR3_ACON 0 // fixme: 0x0002 /* ALE control */ -#define CSR3_BSWP 0x0004 /* byte swap (1=big endian) */ - - - -/***************************** Prototypes *****************************/ - -static int addr_accessible( volatile void *regp, int wordflag, int - writeflag ); -static int lance_probe1( struct net_device *dev, struct lance_addr *init_rec ); -static int lance_open( struct net_device *dev ); -static void lance_init_ring( struct net_device *dev ); -static int lance_start_xmit( struct sk_buff *skb, struct net_device *dev ); -static irqreturn_t lance_interrupt( int irq, void *dev_id, struct pt_regs *fp ); -static int lance_rx( struct net_device *dev ); -static int lance_close( struct net_device *dev ); -static struct net_device_stats *lance_get_stats( struct net_device *dev ); -static void set_multicast_list( struct net_device *dev ); -static int lance_set_mac_address( struct net_device *dev, void *addr ); - -/************************* End of Prototypes **************************/ - -/* Network traffic statistic (bytes) */ - -int lance_stat = 0; - -static void update_lance_stat (int len) { - lance_stat += len; -} - -/* - This function is used to access Baget/Lance memory to avoid - 8/32BIT access to VAC A24 space - ALL memcpy calls was chenged to this function to avoid dbe problems - Don't confuse with function name -- it stays from original code -*/ - -void *slow_memcpy( void *dst, const void *src, size_t len ) - -{ - unsigned long to = (unsigned long)dst; - unsigned long from = (unsigned long)src; - unsigned long to_end = to +len; - - /* Unaligned flags */ - - int odd_from = from & 1; - int odd_to = to & 1; - int odd_to_end = to_end & 1; - - /* Align for 16BIT-access first */ - - register unsigned short *from_a = (unsigned short*) (from & ~1); - register unsigned short *to_a = (unsigned short*) (to & ~1); - register unsigned short *to_end_a = (unsigned short*) (to_end & ~1); - - /* Caching values -- not in loop invariant */ - - register unsigned short from_v; - register unsigned short to_v; - - /* Invariant is: from_a and to_a are pointers before or exactly to - currently copying byte */ - - if (odd_to) { - /* First byte unaligned case */ - from_v = *from_a; - to_v = *to_a; - - to_v &= ~0xff; - to_v |= 0xff & (from_v >> (odd_from ? 0 : 8)); - *to_a++ = to_v; - - if (odd_from) from_a++; - } - if (odd_from == odd_to) { - /* Same parity */ - while (to_a + 7 < to_end_a) { - unsigned long dummy1, dummy2; - unsigned long reg1, reg2, reg3, reg4; - - __asm__ __volatile__( - ".set\tnoreorder\n\t" - ".set\tnoat\n\t" - "lh\t%2,0(%1)\n\t" - "nop\n\t" - "lh\t%3,2(%1)\n\t" - "sh\t%2,0(%0)\n\t" - "lh\t%4,4(%1)\n\t" - "sh\t%3,2(%0)\n\t" - "lh\t%5,6(%1)\n\t" - "sh\t%4,4(%0)\n\t" - "lh\t%2,8(%1)\n\t" - "sh\t%5,6(%0)\n\t" - "lh\t%3,10(%1)\n\t" - "sh\t%2,8(%0)\n\t" - "lh\t%4,12(%1)\n\t" - "sh\t%3,10(%0)\n\t" - "lh\t%5,14(%1)\n\t" - "sh\t%4,12(%0)\n\t" - "nop\n\t" - "sh\t%5,14(%0)\n\t" - ".set\tat\n\t" - ".set\treorder" - :"=r" (dummy1), "=r" (dummy2), - "=&r" (reg1), "=&r" (reg2), "=&r" (reg3), "=&r" (reg4) - :"0" (to_a), "1" (from_a) - :"memory"); - - to_a += 8; - from_a += 8; - - } - while (to_a < to_end_a) { - *to_a++ = *from_a++; - } - } else { - /* Different parity */ - from_v = *from_a; - while (to_a < to_end_a) { - unsigned short from_v_next; - from_v_next = *++from_a; - *to_a++ = ((from_v & 0xff)<<8) | ((from_v_next>>8) & 0xff); - from_v = from_v_next; - } - - } - if (odd_to_end) { - /* Last byte unaligned case */ - to_v = *to_a; - from_v = *from_a; - - to_v &= ~0xff00; - if (odd_from == odd_to) { - to_v |= from_v & 0xff00; - } else { - to_v |= (from_v<<8) & 0xff00; - } - - *to_a = to_v; - } - - update_lance_stat( len ); - - return( dst ); -} - - -struct net_device * __init bagetlance_probe(int unit) -{ - struct net_device *dev; - int i; - static int found; - int err = -ENODEV; - - if (found) - /* Assume there's only one board possible... That seems true, since - * the Riebl/PAM board's address cannot be changed. */ - return ERR_PTR(-ENODEV); - - dev = alloc_etherdev(sizeof(struct lance_private)); - if (!dev) - return ERR_PTR(-ENOMEM); - - SET_MODULE_OWNER(dev); - - for( i = 0; i < N_LANCE_ADDR; ++i ) { - if (lance_probe1( dev, &lance_addr_list[i] )) { - found = 1; - break; - } - } - if (!found) - goto out; - err = register_netdev(dev); - if (err) - goto out1; - return dev; -out1: - free_irq(dev->irq, dev); -out: - free_netdev(dev); - return ERR_PTR(err); -} - -/* Derived from hwreg_present() in vme/config.c: */ - -static int __init addr_accessible( volatile void *regp, - int wordflag, - int writeflag ) -{ - /* We have a fine function to do it */ - extern int try_read(unsigned long, int); - return try_read((unsigned long)regp, sizeof(short)) != -1; -} - - - -/* Original atari driver uses it */ -#define IRQ_TYPE_PRIO SA_INTERRUPT -#define IRQ_SOURCE_TO_VECTOR(x) (x) - -static int __init lance_probe1( struct net_device *dev, - struct lance_addr *init_rec ) - -{ volatile unsigned short *memaddr = - (volatile unsigned short *)init_rec->memaddr; - volatile unsigned short *ioaddr = - (volatile unsigned short *)init_rec->ioaddr; - struct lance_private *lp; - struct lance_ioreg *IO; - int i; - static int did_version; - unsigned short save1, save2; - - PROBE_PRINT(( "Probing for Lance card at mem %#lx io %#lx\n", - (long)memaddr, (long)ioaddr )); - - /* Test whether memory readable and writable */ - PROBE_PRINT(( "lance_probe1: testing memory to be accessible\n" )); - if (!addr_accessible( memaddr, 1, 1 )) goto probe_fail; - - if ((unsigned long)memaddr >= KSEG2) { - /* FIXME: do we need to undo that on cleanup paths? */ - extern int kseg2_alloc_io (unsigned long addr, unsigned long size); - if (kseg2_alloc_io((unsigned long)memaddr, BAGET_LANCE_MEM_SIZE)) { - printk("bagetlance: unable map lance memory\n"); - goto probe_fail; - } - } - - /* Written values should come back... */ - PROBE_PRINT(( "lance_probe1: testing memory to be writable (1)\n" )); - save1 = *memaddr; - *memaddr = 0x0001; - if (*memaddr != 0x0001) goto probe_fail; - PROBE_PRINT(( "lance_probe1: testing memory to be writable (2)\n" )); - *memaddr = 0x0000; - if (*memaddr != 0x0000) goto probe_fail; - *memaddr = save1; - - /* First port should be readable and writable */ - PROBE_PRINT(( "lance_probe1: testing ioport to be accessible\n" )); - if (!addr_accessible( ioaddr, 1, 1 )) goto probe_fail; - - /* and written values should be readable */ - PROBE_PRINT(( "lance_probe1: testing ioport to be writeable\n" )); - save2 = ioaddr[1]; - ioaddr[1] = 0x0001; - if (ioaddr[1] != 0x0001) goto probe_fail; - - /* The CSR0_INIT bit should not be readable */ - PROBE_PRINT(( "lance_probe1: testing CSR0 register function (1)\n" )); - save1 = ioaddr[0]; - ioaddr[1] = CSR0; - ioaddr[0] = CSR0_INIT | CSR0_STOP; - if (ioaddr[0] != CSR0_STOP) { - ioaddr[0] = save1; - ioaddr[1] = save2; - goto probe_fail; - } - PROBE_PRINT(( "lance_probe1: testing CSR0 register function (2)\n" )); - ioaddr[0] = CSR0_STOP; - if (ioaddr[0] != CSR0_STOP) { - ioaddr[0] = save1; - ioaddr[1] = save2; - goto probe_fail; - } - - /* Now ok... */ - PROBE_PRINT(( "lance_probe1: Lance card detected\n" )); - goto probe_ok; - - probe_fail: - return( 0 ); - - probe_ok: - lp = netdev_priv(dev); - MEM = (struct lance_memory *)memaddr; - IO = lp->iobase = (struct lance_ioreg *)ioaddr; - dev->base_addr = (unsigned long)ioaddr; /* informational only */ - lp->memcpy_f = init_rec->slow_flag ? slow_memcpy : memcpy; - - REGA( CSR0 ) = CSR0_STOP; - - /* Now test for type: If the eeprom I/O port is readable, it is a - * PAM card */ - if (addr_accessible( &(IO->eeprom), 0, 0 )) { - /* Switch back to Ram */ - i = IO->mem; - lp->cardtype = PAM_CARD; - } -#ifdef NORMAL_MEM_ACCESS - else if (*RIEBL_MAGIC_ADDR == RIEBL_MAGIC) { -#else - else if (({ - unsigned short *a = (unsigned short*)RIEBL_MAGIC_ADDR; - (((int)a[0]) << 16) + ((int)a[1]) == RIEBL_MAGIC; - })) { -#endif - lp->cardtype = NEW_RIEBL; - } - else - lp->cardtype = OLD_RIEBL; - - if (lp->cardtype == PAM_CARD || - memaddr == (unsigned short *)0xffe00000) { - /* PAMs card and Riebl on ST use level 5 autovector */ - if (request_irq(BAGET_LANCE_IRQ, lance_interrupt, IRQ_TYPE_PRIO, - "PAM/Riebl-ST Ethernet", dev)) - goto probe_fail; - dev->irq = (unsigned short)BAGET_LANCE_IRQ; - } - else { - /* For VME-RieblCards, request a free VME int; - * (This must be unsigned long, since dev->irq is short and the - * IRQ_MACHSPEC bit would be cut off...) - */ - unsigned long irq = BAGET_LANCE_IRQ; - if (!irq) { - printk( "Lance: request for VME interrupt failed\n" ); - goto probe_fail; - } - if (request_irq(irq, lance_interrupt, IRQ_TYPE_PRIO, - "Riebl-VME Ethernet", dev)) - goto probe_fail; - dev->irq = irq; - } - - printk("%s: %s at io %#lx, mem %#lx, irq %d%s, hwaddr ", - dev->name, lance_names[lp->cardtype], - (unsigned long)ioaddr, - (unsigned long)memaddr, - dev->irq, - init_rec->slow_flag ? " (slow memcpy)" : "" ); - - /* Get the ethernet address */ - switch( lp->cardtype ) { - case OLD_RIEBL: - /* No ethernet address! (Set some default address) */ - slow_memcpy( dev->dev_addr, OldRieblDefHwaddr, 6 ); - break; - case NEW_RIEBL: - lp->memcpy_f( dev->dev_addr, RIEBL_HWADDR_ADDR, 6 ); - break; - case PAM_CARD: - i = IO->eeprom; - for( i = 0; i < 6; ++i ) - dev->dev_addr[i] = - ((((unsigned short *)MEM)[i*2] & 0x0f) << 4) | - ((((unsigned short *)MEM)[i*2+1] & 0x0f)); - i = IO->mem; - break; - } - for( i = 0; i < 6; ++i ) - printk( "%02x%s", dev->dev_addr[i], (i < 5) ? ":" : "\n" ); - if (lp->cardtype == OLD_RIEBL) { - printk( "%s: Warning: This is a default ethernet address!\n", - dev->name ); - printk( " Use \"ifconfig hw ether ...\" to set the address.\n" ); - } - - MEM->init.mode = 0x0000; /* Disable Rx and Tx. */ - - { - unsigned char hwaddr[6]; - for( i = 0; i < 6; i++ ) - hwaddr[i] = dev->dev_addr[i^1]; /* <- 16 bit swap! */ - slow_memcpy(MEM->init.hwaddr, hwaddr, sizeof(hwaddr)); - } - - MEM->init.filter[0] = 0x00000000; - MEM->init.filter[1] = 0x00000000; - MEM->init.rx_ring.adr_lo = offsetof( struct lance_memory, rx_head ); - -#ifdef NORMAL_MEM_ACCESS - MEM->init.rx_ring.adr_hi = LANCE_HI_BASE; - MEM->init.rx_ring.len = RX_RING_LEN_BITS; -#else - MEM->init.rx_ring.len_adr_hi = - ((unsigned)RX_RING_LEN_BITS << 8) | LANCE_HI_BASE; -#endif - - - MEM->init.tx_ring.adr_lo = offsetof( struct lance_memory, tx_head ); - -#ifdef NORMAL_MEM_ACCESS - MEM->init.tx_ring.adr_hi = LANCE_HI_BASE; - MEM->init.tx_ring.len = TX_RING_LEN_BITS; -#else - MEM->init.tx_ring.len_adr_hi = - ((unsigned)TX_RING_LEN_BITS<<8) | LANCE_HI_BASE; -#endif - - if (lp->cardtype == PAM_CARD) - IO->ivec = IRQ_SOURCE_TO_VECTOR(dev->irq); - else - *RIEBL_IVEC_ADDR = IRQ_SOURCE_TO_VECTOR(dev->irq); - - if (did_version++ == 0) - DPRINTK( 1, ( version )); - - /* The LANCE-specific entries in the device structure. */ - dev->open = &lance_open; - dev->hard_start_xmit = &lance_start_xmit; - dev->stop = &lance_close; - dev->get_stats = &lance_get_stats; - dev->set_multicast_list = &set_multicast_list; - dev->set_mac_address = &lance_set_mac_address; - dev->start = 0; - - memset( &lp->stats, 0, sizeof(lp->stats) ); - - return( 1 ); -} - - -static int lance_open( struct net_device *dev ) - -{ struct lance_private *lp = netdev_priv(dev); - struct lance_ioreg *IO = lp->iobase; - int i; - - DPRINTK( 2, ( "%s: lance_open()\n", dev->name )); - - lance_init_ring(dev); - /* Re-initialize the LANCE, and start it when done. */ - - REGA( CSR3 ) = CSR3_BSWP | (lp->cardtype == PAM_CARD ? CSR3_ACON : 0); - REGA( CSR2 ) = 0; - REGA( CSR1 ) = 0; - REGA( CSR0 ) = CSR0_INIT; - /* From now on, AREG is kept to point to CSR0 */ - - i = 1000000; - while (--i > 0) - if (DREG & CSR0_IDON) - break; - if (i < 0 || (DREG & CSR0_ERR)) { - DPRINTK( 2, ( "lance_open(): opening %s failed, i=%d, csr0=%04x\n", - dev->name, i, DREG )); - DREG = CSR0_STOP; - return( -EIO ); - } - DREG = CSR0_IDON; - DREG = CSR0_STRT; - DREG = CSR0_INEA; - - dev->tbusy = 0; - dev->interrupt = 0; - dev->start = 1; - - DPRINTK( 2, ( "%s: LANCE is open, csr0 %04x\n", dev->name, DREG )); - return( 0 ); -} - - -/* Initialize the LANCE Rx and Tx rings. */ - -static void lance_init_ring( struct net_device *dev ) - -{ struct lance_private *lp = netdev_priv(dev); - int i; - unsigned offset; - - lp->lock = 0; - lp->tx_full = 0; - lp->cur_rx = lp->cur_tx = 0; - lp->dirty_tx = 0; - - offset = offsetof( struct lance_memory, packet_area ); - -/* If the packet buffer at offset 'o' would conflict with the reserved area - * of RieblCards, advance it */ -#define CHECK_OFFSET(o) \ - do { \ - if (lp->cardtype == OLD_RIEBL || lp->cardtype == NEW_RIEBL) { \ - if (((o) < RIEBL_RSVD_START) ? (o)+PKT_BUF_SZ > RIEBL_RSVD_START \ - : (o) < RIEBL_RSVD_END) \ - (o) = RIEBL_RSVD_END; \ - } \ - } while(0) - - for( i = 0; i < TX_RING_SIZE; i++ ) { - CHECK_OFFSET(offset); - MEM->tx_head[i].base = offset; -#ifdef NORMAL_MEM_ACCESS - MEM->tx_head[i].flag = TMD1_OWN_HOST; - MEM->tx_head[i].base_hi = LANCE_HI_BASE; -#else - MEM->tx_head[i].flag_base_hi = - (TMD1_OWN_HOST<<8) | LANCE_HI_BASE; -#endif - MEM->tx_head[i].length = 0; - MEM->tx_head[i].misc = 0; - offset += PKT_BUF_SZ; - } - - for( i = 0; i < RX_RING_SIZE; i++ ) { - CHECK_OFFSET(offset); - MEM->rx_head[i].base = offset; -#ifdef NORMAL_MEM_ACCESS - MEM->rx_head[i].flag = TMD1_OWN_CHIP; - MEM->rx_head[i].base_hi = LANCE_HI_BASE; -#else - MEM->rx_head[i].flag_base_hi = - (TMD1_OWN_CHIP<<8) | LANCE_HI_BASE; -#endif - MEM->rx_head[i].buf_length = -PKT_BUF_SZ; - MEM->rx_head[i].msg_length = 0; - offset += PKT_BUF_SZ; - } -} - - -static int lance_start_xmit( struct sk_buff *skb, struct net_device *dev ) - -{ struct lance_private *lp = netdev_priv(dev); - struct lance_ioreg *IO = lp->iobase; - int entry, len; - struct lance_tx_head *head; - unsigned long flags; - - /* The old LANCE chips doesn't automatically pad buffers to min. size. */ - len = (ETH_ZLEN < skb->len) ? skb->len : ETH_ZLEN; - /* PAM-Card has a bug: Can only send packets with even number of bytes! */ - if (lp->cardtype == PAM_CARD && (len & 1)) - ++len; - - if (len > skb->len) { - skb = skb_padto(skb, len); - if (skb == NULL) - return 0; - } - - /* Transmitter timeout, serious problems. */ - if (dev->tbusy) { - int tickssofar = jiffies - dev->trans_start; - if (tickssofar < 20) - return( 1 ); - AREG = CSR0; - DPRINTK( 1, ( "%s: transmit timed out, status %04x, resetting.\n", - dev->name, DREG )); - DREG = CSR0_STOP; - /* - * Always set BSWP after a STOP as STOP puts it back into - * little endian mode. - */ - REGA( CSR3 ) = CSR3_BSWP | (lp->cardtype == PAM_CARD ? CSR3_ACON : 0); - lp->stats.tx_errors++; -#ifndef final_version - { int i; - DPRINTK( 2, ( "Ring data: dirty_tx %d cur_tx %d%s cur_rx %d\n", - lp->dirty_tx, lp->cur_tx, - lp->tx_full ? " (full)" : "", - lp->cur_rx )); - for( i = 0 ; i < RX_RING_SIZE; i++ ) - DPRINTK( 2, ( "rx #%d: base=%04x blen=%04x mlen=%04x\n", - i, MEM->rx_head[i].base, - -MEM->rx_head[i].buf_length, - MEM->rx_head[i].msg_length )); - for( i = 0 ; i < TX_RING_SIZE; i++ ) - DPRINTK( 2, ( "tx #%d: base=%04x len=%04x misc=%04x\n", - i, MEM->tx_head[i].base, - -MEM->tx_head[i].length, - MEM->tx_head[i].misc )); - } -#endif - lance_init_ring(dev); - REGA( CSR0 ) = CSR0_INEA | CSR0_INIT | CSR0_STRT; - - dev->tbusy = 0; - dev->trans_start = jiffies; - - return( 0 ); - } - - DPRINTK( 2, ( "%s: lance_start_xmit() called, csr0 %4.4x.\n", - dev->name, DREG )); - - /* Block a timer-based transmit from overlapping. This could better be - done with atomic_swap(1, dev->tbusy), but set_bit() works as well. */ - if (test_and_set_bit( 0, (void*)&dev->tbusy ) != 0) { - DPRINTK( 0, ( "%s: Transmitter access conflict.\n", dev->name )); - return 1; - } - - if (test_and_set_bit( 0, (void*)&lp->lock ) != 0) { - DPRINTK( 0, ( "%s: tx queue lock!.\n", dev->name )); - /* don't clear dev->tbusy flag. */ - return 1; - } - - /* Fill in a Tx ring entry */ - if (lance_debug >= 3) { - u_char *p; - int i; - printk( "%s: TX pkt type 0x%04x from ", dev->name, - ((u_short *)skb->data)[6]); - for( p = &((u_char *)skb->data)[6], i = 0; i < 6; i++ ) - printk("%02x%s", *p++, i != 5 ? ":" : "" ); - printk(" to "); - for( p = (u_char *)skb->data, i = 0; i < 6; i++ ) - printk("%02x%s", *p++, i != 5 ? ":" : "" ); - printk(" data at 0x%08x len %d\n", (int)skb->data, - (int)skb->len ); - } - - /* We're not prepared for the int until the last flags are set/reset. And - * the int may happen already after setting the OWN_CHIP... */ - save_flags(flags); - cli(); - - /* Mask to ring buffer boundary. */ - entry = lp->cur_tx & TX_RING_MOD_MASK; - head = &(MEM->tx_head[entry]); - - /* Caution: the write order is important here, set the "ownership" bits - * last. - */ - - head->length = -len; - head->misc = 0; - lp->memcpy_f( PKTBUF_ADDR(head), (void *)skb->data, skb->len ); -#ifdef NORMAL_MEM_ACCESS - head->flag = TMD1_OWN_CHIP | TMD1_ENP | TMD1_STP; -#else - SET_FLAG(head,(TMD1_OWN_CHIP | TMD1_ENP | TMD1_STP)); -#endif - lp->stats.tx_bytes += skb->len; - dev_kfree_skb( skb ); - lp->cur_tx++; - while( lp->cur_tx >= TX_RING_SIZE && lp->dirty_tx >= TX_RING_SIZE ) { - lp->cur_tx -= TX_RING_SIZE; - lp->dirty_tx -= TX_RING_SIZE; - } - - /* Trigger an immediate send poll. */ - DREG = CSR0_INEA | CSR0_TDMD; - dev->trans_start = jiffies; - - lp->lock = 0; -#ifdef NORMAL_MEM_ACCESS - if ((MEM->tx_head[(entry+1) & TX_RING_MOD_MASK].flag & TMD1_OWN) == -#else - if ((GET_FLAG(&MEM->tx_head[(entry+1) & TX_RING_MOD_MASK]) & TMD1_OWN) == -#endif - TMD1_OWN_HOST) - dev->tbusy = 0; - else - lp->tx_full = 1; - restore_flags(flags); - - return 0; -} - -/* The LANCE interrupt handler. */ - -static irqreturn_t lance_interrupt( int irq, void *dev_id, struct pt_regs *fp) -{ - struct net_device *dev = dev_id; - struct lance_private *lp; - struct lance_ioreg *IO; - int csr0, boguscnt = 10; - int handled = 0; - - if (dev == NULL) { - DPRINTK( 1, ( "lance_interrupt(): interrupt for unknown device.\n" )); - return IRQ_NONE; - } - - lp = netdev_priv(dev); - IO = lp->iobase; - AREG = CSR0; - - if (dev->interrupt) { - DPRINTK( 1, ( "Re-entering CAUSE=%08x STATUS=%08x\n", - read_32bit_cp0_register(CP0_CAUSE), - read_32bit_cp0_register(CP0_STATUS) )); - panic("lance: interrupt handler reentered !"); - } - - dev->interrupt = 1; - - while( ((csr0 = DREG) & (CSR0_ERR | CSR0_TINT | CSR0_RINT)) && - --boguscnt >= 0) { - handled = 1; - /* Acknowledge all of the current interrupt sources ASAP. */ - DREG = csr0 & ~(CSR0_INIT | CSR0_STRT | CSR0_STOP | - CSR0_TDMD | CSR0_INEA); - - DPRINTK( 2, ( "%s: interrupt csr0=%04x new csr=%04x.\n", - dev->name, csr0, DREG )); - - if (csr0 & CSR0_RINT) /* Rx interrupt */ - lance_rx( dev ); - - if (csr0 & CSR0_TINT) { /* Tx-done interrupt */ - int dirty_tx = lp->dirty_tx; - - while( dirty_tx < lp->cur_tx) { - int entry = dirty_tx & TX_RING_MOD_MASK; -#ifdef NORMAL_MEM_ACCESS - int status = MEM->tx_head[entry].flag; -#else - int status = GET_FLAG(&MEM->tx_head[entry]); -#endif - if (status & TMD1_OWN_CHIP) - break; /* It still hasn't been Txed */ - -#ifdef NORMAL_MEM_ACCESS - MEM->tx_head[entry].flag = 0; -#else - SET_FLAG(&MEM->tx_head[entry],0); -#endif - - if (status & TMD1_ERR) { - /* There was an major error, log it. */ - int err_status = MEM->tx_head[entry].misc; - lp->stats.tx_errors++; - if (err_status & TMD3_RTRY) lp->stats.tx_aborted_errors++; - if (err_status & TMD3_LCAR) lp->stats.tx_carrier_errors++; - if (err_status & TMD3_LCOL) lp->stats.tx_window_errors++; - if (err_status & TMD3_UFLO) { - /* Ackk! On FIFO errors the Tx unit is turned off! */ - lp->stats.tx_fifo_errors++; - /* Remove this verbosity later! */ - DPRINTK( 1, ( "%s: Tx FIFO error! Status %04x\n", - dev->name, csr0 )); - /* Restart the chip. */ - DREG = CSR0_STRT; - } - } else { - if (status & (TMD1_MORE | TMD1_ONE | TMD1_DEF)) - lp->stats.collisions++; - lp->stats.tx_packets++; - } - dirty_tx++; - } - -#ifndef final_version - if (lp->cur_tx - dirty_tx >= TX_RING_SIZE) { - DPRINTK( 0, ( "out-of-sync dirty pointer," - " %d vs. %d, full=%d.\n", - dirty_tx, lp->cur_tx, lp->tx_full )); - dirty_tx += TX_RING_SIZE; - } -#endif - - if (lp->tx_full && dev->tbusy - && dirty_tx > lp->cur_tx - TX_RING_SIZE + 2) { - /* The ring is no longer full, clear tbusy. */ - lp->tx_full = 0; - dev->tbusy = 0; - mark_bh( NET_BH ); - } - - lp->dirty_tx = dirty_tx; - } - - /* Log misc errors. */ - if (csr0 & CSR0_BABL) lp->stats.tx_errors++; /* Tx babble. */ - if (csr0 & CSR0_MISS) lp->stats.rx_errors++; /* Missed a Rx frame. */ - if (csr0 & CSR0_MERR) { - DPRINTK( 1, ( "%s: Bus master arbitration failure (?!?), " - "status %04x.\n", dev->name, csr0 )); - /* Restart the chip. */ - DREG = CSR0_STRT; - } - } - - /* Clear any other interrupt, and set interrupt enable. */ - DREG = CSR0_BABL | CSR0_CERR | CSR0_MISS | CSR0_MERR | - CSR0_IDON | CSR0_INEA; - - DPRINTK( 2, ( "%s: exiting interrupt, csr0=%#04x.\n", - dev->name, DREG )); - dev->interrupt = 0; - return IRQ_RETVAL(handled); -} - - -static int lance_rx( struct net_device *dev ) - -{ struct lance_private *lp = netdev_priv(dev); - int entry = lp->cur_rx & RX_RING_MOD_MASK; - int i; - -#ifdef NORMAL_MEM_ACCESS - DPRINTK( 2, ( "%s: rx int, flag=%04x\n", dev->name, - MEM->rx_head[entry].flag )); -#else - DPRINTK( 2, ( "%s: rx int, flag=%04x\n", dev->name, - GET_FLAG(&MEM->rx_head[entry]) )); -#endif - - /* If we own the next entry, it's a new packet. Send it up. */ -#ifdef NORMAL_MEM_ACCESS - while( (MEM->rx_head[entry].flag & RMD1_OWN) == RMD1_OWN_HOST ) { -#else - while( (GET_FLAG(&MEM->rx_head[entry]) & RMD1_OWN) == RMD1_OWN_HOST ) { -#endif - struct lance_rx_head *head = &(MEM->rx_head[entry]); -#ifdef NORMAL_MEM_ACCESS - int status = head->flag; -#else - int status = GET_FLAG(head); -#endif - - if (status != (RMD1_ENP|RMD1_STP)) { /* There was an error. */ - /* There is a tricky error noted by John Murphy, - to Russ Nelson: Even with full-sized - buffers it's possible for a jabber packet to use two - buffers, with only the last correctly noting the error. */ - if (status & RMD1_ENP) /* Only count a general error at the */ - lp->stats.rx_errors++; /* end of a packet.*/ - if (status & RMD1_FRAM) lp->stats.rx_frame_errors++; - if (status & RMD1_OFLO) lp->stats.rx_over_errors++; - if (status & RMD1_CRC) lp->stats.rx_crc_errors++; - if (status & RMD1_BUFF) lp->stats.rx_fifo_errors++; -#ifdef NORMAL_MEM_ACCESS - head->flag &= (RMD1_ENP|RMD1_STP); -#else - SET_FLAG(head,GET_FLAG(head) & (RMD1_ENP|RMD1_STP)); -#endif - } else { - /* Malloc up new buffer, compatible with net-3. */ - short pkt_len = head->msg_length & 0xfff; - struct sk_buff *skb; - - if (pkt_len < 60) { - printk( "%s: Runt packet!\n", dev->name ); - lp->stats.rx_errors++; - } - else { - skb = dev_alloc_skb( pkt_len+2 ); - if (skb == NULL) { - DPRINTK( 1, ( "%s: Memory squeeze, deferring packet.\n", - dev->name )); - for( i = 0; i < RX_RING_SIZE; i++ ) -#ifdef NORMAL_MEM_ACCESS - if (MEM->rx_head[(entry+i) & RX_RING_MOD_MASK].flag & -#else - if (GET_FLAG(&MEM->rx_head[(entry+i) & \ - RX_RING_MOD_MASK]) & -#endif - RMD1_OWN_CHIP) - break; - - if (i > RX_RING_SIZE - 2) { - lp->stats.rx_dropped++; -#ifdef NORMAL_MEM_ACCESS - head->flag |= RMD1_OWN_CHIP; -#else - SET_FLAG(head,GET_FLAG(head) | RMD1_OWN_CHIP); -#endif - lp->cur_rx++; - } - break; - } - - if (lance_debug >= 3) { - u_char *data = PKTBUF_ADDR(head), *p; - printk( "%s: RX pkt type 0x%04x from ", dev->name, - ((u_short *)data)[6]); - for( p = &data[6], i = 0; i < 6; i++ ) - printk("%02x%s", *p++, i != 5 ? ":" : "" ); - printk(" to "); - for( p = data, i = 0; i < 6; i++ ) - printk("%02x%s", *p++, i != 5 ? ":" : "" ); - printk(" data %02x %02x %02x %02x %02x %02x %02x %02x " - "len %d\n", - data[15], data[16], data[17], data[18], - data[19], data[20], data[21], data[22], - pkt_len ); - } - - skb->dev = dev; - skb_reserve( skb, 2 ); /* 16 byte align */ - skb_put( skb, pkt_len ); /* Make room */ - lp->memcpy_f( skb->data, PKTBUF_ADDR(head), pkt_len ); - skb->protocol = eth_type_trans( skb, dev ); - netif_rx( skb ); - dev->last_rx = jiffies; - lp->stats.rx_packets++; - lp->stats.rx_bytes += pkt_len; - } - } - -#ifdef NORMAL_MEM_ACCESS - head->flag |= RMD1_OWN_CHIP; -#else - SET_FLAG(head,GET_FLAG(head) | RMD1_OWN_CHIP); -#endif - entry = (++lp->cur_rx) & RX_RING_MOD_MASK; - } - lp->cur_rx &= RX_RING_MOD_MASK; - - /* From lance.c (Donald Becker): */ - /* We should check that at least two ring entries are free. If not, - we should free one and mark stats->rx_dropped++. */ - - return 0; -} - - -static int lance_close( struct net_device *dev ) - -{ struct lance_private *lp = netdev_priv(dev); - struct lance_ioreg *IO = lp->iobase; - - dev->start = 0; - dev->tbusy = 1; - - AREG = CSR0; - - DPRINTK( 2, ( "%s: Shutting down ethercard, status was %2.2x.\n", - dev->name, DREG )); - - /* We stop the LANCE here -- it occasionally polls - memory if we don't. */ - DREG = CSR0_STOP; - - return 0; -} - - -static struct net_device_stats *lance_get_stats( struct net_device *dev ) - -{ - struct lance_private *lp = netdev_priv(dev); - return &lp->stats; -} - - -/* Set or clear the multicast filter for this adaptor. - num_addrs == -1 Promiscuous mode, receive all packets - num_addrs == 0 Normal mode, clear multicast list - num_addrs > 0 Multicast mode, receive normal and MC packets, and do - best-effort filtering. - */ - -static void set_multicast_list( struct net_device *dev ) - -{ struct lance_private *lp = netdev_priv(dev); - struct lance_ioreg *IO = lp->iobase; - - if (!dev->start) - /* Only possible if board is already started */ - return; - - /* We take the simple way out and always enable promiscuous mode. */ - DREG = CSR0_STOP; /* Temporarily stop the lance. */ - - if (dev->flags & IFF_PROMISC) { - /* Log any net taps. */ - DPRINTK( 1, ( "%s: Promiscuous mode enabled.\n", dev->name )); - REGA( CSR15 ) = 0x8000; /* Set promiscuous mode */ - } else { - short multicast_table[4]; - int num_addrs = dev->mc_count; - int i; - /* We don't use the multicast table, but rely on upper-layer - * filtering. */ - memset( multicast_table, (num_addrs == 0) ? 0 : -1, - sizeof(multicast_table) ); - for( i = 0; i < 4; i++ ) - REGA( CSR8+i ) = multicast_table[i]; - REGA( CSR15 ) = 0; /* Unset promiscuous mode */ - } - - /* - * Always set BSWP after a STOP as STOP puts it back into - * little endian mode. - */ - REGA( CSR3 ) = CSR3_BSWP | (lp->cardtype == PAM_CARD ? CSR3_ACON : 0); - - /* Resume normal operation and reset AREG to CSR0 */ - REGA( CSR0 ) = CSR0_IDON | CSR0_INEA | CSR0_STRT; -} - - -/* This is needed for old RieblCards and possible for new RieblCards */ - -static int lance_set_mac_address( struct net_device *dev, void *addr ) - -{ struct lance_private *lp = netdev_priv(dev); - struct sockaddr *saddr = addr; - int i; - - if (lp->cardtype != OLD_RIEBL && lp->cardtype != NEW_RIEBL) - return( -EOPNOTSUPP ); - - if (dev->start) { - /* Only possible while card isn't started */ - DPRINTK( 1, ( "%s: hwaddr can be set only while card isn't open.\n", - dev->name )); - return( -EIO ); - } - - slow_memcpy( dev->dev_addr, saddr->sa_data, dev->addr_len ); - - { - unsigned char hwaddr[6]; - for( i = 0; i < 6; i++ ) - hwaddr[i] = dev->dev_addr[i^1]; /* <- 16 bit swap! */ - slow_memcpy(MEM->init.hwaddr, hwaddr, sizeof(hwaddr)); - } - - lp->memcpy_f( RIEBL_HWADDR_ADDR, dev->dev_addr, 6 ); - /* set also the magic for future sessions */ -#ifdef NORMAL_MEM_ACCESS - *RIEBL_MAGIC_ADDR = RIEBL_MAGIC; -#else - { - unsigned long magic = RIEBL_MAGIC; - slow_memcpy(RIEBL_MAGIC_ADDR, &magic, sizeof(*RIEBL_MAGIC_ADDR)); - } -#endif - return( 0 ); -} - - -#ifdef MODULE -static struct net_device *bagetlance_dev; - -int init_module(void) -{ - bagetlance_dev = bagetlance_probe(-1); - if (IS_ERR(bagetlance_dev)) - return PTR_ERR(bagetlance_dev); - return 0; -} - -void cleanup_module(void) -{ - unregister_netdev(bagetlance_dev); - free_irq(bagetlance_dev->irq, bagetlance_dev); - free_netdev(bagetlance_dev); -} - -#endif /* MODULE */ - -/* - * Local variables: - * c-indent-level: 4 - * tab-width: 4 - * End: - */ diff -Nru a/drivers/net/dl2k.c b/drivers/net/dl2k.c --- a/drivers/net/dl2k.c 2005-03-06 18:36:50 -05:00 +++ b/drivers/net/dl2k.c 2005-03-06 18:36:50 -05:00 @@ -1199,7 +1199,7 @@ static void rio_get_drvinfo(struct net_device *dev, struct ethtool_drvinfo *info) { struct netdev_private *np = netdev_priv(dev); - strcpy(info->driver, "DL2K"); + strcpy(info->driver, "dl2k"); strcpy(info->version, DRV_VERSION); strcpy(info->bus_info, pci_name(np->pdev)); } diff -Nru a/drivers/net/gianfar.c b/drivers/net/gianfar.c --- a/drivers/net/gianfar.c 2005-03-06 18:36:50 -05:00 +++ b/drivers/net/gianfar.c 2005-03-06 18:36:50 -05:00 @@ -377,6 +377,8 @@ ADVERTISED_1000baseT_Full); mii_info->autoneg = 1; + spin_lock_init(&mii_info->mdio_lock); + mii_info->mii_id = priv->einfo->phyid; mii_info->dev = dev; diff -Nru a/drivers/net/ibm_emac/ibm_emac.h b/drivers/net/ibm_emac/ibm_emac.h --- a/drivers/net/ibm_emac/ibm_emac.h 2005-03-06 18:36:50 -05:00 +++ b/drivers/net/ibm_emac/ibm_emac.h 2005-03-06 18:36:50 -05:00 @@ -237,6 +237,10 @@ #define EMAC_RWMR_DEFAULT 0x1000a200 #define EMAC_TMR0_DEFAULT EMAC_TMR0_TFAE_2_32 #define EMAC_TMR1_DEFAULT 0xa00f0000 +#elif defined(CONFIG_440SP) +#define EMAC_RWMR_DEFAULT 0x08002000 +#define EMAC_TMR0_DEFAULT EMAC_TMR0_TFAE_128_2048 +#define EMAC_TMR1_DEFAULT 0xf8200000 #else #define EMAC_RWMR_DEFAULT 0x0f002000 #define EMAC_TMR0_DEFAULT 0x00000000 diff -Nru a/drivers/net/ibm_emac/ibm_emac_core.c b/drivers/net/ibm_emac/ibm_emac_core.c --- a/drivers/net/ibm_emac/ibm_emac_core.c 2005-03-06 18:36:50 -05:00 +++ b/drivers/net/ibm_emac/ibm_emac_core.c 2005-03-06 18:36:50 -05:00 @@ -1041,7 +1041,7 @@ /* set speed (default is 10Mb) */ switch (speed) { case SPEED_1000: - mode_reg |= EMAC_M1_JUMBO_ENABLE | EMAC_M1_RFS_16K; + mode_reg |= EMAC_M1_RFS_16K; if (fep->rgmii_dev) { struct ibm_ocp_rgmii *rgmii = RGMII_PRIV(fep->rgmii_dev); @@ -1118,6 +1118,7 @@ { struct ocp_enet_private *fep = dev->priv; int old_mtu = dev->mtu; + unsigned long mode_reg; emac_t *emacp = fep->emacp; u32 em0mr0; int i, full; @@ -1160,10 +1161,17 @@ fep->rx_skb[i] = NULL; } - /* Set new rx_buffer_size and advertise new mtu */ - fep->rx_buffer_size = - new_mtu + ENET_HEADER_SIZE + ENET_FCS_SIZE; + /* Set new rx_buffer_size, jumbo cap, and advertise new mtu */ + mode_reg = in_be32(&emacp->em0mr1); + if (new_mtu > ENET_DEF_MTU_SIZE) { + mode_reg |= EMAC_M1_JUMBO_ENABLE; + fep->rx_buffer_size = EMAC_MAX_FRAME; + } else { + mode_reg &= ~EMAC_M1_JUMBO_ENABLE; + fep->rx_buffer_size = ENET_DEF_BUF_SIZE; + } dev->mtu = new_mtu; + out_be32(&emacp->em0mr1, mode_reg); /* Re-init rx skbs */ fep->rx_slot = 0; diff -Nru a/drivers/net/ibm_emac/ibm_emac_core.h b/drivers/net/ibm_emac/ibm_emac_core.h --- a/drivers/net/ibm_emac/ibm_emac_core.h 2005-03-06 18:36:50 -05:00 +++ b/drivers/net/ibm_emac/ibm_emac_core.h 2005-03-06 18:36:50 -05:00 @@ -77,6 +77,8 @@ #define ENET_HEADER_SIZE 14 #define ENET_FCS_SIZE 4 +#define ENET_DEF_MTU_SIZE 1500 +#define ENET_DEF_BUF_SIZE (ENET_DEF_MTU_SIZE + ENET_HEADER_SIZE + ENET_FCS_SIZE) #define EMAC_MIN_FRAME 64 #define EMAC_MAX_FRAME 9018 #define EMAC_MIN_MTU (EMAC_MIN_FRAME - ENET_HEADER_SIZE - ENET_FCS_SIZE) diff -Nru a/drivers/net/ioc3-eth.c b/drivers/net/ioc3-eth.c --- a/drivers/net/ioc3-eth.c 2005-03-06 18:36:50 -05:00 +++ b/drivers/net/ioc3-eth.c 2005-03-06 18:36:50 -05:00 @@ -463,6 +463,29 @@ printk(".\n"); } +static void __ioc3_set_mac_address(struct net_device *dev) +{ + struct ioc3_private *ip = netdev_priv(dev); + struct ioc3 *ioc3 = ip->regs; + + ioc3_w_emar_h((dev->dev_addr[5] << 8) | dev->dev_addr[4]); + ioc3_w_emar_l((dev->dev_addr[3] << 24) | (dev->dev_addr[2] << 16) | + (dev->dev_addr[1] << 8) | dev->dev_addr[0]); +} + +static int ioc3_set_mac_address(struct net_device *dev, void *addr) +{ + struct ioc3_private *ip = netdev_priv(dev); + struct sockaddr *sa = addr; + + memcpy(dev->dev_addr, sa->sa_data, dev->addr_len); + + spin_lock_irq(&ip->ioc3_lock); + __ioc3_set_mac_address(dev); + spin_unlock_irq(&ip->ioc3_lock); + + return 0; +} /* * Caller must hold the ioc3_lock ever for MII readers. This is also @@ -1014,9 +1037,7 @@ (void) ioc3_r_etcdc(); /* Clear on read */ ioc3_w_ercsr(15); /* RX low watermark */ ioc3_w_ertr(0); /* Interrupt immediately */ - ioc3_w_emar_h((dev->dev_addr[5] << 8) | dev->dev_addr[4]); - ioc3_w_emar_l((dev->dev_addr[3] << 24) | (dev->dev_addr[2] << 16) | - (dev->dev_addr[1] << 8) | dev->dev_addr[0]); + __ioc3_set_mac_address(dev); ioc3_w_ehar_h(ip->ehar_h); ioc3_w_ehar_l(ip->ehar_l); ioc3_w_ersr(42); /* XXX should be random */ @@ -1100,6 +1121,7 @@ && dev->device == PCI_DEVICE_ID_SGI_IOC3; } +#ifdef CONFIG_SERIAL_8250 /* * Note about serial ports and consoles: * For console output, everyone uses the IOC3 UARTA (offset 0x178) @@ -1121,15 +1143,14 @@ * "device" routine referred to in this console structure * (ip27prom_console_dev). * - * Also look in ip27-pci.c:pci_fixuop_ioc3() for some comments on working + * Also look in ip27-pci.c:pci_fixup_ioc3() for some comments on working * around ioc3 oddities in this respect. * * The IOC3 serials use a 22MHz clock rate with an additional divider by 3. * (IOC3_BAUD = (22000000 / (3*16))) */ -static inline void ioc3_serial_probe(struct pci_dev *pdev, - struct ioc3 *ioc3) +static void __devinit ioc3_serial_probe(struct pci_dev *pdev, struct ioc3 *ioc3) { struct serial_struct req; @@ -1160,9 +1181,9 @@ req.iomem_base = (unsigned char *) &ioc3->sregs.uartb; register_serial(&req); } +#endif -static int __devinit ioc3_probe(struct pci_dev *pdev, - const struct pci_device_id *ent) +static int ioc3_probe(struct pci_dev *pdev, const struct pci_device_id *ent) { unsigned int sw_physid1, sw_physid2; struct net_device *dev = NULL; @@ -1170,11 +1191,39 @@ struct ioc3 *ioc3; unsigned long ioc3_base, ioc3_size; u32 vendor, model, rev; - int err; + int err, pci_using_dac; + + /* Configure DMA attributes. */ + err = pci_set_dma_mask(pdev, 0xffffffffffffffffULL); + if (!err) { + pci_using_dac = 1; + err = pci_set_consistent_dma_mask(pdev, 0xffffffffffffffffULL); + if (err < 0) { + printk(KERN_ERR "%s: Unable to obtain 64 bit DMA " + "for consistent allocations\n", pci_name(pdev)); + goto out; + } + } else { + err = pci_set_dma_mask(pdev, 0xffffffffULL); + if (err) { + printk(KERN_ERR "%s: No usable DMA configuration, " + "aborting.\n", pci_name(pdev)); + goto out; + } + pci_using_dac = 0; + } + + if (pci_enable_device(pdev)) + return -ENODEV; dev = alloc_etherdev(sizeof(struct ioc3_private)); - if (!dev) - return -ENOMEM; + if (!dev) { + err = -ENOMEM; + goto out_disable; + } + + if (pci_using_dac) + dev->features |= NETIF_F_HIGHDMA; err = pci_request_regions(pdev, "ioc3"); if (err) @@ -1237,6 +1286,7 @@ dev->get_stats = ioc3_get_stats; dev->do_ioctl = ioc3_ioctl; dev->set_multicast_list = ioc3_set_multicast_list; + dev->set_mac_address = ioc3_set_mac_address; dev->ethtool_ops = &ioc3_ethtool_ops; #ifdef CONFIG_SGI_IOC3_ETH_HW_TX_CSUM dev->features = NETIF_F_IP_CSUM; @@ -1269,6 +1319,12 @@ pci_release_regions(pdev); out_free: free_netdev(dev); +out_disable: + /* + * We should call pci_disable_device(pdev); here if the IOC3 wasn't + * such a weird device ... + */ +out: return err; } @@ -1282,6 +1338,10 @@ iounmap(ioc3); pci_release_regions(pdev); free_netdev(dev); + /* + * We should call pci_disable_device(pdev); here if the IOC3 wasn't + * such a weird device ... + */ } static struct pci_device_id ioc3_pci_tbl[] = { diff -Nru a/drivers/net/jazzsonic.c b/drivers/net/jazzsonic.c --- a/drivers/net/jazzsonic.c 2005-03-06 18:36:50 -05:00 +++ b/drivers/net/jazzsonic.c 2005-03-06 18:36:50 -05:00 @@ -14,6 +14,7 @@ */ #include +#include #include #include #include @@ -28,6 +29,7 @@ #include #include #include +#include #include #include @@ -37,7 +39,10 @@ #include #include -#define DRV_NAME "jazzsonic" +static char jazz_sonic_string[] = "jazzsonic"; +static struct platform_device *jazz_sonic_device; + +#define SONIC_MEM_SIZE 0x100 #define SREGS_PAD(n) u16 n; @@ -50,8 +55,8 @@ #define SONIC_WRITE(reg,val) \ do { \ - *((volatile unsigned int *)base_addr+reg) = val; \ -} + *((volatile unsigned int *)base_addr+(reg)) = (val); \ +} while (0) /* use 0 for production, 1 for verification, >2 for debug */ @@ -80,70 +85,7 @@ 0xffff /* end of list */ }; -/* Index to functions, as function prototypes. */ - -static int sonic_probe1(struct net_device *dev, unsigned int base_addr, - unsigned int irq); - - -/* - * Probe for a SONIC ethernet controller on a Mips Jazz board. - * Actually probing is superfluous but we're paranoid. - */ -struct net_device * __init sonic_probe(int unit) -{ - struct net_device *dev; - struct sonic_local *lp; - unsigned int base_addr; - int err = 0; - int i; - - /* - * Don't probe if we're not running on a Jazz board. - */ - if (mips_machgroup != MACH_GROUP_JAZZ) - return ERR_PTR(-ENODEV); - - dev = alloc_etherdev(0); - if (!dev) - return ERR_PTR(-ENOMEM); - - sprintf(dev->name, "eth%d", unit); - netdev_boot_setup_check(dev); - base_addr = dev->base_addr; - - if (base_addr >= KSEG0) { /* Check a single specified location. */ - err = sonic_probe1(dev, base_addr, dev->irq); - } else if (base_addr != 0) { /* Don't probe at all. */ - err = -ENXIO; - } else { - for (i = 0; sonic_portlist[i].port; i++) { - int io = sonic_portlist[i].port; - if (sonic_probe1(dev, io, sonic_portlist[i].irq) == 0) - break; - } - if (!sonic_portlist[i].port) - err = -ENODEV; - } - if (err) - goto out; - err = register_netdev(dev); - if (err) - goto out1; - return dev; -out1: - lp = dev->priv; - vdma_free(lp->rba_laddr); - kfree(lp->rba); - vdma_free(lp->cda_laddr); - kfree(lp); - release_region(dev->base_addr, 0x100); -out: - free_netdev(dev); - return ERR_PTR(err); -} - -static int __init sonic_probe1(struct net_device *dev, unsigned int base_addr, +static int __init sonic_probe1(struct net_device *dev, unsigned long base_addr, unsigned int irq) { static unsigned version_printed; @@ -153,7 +95,7 @@ int err = -ENODEV; int i; - if (!request_region(base_addr, 0x100, DRV_NAME)) + if (!request_mem_region(base_addr, SONIC_MEM_SIZE, jazz_sonic_string)) return -EBUSY; /* * get the Silicon Revision ID. If this is one of the known @@ -233,7 +175,7 @@ memset(lp, 0, sizeof(struct sonic_local)); /* get the virtual dma address */ - lp->cda_laddr = vdma_alloc(PHYSADDR(lp),sizeof(*lp)); + lp->cda_laddr = vdma_alloc(CPHYSADDR(lp),sizeof(*lp)); if (lp->cda_laddr == ~0UL) { printk("%s: couldn't get DMA page entry for " "descriptors\n", dev->name); @@ -254,7 +196,7 @@ } /* get virtual dma address */ - lp->rba_laddr = vdma_alloc(PHYSADDR(lp->rba), + lp->rba_laddr = vdma_alloc(CPHYSADDR(lp->rba), SONIC_NUM_RRS * SONIC_RBSIZE); if (lp->rba_laddr == ~0UL) { printk("%s: couldn't get DMA page entry for receive " @@ -291,7 +233,66 @@ out1: kfree(lp); out: - release_region(base_addr, 0x100); + release_region(base_addr, SONIC_MEM_SIZE); + return err; +} + +/* + * Probe for a SONIC ethernet controller on a Mips Jazz board. + * Actually probing is superfluous but we're paranoid. + */ +static int __init jazz_sonic_probe(struct device *device) +{ + struct net_device *dev; + struct sonic_local *lp; + unsigned long base_addr; + int err = 0; + int i; + + /* + * Don't probe if we're not running on a Jazz board. + */ + if (mips_machgroup != MACH_GROUP_JAZZ) + return -ENODEV; + + dev = alloc_etherdev(0); + if (!dev) + return -ENOMEM; + + netdev_boot_setup_check(dev); + base_addr = dev->base_addr; + + if (base_addr >= KSEG0) { /* Check a single specified location. */ + err = sonic_probe1(dev, base_addr, dev->irq); + } else if (base_addr != 0) { /* Don't probe at all. */ + err = -ENXIO; + } else { + for (i = 0; sonic_portlist[i].port; i++) { + int io = sonic_portlist[i].port; + if (sonic_probe1(dev, io, sonic_portlist[i].irq) == 0) + break; + } + if (!sonic_portlist[i].port) + err = -ENODEV; + } + if (err) + goto out; + err = register_netdev(dev); + if (err) + goto out1; + + return 0; + +out1: + lp = dev->priv; + vdma_free(lp->rba_laddr); + kfree(lp->rba); + vdma_free(lp->cda_laddr); + kfree(lp); + release_region(dev->base_addr, SONIC_MEM_SIZE); +out: + free_netdev(dev); + return err; } @@ -304,3 +305,77 @@ #define sonic_chiptomem(x) KSEG1ADDR(vdma_log2phys(x)) #include "sonic.c" + +static int __devexit jazz_sonic_device_remove (struct device *device) +{ + struct net_device *dev = device->driver_data; + + unregister_netdev (dev); + release_region (dev->base_addr, SONIC_MEM_SIZE); + free_netdev (dev); + + return 0; +} + +static struct device_driver jazz_sonic_driver = { + .name = jazz_sonic_string, + .bus = &platform_bus_type, + .probe = jazz_sonic_probe, + .remove = __devexit_p(jazz_sonic_device_remove), +}; + +static void jazz_sonic_platform_release (struct device *device) +{ + struct platform_device *pldev; + + /* free device */ + pldev = to_platform_device (device); + kfree (pldev); +} + +static int __init jazz_sonic_init_module(void) +{ + struct platform_device *pldev; + + if (driver_register(&jazz_sonic_driver)) { + printk(KERN_ERR "Driver registration failed\n"); + return -ENOMEM; + } + + jazz_sonic_device = NULL; + + if (!(pldev = kmalloc (sizeof (*pldev), GFP_KERNEL))) { + goto out_unregister; + } + + memset(pldev, 0, sizeof (*pldev)); + pldev->name = jazz_sonic_string; + pldev->id = 0; + pldev->dev.release = jazz_sonic_platform_release; + jazz_sonic_device = pldev; + + if (platform_device_register (pldev)) { + kfree(pldev); + jazz_sonic_device = NULL; + } + + return 0; + +out_unregister: + platform_device_unregister(pldev); + + return -ENOMEM; +} + +static void __exit jazz_sonic_cleanup_module(void) +{ + driver_unregister(&jazz_sonic_driver); + + if (jazz_sonic_device) { + platform_device_unregister(jazz_sonic_device); + jazz_sonic_device = NULL; + } +} + +module_init(jazz_sonic_init_module); +module_exit(jazz_sonic_cleanup_module); diff -Nru a/drivers/net/meth.c b/drivers/net/meth.c --- a/drivers/net/meth.c 2005-03-06 18:36:50 -05:00 +++ b/drivers/net/meth.c 2005-03-06 18:36:50 -05:00 @@ -27,7 +27,7 @@ #include /* struct iphdr */ #include /* struct tcphdr */ #include -#include /*MII definitions */ +#include /* MII definitions */ #include #include @@ -105,27 +105,27 @@ (int)o2meth_eaddr[3]&0xFF,(int)o2meth_eaddr[4]&0xFF,(int)o2meth_eaddr[5]&0xFF); for (i = 0; i < 6; i++) dev->dev_addr[i] = o2meth_eaddr[i]; - mace_eth_write((*(u64*)o2meth_eaddr)>>16, mac_addr); + mace->eth.mac_addr = (*(unsigned long*)o2meth_eaddr) >> 16; } /* * Waits for BUSY status of mdio bus to clear */ -#define WAIT_FOR_PHY(___rval) \ - while ((___rval = mace_eth_read(phy_data)) & MDIO_BUSY) { \ - udelay(25); \ +#define WAIT_FOR_PHY(___rval) \ + while ((___rval = mace->eth.phy_data) & MDIO_BUSY) { \ + udelay(25); \ } /*read phy register, return value read */ static unsigned long mdio_read(struct meth_private *priv, unsigned long phyreg) { unsigned long rval; WAIT_FOR_PHY(rval); - mace_eth_write((priv->phy_addr << 5) | (phyreg & 0x1f), phy_regs); + mace->eth.phy_regs = (priv->phy_addr << 5) | (phyreg & 0x1f); udelay(25); - mace_eth_write(1, phy_trans_go); + mace->eth.phy_trans_go = 1; udelay(25); WAIT_FOR_PHY(rval); - return rval&MDIO_DATA_MASK; + return rval & MDIO_DATA_MASK; } static int mdio_probe(struct meth_private *priv) @@ -191,7 +191,7 @@ priv->mac_ctrl |= METH_PHY_FDX; else priv->mac_ctrl &= ~METH_PHY_FDX; - mace_eth_write(priv->mac_ctrl, mac_ctrl); + mace->eth.mac_ctrl = priv->mac_ctrl; } if ((priv->mac_ctrl & METH_100MBIT) ^ speed) { @@ -200,7 +200,7 @@ priv->mac_ctrl |= METH_100MBIT; else priv->mac_ctrl &= ~METH_100MBIT; - mace_eth_write(priv->mac_ctrl, mac_ctrl); + mace->eth.mac_ctrl = priv->mac_ctrl; } } @@ -214,26 +214,28 @@ return -ENOMEM; memset(priv->tx_ring, 0, TX_RING_BUFFER_SIZE); priv->tx_count = priv->tx_read = priv->tx_write = 0; - mace_eth_write(priv->tx_ring_dma, tx_ring_base); + mace->eth.tx_ring_base = priv->tx_ring_dma; /* Now init skb save area */ - memset(priv->tx_skbs,0,sizeof(priv->tx_skbs)); - memset(priv->tx_skb_dmas,0,sizeof(priv->tx_skb_dmas)); + memset(priv->tx_skbs, 0, sizeof(priv->tx_skbs)); + memset(priv->tx_skb_dmas, 0, sizeof(priv->tx_skb_dmas)); return 0; } static int meth_init_rx_ring(struct meth_private *priv) { int i; - for(i=0;irx_skbs[i]=alloc_skb(METH_RX_BUFF_SIZE,0); - /* 8byte status vector+3quad padding + 2byte padding, - to put data on 64bit aligned boundary */ + + for (i = 0; i < RX_RING_ENTRIES; i++) { + priv->rx_skbs[i] = alloc_skb(METH_RX_BUFF_SIZE, 0); + /* 8byte status vector + 3quad padding + 2byte padding, + * to put data on 64bit aligned boundary */ skb_reserve(priv->rx_skbs[i],METH_RX_HEAD); priv->rx_ring[i]=(rx_packet*)(priv->rx_skbs[i]->head); /* I'll need to re-sync it after each RX */ - priv->rx_ring_dmas[i]=dma_map_single(NULL,priv->rx_ring[i], - METH_RX_BUFF_SIZE,DMA_FROM_DEVICE); - mace_eth_write(priv->rx_ring_dmas[i], rx_fifo); + priv->rx_ring_dmas[i] = + dma_map_single(NULL, priv->rx_ring[i], + METH_RX_BUFF_SIZE, DMA_FROM_DEVICE); + mace->eth.rx_fifo = priv->rx_ring_dmas[i]; } priv->rx_write = 0; return 0; @@ -257,10 +259,11 @@ { int i; - for(i=0;irx_ring_dmas[i],METH_RX_BUFF_SIZE,DMA_FROM_DEVICE); - priv->rx_ring[i]=0; - priv->rx_ring_dmas[i]=0; + for (i = 0; i < RX_RING_ENTRIES; i++) { + dma_unmap_single(NULL, priv->rx_ring_dmas[i], + METH_RX_BUFF_SIZE, DMA_FROM_DEVICE); + priv->rx_ring[i] = 0; + priv->rx_ring_dmas[i] = 0; kfree_skb(priv->rx_skbs[i]); } } @@ -270,8 +273,9 @@ struct meth_private *priv = (struct meth_private *) dev->priv; /* Reset card */ - mace_eth_write(SGI_MAC_RESET, mac_ctrl); - mace_eth_write(0, mac_ctrl); + mace->eth.mac_ctrl = SGI_MAC_RESET; + udelay(1); + mace->eth.mac_ctrl = 0; udelay(25); /* Load ethernet address */ @@ -279,24 +283,24 @@ /* Should load some "errata", but later */ /* Check for device */ - if(mdio_probe(priv) < 0) { + if (mdio_probe(priv) < 0) { DPRINTK("Unable to find PHY\n"); return -ENODEV; } /* Initial mode: 10 | Half-duplex | Accept normal packets */ priv->mac_ctrl = METH_ACCEPT_MCAST | METH_DEFAULT_IPG; - if(dev->flags | IFF_PROMISC) + if (dev->flags | IFF_PROMISC) priv->mac_ctrl |= METH_PROMISC; - mace_eth_write(priv->mac_ctrl, mac_ctrl); + mace->eth.mac_ctrl = priv->mac_ctrl; /* Autonegotiate speed and duplex mode */ meth_check_link(dev); /* Now set dma control, but don't enable DMA, yet */ - priv->dma_ctrl= (4 << METH_RX_OFFSET_SHIFT) | - (RX_RING_ENTRIES << METH_RX_DEPTH_SHIFT); - mace_eth_write(priv->dma_ctrl, dma_ctrl); + priv->dma_ctrl = (4 << METH_RX_OFFSET_SHIFT) | + (RX_RING_ENTRIES << METH_RX_DEPTH_SHIFT); + mace->eth.dma_ctrl = priv->dma_ctrl; return 0; } @@ -335,7 +339,7 @@ /* Start DMA */ priv->dma_ctrl |= METH_DMA_TX_EN | /*METH_DMA_TX_INT_EN |*/ METH_DMA_RX_EN | METH_DMA_RX_INT_EN; - mace_eth_write(priv->dma_ctrl, dma_ctrl); + mace->eth.dma_ctrl = priv->dma_ctrl; DPRINTK("About to start queue\n"); netif_start_queue(dev); @@ -359,7 +363,7 @@ /* shut down DMA */ priv->dma_ctrl &= ~(METH_DMA_TX_EN | METH_DMA_TX_INT_EN | METH_DMA_RX_EN | METH_DMA_RX_INT_EN); - mace_eth_write(priv->dma_ctrl, dma_ctrl); + mace->eth.dma_ctrl = priv->dma_ctrl; free_irq(dev->irq, dev); meth_free_tx_ring(priv); meth_free_rx_ring(priv); @@ -373,56 +377,57 @@ static void meth_rx(struct net_device* dev, unsigned long int_status) { struct sk_buff *skb; + unsigned long status; struct meth_private *priv = (struct meth_private *) dev->priv; - unsigned long fifo_rptr=(int_status&METH_INT_RX_RPTR_MASK)>>8; + unsigned long fifo_rptr = (int_status & METH_INT_RX_RPTR_MASK) >> 8; + spin_lock(&priv->meth_lock); - priv->dma_ctrl&=~METH_DMA_RX_INT_EN; - mace_eth_write(priv->dma_ctrl, dma_ctrl); + priv->dma_ctrl &= ~METH_DMA_RX_INT_EN; + mace->eth.dma_ctrl = priv->dma_ctrl; spin_unlock(&priv->meth_lock); - if (int_status & METH_INT_RX_UNDERFLOW){ - fifo_rptr=(fifo_rptr-1)&(0xF); + if (int_status & METH_INT_RX_UNDERFLOW) { + fifo_rptr = (fifo_rptr - 1) & 0x0f; } - while(priv->rx_write != fifo_rptr) { - u64 status; - dma_unmap_single(NULL,priv->rx_ring_dmas[priv->rx_write], - METH_RX_BUFF_SIZE,DMA_FROM_DEVICE); - status=priv->rx_ring[priv->rx_write]->status.raw; + while (priv->rx_write != fifo_rptr) { + dma_unmap_single(NULL, priv->rx_ring_dmas[priv->rx_write], + METH_RX_BUFF_SIZE, DMA_FROM_DEVICE); + status = priv->rx_ring[priv->rx_write]->status.raw; #if MFE_DEBUG - if(!(status&METH_RX_ST_VALID)) { + if (!(status & METH_RX_ST_VALID)) { DPRINTK("Not received? status=%016lx\n",status); } #endif - if((!(status&METH_RX_STATUS_ERRORS))&&(status&METH_RX_ST_VALID)){ - int len=(status&0xFFFF) - 4; /* omit CRC */ + if ((!(status & METH_RX_STATUS_ERRORS)) && (status & METH_RX_ST_VALID)) { + int len = (status & 0xffff) - 4; /* omit CRC */ /* length sanity check */ - if(len < 60 || len > 1518) { - printk(KERN_DEBUG "%s: bogus packet size: %d, status=%#2lx.\n", + if (len < 60 || len > 1518) { + printk(KERN_DEBUG "%s: bogus packet size: %ld, status=%#2lx.\n", dev->name, priv->rx_write, priv->rx_ring[priv->rx_write]->status.raw); priv->stats.rx_errors++; priv->stats.rx_length_errors++; - skb=priv->rx_skbs[priv->rx_write]; + skb = priv->rx_skbs[priv->rx_write]; } else { - skb=alloc_skb(METH_RX_BUFF_SIZE,GFP_ATOMIC|GFP_DMA); - if(!skb){ + skb = alloc_skb(METH_RX_BUFF_SIZE, GFP_ATOMIC | GFP_DMA); + if (!skb) { /* Ouch! No memory! Drop packet on the floor */ DPRINTK("No mem: dropping packet\n"); priv->stats.rx_dropped++; - skb=priv->rx_skbs[priv->rx_write]; + skb = priv->rx_skbs[priv->rx_write]; } else { - struct sk_buff *skb_c=priv->rx_skbs[priv->rx_write]; - /* 8byte status vector+3quad padding + 2byte padding, - to put data on 64bit aligned boundary */ - skb_reserve(skb,METH_RX_HEAD); + struct sk_buff *skb_c = priv->rx_skbs[priv->rx_write]; + /* 8byte status vector + 3quad padding + 2byte padding, + * to put data on 64bit aligned boundary */ + skb_reserve(skb, METH_RX_HEAD); /* Write metadata, and then pass to the receive level */ - skb_put(skb_c,len); - priv->rx_skbs[priv->rx_write]=skb; + skb_put(skb_c, len); + priv->rx_skbs[priv->rx_write] = skb; skb_c->dev = dev; skb_c->protocol = eth_type_trans(skb_c, dev); dev->last_rx = jiffies; priv->stats.rx_packets++; - priv->stats.rx_bytes+=len; + priv->stats.rx_bytes += len; netif_rx(skb_c); } } @@ -445,18 +450,19 @@ printk(KERN_WARNING "Carrier Event Seen\n"); #endif } - priv->rx_ring[priv->rx_write]=(rx_packet*)skb->head; - priv->rx_ring[priv->rx_write]->status.raw=0; - priv->rx_ring_dmas[priv->rx_write]=dma_map_single(NULL,priv->rx_ring[priv->rx_write], - METH_RX_BUFF_SIZE,DMA_FROM_DEVICE); - mace_eth_write(priv->rx_ring_dmas[priv->rx_write], rx_fifo); + priv->rx_ring[priv->rx_write] = (rx_packet*)skb->head; + priv->rx_ring[priv->rx_write]->status.raw = 0; + priv->rx_ring_dmas[priv->rx_write] = + dma_map_single(NULL, priv->rx_ring[priv->rx_write], + METH_RX_BUFF_SIZE, DMA_FROM_DEVICE); + mace->eth.rx_fifo = priv->rx_ring_dmas[priv->rx_write]; ADVANCE_RX_PTR(priv->rx_write); } spin_lock(&priv->meth_lock); /* In case there was underflow, and Rx DMA was disabled */ - priv->dma_ctrl|=METH_DMA_RX_INT_EN|METH_DMA_RX_EN; - mace_eth_write(priv->dma_ctrl, dma_ctrl); - mace_eth_write(METH_INT_RX_THRESHOLD, int_stat); + priv->dma_ctrl |= METH_DMA_RX_INT_EN | METH_DMA_RX_EN; + mace->eth.dma_ctrl = priv->dma_ctrl; + mace->eth.int_stat = METH_INT_RX_THRESHOLD; spin_unlock(&priv->meth_lock); } @@ -464,31 +470,31 @@ { struct meth_private *priv = (struct meth_private *) dev->priv; - return(priv->tx_count >= TX_RING_ENTRIES-1); + return (priv->tx_count >= TX_RING_ENTRIES - 1); } static void meth_tx_cleanup(struct net_device* dev, unsigned long int_status) { struct meth_private *priv = dev->priv; - u64 status; + unsigned long status; struct sk_buff *skb; - unsigned long rptr=(int_status&TX_INFO_RPTR)>>16; + unsigned long rptr = (int_status&TX_INFO_RPTR) >> 16; spin_lock(&priv->meth_lock); /* Stop DMA notification */ priv->dma_ctrl &= ~(METH_DMA_TX_INT_EN); - mace_eth_write(priv->dma_ctrl, dma_ctrl); + mace->eth.dma_ctrl = priv->dma_ctrl; - while(priv->tx_read != rptr){ + while (priv->tx_read != rptr) { skb = priv->tx_skbs[priv->tx_read]; status = priv->tx_ring[priv->tx_read].header.raw; #if MFE_DEBUG>=1 - if(priv->tx_read==priv->tx_write) - DPRINTK("Auchi! tx_read=%d,tx_write=%d,rptr=%d?\n",priv->tx_read,priv->tx_write,rptr); + if (priv->tx_read == priv->tx_write) + DPRINTK("Auchi! tx_read=%d,tx_write=%d,rptr=%d?\n", priv->tx_read, priv->tx_write,rptr); #endif - if(status & METH_TX_ST_DONE) { - if(status & METH_TX_ST_SUCCESS){ + if (status & METH_TX_ST_DONE) { + if (status & METH_TX_ST_SUCCESS){ priv->stats.tx_packets++; priv->stats.tx_bytes += skb->len; } else { @@ -518,19 +524,19 @@ priv->tx_skbs[priv->tx_read] = NULL; priv->tx_ring[priv->tx_read].header.raw = 0; priv->tx_read = (priv->tx_read+1)&(TX_RING_ENTRIES-1); - priv->tx_count --; + priv->tx_count--; } /* wake up queue if it was stopped */ - if (netif_queue_stopped(dev) && ! meth_tx_full(dev)) { + if (netif_queue_stopped(dev) && !meth_tx_full(dev)) { netif_wake_queue(dev); } - mace_eth_write(METH_INT_TX_EMPTY | METH_INT_TX_PKT, int_stat); + mace->eth.int_stat = METH_INT_TX_EMPTY | METH_INT_TX_PKT; spin_unlock(&priv->meth_lock); } -static void meth_error(struct net_device* dev, u32 status) +static void meth_error(struct net_device* dev, unsigned status) { struct meth_private *priv = (struct meth_private *) dev->priv; @@ -548,17 +554,16 @@ if (status & (METH_INT_RX_UNDERFLOW)) { printk(KERN_WARNING "meth: Rx underflow\n"); spin_lock(&priv->meth_lock); - mace_eth_write(METH_INT_RX_UNDERFLOW, int_stat); + mace->eth.int_stat = METH_INT_RX_UNDERFLOW; /* more underflow interrupts will be delivered, - effectively throwing us into an infinite loop. - Thus I stop processing Rx in this case. - */ - priv->dma_ctrl&=~METH_DMA_RX_EN; - mace_eth_write(priv->dma_ctrl, dma_ctrl); + * effectively throwing us into an infinite loop. + * Thus I stop processing Rx in this case. */ + priv->dma_ctrl &= ~METH_DMA_RX_EN; + mace->eth.dma_ctrl = priv->dma_ctrl; DPRINTK("Disabled meth Rx DMA temporarily\n"); spin_unlock(&priv->meth_lock); } - mace_eth_write(METH_INT_ERROR, int_stat); + mace->eth.int_stat = METH_INT_ERROR; } /* @@ -570,12 +575,12 @@ struct meth_private *priv = (struct meth_private *) dev->priv; unsigned long status; - status = mace_eth_read(int_stat); - while (status & 0xFF) { + status = mace->eth.int_stat; + while (status & 0xff) { /* First handle errors - if we get Rx underflow, - Rx DMA will be disabled, and Rx handler will reenable - it. I don't think it's possible to get Rx underflow, - without getting Rx interrupt */ + * Rx DMA will be disabled, and Rx handler will reenable + * it. I don't think it's possible to get Rx underflow, + * without getting Rx interrupt */ if (status & METH_INT_ERROR) { meth_error(dev, status); } @@ -589,7 +594,7 @@ /* send it to meth_rx for handling */ meth_rx(dev, status); } - status = mace_eth_read(int_stat); + status = mace->eth.int_stat; } return IRQ_HANDLED; @@ -601,45 +606,45 @@ static void meth_tx_short_prepare(struct meth_private *priv, struct sk_buff *skb) { - tx_packet *desc=&priv->tx_ring[priv->tx_write]; - int len = (skb->lenlen; + tx_packet *desc = &priv->tx_ring[priv->tx_write]; + int len = (skb->len < ETH_ZLEN) ? ETH_ZLEN : skb->len; - desc->header.raw=METH_TX_CMD_INT_EN|(len-1)|((128-len)<<16); + desc->header.raw = METH_TX_CMD_INT_EN | (len-1) | ((128-len) << 16); /* maybe I should set whole thing to 0 first... */ - memcpy(desc->data.dt+(120-len),skb->data,skb->len); - if(skb->len < len) - memset(desc->data.dt+120-len+skb->len,0,len-skb->len); + memcpy(desc->data.dt + (120 - len), skb->data, skb->len); + if (skb->len < len) + memset(desc->data.dt + 120 - len + skb->len, 0, len-skb->len); } #define TX_CATBUF1 BIT(25) static void meth_tx_1page_prepare(struct meth_private *priv, struct sk_buff *skb) { - tx_packet *desc=&priv->tx_ring[priv->tx_write]; + tx_packet *desc = &priv->tx_ring[priv->tx_write]; void *buffer_data = (void *)(((unsigned long)skb->data + 7) & ~7); int unaligned_len = (int)((unsigned long)buffer_data - (unsigned long)skb->data); int buffer_len = skb->len - unaligned_len; dma_addr_t catbuf; - desc->header.raw=METH_TX_CMD_INT_EN|TX_CATBUF1|(skb->len-1); + desc->header.raw = METH_TX_CMD_INT_EN | TX_CATBUF1 | (skb->len - 1); /* unaligned part */ - if(unaligned_len){ - memcpy(desc->data.dt+(120-unaligned_len), + if (unaligned_len) { + memcpy(desc->data.dt + (120 - unaligned_len), skb->data, unaligned_len); - desc->header.raw |= (128-unaligned_len) << 16; + desc->header.raw |= (128 - unaligned_len) << 16; } /* first page */ catbuf = dma_map_single(NULL, buffer_data, buffer_len, DMA_TO_DEVICE); desc->data.cat_buf[0].form.start_addr = catbuf >> 3; - desc->data.cat_buf[0].form.len = buffer_len-1; + desc->data.cat_buf[0].form.len = buffer_len - 1; } #define TX_CATBUF2 BIT(26) static void meth_tx_2page_prepare(struct meth_private *priv, struct sk_buff *skb) { - tx_packet *desc=&priv->tx_ring[priv->tx_write]; + tx_packet *desc = &priv->tx_ring[priv->tx_write]; void *buffer1_data = (void *)(((unsigned long)skb->data + 7) & ~7); void *buffer2_data = (void *)PAGE_ALIGN((unsigned long)skb->data); int unaligned_len = (int)((unsigned long)buffer1_data - (unsigned long)skb->data); @@ -647,44 +652,44 @@ int buffer2_len = skb->len - buffer1_len - unaligned_len; dma_addr_t catbuf1, catbuf2; - desc->header.raw=METH_TX_CMD_INT_EN|TX_CATBUF1|TX_CATBUF2|(skb->len-1); + desc->header.raw = METH_TX_CMD_INT_EN | TX_CATBUF1 | TX_CATBUF2| (skb->len - 1); /* unaligned part */ - if(unaligned_len){ - memcpy(desc->data.dt+(120-unaligned_len), + if (unaligned_len){ + memcpy(desc->data.dt + (120 - unaligned_len), skb->data, unaligned_len); - desc->header.raw |= (128-unaligned_len) << 16; + desc->header.raw |= (128 - unaligned_len) << 16; } /* first page */ catbuf1 = dma_map_single(NULL, buffer1_data, buffer1_len, DMA_TO_DEVICE); desc->data.cat_buf[0].form.start_addr = catbuf1 >> 3; - desc->data.cat_buf[0].form.len = buffer1_len-1; + desc->data.cat_buf[0].form.len = buffer1_len - 1; /* second page */ catbuf2 = dma_map_single(NULL, buffer2_data, buffer2_len, DMA_TO_DEVICE); desc->data.cat_buf[1].form.start_addr = catbuf2 >> 3; - desc->data.cat_buf[1].form.len = buffer2_len-1; + desc->data.cat_buf[1].form.len = buffer2_len - 1; } static void meth_add_to_tx_ring(struct meth_private *priv, struct sk_buff *skb) { /* Remember the skb, so we can free it at interrupt time */ priv->tx_skbs[priv->tx_write] = skb; - if(skb->len <= 120) { + if (skb->len <= 120) { /* Whole packet fits into descriptor */ - meth_tx_short_prepare(priv,skb); - } else if(PAGE_ALIGN((unsigned long)skb->data) != - PAGE_ALIGN((unsigned long)skb->data+skb->len-1)) { + meth_tx_short_prepare(priv, skb); + } else if (PAGE_ALIGN((unsigned long)skb->data) != + PAGE_ALIGN((unsigned long)skb->data + skb->len - 1)) { /* Packet crosses page boundary */ - meth_tx_2page_prepare(priv,skb); + meth_tx_2page_prepare(priv, skb); } else { /* Packet is in one page */ - meth_tx_1page_prepare(priv,skb); + meth_tx_1page_prepare(priv, skb); } - priv->tx_write = (priv->tx_write+1) & (TX_RING_ENTRIES-1); - mace_eth_write(priv->tx_write, tx_info); - priv->tx_count ++; + priv->tx_write = (priv->tx_write + 1) & (TX_RING_ENTRIES - 1); + mace->eth.tx_info = priv->tx_write; + priv->tx_count++; } /* @@ -695,10 +700,10 @@ struct meth_private *priv = (struct meth_private *) dev->priv; unsigned long flags; - spin_lock_irqsave(&priv->meth_lock,flags); + spin_lock_irqsave(&priv->meth_lock, flags); /* Stop DMA notification */ priv->dma_ctrl &= ~(METH_DMA_TX_INT_EN); - mace_eth_write(priv->dma_ctrl, dma_ctrl); + mace->eth.dma_ctrl = priv->dma_ctrl; meth_add_to_tx_ring(priv, skb); dev->trans_start = jiffies; /* save the timestamp */ @@ -711,9 +716,9 @@ /* Restart DMA notification */ priv->dma_ctrl |= METH_DMA_TX_INT_EN; - mace_eth_write(priv->dma_ctrl, dma_ctrl); + mace->eth.dma_ctrl = priv->dma_ctrl; - spin_unlock_irqrestore(&priv->meth_lock,flags); + spin_unlock_irqrestore(&priv->meth_lock, flags); return 0; } @@ -743,11 +748,11 @@ meth_init_rx_ring(priv); /* Restart dma */ - priv->dma_ctrl|=METH_DMA_TX_EN|METH_DMA_RX_EN|METH_DMA_RX_INT_EN; - mace_eth_write(priv->dma_ctrl, dma_ctrl); + priv->dma_ctrl |= METH_DMA_TX_EN | METH_DMA_RX_EN | METH_DMA_RX_INT_EN; + mace->eth.dma_ctrl = priv->dma_ctrl; /* Enable interrupt */ - spin_unlock_irqrestore(&priv->meth_lock,flags); + spin_unlock_irqrestore(&priv->meth_lock, flags); dev->trans_start = jiffies; netif_wake_queue(dev); @@ -760,8 +765,14 @@ */ static int meth_ioctl(struct net_device *dev, struct ifreq *rq, int cmd) { - DPRINTK("ioctl\n"); - return 0; + /* XXX Not yet implemented */ + switch(cmd) { + case SIOCGMIIPHY: + case SIOCGMIIREG: + case SIOCSMIIREG: + default: + return -EOPNOTSUPP; + } } /* @@ -808,7 +819,7 @@ } printk(KERN_INFO "%s: SGI MACE Ethernet rev. %d\n", - dev->name, (unsigned int)mace_eth_read(mac_ctrl) >> 29); + dev->name, (unsigned int)(mace->eth.mac_ctrl >> 29)); return 0; } diff -Nru a/drivers/net/meth.h b/drivers/net/meth.h --- a/drivers/net/meth.h 2005-03-06 18:36:50 -05:00 +++ b/drivers/net/meth.h 2005-03-06 18:36:50 -05:00 @@ -29,7 +29,7 @@ #define RX_BUCKET_SIZE 256 #undef BIT -#define BIT(x) (1 << (x)) +#define BIT(x) (1UL << (x)) /* For more detailed explanations of what each field menas, see Nick's great comments to #defines below (or docs, if diff -Nru a/drivers/net/mv643xx_eth.c b/drivers/net/mv643xx_eth.c --- a/drivers/net/mv643xx_eth.c 2005-03-06 18:36:50 -05:00 +++ b/drivers/net/mv643xx_eth.c 2005-03-06 18:36:50 -05:00 @@ -1349,13 +1349,11 @@ #ifdef MV64340_CHECKSUM_OFFLOAD_TX #ifdef MAX_SKB_FRAGS -#ifndef CONFIG_JAGUAR_DMALOW /* * Zero copy can only work if we use Discovery II memory. Else, we will * have to map the buffers to ISA memory which is only 16 MB */ dev->features = NETIF_F_SG | NETIF_F_IP_CSUM | NETIF_F_HW_CSUM; -#endif #endif #endif diff -Nru a/drivers/net/pcnet32.c b/drivers/net/pcnet32.c --- a/drivers/net/pcnet32.c 2005-03-06 18:36:50 -05:00 +++ b/drivers/net/pcnet32.c 2005-03-06 18:36:50 -05:00 @@ -1429,25 +1429,36 @@ val |= 0x10; lp->a.write_csr (ioaddr, 124, val); - /* 24 Jun 2004 according AMD, in order to change the PHY, - * DANAS (or DISPM for 79C976) must be set; then select the speed, - * duplex, and/or enable auto negotiation, and clear DANAS */ - if (lp->mii && !(lp->options & PCNET32_PORT_ASEL)) { - lp->a.write_bcr(ioaddr, 32, lp->a.read_bcr(ioaddr, 32) | 0x0080); - /* disable Auto Negotiation, set 10Mpbs, HD */ - val = lp->a.read_bcr(ioaddr, 32) & ~0xb8; - if (lp->options & PCNET32_PORT_FD) - val |= 0x10; - if (lp->options & PCNET32_PORT_100) - val |= 0x08; - lp->a.write_bcr (ioaddr, 32, val); + /* Allied Telesyn AT 2700/2701 FX looses the link, so skip that */ + if (lp->pci_dev->subsystem_vendor == PCI_VENDOR_ID_AT && + (lp->pci_dev->subsystem_device == PCI_SUBDEVICE_ID_AT_2700FX || + lp->pci_dev->subsystem_device == PCI_SUBDEVICE_ID_AT_2701FX)) { + printk(KERN_DEBUG "%s: Skipping PHY selection.\n", dev->name); } else { - if (lp->options & PCNET32_PORT_ASEL) { - lp->a.write_bcr(ioaddr, 32, lp->a.read_bcr(ioaddr, 32) | 0x0080); - /* enable auto negotiate, setup, disable fd */ - val = lp->a.read_bcr(ioaddr, 32) & ~0x98; - val |= 0x20; - lp->a.write_bcr(ioaddr, 32, val); + /* + * 24 Jun 2004 according AMD, in order to change the PHY, + * DANAS (or DISPM for 79C976) must be set; then select the speed, + * duplex, and/or enable auto negotiation, and clear DANAS + */ + if (lp->mii && !(lp->options & PCNET32_PORT_ASEL)) { + lp->a.write_bcr(ioaddr, 32, + lp->a.read_bcr(ioaddr, 32) | 0x0080); + /* disable Auto Negotiation, set 10Mpbs, HD */ + val = lp->a.read_bcr(ioaddr, 32) & ~0xb8; + if (lp->options & PCNET32_PORT_FD) + val |= 0x10; + if (lp->options & PCNET32_PORT_100) + val |= 0x08; + lp->a.write_bcr (ioaddr, 32, val); + } else { + if (lp->options & PCNET32_PORT_ASEL) { + lp->a.write_bcr(ioaddr, 32, + lp->a.read_bcr(ioaddr, 32) | 0x0080); + /* enable auto negotiate, setup, disable fd */ + val = lp->a.read_bcr(ioaddr, 32) & ~0x98; + val |= 0x20; + lp->a.write_bcr(ioaddr, 32, val); + } } } diff -Nru a/drivers/net/s2io.c b/drivers/net/s2io.c --- a/drivers/net/s2io.c 2005-03-06 18:36:50 -05:00 +++ b/drivers/net/s2io.c 2005-03-06 18:36:50 -05:00 @@ -36,28 +36,29 @@ * in PCI Configuration space. ************************************************************************/ -#include -#include -#include -#include -#include -#include -#include -#include -#include -#include -#include -#include -#include -#include -#include -#include -#include -#include -#include -#include -#include -#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include + +#include +#include +#include /* local include */ #include "s2io.h" diff -Nru a/drivers/net/sb1250-mac.c b/drivers/net/sb1250-mac.c --- a/drivers/net/sb1250-mac.c 2005-03-06 18:36:50 -05:00 +++ b/drivers/net/sb1250-mac.c 2005-03-06 18:36:50 -05:00 @@ -14,47 +14,11 @@ * You should have received a copy of the GNU General Public License * along with this program; if not, write to the Free Software * Foundation, Inc., 59 Temple Place - Suite 330, Boston, MA 02111-1307, USA. + * + * + * This driver is designed for the Broadcom SiByte SOC built-in + * Ethernet controllers. Written by Mitch Lichtenberg at Broadcom Corp. */ - -/* - This driver is designed for the Broadcom SiByte SOC built-in - Ethernet controllers. - - Written by Mitch Lichtenberg at Broadcom Corp. -*/ - - - -#define CONFIG_SBMAC_COALESCE - -/* A few user-configurable values. - These may be modified when a driver module is loaded. */ - -static int debug = 1; /* 1 normal messages, 0 quiet .. 7 verbose. */ -static int noisy_mii = 1; /* mii status msgs */ - -/* Used to pass the media type, etc. - Both 'options[]' and 'full_duplex[]' should exist for driver - interoperability. - The media type is usually passed in 'options[]'. -*/ - -#define MAX_UNITS 3 /* More are supported, limit only on options */ -#ifdef MODULE -static int options[MAX_UNITS] = {-1, -1, -1}; -static int full_duplex[MAX_UNITS] = {-1, -1, -1}; -#endif - -#ifdef CONFIG_SBMAC_COALESCE -static int int_pktcnt = 0; -static int int_timeout = 0; -#endif - -/* Operational parameters that usually are not changed. */ - -/* Time in jiffies before concluding the transmitter is hung. */ -#define TX_TIMEOUT (2*HZ) - #include #include #include @@ -89,16 +53,56 @@ #endif +/* Operational parameters that usually are not changed. */ + +#define CONFIG_SBMAC_COALESCE + +#define MAX_UNITS 3 /* More are supported, limit only on options */ + +/* Time in jiffies before concluding the transmitter is hung. */ +#define TX_TIMEOUT (2*HZ) + MODULE_AUTHOR("Mitch Lichtenberg (Broadcom Corp.)"); MODULE_DESCRIPTION("Broadcom SiByte SOC GB Ethernet driver"); -MODULE_PARM(debug, "i"); -MODULE_PARM(noisy_mii, "i"); -MODULE_PARM(options, "1-" __MODULE_STRING(MAX_UNITS) "i"); -MODULE_PARM(full_duplex, "1-" __MODULE_STRING(MAX_UNITS) "i"); -MODULE_PARM(int_pktcnt, "i"); -MODULE_PARM(int_timeout, "i"); +/* A few user-configurable values which may be modified when a driver + module is loaded. */ + +/* 1 normal messages, 0 quiet .. 7 verbose. */ +static int debug = 1; +module_param(debug, int, S_IRUGO); +MODULE_PARM_DESC(debug, "Debug messages"); + +/* mii status msgs */ +static int noisy_mii = 1; +module_param(noisy_mii, int, S_IRUGO); +MODULE_PARM_DESC(noisy_mii, "MII status messages"); + +/* Used to pass the media type, etc. + Both 'options[]' and 'full_duplex[]' should exist for driver + interoperability. + The media type is usually passed in 'options[]'. +*/ +#ifdef MODULE +static int options[MAX_UNITS] = {-1, -1, -1}; +module_param_array(options, int, NULL, S_IRUGO); +MODULE_PARM_DESC(options, "1-" __MODULE_STRING(MAX_UNITS)); + +static int full_duplex[MAX_UNITS] = {-1, -1, -1}; +module_param_array(full_duplex, int, NULL, S_IRUGO); +MODULE_PARM_DESC(full_duplex, "1-" __MODULE_STRING(MAX_UNITS)); +#endif + +#ifdef CONFIG_SBMAC_COALESCE +static int int_pktcnt = 0; +module_param(int_pktcnt, int, S_IRUGO); +MODULE_PARM_DESC(int_pktcnt, "Packet count"); + +static int int_timeout = 0; +module_param(int_timeout, int, S_IRUGO); +MODULE_PARM_DESC(int_timeout, "Timeout value"); +#endif #include #include @@ -1811,8 +1815,6 @@ /* read system identification to determine revision */ if (periph_rev >= 2) { - printk(KERN_INFO "%s: enabling TCP rcv checksum\n", - sc->sbm_dev->name); sc->rx_hw_checksum = ENABLE; } else { sc->rx_hw_checksum = DISABLE; @@ -2417,6 +2419,11 @@ if (err) goto out_uninit; + if (periph_rev >= 2) { + printk(KERN_INFO "%s: enabling TCP rcv checksum\n", + sc->sbm_dev->name); + } + /* * Display Ethernet address (this is called during the config * process so we need to finish off the config message that @@ -2879,12 +2886,12 @@ dev->mem_end = 0; if (sbmac_init(dev, idx)) { port = A_MAC_CHANNEL_BASE(idx); - SBMAC_WRITECSR(KSEG1ADDR(port+R_MAC_ETHERNET_ADDR), - sbmac_orig_hwaddr[idx] ); + SBMAC_WRITECSR(IOADDR(port+R_MAC_ETHERNET_ADDR), + sbmac_orig_hwaddr[idx]); free_netdev(dev); continue; } - dev_sbmac[idx++] = dev; + dev_sbmac[idx] = dev; } return 0; } diff -Nru a/drivers/net/sgiseeq.c b/drivers/net/sgiseeq.c --- a/drivers/net/sgiseeq.c 2005-03-06 18:36:50 -05:00 +++ b/drivers/net/sgiseeq.c 2005-03-06 18:36:50 -05:00 @@ -136,9 +136,10 @@ hregs->rx_ctrl = HPC3_ERXCTRL_ACTIVE; } -static inline void seeq_load_eaddr(struct net_device *dev, - struct sgiseeq_regs *sregs) +static inline void __sgiseeq_set_mac_address(struct net_device *dev) { + struct sgiseeq_private *sp = netdev_priv(dev); + struct sgiseeq_regs *sregs = sp->sregs; int i; sregs->tstat = SEEQ_TCMD_RB0; @@ -146,6 +147,20 @@ sregs->rw.eth_addr[i] = dev->dev_addr[i]; } +static int sgiseeq_set_mac_address(struct net_device *dev, void *addr) +{ + struct sgiseeq_private *sp = netdev_priv(dev); + struct sockaddr *sa = addr; + + memcpy(dev->dev_addr, sa->sa_data, dev->addr_len); + + spin_lock_irq(&sp->tx_lock); + __sgiseeq_set_mac_address(dev); + spin_unlock_irq(&sp->tx_lock); + + return 0; +} + #define TCNTINFO_INIT (HPCDMA_EOX | HPCDMA_ETXD) #define RCNTCFG_INIT (HPCDMA_OWN | HPCDMA_EORP | HPCDMA_XIE) #define RCNTINFO_INIT (RCNTCFG_INIT | (PKT_BUF_SZ & HPCDMA_BCNT)) @@ -159,13 +174,7 @@ sp->rx_new = sp->tx_new = 0; sp->rx_old = sp->tx_old = 0; - seeq_load_eaddr(dev, sp->sregs); - - /* XXX for now just accept packets directly to us - * XXX and ether-broadcast. Will do multicast and - * XXX promiscuous mode later. -davem - */ - sp->mode = SEEQ_RCMD_RBCAST; + __sgiseeq_set_mac_address(dev); /* Setup tx ring. */ for(i = 0; i < SEEQ_TX_BUFFERS; i++) { @@ -175,7 +184,7 @@ buffer = (unsigned long) kmalloc(PKT_BUF_SZ, GFP_KERNEL); if (!buffer) return -ENOMEM; - sp->tx_desc[i].buf_vaddr = KSEG1ADDR(buffer); + sp->tx_desc[i].buf_vaddr = CKSEG1ADDR(buffer); sp->tx_desc[i].tdma.pbuf = CPHYSADDR(buffer); } sp->tx_desc[i].tdma.cntinfo = TCNTINFO_INIT; @@ -189,7 +198,7 @@ buffer = (unsigned long) kmalloc(PKT_BUF_SZ, GFP_KERNEL); if (!buffer) return -ENOMEM; - sp->rx_desc[i].buf_vaddr = KSEG1ADDR(buffer); + sp->rx_desc[i].buf_vaddr = CKSEG1ADDR(buffer); sp->rx_desc[i].rdma.pbuf = CPHYSADDR(buffer); } sp->rx_desc[i].rdma.cntinfo = RCNTINFO_INIT; @@ -331,10 +340,17 @@ /* Copy out of kseg1 to avoid silly cache flush. */ eth_copy_and_sum(skb, pkt_pointer + 2, len, 0); skb->protocol = eth_type_trans(skb, dev); - netif_rx(skb); - dev->last_rx = jiffies; - sp->stats.rx_packets++; - sp->stats.rx_bytes += len; + + /* We don't want to receive our own packets */ + if (memcmp(eth_hdr(skb)->h_source, dev->dev_addr, ETH_ALEN)) { + netif_rx(skb); + dev->last_rx = jiffies; + sp->stats.rx_packets++; + sp->stats.rx_bytes += len; + } else { + /* Silently drop my own packets */ + dev_kfree_skb_irq(skb); + } } else { printk (KERN_NOTICE "%s: Memory squeeze, deferring packet.\n", dev->name); @@ -373,7 +389,7 @@ */ while ((td->tdma.cntinfo & (HPCDMA_XIU | HPCDMA_ETXD)) == (HPCDMA_XIU | HPCDMA_ETXD)) - td = (struct sgiseeq_tx_desc *)(long) KSEG1ADDR(td->tdma.pnext); + td = (struct sgiseeq_tx_desc *)(long) CKSEG1ADDR(td->tdma.pnext); if (td->tdma.cntinfo & HPCDMA_XIU) { hregs->tx_ndptr = CPHYSADDR(td); hregs->tx_ctrl = HPC3_ETXCTRL_ACTIVE; @@ -583,6 +599,22 @@ static void sgiseeq_set_multicast(struct net_device *dev) { + struct sgiseeq_private *sp = (struct sgiseeq_private *) dev->priv; + unsigned char oldmode = sp->mode; + + if(dev->flags & IFF_PROMISC) + sp->mode = SEEQ_RCMD_RANY; + else if ((dev->flags & IFF_ALLMULTI) || dev->mc_count) + sp->mode = SEEQ_RCMD_RBMCAST; + else + sp->mode = SEEQ_RCMD_RBCAST; + + /* XXX I know this sucks, but is there a better way to reprogram + * XXX the receiver? At least, this shouldn't happen too often. + */ + + if (oldmode != sp->mode) + sgiseeq_reset(dev); } static inline void setup_tx_ring(struct sgiseeq_tx_desc *buf, int nbufs) @@ -651,13 +683,14 @@ sp->sregs = (struct sgiseeq_regs *) &hpc3c0->eth_ext[0]; sp->hregs = &hpc3c0->ethregs; sp->name = sgiseeqstr; + sp->mode = SEEQ_RCMD_RBCAST; sp->rx_desc = (struct sgiseeq_rx_desc *) - KSEG1ADDR(ALIGNED(&sp->srings->rxvector[0])); + CKSEG1ADDR(ALIGNED(&sp->srings->rxvector[0])); dma_cache_wback_inv((unsigned long)&sp->srings->rxvector, sizeof(sp->srings->rxvector)); sp->tx_desc = (struct sgiseeq_tx_desc *) - KSEG1ADDR(ALIGNED(&sp->srings->txvector[0])); + CKSEG1ADDR(ALIGNED(&sp->srings->txvector[0])); dma_cache_wback_inv((unsigned long)&sp->srings->txvector, sizeof(sp->srings->txvector)); @@ -681,6 +714,7 @@ dev->watchdog_timeo = (200 * HZ) / 1000; dev->get_stats = sgiseeq_get_stats; dev->set_multicast_list = sgiseeq_set_multicast; + dev->set_mac_address = sgiseeq_set_mac_address; dev->irq = irq; if (register_netdev(dev)) { diff -Nru a/drivers/net/sk98lin/skge.c b/drivers/net/sk98lin/skge.c --- a/drivers/net/sk98lin/skge.c 2005-03-06 18:36:50 -05:00 +++ b/drivers/net/sk98lin/skge.c 2005-03-06 18:36:50 -05:00 @@ -5152,6 +5152,8 @@ { 0, } }; +MODULE_DEVICE_TABLE(pci, skge_pci_tbl); + static struct pci_driver skge_driver = { .name = "skge", .id_table = skge_pci_tbl, diff -Nru a/drivers/net/sonic.c b/drivers/net/sonic.c --- a/drivers/net/sonic.c 2005-03-06 18:36:50 -05:00 +++ b/drivers/net/sonic.c 2005-03-06 18:36:50 -05:00 @@ -116,7 +116,7 @@ /* * Map the packet data into the logical DMA address space */ - if ((laddr = vdma_alloc(PHYSADDR(skb->data), skb->len)) == ~0UL) { + if ((laddr = vdma_alloc(CPHYSADDR(skb->data), skb->len)) == ~0UL) { printk("%s: no VDMA entry for transmit available.\n", dev->name); dev_kfree_skb(skb); @@ -223,7 +223,7 @@ /* We must free the original skb */ if (lp->tx_skb[entry]) { - dev_kfree_skb(lp->tx_skb[entry]); + dev_kfree_skb_irq(lp->tx_skb[entry]); lp->tx_skb[entry] = 0; } /* and the VDMA address */ diff -Nru a/drivers/net/wan/Kconfig b/drivers/net/wan/Kconfig --- a/drivers/net/wan/Kconfig 2005-03-06 18:36:50 -05:00 +++ b/drivers/net/wan/Kconfig 2005-03-06 18:36:50 -05:00 @@ -155,7 +155,8 @@ Network) card supported by this driver and you are planning to connect the box to a WAN. - You will need supporting software from . + You will need supporting software from + . Generic HDLC driver currently supports raw HDLC, Cisco HDLC, Frame Relay, synchronous Point-to-Point Protocol (PPP) and X.25. @@ -225,7 +226,7 @@ Driver for PCI200SYN cards by Goramo sp. j. If you have such a card, say Y here and see - . + . To compile this as a module, choose M here: the module will be called pci200syn. @@ -239,7 +240,7 @@ Driver for wanXL PCI cards by SBE Inc. If you have such a card, say Y here and see - . + . To compile this as a module, choose M here: the module will be called wanxl. @@ -292,7 +293,7 @@ SDL Communications Inc. If you have such a card, say Y here and see - . + . Note that N2csu and N2dds cards are not supported by this driver. @@ -308,7 +309,7 @@ Driver for C101 SuperSync ISA cards by Moxa Technologies Co., Ltd. If you have such a card, say Y here and see - + . To compile this driver as a module, choose M here: the module will be called c101. diff -Nru a/drivers/net/wan/hd6457x.c b/drivers/net/wan/hd6457x.c --- a/drivers/net/wan/hd6457x.c 2005-03-06 18:36:50 -05:00 +++ b/drivers/net/wan/hd6457x.c 2005-03-06 18:36:50 -05:00 @@ -315,7 +315,7 @@ #endif stats->rx_packets++; stats->rx_bytes += skb->len; - skb->dev->last_rx = jiffies; + dev->last_rx = jiffies; skb->protocol = hdlc_type_trans(skb, dev); netif_rx(skb); } diff -Nru a/drivers/net/wan/z85230.c b/drivers/net/wan/z85230.c --- a/drivers/net/wan/z85230.c 2005-03-06 18:36:50 -05:00 +++ b/drivers/net/wan/z85230.c 2005-03-06 18:36:50 -05:00 @@ -734,7 +734,7 @@ u8 intr; static volatile int locker=0; int work=0; - struct z8530_irqhandler *irqs=dev->chanA.irqs; + struct z8530_irqhandler *irqs; if(locker) { @@ -758,6 +758,8 @@ /* Now walk the chip and see what it is wanting - it may be an IRQ for someone else remember */ + irqs=dev->chanA.irqs; + if(intr & (CHARxIP|CHATxIP|CHAEXT)) { if(intr&CHARxIP) diff -Nru a/include/linux/pci_ids.h b/include/linux/pci_ids.h --- a/include/linux/pci_ids.h 2005-03-06 18:36:50 -05:00 +++ b/include/linux/pci_ids.h 2005-03-06 18:36:50 -05:00 @@ -1656,6 +1656,11 @@ #define PCI_DEVICE_ID_OPTIBASE_VPLEXCC 0x2120 #define PCI_DEVICE_ID_OPTIBASE_VQUEST 0x2130 +/* Allied Telesyn */ +#define PCI_VENDOR_ID_AT 0x1259 +#define PCI_SUBDEVICE_ID_AT_2700FX 0x2701 +#define PCI_SUBDEVICE_ID_AT_2701FX 0x2703 + #define PCI_VENDOR_ID_ESS 0x125d #define PCI_DEVICE_ID_ESS_ESS1968 0x1968 #define PCI_DEVICE_ID_ESS_AUDIOPCI 0x1969 --------------030602010205090106010908-- From webmaster@rapidforum.com Sun Mar 6 16:27:20 2005 Received: with ECARTIS (v1.0.0; list netdev); Sun, 06 Mar 2005 16:27:25 -0800 (PST) Received: from rapidforum.com (www.rapidforum.com [80.237.244.2]) by oss.sgi.com (8.13.0/8.13.0) with SMTP id j270RJdV023084 for ; Sun, 6 Mar 2005 16:27:20 -0800 Received: (qmail 10869 invoked by uid 1004); 7 Mar 2005 00:27:16 -0000 Received: from p3ee0455d.dip0.t-ipconnect.de (HELO ?62.224.69.93?) (62.224.69.93) by www.rapidforum.com with SMTP; 7 Mar 2005 00:27:16 -0000 Message-ID: <422B9FDD.8070308@rapidforum.com> Date: Mon, 07 Mar 2005 01:27:09 +0100 From: Christian Schmid User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.8a3) Gecko/20040817 X-Accept-Language: de, en MIME-Version: 1.0 To: netdev@oss.sgi.com Subject: What are you doing??? Content-Type: multipart/mixed; boundary="------------020308000408030901070304" X-Virus-Scanned: ClamAV 0.83/748/Fri Mar 4 14:19:11 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 2554 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: webmaster@rapidforum.com Precedence: bulk X-list: netdev Content-Length: 4060 Lines: 69 This is a multi-part message in MIME format. --------------020308000408030901070304 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Just for your info: The bug got worse on 2.6.11 Attached is an image showing you a direct comparison between 2.6.11 (the first) then a rebbot and then 2.6.10 (the last) Chris --------------020308000408030901070304 Content-Type: image/png; name="traffic3.png" Content-Transfer-Encoding: base64 Content-Disposition: inline; filename="traffic3.png" iVBORw0KGgoAAAANSUhEUgAAArEAAABnCAYAAAAXIho2AAAABmJLR0QA/wD/AP+gvaeTAAAA CXBIWXMAAAuJAAALiQE3ycutAAAAB3RJTUUH1QMGEiAtIxUN+QAAAB10RVh0Q29tbWVudABD cmVhdGVkIHdpdGggVGhlIEdJTVDvZCVuAAAJeElEQVR42u3dvXKjWBYA4OspAoUms591+gl6 N9/E/QiTbNXMI2y4r2FnTKiAKm/Qiwcz4keYn3vg+6q6aIQlXeByOFwdoYeqen1PQTw+PiUA AM7t2z9+pCJao//8882ey1hZPqWqso+ibAf7C8QjYm3vyPtz0bbXKf2iu537QAOAs5w/nPcO tI0KSSwAIIEimvoqiQUAIJjiIokFACAYNbEAAISjJhYAgHDUxEI/XzAAgEypiUVSuW+bJMoA MEO0mlg/dMDWiWjfsu7jklEA2JCaWFgv0QUAVqImFpZJZMf+Zuy5EuH89y0AGVET6wSL/QSI HegT4bhPLAhcAOR5Huj7v/NRSqlIqRhegedP81X1utsyiBiIqurtZlDoPg4AYRPKPQzVxDYJ ZVW9fiSTzWNbL8MBmMtBXZZPq73vXl8eExxBHCbGvmiet+W+zLbfqIlliw6f0wEwpy0Cv5Mw OIZY+xzZHSS55wvBWw2u3Hqf3frUUE1sezS0PUoKUw+gOcnsEgfDPaOle9YbOakAW8WXbqy7 Nx7PeU6UZH3PNk8ZWR1b1n2N5rF7z4P3ftI495PJxbb30H1ifbzPEp0vx6u4td9vSmI8NShJ lIG1jvspidPcQYEt16sv2Z6bkM39NHFKXF974GTonHMr2f3qNp563lrl3F9f00NVvb6PJbHd +a2X3WoXAADn9Ov3l+G7E+TojCUNt77lvsRrtb8p3/cezeO3pu3n/n0/vfVeZd36xv7Q6/Rt h75v+g/dAaC7bGgbrD2qMLSNxtZ9qT4U7W4JSx4LW7wu7NX/cvj05d51GjuvLBlnp77H2Pmu ey6Z+z457Kslt/nYuX2JfvPPf/3ui11RA95XAtW9H3Hv/ZOrexSvR+oDAE1cWPMOKmvGqbXi /Fdfa4nysDPnKKsqZn6xa+tlLN+RtqwLXTrArb0+EkTBVF8gSt/OKWmdcgzdW0tpIOC8sXf0 NerrcDnBUBK59TKmJXJzhu5vXWkOffS81B0Eln4tAW7aeh31Y3MlARy5P2d1a6OFElnHK1P7 y61yxl+/X+LVxDIcvCKMSLqVlYQOmD6oAEfLVRZ5vaH7xBKrk5wtQRMQbBv9CuDECkns4U+w e/xEXeRteqTtlMOvvQAupGCVY6O+SmIFxuOu05HrWr+6fkc/Web808cALKC4SGI5R6J9hiRm y3XM4Wcav/p3ElvOevzCIY4LNbEC21m3le0aez/afwAnpyZWcqDNx9unW41A2jfgOILdqInF CSJ++7dex73KFta4rZzaWYCg1MRKwGxHjrRf1cEiNsFJqIkFJ8O13yfXX2WDvY7Ts93bG1ZR pOFf7CrL50/z7Z+F3XqZhAS26Ve3fu5yzq9/tZ9372tM/Xv3QSbacaevwkKGamKbhLKqXj+S yeaxrZdJNOAY/TjH/u2YQ9+CgIrL8Ehs21lHRYHtTvi3Rl/3TgS+MqKMxBVYiZpYOPbJ8d7n rP33Y8+VACCBBSaZcp/Ysnz++Ac4Mc5t35YJsv2DfgAHV1/Hywna9all+bx7WYFkeqvtrN17 t3WpdZn6Ou2/6z5nbltvPT70PmusbzPfnd6zLmNtjnq8IGZrs3UIux7Fy/Sa2FwcuTY3pyv5 qnoLObIQqd1jbd16Xdrv1707wVh7unWiQ8/pqy9da127bWi//9C69D2nb9twhkQxz7rtqDE7 6nnmaOsQdj3qH2piJbCg/zo+0TcgmKGa2G4ZQfuxrZeBk+M+733EE/Tcder+BK7kBWBHYzWx Q0nk1suAmMkeOEaAxRUX5QQCITjmQB+CYNwnFuC+5ETyApCBQhILSM4AiGbKfWIBJMugD0NW ioskVjAEfdlxCRCMmlhg72RRwogLHOBuamIBiQEA4dRXSSwAAMG4T+y+jD4BiNfADGpiAQAI p0jT705Qls8ppb9+GraZb7R/MnaNZa7qAQBIKU2vie0ml+2EtpvUrrEMAPZi0AEyNKUmtiyf Dz0iCgBAMGpiXdUDIF5DOGP3iTUKCwDgYi079bX/i125JrDqZLfaztqtrfrE0bcNYrY2W4ew ipfhuxPcShj3TiKPMDLs46k1+8dbmO0bqa0R27v1tuGoyaE+D1mqf/Qnsd1ksX33AKOhAiKA eA3sppj5xa72LbC6949dYxkc8aTjBAkAMw3VxPYlrn3zay+TYAEAkFKadp9YAFygAmTFfWIB wIUJhFNIYgVDAIBo6qskVgILABCMmlgJLABAOGpiAeAzAxAQQJGm32ILARD9GgCyoCYWAFys QThqYpcPfAIgAMDK1MQCcGZl+WTwASIaq4kty+dP8+2fhd16WZRgCEC8WF2WT6mq3mwciGKo JrZJKKvq9SOZbB7behkAGGwAPhSX/pHYaKOgACCBhZOYWhPbHiUFAAkssKtiQhIrgQVAAgtk pb5O+2JXTgls1DrZstTf4NiJkm1gHwKbKV76k9hcR2BzHBGecpVfVW9GA+DAfLM918T06a59 KE5DEPUP94ndKkAKjAD5JrBAMGP3if0ZBP5+79aqek1l+fxpWTNCusYyAAD4MFQTO5ZADi1f Y5mrfADEZyCllFJxUU4AgMQVCKaeUE6AIAkgTgNZKSSxAiKAeC3WQzT1VTkBAADBqIl1ZQ6I FbY/EE6dYiWxj4/bBilBEUACC2SoSEZiAZDAAsGoiQUAIBw1sa7uAQDCqZUTABCUwQY4MTWx LO09PYR87bO2NdI2XbO9S72upAqxPu+YtEXMi74OYc7j9dWPHUQJFg/pfZHXuNWBbj0+9bHc DoCpbcwhyI+1tb3Ph/bfmLHnNcu6f9e8f9/yvraOPaf9ut11nNLue7fB1L7cbnPfsTflWGwS 2ap6+5hv/g9TY3z7se5x2Y0H3WNqqxj41fdZ6hjfM5E6wjrcWo8Iiey34iVeEjs00lFVbzdP GGOjI83zcr6aXWKn973Glm1g/v6au/3n7t973u+evjU1UO4VRMe2w9REvh1T7o0ve8Wkofft xtdbfze13WN/17d8z1i9R58ceqx7HN1KeOHQ6pQequr1PUp7Hx+f0kNmx+fUgJHTCCGwjq9+ YsK+iac4DXF8+x5wJDZqgBEYQcKE/QcspL6mh9/+/Z/3VFzStb6mS3FJqb4m8+bNmzdv3rx5 8+azmE+XdE3XdEkpXVP6mH/47Y//vjcPmZqampqampqammY1/ZTQ/rX0l5TSz4zX1NTU1NTU 1NTUNLfp5Wfqeiku6fr/aoJrndL/AOLJE/S6WoHXAAAAAElFTkSuQmCC --------------020308000408030901070304-- From dgibson@ozlabs.org Sun Mar 6 17:09:56 2005 Received: with ECARTIS (v1.0.0; list netdev); Sun, 06 Mar 2005 17:10:08 -0800 (PST) Received: from ozlabs.org (ozlabs.org [203.10.76.45]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j2719tFS024617 for ; Sun, 6 Mar 2005 17:09:56 -0800 Received: by ozlabs.org (Postfix, from userid 1007) id 994B567A8A; Mon, 7 Mar 2005 12:09:47 +1100 (EST) Date: Mon, 7 Mar 2005 11:57:36 +1100 From: David Gibson To: domen@coderock.org Cc: proski@gnu.org, netdev@oss.sgi.com, nacc@us.ibm.com, janitor@sternwelten.at Subject: Re: [patch 1/2] net/orinoco_plx: replace schedule_timeout() with ssleep() Message-ID: <20050307005736.GA19547@localhost.localdomain> References: <20050306222140.6ACE51EC90@trashy.coderock.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20050306222140.6ACE51EC90@trashy.coderock.org> User-Agent: Mutt/1.5.6+20040523i X-Virus-Scanned: ClamAV 0.83/748/Fri Mar 4 14:19:11 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 2555 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: hermes@gibson.dropbear.id.au Precedence: bulk X-list: netdev Content-Length: 586 Lines: 16 On Sun, Mar 06, 2005 at 11:21:40PM +0100, domen@coderock.org wrote: > > Use ssleep() instead of schedule_timeout() > to guarantee the task delays as expected. > > Signed-off-by: Nishanth Aravamudan > Signed-off-by: Maximilian Attems > Signed-off-by: Domen Puncer Already in CVS, patch already sent to Jeff. Likewise for orinoco_tmd. -- David Gibson | I'll have my music baroque, and my code david AT gibson.dropbear.id.au | minimalist. NOT _the_ _other_ _way_ | _around_! http://www.ozlabs.org/people/dgibson From herbert@gondor.apana.org.au Sun Mar 6 17:25:48 2005 Received: with ECARTIS (v1.0.0; list netdev); Sun, 06 Mar 2005 17:25:55 -0800 (PST) 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 j271PlI5025351 for ; Sun, 6 Mar 2005 17:25:48 -0800 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 1D86zt-0007KF-00; Mon, 07 Mar 2005 12:25:25 +1100 Received: from herbert by gondolin.me.apana.org.au with local (Exim 3.36 #1 (Debian)) id 1D86zS-00018E-00; Mon, 07 Mar 2005 12:24:58 +1100 Date: Mon, 7 Mar 2005 12:24:58 +1100 To: Patrick McHardy Cc: davem@davemloft.net, netdev@oss.sgi.com Subject: Re: [PATCH 3/3 XFRM]: Fix invalid key for lookup of cached bundles Message-ID: <20050307012458.GA4335@gondor.apana.org.au> References: <422AF8D0.3010905@trash.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <422AF8D0.3010905@trash.net> User-Agent: Mutt/1.5.6+20040907i From: Herbert Xu X-Virus-Scanned: ClamAV 0.83/748/Fri Mar 4 14:19:11 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 2556 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: herbert@gondor.apana.org.au Precedence: bulk X-list: netdev Content-Length: 659 Lines: 17 On Sun, Mar 06, 2005 at 01:34:24PM +0100, Patrick McHardy wrote: > > How about this one ? It keeps the DST_XFRM_TUNNEL flag and sets it on > the first xfrm_dst in a bundle. I know it doesn't really belong there, Actually, why do we need to treat tunnel mode differently here? In other words, why not just do the mark/tos checks unconditionally. Forwarded packets don't get a proper tos/mark setting for IPsec but that's a bug in itself. Cheers, -- Visit Openswan at http://www.openswan.org/ Email: Herbert Xu ~{PmV>HI~} Home Page: http://gondor.apana.org.au/~herbert/ PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt From kaber@trash.net Sun Mar 6 17:42:08 2005 Received: with ECARTIS (v1.0.0; list netdev); Sun, 06 Mar 2005 17:42:12 -0800 (PST) Received: from kaber.coreworks.de ([62.206.217.67]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j271g7Fp026105 for ; Sun, 6 Mar 2005 17:42:08 -0800 Received: from localhost ([127.0.0.1]) by kaber.coreworks.de with esmtp (Exim 4.50) id 1D87FS-0006qW-Os; Mon, 07 Mar 2005 02:41:30 +0100 Message-ID: <422BB14A.5030302@trash.net> Date: Mon, 07 Mar 2005 02:41:30 +0100 From: Patrick McHardy User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.7.5) Gecko/20050106 Debian/1.7.5-1 X-Accept-Language: en MIME-Version: 1.0 To: Herbert Xu CC: davem@davemloft.net, netdev@oss.sgi.com Subject: Re: [PATCH 3/3 XFRM]: Fix invalid key for lookup of cached bundles References: <422AF8D0.3010905@trash.net> <20050307012458.GA4335@gondor.apana.org.au> In-Reply-To: <20050307012458.GA4335@gondor.apana.org.au> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV 0.83/748/Fri Mar 4 14:19:11 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 2557 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: kaber@trash.net Precedence: bulk X-list: netdev Content-Length: 787 Lines: 21 Herbert Xu wrote: > On Sun, Mar 06, 2005 at 01:34:24PM +0100, Patrick McHardy wrote: > >>How about this one ? It keeps the DST_XFRM_TUNNEL flag and sets it on >>the first xfrm_dst in a bundle. I know it doesn't really belong there, > > > Actually, why do we need to treat tunnel mode differently here? > In other words, why not just do the mark/tos checks unconditionally. > > Forwarded packets don't get a proper tos/mark setting for IPsec > but that's a bug in itself. Mainly to avoid excessive long lists of cached bundles in tunnel mode. The use of a single list for the cache is questionable, but the patch was supposed to fix a different issue. Restricting use of tos/mark to transport mode avoids having exploding lists that are easily remotely triggerable. Regards Patrick From herbert@gondor.apana.org.au Sun Mar 6 17:44:14 2005 Received: with ECARTIS (v1.0.0; list netdev); Sun, 06 Mar 2005 17:44:20 -0800 (PST) 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 j271iCOZ026584 for ; Sun, 6 Mar 2005 17:44:13 -0800 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 1D87Hr-0007RD-00; Mon, 07 Mar 2005 12:43:59 +1100 Received: from herbert by gondolin.me.apana.org.au with local (Exim 3.36 #1 (Debian)) id 1D87HV-0001A0-00; Mon, 07 Mar 2005 12:43:37 +1100 Date: Mon, 7 Mar 2005 12:43:37 +1100 To: Patrick McHardy Cc: davem@davemloft.net, netdev@oss.sgi.com Subject: Re: [PATCH 3/3 XFRM]: Fix invalid key for lookup of cached bundles Message-ID: <20050307014337.GA4451@gondor.apana.org.au> References: <422AF8D0.3010905@trash.net> <20050307012458.GA4335@gondor.apana.org.au> <422BB14A.5030302@trash.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <422BB14A.5030302@trash.net> User-Agent: Mutt/1.5.6+20040907i From: Herbert Xu X-Virus-Scanned: ClamAV 0.83/748/Fri Mar 4 14:19:11 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 2558 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: herbert@gondor.apana.org.au Precedence: bulk X-list: netdev Content-Length: 850 Lines: 20 On Mon, Mar 07, 2005 at 02:41:30AM +0100, Patrick McHardy wrote: > > > >Actually, why do we need to treat tunnel mode differently here? > >In other words, why not just do the mark/tos checks unconditionally. > > Mainly to avoid excessive long lists of cached bundles in tunnel > mode. The use of a single list for the cache is questionable, but > the patch was supposed to fix a different issue. Restricting use > of tos/mark to transport mode avoids having exploding lists that > are easily remotely triggerable. That's a different problem. You can already create arbitrarily long bundle lists by spoofing src/dst addresses... Cheers, -- Visit Openswan at http://www.openswan.org/ Email: Herbert Xu ~{PmV>HI~} Home Page: http://gondor.apana.org.au/~herbert/ PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt From kaber@trash.net Sun Mar 6 17:55:40 2005 Received: with ECARTIS (v1.0.0; list netdev); Sun, 06 Mar 2005 17:55:43 -0800 (PST) Received: from kaber.coreworks.de ([62.206.217.67]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j271tdrM027337 for ; Sun, 6 Mar 2005 17:55:40 -0800 Received: from localhost ([127.0.0.1]) by kaber.coreworks.de with esmtp (Exim 4.50) id 1D87SZ-0006s3-5e; Mon, 07 Mar 2005 02:55:03 +0100 Message-ID: <422BB477.3040607@trash.net> Date: Mon, 07 Mar 2005 02:55:03 +0100 From: Patrick McHardy User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.7.5) Gecko/20050106 Debian/1.7.5-1 X-Accept-Language: en MIME-Version: 1.0 To: Herbert Xu CC: davem@davemloft.net, netdev@oss.sgi.com Subject: Re: [PATCH 3/3 XFRM]: Fix invalid key for lookup of cached bundles References: <422AF8D0.3010905@trash.net> <20050307012458.GA4335@gondor.apana.org.au> <422BB14A.5030302@trash.net> <20050307014337.GA4451@gondor.apana.org.au> In-Reply-To: <20050307014337.GA4451@gondor.apana.org.au> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV 0.83/748/Fri Mar 4 14:19:11 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 2559 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: kaber@trash.net Precedence: bulk X-list: netdev Content-Length: 686 Lines: 19 Herbert Xu wrote: > On Mon, Mar 07, 2005 at 02:41:30AM +0100, Patrick McHardy wrote: >> >>Mainly to avoid excessive long lists of cached bundles in tunnel >>mode. The use of a single list for the cache is questionable, but >>the patch was supposed to fix a different issue. Restricting use >>of tos/mark to transport mode avoids having exploding lists that >>are easily remotely triggerable. > > > That's a different problem. You can already create arbitrarily > long bundle lists by spoofing src/dst addresses... But I don't want to make it worse. The number is still restricted by the scope of the selector, using tos and fwmark makes the worst case a lot worse. Regards Patrick From herbert@gondor.apana.org.au Sun Mar 6 18:00:20 2005 Received: with ECARTIS (v1.0.0; list netdev); Sun, 06 Mar 2005 18:00:27 -0800 (PST) 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 j2720IY0028077 for ; Sun, 6 Mar 2005 18:00:19 -0800 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 1D87XR-0007Ug-00; Mon, 07 Mar 2005 13:00:05 +1100 Received: from herbert by gondolin.me.apana.org.au with local (Exim 3.36 #1 (Debian)) id 1D87X5-0001BR-00; Mon, 07 Mar 2005 12:59:43 +1100 Date: Mon, 7 Mar 2005 12:59:43 +1100 To: Patrick McHardy Cc: davem@davemloft.net, netdev@oss.sgi.com Subject: Re: [PATCH 3/3 XFRM]: Fix invalid key for lookup of cached bundles Message-ID: <20050307015943.GA4533@gondor.apana.org.au> References: <422AF8D0.3010905@trash.net> <20050307012458.GA4335@gondor.apana.org.au> <422BB14A.5030302@trash.net> <20050307014337.GA4451@gondor.apana.org.au> <422BB477.3040607@trash.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <422BB477.3040607@trash.net> User-Agent: Mutt/1.5.6+20040907i From: Herbert Xu X-Virus-Scanned: ClamAV 0.83/748/Fri Mar 4 14:19:11 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 2560 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: herbert@gondor.apana.org.au Precedence: bulk X-list: netdev Content-Length: 647 Lines: 16 On Mon, Mar 07, 2005 at 02:55:03AM +0100, Patrick McHardy wrote: > > But I don't want to make it worse. The number is still restricted by > the scope of the selector, using tos and fwmark makes the worst case > a lot worse. How about we fix the bundle problem first, and then add the fwmark/tos stuff? I think fixing the bundle list scalability is probably more important than having working TOS/fwmark at this point in time. Cheers, -- Visit Openswan at http://www.openswan.org/ Email: Herbert Xu ~{PmV>HI~} Home Page: http://gondor.apana.org.au/~herbert/ PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt From kaber@trash.net Sun Mar 6 18:31:03 2005 Received: with ECARTIS (v1.0.0; list netdev); Sun, 06 Mar 2005 18:31:08 -0800 (PST) Received: from kaber.coreworks.de ([62.206.217.67]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j272V28V029175 for ; Sun, 6 Mar 2005 18:31:03 -0800 Received: from localhost ([127.0.0.1]) by kaber.coreworks.de with esmtp (Exim 4.50) id 1D880o-0006wn-A5; Mon, 07 Mar 2005 03:30:26 +0100 Message-ID: <422BBCC2.4010706@trash.net> Date: Mon, 07 Mar 2005 03:30:26 +0100 From: Patrick McHardy User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.7.5) Gecko/20050106 Debian/1.7.5-1 X-Accept-Language: en MIME-Version: 1.0 To: Herbert Xu CC: davem@davemloft.net, netdev@oss.sgi.com Subject: Re: [PATCH 3/3 XFRM]: Fix invalid key for lookup of cached bundles References: <422AF8D0.3010905@trash.net> <20050307012458.GA4335@gondor.apana.org.au> <422BB14A.5030302@trash.net> <20050307014337.GA4451@gondor.apana.org.au> <422BB477.3040607@trash.net> <20050307015943.GA4533@gondor.apana.org.au> In-Reply-To: <20050307015943.GA4533@gondor.apana.org.au> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV 0.83/748/Fri Mar 4 14:19:11 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 2561 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: kaber@trash.net Precedence: bulk X-list: netdev Content-Length: 754 Lines: 16 Herbert Xu wrote: > How about we fix the bundle problem first, and then add the fwmark/tos > stuff? I think fixing the bundle list scalability is probably more > important than having working TOS/fwmark at this point in time. I agree that it is more important, but I don't see any harm in fixing the other problem for transport mode first. Fixing the scalability problem requires a dynamically resized hash, anything static will lead to different scalability problems with a large number of policies. The tos/fwmark part looks comparatively small, simply reroute all packets based on src/dst/fwmark/predicted final tos if they differ. But since both of this is not done yet, I think it would be better to fix the smaller problem first. Regards Patrick From pedro.fortuna@gmail.com Sun Mar 6 18:46:02 2005 Received: with ECARTIS (v1.0.0; list netdev); Sun, 06 Mar 2005 18:46:05 -0800 (PST) Received: from rproxy.gmail.com (rproxy.gmail.com [64.233.170.195]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j272k1sM030003 for ; Sun, 6 Mar 2005 18:46:01 -0800 Received: by rproxy.gmail.com with SMTP id y7so1051747rne for ; Sun, 06 Mar 2005 18:46:01 -0800 (PST) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:reply-to:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:references; b=epZRpyuLNX7t7vj6pYMtZYz3ZCFtsMvqiSggaD8OREq5w40V7x4kXY16kj0lcYKClp7bfbfzgmg5ZacYyWyMdZm6W00K71TqlRY0EdlCNghBGcnpeuALkfY03sPX4M2SwwBGsR9gb6ptqFSRrq7ZRRcYuxuoU3XU33rWpENxnBk= Received: by 10.11.118.24 with SMTP id q24mr311554cwc; Sun, 06 Mar 2005 18:46:00 -0800 (PST) Received: by 10.11.99.66 with HTTP; Sun, 6 Mar 2005 18:46:00 -0800 (PST) Message-ID: Date: Mon, 7 Mar 2005 02:46:00 +0000 From: Pedro Fortuna Reply-To: Pedro Fortuna To: Asim Shankar Subject: Re: filtering packtes before OS takes care about them Cc: netdev@oss.sgi.com In-Reply-To: <7bca1cb50503051729e3273d3@mail.gmail.com> Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit References: <09766A6E64A068419B362367800D50C0B58A17@moritz.faps.uni-erlangen.de> <7bca1cb50502281209798e8a00@mail.gmail.com> <7bca1cb505030510586aeb96c1@mail.gmail.com> <7bca1cb50503051729e3273d3@mail.gmail.com> X-Virus-Scanned: ClamAV 0.83/748/Fri Mar 4 14:19:11 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 2562 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: pedro.fortuna@gmail.com Precedence: bulk X-list: netdev Content-Length: 4346 Lines: 115 Hello Asim, Sorry to bother you again, but I run into some problems doing the tunneling stuff and maybe you or somebody else can give some clues. Based on your code I've coded two small kernel modules that used packet_type function handlers to basically do the following: The mod1@PC1 intercepts every FTP packet sent from PC1 to PC2, replacing the ethertype (0x800) in the ethernet header for a new unknown ethertype (0x801). The packets are then sent to PC2 in which mod2 is running. Mod2@PC2 intercepts the packet and replaces back the ethertype to the standard (0x800). The packet is then delivered to the FTP application which answers back to PC1 with unchanged frames. The PC's are linked with a cross-over ethernet cable (no switch/bridge interference) I've run ethereal in both hosts while I test the modules and this was what I observed: - In PC1, I was able to observe ethernet frames with 0x801: I shouln't see this because the ethertype change should be the _last_ thing just before the packet is passed to the network driver. From this I conclued that my packet_type function is not registed as the last function to handle packets (i.e. might be the first). - In PC2, I was able to observe the ethernet frames (sent by PC1) with 0x800: This is good, because it means that mod2 was able to change the ethertype 0x801 to 0x800 before (I presume) any other function handled the packet. - The problem is that PC2 never answers to the FTP Syn packets :-( With mod1 and mod2 unloaded I was able to fully use FTP, so I know it is (almost certainly) a problem with mod2. Here it is a small portion of mod2's code: static int __init init(void) { my_packet_type.type = htons(ETH_P_ALL); my_packet_type.func = packet_rcv; my_packet_type.dev = NULL; dev_add_pack(&my_packet_type); } static int packet_rcv(struct sk_buff *skb, struct net_device *dev, struct packet_type *pt) { struct ethhdr *eh = eth_hdr(skb); if (eh->h_proto == htons(0x801)) { //reverse operation revopcount++; eh->h_proto=htons(0x800); printk(KERN_ERR "packet_type_test: reverse-op! revopcount=%d\n",revopcount); } kfree_skb(skb); return 0; } As you can see from the code excerpt, this is a very simple module, so I guess Im missing some very basic piece of the puzzle :\ I think the problem might be related with the position of my packet_type function in the packet_type functions list i.e. the ip_rcv() receiving the 0x801 version (not the 0x800) and dropping the FTP syn packet. Any tips are appreciated, -Pedro Fortuna On Sat, 5 Mar 2005 19:29:34 -0600, Asim Shankar wrote: > Hi Pedro, > > Yeah, it should be able to cover all outgoing packets as well. > Basically, all struct packet_type{}s with the type field set to > htons(ETH_P_ALL) are also called on outgoing packets (see > dev_queue_xmit_nit() called by dev_queue_xmit() in net/core/dev.c) > > Though as I mentioned earlier, I'm not sure if this will *always* > happen (i.e., if outgoing packets *always* go through > dev_queue_xmit()). Someone more knowledgeable may have to answer that. > > Best of luck and let me know if you have any trouble, > Regards, > > -- Asim > > On Sat, 5 Mar 2005 19:36:38 +0000, Pedro Fortuna > wrote: > > Hello Asim, > > I tried again but this time in Fedora Core 3 (kernel 2.6.10-1.760_FC3) > > and it went flawlessly. > > I have a look into your example and also into the Phrack article you > > mentioned and now I'm ready to begin some tests towards what I want to > > implement. > > > > It's absolutly clear you can fetch (and modify) packets before they > > are delivered to the TCP/IP stack with a custom packet_type function, > > but is it also possible to intercept just before they are passed to > > the network driver? > > > > Thanks, > > -Pedro Fortuna > > > > > > On Sat, 5 Mar 2005 12:58:23 -0600, Asim Shankar wrote: > > > > I wasnt able to compile your packet_type_test.c : > > > > all I got was a huge list of errors > > > > and warnings, and no .o compiled in the end. > > > > > > Can you send the specific errors you got? > > > And is the kernel sources present in > > > /lib/modules/`uname -r`/build? > > > > > > Regards, > > > > > > -- Asim > > > > > > From herbert@gondor.apana.org.au Sun Mar 6 18:58:14 2005 Received: with ECARTIS (v1.0.0; list netdev); Sun, 06 Mar 2005 18:58:21 -0800 (PST) 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 j272wCMo030802 for ; Sun, 6 Mar 2005 18:58:13 -0800 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 1D88RL-0007jh-00; Mon, 07 Mar 2005 13:57:51 +1100 Received: from herbert by gondolin.me.apana.org.au with local (Exim 3.36 #1 (Debian)) id 1D88Qt-0001GH-00; Mon, 07 Mar 2005 13:57:23 +1100 Date: Mon, 7 Mar 2005 13:57:23 +1100 To: Patrick McHardy Cc: davem@davemloft.net, netdev@oss.sgi.com Subject: Re: [PATCH 3/3 XFRM]: Fix invalid key for lookup of cached bundles Message-ID: <20050307025723.GA4818@gondor.apana.org.au> References: <422AF8D0.3010905@trash.net> <20050307012458.GA4335@gondor.apana.org.au> <422BB14A.5030302@trash.net> <20050307014337.GA4451@gondor.apana.org.au> <422BB477.3040607@trash.net> <20050307015943.GA4533@gondor.apana.org.au> <422BBCC2.4010706@trash.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <422BBCC2.4010706@trash.net> User-Agent: Mutt/1.5.6+20040907i From: Herbert Xu X-Virus-Scanned: ClamAV 0.83/748/Fri Mar 4 14:19:11 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 2563 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: herbert@gondor.apana.org.au Precedence: bulk X-list: netdev Content-Length: 1225 Lines: 26 On Mon, Mar 07, 2005 at 03:30:26AM +0100, Patrick McHardy wrote: > > I agree that it is more important, but I don't see any harm in fixing > the other problem for transport mode first. Fixing the scalability > problem requires a dynamically resized hash, anything static will > lead to different scalability problems with a large number of policies. > The tos/fwmark part looks comparatively small, simply reroute all > packets based on src/dst/fwmark/predicted final tos if they differ. > But since both of this is not done yet, I think it would be better to > fix the smaller problem first. The reason I'm asking is because the places where you're most likely to use tos/fwmark is in IPsec gateways. In other words, it isn't very useful unless it works in tunnel mode. This plus the fact that the check for tunnel mode is a bit of a hack makes me think that it's not worth it at the moment. On the subject of fixing the scalability issue, we should just use the flow cache directly for each bundle. Cheers, -- Visit Openswan at http://www.openswan.org/ Email: Herbert Xu ~{PmV>HI~} Home Page: http://gondor.apana.org.au/~herbert/ PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt From kaber@trash.net Sun Mar 6 19:11:55 2005 Received: with ECARTIS (v1.0.0; list netdev); Sun, 06 Mar 2005 19:11:58 -0800 (PST) Received: from kaber.coreworks.de ([62.206.217.67]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j273Bspc031602 for ; Sun, 6 Mar 2005 19:11:55 -0800 Received: from localhost ([127.0.0.1]) by kaber.coreworks.de with esmtp (Exim 4.50) id 1D88eL-00074S-Qn; Mon, 07 Mar 2005 04:11:17 +0100 Message-ID: <422BC655.5070907@trash.net> Date: Mon, 07 Mar 2005 04:11:17 +0100 From: Patrick McHardy User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.7.5) Gecko/20050106 Debian/1.7.5-1 X-Accept-Language: en MIME-Version: 1.0 To: Herbert Xu CC: davem@davemloft.net, netdev@oss.sgi.com Subject: Re: [PATCH 3/3 XFRM]: Fix invalid key for lookup of cached bundles References: <422AF8D0.3010905@trash.net> <20050307012458.GA4335@gondor.apana.org.au> <422BB14A.5030302@trash.net> <20050307014337.GA4451@gondor.apana.org.au> <422BB477.3040607@trash.net> <20050307015943.GA4533@gondor.apana.org.au> <422BBCC2.4010706@trash.net> <20050307025723.GA4818@gondor.apana.org.au> In-Reply-To: <20050307025723.GA4818@gondor.apana.org.au> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV 0.83/748/Fri Mar 4 14:19:11 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 2564 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: kaber@trash.net Precedence: bulk X-list: netdev Content-Length: 749 Lines: 19 Herbert Xu wrote: > The reason I'm asking is because the places where you're most likely > to use tos/fwmark is in IPsec gateways. In other words, it isn't > very useful unless it works in tunnel mode. This plus the fact > that the check for tunnel mode is a bit of a hack makes me think that > it's not worth it at the moment. Ok, let's drop it for now. One of my reasons for fixing it was that it gives clearly defined behaviour, which makes it easier for me to make sure the changes I made for xfrm resolution are correct. I'm simply going to assume it will be working correctly sometime. > On the subject of fixing the scalability issue, we should just use > the flow cache directly for each bundle. Let me think about it. Regards Patrick From davem@davemloft.net Sun Mar 6 21:25:55 2005 Received: with ECARTIS (v1.0.0; list netdev); Sun, 06 Mar 2005 21:26:00 -0800 (PST) Received: from cheetah.davemloft.net (mail@dsl027-180-174.sfo1.dsl.speakeasy.net [216.27.180.174]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j275PsLH006681 for ; Sun, 6 Mar 2005 21:25:55 -0800 Received: from localhost ([127.0.0.1] helo=cheetah.davemloft.net ident=davem) by cheetah.davemloft.net with smtp (Exim 3.36 #1 (Debian)) id 1D8AiH-000051-00; Sun, 06 Mar 2005 21:23:29 -0800 Date: Sun, 6 Mar 2005 21:23:28 -0800 From: "David S. Miller" To: Herbert Xu Cc: kuznet@ms2.inr.ac.ru, jmorris@redhat.com, yoshfuji@linux-ipv6.org, netdev@oss.sgi.com Subject: Re: [2/4] [IPSEC] Add xfrm_state_mtu Message-Id: <20050306212328.1d71b8a2.davem@davemloft.net> In-Reply-To: <20050214221200.GA18465@gondor.apana.org.au> References: <20050214221006.GA18415@gondor.apana.org.au> <20050214221200.GA18465@gondor.apana.org.au> X-Mailer: Sylpheed version 1.0.1 (GTK+ 1.2.10; sparc-unknown-linux-gnu) X-Face: "_;p5u5aPsO,_Vsx"^v-pEq09'CU4&Dc1$fQExov$62l60cgCc%FnIwD=.UF^a>?5'9Kn[;433QFVV9M..2eN.@4ZWPGbdi<=?[:T>y?SD(R*-3It"Vj:)"dP Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV 0.83/748/Fri Mar 4 14:19:11 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 2565 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: davem@davemloft.net Precedence: bulk X-list: netdev Content-Length: 352 Lines: 9 On Tue, 15 Feb 2005 09:12:00 +1100 Herbert Xu wrote: > This patch introduces the function xfrm_state_mtu which calculates > the MTU under a specific SA. This function can be simplified once > we get rid all other uses of get_max_size as we can move the calculation > into the invidual SA type. Applied, thanks Herbert. From davem@davemloft.net Sun Mar 6 21:29:55 2005 Received: with ECARTIS (v1.0.0; list netdev); Sun, 06 Mar 2005 21:29:59 -0800 (PST) Received: from cheetah.davemloft.net (mail@dsl027-180-174.sfo1.dsl.speakeasy.net [216.27.180.174]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j275TtSe007208 for ; Sun, 6 Mar 2005 21:29:55 -0800 Received: from localhost ([127.0.0.1] helo=cheetah.davemloft.net ident=davem) by cheetah.davemloft.net with smtp (Exim 3.36 #1 (Debian)) id 1D8Ame-00005m-00; Sun, 06 Mar 2005 21:28:00 -0800 Date: Sun, 6 Mar 2005 21:28:00 -0800 From: "David S. Miller" To: Herbert Xu Cc: kuznet@ms2.inr.ac.ru, jmorris@redhat.com, yoshfuji@linux-ipv6.org, netdev@oss.sgi.com Subject: Re: [3/4] [IPSEC] Add route element to xfrm_dst Message-Id: <20050306212800.43d3d42e.davem@davemloft.net> In-Reply-To: <20050214221433.GB18465@gondor.apana.org.au> References: <20050214221006.GA18415@gondor.apana.org.au> <20050214221200.GA18465@gondor.apana.org.au> <20050214221433.GB18465@gondor.apana.org.au> X-Mailer: Sylpheed version 1.0.1 (GTK+ 1.2.10; sparc-unknown-linux-gnu) X-Face: "_;p5u5aPsO,_Vsx"^v-pEq09'CU4&Dc1$fQExov$62l60cgCc%FnIwD=.UF^a>?5'9Kn[;433QFVV9M..2eN.@4ZWPGbdi<=?[:T>y?SD(R*-3It"Vj:)"dP Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV 0.83/748/Fri Mar 4 14:19:11 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 2566 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: davem@davemloft.net Precedence: bulk X-list: netdev Content-Length: 513 Lines: 14 On Tue, 15 Feb 2005 09:14:33 +1100 Herbert Xu wrote: > This patch adds a pointer to the route corresponding to the specific > flow over the SA of an xfrm_dst that's being used. > > It also sets the next pointer of each xfrm_dst to the one above it. > This allows to traverse the list upwards from the bottom. Applied, thanks Herbert. I guess this back traversal list makes it impossible for us to share xfrm_dst's for multiple unique flows even if that could be possible, right? From davem@davemloft.net Sun Mar 6 21:34:11 2005 Received: with ECARTIS (v1.0.0; list netdev); Sun, 06 Mar 2005 21:34:15 -0800 (PST) Received: from cheetah.davemloft.net (mail@dsl027-180-174.sfo1.dsl.speakeasy.net [216.27.180.174]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j275YBSD007777 for ; Sun, 6 Mar 2005 21:34:11 -0800 Received: from localhost ([127.0.0.1] helo=cheetah.davemloft.net ident=davem) by cheetah.davemloft.net with smtp (Exim 3.36 #1 (Debian)) id 1D8Aqk-0000Ax-00; Sun, 06 Mar 2005 21:32:14 -0800 Date: Sun, 6 Mar 2005 21:32:14 -0800 From: "David S. Miller" To: Herbert Xu Cc: kuznet@ms2.inr.ac.ru, jmorris@redhat.com, yoshfuji@linux-ipv6.org, netdev@oss.sgi.com Subject: Re: [4/4] [IPSEC] Store MTU at each xfrm_dst Message-Id: <20050306213214.7d8a143d.davem@davemloft.net> In-Reply-To: <20050214221607.GC18465@gondor.apana.org.au> References: <20050214221006.GA18415@gondor.apana.org.au> <20050214221200.GA18465@gondor.apana.org.au> <20050214221433.GB18465@gondor.apana.org.au> <20050214221607.GC18465@gondor.apana.org.au> X-Mailer: Sylpheed version 1.0.1 (GTK+ 1.2.10; sparc-unknown-linux-gnu) X-Face: "_;p5u5aPsO,_Vsx"^v-pEq09'CU4&Dc1$fQExov$62l60cgCc%FnIwD=.UF^a>?5'9Kn[;433QFVV9M..2eN.@4ZWPGbdi<=?[:T>y?SD(R*-3It"Vj:)"dP Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV 0.83/748/Fri Mar 4 14:19:11 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 2567 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: davem@davemloft.net Precedence: bulk X-list: netdev Content-Length: 629 Lines: 22 On Tue, 15 Feb 2005 09:16:07 +1100 Herbert Xu wrote: > Finally this is the patch that sets the MTU values of each xfrm_dst > and keeps it up-to-date. > > Signed-off-by: Herbert Xu > > To recap, at this point we've obtained accurate MTU values at each > xfrm_dst. The next step would be to start using it as > dst_pmtu(xfrm_dst). Applied, but with a bug fix: + mtu = dst_pmtu(xdst->route); + if (xdst->child_mtu_cached != mtu) { + last = xdst; + xdst->route_mtu_cached = mtu; + } You obviously meant "route_mtu_cached" in the test, not child_mtu_cached. From davem@davemloft.net Sun Mar 6 21:35:30 2005 Received: with ECARTIS (v1.0.0; list netdev); Sun, 06 Mar 2005 21:35:34 -0800 (PST) Received: from cheetah.davemloft.net (mail@dsl027-180-174.sfo1.dsl.speakeasy.net [216.27.180.174]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j275ZUVX008163 for ; Sun, 6 Mar 2005 21:35:30 -0800 Received: from localhost ([127.0.0.1] helo=cheetah.davemloft.net ident=davem) by cheetah.davemloft.net with smtp (Exim 3.36 #1 (Debian)) id 1D8As1-0000D6-00; Sun, 06 Mar 2005 21:33:33 -0800 Date: Sun, 6 Mar 2005 21:33:33 -0800 From: "David S. Miller" To: Herbert Xu Cc: kuznet@ms2.inr.ac.ru, jmorris@redhat.com, yoshfuji@linux-ipv6.org, netdev@oss.sgi.com Subject: Re: [5/*] [IPSEC] Use dst_mtu in xfrm[46]_output Message-Id: <20050306213333.4e2e47e9.davem@davemloft.net> In-Reply-To: <20050216103744.GA476@gondor.apana.org.au> References: <20050214221006.GA18415@gondor.apana.org.au> <20050214221200.GA18465@gondor.apana.org.au> <20050214221433.GB18465@gondor.apana.org.au> <20050214221607.GC18465@gondor.apana.org.au> <20050216103744.GA476@gondor.apana.org.au> X-Mailer: Sylpheed version 1.0.1 (GTK+ 1.2.10; sparc-unknown-linux-gnu) X-Face: "_;p5u5aPsO,_Vsx"^v-pEq09'CU4&Dc1$fQExov$62l60cgCc%FnIwD=.UF^a>?5'9Kn[;433QFVV9M..2eN.@4ZWPGbdi<=?[:T>y?SD(R*-3It"Vj:)"dP Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV 0.83/748/Fri Mar 4 14:19:11 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 2568 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: davem@davemloft.net Precedence: bulk X-list: netdev Content-Length: 582 Lines: 16 On Wed, 16 Feb 2005 21:37:44 +1100 Herbert Xu wrote: > There was a lot of fun in laying the foundations. Now it's time > to start using it. > > This patch fixes the calculations in xfrm[46]_output so that we don't > reject properly sized packets from the TCP stack. The previous > calculation is wrong because the xfrm overhead is not constant. > > Signed-off-by: Herbert Xu > > After this I'll start cleaning stuff up. For example, tcp's > ext2_header_len and dst's path can both be removed. Looks good, applied. From davem@davemloft.net Sun Mar 6 21:37:03 2005 Received: with ECARTIS (v1.0.0; list netdev); Sun, 06 Mar 2005 21:37:07 -0800 (PST) Received: from cheetah.davemloft.net (mail@dsl027-180-174.sfo1.dsl.speakeasy.net [216.27.180.174]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j275b3dX008809 for ; Sun, 6 Mar 2005 21:37:03 -0800 Received: from localhost ([127.0.0.1] helo=cheetah.davemloft.net ident=davem) by cheetah.davemloft.net with smtp (Exim 3.36 #1 (Debian)) id 1D8AtS-0000G3-00; Sun, 06 Mar 2005 21:35:02 -0800 Date: Sun, 6 Mar 2005 21:35:02 -0800 From: "David S. Miller" To: Herbert Xu Cc: kuznet@ms2.inr.ac.ru, jmorris@redhat.com, yoshfuji@linux-ipv6.org, netdev@oss.sgi.com Subject: Re: [6/*] [IPSEC] Fix xfrm[46]_update_pmtu to update top dst Message-Id: <20050306213502.1920a99a.davem@davemloft.net> In-Reply-To: <20050216110842.GA1024@gondor.apana.org.au> References: <20050214221006.GA18415@gondor.apana.org.au> <20050214221200.GA18465@gondor.apana.org.au> <20050214221433.GB18465@gondor.apana.org.au> <20050214221607.GC18465@gondor.apana.org.au> <20050216103744.GA476@gondor.apana.org.au> <20050216110842.GA1024@gondor.apana.org.au> X-Mailer: Sylpheed version 1.0.1 (GTK+ 1.2.10; sparc-unknown-linux-gnu) X-Face: "_;p5u5aPsO,_Vsx"^v-pEq09'CU4&Dc1$fQExov$62l60cgCc%FnIwD=.UF^a>?5'9Kn[;433QFVV9M..2eN.@4ZWPGbdi<=?[:T>y?SD(R*-3It"Vj:)"dP Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV 0.83/748/Fri Mar 4 14:19:11 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 2569 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: davem@davemloft.net Precedence: bulk X-list: netdev Content-Length: 751 Lines: 20 On Wed, 16 Feb 2005 22:08:42 +1100 Herbert Xu wrote: > Let's also fix IPsec PMTU storage. When we get an MTU update for an > xfrm_dst, it should be done to the top dst, not the bottom dst. > > For example, when we get a need-to-frag message for host C behind > a our IPsec peer B, we should be updating the dst entry for C and > not B as we do now. > > I've removed the boundary checks since the same checks are done > in ipv[46]/route.c already. > > Signed-off-by: Herbert Xu Applied, thanks Herbert. Note that sometimes it is better to replace an "unnecessary as determined by me" boundary check with a BUG() instead of outright removal. That way you get to test your assertion :) From davem@davemloft.net Sun Mar 6 21:50:22 2005 Received: with ECARTIS (v1.0.0; list netdev); Sun, 06 Mar 2005 21:50:25 -0800 (PST) Received: from cheetah.davemloft.net (mail@dsl027-180-174.sfo1.dsl.speakeasy.net [216.27.180.174]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j275oL2v009572 for ; Sun, 6 Mar 2005 21:50:22 -0800 Received: from localhost ([127.0.0.1] helo=cheetah.davemloft.net ident=davem) by cheetah.davemloft.net with smtp (Exim 3.36 #1 (Debian)) id 1D8B5v-0000Ny-00; Sun, 06 Mar 2005 21:47:55 -0800 Date: Sun, 6 Mar 2005 21:47:54 -0800 From: "David S. Miller" To: Herbert Xu Cc: kuznet@ms2.inr.ac.ru, jmorris@redhat.com, yoshfuji@linux-ipv6.org, netdev@oss.sgi.com Subject: Re: [7/*] [IPSEC] Get metrics for xfrm_dst from top dst Message-Id: <20050306214754.7a1839e1.davem@davemloft.net> In-Reply-To: <20050216113836.GA1652@gondor.apana.org.au> References: <20050214221006.GA18415@gondor.apana.org.au> <20050214221200.GA18465@gondor.apana.org.au> <20050214221433.GB18465@gondor.apana.org.au> <20050214221607.GC18465@gondor.apana.org.au> <20050216103744.GA476@gondor.apana.org.au> <20050216110842.GA1024@gondor.apana.org.au> <20050216113836.GA1652@gondor.apana.org.au> X-Mailer: Sylpheed version 1.0.1 (GTK+ 1.2.10; sparc-unknown-linux-gnu) X-Face: "_;p5u5aPsO,_Vsx"^v-pEq09'CU4&Dc1$fQExov$62l60cgCc%FnIwD=.UF^a>?5'9Kn[;433QFVV9M..2eN.@4ZWPGbdi<=?[:T>y?SD(R*-3It"Vj:)"dP Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV 0.83/748/Fri Mar 4 14:19:11 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 2570 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: davem@davemloft.net Precedence: bulk X-list: netdev Content-Length: 670 Lines: 21 On Wed, 16 Feb 2005 22:38:36 +1100 Herbert Xu wrote: > For the metrics other than MTU, we should also be getting it from > the top dst as opposed to the bottom dst. With this change, the > user is able to manipulate values such as advmss for individual > hosts behind a remote IPsec gateway. > > Signed-off-by: Herbert Xu Applied, great work Herbert. This is the last patch I saw in this series. Any more stuff you have ready to apply in this area? My net-2.6 tree at: bk://kernel.bkbits.net/davem/net-2.6 has all of the patches I applied today in it. I'll push that to Linus tomorrow most likely. From sumit@elitecore.com Sun Mar 6 23:04:17 2005 Received: with ECARTIS (v1.0.0; list netdev); Sun, 06 Mar 2005 23:04:22 -0800 (PST) Received: from elitecore.com ([203.88.135.194]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j2774FUW011833 for ; Sun, 6 Mar 2005 23:04:16 -0800 Received: (qmail 4764 invoked from network); 7 Mar 2005 06:53:22 -0000 Received: from unknown (HELO elitecore.com) ([127.0.0.1]) (envelope-sender ) by elitecore.com (qmail-ldap-1.03) with SMTP for ; 7 Mar 2005 06:53:22 -0000 Received: (qmail 4752 invoked from network); 7 Mar 2005 06:53:22 -0000 Received: from unknown (HELO sumit) ([192.168.1.57])(envelope-sender )by elitecore.com (qmail-ldap-1.03) with SMTPfor ; 7 Mar 2005 06:53:22 -0000 From: "Sumit Pandya" To: "Zdenek Radouch" Cc: , Subject: RE: Do you know the TCP stack? (127.x.x.x routing) Date: Mon, 7 Mar 2005 12:31:57 +0530 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset=Windows-1252 Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.6604 (9.0.2911.0) X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6600 Importance: Normal In-Reply-To: <3sp35g$7hpm0@smtp04.mrf.mail.rcn.net> X-imss-version: 2.19 X-imss-result: Passed X-imss-scores: Clean:99.90000 C:2 M:3 S:5 R:5 X-imss-settings: Baseline:1 C:1 M:1 S:1 R:1 (0.0000 0.0000) X-Virus-Scanned: ClamAV 0.83/748/Fri Mar 4 14:19:11 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 2571 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: sumit@elitecore.com Precedence: bulk X-list: netdev Content-Length: 1368 Lines: 36 Zdenek, I don't know how much help you can get with "dummy" interface. Try to set your requirement with that special interface into mind. -- Sumit > -----Original Message----- > From: linux-net-owner@vger.kernel.org > [mailto:linux-net-owner@vger.kernel.org]On Behalf Of Zdenek Radouch > Sent: Monday, March 07, 2005 3:21 AM > > OK. We've gone a full circle, [except for a few digressions > along the lines of me not knowing that while the rest of the > world still uses 'route', under linux it has long been deprecated] > you seem to be agreeing with my original guess that > subnetting the 127 net may not be trivial, and that it may require > some kernel hacking. > > So my original questions still stand: > > 1) How could one remove the special kernel treatment of the 127 net? > [so that "lo" gets 127.0.0.1/16 and "foo" gets 127.1.0.1/16, and > so that the "foo" interface can actually receive packets? > > 2) If it does require kernel hacking, would you like to do it for me? > (as I had said, as a contract) > > > >> it won't accept outside packets with a loopback address. > > Not accepting packets with with a loopback address is one > thing, not accepting any 127.0.0.0/8 packets is entirely something else. > > Couldn't that whole 127 thing be ripped out of the kernel? > Why couldn't the "lo" interface be treated as any other interface? From yrgrknmxpzlk@gawab.com Sun Mar 6 23:13:57 2005 Received: with ECARTIS (v1.0.0; list netdev); Sun, 06 Mar 2005 23:14:02 -0800 (PST) Received: from info5 (info5.gawab.com [204.97.230.42]) by oss.sgi.com (8.13.0/8.13.0) with SMTP id j277DuoS012590 for ; Sun, 6 Mar 2005 23:13:57 -0800 Received: (qmail 31646 invoked by uid 1004); 7 Mar 2005 07:12:17 -0000 Received: from unknown (HELO yihye-beseder) (yrgrknmxpzlk@gawab.com@62.0.90.173) by gawab.com with SMTP; 7 Mar 2005 07:12:17 -0000 X-Trusted: Whitelisted From: "Stephen Biggs" To: yoshfuji@linux-ipv6.org, davem@davemloft.com, netdev@oss.sgi.com, yoshfuji@linux-ipv6.org, domen@coderock.org Date: Mon, 07 Mar 2005 09:13:42 +0200 MIME-Version: 1.0 Subject: Re: [patch 4/5] net/ipv6/ip6_flowlabel.c: copy_to_user return code Message-ID: <422C1B46.21973.35151C@localhost> Priority: normal In-reply-to: <20050307.073843.09980515.yoshfuji@linux-ipv6.org> References: <20050307.073213.32943613.yoshfuji@linux-ipv6.org> X-mailer: Pegasus Mail for Windows (4.21c) Content-type: text/plain; charset=US-ASCII Content-transfer-encoding: 7BIT Content-description: Mail message body X-Virus-Scanned: ClamAV 0.83/748/Fri Mar 4 14:19:11 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 2572 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: yrgrknmxpzlk@gawab.com Precedence: bulk X-list: netdev Content-Length: 1090 Lines: 38 Mr. Hideaki, Thank you very much (domo arigato gozaimasu) for your feedback. Please see below for my comments. On 7 Mar 2005 at 7:38, B wrote: > In article <20050307.073213.32943613.yoshfuji@linux-ipv6.org> (at Mon, 07 Mar 2005 07:32:13 +0900 (JST)), YOSHIFUJI Hideaki / $B5HF#1QL@ (B says: > > > In article <20050306222118.401D11ED3D@trashy.coderock.org> (at Sun, 06 Mar 2005 23:21:17 +0100), domen@coderock.org says: > > > > > > > > compile warning cleanup - handle copy_to/from_user error > > > returns > > > > Wrong. You introduce a leak. > > Ah, sorry, not really, Actually, you are correct. This is one of my first attempts at a patch submittal and this is one of a few patches where I did not check for side effects. I will try very much not to make that same mistake again. > but I still think it is wrong: > fl_intern() insert it to hash, and > then you freed up the memory. > I believe this is wrong. Yes, you are completely correct, and thank you for catching this. I will submit a more correct patch shortly. > > --yoshfuji > From jgarzik@pobox.com Mon Mar 7 00:00:22 2005 Received: with ECARTIS (v1.0.0; list netdev); Mon, 07 Mar 2005 00:00:27 -0800 (PST) Received: from parcelfarce.linux.theplanet.co.uk (IDENT:93@parcelfarce.linux.theplanet.co.uk [195.92.249.252]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j2780L9e014138 for ; Mon, 7 Mar 2005 00:00:21 -0800 Received: from [69.134.152.124] (helo=[10.10.10.88]) by parcelfarce.linux.theplanet.co.uk with asmtp (TLSv1:AES256-SHA:256) (Exim 4.33) id 1D8DA0-0008D5-Tk; Mon, 07 Mar 2005 08:00:17 +0000 Message-ID: <422C09FD.3000702@pobox.com> Date: Mon, 07 Mar 2005 02:59:57 -0500 From: Jeff Garzik User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.3) Gecko/20040922 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Arnaldo Carvalho de Melo , "David S. Miller" , Netdev Subject: build breakage Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV 0.83/748/Fri Mar 4 14:19:11 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 2573 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: jgarzik@pobox.com Precedence: bulk X-list: netdev Content-Length: 302 Lines: 7 Upstream net changes caused this to appear.. CC drivers/net/appletalk/cops.o In file included from drivers/net/appletalk/cops.c:70: include/linux/atalk.h:67: error: field `sk' has incomplete type make[3]: *** [drivers/net/appletalk/cops.o] Error 1 make[2]: *** [drivers/net/appletalk] Error 2 From emann@mrv.com Mon Mar 7 00:04:50 2005 Received: with ECARTIS (v1.0.0; list netdev); Mon, 07 Mar 2005 00:04:55 -0800 (PST) Received: from apollo.nbase.co.il (apollo.nbase.co.il [194.90.137.2]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j2784m2k014716 for ; Mon, 7 Mar 2005 00:04:49 -0800 Received: from [194.90.139.38] by apollo.nbase.co.il (Post.Office MTA v3.1.2 release (PO205-101c) ID# 0-44418U200L2S100) with ESMTP id AAA1266; Mon, 7 Mar 2005 10:08:50 +0200 Message-ID: <422C0B50.20500@mrv.com> Date: Mon, 07 Mar 2005 10:05:36 +0200 From: emann@mrv.com (Eran Mann) User-Agent: Mozilla Thunderbird 1.0 (X11/20041206) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Zdenek Radouch CC: Thomas Graf , Andi Kleen , Martin Mares , netdev@oss.sgi.com, linux-net@vger.kernel.org Subject: Re: Do you know the TCP stack? (127.x.x.x routing) References: <20050306173145.GQ31837@postel.suug.ch> <3sp35g$7hpm0@smtp04.mrf.mail.rcn.net> In-Reply-To: <3sp35g$7hpm0@smtp04.mrf.mail.rcn.net> Content-Type: multipart/mixed; boundary="------------040802000603020000010405" X-Virus-Scanned: ClamAV 0.83/748/Fri Mar 4 14:19:11 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 2574 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: emann@mrv.com Precedence: bulk X-list: netdev Content-Length: 2749 Lines: 72 This is a multi-part message in MIME format. --------------040802000603020000010405 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Zdenek Radouch wrote: ... > > 2) If it does require kernel hacking, would you like to do it for me? > (as I had said, as a contract) I think what Andi Kleen was talking about below is something like the attached 5 minutes patch (applies cleanly to 2.4.2x kernels I have at hand, and to 2.6.11 with minor offset). Please donate the 5 minute wages to the OSDL or the FSF at your choice ;-) ... > > Not accepting packets with with a loopback address is one > thing, not accepting any 127.0.0.0/8 packets is entirely something else. Yes, however it seems to be required by the RFC (quoting RFC 3330 "special use IPv4 addresses") : " 127.0.0.0/8 - This block is assigned for use as the Internet host loopback address. A datagram sent by a higher level protocol to an address anywhere within this block should loop back inside the host. This is ordinarily implemented using only 127.0.0.1/32 for loopback, but no addresses within this block should ever appear on any network anywhere [RFC1700, page 5]. " >>* Andi Kleen 2005-03-06 21:19 >> ... >>> >>>It is. 127.* is hardcoded in the routing engine and e.g. >>>it won't accept outside packets with a loopback address. >>> >>>Most likely it's enough to change the "LOOPBACK" macro to allow >>>parts of the Class A to be used for other purposes. ... -- Eran Mann MRV International --------------040802000603020000010405 Content-Type: text/x-patch; name="lo_hack.patch" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="lo_hack.patch" --- 2.4.27/include/linux/in.h 2004-05-28 17:15:37.000000000 +0300 +++ 2.4.27.hacked/include/linux/in.h 2005-03-07 09:53:02.000000000 +0200 @@ -226,7 +226,7 @@ /* Address to loopback in software to local host. */ #define INADDR_LOOPBACK 0x7f000001 /* 127.0.0.1 */ -#define IN_LOOPBACK(a) ((((long int) (a)) & 0xff000000) == 0x7f000000) +#define IN_LOOPBACK(a) ((((long int) (a)) & 0xffff0000) == 0x7f000000) /* Defines for Multicast INADDR */ #define INADDR_UNSPEC_GROUP 0xe0000000U /* 224.0.0.0 */ @@ -240,7 +240,7 @@ #ifdef __KERNEL__ /* Some random defines to make it easier in the kernel.. */ -#define LOOPBACK(x) (((x) & htonl(0xff000000)) == htonl(0x7f000000)) +#define LOOPBACK(x) (((x) & htonl(0xffff0000)) == htonl(0x7f000000)) #define MULTICAST(x) (((x) & htonl(0xf0000000)) == htonl(0xe0000000)) #define BADCLASS(x) (((x) & htonl(0xf0000000)) == htonl(0xf0000000)) #define ZERONET(x) (((x) & htonl(0xff000000)) == htonl(0x00000000)) --------------040802000603020000010405-- From akpm@osdl.org Mon Mar 7 01:51:10 2005 Received: with ECARTIS (v1.0.0; list netdev); Mon, 07 Mar 2005 01:51:17 -0800 (PST) Received: from smtp.osdl.org (fire.osdl.org [65.172.181.4]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j279pAt5022844 for ; Mon, 7 Mar 2005 01:51:10 -0800 Received: from shell0.pdx.osdl.net (fw.osdl.org [65.172.181.6]) by smtp.osdl.org (8.12.8/8.12.8) with ESMTP id j279oxqi003571 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO); Mon, 7 Mar 2005 01:51:00 -0800 Received: from localhost.localdomain (shell0.pdx.osdl.net [10.9.0.31]) by shell0.pdx.osdl.net (8.13.1/8.11.6) with ESMTP id j279oxDf000951; Mon, 7 Mar 2005 01:50:59 -0800 Message-Id: <200503070950.j279oxDf000951@shell0.pdx.osdl.net> Subject: [patch 1/1] atalk build fix To: davem@davemloft.net Cc: netdev@oss.sgi.com, akpm@osdl.org From: akpm@osdl.org Date: Mon, 07 Mar 2005 01:50:35 -0800 Received-SPF: pass (domain of akpm@osdl.org designates 65.172.181.6 as permitted sender) X-MIMEDefang-Filter: osdl$Revision: 1.104 $ X-Scanned-By: MIMEDefang 2.36 X-Virus-Scanned: ClamAV 0.83/748/Fri Mar 4 14:19:11 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 2575 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: akpm@osdl.org Precedence: bulk X-list: netdev Content-Length: 607 Lines: 25 In file included from drivers/net/appletalk/cops.c:70: include/linux/atalk.h:67: field `sk' has incomplete type Signed-off-by: Andrew Morton --- 25-akpm/include/linux/atalk.h | 3 +++ 1 files changed, 3 insertions(+) diff -puN include/linux/atalk.h~atalk-build-fix include/linux/atalk.h --- 25/include/linux/atalk.h~atalk-build-fix 2005-03-07 00:00:55.000000000 -0800 +++ 25-akpm/include/linux/atalk.h 2005-03-07 00:00:55.000000000 -0800 @@ -1,5 +1,8 @@ #ifndef __LINUX_ATALK_H__ #define __LINUX_ATALK_H__ + +#include + /* * AppleTalk networking structures * _ From herbert@gondor.apana.org.au Mon Mar 7 02:04:04 2005 Received: with ECARTIS (v1.0.0; list netdev); Mon, 07 Mar 2005 02:04:12 -0800 (PST) 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 j27A43jm024396 for ; Mon, 7 Mar 2005 02:04:04 -0800 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 1D8F4i-0001BV-00; Mon, 07 Mar 2005 21:02:56 +1100 Received: from herbert by gondolin.me.apana.org.au with local (Exim 3.36 #1 (Debian)) id 1D8F3y-0001s9-00; Mon, 07 Mar 2005 21:02:10 +1100 Date: Mon, 7 Mar 2005 21:02:09 +1100 To: "David S. Miller" Cc: kuznet@ms2.inr.ac.ru, jmorris@redhat.com, yoshfuji@linux-ipv6.org, netdev@oss.sgi.com Subject: Re: [3/4] [IPSEC] Add route element to xfrm_dst Message-ID: <20050307100209.GA7137@gondor.apana.org.au> References: <20050214221006.GA18415@gondor.apana.org.au> <20050214221200.GA18465@gondor.apana.org.au> <20050214221433.GB18465@gondor.apana.org.au> <20050306212800.43d3d42e.davem@davemloft.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20050306212800.43d3d42e.davem@davemloft.net> User-Agent: Mutt/1.5.6+20040907i From: Herbert Xu X-Virus-Scanned: ClamAV 0.83/748/Fri Mar 4 14:19:11 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 2576 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: herbert@gondor.apana.org.au Precedence: bulk X-list: netdev Content-Length: 682 Lines: 19 On Sun, Mar 06, 2005 at 09:28:00PM -0800, David S. Miller wrote: > > I guess this back traversal list makes it impossible for us > to share xfrm_dst's for multiple unique flows even if that > could be possible, right? I used the back traversal only because it was convenient. There is nothing fundamental about it. So if we ever implemented xdst sharing, we could easily modify the couple of functions involved to walk the bundle forward and then in reverse. Cheers, -- Visit Openswan at http://www.openswan.org/ Email: Herbert Xu ~{PmV>HI~} Home Page: http://gondor.apana.org.au/~herbert/ PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt From herbert@gondor.apana.org.au Mon Mar 7 02:17:32 2005 Received: with ECARTIS (v1.0.0; list netdev); Mon, 07 Mar 2005 02:17:39 -0800 (PST) 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 j27AHVk1025186 for ; Mon, 7 Mar 2005 02:17:32 -0800 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 1D8FIZ-0001GG-00; Mon, 07 Mar 2005 21:17:15 +1100 Received: from herbert by gondolin.me.apana.org.au with local (Exim 3.36 #1 (Debian)) id 1D8FIH-0001x9-00; Mon, 07 Mar 2005 21:16:57 +1100 Date: Mon, 7 Mar 2005 21:16:57 +1100 To: "David S. Miller" , netdev@oss.sgi.com Subject: [IPSEC] Kill redundan dst_release check in xfrm_dst_destroy Message-ID: <20050307101657.GA7486@gondor.apana.org.au> References: <20050214221006.GA18415@gondor.apana.org.au> <20050214221200.GA18465@gondor.apana.org.au> <20050214221433.GB18465@gondor.apana.org.au> Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="oyUTqETQ0mS9luUI" Content-Disposition: inline In-Reply-To: <20050214221433.GB18465@gondor.apana.org.au> User-Agent: Mutt/1.5.6+20040907i From: Herbert Xu X-Virus-Scanned: ClamAV 0.83/748/Fri Mar 4 14:19:11 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 2577 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: herbert@gondor.apana.org.au Precedence: bulk X-list: netdev Content-Length: 994 Lines: 38 --oyUTqETQ0mS9luUI Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Hi Dave: Here's a trivial patch to get rid of a redundant check that I added in patch 3/4. dst_release already checks for dst == NULL. 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 --oyUTqETQ0mS9luUI Content-Type: text/plain; charset=us-ascii Content-Disposition: attachment; filename=xfrm-8 ===== net/xfrm/xfrm_policy.c 1.69 vs edited ===== --- 1.69/net/xfrm/xfrm_policy.c 2005-03-07 16:31:30 +11:00 +++ edited/net/xfrm/xfrm_policy.c 2005-03-07 21:12:23 +11:00 @@ -1028,8 +1028,7 @@ { struct xfrm_dst *xdst = (struct xfrm_dst *)dst; - if (xdst->route) - dst_release(xdst->route); + dst_release(xdst->route); if (!dst->xfrm) return; --oyUTqETQ0mS9luUI-- From herbert@gondor.apana.org.au Mon Mar 7 02:37:10 2005 Received: with ECARTIS (v1.0.0; list netdev); Mon, 07 Mar 2005 02:37:17 -0800 (PST) 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 j27Ab85l026090 for ; Mon, 7 Mar 2005 02:37:09 -0800 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 1D8Faw-0001Pd-00; Mon, 07 Mar 2005 21:36:14 +1100 Received: from herbert by gondolin.me.apana.org.au with local (Exim 3.36 #1 (Debian)) id 1D8FaK-00022M-00; Mon, 07 Mar 2005 21:35:36 +1100 Date: Mon, 7 Mar 2005 21:35:36 +1100 To: "David S. Miller" Cc: kuznet@ms2.inr.ac.ru, jmorris@redhat.com, yoshfuji@linux-ipv6.org, netdev@oss.sgi.com Subject: [9/*] [IPSEC] Check dst validity harder in xfrm_bundle_ok Message-ID: <20050307103536.GB7137@gondor.apana.org.au> References: <20050214221006.GA18415@gondor.apana.org.au> <20050214221200.GA18465@gondor.apana.org.au> <20050214221433.GB18465@gondor.apana.org.au> <20050214221607.GC18465@gondor.apana.org.au> <20050306213214.7d8a143d.davem@davemloft.net> Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="ikeVEW9yuYc//A+q" Content-Disposition: inline In-Reply-To: <20050306213214.7d8a143d.davem@davemloft.net> User-Agent: Mutt/1.5.6+20040907i From: Herbert Xu X-Virus-Scanned: ClamAV 0.83/748/Fri Mar 4 14:19:11 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 2578 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: herbert@gondor.apana.org.au Precedence: bulk X-list: netdev Content-Length: 2369 Lines: 87 --ikeVEW9yuYc//A+q Content-Type: text/plain; charset=us-ascii Content-Disposition: inline On Sun, Mar 06, 2005 at 09:32:14PM -0800, David S. Miller wrote: > > Applied, but with a bug fix: > > + mtu = dst_pmtu(xdst->route); > + if (xdst->child_mtu_cached != mtu) { > + last = xdst; > + xdst->route_mtu_cached = mtu; > + } > > You obviously meant "route_mtu_cached" in the test, > not child_mtu_cached. Thanks for catching this. There is another bug in xfrm_bundle_ok where I forgot to check the validity of xdst->route. In fact, the check on dst->path isn't strong enough either. For IPv6 entries, dst->path->obsolete is always negative until you call ipv6_dst_check. So we really need to do that here. Here's the patch to fix those two problems. Yes I know my dst_check implementation is lame. I'll come back and fix up all the dst_check functions by moving their dst_release calls out. It proves that you were right in that IPv6 dst leak thread :) 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 --ikeVEW9yuYc//A+q Content-Type: text/plain; charset=us-ascii Content-Disposition: attachment; filename=xfrm-9 ===== include/net/dst.h 1.27 vs edited ===== --- 1.27/include/net/dst.h 2005-03-07 16:33:59 +11:00 +++ edited/include/net/dst.h 2005-03-07 21:06:13 +11:00 @@ -259,6 +259,15 @@ } } +static inline struct dst_entry *dst_check(struct dst_entry *dst, u32 cookie) +{ + dst_hold(dst); + if (dst->obsolete) + dst = dst->ops->check(dst, cookie); + dst_release(dst); + return dst; +} + extern void dst_init(void); struct flowi; ===== net/xfrm/xfrm_policy.c 1.70 vs edited ===== --- 1.70/net/xfrm/xfrm_policy.c 2005-03-07 21:17:35 +11:00 +++ edited/net/xfrm/xfrm_policy.c 2005-03-07 21:26:28 +11:00 @@ -1147,7 +1147,7 @@ struct xfrm_dst *last; u32 mtu; - if (dst->path->obsolete > 0 || + if (!dst_check(dst->path, 0) || (dst->dev && !netif_running(dst->dev))) return 0; @@ -1167,6 +1167,8 @@ xdst->child_mtu_cached = mtu; } + if (!dst_check(xdst->route, 0)) + return 0; mtu = dst_pmtu(xdst->route); if (xdst->route_mtu_cached != mtu) { last = xdst; --ikeVEW9yuYc//A+q-- From herbert@gondor.apana.org.au Mon Mar 7 02:40:02 2005 Received: with ECARTIS (v1.0.0; list netdev); Mon, 07 Mar 2005 02:40:07 -0800 (PST) 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 j27Ae0EL026636 for ; Mon, 7 Mar 2005 02:40:01 -0800 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 1D8FeA-0001Se-00; Mon, 07 Mar 2005 21:39:34 +1100 Received: from herbert by gondolin.me.apana.org.au with local (Exim 3.36 #1 (Debian)) id 1D8Fe4-00023H-00; Mon, 07 Mar 2005 21:39:28 +1100 Date: Mon, 7 Mar 2005 21:39:27 +1100 To: "David S. Miller" Cc: kuznet@ms2.inr.ac.ru, jmorris@redhat.com, yoshfuji@linux-ipv6.org, netdev@oss.sgi.com Subject: Re: [6/*] [IPSEC] Fix xfrm[46]_update_pmtu to update top dst Message-ID: <20050307103927.GA7851@gondor.apana.org.au> References: <20050214221006.GA18415@gondor.apana.org.au> <20050214221200.GA18465@gondor.apana.org.au> <20050214221433.GB18465@gondor.apana.org.au> <20050214221607.GC18465@gondor.apana.org.au> <20050216103744.GA476@gondor.apana.org.au> <20050216110842.GA1024@gondor.apana.org.au> <20050306213502.1920a99a.davem@davemloft.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20050306213502.1920a99a.davem@davemloft.net> User-Agent: Mutt/1.5.6+20040907i From: Herbert Xu X-Virus-Scanned: ClamAV 0.83/748/Fri Mar 4 14:19:11 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 2579 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: herbert@gondor.apana.org.au Precedence: bulk X-list: netdev Content-Length: 1072 Lines: 25 On Sun, Mar 06, 2005 at 09:35:02PM -0800, David S. Miller wrote: > On Wed, 16 Feb 2005 22:08:42 +1100 > Herbert Xu wrote: > > > Let's also fix IPsec PMTU storage. When we get an MTU update for an > > xfrm_dst, it should be done to the top dst, not the bottom dst. > > > > For example, when we get a need-to-frag message for host C behind > > a our IPsec peer B, we should be updating the dst entry for C and > > not B as we do now. > > > > I've removed the boundary checks since the same checks are done > > in ipv[46]/route.c already. > > Note that sometimes it is better to replace an "unnecessary as > determined by me" boundary check with a BUG() instead of > outright removal. That way you get to test your assertion :) Point taken. However, I must say that using BUG() in these two particular places would be fatal :) -- Visit Openswan at http://www.openswan.org/ Email: Herbert Xu ~{PmV>HI~} Home Page: http://gondor.apana.org.au/~herbert/ PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt From herbert@gondor.apana.org.au Mon Mar 7 02:42:42 2005 Received: with ECARTIS (v1.0.0; list netdev); Mon, 07 Mar 2005 02:42:48 -0800 (PST) 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 j27Age6J029084 for ; Mon, 7 Mar 2005 02:42:41 -0800 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 1D8FgW-0001Uq-00; Mon, 07 Mar 2005 21:42:00 +1100 Received: from herbert by gondolin.me.apana.org.au with local (Exim 3.36 #1 (Debian)) id 1D8FgF-00023o-00; Mon, 07 Mar 2005 21:41:43 +1100 Date: Mon, 7 Mar 2005 21:41:43 +1100 To: "David S. Miller" Cc: kuznet@ms2.inr.ac.ru, jmorris@redhat.com, yoshfuji@linux-ipv6.org, netdev@oss.sgi.com Subject: Re: [7/*] [IPSEC] Get metrics for xfrm_dst from top dst Message-ID: <20050307104143.GB7851@gondor.apana.org.au> References: <20050214221006.GA18415@gondor.apana.org.au> <20050214221200.GA18465@gondor.apana.org.au> <20050214221433.GB18465@gondor.apana.org.au> <20050214221607.GC18465@gondor.apana.org.au> <20050216103744.GA476@gondor.apana.org.au> <20050216110842.GA1024@gondor.apana.org.au> <20050216113836.GA1652@gondor.apana.org.au> <20050306214754.7a1839e1.davem@davemloft.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20050306214754.7a1839e1.davem@davemloft.net> User-Agent: Mutt/1.5.6+20040907i From: Herbert Xu X-Virus-Scanned: ClamAV 0.83/748/Fri Mar 4 14:19:11 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 2580 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: herbert@gondor.apana.org.au Precedence: bulk X-list: netdev Content-Length: 626 Lines: 18 On Sun, Mar 06, 2005 at 09:47:54PM -0800, David S. Miller wrote: > > This is the last patch I saw in this series. Any more stuff > you have ready to apply in this area? I've just sent you two fix-up's. I'll work on the clean-up's that I talked about next. Once that's done we can consider the first step in the MTU rework complete. The next step would be to relay ICMP information back to the sender. Cheers, -- Visit Openswan at http://www.openswan.org/ Email: Herbert Xu ~{PmV>HI~} Home Page: http://gondor.apana.org.au/~herbert/ PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt From herbert@gondor.apana.org.au Mon Mar 7 03:47:24 2005 Received: with ECARTIS (v1.0.0; list netdev); Mon, 07 Mar 2005 03:47:32 -0800 (PST) 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 j27BlLw5031477 for ; Mon, 7 Mar 2005 03:47:22 -0800 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 1D8Gge-0001of-00; Mon, 07 Mar 2005 22:46:12 +1100 Received: from herbert by gondolin.me.apana.org.au with local (Exim 3.36 #1 (Debian)) id 1D8Gg1-00039D-00; Mon, 07 Mar 2005 22:45:33 +1100 Date: Mon, 7 Mar 2005 22:45:33 +1100 To: "David S. Miller" , Alexey Kuznetsov , James Morris , YOSHIFUJI Hideaki , Patrick McHardy , netdev@oss.sgi.com Subject: [10/*] [TCP] Get rid of dst_ptmu/ext2_header_len Message-ID: <20050307114533.GA11190@gondor.apana.org.au> References: <20050214221006.GA18415@gondor.apana.org.au> <20050214221200.GA18465@gondor.apana.org.au> <20050214221433.GB18465@gondor.apana.org.au> <20050214221607.GC18465@gondor.apana.org.au> <20050216103744.GA476@gondor.apana.org.au> Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="HlL+5n6rz5pIUxbD" Content-Disposition: inline In-Reply-To: <20050216103744.GA476@gondor.apana.org.au> User-Agent: Mutt/1.5.6+20040907i From: Herbert Xu X-Virus-Scanned: ClamAV 0.83/748/Fri Mar 4 14:19:11 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 2581 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: herbert@gondor.apana.org.au Precedence: bulk X-list: netdev Content-Length: 6999 Lines: 220 --HlL+5n6rz5pIUxbD Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Hi Dave: Here is a patch that replaces all occurrences of dst_pmtu in the TCP stack. As a result we no longer need ext2_header_len. This has a nice synergetic effect with Arnaldo's latest change to linux/tcp.h :) Signed-off-by: Herbert Xu I'll be removing other users of dst->path/dst_pmtu next. 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 --HlL+5n6rz5pIUxbD Content-Type: text/plain; charset=us-ascii Content-Disposition: attachment; filename=xfrm-10 ===== include/linux/tcp.h 1.35 vs edited ===== --- 1.35/include/linux/tcp.h 2005-02-23 05:45:31 +11:00 +++ edited/include/linux/tcp.h 2005-03-07 22:41:00 +11:00 @@ -284,10 +284,13 @@ __u32 mss_cache; /* Cached effective mss, not including SACKS */ __u16 mss_cache_std; /* Like mss_cache, but without TSO */ __u16 ext_header_len; /* Network protocol overhead (IP/IPv6 options) */ - __u16 ext2_header_len;/* Options depending on route */ __u8 ca_state; /* State of fast-retransmit machine */ __u8 retransmits; /* Number of unrecovered RTO timeouts. */ + __u16 advmss; /* Advertised MSS */ + __u32 window_clamp; /* Maximal window to advertise */ + __u32 rcv_ssthresh; /* Current window clamp */ + __u32 frto_highmark; /* snd_nxt when RTO occurred */ __u8 reordering; /* Packet reordering metric. */ __u8 frto_counter; /* Number of new acks after RTO */ @@ -345,14 +348,9 @@ struct tcp_sack_block duplicate_sack[1]; /* D-SACK block */ struct tcp_sack_block selective_acks[4]; /* The SACKS themselves*/ - __u32 window_clamp; /* Maximal window to advertise */ - __u32 rcv_ssthresh; /* Current window clamp */ - __u16 advmss; /* Advertised MSS */ - __u8 syn_retries; /* num of allowed syn retries */ __u8 ecn_flags; /* ECN status bits. */ __u16 prior_ssthresh; /* ssthresh saved at recovery start */ - __u16 __pad1; __u32 lost_out; /* Lost packets */ __u32 sacked_out; /* SACK'd packets */ __u32 fackets_out; /* FACK'd packets */ ===== net/ipv4/tcp_ipv4.c 1.110 vs edited ===== --- 1.110/net/ipv4/tcp_ipv4.c 2005-02-23 14:23:09 +11:00 +++ edited/net/ipv4/tcp_ipv4.c 2005-03-07 22:02:37 +11:00 @@ -831,7 +831,6 @@ /* OK, now commit destination to socket. */ __sk_dst_set(sk, &rt->u.dst); tcp_v4_setup_caps(sk, &rt->u.dst); - tp->ext2_header_len = rt->u.dst.header_len; if (!tp->write_seq) tp->write_seq = secure_tcp_sequence_number(inet->saddr, @@ -941,10 +940,10 @@ /* Something is about to be wrong... Remember soft error * for the case, if this connection will not able to recover. */ - if (mtu < dst_pmtu(dst) && ip_dont_fragment(sk, dst)) + if (mtu < dst_mtu(dst) && ip_dont_fragment(sk, dst)) sk->sk_err_soft = EMSGSIZE; - mtu = dst_pmtu(dst); + mtu = dst_mtu(dst); if (inet->pmtudisc != IP_PMTUDISC_DONT && tp->pmtu_cookie > mtu) { @@ -1578,10 +1577,9 @@ newtp->ext_header_len = 0; if (newinet->opt) newtp->ext_header_len = newinet->opt->optlen; - newtp->ext2_header_len = dst->header_len; newinet->id = newtp->write_seq ^ jiffies; - tcp_sync_mss(newsk, dst_pmtu(dst)); + tcp_sync_mss(newsk, dst_mtu(dst)); newtp->advmss = dst_metric(dst, RTAX_ADVMSS); tcp_initialize_rcv_mss(newsk); @@ -1877,7 +1875,6 @@ __sk_dst_set(sk, &rt->u.dst); tcp_v4_setup_caps(sk, &rt->u.dst); - tcp_sk(sk)->ext2_header_len = rt->u.dst.header_len; new_saddr = rt->rt_src; @@ -1937,7 +1934,6 @@ if (!err) { __sk_dst_set(sk, &rt->u.dst); tcp_v4_setup_caps(sk, &rt->u.dst); - tcp_sk(sk)->ext2_header_len = rt->u.dst.header_len; return 0; } ===== net/ipv4/tcp_output.c 1.80 vs edited ===== --- 1.80/net/ipv4/tcp_output.c 2005-02-24 14:16:59 +11:00 +++ edited/net/ipv4/tcp_output.c 2005-03-07 22:11:07 +11:00 @@ -632,12 +632,8 @@ unsigned int tcp_sync_mss(struct sock *sk, u32 pmtu) { struct tcp_sock *tp = tcp_sk(sk); - struct dst_entry *dst = __sk_dst_get(sk); int mss_now; - if (dst && dst->ops->get_mss) - pmtu = dst->ops->get_mss(dst, pmtu); - /* Calculate base mss without TCP options: It is MMS_S - sizeof(tcphdr) of rfc1122 */ @@ -648,7 +644,7 @@ mss_now = tp->rx_opt.mss_clamp; /* Now subtract optional transport overhead */ - mss_now -= tp->ext_header_len + tp->ext2_header_len; + mss_now -= tp->ext_header_len; /* Then reserve room for full set of TCP options and 8 bytes of data */ if (mss_now < 48) @@ -684,9 +680,8 @@ mss_now = tp->mss_cache_std; if (dst) { - u32 mtu = dst_pmtu(dst); - if (mtu != tp->pmtu_cookie || - tp->ext2_header_len != dst->header_len) + u32 mtu = dst_mtu(dst); + if (mtu != tp->pmtu_cookie) mss_now = tcp_sync_mss(sk, mtu); } @@ -698,8 +693,7 @@ unsigned int large_mss, factor, limit; large_mss = 65535 - tp->af_specific->net_header_len - - tp->ext_header_len - tp->ext2_header_len - - tp->tcp_header_len; + tp->ext_header_len - tp->tcp_header_len; if (tp->max_window && large_mss > (tp->max_window>>1)) large_mss = max((tp->max_window>>1), @@ -1444,7 +1438,7 @@ if (tp->rx_opt.user_mss) tp->rx_opt.mss_clamp = tp->rx_opt.user_mss; tp->max_window = 0; - tcp_sync_mss(sk, dst_pmtu(dst)); + tcp_sync_mss(sk, dst_mtu(dst)); if (!tp->window_clamp) tp->window_clamp = dst_metric(dst, RTAX_WINDOW); ===== net/ipv6/tcp_ipv6.c 1.106 vs edited ===== --- 1.106/net/ipv6/tcp_ipv6.c 2005-02-23 14:23:09 +11:00 +++ edited/net/ipv6/tcp_ipv6.c 2005-03-07 22:02:38 +11:00 @@ -782,7 +782,6 @@ tp->ext_header_len = 0; if (np->opt) tp->ext_header_len = np->opt->opt_flen + np->opt->opt_nflen; - tp->ext2_header_len = dst->header_len; tp->rx_opt.mss_clamp = IPV6_MIN_MTU - sizeof(struct tcphdr) - sizeof(struct ipv6hdr); @@ -894,8 +893,8 @@ } else dst_hold(dst); - if (tp->pmtu_cookie > dst_pmtu(dst)) { - tcp_sync_mss(sk, dst_pmtu(dst)); + if (tp->pmtu_cookie > dst_mtu(dst)) { + tcp_sync_mss(sk, dst_mtu(dst)); tcp_simple_retransmit(sk); } /* else let the usual retransmit timer handle it */ dst_release(dst); @@ -1524,9 +1523,8 @@ if (newnp->opt) newtp->ext_header_len = newnp->opt->opt_nflen + newnp->opt->opt_flen; - newtp->ext2_header_len = dst->header_len; - tcp_sync_mss(newsk, dst_pmtu(dst)); + tcp_sync_mss(newsk, dst_mtu(dst)); newtp->advmss = dst_metric(dst, RTAX_ADVMSS); tcp_initialize_rcv_mss(newsk); @@ -1873,7 +1871,6 @@ ip6_dst_store(sk, dst, NULL); sk->sk_route_caps = dst->dev->features & ~(NETIF_F_IP_CSUM | NETIF_F_TSO); - tcp_sk(sk)->ext2_header_len = dst->header_len; } return 0; @@ -1927,7 +1924,6 @@ ip6_dst_store(sk, dst, NULL); sk->sk_route_caps = dst->dev->features & ~(NETIF_F_IP_CSUM | NETIF_F_TSO); - tcp_sk(sk)->ext2_header_len = dst->header_len; } skb->dst = dst_clone(dst); --HlL+5n6rz5pIUxbD-- From hadi@cyberus.ca Mon Mar 7 04:14:57 2005 Received: with ECARTIS (v1.0.0; list netdev); Mon, 07 Mar 2005 04:15:04 -0800 (PST) Received: from mx02.cybersurf.com (mx02.cybersurf.com [209.197.145.105]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j27CEuAK000675 for ; Mon, 7 Mar 2005 04:14:57 -0800 Received: from mail.cyberus.ca ([209.197.145.21]) by mx02.cybersurf.com with esmtp (Exim 4.30) id 1D8H8O-0003qa-4I for netdev@oss.sgi.com; Mon, 07 Mar 2005 07:14:52 -0500 Received: from [24.103.99.32] (helo=[10.0.0.9]) by mail.cyberus.ca with esmtp (Exim 4.20) id 1D8H8J-0008H4-J9; Mon, 07 Mar 2005 07:14:47 -0500 Subject: Re: Do you know the TCP stack? (127.x.x.x routing) From: jamal Reply-To: hadi@cyberus.ca To: Eran Mann Cc: Zdenek Radouch , Thomas Graf , Andi Kleen , Martin Mares , netdev@oss.sgi.com, linux-net@vger.kernel.org In-Reply-To: <422C0B50.20500@mrv.com> References: <20050306173145.GQ31837@postel.suug.ch> <3sp35g$7hpm0@smtp04.mrf.mail.rcn.net> <422C0B50.20500@mrv.com> Content-Type: text/plain Organization: jamalopolous Message-Id: <1110197684.1087.1251.camel@jzny.localdomain> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.2.2 Date: 07 Mar 2005 07:14:44 -0500 Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV 0.83/748/Fri Mar 4 14:19:11 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 2582 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: hadi@cyberus.ca Precedence: bulk X-list: netdev Content-Length: 858 Lines: 24 On Mon, 2005-03-07 at 03:05, Eran Mann wrote: > Zdenek Radouch wrote: > ... > > > > 2) If it does require kernel hacking, would you like to do it for me? > > (as I had said, as a contract) > I think what Andi Kleen was talking about below is something like the > attached 5 minutes patch (applies cleanly to 2.4.2x kernels I have at > hand, and to 2.6.11 with minor offset). Please donate the 5 minute wages > to the OSDL or the FSF at your choice ;-) That should do it. Or you can even return false in the macro always for his case - since he will never have a lo device. However, using these addresses is a BAD BAD idea. A lot of other machines will be expecting 127.x to mean something speacial. I dont think you should ask the poster for wages, he will suffer enough with ARPs etc ;-> What is so wrong with RFC198 addresses?? cheers, jamal From hadi@cyberus.ca Mon Mar 7 04:40:08 2005 Received: with ECARTIS (v1.0.0; list netdev); Mon, 07 Mar 2005 04:40:12 -0800 (PST) Received: from mx02.cybersurf.com (mx02.cybersurf.com [209.197.145.105]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j27Ce7Ft005068 for ; Mon, 7 Mar 2005 04:40:07 -0800 Received: from mail.cyberus.ca ([209.197.145.21]) by mx02.cybersurf.com with esmtp (Exim 4.30) id 1D8HWk-0000cy-JH for netdev@oss.sgi.com; Mon, 07 Mar 2005 07:40:02 -0500 Received: from [24.103.99.32] (helo=[10.0.0.9]) by mail.cyberus.ca with esmtp (Exim 4.20) id 1D8HWj-00038v-MW; Mon, 07 Mar 2005 07:40:02 -0500 Subject: Re: bridge between ppp and ethernet - 1 IP address and assign it to another host From: jamal Reply-To: hadi@cyberus.ca To: Mark Smith Cc: ahu@ds9a.nl, netdev@oss.sgi.com In-Reply-To: <20050306153108.20430b58.random@72616e646f6d20323030342d30342d31360a.nosense.org> References: <20050306153108.20430b58.random@72616e646f6d20323030342d30342d31360a.nosense.org> Content-Type: text/plain Organization: jamalopolous Message-Id: <1110199198.1094.1282.camel@jzny.localdomain> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.2.2 Date: 07 Mar 2005 07:39:59 -0500 Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV 0.83/748/Fri Mar 4 14:19:11 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 2583 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: hadi@cyberus.ca Precedence: bulk X-list: netdev Content-Length: 622 Lines: 25 I actually havent quiet figured what you guys are talking about. Did i misunderstand or is it as simple as having ethernet on one (LAN) side and ppp on other (wan) side? cheers, jamal On Sun, 2005-03-06 at 00:01, Mark Smith wrote: > Hi Ben, > > (sorry for not preserving the message thread id, I'm not subscribed to netdev) > > "What we're trying to do is a lot like building a bridge between ethernet and > ppp, but not quite." > > I've thought doing this sort of thing would be quite useful, in > particular if the Linux box could also perform firewalling on the > "bridged" traffic. > > > > Regards, > Mark. From hadi@cyberus.ca Mon Mar 7 04:48:26 2005 Received: with ECARTIS (v1.0.0; list netdev); Mon, 07 Mar 2005 04:48:34 -0800 (PST) Received: from mx02.cybersurf.com (mx02.cybersurf.com [209.197.145.105]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j27CmPLO005744 for ; Mon, 7 Mar 2005 04:48:26 -0800 Received: from mail.cyberus.ca ([209.197.145.21]) by mx02.cybersurf.com with esmtp (Exim 4.30) id 1D8Hen-0007SB-Nv for netdev@oss.sgi.com; Mon, 07 Mar 2005 07:48:21 -0500 Received: from [24.103.99.32] (helo=[10.0.0.9]) by mail.cyberus.ca with esmtp (Exim 4.20) id 1D8Hem-0004vS-4I; Mon, 07 Mar 2005 07:48:20 -0500 Subject: Re: [leo@yuriev.ru: [PATCH] ethernet-bridge: update skb->priority in case forwarded frame has VLAN-header] From: jamal Reply-To: hadi@cyberus.ca To: Ben Greear , leo@yuriev.ru Cc: Patrick McHardy , Lennert Buytenhek , shemminger@osdl.org, netdev@oss.sgi.com, leo@yuriev.ru In-Reply-To: <422A0C21.3050709@candelatech.com> References: <20050305141225.GA5180@xi.wantstofly.org> <4229D98F.9010008@trash.net> <422A0C21.3050709@candelatech.com> Content-Type: text/plain Organization: jamalopolous Message-Id: <1110199696.1094.1299.camel@jzny.localdomain> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.2.2 Date: 07 Mar 2005 07:48:16 -0500 Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV 0.83/748/Fri Mar 4 14:19:11 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 2584 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: hadi@cyberus.ca Precedence: bulk X-list: netdev Content-Length: 710 Lines: 24 On Sat, 2005-03-05 at 14:44, Ben Greear wrote: > Patrick McHardy wrote: > > Lennert Buytenhek wrote: >From looking at the patch: ------ + /* + * We map VLAN_TCI priority (0..7) to skb->priority (0..15) + * most similarly e.g. 0->0, 1->1, .., 7->7 + */ + skb->priority = (vlan_TCI >> 13) & 7; ------ This is wrong. IEEE priorities are opposite of IETF priorities (as used by skb->prio). Unless you install a prio qdisc and rewrite the priomap, you are screwed. So you should do opposite mapping, i.e something along the lines of VLAN_TCI priority (0..7) to skb->priority (15..8) i,e skb->priority = 15 - vlan_TCI; cheers, jamal From hadi@cyberus.ca Mon Mar 7 05:35:15 2005 Received: with ECARTIS (v1.0.0; list netdev); Mon, 07 Mar 2005 05:35:19 -0800 (PST) Received: from mx01.cybersurf.com (mx01.cybersurf.com [209.197.145.104]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j27DZCwk007545 for ; Mon, 7 Mar 2005 05:35:15 -0800 Received: from mail.cyberus.ca ([209.197.145.21]) by mx01.cybersurf.com with esmtp (Exim 4.30) id 1D8IO1-0007H1-DE for netdev@oss.sgi.com; Mon, 07 Mar 2005 06:35:05 -0700 Received: from [24.103.99.32] (helo=[10.0.0.9]) by mail.cyberus.ca with esmtp (Exim 4.20) id 1D8INz-0003sB-L5; Mon, 07 Mar 2005 08:35:03 -0500 Subject: Re: [RFC] neighbour tables configuration via rtnetlink From: jamal Reply-To: hadi@cyberus.ca To: Thomas Graf Cc: netdev@oss.sgi.com In-Reply-To: <20050305172257.GN31837@postel.suug.ch> References: <20050305172257.GN31837@postel.suug.ch> Content-Type: text/plain Organization: jamalopolous Message-Id: <1110202499.1094.1371.camel@jzny.localdomain> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.2.2 Date: 07 Mar 2005 08:34:59 -0500 Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV 0.83/751/Mon Mar 7 03:06:27 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 2585 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: hadi@cyberus.ca Precedence: bulk X-list: netdev Content-Length: 2919 Lines: 66 On Sat, 2005-03-05 at 12:22, Thomas Graf wrote: > Hi, > > I have need to change multiple neighbour table parameters as a atomic operation The patch overall looks ok although adventerous. What is it that requires you to change multiple parameters atomically? I cant seem to think of anything. I can see value in seeing some of these parameters in user space. Maybe. > which lead me to make it available via rtnetlink. I started with the patch > below which extends the existing RTM_*NEIGH commands by a flag NTF_TABLES > changing the context from entries to the tables itself. I regard this as quite > hacky, the alternative would be to add a new RTM operation set, i.e. > RTM_*NEIGHTBL or alike. > > It's only dumping for now but I plan to also allow modification of parameters. Some of the parameters you are dumping maybe dangerous if they are also allowed to be setable. As an example, changing a table name/id etc. I think you should review closely again what needs to be exposed. > One of the problem that arises is the fact that the interface identifier, > to differ the various parameters sets, is stored in the sysctl table which > would introduce quite a nasty depedency. > > Before I go ahead, putting more effort into it, what is our preferred > interface for network configuration? My personal preference is to make > everything available via netlink I think this is reasonable. However - it is a lot of work. I will have no issues with seeing nothing else but netlink (even for ethtool like setups). There are certain things that would require more attention than others. I was going to write a simple patch to allow setting of indev parameters via netlink but havent had time. Started it but havent had time to revisit it - if you want to take over that one as well i could pass it on to you. > with the long term plan to extend it with distributive remote configuration > protocol in userspace. Related but slightly different issues. To achieve distributed configuration you dont need netlink. The main advantage of netlink over say /proc is the ability to do async events. [Yes, I know i have been shouting for taking netlink and and sending it over the wire and mucking around with endianness flags - but after practical considerations i am having second thoughts;] > If so, > shall we continue to push everything into rtnetlink regardless of the > association to routing? The only drawback of the currently "overloaded" > rtnetlink is the rtnl semaphore which has grown into something like > the BKL for networking. I'm not aware of any performance problems or > other issues because of this except for the module loading over nfs. > Does anyone? > You need rtnetlink for anything that has "interface" relationship because for those you end up using the rtnl semaphore. So you are stuck for all the ones that somehow in their configuration the term "dev" may appear. cheers, jamal From hadi@cyberus.ca Mon Mar 7 05:55:30 2005 Received: with ECARTIS (v1.0.0; list netdev); Mon, 07 Mar 2005 05:55:38 -0800 (PST) Received: from mx03.cybersurf.com (mx03.cybersurf.com [209.197.145.106]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j27DtTHx014175 for ; Mon, 7 Mar 2005 05:55:30 -0800 Received: from mail.cyberus.ca ([209.197.145.21]) by mx03.cybersurf.com with esmtp (Exim 4.30) id 1D8Ihi-0005XI-HF for netdev@oss.sgi.com; Mon, 07 Mar 2005 08:55:26 -0500 Received: from [24.103.99.32] (helo=[10.0.0.9]) by mail.cyberus.ca with esmtp (Exim 4.20) id 1D8IhX-0006vI-Hp; Mon, 07 Mar 2005 08:55:15 -0500 Subject: Re: netif_rx packet dumping From: jamal Reply-To: hadi@cyberus.ca To: Baruch Even Cc: Stephen Hemminger , John Heffner , "David S. Miller" , rhee@eos.ncsu.edu, Yee-Ting.Li@nuim.ie, netdev@oss.sgi.com In-Reply-To: <42282098.8010506@ev-en.org> References: <20050303123811.4d934249@dxpl.pdx.osdl.net> <20050303125556.6850cfe5.davem@davemloft.net> <1109884688.1090.282.camel@jzny.localdomain> <20050303132143.7eef517c@dxpl.pdx.osdl.net> <1109885065.1098.285.camel@jzny.localdomain> <20050303133237.5d64578f.davem@davemloft.net> <20050303135416.0d6e7708@dxpl.pdx.osdl.net> <1109888811.1092.352.camel@jzny.localdomain> <20050303151606.3587394f@dxpl.pdx.osdl.net> <4227A23C.5050300@ev-en.org> <1109907956.1092.476.camel@jzny.localdomain> <42282098.8010506@ev-en.org> Content-Type: text/plain Organization: jamalopolous Message-Id: <1110203711.1088.1393.camel@jzny.localdomain> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.2.2 Date: 07 Mar 2005 08:55:11 -0500 Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV 0.83/751/Mon Mar 7 03:06:27 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 2586 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: hadi@cyberus.ca Precedence: bulk X-list: netdev Content-Length: 4495 Lines: 95 On Fri, 2005-03-04 at 03:47, Baruch Even wrote: > jamal wrote: > > Can you explain a little more? Why does the the throttling cause any > > bad behavior thats any different from the queue being full? In both > > cases, packets arriving during that transient will be dropped. > > If you have 300 packets in the queue and the throttling kicks in you now > drop ALL packets until the queue is empty, this will normally take some > time, during all of this time you are dropping all the ACKs that are > coming in, you lose SACK information and potentially you leave no packet > in flight so that the next packet will be sent only due to retransmit > timer waking up, at which point your congestion control algorithm starts > from cwnd=1. > > You can look at the report http://hamilton.ie/net/LinuxHighSpeed.pdf for > some graphs of the effects. > Always cool to see some test running across the pond. Were the processors tied to NICs? Your experiment is more than likely a single flow, correct? In other words the whole queue was infact dedicated just for your one flow - thats why you can call this queue a transient burst queue. Do you still have the data that shows how many packets were dropped during this period. Do you still have the experimental data? I am particulary interested in seeing the softnet stats as well as tcp netstats. I think your main problem was the huge amounts of SACK on the writequeue and the resultant processing i.e section 1.1 and how you resolved that. I dont see any issue in dropping ACKs, many of them even for such large windows as you have - TCPs ACKs are cummulative. It is true if you drop "large" enough amounts of ACKS, you will end up in timeouts - but large enough in your case must be in the minimal 1000 packets. And to say you dropped a 1000 packets while processing 300 means you were taking too long processing the 300. So it would be interesting to see a repeat of the test after youve resolved 1.1 but without removing the congestion code. Then what would be really interesting is to see the perfomance you get from multiple flows with and without congestion. I am not against a the benchmarky nature of the single flow and tuning for that, but we should also look at a wider scope at the effect before you handwave based on the result of one testcase. Infact i would agree with giving you a way to turn off the congestion control - and i am not sure how long we should keep it around with NAPI getting more popular.. I will prepare a simple patch. What you really need to do eventually is use NAPI not these antiquated schemes. I am also worried that since you used a non-NAPI driver, the effect of reordering necessitating the UNDO is much much higher. So if i was you i would repeat 1.2 with the fix from 1.1 as well as tying the NIC to one CPU. And it would be a good idea to present more detailed results - not just tcp windows fluctuating (you may not need them for the paper, but would be useful to see for debugging purposes other parameters). > >>the smart schemes are not going to make it that much better if > >>the hardware/software can't keep up. > > > > consider that this queue could be shared by as many as a few thousand > > unrelated TCP flows - not just one. It is also used for packets being > > forwarded. If you factor that the system has to react to protect itself > > then these schemes may make sense. The best place to do it is really in > > hardware, but the closer to the hardware as possible is the next besr > > possible spot. > > Actually the problem we had was with TCP end-system performance > problems, compared to them the router problem is more limited since it > only needs to do a lookup on a hash, tree or whatever and not a linked > list of several thousand packets. > I am not sure i followed. If you mean routers dont use linked lists you are highly mistaken. > I'd prefer avoiding an AFQ scheme in the incoming queue, if you do add > one, please make it configurable so I can disable it. The drop-tail > behaviour is good enough for me. Remember that an AFQ needs to drop > packets long before the queue is full so there will likely be more > losses involved. What i was suggesting to Stephen would probably make more sense to kick in when theres congestion. weighted windowing allows to sense things that are coming; so the idea was to more not allow new flows once the we are congested. Just Use NAPI driver and you wont have to worry about this. cheers, jamal From random@72616e646f6d20323030342d30342d31360a.nosense.org Mon Mar 7 05:56:51 2005 Received: with ECARTIS (v1.0.0; list netdev); Mon, 07 Mar 2005 05:56:57 -0800 (PST) Received: from ubu.nosense.org (166.cust13.sa.dsl.ozemail.com.au [210.84.236.166]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j27DunMi014484 for ; Mon, 7 Mar 2005 05:56:50 -0800 Received: from ubu.nosense.org (ubu.nosense.org [127.0.0.1]) by ubu.nosense.org (Postfix) with SMTP id 4947C62AAE; Tue, 8 Mar 2005 00:26:43 +1030 (CST) Date: Tue, 8 Mar 2005 00:26:43 +1030 From: Mark Smith To: hadi@cyberus.ca Cc: ahu@ds9a.nl, netdev@oss.sgi.com Subject: Re: bridge between ppp and ethernet - 1 IP address and assign it to another host Message-Id: <20050308002643.7eac84e7.random@72616e646f6d20323030342d30342d31360a.nosense.org> In-Reply-To: <1110199198.1094.1282.camel@jzny.localdomain> References: <20050306153108.20430b58.random@72616e646f6d20323030342d30342d31360a.nosense.org> <1110199198.1094.1282.camel@jzny.localdomain> X-Mailer: Sylpheed version 1.0.0beta1 (GTK+ 1.2.10; i686-pc-linux-gnu) X-Location: Adelaide, Australia Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV 0.83/751/Mon Mar 7 03:06:27 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 2587 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: random@72616e646f6d20323030342d30342d31360a.nosense.org Precedence: bulk X-list: netdev Content-Length: 4525 Lines: 105 On 07 Mar 2005 07:39:59 -0500 jamal wrote: Hi Jamal, Bert, (Bert, sorry for calling you Ben earlier, I must have got a bit distracted between seeing your name on a web page, and typing it on my email client) I'm fairly confident that broadly I'm thinking about the same way as Bert, although as I'm about to go into some detail, it might turn out we have slightly different ideas. > > I actually havent quiet figured what you guys are talking about. > Did i misunderstand or is it as simple as having ethernet on one (LAN) > side and ppp on other (wan) side? > Not quite that simple. It's sort of "half routing" / "half bridging". The Linux box terminates the PPP connection, including performing authentication and aquisition of a /32 IP address from the service providers PPP server - a typical point-to-point scenario. However, rather than considering that IP address to now be a local address on the Linux host, it is then allocated to the Windows (for e.g.) box ie. on the Window's box's ethernet interface, the IP address is assigned. One possiblity would be for the Linux box to issue the IP address to the Windows box via DHCP. The Windows box's default gateway would be remote PPP endpoint IP address, which means that the Linux box would also have to perform Proxy ARP for that remote IP address on it's windows facing ethernet interface. (I'm not sure if there would be issues with the default gateway on the Windows box not being part of the same IP subnet that the allocated IP address is, maybe that would be solved by assigning a /32 mask to the IP address on the windows box, or possibly have DHCP configure a host route on the Windows box for the default gateway, pointing out the ethernet interface, so that it ARPs for the default gateway address, which the Proxy ARP on the Linux box would receive. It would be interesting to see what the DSL modems that do this trick do on the devices sitting behind them.). Here is the path an incoming and outgoing IP packets would follow, adding in my firewalling suggestion : 1) IP packet comes in encapsulated in PPP. 2) The Linux box decapsulates it from the PPP header / trailer. 3) The Linux box performs layer 3 firewalling processing against the IP packet. 4) If the IP packet passes the firewall rules, it is then encapsulated in an ethernet frame, and sent to the Windows box. This might be achived by configuring a host route for the IP address on the Linux box, pointing directly to the ethernet interface, indicating it is directly attached. 5) The windows box does what ever it wants with the IP packet, as normal. 6) The windows box sends a IP packet back, encapsulated in the ethernet frame, via it's default gateway, which would be the Linux box Proxy ARP'ing for the IP address of the remote PPP endpoint IP address. 7) The Linux box receives the IP packet, decapsulates it, and then passes it through the layer 3 outgoing firewalling rules again. 8) If it passes those, it is then encapsulated in PPP, and off it goes. The role the Linux box would be performing would be PPP session termination, layer 3 firewalling and layer 2 style forwarding between its ethernet and PPP interfaces. Actually, what I've just described is quite similar to translational bridging eg 802.5 (Token Ring) <-> 802.3 (Ethernet), with a bit of layer 3 processing ie. the firewalling occuring during the translation between the layer 2 frame formats. The reason why it isn't quite translational bridging is that PPP doesn't really have layer 2 addresses at all, so the ethernet device can't specify a destination address in its header of the PPP remote endpoint layer 2 address, which is why the Linux box has to act as a Proxy for ARPs for the IP address of the remote end. In a TR <-> Eth translation scenario, TR and Eth use compatible IEEE MAC addresses, so the ethernet device can be fooled into believing it is talking to another ethernet device, and vice versa, with a device in between performing frame translation. pppd already supports the Proxy ARP facility, although it is commonly used to make a PPP connected remote PC appear on the local LAN where the PPPD server is located. In the above scenario, Proxy ARP would be making the remote router (ie. default getway) appear on the local LAN that the Windows PC is attached to. Hopefully that all makes sense ! If it doesn't, please ask, I'll work out another way to explain it, or go into more detail. Regards, Mark. -- The Internet's nature is peer to peer. From tgraf@suug.ch Mon Mar 7 06:26:05 2005 Received: with ECARTIS (v1.0.0; list netdev); Mon, 07 Mar 2005 06:26:08 -0800 (PST) Received: from b.mx.projectdream.org (eth0-0.arisu.projectdream.org [194.158.4.191]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j27EQ3UT030266 for ; Mon, 7 Mar 2005 06:26:04 -0800 Received: from postel.suug.ch (postel.suug.ch [195.134.158.23]) (using TLSv1 with cipher EDH-RSA-DES-CBC3-SHA (168/168 bits)) (No client certificate requested) by b.mx.projectdream.org (Postfix) with ESMTP id 7A51E84; Mon, 7 Mar 2005 15:25:40 +0100 (CET) Received: by postel.suug.ch (Postfix, from userid 10001) id 9952D1C0EA; Mon, 7 Mar 2005 15:26:22 +0100 (CET) Date: Mon, 7 Mar 2005 15:26:22 +0100 From: Thomas Graf To: jamal Cc: netdev@oss.sgi.com Subject: Re: [RFC] neighbour tables configuration via rtnetlink Message-ID: <20050307142622.GT31837@postel.suug.ch> References: <20050305172257.GN31837@postel.suug.ch> <1110202499.1094.1371.camel@jzny.localdomain> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1110202499.1094.1371.camel@jzny.localdomain> X-Virus-Scanned: ClamAV 0.83/751/Mon Mar 7 03:06:27 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 2588 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: tgraf@suug.ch Precedence: bulk X-list: netdev Content-Length: 3457 Lines: 62 * jamal <1110202499.1094.1371.camel@jzny.localdomain> 2005-03-07 08:34 > On Sat, 2005-03-05 at 12:22, Thomas Graf wrote: > The patch overall looks ok although adventerous. > What is it that requires you to change multiple parameters atomically? I > cant seem to think of anything. I can see value in seeing some of these > parameters in user space. Maybe. Mainly because we have multiple applications that modify neighbour parameters and they really have need to finish changing all parameters before another application can look at them again. I solved this with a userspace lockfile so far but this only catches applications that are aware of the lockfile. The netlink method still leaves the gap open between fetching the data and then changing it but that isn't a problem in my case and can be solved with the netlink daemon for those who care. > Some of the parameters you are dumping maybe dangerous if they are also > allowed to be setable. As an example, changing a table name/id etc. > I think you should review closely again what needs to be exposed. Sure, not all dumpable parameters will be available for modification but having them all available in userspace is definitely a good thing. > I think this is reasonable. However - it is a lot of work. I will have > no issues with seeing nothing else but netlink (even for ethtool like > setups). There are certain things that would require more attention than > others. Yes, I think so as well but I really want to avoid putting effort into it and then see it replaced with something else. I think Herbert once thought about moving some of the rtnetlink stuff into a separate family and restructuring the whole thing. Still plans there Herbert? > I was going to write a simple patch to allow setting of indev > parameters via netlink but havent had time. Started it but havent had > time to revisit it - if you want to take over that one as well i could > pass it on to you. Sure, but I won't have time to actually work on it until next week. > To achieve distributed configuration you dont need netlink. The main > advantage of netlink over say /proc is the ability to do async events. > [Yes, I know i have been shouting for taking netlink and and sending it > over the wire and mucking around with endianness flags - but after > practical considerations i am having second thoughts;] Yes I went through severeal iterations of thoughts as well but it still seems reasonable to me. My current approach sounds quite silly but seems to work out pretty well. It gets down to having libnl providing a XML input and output interface and XSLT templates to convert every block into byte order independant form and vice versa. I'm still toying around but I already managed to convert my XML thingy into other protocols (given they are at least somehow compatible in architecture). It is also quite simple to convert these requests into a human readable form such as HTML and have it placed onto a website for a operator to accept the change or to simply keep a log of what has been changed when. I'm not yet sure if it works out in the end but the goal is to reduce the work needed to support a new rtnetlink object to the existance of a XSLT stylesheet published somewhere and if possible have the XSLT processor fetch it automatically from a local or global site. Other advantages? Operators could modify the XSLT and add conditions and automatically modify change requests to their needs. From mcgrof@ruslug.rutgers.edu Mon Mar 7 09:13:10 2005 Received: with ECARTIS (v1.0.0; list netdev); Mon, 07 Mar 2005 09:13:18 -0800 (PST) Received: from ruslug.rutgers.edu (ruslug.rutgers.edu [128.6.24.131]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j27HD4nh021111 for ; Mon, 7 Mar 2005 09:13:09 -0800 Received: by ruslug.rutgers.edu (Postfix, from userid 503) id 26A68F9D94; Mon, 7 Mar 2005 12:13:04 -0500 (EST) Date: Mon, 7 Mar 2005 12:13:04 -0500 To: domen@coderock.org Cc: prism54-private@prism54.org, netdev@oss.sgi.com, nacc@us.ibm.com, janitor@sternwelten.at Subject: Re: [patch 1/3] net/islpci_dev: replace schedule_timeout() with msleep() Message-ID: <20050307171304.GR3936@ruslug.rutgers.edu> Mail-Followup-To: domen@coderock.org, prism54-private@prism54.org, netdev@oss.sgi.com, nacc@us.ibm.com, janitor@sternwelten.at References: <20050306222352.514491EC90@trashy.coderock.org> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="Er/3qITiDpnrteFh" Content-Disposition: inline In-Reply-To: <20050306222352.514491EC90@trashy.coderock.org> User-Agent: Mutt/1.3.28i X-Operating-System: 2.4.18-1-686 Organization: Rutgers University Student Linux Users Group From: mcgrof@ruslug.rutgers.edu (Luis R. Rodriguez) X-Virus-Scanned: ClamAV 0.83/751/Mon Mar 7 03:06:27 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 2590 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: mcgrof@ruslug.rutgers.edu Precedence: bulk X-list: netdev Content-Length: 1756 Lines: 63 --Er/3qITiDpnrteFh Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Patch applied to prism54 latest svn tree, thanks Luis On Sun, Mar 06, 2005 at 11:23:51PM +0100, domen@coderock.org wrote: >=20 >=20 >=20 >=20 > Use msleep() instead of schedule_timeout() > to guarantee the task delays as expected. Also set_current_state() is > inserted before schedule_timeout(). >=20 > Signed-off-by: Nishanth Aravamudan > Signed-off-by: Maximilian Attems > Signed-off-by: Domen Puncer > --- >=20 >=20 > kj-domen/drivers/net/wireless/prism54/islpci_dev.c | 3 +-- > 1 files changed, 1 insertion(+), 2 deletions(-) >=20 > diff -puN drivers/net/wireless/prism54/islpci_dev.c~msleep-drivers_net_wi= reless_prism54_islpci_dev drivers/net/wireless/prism54/islpci_dev.c > --- kj/drivers/net/wireless/prism54/islpci_dev.c~msleep-drivers_net_wirel= ess_prism54_islpci_dev 2005-03-05 16:09:30.000000000 +0100 > +++ kj-domen/drivers/net/wireless/prism54/islpci_dev.c 2005-03-05 16:09:3= 0.000000000 +0100 > @@ -438,8 +438,7 @@ prism54_bring_down(islpci_private *priv) > wmb(); > =20 > /* wait a while for the device to reset */ > - set_current_state(TASK_UNINTERRUPTIBLE); > - schedule_timeout(50*HZ/1000); > + msleep(50); > =20 > return 0; > } > _ --=20 GnuPG Key fingerprint =3D 113F B290 C6D2 0251 4D84 A34A 6ADD 4937 E20A 525E --Er/3qITiDpnrteFh Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.4 (GNU/Linux) iD8DBQFCLIufat1JN+IKUl4RAtQdAJ9bY5y7NUYwF7bVjmoQXndTSZTNnwCglaEk HBspnFcPstZax4SPtHZtg0I= =nGuK -----END PGP SIGNATURE----- --Er/3qITiDpnrteFh-- From jgarzik@pobox.com Mon Mar 7 09:11:01 2005 Received: with ECARTIS (v1.0.0; list netdev); Mon, 07 Mar 2005 09:11:25 -0800 (PST) Received: from parcelfarce.linux.theplanet.co.uk (IDENT:93@parcelfarce.linux.theplanet.co.uk [195.92.249.252]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j27HAwZc020745 for ; Mon, 7 Mar 2005 09:10:58 -0800 Received: from [69.134.152.124] (helo=[10.10.10.88]) by parcelfarce.linux.theplanet.co.uk with asmtp (TLSv1:AES256-SHA:256) (Exim 4.33) id 1D8Lko-0007zz-NX; Mon, 07 Mar 2005 17:10:57 +0000 Message-ID: <422C8B0C.60806@pobox.com> Date: Mon, 07 Mar 2005 12:10:36 -0500 From: Jeff Garzik User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.3) Gecko/20040922 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Andrew Morton , Linus Torvalds CC: Netdev , Linux Kernel Subject: [BK PATCHES] 2.6.x net driver updates Content-Type: multipart/mixed; boundary="------------010006070602020702040406" X-Virus-Scanned: ClamAV 0.83/751/Mon Mar 7 03:06:27 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 2589 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: jgarzik@pobox.com Precedence: bulk X-list: netdev Content-Length: 194429 Lines: 5083 This is a multi-part message in MIME format. --------------010006070602020702040406 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit --------------010006070602020702040406 Content-Type: text/plain; name="changelog.txt" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="changelog.txt" Please do a bk pull bk://gkernel.bkbits.net/net-drivers-2.6 This will update the following files: Documentation/networking/bonding.txt | 2101 ++++++++++++++++++++------------ drivers/net/3c59x.c | 2 drivers/net/8139too.c | 99 - drivers/net/Kconfig | 15 drivers/net/amd8111e.c | 2 drivers/net/b44.c | 2 drivers/net/b44.h | 14 drivers/net/bonding/bond_alb.c | 8 drivers/net/bonding/bond_main.c | 35 drivers/net/e100.c | 4 drivers/net/eepro100.c | 6 drivers/net/epic100.c | 2 drivers/net/ibmlana.c | 99 - drivers/net/ibmlana.h | 1 drivers/net/irda/donauboe.c | 2 drivers/net/mii.c | 63 drivers/net/natsemi.c | 2 drivers/net/ne2k-pci.c | 4 drivers/net/s2io.c | 53 drivers/net/sis900.c | 2 drivers/net/sk_mca.c | 126 - drivers/net/sk_mca.h | 19 drivers/net/smc91x.h | 19 drivers/net/sundance.c | 7 drivers/net/sungem.c | 2 drivers/net/tg3.c | 4 drivers/net/tg3.h | 14 drivers/net/tulip/tulip_core.c | 2 drivers/net/typhoon.c | 10 drivers/net/via-rhine.c | 2 drivers/net/via-velocity.c | 4 drivers/net/wireless/arlan.h | 4 drivers/net/wireless/atmel.c | 103 + drivers/net/wireless/atmel.h | 43 drivers/net/wireless/atmel_cs.c | 49 drivers/net/wireless/atmel_pci.c | 6 drivers/net/wireless/prism54/isl_38xx.c | 12 include/linux/mii.h | 20 include/linux/netdevice.h | 2 net/core/dev.c | 28 40 files changed, 1869 insertions(+), 1123 deletions(-) through these ChangeSets: : o sundance: attempt to address high irqs due to TX overflow : o wireless: Make Atmel driver use SET_NETDEV_DEV o wireless: WEXT quality cleanups + max rssi o wireless: Clean up firmware loading in : o mii: add GigE support Alexander Viro: o ibmlana part 2 (iomem annotations and isa-ectomy) o ibmlana part 1 (netdev_priv()) o sk_mca - iomem and isa-ectomy o sk_mca - netdev_priv() David T. Hollis: o Move MII-related constants from b44/tg3 drivers to linux/mii.h Jay Vosburgh: o bonding: Update/rewrite bonding.txt o bonding: Update kconfig description o bonding: change misleading warning o bonding: use wrappers to change mtu and MAC o net/core: move set MAC into separate function Jeff Garzik: o [wireless atmel] Add support LG LW2100N WLAN PCMCIA card Nishanth Aravamudan: o net/s2io: replace schedule_timeout() with msleep() Paul Mundt: o net: port smc91x to SH4-202 Microdev Pavel Machek: o Fix u32 vs. pm_message_t in network device drivers Randy Dunlap: o prism54: fix printk format warnings o (v2) arlan: remove gcc warning with CONFIG_PROC_FS=n Rene Herman: o 8139too Interframe Gap Time Stephen Hemminger: o 8139too: use netdev_priv Thomas Gleixner: o rtl8139too.c: Fix missing pci_disable_dev o rtl8139too.c: Fix missing pci_disable_dev --------------010006070602020702040406 Content-Type: text/plain; name="patch" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="patch" diff -Nru a/Documentation/networking/bonding.txt b/Documentation/networking/bonding.txt --- a/Documentation/networking/bonding.txt 2005-03-07 12:09:08 -05:00 +++ b/Documentation/networking/bonding.txt 2005-03-07 12:09:08 -05:00 @@ -1,5 +1,5 @@ - Linux Ethernet Bonding Driver mini-howto + Linux Ethernet Bonding Driver HOWTO Initial release : Thomas Davis Corrections, HA extensions : 2000/10/03-15 : @@ -9,8 +9,11 @@ - Janice Girouard - Jay Vosburgh +Reorganized and updated Feb 2005 by Jay Vosburgh + Note : ------ + The bonding driver originally came from Donald Becker's beowulf patches for kernel 2.0. It has changed quite a bit since, and the original tools from extreme-linux and beowulf sites will not work with this version of the driver. @@ -18,218 +21,190 @@ For new versions of the driver, patches for older kernels and the updated userspace tools, please follow the links at the end of this file. - Table of Contents ================= -Installation -Bond Configuration -Module Parameters -Configuring Multiple Bonds -Switch Configuration -Verifying Bond Configuration -Frequently Asked Questions -High Availability -Promiscuous Sniffing notes -8021q VLAN support -Limitations -Resources and Links - - -Installation -============ - -1) Build kernel with the bonding driver ---------------------------------------- -For the latest version of the bonding driver, use kernel 2.4.12 or above -(otherwise you will need to apply a patch). - -Configure kernel with `make menuconfig/xconfig/config', and select "Bonding -driver support" in the "Network device support" section. It is recommended -to configure the driver as module since it is currently the only way to -pass parameters to the driver and configure more than one bonding device. - -Build and install the new kernel and modules. - -2) Get and install the userspace tools --------------------------------------- -This version of the bonding driver requires updated ifenslave program. The -original one from extreme-linux and beowulf will not work. Kernels 2.4.12 -and above include the updated version of ifenslave.c in -Documentation/networking directory. For older kernels, please follow the -links at the end of this file. - -IMPORTANT!!! If you are running on Redhat 7.1 or greater, you need -to be careful because /usr/include/linux is no longer a symbolic link -to /usr/src/linux/include/linux. If you build ifenslave while this is -true, ifenslave will appear to succeed but your bond won't work. The purpose -of the -I option on the ifenslave compile line is to make sure it uses -/usr/src/linux/include/linux/if_bonding.h instead of the version from -/usr/include/linux. - -To install ifenslave.c, do: - # gcc -Wall -Wstrict-prototypes -O -I/usr/src/linux/include ifenslave.c -o ifenslave - # cp ifenslave /sbin/ifenslave +1. Bonding Driver Installation +2. Bonding Driver Options -Bond Configuration -================== +3. Configuring Bonding Devices +3.1 Configuration with sysconfig support +3.2 Configuration with initscripts support +3.3 Configuring Bonding Manually +3.4 Configuring Multiple Bonds -You will need to add at least the following line to /etc/modprobe.conf -so the bonding driver will automatically load when the bond0 interface is -configured. Refer to the modprobe.conf manual page for specific modprobe.conf -syntax details. The Module Parameters section of this document describes each -bonding driver parameter. - - alias bond0 bonding - -Use standard distribution techniques to define the bond0 network interface. For -example, on modern Red Hat distributions, create an ifcfg-bond0 file in -the /etc/sysconfig/network-scripts directory that resembles the following: +5. Querying Bonding Configuration +5.1 Bonding Configuration +5.2 Network Configuration -DEVICE=bond0 -IPADDR=192.168.1.1 -NETMASK=255.255.255.0 -NETWORK=192.168.1.0 -BROADCAST=192.168.1.255 -ONBOOT=yes -BOOTPROTO=none -USERCTL=no +6. Switch Configuration -(use appropriate values for your network above) +7. 802.1q VLAN Support -All interfaces that are part of a bond should have SLAVE and MASTER -definitions. For example, in the case of Red Hat, if you wish to make eth0 and -eth1 a part of the bonding interface bond0, their config files (ifcfg-eth0 and -ifcfg-eth1) should resemble the following: +8. Link Monitoring +8.1 ARP Monitor Operation +8.2 Configuring Multiple ARP Targets +8.3 MII Monitor Operation -DEVICE=eth0 -USERCTL=no -ONBOOT=yes -MASTER=bond0 -SLAVE=yes -BOOTPROTO=none +9. Potential Trouble Sources +9.1 Adventures in Routing +9.2 Ethernet Device Renaming +9.3 Painfully Slow Or No Failed Link Detection By Miimon -Use DEVICE=eth1 in the ifcfg-eth1 config file. If you configure a second -bonding interface (bond1), use MASTER=bond1 in the config file to make the -network interface be a slave of bond1. - -Restart the networking subsystem or just bring up the bonding device if your -administration tools allow it. Otherwise, reboot. On Red Hat distros you can -issue `ifup bond0' or `/etc/rc.d/init.d/network restart'. - -If the administration tools of your distribution do not support -master/slave notation in configuring network interfaces, you will need to -manually configure the bonding device with the following commands: - - # /sbin/ifconfig bond0 192.168.1.1 netmask 255.255.255.0 \ - broadcast 192.168.1.255 up - - # /sbin/ifenslave bond0 eth0 - # /sbin/ifenslave bond0 eth1 - -(use appropriate values for your network above) - -You can then create a script containing these commands and place it in the -appropriate rc directory. - -If you specifically need all network drivers loaded before the bonding driver, -adding the following line to modprobe.conf will cause the network driver for -eth0 and eth1 to be loaded before the bonding driver. - -install bond0 /sbin/modprobe -a eth0 eth1 && /sbin/modprobe bonding - -Be careful not to reference bond0 itself at the end of the line, or modprobe -will die in an endless recursive loop. - -If running SNMP agents, the bonding driver should be loaded before any network -drivers participating in a bond. This requirement is due to the the interface -index (ipAdEntIfIndex) being associated to the first interface found with a -given IP address. That is, there is only one ipAdEntIfIndex for each IP -address. For example, if eth0 and eth1 are slaves of bond0 and the driver for -eth0 is loaded before the bonding driver, the interface for the IP address -will be associated with the eth0 interface. This configuration is shown below, -the IP address 192.168.1.1 has an interface index of 2 which indexes to eth0 -in the ifDescr table (ifDescr.2). +10. SNMP agents - interfaces.ifTable.ifEntry.ifDescr.1 = lo - interfaces.ifTable.ifEntry.ifDescr.2 = eth0 - interfaces.ifTable.ifEntry.ifDescr.3 = eth1 - interfaces.ifTable.ifEntry.ifDescr.4 = eth2 - interfaces.ifTable.ifEntry.ifDescr.5 = eth3 - interfaces.ifTable.ifEntry.ifDescr.6 = bond0 - ip.ipAddrTable.ipAddrEntry.ipAdEntIfIndex.10.10.10.10 = 5 - ip.ipAddrTable.ipAddrEntry.ipAdEntIfIndex.192.168.1.1 = 2 - ip.ipAddrTable.ipAddrEntry.ipAdEntIfIndex.10.74.20.94 = 4 - ip.ipAddrTable.ipAddrEntry.ipAdEntIfIndex.127.0.0.1 = 1 +11. Promiscuous mode -This problem is avoided by loading the bonding driver before any network -drivers participating in a bond. Below is an example of loading the bonding -driver first, the IP address 192.168.1.1 is correctly associated with -ifDescr.2. +12. High Availability Information +12.1 High Availability in a Single Switch Topology +12.1.1 Bonding Mode Selection for Single Switch Topology +12.1.2 Link Monitoring for Single Switch Topology +12.2 High Availability in a Multiple Switch Topology +12.2.1 Bonding Mode Selection for Multiple Switch Topology +12.2.2 Link Monitoring for Multiple Switch Topology +12.3 Switch Behavior Issues for High Availability - interfaces.ifTable.ifEntry.ifDescr.1 = lo - interfaces.ifTable.ifEntry.ifDescr.2 = bond0 - interfaces.ifTable.ifEntry.ifDescr.3 = eth0 - interfaces.ifTable.ifEntry.ifDescr.4 = eth1 - interfaces.ifTable.ifEntry.ifDescr.5 = eth2 - interfaces.ifTable.ifEntry.ifDescr.6 = eth3 - ip.ipAddrTable.ipAddrEntry.ipAdEntIfIndex.10.10.10.10 = 6 - ip.ipAddrTable.ipAddrEntry.ipAdEntIfIndex.192.168.1.1 = 2 - ip.ipAddrTable.ipAddrEntry.ipAdEntIfIndex.10.74.20.94 = 5 - ip.ipAddrTable.ipAddrEntry.ipAdEntIfIndex.127.0.0.1 = 1 +13. Hardware Specific Considerations +13.1 IBM BladeCenter -While some distributions may not report the interface name in ifDescr, -the association between the IP address and IfIndex remains and SNMP -functions such as Interface_Scan_Next will report that association. +14. Frequently Asked Questions +15. Resources and Links -Module Parameters -================= -Optional parameters for the bonding driver can be supplied as command line -arguments to the insmod command. Typically, these parameters are specified in -the file /etc/modprobe.conf (see the manual page for modprobe.conf). The -available bonding driver parameters are listed below. If a parameter is not -specified the default value is used. When initially configuring a bond, it -is recommended "tail -f /var/log/messages" be run in a separate window to -watch for bonding driver error messages. - -It is critical that either the miimon or arp_interval and arp_ip_target -parameters be specified, otherwise serious network degradation will occur -during link failures. +1. Bonding Driver Installation +============================== + + Most popular distro kernels ship with the bonding driver +already available as a module and the ifenslave user level control +program installed and ready for use. If your distro does not, or you +have need to compile bonding from source (e.g., configuring and +installing a mainline kernel from kernel.org), you'll need to perform +the following steps: + +1.1 Configure and build the kernel with bonding +----------------------------------------------- + + The latest version of the bonding driver is available in the +drivers/net/bonding subdirectory of the most recent kernel source +(which is available on http://kernel.org). + + Prior to the 2.4.11 kernel, the bonding driver was maintained +largely outside the kernel tree; patches for some earlier kernels are +available on the bonding sourceforge site, although those patches are +still several years out of date. Most users will want to use either +the most recent kernel from kernel.org or whatever kernel came with +their distro. + + Configure kernel with "make menuconfig" (or "make xconfig" or +"make config"), then select "Bonding driver support" in the "Network +device support" section. It is recommended that you configure the +driver as module since it is currently the only way to pass parameters +to the driver or configure more than one bonding device. + + Build and install the new kernel and modules, then proceed to +step 2. + +1.2 Install ifenslave Control Utility +------------------------------------- + + The ifenslave user level control program is included in the +kernel source tree, in the file Documentation/networking/ifenslave.c. +It is generally recommended that you use the ifenslave that +corresponds to the kernel that you are using (either from the same +source tree or supplied with the distro), however, ifenslave +executables from older kernels should function (but features newer +than the ifenslave release are not supported). Running an ifenslave +that is newer than the kernel is not supported, and may or may not +work. + + To install ifenslave, do the following: + +# gcc -Wall -O -I/usr/src/linux/include ifenslave.c -o ifenslave +# cp ifenslave /sbin/ifenslave + + If your kernel source is not in "/usr/src/linux," then replace +"/usr/src/linux/include" in the above with the location of your kernel +source include directory. + + You may wish to back up any existing /sbin/ifenslave, or, for +testing or informal use, tag the ifenslave to the kernel version +(e.g., name the ifenslave executable /sbin/ifenslave-2.6.10). + +IMPORTANT NOTE: + + If you omit the "-I" or specify an incorrect directory, you +may end up with an ifenslave that is incompatible with the kernel +you're trying to build it for. Some distros (e.g., Red Hat from 7.1 +onwards) do not have /usr/include/linux symbolically linked to the +default kernel source include directory. + + +2. Bonding Driver Options +========================= + + Options for the bonding driver are supplied as parameters to +the bonding module at load time. They may be given as command line +arguments to the insmod or modprobe command, but are usually specified +in either the /etc/modprobe.conf configuration file, or in a +distro-specific configuration file (some of which are detailed in the +next section). + + The available bonding driver parameters are listed below. If a +parameter is not specified the default value is used. When initially +configuring a bond, it is recommended "tail -f /var/log/messages" be +run in a separate window to watch for bonding driver error messages. + + It is critical that either the miimon or arp_interval and +arp_ip_target parameters be specified, otherwise serious network +degradation will occur during link failures. Very few devices do not +support at least miimon, so there is really no reason not to use it. + + Options with textual values will accept either the text name + or, for backwards compatibility, the option value. E.g., + "mode=802.3ad" and "mode=4" set the same mode. + + The parameters are as follows: arp_interval - Specifies the ARP monitoring frequency in milli-seconds. - If ARP monitoring is used in a load-balancing mode (mode 0 or 2), the - switch should be configured in a mode that evenly distributes packets - across all links - such as round-robin. If the switch is configured to - distribute the packets in an XOR fashion, all replies from the ARP - targets will be received on the same link which could cause the other - team members to fail. ARP monitoring should not be used in conjunction - with miimon. A value of 0 disables ARP monitoring. The default value - is 0. + Specifies the ARP monitoring frequency in milli-seconds. If + ARP monitoring is used in a load-balancing mode (mode 0 or 2), + the switch should be configured in a mode that evenly + distributes packets across all links - such as round-robin. If + the switch is configured to distribute the packets in an XOR + fashion, all replies from the ARP targets will be received on + the same link which could cause the other team members to + fail. ARP monitoring should not be used in conjunction with + miimon. A value of 0 disables ARP monitoring. The default + value is 0. arp_ip_target - Specifies the ip addresses to use when arp_interval is > 0. These - are the targets of the ARP request sent to determine the health of - the link to the targets. Specify these values in ddd.ddd.ddd.ddd - format. Multiple ip adresses must be seperated by a comma. At least - one ip address needs to be given for ARP monitoring to work. The - maximum number of targets that can be specified is set at 16. + Specifies the ip addresses to use when arp_interval is > 0. + These are the targets of the ARP request sent to determine the + health of the link to the targets. Specify these values in + ddd.ddd.ddd.ddd format. Multiple ip adresses must be + seperated by a comma. At least one IP address must be given + for ARP monitoring to function. The maximum number of targets + that can be specified is 16. The default value is no IP + addresses. downdelay - Specifies the delay time in milli-seconds to disable a link after a - link failure has been detected. This should be a multiple of miimon - value, otherwise the value will be rounded. The default value is 0. + Specifies the time, in milliseconds, to wait before disabling + a slave after a link failure has been detected. This option + is only valid for the miimon link monitor. The downdelay + value should be a multiple of the miimon value; if not, it + will be rounded down to the nearest multiple. The default + value is 0. lacp_rate - Option specifying the rate in which we'll ask our link partner to - transmit LACPDU packets in 802.3ad mode. Possible values are: + Option specifying the rate in which we'll ask our link partner + to transmit LACPDU packets in 802.3ad mode. Possible values + are: slow or 0 Request partner to transmit LACPDUs every 30 seconds (default) @@ -246,69 +221,76 @@ miimon - Specifies the frequency in milli-seconds that MII link monitoring - will occur. A value of zero disables MII link monitoring. A value - of 100 is a good starting point. See High Availability section for - additional information. The default value is 0. + Specifies the frequency in milli-seconds that MII link + monitoring will occur. A value of zero disables MII link + monitoring. A value of 100 is a good starting point. The + use_carrier option, below, affects how the link state is + determined. See the High Availability section for additional + information. The default value is 0. mode Specifies one of the bonding policies. The default is - round-robin (balance-rr). Possible values are (you can use - either the text or numeric option): + balance-rr (round robin). Possible values are: balance-rr or 0 - Round-robin policy: Transmit in a sequential order - from the first available slave through the last. This - mode provides load balancing and fault tolerance. + Round-robin policy: Transmit packets in sequential + order from the first available slave through the + last. This mode provides load balancing and fault + tolerance. active-backup or 1 Active-backup policy: Only one slave in the bond is - active. A different slave becomes active if, and only - if, the active slave fails. The bond's MAC address is + active. A different slave becomes active if, and only + if, the active slave fails. The bond's MAC address is externally visible on only one port (network adapter) to avoid confusing the switch. This mode provides - fault tolerance. + fault tolerance. The primary option affects the + behavior of this mode. balance-xor or 2 XOR policy: Transmit based on [(source MAC address - XOR'd with destination MAC address) modula slave - count]. This selects the same slave for each - destination MAC address. This mode provides load + XOR'd with destination MAC address) modulo slave + count]. This selects the same slave for each + destination MAC address. This mode provides load balancing and fault tolerance. broadcast or 3 Broadcast policy: transmits everything on all slave - interfaces. This mode provides fault tolerance. + interfaces. This mode provides fault tolerance. 802.3ad or 4 - IEEE 802.3ad Dynamic link aggregation. Creates aggregation - groups that share the same speed and duplex settings. - Transmits and receives on all slaves in the active - aggregator. + IEEE 802.3ad Dynamic link aggregation. Creates + aggregation groups that share the same speed and + duplex settings. Utilizes all slaves in the active + aggregator according to the 802.3ad specification. Pre-requisites: - 1. Ethtool support in the base drivers for retrieving the - speed and duplex of each slave. + 1. Ethtool support in the base drivers for retrieving + the speed and duplex of each slave. 2. A switch that supports IEEE 802.3ad Dynamic link aggregation. + Most switches will require some type of configuration + to enable 802.3ad mode. + balance-tlb or 5 - Adaptive transmit load balancing: channel bonding that does - not require any special switch support. The outgoing - traffic is distributed according to the current load - (computed relative to the speed) on each slave. Incoming - traffic is received by the current slave. If the receiving - slave fails, another slave takes over the MAC address of - the failed receiving slave. + Adaptive transmit load balancing: channel bonding that + does not require any special switch support. The + outgoing traffic is distributed according to the + current load (computed relative to the speed) on each + slave. Incoming traffic is received by the current + slave. If the receiving slave fails, another slave + takes over the MAC address of the failed receiving + slave. Prerequisite: @@ -317,205 +299,452 @@ balance-alb or 6 - Adaptive load balancing: includes balance-tlb + receive - load balancing (rlb) for IPV4 traffic and does not require - any special switch support. The receive load balancing is - achieved by ARP negotiation. The bonding driver intercepts - the ARP Replies sent by the server on their way out and - overwrites the src hw address with the unique hw address of - one of the slaves in the bond such that different clients - use different hw addresses for the server. - - Receive traffic from connections created by the server is - also balanced. When the server sends an ARP Request the - bonding driver copies and saves the client's IP information - from the ARP. When the ARP Reply arrives from the client, - its hw address is retrieved and the bonding driver - initiates an ARP reply to this client assigning it to one - of the slaves in the bond. A problematic outcome of using - ARP negotiation for balancing is that each time that an ARP - request is broadcasted it uses the hw address of the - bond. Hence, clients learn the hw address of the bond and - the balancing of receive traffic collapses to the current - salve. This is handled by sending updates (ARP Replies) to - all the clients with their assigned hw address such that - the traffic is redistributed. Receive traffic is also - redistributed when a new slave is added to the bond and - when an inactive slave is re-activated. The receive load is - distributed sequentially (round robin) among the group of - highest speed slaves in the bond. - - When a link is reconnected or a new slave joins the bond - the receive traffic is redistributed among all active - slaves in the bond by intiating ARP Replies with the - selected mac address to each of the clients. The updelay - modeprobe parameter must be set to a value equal or greater - than the switch's forwarding delay so that the ARP Replies - sent to the clients will not be blocked by the switch. + Adaptive load balancing: includes balance-tlb plus + receive load balancing (rlb) for IPV4 traffic, and + does not require any special switch support. The + receive load balancing is achieved by ARP negotiation. + The bonding driver intercepts the ARP Replies sent by + the local system on their way out and overwrites the + source hardware address with the unique hardware + address of one of the slaves in the bond such that + different peers use different hardware addresses for + the server. + + Receive traffic from connections created by the server + is also balanced. When the local system sends an ARP + Request the bonding driver copies and saves the peer's + IP information from the ARP packet. When the ARP + Reply arrives from the peer, its hardware address is + retrieved and the bonding driver initiates an ARP + reply to this peer assigning it to one of the slaves + in the bond. A problematic outcome of using ARP + negotiation for balancing is that each time that an + ARP request is broadcast it uses the hardware address + of the bond. Hence, peers learn the hardware address + of the bond and the balancing of receive traffic + collapses to the current slave. This is handled by + sending updates (ARP Replies) to all the peers with + their individually assigned hardware address such that + the traffic is redistributed. Receive traffic is also + redistributed when a new slave is added to the bond + and when an inactive slave is re-activated. The + receive load is distributed sequentially (round robin) + among the group of highest speed slaves in the bond. + + When a link is reconnected or a new slave joins the + bond the receive traffic is redistributed among all + active slaves in the bond by intiating ARP Replies + with the selected mac address to each of the + clients. The updelay parameter (detailed below) must + be set to a value equal or greater than the switch's + forwarding delay so that the ARP Replies sent to the + peers will not be blocked by the switch. Prerequisites: - 1. Ethtool support in the base drivers for retrieving the - speed of each slave. + 1. Ethtool support in the base drivers for retrieving + the speed of each slave. - 2. Base driver support for setting the hw address of a - device also when it is open. This is required so that there - will always be one slave in the team using the bond hw - address (the curr_active_slave) while having a unique hw - address for each slave in the bond. If the curr_active_slave - fails it's hw address is swapped with the new curr_active_slave - that was chosen. + 2. Base driver support for setting the hardware + address of a device while it is open. This is + required so that there will always be one slave in the + team using the bond hardware address (the + curr_active_slave) while having a unique hardware + address for each slave in the bond. If the + curr_active_slave fails its hardware address is + swapped with the new curr_active_slave that was + chosen. primary - A string (eth0, eth2, etc) to equate to a primary device. If this - value is entered, and the device is on-line, it will be used first - as the output media. Only when this device is off-line, will - alternate devices be used. Otherwise, once a failover is detected - and a new default output is chosen, it will remain the output media - until it too fails. This is useful when one slave was preferred - over another, i.e. when one slave is 1000Mbps and another is - 100Mbps. If the 1000Mbps slave fails and is later restored, it may - be preferred the faster slave gracefully become the active slave - - without deliberately failing the 100Mbps slave. Specifying a - primary is only valid in active-backup mode. + A string (eth0, eth2, etc) specifying which slave is the + primary device. The specified device will always be the + active slave while it is available. Only when the primary is + off-line will alternate devices be used. This is useful when + one slave is preferred over another, e.g., when one slave has + higher throughput than another. + + The primary option is only valid for active-backup mode. updelay - Specifies the delay time in milli-seconds to enable a link after a - link up status has been detected. This should be a multiple of miimon - value, otherwise the value will be rounded. The default value is 0. + Specifies the time, in milliseconds, to wait before enabling a + slave after a link recovery has been detected. This option is + only valid for the miimon link monitor. The updelay value + should be a multiple of the miimon value; if not, it will be + rounded down to the nearest multiple. The default value is 0. use_carrier - Specifies whether or not miimon should use MII or ETHTOOL - ioctls vs. netif_carrier_ok() to determine the link status. - The MII or ETHTOOL ioctls are less efficient and utilize a - deprecated calling sequence within the kernel. The - netif_carrier_ok() relies on the device driver to maintain its - state with netif_carrier_on/off; at this writing, most, but - not all, device drivers support this facility. - - If bonding insists that the link is up when it should not be, - it may be that your network device driver does not support - netif_carrier_on/off. This is because the default state for - netif_carrier is "carrier on." In this case, disabling - use_carrier will cause bonding to revert to the MII / ETHTOOL - ioctl method to determine the link state. - - A value of 1 enables the use of netif_carrier_ok(), a value of - 0 will use the deprecated MII / ETHTOOL ioctls. The default - value is 1. - - -Configuring Multiple Bonds -========================== - -If several bonding interfaces are required, either specify the max_bonds -parameter (described above), or load the driver multiple times. Using -the max_bonds parameter is less complicated, but has the limitation that -all bonding instances created will have the same options. Loading the -driver multiple times allows each instance of the driver to have differing -options. - -For example, to configure two bonding interfaces, one with mii link -monitoring performed every 100 milliseconds, and one with ARP link -monitoring performed every 200 milliseconds, the /etc/conf.modules should -resemble the following: + Specifies whether or not miimon should use MII or ETHTOOL + ioctls vs. netif_carrier_ok() to determine the link + status. The MII or ETHTOOL ioctls are less efficient and + utilize a deprecated calling sequence within the kernel. The + netif_carrier_ok() relies on the device driver to maintain its + state with netif_carrier_on/off; at this writing, most, but + not all, device drivers support this facility. + + If bonding insists that the link is up when it should not be, + it may be that your network device driver does not support + netif_carrier_on/off. The default state for netif_carrier is + "carrier on," so if a driver does not support netif_carrier, + it will appear as if the link is always up. In this case, + setting use_carrier to 0 will cause bonding to revert to the + MII / ETHTOOL ioctl method to determine the link state. + + A value of 1 enables the use of netif_carrier_ok(), a value of + 0 will use the deprecated MII / ETHTOOL ioctls. The default + value is 1. + + + +3. Configuring Bonding Devices +============================== + + There are, essentially, two methods for configuring bonding: +with support from the distro's network initialization scripts, and +without. Distros generally use one of two packages for the network +initialization scripts: initscripts or sysconfig. Recent versions of +these packages have support for bonding, while older versions do not. + + We will first describe the options for configuring bonding for +distros using versions of initscripts and sysconfig with full or +partial support for bonding, then provide information on enabling +bonding without support from the network initialization scripts (i.e., +older versions of initscripts or sysconfig). + + If you're unsure whether your distro uses sysconfig or +initscripts, or don't know if it's new enough, have no fear. +Determining this is fairly straightforward. + + First, issue the command: + +$ rpm -qf /sbin/ifup + + It will respond with a line of text starting with either +"initscripts" or "sysconfig," followed by some numbers. This is the +package that provides your network initialization scripts. + + Next, to determine if your installation supports bonding, +issue the command: + +$ grep ifenslave /sbin/ifup + + If this returns any matches, then your initscripts or +sysconfig has support for bonding. + +3.1 Configuration with sysconfig support +---------------------------------------- + + This section applies to distros using a version of sysconfig +with bonding support, for example, SuSE Linux Enterprise Server 9. + + SuSE SLES 9's networking configuration system does support +bonding, however, at this writing, the YaST system configuration +frontend does not provide any means to work with bonding devices. +Bonding devices can be managed by hand, however, as follows. + + First, if they have not already been configured, configure the +slave devices. On SLES 9, this is most easily done by running the +yast2 sysconfig configuration utility. The goal is for to create an +ifcfg-id file for each slave device. The simplest way to accomplish +this is to configure the devices for DHCP. The name of the +configuration file for each device will be of the form: + +ifcfg-id-xx:xx:xx:xx:xx:xx + + Where the "xx" portion will be replaced with the digits from +the device's permanent MAC address. + + Once the set of ifcfg-id-xx:xx:xx:xx:xx:xx files has been +created, it is necessary to edit the configuration files for the slave +devices (the MAC addresses correspond to those of the slave devices). +Before editing, the file will contain muliple lines, and will look +something like this: + +BOOTPROTO='dhcp' +STARTMODE='on' +USERCTL='no' +UNIQUE='XNzu.WeZGOGF+4wE' +_nm_name='bus-pci-0001:61:01.0' + + Change the BOOTPROTO and STARTMODE lines to the following: + +BOOTPROTO='none' +STARTMODE='off' + + Do not alter the UNIQUE or _nm_name lines. Remove any other +lines (USERCTL, etc). + + Once the ifcfg-id-xx:xx:xx:xx:xx:xx files have been modified, +it's time to create the configuration file for the bonding device +itself. This file is named ifcfg-bondX, where X is the number of the +bonding device to create, starting at 0. The first such file is +ifcfg-bond0, the second is ifcfg-bond1, and so on. The sysconfig +network configuration system will correctly start multiple instances +of bonding. + + The contents of the ifcfg-bondX file is as follows: + +BOOTPROTO="static" +BROADCAST="10.0.2.255" +IPADDR="10.0.2.10" +NETMASK="255.255.0.0" +NETWORK="10.0.2.0" +REMOTE_IPADDR="" +STARTMODE="onboot" +BONDING_MASTER="yes" +BONDING_MODULE_OPTS="mode=active-backup miimon=100" +BONDING_SLAVE0="eth0" +BONDING_SLAVE1="eth1" + + Replace the sample BROADCAST, IPADDR, NETMASK and NETWORK +values with the appropriate values for your network. + + Note that configuring the bonding device with BOOTPROTO='dhcp' +does not work; the scripts attempt to obtain the device address from +DHCP prior to adding any of the slave devices. Without active slaves, +the DHCP requests are not sent to the network. + + The STARTMODE specifies when the device is brought online. +The possible values are: + + onboot: The device is started at boot time. If you're not + sure, this is probably what you want. + + manual: The device is started only when ifup is called + manually. Bonding devices may be configured this + way if you do not wish them to start automatically + at boot for some reason. + + hotplug: The device is started by a hotplug event. This is not + a valid choice for a bonding device. + + off or ignore: The device configuration is ignored. + + The line BONDING_MASTER='yes' indicates that the device is a +bonding master device. The only useful value is "yes." + + The contents of BONDING_MODULE_OPTS are supplied to the +instance of the bonding module for this device. Specify the options +for the bonding mode, link monitoring, and so on here. Do not include +the max_bonds bonding parameter; this will confuse the configuration +system if you have multiple bonding devices. + + Finally, supply one BONDING_SLAVEn="ethX" for each slave, +where "n" is an increasing value, one for each slave, and "ethX" is +the name of the slave device (eth0, eth1, etc). + + When all configuration files have been modified or created, +networking must be restarted for the configuration changes to take +effect. This can be accomplished via the following: + +# /etc/init.d/network restart + + Note that the network control script (/sbin/ifdown) will +remove the bonding module as part of the network shutdown processing, +so it is not necessary to remove the module by hand if, e.g., the +module paramters have changed. + + Also, at this writing, YaST/YaST2 will not manage bonding +devices (they do not show bonding interfaces on its list of network +devices). It is necessary to edit the configuration file by hand to +change the bonding configuration. + + Additional general options and details of the ifcfg file +format can be found in an example ifcfg template file: + +/etc/sysconfig/network/ifcfg.template + + Note that the template does not document the various BONDING_ +settings described above, but does describe many of the other options. + +3.2 Configuration with initscripts support +------------------------------------------ + + This section applies to distros using a version of initscripts +with bonding support, for example, Red Hat Linux 9 or Red Hat +Enterprise Linux version 3. On these systems, the network +initialization scripts have some knowledge of bonding, and can be +configured to control bonding devices. + + These distros will not automatically load the network adapter +driver unless the ethX device is configured with an IP address. +Because of this constraint, users must manually configure a +network-script file for all physical adapters that will be members of +a bondX link. Network script files are located in the directory: + +/etc/sysconfig/network-scripts + + The file name must be prefixed with "ifcfg-eth" and suffixed +with the adapter's physical adapter number. For example, the script +for eth0 would be named /etc/sysconfig/network-scripts/ifcfg-eth0. +Place the following text in the file: -alias bond0 bonding -alias bond1 bonding +DEVICE=eth0 +USERCTL=no +ONBOOT=yes +MASTER=bond0 +SLAVE=yes +BOOTPROTO=none -options bond0 miimon=100 -options bond1 -o bonding1 arp_interval=200 arp_ip_target=10.0.0.1 + The DEVICE= line will be different for every ethX device and +must correspond with the name of the file, i.e., ifcfg-eth1 must have +a device line of DEVICE=eth1. The setting of the MASTER= line will +also depend on the final bonding interface name chosen for your bond. +As with other network devices, these typically start at 0, and go up +one for each device, i.e., the first bonding instance is bond0, the +second is bond1, and so on. + + Next, create a bond network script. The file name for this +script will be /etc/sysconfig/network-scripts/ifcfg-bondX where X is +the number of the bond. For bond0 the file is named "ifcfg-bond0", +for bond1 it is named "ifcfg-bond1", and so on. Within that file, +place the following text: -Configuring Multiple ARP Targets -================================ +DEVICE=bond0 +IPADDR=192.168.1.1 +NETMASK=255.255.255.0 +NETWORK=192.168.1.0 +BROADCAST=192.168.1.255 +ONBOOT=yes +BOOTPROTO=none +USERCTL=no -While ARP monitoring can be done with just one target, it can be useful -in a High Availability setup to have several targets to monitor. In the -case of just one target, the target itself may go down or have a problem -making it unresponsive to ARP requests. Having an additional target (or -several) increases the reliability of the ARP monitoring. + Be sure to change the networking specific lines (IPADDR, +NETMASK, NETWORK and BROADCAST) to match your network configuration. -Multiple ARP targets must be seperated by commas as follows: + Finally, it is necessary to edit /etc/modules.conf to load the +bonding module when the bond0 interface is brought up. The following +sample lines in /etc/modules.conf will load the bonding module, and +select its options: -# example options for ARP monitoring with three targets alias bond0 bonding -options bond0 arp_interval=60 arp_ip_target=192.168.0.1,192.168.0.3,192.168.0.9 +options bond0 mode=balance-alb miimon=100 -For just a single target the options would resemble: + Replace the sample parameters with the appropriate set of +options for your configuration. -# example options for ARP monitoring with one target + Finally run "/etc/rc.d/init.d/network restart" as root. This +will restart the networking subsystem and your bond link should be now +up and running. + + +3.3 Configuring Bonding Manually +-------------------------------- + + This section applies to distros whose network initialization +scripts (the sysconfig or initscripts package) do not have specific +knowledge of bonding. One such distro is SuSE Linux Enterprise Server +version 8. + + The general methodology for these systems is to place the +bonding module parameters into /etc/modprobe.conf, then add modprobe +and/or ifenslave commands to the system's global init script. The +name of the global init script differs; for sysconfig, it is +/etc/init.d/boot.local and for initscripts it is /etc/rc.d/rc.local. + + For example, if you wanted to make a simple bond of two e100 +devices (presumed to be eth0 and eth1), and have it persist across +reboots, edit the appropriate file (/etc/init.d/boot.local or +/etc/rc.d/rc.local), and add the following: + +modprobe bonding -obond0 mode=balance-alb miimon=100 +modprobe e100 +ifconfig bond0 192.168.1.1 netmask 255.255.255.0 up +ifenslave bond0 eth0 +ifenslave bond0 eth1 + + Replace the example bonding module parameters and bond0 +network configuration (IP address, netmask, etc) with the appropriate +values for your configuration. The above example loads the bonding +module with the name "bond0," this simplifies the naming if multiple +bonding modules are loaded (each successive instance of the module is +given a different name, and the module instance names match the +bonding interface names). + + Unfortunately, this method will not provide support for the +ifup and ifdown scripts on the bond devices. To reload the bonding +configuration, it is necessary to run the initialization script, e.g., + +# /etc/init.d/boot.local + + or + +# /etc/rc.d/rc.local + + It may be desirable in such a case to create a separate script +which only initializes the bonding configuration, then call that +separate script from within boot.local. This allows for bonding to be +enabled without re-running the entire global init script. + + To shut down the bonding devices, it is necessary to first +mark the bonding device itself as being down, then remove the +appropriate device driver modules. For our example above, you can do +the following: + +# ifconfig bond0 down +# rmmod bond0 +# rmmod e100 + + Again, for convenience, it may be desirable to create a script +with these commands. + + +3.4 Configuring Multiple Bonds +------------------------------ + + This section contains information on configuring multiple +bonding devices with differing options. If you require multiple +bonding devices, but all with the same options, see the "max_bonds" +module paramter, documented above. + + To create multiple bonding devices with differing options, it +is necessary to load the bonding driver multiple times. Note that +current versions of the sysconfig network initialization scripts +handle this automatically; if your distro uses these scripts, no +special action is needed. See the section Configuring Bonding +Devices, above, if you're not sure about your network initialization +scripts. + + To load multiple instances of the module, it is necessary to +specify a different name for each instance (the module loading system +requires that every loaded module, even multiple instances of the same +module, have a unique name). This is accomplished by supplying +multiple sets of bonding options in /etc/modprobe.conf, for example: + alias bond0 bonding -options bond0 arp_interval=60 arp_ip_target=192.168.0.100 - -Potential Problems When Using ARP Monitor -========================================= +options bond0 -o bond0 mode=balance-rr miimon=100 -1. Driver support - -The ARP monitor relies on the network device driver to maintain two -statistics: the last receive time (dev->last_rx), and the last -transmit time (dev->trans_start). If the network device driver does -not update one or both of these, then the typical result will be that, -upon startup, all links in the bond will immediately be declared down, -and remain that way. A network monitoring tool (tcpdump, e.g.) will -show ARP requests and replies being sent and received on the bonding -device. - -The possible resolutions for this are to (a) fix the device driver, or -(b) discontinue the ARP monitor (using miimon as an alternative, for -example). - -2. Adventures in Routing - -When bonding is set up with the ARP monitor, it is important that the -slave devices not have routes that supercede routes of the master (or, -generally, not have routes at all). For example, suppose the bonding -device bond0 has two slaves, eth0 and eth1, and the routing table is -as follows: - -Kernel IP routing table -Destination Gateway Genmask Flags MSS Window irtt Iface -10.0.0.0 0.0.0.0 255.255.0.0 U 40 0 0 eth0 -10.0.0.0 0.0.0.0 255.255.0.0 U 40 0 0 eth1 -10.0.0.0 0.0.0.0 255.255.0.0 U 40 0 0 bond0 -127.0.0.0 0.0.0.0 255.0.0.0 U 40 0 0 lo +alias bond1 bonding +options bond1 -o bond1 mode=balance-alb miimon=50 -In this case, the ARP monitor (and ARP itself) may become confused, -because ARP requests will be sent on one interface (bond0), but the -corresponding reply will arrive on a different interface (eth0). This -reply looks to ARP as an unsolicited ARP reply (because ARP matches -replies on an interface basis), and is discarded. This will likely -still update the receive/transmit times in the driver, but will lose -packets. - -The resolution here is simply to insure that slaves do not have routes -of their own, and if for some reason they must, those routes do not -supercede routes of their master. This should generally be the case, -but unusual configurations or errant manual or automatic static route -additions may cause trouble. + will load the bonding module two times. The first instance is +named "bond0" and creates the bond0 device in balance-rr mode with an +miimon of 100. The second instance is named "bond1" and creates the +bond1 device in balance-alb mode with an miimon of 50. -Switch Configuration -==================== + This may be repeated any number of times, specifying a new and +unique name in place of bond0 or bond1 for each instance. -While the switch does not need to be configured when the active-backup, -balance-tlb or balance-alb policies (mode=1,5,6) are used, it does need to -be configured for the round-robin, XOR, broadcast, or 802.3ad policies -(mode=0,2,3,4). + When the appropriate module paramters are in place, then +configure bonding according to the instructions for your distro. +5. Querying Bonding Configuration +================================= -Verifying Bond Configuration -============================ +5.1 Bonding Configuration +------------------------- -1) Bonding information files ----------------------------- -The bonding driver information files reside in the /proc/net/bonding directory. + Each bonding device has a read-only file residing in the +/proc/net/bonding directory. The file contents include information +about the bonding configuration, options and state of each slave. -Sample contents of /proc/net/bonding/bond0 after the driver is loaded with -parameters of mode=0 and miimon=1000 is shown below. + For example, the contents of /proc/net/bonding/bond0 after the +driver is loaded with parameters of mode=0 and miimon=1000 is +generally as follows: + Ethernet Channel Bonding Driver: 2.6.1 (October 29, 2004) Bonding Mode: load balancing (round-robin) Currently Active Slave: eth0 MII Status: up @@ -531,15 +760,23 @@ MII Status: up Link Failure Count: 1 -2) Network verification ------------------------ -The network configuration can be verified using the ifconfig command. In -the example below, the bond0 interface is the master (MASTER) while eth0 and -eth1 are slaves (SLAVE). Notice all slaves of bond0 have the same MAC address -(HWaddr) as bond0 for all modes except TLB and ALB that require a unique MAC -address for each slave. + The precise format and contents will change depending upon the +bonding configuration, state, and version of the bonding driver. + +5.2 Network configuration +------------------------- + + The network configuration can be inspected using the ifconfig +command. Bonding devices will have the MASTER flag set; Bonding slave +devices will have the SLAVE flag set. The ifconfig output does not +contain information on which slaves are associated with which masters. + + In the example below, the bond0 interface is the master +(MASTER) while eth0 and eth1 are slaves (SLAVE). Notice all slaves of +bond0 have the same MAC address (HWaddr) as bond0 for all modes except +TLB and ALB that require a unique MAC address for each slave. -[root]# /sbin/ifconfig +# /sbin/ifconfig bond0 Link encap:Ethernet HWaddr 00:C0:F0:1F:37:B4 inet addr:XXX.XXX.XXX.YYY Bcast:XXX.XXX.XXX.255 Mask:255.255.252.0 UP BROADCAST RUNNING MASTER MULTICAST MTU:1500 Metric:1 @@ -563,430 +800,819 @@ collisions:0 txqueuelen:100 Interrupt:9 Base address:0x1400 +6. Switch Configuration +======================= -Frequently Asked Questions -========================== + For this section, "switch" refers to whatever system the +bonded devices are directly connected to (i.e., where the other end of +the cable plugs into). This may be an actual dedicated switch device, +or it may be another regular system (e.g., another computer running +Linux), + + The active-backup, balance-tlb and balance-alb modes do not +require any specific configuration of the switch. + + The 802.3ad mode requires that the switch have the appropriate +ports configured as an 802.3ad aggregation. The precise method used +to configure this varies from switch to switch, but, for example, a +Cisco 3550 series switch requires that the appropriate ports first be +grouped together in a single etherchannel instance, then that +etherchannel is set to mode "lacp" to enable 802.3ad (instead of +standard EtherChannel). + + The balance-rr, balance-xor and broadcast modes generally +require that the switch have the appropriate ports grouped together. +The nomenclature for such a group differs between switches, it may be +called an "etherchannel" (as in the Cisco example, above), a "trunk +group" or some other similar variation. For these modes, each switch +will also have its own configuration options for the switch's transmit +policy to the bond. Typical choices include XOR of either the MAC or +IP addresses. The transmit policy of the two peers does not need to +match. For these three modes, the bonding mode really selects a +transmit policy for an EtherChannel group; all three will interoperate +with another EtherChannel group. + + +7. 802.1q VLAN Support +====================== + + It is possible to configure VLAN devices over a bond interface +using the 8021q driver. However, only packets coming from the 8021q +driver and passing through bonding will be tagged by default. Self +generated packets, for example, bonding's learning packets or ARP +packets generated by either ALB mode or the ARP monitor mechanism, are +tagged internally by bonding itself. As a result, bonding must +"learn" the VLAN IDs configured above it, and use those IDs to tag +self generated packets. + + For reasons of simplicity, and to support the use of adapters +that can do VLAN hardware acceleration offloding, the bonding +interface declares itself as fully hardware offloaing capable, it gets +the add_vid/kill_vid notifications to gather the necessary +information, and it propagates those actions to the slaves. In case +of mixed adapter types, hardware accelerated tagged packets that +should go through an adapter that is not offloading capable are +"un-accelerated" by the bonding driver so the VLAN tag sits in the +regular location. + + VLAN interfaces *must* be added on top of a bonding interface +only after enslaving at least one slave. The bonding interface has a +hardware address of 00:00:00:00:00:00 until the first slave is added. +If the VLAN interface is created prior to the first enslavement, it +would pick up the all-zeroes hardware address. Once the first slave +is attached to the bond, the bond device itself will pick up the +slave's hardware address, which is then available for the VLAN device. + + Also, be aware that a similar problem can occur if all slaves +are released from a bond that still has one or more VLAN interfaces on +top of it. When a new slave is added, the bonding interface will +obtain its hardware address from the first slave, which might not +match the hardware address of the VLAN interfaces (which was +ultimately copied from an earlier slave). + + There are two methods to insure that the VLAN device operates +with the correct hardware address if all slaves are removed from a +bond interface: + + 1. Remove all VLAN interfaces then recreate them + + 2. Set the bonding interface's hardware address so that it +matches the hardware address of the VLAN interfaces. + + Note that changing a VLAN interface's HW address would set the +underlying device -- i.e. the bonding interface -- to promiscouos +mode, which might not be what you want. -1. Is it SMP safe? - - Yes. The old 2.0.xx channel bonding patch was not SMP safe. - The new driver was designed to be SMP safe from the start. -2. What type of cards will work with it? - - Any Ethernet type cards (you can even mix cards - a Intel - EtherExpress PRO/100 and a 3com 3c905b, for example). - You can even bond together Gigabit Ethernet cards! +8. Link Monitoring +================== -3. How many bonding devices can I have? + The bonding driver at present supports two schemes for +monitoring a slave device's link state: the ARP monitor and the MII +monitor. + + At the present time, due to implementation restrictions in the +bonding driver itself, it is not possible to enable both ARP and MII +monitoring simultaneously. + +8.1 ARP Monitor Operation +------------------------- + + The ARP monitor operates as its name suggests: it sends ARP +queries to one or more designated peer systems on the network, and +uses the response as an indication that the link is operating. This +gives some assurance that traffic is actually flowing to and from one +or more peers on the local network. + + The ARP monitor relies on the device driver itself to verify +that traffic is flowing. In particular, the driver must keep up to +date the last receive time, dev->last_rx, and transmit start time, +dev->trans_start. If these are not updated by the driver, then the +ARP monitor will immediately fail any slaves using that driver, and +those slaves will stay down. If networking monitoring (tcpdump, etc) +shows the ARP requests and replies on the network, then it may be that +your device driver is not updating last_rx and trans_start. - There is no limit. +8.2 Configuring Multiple ARP Targets +------------------------------------ -4. How many slaves can a bonding device have? + While ARP monitoring can be done with just one target, it can +be useful in a High Availability setup to have several targets to +monitor. In the case of just one target, the target itself may go +down or have a problem making it unresponsive to ARP requests. Having +an additional target (or several) increases the reliability of the ARP +monitoring. - Limited by the number of network interfaces Linux supports and/or the - number of network cards you can place in your system. + Multiple ARP targets must be seperated by commas as follows: -5. What happens when a slave link dies? +# example options for ARP monitoring with three targets +alias bond0 bonding +options bond0 arp_interval=60 arp_ip_target=192.168.0.1,192.168.0.3,192.168.0.9 - If your ethernet cards support MII or ETHTOOL link status monitoring - and the MII monitoring has been enabled in the driver (see description - of module parameters), there will be no adverse consequences. This - release of the bonding driver knows how to get the MII information and - enables or disables its slaves according to their link status. - See section on High Availability for additional information. - - For ethernet cards not supporting MII status, the arp_interval and - arp_ip_target parameters must be specified for bonding to work - correctly. If packets have not been sent or received during the - specified arp_interval duration, an ARP request is sent to the - targets to generate send and receive traffic. If after this - interval, either the successful send and/or receive count has not - incremented, the next slave in the sequence will become the active - slave. - - If neither mii_monitor and arp_interval is configured, the bonding - driver will not handle this situation very well. The driver will - continue to send packets but some packets will be lost. Retransmits - will cause serious degradation of performance (in the case when one - of two slave links fails, 50% packets will be lost, which is a serious - problem for both TCP and UDP). + For just a single target the options would resemble: -6. Can bonding be used for High Availability? +# example options for ARP monitoring with one target +alias bond0 bonding +options bond0 arp_interval=60 arp_ip_target=192.168.0.100 - Yes, if you use MII monitoring and ALL your cards support MII link - status reporting. See section on High Availability for more - information. -7. Which switches/systems does it work with? +8.3 MII Monitor Operation +------------------------- - In round-robin and XOR mode, it works with systems that support - trunking: + The MII monitor monitors only the carrier state of the local +network interface. It accomplishes this in one of three ways: by +depending upon the device driver to maintain its carrier state, by +querying the device's MII registers, or by making an ethtool query to +the device. + + If the use_carrier module parameter is 1 (the default value), +then the MII monitor will rely on the driver for carrier state +information (via the netif_carrier subsystem). As explained in the +use_carrier parameter information, above, if the MII monitor fails to +detect carrier loss on the device (e.g., when the cable is physically +disconnected), it may be that the driver does not support +netif_carrier. + + If use_carrier is 0, then the MII monitor will first query the +device's (via ioctl) MII registers and check the link state. If that +request fails (not just that it returns carrier down), then the MII +monitor will make an ethtool ETHOOL_GLINK request to attempt to obtain +the same information. If both methods fail (i.e., the driver either +does not support or had some error in processing both the MII register +and ethtool requests), then the MII monitor will assume the link is +up. - * Many Cisco switches and routers (look for EtherChannel support). - * SunTrunking software. - * Alteon AceDirector switches / WebOS (use Trunks). - * BayStack Switches (trunks must be explicitly configured). Stackable - models (450) can define trunks between ports on different physical - units. - * Linux bonding, of course ! - - In 802.3ad mode, it works with with systems that support IEEE 802.3ad - Dynamic Link Aggregation: - - * Extreme networks Summit 7i (look for link-aggregation). - * Many Cisco switches and routers (look for LACP support; this may - require an upgrade to your IOS software; LACP support was added - by Cisco in late 2002). - * Foundry Big Iron 4000 +9. Potential Sources of Trouble +=============================== - In active-backup, balance-tlb and balance-alb modes, it should work - with any Layer-II switch. +9.1 Adventures in Routing +------------------------- + When bonding is configured, it is important that the slave +devices not have routes that supercede routes of the master (or, +generally, not have routes at all). For example, suppose the bonding +device bond0 has two slaves, eth0 and eth1, and the routing table is +as follows: -8. Where does a bonding device get its MAC address from? +Kernel IP routing table +Destination Gateway Genmask Flags MSS Window irtt Iface +10.0.0.0 0.0.0.0 255.255.0.0 U 40 0 0 eth0 +10.0.0.0 0.0.0.0 255.255.0.0 U 40 0 0 eth1 +10.0.0.0 0.0.0.0 255.255.0.0 U 40 0 0 bond0 +127.0.0.0 0.0.0.0 255.0.0.0 U 40 0 0 lo - If not explicitly configured with ifconfig, the MAC address of the - bonding device is taken from its first slave device. This MAC address - is then passed to all following slaves and remains persistent (even if - the the first slave is removed) until the bonding device is brought - down or reconfigured. + This routing configuration will likely still update the +receive/transmit times in the driver (needed by the ARP monitor), but +may bypass the bonding driver (because outgoing traffic to, in this +case, another host on network 10 would use eth0 or eth1 before bond0). + + The ARP monitor (and ARP itself) may become confused by this +configuration, because ARP requests (generated by the ARP monitor) +will be sent on one interface (bond0), but the corresponding reply +will arrive on a different interface (eth0). This reply looks to ARP +as an unsolicited ARP reply (because ARP matches replies on an +interface basis), and is discarded. The MII monitor is not affected +by the state of the routing table. + + The solution here is simply to insure that slaves do not have +routes of their own, and if for some reason they must, those routes do +not supercede routes of their master. This should generally be the +case, but unusual configurations or errant manual or automatic static +route additions may cause trouble. - If you wish to change the MAC address, you can set it with ifconfig: +9.2 Ethernet Device Renaming +---------------------------- - # ifconfig bond0 hw ether 00:11:22:33:44:55 + On systems with network configuration scripts that do not +associate physical devices directly with network interface names (so +that the same physical device always has the same "ethX" name), it may +be necessary to add some special logic to either /etc/modules.conf or +/etc/modprobe.conf (depending upon which is installed on the system). - The MAC address can be also changed by bringing down/up the device - and then changing its slaves (or their order): + For example, given a modules.conf containing the following: - # ifconfig bond0 down ; modprobe -r bonding - # ifconfig bond0 .... up - # ifenslave bond0 eth... +alias bond0 bonding +options bond0 mode=some-mode miimon=50 +alias eth0 tg3 +alias eth1 tg3 +alias eth2 e1000 +alias eth3 e1000 + + If neither eth0 and eth1 are slaves to bond0, then when the +bond0 interface comes up, the devices may end up reordered. This +happens because bonding is loaded first, then its slave device's +drivers are loaded next. Since no other drivers have been loaded, +when the e1000 driver loads, it will receive eth0 and eth1 for its +devices, but the bonding configuration tries to enslave eth2 and eth3 +(which may later be assigned to the tg3 devices). + + Adding the following: + +add above bonding e1000 tg3 + + causes modprobe to load e1000 then tg3, in that order, when +bonding is loaded. This command is fully documented in the +modules.conf manual page. + + On systems utilizing modprobe.conf (or modprobe.conf.local), +an equivalent problem can occur. In this case, the following can be +added to modprobe.conf (or modprobe.conf.local, as appropriate), as +follows (all on one line; it has been split here for clarity): + +install bonding /sbin/modprobe tg3; /sbin/modprobe e1000; + /sbin/modprobe --ignore-install bonding + + This will, when loading the bonding module, rather than +performing the normal action, instead execute the provided command. +This command loads the device drivers in the order needed, then calls +modprobe with --ingore-install to cause the normal action to then take +place. Full documentation on this can be found in the modprobe.conf +and modprobe manual pages. + +9.3. Painfully Slow Or No Failed Link Detection By Miimon +--------------------------------------------------------- + + By default, bonding enables the use_carrier option, which +instructs bonding to trust the driver to maintain carrier state. + + As discussed in the options section, above, some drivers do +not support the netif_carrier_on/_off link state tracking system. +With use_carrier enabled, bonding will always see these links as up, +regardless of their actual state. + + Additionally, other drivers do support netif_carrier, but do +not maintain it in real time, e.g., only polling the link state at +some fixed interval. In this case, miimon will detect failures, but +only after some long period of time has expired. If it appears that +miimon is very slow in detecting link failures, try specifying +use_carrier=0 to see if that improves the failure detection time. If +it does, then it may be that the driver checks the carrier state at a +fixed interval, but does not cache the MII register values (so the +use_carrier=0 method of querying the registers directly works). If +use_carrier=0 does not improve the failover, then the driver may cache +the registers, or the problem may be elsewhere. + + Also, remember that miimon only checks for the device's +carrier state. It has no way to determine the state of devices on or +beyond other ports of a switch, or if a switch is refusing to pass +traffic while still maintaining carrier on. + +10. SNMP agents +=============== + + If running SNMP agents, the bonding driver should be loaded +before any network drivers participating in a bond. This requirement +is due to the the interface index (ipAdEntIfIndex) being associated to +the first interface found with a given IP address. That is, there is +only one ipAdEntIfIndex for each IP address. For example, if eth0 and +eth1 are slaves of bond0 and the driver for eth0 is loaded before the +bonding driver, the interface for the IP address will be associated +with the eth0 interface. This configuration is shown below, the IP +address 192.168.1.1 has an interface index of 2 which indexes to eth0 +in the ifDescr table (ifDescr.2). - This method will automatically take the address from the next slave - that will be added. + interfaces.ifTable.ifEntry.ifDescr.1 = lo + interfaces.ifTable.ifEntry.ifDescr.2 = eth0 + interfaces.ifTable.ifEntry.ifDescr.3 = eth1 + interfaces.ifTable.ifEntry.ifDescr.4 = eth2 + interfaces.ifTable.ifEntry.ifDescr.5 = eth3 + interfaces.ifTable.ifEntry.ifDescr.6 = bond0 + ip.ipAddrTable.ipAddrEntry.ipAdEntIfIndex.10.10.10.10 = 5 + ip.ipAddrTable.ipAddrEntry.ipAdEntIfIndex.192.168.1.1 = 2 + ip.ipAddrTable.ipAddrEntry.ipAdEntIfIndex.10.74.20.94 = 4 + ip.ipAddrTable.ipAddrEntry.ipAdEntIfIndex.127.0.0.1 = 1 - To restore your slaves' MAC addresses, you need to detach them - from the bond (`ifenslave -d bond0 eth0'). The bonding driver will then - restore the MAC addresses that the slaves had before they were enslaved. + This problem is avoided by loading the bonding driver before +any network drivers participating in a bond. Below is an example of +loading the bonding driver first, the IP address 192.168.1.1 is +correctly associated with ifDescr.2. -9. Which transmit polices can be used? + interfaces.ifTable.ifEntry.ifDescr.1 = lo + interfaces.ifTable.ifEntry.ifDescr.2 = bond0 + interfaces.ifTable.ifEntry.ifDescr.3 = eth0 + interfaces.ifTable.ifEntry.ifDescr.4 = eth1 + interfaces.ifTable.ifEntry.ifDescr.5 = eth2 + interfaces.ifTable.ifEntry.ifDescr.6 = eth3 + ip.ipAddrTable.ipAddrEntry.ipAdEntIfIndex.10.10.10.10 = 6 + ip.ipAddrTable.ipAddrEntry.ipAdEntIfIndex.192.168.1.1 = 2 + ip.ipAddrTable.ipAddrEntry.ipAdEntIfIndex.10.74.20.94 = 5 + ip.ipAddrTable.ipAddrEntry.ipAdEntIfIndex.127.0.0.1 = 1 - Round-robin, based on the order of enslaving, the output device - is selected base on the next available slave. Regardless of - the source and/or destination of the packet. + While some distributions may not report the interface name in +ifDescr, the association between the IP address and IfIndex remains +and SNMP functions such as Interface_Scan_Next will report that +association. - Active-backup policy that ensures that one and only one device will - transmit at any given moment. Active-backup policy is useful for - implementing high availability solutions using two hubs (see - section on High Availability). +11. Promiscuous mode +==================== - XOR, based on (src hw addr XOR dst hw addr) % slave count. This - policy selects the same slave for each destination hw address. + When running network monitoring tools, e.g., tcpdump, it is +common to enable promiscuous mode on the device, so that all traffic +is seen (instead of seeing only traffic destined for the local host). +The bonding driver handles promiscuous mode changes to the bonding +master device (e.g., bond0), and propogates the setting to the slave +devices. + + For the balance-rr, balance-xor, broadcast, and 802.3ad modes, +the promiscuous mode setting is propogated to all slaves. + + For the active-backup, balance-tlb and balance-alb modes, the +promiscuous mode setting is propogated only to the active slave. + + For balance-tlb mode, the active slave is the slave currently +receiving inbound traffic. + + For balance-alb mode, the active slave is the slave used as a +"primary." This slave is used for mode-specific control traffic, for +sending to peers that are unassigned or if the load is unbalanced. + + For the active-backup, balance-tlb and balance-alb modes, when +the active slave changes (e.g., due to a link failure), the +promiscuous setting will be propogated to the new active slave. + +12. High Availability Information +================================= + + High Availability refers to configurations that provide +maximum network availability by having redundant or backup devices, +links and switches between the host and the rest of the world. + + There are currently two basic methods for configuring to +maximize availability. They are dependent on the network topology and +the primary goal of the configuration, but in general, a configuration +can be optimized for maximum available bandwidth, or for maximum +network availability. + +12.1 High Availability in a Single Switch Topology +-------------------------------------------------- + + If two hosts (or a host and a switch) are directly connected +via multiple physical links, then there is no network availability +penalty for optimizing for maximum bandwidth: there is only one switch +(or peer), so if it fails, you have no alternative access to fail over +to. - Broadcast policy transmits everything on all slave interfaces. +Example 1 : host to switch (or other host) - 802.3ad, based on XOR but distributes traffic among all interfaces - in the active aggregator. + +----------+ +----------+ + | |eth0 eth0| switch | + | Host A +--------------------------+ or | + | +--------------------------+ other | + | |eth1 eth1| host | + +----------+ +----------+ - Transmit load balancing (balance-tlb) balances the traffic - according to the current load on each slave. The balancing is - clients based and the least loaded slave is selected for each new - client. The load of each slave is calculated relative to its speed - and enables load balancing in mixed speed teams. - Adaptive load balancing (balance-alb) uses the Transmit load - balancing for the transmit load. The receive load is balanced only - among the group of highest speed active slaves in the bond. The - load is distributed with round-robin i.e. next available slave in - the high speed group of active slaves. +12.1.1 Bonding Mode Selection for single switch topology +-------------------------------------------------------- -High Availability -================= + This configuration is the easiest to set up and to understand, +although you will have to decide which bonding mode best suits your +needs. The tradeoffs for each mode are detailed below: + +balance-rr: This mode is the only mode that will permit a single + TCP/IP connection to stripe traffic across multiple + interfaces. It is therefore the only mode that will allow a + single TCP/IP stream to utilize more than one interface's + worth of throughput. This comes at a cost, however: the + striping often results in peer systems receiving packets out + of order, causing TCP/IP's congestion control system to kick + in, often by retransmitting segments. + + It is possible to adjust TCP/IP's congestion limits by + altering the net.ipv4.tcp_reordering sysctl parameter. The + usual default value is 3, and the maximum useful value is 127. + For a four interface balance-rr bond, expect that a single + TCP/IP stream will utilize no more than approximately 2.3 + interface's worth of throughput, even after adjusting + tcp_reordering. + + If you are utilizing protocols other than TCP/IP, UDP for + example, and your application can tolerate out of order + delivery, then this mode can allow for single stream datagram + performance that scales near linearly as interfaces are added + to the bond. + + This mode requires the switch to have the appropriate ports + configured for "etherchannel" or "trunking." + +active-backup: There is not much advantage in this network topology to + the active-backup mode, as the inactive backup devices are all + connected to the same peer as the primary. In this case, a + load balancing mode (with link monitoring) will provide the + same level of network availability, but with increased + available bandwidth. On the plus side, it does not require + any configuration of the switch. + +balance-xor: This mode will limit traffic such that packets destined + for specific peers will always be sent over the same + interface. Since the destination is determined by the MAC + addresses involved, this may be desirable if you have a large + network with many hosts. It is likely to be suboptimal if all + your traffic is passed through a single router, however. As + with balance-rr, the switch ports need to be configured for + "etherchannel" or "trunking." + +broadcast: Like active-backup, there is not much advantage to this + mode in this type of network topology. + +802.3ad: This mode can be a good choice for this type of network + topology. The 802.3ad mode is an IEEE standard, so all peers + that implement 802.3ad should interoperate well. The 802.3ad + protocol includes automatic configuration of the aggregates, + so minimal manual configuration of the switch is needed + (typically only to designate that some set of devices is + usable for 802.3ad). The 802.3ad standard also mandates that + frames be delivered in order (within certain limits), so in + general single connections will not see misordering of + packets. The 802.3ad mode does have some drawbacks: the + standard mandates that all devices in the aggregate operate at + the same speed and duplex. Also, as with all bonding load + balance modes other than balance-rr, no single connection will + be able to utilize more than a single interface's worth of + bandwidth. Additionally, the linux bonding 802.3ad + implementation distributes traffic by peer (using an XOR of + MAC addresses), so in general all traffic to a particular + destination will use the same interface. Finally, the 802.3ad + mode mandates the use of the MII monitor, therefore, the ARP + monitor is not available in this mode. + +balance-tlb: This mode is also a good choice for this type of + topology. It has no special switch configuration + requirements, and balances outgoing traffic by peer, in a + vaguely intelligent manner (not a simple XOR as in balance-xor + or 802.3ad mode), so that unlucky MAC addresses will not all + "bunch up" on a single interface. Interfaces may be of + differing speeds. On the down side, in this mode all incoming + traffic arrives over a single interface, this mode requires + certain ethtool support in the network device driver of the + slave interfaces, and the ARP monitor is not available. + +balance-alb: This mode is everything that balance-tlb is, and more. It + has all of the features (and restrictions) of balance-tlb, and + will also balance incoming traffic from peers (as described in + the Bonding Module Options section, above). The only extra + down side to this mode is that the network device driver must + support changing the hardware address while the device is + open. + +12.1.2 Link Monitoring for Single Switch Topology +------------------------------------------------- + + The choice of link monitoring may largely depend upon which +mode you choose to use. The more advanced load balancing modes do not +support the use of the ARP monitor, and are thus restricted to using +the MII monitor (which does not provide as high a level of assurance +as the ARP monitor). + + +12.2 High Availability in a Multiple Switch Topology +---------------------------------------------------- + + With multiple switches, the configuration of bonding and the +network changes dramatically. In multiple switch topologies, there is +a tradeoff between network availability and usable bandwidth. -To implement high availability using the bonding driver, the driver needs to be -compiled as a module, because currently it is the only way to pass parameters -to the driver. This may change in the future. - -High availability is achieved by using MII or ETHTOOL status reporting. You -need to verify that all your interfaces support MII or ETHTOOL link status -reporting. On Linux kernel 2.2.17, all the 100 Mbps capable drivers and -yellowfin gigabit driver support MII. To determine if ETHTOOL link reporting -is available for interface eth0, type "ethtool eth0" and the "Link detected:" -line should contain the correct link status. If your system has an interface -that does not support MII or ETHTOOL status reporting, a failure of its link -will not be detected! A message indicating MII and ETHTOOL is not supported by -a network driver is logged when the bonding driver is loaded with a non-zero -miimon value. - -The bonding driver can regularly check all its slaves links using the ETHTOOL -IOCTL (ETHTOOL_GLINK command) or by checking the MII status registers. The -check interval is specified by the module argument "miimon" (MII monitoring). -It takes an integer that represents the checking time in milliseconds. It -should not come to close to (1000/HZ) (10 milli-seconds on i386) because it -may then reduce the system interactivity. A value of 100 seems to be a good -starting point. It means that a dead link will be detected at most 100 -milli-seconds after it goes down. - -Example: - - # modprobe bonding miimon=100 - -Or, put the following line in /etc/modprobe.conf: - - options bond0 miimon=100 - -There are currently two policies for high availability. They are dependent on -whether: - - a) hosts are connected to a single host or switch that support trunking - - b) hosts are connected to several different switches or a single switch that - does not support trunking - - -1) High Availability on a single switch or host - load balancing ----------------------------------------------------------------- -It is the easiest to set up and to understand. Simply configure the -remote equipment (host or switch) to aggregate traffic over several -ports (Trunk, EtherChannel, etc.) and configure the bonding interfaces. -If the module has been loaded with the proper MII option, it will work -automatically. You can then try to remove and restore different links -and see in your logs what the driver detects. When testing, you may -encounter problems on some buggy switches that disable the trunk for a -long time if all ports in a trunk go down. This is not Linux, but really -the switch (reboot it to ensure). + Below is a sample network, configured to maximize the +availability of the network: -Example 1 : host to host at twice the speed + | | + |port3 port3| + +-----+----+ +-----+----+ + | |port2 ISL port2| | + | switch A +--------------------------+ switch B | + | | | | + +-----+----+ +-----++---+ + |port1 port1| + | +-------+ | + +-------------+ host1 +---------------+ + eth0 +-------+ eth1 - +----------+ +----------+ - | |eth0 eth0| | - | Host A +--------------------------+ Host B | - | +--------------------------+ | - | |eth1 eth1| | - +----------+ +----------+ + In this configuration, there is a link between the two +switches (ISL, or inter switch link), and multiple ports connecting to +the outside world ("port3" on each switch). There is no technical +reason that this could not be extended to a third switch. + +12.2.1 Bonding Mode Selection for Multiple Switch Topology +---------------------------------------------------------- + + In a topology such as this, the active-backup and broadcast +modes are the only useful bonding modes; the other modes require all +links to terminate on the same peer for them to behave rationally. + +active-backup: This is generally the preferred mode, particularly if + the switches have an ISL and play together well. If the + network configuration is such that one switch is specifically + a backup switch (e.g., has lower capacity, higher cost, etc), + then the primary option can be used to insure that the + preferred link is always used when it is available. + +broadcast: This mode is really a special purpose mode, and is suitable + only for very specific needs. For example, if the two + switches are not connected (no ISL), and the networks beyond + them are totally independant. In this case, if it is + necessary for some specific one-way traffic to reach both + independent networks, then the broadcast mode may be suitable. + +12.2.2 Link Monitoring Selection for Multiple Switch Topology +------------------------------------------------------------- + + The choice of link monitoring ultimately depends upon your +switch. If the switch can reliably fail ports in response to other +failures, then either the MII or ARP monitors should work. For +example, in the above example, if the "port3" link fails at the remote +end, the MII monitor has no direct means to detect this. The ARP +monitor could be configured with a target at the remote end of port3, +thus detecting that failure without switch support. + + In general, however, in a multiple switch topology, the ARP +monitor can provide a higher level of reliability in detecting link +failures. Additionally, it should be configured with multiple targets +(at least one for each switch in the network). This will insure that, +regardless of which switch is active, the ARP monitor has a suitable +target to query. + + +12.3 Switch Behavior Issues for High Availability +------------------------------------------------- + + You may encounter issues with the timing of link up and down +reporting by the switch. + + First, when a link comes up, some switches may indicate that +the link is up (carrier available), but not pass traffic over the +interface for some period of time. This delay is typically due to +some type of autonegotiation or routing protocol, but may also occur +during switch initialization (e.g., during recovery after a switch +failure). If you find this to be a problem, specify an appropriate +value to the updelay bonding module option to delay the use of the +relevant interface(s). + + Second, some switches may "bounce" the link state one or more +times while a link is changing state. This occurs most commonly while +the switch is initializing. Again, an appropriate updelay value may +help, but note that if all links are down, then updelay is ignored +when any link becomes active (the slave closest to completing its +updelay is chosen). + + Note that when a bonding interface has no active links, the +driver will immediately reuse the first link that goes up, even if +updelay parameter was specified. If there are slave interfaces +waiting for the updelay timeout to expire, the interface that first +went into that state will be immediately reused. This reduces down +time of the network if the value of updelay has been overestimated. + + In addition to the concerns about switch timings, if your +switches take a long time to go into backup mode, it may be desirable +to not activate a backup interface immediately after a link goes down. +Failover may be delayed via the downdelay bonding module option. + +13. Hardware Specific Considerations +==================================== + + This section contains additional information for configuring +bonding on specific hardware platforms, or for interfacing bonding +with particular switches or other devices. + +13.1 IBM BladeCenter +-------------------- + + This applies to the JS20 and similar systems. + + On the JS20 blades, the bonding driver supports only +balance-rr, active-backup, balance-tlb and balance-alb modes. This is +largely due to the network topology inside the BladeCenter, detailed +below. + +JS20 network adapter information +-------------------------------- + + All JS20s come with two Broadcom Gigabit Ethernet ports +integrated on the planar. In the BladeCenter chassis, the eth0 port +of all JS20 blades is hard wired to I/O Module #1; similarly, all eth1 +ports are wired to I/O Module #2. An add-on Broadcom daughter card +can be installed on a JS20 to provide two more Gigabit Ethernet ports. +These ports, eth2 and eth3, are wired to I/O Modules 3 and 4, +respectively. + + Each I/O Module may contain either a switch or a passthrough +module (which allows ports to be directly connected to an external +switch). Some bonding modes require a specific BladeCenter internal +network topology in order to function; these are detailed below. - On each host : - # modprobe bonding miimon=100 - # ifconfig bond0 addr - # ifenslave bond0 eth0 eth1 + Additional BladeCenter-specific networking information can be +found in two IBM Redbooks (www.ibm.com/redbooks): -Example 2 : host to switch at twice the speed +"IBM eServer BladeCenter Networking Options" +"IBM eServer BladeCenter Layer 2-7 Network Switching" - +----------+ +----------+ - | |eth0 port1| | - | Host A +--------------------------+ switch | - | +--------------------------+ | - | |eth1 port2| | - +----------+ +----------+ +BladeCenter networking configuration +------------------------------------ - On host A : On the switch : - # modprobe bonding miimon=100 # set up a trunk on port1 - # ifconfig bond0 addr and port2 - # ifenslave bond0 eth0 eth1 + Because a BladeCenter can be configured in a very large number +of ways, this discussion will be confined to describing basic +configurations. + + Normally, Ethernet Switch Modules (ESM) are used in I/O +modules 1 and 2. In this configuration, the eth0 and eth1 ports of a +JS20 will be connected to different internal switches (in the +respective I/O modules). + + An optical passthru module (OPM) connects the I/O module +directly to an external switch. By using OPMs in I/O module #1 and +#2, the eth0 and eth1 interfaces of a JS20 can be redirected to the +outside world and connected to a common external switch. + + Depending upon the mix of ESM and OPM modules, the network +will appear to bonding as either a single switch topology (all OPM +modules) or as a multiple switch topology (one or more ESM modules, +zero or more OPM modules). It is also possible to connect ESM modules +together, resulting in a configuration much like the example in "High +Availability in a multiple switch topology." + +Requirements for specifc modes +------------------------------ + + The balance-rr mode requires the use of OPM modules for +devices in the bond, all connected to an common external switch. That +switch must be configured for "etherchannel" or "trunking" on the +appropriate ports, as is usual for balance-rr. + + The balance-alb and balance-tlb modes will function with +either switch modules or passthrough modules (or a mix). The only +specific requirement for these modes is that all network interfaces +must be able to reach all destinations for traffic sent over the +bonding device (i.e., the network must converge at some point outside +the BladeCenter). + + The active-backup mode has no additional requirements. + +Link monitoring issues +---------------------- + + When an Ethernet Switch Module is in place, only the ARP +monitor will reliably detect link loss to an external switch. This is +nothing unusual, but examination of the BladeCenter cabinet would +suggest that the "external" network ports are the ethernet ports for +the system, when it fact there is a switch between these "external" +ports and the devices on the JS20 system itself. The MII monitor is +only able to detect link failures between the ESM and the JS20 system. + + When a passthrough module is in place, the MII monitor does +detect failures to the "external" port, which is then directly +connected to the JS20 system. + +Other concerns +-------------- + + The Serial Over LAN link is established over the primary +ethernet (eth0) only, therefore, any loss of link to eth0 will result +in losing your SoL connection. It will not fail over with other +network traffic. + + It may be desirable to disable spanning tree on the switch +(either the internal Ethernet Switch Module, or an external switch) to +avoid fail-over delays issues when using bonding. + + +14. Frequently Asked Questions +============================== +1. Is it SMP safe? -2) High Availability on two or more switches (or a single switch without - trunking support) ---------------------------------------------------------------------------- -This mode is more problematic because it relies on the fact that there -are multiple ports and the host's MAC address should be visible on one -port only to avoid confusing the switches. + Yes. The old 2.0.xx channel bonding patch was not SMP safe. +The new driver was designed to be SMP safe from the start. -If you need to know which interface is the active one, and which ones are -backup, use ifconfig. All backup interfaces have the NOARP flag set. +2. What type of cards will work with it? -To use this mode, pass "mode=1" to the module at load time : + Any Ethernet type cards (you can even mix cards - a Intel +EtherExpress PRO/100 and a 3com 3c905b, for example). They need not +be of the same speed. - # modprobe bonding miimon=100 mode=active-backup +3. How many bonding devices can I have? - or: + There is no limit. - # modprobe bonding miimon=100 mode=1 +4. How many slaves can a bonding device have? -Or, put in your /etc/modprobe.conf : + This is limited only by the number of network interfaces Linux +supports and/or the number of network cards you can place in your +system. - options bond0 miimon=100 mode=active-backup +5. What happens when a slave link dies? -Example 1: Using multiple host and multiple switches to build a "no single -point of failure" solution. + If link monitoring is enabled, then the failing device will be +disabled. The active-backup mode will fail over to a backup link, and +other modes will ignore the failed link. The link will continue to be +monitored, and should it recover, it will rejoin the bond (in whatever +manner is appropriate for the mode). See the section on High +Availability for additional information. + + Link monitoring can be enabled via either the miimon or +arp_interval paramters (described in the module paramters section, +above). In general, miimon monitors the carrier state as sensed by +the underlying network device, and the arp monitor (arp_interval) +monitors connectivity to another host on the local network. + + If no link monitoring is configured, the bonding driver will +be unable to detect link failures, and will assume that all links are +always available. This will likely result in lost packets, and a +resulting degredation of performance. The precise performance loss +depends upon the bonding mode and network configuration. +6. Can bonding be used for High Availability? - | | - |port3 port3| - +-----+----+ +-----+----+ - | |port7 ISL port7| | - | switch A +--------------------------+ switch B | - | +--------------------------+ | - | |port8 port8| | - +----++----+ +-----++---+ - port2||port1 port1||port2 - || +-------+ || - |+-------------+ host1 +---------------+| - | eth0 +-------+ eth1 | - | | - | +-------+ | - +--------------+ host2 +----------------+ - eth0 +-------+ eth1 + Yes. See the section on High Availability for details. -In this configuration, there is an ISL - Inter Switch Link (could be a trunk), -several servers (host1, host2 ...) attached to both switches each, and one or -more ports to the outside world (port3...). One and only one slave on each host -is active at a time, while all links are still monitored (the system can -detect a failure of active and backup links). - -Each time a host changes its active interface, it sticks to the new one until -it goes down. In this example, the hosts are negligibly affected by the -expiration time of the switches' forwarding tables. - -If host1 and host2 have the same functionality and are used in load balancing -by another external mechanism, it is good to have host1's active interface -connected to one switch and host2's to the other. Such system will survive -a failure of a single host, cable, or switch. The worst thing that may happen -in the case of a switch failure is that half of the hosts will be temporarily -unreachable until the other switch expires its tables. +7. Which switches/systems does it work with? -Example 2: Using multiple ethernet cards connected to a switch to configure - NIC failover (switch is not required to support trunking). + The full answer to this depends upon the desired mode. + In the basic balance modes (balance-rr and balance-xor), it +works with any system that supports etherchannel (also called +trunking). Most managed switches currently available have such +support, and many unmananged switches as well. + + The advanced balance modes (balance-tlb and balance-alb) do +not have special switch requirements, but do need device drivers that +support specific features (described in the appropriate section under +module paramters, above). + + In 802.3ad mode, it works with with systems that support IEEE +802.3ad Dynamic Link Aggregation. Most managed and many unmanaged +switches currently available support 802.3ad. - +----------+ +----------+ - | |eth0 port1| | - | Host A +--------------------------+ switch | - | +--------------------------+ | - | |eth1 port2| | - +----------+ +----------+ + The active-backup mode should work with any Layer-II switch. - On host A : On the switch : - # modprobe bonding miimon=100 mode=1 # (optional) minimize the time - # ifconfig bond0 addr # for table expiration - # ifenslave bond0 eth0 eth1 +8. Where does a bonding device get its MAC address from? -Each time the host changes its active interface, it sticks to the new one until -it goes down. In this example, the host is strongly affected by the expiration -time of the switch forwarding table. + If not explicitly configured with ifconfig, the MAC address of +the bonding device is taken from its first slave device. This MAC +address is then passed to all following slaves and remains persistent +(even if the the first slave is removed) until the bonding device is +brought down or reconfigured. + + If you wish to change the MAC address, you can set it with +ifconfig: + +# ifconfig bond0 hw ether 00:11:22:33:44:55 + + The MAC address can be also changed by bringing down/up the +device and then changing its slaves (or their order): + +# ifconfig bond0 down ; modprobe -r bonding +# ifconfig bond0 .... up +# ifenslave bond0 eth... + This method will automatically take the address from the next +slave that is added. -3) Adapting to your switches' timing ------------------------------------- -If your switches take a long time to go into backup mode, it may be -desirable not to activate a backup interface immediately after a link goes -down. It is possible to delay the moment at which a link will be -completely disabled by passing the module parameter "downdelay" (in -milliseconds, must be a multiple of miimon). - -When a switch reboots, it is possible that its ports report "link up" status -before they become usable. This could fool a bond device by causing it to -use some ports that are not ready yet. It is possible to delay the moment at -which an active link will be reused by passing the module parameter "updelay" -(in milliseconds, must be a multiple of miimon). - -A similar situation can occur when a host re-negotiates a lost link with the -switch (a case of cable replacement). - -A special case is when a bonding interface has lost all slave links. Then the -driver will immediately reuse the first link that goes up, even if updelay -parameter was specified. (If there are slave interfaces in the "updelay" state, -the interface that first went into that state will be immediately reused.) This -allows to reduce down-time if the value of updelay has been overestimated. - -Examples : - - # modprobe bonding miimon=100 mode=1 downdelay=2000 updelay=5000 - # modprobe bonding miimon=100 mode=balance-rr downdelay=0 updelay=5000 - - -Promiscuous Sniffing notes -========================== - -If you wish to bond channels together for a network sniffing -application --- you wish to run tcpdump, or ethereal, or an IDS like -snort, with its input aggregated from multiple interfaces using the -bonding driver --- then you need to handle the Promiscuous interface -setting by hand. Specifically, when you "ifconfing bond0 up" you -must add the promisc flag there; it will be propagated down to the -slave interfaces at ifenslave time; a full example might look like: - - ifconfig bond0 promisc up - for if in eth1 eth2 ...;do - ifconfig $if up - ifenslave bond0 $if - done - snort ... -i bond0 ... - -Ifenslave also wants to propagate addresses from interface to -interface, appropriately for its design functions in HA and channel -capacity aggregating; but it works fine for unnumbered interfaces; -just ignore all the warnings it emits. + To restore your slaves' MAC addresses, you need to detach them +from the bond (`ifenslave -d bond0 eth0'). The bonding driver will +then restore the MAC addresses that the slaves had before they were +enslaved. +15. Resources and Links +======================= -8021q VLAN support -================== +The latest version of the bonding driver can be found in the latest +version of the linux kernel, found on http://kernel.org -It is possible to configure VLAN devices over a bond interface using the 8021q -driver. However, only packets coming from the 8021q driver and passing through -bonding will be tagged by default. Self generated packets, like bonding's -learning packets or ARP packets generated by either ALB mode or the ARP -monitor mechanism, are tagged internally by bonding itself. As a result, -bonding has to "learn" what VLAN IDs are configured on top of it, and it uses -those IDs to tag self generated packets. - -For simplicity reasons, and to support the use of adapters that can do VLAN -hardware acceleration offloding, the bonding interface declares itself as -fully hardware offloaing capable, it gets the add_vid/kill_vid notifications -to gather the necessary information, and it propagates those actions to the -slaves. -In case of mixed adapter types, hardware accelerated tagged packets that should -go through an adapter that is not offloading capable are "un-accelerated" by the -bonding driver so the VLAN tag sits in the regular location. - -VLAN interfaces *must* be added on top of a bonding interface only after -enslaving at least one slave. This is because until the first slave is added the -bonding interface has a HW address of 00:00:00:00:00:00, which will be copied by -the VLAN interface when it is created. - -Notice that a problem would occur if all slaves are released from a bond that -still has VLAN interfaces on top of it. When later coming to add new slaves, the -bonding interface would get a HW address from the first slave, which might not -match that of the VLAN interfaces. It is recommended that either all VLANs are -removed and then re-added, or to manually set the bonding interface's HW -address so it matches the VLAN's. (Note: changing a VLAN interface's HW address -would set the underlying device -- i.e. the bonding interface -- to promiscouos -mode, which might not be what you want). - - -Limitations -=========== -The main limitations are : - - only the link status is monitored. If the switch on the other side is - partially down (e.g. doesn't forward anymore, but the link is OK), the link - won't be disabled. Another way to check for a dead link could be to count - incoming frames on a heavily loaded host. This is not applicable to small - servers, but may be useful when the front switches send multicast - information on their links (e.g. VRRP), or even health-check the servers. - Use the arp_interval/arp_ip_target parameters to count incoming/outgoing - frames. +Discussions regarding the bonding driver take place primarily on the +bonding-devel mailing list, hosted at sourceforge.net. If you have +questions or problems, post them to the list. +bonding-devel@lists.sourceforge.net +https://lists.sourceforge.net/lists/listinfo/bonding-devel -Resources and Links -=================== +There is also a project site on sourceforge. -Current development on this driver is posted to: - - http://www.sourceforge.net/projects/bonding/ +http://www.sourceforge.net/projects/bonding Donald Becker's Ethernet Drivers and diag programs may be found at : - http://www.scyld.com/network/ -You will also find a lot of information regarding Ethernet, NWay, MII, etc. at -www.scyld.com. - -Patches for 2.2 kernels are at Willy Tarreau's site : - - http://wtarreau.free.fr/pub/bonding/ - - http://www-miaif.lip6.fr/~tarreau/pub/bonding/ - -To get latest informations about Linux Kernel development, please consult -the Linux Kernel Mailing List Archives at : - http://www.ussg.iu.edu/hypermail/linux/kernel/ +You will also find a lot of information regarding Ethernet, NWay, MII, +etc. at www.scyld.com. -- END -- diff -Nru a/drivers/net/3c59x.c b/drivers/net/3c59x.c --- a/drivers/net/3c59x.c 2005-03-07 12:09:08 -05:00 +++ b/drivers/net/3c59x.c 2005-03-07 12:09:08 -05:00 @@ -964,7 +964,7 @@ #ifdef CONFIG_PM -static int vortex_suspend (struct pci_dev *pdev, u32 state) +static int vortex_suspend (struct pci_dev *pdev, pm_message_t state) { struct net_device *dev = pci_get_drvdata(pdev); diff -Nru a/drivers/net/8139too.c b/drivers/net/8139too.c --- a/drivers/net/8139too.c 2005-03-07 12:09:08 -05:00 +++ b/drivers/net/8139too.c 2005-03-07 12:09:08 -05:00 @@ -389,8 +389,14 @@ /* Bits in TxConfig. */ enum tx_config_bits { - TxIFG1 = (1 << 25), /* Interframe Gap Time */ - TxIFG0 = (1 << 24), /* Enabling these bits violates IEEE 802.3 */ + + /* Interframe Gap Time. Only TxIFG96 doesn't violate IEEE 802.3 */ + TxIFGShift = 24, + TxIFG84 = (0 << TxIFGShift), /* 8.4us / 840ns (10 / 100Mbps) */ + TxIFG88 = (1 << TxIFGShift), /* 8.8us / 880ns (10 / 100Mbps) */ + TxIFG92 = (2 << TxIFGShift), /* 9.2us / 920ns (10 / 100Mbps) */ + TxIFG96 = (3 << TxIFGShift), /* 9.6us / 960ns (10 / 100Mbps) */ + TxLoopBack = (1 << 18) | (1 << 17), /* enable loopback test mode */ TxCRC = (1 << 16), /* DISABLE appending CRC to end of Tx packets */ TxClearAbt = (1 << 0), /* Clear abort (WO) */ @@ -723,17 +729,14 @@ #endif static const unsigned int rtl8139_tx_config = - (TX_DMA_BURST << TxDMAShift) | (TX_RETRY << TxRetryShift); + TxIFG96 | (TX_DMA_BURST << TxDMAShift) | (TX_RETRY << TxRetryShift); static void __rtl8139_cleanup_dev (struct net_device *dev) { - struct rtl8139_private *tp; + struct rtl8139_private *tp = netdev_priv(dev); struct pci_dev *pdev; assert (dev != NULL); - assert (dev->priv != NULL); - - tp = dev->priv; assert (tp->pci_dev != NULL); pdev = tp->pci_dev; @@ -746,7 +749,7 @@ pci_release_regions (pdev); free_netdev(dev); - + pci_disable_device(pdev); pci_set_drvdata (pdev, NULL); } @@ -785,7 +788,7 @@ *dev_out = NULL; - /* dev and dev->priv zeroed in alloc_etherdev */ + /* dev and priv zeroed in alloc_etherdev */ dev = alloc_etherdev (sizeof (*tp)); if (dev == NULL) { printk (KERN_ERR PFX "%s: Unable to alloc new net device\n", pci_name(pdev)); @@ -794,7 +797,7 @@ SET_MODULE_OWNER(dev); SET_NETDEV_DEV(dev, &pdev->dev); - tp = dev->priv; + tp = netdev_priv(dev); tp->pci_dev = pdev; /* enable device (incl. PCI PM wakeup and hotplug setup) */ @@ -976,8 +979,8 @@ return i; assert (dev != NULL); - tp = dev->priv; - assert (tp != NULL); + tp = netdev_priv(dev); + ioaddr = tp->mmio_addr; assert (ioaddr != NULL); @@ -1010,8 +1013,8 @@ dev->irq = pdev->irq; - /* dev->priv/tp zeroed and aligned in alloc_etherdev */ - tp = dev->priv; + /* tp zeroed and aligned in alloc_etherdev */ + tp = netdev_priv(dev); /* note: tp->chipset set in rtl8139_init_board */ tp->drv_flags = board_info[ent->driver_data].hw_flags; @@ -1116,11 +1119,8 @@ static void __devexit rtl8139_remove_one (struct pci_dev *pdev) { struct net_device *dev = pci_get_drvdata (pdev); - struct rtl8139_private *np; assert (dev != NULL); - np = dev->priv; - assert (np != NULL); unregister_netdev (dev); @@ -1234,7 +1234,7 @@ static int mdio_read (struct net_device *dev, int phy_id, int location) { - struct rtl8139_private *tp = dev->priv; + struct rtl8139_private *tp = netdev_priv(dev); int retval = 0; #ifdef CONFIG_8139TOO_8129 void *mdio_addr = tp->mmio_addr + Config4; @@ -1276,7 +1276,7 @@ static void mdio_write (struct net_device *dev, int phy_id, int location, int value) { - struct rtl8139_private *tp = dev->priv; + struct rtl8139_private *tp = netdev_priv(dev); #ifdef CONFIG_8139TOO_8129 void *mdio_addr = tp->mmio_addr + Config4; int mii_cmd = (0x5002 << 16) | (phy_id << 23) | (location << 18) | value; @@ -1319,7 +1319,7 @@ static int rtl8139_open (struct net_device *dev) { - struct rtl8139_private *tp = dev->priv; + struct rtl8139_private *tp = netdev_priv(dev); int retval; void *ioaddr = tp->mmio_addr; @@ -1367,7 +1367,7 @@ static void rtl_check_media (struct net_device *dev, unsigned int init_media) { - struct rtl8139_private *tp = dev->priv; + struct rtl8139_private *tp = netdev_priv(dev); if (tp->phys[0] >= 0) { mii_check_media(&tp->mii, netif_msg_link(tp), init_media); @@ -1377,7 +1377,7 @@ /* Start the hardware at open or resume. */ static void rtl8139_hw_start (struct net_device *dev) { - struct rtl8139_private *tp = dev->priv; + struct rtl8139_private *tp = netdev_priv(dev); void *ioaddr = tp->mmio_addr; u32 i; u8 tmp; @@ -1399,8 +1399,6 @@ tp->rx_config = rtl8139_rx_config | AcceptBroadcast | AcceptMyPhys; RTL_W32 (RxConfig, tp->rx_config); - - /* Check this value: the documentation for IFG contradicts ifself. */ RTL_W32 (TxConfig, rtl8139_tx_config); tp->cur_rx = 0; @@ -1446,7 +1444,7 @@ /* Initialize the Rx and Tx rings, along with various 'dev' bits. */ static void rtl8139_init_ring (struct net_device *dev) { - struct rtl8139_private *tp = dev->priv; + struct rtl8139_private *tp = netdev_priv(dev); int i; tp->cur_rx = 0; @@ -1613,7 +1611,7 @@ static int rtl8139_thread (void *data) { struct net_device *dev = data; - struct rtl8139_private *tp = dev->priv; + struct rtl8139_private *tp = netdev_priv(dev); unsigned long timeout; daemonize("%s", dev->name); @@ -1645,7 +1643,7 @@ static void rtl8139_start_thread(struct net_device *dev) { - struct rtl8139_private *tp = dev->priv; + struct rtl8139_private *tp = netdev_priv(dev); tp->thr_pid = -1; tp->twistie = 0; @@ -1673,7 +1671,7 @@ static void rtl8139_tx_timeout (struct net_device *dev) { - struct rtl8139_private *tp = dev->priv; + struct rtl8139_private *tp = netdev_priv(dev); void *ioaddr = tp->mmio_addr; int i; u8 tmp8; @@ -1718,7 +1716,7 @@ static int rtl8139_start_xmit (struct sk_buff *skb, struct net_device *dev) { - struct rtl8139_private *tp = dev->priv; + struct rtl8139_private *tp = netdev_priv(dev); void *ioaddr = tp->mmio_addr; unsigned int entry; unsigned int len = skb->len; @@ -1766,7 +1764,6 @@ unsigned long dirty_tx, tx_left; assert (dev != NULL); - assert (tp != NULL); assert (ioaddr != NULL); dirty_tx = tp->dirty_tx; @@ -2125,7 +2122,7 @@ static int rtl8139_poll(struct net_device *dev, int *budget) { - struct rtl8139_private *tp = dev->priv; + struct rtl8139_private *tp = netdev_priv(dev); void *ioaddr = tp->mmio_addr; int orig_budget = min(*budget, dev->quota); int done = 1; @@ -2163,7 +2160,7 @@ struct pt_regs *regs) { struct net_device *dev = (struct net_device *) dev_instance; - struct rtl8139_private *tp = dev->priv; + struct rtl8139_private *tp = netdev_priv(dev); void *ioaddr = tp->mmio_addr; u16 status, ackstat; int link_changed = 0; /* avoid bogus "uninit" warning */ @@ -2239,7 +2236,7 @@ static int rtl8139_close (struct net_device *dev) { - struct rtl8139_private *tp = dev->priv; + struct rtl8139_private *tp = netdev_priv(dev); void *ioaddr = tp->mmio_addr; int ret = 0; unsigned long flags; @@ -2302,7 +2299,7 @@ other threads or interrupts aren't messing with the 8139. */ static void rtl8139_get_wol(struct net_device *dev, struct ethtool_wolinfo *wol) { - struct rtl8139_private *np = dev->priv; + struct rtl8139_private *np = netdev_priv(dev); void *ioaddr = np->mmio_addr; spin_lock_irq(&np->lock); @@ -2336,7 +2333,7 @@ aren't messing with the 8139. */ static int rtl8139_set_wol(struct net_device *dev, struct ethtool_wolinfo *wol) { - struct rtl8139_private *np = dev->priv; + struct rtl8139_private *np = netdev_priv(dev); void *ioaddr = np->mmio_addr; u32 support; u8 cfg3, cfg5; @@ -2376,7 +2373,7 @@ static void rtl8139_get_drvinfo(struct net_device *dev, struct ethtool_drvinfo *info) { - struct rtl8139_private *np = dev->priv; + struct rtl8139_private *np = netdev_priv(dev); strcpy(info->driver, DRV_NAME); strcpy(info->version, DRV_VERSION); strcpy(info->bus_info, pci_name(np->pci_dev)); @@ -2385,7 +2382,7 @@ static int rtl8139_get_settings(struct net_device *dev, struct ethtool_cmd *cmd) { - struct rtl8139_private *np = dev->priv; + struct rtl8139_private *np = netdev_priv(dev); spin_lock_irq(&np->lock); mii_ethtool_gset(&np->mii, cmd); spin_unlock_irq(&np->lock); @@ -2394,7 +2391,7 @@ static int rtl8139_set_settings(struct net_device *dev, struct ethtool_cmd *cmd) { - struct rtl8139_private *np = dev->priv; + struct rtl8139_private *np = netdev_priv(dev); int rc; spin_lock_irq(&np->lock); rc = mii_ethtool_sset(&np->mii, cmd); @@ -2404,25 +2401,25 @@ static int rtl8139_nway_reset(struct net_device *dev) { - struct rtl8139_private *np = dev->priv; + struct rtl8139_private *np = netdev_priv(dev); return mii_nway_restart(&np->mii); } static u32 rtl8139_get_link(struct net_device *dev) { - struct rtl8139_private *np = dev->priv; + struct rtl8139_private *np = netdev_priv(dev); return mii_link_ok(&np->mii); } static u32 rtl8139_get_msglevel(struct net_device *dev) { - struct rtl8139_private *np = dev->priv; + struct rtl8139_private *np = netdev_priv(dev); return np->msg_enable; } static void rtl8139_set_msglevel(struct net_device *dev, u32 datum) { - struct rtl8139_private *np = dev->priv; + struct rtl8139_private *np = netdev_priv(dev); np->msg_enable = datum; } @@ -2433,13 +2430,13 @@ #else static int rtl8139_get_regs_len(struct net_device *dev) { - struct rtl8139_private *np = dev->priv; + struct rtl8139_private *np = netdev_priv(dev); return np->regs_len; } static void rtl8139_get_regs(struct net_device *dev, struct ethtool_regs *regs, void *regbuf) { - struct rtl8139_private *np = dev->priv; + struct rtl8139_private *np = netdev_priv(dev); regs->version = RTL_REGS_VER; @@ -2456,7 +2453,7 @@ static void rtl8139_get_ethtool_stats(struct net_device *dev, struct ethtool_stats *stats, u64 *data) { - struct rtl8139_private *np = dev->priv; + struct rtl8139_private *np = netdev_priv(dev); data[0] = np->xstats.early_rx; data[1] = np->xstats.tx_buf_mapped; @@ -2488,7 +2485,7 @@ static int netdev_ioctl(struct net_device *dev, struct ifreq *rq, int cmd) { - struct rtl8139_private *np = dev->priv; + struct rtl8139_private *np = netdev_priv(dev); int rc; if (!netif_running(dev)) @@ -2504,7 +2501,7 @@ static struct net_device_stats *rtl8139_get_stats (struct net_device *dev) { - struct rtl8139_private *tp = dev->priv; + struct rtl8139_private *tp = netdev_priv(dev); void *ioaddr = tp->mmio_addr; unsigned long flags; @@ -2523,7 +2520,7 @@ static void __set_rx_mode (struct net_device *dev) { - struct rtl8139_private *tp = dev->priv; + struct rtl8139_private *tp = netdev_priv(dev); void *ioaddr = tp->mmio_addr; u32 mc_filter[2]; /* Multicast hash filter */ int i, rx_mode; @@ -2572,7 +2569,7 @@ static void rtl8139_set_rx_mode (struct net_device *dev) { unsigned long flags; - struct rtl8139_private *tp = dev->priv; + struct rtl8139_private *tp = netdev_priv(dev); spin_lock_irqsave (&tp->lock, flags); __set_rx_mode(dev); @@ -2581,10 +2578,10 @@ #ifdef CONFIG_PM -static int rtl8139_suspend (struct pci_dev *pdev, u32 state) +static int rtl8139_suspend (struct pci_dev *pdev, pm_message_t state) { struct net_device *dev = pci_get_drvdata (pdev); - struct rtl8139_private *tp = dev->priv; + struct rtl8139_private *tp = netdev_priv(dev); void *ioaddr = tp->mmio_addr; unsigned long flags; diff -Nru a/drivers/net/Kconfig b/drivers/net/Kconfig --- a/drivers/net/Kconfig 2005-03-07 12:09:08 -05:00 +++ b/drivers/net/Kconfig 2005-03-07 12:09:08 -05:00 @@ -47,16 +47,13 @@ ---help--- Say 'Y' or 'M' if you wish to be able to 'bond' multiple Ethernet Channels together. This is called 'Etherchannel' by Cisco, - 'Trunking' by Sun, and 'Bonding' in Linux. + 'Trunking' by Sun, 802.3ad by the IEEE, and 'Bonding' in Linux. - If you have two Ethernet connections to some other computer, you can - make them behave like one double speed connection using this driver. - Naturally, this has to be supported at the other end as well, either - with a similar Bonding Linux driver, a Cisco 5500 switch or a - SunTrunking SunSoft driver. + The driver supports multiple bonding modes to allow for both high + perfomance and high availability operation. - This is similar to the EQL driver, but it merges Ethernet segments - instead of serial lines. + Refer to for more + information. To compile this driver as a module, choose M here: the module will be called bonding. @@ -819,7 +816,7 @@ tristate "SMC 91C9x/91C1xxx support" select CRC32 select MII - depends on NET_ETHERNET && (ARM || REDWOOD_5 || REDWOOD_6 || M32R) + depends on NET_ETHERNET && (ARM || REDWOOD_5 || REDWOOD_6 || M32R || SUPERH) help This is a driver for SMC's 91x series of Ethernet chipsets, including the SMC91C94 and the SMC91C111. Say Y if you want it diff -Nru a/drivers/net/amd8111e.c b/drivers/net/amd8111e.c --- a/drivers/net/amd8111e.c 2005-03-07 12:09:08 -05:00 +++ b/drivers/net/amd8111e.c 2005-03-07 12:09:08 -05:00 @@ -1799,7 +1799,7 @@ if(!err) netif_wake_queue(dev); } -static int amd8111e_suspend(struct pci_dev *pci_dev, u32 state) +static int amd8111e_suspend(struct pci_dev *pci_dev, pm_message_t state) { struct net_device *dev = pci_get_drvdata(pci_dev); struct amd8111e_priv *lp = netdev_priv(dev); diff -Nru a/drivers/net/b44.c b/drivers/net/b44.c --- a/drivers/net/b44.c 2005-03-07 12:09:08 -05:00 +++ b/drivers/net/b44.c 2005-03-07 12:09:08 -05:00 @@ -1903,7 +1903,7 @@ } } -static int b44_suspend(struct pci_dev *pdev, u32 state) +static int b44_suspend(struct pci_dev *pdev, pm_message_t state) { struct net_device *dev = pci_get_drvdata(pdev); struct b44 *bp = netdev_priv(dev); diff -Nru a/drivers/net/b44.h b/drivers/net/b44.h --- a/drivers/net/b44.h 2005-03-07 12:09:08 -05:00 +++ b/drivers/net/b44.h 2005-03-07 12:09:08 -05:00 @@ -302,20 +302,6 @@ #define B44_MII_TLEDCTRL 27 /* Traffic Meter LED */ #define MII_TLEDCTRL_ENABLE 0x0040 -/* XXX Add this to mii.h */ -#ifndef ADVERTISE_PAUSE -#define ADVERTISE_PAUSE_CAP 0x0400 -#endif -#ifndef ADVERTISE_PAUSE_ASYM -#define ADVERTISE_PAUSE_ASYM 0x0800 -#endif -#ifndef LPA_PAUSE -#define LPA_PAUSE_CAP 0x0400 -#endif -#ifndef LPA_PAUSE_ASYM -#define LPA_PAUSE_ASYM 0x0800 -#endif - struct dma_desc { u32 ctrl; u32 addr; diff -Nru a/drivers/net/bonding/bond_alb.c b/drivers/net/bonding/bond_alb.c --- a/drivers/net/bonding/bond_alb.c 2005-03-07 12:09:08 -05:00 +++ b/drivers/net/bonding/bond_alb.c 2005-03-07 12:09:08 -05:00 @@ -954,9 +954,9 @@ /* each slave will receive packets destined to a different mac */ memcpy(s_addr.sa_data, addr, dev->addr_len); s_addr.sa_family = dev->type; - if (dev->set_mac_address(dev, &s_addr)) { + if (dev_set_mac_address(dev, &s_addr)) { printk(KERN_ERR DRV_NAME - ": Error: dev->set_mac_address of dev %s failed! ALB " + ": Error: dev_set_mac_address of dev %s failed! ALB " "mode requires that the base driver support setting " "the hw address also when the network device's " "interface is open\n", @@ -1209,7 +1209,7 @@ /* save net_device's current hw address */ memcpy(tmp_addr, slave->dev->dev_addr, ETH_ALEN); - res = slave->dev->set_mac_address(slave->dev, addr); + res = dev_set_mac_address(slave->dev, addr); /* restore net_device's hw address */ memcpy(slave->dev->dev_addr, tmp_addr, ETH_ALEN); @@ -1229,7 +1229,7 @@ stop_at = slave; bond_for_each_slave_from_to(bond, slave, i, bond->first_slave, stop_at) { memcpy(tmp_addr, slave->dev->dev_addr, ETH_ALEN); - slave->dev->set_mac_address(slave->dev, &sa); + dev_set_mac_address(slave->dev, &sa); memcpy(slave->dev->dev_addr, tmp_addr, ETH_ALEN); } diff -Nru a/drivers/net/bonding/bond_main.c b/drivers/net/bonding/bond_main.c --- a/drivers/net/bonding/bond_main.c 2005-03-07 12:09:08 -05:00 +++ b/drivers/net/bonding/bond_main.c 2005-03-07 12:09:08 -05:00 @@ -1719,7 +1719,7 @@ */ memcpy(addr.sa_data, bond_dev->dev_addr, bond_dev->addr_len); addr.sa_family = slave_dev->type; - res = slave_dev->set_mac_address(slave_dev, &addr); + res = dev_set_mac_address(slave_dev, &addr); if (res) { dprintk("Error %d calling set_mac_address\n", res); goto err_free; @@ -1849,8 +1849,8 @@ if (bond_update_speed_duplex(new_slave) && (new_slave->link != BOND_LINK_DOWN)) { printk(KERN_WARNING DRV_NAME - ": Warning: failed to get speed/duplex from %s, speed " - "forced to 100Mbps, duplex forced to Full.\n", + ": Warning: failed to get speed and duplex from %s, " + "assumed to be 100Mb/sec and Full.\n", new_slave->dev->name); if (bond->params.mode == BOND_MODE_8023AD) { @@ -1991,7 +1991,7 @@ err_restore_mac: memcpy(addr.sa_data, new_slave->perm_hwaddr, ETH_ALEN); addr.sa_family = slave_dev->type; - slave_dev->set_mac_address(slave_dev, &addr); + dev_set_mac_address(slave_dev, &addr); err_free: kfree(new_slave); @@ -2171,7 +2171,7 @@ /* restore original ("permanent") mac address */ memcpy(addr.sa_data, slave->perm_hwaddr, ETH_ALEN); addr.sa_family = slave_dev->type; - slave_dev->set_mac_address(slave_dev, &addr); + dev_set_mac_address(slave_dev, &addr); } /* restore the original state of the @@ -2262,7 +2262,7 @@ /* restore original ("permanent") mac address*/ memcpy(addr.sa_data, slave->perm_hwaddr, ETH_ALEN); addr.sa_family = slave_dev->type; - slave_dev->set_mac_address(slave_dev, &addr); + dev_set_mac_address(slave_dev, &addr); } /* restore the original state of the IFF_NOARP flag that might have @@ -3898,12 +3898,7 @@ bond_for_each_slave(bond, slave, i) { dprintk("s %p s->p %p c_m %p\n", slave, slave->prev, slave->dev->change_mtu); - if (slave->dev->change_mtu) { - res = slave->dev->change_mtu(slave->dev, new_mtu); - } else { - slave->dev->mtu = new_mtu; - res = 0; - } + res = dev_set_mtu(slave->dev, new_mtu); if (res) { /* If we failed to set the slave's mtu to the new value @@ -3929,14 +3924,10 @@ bond_for_each_slave_from_to(bond, slave, i, bond->first_slave, stop_at) { int tmp_res; - if (slave->dev->change_mtu) { - tmp_res = slave->dev->change_mtu(slave->dev, bond_dev->mtu); - if (tmp_res) { - dprintk("unwind err %d dev %s\n", tmp_res, - slave->dev->name); - } - } else { - slave->dev->mtu = bond_dev->mtu; + tmp_res = dev_set_mtu(slave->dev, bond_dev->mtu); + if (tmp_res) { + dprintk("unwind err %d dev %s\n", tmp_res, + slave->dev->name); } } @@ -3988,7 +3979,7 @@ goto unwind; } - res = slave->dev->set_mac_address(slave->dev, addr); + res = dev_set_mac_address(slave->dev, addr); if (res) { /* TODO: consider downing the slave * and retry ? @@ -4014,7 +4005,7 @@ bond_for_each_slave_from_to(bond, slave, i, bond->first_slave, stop_at) { int tmp_res; - tmp_res = slave->dev->set_mac_address(slave->dev, &tmp_sa); + tmp_res = dev_set_mac_address(slave->dev, &tmp_sa); if (tmp_res) { dprintk("unwind err %d dev %s\n", tmp_res, slave->dev->name); diff -Nru a/drivers/net/e100.c b/drivers/net/e100.c --- a/drivers/net/e100.c 2005-03-07 12:09:08 -05:00 +++ b/drivers/net/e100.c 2005-03-07 12:09:08 -05:00 @@ -2310,7 +2310,7 @@ } #ifdef CONFIG_PM -static int e100_suspend(struct pci_dev *pdev, u32 state) +static int e100_suspend(struct pci_dev *pdev, pm_message_t state) { struct net_device *netdev = pci_get_drvdata(pdev); struct nic *nic = netdev_priv(netdev); @@ -2321,7 +2321,7 @@ netif_device_detach(netdev); pci_save_state(pdev); - pci_enable_wake(pdev, state, nic->flags & (wol_magic | e100_asf(nic))); + pci_enable_wake(pdev, pci_choose_state(pdev, state), nic->flags & (wol_magic | e100_asf(nic))); pci_disable_device(pdev); pci_set_power_state(pdev, pci_choose_state(pdev, state)); diff -Nru a/drivers/net/eepro100.c b/drivers/net/eepro100.c --- a/drivers/net/eepro100.c 2005-03-07 12:09:08 -05:00 +++ b/drivers/net/eepro100.c 2005-03-07 12:09:08 -05:00 @@ -2281,7 +2281,7 @@ } #ifdef CONFIG_PM -static int eepro100_suspend(struct pci_dev *pdev, u32 state) +static int eepro100_suspend(struct pci_dev *pdev, pm_message_t state) { struct net_device *dev = pci_get_drvdata (pdev); struct speedo_private *sp = netdev_priv(dev); @@ -2299,7 +2299,7 @@ /* XXX call pci_set_power_state ()? */ pci_disable_device(pdev); - pci_set_power_state (pdev, 3); + pci_set_power_state (pdev, PCI_D3hot); return 0; } @@ -2309,7 +2309,7 @@ struct speedo_private *sp = netdev_priv(dev); void __iomem *ioaddr = sp->regs; - pci_set_power_state(pdev, 0); + pci_set_power_state(pdev, PCI_D0); pci_restore_state(pdev); pci_enable_device(pdev); pci_set_master(pdev); diff -Nru a/drivers/net/epic100.c b/drivers/net/epic100.c --- a/drivers/net/epic100.c 2005-03-07 12:09:08 -05:00 +++ b/drivers/net/epic100.c 2005-03-07 12:09:08 -05:00 @@ -1624,7 +1624,7 @@ #ifdef CONFIG_PM -static int epic_suspend (struct pci_dev *pdev, u32 state) +static int epic_suspend (struct pci_dev *pdev, pm_message_t state) { struct net_device *dev = pci_get_drvdata(pdev); long ioaddr = dev->base_addr; diff -Nru a/drivers/net/ibmlana.c b/drivers/net/ibmlana.c --- a/drivers/net/ibmlana.c 2005-03-07 12:09:08 -05:00 +++ b/drivers/net/ibmlana.c 2005-03-07 12:09:08 -05:00 @@ -133,13 +133,14 @@ static void dumpmem(struct net_device *dev, u32 start, u32 len) { + ibmlana_priv *priv = netdev_priv(dev); int z; printk("Address %04x:\n", start); for (z = 0; z < len; z++) { if ((z & 15) == 0) printk("%04x:", z); - printk(" %02x", isa_readb(dev->mem_start + start + z)); + printk(" %02x", readb(priv->base + start + z)); if ((z & 15) == 15) printk("\n"); } @@ -231,7 +232,7 @@ static void InitDscrs(struct net_device *dev) { - ibmlana_priv *priv = (ibmlana_priv *) dev->priv; + ibmlana_priv *priv = netdev_priv(dev); u32 addr, baddr, raddr; int z; tda_t tda; @@ -240,8 +241,8 @@ /* initialize RAM */ - isa_memset_io(dev->mem_start, 0xaa, - dev->mem_start - dev->mem_start); + memset_io(priv->base, 0xaa, + dev->mem_start - dev->mem_start); /* XXX: typo? */ /* setup n TX descriptors - independent of RAM size */ @@ -260,7 +261,7 @@ else tda.link = addr + sizeof(tda_t); tda.link |= 1; - isa_memcpy_toio(dev->mem_start + addr, &tda, sizeof(tda_t)); + memcpy_toio(priv->base + addr, &tda, sizeof(tda_t)); addr += sizeof(tda_t); baddr += PKTSIZE; } @@ -280,7 +281,7 @@ rra.starthi = 0; rra.cntlo = PKTSIZE >> 1; rra.cnthi = 0; - isa_memcpy_toio(dev->mem_start + raddr, &rra, sizeof(rra_t)); + memcpy_toio(priv->base + raddr, &rra, sizeof(rra_t)); rda.status = 0; rda.length = 0; @@ -292,7 +293,7 @@ else rda.link = 1; rda.inuse = 1; - isa_memcpy_toio(dev->mem_start + addr, &rda, sizeof(rda_t)); + memcpy_toio(priv->base + addr, &rda, sizeof(rda_t)); baddr += PKTSIZE; raddr += sizeof(rra_t); @@ -313,7 +314,7 @@ static int InitSONIC(struct net_device *dev) { - ibmlana_priv *priv = (ibmlana_priv *) dev->priv; + ibmlana_priv *priv = netdev_priv(dev); /* set up start & end of resource area */ @@ -379,6 +380,7 @@ static void InitBoard(struct net_device *dev) { + ibmlana_priv *priv = netdev_priv(dev); int camcnt; camentry_t cams[16]; u32 cammask; @@ -429,8 +431,8 @@ /* feed CDA into SONIC, initialize RCR value (always get broadcasts) */ - isa_memcpy_toio(dev->mem_start, cams, sizeof(camentry_t) * camcnt); - isa_memcpy_toio(dev->mem_start + (sizeof(camentry_t) * camcnt), &cammask, sizeof(cammask)); + memcpy_toio(priv->base, cams, sizeof(camentry_t) * camcnt); + memcpy_toio(priv->base + (sizeof(camentry_t) * camcnt), &cammask, sizeof(cammask)); #ifdef DEBUG printk("CAM setup:\n"); @@ -520,7 +522,7 @@ static void StartTx(struct net_device *dev, int descr) { - ibmlana_priv *priv = (ibmlana_priv *) dev->priv; + ibmlana_priv *priv = netdev_priv(dev); int addr; addr = priv->tdastart + (descr * sizeof(tda_t)); @@ -543,7 +545,7 @@ static void irqrbe_handler(struct net_device *dev) { - ibmlana_priv *priv = (ibmlana_priv *) dev->priv; + ibmlana_priv *priv = netdev_priv(dev); /* point the SONIC back to the RRA start */ @@ -555,7 +557,7 @@ static void irqrx_handler(struct net_device *dev) { - ibmlana_priv *priv = (ibmlana_priv *) dev->priv; + ibmlana_priv *priv = netdev_priv(dev); rda_t rda; u32 rdaaddr, lrdaaddr; @@ -566,7 +568,7 @@ rdaaddr = priv->rdastart + (priv->nextrxdescr * sizeof(rda_t)); lrdaaddr = priv->rdastart + (priv->lastrxdescr * sizeof(rda_t)); - isa_memcpy_fromio(&rda, dev->mem_start + rdaaddr, sizeof(rda_t)); + memcpy_fromio(&rda, priv->base + rdaaddr, sizeof(rda_t)); /* iron out upper word halves of fields we use - SONIC will duplicate bits 0..15 to 16..31 */ @@ -593,8 +595,8 @@ else { /* copy out data */ - isa_memcpy_fromio(skb_put(skb, rda.length), - dev->mem_start + + memcpy_fromio(skb_put(skb, rda.length), + priv->base + rda.startlo, rda.length); /* set up skb fields */ @@ -627,14 +629,14 @@ rda.link = 1; rda.inuse = 1; - isa_memcpy_toio(dev->mem_start + rdaaddr, &rda, + memcpy_toio(priv->base + rdaaddr, &rda, sizeof(rda_t)); /* set up link and EOL = 0 in currently last descriptor. Only write the link field since the SONIC may currently already access the other fields. */ - isa_memcpy_toio(dev->mem_start + lrdaaddr + 20, &rdaaddr, 4); + memcpy_toio(priv->base + lrdaaddr + 20, &rdaaddr, 4); /* advance indices */ @@ -648,11 +650,11 @@ static void irqtx_handler(struct net_device *dev) { - ibmlana_priv *priv = (ibmlana_priv *) dev->priv; + ibmlana_priv *priv = netdev_priv(dev); tda_t tda; /* fetch descriptor (we forgot the size ;-) */ - isa_memcpy_fromio(&tda, dev->mem_start + priv->tdastart + (priv->currtxdescr * sizeof(tda_t)), sizeof(tda_t)); + memcpy_fromio(&tda, priv->base + priv->tdastart + (priv->currtxdescr * sizeof(tda_t)), sizeof(tda_t)); /* update statistics */ priv->stat.tx_packets++; @@ -672,11 +674,11 @@ static void irqtxerr_handler(struct net_device *dev) { - ibmlana_priv *priv = (ibmlana_priv *) dev->priv; + ibmlana_priv *priv = netdev_priv(dev); tda_t tda; /* fetch descriptor to check status */ - isa_memcpy_fromio(&tda, dev->mem_start + priv->tdastart + (priv->currtxdescr * sizeof(tda_t)), sizeof(tda_t)); + memcpy_fromio(&tda, priv->base + priv->tdastart + (priv->currtxdescr * sizeof(tda_t)), sizeof(tda_t)); /* update statistics */ priv->stat.tx_errors++; @@ -753,9 +755,7 @@ if (dev == NULL) return len; - if (dev->priv == NULL) - return len; - priv = (ibmlana_priv *) dev->priv; + priv = netdev_priv(dev); /* print info */ @@ -778,7 +778,7 @@ static int ibmlana_open(struct net_device *dev) { int result; - ibmlana_priv *priv = (ibmlana_priv *) dev->priv; + ibmlana_priv *priv = netdev_priv(dev); /* register resources - only necessary for IRQ */ @@ -814,7 +814,7 @@ static int ibmlana_tx(struct sk_buff *skb, struct net_device *dev) { - ibmlana_priv *priv = (ibmlana_priv *) dev->priv; + ibmlana_priv *priv = netdev_priv(dev); int retval = 0, tmplen, addr; unsigned long flags; tda_t tda; @@ -834,7 +834,7 @@ if (tmplen < 60) tmplen = 60; baddr = priv->txbufstart + (priv->nexttxdescr * PKTSIZE); - isa_memcpy_toio(dev->mem_start + baddr, skb->data, skb->len); + memcpy_toio(priv->base + baddr, skb->data, skb->len); /* copy filler into RAM - in case we're filling up... we're filling a bit more than necessary, but that doesn't harm @@ -846,16 +846,16 @@ unsigned int destoffs = skb->len, l = strlen(fill); while (destoffs < tmplen) { - isa_memcpy_toio(dev->mem_start + baddr + destoffs, fill, l); + memcpy_toio(priv->base + baddr + destoffs, fill, l); destoffs += l; } } /* set up the new frame descriptor */ addr = priv->tdastart + (priv->nexttxdescr * sizeof(tda_t)); - isa_memcpy_fromio(&tda, dev->mem_start + addr, sizeof(tda_t)); + memcpy_fromio(&tda, priv->base + addr, sizeof(tda_t)); tda.length = tda.fraglength = tmplen; - isa_memcpy_toio(dev->mem_start + addr, &tda, sizeof(tda_t)); + memcpy_toio(priv->base + addr, &tda, sizeof(tda_t)); /* if there were no active descriptors, trigger the SONIC */ spin_lock_irqsave(&priv->lock, flags); @@ -881,7 +881,7 @@ static struct net_device_stats *ibmlana_stats(struct net_device *dev) { - ibmlana_priv *priv = (ibmlana_priv *) dev->priv; + ibmlana_priv *priv = netdev_priv(dev); return &priv->stat; } @@ -903,7 +903,6 @@ static int ibmlana_probe(struct net_device *dev) { - int force_detect = 0; int slot, z; int base = 0, irq = 0, iobase = 0, memlen = 0; ibmlana_priv *priv; @@ -915,10 +914,6 @@ if (MCA_bus == 0) return -ENODEV; - /* start address of 1 --> forced detection */ - if (dev->mem_start == 1) - force_detect = 1; - base = dev->mem_start; irq = dev->irq; @@ -952,18 +947,12 @@ return -EBUSY; } - /* make procfs entries */ - mca_set_adapter_name(slot, "IBM LAN Adapter/A"); - mca_set_adapter_procfn(slot, (MCA_ProcFn) ibmlana_getinfo, dev); - - mca_mark_as_used(slot); - - /* allocate structure */ - priv = dev->priv; + priv = netdev_priv(dev); priv->slot = slot; priv->realirq = irq; priv->medium = medium; spin_lock_init(&priv->lock); + /* set base + irq for this device (irq not allocated so far) */ @@ -972,6 +961,20 @@ dev->mem_end = base + memlen; dev->base_addr = iobase; + priv->base = ioremap(base, memlen); + if (!priv->base) { + printk(KERN_ERR "%s: cannot remap memory!\n", DRV_NAME); + startslot = slot + 1; + release_region(iobase, IBM_LANA_IORANGE); + return -EBUSY; + } + + /* make procfs entries */ + mca_set_adapter_name(slot, "IBM LAN Adapter/A"); + mca_set_adapter_procfn(slot, (MCA_ProcFn) ibmlana_getinfo, dev); + + mca_mark_as_used(slot); + /* set methods */ dev->open = ibmlana_open; @@ -1042,11 +1045,12 @@ break; } if (register_netdev(dev)) { - ibmlana_priv *priv = dev->priv; + ibmlana_priv *priv = netdev_priv(dev); release_region(dev->base_addr, IBM_LANA_IORANGE); mca_mark_as_unused(priv->slot); mca_set_adapter_name(priv->slot, ""); mca_set_adapter_procfn(priv->slot, NULL, NULL); + iounmap(priv->base); free_netdev(dev); break; } @@ -1061,13 +1065,14 @@ for (z = 0; z < DEVMAX; z++) { struct net_device *dev = moddevs[z]; if (dev) { - ibmlana_priv *priv = (ibmlana_priv *) dev->priv; + ibmlana_priv *priv = netdev_priv(dev); unregister_netdev(dev); /*DeinitBoard(dev); */ release_region(dev->base_addr, IBM_LANA_IORANGE); mca_mark_as_unused(priv->slot); mca_set_adapter_name(priv->slot, ""); mca_set_adapter_procfn(priv->slot, NULL, NULL); + iounmap(priv->base); free_netdev(dev); } } diff -Nru a/drivers/net/ibmlana.h b/drivers/net/ibmlana.h --- a/drivers/net/ibmlana.h 2005-03-07 12:09:08 -05:00 +++ b/drivers/net/ibmlana.h 2005-03-07 12:09:08 -05:00 @@ -37,6 +37,7 @@ nexttxdescr, /* last tx descriptor to be used */ currtxdescr, /* tx descriptor currently tx'ed */ txused[TXBUFCNT]; /* busy flags */ + void __iomem *base; spinlock_t lock; } ibmlana_priv; diff -Nru a/drivers/net/irda/donauboe.c b/drivers/net/irda/donauboe.c --- a/drivers/net/irda/donauboe.c 2005-03-07 12:09:08 -05:00 +++ b/drivers/net/irda/donauboe.c 2005-03-07 12:09:08 -05:00 @@ -1712,7 +1712,7 @@ } static int -toshoboe_gotosleep (struct pci_dev *pci_dev, u32 crap) +toshoboe_gotosleep (struct pci_dev *pci_dev, pm_message_t crap) { struct toshoboe_cb *self = (struct toshoboe_cb*)pci_get_drvdata(pci_dev); unsigned long flags; diff -Nru a/drivers/net/mii.c b/drivers/net/mii.c --- a/drivers/net/mii.c 2005-03-07 12:09:08 -05:00 +++ b/drivers/net/mii.c 2005-03-07 12:09:08 -05:00 @@ -37,6 +37,7 @@ { struct net_device *dev = mii->dev; u32 advert, bmcr, lpa, nego; + u32 advert2 = 0, bmcr2 = 0, lpa2 = 0; ecmd->supported = (SUPPORTED_10baseT_Half | SUPPORTED_10baseT_Full | @@ -54,6 +55,9 @@ ecmd->advertising = ADVERTISED_TP | ADVERTISED_MII; advert = mii->mdio_read(dev, mii->phy_id, MII_ADVERTISE); + if (mii->supports_gmii) + advert2 = mii->mdio_read(dev, mii->phy_id, MII_CTRL1000); + if (advert & ADVERTISE_10HALF) ecmd->advertising |= ADVERTISED_10baseT_Half; if (advert & ADVERTISE_10FULL) @@ -62,19 +66,31 @@ ecmd->advertising |= ADVERTISED_100baseT_Half; if (advert & ADVERTISE_100FULL) ecmd->advertising |= ADVERTISED_100baseT_Full; + if (advert2 & ADVERTISE_1000HALF) + ecmd->advertising |= ADVERTISED_1000baseT_Half; + if (advert2 & ADVERTISE_1000FULL) + ecmd->advertising |= ADVERTISED_1000baseT_Full; bmcr = mii->mdio_read(dev, mii->phy_id, MII_BMCR); lpa = mii->mdio_read(dev, mii->phy_id, MII_LPA); + if (mii->supports_gmii) { + bmcr2 = mii->mdio_read(dev, mii->phy_id, MII_CTRL1000); + lpa2 = mii->mdio_read(dev, mii->phy_id, MII_STAT1000); + } if (bmcr & BMCR_ANENABLE) { ecmd->advertising |= ADVERTISED_Autoneg; ecmd->autoneg = AUTONEG_ENABLE; nego = mii_nway_result(advert & lpa); - if (nego == LPA_100FULL || nego == LPA_100HALF) + if ((bmcr2 & (ADVERTISE_1000HALF | ADVERTISE_1000FULL)) & + (lpa2 >> 2)) + ecmd->speed = SPEED_1000; + else if (nego == LPA_100FULL || nego == LPA_100HALF) ecmd->speed = SPEED_100; else ecmd->speed = SPEED_10; - if (nego == LPA_100FULL || nego == LPA_10FULL) { + if ((lpa2 & LPA_1000FULL) || nego == LPA_100FULL || + nego == LPA_10FULL) { ecmd->duplex = DUPLEX_FULL; mii->full_duplex = 1; } else { @@ -84,7 +100,9 @@ } else { ecmd->autoneg = AUTONEG_DISABLE; - ecmd->speed = (bmcr & BMCR_SPEED100) ? SPEED_100 : SPEED_10; + ecmd->speed = ((bmcr2 & BMCR_SPEED1000 && + (bmcr & BMCR_SPEED100) == 0) ? SPEED_1000 : + (bmcr & BMCR_SPEED100) ? SPEED_100 : SPEED_10); ecmd->duplex = (bmcr & BMCR_FULLDPLX) ? DUPLEX_FULL : DUPLEX_HALF; } @@ -97,7 +115,9 @@ { struct net_device *dev = mii->dev; - if (ecmd->speed != SPEED_10 && ecmd->speed != SPEED_100) + if (ecmd->speed != SPEED_10 && + ecmd->speed != SPEED_100 && + ecmd->speed != SPEED_1000) return -EINVAL; if (ecmd->duplex != DUPLEX_HALF && ecmd->duplex != DUPLEX_FULL) return -EINVAL; @@ -109,21 +129,30 @@ return -EINVAL; if (ecmd->autoneg != AUTONEG_DISABLE && ecmd->autoneg != AUTONEG_ENABLE) return -EINVAL; + if ((ecmd->speed == SPEED_1000) && (!mii->supports_gmii)) + return -EINVAL; /* ignore supported, maxtxpkt, maxrxpkt */ if (ecmd->autoneg == AUTONEG_ENABLE) { u32 bmcr, advert, tmp; + u32 advert2 = 0, tmp2 = 0; if ((ecmd->advertising & (ADVERTISED_10baseT_Half | ADVERTISED_10baseT_Full | ADVERTISED_100baseT_Half | - ADVERTISED_100baseT_Full)) == 0) + ADVERTISED_100baseT_Full | + ADVERTISED_1000baseT_Half | + ADVERTISED_1000baseT_Full)) == 0) return -EINVAL; /* advertise only what has been requested */ advert = mii->mdio_read(dev, mii->phy_id, MII_ADVERTISE); tmp = advert & ~(ADVERTISE_ALL | ADVERTISE_100BASE4); + if (mii->supports_gmii) { + advert2 = mii->mdio_read(dev, mii->phy_id, MII_CTRL1000); + tmp2 = advert2 & ~(ADVERTISE_1000HALF | ADVERTISE_1000FULL); + } if (ecmd->advertising & ADVERTISED_10baseT_Half) tmp |= ADVERTISE_10HALF; if (ecmd->advertising & ADVERTISED_10baseT_Full) @@ -132,10 +161,18 @@ tmp |= ADVERTISE_100HALF; if (ecmd->advertising & ADVERTISED_100baseT_Full) tmp |= ADVERTISE_100FULL; + if (mii->supports_gmii) { + if (ecmd->advertising & ADVERTISED_1000baseT_Half) + advert2 |= ADVERTISE_1000HALF; + if (ecmd->advertising & ADVERTISED_1000baseT_Full) + advert2 |= ADVERTISE_1000FULL; + } if (advert != tmp) { mii->mdio_write(dev, mii->phy_id, MII_ADVERTISE, tmp); mii->advertising = tmp; } + if ((mii->supports_gmii) && (advert2 != tmp2)) + mii->mdio_write(dev, mii->phy_id, MII_CTRL1000, tmp2); /* turn on autonegotiation, and force a renegotiate */ bmcr = mii->mdio_read(dev, mii->phy_id, MII_BMCR); @@ -148,8 +185,11 @@ /* turn off auto negotiation, set speed and duplexity */ bmcr = mii->mdio_read(dev, mii->phy_id, MII_BMCR); - tmp = bmcr & ~(BMCR_ANENABLE | BMCR_SPEED100 | BMCR_FULLDPLX); - if (ecmd->speed == SPEED_100) + tmp = bmcr & ~(BMCR_ANENABLE | BMCR_SPEED100 | + BMCR_SPEED1000 | BMCR_FULLDPLX); + if (ecmd->speed == SPEED_1000) + tmp |= BMCR_SPEED1000; + else if (ecmd->speed == SPEED_100) tmp |= BMCR_SPEED100; if (ecmd->duplex == DUPLEX_FULL) { tmp |= BMCR_FULLDPLX; @@ -207,6 +247,7 @@ { unsigned int old_carrier, new_carrier; int advertise, lpa, media, duplex; + int lpa2 = 0; /* if forced media, go no further */ if (mii->force_media) @@ -243,16 +284,20 @@ mii->advertising = advertise; } lpa = mii->mdio_read(mii->dev, mii->phy_id, MII_LPA); + if (mii->supports_gmii) + lpa2 = mii->mdio_read(mii->dev, mii->phy_id, MII_STAT1000); /* figure out media and duplex from advertise and LPA values */ media = mii_nway_result(lpa & advertise); duplex = (media & ADVERTISE_FULL) ? 1 : 0; + if (lpa2 & LPA_1000FULL) + duplex = 1; if (ok_to_print) printk(KERN_INFO "%s: link up, %sMbps, %s-duplex, lpa 0x%04X\n", mii->dev->name, - media & (ADVERTISE_100FULL | ADVERTISE_100HALF) ? - "100" : "10", + lpa2 & (LPA_1000FULL | LPA_1000HALF) ? "1000" : + media & (ADVERTISE_100FULL | ADVERTISE_100HALF) ? "100" : "10", duplex ? "full" : "half", lpa); diff -Nru a/drivers/net/natsemi.c b/drivers/net/natsemi.c --- a/drivers/net/natsemi.c 2005-03-07 12:09:08 -05:00 +++ b/drivers/net/natsemi.c 2005-03-07 12:09:08 -05:00 @@ -3162,7 +3162,7 @@ * Interrupts must be disabled, otherwise hands_off can cause irq storms. */ -static int natsemi_suspend (struct pci_dev *pdev, u32 state) +static int natsemi_suspend (struct pci_dev *pdev, pm_message_t state) { struct net_device *dev = pci_get_drvdata (pdev); struct netdev_private *np = netdev_priv(dev); diff -Nru a/drivers/net/ne2k-pci.c b/drivers/net/ne2k-pci.c --- a/drivers/net/ne2k-pci.c 2005-03-07 12:09:08 -05:00 +++ b/drivers/net/ne2k-pci.c 2005-03-07 12:09:08 -05:00 @@ -654,13 +654,13 @@ } #ifdef CONFIG_PM -static int ne2k_pci_suspend (struct pci_dev *pdev, u32 state) +static int ne2k_pci_suspend (struct pci_dev *pdev, pm_message_t state) { struct net_device *dev = pci_get_drvdata (pdev); netif_device_detach(dev); pci_save_state(pdev); - pci_set_power_state(pdev, state); + pci_set_power_state(pdev, pci_choose_state(pdev, state)); return 0; } diff -Nru a/drivers/net/s2io.c b/drivers/net/s2io.c --- a/drivers/net/s2io.c 2005-03-07 12:09:08 -05:00 +++ b/drivers/net/s2io.c 2005-03-07 12:09:08 -05:00 @@ -699,8 +699,7 @@ val64 = 0; writeq(val64, &bar0->sw_reset); val64 = readq(&bar0->sw_reset); - set_current_state(TASK_UNINTERRUPTIBLE); - schedule_timeout(HZ / 2); + msleep(500); /* Enable Receiving broadcasts */ add = &bar0->mac_cfg; @@ -953,8 +952,7 @@ dev->name); return -1; } - set_current_state(TASK_UNINTERRUPTIBLE); - schedule_timeout(HZ / 20); + msleep(50); time++; } @@ -992,8 +990,7 @@ return -1; } time++; - set_current_state(TASK_UNINTERRUPTIBLE); - schedule_timeout(HZ / 20); + msleep(50); } /* @@ -1422,8 +1419,7 @@ SPECIAL_REG_WRITE(val64, &bar0->mc_rldram_mrs, UF); val64 = readq(&bar0->mc_rldram_mrs); - set_current_state(TASK_UNINTERRUPTIBLE); - schedule_timeout(HZ / 10); /* Delay by around 100 ms. */ + msleep(100); /* Delay by around 100 ms. */ /* Enabling ECC Protection. */ val64 = readq(&bar0->adapter_control); @@ -2438,8 +2434,7 @@ ret = SUCCESS; break; } - set_current_state(TASK_UNINTERRUPTIBLE); - schedule_timeout(HZ / 20); + msleep(50); if (cnt++ > 10) break; } @@ -2478,15 +2473,13 @@ * As of now I'am just giving a 250ms delay and hoping that the * PCI write to sw_reset register is done by this time. */ - set_current_state(TASK_UNINTERRUPTIBLE); - schedule_timeout(HZ / 4); + msleep(250); /* Restore the PCI state saved during initializarion. */ pci_restore_state(sp->pdev); s2io_init_pci(sp); - set_current_state(TASK_UNINTERRUPTIBLE); - schedule_timeout(HZ / 4); + msleep(250); /* SXE-002: Configure link and activity LED to turn it off */ subid = sp->pdev->subsystem_device; @@ -3304,11 +3297,10 @@ sp->id_timer.data = (unsigned long) sp; } mod_timer(&sp->id_timer, jiffies); - set_current_state(TASK_INTERRUPTIBLE); if (data) - schedule_timeout(data * HZ); + msleep(data * 1000); else - schedule_timeout(MAX_SCHEDULE_TIMEOUT); + msleep(0xFFFFFFFF); del_timer_sync(&sp->id_timer); if (CARDS_WITH_FAULTY_LINK_INDICATORS(subid)) { @@ -3411,8 +3403,7 @@ ret = 0; break; } - set_current_state(TASK_UNINTERRUPTIBLE); - schedule_timeout(HZ / 20); + msleep(50); exit_cnt++; } @@ -3452,8 +3443,7 @@ ret = 0; break; } - set_current_state(TASK_UNINTERRUPTIBLE); - schedule_timeout(HZ / 20); + msleep(50); exit_cnt++; } @@ -3709,8 +3699,7 @@ ret = 0; break; } - set_current_state(TASK_UNINTERRUPTIBLE); - schedule_timeout(HZ / 10); + msleep(100); cnt++; } @@ -3811,8 +3800,7 @@ val64 = readq(&bar0->mc_rldram_test_ctrl); if (val64 & MC_RLDRAM_TEST_DONE) break; - set_current_state(TASK_UNINTERRUPTIBLE); - schedule_timeout(HZ / 5); + msleep(200); } if (cnt == 5) @@ -3828,8 +3816,7 @@ val64 = readq(&bar0->mc_rldram_test_ctrl); if (val64 & MC_RLDRAM_TEST_DONE) break; - set_current_state(TASK_UNINTERRUPTIBLE); - schedule_timeout(HZ / 2); + msleep(500); } if (cnt == 5) @@ -4189,8 +4176,7 @@ * Allow a small delay for the NICs self initiated * cleanup to complete. */ - set_current_state(TASK_UNINTERRUPTIBLE); - schedule_timeout(HZ / 10); + msleep(100); val64 = readq(&bar0->adapter_status); if (verify_xena_quiescence(val64, nic->device_enabled_once)) { @@ -4244,10 +4230,8 @@ register u64 val64 = 0; /* If s2io_set_link task is executing, wait till it completes. */ - while (test_and_set_bit(0, &(sp->link_state))) { - set_current_state(TASK_UNINTERRUPTIBLE); - schedule_timeout(HZ / 20); - } + while (test_and_set_bit(0, &(sp->link_state))) + msleep(50); atomic_set(&sp->card_state, CARD_DOWN); /* disable Tx and Rx traffic on the NIC */ @@ -4263,8 +4247,7 @@ break; } - set_current_state(TASK_UNINTERRUPTIBLE); - schedule_timeout(HZ / 20); + msleep(50); cnt++; if (cnt == 10) { DBG_PRINT(ERR_DBG, diff -Nru a/drivers/net/sis900.c b/drivers/net/sis900.c --- a/drivers/net/sis900.c 2005-03-07 12:09:08 -05:00 +++ b/drivers/net/sis900.c 2005-03-07 12:09:08 -05:00 @@ -2226,7 +2226,7 @@ #ifdef CONFIG_PM -static int sis900_suspend(struct pci_dev *pci_dev, u32 state) +static int sis900_suspend(struct pci_dev *pci_dev, pm_message_t state) { struct net_device *net_dev = pci_get_drvdata(pci_dev); long ioaddr = net_dev->base_addr; diff -Nru a/drivers/net/sk_mca.c b/drivers/net/sk_mca.c --- a/drivers/net/sk_mca.c 2005-03-07 12:09:08 -05:00 +++ b/drivers/net/sk_mca.c 2005-03-07 12:09:08 -05:00 @@ -127,12 +127,13 @@ #ifdef DEBUG static void dumpmem(struct net_device *dev, u32 start, u32 len) { + skmca_priv *priv = netdev_priv(dev); int z; for (z = 0; z < len; z++) { if ((z & 15) == 0) printk("%04x:", z); - printk(" %02x", SKMCA_READB(dev->mem_start + start + z)); + printk(" %02x", readb(priv->base + start + z)); if ((z & 15) == 15) printk("\n"); } @@ -220,21 +221,21 @@ static void ResetBoard(struct net_device *dev) { - skmca_priv *priv = (skmca_priv *) dev->priv; + skmca_priv *priv = netdev_priv(dev); - SKMCA_WRITEB(CTRL_RESET_ON, priv->ctrladdr); + writeb(CTRL_RESET_ON, priv->ctrladdr); udelay(10); - SKMCA_WRITEB(CTRL_RESET_OFF, priv->ctrladdr); + writeb(CTRL_RESET_OFF, priv->ctrladdr); } /* wait for LANCE interface to become not busy */ static int WaitLANCE(struct net_device *dev) { - skmca_priv *priv = (skmca_priv *) dev->priv; + skmca_priv *priv = netdev_priv(dev); int t = 0; - while ((SKMCA_READB(priv->ctrladdr) & STAT_IO_BUSY) == + while ((readb(priv->ctrladdr) & STAT_IO_BUSY) == STAT_IO_BUSY) { udelay(1); if (++t > 1000) { @@ -250,7 +251,7 @@ static void SetLANCE(struct net_device *dev, u16 addr, u16 value) { - skmca_priv *priv = (skmca_priv *) dev->priv; + skmca_priv *priv = netdev_priv(dev); unsigned long flags; /* disable interrupts */ @@ -263,19 +264,17 @@ /* transfer register address to RAP */ - SKMCA_WRITEB(CTRL_RESET_OFF | CTRL_RW_WRITE | CTRL_ADR_RAP, - priv->ctrladdr); - SKMCA_WRITEW(addr, priv->ioregaddr); - SKMCA_WRITEB(IOCMD_GO, priv->cmdaddr); + writeb(CTRL_RESET_OFF | CTRL_RW_WRITE | CTRL_ADR_RAP, priv->ctrladdr); + writew(addr, priv->ioregaddr); + writeb(IOCMD_GO, priv->cmdaddr); udelay(1); WaitLANCE(dev); /* transfer data to register */ - SKMCA_WRITEB(CTRL_RESET_OFF | CTRL_RW_WRITE | CTRL_ADR_DATA, - priv->ctrladdr); - SKMCA_WRITEW(value, priv->ioregaddr); - SKMCA_WRITEB(IOCMD_GO, priv->cmdaddr); + writeb(CTRL_RESET_OFF | CTRL_RW_WRITE | CTRL_ADR_DATA, priv->ctrladdr); + writew(value, priv->ioregaddr); + writeb(IOCMD_GO, priv->cmdaddr); udelay(1); WaitLANCE(dev); @@ -288,7 +287,7 @@ static u16 GetLANCE(struct net_device *dev, u16 addr) { - skmca_priv *priv = (skmca_priv *) dev->priv; + skmca_priv *priv = netdev_priv(dev); unsigned long flags; unsigned int res; @@ -302,21 +301,19 @@ /* transfer register address to RAP */ - SKMCA_WRITEB(CTRL_RESET_OFF | CTRL_RW_WRITE | CTRL_ADR_RAP, - priv->ctrladdr); - SKMCA_WRITEW(addr, priv->ioregaddr); - SKMCA_WRITEB(IOCMD_GO, priv->cmdaddr); + writeb(CTRL_RESET_OFF | CTRL_RW_WRITE | CTRL_ADR_RAP, priv->ctrladdr); + writew(addr, priv->ioregaddr); + writeb(IOCMD_GO, priv->cmdaddr); udelay(1); WaitLANCE(dev); /* transfer data from register */ - SKMCA_WRITEB(CTRL_RESET_OFF | CTRL_RW_READ | CTRL_ADR_DATA, - priv->ctrladdr); - SKMCA_WRITEB(IOCMD_GO, priv->cmdaddr); + writeb(CTRL_RESET_OFF | CTRL_RW_READ | CTRL_ADR_DATA, priv->ctrladdr); + writeb(IOCMD_GO, priv->cmdaddr); udelay(1); WaitLANCE(dev); - res = SKMCA_READW(priv->ioregaddr); + res = readw(priv->ioregaddr); /* reenable interrupts */ @@ -329,6 +326,7 @@ static void InitDscrs(struct net_device *dev) { + skmca_priv *priv = netdev_priv(dev); u32 bufaddr; /* Set up Tx descriptors. The board has only 16K RAM so bits 16..23 @@ -344,11 +342,10 @@ descr.Flags = 0; descr.Len = 0xf000; descr.Status = 0; - SKMCA_TOIO(dev->mem_start + RAM_TXBASE + + memcpy_toio(priv->base + RAM_TXBASE + (z * sizeof(LANCE_TxDescr)), &descr, sizeof(LANCE_TxDescr)); - SKMCA_SETIO(dev->mem_start + bufaddr, 0, - RAM_BUFSIZE); + memset_io(priv->base + bufaddr, 0, RAM_BUFSIZE); bufaddr += RAM_BUFSIZE; } } @@ -364,11 +361,10 @@ descr.Flags = RXDSCR_FLAGS_OWN; descr.MaxLen = -RAM_BUFSIZE; descr.Len = 0; - SKMCA_TOIO(dev->mem_start + RAM_RXBASE + + memcpy_toio(priv->base + RAM_RXBASE + (z * sizeof(LANCE_RxDescr)), &descr, sizeof(LANCE_RxDescr)); - SKMCA_SETIO(dev->mem_start + bufaddr, 0, - RAM_BUFSIZE); + memset_io(priv->base + bufaddr, 0, RAM_BUFSIZE); bufaddr += RAM_BUFSIZE; } } @@ -425,7 +421,7 @@ static void InitLANCE(struct net_device *dev) { - skmca_priv *priv = (skmca_priv *) dev->priv; + skmca_priv *priv = netdev_priv(dev); /* build up descriptors. */ @@ -478,6 +474,7 @@ static void InitBoard(struct net_device *dev) { + skmca_priv *priv = netdev_priv(dev); LANCE_InitBlock block; /* Lay out the shared RAM - first we create the init block for the LANCE. @@ -492,7 +489,7 @@ block.RdrP = (RAM_RXBASE & 0xffffff) | (LRXCOUNT << 29); block.TdrP = (RAM_TXBASE & 0xffffff) | (LTXCOUNT << 29); - SKMCA_TOIO(dev->mem_start + RAM_INITBASE, &block, sizeof(block)); + memcpy_toio(priv->base + RAM_INITBASE, &block, sizeof(block)); /* initialize LANCE. Implicitly sets up other structures in RAM. */ @@ -572,7 +569,7 @@ static u16 irqmiss_handler(struct net_device *dev, u16 oldcsr0) { - skmca_priv *priv = (skmca_priv *) dev->priv; + skmca_priv *priv = netdev_priv(dev); /* update statistics */ @@ -588,7 +585,7 @@ static u16 irqrx_handler(struct net_device *dev, u16 oldcsr0) { - skmca_priv *priv = (skmca_priv *) dev->priv; + skmca_priv *priv = netdev_priv(dev); LANCE_RxDescr descr; unsigned int descraddr; @@ -597,7 +594,7 @@ descraddr = RAM_RXBASE + (priv->nextrx * sizeof(LANCE_RxDescr)); while (1) { /* read descriptor */ - SKMCA_FROMIO(&descr, dev->mem_start + descraddr, + memcpy_fromio(&descr, priv->base + descraddr, sizeof(LANCE_RxDescr)); /* if we reach a descriptor we do not own, we're done */ @@ -629,8 +626,8 @@ if (skb == NULL) priv->stat.rx_dropped++; else { - SKMCA_FROMIO(skb_put(skb, descr.Len), - dev->mem_start + + memcpy_fromio(skb_put(skb, descr.Len), + priv->base + descr.LowAddr, descr.Len); skb->dev = dev; skb->protocol = eth_type_trans(skb, dev); @@ -647,7 +644,7 @@ descr.Flags |= RXDSCR_FLAGS_OWN; /* update descriptor in shared RAM */ - SKMCA_TOIO(dev->mem_start + descraddr, &descr, + memcpy_toio(priv->base + descraddr, &descr, sizeof(LANCE_RxDescr)); /* go to next descriptor */ @@ -669,7 +666,7 @@ static u16 irqtx_handler(struct net_device *dev, u16 oldcsr0) { - skmca_priv *priv = (skmca_priv *) dev->priv; + skmca_priv *priv = netdev_priv(dev); LANCE_TxDescr descr; unsigned int descraddr; @@ -679,7 +676,7 @@ RAM_TXBASE + (priv->nexttxdone * sizeof(LANCE_TxDescr)); while (priv->txbusy > 0) { /* read descriptor */ - SKMCA_FROMIO(&descr, dev->mem_start + descraddr, + memcpy_fromio(&descr, priv->base + descraddr, sizeof(LANCE_TxDescr)); /* if the LANCE still owns this one, we've worked out all sent packets */ @@ -798,9 +795,7 @@ if (dev == NULL) return len; - if (dev->priv == NULL) - return len; - priv = (skmca_priv *) dev->priv; + priv = netdev_priv(dev); /* print info */ @@ -825,7 +820,7 @@ static int skmca_open(struct net_device *dev) { int result; - skmca_priv *priv = (skmca_priv *) dev->priv; + skmca_priv *priv = netdev_priv(dev); /* register resources - only necessary for IRQ */ result = @@ -868,7 +863,7 @@ static int skmca_tx(struct sk_buff *skb, struct net_device *dev) { - skmca_priv *priv = (skmca_priv *) dev->priv; + skmca_priv *priv = netdev_priv(dev); LANCE_TxDescr descr; unsigned int address; int tmplen, retval = 0; @@ -894,8 +889,7 @@ /* get TX descriptor */ address = RAM_TXBASE + (priv->nexttxput * sizeof(LANCE_TxDescr)); - SKMCA_FROMIO(&descr, dev->mem_start + address, - sizeof(LANCE_TxDescr)); + memcpy_fromio(&descr, priv->base + address, sizeof(LANCE_TxDescr)); /* enter packet length as 2s complement - assure minimum length */ tmplen = skb->len; @@ -911,14 +905,14 @@ unsigned int destoffs = 0, l = strlen(fill); while (destoffs < tmplen) { - SKMCA_TOIO(dev->mem_start + descr.LowAddr + + memcpy_toio(priv->base + descr.LowAddr + destoffs, fill, l); destoffs += l; } } /* do the real data copying */ - SKMCA_TOIO(dev->mem_start + descr.LowAddr, skb->data, skb->len); + memcpy_toio(priv->base + descr.LowAddr, skb->data, skb->len); /* hand descriptor over to LANCE - this is the first and last chunk */ descr.Flags = @@ -945,8 +939,7 @@ netif_stop_queue(dev); /* write descriptor back to RAM */ - SKMCA_TOIO(dev->mem_start + address, &descr, - sizeof(LANCE_TxDescr)); + memcpy_toio(priv->base + address, &descr, sizeof(LANCE_TxDescr)); /* if no descriptors were active, give the LANCE a hint to read it immediately */ @@ -967,7 +960,7 @@ static struct net_device_stats *skmca_stats(struct net_device *dev) { - skmca_priv *priv = (skmca_priv *) dev->priv; + skmca_priv *priv = netdev_priv(dev); return &(priv->stat); } @@ -977,13 +970,14 @@ static void skmca_set_multicast_list(struct net_device *dev) { + skmca_priv *priv = netdev_priv(dev); LANCE_InitBlock block; /* first stop the LANCE... */ StopLANCE(dev); /* ...then modify the initialization block... */ - SKMCA_FROMIO(&block, dev->mem_start + RAM_INITBASE, sizeof(block)); + memcpy_fromio(&block, priv->base + RAM_INITBASE, sizeof(block)); if (dev->flags & IFF_PROMISC) block.Mode |= LANCE_INIT_PROM; else @@ -1003,7 +997,7 @@ } } - SKMCA_TOIO(dev->mem_start + RAM_INITBASE, &block, sizeof(block)); + memcpy_toio(priv->base + RAM_INITBASE, &block, sizeof(block)); /* ...then reinit LANCE with the correct flags */ InitLANCE(dev); @@ -1017,10 +1011,11 @@ static void cleanup_card(struct net_device *dev) { - skmca_priv *priv = dev->priv; + skmca_priv *priv = netdev_priv(dev); DeinitBoard(dev); if (dev->irq != 0) free_irq(dev->irq, dev); + iounmap(priv->base); mca_mark_as_unused(priv->slot); mca_set_adapter_procfn(priv->slot, NULL, NULL); } @@ -1104,13 +1099,20 @@ printk("%s: SKNet %s adapter found in slot %d\n", dev->name, junior ? "Junior MC2" : "MC2+", slot + 1); - /* allocate structure */ - priv = dev->priv; + priv = netdev_priv(dev); + priv->base = ioremap(base, 0x4000); + if (!priv->base) { + mca_set_adapter_procfn(slot, NULL, NULL); + mca_mark_as_unused(slot); + free_netdev(dev); + return ERR_PTR(-ENOMEM); + } + priv->slot = slot; - priv->macbase = base + 0x3fc0; - priv->ioregaddr = base + 0x3ff0; - priv->ctrladdr = base + 0x3ff2; - priv->cmdaddr = base + 0x3ff3; + priv->macbase = priv->base + 0x3fc0; + priv->ioregaddr = priv->base + 0x3ff0; + priv->ctrladdr = priv->base + 0x3ff2; + priv->cmdaddr = priv->base + 0x3ff3; priv->medium = medium; memset(&priv->stat, 0, sizeof(struct net_device_stats)); spin_lock_init(&priv->lock); @@ -1147,7 +1149,7 @@ /* copy out MAC address */ for (i = 0; i < 6; i++) - dev->dev_addr[i] = SKMCA_READB(priv->macbase + (i << 1)); + dev->dev_addr[i] = readb(priv->macbase + (i << 1)); /* print config */ printk("%s: IRQ %d, memory %#lx-%#lx, " diff -Nru a/drivers/net/sk_mca.h b/drivers/net/sk_mca.h --- a/drivers/net/sk_mca.h 2005-03-07 12:09:08 -05:00 +++ b/drivers/net/sk_mca.h 2005-03-07 12:09:08 -05:00 @@ -5,16 +5,6 @@ #ifdef _SK_MCA_DRIVER_ -/* version-dependent functions/structures */ - -#define SKMCA_READB(addr) isa_readb(addr) -#define SKMCA_READW(addr) isa_readw(addr) -#define SKMCA_WRITEB(data, addr) isa_writeb(data, addr) -#define SKMCA_WRITEW(data, addr) isa_writew(data, addr) -#define SKMCA_TOIO(dest, src, len) isa_memcpy_toio(dest, src, len) -#define SKMCA_FROMIO(dest, src, len) isa_memcpy_fromio(dest, src, len) -#define SKMCA_SETIO(dest, val, len) isa_memset_io(dest, val, len) - /* Adapter ID's */ #define SKNET_MCA_ID 0x6afd #define SKNET_JUNIOR_MCA_ID 0x6be9 @@ -29,10 +19,11 @@ /* private structure */ typedef struct { unsigned int slot; /* MCA-Slot-# */ - unsigned int macbase; /* base address of MAC address PROM */ - unsigned int ioregaddr; /* address of I/O-register (Lo) */ - unsigned int ctrladdr; /* address of control/stat register */ - unsigned int cmdaddr; /* address of I/O-command register */ + void __iomem *base; + void __iomem *macbase; /* base address of MAC address PROM */ + void __iomem *ioregaddr;/* address of I/O-register (Lo) */ + void __iomem *ctrladdr; /* address of control/stat register */ + void __iomem *cmdaddr; /* address of I/O-command register */ int nextrx; /* index of next RX descriptor to be read */ int nexttxput; /* index of next free TX descriptor */ diff -Nru a/drivers/net/smc91x.h b/drivers/net/smc91x.h --- a/drivers/net/smc91x.h 2005-03-07 12:09:08 -05:00 +++ b/drivers/net/smc91x.h 2005-03-07 12:09:08 -05:00 @@ -182,6 +182,25 @@ #define SMC_insl(a, r, p, l) readsl((a) + (r), p, l) #define SMC_outsl(a, r, p, l) writesl((a) + (r), p, l) +#elif defined(CONFIG_SH_SH4202_MICRODEV) + +#define SMC_CAN_USE_8BIT 0 +#define SMC_CAN_USE_16BIT 1 +#define SMC_CAN_USE_32BIT 0 + +#define SMC_inb(a, r) inb((a) + (r) - 0xa0000000) +#define SMC_inw(a, r) inw((a) + (r) - 0xa0000000) +#define SMC_inl(a, r) inl((a) + (r) - 0xa0000000) +#define SMC_outb(v, a, r) outb(v, (a) + (r) - 0xa0000000) +#define SMC_outw(v, a, r) outw(v, (a) + (r) - 0xa0000000) +#define SMC_outl(v, a, r) outl(v, (a) + (r) - 0xa0000000) +#define SMC_insl(a, r, p, l) insl((a) + (r) - 0xa0000000, p, l) +#define SMC_outsl(a, r, p, l) outsl((a) + (r) - 0xa0000000, p, l) +#define SMC_insw(a, r, p, l) insw((a) + (r) - 0xa0000000, p, l) +#define SMC_outsw(a, r, p, l) outsw((a) + (r) - 0xa0000000, p, l) + +#define set_irq_type(irq, type) do {} while(0) + #elif defined(CONFIG_ISA) #define SMC_CAN_USE_8BIT 1 diff -Nru a/drivers/net/sundance.c b/drivers/net/sundance.c --- a/drivers/net/sundance.c 2005-03-07 12:09:08 -05:00 +++ b/drivers/net/sundance.c 2005-03-07 12:09:08 -05:00 @@ -1210,9 +1210,11 @@ } /* Yup, this is a documentation bug. It cost me *hours*. */ iowrite16 (0, ioaddr + TxStatus); - tx_status = ioread16 (ioaddr + TxStatus); - if (tx_cnt < 0) + if (tx_cnt < 0) { + iowrite32(5000, ioaddr + DownCounter); break; + } + tx_status = ioread16 (ioaddr + TxStatus); } hw_frame_id = (tx_status >> 8) & 0xff; } else { @@ -1278,7 +1280,6 @@ if (netif_msg_intr(np)) printk(KERN_DEBUG "%s: exiting interrupt, status=%#4.4x.\n", dev->name, ioread16(ioaddr + IntrStatus)); - iowrite32(5000, ioaddr + DownCounter); return IRQ_RETVAL(handled); } diff -Nru a/drivers/net/sungem.c b/drivers/net/sungem.c --- a/drivers/net/sungem.c 2005-03-07 12:09:08 -05:00 +++ b/drivers/net/sungem.c 2005-03-07 12:09:08 -05:00 @@ -2356,7 +2356,7 @@ } #ifdef CONFIG_PM -static int gem_suspend(struct pci_dev *pdev, u32 state) +static int gem_suspend(struct pci_dev *pdev, pm_message_t state) { struct net_device *dev = pci_get_drvdata(pdev); struct gem *gp = dev->priv; diff -Nru a/drivers/net/tg3.c b/drivers/net/tg3.c --- a/drivers/net/tg3.c 2005-03-07 12:09:08 -05:00 +++ b/drivers/net/tg3.c 2005-03-07 12:09:08 -05:00 @@ -8948,7 +8948,7 @@ } } -static int tg3_suspend(struct pci_dev *pdev, u32 state) +static int tg3_suspend(struct pci_dev *pdev, pm_message_t state) { struct net_device *dev = pci_get_drvdata(pdev); struct tg3 *tp = netdev_priv(dev); @@ -8975,7 +8975,7 @@ spin_unlock(&tp->tx_lock); spin_unlock_irq(&tp->lock); - err = tg3_set_power_state(tp, state); + err = tg3_set_power_state(tp, pci_choose_state(pdev, state)); if (err) { spin_lock_irq(&tp->lock); spin_lock(&tp->tx_lock); diff -Nru a/drivers/net/tg3.h b/drivers/net/tg3.h --- a/drivers/net/tg3.h 2005-03-07 12:09:08 -05:00 +++ b/drivers/net/tg3.h 2005-03-07 12:09:08 -05:00 @@ -1548,20 +1548,6 @@ #define MII_TG3_INT_DUPLEXCHG 0x0008 #define MII_TG3_INT_ANEG_PAGE_RX 0x0400 -/* XXX Add this to mii.h */ -#ifndef ADVERTISE_PAUSE -#define ADVERTISE_PAUSE_CAP 0x0400 -#endif -#ifndef ADVERTISE_PAUSE_ASYM -#define ADVERTISE_PAUSE_ASYM 0x0800 -#endif -#ifndef LPA_PAUSE -#define LPA_PAUSE_CAP 0x0400 -#endif -#ifndef LPA_PAUSE_ASYM -#define LPA_PAUSE_ASYM 0x0800 -#endif - /* There are two ways to manage the TX descriptors on the tigon3. * Either the descriptors are in host DMA'able memory, or they * exist only in the cards on-chip SRAM. All 16 send bds are under diff -Nru a/drivers/net/tulip/tulip_core.c b/drivers/net/tulip/tulip_core.c --- a/drivers/net/tulip/tulip_core.c 2005-03-07 12:09:08 -05:00 +++ b/drivers/net/tulip/tulip_core.c 2005-03-07 12:09:08 -05:00 @@ -1749,7 +1749,7 @@ #ifdef CONFIG_PM -static int tulip_suspend (struct pci_dev *pdev, u32 state) +static int tulip_suspend (struct pci_dev *pdev, pm_message_t state) { struct net_device *dev = pci_get_drvdata(pdev); diff -Nru a/drivers/net/typhoon.c b/drivers/net/typhoon.c --- a/drivers/net/typhoon.c 2005-03-07 12:09:08 -05:00 +++ b/drivers/net/typhoon.c 2005-03-07 12:09:08 -05:00 @@ -1874,7 +1874,7 @@ } static int -typhoon_sleep(struct typhoon *tp, int state, u16 events) +typhoon_sleep(struct typhoon *tp, pci_power_t state, u16 events) { struct pci_dev *pdev = tp->pdev; void __iomem *ioaddr = tp->ioaddr; @@ -2155,7 +2155,7 @@ goto out; } - if(typhoon_sleep(tp, 3, 0) < 0) + if(typhoon_sleep(tp, PCI_D3hot, 0) < 0) printk(KERN_ERR "%s: unable to go back to sleep\n", dev->name); out: @@ -2182,7 +2182,7 @@ if(typhoon_boot_3XP(tp, TYPHOON_STATUS_WAITING_FOR_HOST) < 0) printk(KERN_ERR "%s: unable to boot sleep image\n", dev->name); - if(typhoon_sleep(tp, 3, 0) < 0) + if(typhoon_sleep(tp, PCI_D3hot, 0) < 0) printk(KERN_ERR "%s: unable to put card to sleep\n", dev->name); return 0; @@ -2222,7 +2222,7 @@ } static int -typhoon_suspend(struct pci_dev *pdev, u32 state) +typhoon_suspend(struct pci_dev *pdev, pm_message_t state) { struct net_device *dev = pci_get_drvdata(pdev); struct typhoon *tp = netdev_priv(dev); @@ -2532,7 +2532,7 @@ if(xp_resp[0].numDesc != 0) tp->capabilities |= TYPHOON_WAKEUP_NEEDS_RESET; - if(typhoon_sleep(tp, 3, 0) < 0) { + if(typhoon_sleep(tp, PCI_D3hot, 0) < 0) { printk(ERR_PFX "%s: cannot put adapter to sleep\n", pci_name(pdev)); err = -EIO; diff -Nru a/drivers/net/via-rhine.c b/drivers/net/via-rhine.c --- a/drivers/net/via-rhine.c 2005-03-07 12:09:08 -05:00 +++ b/drivers/net/via-rhine.c 2005-03-07 12:09:08 -05:00 @@ -1937,7 +1937,7 @@ } #ifdef CONFIG_PM -static int rhine_suspend(struct pci_dev *pdev, u32 state) +static int rhine_suspend(struct pci_dev *pdev, pm_message_t state) { struct net_device *dev = pci_get_drvdata(pdev); struct rhine_private *rp = netdev_priv(dev); diff -Nru a/drivers/net/via-velocity.c b/drivers/net/via-velocity.c --- a/drivers/net/via-velocity.c 2005-03-07 12:09:08 -05:00 +++ b/drivers/net/via-velocity.c 2005-03-07 12:09:08 -05:00 @@ -263,7 +263,7 @@ #ifdef CONFIG_PM -static int velocity_suspend(struct pci_dev *pdev, u32 state); +static int velocity_suspend(struct pci_dev *pdev, pm_message_t state); static int velocity_resume(struct pci_dev *pdev); static int velocity_netdev_event(struct notifier_block *nb, unsigned long notification, void *ptr); @@ -3210,7 +3210,7 @@ return 0; } -static int velocity_suspend(struct pci_dev *pdev, u32 state) +static int velocity_suspend(struct pci_dev *pdev, pm_message_t state) { struct velocity_info *vptr = pci_get_drvdata(pdev); unsigned long flags; diff -Nru a/drivers/net/wireless/arlan.h b/drivers/net/wireless/arlan.h --- a/drivers/net/wireless/arlan.h 2005-03-07 12:09:08 -05:00 +++ b/drivers/net/wireless/arlan.h 2005-03-07 12:09:08 -05:00 @@ -43,8 +43,8 @@ extern int init_arlan_proc(void); extern void cleanup_arlan_proc(void); #else -#define init_arlan_proc() (0) -#define cleanup_arlan_proc() do { } while (0); +#define init_arlan_proc() ({ 0; }) +#define cleanup_arlan_proc() do { } while (0) #endif extern struct net_device *arlan_device[MAX_ARLANS]; diff -Nru a/drivers/net/wireless/atmel.c b/drivers/net/wireless/atmel.c --- a/drivers/net/wireless/atmel.c 2005-03-07 12:09:08 -05:00 +++ b/drivers/net/wireless/atmel.c 2005-03-07 12:09:08 -05:00 @@ -69,6 +69,7 @@ #include #include #include "ieee802_11.h" +#include "atmel.h" #define DRIVER_MAJOR 0 #define DRIVER_MINOR 96 @@ -83,6 +84,23 @@ static char *firmware = NULL; module_param(firmware, charp, 0); +/* table of firmware file names */ +static struct { + AtmelFWType fw_type; + const char *fw_file; + const char *fw_file_ext; +} fw_table[] = { + { ATMEL_FW_TYPE_502, "atmel_at76c502", "bin" }, + { ATMEL_FW_TYPE_502D, "atmel_at76c502d", "bin" }, + { ATMEL_FW_TYPE_502E, "atmel_at76c502e", "bin" }, + { ATMEL_FW_TYPE_502_3COM, "atmel_at76c502_3com", "bin" }, + { ATMEL_FW_TYPE_504, "atmel_at76c504", "bin" }, + { ATMEL_FW_TYPE_504_2958, "atmel_at76c504_2958", "bin" }, + { ATMEL_FW_TYPE_504A_2958,"atmel_at76c504a_2958","bin" }, + { ATMEL_FW_TYPE_506, "atmel_at76c506", "bin" }, + { ATMEL_FW_TYPE_NONE, NULL, NULL } +}; + #define MAX_SSID_LENGTH 32 #define MGMT_JIFFIES (256 * HZ / 100) @@ -458,8 +476,8 @@ void *card; /* Bus dependent stucture varies for PCcard */ int (*present_callback)(void *); /* And callback which uses it */ char firmware_id[32]; - char firmware_template[32]; - unsigned char *firmware; + AtmelFWType firmware_type; + u8 *firmware; int firmware_length; struct timer_list management_timer; struct net_device *dev; @@ -1293,17 +1311,21 @@ if (priv->operating_mode == IW_MODE_INFRA) { if (priv->station_state != STATION_STATE_READY) { priv->wstats.qual.qual = 0; - priv->wstats.qual.level = 0; + priv->wstats.qual.level = 0; + priv->wstats.qual.updated = (IW_QUAL_QUAL_INVALID + | IW_QUAL_LEVEL_INVALID); } priv->wstats.qual.noise = 0; - priv->wstats.qual.updated = 7; + priv->wstats.qual.updated |= IW_QUAL_NOISE_INVALID; } else { /* Quality levels cannot be determined in ad-hoc mode, because we can 'hear' more that one remote station. */ priv->wstats.qual.qual = 0; priv->wstats.qual.level = 0; priv->wstats.qual.noise = 0; - priv->wstats.qual.updated = 0; + priv->wstats.qual.updated = IW_QUAL_QUAL_INVALID + | IW_QUAL_LEVEL_INVALID + | IW_QUAL_NOISE_INVALID; priv->wstats.miss.beacon = 0; } @@ -1482,7 +1504,7 @@ return len; } -struct net_device *init_atmel_card( unsigned short irq, int port, char *firmware_id, +struct net_device *init_atmel_card( unsigned short irq, int port, const AtmelFWType fw_type, struct device *sys_dev, int (*card_present)(void *), void *card) { struct net_device *dev; @@ -1507,11 +1529,9 @@ priv->card = card; priv->firmware = NULL; priv->firmware_id[0] = '\0'; - priv->firmware_template[0] = '\0'; + priv->firmware_type = fw_type; if (firmware) /* module parameter */ strcpy(priv->firmware_id, firmware); - else if (firmware_id) /* from PCMCIA card-matching or PCI */ - strcpy(priv->firmware_template, firmware_id); priv->bus_type = card_present ? BUS_TYPE_PCCARD : BUS_TYPE_PCI; priv->station_state = STATION_STATE_DOWN; priv->do_rx_crc = 0; @@ -1579,6 +1599,8 @@ dev->irq = irq; dev->base_addr = port; + SET_NETDEV_DEV(dev, sys_dev); + if ((rc = request_irq(dev->irq, service_interrupt, SA_SHIRQ, dev->name, dev))) { printk(KERN_ERR "%s: register interrupt %d failed, rc %d\n", dev->name, irq, rc ); goto err_out_free; @@ -2218,6 +2240,13 @@ range->max_qual.qual = 100; range->max_qual.level = 100; range->max_qual.noise = 0; + range->max_qual.updated = IW_QUAL_NOISE_INVALID; + + range->avg_qual.qual = 50; + range->avg_qual.level = 50; + range->avg_qual.noise = 0; + range->avg_qual.updated = IW_QUAL_NOISE_INVALID; + range->sensitivity = 0; range->bitrate[0] = 1000000; @@ -2247,9 +2276,6 @@ range->r_time_flags = 0; range->min_retry = 1; range->max_retry = 65535; - range->avg_qual.qual = 50; - range->avg_qual.level = 50; - range->avg_qual.noise = 0; return 0; } @@ -3025,16 +3051,23 @@ static void smooth_rssi(struct atmel_private *priv, u8 rssi) { u8 old = priv->wstats.qual.level; + u8 max_rssi = 42; /* 502-rmfd-revd max by experiment, default for now */ - /* 502-rmfd-revd gives max signal level as 42, by experiment. - This is going to break for other hardware variants. */ + switch (priv->firmware_type) { + case ATMEL_FW_TYPE_502E: + max_rssi = 63; /* 502-rmfd-reve max by experiment */ + break; + default: + break; + } - rssi = rssi * 100 / 42; + rssi = rssi * 100 / max_rssi; if((rssi + old) % 2) priv->wstats.qual.level = ((rssi + old)/2) + 1; else priv->wstats.qual.level = ((rssi + old)/2); - + priv->wstats.qual.updated |= IW_QUAL_LEVEL_UPDATED; + priv->wstats.qual.updated &= ~IW_QUAL_LEVEL_INVALID; } static void atmel_smooth_qual(struct atmel_private *priv) @@ -3047,8 +3080,10 @@ priv->beacons_this_sec * priv->beacon_period * (priv->wstats.qual.level + 100) / 4000; priv->beacons_this_sec = 0; } + priv->wstats.qual.updated |= IW_QUAL_QUAL_UPDATED; + priv->wstats.qual.updated &= ~IW_QUAL_QUAL_INVALID; } - + /* deals with incoming managment frames. */ static void atmel_management_frame(struct atmel_private *priv, struct ieee802_11_hdr *header, u16 frame_len, u8 rssi) @@ -3611,8 +3646,8 @@ const struct firmware *fw_entry = NULL; unsigned char *fw; int len = priv->firmware_length; - if (!(fw = priv->firmware)) { - if (strlen(priv->firmware_template) == 0) { + if (!(fw = priv->firmware)) { + if (priv->firmware_type == ATMEL_FW_TYPE_NONE) { if (strlen(priv->firmware_id) == 0) { printk(KERN_INFO "%s: card type is unknown: assuming at76c502 firmware is OK.\n", @@ -3627,24 +3662,36 @@ "%s: firmware %s is missing, cannot continue.\n", dev->name, priv->firmware_id); return 0; - - } + } } else { - int i; + int fw_index = 0; + int success = 0; + + /* get firmware filename entry based on firmware type ID */ + while (fw_table[fw_index].fw_type != priv->firmware_type + && fw_table[fw_index].fw_type != ATMEL_FW_TYPE_NONE) + fw_index++; - for (i = 0; firmware_modifier[i]; i++) { - sprintf(priv->firmware_id, priv->firmware_template, firmware_modifier[i]); - if (request_firmware(&fw_entry, priv->firmware_id, priv->sys_dev) == 0) - break; + /* construct the actual firmware file name */ + if (fw_table[fw_index].fw_type != ATMEL_FW_TYPE_NONE) { + int i; + for (i = 0; firmware_modifier[i]; i++) { + snprintf(priv->firmware_id, 32, "%s%s.%s", fw_table[fw_index].fw_file, + firmware_modifier[i], fw_table[fw_index].fw_file_ext); + priv->firmware_id[31] = '\0'; + if (request_firmware(&fw_entry, priv->firmware_id, priv->sys_dev) == 0) { + success = 1; + break; + } + } } - if (!firmware_modifier[i]) { + if (!success) { printk(KERN_ALERT "%s: firmware %s is missing, cannot start.\n", dev->name, priv->firmware_id); priv->firmware_id[0] = '\0'; return 0; } - priv->firmware_template[0] = '\0'; } fw = fw_entry->data; diff -Nru a/drivers/net/wireless/atmel.h b/drivers/net/wireless/atmel.h --- /dev/null Wed Dec 31 16:00:00 196900 +++ b/drivers/net/wireless/atmel.h 2005-03-07 12:09:08 -05:00 @@ -0,0 +1,43 @@ +/*** -*- linux-c -*- ********************************************************** + + Driver for Atmel at76c502 at76c504 and at76c506 wireless cards. + + Copyright 2005 Dan Williams and Red Hat, Inc. + + This program is free software; you can redistribute it and/or modify + it under the terms of the GNU General Public License as published by + the Free Software Foundation; either version 2 of the License, or + (at your option) any later version. + + This software is distributed in the hope that it will be useful, + but WITHOUT ANY WARRANTY; without even the implied warranty of + MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the + GNU General Public License for more details. + + You should have received a copy of the GNU General Public License + along with Atmel wireless lan drivers; if not, write to the Free Software + Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA 02111-1307 USA + +******************************************************************************/ + +#ifndef _ATMEL_H +#define _ATMEL_H + +typedef enum { + ATMEL_FW_TYPE_NONE = 0, + ATMEL_FW_TYPE_502, + ATMEL_FW_TYPE_502D, + ATMEL_FW_TYPE_502E, + ATMEL_FW_TYPE_502_3COM, + ATMEL_FW_TYPE_504, + ATMEL_FW_TYPE_504_2958, + ATMEL_FW_TYPE_504A_2958, + ATMEL_FW_TYPE_506 +} AtmelFWType; + +struct net_device *init_atmel_card(unsigned short, int, const AtmelFWType, struct device *, + int (*present_func)(void *), void * ); +void stop_atmel_card( struct net_device *, int ); +int atmel_open( struct net_device * ); + +#endif diff -Nru a/drivers/net/wireless/atmel_cs.c b/drivers/net/wireless/atmel_cs.c --- a/drivers/net/wireless/atmel_cs.c 2005-03-07 12:09:08 -05:00 +++ b/drivers/net/wireless/atmel_cs.c 2005-03-07 12:09:08 -05:00 @@ -55,6 +55,7 @@ #include #include +#include "atmel.h" /* All the PCMCIA modules use PCMCIA_DEBUG to control debugging. If @@ -90,11 +91,6 @@ event handler. */ -struct net_device *init_atmel_card(int, int, char *, struct device *, - int (*present_func)(void *), void * ); -void stop_atmel_card( struct net_device *, int ); -int atmel_open( struct net_device * ); - static void atmel_config(dev_link_t *link); static void atmel_release(dev_link_t *link); static int atmel_event(event_t event, int priority, @@ -307,28 +303,29 @@ static struct { int manf, card; char *ver1; - char *firmware; + AtmelFWType firmware; char *name; } card_table[] = { - { 0, 0, "WLAN/802.11b PC CARD", "atmel_at76c502d%s.bin", "Actiontec 802CAT1" }, - { 0, 0, "ATMEL/AT76C502AR", "atmel_at76c502%s.bin", "NoName-RFMD" }, - { 0, 0, "ATMEL/AT76C502AR_D", "atmel_at76c502d%s.bin", "NoName-revD" }, - { 0, 0, "ATMEL/AT76C502AR_E", "atmel_at76c502e%s.bin", "NoName-revE" }, - { 0, 0, "ATMEL/AT76C504", "atmel_at76c504%s.bin", "NoName-504" }, - { 0, 0, "ATMEL/AT76C504A", "atmel_at76c504a_2958%s.bin", "NoName-504a-2958" }, - { 0, 0, "ATMEL/AT76C504_R", "atmel_at76c504_2958%s.bin", "NoName-504-2958" }, - { MANFID_3COM, 0x0620, NULL, "atmel_at76c502_3com%s.bin", "3com 3CRWE62092B" }, - { MANFID_3COM, 0x0696, NULL, "atmel_at76c502_3com%s.bin", "3com 3CRSHPW196" }, - { 0, 0, "SMC/2632W-V2", "atmel_at76c502%s.bin", "SMC 2632W-V2" }, - { 0, 0, "SMC/2632W", "atmel_at76c502d%s.bin", "SMC 2632W-V3" }, - { 0xd601, 0x0007, NULL, "atmel_at76c502%s.bin", "Sitecom WLAN-011" }, - { 0x01bf, 0x3302, NULL, "atmel_at76c502e%s.bin", "Belkin F5D6020-V2" }, - { 0, 0, "BT/Voyager 1020 Laptop Adapter", "atmel_at76c502%s.bin", "BT Voyager 1020" }, - { 0, 0, "IEEE 802.11b/Wireless LAN PC Card", "atmel_at76c502%s.bin", "Siemens Gigaset PC Card II" }, - { 0, 0, "CNet/CNWLC 11Mbps Wireless PC Card V-5", "atmel_at76c502e%s.bin", "CNet CNWLC-811ARL" }, - { 0, 0, "Wireless/PC_CARD", "atmel_at76c502d%s.bin", "Planet WL-3552" }, - { 0, 0, "OEM/11Mbps Wireless LAN PC Card V-3", "atmel_at76c502%s.bin", "OEM 11Mbps WLAN PCMCIA Card" }, - { 0, 0, "11WAVE/11WP611AL-E", "atmel_at76c502e%s.bin", "11WAVE WaveBuddy" } + { 0, 0, "WLAN/802.11b PC CARD", ATMEL_FW_TYPE_502D, "Actiontec 802CAT1" }, + { 0, 0, "ATMEL/AT76C502AR", ATMEL_FW_TYPE_502, "NoName-RFMD" }, + { 0, 0, "ATMEL/AT76C502AR_D", ATMEL_FW_TYPE_502D, "NoName-revD" }, + { 0, 0, "ATMEL/AT76C502AR_E", ATMEL_FW_TYPE_502E, "NoName-revE" }, + { 0, 0, "ATMEL/AT76C504", ATMEL_FW_TYPE_504, "NoName-504" }, + { 0, 0, "ATMEL/AT76C504A", ATMEL_FW_TYPE_504A_2958, "NoName-504a-2958" }, + { 0, 0, "ATMEL/AT76C504_R", ATMEL_FW_TYPE_504_2958, "NoName-504-2958" }, + { MANFID_3COM, 0x0620, NULL, ATMEL_FW_TYPE_502_3COM, "3com 3CRWE62092B" }, + { MANFID_3COM, 0x0696, NULL, ATMEL_FW_TYPE_502_3COM, "3com 3CRSHPW196" }, + { 0, 0, "SMC/2632W-V2", ATMEL_FW_TYPE_502, "SMC 2632W-V2" }, + { 0, 0, "SMC/2632W", ATMEL_FW_TYPE_502D, "SMC 2632W-V3" }, + { 0xd601, 0x0007, NULL, ATMEL_FW_TYPE_502, "Sitecom WLAN-011" }, + { 0x01bf, 0x3302, NULL, ATMEL_FW_TYPE_502E, "Belkin F5D6020-V2" }, + { 0, 0, "BT/Voyager 1020 Laptop Adapter", ATMEL_FW_TYPE_502, "BT Voyager 1020" }, + { 0, 0, "IEEE 802.11b/Wireless LAN PC Card", ATMEL_FW_TYPE_502, "Siemens Gigaset PC Card II" }, + { 0, 0, "CNet/CNWLC 11Mbps Wireless PC Card V-5", ATMEL_FW_TYPE_502E, "CNet CNWLC-811ARL" }, + { 0, 0, "Wireless/PC_CARD", ATMEL_FW_TYPE_502D, "Planet WL-3552" }, + { 0, 0, "OEM/11Mbps Wireless LAN PC Card V-3", ATMEL_FW_TYPE_502, "OEM 11Mbps WLAN PCMCIA Card" }, + { 0, 0, "11WAVE/11WP611AL-E", ATMEL_FW_TYPE_502E, "11WAVE WaveBuddy" }, + { 0, 0, "LG/LW2100N", ATMEL_FW_TYPE_502E, "LG LW2100N 11Mbps WLAN PCMCIA Card" }, }; static void atmel_config(dev_link_t *link) @@ -520,7 +517,7 @@ ((local_info_t*)link->priv)->eth_dev = init_atmel_card(link->irq.AssignedIRQ, link->io.BasePort1, - card_index == -1 ? NULL : card_table[card_index].firmware, + card_index == -1 ? ATMEL_FW_TYPE_NONE : card_table[card_index].firmware, &handle_to_dev(handle), card_present, link); diff -Nru a/drivers/net/wireless/atmel_pci.c b/drivers/net/wireless/atmel_pci.c --- a/drivers/net/wireless/atmel_pci.c 2005-03-07 12:09:08 -05:00 +++ b/drivers/net/wireless/atmel_pci.c 2005-03-07 12:09:08 -05:00 @@ -25,6 +25,7 @@ #include #include #include +#include "atmel.h" MODULE_AUTHOR("Simon Kelley"); MODULE_DESCRIPTION("Support for Atmel at76c50x 802.11 wireless ethernet cards."); @@ -40,9 +41,6 @@ static int atmel_pci_probe(struct pci_dev *, const struct pci_device_id *); static void atmel_pci_remove(struct pci_dev *); -struct net_device *init_atmel_card(int, int, char *, struct device *, - int (*present_func)(void *), void * ); -void stop_atmel_card( struct net_device *, int ); static struct pci_driver atmel_driver = { .name = "atmel", @@ -63,7 +61,7 @@ pci_set_master(pdev); dev = init_atmel_card(pdev->irq, pdev->resource[1].start, - "atmel_at76c506%s.bin", + ATMEL_FW_TYPE_506, &pdev->dev, NULL, NULL); if (!dev) return -ENODEV; diff -Nru a/drivers/net/wireless/prism54/isl_38xx.c b/drivers/net/wireless/prism54/isl_38xx.c --- a/drivers/net/wireless/prism54/isl_38xx.c 2005-03-07 12:09:08 -05:00 +++ b/drivers/net/wireless/prism54/isl_38xx.c 2005-03-07 12:09:08 -05:00 @@ -125,11 +125,11 @@ #if VERBOSE > SHOW_ERROR_MESSAGES do_gettimeofday(¤t_time); DEBUG(SHOW_TRACING, "%08li.%08li Device wakeup triggered\n", - current_time.tv_sec, current_time.tv_usec); + current_time.tv_sec, (long)current_time.tv_usec); #endif DEBUG(SHOW_TRACING, "%08li.%08li Device register read %08x\n", - current_time.tv_sec, current_time.tv_usec, + current_time.tv_sec, (long)current_time.tv_usec, readl(device_base + ISL38XX_CTRL_STAT_REG)); udelay(ISL38XX_WRITEIO_DELAY); @@ -139,7 +139,7 @@ do_gettimeofday(¤t_time); DEBUG(SHOW_TRACING, "%08li.%08li Device register abadface\n", - current_time.tv_sec, current_time.tv_usec); + current_time.tv_sec, (long)current_time.tv_usec); #endif /* read the Device Status Register until Sleepmode bit is set */ while (reg = readl(device_base + ISL38XX_CTRL_STAT_REG), @@ -150,7 +150,7 @@ DEBUG(SHOW_TRACING, "%08li.%08li Device register read %08x\n", - current_time.tv_sec, current_time.tv_usec, + current_time.tv_sec, (long)current_time.tv_usec, readl(device_base + ISL38XX_CTRL_STAT_REG)); udelay(ISL38XX_WRITEIO_DELAY); @@ -158,7 +158,7 @@ do_gettimeofday(¤t_time); DEBUG(SHOW_TRACING, "%08li.%08li Device asleep counter %i\n", - current_time.tv_sec, current_time.tv_usec, + current_time.tv_sec, (long)current_time.tv_usec, counter); #endif } @@ -174,7 +174,7 @@ #if VERBOSE > SHOW_ERROR_MESSAGES do_gettimeofday(¤t_time); DEBUG(SHOW_TRACING, "%08li.%08li Device register read %08x\n", - current_time.tv_sec, current_time.tv_usec, reg); + current_time.tv_sec, (long)current_time.tv_usec, reg); #endif } else { /* device is (still) awake */ diff -Nru a/include/linux/mii.h b/include/linux/mii.h --- a/include/linux/mii.h 2005-03-07 12:09:08 -05:00 +++ b/include/linux/mii.h 2005-03-07 12:09:08 -05:00 @@ -20,6 +20,8 @@ #define MII_ADVERTISE 0x04 /* Advertisement control reg */ #define MII_LPA 0x05 /* Link partner ability reg */ #define MII_EXPANSION 0x06 /* Expansion register */ +#define MII_CTRL1000 0x09 /* 1000BASE-T control */ +#define MII_STAT1000 0x0a /* 1000BASE-T status */ #define MII_DCOUNTER 0x12 /* Disconnect counter */ #define MII_FCSCOUNTER 0x13 /* False carrier counter */ #define MII_NWAYTEST 0x14 /* N-way auto-neg test reg */ @@ -67,7 +69,9 @@ #define ADVERTISE_100HALF 0x0080 /* Try for 100mbps half-duplex */ #define ADVERTISE_100FULL 0x0100 /* Try for 100mbps full-duplex */ #define ADVERTISE_100BASE4 0x0200 /* Try for 100mbps 4k packets */ -#define ADVERTISE_RESV 0x1c00 /* Unused... */ +#define ADVERTISE_PAUSE_CAP 0x0400 /* Try for pause */ +#define ADVERTISE_PAUSE_ASYM 0x0800 /* Try for asymetric pause */ +#define ADVERTISE_RESV 0x1000 /* Unused... */ #define ADVERTISE_RFAULT 0x2000 /* Say we can detect faults */ #define ADVERTISE_LPACK 0x4000 /* Ack link partners response */ #define ADVERTISE_NPAGE 0x8000 /* Next page bit */ @@ -84,7 +88,9 @@ #define LPA_100HALF 0x0080 /* Can do 100mbps half-duplex */ #define LPA_100FULL 0x0100 /* Can do 100mbps full-duplex */ #define LPA_100BASE4 0x0200 /* Can do 100mbps 4k packets */ -#define LPA_RESV 0x1c00 /* Unused... */ +#define LPA_PAUSE_CAP 0x0400 /* Can pause */ +#define LPA_PAUSE_ASYM 0x0800 /* Can pause asymetrically */ +#define LPA_RESV 0x1000 /* Unused... */ #define LPA_RFAULT 0x2000 /* Link partner faulted */ #define LPA_LPACK 0x4000 /* Link partner acked us */ #define LPA_NPAGE 0x8000 /* Next page bit */ @@ -105,6 +111,15 @@ #define NWAYTEST_LOOPBACK 0x0100 /* Enable loopback for N-way */ #define NWAYTEST_RESV2 0xfe00 /* Unused... */ +/* 1000BASE-T Control register */ +#define ADVERTISE_1000FULL 0x0200 /* Advertise 1000BASE-T full duplex */ +#define ADVERTISE_1000HALF 0x0100 /* Advertise 1000BASE-T half duplex */ + +/* 1000BASE-T Status register */ +#define LPA_1000LOCALRXOK 0x2000 /* Link partner local receiver status */ +#define LPA_1000REMRXOK 0x1000 /* Link partner remote receiver status */ +#define LPA_1000FULL 0x0800 /* Link partner 1000BASE-T full duplex */ +#define LPA_1000HALF 0x0400 /* Link partner 1000BASE-T half duplex */ struct mii_if_info { int phy_id; @@ -114,6 +129,7 @@ unsigned int full_duplex : 1; /* is full duplex? */ unsigned int force_media : 1; /* is autoneg. disabled? */ + unsigned int supports_gmii : 1; /* are GMII registers supported? */ struct net_device *dev; int (*mdio_read) (struct net_device *dev, int phy_id, int location); diff -Nru a/include/linux/netdevice.h b/include/linux/netdevice.h --- a/include/linux/netdevice.h 2005-03-07 12:09:08 -05:00 +++ b/include/linux/netdevice.h 2005-03-07 12:09:08 -05:00 @@ -678,6 +678,8 @@ extern int dev_change_flags(struct net_device *, unsigned); extern int dev_change_name(struct net_device *, char *); extern int dev_set_mtu(struct net_device *, int); +extern int dev_set_mac_address(struct net_device *, + struct sockaddr *); extern void dev_queue_xmit_nit(struct sk_buff *skb, struct net_device *dev); extern void dev_init(void); diff -Nru a/net/core/dev.c b/net/core/dev.c --- a/net/core/dev.c 2005-03-07 12:09:08 -05:00 +++ b/net/core/dev.c 2005-03-07 12:09:08 -05:00 @@ -2300,6 +2300,21 @@ return err; } +int dev_set_mac_address(struct net_device *dev, struct sockaddr *sa) +{ + int err; + + if (!dev->set_mac_address) + return -EOPNOTSUPP; + if (sa->sa_family != dev->type) + return -EINVAL; + if (!netif_device_present(dev)) + return -ENODEV; + err = dev->set_mac_address(dev, sa); + if (!err) + notifier_call_chain(&netdev_chain, NETDEV_CHANGEADDR, dev); + return err; +} /* * Perform the SIOCxIFxxx calls. @@ -2346,17 +2361,7 @@ return 0; case SIOCSIFHWADDR: - if (!dev->set_mac_address) - return -EOPNOTSUPP; - if (ifr->ifr_hwaddr.sa_family != dev->type) - return -EINVAL; - if (!netif_device_present(dev)) - return -ENODEV; - err = dev->set_mac_address(dev, &ifr->ifr_hwaddr); - if (!err) - notifier_call_chain(&netdev_chain, - NETDEV_CHANGEADDR, dev); - return err; + return dev_set_mac_address(dev, &ifr->ifr_hwaddr); case SIOCSIFHWBROADCAST: if (ifr->ifr_hwaddr.sa_family != dev->type) @@ -3322,6 +3327,7 @@ EXPORT_SYMBOL(dev_set_promiscuity); EXPORT_SYMBOL(dev_change_flags); EXPORT_SYMBOL(dev_set_mtu); +EXPORT_SYMBOL(dev_set_mac_address); EXPORT_SYMBOL(free_netdev); EXPORT_SYMBOL(netdev_boot_setup_check); EXPORT_SYMBOL(netdev_set_master); --------------010006070602020702040406-- From mcgrof@ruslug.rutgers.edu Mon Mar 7 09:14:21 2005 Received: with ECARTIS (v1.0.0; list netdev); Mon, 07 Mar 2005 09:14:27 -0800 (PST) Received: from ruslug.rutgers.edu (ruslug.rutgers.edu [128.6.24.131]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j27HEJKw021514 for ; Mon, 7 Mar 2005 09:14:21 -0800 Received: by ruslug.rutgers.edu (Postfix, from userid 503) id C181FF9D94; Mon, 7 Mar 2005 12:14:18 -0500 (EST) Date: Mon, 7 Mar 2005 12:14:18 -0500 To: domen@coderock.org Cc: prism54-private@prism54.org, netdev@oss.sgi.com, tklauser@nuerscht.ch Subject: Re: [patch 2/3] drivers/net/wireless/prism54/islpci_hotplug: Use the DMA_{64, 32}BIT_MASK constants Message-ID: <20050307171418.GT3936@ruslug.rutgers.edu> Mail-Followup-To: domen@coderock.org, prism54-private@prism54.org, netdev@oss.sgi.com, tklauser@nuerscht.ch References: <20050306222355.6686C1ED3D@trashy.coderock.org> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="1G7eoSzW1hxPALpv" Content-Disposition: inline In-Reply-To: <20050306222355.6686C1ED3D@trashy.coderock.org> User-Agent: Mutt/1.3.28i X-Operating-System: 2.4.18-1-686 Organization: Rutgers University Student Linux Users Group From: mcgrof@ruslug.rutgers.edu (Luis R. Rodriguez) X-Virus-Scanned: ClamAV 0.83/751/Mon Mar 7 03:06:27 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 2591 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: mcgrof@ruslug.rutgers.edu Precedence: bulk X-list: netdev Content-Length: 1671 Lines: 54 --1G7eoSzW1hxPALpv Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Sun, Mar 06, 2005 at 11:23:55PM +0100, domen@coderock.org wrote: >=20 > Use the DMA_{64,32}BIT_MASK constants from dma-mapping.h > when calling pci_set_dma_mask() or pci_set_consistent_dma_mask() >=20 > Signed-off-by: Tobias Klauser > Signed-off-by: Domen Puncer > --- >=20 >=20 > kj-domen/drivers/net/wireless/prism54/islpci_hotplug.c | 2 +- > 1 files changed, 1 insertion(+), 1 deletion(-) >=20 > diff -puN drivers/net/wireless/prism54/islpci_hotplug.c~dma_mask-drivers_= net_wireless_prism54_islpci_hotplug drivers/net/wireless/prism54/islpci_hot= plug.c > --- kj/drivers/net/wireless/prism54/islpci_hotplug.c~dma_mask-drivers_net= _wireless_prism54_islpci_hotplug 2005-03-05 16:12:02.000000000 +0100 > +++ kj-domen/drivers/net/wireless/prism54/islpci_hotplug.c 2005-03-05 16:= 12:02.000000000 +0100 > @@ -125,7 +125,7 @@ prism54_probe(struct pci_dev *pdev, cons > } > =20 > /* enable PCI DMA */ > - if (pci_set_dma_mask(pdev, 0xffffffff)) { > + if (pci_set_dma_mask(pdev, DMA_32BIT_MASK)) { Is this 2.4 backward compatible? If not we'll have to add to 2.4 compat file on prism54. =09 Luis --=20 GnuPG Key fingerprint =3D 113F B290 C6D2 0251 4D84 A34A 6ADD 4937 E20A 525E --1G7eoSzW1hxPALpv Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.4 (GNU/Linux) iD8DBQFCLIvqat1JN+IKUl4RAqB5AKCwsKQDC/pvMc0GQQPzeTP3hBeE1gCcCupp yRL9OwKd83/W2RHdLaSW+jQ= =Qg/A -----END PGP SIGNATURE----- --1G7eoSzW1hxPALpv-- From mcgrof@ruslug.rutgers.edu Mon Mar 7 09:14:45 2005 Received: with ECARTIS (v1.0.0; list netdev); Mon, 07 Mar 2005 09:14:53 -0800 (PST) Received: from ruslug.rutgers.edu (ruslug.rutgers.edu [128.6.24.131]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j27HEi8k021769 for ; Mon, 7 Mar 2005 09:14:45 -0800 Received: by ruslug.rutgers.edu (Postfix, from userid 503) id 93920F9D94; Mon, 7 Mar 2005 12:14:44 -0500 (EST) Date: Mon, 7 Mar 2005 12:14:44 -0500 To: domen@coderock.org Cc: prism54-private@prism54.org, netdev@oss.sgi.com, c.lucas@ifrance.com Subject: Re: [patch 3/3] drivers/net/wireless/prism54/*: convert to pci_register_driver Message-ID: <20050307171444.GU3936@ruslug.rutgers.edu> Mail-Followup-To: domen@coderock.org, prism54-private@prism54.org, netdev@oss.sgi.com, c.lucas@ifrance.com References: <20050306222358.752961EC90@trashy.coderock.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20050306222358.752961EC90@trashy.coderock.org> User-Agent: Mutt/1.3.28i X-Operating-System: 2.4.18-1-686 Organization: Rutgers University Student Linux Users Group From: mcgrof@ruslug.rutgers.edu (Luis R. Rodriguez) X-Virus-Scanned: ClamAV 0.83/751/Mon Mar 7 03:06:27 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 2592 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: mcgrof@ruslug.rutgers.edu Precedence: bulk X-list: netdev Content-Length: 1190 Lines: 31 On Sun, Mar 06, 2005 at 11:23:58PM +0100, domen@coderock.org wrote: > > convert from pci_module_init to pci_register_driver > (from:http://kerneljanitors.org/TODO). > > Signed-off-by: Christophe Lucas > Signed-off-by: Domen Puncer > --- > > > kj-domen/drivers/net/wireless/prism54/islpci_hotplug.c | 2 +- > 1 files changed, 1 insertion(+), 1 deletion(-) > > diff -puN drivers/net/wireless/prism54/islpci_hotplug.c~pci_register_driver-drivers_net_wireless_prism54 drivers/net/wireless/prism54/islpci_hotplug.c > --- kj/drivers/net/wireless/prism54/islpci_hotplug.c~pci_register_driver-drivers_net_wireless_prism54 2005-03-05 16:12:44.000000000 +0100 > +++ kj-domen/drivers/net/wireless/prism54/islpci_hotplug.c 2005-03-05 16:12:44.000000000 +0100 > @@ -315,7 +315,7 @@ prism54_module_init(void) > > __bug_on_wrong_struct_sizes (); > > - return pci_module_init(&prism54_driver); > + return pci_register_driver(&prism54_driver); > } > > /* by the time prism54_module_exit() terminates, as a postcondition > _ How about this one? Is this 2.4 compat? -- GnuPG Key fingerprint = 113F B290 C6D2 0251 4D84 A34A 6ADD 4937 E20A 525E From jgarzik@pobox.com Mon Mar 7 09:24:01 2005 Received: with ECARTIS (v1.0.0; list netdev); Mon, 07 Mar 2005 09:24:05 -0800 (PST) Received: from parcelfarce.linux.theplanet.co.uk (IDENT:93@parcelfarce.linux.theplanet.co.uk [195.92.249.252]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j27HO0M9023218 for ; Mon, 7 Mar 2005 09:24:00 -0800 Received: from [69.134.152.124] (helo=[10.10.10.88]) by parcelfarce.linux.theplanet.co.uk with asmtp (TLSv1:AES256-SHA:256) (Exim 4.33) id 1D8LxV-0008Ki-D8; Mon, 07 Mar 2005 17:23:57 +0000 Message-ID: <422C8E1C.40400@pobox.com> Date: Mon, 07 Mar 2005 12:23:40 -0500 From: Jeff Garzik User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.3) Gecko/20040922 X-Accept-Language: en-us, en MIME-Version: 1.0 To: "Luis R. Rodriguez" CC: domen@coderock.org, prism54-private@prism54.org, netdev@oss.sgi.com, c.lucas@ifrance.com Subject: Re: [patch 3/3] drivers/net/wireless/prism54/*: convert to pci_register_driver References: <20050306222358.752961EC90@trashy.coderock.org> <20050307171444.GU3936@ruslug.rutgers.edu> In-Reply-To: <20050307171444.GU3936@ruslug.rutgers.edu> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV 0.83/751/Mon Mar 7 03:06:27 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 2593 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: jgarzik@pobox.com Precedence: bulk X-list: netdev Content-Length: 1181 Lines: 37 Luis R. Rodriguez wrote: > On Sun, Mar 06, 2005 at 11:23:58PM +0100, domen@coderock.org wrote: > >>convert from pci_module_init to pci_register_driver >>(from:http://kerneljanitors.org/TODO). >> >>Signed-off-by: Christophe Lucas >>Signed-off-by: Domen Puncer >>--- >> >> >> kj-domen/drivers/net/wireless/prism54/islpci_hotplug.c | 2 +- >> 1 files changed, 1 insertion(+), 1 deletion(-) >> >>diff -puN drivers/net/wireless/prism54/islpci_hotplug.c~pci_register_driver-drivers_net_wireless_prism54 drivers/net/wireless/prism54/islpci_hotplug.c >>--- kj/drivers/net/wireless/prism54/islpci_hotplug.c~pci_register_driver-drivers_net_wireless_prism54 2005-03-05 16:12:44.000000000 +0100 >>+++ kj-domen/drivers/net/wireless/prism54/islpci_hotplug.c 2005-03-05 16:12:44.000000000 +0100 >>@@ -315,7 +315,7 @@ prism54_module_init(void) >> >> __bug_on_wrong_struct_sizes (); >> >>- return pci_module_init(&prism54_driver); >>+ return pci_register_driver(&prism54_driver); >> } >> >> /* by the time prism54_module_exit() terminates, as a postcondition >>_ > > > How about this one? Is this 2.4 compat? Nope, not 2.4 compatible. Jeff From jgarzik@pobox.com Mon Mar 7 09:24:43 2005 Received: with ECARTIS (v1.0.0; list netdev); Mon, 07 Mar 2005 09:24:49 -0800 (PST) Received: from parcelfarce.linux.theplanet.co.uk (IDENT:93@parcelfarce.linux.theplanet.co.uk [195.92.249.252]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j27HOg4B023482 for ; Mon, 7 Mar 2005 09:24:42 -0800 Received: from [69.134.152.124] (helo=[10.10.10.88]) by parcelfarce.linux.theplanet.co.uk with asmtp (TLSv1:AES256-SHA:256) (Exim 4.33) id 1D8LyC-0008LT-Ms; Mon, 07 Mar 2005 17:24:41 +0000 Message-ID: <422C8E48.9000006@pobox.com> Date: Mon, 07 Mar 2005 12:24:24 -0500 From: Jeff Garzik User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.3) Gecko/20040922 X-Accept-Language: en-us, en MIME-Version: 1.0 To: "Luis R. Rodriguez" CC: domen@coderock.org, prism54-private@prism54.org, netdev@oss.sgi.com, tklauser@nuerscht.ch Subject: Re: [patch 2/3] drivers/net/wireless/prism54/islpci_hotplug: Use the DMA_{64, 32}BIT_MASK constants References: <20050306222355.6686C1ED3D@trashy.coderock.org> <20050307171418.GT3936@ruslug.rutgers.edu> In-Reply-To: <20050307171418.GT3936@ruslug.rutgers.edu> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV 0.83/751/Mon Mar 7 03:06:27 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 2594 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: jgarzik@pobox.com Precedence: bulk X-list: netdev Content-Length: 1366 Lines: 38 Luis R. Rodriguez wrote: > On Sun, Mar 06, 2005 at 11:23:55PM +0100, domen@coderock.org wrote: > >>Use the DMA_{64,32}BIT_MASK constants from dma-mapping.h >>when calling pci_set_dma_mask() or pci_set_consistent_dma_mask() >> >>Signed-off-by: Tobias Klauser >>Signed-off-by: Domen Puncer >>--- >> >> >> kj-domen/drivers/net/wireless/prism54/islpci_hotplug.c | 2 +- >> 1 files changed, 1 insertion(+), 1 deletion(-) >> >>diff -puN drivers/net/wireless/prism54/islpci_hotplug.c~dma_mask-drivers_net_wireless_prism54_islpci_hotplug drivers/net/wireless/prism54/islpci_hotplug.c >>--- kj/drivers/net/wireless/prism54/islpci_hotplug.c~dma_mask-drivers_net_wireless_prism54_islpci_hotplug 2005-03-05 16:12:02.000000000 +0100 >>+++ kj-domen/drivers/net/wireless/prism54/islpci_hotplug.c 2005-03-05 16:12:02.000000000 +0100 >>@@ -125,7 +125,7 @@ prism54_probe(struct pci_dev *pdev, cons >> } >> >> /* enable PCI DMA */ >>- if (pci_set_dma_mask(pdev, 0xffffffff)) { >>+ if (pci_set_dma_mask(pdev, DMA_32BIT_MASK)) { > > > Is this 2.4 backward compatible? If not we'll have to add to 2.4 compat > file on prism54. Not compatible, but it is preferred to patch the file and add that definition to a compat header. For pci_module_init(), it is preferred to keep pci_module_init() rather than adding compat gunk. Jeff From mcgrof@ruslug.rutgers.edu Mon Mar 7 09:29:58 2005 Received: with ECARTIS (v1.0.0; list netdev); Mon, 07 Mar 2005 09:30:04 -0800 (PST) Received: from ruslug.rutgers.edu (ruslug.rutgers.edu [128.6.24.131]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j27HTwRg024329 for ; Mon, 7 Mar 2005 09:29:58 -0800 Received: by ruslug.rutgers.edu (Postfix, from userid 503) id 595FBF9D94; Mon, 7 Mar 2005 12:29:57 -0500 (EST) Date: Mon, 7 Mar 2005 12:29:57 -0500 To: Jeff Garzik Cc: domen@coderock.org, prism54-private@prism54.org, netdev@oss.sgi.com, tklauser@nuerscht.ch, prism54-devel@prism54.org Subject: Re: [patch 2/3] drivers/net/wireless/prism54/islpci_hotplug: Use the DMA_{64, 32}BIT_MASK constants Message-ID: <20050307172957.GW3936@ruslug.rutgers.edu> Mail-Followup-To: Jeff Garzik , domen@coderock.org, prism54-private@prism54.org, netdev@oss.sgi.com, tklauser@nuerscht.ch, prism54-devel@prism54.org References: <20050306222355.6686C1ED3D@trashy.coderock.org> <20050307171418.GT3936@ruslug.rutgers.edu> <422C8E48.9000006@pobox.com> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="F67xnxMyVwCoXwbx" Content-Disposition: inline In-Reply-To: <422C8E48.9000006@pobox.com> User-Agent: Mutt/1.3.28i X-Operating-System: 2.4.18-1-686 Organization: Rutgers University Student Linux Users Group From: mcgrof@ruslug.rutgers.edu (Luis R. Rodriguez) X-Virus-Scanned: ClamAV 0.83/751/Mon Mar 7 03:06:27 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 2595 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: mcgrof@ruslug.rutgers.edu Precedence: bulk X-list: netdev Content-Length: 2262 Lines: 75 --F67xnxMyVwCoXwbx Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Mon, Mar 07, 2005 at 12:24:24PM -0500, Jeff Garzik wrote: > Luis R. Rodriguez wrote: > >On Sun, Mar 06, 2005 at 11:23:55PM +0100, domen@coderock.org wrote: > > > >>Use the DMA_{64,32}BIT_MASK constants from dma-mapping.h > >>when calling pci_set_dma_mask() or pci_set_consistent_dma_mask() > >> > >>Signed-off-by: Tobias Klauser > >>Signed-off-by: Domen Puncer > >>--- > >> > >> > >>kj-domen/drivers/net/wireless/prism54/islpci_hotplug.c | 2 +- > >>1 files changed, 1 insertion(+), 1 deletion(-) > >> > >>diff -puN=20 > >>drivers/net/wireless/prism54/islpci_hotplug.c~dma_mask-drivers_net_wire= less_prism54_islpci_hotplug drivers/net/wireless/prism54/islpci_hotplug.c > >>---=20 > >>kj/drivers/net/wireless/prism54/islpci_hotplug.c~dma_mask-drivers_net_w= ireless_prism54_islpci_hotplug 2005-03-05 16:12:02.000000000 +0100 > >>+++ kj-domen/drivers/net/wireless/prism54/islpci_hotplug.c 2005-03-05= =20 > >>16:12:02.000000000 +0100 > >>@@ -125,7 +125,7 @@ prism54_probe(struct pci_dev *pdev, cons > >> } > >> > >> /* enable PCI DMA */ > >>- if (pci_set_dma_mask(pdev, 0xffffffff)) { > >>+ if (pci_set_dma_mask(pdev, DMA_32BIT_MASK)) { > > > > > >Is this 2.4 backward compatible? If not we'll have to add to 2.4 compat > >file on prism54. >=20 > Not compatible, but it is preferred to patch the file and add that=20 > definition to a compat header. >=20 > For pci_module_init(), it is preferred to keep pci_module_init() rather= =20 > than adding compat gunk. >=20 > Jeff Alright, I'll add DMA_32BIT_MASK through compat and leave pci_module_init as is. That said: Patch 1 applied Patch 2 will be applied after compat work Patch 3 rejected per Jeff's recomendation due to 2.4 compat Luis --=20 GnuPG Key fingerprint =3D 113F B290 C6D2 0251 4D84 A34A 6ADD 4937 E20A 525E --F67xnxMyVwCoXwbx Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.4 (GNU/Linux) iD8DBQFCLI+Vat1JN+IKUl4RAjenAJ4gOoXFlfjwa8fRMT7on6kEn9qDsQCgqAU8 umlrOS+3w7ZhM5BI0l5ilzo= =jMD9 -----END PGP SIGNATURE----- --F67xnxMyVwCoXwbx-- From davem@davemloft.net Mon Mar 7 09:33:15 2005 Received: with ECARTIS (v1.0.0; list netdev); Mon, 07 Mar 2005 09:33:21 -0800 (PST) Received: from cheetah.davemloft.net (mail@dsl027-180-174.sfo1.dsl.speakeasy.net [216.27.180.174]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j27HXF5Q024904 for ; Mon, 7 Mar 2005 09:33:15 -0800 Received: from localhost ([127.0.0.1] helo=cheetah.davemloft.net ident=davem) by cheetah.davemloft.net with smtp (Exim 3.36 #1 (Debian)) id 1D8M5R-0000Ih-00; Mon, 07 Mar 2005 09:32:09 -0800 Date: Mon, 7 Mar 2005 09:32:09 -0800 From: "David S. Miller" To: Herbert Xu Cc: kuznet@ms2.inr.ac.ru, jmorris@redhat.com, yoshfuji@linux-ipv6.org, netdev@oss.sgi.com Subject: Re: [9/*] [IPSEC] Check dst validity harder in xfrm_bundle_ok Message-Id: <20050307093209.023c3a1a.davem@davemloft.net> In-Reply-To: <20050307103536.GB7137@gondor.apana.org.au> References: <20050214221006.GA18415@gondor.apana.org.au> <20050214221200.GA18465@gondor.apana.org.au> <20050214221433.GB18465@gondor.apana.org.au> <20050214221607.GC18465@gondor.apana.org.au> <20050306213214.7d8a143d.davem@davemloft.net> <20050307103536.GB7137@gondor.apana.org.au> X-Mailer: Sylpheed version 1.0.1 (GTK+ 1.2.10; sparc-unknown-linux-gnu) X-Face: "_;p5u5aPsO,_Vsx"^v-pEq09'CU4&Dc1$fQExov$62l60cgCc%FnIwD=.UF^a>?5'9Kn[;433QFVV9M..2eN.@4ZWPGbdi<=?[:T>y?SD(R*-3It"Vj:)"dP Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV 0.83/751/Mon Mar 7 03:06:27 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 2596 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: davem@davemloft.net Precedence: bulk X-list: netdev Content-Length: 721 Lines: 18 On Mon, 7 Mar 2005 21:35:36 +1100 Herbert Xu wrote: > There is another bug in xfrm_bundle_ok where I forgot to > check the validity of xdst->route. In fact, the check > on dst->path isn't strong enough either. For IPv6 entries, > dst->path->obsolete is always negative until you call > ipv6_dst_check. So we really need to do that here. > > Here's the patch to fix those two problems. Yes I know > my dst_check implementation is lame. I'll come back and > fix up all the dst_check functions by moving their dst_release > calls out. It proves that you were right in that IPv6 dst > leak thread :) > > Signed-off-by: Herbert Xu Applied, thanks Herbert. From davem@davemloft.net Mon Mar 7 09:33:52 2005 Received: with ECARTIS (v1.0.0; list netdev); Mon, 07 Mar 2005 09:33:55 -0800 (PST) Received: from cheetah.davemloft.net (mail@dsl027-180-174.sfo1.dsl.speakeasy.net [216.27.180.174]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j27HXngI025192 for ; Mon, 7 Mar 2005 09:33:52 -0800 Received: from localhost ([127.0.0.1] helo=cheetah.davemloft.net ident=davem) by cheetah.davemloft.net with smtp (Exim 3.36 #1 (Debian)) id 1D8M6S-0000J4-00; Mon, 07 Mar 2005 09:33:12 -0800 Date: Mon, 7 Mar 2005 09:33:12 -0800 From: "David S. Miller" To: Herbert Xu Cc: kuznet@ms2.inr.ac.ru, jmorris@redhat.com, yoshfuji@linux-ipv6.org, kaber@trash.net, netdev@oss.sgi.com Subject: Re: [10/*] [TCP] Get rid of dst_ptmu/ext2_header_len Message-Id: <20050307093312.68a2dd22.davem@davemloft.net> In-Reply-To: <20050307114533.GA11190@gondor.apana.org.au> References: <20050214221006.GA18415@gondor.apana.org.au> <20050214221200.GA18465@gondor.apana.org.au> <20050214221433.GB18465@gondor.apana.org.au> <20050214221607.GC18465@gondor.apana.org.au> <20050216103744.GA476@gondor.apana.org.au> <20050307114533.GA11190@gondor.apana.org.au> X-Mailer: Sylpheed version 1.0.1 (GTK+ 1.2.10; sparc-unknown-linux-gnu) X-Face: "_;p5u5aPsO,_Vsx"^v-pEq09'CU4&Dc1$fQExov$62l60cgCc%FnIwD=.UF^a>?5'9Kn[;433QFVV9M..2eN.@4ZWPGbdi<=?[:T>y?SD(R*-3It"Vj:)"dP Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV 0.83/751/Mon Mar 7 03:06:27 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 2597 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: davem@davemloft.net Precedence: bulk X-list: netdev Content-Length: 453 Lines: 14 On Mon, 7 Mar 2005 22:45:33 +1100 Herbert Xu wrote: > Here is a patch that replaces all occurrences of dst_pmtu in the TCP > stack. As a result we no longer need ext2_header_len. > > This has a nice synergetic effect with Arnaldo's latest change to > linux/tcp.h :) > > Signed-off-by: Herbert Xu > > I'll be removing other users of dst->path/dst_pmtu next. Also applied, thanks Herbert. From davem@davemloft.net Mon Mar 7 09:35:01 2005 Received: with ECARTIS (v1.0.0; list netdev); Mon, 07 Mar 2005 09:35:05 -0800 (PST) Received: from cheetah.davemloft.net (mail@dsl027-180-174.sfo1.dsl.speakeasy.net [216.27.180.174]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j27HYwLo025789 for ; Mon, 7 Mar 2005 09:35:01 -0800 Received: from localhost ([127.0.0.1] helo=cheetah.davemloft.net ident=davem) by cheetah.davemloft.net with smtp (Exim 3.36 #1 (Debian)) id 1D8M88-0000Jh-00; Mon, 07 Mar 2005 09:34:56 -0800 Date: Mon, 7 Mar 2005 09:34:56 -0800 From: "David S. Miller" To: akpm@osdl.org Cc: netdev@oss.sgi.com, akpm@osdl.org Subject: Re: [patch 1/1] atalk build fix Message-Id: <20050307093456.4aa0b4c6.davem@davemloft.net> In-Reply-To: <200503070950.j279oxDf000951@shell0.pdx.osdl.net> References: <200503070950.j279oxDf000951@shell0.pdx.osdl.net> X-Mailer: Sylpheed version 1.0.1 (GTK+ 1.2.10; sparc-unknown-linux-gnu) X-Face: "_;p5u5aPsO,_Vsx"^v-pEq09'CU4&Dc1$fQExov$62l60cgCc%FnIwD=.UF^a>?5'9Kn[;433QFVV9M..2eN.@4ZWPGbdi<=?[:T>y?SD(R*-3It"Vj:)"dP Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV 0.83/751/Mon Mar 7 03:06:27 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 2598 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: davem@davemloft.net Precedence: bulk X-list: netdev Content-Length: 198 Lines: 7 On Mon, 07 Mar 2005 01:50:35 -0800 akpm@osdl.org wrote: > In file included from drivers/net/appletalk/cops.c:70: > include/linux/atalk.h:67: field `sk' has incomplete type Applied, thanks Andrew. From davem@davemloft.net Mon Mar 7 09:35:24 2005 Received: with ECARTIS (v1.0.0; list netdev); Mon, 07 Mar 2005 09:35:29 -0800 (PST) Received: from cheetah.davemloft.net (mail@dsl027-180-174.sfo1.dsl.speakeasy.net [216.27.180.174]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j27HZNuP026048 for ; Mon, 7 Mar 2005 09:35:23 -0800 Received: from localhost ([127.0.0.1] helo=cheetah.davemloft.net ident=davem) by cheetah.davemloft.net with smtp (Exim 3.36 #1 (Debian)) id 1D8M7l-0000Ja-00; Mon, 07 Mar 2005 09:34:33 -0800 Date: Mon, 7 Mar 2005 09:34:33 -0800 From: "David S. Miller" To: Jeff Garzik Cc: acme@conectiva.com.br, netdev@oss.sgi.com Subject: Re: build breakage Message-Id: <20050307093433.3b3270b0.davem@davemloft.net> In-Reply-To: <422C09FD.3000702@pobox.com> References: <422C09FD.3000702@pobox.com> X-Mailer: Sylpheed version 1.0.1 (GTK+ 1.2.10; sparc-unknown-linux-gnu) X-Face: "_;p5u5aPsO,_Vsx"^v-pEq09'CU4&Dc1$fQExov$62l60cgCc%FnIwD=.UF^a>?5'9Kn[;433QFVV9M..2eN.@4ZWPGbdi<=?[:T>y?SD(R*-3It"Vj:)"dP Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV 0.83/751/Mon Mar 7 03:06:27 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 2599 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: davem@davemloft.net Precedence: bulk X-list: netdev Content-Length: 494 Lines: 16 On Mon, 07 Mar 2005 02:59:57 -0500 Jeff Garzik wrote: > Upstream net changes caused this to appear.. > > CC drivers/net/appletalk/cops.o > In file included from drivers/net/appletalk/cops.c:70: > include/linux/atalk.h:67: error: field `sk' has incomplete type > make[3]: *** [drivers/net/appletalk/cops.o] Error 1 > make[2]: *** [drivers/net/appletalk] Error 2 atalk.h needs net/sock.h, I've just applied a patch from Andrew Morton fixing exactly that. Thanks. From davem@davemloft.net Mon Mar 7 09:36:00 2005 Received: with ECARTIS (v1.0.0; list netdev); Mon, 07 Mar 2005 09:36:04 -0800 (PST) Received: from cheetah.davemloft.net (mail@dsl027-180-174.sfo1.dsl.speakeasy.net [216.27.180.174]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j27Ha0XW026636 for ; Mon, 7 Mar 2005 09:36:00 -0800 Received: from localhost ([127.0.0.1] helo=cheetah.davemloft.net ident=davem) by cheetah.davemloft.net with smtp (Exim 3.36 #1 (Debian)) id 1D8M8y-0000K2-00; Mon, 07 Mar 2005 09:35:48 -0800 Date: Mon, 7 Mar 2005 09:35:48 -0800 From: "David S. Miller" To: Herbert Xu Cc: netdev@oss.sgi.com Subject: Re: [IPSEC] Kill redundan dst_release check in xfrm_dst_destroy Message-Id: <20050307093548.1c10ef80.davem@davemloft.net> In-Reply-To: <20050307101657.GA7486@gondor.apana.org.au> References: <20050214221006.GA18415@gondor.apana.org.au> <20050214221200.GA18465@gondor.apana.org.au> <20050214221433.GB18465@gondor.apana.org.au> <20050307101657.GA7486@gondor.apana.org.au> X-Mailer: Sylpheed version 1.0.1 (GTK+ 1.2.10; sparc-unknown-linux-gnu) X-Face: "_;p5u5aPsO,_Vsx"^v-pEq09'CU4&Dc1$fQExov$62l60cgCc%FnIwD=.UF^a>?5'9Kn[;433QFVV9M..2eN.@4ZWPGbdi<=?[:T>y?SD(R*-3It"Vj:)"dP Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV 0.83/751/Mon Mar 7 03:06:27 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 2600 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: davem@davemloft.net Precedence: bulk X-list: netdev Content-Length: 301 Lines: 9 On Mon, 7 Mar 2005 21:16:57 +1100 Herbert Xu wrote: > Here's a trivial patch to get rid of a redundant check that I added > in patch 3/4. dst_release already checks for dst == NULL. > > Signed-off-by: Herbert Xu Applied, thanks Herbert. From asimshankar@gmail.com Mon Mar 7 09:51:28 2005 Received: with ECARTIS (v1.0.0; list netdev); Mon, 07 Mar 2005 09:51:31 -0800 (PST) Received: from wproxy.gmail.com (wproxy.gmail.com [64.233.184.203]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j27HpRRG027930 for ; Mon, 7 Mar 2005 09:51:28 -0800 Received: by wproxy.gmail.com with SMTP id 71so1343827wri for ; Mon, 07 Mar 2005 09:51:20 -0800 (PST) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:reply-to:to:subject:mime-version:content-type:content-transfer-encoding; b=M4D4hsUgJA3DUUZ3voQPYEER8P/FTyTVLaRBVGRv+UKMaNLbFuJsrYw9ToPajZe2+kCSHoBCn3eSqbWed+ayaZRdl3NnNXSGn2Jti/1vfw0TB56aOteZblZ8Z6xj381aGT0BD2lBhHIpEkdhlVa1UmXzm+AYjbdVO4Wc3scjK5E= Received: by 10.54.71.19 with SMTP id t19mr60635wra; Mon, 07 Mar 2005 09:50:40 -0800 (PST) Received: by 10.54.24.42 with HTTP; Mon, 7 Mar 2005 09:50:39 -0800 (PST) Message-ID: <7bca1cb505030709502316f9b8@mail.gmail.com> Date: Mon, 7 Mar 2005 11:50:39 -0600 From: Asim Shankar Reply-To: Asim Shankar To: netdev@oss.sgi.com Subject: Dynamically classifying flows? Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV 0.83/751/Mon Mar 7 03:06:27 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 2601 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: asimshankar@gmail.com Precedence: bulk X-list: netdev Content-Length: 3283 Lines: 65 Hi, I was looking into various queueing disciplines and had some thoughts/queries. This email is going to be fairly high-level and somewhat long, so I'd be grateful if you can bear with me. Okay, so qdiscs can be run in various ways - FIFO, Round Robin (SFQ, PRIO), HTB etc. Grossly oversimplified, I see all these strategies as allowing administrators to statically define packet classes and class priorities, and then possibly ensuring fairness amongst packets with equal class priotities. This "staticness" of class priorities *may* lead to some problems (well, I'm going to ask if they can). Consider a huge, popular file on an HTTP server. Due to its popularity, requests for small pages may suffer. Similarly, consider an SSH/SFTP server where SFTP traffic for large, popular files may choke the SSH terminal connections (especially if the application doesn't set the TOS bits or routers along the way ignore them). So we have interactive flows (like someone SSHing to do some 'ls'es or many clients viewing a small web-page) and bulk flows (downloads). By "flow" I mean a connection, not necessarily an explicit TCP connection but a loose definition - say something that "ip_conntrack" tracks. Question 1: Can the number of and speed with which bulk flow packets are generated adversely affect the interactive flows - i.e., can too many large file downloads make the 'ls' or the small page downloads slow? Is this a _likely_ scenario? Diffserv already in effect tries to classify traffic as interactive or bulk. However, this classification is still static and requires application cooperation, which may not always be available or may be overridden. Web servers for example don't change the TOS fields depending on whether the file requested was a 700MB CD-image or a 2K homepage. Question 2: Does the idea of _dynamically_ classifying traffic as interactive or bulk make any sense at all? Or does the TOS field work well enough for dynamic classification to not be of any practical interest? If it does make sense, Question 3: Has work already been along along these lines? If so, any pointers would be appreciated. Can we use ideas from process scheduling to be kinder to the interactive flows? A "process" becomes a "flow", the "CPU" becomes the "NIC" and "time" becomes "bytes". Process scheduling tries to keep system responsiveness high by dynamically classifying processes as interactive or bulk and then making interactive process priorities higher than non-interactive. A similar strategy at the qdisc would mean that when the interactive flow has something to send, it will get a higher priority. Flows will be dynamically assigned priorities based on the history of traffic they generate. Applying process scheduling would be somewhat expensive (we're keeping track of connections). RED on the other hand does something *like* this by making the probability of a packet drop of a particular flow proportional to the traffic generated by the flow, of course it does so without any explicit notion of flows. This leads to: Question 5: Does RED provide *everything* this process-scheduling strategy would? i.e., how would you compare the two? Well, I guess that completes my question list for now. Thanks for reading (and replying :-)), Regards, -- Asim From acme@conectiva.com.br Mon Mar 7 09:52:46 2005 Received: with ECARTIS (v1.0.0; list netdev); Mon, 07 Mar 2005 09:52:51 -0800 (PST) Received: from orion.netbank.com.br (orion.netbank.com.br [200.203.199.90]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j27Hqi4R028304 for ; Mon, 7 Mar 2005 09:52:45 -0800 Received: from [200.138.46.56] (helo=oops.ghostprotocols.net) by orion.netbank.com.br with asmtp (Exim 3.33 #1) id 1D8MOe-0000yO-00; Mon, 07 Mar 2005 14:52:00 -0300 Received: by oops.ghostprotocols.net (Postfix, from userid 500) id 296F774F21; Mon, 7 Mar 2005 14:52:31 -0300 (BRT) Date: Mon, 7 Mar 2005 14:52:31 -0300 From: Arnaldo Carvalho de Melo To: "David S. Miller" Cc: Jeff Garzik , netdev@oss.sgi.com Subject: Re: build breakage Message-ID: <20050307175231.GB28841@conectiva.com.br> References: <422C09FD.3000702@pobox.com> <20050307093433.3b3270b0.davem@davemloft.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20050307093433.3b3270b0.davem@davemloft.net> X-Url: http://advogato.org/person/acme User-Agent: Mutt/1.5.6i X-Virus-Scanned: ClamAV 0.83/751/Mon Mar 7 03:06:27 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 2602 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: acme@conectiva.com.br Precedence: bulk X-list: netdev Content-Length: 650 Lines: 18 Em Mon, Mar 07, 2005 at 09:34:33AM -0800, David S. Miller escreveu: > On Mon, 07 Mar 2005 02:59:57 -0500 > Jeff Garzik wrote: > > > Upstream net changes caused this to appear.. > > > > CC drivers/net/appletalk/cops.o > > In file included from drivers/net/appletalk/cops.c:70: > > include/linux/atalk.h:67: error: field `sk' has incomplete type > > make[3]: *** [drivers/net/appletalk/cops.o] Error 1 > > make[2]: *** [drivers/net/appletalk] Error 2 > > atalk.h needs net/sock.h, I've just applied a patch from > Andrew Morton fixing exactly that. > > Thanks. Thanks, I wonder how this one slipped in unnoticed... :-\ From shemminger@osdl.org Mon Mar 7 10:07:36 2005 Received: with ECARTIS (v1.0.0; list netdev); Mon, 07 Mar 2005 10:07:42 -0800 (PST) Received: from smtp.osdl.org (fire.osdl.org [65.172.181.4]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j27I7ZVb029618 for ; Mon, 7 Mar 2005 10:07:36 -0800 Received: from shell0.pdx.osdl.net (fw.osdl.org [65.172.181.6]) by smtp.osdl.org (8.12.8/8.12.8) with ESMTP id j27I7Sqi009592 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO); Mon, 7 Mar 2005 10:07:28 -0800 Received: from dxpl.pdx.osdl.net (dxpl.pdx.osdl.net [172.20.1.103]) by shell0.pdx.osdl.net (8.13.1/8.11.6) with ESMTP id j27I7SwE019663; Mon, 7 Mar 2005 10:07:28 -0800 Date: Mon, 7 Mar 2005 10:07:44 -0800 From: Stephen Hemminger To: Ben Greear Cc: netdev@oss.sgi.com Subject: Re: [leo@yuriev.ru: [PATCH] ethernet-bridge: update skb->priority in case forwarded frame has VLAN-header] Message-ID: <20050307100744.429e100a@dxpl.pdx.osdl.net> In-Reply-To: <20050305141225.GA5180@xi.wantstofly.org> References: <20050305141225.GA5180@xi.wantstofly.org> Organization: Open Source Development Lab X-Mailer: Sylpheed-Claws 1.0.1 (GTK+ 1.2.10; x86_64-unknown-linux-gnu) X-Face: &@E+xe?c%:&e4D{>f1O<&U>2qwRREG5!}7R4;D<"NO^UI2mJ[eEOA2*3>(`Th.yP,VDPo9$ /`~cw![cmj~~jWe?AHY7D1S+\}5brN0k*NE?pPh_'_d>6;XGG[\KDRViCfumZT3@[ Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Received-SPF: pass (domain of shemminger@osdl.org designates 65.172.181.6 as permitted sender) X-MIMEDefang-Filter: osdl$Revision: 1.104 $ X-Scanned-By: MIMEDefang 2.36 X-Virus-Scanned: ClamAV 0.83/751/Mon Mar 7 03:06:27 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 2603 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: shemminger@osdl.org Precedence: bulk X-list: netdev Content-Length: 865 Lines: 23 On Sat, 5 Mar 2005 15:12:25 +0100 Lennert Buytenhek wrote: > ----- Forwarded message from Leo Yuriev ----- > > From: Leo Yuriev > To: Lennert Buytenhek , > Alexey Kuznetsov > Cc: linux-kernel@vger.kernel.org > Subject: [PATCH] ethernet-bridge: update skb->priority in case forwarded frame has VLAN-header > > Kernel 2.6 (2.6.11) > > When ethernet-bridge forward a packet and such ethernet-frame has > VLAN-tag, bridge should update skb->prioriry for properly QoS > handling. > > This small patch does this. Currently vlan_TCI-priority directly > mapped to skb->priority, but this looks enough. I don't see why the VLAN code doesn't handle this itself. I don't like special case layer violations because it becomes a slippery slope with more and more additions. From greearb@candelatech.com Mon Mar 7 10:13:40 2005 Received: with ECARTIS (v1.0.0; list netdev); Mon, 07 Mar 2005 10:13:45 -0800 (PST) Received: from www.lanforge.com (ns1.lanforge.com [66.165.47.210]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j27IDdJI030316 for ; Mon, 7 Mar 2005 10:13:40 -0800 Received: from [4.33.45.22] (evrtwa1-ar2-4-33-045-022.evrtwa1.dsl-verizon.net [4.33.45.22]) (authenticated bits=0) by www.lanforge.com (8.12.8/8.12.8) with ESMTP id j27IacLH030142; Mon, 7 Mar 2005 10:36:38 -0800 Message-ID: <422C99D1.4030105@candelatech.com> Date: Mon, 07 Mar 2005 10:13:37 -0800 From: Ben Greear Organization: Candela Technologies User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.7.3) Gecko/20041020 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Stephen Hemminger CC: netdev@oss.sgi.com Subject: Re: [leo@yuriev.ru: [PATCH] ethernet-bridge: update skb->priority in case forwarded frame has VLAN-header] References: <20050305141225.GA5180@xi.wantstofly.org> <20050307100744.429e100a@dxpl.pdx.osdl.net> In-Reply-To: <20050307100744.429e100a@dxpl.pdx.osdl.net> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV 0.83/751/Mon Mar 7 03:06:27 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 2604 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: greearb@candelatech.com Precedence: bulk X-list: netdev Content-Length: 1176 Lines: 37 Stephen Hemminger wrote: > On Sat, 5 Mar 2005 15:12:25 +0100 > Lennert Buytenhek wrote: > > >>----- Forwarded message from Leo Yuriev ----- >> >>From: Leo Yuriev >>To: Lennert Buytenhek , >> Alexey Kuznetsov >>Cc: linux-kernel@vger.kernel.org >>Subject: [PATCH] ethernet-bridge: update skb->priority in case forwarded frame has VLAN-header >> >>Kernel 2.6 (2.6.11) >> >>When ethernet-bridge forward a packet and such ethernet-frame has >>VLAN-tag, bridge should update skb->prioriry for properly QoS >>handling. >> >>This small patch does this. Currently vlan_TCI-priority directly >>mapped to skb->priority, but this looks enough. > > > I don't see why the VLAN code doesn't handle this itself. I don't like special > case layer violations because it becomes a slippery slope with more and > more additions. VLAN does handle this. The main use for the patch is for bridging VLANs across a normal ethernet device, it appears. Ie, not really using the VLAN module at all. Ben -- Ben Greear Candela Technologies Inc http://www.candelatech.com From kaber@trash.net Mon Mar 7 10:16:58 2005 Received: with ECARTIS (v1.0.0; list netdev); Mon, 07 Mar 2005 10:17:02 -0800 (PST) Received: from kaber.coreworks.de ([62.206.217.67]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j27IGvRM030913 for ; Mon, 7 Mar 2005 10:16:58 -0800 Received: from localhost ([127.0.0.1]) by kaber.coreworks.de with esmtp (Exim 4.50) id 1D8Mmg-0001XT-4e; Mon, 07 Mar 2005 19:16:50 +0100 Message-ID: <422C9A92.6040902@trash.net> Date: Mon, 07 Mar 2005 19:16:50 +0100 From: Patrick McHardy User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.7.5) Gecko/20050106 Debian/1.7.5-1 X-Accept-Language: en MIME-Version: 1.0 To: Stephen Hemminger CC: Ben Greear , netdev@oss.sgi.com Subject: Re: [leo@yuriev.ru: [PATCH] ethernet-bridge: update skb->priority in case forwarded frame has VLAN-header] References: <20050305141225.GA5180@xi.wantstofly.org> <20050307100744.429e100a@dxpl.pdx.osdl.net> In-Reply-To: <20050307100744.429e100a@dxpl.pdx.osdl.net> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV 0.83/751/Mon Mar 7 03:06:27 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 2605 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: kaber@trash.net Precedence: bulk X-list: netdev Content-Length: 623 Lines: 17 Stephen Hemminger wrote: >> >>This small patch does this. Currently vlan_TCI-priority directly >>mapped to skb->priority, but this looks enough. > > I don't see why the VLAN code doesn't handle this itself. I don't like special > case layer violations because it becomes a slippery slope with more and > more additions. The patch is meant for bridges briging vlan frames without doing vlan themselves. I agree with you, from the bridge point of view a vlan header is just as outside of its scope as an IP header, that's why I proposed to put it in an ebtables target and make it useable for vlan and IP. Regards Patrick From shemminger@osdl.org Mon Mar 7 10:50:26 2005 Received: with ECARTIS (v1.0.0; list netdev); Mon, 07 Mar 2005 10:50:31 -0800 (PST) Received: from smtp.osdl.org (fire.osdl.org [65.172.181.4]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j27IoP6A031951 for ; Mon, 7 Mar 2005 10:50:26 -0800 Received: from shell0.pdx.osdl.net (fw.osdl.org [65.172.181.6]) by smtp.osdl.org (8.12.8/8.12.8) with ESMTP id j27IoJqi012677 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO); Mon, 7 Mar 2005 10:50:20 -0800 Received: from dxpl.pdx.osdl.net (dxpl.pdx.osdl.net [172.20.1.103]) by shell0.pdx.osdl.net (8.13.1/8.11.6) with ESMTP id j27IoJS6021764; Mon, 7 Mar 2005 10:50:19 -0800 Date: Mon, 7 Mar 2005 10:50:36 -0800 From: Stephen Hemminger To: Patrick McHardy Cc: Ben Greear , netdev@oss.sgi.com Subject: Re: [leo@yuriev.ru: [PATCH] ethernet-bridge: update skb->priority in case forwarded frame has VLAN-header] Message-ID: <20050307105036.4a7e4fea@dxpl.pdx.osdl.net> In-Reply-To: <422C9A92.6040902@trash.net> References: <20050305141225.GA5180@xi.wantstofly.org> <20050307100744.429e100a@dxpl.pdx.osdl.net> <422C9A92.6040902@trash.net> Organization: Open Source Development Lab X-Mailer: Sylpheed-Claws 1.0.1 (GTK+ 1.2.10; x86_64-unknown-linux-gnu) X-Face: &@E+xe?c%:&e4D{>f1O<&U>2qwRREG5!}7R4;D<"NO^UI2mJ[eEOA2*3>(`Th.yP,VDPo9$ /`~cw![cmj~~jWe?AHY7D1S+\}5brN0k*NE?pPh_'_d>6;XGG[\KDRViCfumZT3@[ Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Received-SPF: pass (domain of shemminger@osdl.org designates 65.172.181.6 as permitted sender) X-MIMEDefang-Filter: osdl$Revision: 1.104 $ X-Scanned-By: MIMEDefang 2.36 X-Virus-Scanned: ClamAV 0.83/751/Mon Mar 7 03:06:27 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 2606 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: shemminger@osdl.org Precedence: bulk X-list: netdev Content-Length: 806 Lines: 20 On Mon, 07 Mar 2005 19:16:50 +0100 Patrick McHardy wrote: > Stephen Hemminger wrote: > >> > >>This small patch does this. Currently vlan_TCI-priority directly > >>mapped to skb->priority, but this looks enough. > > > > I don't see why the VLAN code doesn't handle this itself. I don't like special > > case layer violations because it becomes a slippery slope with more and > > more additions. > > The patch is meant for bridges briging vlan frames without doing > vlan themselves. I agree with you, from the bridge point of view > a vlan header is just as outside of its scope as an IP header, > that's why I proposed to put it in an ebtables target and make > it useable for vlan and IP. That's much better. Leave the protocol violations to netfilter modules where they belong ;-) From shemminger@osdl.org Mon Mar 7 10:59:28 2005 Received: with ECARTIS (v1.0.0; list netdev); Mon, 07 Mar 2005 10:59:32 -0800 (PST) Received: from smtp.osdl.org (fire.osdl.org [65.172.181.4]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j27IxRD0000380 for ; Mon, 7 Mar 2005 10:59:28 -0800 Received: from shell0.pdx.osdl.net (fw.osdl.org [65.172.181.6]) by smtp.osdl.org (8.12.8/8.12.8) with ESMTP id j27IxKqi013337 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO); Mon, 7 Mar 2005 10:59:20 -0800 Received: from dxpl.pdx.osdl.net (dxpl.pdx.osdl.net [172.20.1.103]) by shell0.pdx.osdl.net (8.13.1/8.11.6) with ESMTP id j27IxKZh022125; Mon, 7 Mar 2005 10:59:20 -0800 Date: Mon, 7 Mar 2005 10:59:36 -0800 From: Stephen Hemminger To: Francois Romieu Cc: Jon Mason , netdev@oss.sgi.com Subject: Re: r8169: panic on 2.6.11 Message-ID: <20050307105936.12bca470@dxpl.pdx.osdl.net> In-Reply-To: <20050305003735.GE1148@electric-eye.fr.zoreil.com> References: <20050304132804.270cf05b@dxpl.pdx.osdl.net> <20050304145317.772859da@dxpl.pdx.osdl.net> <20050304230214.GC1148@electric-eye.fr.zoreil.com> <200503041728.54026.jdmason@us.ibm.com> <20050304154903.7b7e0fb1@dxpl.pdx.osdl.net> <20050305003735.GE1148@electric-eye.fr.zoreil.com> Organization: Open Source Development Lab X-Mailer: Sylpheed-Claws 1.0.1 (GTK+ 1.2.10; x86_64-unknown-linux-gnu) X-Face: &@E+xe?c%:&e4D{>f1O<&U>2qwRREG5!}7R4;D<"NO^UI2mJ[eEOA2*3>(`Th.yP,VDPo9$ /`~cw![cmj~~jWe?AHY7D1S+\}5brN0k*NE?pPh_'_d>6;XGG[\KDRViCfumZT3@[ Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Received-SPF: pass (domain of shemminger@osdl.org designates 65.172.181.6 as permitted sender) X-MIMEDefang-Filter: osdl$Revision: 1.104 $ X-Scanned-By: MIMEDefang 2.36 X-Virus-Scanned: ClamAV 0.83/751/Mon Mar 7 03:06:27 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 2607 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: shemminger@osdl.org Precedence: bulk X-list: netdev Content-Length: 743 Lines: 25 On Sat, 5 Mar 2005 01:37:35 +0100 Francois Romieu wrote: > Stephen Hemminger : > [...] > > Added this and took out "too much work at interrupt message" > > Ok (leaks but see below). > > > And got this (before it died): > > > > eth0: status=803ff0 opts=803ff0 opts2=0 addr=0:106ad012 > ^^^^^^ > 3ff0 would be a ~16k packet. The high weight byte is > missing: the descriptor would be strictly somewhere between > the first descriptor and the last descriptor for the packet. > > opts=80xxxx -> FIFO overflow (*bulb flashes*) > > The code does not look pretty there. Doesn't come up because it gets that bit set in the normal case. eth0: Rx ERROR status=328440ff!!! From kaber@trash.net Mon Mar 7 11:37:00 2005 Received: with ECARTIS (v1.0.0; list netdev); Mon, 07 Mar 2005 11:37:04 -0800 (PST) Received: from kaber.coreworks.de ([62.206.217.67]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j27JaxQj001649 for ; Mon, 7 Mar 2005 11:37:00 -0800 Received: from localhost ([127.0.0.1]) by kaber.coreworks.de with esmtp (Exim 4.50) id 1D8O1r-0001fU-N1; Mon, 07 Mar 2005 20:36:35 +0100 Date: Mon, 7 Mar 2005 20:36:35 +0100 (CET) From: Patrick McHardy X-X-Sender: kaber@kaber.coreworks.de To: jamal cc: Ben Greear , leo@yuriev.ru, Lennert Buytenhek , shemminger@osdl.org, netdev@oss.sgi.com Subject: Re: [leo@yuriev.ru: [PATCH] ethernet-bridge: update skb->priority in case forwarded frame has VLAN-header] In-Reply-To: <1110199696.1094.1299.camel@jzny.localdomain> Message-ID: References: <20050305141225.GA5180@xi.wantstofly.org> <4229D98F.9010008@trash.net> <422A0C21.3050709@candelatech.com> <1110199696.1094.1299.camel@jzny.localdomain> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Virus-Scanned: ClamAV 0.83/751/Mon Mar 7 03:06:27 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 2608 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: kaber@trash.net Precedence: bulk X-list: netdev Content-Length: 488 Lines: 15 On Mon, 7 Mar 2005, jamal wrote: > This is wrong. IEEE priorities are opposite of IETF priorities (as used by > skb->prio). > Unless you install a prio qdisc and rewrite the priomap, you are screwed. > So you should do opposite mapping, i.e something along the lines of > VLAN_TCI priority (0..7) to skb->priority (15..8) i,e > > skb->priority = 15 - vlan_TCI; The priority should still start at 0. You don't want to create a 16-band queue just to have 8 bands unused. Regards Patrick From tgraf@suug.ch Mon Mar 7 12:34:35 2005 Received: with ECARTIS (v1.0.0; list netdev); Mon, 07 Mar 2005 12:34:40 -0800 (PST) Received: from b.mx.projectdream.org (eth0-0.arisu.projectdream.org [194.158.4.191]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j27KYX9M007060 for ; Mon, 7 Mar 2005 12:34:34 -0800 Received: from postel.suug.ch (postel.suug.ch [195.134.158.23]) (using TLSv1 with cipher EDH-RSA-DES-CBC3-SHA (168/168 bits)) (No client certificate requested) by b.mx.projectdream.org (Postfix) with ESMTP id 96BA182; Mon, 7 Mar 2005 21:34:08 +0100 (CET) Received: by postel.suug.ch (Postfix, from userid 10001) id AF9941C0EA; Mon, 7 Mar 2005 21:34:50 +0100 (CET) Date: Mon, 7 Mar 2005 21:34:50 +0100 From: Thomas Graf To: Asim Shankar Cc: netdev@oss.sgi.com Subject: Re: Dynamically classifying flows? Message-ID: <20050307203450.GX31837@postel.suug.ch> References: <7bca1cb505030709502316f9b8@mail.gmail.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <7bca1cb505030709502316f9b8@mail.gmail.com> X-Virus-Scanned: ClamAV 0.83/751/Mon Mar 7 03:06:27 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 2609 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: tgraf@suug.ch Precedence: bulk X-list: netdev Content-Length: 3556 Lines: 63 * Asim Shankar <7bca1cb505030709502316f9b8@mail.gmail.com> 2005-03-07 11:50 > Okay, so qdiscs can be run in various ways - FIFO, Round Robin (SFQ, PRIO), > HTB etc. Grossly oversimplified, I see all these strategies as allowing > administrators to statically define packet classes and class priorities, and > then possibly ensuring fairness amongst packets with equal class priotities. > > This "staticness" of class priorities *may* lead to some problems (well, I'm > going to ask if they can). Consider a huge, popular file on an HTTP server. > Due to its popularity, requests for small pages may suffer. Similarly, > consider an SSH/SFTP server where SFTP traffic for large, popular files may > choke the SSH terminal connections (especially if the application doesn't set > the TOS bits or routers along the way ignore them). So we have interactive > flows (like someone SSHing to do some 'ls'es or many clients viewing a small > web-page) and bulk flows (downloads). By "flow" I mean a connection, not > necessarily an explicit TCP connection but a loose definition - say something > that "ip_conntrack" tracks. The example of SSH is bad because it behaves very well. A scp/sftp will have different DSCP flags than "normal" SSH sessions. > Question 1: Can the number of and speed with which bulk flow packets are > generated adversely affect the interactive flows - i.e., can too many large > file downloads make the 'ls' or the small page downloads slow? Is this a > _likely_ scenario? It is a likely scenario but usually not a problem because you can classify this kind of bulk packets by their size. u32 can be used use for such things or the newly added meta ematch. A much worse scenarios is a high amount of new, short living connections because it is hard to classify those on non-static patterns and they pollute all your queues. A real world scenario for this is a bunch of bittorrent users in your network. > Question 2: Does the idea of _dynamically_ classifying traffic as interactive > or bulk make any sense at all? Or does the TOS field work well enough for > dynamic classification to not be of any practical interest? Yes it does and that's exactly the direction the ematch API is going to. > Question 3: Has work already been along along these lines? If so, any pointers > would be appreciated. Quite a few papers but most of them don't work in practice for me. > Can we use ideas from process scheduling to be kinder to the interactive > flows? A "process" becomes a "flow", the "CPU" becomes the "NIC" and "time" > becomes "bytes". Process scheduling tries to keep system responsiveness high > by dynamically classifying processes as interactive or bulk and then making > interactive process priorities higher than non-interactive. A similar strategy > at the qdisc would mean that when the interactive flow has something to send, > it will get a higher priority. Flows will be dynamically assigned priorities > based on the history of traffic they generate. In order to prioritize there must be a queue, and for remote terminal protocols you want to avoid queues at any cost because it will introduce latency in any case. Even on overloaded lines with full queues, the queues are rarely bigh enough to really apply any sort of priority queues. Another problem that arises is that usually you want different queue parameters depending on the type of traffic it holds. I'm not sure if it would help to determine those more dynamically, intuitively I'd say it doesn't make too much sense but feel free to prove me wrong. From ahu@outpost.ds9a.nl Mon Mar 7 13:32:15 2005 Received: with ECARTIS (v1.0.0; list netdev); Mon, 07 Mar 2005 13:32:20 -0800 (PST) Received: from outpost.ds9a.nl (postfix@outpost.ds9a.nl [213.244.168.210]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j27LWEct009161 for ; Mon, 7 Mar 2005 13:32:14 -0800 Received: by outpost.ds9a.nl (Postfix, from userid 1000) id ACB983F66; Mon, 7 Mar 2005 22:32:11 +0100 (CET) Date: Mon, 7 Mar 2005 22:32:11 +0100 From: bert hubert To: Mark Smith Cc: hadi@cyberus.ca, netdev@oss.sgi.com Subject: Re: bridge between ppp and ethernet - 1 IP address and assign it to another host Message-ID: <20050307213211.GA25323@outpost.ds9a.nl> Mail-Followup-To: bert hubert , Mark Smith , hadi@cyberus.ca, netdev@oss.sgi.com References: <20050306153108.20430b58.random@72616e646f6d20323030342d30342d31360a.nosense.org> <1110199198.1094.1282.camel@jzny.localdomain> <20050308002643.7eac84e7.random@72616e646f6d20323030342d30342d31360a.nosense.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20050308002643.7eac84e7.random@72616e646f6d20323030342d30342d31360a.nosense.org> User-Agent: Mutt/1.3.28i X-Virus-Scanned: ClamAV 0.83/751/Mon Mar 7 03:06:27 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 2610 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: ahu@ds9a.nl Precedence: bulk X-list: netdev Content-Length: 1179 Lines: 28 On Tue, Mar 08, 2005 at 12:26:43AM +1030, Mark Smith wrote: > (Bert, sorry for calling you Ben earlier, I must have got a bit > distracted between seeing your name on a web page, and typing it on my > email client) I'll live :-) there are several Ben's I'd love to be confused with :-) > I'm fairly confident that broadly I'm thinking about the same way as > Bert, although as I'm about to go into some detail, it might turn out we > have slightly different ideas. Indeed, we are in full agreement. The idea is to have the ability to fully firewall and monitor a machine that absolutely needs to have a real routable IP address, without wasting an IP address for the router (or trying to get an ISP to assign you multiple addresses, which can be a major chore these days). I'd settle for a 'dirty' solution. Remco van Mook of Virtu.nl suggested abusing iptables -j QUEUE combind with tun/tap to inject the packets on the ethernet side, where userspace does the PPP -> ethernet conversion by making up the required headers. Ideas? -- http://www.PowerDNS.com Open source, database driven DNS Software http://netherlabs.nl Open and Closed source services From chas@cmf.nrl.navy.mil Mon Mar 7 14:03:51 2005 Received: with ECARTIS (v1.0.0; list netdev); Mon, 07 Mar 2005 14:03:57 -0800 (PST) Received: from ginger.cmf.nrl.navy.mil (ginger.cmf.nrl.navy.mil [134.207.10.161]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j27M3oGm010568 for ; Mon, 7 Mar 2005 14:03:51 -0800 Received: from cmf.nrl.navy.mil (thirdoffive.cmf.nrl.navy.mil [134.207.10.180]) by ginger.cmf.nrl.navy.mil (8.12.11/8.12.11) with ESMTP id j27M3i0u020879; Mon, 7 Mar 2005 17:03:44 -0500 (EST) Message-Id: <200503072203.j27M3i0u020879@ginger.cmf.nrl.navy.mil> To: netdev@oss.sgi.com Cc: davem@redhat.com Subject: [PATCH 1/9][ATM]: [lanai] use the DMA_{64,32}BIT_MASK constants from dma-mapping.h Date: Mon, 07 Mar 2005 17:03:44 -0500 From: "chas williams - CONTRACTOR" X-Virus-Scanned: ClamAV 0.83/751/Mon Mar 7 03:06:27 2005 on oss.sgi.com X-Virus-Scanned: NAI Completed X-Scanned-By: MIMEDefang 2.30 (www . roaringpenguin . com / mimedefang) X-Virus-Status: Clean X-archive-position: 2611 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: chas@cmf.nrl.navy.mil Precedence: bulk X-list: netdev Content-Length: 1191 Lines: 32 please apply to 2.6 -- thanks! # This is a BitKeeper generated diff -Nru style patch. # # ChangeSet # 2005/03/07 14:02:03-05:00 chas@relax.cmf.nrl.navy.mil # [ATM]: [lanai] use the DMA_{64,32}BIT_MASK constants from dma-mapping.h # # Signed-off-by: Tobias Klauser # Signed-off-by: Domen Puncer # Signed-off-by: Chas Williams # # drivers/atm/lanai.c # 2005/03/07 14:01:44-05:00 chas@relax.cmf.nrl.navy.mil +1 -1 # [ATM]: [lanai] use the DMA_{64,32}BIT_MASK constants from dma-mapping.h # # Signed-off-by: Tobias Klauser # Signed-off-by: Domen Puncer # Signed-off-by: Chas Williams # diff -Nru a/drivers/atm/lanai.c b/drivers/atm/lanai.c --- a/drivers/atm/lanai.c 2005-03-07 15:32:25 -05:00 +++ b/drivers/atm/lanai.c 2005-03-07 15:32:26 -05:00 @@ -1964,7 +1964,7 @@ return -ENXIO; } pci_set_master(pci); - if (pci_set_dma_mask(pci, 0xFFFFFFFF) != 0) { + if (pci_set_dma_mask(pci, DMA_32BIT_MASK) != 0) { printk(KERN_WARNING DEV_LABEL "(itf %d): No suitable DMA available.\n", lanai->number); return -EBUSY; From chas@cmf.nrl.navy.mil Mon Mar 7 14:04:09 2005 Received: with ECARTIS (v1.0.0; list netdev); Mon, 07 Mar 2005 14:04:14 -0800 (PST) Received: from ginger.cmf.nrl.navy.mil (ginger.cmf.nrl.navy.mil [134.207.10.161]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j27M48G8010645 for ; Mon, 7 Mar 2005 14:04:08 -0800 Received: from cmf.nrl.navy.mil (thirdoffive.cmf.nrl.navy.mil [134.207.10.180]) by ginger.cmf.nrl.navy.mil (8.12.11/8.12.11) with ESMTP id j27M41BT020891; Mon, 7 Mar 2005 17:04:01 -0500 (EST) Message-Id: <200503072204.j27M41BT020891@ginger.cmf.nrl.navy.mil> To: netdev@oss.sgi.com Cc: davem@redhat.com Subject: [PATCH 2/9][ATM]: convert from pci_module_init to pci_register_driver Date: Mon, 07 Mar 2005 17:04:00 -0500 From: "chas williams - CONTRACTOR" X-Virus-Scanned: ClamAV 0.83/751/Mon Mar 7 03:06:27 2005 on oss.sgi.com X-Virus-Scanned: NAI Completed X-Scanned-By: MIMEDefang 2.30 (www . roaringpenguin . com / mimedefang) X-Virus-Status: Clean X-archive-position: 2612 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: chas@cmf.nrl.navy.mil Precedence: bulk X-list: netdev Content-Length: 5940 Lines: 172 please apply to 2.6 -- thanks! # This is a BitKeeper generated diff -Nru style patch. # # ChangeSet # 2005/03/07 14:23:39-05:00 chas@relax.cmf.nrl.navy.mil # [ATM]: convert from pci_module_init to pci_register_driver # # Signed-off-by: Christophe Lucas # Signed-off-by: Domen Puncer # Signed-off-by: Chas Williams # # drivers/atm/zatm.c # 2005/03/07 14:23:21-05:00 chas@relax.cmf.nrl.navy.mil +1 -1 # [ATM]: convert from pci_module_init to pci_register_driver # # Signed-off-by: Christophe Lucas # Signed-off-by: Domen Puncer # Signed-off-by: Chas Williams # # drivers/atm/nicstar.c # 2005/03/07 14:23:21-05:00 chas@relax.cmf.nrl.navy.mil +1 -1 # [ATM]: convert from pci_module_init to pci_register_driver # # Signed-off-by: Christophe Lucas # Signed-off-by: Domen Puncer # Signed-off-by: Chas Williams # # drivers/atm/lanai.c # 2005/03/07 14:23:21-05:00 chas@relax.cmf.nrl.navy.mil +1 -1 # [ATM]: convert from pci_module_init to pci_register_driver # # Signed-off-by: Christophe Lucas # Signed-off-by: Domen Puncer # Signed-off-by: Chas Williams # # drivers/atm/iphase.c # 2005/03/07 14:23:21-05:00 chas@relax.cmf.nrl.navy.mil +1 -1 # [ATM]: convert from pci_module_init to pci_register_driver # # Signed-off-by: Christophe Lucas # Signed-off-by: Domen Puncer # Signed-off-by: Chas Williams # # drivers/atm/horizon.c # 2005/03/07 14:23:21-05:00 chas@relax.cmf.nrl.navy.mil +1 -1 # [ATM]: convert from pci_module_init to pci_register_driver # # Signed-off-by: Christophe Lucas # Signed-off-by: Domen Puncer # Signed-off-by: Chas Williams # # drivers/atm/he.c # 2005/03/07 14:23:21-05:00 chas@relax.cmf.nrl.navy.mil +1 -1 # [ATM]: convert from pci_module_init to pci_register_driver # # Signed-off-by: Christophe Lucas # Signed-off-by: Domen Puncer # Signed-off-by: Chas Williams # # drivers/atm/firestream.c # 2005/03/07 14:23:21-05:00 chas@relax.cmf.nrl.navy.mil +1 -1 # [ATM]: convert from pci_module_init to pci_register_driver # # Signed-off-by: Christophe Lucas # Signed-off-by: Domen Puncer # Signed-off-by: Chas Williams # # drivers/atm/ambassador.c # 2005/03/07 14:23:21-05:00 chas@relax.cmf.nrl.navy.mil +1 -1 # [ATM]: convert from pci_module_init to pci_register_driver # # Signed-off-by: Christophe Lucas # Signed-off-by: Domen Puncer # Signed-off-by: Chas Williams # diff -Nru a/drivers/atm/ambassador.c b/drivers/atm/ambassador.c --- a/drivers/atm/ambassador.c 2005-03-07 15:33:10 -05:00 +++ b/drivers/atm/ambassador.c 2005-03-07 15:33:10 -05:00 @@ -2447,7 +2447,7 @@ amb_check_args(); // get the juice - return pci_module_init(&amb_driver); + return pci_register_driver(&amb_driver); } /********** module exit **********/ diff -Nru a/drivers/atm/firestream.c b/drivers/atm/firestream.c --- a/drivers/atm/firestream.c 2005-03-07 15:33:10 -05:00 +++ b/drivers/atm/firestream.c 2005-03-07 15:33:10 -05:00 @@ -2034,7 +2034,7 @@ int error; func_enter (); - error = pci_module_init(&firestream_driver); + error = pci_register_driver(&firestream_driver); func_exit (); return error; } diff -Nru a/drivers/atm/he.c b/drivers/atm/he.c --- a/drivers/atm/he.c 2005-03-07 15:33:10 -05:00 +++ b/drivers/atm/he.c 2005-03-07 15:33:10 -05:00 @@ -3079,7 +3079,7 @@ static int __init he_init(void) { - return pci_module_init(&he_driver); + return pci_register_driver(&he_driver); } static void __exit he_cleanup(void) diff -Nru a/drivers/atm/horizon.c b/drivers/atm/horizon.c --- a/drivers/atm/horizon.c 2005-03-07 15:33:10 -05:00 +++ b/drivers/atm/horizon.c 2005-03-07 15:33:10 -05:00 @@ -2938,7 +2938,7 @@ hrz_check_args(); // get the juice - return pci_module_init(&hrz_driver); + return pci_register_driver(&hrz_driver); } /********** module exit **********/ diff -Nru a/drivers/atm/iphase.c b/drivers/atm/iphase.c --- a/drivers/atm/iphase.c 2005-03-07 15:33:10 -05:00 +++ b/drivers/atm/iphase.c 2005-03-07 15:33:10 -05:00 @@ -3274,7 +3274,7 @@ { int ret; - ret = pci_module_init(&ia_driver); + ret = pci_register_driver(&ia_driver); if (ret >= 0) { ia_timer.expires = jiffies + 3*HZ; add_timer(&ia_timer); diff -Nru a/drivers/atm/lanai.c b/drivers/atm/lanai.c --- a/drivers/atm/lanai.c 2005-03-07 15:33:10 -05:00 +++ b/drivers/atm/lanai.c 2005-03-07 15:33:10 -05:00 @@ -2746,7 +2746,7 @@ { int x; - x = pci_module_init(&lanai_driver); + x = pci_register_driver(&lanai_driver); if (x != 0) printk(KERN_ERR DEV_LABEL ": no adapter found\n"); return x; diff -Nru a/drivers/atm/nicstar.c b/drivers/atm/nicstar.c --- a/drivers/atm/nicstar.c 2005-03-07 15:33:10 -05:00 +++ b/drivers/atm/nicstar.c 2005-03-07 15:33:10 -05:00 @@ -381,7 +381,7 @@ XPRINTK("nicstar: nicstar_init() called.\n"); - error = pci_module_init(&nicstar_driver); + error = pci_register_driver(&nicstar_driver); TXPRINTK("nicstar: TX debug enabled.\n"); RXPRINTK("nicstar: RX debug enabled.\n"); diff -Nru a/drivers/atm/zatm.c b/drivers/atm/zatm.c --- a/drivers/atm/zatm.c 2005-03-07 15:33:10 -05:00 +++ b/drivers/atm/zatm.c 2005-03-07 15:33:10 -05:00 @@ -1639,7 +1639,7 @@ static int __init zatm_init_module(void) { - return pci_module_init(&zatm_driver); + return pci_register_driver(&zatm_driver); } module_init(zatm_init_module); From chas@cmf.nrl.navy.mil Mon Mar 7 14:04:28 2005 Received: with ECARTIS (v1.0.0; list netdev); Mon, 07 Mar 2005 14:04:33 -0800 (PST) Received: from ginger.cmf.nrl.navy.mil (ginger.cmf.nrl.navy.mil [134.207.10.161]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j27M4RdS010847 for ; Mon, 7 Mar 2005 14:04:27 -0800 Received: from cmf.nrl.navy.mil (thirdoffive.cmf.nrl.navy.mil [134.207.10.180]) by ginger.cmf.nrl.navy.mil (8.12.11/8.12.11) with ESMTP id j27M4KYc020899; Mon, 7 Mar 2005 17:04:20 -0500 (EST) Message-Id: <200503072204.j27M4KYc020899@ginger.cmf.nrl.navy.mil> To: netdev@oss.sgi.com Cc: davem@redhat.com Subject: [PATCH 3/9][ATM]: [lanai] atm/lanai: fix text section references to __init text; should be __devinit Date: Mon, 07 Mar 2005 17:04:20 -0500 From: "chas williams - CONTRACTOR" X-Virus-Scanned: ClamAV 0.83/751/Mon Mar 7 03:06:27 2005 on oss.sgi.com X-Virus-Scanned: NAI Completed X-Scanned-By: MIMEDefang 2.30 (www . roaringpenguin . com / mimedefang) X-Virus-Status: Clean X-archive-position: 2613 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: chas@cmf.nrl.navy.mil Precedence: bulk X-list: netdev Content-Length: 3465 Lines: 111 please apply to 2.6 -- thanks! # This is a BitKeeper generated diff -Nru style patch. # # ChangeSet # 2005/03/07 14:27:39-05:00 chas@relax.cmf.nrl.navy.mil # [ATM]: [lanai] atm/lanai: fix text section references to __init text; should be __devinit # # Signed-off-by: Randy Dunlap # Signed-off-by: Chas Williams # # drivers/atm/lanai.c # 2005/03/07 14:27:20-05:00 chas@relax.cmf.nrl.navy.mil +10 -10 # [ATM]: [lanai] atm/lanai: fix text section references to __init text; should be __devinit # # Signed-off-by: Randy Dunlap # Signed-off-by: Chas Williams # diff -Nru a/drivers/atm/lanai.c b/drivers/atm/lanai.c --- a/drivers/atm/lanai.c 2005-03-07 15:33:49 -05:00 +++ b/drivers/atm/lanai.c 2005-03-07 15:33:49 -05:00 @@ -566,7 +566,7 @@ return -EIO; } -static int __init sram_test_pass(const struct lanai_dev *lanai, u32 pattern) +static int __devinit sram_test_pass(const struct lanai_dev *lanai, u32 pattern) { int offset, result = 0; for (offset = 0; offset < SRAM_BYTES && result == 0; offset += 4) @@ -574,7 +574,7 @@ return result; } -static int __init sram_test_and_clear(const struct lanai_dev *lanai) +static int __devinit sram_test_and_clear(const struct lanai_dev *lanai) { #ifdef FULL_MEMORY_TEST int result; @@ -860,7 +860,7 @@ #ifndef READ_EEPROM /* Stub functions to use if EEPROM reading is disabled */ -static int __init eeprom_read(struct lanai_dev *lanai) +static int __devinit eeprom_read(struct lanai_dev *lanai) { printk(KERN_INFO DEV_LABEL "(itf %d): *NOT* reading EEPROM\n", lanai->number); @@ -868,7 +868,7 @@ return 0; } -static int __init eeprom_validate(struct lanai_dev *lanai) +static int __devinit eeprom_validate(struct lanai_dev *lanai) { lanai->serialno = 0; lanai->magicno = EEPROM_MAGIC_VALUE; @@ -877,7 +877,7 @@ #else /* READ_EEPROM */ -static int __init eeprom_read(struct lanai_dev *lanai) +static int __devinit eeprom_read(struct lanai_dev *lanai) { int i, address; u8 data; @@ -953,7 +953,7 @@ } /* Checksum/validate EEPROM contents */ -static int __init eeprom_validate(struct lanai_dev *lanai) +static int __devinit eeprom_validate(struct lanai_dev *lanai) { int i, s; u32 v; @@ -1449,7 +1449,7 @@ #include #endif -static int __init vcc_table_allocate(struct lanai_dev *lanai) +static int __devinit vcc_table_allocate(struct lanai_dev *lanai) { #ifdef VCCTABLE_GETFREEPAGE APRINTK((lanai->num_vci) * sizeof(struct lanai_vcc *) <= PAGE_SIZE, @@ -1596,7 +1596,7 @@ /* * Allocate service buffer and tell card about it */ -static int __init service_buffer_allocate(struct lanai_dev *lanai) +static int __devinit service_buffer_allocate(struct lanai_dev *lanai) { lanai_buf_allocate(&lanai->service, SERVICE_ENTRIES * 4, 8, lanai->pci); @@ -1952,7 +1952,7 @@ /* -------------------- PCI INITIALIZATION/SHUTDOWN: */ -static int __init lanai_pci_start(struct lanai_dev *lanai) +static int __devinit lanai_pci_start(struct lanai_dev *lanai) { struct pci_dev *pci = lanai->pci; int result; @@ -2148,7 +2148,7 @@ /* -------------------- OPERATIONS: */ /* setup a newly detected device */ -static int __init lanai_dev_open(struct atm_dev *atmdev) +static int __devinit lanai_dev_open(struct atm_dev *atmdev) { struct lanai_dev *lanai = (struct lanai_dev *) atmdev->dev_data; unsigned long raw_base; From chas@cmf.nrl.navy.mil Mon Mar 7 14:06:20 2005 Received: with ECARTIS (v1.0.0; list netdev); Mon, 07 Mar 2005 14:06:25 -0800 (PST) Received: from ginger.cmf.nrl.navy.mil (ginger.cmf.nrl.navy.mil [134.207.10.161]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j27M6JA8011973 for ; Mon, 7 Mar 2005 14:06:20 -0800 Received: from cmf.nrl.navy.mil (thirdoffive.cmf.nrl.navy.mil [134.207.10.180]) by ginger.cmf.nrl.navy.mil (8.12.11/8.12.11) with ESMTP id j27M6D9x020972; Mon, 7 Mar 2005 17:06:13 -0500 (EST) Message-Id: <200503072206.j27M6D9x020972@ginger.cmf.nrl.navy.mil> To: netdev@oss.sgi.com Cc: davem@redhat.com Subject: [PATCH 4/9][ATM]: [zatm] fix text section references to __init text and __initdata; should be __devinit Date: Mon, 07 Mar 2005 17:06:13 -0500 From: "chas williams - CONTRACTOR" X-Virus-Scanned: ClamAV 0.83/751/Mon Mar 7 03:06:27 2005 on oss.sgi.com X-Virus-Scanned: NAI Completed X-Scanned-By: MIMEDefang 2.30 (www . roaringpenguin . com / mimedefang) X-Virus-Status: Clean X-archive-position: 2614 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: chas@cmf.nrl.navy.mil Precedence: bulk X-list: netdev Content-Length: 2314 Lines: 75 please apply to 2.6 -- thanks! # This is a BitKeeper generated diff -Nru style patch. # # ChangeSet # 2005/03/07 14:29:53-05:00 chas@relax.cmf.nrl.navy.mil # [ATM]: [zatm] fix text section references to __init text and __initdata; should be __devinit # # Signed-off-by: Randy Dunlap # Signed-off-by: Chas Williams # # drivers/atm/zatm.c # 2005/03/07 14:29:35-05:00 chas@relax.cmf.nrl.navy.mil +6 -6 # [ATM]: [zatm] fix text section references to __init text and __initdata; should be __devinit # # Signed-off-by: Randy Dunlap # Signed-off-by: Chas Williams # diff -Nru a/drivers/atm/zatm.c b/drivers/atm/zatm.c --- a/drivers/atm/zatm.c 2005-03-07 15:34:29 -05:00 +++ b/drivers/atm/zatm.c 2005-03-07 15:34:29 -05:00 @@ -1090,7 +1090,7 @@ /*----------------------------- (E)EPROM access -----------------------------*/ -static void __init eprom_set(struct zatm_dev *zatm_dev,unsigned long value, +static void __devinit eprom_set(struct zatm_dev *zatm_dev,unsigned long value, unsigned short cmd) { int error; @@ -1101,7 +1101,7 @@ } -static unsigned long __init eprom_get(struct zatm_dev *zatm_dev, +static unsigned long __devinit eprom_get(struct zatm_dev *zatm_dev, unsigned short cmd) { unsigned int value; @@ -1114,7 +1114,7 @@ } -static void __init eprom_put_bits(struct zatm_dev *zatm_dev, +static void __devinit eprom_put_bits(struct zatm_dev *zatm_dev, unsigned long data,int bits,unsigned short cmd) { unsigned long value; @@ -1129,7 +1129,7 @@ } -static void __init eprom_get_byte(struct zatm_dev *zatm_dev, +static void __devinit eprom_get_byte(struct zatm_dev *zatm_dev, unsigned char *byte,unsigned short cmd) { int i; @@ -1145,7 +1145,7 @@ } -static unsigned char __init eprom_try_esi(struct atm_dev *dev, +static unsigned char __devinit eprom_try_esi(struct atm_dev *dev, unsigned short cmd,int offset,int swap) { unsigned char buf[ZEPROM_SIZE]; @@ -1166,7 +1166,7 @@ } -static void __init eprom_get_esi(struct atm_dev *dev) +static void __devinit eprom_get_esi(struct atm_dev *dev) { if (eprom_try_esi(dev,ZEPROM_V1_REG,ZEPROM_V1_ESI_OFF,1)) return; (void) eprom_try_esi(dev,ZEPROM_V2_REG,ZEPROM_V2_ESI_OFF,0); From chas@cmf.nrl.navy.mil Mon Mar 7 14:06:39 2005 Received: with ECARTIS (v1.0.0; list netdev); Mon, 07 Mar 2005 14:06:43 -0800 (PST) Received: from ginger.cmf.nrl.navy.mil (ginger.cmf.nrl.navy.mil [134.207.10.161]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j27M6cf1012372 for ; Mon, 7 Mar 2005 14:06:38 -0800 Received: from cmf.nrl.navy.mil (thirdoffive.cmf.nrl.navy.mil [134.207.10.180]) by ginger.cmf.nrl.navy.mil (8.12.11/8.12.11) with ESMTP id j27M6V7g020979; Mon, 7 Mar 2005 17:06:31 -0500 (EST) Message-Id: <200503072206.j27M6V7g020979@ginger.cmf.nrl.navy.mil> To: netdev@oss.sgi.com Cc: davem@redhat.com Subject: [PATCH 5/9][ATM]: [ambassador] fix text section references to __init text and __initdata Date: Mon, 07 Mar 2005 17:06:31 -0500 From: "chas williams - CONTRACTOR" X-Virus-Scanned: ClamAV 0.83/751/Mon Mar 7 03:06:27 2005 on oss.sgi.com X-Virus-Scanned: NAI Completed X-Scanned-By: MIMEDefang 2.30 (www . roaringpenguin . com / mimedefang) X-Virus-Status: Clean X-archive-position: 2615 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: chas@cmf.nrl.navy.mil Precedence: bulk X-list: netdev Content-Length: 4035 Lines: 140 please apply to 2.6 -- thanks! # This is a BitKeeper generated diff -Nru style patch. # # ChangeSet # 2005/03/07 14:31:55-05:00 chas@relax.cmf.nrl.navy.mil # [ATM]: [ambassador] fix text section references to __init text and __initdata # # Signed-off-by: Randy Dunlap # Signed-off-by: Chas Williams # # drivers/atm/ambassador.c # 2005/03/07 14:31:37-05:00 chas@relax.cmf.nrl.navy.mil +14 -14 # [ATM]: [ambassador] fix text section references to __init text and __initdata # # Signed-off-by: Randy Dunlap # Signed-off-by: Chas Williams # diff -Nru a/drivers/atm/ambassador.c b/drivers/atm/ambassador.c --- a/drivers/atm/ambassador.c 2005-03-07 15:34:59 -05:00 +++ b/drivers/atm/ambassador.c 2005-03-07 15:34:59 -05:00 @@ -296,16 +296,16 @@ #endif #define UCODE2(x) #x -static u32 __initdata ucode_start = +static u32 __devinitdata ucode_start = #include UCODE(start) ; -static region __initdata ucode_regions[] = { +static region __devinitdata ucode_regions[] = { #include UCODE(regions) { 0, 0 } }; -static u32 __initdata ucode_data[] = { +static u32 __devinitdata ucode_data[] = { #include UCODE(data) 0xdeadbeef }; @@ -1539,7 +1539,7 @@ /********** creation of communication queues **********/ -static int __init create_queues (amb_dev * dev, unsigned int cmds, +static int __devinit create_queues (amb_dev * dev, unsigned int cmds, unsigned int txs, unsigned int * rxs, unsigned int * rx_buffer_sizes) { unsigned char pool; @@ -1769,7 +1769,7 @@ return res; } -static int __init do_loader_command (volatile loader_block * lb, +static int __devinit do_loader_command (volatile loader_block * lb, const amb_dev * dev, loader_command cmd) { unsigned long timeout; @@ -1825,7 +1825,7 @@ /* loader: determine loader version */ -static int __init get_loader_version (loader_block * lb, +static int __devinit get_loader_version (loader_block * lb, const amb_dev * dev, u32 * version) { int res; @@ -1841,7 +1841,7 @@ /* loader: write memory data blocks */ -static int __init loader_write (loader_block * lb, +static int __devinit loader_write (loader_block * lb, const amb_dev * dev, const u32 * data, u32 address, unsigned int count) { unsigned int i; @@ -1860,7 +1860,7 @@ /* loader: verify memory data blocks */ -static int __init loader_verify (loader_block * lb, +static int __devinit loader_verify (loader_block * lb, const amb_dev * dev, const u32 * data, u32 address, unsigned int count) { unsigned int i; @@ -1885,7 +1885,7 @@ /* loader: start microcode */ -static int __init loader_start (loader_block * lb, +static int __devinit loader_start (loader_block * lb, const amb_dev * dev, u32 address) { PRINTD (DBG_FLOW|DBG_LOAD, "loader_start"); @@ -1961,7 +1961,7 @@ /********** transfer and start the microcode **********/ -static int __init ucode_init (loader_block * lb, amb_dev * dev) { +static int __devinit ucode_init (loader_block * lb, amb_dev * dev) { unsigned int i = 0; unsigned int total = 0; const u32 * pointer = ucode_data; @@ -2011,7 +2011,7 @@ return cpu_to_be32 (virt_to_bus (addr)); } -static int __init amb_talk (amb_dev * dev) { +static int __devinit amb_talk (amb_dev * dev) { adap_talk_block a; unsigned char pool; unsigned long timeout; @@ -2058,7 +2058,7 @@ } // get microcode version -static void __init amb_ucode_version (amb_dev * dev) { +static void __devinit amb_ucode_version (amb_dev * dev) { u32 major; u32 minor; command cmd; @@ -2085,7 +2085,7 @@ } // get end station address -static void __init amb_esi (amb_dev * dev, u8 * esi) { +static void __devinit amb_esi (amb_dev * dev, u8 * esi) { u32 lower4; u16 upper2; command cmd; @@ -2131,7 +2131,7 @@ return; } -static int __init amb_init (amb_dev * dev) +static int __devinit amb_init (amb_dev * dev) { loader_block lb; From chas@cmf.nrl.navy.mil Mon Mar 7 14:07:06 2005 Received: with ECARTIS (v1.0.0; list netdev); Mon, 07 Mar 2005 14:07:10 -0800 (PST) Received: from ginger.cmf.nrl.navy.mil (ginger.cmf.nrl.navy.mil [134.207.10.161]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j27M75kJ012860 for ; Mon, 7 Mar 2005 14:07:05 -0800 Received: from cmf.nrl.navy.mil (thirdoffive.cmf.nrl.navy.mil [134.207.10.180]) by ginger.cmf.nrl.navy.mil (8.12.11/8.12.11) with ESMTP id j27M6xOR020993; Mon, 7 Mar 2005 17:06:59 -0500 (EST) Message-Id: <200503072206.j27M6xOR020993@ginger.cmf.nrl.navy.mil> To: netdev@oss.sgi.com Cc: davem@redhat.com Subject: [PATCH 6/9][ATM]: [fore200e] Replace MSECS() with msecs_to_jiffies() Date: Mon, 07 Mar 2005 17:06:59 -0500 From: "chas williams - CONTRACTOR" X-Virus-Scanned: ClamAV 0.83/751/Mon Mar 7 03:06:27 2005 on oss.sgi.com X-Virus-Scanned: NAI Completed X-Scanned-By: MIMEDefang 2.30 (www . roaringpenguin . com / mimedefang) X-Virus-Status: Clean X-archive-position: 2616 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: chas@cmf.nrl.navy.mil Precedence: bulk X-list: netdev Content-Length: 2165 Lines: 68 please apply to 2.6 -- thanks! # This is a BitKeeper generated diff -Nru style patch. # # ChangeSet # 2005/03/07 15:15:01-05:00 chas@relax.cmf.nrl.navy.mil # [ATM]: [fore200e] Replace MSECS() with msecs_to_jiffies() # # Signed-off-by: Nishanth Aravamudan # Signed-off-by: Chas Williams # # drivers/atm/fore200e.c # 2005/03/07 15:14:43-05:00 chas@relax.cmf.nrl.navy.mil +4 -8 # [ATM]: [fore200e] Replace MSECS() with msecs_to_jiffies() # # Signed-off-by: Nishanth Aravamudan # Signed-off-by: Chas Williams # diff -Nru a/drivers/atm/fore200e.c b/drivers/atm/fore200e.c --- a/drivers/atm/fore200e.c 2005-03-07 15:36:02 -05:00 +++ b/drivers/atm/fore200e.c 2005-03-07 15:36:02 -05:00 @@ -96,10 +96,6 @@ #define FORE200E_NEXT_ENTRY(index, modulo) (index = ++(index) % (modulo)) - -#define MSECS(ms) (((ms)*HZ/1000)+1) - - #if 1 #define ASSERT(expr) if (!(expr)) { \ printk(FORE200E "assertion failed! %s[%d]: %s\n", \ @@ -246,7 +242,7 @@ static void fore200e_spin(int msecs) { - unsigned long timeout = jiffies + MSECS(msecs); + unsigned long timeout = jiffies + msecs_to_jiffies(msecs); while (time_before(jiffies, timeout)); } @@ -254,7 +250,7 @@ static int fore200e_poll(struct fore200e* fore200e, volatile u32* addr, u32 val, int msecs) { - unsigned long timeout = jiffies + MSECS(msecs); + unsigned long timeout = jiffies + msecs_to_jiffies(msecs); int ok; mb(); @@ -278,7 +274,7 @@ static int fore200e_io_poll(struct fore200e* fore200e, volatile u32 __iomem *addr, u32 val, int msecs) { - unsigned long timeout = jiffies + MSECS(msecs); + unsigned long timeout = jiffies + msecs_to_jiffies(msecs); int ok; do { @@ -2596,7 +2592,7 @@ fore200e_monitor_getc(struct fore200e* fore200e) { struct cp_monitor __iomem * monitor = fore200e->cp_monitor; - unsigned long timeout = jiffies + MSECS(50); + unsigned long timeout = jiffies + msecs_to_jiffies(50); int c; while (time_before(jiffies, timeout)) { From chas@cmf.nrl.navy.mil Mon Mar 7 14:07:39 2005 Received: with ECARTIS (v1.0.0; list netdev); Mon, 07 Mar 2005 14:07:45 -0800 (PST) Received: from ginger.cmf.nrl.navy.mil (ginger.cmf.nrl.navy.mil [134.207.10.161]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j27M7cAR013397 for ; Mon, 7 Mar 2005 14:07:39 -0800 Received: from cmf.nrl.navy.mil (thirdoffive.cmf.nrl.navy.mil [134.207.10.180]) by ginger.cmf.nrl.navy.mil (8.12.11/8.12.11) with ESMTP id j27M7WNh021002; Mon, 7 Mar 2005 17:07:32 -0500 (EST) Message-Id: <200503072207.j27M7WNh021002@ginger.cmf.nrl.navy.mil> To: netdev@oss.sgi.com Cc: davem@redhat.com Subject: [PATCH 7/9][ATM]: [iphase] use after free, found by Coverity tool Date: Mon, 07 Mar 2005 17:07:32 -0500 From: "chas williams - CONTRACTOR" X-Virus-Scanned: ClamAV 0.83/751/Mon Mar 7 03:06:27 2005 on oss.sgi.com X-Virus-Scanned: NAI Completed X-Scanned-By: MIMEDefang 2.30 (www . roaringpenguin . com / mimedefang) X-Virus-Status: Clean X-archive-position: 2617 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: chas@cmf.nrl.navy.mil Precedence: bulk X-list: netdev Content-Length: 1091 Lines: 31 please apply to 2.6 -- thanks! # This is a BitKeeper generated diff -Nru style patch. # # ChangeSet # 2005/03/07 15:16:16-05:00 chas@relax.cmf.nrl.navy.mil # [ATM]: [iphase] use after free, found by Coverity tool # # Signed-off-by: Alexander Nyberg # Signed-off-by: Chas Williams # # drivers/atm/iphase.c # 2005/03/07 15:15:58-05:00 chas@relax.cmf.nrl.navy.mil +1 -1 # [ATM]: [iphase] use after free, found by Coverity tool # # Signed-off-by: Alexander Nyberg # Signed-off-by: Chas Williams # diff -Nru a/drivers/atm/iphase.c b/drivers/atm/iphase.c --- a/drivers/atm/iphase.c 2005-03-07 15:36:19 -05:00 +++ b/drivers/atm/iphase.c 2005-03-07 15:36:19 -05:00 @@ -3244,8 +3244,8 @@ iadev_count--; ia_dev[iadev_count] = NULL; _ia_dev[iadev_count] = NULL; + IF_EVENT(printk("deregistering iav at (itf:%d)\n", dev->number);) atm_dev_deregister(dev); - IF_EVENT(printk("iav deregistered at (itf:%d)\n", dev->number);) iounmap(iadev->base); pci_disable_device(pdev); From chas@cmf.nrl.navy.mil Mon Mar 7 14:07:56 2005 Received: with ECARTIS (v1.0.0; list netdev); Mon, 07 Mar 2005 14:08:00 -0800 (PST) Received: from ginger.cmf.nrl.navy.mil (ginger.cmf.nrl.navy.mil [134.207.10.161]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j27M7tVH013673 for ; Mon, 7 Mar 2005 14:07:56 -0800 Received: from cmf.nrl.navy.mil (thirdoffive.cmf.nrl.navy.mil [134.207.10.180]) by ginger.cmf.nrl.navy.mil (8.12.11/8.12.11) with ESMTP id j27M7nAJ021016; Mon, 7 Mar 2005 17:07:49 -0500 (EST) Message-Id: <200503072207.j27M7nAJ021016@ginger.cmf.nrl.navy.mil> To: netdev@oss.sgi.com Cc: davem@redhat.com Subject: [PATCH 8/9][ATM]: [lanai] quiet sparse warnings Date: Mon, 07 Mar 2005 17:07:49 -0500 From: "chas williams - CONTRACTOR" X-Virus-Scanned: ClamAV 0.83/751/Mon Mar 7 03:06:27 2005 on oss.sgi.com X-Virus-Scanned: NAI Completed X-Scanned-By: MIMEDefang 2.30 (www . roaringpenguin . com / mimedefang) X-Virus-Status: Clean X-archive-position: 2618 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: chas@cmf.nrl.navy.mil Precedence: bulk X-list: netdev Content-Length: 3575 Lines: 102 please apply to 2.6 -- thanks! # This is a BitKeeper generated diff -Nru style patch. # # ChangeSet # 2005/03/07 15:26:27-05:00 chas@relax.cmf.nrl.navy.mil # [ATM]: [lanai] quiet sparse warnings # # Signed-off-by: Randy Dunlap # Signed-off-by: Chas Williams # # drivers/atm/lanai.c # 2005/03/07 15:26:10-05:00 chas@relax.cmf.nrl.navy.mil +9 -9 # [ATM]: [lanai] quiet sparse warnings # # Signed-off-by: Randy Dunlap # Signed-off-by: Chas Williams # diff -Nru a/drivers/atm/lanai.c b/drivers/atm/lanai.c --- a/drivers/atm/lanai.c 2005-03-07 15:36:36 -05:00 +++ b/drivers/atm/lanai.c 2005-03-07 15:36:36 -05:00 @@ -650,7 +650,7 @@ enum lanai_vcc_offset offset) { u32 val; - APRINTK(lvcc->vbase != 0, "cardvcc_read: unbound vcc!\n"); + APRINTK(lvcc->vbase != NULL, "cardvcc_read: unbound vcc!\n"); val= readl(lvcc->vbase + offset); RWDEBUG("VR vci=%04d 0x%02X = 0x%08X\n", lvcc->vci, (int) offset, val); @@ -660,7 +660,7 @@ static inline void cardvcc_write(const struct lanai_vcc *lvcc, u32 val, enum lanai_vcc_offset offset) { - APRINTK(lvcc->vbase != 0, "cardvcc_write: unbound vcc!\n"); + APRINTK(lvcc->vbase != NULL, "cardvcc_write: unbound vcc!\n"); APRINTK((val & ~0xFFFF) == 0, "cardvcc_write: bad val 0x%X (vci=%d, addr=0x%02X)\n", (unsigned int) val, lvcc->vci, (unsigned int) offset); @@ -748,7 +748,7 @@ /* Shutdown receiving on card */ static void lanai_shutdown_rx_vci(const struct lanai_vcc *lvcc) { - if (lvcc->vbase == 0) /* We were never bound to a VCI */ + if (lvcc->vbase == NULL) /* We were never bound to a VCI */ return; /* 15.1.1 - set to trashing, wait one cell time (15us) */ cardvcc_write(lvcc, @@ -779,7 +779,7 @@ int read, write, lastread = -1; APRINTK(!in_interrupt(), "lanai_shutdown_tx_vci called w/o process context!\n"); - if (lvcc->vbase == 0) /* We were never bound to a VCI */ + if (lvcc->vbase == NULL) /* We were never bound to a VCI */ return; /* 15.2.1 - wait for queue to drain */ while ((skb = skb_dequeue(&lvcc->tx.backlog)) != NULL) @@ -1544,7 +1544,7 @@ static inline void host_vcc_bind(struct lanai_dev *lanai, struct lanai_vcc *lvcc, vci_t vci) { - if (lvcc->vbase != 0) + if (lvcc->vbase != NULL) return; /* We already were bound in the other direction */ DPRINTK("Binding vci %d\n", vci); #ifdef USE_POWERDOWN @@ -1562,7 +1562,7 @@ static inline void host_vcc_unbind(struct lanai_dev *lanai, struct lanai_vcc *lvcc) { - if (lvcc->vbase == 0) + if (lvcc->vbase == NULL) return; /* This vcc was never bound */ DPRINTK("Unbinding vci %d\n", lvcc->vci); lvcc->vbase = NULL; @@ -2179,7 +2179,7 @@ goto error; raw_base = lanai->pci->resource[0].start; lanai->base = (bus_addr_t) ioremap(raw_base, LANAI_MAPPING_SIZE); - if (lanai->base == 0) { + if (lanai->base == NULL) { printk(KERN_ERR DEV_LABEL ": couldn't remap I/O space\n"); goto error_pci; } @@ -2333,7 +2333,7 @@ } if (lvcc->tx.atmvcc == atmvcc) { if (atmvcc == lanai->cbrvcc) { - if (lvcc->vbase != 0) + if (lvcc->vbase != NULL) lanai_cbr_shutdown(lanai); lanai->cbrvcc = NULL; } @@ -2524,7 +2524,7 @@ struct lanai_vcc *lvcc = (struct lanai_vcc *) atmvcc->dev_data; struct lanai_dev *lanai = (struct lanai_dev *) atmvcc->dev->dev_data; unsigned long flags; - if (unlikely(lvcc == NULL || lvcc->vbase == 0 || + if (unlikely(lvcc == NULL || lvcc->vbase == NULL || lvcc->tx.atmvcc != atmvcc)) goto einval; #ifdef DEBUG From chas@cmf.nrl.navy.mil Mon Mar 7 14:08:37 2005 Received: with ECARTIS (v1.0.0; list netdev); Mon, 07 Mar 2005 14:08:41 -0800 (PST) Received: from ginger.cmf.nrl.navy.mil (ginger.cmf.nrl.navy.mil [134.207.10.161]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j27M8aGF014468 for ; Mon, 7 Mar 2005 14:08:36 -0800 Received: from cmf.nrl.navy.mil (thirdoffive.cmf.nrl.navy.mil [134.207.10.180]) by ginger.cmf.nrl.navy.mil (8.12.11/8.12.11) with ESMTP id j27M8SOt021044; Mon, 7 Mar 2005 17:08:28 -0500 (EST) Message-Id: <200503072208.j27M8SOt021044@ginger.cmf.nrl.navy.mil> To: netdev@oss.sgi.com Cc: davem@redhat.com Subject: [PATCH 9/9][ATM]: [fore200e] rewrite to eliminate pci_find_device() but preserve sbus support Date: Mon, 07 Mar 2005 17:08:28 -0500 From: "chas williams - CONTRACTOR" X-Virus-Scanned: ClamAV 0.83/751/Mon Mar 7 03:06:27 2005 on oss.sgi.com X-Virus-Scanned: NAI Completed X-Scanned-By: MIMEDefang 2.30 (www . roaringpenguin . com / mimedefang) X-Virus-Status: Clean X-archive-position: 2619 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: chas@cmf.nrl.navy.mil Precedence: bulk X-list: netdev Content-Length: 7054 Lines: 249 please apply to 2.6 -- thanks! # This is a BitKeeper generated diff -Nru style patch. # # ChangeSet # 2005/03/07 15:31:25-05:00 chas@relax.cmf.nrl.navy.mil # [ATM]: [fore200e] rewrite to eliminate pci_find_device() but preserve sbus support # # Signed-off-by: Chas Williams # # drivers/atm/fore200e.h # 2005/03/07 15:31:07-05:00 chas@relax.cmf.nrl.navy.mil +1 -1 # [ATM]: [fore200e] rewrite to eliminate pci_find_device() but preserve sbus support # # Signed-off-by: Chas Williams # # drivers/atm/fore200e.c # 2005/03/07 15:31:07-05:00 chas@relax.cmf.nrl.navy.mil +107 -47 # [ATM]: [fore200e] rewrite to eliminate pci_find_device() but preserve sbus support # # Signed-off-by: Chas Williams # diff -Nru a/drivers/atm/fore200e.c b/drivers/atm/fore200e.c --- a/drivers/atm/fore200e.c 2005-03-07 15:36:53 -05:00 +++ b/drivers/atm/fore200e.c 2005-03-07 15:36:53 -05:00 @@ -110,7 +110,7 @@ static const struct atmdev_ops fore200e_ops; static const struct fore200e_bus fore200e_bus[]; -static struct fore200e* fore200e_boards = NULL; +static LIST_HEAD(fore200e_boards); MODULE_AUTHOR("Christophe Lizzi - credits to Uwe Dannowski and Heikki Vatiainen"); @@ -633,39 +633,6 @@ } -static struct fore200e* __init -fore200e_pca_detect(const struct fore200e_bus* bus, int index) -{ - struct fore200e* fore200e; - struct pci_dev* pci_dev = NULL; - int count = index; - - do { - pci_dev = pci_find_device(PCI_VENDOR_ID_FORE, PCI_DEVICE_ID_FORE_PCA200E, pci_dev); - if (pci_dev == NULL) - return NULL; - } while (count--); - - if (pci_enable_device(pci_dev)) - return NULL; - - fore200e = fore200e_kmalloc(sizeof(struct fore200e), GFP_KERNEL); - if (fore200e == NULL) - return NULL; - - fore200e->bus = bus; - fore200e->bus_dev = pci_dev; - fore200e->irq = pci_dev->irq; - fore200e->phys_base = pci_resource_start(pci_dev, 0); - - sprintf(fore200e->name, "%s-%d", bus->model_name, index - 1); - - pci_set_master(pci_dev); - - return fore200e; -} - - static int __init fore200e_pca_prom_read(struct fore200e* fore200e, struct prom_data* prom) { @@ -2764,20 +2731,107 @@ return 0; } + +static int __devinit +fore200e_pca_detect(struct pci_dev *pci_dev, const struct pci_device_id *pci_ent) +{ + const struct fore200e_bus* bus = (struct fore200e_bus*) pci_ent->driver_data; + struct fore200e* fore200e; + int err = 0; + static int index = 0; + + if (pci_enable_device(pci_dev)) { + err = -EINVAL; + goto out; + } + + fore200e = fore200e_kmalloc(sizeof(struct fore200e), GFP_KERNEL); + if (fore200e == NULL) { + err = -ENOMEM; + goto out_disable; + } + + fore200e->bus = bus; + fore200e->bus_dev = pci_dev; + fore200e->irq = pci_dev->irq; + fore200e->phys_base = pci_resource_start(pci_dev, 0); + + sprintf(fore200e->name, "%s-%d", bus->model_name, index - 1); + + pci_set_master(pci_dev); + + printk(FORE200E "device %s found at 0x%lx, IRQ %s\n", + fore200e->bus->model_name, + fore200e->phys_base, fore200e_irq_itoa(fore200e->irq)); + + sprintf(fore200e->name, "%s-%d", bus->model_name, index); + + err = fore200e_init(fore200e); + if (err < 0) { + fore200e_shutdown(fore200e); + goto out_free; + } + + ++index; + pci_set_drvdata(pci_dev, fore200e); + +out: + return err; + +out_free: + kfree(fore200e); +out_disable: + pci_disable_device(pci_dev); + goto out; +} + + +static void __devexit fore200e_pca_remove_one(struct pci_dev *pci_dev) +{ + struct fore200e *fore200e; + + fore200e = pci_get_drvdata(pci_dev); + + list_del(&fore200e->entry); + + fore200e_shutdown(fore200e); + kfree(fore200e); + pci_disable_device(pci_dev); +} + + +#ifdef CONFIG_ATM_FORE200E_PCA +static struct pci_device_id fore200e_pca_tbl[] = { + { PCI_VENDOR_ID_FORE, PCI_DEVICE_ID_FORE_PCA200E, PCI_ANY_ID, PCI_ANY_ID, + 0, 0, (unsigned long) &fore200e_bus[0] }, + { 0, } +}; + +MODULE_DEVICE_TABLE(pci, fore200e_pca_tbl); + +static struct pci_driver fore200e_pca_driver = { + .name = "fore_200e", + .probe = fore200e_pca_detect, + .remove = __devexit_p(fore200e_pca_remove_one), + .id_table = fore200e_pca_tbl, +}; +#endif + + static int __init fore200e_module_init(void) { const struct fore200e_bus* bus; struct fore200e* fore200e; - int index, link; + int index; printk(FORE200E "FORE Systems 200E-series ATM driver - version " FORE200E_VERSION "\n"); /* for each configured bus interface */ - for (link = 0, bus = fore200e_bus; bus->model_name; bus++) { + for (bus = fore200e_bus; bus->model_name; bus++) { /* detect all boards present on that bus */ - for (index = 0; (fore200e = bus->detect(bus, index)); index++) { + for (index = 0; bus->detect && (fore200e = bus->detect(bus, index)); index++) { printk(FORE200E "device %s found at 0x%lx, IRQ %s\n", fore200e->bus->model_name, @@ -2791,15 +2845,18 @@ break; } - link++; - - fore200e->next = fore200e_boards; - fore200e_boards = fore200e; + list_add(&fore200e->entry, &fore200e_boards); } } - if (link) - return 0; +#ifdef CONFIG_ATM_FORE200E_PCA + if (!pci_register_driver(&fore200e_pca_driver)) + return 0; +#endif + + if (!list_empty(&fore200e_boards)) + return 0; + return -ENODEV; } @@ -2807,11 +2864,14 @@ static void __exit fore200e_module_cleanup(void) { - while (fore200e_boards) { - struct fore200e* fore200e = fore200e_boards; + struct fore200e *fore200e, *next; + +#ifdef CONFIG_ATM_FORE200E_PCA + pci_unregister_driver(&fore200e_pca_driver); +#endif + list_for_each_entry_safe(fore200e, next, &fore200e_boards, entry) { fore200e_shutdown(fore200e); - fore200e_boards = fore200e->next; kfree(fore200e); } DPRINTK(1, "module being removed\n"); @@ -3146,7 +3206,7 @@ fore200e_pca_dma_sync_for_device, fore200e_pca_dma_chunk_alloc, fore200e_pca_dma_chunk_free, - fore200e_pca_detect, + NULL, fore200e_pca_configure, fore200e_pca_map, fore200e_pca_reset, diff -Nru a/drivers/atm/fore200e.h b/drivers/atm/fore200e.h --- a/drivers/atm/fore200e.h 2005-03-07 15:36:53 -05:00 +++ b/drivers/atm/fore200e.h 2005-03-07 15:36:53 -05:00 @@ -841,7 +841,7 @@ /* per-device data */ typedef struct fore200e { - struct fore200e* next; /* next device */ + struct list_head entry; /* next device */ const struct fore200e_bus* bus; /* bus-dependent code and data */ union fore200e_regs regs; /* bus-dependent registers */ struct atm_dev* atm_dev; /* ATM device */ From imipak@yahoo.com Mon Mar 7 15:17:16 2005 Received: with ECARTIS (v1.0.0; list netdev); Mon, 07 Mar 2005 15:17:20 -0800 (PST) Received: from web31510.mail.mud.yahoo.com (web31510.mail.mud.yahoo.com [68.142.198.139]) by oss.sgi.com (8.13.0/8.13.0) with SMTP id j27NHF4b017325 for ; Mon, 7 Mar 2005 15:17:15 -0800 Received: (qmail 52442 invoked by uid 60001); 7 Mar 2005 23:17:10 -0000 Comment: DomainKeys? See http://antispam.yahoo.com/domainkeys DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; b=xBAA86DUuuywZn5vWWjddofZxLDRWjbgmXlB4nOIj0H25QvsoAIRIrtazSakSlz9QcD6JRU4XP+0IIqwQCLQ3l1iZfHD08lWnTpc1u1/UZz0JT6D0t4KWhyUan5JxVVqvEPMPpCcYFp0oEbbgLC3i9Eg4FDgjj5Q6n1YDfY9iAY= ; Message-ID: <20050307231710.52440.qmail@web31510.mail.mud.yahoo.com> Received: from [63.86.107.226] by web31510.mail.mud.yahoo.com via HTTP; Mon, 07 Mar 2005 15:17:10 PST Date: Mon, 7 Mar 2005 15:17:10 -0800 (PST) From: Jonathan Day Subject: Re: Dynamically classifying flows? To: Asim Shankar , netdev@oss.sgi.com In-Reply-To: <7bca1cb505030709502316f9b8@mail.gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Virus-Scanned: ClamAV 0.83/751/Mon Mar 7 03:06:27 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 2620 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: imipak@yahoo.com Precedence: bulk X-list: netdev Content-Length: 5418 Lines: 158 It depends a bit on what OS you are using, as to the best strategy to follow. Linux has Layer 7 packet classification, so it should be possible to identify the more troublesome applications and have them in seperate queues. I don't think BSD's ALTQ has that capability, but I could be wrong. Other Operating Systems are anybody's guess. If applications are likely to misbehave, and in a manner that is unpredictable, then something in the "Fair Queueing" family would seem a good place to start. Your primary goal is not to impose bounds on the traffic as much as it is to place bounds on the penalties imposed, so it's not clear that you'd necessarily need to know whether something is bulk or interactive, you'd just need to know if it would cause problems if it were given greater bandwidth. RED is good under certain conditions, not so good under others. There are many members of the RED family, so you might want to shop around a little. There may be something that is perfect for your situation. I'd suggest ECN, but most applications don't pay attention to notifications. Worth a look, though - the OS might understand ECN and throttle the application on its behalf. (Sounds sadistic.) If you definitely want classful QoS, then I'd say make two classes - everything definitely known & needing high bandwidth, and everything else. Configure it so that your second class can NEVER steal used bandwidth from the first, but CAN be loaned it if there's insufficient interactive traffic to fill the quota it has been given. That way, you needn't care about "unknown" stuff, or whatever, because it'll all be lumped into the second class, unless it is specifically designated as being in the first class. --- Asim Shankar wrote: > Hi, > > I was looking into various queueing disciplines and > had some thoughts/queries. > This email is going to be fairly high-level and > somewhat long, so I'd be > grateful if you can bear with me. > > Okay, so qdiscs can be run in various ways - FIFO, > Round Robin (SFQ, PRIO), > HTB etc. Grossly oversimplified, I see all these > strategies as allowing > administrators to statically define packet classes > and class priorities, and > then possibly ensuring fairness amongst packets with > equal class priotities. > > This "staticness" of class priorities *may* lead to > some problems (well, I'm > going to ask if they can). Consider a huge, popular > file on an HTTP server. > Due to its popularity, requests for small pages may > suffer. Similarly, > consider an SSH/SFTP server where SFTP traffic for > large, popular files may > choke the SSH terminal connections (especially if > the application doesn't set > the TOS bits or routers along the way ignore them). > So we have interactive > flows (like someone SSHing to do some 'ls'es or many > clients viewing a small > web-page) and bulk flows (downloads). By "flow" I > mean a connection, not > necessarily an explicit TCP connection but a loose > definition - say something > that "ip_conntrack" tracks. > > Question 1: Can the number of and speed with which > bulk flow packets are > generated adversely affect the interactive flows - > i.e., can too many large > file downloads make the 'ls' or the small page > downloads slow? Is this a > _likely_ scenario? > > Diffserv already in effect tries to classify traffic > as interactive or > bulk. However, this classification is still static > and requires application > cooperation, which may not always be available or > may be overridden. Web > servers for example don't change the TOS fields > depending on whether the > file requested was a 700MB CD-image or a 2K > homepage. > > Question 2: Does the idea of _dynamically_ > classifying traffic as interactive > or bulk make any sense at all? Or does the TOS field > work well enough for > dynamic classification to not be of any practical > interest? > > If it does make sense, > > Question 3: Has work already been along along these > lines? If so, any pointers > would be appreciated. > > Can we use ideas from process scheduling to be > kinder to the interactive > flows? A "process" becomes a "flow", the "CPU" > becomes the "NIC" and "time" > becomes "bytes". Process scheduling tries to keep > system responsiveness high > by dynamically classifying processes as interactive > or bulk and then making > interactive process priorities higher than > non-interactive. A similar strategy > at the qdisc would mean that when the interactive > flow has something to send, > it will get a higher priority. Flows will be > dynamically assigned priorities > based on the history of traffic they generate. > > Applying process scheduling would be somewhat > expensive (we're keeping track > of connections). RED on the other hand does > something *like* this by making > the probability of a packet drop of a particular > flow proportional to the > traffic generated by the flow, of course it does so > without any explicit > notion of flows. This leads to: > > Question 5: Does RED provide *everything* this > process-scheduling strategy > would? i.e., how would you compare the two? > > Well, I guess that completes my question list for > now. > Thanks for reading (and replying :-)), > Regards, > > -- Asim > > __________________________________________________ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com From hadi@cyberus.ca Mon Mar 7 15:33:37 2005 Received: with ECARTIS (v1.0.0; list netdev); Mon, 07 Mar 2005 15:33:42 -0800 (PST) Received: from mx02.cybersurf.com (mx02.cybersurf.com [209.197.145.105]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j27NXYUU018191 for ; Mon, 7 Mar 2005 15:33:37 -0800 Received: from mail.cyberus.ca ([209.197.145.21]) by mx02.cybersurf.com with esmtp (Exim 4.30) id 1D8RjA-0006Kc-Hv for netdev@oss.sgi.com; Mon, 07 Mar 2005 18:33:32 -0500 Received: from [24.103.99.32] (helo=[10.0.0.9]) by mail.cyberus.ca with esmtp (Exim 4.20) id 1D8Rj8-00025p-HY; Mon, 07 Mar 2005 18:33:30 -0500 Subject: Re: bridge between ppp and ethernet - 1 IP address and assign it to another host From: jamal Reply-To: hadi@cyberus.ca To: bert hubert Cc: Mark Smith , netdev@oss.sgi.com In-Reply-To: <20050307213211.GA25323@outpost.ds9a.nl> References: <20050306153108.20430b58.random@72616e646f6d20323030342d30342d31360a.nosense.org> <1110199198.1094.1282.camel@jzny.localdomain> <20050308002643.7eac84e7.random@72616e646f6d20323030342d30342d31360a.nosense.org> <20050307213211.GA25323@outpost.ds9a.nl> Content-Type: text/plain Organization: jamalopolous Message-Id: <1110238406.1043.57.camel@jzny.localdomain> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.2.2 Date: 07 Mar 2005 18:33:26 -0500 Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV 0.83/751/Mon Mar 7 03:06:27 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 2621 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: hadi@cyberus.ca Precedence: bulk X-list: netdev Content-Length: 2487 Lines: 69 On Mon, 2005-03-07 at 16:32, bert hubert wrote: > On Tue, Mar 08, 2005 at 12:26:43AM +1030, Mark Smith wrote: I think i got it finally .. > Indeed, we are in full agreement. The idea is to have the ability to fully > firewall and monitor a machine that absolutely needs to have a real > routable IP address, without wasting an IP address for the router (or trying > to get an ISP to assign you multiple addresses, which can be a major chore > these days). > > I'd settle for a 'dirty' solution. Remco van Mook of Virtu.nl suggested > abusing iptables -j QUEUE combind with tun/tap to inject the packets on the > ethernet side, where userspace does the PPP -> ethernet conversion by making > up the required headers. > > Ideas? Seems you will get much speedup doing it in the kernel instead. So lets take the steps Mark posted. Actually before that, is the proxy ARP really necessary if the windoz machines have a default gateway of this proxy machine. Lets looks t incoming from PPP: > 1) IP packet comes in encapsulated in PPP. > 2) The Linux box decapsulates it from the PPP header / trailer. > 3) The Linux box performs layer 3 firewalling processing against the > IP packet. Assuming 1 to 1 mapping i.e each pppx maps to one windows machine (on one eth device?); then when you issue the DHCP IP to the windoz machine you add the following rules: (assuming kernels 2.6.8 and up) with tc actions eg tc ...ingress pppx... tc ... dev pppx u32 match 0/0 i.e match all packets that came via pppx action some firewall rules here .. (stateless for now) action some rate limit here .. action mirred redirect ethx // eventually redirect to windoz I think this should work fine; there may be need to rewrite MAC addresses - but if you give this a shot and things are screwed up we could redraw. I am willing toi help you resolve the issue if you put the effort. >4) If the IP packet passes the firewall rules, it is then encapsulated >in an ethernet frame, and sent to the Windows box. This might be >achived by configuring a host route for the IP address on the Linux > box, pointing directly to the ethernet interface, indicating it is > directly attached. If you do the above, do you really need to route to the windoz machines? Let them worry about things... On the return path it is much simpler; just have windows forward and let routing take care of it. So summary: -->pppx -->"switch"---> windoz <--pppx <-- L3route <--- windoz cheers, jamal From hadi@cyberus.ca Mon Mar 7 15:35:50 2005 Received: with ECARTIS (v1.0.0; list netdev); Mon, 07 Mar 2005 15:35:55 -0800 (PST) Received: from mx04.cybersurf.com (mx04.cybersurf.com [209.197.145.108]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j27NZnqe018643 for ; Mon, 7 Mar 2005 15:35:49 -0800 Received: from mail.cyberus.ca ([209.197.145.21]) by mx01.cybersurf.com with esmtp (Exim 4.30) id 1D8RlM-0008H9-Cq for netdev@oss.sgi.com; Mon, 07 Mar 2005 18:35:48 -0500 Received: from [24.103.99.32] (helo=[10.0.0.9]) by mail.cyberus.ca with esmtp (Exim 4.20) id 1D8RlF-0002ON-TG; Mon, 07 Mar 2005 18:35:42 -0500 Subject: Re: [leo@yuriev.ru: [PATCH] ethernet-bridge: update skb->priority in case forwarded frame has VLAN-header] From: jamal Reply-To: hadi@cyberus.ca To: Patrick McHardy Cc: Ben Greear , leo@yuriev.ru, Lennert Buytenhek , shemminger@osdl.org, netdev@oss.sgi.com In-Reply-To: References: <20050305141225.GA5180@xi.wantstofly.org> <4229D98F.9010008@trash.net> <422A0C21.3050709@candelatech.com> <1110199696.1094.1299.camel@jzny.localdomain> Content-Type: text/plain Organization: jamalopolous Message-Id: <1110238537.1043.62.camel@jzny.localdomain> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.2.2 Date: 07 Mar 2005 18:35:37 -0500 Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV 0.83/751/Mon Mar 7 03:06:27 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 2622 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: hadi@cyberus.ca Precedence: bulk X-list: netdev Content-Length: 650 Lines: 20 On Mon, 2005-03-07 at 14:36, Patrick McHardy wrote: > On Mon, 7 Mar 2005, jamal wrote: > > > This is wrong. IEEE priorities are opposite of IETF priorities (as used by > > skb->prio). > > Unless you install a prio qdisc and rewrite the priomap, you are screwed. > > So you should do opposite mapping, i.e something along the lines of > > VLAN_TCI priority (0..7) to skb->priority (15..8) i,e > > > > skb->priority = 15 - vlan_TCI; > > The priority should still start at 0. You don't want to create a 16-band > queue just to have 8 bands unused. say what?;-> Nothing has to start at 0. 16 priorities does not equate to 16 queues. cheers, jamal From hadi@cyberus.ca Mon Mar 7 15:50:45 2005 Received: with ECARTIS (v1.0.0; list netdev); Mon, 07 Mar 2005 15:50:48 -0800 (PST) Received: from mx03.cybersurf.com (mx03.cybersurf.com [209.197.145.106]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j27Nog0I019514 for ; Mon, 7 Mar 2005 15:50:44 -0800 Received: from mail.cyberus.ca ([209.197.145.21]) by mx03.cybersurf.com with esmtp (Exim 4.30) id 1D8Rzm-0004su-86 for netdev@oss.sgi.com; Mon, 07 Mar 2005 18:50:42 -0500 Received: from [24.103.99.32] (helo=[10.0.0.9]) by mail.cyberus.ca with esmtp (Exim 4.20) id 1D8Rzf-00048R-Gr; Mon, 07 Mar 2005 18:50:35 -0500 Subject: Re: Do you know the TCP stack? (127.x.x.x routing) From: jamal Reply-To: hadi@cyberus.ca To: Steve Iribarne Cc: Eran Mann , Zdenek Radouch , Thomas Graf , Andi Kleen , Martin Mares , netdev@oss.sgi.com, linux-net@vger.kernel.org In-Reply-To: <422C0B50.20500@mrv.com> References: <20050306173145.GQ31837@postel.suug.ch> <3sp35g$7hpm0@smtp04.mrf.mail.rcn.net> <422C0B50.20500@mrv.com> Content-Type: text/plain Organization: jamalopolous Message-Id: <1110239430.1043.71.camel@jzny.localdomain> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.2.2 Date: 07 Mar 2005 18:50:31 -0500 Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV 0.83/751/Mon Mar 7 03:06:27 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 2623 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: hadi@cyberus.ca Precedence: bulk X-list: netdev Content-Length: 1122 Lines: 35 BTW, please cc netdev or myself if you are addressing me. This email was just forwarde by someone else to me - I am not on linux-net. You seem to have trimmed down the CC list. On Mon, 2005-03-07 at 18:02:18, Steve Iribarne wrote: >-> >-> What is so wrong with RFC198 addresses?? >-> >Really RFC1918 you mean... Indeed 1918 >Well if your product is placed behind a nat'd network, MOST if not ALL > nat'd network addresses on the "inside" use the RFC1918 address space. I read this a few times and still didnt get it: Why is it that people using 1918 addresses are affecting you? Does using 127.x help you because you assume _nobody_ else would be using 127.x addresses? I am assuming you want this address for some internal network whereas the external contains some routable addresses? > So I have this working in my products now. I had to do something a bit > different in that I want a "special" 127.xx.xx.xx range to be sent out > on the wire. So here is what I did. [..] Seems you did too much. Look at the 2 liner patch posted by Eran Mann (which should work on 2.4 and 2.6 as well). cheers, jamal From kaber@trash.net Mon Mar 7 15:54:05 2005 Received: with ECARTIS (v1.0.0; list netdev); Mon, 07 Mar 2005 15:54:09 -0800 (PST) Received: from kaber.coreworks.de ([62.206.217.67]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j27Ns3vt020062 for ; Mon, 7 Mar 2005 15:54:05 -0800 Received: from localhost ([127.0.0.1]) by kaber.coreworks.de with esmtp (Exim 4.50) id 1D8S2d-0002bH-TR; Tue, 08 Mar 2005 00:53:39 +0100 Message-ID: <422CE983.7060305@trash.net> Date: Tue, 08 Mar 2005 00:53:39 +0100 From: Patrick McHardy User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.7.5) Gecko/20050106 Debian/1.7.5-1 X-Accept-Language: en MIME-Version: 1.0 To: hadi@cyberus.ca CC: Ben Greear , leo@yuriev.ru, Lennert Buytenhek , shemminger@osdl.org, netdev@oss.sgi.com Subject: Re: [leo@yuriev.ru: [PATCH] ethernet-bridge: update skb->priority in case forwarded frame has VLAN-header] References: <20050305141225.GA5180@xi.wantstofly.org> <4229D98F.9010008@trash.net> <422A0C21.3050709@candelatech.com> <1110199696.1094.1299.camel@jzny.localdomain> <1110238537.1043.62.camel@jzny.localdomain> In-Reply-To: <1110238537.1043.62.camel@jzny.localdomain> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV 0.83/751/Mon Mar 7 03:06:27 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 2624 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: kaber@trash.net Precedence: bulk X-list: netdev Content-Length: 545 Lines: 17 jamal wrote: >> >>The priority should still start at 0. You don't want to create a 16-band >>queue just to have 8 bands unused. > > > say what?;-> Nothing has to start at 0. 16 priorities does not equate to > 16 queues. Right. But the default pfifo_fast/prio mapping maps the upper 8 values to queue 1, which seems to make this effort kind of useless. I don't know if the default-mapping of the lower 8 values is useable in this context, I need to inform myself more on this subject (thanks for the IEEE vs. IETF pointers). Regards Patrick From hadi@cyberus.ca Mon Mar 7 16:03:48 2005 Received: with ECARTIS (v1.0.0; list netdev); Mon, 07 Mar 2005 16:03:52 -0800 (PST) Received: from mx02.cybersurf.com (mx02.cybersurf.com [209.197.145.105]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j2803lOH023695 for ; Mon, 7 Mar 2005 16:03:48 -0800 Received: from mail.cyberus.ca ([209.197.145.21]) by mx02.cybersurf.com with esmtp (Exim 4.30) id 1D8SCP-0001AV-Mr for netdev@oss.sgi.com; Mon, 07 Mar 2005 19:03:45 -0500 Received: from [24.103.99.32] (helo=[10.0.0.9]) by mail.cyberus.ca with esmtp (Exim 4.20) id 1D8SCN-0005Vl-7z; Mon, 07 Mar 2005 19:03:43 -0500 Subject: Re: [RFC] neighbour tables configuration via rtnetlink From: jamal Reply-To: hadi@cyberus.ca To: Thomas Graf Cc: netdev@oss.sgi.com In-Reply-To: <20050307142622.GT31837@postel.suug.ch> References: <20050305172257.GN31837@postel.suug.ch> <1110202499.1094.1371.camel@jzny.localdomain> <20050307142622.GT31837@postel.suug.ch> Content-Type: text/plain Organization: jamalopolous Message-Id: <1110240219.1044.83.camel@jzny.localdomain> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.2.2 Date: 07 Mar 2005 19:03:39 -0500 Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV 0.83/751/Mon Mar 7 03:06:27 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 2625 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: hadi@cyberus.ca Precedence: bulk X-list: netdev Content-Length: 4552 Lines: 92 On Mon, 2005-03-07 at 09:26, Thomas Graf wrote: > * jamal <1110202499.1094.1371.camel@jzny.localdomain> 2005-03-07 08:34 [..] > Mainly because we have multiple applications that modify neighbour parameters > and they really have need to finish changing all parameters before another > application can look at them again. I solved this with a userspace lockfile > so far but this only catches applications that are aware of the lockfile. > The netlink method still leaves the gap open between fetching the data and > then changing it but that isn't a problem in my case and can be solved with > the netlink daemon for those who care. > Sure - but this problem is not restricted to just this app of yours but rather to the whole of netlink. I am not questioning need for this approach - so lets forget about you providing justification. > > Some of the parameters you are dumping maybe dangerous if they are also > > allowed to be setable. As an example, changing a table name/id etc. > > I think you should review closely again what needs to be exposed. > > Sure, not all dumpable parameters will be available for modification but > having them all available in userspace is definitely a good thing. > I would tend to agree > > I think this is reasonable. However - it is a lot of work. I will have > > no issues with seeing nothing else but netlink (even for ethtool like > > setups). There are certain things that would require more attention than > > others. > > Yes, I think so as well but I really want to avoid putting effort into it > and then see it replaced with something else. I think Herbert once thought > about moving some of the rtnetlink stuff into a separate family and > restructuring the whole thing. Still plans there Herbert? > You will still need to grab the rtnl - so probably not much value in creating a new netlink proto. > > I was going to write a simple patch to allow setting of indev > > parameters via netlink but havent had time. Started it but havent had > > time to revisit it - if you want to take over that one as well i could > > pass it on to you. > > Sure, but I won't have time to actually work on it until next week. > I have it on another machine - will send it later; if you havent received it from me by the time you have cycles, please ping me. > > To achieve distributed configuration you dont need netlink. The main > > advantage of netlink over say /proc is the ability to do async events. > > [Yes, I know i have been shouting for taking netlink and and sending it > > over the wire and mucking around with endianness flags - but after > > practical considerations i am having second thoughts;] > > Yes I went through severeal iterations of thoughts as well but it still > seems reasonable to me. My current approach sounds quite silly but seems > to work out pretty well. It gets down to having libnl providing a XML input > and output interface and XSLT templates to convert every block into byte > order independant form and vice versa. I'm still toying around but I > already managed to convert my XML thingy into other protocols (given they > are at least somehow compatible in architecture). It is also quite simple > to convert these requests into a human readable form such as HTML and > have it placed onto a website for a operator to accept the change or to > simply keep a log of what has been changed when. > > I'm not yet sure if it works out in the end but the goal is to reduce the > work needed to support a new rtnetlink object to the existance of a XSLT > stylesheet published somewhere and if possible have the XSLT processor > fetch it automatically from a local or global site. Other advantages? > Operators could modify the XSLT and add conditions and automatically > modify change requests to their needs. Yes, i think you are on the right track as far as using xnl. And if you do that endianness issues dont exist (since XML is ascii). I would advice (like i have many times on this) to not invent a protocol - reusing something like netconf is the best approach. My understanding of netconf though is a little dissapointing in that it does not do events in the current version they are working on. I think events are supposed to come post version 1.0 of the protocol. I believe there is a open source project which does netconf already; maybe all they need is just your library and xml interface ... I will look it up and send you some pointers. BTW, what happened in the discussion with the gent who was doing SOAP (or was going to do SOAP?) cheers, jamal From asimshankar@gmail.com Mon Mar 7 16:10:50 2005 Received: with ECARTIS (v1.0.0; list netdev); Mon, 07 Mar 2005 16:10:53 -0800 (PST) Received: from wproxy.gmail.com (wproxy.gmail.com [64.233.184.195]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j280Anmu024792 for ; Mon, 7 Mar 2005 16:10:49 -0800 Received: by wproxy.gmail.com with SMTP id 71so1459385wri for ; Mon, 07 Mar 2005 16:10:44 -0800 (PST) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:reply-to:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:references; b=f/PC0I8QrJXrWXmVd4s4qIPSs3UEPnSgnCVSeYZBUSfoO6YzWZ1M0lV3cOkwFiCXOaMN01CYItnM9ctoF1EjjW21HNKuErncCMBX1BQdHC2BxX/cwwyPHaQtFj8HOpZzygysqr32IBFoOL9ZXHmKaBd5k7hDn5USwTLDuS+AXb4= Received: by 10.54.80.12 with SMTP id d12mr50736wrb; Mon, 07 Mar 2005 16:10:44 -0800 (PST) Received: by 10.54.24.42 with HTTP; Mon, 7 Mar 2005 16:10:43 -0800 (PST) Message-ID: <7bca1cb505030716104856fe3@mail.gmail.com> Date: Mon, 7 Mar 2005 18:10:43 -0600 From: Asim Shankar Reply-To: Asim Shankar To: Thomas Graf Subject: Re: Dynamically classifying flows? Cc: netdev@oss.sgi.com In-Reply-To: <20050307203450.GX31837@postel.suug.ch> Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit References: <7bca1cb505030709502316f9b8@mail.gmail.com> <20050307203450.GX31837@postel.suug.ch> X-Virus-Scanned: ClamAV 0.83/751/Mon Mar 7 03:06:27 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 2626 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: asimshankar@gmail.com Precedence: bulk X-list: netdev Content-Length: 1935 Lines: 38 > It is a likely scenario but usually not a problem because you can classify this > kind of bulk packets by their size. u32 can be used use for such things or the > newly added meta ematch. Filtering by size may not always work. An interactive flow may also generate big (MTU) size packets, but it is interactive because the _rate_ at which packets are produced is smaller. Though, if you think that such cases are purely theoretical and don't create problems in practice, do let me know. > > Question 2: Does the idea of _dynamically_ classifying traffic as interactive > > or bulk make any sense at all? Or does the TOS field work well enough for > > dynamic classification to not be of any practical interest? > > Yes it does and that's exactly the direction the ematch API is going to. Can you point me to some details on ematch? Specifically, how it supports dynamic classifications of flows? Seems like this is something really new you guys are working on, so not much documentation is available. > > Can we use ideas from process scheduling to be kinder to the interactive > > flows? > In order to prioritize there must be a queue, and for remote terminal protocols > you want to avoid queues at any cost because it will introduce latency in any > case. Even on overloaded lines with full queues, the queues are rarely bigh > enough to really apply any sort of priority queues. Won't we always have queues? After all a qdisc essentially specifies a de-queuing algorithm. I was thinking along the lines of process scheduling to be able to avoid having to manually specify flow priorities. Ideally speaking, it would automatically classify remote terminal flows such that they see the least possible queueing delays. Though, you seem to be of the opinion that manual classification is easy enough and most traffic worth worrying about use DSCP flags effectively. Is that correct? Thanks for your comments, Regards, -- Asim From hadi@cyberus.ca Mon Mar 7 16:19:59 2005 Received: with ECARTIS (v1.0.0; list netdev); Mon, 07 Mar 2005 16:20:06 -0800 (PST) Received: from mx02.cybersurf.com (mx02.cybersurf.com [209.197.145.105]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j280Jxdd028816 for ; Mon, 7 Mar 2005 16:19:59 -0800 Received: from mail.cyberus.ca ([209.197.145.21]) by mx02.cybersurf.com with esmtp (Exim 4.30) id 1D8SS5-0007l5-0h for netdev@oss.sgi.com; Mon, 07 Mar 2005 19:19:57 -0500 Received: from [24.103.99.32] (helo=[10.0.0.9]) by mail.cyberus.ca with esmtp (Exim 4.20) id 1D8SS2-0007IW-LL; Mon, 07 Mar 2005 19:19:54 -0500 Subject: Re: [leo@yuriev.ru: [PATCH] ethernet-bridge: update skb->priority in case forwarded frame has VLAN-header] From: jamal Reply-To: hadi@cyberus.ca To: Patrick McHardy Cc: Ben Greear , leo@yuriev.ru, Lennert Buytenhek , shemminger@osdl.org, netdev@oss.sgi.com In-Reply-To: <422CE983.7060305@trash.net> References: <20050305141225.GA5180@xi.wantstofly.org> <4229D98F.9010008@trash.net> <422A0C21.3050709@candelatech.com> <1110199696.1094.1299.camel@jzny.localdomain> <1110238537.1043.62.camel@jzny.localdomain> <422CE983.7060305@trash.net> Content-Type: text/plain Organization: jamalopolous Message-Id: <1110241190.1043.100.camel@jzny.localdomain> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.2.2 Date: 07 Mar 2005 19:19:50 -0500 Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV 0.83/751/Mon Mar 7 03:06:27 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 2627 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: hadi@cyberus.ca Precedence: bulk X-list: netdev Content-Length: 1178 Lines: 35 On Mon, 2005-03-07 at 18:53, Patrick McHardy wrote: > jamal wrote: > >> > >>The priority should still start at 0. You don't want to create a 16-band > >>queue just to have 8 bands unused. > > > > > > say what?;-> Nothing has to start at 0. 16 priorities does not equate to > > 16 queues. > > Right. But the default pfifo_fast/prio mapping maps the upper 8 values > to queue 1, which seems to make this effort kind of useless. > I don't know if the default-mapping of the lower 8 values is useable > in this context, Indeed that looks bad. But wouldnt have helped if we started at 0 either. You need monotonically increasing values to make proper sense. So i suppose to do proper qos with L2, one must install the prio qdisc and rewrite the priomap. The mapping used in pfifo_fast is derived from RFC1349 4 bit TOS which is really considered toast these days. We need to revamp things - but this would require some surgery in the route code as well (so maybe safe to leave as is). > I need to inform myself more on this subject (thanks for the > IEEE vs. IETF pointers). > Has bitten me a few times when trying to do Qos between switches and routers. cheers, jamal From akpm@osdl.org Mon Mar 7 16:22:58 2005 Received: with ECARTIS (v1.0.0; list netdev); Mon, 07 Mar 2005 16:23:02 -0800 (PST) Received: from smtp.osdl.org (fire.osdl.org [65.172.181.4]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j280Mvjm029804 for ; Mon, 7 Mar 2005 16:22:58 -0800 Received: from shell0.pdx.osdl.net (fw.osdl.org [65.172.181.6]) by smtp.osdl.org (8.12.8/8.12.8) with ESMTP id j280Mdqi008069 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO); Mon, 7 Mar 2005 16:22:40 -0800 Received: from localhost.localdomain (shell0.pdx.osdl.net [10.9.0.31]) by shell0.pdx.osdl.net (8.13.1/8.11.6) with ESMTP id j280MdD3008666; Mon, 7 Mar 2005 16:22:39 -0800 Message-Id: <200503080022.j280MdD3008666@shell0.pdx.osdl.net> Subject: [patch 1/1] remove last_rx update from loopback device To: davem@davemloft.net Cc: netdev@oss.sgi.com, akpm@osdl.org, christoph@graphe.net, nirajk@calsoftinc.com, christoph@lameter.com, Shai@Scalex86.org From: akpm@osdl.org Date: Mon, 7 Mar 2005 16:22:41 -0800 Received-SPF: pass (domain of akpm@osdl.org designates 65.172.181.6 as permitted sender) X-MIMEDefang-Filter: osdl$Revision: 1.104 $ X-Scanned-By: MIMEDefang 2.36 X-Virus-Scanned: ClamAV 0.83/751/Mon Mar 7 03:06:27 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 2628 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: akpm@osdl.org Precedence: bulk X-list: netdev Content-Length: 1257 Lines: 34 From: Christoph Lameter The last_rx field in the loopback driver is updated on every xmit but is not used otherwise. Accesses to ->last_rx cause unecessary traffic on the interlink for NUMA systems which limits the performance of the loopback device. The comment given at include/linux/netdevice.h says that last_rx may be used for future network-power-down code, which is likely not relevant for the loopback device (please let me know if it is otherwise ..). Signed-off-by: Niraj Kumar Signed-off-by: Christoph Lameter Signed-off-by: Shai Fultheim Signed-off-by: Andrew Morton --- 25-akpm/drivers/net/loopback.c | 2 -- 1 files changed, 2 deletions(-) diff -puN drivers/net/loopback.c~remove-last_rx-update-from-loopback-device drivers/net/loopback.c --- 25/drivers/net/loopback.c~remove-last_rx-update-from-loopback-device Mon Mar 7 16:21:49 2005 +++ 25-akpm/drivers/net/loopback.c Mon Mar 7 16:21:49 2005 @@ -144,8 +144,6 @@ static int loopback_xmit(struct sk_buff return 0; } - dev->last_rx = jiffies; - lb_stats = &per_cpu(loopback_stats, get_cpu()); lb_stats->rx_bytes += skb->len; lb_stats->tx_bytes += skb->len; _ From kaber@trash.net Mon Mar 7 16:25:28 2005 Received: with ECARTIS (v1.0.0; list netdev); Mon, 07 Mar 2005 16:25:31 -0800 (PST) Received: from kaber.coreworks.de ([62.206.217.67]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j280PRtP030363 for ; Mon, 7 Mar 2005 16:25:28 -0800 Received: from localhost ([127.0.0.1]) by kaber.coreworks.de with esmtp (Exim 4.50) id 1D8SXI-0002gg-Lb; Tue, 08 Mar 2005 01:25:20 +0100 Message-ID: <422CF0F0.3020407@trash.net> Date: Tue, 08 Mar 2005 01:25:20 +0100 From: Patrick McHardy User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.7.5) Gecko/20050106 Debian/1.7.5-1 X-Accept-Language: en MIME-Version: 1.0 To: Asim Shankar CC: Thomas Graf , netdev@oss.sgi.com Subject: Re: Dynamically classifying flows? References: <7bca1cb505030709502316f9b8@mail.gmail.com> <20050307203450.GX31837@postel.suug.ch> <7bca1cb505030716104856fe3@mail.gmail.com> In-Reply-To: <7bca1cb505030716104856fe3@mail.gmail.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV 0.83/751/Mon Mar 7 03:06:27 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 2629 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: kaber@trash.net Precedence: bulk X-list: netdev Content-Length: 799 Lines: 18 Asim Shankar wrote: >>It is a likely scenario but usually not a problem because you can classify this >>kind of bulk packets by their size. u32 can be used use for such things or the >>newly added meta ematch. > > Filtering by size may not always work. An interactive flow may also > generate big (MTU) size packets, but it is interactive because the > _rate_ at which packets are produced is smaller. Though, if you think > that such cases are purely theoretical and don't create problems in > practice, do let me know. The connbytes and the connrate match from netfilter patch-o-matic can be used to dynamically reclassify demanding connections. Keep in mind that reclassification can cause reordering, so you should make sure it can't happen frequently for single connections. Regards Patrick From tgraf@suug.ch Mon Mar 7 17:14:32 2005 Received: with ECARTIS (v1.0.0; list netdev); Mon, 07 Mar 2005 17:14:36 -0800 (PST) Received: from b.mx.projectdream.org (eth0-0.arisu.projectdream.org [194.158.4.191]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j281EVQV000746 for ; Mon, 7 Mar 2005 17:14:31 -0800 Received: from postel.suug.ch (postel.suug.ch [195.134.158.23]) (using TLSv1 with cipher EDH-RSA-DES-CBC3-SHA (168/168 bits)) (No client certificate requested) by b.mx.projectdream.org (Postfix) with ESMTP id 2CB5182; Tue, 8 Mar 2005 02:14:00 +0100 (CET) Received: by postel.suug.ch (Postfix, from userid 10001) id D8C5A1C0EA; Tue, 8 Mar 2005 02:14:31 +0100 (CET) Date: Tue, 8 Mar 2005 02:14:31 +0100 From: Thomas Graf To: Asim Shankar Cc: netdev@oss.sgi.com Subject: Re: Dynamically classifying flows? Message-ID: <20050308011431.GY31837@postel.suug.ch> References: <7bca1cb505030709502316f9b8@mail.gmail.com> <20050307203450.GX31837@postel.suug.ch> <7bca1cb505030716104856fe3@mail.gmail.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <7bca1cb505030716104856fe3@mail.gmail.com> X-Virus-Scanned: ClamAV 0.83/751/Mon Mar 7 03:06:27 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 2630 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: tgraf@suug.ch Precedence: bulk X-list: netdev Content-Length: 5716 Lines: 109 * Asim Shankar <7bca1cb505030716104856fe3@mail.gmail.com> 2005-03-07 18:10 > Filtering by size may not always work. An interactive flow may also > generate big (MTU) size packets, but it is interactive because the > _rate_ at which packets are produced is smaller. Though, if you think > that such cases are purely theoretical and don't create problems in > practice, do let me know. It really depends on your needs and the accuracy you need. I guess, there is not a single truth. I've been experimenting with a classifier which classifies based on the packet rate over a certain time, relative to the total packet rate, i.e. the higher the packet rate the more likely it is supposd to be a bulk data transfer. It is quite successful for high traffic scenarios where real connection tracking is not possible. However, this only works for certain scenarios, there are dozens of other ways to solve this problem, one of them is the recent additions to netfilter as Patrick pointed out. > Can you point me to some details on ematch? Specifically, how it > supports dynamic classifications of flows? Seems like this is > something really new you guys are working on, so not much > documentation is available. The term "dynamic classification" is a bit wide and can be interpreted in various ways. Ematch is not aiming towards a specific direction but rather tries to provide a easy to use API for everyone to write their own classification procedures or construct one by combining existing ematches. As you mentioned, it's quite new and still experimental and not well documented but this will change together with the required userspace additions. > Won't we always have queues? After all a qdisc essentially specifies a > de-queuing algorithm. Yes but the queues will be empty most of the times except if you apply some kind of rate limitation and that is exactly what should be avoided while handling interactive flows. It would be possible of course to try and pick all the packets belonging to a interactive flow but why bother? Enqueueing them into a separate band is easier and causes less troubles. > I was thinking along the lines of process > scheduling to be able to avoid having to manually specify flow > priorities. Ideally speaking, it would automatically classify remote > terminal flows such that they see the least possible queueing delays. This would be nice but really is hard to achieve. The drawback of any automation is that the worst-case scenarios are often much worse. The classifier algorithm mentioned above aims into this direction by automatically classifying packets into different bands based on their packet rate relative to the total packet rate. It is an interesting topic and has potention for great ideas and concepts but it is harder than it looks at a first glance. It gets quite worse when you try to guarantee some kind of QoS policy because all dynamic approachs I've seen go totally berserk under extreme conditions. I'll give you some examples of what I mean: Assuming you to want detect and classify interactive flows. Does this mean that the connection handshake is included as well? If so, how do you differ between connection handshakes of interactive flows and bulk flows if not with the help of some static pattern? Depending on your actual policy you're likely being forced to drop out of band packets which will make the connection estabilishment very unreliable for interactive traffic which probably interfers with your QoS policy. Assuming you either ignore or solved the above problem, what happens if certain packets are classified wrong? Your flows are unreliable because they are subject to arbitary bursts of high latency or even packet loss. Assuming you use connection tracking and automatically classify all packets the same belonging to the same connection (which is a quite popular approach) what happens if parts of your interactive flows contain heavy bulky areas in between (e.g. ls -R / over a remote terminal connection)? It will pollute all your fine tuned interactive queues and take influence on other unrelated interactive flows. As you can see it really depends on your needs and the actual problem you're trying to solve. There is no easy and fully automatic solution for the above. Actually it's quite hard to solve these with manual fine tuned classification too but it is possible because you can divided it into various problem domains and solve each independantly. I will agree with you when you say that there is a possibility to build a qdisc which will handle the typical home end-user setup with remote terminal traffic, bulk data traffic and possibily some gaming and I'll assist you in any way if you want to put effort into it because it would be a good thing (tm). > Though, you seem to be of the opinion that manual classification is > easy enough and most traffic worth worrying about use DSCP flags > effectively. Is that correct? I think manually configurable classification tools have a more wide spectrum of usability but I agree with you that those are harder to use. I also think that DSCP is doing a good job and is enough for more jobs than many people can imagine but it has strong limitations and most problems need a combination of various techniques which is the reason for the ematches to support logical expressions. I think there is a big potential for making things easier to configure but this needs time and a lot of effort. I think ematches are a step in the right direction but a lot more effort needs to go into the userspace tools. There is some work going on in the background but the fact that usability is very time consuming makes it a slow process. From random@72616e646f6d20323030342d30342d31360a.nosense.org Mon Mar 7 17:27:43 2005 Received: with ECARTIS (v1.0.0; list netdev); Mon, 07 Mar 2005 17:27:49 -0800 (PST) Received: from ubu.nosense.org (166.cust13.sa.dsl.ozemail.com.au [210.84.236.166]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j281RglR001691 for ; Mon, 7 Mar 2005 17:27:42 -0800 Received: from ubu.nosense.org (ubu.nosense.org [127.0.0.1]) by ubu.nosense.org (Postfix) with SMTP id 0F10762AAE; Tue, 8 Mar 2005 11:57:35 +1030 (CST) Date: Tue, 8 Mar 2005 11:57:34 +1030 From: Mark Smith To: hadi@cyberus.ca Cc: ahu@ds9a.nl, netdev@oss.sgi.com Subject: Re: bridge between ppp and ethernet - 1 IP address and assign it to another host Message-Id: <20050308115734.544fcaca.random@72616e646f6d20323030342d30342d31360a.nosense.org> In-Reply-To: <1110238406.1043.57.camel@jzny.localdomain> References: <20050306153108.20430b58.random@72616e646f6d20323030342d30342d31360a.nosense.org> <1110199198.1094.1282.camel@jzny.localdomain> <20050308002643.7eac84e7.random@72616e646f6d20323030342d30342d31360a.nosense.org> <20050307213211.GA25323@outpost.ds9a.nl> <1110238406.1043.57.camel@jzny.localdomain> X-Mailer: Sylpheed version 1.0.0beta1 (GTK+ 1.2.10; i686-pc-linux-gnu) X-Location: Adelaide, Australia Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV 0.83/751/Mon Mar 7 03:06:27 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 2631 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: random@72616e646f6d20323030342d30342d31360a.nosense.org Precedence: bulk X-list: netdev Content-Length: 2575 Lines: 61 Hi Jamal, Bert, On 07 Mar 2005 18:33:26 -0500 jamal wrote: > On Mon, 2005-03-07 at 16:32, bert hubert wrote: > > On Tue, Mar 08, 2005 at 12:26:43AM +1030, Mark Smith wrote: > > I think i got it finally .. > > > Indeed, we are in full agreement. The idea is to have the ability to fully > > firewall and monitor a machine that absolutely needs to have a real > > routable IP address, without wasting an IP address for the router (or trying > > to get an ISP to assign you multiple addresses, which can be a major chore > > these days). > > > > I'd settle for a 'dirty' solution. Remco van Mook of Virtu.nl suggested > > abusing iptables -j QUEUE combind with tun/tap to inject the packets on the > > ethernet side, where userspace does the PPP -> ethernet conversion by making > > up the required headers. > > A while back I was playing a bit with policy forwarding/routing, specifically trying to get traffic for a local address to travel "outside" the machine that it was assigned to, rather than short circuiting internal to the host. All I did was move the default rule for matching local addresses from 0 within the 64K priority list to the middle of it, ie 16383. This allowed me to insert policy forwarding rules for local addresses before the local address match. I was then able to push traffic for local addresses out the ethernet interface. When it returned, I then had a policy rule that matched incoming traffic against the local address table. It seems to me that the biggest issue with this "transparent firewall / ppp proxy" scenario is getting the Linux box to ignore what thinks to be is a local IP adress, and throw it at its forwarding table instead. What I did allows this to be overridden using policy forwarding. I'm not sure about how layer 3 firewalling would work, however I'd guess that since the packet is being forwarded, it would be matched against any iptables FORWARD rules. I went into some detail as to how it worked and how I set it up in the following post. : http://oss.sgi.com/archives/netdev/2004-06/msg00536.html Alexey gave some feedback suggesting that doing what I was doing would cause some inconsistencies in other areas of the kernel networking stack sadly. Maybe if there is a more common use for this sort of ability, eg this scenario, worth putting the effort into "fixing" those other areas. Unfortunately I don't know enough about kernel programming, and I'm a bit rusty on C, such that I couldn't pursue these other areas myself. Regards, Mark. -- The Internet's nature is peer to peer. From tgraf@suug.ch Mon Mar 7 17:37:02 2005 Received: with ECARTIS (v1.0.0; list netdev); Mon, 07 Mar 2005 17:37:06 -0800 (PST) Received: from b.mx.projectdream.org (eth0-0.arisu.projectdream.org [194.158.4.191]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j281b1fi002359 for ; Mon, 7 Mar 2005 17:37:02 -0800 Received: from postel.suug.ch (postel.suug.ch [195.134.158.23]) (using TLSv1 with cipher EDH-RSA-DES-CBC3-SHA (168/168 bits)) (No client certificate requested) by b.mx.projectdream.org (Postfix) with ESMTP id 6FF6F82; Tue, 8 Mar 2005 02:36:37 +0100 (CET) Received: by postel.suug.ch (Postfix, from userid 10001) id 1F5BF1C0EB; Tue, 8 Mar 2005 02:37:19 +0100 (CET) Date: Tue, 8 Mar 2005 02:37:18 +0100 From: Thomas Graf To: jamal Cc: netdev@oss.sgi.com Subject: Re: [RFC] neighbour tables configuration via rtnetlink Message-ID: <20050308013718.GZ31837@postel.suug.ch> References: <20050305172257.GN31837@postel.suug.ch> <1110202499.1094.1371.camel@jzny.localdomain> <20050307142622.GT31837@postel.suug.ch> <1110240219.1044.83.camel@jzny.localdomain> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1110240219.1044.83.camel@jzny.localdomain> X-Virus-Scanned: ClamAV 0.83/751/Mon Mar 7 03:06:27 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 2632 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: tgraf@suug.ch Precedence: bulk X-list: netdev Content-Length: 2345 Lines: 51 * jamal <1110240219.1044.83.camel@jzny.localdomain> 2005-03-07 19:03 > On Mon, 2005-03-07 at 09:26, Thomas Graf wrote: > > Yes, I think so as well but I really want to avoid putting effort into it > > and then see it replaced with something else. I think Herbert once thought > > about moving some of the rtnetlink stuff into a separate family and > > restructuring the whole thing. Still plans there Herbert? > > You will still need to grab the rtnl - so probably not much value in > creating a new netlink proto. I think so too, still it was worth deploying my sensors scanning for possible changes to make sure the planned effort is worth it. :-> > Yes, i think you are on the right track as far as using xnl. And if you > do that endianness issues dont exist (since XML is ascii). I would > advice (like i have many times on this) to not invent a protocol - > reusing something like netconf is the best approach. My understanding of > netconf though is a little dissapointing in that it does not do events > in the current version they are working on. I think events are supposed > to come post version 1.0 of the protocol. Absolutely, I plan to be compatible to as many existing protocols as possible. The conceptual idea behind is to add another abstraction layer before that protocol and have XSLT do the transformation into those protocols. The path could look like this: (netlink) (API/daemon) (XSLT) Kernel -> libnl -> libnl_XML -> netconf I left out the byte order issues here because I'm not yet sure how to solve them although as stated already, using XSLT would be one possible path to follow. > I believe there is a open source project which does netconf already; > maybe all they need is just your library and xml interface ... I will > look it up and send you some pointers. You probably mean Yenca, I'm looking into it but it uses ioctl for configuration and only implements a small subset of the functionality. I've CC'ed Benjamin Zores which is stated as the author in the source files. > BTW, what happened in the discussion with the gent who was doing SOAP > (or was going to do SOAP?) The discussion somewhat stalled but I didn't forget about it. Having the above architecture would allow to simply put the XML based architecture indepedant change requests into SOAP envelopes and distribute them. From rick.jones2@hp.com Mon Mar 7 18:43:06 2005 Received: with ECARTIS (v1.0.0; list netdev); Mon, 07 Mar 2005 18:43:11 -0800 (PST) Received: from palrel10.hp.com (palrel10.hp.com [156.153.255.245]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j282h3xm004769 for ; Mon, 7 Mar 2005 18:43:05 -0800 Received: from tardy.cup.hp.com (tardy.cup.hp.com [15.244.44.58]) by palrel10.hp.com (Postfix) with ESMTP id 44CA1619 for ; Mon, 7 Mar 2005 18:43:03 -0800 (PST) Received: from hp.com (localhost [127.0.0.1]) by tardy.cup.hp.com (8.9.3 (PHNE_28810)/8.9.3 SMKit7.02) with ESMTP id SAA21796 for ; Mon, 7 Mar 2005 18:43:02 -0800 (PST) Message-ID: <422D1136.3060601@hp.com> Date: Mon, 07 Mar 2005 18:43:02 -0800 From: Rick Jones User-Agent: Mozilla/5.0 (X11; U; HP-UX 9000/785; en-US; rv:1.6) Gecko/20040304 X-Accept-Language: en-us, en MIME-Version: 1.0 To: netdev@oss.sgi.com Subject: Data demonstrating the CPU overhead of ACKs Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV 0.83/751/Mon Mar 7 03:06:27 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 2633 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: rick.jones2@hp.com Precedence: bulk X-list: netdev Content-Length: 19554 Lines: 386 Folks - At some point in the not too distant past I believe I said I'd try to present some data on the CPU overhead of ACKs. I'm afraid it took me a triffle longer than I anticipated, with "other" things getting in the way and having to track-down some TSO-capable GbE NICs (the cores on the systems I have being based on BCM 5701's which IIRC the tg3 driver at least does not enable TSO on) Sooo.... The data below is from netperf TCP_STREAM tests (version 2.4.0alpha8 for the intensely curious). The kernel is a 2.6.11-rc5 kernel. This happens to be using one port of a dual-port Intel GbE NIC. Going from left to right we have the limit to the number of segments received before an ACK is emitted by the receiver (2, 3, 4, ... it was configurable, but could not be set to ack-every-segment - that is left as an extrapolation excercise for the reader) the remote's SO_RCVBUF (128KB), the local SO_SNDBUF (setsockopt of 128KB, getsockopt reporting 256KB), the size of the buffer in each send() call (32KB), the length of the test (10 seconds) the throughput in 10^6 bits per second, the local CPU utilization (this is a 2P system), the remote CPU utilization (-1 not measured), the local service demand (microseconds of CPU time to transfer a KB of data) and the remote service demand (-1 not measured) I took the numbers out a bit farther than one might just for grins. I did not do any process binding or enable the netperf confidence intervals so the data is going to be a little bit noisy. TSO disabled, netperf 128x32 TCP_STREAM: 2 131072 262144 32768 10.00 941.29 22.14 -1.00 3.853 -1.000 3 131072 262144 32768 10.00 941.26 20.05 -1.00 3.490 -1.000 4 131072 262144 32768 10.00 941.23 18.63 -1.00 3.243 -1.000 5 131072 262144 32768 10.00 941.22 18.21 -1.00 3.169 -1.000 6 131072 262144 32768 10.00 941.22 17.63 -1.00 3.069 -1.000 7 131072 262144 32768 10.00 941.15 17.33 -1.00 3.017 -1.000 8 131072 262144 32768 10.00 941.17 17.04 -1.00 2.966 -1.000 9 131072 262144 32768 10.00 941.04 17.06 -1.00 2.971 -1.000 10 131072 262144 32768 10.00 941.17 16.85 -1.00 2.934 -1.000 11 131072 262144 32768 10.00 940.90 16.71 -1.00 2.910 -1.000 12 131072 262144 32768 10.00 941.14 16.79 -1.00 2.923 -1.000 13 131072 262144 32768 10.00 941.03 16.12 -1.00 2.806 -1.000 14 131072 262144 32768 10.00 940.85 16.09 -1.00 2.802 -1.000 15 131072 262144 32768 10.00 941.01 16.09 -1.00 2.802 -1.000 16 131072 262144 32768 10.00 941.12 15.62 -1.00 2.719 -1.000 17 131072 262144 32768 10.00 941.08 15.87 -1.00 2.764 -1.000 18 131072 262144 32768 10.00 940.94 15.88 -1.00 2.764 -1.000 19 131072 262144 32768 10.00 940.80 15.95 -1.00 2.777 -1.000 20 131072 262144 32768 10.00 940.79 15.80 -1.00 2.752 -1.000 21 131072 262144 32768 10.00 940.90 15.90 -1.00 2.768 -1.000 22 131072 262144 32768 10.00 940.93 15.97 -1.00 2.780 -1.000 23 131072 262144 32768 10.00 941.07 15.43 -1.00 2.687 -1.000 24 131072 262144 32768 10.00 941.04 15.52 -1.00 2.702 -1.000 25 131072 262144 32768 10.00 941.05 16.36 -1.00 2.848 -1.000 26 131072 262144 32768 10.00 940.83 15.54 -1.00 2.706 -1.000 27 131072 262144 32768 10.00 940.88 15.05 -1.00 2.620 -1.000 28 131072 262144 32768 10.00 940.67 15.49 -1.00 2.698 -1.000 29 131072 262144 32768 10.00 940.68 15.53 -1.00 2.705 -1.000 30 131072 262144 32768 10.00 940.62 15.52 -1.00 2.704 -1.000 31 131072 262144 32768 10.00 940.76 15.70 -1.00 2.734 -1.000 32 131072 262144 32768 10.00 940.75 15.52 -1.00 2.703 -1.000 By the time ACKs are deferred for 8 segments rather than 2, the quantity of CPU per KB transfered has dropped from 3.853 usec/KB to 2.966 usec/KB, or ~23% (or if you prefer to look the other way, 2 segments per ACK takes ~30% more CPU than 8). By the time we are out to 16 segments, it has dropped to 2.719 or 29% less (or ~42% more looking the other way) Now, with TSO enabled and tcp_tso_win_divisor at its default of 8, still a 128x32 TCP_STREAM test: 2 131072 262144 32768 10.00 941.37 12.02 -1.00 2.092 -1.000 3 131072 262144 32768 10.00 941.35 10.78 -1.00 1.875 -1.000 4 131072 262144 32768 10.00 941.32 10.95 -1.00 1.906 -1.000 5 131072 262144 32768 10.00 941.33 8.35 -1.00 1.454 -1.000 6 131072 262144 32768 10.00 941.28 9.53 -1.00 1.659 -1.000 7 131072 262144 32768 10.00 941.34 7.75 -1.00 1.348 -1.000 8 131072 262144 32768 10.00 941.28 7.71 -1.00 1.342 -1.000 9 131072 262144 32768 10.00 941.19 7.58 -1.00 1.319 -1.000 10 131072 262144 32768 10.00 941.24 8.36 -1.00 1.456 -1.000 11 131072 262144 32768 10.00 941.18 6.09 -1.00 1.061 -1.000 12 131072 262144 32768 10.00 848.64 8.67 -1.00 1.674 -1.000 13 131072 262144 32768 10.00 941.20 5.82 -1.00 1.013 -1.000 14 131072 262144 32768 10.00 647.50 7.80 -1.00 1.974 -1.000 15 131072 262144 32768 10.00 885.04 9.04 -1.00 1.673 -1.000 16 131072 262144 32768 10.00 740.94 10.74 -1.00 2.375 -1.000 17 131072 262144 32768 10.00 941.12 5.58 -1.00 0.971 -1.000 18 131072 262144 32768 10.00 555.61 7.06 -1.00 2.082 -1.000 19 131072 262144 32768 10.00 941.13 5.46 -1.00 0.951 -1.000 20 131072 262144 32768 10.00 612.37 7.76 -1.00 2.075 -1.000 21 131072 262144 32768 10.00 771.96 7.70 -1.00 1.634 -1.000 22 131072 262144 32768 10.00 867.43 6.87 -1.00 1.297 -1.000 23 131072 262144 32768 10.00 797.88 6.78 -1.00 1.392 -1.000 24 131072 262144 32768 10.00 935.02 5.13 -1.00 0.899 -1.000 25 131072 262144 32768 10.00 735.36 6.03 -1.00 1.344 -1.000 26 131072 262144 32768 10.00 921.27 6.58 -1.00 1.171 -1.000 27 131072 262144 32768 10.00 792.32 6.26 -1.00 1.294 -1.000 28 131072 262144 32768 10.00 935.38 6.05 -1.00 1.060 -1.000 29 131072 262144 32768 10.00 845.99 6.71 -1.00 1.300 -1.000 30 131072 262144 32768 10.00 935.51 5.01 -1.00 0.878 -1.000 31 131072 262144 32768 10.00 751.12 6.30 -1.00 1.374 -1.000 32 131072 262144 32768 10.00 934.96 4.97 -1.00 0.870 -1.000 Here we see that going from 2 to 8 segments per ACK drops the service demand ~36% (~56% in the other direction) which is thirteen percentage points or ~>50% more than the delta for TSO off. At 16 segments per ACK we see what I will call a "throughput anomaly" :) This is what happens when the sender is not filling the congestion window. That leads to a delayed ACK in the reciever, which affects the throughput and it also causes the receiver to start to "re-estimate the sender's cwnd, starting IIRC with an immediate ACK and building-up its segments per ACK. If this happens "often enough" the receiver ends-up falling back on ack-every-other. Since there is the anomaly at 16 segments, I'll take the data from 17 segments, which shows that the service demand has decreased ~54% (or that service demand would increase by ~115% assuming I have done the math correctly). Now, if we set tcp_tso_win_divisor to 1 we get even more of those throughput anomalies but here is the data from segments per ACK == 2 2 131072 262144 32768 10.00 940.14 9.59 -1.00 1.671 -1.000 which shows service demand even lower than the default case, and I suspect that were the throughput anomalies not present a curve similar to those above would be seen. So, we can see that as sending has become more efficient, going from non-TSO to TSO, we have a greater percentage of the CPU time in the sender being consumed by ACK processing. If the changes coming in TSO manage to maintain the "keep the cwnd full" behaviour of TSO off things should be pretty nice. Naturally, the subject of burstiness will come-up. Related to that, the data below is a tcpdump trace of a netperf TCP_RR test over that same link "simulating" what one might see with a persistent HTTP connection asking for a 16KB "thing" from the server. Just to keep things simple and the tcpdumps easier to read, I've disabled TSO. 16K was pulled from the ether to demonstrate the point. With the Linux system as the server, trace from the server: (sorry about wrap) the port 12865 port stuff is the netperf control connection. You can ignore that. The port 32970 is the data connection. 000000 192.168.1.213.58582 > 192.168.1.212.12865: S 1870881128:1870881128(0) win 32768 (DF) 000005 192.168.1.212.12865 > 192.168.1.213.58582: S 3776130675:3776130675(0) ack 1870881129 win 5840 (DF) 000537 192.168.1.213.58582 > 192.168.1.212.12865: P 1:257(256) ack 1 win 32768 (DF) 000039 192.168.1.212.12865 > 192.168.1.213.58582: . ack 257 win 1728 (DF) 002299 192.168.1.212.12865 > 192.168.1.213.58582: P 1:257(256) ack 257 win 1728 (DF) 000169 192.168.1.213.58583 > 192.168.1.212.32970: S 1870933516:1870933516(0) win 32768 (DF) 000022 192.168.1.212.32970 > 192.168.1.213.58583: S 3760261556:3760261556(0) ack 1870933517 win 5840 (DF) 000219 192.168.1.213.58583 > 192.168.1.212.32970: P 1:129(128) ack 1 win 32768 (DF) the request arrives above and we see the usual slow-start stuff below, mised-in with the receiver learning the cwnd for its ACK avoidance: 000018 192.168.1.212.32970 > 192.168.1.213.58583: . ack 129 win 1460 (DF) 000060 192.168.1.212.32970 > 192.168.1.213.58583: . 1:1461(1460) ack 129 win 1460 (DF) 000019 192.168.1.212.32970 > 192.168.1.213.58583: . 1461:2921(1460) ack 129 win 1460 (DF) 000007 192.168.1.212.32970 > 192.168.1.213.58583: . 2921:4381(1460) ack 129 win 1460 (DF) 000146 192.168.1.213.58583 > 192.168.1.212.32970: . ack 1461 win 32768 (DF) 000017 192.168.1.212.32970 > 192.168.1.213.58583: . 4381:5841(1460) ack 129 win 1460 (DF) 000004 192.168.1.212.32970 > 192.168.1.213.58583: . 5841:7301(1460) ack 129 win 1460 (DF) 000004 192.168.1.213.58583 > 192.168.1.212.32970: . ack 4381 win 32768 (DF) 000006 192.168.1.212.32970 > 192.168.1.213.58583: . 7301:8761(1460) ack 129 win 1460 (DF) 000003 192.168.1.212.32970 > 192.168.1.213.58583: . 8761:10221(1460) ack 129 win 1460 (DF) 000003 192.168.1.212.32970 > 192.168.1.213.58583: . 10221:11681(1460) ack 129 win 1460 (DF) 000090 192.168.1.213.58583 > 192.168.1.212.32970: . ack 8761 win 32768 (DF) 000007 192.168.1.212.32970 > 192.168.1.213.58583: P 11681:13141(1460) ack 129 win 1460 (DF) 000017 192.168.1.212.32970 > 192.168.1.213.58583: . 13141:14601(1460) ack 129 win 1460 (DF) 000024 192.168.1.212.32970 > 192.168.1.213.58583: . 14601:16061(1460) ack 129 win 1460 (DF) 000015 192.168.1.212.32970 > 192.168.1.213.58583: P 16061:16385(324) ack 129 win 1460 (DF) 000064 192.168.1.213.58583 > 192.168.1.212.32970: . ack 14601 win 32768 (DF) There was the last of the 16KB response to the first request. Now we have the next request: 000121 192.168.1.213.58583 > 192.168.1.212.32970: P 129:257(128) ack 16385 win 32768 (DF) 000026 192.168.1.212.32970 > 192.168.1.213.58583: . 16385:17845(1460) ack 257 win 1460 (DF) 000010 192.168.1.212.32970 > 192.168.1.213.58583: . 17845:19305(1460) ack 257 win 1460 (DF) 000005 192.168.1.212.32970 > 192.168.1.213.58583: . 19305:20765(1460) ack 257 win 1460 (DF) 000006 192.168.1.212.32970 > 192.168.1.213.58583: . 20765:22225(1460) ack 257 win 1460 (DF) 000007 192.168.1.212.32970 > 192.168.1.213.58583: . 22225:23685(1460) ack 257 win 1460 (DF) 000018 192.168.1.212.32970 > 192.168.1.213.58583: . 23685:25145(1460) ack 257 win 1460 (DF) 000007 192.168.1.212.32970 > 192.168.1.213.58583: . 25145:26605(1460) ack 257 win 1460 (DF) Notice how a 7 segment burst was emitted by the sender. That same seven segment burst would have been emitted even if the receiver was doing ack-every-other. 000171 192.168.1.213.58583 > 192.168.1.212.32970: . ack 23685 win 32768 (DF) 000017 192.168.1.212.32970 > 192.168.1.213.58583: . 26605:28065(1460) ack 257 win 1460 (DF) 000013 192.168.1.212.32970 > 192.168.1.213.58583: . 28065:29525(1460) ack 257 win 1460 (DF) 000004 192.168.1.212.32970 > 192.168.1.213.58583: . 29525:30985(1460) ack 257 win 1460 (DF) 000004 192.168.1.212.32970 > 192.168.1.213.58583: . 30985:32445(1460) ack 257 win 1460 (DF) 000004 192.168.1.212.32970 > 192.168.1.213.58583: P 32445:32769(324) ack 257 win 1460 (DF) 000207 192.168.1.213.58583 > 192.168.1.212.32970: . ack 32445 win 32768 (DF) Finish that request, here comes #3. This time it is an 8 segment burst as the cwnd grows: 000009 192.168.1.213.58583 > 192.168.1.212.32970: P 257:385(128) ack 32769 win 32768 (DF) 000016 192.168.1.212.32970 > 192.168.1.213.58583: . 32769:34229(1460) ack 385 win 1460 (DF) 000011 192.168.1.212.32970 > 192.168.1.213.58583: . 34229:35689(1460) ack 385 win 1460 (DF) 000005 192.168.1.212.32970 > 192.168.1.213.58583: . 35689:37149(1460) ack 385 win 1460 (DF) 000006 192.168.1.212.32970 > 192.168.1.213.58583: . 37149:38609(1460) ack 385 win 1460 (DF) 000006 192.168.1.212.32970 > 192.168.1.213.58583: . 38609:40069(1460) ack 385 win 1460 (DF) 000024 192.168.1.212.32970 > 192.168.1.213.58583: . 40069:41529(1460) ack 385 win 1460 (DF) 000006 192.168.1.212.32970 > 192.168.1.213.58583: . 41529:42989(1460) ack 385 win 1460 (DF) 000008 192.168.1.212.32970 > 192.168.1.213.58583: . 42989:44449(1460) ack 385 win 1460 (DF) 000159 192.168.1.213.58583 > 192.168.1.212.32970: . ack 42989 win 32768 (DF) 000017 192.168.1.212.32970 > 192.168.1.213.58583: . 44449:45909(1460) ack 385 win 1460 (DF) 000013 192.168.1.212.32970 > 192.168.1.213.58583: . 45909:47369(1460) ack 385 win 1460 (DF) 000003 192.168.1.212.32970 > 192.168.1.213.58583: . 47369:48829(1460) ack 385 win 1460 (DF) 000004 192.168.1.212.32970 > 192.168.1.213.58583: P 48829:49153(324) ack 385 win 1460 (DF) And now this one is a 9 segment burst: 000213 192.168.1.213.58583 > 192.168.1.212.32970: P 385:513(128) ack 49153 win 32768 (DF) 000025 192.168.1.212.32970 > 192.168.1.213.58583: . 49153:50613(1460) ack 513 win 1460 (DF) 000014 192.168.1.212.32970 > 192.168.1.213.58583: . 50613:52073(1460) ack 513 win 1460 (DF) 000006 192.168.1.212.32970 > 192.168.1.213.58583: . 52073:53533(1460) ack 513 win 1460 (DF) 000006 192.168.1.212.32970 > 192.168.1.213.58583: . 53533:54993(1460) ack 513 win 1460 (DF) 000007 192.168.1.212.32970 > 192.168.1.213.58583: . 54993:56453(1460) ack 513 win 1460 (DF) 000023 192.168.1.212.32970 > 192.168.1.213.58583: . 56453:57913(1460) ack 513 win 1460 (DF) 000008 192.168.1.212.32970 > 192.168.1.213.58583: . 57913:59373(1460) ack 513 win 1460 (DF) 000015 192.168.1.212.32970 > 192.168.1.213.58583: . 59373:60833(1460) ack 513 win 1460 (DF) 000005 192.168.1.212.32970 > 192.168.1.213.58583: . 60833:62293(1460) ack 513 win 1460 (DF) 000141 192.168.1.213.58583 > 192.168.1.212.32970: . ack 60833 win 32768 (DF) 000022 192.168.1.212.32970 > 192.168.1.213.58583: . 62293:63753(1460) ack 513 win 1460 (DF) 000013 192.168.1.212.32970 > 192.168.1.213.58583: . 63753:65213(1460) ack 513 win 1460 (DF) 000004 192.168.1.212.32970 > 192.168.1.213.58583: P 65213:65537(324) ack 513 win 1460 (DF) Now, when the receiver is doing ack-every-other, starting with the second and third transactions to keep this from being heinously long... We still get a 6 segment burst onto the wire for the second transaction before the first ACK arives, and I suspect the sender was not stuck waiting for that ACK: 000003 192.168.1.213.58596 > 192.168.1.212.32971: P 129:257(128) ack 16385 win 32768 (DF) 000017 192.168.1.212.32971 > 192.168.1.213.58596: . 16385:17845(1460) ack 257 win 1460 (DF) 000011 192.168.1.212.32971 > 192.168.1.213.58596: . 17845:19305(1460) ack 257 win 1460 (DF) 000005 192.168.1.212.32971 > 192.168.1.213.58596: . 19305:20765(1460) ack 257 win 1460 (DF) 000007 192.168.1.212.32971 > 192.168.1.213.58596: . 20765:22225(1460) ack 257 win 1460 (DF) 000018 192.168.1.212.32971 > 192.168.1.213.58596: . 22225:23685(1460) ack 257 win 1460 (DF) 000006 192.168.1.212.32971 > 192.168.1.213.58596: . 23685:25145(1460) ack 257 win 1460 (DF) 000046 192.168.1.213.58596 > 192.168.1.212.32971: . ack 19305 win 32768 (DF) 000008 192.168.1.212.32971 > 192.168.1.213.58596: . 25145:26605(1460) ack 257 win 1460 (DF) 000004 192.168.1.212.32971 > 192.168.1.213.58596: . 26605:28065(1460) ack 257 win 1460 (DF) 000004 192.168.1.212.32971 > 192.168.1.213.58596: . 28065:29525(1460) ack 257 win 1460 (DF) 000105 192.168.1.213.58596 > 192.168.1.212.32971: . ack 22225 win 32768 (DF) 000007 192.168.1.212.32971 > 192.168.1.213.58596: P 29525:30985(1460) ack 257 win 1460 (DF) 000005 192.168.1.213.58596 > 192.168.1.212.32971: . ack 25145 win 32768 (DF) 000003 192.168.1.213.58596 > 192.168.1.212.32971: . ack 28065 win 32768 (DF) 000006 192.168.1.212.32971 > 192.168.1.213.58596: . 30985:32445(1460) ack 257 win 1460 (DF) 000007 192.168.1.212.32971 > 192.168.1.213.58596: P 32445:32769(324) ack 257 win 1460 (DF) 000099 192.168.1.213.58596 > 192.168.1.212.32971: . ack 30985 win 32768 (DF) And one instance of a twoACK "burst" arriving above. For transaction three, we see a 9 segment burst going-out and it may have simply been a matter of timing keeping it from being any larger in this trace: 000013 192.168.1.213.58596 > 192.168.1.212.32971: P 257:385(128) ack 32769 win 32768 (DF) 000014 192.168.1.212.32971 > 192.168.1.213.58596: . 32769:34229(1460) ack 385 win 1460 (DF) 000012 192.168.1.212.32971 > 192.168.1.213.58596: . 34229:35689(1460) ack 385 win 1460 (DF) 000006 192.168.1.212.32971 > 192.168.1.213.58596: . 35689:37149(1460) ack 385 win 1460 (DF) 000006 192.168.1.212.32971 > 192.168.1.213.58596: . 37149:38609(1460) ack 385 win 1460 (DF) 000006 192.168.1.212.32971 > 192.168.1.213.58596: . 38609:40069(1460) ack 385 win 1460 (DF) 000021 192.168.1.212.32971 > 192.168.1.213.58596: . 40069:41529(1460) ack 385 win 1460 (DF) 000015 192.168.1.212.32971 > 192.168.1.213.58596: . 41529:42989(1460) ack 385 win 1460 (DF) 000006 192.168.1.212.32971 > 192.168.1.213.58596: . 42989:44449(1460) ack 385 win 1460 (DF) 000011 192.168.1.212.32971 > 192.168.1.213.58596: . 44449:45909(1460) ack 385 win 1460 (DF) 000020 192.168.1.213.58596 > 192.168.1.212.32971: . ack 35689 win 32768 (DF) 000013 192.168.1.213.58596 > 192.168.1.212.32971: . ack 38609 win 32768 (DF) 000008 192.168.1.212.32971 > 192.168.1.213.58596: . 45909:47369(1460) ack 385 win 1460 (DF) 000005 192.168.1.212.32971 > 192.168.1.213.58596: . 47369:48829(1460) ack 385 win 1460 (DF) 000005 192.168.1.212.32971 > 192.168.1.213.58596: P 48829:49153(324) ack 385 win 1460 (DF) 000089 192.168.1.213.58596 > 192.168.1.212.32971: . ack 41529 win 32768 (DF) 000008 192.168.1.213.58596 > 192.168.1.212.32971: . ack 44449 win 32768 (DF) 000004 192.168.1.213.58596 > 192.168.1.212.32971: . ack 47369 win 32768 (DF) and we get a three ACK burst coming in. It gets burstier the longer we look in the trace. Had the systems been separated by longer pipes (I didn't take time to setup a delay simulator) and/or a greater number of transactions on the connection, the bursts of both data segments and ACKs would have been even greater for request/response traffic. My point? Basically this - that unless we require every user send to go through slow-start..., there will be bursty traffic - and traffic with bursts of a non-trivial number of segments. That behavour is happening today, and the network does not seem to have come to a crashing halt. And those bursts of ACKs aren't really doing us all that much good (modulo the contemporary requirement of cwnd growth per-ACK rather than per byte ACKed). Certainly they aren't causing data to be paced onto the network. Perhaps paradoxically, the burstiness of the arriving ACKs is actually reduced by an ACK avoiding reciever :) Anyhow, I hope this data is interesting, useful and thought provoking. I'm ready with my nomex :) and am sure I'll learn something from the responses. sincerely, rick jones From zdenek@rcn.com Mon Mar 7 19:18:06 2005 Received: with ECARTIS (v1.0.0; list netdev); Mon, 07 Mar 2005 19:18:10 -0800 (PST) Received: from smtp04.mrf.mail.rcn.net (smtp04.mrf.mail.rcn.net [207.172.4.63]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j283I3m7010448 for ; Mon, 7 Mar 2005 19:18:06 -0800 Received: from 209-150-50-115.c3-0.nwt-ubr3.sbo-nwt.ma.cable.rcn.com (HELO funex) (209.150.50.115) by smtp04.mrf.mail.rcn.net with SMTP; 07 Mar 2005 22:18:02 -0500 Message-Id: <3sp35g$7rsc1@smtp04.mrf.mail.rcn.net> X-IronPort-AV: i="3.90,145,1107752400"; d="scan'208"; a="8253825:sNHT21729456" X-Sender: zdenek@pop.rcn.com X-Mailer: QUALCOMM Windows Eudora Pro Version 4.0 Date: Mon, 07 Mar 2005 22:15:03 -0500 To: hadi@cyberus.ca, Steve Iribarne From: Zdenek Radouch Subject: Re: Do you know the TCP stack? (127.x.x.x routing) Cc: Eran Mann , Thomas Graf , Andi Kleen , Martin Mares , netdev@oss.sgi.com, linux-net@vger.kernel.org In-Reply-To: <1110239430.1043.71.camel@jzny.localdomain> References: <422C0B50.20500@mrv.com> <20050306173145.GQ31837@postel.suug.ch> <3sp35g$7hpm0@smtp04.mrf.mail.rcn.net> <422C0B50.20500@mrv.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" X-Virus-Scanned: ClamAV 0.83/751/Mon Mar 7 03:06:27 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 2634 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: zdenek@rcn.com Precedence: bulk X-list: netdev Content-Length: 1268 Lines: 37 At 06:50 PM 3/7/05 -0500, jamal wrote: >BTW, please cc netdev or myself if you are addressing me. This email was >just forwarde by someone else to me - I am not on linux-net. You seem to >have trimmed down the CC list. > >On Mon, 2005-03-07 at 18:02:18, Steve Iribarne wrote: >>-> >>-> What is so wrong with RFC198 addresses?? >>-> > >>Really RFC1918 you mean... > >Indeed 1918 > >>Well if your product is placed behind a nat'd network, MOST if not ALL >> nat'd network addresses on the "inside" use the RFC1918 address space. > >I read this a few times and still didnt get it: >Why is it that people using 1918 addresses are affecting you? RFC 1918 trivializes the IP addressing by boxing all hosts into either a "private" or "public" category, based on their need to access the Internet. The major thing the RFC misses is the fact that internal to one of these "public" or "private" hosts, you may have another, "even more private" network, for example one that connects the cards within the chassis. Such network must be (for obvious reasons) completely hidden from the outside, and thus cannot come from the "outside" address space. This "outside" space is a union of the "public" and "private" IP addresses. Guess what's left? How 'bout 127.0.0.0. -Z From kaber@trash.net Mon Mar 7 19:38:38 2005 Received: with ECARTIS (v1.0.0; list netdev); Mon, 07 Mar 2005 19:38:42 -0800 (PST) Received: from kaber.coreworks.de ([62.206.217.67]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j283cbhH011474 for ; Mon, 7 Mar 2005 19:38:38 -0800 Received: from localhost ([127.0.0.1]) by kaber.coreworks.de with esmtp (Exim 4.50) id 1D8VXy-00032q-6x; Tue, 08 Mar 2005 04:38:14 +0100 Message-ID: <422D1E26.1010902@trash.net> Date: Tue, 08 Mar 2005 04:38:14 +0100 From: Patrick McHardy User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.7.5) Gecko/20050106 Debian/1.7.5-1 X-Accept-Language: en MIME-Version: 1.0 To: hadi@cyberus.ca CC: Ben Greear , leo@yuriev.ru, Lennert Buytenhek , shemminger@osdl.org, netdev@oss.sgi.com Subject: Re: [leo@yuriev.ru: [PATCH] ethernet-bridge: update skb->priority in case forwarded frame has VLAN-header] References: <20050305141225.GA5180@xi.wantstofly.org> <4229D98F.9010008@trash.net> <422A0C21.3050709@candelatech.com> <1110199696.1094.1299.camel@jzny.localdomain> <1110238537.1043.62.camel@jzny.localdomain> <422CE983.7060305@trash.net> <1110241190.1043.100.camel@jzny.localdomain> In-Reply-To: <1110241190.1043.100.camel@jzny.localdomain> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV 0.83/751/Mon Mar 7 03:06:27 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 2635 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: kaber@trash.net Precedence: bulk X-list: netdev Content-Length: 825 Lines: 20 jamal wrote: > Indeed that looks bad. But wouldnt have helped if we started at 0 > either. You need monotonically increasing values to make proper > sense. So i suppose to do proper qos with L2, one must install the prio > qdisc and rewrite the priomap. One reason more to move it to an optional ebtables target. Or leave it all to prio + u32. But I guess a CLASSIFY target similar to iptables could also be useful otherwise. > The mapping used in pfifo_fast is derived from RFC1349 4 bit TOS which > is really considered toast these days. We need to revamp things - but > this would require some surgery in the route code as well (so maybe safe > to leave as is). Are there any changes required besides ip_tos2prio ? More importantly, it there a different meaningful mapping to priorities we can apply ? Regards Patrick From bennybbz@yahoo.fr Tue Mar 8 01:13:05 2005 Received: with ECARTIS (v1.0.0; list netdev); Tue, 08 Mar 2005 01:13:09 -0800 (PST) Received: from web26607.mail.ukl.yahoo.com (web26607.mail.ukl.yahoo.com [217.146.176.57]) by oss.sgi.com (8.13.0/8.13.0) with SMTP id j289D44K029423 for ; Tue, 8 Mar 2005 01:13:05 -0800 Received: (qmail 4720 invoked by uid 60001); 8 Mar 2005 09:12:58 -0000 Message-ID: <20050308091258.4718.qmail@web26607.mail.ukl.yahoo.com> Received: from [63.87.1.243] by web26607.mail.ukl.yahoo.com via HTTP; Tue, 08 Mar 2005 10:12:58 CET Date: Tue, 8 Mar 2005 10:12:58 +0100 (CET) From: BZ Benny Subject: more about ethertap To: netdev MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Virus-Scanned: ClamAV 0.83/751/Mon Mar 7 03:06:27 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 2637 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: bennybbz@yahoo.fr Precedence: bulk X-list: netdev Content-Length: 241 Lines: 15 Hi, Do you know how we could change the hardware adresse of an ethertap device? regards benny Découvrez le nouveau Yahoo! Mail : 250 Mo d'espace de stockage pour vos mails ! Créez votre Yahoo! Mail sur http://fr.mail.yahoo.com/ From acme@conectiva.com.br Tue Mar 8 01:49:44 2005 Received: with ECARTIS (v1.0.0; list netdev); Tue, 08 Mar 2005 01:49:48 -0800 (PST) Received: from orion.netbank.com.br (orion.netbank.com.br [200.203.199.90]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j289nfra030777 for ; Tue, 8 Mar 2005 01:49:44 -0800 Received: from [200.138.46.56] (helo=oops.ghostprotocols.net) by orion.netbank.com.br with asmtp (Exim 3.33 #1) id 1D8bKv-0001jz-00; Tue, 08 Mar 2005 06:49:09 -0300 Received: by oops.ghostprotocols.net (Postfix, from userid 500) id CABE3759DC; Tue, 8 Mar 2005 06:49:37 -0300 (BRT) Date: Tue, 8 Mar 2005 06:49:37 -0300 From: Arnaldo Carvalho de Melo To: marcel@holtmann.org, maxk@qualcomm.com, davem@davemloft.net Cc: netdev@oss.sgi.com Subject: [PATCH][BLUETOOTH] kill bt_sock_alloc Message-ID: <20050308094937.GA9468@conectiva.com.br> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline X-Url: http://advogato.org/person/acme User-Agent: Mutt/1.5.6i X-Virus-Scanned: ClamAV 0.83/751/Mon Mar 7 03:06:27 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 2638 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: acme@conectiva.com.br Precedence: bulk X-list: netdev Content-Length: 154 Lines: 10 Hi, Please take a look and if acceptable pull from: bk://kernel.bkbits.net/acme/connection_sock-2.6 Best Regards, - Arnaldo From acme@conectiva.com.br Tue Mar 8 01:52:12 2005 Received: with ECARTIS (v1.0.0; list netdev); Tue, 08 Mar 2005 01:52:20 -0800 (PST) Received: from orion.netbank.com.br (orion.netbank.com.br [200.203.199.90]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j289qBQc031226 for ; Tue, 8 Mar 2005 01:52:11 -0800 Received: from [200.138.46.56] (helo=oops.ghostprotocols.net) by orion.netbank.com.br with asmtp (Exim 3.33 #1) id 1D8bNN-0001kI-00; Tue, 08 Mar 2005 06:51:41 -0300 Received: by oops.ghostprotocols.net (Postfix, from userid 500) id A635F759E7; Tue, 8 Mar 2005 06:52:09 -0300 (BRT) Date: Tue, 8 Mar 2005 06:52:09 -0300 From: Arnaldo Carvalho de Melo To: marcel@holtmann.org, maxk@qualcomm.com, davem@davemloft.net Cc: netdev@oss.sgi.com Subject: Re: [PATCH][BLUETOOTH] kill bt_sock_alloc Message-ID: <20050308095209.GB9468@conectiva.com.br> References: <20050308094937.GA9468@conectiva.com.br> Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="XsQoSWH+UP9D9v3l" Content-Disposition: inline In-Reply-To: <20050308094937.GA9468@conectiva.com.br> X-Url: http://advogato.org/person/acme User-Agent: Mutt/1.5.6i X-Virus-Scanned: ClamAV 0.83/751/Mon Mar 7 03:06:27 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 2639 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: acme@conectiva.com.br Precedence: bulk X-list: netdev Content-Length: 10311 Lines: 350 --XsQoSWH+UP9D9v3l Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Em Tue, Mar 08, 2005 at 06:49:37AM -0300, Arnaldo Carvalho de Melo escreveu: > Hi, > > Please take a look and if acceptable pull from: > > bk://kernel.bkbits.net/acme/connection_sock-2.6 Sorry, now with the patch attached. - Arnaldo --XsQoSWH+UP9D9v3l Content-Type: text/plain; charset=us-ascii Content-Disposition: attachment; filename="bt_sock_alloc.patch" =================================================================== ChangeSet@1.1995, 2005-03-08 04:50:51-03:00, acme@toy.ghostprotocols.net [BLUETOOTH] kill bt_sock_alloc And make the derived socks have a struct bt_sock as its first member, so that the _pi() functions can just cast the struct sock pointer to its respective types, taking advantage of the fact that sk_alloc now use kmalloc when no slab is passed. This is another step, close to the final one, to kill sk_protinfo and make further planed channges possible. Signed-off-by: Arnaldo Carvalho de Melo Signed-off-by: David S. Miller include/net/bluetooth/bluetooth.h | 1 include/net/bluetooth/hci_core.h | 3 +- include/net/bluetooth/l2cap.h | 3 +- include/net/bluetooth/rfcomm.h | 3 +- include/net/bluetooth/sco.h | 3 +- net/bluetooth/af_bluetooth.c | 43 -------------------------------------- net/bluetooth/bnep/sock.c | 8 +++++-- net/bluetooth/hci_sock.c | 7 +++++- net/bluetooth/hidp/sock.c | 6 +++-- net/bluetooth/l2cap.c | 6 ++++- net/bluetooth/rfcomm/sock.c | 7 ++++-- net/bluetooth/sco.c | 7 +++++- 12 files changed, 40 insertions(+), 57 deletions(-) diff -Nru a/include/net/bluetooth/bluetooth.h b/include/net/bluetooth/bluetooth.h --- a/include/net/bluetooth/bluetooth.h 2005-03-08 06:44:10 -03:00 +++ b/include/net/bluetooth/bluetooth.h 2005-03-08 06:44:10 -03:00 @@ -125,7 +125,6 @@ int bt_sock_register(int proto, struct net_proto_family *ops); int bt_sock_unregister(int proto); -struct sock *bt_sock_alloc(struct socket *sock, int proto, int pi_size, int prio); void bt_sock_link(struct bt_sock_list *l, struct sock *s); void bt_sock_unlink(struct bt_sock_list *l, struct sock *s); int bt_sock_recvmsg(struct kiocb *iocb, struct socket *sock, struct msghdr *msg, size_t len, int flags); diff -Nru a/include/net/bluetooth/hci_core.h b/include/net/bluetooth/hci_core.h --- a/include/net/bluetooth/hci_core.h 2005-03-08 06:44:10 -03:00 +++ b/include/net/bluetooth/hci_core.h 2005-03-08 06:44:10 -03:00 @@ -595,8 +595,9 @@ void hci_send_to_sock(struct hci_dev *hdev, struct sk_buff *skb); /* HCI info for socket */ -#define hci_pi(sk) ((struct hci_pinfo *)sk->sk_protinfo) +#define hci_pi(sk) ((struct hci_pinfo *)sk) struct hci_pinfo { + struct bt_sock bt; struct hci_dev *hdev; struct hci_filter filter; __u32 cmsg_mask; diff -Nru a/include/net/bluetooth/l2cap.h b/include/net/bluetooth/l2cap.h --- a/include/net/bluetooth/l2cap.h 2005-03-08 06:44:10 -03:00 +++ b/include/net/bluetooth/l2cap.h 2005-03-08 06:44:10 -03:00 @@ -201,9 +201,10 @@ }; /* ----- L2CAP channel and socket info ----- */ -#define l2cap_pi(sk) ((struct l2cap_pinfo *)sk->sk_protinfo) +#define l2cap_pi(sk) ((struct l2cap_pinfo *)sk) struct l2cap_pinfo { + struct bt_sock bt; __u16 psm; __u16 dcid; __u16 scid; diff -Nru a/include/net/bluetooth/rfcomm.h b/include/net/bluetooth/rfcomm.h --- a/include/net/bluetooth/rfcomm.h 2005-03-08 06:44:10 -03:00 +++ b/include/net/bluetooth/rfcomm.h 2005-03-08 06:44:10 -03:00 @@ -293,9 +293,10 @@ #define RFCOMM_LM_RELIABLE 0x0010 #define RFCOMM_LM_SECURE 0x0020 -#define rfcomm_pi(sk) ((struct rfcomm_pinfo *)sk->sk_protinfo) +#define rfcomm_pi(sk) ((struct rfcomm_pinfo *)sk) struct rfcomm_pinfo { + struct bt_sock bt; struct rfcomm_dlc *dlc; u8 channel; u32 link_mode; diff -Nru a/include/net/bluetooth/sco.h b/include/net/bluetooth/sco.h --- a/include/net/bluetooth/sco.h 2005-03-08 06:44:10 -03:00 +++ b/include/net/bluetooth/sco.h 2005-03-08 06:44:10 -03:00 @@ -68,9 +68,10 @@ #define sco_conn_unlock(c) spin_unlock(&c->lock); /* ----- SCO socket info ----- */ -#define sco_pi(sk) ((struct sco_pinfo *)sk->sk_protinfo) +#define sco_pi(sk) ((struct sco_pinfo *)sk) struct sco_pinfo { + struct bt_sock bt; __u32 flags; struct sco_conn *conn; }; diff -Nru a/net/bluetooth/af_bluetooth.c b/net/bluetooth/af_bluetooth.c --- a/net/bluetooth/af_bluetooth.c 2005-03-08 06:44:10 -03:00 +++ b/net/bluetooth/af_bluetooth.c 2005-03-08 06:44:10 -03:00 @@ -60,8 +60,6 @@ #define BT_MAX_PROTO 8 static struct net_proto_family *bt_proto[BT_MAX_PROTO]; -static kmem_cache_t *bt_sock_cache; - int bt_sock_register(int proto, struct net_proto_family *ops) { if (proto >= BT_MAX_PROTO) @@ -108,36 +106,6 @@ return err; } -struct sock *bt_sock_alloc(struct socket *sock, int proto, int pi_size, int prio) -{ - struct sock *sk; - void *pi; - - sk = sk_alloc(PF_BLUETOOTH, prio, sizeof(struct bt_sock), bt_sock_cache); - if (!sk) - return NULL; - - if (pi_size) { - pi = kmalloc(pi_size, prio); - if (!pi) { - sk_free(sk); - return NULL; - } - memset(pi, 0, pi_size); - sk->sk_protinfo = pi; - } - - sock_init_data(sock, sk); - INIT_LIST_HEAD(&bt_sk(sk)->accept_q); - - sk->sk_zapped = 0; - sk->sk_protocol = proto; - sk->sk_state = BT_OPEN; - - return sk; -} -EXPORT_SYMBOL(bt_sock_alloc); - void bt_sock_link(struct bt_sock_list *l, struct sock *sk) { write_lock_bh(&l->lock); @@ -355,16 +323,6 @@ if (proc_bt) proc_bt->owner = THIS_MODULE; - /* Init socket cache */ - bt_sock_cache = kmem_cache_create("bt_sock", - sizeof(struct bt_sock), 0, - SLAB_HWCACHE_ALIGN, NULL, NULL); - - if (!bt_sock_cache) { - BT_ERR("Socket cache creation failed"); - return -ENOMEM; - } - sock_register(&bt_sock_family_ops); BT_INFO("HCI device and connection manager initialized"); @@ -383,7 +341,6 @@ bt_sysfs_cleanup(); sock_unregister(PF_BLUETOOTH); - kmem_cache_destroy(bt_sock_cache); remove_proc_entry("bluetooth", NULL); } diff -Nru a/net/bluetooth/bnep/sock.c b/net/bluetooth/bnep/sock.c --- a/net/bluetooth/bnep/sock.c 2005-03-08 06:44:10 -03:00 +++ b/net/bluetooth/bnep/sock.c 2005-03-08 06:44:10 -03:00 @@ -176,17 +176,21 @@ if (sock->type != SOCK_RAW) return -ESOCKTNOSUPPORT; - if (!(sk = bt_sock_alloc(sock, PF_BLUETOOTH, 0, GFP_KERNEL))) + if (!(sk = sk_alloc(PF_BLUETOOTH, GFP_KERNEL, sizeof(struct bt_sock), NULL))) return -ENOMEM; + sock_init_data(sock, sk); + INIT_LIST_HEAD(&bt_sk(sk)->accept_q); + sk_set_owner(sk, THIS_MODULE); sock->ops = &bnep_sock_ops; sock->state = SS_UNCONNECTED; - sk->sk_destruct = NULL; + sk->sk_zapped = 0; sk->sk_protocol = protocol; + sk->sk_state = BT_OPEN; return 0; } diff -Nru a/net/bluetooth/hci_sock.c b/net/bluetooth/hci_sock.c --- a/net/bluetooth/hci_sock.c 2005-03-08 06:44:10 -03:00 +++ b/net/bluetooth/hci_sock.c 2005-03-08 06:44:10 -03:00 @@ -601,9 +601,14 @@ sock->ops = &hci_sock_ops; - sk = bt_sock_alloc(sock, protocol, sizeof(struct hci_pinfo), GFP_KERNEL); + sk = sk_alloc(PF_BLUETOOTH, GFP_KERNEL, sizeof(struct hci_pinfo), NULL); if (!sk) return -ENOMEM; + + sock_init_data(sock, sk); + + sk->sk_zapped = 0; + sk->sk_protocol = protocol; sk_set_owner(sk, THIS_MODULE); diff -Nru a/net/bluetooth/hidp/sock.c b/net/bluetooth/hidp/sock.c --- a/net/bluetooth/hidp/sock.c 2005-03-08 06:44:10 -03:00 +++ b/net/bluetooth/hidp/sock.c 2005-03-08 06:44:10 -03:00 @@ -173,17 +173,19 @@ if (sock->type != SOCK_RAW) return -ESOCKTNOSUPPORT; - if (!(sk = bt_sock_alloc(sock, PF_BLUETOOTH, 0, GFP_KERNEL))) + if (!(sk = sk_alloc(PF_BLUETOOTH, GFP_KERNEL, sizeof(struct bt_sock), NULL))) return -ENOMEM; + sock_init_data(sock, sk); sk_set_owner(sk, THIS_MODULE); sock->ops = &hidp_sock_ops; sock->state = SS_UNCONNECTED; - sk->sk_destruct = NULL; sk->sk_protocol = protocol; + sk->sk_zapped = 0; + sk->sk_state = BT_OPEN; return 0; } diff -Nru a/net/bluetooth/l2cap.c b/net/bluetooth/l2cap.c --- a/net/bluetooth/l2cap.c 2005-03-08 06:44:10 -03:00 +++ b/net/bluetooth/l2cap.c 2005-03-08 06:44:10 -03:00 @@ -374,10 +374,13 @@ { struct sock *sk; - sk = bt_sock_alloc(sock, proto, sizeof(struct l2cap_pinfo), prio); + sk = sk_alloc(PF_BLUETOOTH, prio, sizeof(struct l2cap_pinfo), NULL); if (!sk) return NULL; + sock_init_data(sock, sk); + INIT_LIST_HEAD(&bt_sk(sk)->accept_q); + sk_set_owner(sk, THIS_MODULE); sk->sk_destruct = l2cap_sock_destruct; @@ -385,6 +388,7 @@ sk->sk_protocol = proto; sk->sk_state = BT_OPEN; + sk->sk_zapped = 0; l2cap_sock_init_timer(sk); diff -Nru a/net/bluetooth/rfcomm/sock.c b/net/bluetooth/rfcomm/sock.c --- a/net/bluetooth/rfcomm/sock.c 2005-03-08 06:44:10 -03:00 +++ b/net/bluetooth/rfcomm/sock.c 2005-03-08 06:44:10 -03:00 @@ -287,11 +287,13 @@ struct rfcomm_dlc *d; struct sock *sk; - sk = bt_sock_alloc(sock, BTPROTO_RFCOMM, sizeof(struct rfcomm_pinfo), prio); + sk = sk_alloc(PF_BLUETOOTH, prio, sizeof(struct rfcomm_pinfo), NULL); if (!sk) return NULL; + sock_init_data(sock, sk); sk_set_owner(sk, THIS_MODULE); + INIT_LIST_HEAD(&bt_sk(sk)->accept_q); d = rfcomm_dlc_alloc(prio); if (!d) { @@ -311,7 +313,8 @@ sk->sk_rcvbuf = RFCOMM_MAX_CREDITS * RFCOMM_DEFAULT_MTU * 10; sk->sk_protocol = proto; - sk->sk_state = BT_OPEN; + sk->sk_state = BT_OPEN; + sk->sk_zapped = 0; bt_sock_link(&rfcomm_sk_list, sk); diff -Nru a/net/bluetooth/sco.c b/net/bluetooth/sco.c --- a/net/bluetooth/sco.c 2005-03-08 06:44:10 -03:00 +++ b/net/bluetooth/sco.c 2005-03-08 06:44:10 -03:00 @@ -420,15 +420,20 @@ { struct sock *sk; - sk = bt_sock_alloc(sock, proto, sizeof(struct sco_pinfo), prio); + sk = sk_alloc(PF_BLUETOOTH, prio, sizeof(struct sco_pinfo), NULL); if (!sk) return NULL; + sock_init_data(sock, sk); + INIT_LIST_HEAD(&bt_sk(sk)->accept_q); + sk_set_owner(sk, THIS_MODULE); sk->sk_destruct = sco_sock_destruct; sk->sk_sndtimeo = SCO_CONN_TIMEOUT; sk->sk_state = BT_OPEN; + sk->sk_zapped = 0; + sk->sk_protocol = proto; sco_sock_init_timer(sk); --XsQoSWH+UP9D9v3l-- From herbert@gondor.apana.org.au Tue Mar 8 02:29:40 2005 Received: with ECARTIS (v1.0.0; list netdev); Tue, 08 Mar 2005 02:29:47 -0800 (PST) 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 j28ATc4J000743 for ; Tue, 8 Mar 2005 02:29:38 -0800 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 1D8bwx-0002Fg-00; Tue, 08 Mar 2005 21:28:27 +1100 Received: from herbert by gondolin.me.apana.org.au with local (Exim 3.36 #1 (Debian)) id 1D8bwE-00067a-00; Tue, 08 Mar 2005 21:27:42 +1100 Date: Tue, 8 Mar 2005 21:27:41 +1100 To: "David S. Miller" Cc: kuznet@ms2.inr.ac.ru, jmorris@redhat.com, yoshfuji@linux-ipv6.org, netdev@oss.sgi.com Subject: [11/*] [NET] Move dst_release out of dst->ops->check Message-ID: <20050308102741.GA23468@gondor.apana.org.au> References: <20050214221006.GA18415@gondor.apana.org.au> <20050214221200.GA18465@gondor.apana.org.au> <20050214221433.GB18465@gondor.apana.org.au> <20050214221607.GC18465@gondor.apana.org.au> <20050306213214.7d8a143d.davem@davemloft.net> <20050307103536.GB7137@gondor.apana.org.au> Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="IJpNTDwzlM2Ie8A6" Content-Disposition: inline In-Reply-To: <20050307103536.GB7137@gondor.apana.org.au> User-Agent: Mutt/1.5.6+20040907i From: Herbert Xu X-Virus-Scanned: ClamAV 0.83/751/Mon Mar 7 03:06:27 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 2640 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: herbert@gondor.apana.org.au Precedence: bulk X-list: netdev Content-Length: 3819 Lines: 132 --IJpNTDwzlM2Ie8A6 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline On Mon, Mar 07, 2005 at 09:35:36PM +1100, herbert wrote: > > Here's the patch to fix those two problems. Yes I know > my dst_check implementation is lame. I'll come back and > fix up all the dst_check functions by moving their dst_release > calls out. It proves that you were right in that IPv6 dst > leak thread :) As promised here is the patch that moves dst_release out of dst->ops->check. It bloats sk_dst_check/__sk_dst_check slightly but they're only used in a handful of places so it isn't too bad. I actually counted, it's about a few hundred bytes. 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 --IJpNTDwzlM2Ie8A6 Content-Type: text/plain; charset=us-ascii Content-Disposition: attachment; filename=xfrm-11 ===== include/net/dst.h 1.28 vs edited ===== --- 1.28/include/net/dst.h 2005-03-07 22:03:36 +11:00 +++ edited/include/net/dst.h 2005-03-08 21:04:46 +11:00 @@ -261,10 +261,8 @@ static inline struct dst_entry *dst_check(struct dst_entry *dst, u32 cookie) { - dst_hold(dst); if (dst->obsolete) dst = dst->ops->check(dst, cookie); - dst_release(dst); return dst; } ===== include/net/sock.h 1.90 vs edited ===== --- 1.90/include/net/sock.h 2005-01-11 07:23:55 +11:00 +++ edited/include/net/sock.h 2005-03-08 21:05:42 +11:00 @@ -983,6 +983,7 @@ if (dst && dst->obsolete && dst->ops->check(dst, cookie) == NULL) { sk->sk_dst_cache = NULL; + dst_release(dst); return NULL; } @@ -996,6 +997,7 @@ if (dst && dst->obsolete && dst->ops->check(dst, cookie) == NULL) { sk_dst_reset(sk); + dst_release(dst); return NULL; } ===== net/decnet/dn_route.c 1.31 vs edited ===== --- 1.31/net/decnet/dn_route.c 2005-01-14 16:03:01 +11:00 +++ edited/net/decnet/dn_route.c 2005-03-08 21:04:46 +11:00 @@ -253,7 +253,6 @@ */ static struct dst_entry *dn_dst_check(struct dst_entry *dst, __u32 cookie) { - dst_release(dst); return NULL; } ===== net/ipv4/route.c 1.104 vs edited ===== --- 1.104/net/ipv4/route.c 2005-03-06 15:43:44 +11:00 +++ edited/net/ipv4/route.c 2005-03-08 21:04:46 +11:00 @@ -1326,7 +1326,6 @@ static struct dst_entry *ipv4_dst_check(struct dst_entry *dst, u32 cookie) { - dst_release(dst); return NULL; } ===== net/ipv4/ipvs/ip_vs_xmit.c 1.11 vs edited ===== --- 1.11/net/ipv4/ipvs/ip_vs_xmit.c 2004-09-13 09:25:50 +10:00 +++ edited/net/ipv4/ipvs/ip_vs_xmit.c 2005-03-08 21:04:46 +11:00 @@ -52,6 +52,7 @@ if ((dst->obsolete || rtos != dest->dst_rtos) && dst->ops->check(dst, cookie) == NULL) { dest->dst_cache = NULL; + dst_release(dst); return NULL; } dst_hold(dst); ===== net/ipv6/ip6_tunnel.c 1.28 vs edited ===== --- 1.28/net/ipv6/ip6_tunnel.c 2005-02-07 16:40:51 +11:00 +++ edited/net/ipv6/ip6_tunnel.c 2005-03-08 21:04:47 +11:00 @@ -94,6 +94,7 @@ if (dst && dst->obsolete && dst->ops->check(dst, t->dst_cookie) == NULL) { t->dst_cache = NULL; + dst_release(dst); return NULL; } ===== net/ipv6/route.c 1.106 vs edited ===== --- 1.106/net/ipv6/route.c 2005-02-16 09:23:11 +11:00 +++ edited/net/ipv6/route.c 2005-03-08 21:04:47 +11:00 @@ -589,7 +589,6 @@ if (rt && rt->rt6i_node && (rt->rt6i_node->fn_sernum == cookie)) return dst; - dst_release(dst); return NULL; } ===== net/xfrm/xfrm_policy.c 1.71 vs edited ===== --- 1.71/net/xfrm/xfrm_policy.c 2005-03-07 22:03:36 +11:00 +++ edited/net/xfrm/xfrm_policy.c 2005-03-08 21:04:47 +11:00 @@ -1015,7 +1015,6 @@ if (!stale_bundle(dst)) return dst; - dst_release(dst); return NULL; } --IJpNTDwzlM2Ie8A6-- From yoshfuji@linux-ipv6.org Tue Mar 8 04:49:11 2005 Received: with ECARTIS (v1.0.0; list netdev); Tue, 08 Mar 2005 04:49:18 -0800 (PST) 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 j28CnAHM011086 for ; Tue, 8 Mar 2005 04:49:10 -0800 Received: from localhost (localhost [127.0.0.1]) by yue.st-paulia.net (Postfix) with ESMTP id EB93433CC2; Tue, 8 Mar 2005 21:50:46 +0900 (JST) Date: Tue, 08 Mar 2005 06:50:46 -0600 (CST) Message-Id: <20050308.065046.66114517.yoshfuji@linux-ipv6.org> To: herbert@gondor.apana.org.au Cc: davem@davemloft.net, kuznet@ms2.inr.ac.ru, jmorris@redhat.com, netdev@oss.sgi.com, yoshfuji@linux-ipv6.org Subject: Re: [11/*] [NET] Move dst_release out of dst->ops->check From: YOSHIFUJI Hideaki / =?iso-2022-jp?B?GyRCNUhGIzFRTEAbKEI=?= In-Reply-To: <20050308102741.GA23468@gondor.apana.org.au> References: <20050306213214.7d8a143d.davem@davemloft.net> <20050307103536.GB7137@gondor.apana.org.au> <20050308102741.GA23468@gondor.apana.org.au> Organization: USAGI Project X-URL: http://www.yoshifuji.org/%7Ehideaki/ X-Fingerprint: 9022 65EB 1ECF 3AD1 0BDF 80D8 4807 F894 E062 0EEA X-PGP-Key-URL: http://www.yoshifuji.org/%7Ehideaki/hideaki@yoshifuji.org.asc X-Face: "5$Al-.M>NJ%a'@hhZdQm:."qn~PA^gq4o*>iCFToq*bAi#4FRtx}enhuQKz7fNqQz\BYU] $~O_5m-9'}MIs`XGwIEscw;e5b>n"B_?j/AkL~i/MEaZBLP X-Mailer: Mew version 2.2 on Emacs 20.7 / Mule 4.1 (AOI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV 0.83/755/Mon Mar 7 17:00:18 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 2641 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: yoshfuji@linux-ipv6.org Precedence: bulk X-list: netdev Content-Length: 629 Lines: 16 In article <20050308102741.GA23468@gondor.apana.org.au> (at Tue, 8 Mar 2005 21:27:41 +1100), Herbert Xu says: > On Mon, Mar 07, 2005 at 09:35:36PM +1100, herbert wrote: > > > > Here's the patch to fix those two problems. Yes I know > > my dst_check implementation is lame. I'll come back and > > fix up all the dst_check functions by moving their dst_release > > calls out. It proves that you were right in that IPv6 dst > > leak thread :) > > As promised here is the patch that moves dst_release out of > dst->ops->check. It bloats sk_dst_check/__sk_dst_check slightly I agree. --yoshfuji From hadi@cyberus.ca Tue Mar 8 05:13:57 2005 Received: with ECARTIS (v1.0.0; list netdev); Tue, 08 Mar 2005 05:14:04 -0800 (PST) Received: from mx02.cybersurf.com (mx02.cybersurf.com [209.197.145.105]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j28DDuWZ012538 for ; Tue, 8 Mar 2005 05:13:57 -0800 Received: from mail.cyberus.ca ([209.197.145.21]) by mx02.cybersurf.com with esmtp (Exim 4.30) id 1D8eX2-00075N-Ol for netdev@oss.sgi.com; Tue, 08 Mar 2005 08:13:52 -0500 Received: from [24.103.99.32] (helo=[10.0.0.9]) by mail.cyberus.ca with esmtp (Exim 4.20) id 1D8eWz-0003zi-9P; Tue, 08 Mar 2005 08:13:49 -0500 Subject: Re: [leo@yuriev.ru: [PATCH] ethernet-bridge: update skb->priority in case forwarded frame has VLAN-header] From: jamal Reply-To: hadi@cyberus.ca To: Patrick McHardy Cc: Ben Greear , leo@yuriev.ru, Lennert Buytenhek , shemminger@osdl.org, netdev@oss.sgi.com In-Reply-To: <422D1E26.1010902@trash.net> References: <20050305141225.GA5180@xi.wantstofly.org> <4229D98F.9010008@trash.net> <422A0C21.3050709@candelatech.com> <1110199696.1094.1299.camel@jzny.localdomain> <1110238537.1043.62.camel@jzny.localdomain> <422CE983.7060305@trash.net> <1110241190.1043.100.camel@jzny.localdomain> <422D1E26.1010902@trash.net> Content-Type: text/plain Organization: jamalopolous Message-Id: <1110287626.1043.146.camel@jzny.localdomain> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.2.2 Date: 08 Mar 2005 08:13:47 -0500 Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV 0.83/755/Mon Mar 7 17:00:18 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 2642 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: hadi@cyberus.ca Precedence: bulk X-list: netdev Content-Length: 2092 Lines: 47 On Mon, 2005-03-07 at 22:38, Patrick McHardy wrote: > jamal wrote: > > Indeed that looks bad. But wouldnt have helped if we started at 0 > > either. You need monotonically increasing values to make proper > > sense. So i suppose to do proper qos with L2, one must install the prio > > qdisc and rewrite the priomap. > > One reason more to move it to an optional ebtables target. Or leave it > all to prio + u32. But I guess a CLASSIFY target similar to iptables > could also be useful otherwise. I think you still want (perhaps the vlan) driver to come up with some sane defaults. From what i read from bgrear he has arbitrary values. The only problem is we get conflicting goals with skb->priority between IEEE/IETF so you cant have them both interworking; I dont know what CLASSIFY target but a meta action on ingress of a device would easily set the skb->priority as well. So yes, if you want to have both L2 and L3, you will need something that overwrites the priority according to whatever the map is for one of them. Like i said earlier though you need to have some sane value being set in the vlan driver. > Are there any changes required besides ip_tos2prio ? Theres also the user space->kernel setsockopt semantics; Unfortunately just ridding of this is like killing an ABI interface, so it is untouchable. However, it may be time to introudce a new setsockopt to enable DSCP setting. ip_tos2prio is becoming less important if we are killing TOS routing (which Dave may have done a while back - i have to look); however, we can probably have a ip_dscp2prio or ip_prec2prio map. > More importantly, > it there a different meaningful mapping to priorities we can apply ? Well, old 4 bit TOS is really obsoleted - Look at RFC 2474. Two schools of thoughts exist on mappings - we oughta support both. One is the app controls these settings (MS is big on this approach). The other is network providers control the network and dont give a squat about what you set you values to be - we do that for example in qdiscs. I would say the second is more prelevant. cheers, jamal From ganesh.venkatesan@gmail.com Tue Mar 8 05:25:16 2005 Received: with ECARTIS (v1.0.0; list netdev); Tue, 08 Mar 2005 05:25:27 -0800 (PST) Received: from wproxy.gmail.com (wproxy.gmail.com [64.233.184.204]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j28DPFqS013349 for ; Tue, 8 Mar 2005 05:25:16 -0800 Received: by wproxy.gmail.com with SMTP id 68so1838405wra for ; Tue, 08 Mar 2005 05:25:10 -0800 (PST) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:reply-to:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:references; b=WOYMuFXs3MqVVt1Sod1XDASiaExdONPV5qI/DvWSCHIe119sIIjdckndX49+TISs0grI5skMKYAIFPW96cpgj5UaaqPYqR/I8hLxD6Cv1oKjfwEFy83VpGuHf+4ukd430bH92q3nMhkKmVKpoyPce/3OAL1AY+j6G5MqL2Ix1mY= Received: by 10.54.47.33 with SMTP id u33mr46353wru; Tue, 08 Mar 2005 05:24:41 -0800 (PST) Received: by 10.54.29.37 with HTTP; Tue, 8 Mar 2005 05:24:41 -0800 (PST) Message-ID: <5fc59ff305030805243de69624@mail.gmail.com> Date: Tue, 8 Mar 2005 05:24:41 -0800 From: Ganesh Venkatesan Reply-To: Ganesh Venkatesan To: "domen@coderock.org" Subject: Re: [patch 04/26] net/ixgb_osdep: replace schedule_timeout() with msleep() Cc: jgarzik@pobox.com, netdev@oss.sgi.com, nacc@us.ibm.com, janitor@sternwelten.at In-Reply-To: <20050306103248.7C3A21F1F0@trashy.coderock.org> Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit References: <20050306103248.7C3A21F1F0@trashy.coderock.org> X-Virus-Scanned: ClamAV 0.83/755/Mon Mar 7 17:00:18 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 2643 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: ganesh.venkatesan@gmail.com Precedence: bulk X-list: netdev Content-Length: 1800 Lines: 46 No. This would not work. You cannot replace msec_delay with msleep. You probably could replace the set_current_task/schedule_timeout with msleep. msleep does not check for the correct context, and if one were to call msec_delay from interrupt context, the kernel would panic. ganesh. On Sun, 06 Mar 2005 11:32:48 +0100, domen@coderock.org wrote: > > > Use msleep() instead of schedule_timeout() > to guarantee the task delays as expected. I was told earlier that the > in_interrupt() check is not necessary. It would be nice to get some > verification of this (i.e. the driver functions the same without it). > > Signed-off-by: Nishanth Aravamudan > Signed-off-by: Maximilian Attems > Signed-off-by: Domen Puncer > --- > > kj-domen/drivers/net/ixgb/ixgb_osdep.h | 8 +------- > 1 files changed, 1 insertion(+), 7 deletions(-) > > diff -puN drivers/net/ixgb/ixgb_osdep.h~msleep-drivers_net_ixgb_ixgb_osdep drivers/net/ixgb/ixgb_osdep.h > --- kj/drivers/net/ixgb/ixgb_osdep.h~msleep-drivers_net_ixgb_ixgb_osdep 2005-03-05 16:09:27.000000000 +0100 > +++ kj-domen/drivers/net/ixgb/ixgb_osdep.h 2005-03-05 16:09:27.000000000 +0100 > @@ -41,13 +41,7 @@ > #include > > #ifndef msec_delay > -#define msec_delay(x) do { if(in_interrupt()) { \ > - /* Don't mdelay in interrupt context! */ \ > - BUG(); \ > - } else { \ > - set_current_state(TASK_UNINTERRUPTIBLE); \ > - schedule_timeout((x * HZ)/1000 + 2); \ > - } } while(0) > +#define msec_delay(x) msleep(x) > #endif > > #define PCI_COMMAND_REGISTER PCI_COMMAND > _ > > From sebastian.ionita@focomunicatii.ro Tue Mar 8 05:32:54 2005 Received: with ECARTIS (v1.0.0; list netdev); Tue, 08 Mar 2005 05:32:57 -0800 (PST) Received: from focomunicatii.ro (ns.focomunicatii.ro [212.146.75.6]) by oss.sgi.com (8.13.0/8.13.0) with SMTP id j28DWoje014028 for ; Tue, 8 Mar 2005 05:32:53 -0800 Received: (qmail 31192 invoked by uid 89); 8 Mar 2005 13:30:36 -0000 Message-ID: <20050308133036.31190.qmail@focomunicatii.ro> From: sebastian.ionita@focomunicatii.ro To: netdev@oss.sgi.com Subject: NC320T Date: Tue, 08 Mar 2005 15:30:36 +0200 Mime-Version: 1.0 Content-Type: text/plain; format=flowed; charset="utf-8" Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV 0.83/755/Mon Mar 7 17:00:18 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 2644 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: sebastian.ionita@focomunicatii.ro Precedence: bulk X-list: netdev Content-Length: 249 Lines: 12 Does this network card NC320T works with the linux vlan module? Thankyou, Seby, ____________________________________________________________ SC. FO Comunicatii SRL. Sebastian Ionita Administrator Sistem mobil: 0724 212408 tel fix: 0264 450456 From hadi@cyberus.ca Tue Mar 8 05:34:51 2005 Received: with ECARTIS (v1.0.0; list netdev); Tue, 08 Mar 2005 05:34:54 -0800 (PST) Received: from mx03.cybersurf.com (mx03.cybersurf.com [209.197.145.106]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j28DYo63014443 for ; Tue, 8 Mar 2005 05:34:50 -0800 Received: from mail.cyberus.ca ([209.197.145.21]) by mx03.cybersurf.com with esmtp (Exim 4.30) id 1D8erH-0002zw-0T for netdev@oss.sgi.com; Tue, 08 Mar 2005 08:34:47 -0500 Received: from [24.103.99.32] (helo=[10.0.0.9]) by mail.cyberus.ca with esmtp (Exim 4.20) id 1D8erB-00071p-Fx; Tue, 08 Mar 2005 08:34:41 -0500 Subject: Re: Do you know the TCP stack? (127.x.x.x routing) From: jamal Reply-To: hadi@cyberus.ca To: Zdenek Radouch Cc: Steve Iribarne , Eran Mann , Thomas Graf , Andi Kleen , Martin Mares , netdev@oss.sgi.com, linux-net@vger.kernel.org In-Reply-To: <3sp35g$7rsc1@smtp04.mrf.mail.rcn.net> References: <422C0B50.20500@mrv.com> <20050306173145.GQ31837@postel.suug.ch> <3sp35g$7hpm0@smtp04.mrf.mail.rcn.net> <422C0B50.20500@mrv.com> <3sp35g$7rsc1@smtp04.mrf.mail.rcn.net> Content-Type: text/plain Organization: jamalopolous Message-Id: <1110288879.1050.167.camel@jzny.localdomain> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.2.2 Date: 08 Mar 2005 08:34:39 -0500 Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV 0.83/755/Mon Mar 7 17:00:18 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 2645 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: hadi@cyberus.ca Precedence: bulk X-list: netdev Content-Length: 2061 Lines: 54 PS:- anyone not copying me in the responses while addressing me - i didnt see your response. On Mon, 2005-03-07 at 22:15, Zdenek Radouch wrote: > RFC 1918 trivializes the IP addressing by boxing > all hosts into either a "private" or "public" category, > based on their need to access the Internet. > sure. And the semantics are: dont route "private" addresses if they stray on the "public network". In other words, it is left to the network setup to resolve this. > The major thing the RFC misses is the fact that internal > to one of these "public" or "private" hosts, you may have > another, "even more private" network, for example one > that connects the cards within the chassis. But why is this more "even more private"? Surely you can use 10.x addresses just fine within a chasis. Just make sure the packets dont leak out (if thats what you so desire). i.e set your routing properly. Nothing makes 127.x addresses not usable in NATs or not be routable once you start attching them to non-hostlocal interfaces. > Such network > must be (for obvious reasons) completely hidden > from the outside, and thus cannot come from the > "outside" address space. This "outside" space is a union > of the "public" and "private" IP addresses. > Guess what's left? How 'bout 127.0.0.0. > Lets see, your requirements are: a) packets within a chasis subnet shall stay within a chasis subnet b) the outside (of the chasis) world shall never discover whats inside the chasis (example ARPs will fail to resolve etc) Did i miss anything else? Seems to me you are relying on obscurity of 127.x to achieve goals which you could achieve just as easily with a 10.x address or even a public address. Is this correct? In otherwords it doesnt matter what addresses you use for internal chassis. What matters is how you set the route tables etc. I respect your desire to use whatever address range, but show me one think i couldnt do with a 10.x in the chasis that you can now achieve with a 127.x .. I think this will bring some clarity for me. cheers, jamal From mj+f-080305+netdev=oss.sgi.com@ucw.cz Tue Mar 8 05:51:39 2005 Received: with ECARTIS (v1.0.0; list netdev); Tue, 08 Mar 2005 05:51:44 -0800 (PST) Received: from atrey.karlin.mff.cuni.cz (postfix@atrey.karlin.mff.cuni.cz [195.113.31.123]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j28Dpc42022889 for ; Tue, 8 Mar 2005 05:51:39 -0800 Received: by atrey.karlin.mff.cuni.cz (Postfix, from userid 1000) id C07184B43B5; Tue, 8 Mar 2005 14:51:34 +0100 (CET) Date: Tue, 8 Mar 2005 14:51:34 +0100 From: Martin Mares To: jamal Cc: Zdenek Radouch , Steve Iribarne , Eran Mann , Thomas Graf , Andi Kleen , netdev@oss.sgi.com, linux-net@vger.kernel.org Subject: Re: Do you know the TCP stack? (127.x.x.x routing) Message-ID: <20050308135134.GA20607@atrey.karlin.mff.cuni.cz> References: <20050306173145.GQ31837@postel.suug.ch> <3sp35g$7hpm0@smtp04.mrf.mail.rcn.net> <422C0B50.20500@mrv.com> <3sp35g$7rsc1@smtp04.mrf.mail.rcn.net> <1110288879.1050.167.camel@jzny.localdomain> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1110288879.1050.167.camel@jzny.localdomain> User-Agent: Mutt/1.5.6+20040907i X-Virus-Scanned: ClamAV 0.83/755/Mon Mar 7 17:00:18 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 2646 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: mj@ucw.cz Precedence: bulk X-list: netdev Content-Length: 487 Lines: 13 Hello! > Seems to me you are relying on obscurity of 127.x to achieve goals which > you could achieve just as easily with a 10.x address or even a public > address. Using the same public block in all devices looks like the best solution. Have a nice fortnight -- Martin `MJ' Mares http://atrey.karlin.mff.cuni.cz/~mj/ Faculty of Math and Physics, Charles University, Prague, Czech Rep., Earth "Object orientation is in the mind, not in the compiler." -- Alan Cox From hadi@cyberus.ca Tue Mar 8 05:54:24 2005 Received: with ECARTIS (v1.0.0; list netdev); Tue, 08 Mar 2005 05:54:28 -0800 (PST) Received: from mx02.cybersurf.com (mx02.cybersurf.com [209.197.145.105]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j28DsNRf023344 for ; Tue, 8 Mar 2005 05:54:23 -0800 Received: from mail.cyberus.ca ([209.197.145.21]) by mx02.cybersurf.com with esmtp (Exim 4.30) id 1D8fAB-0007zF-El for netdev@oss.sgi.com; Tue, 08 Mar 2005 08:54:19 -0500 Received: from [24.103.99.32] (helo=[10.0.0.9]) by mail.cyberus.ca with esmtp (Exim 4.20) id 1D8fA9-0001CS-Hp; Tue, 08 Mar 2005 08:54:17 -0500 Subject: Re: [RFC] neighbour tables configuration via rtnetlink From: jamal Reply-To: hadi@cyberus.ca To: Thomas Graf Cc: netdev@oss.sgi.com In-Reply-To: <20050308013718.GZ31837@postel.suug.ch> References: <20050305172257.GN31837@postel.suug.ch> <1110202499.1094.1371.camel@jzny.localdomain> <20050307142622.GT31837@postel.suug.ch> <1110240219.1044.83.camel@jzny.localdomain> <20050308013718.GZ31837@postel.suug.ch> Content-Type: text/plain Organization: jamalopolous Message-Id: <1110290055.1043.183.camel@jzny.localdomain> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.2.2 Date: 08 Mar 2005 08:54:15 -0500 Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV 0.83/755/Mon Mar 7 17:00:18 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 2647 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: hadi@cyberus.ca Precedence: bulk X-list: netdev Content-Length: 2808 Lines: 78 On Mon, 2005-03-07 at 20:37, Thomas Graf wrote: > * jamal <1110240219.1044.83.camel@jzny.localdomain> 2005-03-07 19:03 [..] > Absolutely, I plan to be compatible to as many existing protocols as > possible. The conceptual idea behind is to add another abstraction > layer before that protocol and have XSLT do the transformation into > those protocols. > > The path could look like this: > > (netlink) (API/daemon) (XSLT) > Kernel -> libnl -> libnl_XML -> netconf > That or you could have netconf just call libnl_something else (which i have been trying to emphasize as the "the layer above libnl"). What you have above will work fine and i very flexible for netconf and maybe even for SOAP like activities but will end running in a shell which at some point will become a bottleneck. > I left out the byte order issues here because I'm not yet sure how > to solve them although as stated already, using XSLT would be one > possible path to follow. > There is no byte order issues with ASCII. > > I believe there is a open source project which does netconf already; > > maybe all they need is just your library and xml interface ... I will > > look it up and send you some pointers. > > You probably mean Yenca, Aha, yes - thats the one i saw. > I'm looking into it but it uses ioctl for > configuration and only implements a small subset of the functionality. Yes, i remember that code now. They do use ioctls. Unfortunately your libnl is not backward compatible and a lot of embedded devices are 2.4.x based. Ive mentioned this before. You need to provide a ioctl interface for some things as well and perhaps provide a compile flag to select between the two. On completion, I thin they had some basic stuff working which is a good start (If i recall they could set ip addresses and routes). The architecture seemed pretty sane to me; the whole was in the access to the kernel configuration - they did something but it appeared weak. This is where you could help i think. > I've CC'ed Benjamin Zores which is stated as the author in the source > files. > > > BTW, what happened in the discussion with the gent who was doing SOAP > > (or was going to do SOAP?) > > The discussion somewhat stalled but I didn't forget about it. Having > the above architecture would allow to simply put the XML based > architecture indepedant change requests into SOAP envelopes and distribute > them. > Well, the way i see it is like this: 3rdlayer: netconf/someotherapp secondlayer: "the layer above libnl" firstlayer: libnl (netlink level) layer0: kernel second layer is where that gents code would have been a good fit. He was already providing some good APIs, bindings etc. XML could be just one more binding. The problem is i think you are trying to do all layers. cheers, jamal From hadi@cyberus.ca Tue Mar 8 05:58:30 2005 Received: with ECARTIS (v1.0.0; list netdev); Tue, 08 Mar 2005 05:58:34 -0800 (PST) Received: from mx03.cybersurf.com (mx03.cybersurf.com [209.197.145.106]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j28DwTmS026118 for ; Tue, 8 Mar 2005 05:58:29 -0800 Received: from mail.cyberus.ca ([209.197.145.21]) by mx03.cybersurf.com with esmtp (Exim 4.30) id 1D8fEA-0005p4-G2 for netdev@oss.sgi.com; Tue, 08 Mar 2005 08:58:26 -0500 Received: from [24.103.99.32] (helo=[10.0.0.9]) by mail.cyberus.ca with esmtp (Exim 4.20) id 1D8fE6-0001jV-ST; Tue, 08 Mar 2005 08:58:23 -0500 Subject: Re: Do you know the TCP stack? (127.x.x.x routing) From: jamal Reply-To: hadi@cyberus.ca To: Martin Mares Cc: Zdenek Radouch , Steve Iribarne , Eran Mann , Thomas Graf , Andi Kleen , netdev@oss.sgi.com, linux-net@vger.kernel.org In-Reply-To: <20050308135134.GA20607@atrey.karlin.mff.cuni.cz> References: <20050306173145.GQ31837@postel.suug.ch> <3sp35g$7hpm0@smtp04.mrf.mail.rcn.net> <422C0B50.20500@mrv.com> <3sp35g$7rsc1@smtp04.mrf.mail.rcn.net> <1110288879.1050.167.camel@jzny.localdomain> <20050308135134.GA20607@atrey.karlin.mff.cuni.cz> Content-Type: text/plain Organization: jamalopolous Message-Id: <1110290300.1050.190.camel@jzny.localdomain> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.2.2 Date: 08 Mar 2005 08:58:20 -0500 Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV 0.83/755/Mon Mar 7 17:00:18 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 2648 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: hadi@cyberus.ca Precedence: bulk X-list: netdev Content-Length: 491 Lines: 18 On Tue, 2005-03-08 at 08:51, Martin Mares wrote: > Hello! > > > Seems to me you are relying on obscurity of 127.x to achieve goals which > > you could achieve just as easily with a 10.x address or even a public > > address. > > Using the same public block in all devices looks like the best solution. > People tend to use private blocks in a chasis (unique IP for each blade) - which by default are not routed outside the chasis. I have a feeling this is what you meant cheers, jamal From tgraf@suug.ch Tue Mar 8 06:02:40 2005 Received: with ECARTIS (v1.0.0; list netdev); Tue, 08 Mar 2005 06:02:44 -0800 (PST) Received: from b.mx.projectdream.org (eth0-0.arisu.projectdream.org [194.158.4.191]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j28E2cOs028803 for ; Tue, 8 Mar 2005 06:02:39 -0800 Received: from postel.suug.ch (postel.suug.ch [195.134.158.23]) (using TLSv1 with cipher EDH-RSA-DES-CBC3-SHA (168/168 bits)) (No client certificate requested) by b.mx.projectdream.org (Postfix) with ESMTP id 9CE2384; Tue, 8 Mar 2005 15:02:11 +0100 (CET) Received: by postel.suug.ch (Postfix, from userid 10001) id 415691C0EA; Tue, 8 Mar 2005 15:02:54 +0100 (CET) Date: Tue, 8 Mar 2005 15:02:54 +0100 From: Thomas Graf To: Zdenek Radouch Cc: hadi@cyberus.ca, Steve Iribarne , Eran Mann , Andi Kleen , Martin Mares , netdev@oss.sgi.com, linux-net@vger.kernel.org Subject: Re: Do you know the TCP stack? (127.x.x.x routing) Message-ID: <20050308140254.GA31837@postel.suug.ch> References: <20050306173145.GQ31837@postel.suug.ch> <3sp35g$7hpm0@smtp04.mrf.mail.rcn.net> <422C0B50.20500@mrv.com> <3sp35g$7rsc1@smtp04.mrf.mail.rcn.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <3sp35g$7rsc1@smtp04.mrf.mail.rcn.net> X-Virus-Scanned: ClamAV 0.83/755/Mon Mar 7 17:00:18 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 2649 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: tgraf@suug.ch Precedence: bulk X-list: netdev Content-Length: 2004 Lines: 39 * Zdenek Radouch <3sp35g$7rsc1@smtp04.mrf.mail.rcn.net> 2005-03-07 22:15 > The major thing the RFC misses is the fact that internal > to one of these "public" or "private" hosts, you may have > another, "even more private" network, for example one > that connects the cards within the chassis. Such network > must be (for obvious reasons) completely hidden > from the outside, and thus cannot come from the > "outside" address space. This "outside" space is a union > of the "public" and "private" IP addresses. > Guess what's left? How 'bout 127.0.0.0. RFC 1918 is in no way related to 127/8, it simply suggest various address spaces considered private and the fact that its status is only best practice makes it obvious that it has open issues such as merging conflicts so I'm not quite sure if I understand what you mean. I think we all agree that having 127/8 fully routeable in the local table would be a good thing although I haven't seen any use for it. There are two major problems involved though: The kernel must know about its own local address for ARP, routing and various other reasons. This isn't a problem because it could simply look up the route but sometimes there is not enough information to do a full route lookup. This issue can be resolved with some effort though. It would get easier if policy routing is ignored for this purpose. Userspace must be told about the address and prefix of the loopback which is done via the LOOPBACK() macro. Extracting parts of the address field is not a problem if userspace is recompiled but making it dynamically is. It would mean to change all userspace applications relying on LOOPBACK() to either use netlink or ioctl. Given this issue has been resolved there it is still likely that certain userspace applications do not use LOOPBACK() and simply rely on the fact that 127/8 has a host scope and is _always_ looped back. Problem #2 can probably be ignored in some cases and left to the operator to resolve. From mj+f-080305+netdev=oss.sgi.com@ucw.cz Tue Mar 8 06:03:01 2005 Received: with ECARTIS (v1.0.0; list netdev); Tue, 08 Mar 2005 06:03:07 -0800 (PST) Received: from atrey.karlin.mff.cuni.cz (postfix@atrey.karlin.mff.cuni.cz [195.113.31.123]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j28E30po028935 for ; Tue, 8 Mar 2005 06:03:01 -0800 Received: by atrey.karlin.mff.cuni.cz (Postfix, from userid 1000) id EA92C4B40BD; Tue, 8 Mar 2005 15:03:01 +0100 (CET) Date: Tue, 8 Mar 2005 15:03:01 +0100 From: Martin Mares To: jamal Cc: Zdenek Radouch , Steve Iribarne , Eran Mann , Thomas Graf , Andi Kleen , netdev@oss.sgi.com, linux-net@vger.kernel.org Subject: Re: Do you know the TCP stack? (127.x.x.x routing) Message-ID: <20050308140301.GC20607@atrey.karlin.mff.cuni.cz> References: <20050306173145.GQ31837@postel.suug.ch> <3sp35g$7hpm0@smtp04.mrf.mail.rcn.net> <422C0B50.20500@mrv.com> <3sp35g$7rsc1@smtp04.mrf.mail.rcn.net> <1110288879.1050.167.camel@jzny.localdomain> <20050308135134.GA20607@atrey.karlin.mff.cuni.cz> <1110290300.1050.190.camel@jzny.localdomain> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1110290300.1050.190.camel@jzny.localdomain> User-Agent: Mutt/1.5.6+20040907i X-Virus-Scanned: ClamAV 0.83/755/Mon Mar 7 17:00:18 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 2650 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: mj@ucw.cz Precedence: bulk X-list: netdev Content-Length: 897 Lines: 21 Hello! > People tend to use private blocks in a chasis (unique IP for each blade) > - which by default are not routed outside the chasis. > > I have a feeling this is what you meant No, since this tends to interfere with the outside network using the same private (RFC 1918) addresses. People generally don't expect network equipment to collide with their perfectly legal addressing plan. On the other hand, if the manufacturer gets a small block of public addresses and uses it in all his devices (the same block everywhere) for internal purposes only (no packet ever escapes), everything is perfectly correct and no collisions can arise. Have a nice fortnight -- Martin `MJ' Mares http://atrey.karlin.mff.cuni.cz/~mj/ Faculty of Math and Physics, Charles University, Prague, Czech Rep., Earth "Computers are useless. They can only give you answers." -- Pablo Picasso From hadi@cyberus.ca Tue Mar 8 06:10:31 2005 Received: with ECARTIS (v1.0.0; list netdev); Tue, 08 Mar 2005 06:10:36 -0800 (PST) Received: from mx02.cybersurf.com (mx02.cybersurf.com [209.197.145.105]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j28EAUAT030055 for ; Tue, 8 Mar 2005 06:10:30 -0800 Received: from mail.cyberus.ca ([209.197.145.21]) by mx02.cybersurf.com with esmtp (Exim 4.30) id 1D8fPm-0006W5-Ua for netdev@oss.sgi.com; Tue, 08 Mar 2005 09:10:26 -0500 Received: from [24.103.99.32] (helo=[10.0.0.9]) by mail.cyberus.ca with esmtp (Exim 4.20) id 1D8fPk-0003zd-Fz; Tue, 08 Mar 2005 09:10:24 -0500 Subject: Re: bridge between ppp and ethernet - 1 IP address and assign it to another host From: jamal Reply-To: hadi@cyberus.ca To: Mark Smith Cc: ahu@ds9a.nl, netdev@oss.sgi.com In-Reply-To: <20050308115734.544fcaca.random@72616e646f6d20323030342d30342d31360a.nosense.org> References: <20050306153108.20430b58.random@72616e646f6d20323030342d30342d31360a.nosense.org> <1110199198.1094.1282.camel@jzny.localdomain> <20050308002643.7eac84e7.random@72616e646f6d20323030342d30342d31360a.nosense.org> <20050307213211.GA25323@outpost.ds9a.nl> <1110238406.1043.57.camel@jzny.localdomain> <20050308115734.544fcaca.random@72616e646f6d20323030342d30342d31360a.nosense.org> Content-Type: text/plain Organization: jamalopolous Message-Id: <1110291022.1050.204.camel@jzny.localdomain> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.2.2 Date: 08 Mar 2005 09:10:22 -0500 Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV 0.83/755/Mon Mar 7 17:00:18 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 2651 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: hadi@cyberus.ca Precedence: bulk X-list: netdev Content-Length: 1799 Lines: 46 On Mon, 2005-03-07 at 20:27, Mark Smith wrote: > Hi Jamal, Bert, > > On 07 Mar 2005 18:33:26 -0500 > jamal wrote: > > > On Mon, 2005-03-07 at 16:32, bert hubert wrote: > > > On Tue, Mar 08, 2005 at 12:26:43AM +1030, Mark Smith wrote: > > > > I think i got it finally .. > > > > > Indeed, we are in full agreement. The idea is to have the ability to fully > > > firewall and monitor a machine that absolutely needs to have a real > > > routable IP address, without wasting an IP address for the router (or trying > > > to get an ISP to assign you multiple addresses, which can be a major chore > > > these days). > > > > > > I'd settle for a 'dirty' solution. Remco van Mook of Virtu.nl suggested > > > abusing iptables -j QUEUE combind with tun/tap to inject the packets on the > > > ethernet side, where userspace does the PPP -> ethernet conversion by making > > > up the required headers. > > > > > A while back I was playing a bit with policy forwarding/routing, > specifically trying to get traffic for a local address to travel > "outside" the machine that it was assigned to, rather than short > circuiting internal to the host. Yes, I remember that discussion ;-> Alexey wasnt very thrilled. [Ive deleted the rest of your text for brevity]. Note that the redirect at L2 overcomes the issues you were trying ot address in that email (and infact instead of redirecting you can also just "mirror")... So it seems if all you do is bridge and firewall and you never involve IP then you should be fine. So maybe the return path as well should have no IP involvment either and be L2 switched as well. I think what is needed is some experimenting with some windoz test clients, a ppp server and the middle proxy machine. Like i said i am willing to help. cheers, jamal From hadi@cyberus.ca Tue Mar 8 06:17:59 2005 Received: with ECARTIS (v1.0.0; list netdev); Tue, 08 Mar 2005 06:18:02 -0800 (PST) Received: from mx04.cybersurf.com (mx04.cybersurf.com [209.197.145.108]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j28EHwCw030726 for ; Tue, 8 Mar 2005 06:17:59 -0800 Received: from mail.cyberus.ca ([209.197.145.21]) by mx01.cybersurf.com with esmtp (Exim 4.30) id 1D8fX1-0003k0-GP for netdev@oss.sgi.com; Tue, 08 Mar 2005 09:17:55 -0500 Received: from [24.103.99.32] (helo=[10.0.0.9]) by mail.cyberus.ca with esmtp (Exim 4.20) id 1D8fWy-00057d-ME; Tue, 08 Mar 2005 09:17:52 -0500 Subject: Re: Do you know the TCP stack? (127.x.x.x routing) From: jamal Reply-To: hadi@cyberus.ca To: Martin Mares Cc: Zdenek Radouch , Steve Iribarne , Eran Mann , Thomas Graf , Andi Kleen , netdev@oss.sgi.com, linux-net@vger.kernel.org In-Reply-To: <20050308140301.GC20607@atrey.karlin.mff.cuni.cz> References: <20050306173145.GQ31837@postel.suug.ch> <3sp35g$7hpm0@smtp04.mrf.mail.rcn.net> <422C0B50.20500@mrv.com> <3sp35g$7rsc1@smtp04.mrf.mail.rcn.net> <1110288879.1050.167.camel@jzny.localdomain> <20050308135134.GA20607@atrey.karlin.mff.cuni.cz> <1110290300.1050.190.camel@jzny.localdomain> <20050308140301.GC20607@atrey.karlin.mff.cuni.cz> Content-Type: text/plain Organization: jamalopolous Message-Id: <1110291470.1043.211.camel@jzny.localdomain> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.2.2 Date: 08 Mar 2005 09:17:50 -0500 Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV 0.83/755/Mon Mar 7 17:00:18 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 2652 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: hadi@cyberus.ca Precedence: bulk X-list: netdev Content-Length: 942 Lines: 25 On Tue, 2005-03-08 at 09:03, Martin Mares wrote: > No, since this tends to interfere with the outside network using the > same private (RFC 1918) addresses. People generally don't expect network > equipment to collide with their perfectly legal addressing plan. > Aha! Thanks for clarifying this. So the problem domain is: "IP address conflict" detection and somehow this is seen as a resolution to that problem. So what happens when you put tow or three of Zdenek's boxes in one location? Back to square 1? > On the other hand, if the manufacturer gets a small block of public > addresses and uses it in all his devices (the same block everywhere) > for internal purposes only (no packet ever escapes), everything is > perfectly correct and no collisions can arise. Yes, I see. Except this wont be practical for IPV4 since those addresses are scarce. May make sense for V6 though (becomes like MAC addresses on NICS). cheers, jamal From mj+f-080305+netdev=oss.sgi.com@ucw.cz Tue Mar 8 06:20:22 2005 Received: with ECARTIS (v1.0.0; list netdev); Tue, 08 Mar 2005 06:20:27 -0800 (PST) Received: from atrey.karlin.mff.cuni.cz (postfix@atrey.karlin.mff.cuni.cz [195.113.31.123]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j28EKL9T031311 for ; Tue, 8 Mar 2005 06:20:22 -0800 Received: by atrey.karlin.mff.cuni.cz (Postfix, from userid 1000) id 766D34B4137; Tue, 8 Mar 2005 15:20:23 +0100 (CET) Date: Tue, 8 Mar 2005 15:20:23 +0100 From: Martin Mares To: jamal Cc: Zdenek Radouch , Steve Iribarne , Eran Mann , Thomas Graf , Andi Kleen , netdev@oss.sgi.com, linux-net@vger.kernel.org Subject: Re: Do you know the TCP stack? (127.x.x.x routing) Message-ID: <20050308142022.GG20607@atrey.karlin.mff.cuni.cz> References: <3sp35g$7hpm0@smtp04.mrf.mail.rcn.net> <422C0B50.20500@mrv.com> <3sp35g$7rsc1@smtp04.mrf.mail.rcn.net> <1110288879.1050.167.camel@jzny.localdomain> <20050308135134.GA20607@atrey.karlin.mff.cuni.cz> <1110290300.1050.190.camel@jzny.localdomain> <20050308140301.GC20607@atrey.karlin.mff.cuni.cz> <1110291470.1043.211.camel@jzny.localdomain> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1110291470.1043.211.camel@jzny.localdomain> User-Agent: Mutt/1.5.6+20040907i X-Virus-Scanned: ClamAV 0.83/755/Mon Mar 7 17:00:18 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 2653 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: mj@ucw.cz Precedence: bulk X-list: netdev Content-Length: 874 Lines: 25 Hello! > So what happens when you put tow or three of Zdenek's boxes in one > location? Back to square 1? No, if I understood Zdenek correctly, he wants to use the addresses only internally inside the box, so multiple boxes should happily co-exist. OTOH if the same address is used anywhere in the neighboring network, it's going to break. > Except this wont be practical for IPV4 since those addresses are scarce. If the addresses are going to be used only internally, it suffices to allocate only a small block of addresses and use this block for all devices. > May make sense for V6 though (becomes like MAC addresses on NICS). Sure. Have a nice fortnight -- Martin `MJ' Mares http://atrey.karlin.mff.cuni.cz/~mj/ Faculty of Math and Physics, Charles University, Prague, Czech Rep., Earth Mr. Worf, scan that ship." "Aye, Captain... 600 DPI? From tgraf@suug.ch Tue Mar 8 06:26:55 2005 Received: with ECARTIS (v1.0.0; list netdev); Tue, 08 Mar 2005 06:26:59 -0800 (PST) Received: from b.mx.projectdream.org (eth0-0.arisu.projectdream.org [194.158.4.191]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j28EQs44000338 for ; Tue, 8 Mar 2005 06:26:55 -0800 Received: from postel.suug.ch (postel.suug.ch [195.134.158.23]) (using TLSv1 with cipher EDH-RSA-DES-CBC3-SHA (168/168 bits)) (No client certificate requested) by b.mx.projectdream.org (Postfix) with ESMTP id CA1FE84; Tue, 8 Mar 2005 15:26:30 +0100 (CET) Received: by postel.suug.ch (Postfix, from userid 10001) id E7B2F1C0EA; Tue, 8 Mar 2005 15:27:13 +0100 (CET) Date: Tue, 8 Mar 2005 15:27:13 +0100 From: Thomas Graf To: jamal Cc: netdev@oss.sgi.com, benjamin.zores@loria.fr Subject: Re: [RFC] neighbour tables configuration via rtnetlink Message-ID: <20050308142713.GB31837@postel.suug.ch> References: <20050305172257.GN31837@postel.suug.ch> <1110202499.1094.1371.camel@jzny.localdomain> <20050307142622.GT31837@postel.suug.ch> <1110240219.1044.83.camel@jzny.localdomain> <20050308013718.GZ31837@postel.suug.ch> <1110290055.1043.183.camel@jzny.localdomain> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1110290055.1043.183.camel@jzny.localdomain> X-Virus-Scanned: ClamAV 0.83/755/Mon Mar 7 17:00:18 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 2654 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: tgraf@suug.ch Precedence: bulk X-list: netdev Content-Length: 4128 Lines: 94 * jamal <1110290055.1043.183.camel@jzny.localdomain> 2005-03-08 08:54 > On Mon, 2005-03-07 at 20:37, Thomas Graf wrote: > > [..] > > The path could look like this: > > > > (netlink) (API/daemon) (XSLT) > > Kernel -> libnl -> libnl_XML -> netconf > > > > That or you could have netconf just call libnl_something else (which i > have been trying to emphasize as the "the layer above libnl"). What you > have above will work fine and i very flexible for netconf and maybe even > for SOAP like activities but will end running in a shell which at some > point will become a bottleneck. Possibily yes, I'm not quite sure why it would involve a shell at least it is quite simple to work around using one but I tend to agree. What I'm aiming for is some kind of generic request record format acting as base for logging, distribution, whatever purpose and I think that is what you mean with the "layer above libnl" so we're probably heading into the same direction with minor differences in how to actually do it. I'll keep on experimenting with it hoping to present some more detailed results soon so we can redraw once we have some prototype and numbers. > > I left out the byte order issues here because I'm not yet sure how > > to solve them although as stated already, using XSLT would be one > > possible path to follow. > > > > There is no byte order issues with ASCII. Obviously yes, it depends on at which layer the transformation is done and that's the point I'm still unsure. The obvious way is to do it in the actual module implementations of libnl and have the produced XML protocol being aware of every single configuration bit. Another way is to describe the actual netlink requests in a half-binary format and do the transformation later. The latter saves a lot of transformation work because everything in between doesn't need to be aware of all the configuration possibilities. However, the transformation to other protocol types gets more complicated. I haven't found any arguments for either way that would convice me to head for one direction so I planned to find out by experimenting. > > You probably mean Yenca, > [..] > > I'm looking into it but it uses ioctl for > > configuration and only implements a small subset of the functionality. > > Yes, i remember that code now. They do use ioctls. > Unfortunately your libnl is not backward compatible and a lot of > embedded devices are 2.4.x based. Ive mentioned this before. You need to > provide a ioctl interface for some things as well and perhaps provide a > compile flag to select between the two. Indeed, I'm not sure how to solve this properly though. libnl's scope is already quite huge and it might be better to build another layer on top of it (maybe the one you mentioned) which abstracts the whole network configuration in a nice API automatically doing the right thing (tm) by checking kernel capabilities an choose netlink/ioctl/ethtool/... or whatever is appropriate. > On completion, I thin they had some basic stuff working which is a good > start (If i recall they could set ip addresses and routes). From what the source tells me, interface and routing has been partially implemented which is a nice start. The code could be merged into the above mentioned library acting as interface for netconf to interact with the kernel. > The architecture seemed pretty sane to me; the whole was in the access to > the kernel configuration - they did something but it appeared weak. > This is where you could help i think. I'll try to work this out with Benjamin given it is in his interest. > Well, the way i see it is like this: > > 3rdlayer: netconf/someotherapp > secondlayer: "the layer above libnl" > firstlayer: libnl (netlink level) > layer0: kernel > > second layer is where that gents code would have been a good fit. He was > already providing some good APIs, bindings etc. XML could be just one > more binding. Agreed. > The problem is i think you are trying to do all layers. I'm thinking in all layers to not miss anything important but it should definitely be spread across various independant parts. From steve.iribarne@dilithiumnetworks.com Tue Mar 8 07:07:42 2005 Received: with ECARTIS (v1.0.0; list netdev); Tue, 08 Mar 2005 07:07:46 -0800 (PST) Received: from DHOST001-17.DEX001.intermedia.net (dhost001-17.intermedia.net [64.78.61.64]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j28F7gi1001921 for ; Tue, 8 Mar 2005 07:07:42 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Subject: RE: Do you know the TCP stack? (127.x.x.x routing) Date: Tue, 8 Mar 2005 07:07:42 -0800 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Do you know the TCP stack? (127.x.x.x routing) Thread-Index: AcUjej4PsvOaXecjS3GriTAzdbYHFAAc9kgQ From: "Steve Iribarne" To: Cc: "Eran Mann" , "Zdenek Radouch" , "Thomas Graf" , "Andi Kleen" , "Martin Mares" , , X-Virus-Scanned: ClamAV 0.83/755/Mon Mar 7 17:00:18 2005 on oss.sgi.com X-Virus-Status: Clean Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by oss.sgi.com id j28F7gi1001921 X-archive-position: 2655 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: steve.iribarne@dilithiumnetworks.com Precedence: bulk X-list: netdev Content-Length: 1325 Lines: 44 -> BTW, please cc netdev or myself if you are addressing me. This email was -> just forwarde by someone else to me - I am not on linux-net. You seem to -> have trimmed down the CC list. -> You should join the list and the quit when you are done. Otherwise, like with this email I get multiple copies of it. -> I read this a few times and still didnt get it: -> Why is it that people using 1918 addresses are affecting you? -> Does using 127.x help you because you assume _nobody_ else would be using -> 127.x addresses? I am in a chassis. I need a way to do interface card communication. Even if those cards are exposed to the outside world. -> I am assuming you want this address for some internal network whereas the -> external contains some routable addresses? -> Yep. -> > So I have this working in my products now. I had to do something a bit -> > different in that I want a "special" 127.xx.xx.xx range to be sent out -> > on the wire. So here is what I did. -> -> [..] -> -> Seems you did too much. Look at the 2 liner patch posted by Eran Mann Right. That works too. But what I did was about 10 lines of code. And I refined it a bit better I believe. That way packets destined for "my" internal network got out the appropriate interface. The rest go on their merry way to the loopback world. From mcgrof@ruslug.rutgers.edu Tue Mar 8 07:22:53 2005 Received: with ECARTIS (v1.0.0; list netdev); Tue, 08 Mar 2005 07:22:59 -0800 (PST) Received: from ruslug.rutgers.edu (ruslug.rutgers.edu [128.6.24.131]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j28FMrlp002770 for ; Tue, 8 Mar 2005 07:22:53 -0800 Received: by ruslug.rutgers.edu (Postfix, from userid 503) id C7F67F9928; Tue, 8 Mar 2005 10:22:44 -0500 (EST) Date: Tue, 8 Mar 2005 10:22:44 -0500 To: Jeff Garzik , domen@coderock.org, prism54-private@prism54.org, netdev@oss.sgi.com, tklauser@nuerscht.ch, prism54-devel@prism54.org Subject: Re: [Prism54-devel] Re: [patch 2/3] drivers/net/wireless/prism54/islpci_hotplug: Use the DMA_{64, 32}BIT_MASK constants Message-ID: <20050308152244.GF3936@ruslug.rutgers.edu> Mail-Followup-To: Jeff Garzik , domen@coderock.org, prism54-private@prism54.org, netdev@oss.sgi.com, tklauser@nuerscht.ch, prism54-devel@prism54.org References: <20050306222355.6686C1ED3D@trashy.coderock.org> <20050307171418.GT3936@ruslug.rutgers.edu> <422C8E48.9000006@pobox.com> <20050307172957.GW3936@ruslug.rutgers.edu> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="Xivtt9Q8Gazzyu1i" Content-Disposition: inline In-Reply-To: <20050307172957.GW3936@ruslug.rutgers.edu> User-Agent: Mutt/1.3.28i X-Operating-System: 2.4.18-1-686 Organization: Rutgers University Student Linux Users Group From: mcgrof@ruslug.rutgers.edu (Luis R. Rodriguez) X-Virus-Scanned: ClamAV 0.83/755/Mon Mar 7 17:00:18 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 2656 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: mcgrof@ruslug.rutgers.edu Precedence: bulk X-list: netdev Content-Length: 883 Lines: 37 --Xivtt9Q8Gazzyu1i Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Mon, Mar 07, 2005 at 12:29:57PM -0500, Luis R. Rodriguez wrote: >=20 > Alright, I'll add DMA_32BIT_MASK through compat and leave > pci_module_init as is. That said: >=20 > Patch 1 applied > Patch 2 will be applied after compat work > Patch 3 rejected per Jeff's recomendation due to 2.4 compat >=20 > Luis This has been committed on to prism54 tree. Luis --=20 GnuPG Key fingerprint =3D 113F B290 C6D2 0251 4D84 A34A 6ADD 4937 E20A 525E --Xivtt9Q8Gazzyu1i Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.4 (GNU/Linux) iD8DBQFCLcNEat1JN+IKUl4RAscUAKCD5c1x7GVgeM87CaWQw/D7YMx3BwCeIekZ CcImIvbt4ARf4QcDCSrhV34= =WGO/ -----END PGP SIGNATURE----- --Xivtt9Q8Gazzyu1i-- From joern@wohnheim.fh-wedel.de Tue Mar 8 07:35:00 2005 Received: with ECARTIS (v1.0.0; list netdev); Tue, 08 Mar 2005 07:35:05 -0800 (PST) Received: from moskovskaya.fh-wedel.de (mail.fh-wedel.de [213.39.232.198]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j28FYxsc003559 for ; Tue, 8 Mar 2005 07:35:00 -0800 Received: from wohnheim.fh-wedel.de ([213.39.233.138]:42701) by moskovskaya.fh-wedel.de with esmtp (Exim 4.34) id 1D8gjU-00065Z-HG; Tue, 08 Mar 2005 16:34:52 +0100 Received: from joern by wohnheim.fh-wedel.de with local (Exim 3.35 #1 (Debian)) id 1D8gjZ-0002Nl-00; Tue, 08 Mar 2005 16:34:57 +0100 Date: Tue, 8 Mar 2005 16:34:57 +0100 From: =?iso-8859-1?Q?J=F6rn?= Engel To: Jeff Garzik Cc: netdev@oss.sgi.com Subject: [PATCH] reduce stack usage for arlan Message-ID: <20050308153457.GB8703@wohnheim.fh-wedel.de> Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit User-Agent: Mutt/1.3.28i X-Virus-Scanned: ClamAV 0.83/755/Mon Mar 7 17:00:18 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 2657 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: joern@wohnheim.fh-wedel.de Precedence: bulk X-list: netdev Content-Length: 1084 Lines: 34 Jean Tourrilhes indicated that this driver is currently unmaintained. Jeff, do you want this patch? Jörn -- Fancy algorithms are slow when n is small, and n is usually small. Fancy algorithms have big constants. Until you know that n is frequently going to be big, don't get fancy. -- Rob Pike SARLSTR is never called with nn bigger than 48. This patch should be safe and severly reduces stack consumption. Signed-off-by: Jörn Engel --- drivers/net/wireless/arlan-proc.c | 4 ++-- 1 files changed, 2 insertions(+), 2 deletions(-) --- linux-2.6.10cow/drivers/net/wireless/arlan-proc.c~arlan_stack 2004-09-04 22:59:04.000000000 +0200 +++ linux-2.6.10cow/drivers/net/wireless/arlan-proc.c 2005-02-03 21:29:33.000000000 +0100 @@ -28,9 +28,9 @@ } #define SARLSTR(var,nn) {\ - char tmpStr[400];\ + char tmpStr[50];\ int tmpLn = nn;\ - if (nn > 399 ) tmpLn = 399; \ + BUG_ON(tmpLn > 49);\ memcpy(tmpStr,(char *) priva->conf->var,tmpLn);\ tmpStr[tmpLn] = 0; \ pos += sprintf(arlan_drive_info+pos, "%s\t=\t%s \n",#var,priva->conf->var);\ From baruch@ev-en.org Tue Mar 8 07:43:04 2005 Received: with ECARTIS (v1.0.0; list netdev); Tue, 08 Mar 2005 07:43:10 -0800 (PST) Received: from galon.ev-en.org (rrcs-24-123-59-149.central.biz.rr.com [24.123.59.149]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j28Fh3Qt004272 for ; Tue, 8 Mar 2005 07:43:04 -0800 Received: by galon.ev-en.org (Postfix, from userid 105) id 9615011A6C5; Tue, 8 Mar 2005 17:42:56 +0200 (IST) Received: from [10.220.3.66] (hamilton.nuim.ie [149.157.192.252]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by galon.ev-en.org (Postfix) with ESMTP id 33C3011A696; Tue, 8 Mar 2005 17:42:09 +0200 (IST) Message-ID: <422DC7CE.2040800@ev-en.org> Date: Tue, 08 Mar 2005 15:42:06 +0000 From: Baruch Even User-Agent: Debian Thunderbird 1.0 (X11/20050116) X-Accept-Language: en-us, en MIME-Version: 1.0 To: "David S. Miller" Cc: shemminger@osdl.org, netdev@oss.sgi.com Subject: Re: netif_rx packet dumping References: <20050303123811.4d934249@dxpl.pdx.osdl.net> <42278122.6000000@ev-en.org> <20050303133659.0d224e61.davem@davemloft.net> <42278554.2090902@ev-en.org> <20050303135718.2e1a0170.davem@davemloft.net> In-Reply-To: <20050303135718.2e1a0170.davem@davemloft.net> X-Enigmail-Version: 0.90.0.0 X-Enigmail-Supports: pgp-inline, pgp-mime Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV 0.83/755/Mon Mar 7 17:00:18 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 2658 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: baruch@ev-en.org Precedence: bulk X-list: netdev Content-Length: 1198 Lines: 29 David S. Miller wrote: > On Thu, 03 Mar 2005 21:44:52 +0000 > Baruch Even wrote: > >>The current linked list goes over all the packets, the linked list we >>add is for the packets that were not SACKed. The idea being that it is a >>lot faster since there are a lot less packets not SACKed compared to >>packets already SACKed (or never mentioned in SACKs). >> >>If you have a way around this I'd be happy to hear it. > > I'm sure you can find a way to steal sizeof(void *) from > "struct tcp_skb_cb" :-) > > It is currently 36 bytes on both 32-bit and 64-bit platforms. > This means if you can squeeze out 4 bytes (so that it fits > in the skb->cb[] 40 byte area), you can fit a pointer in there > for the linked list stuff. The current code adds 2 pointers to tcp_skb_cb and 20 bytes tcp_sock. I can squeeze the tcp_skb_cb to one pointer at the expense of extra work to remove a packet from the list (the other pointer is the prev pointer). I'm trying to do two tasks at the same time, port to 2.6.11 and rerun all the tests to produce a chapter in my thesis (on the ported 2.6.11 patches). Hopefully it will work out, otherwise the porting will be delayed. Baruch From baruch@ev-en.org Tue Mar 8 07:56:39 2005 Received: with ECARTIS (v1.0.0; list netdev); Tue, 08 Mar 2005 07:56:44 -0800 (PST) Received: from galon.ev-en.org (rrcs-24-123-59-149.central.biz.rr.com [24.123.59.149]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j28FudTN005056 for ; Tue, 8 Mar 2005 07:56:39 -0800 Received: by galon.ev-en.org (Postfix, from userid 105) id 5C29A11A6C5; Tue, 8 Mar 2005 17:56:33 +0200 (IST) Received: from [10.220.3.66] (hamilton.nuim.ie [149.157.192.252]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by galon.ev-en.org (Postfix) with ESMTP id 4FC5311A696; Tue, 8 Mar 2005 17:56:06 +0200 (IST) Message-ID: <422DCB14.1040805@ev-en.org> Date: Tue, 08 Mar 2005 15:56:04 +0000 From: Baruch Even User-Agent: Debian Thunderbird 1.0 (X11/20050116) X-Accept-Language: en-us, en MIME-Version: 1.0 To: hadi@cyberus.ca Cc: Stephen Hemminger , John Heffner , "David S. Miller" , rhee@eos.ncsu.edu, Yee-Ting.Li@nuim.ie, netdev@oss.sgi.com Subject: Re: netif_rx packet dumping References: <20050303123811.4d934249@dxpl.pdx.osdl.net> <20050303125556.6850cfe5.davem@davemloft.net> <1109884688.1090.282.camel@jzny.localdomain> <20050303132143.7eef517c@dxpl.pdx.osdl.net> <1109885065.1098.285.camel@jzny.localdomain> <20050303133237.5d64578f.davem@davemloft.net> <20050303135416.0d6e7708@dxpl.pdx.osdl.net> <1109888811.1092.352.camel@jzny.localdomain> <20050303151606.3587394f@dxpl.pdx.osdl.net> <4227A23C.5050300@ev-en.org> <1109907956.1092.476.camel@jzny.localdomain> <42282098.8010506@ev-en.org> <1110203711.1088.1393.camel@jzny.localdomain> In-Reply-To: <1110203711.1088.1393.camel@jzny.localdomain> X-Enigmail-Version: 0.90.0.0 X-Enigmail-Supports: pgp-inline, pgp-mime Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV 0.83/755/Mon Mar 7 17:00:18 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 2659 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: baruch@ev-en.org Precedence: bulk X-list: netdev Content-Length: 4166 Lines: 95 jamal wrote: > On Fri, 2005-03-04 at 03:47, Baruch Even wrote: > >>jamal wrote: > > >>>Can you explain a little more? Why does the the throttling cause any >>>bad behavior thats any different from the queue being full? In both >>>cases, packets arriving during that transient will be dropped. >> >>If you have 300 packets in the queue and the throttling kicks in you now >>drop ALL packets until the queue is empty, this will normally take some >>time, during all of this time you are dropping all the ACKs that are >>coming in, you lose SACK information and potentially you leave no packet >>in flight so that the next packet will be sent only due to retransmit >>timer waking up, at which point your congestion control algorithm starts >>from cwnd=1. >> >>You can look at the report http://hamilton.ie/net/LinuxHighSpeed.pdf for >>some graphs of the effects. > > Were the processors tied to NICs? No. These are single CPU machines (with HT). > Your experiment is more than likely a single flow, correct? Yes. > In other words the whole queue was infact dedicated just for your one > flow - thats why you can call this queue a transient burst queue. Indeed, For a router or a web server handling several thousand flows it might be different, but I don't expect it handles a single packet in one ms (or more) as it happens for the current end-system ack handling code. > Do you still have the data that shows how many packets were dropped > during this period. Do you still have the experimental data? I am > particulary interested in seeing the softnet stats as well as tcp > netstats. No, These tests were not run by me, I'll probably rerun similar tests as well to base my work on, send me in private how do I get the stats from the kernel and I'll add it to my test scripts. > I think your main problem was the huge amounts of SACK on the writequeue > and the resultant processing i.e section 1.1 and how you resolved that. That is my main guess as well, the original work was done rather quickly, we are now reorganizing thoughts and redoing the tests in a more orderly fashion. > I dont see any issue in dropping ACKs, many of them even for such large > windows as you have - TCPs ACKs are cummulative. It is true if you drop > "large" enough amounts of ACKS, you will end up in timeouts - but large > enough in your case must be in the minimal 1000 packets. And to say you > dropped a 1000 packets while processing 300 means you were taking too > long processing the 300. With the current code SACK processing takes a long time, so it is possible that it happened to drop more than a thousand packets while handling 300. I think that after the fixing of the SACK code, the rest might work without getting to much into the ingress queue. But that might still change when we go to even higher speeds. > Then what would be really interesting is to see the perfomance you get > from multiple flows with and without congestion. We'd need to get a very high speed link for multiple high speed flows. > I am not against a the benchmarky nature of the single flow and tuning > for that, but we should also look at a wider scope at the effect before > you handwave based on the result of one testcase. I can't say I didn't handwave, but then, there is little experimentation done to see if the other claims are correct and that AFQ is really needed so early in the packet receive stage. There are also voices that say AFQ sucks and causes more damage than good, I don't remember details currently. > So if i was you i would repeat 1.2 with the fix from 1.1 as well as > tying the NIC to one CPU. And it would be a good idea to present more > detailed results - not just tcp windows fluctuating (you may not need > them for the paper, but would be useful to see for debugging purposes > other parameters). I'd be happy to hear what other benchmarks you would like to see, I currently intend to add some ack processing time analysis and oprofile information. With possibly showing the size of the ingress queue as a measure as well. Making it as thorough as possible is one of my goals. Input is always welcome. Baruch From tgraf@suug.ch Tue Mar 8 08:01:32 2005 Received: with ECARTIS (v1.0.0; list netdev); Tue, 08 Mar 2005 08:01:38 -0800 (PST) Received: from b.mx.projectdream.org (eth0-0.arisu.projectdream.org [194.158.4.191]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j28G1VPt005793 for ; Tue, 8 Mar 2005 08:01:31 -0800 Received: from postel.suug.ch (postel.suug.ch [195.134.158.23]) (using TLSv1 with cipher EDH-RSA-DES-CBC3-SHA (168/168 bits)) (No client certificate requested) by b.mx.projectdream.org (Postfix) with ESMTP id 11A3584; Tue, 8 Mar 2005 17:01:06 +0100 (CET) Received: by postel.suug.ch (Postfix, from userid 10001) id 1EB961C0EA; Tue, 8 Mar 2005 17:01:49 +0100 (CET) Date: Tue, 8 Mar 2005 17:01:49 +0100 From: Thomas Graf To: "David S. Miller" Cc: netdev@oss.sgi.com, Herbert Xu Subject: [PATCH] [NET]: Fix deletion of equal local IPv4 addresses only varying in prefix length Message-ID: <20050308160148.GD31837@postel.suug.ch> References: <20050304012003.GA31837@postel.suug.ch> <20050304131419.GE31837@postel.suug.ch> <20050304233212.GA27421@gondor.apana.org.au> <20050305002910.GJ31837@postel.suug.ch> <20050305005911.GA27804@gondor.apana.org.au> <20050305162323.GM31837@postel.suug.ch> <20050305183009.GA26438@gondor.apana.org.au> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20050305183009.GA26438@gondor.apana.org.au> X-Virus-Scanned: ClamAV 0.83/755/Mon Mar 7 17:00:18 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 2660 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: tgraf@suug.ch Precedence: bulk X-list: netdev Content-Length: 4346 Lines: 110 The deletion of equal local IPv4 addresses only varying in prefix length via netlink currently results in the deletion of the address that was added first independently of the prefix length. The fact that parts of the userspace, especially scripts, rely on the fact that specifying no prefix has the meaning of a wildcard makes this fix non trivial. In order to not break compatibilty the prefix length is only compared if userspace explicitely requests an exact match by setting a flag or if the prefix length is not 32 which means that it was specified by the user. Assuming the addresses 1.1.1.1/1, 1.1.1.1/32, and 1.1.1.1/2 are added in the given order the new behaviour looks as follows: Deletion of Unmodified userspace Modified userspace 1.1.1.1/2 1.1.1.1/2 1.1.1.1/2 1.1.1.1 1.1.1.1/1 1.1.1.1/1 1.1.1.1/32 1.1.1.1/1 1.1.1.1/32 While the old kernel behaviour would have deleted 1.1.1.1/1 in all three cases. Signed-off-by: Thomas Graf diff -Nru linux-2.6.11-bk3.orig/include/linux/inetdevice.h linux-2.6.11-bk3/include/linux/inetdevice.h --- linux-2.6.11-bk3.orig/include/linux/inetdevice.h 2005-03-08 13:10:37.000000000 +0100 +++ linux-2.6.11-bk3/include/linux/inetdevice.h 2005-03-08 16:29:27.000000000 +0100 @@ -7,6 +7,7 @@ #include #include #include +#include struct ipv4_devconf { @@ -131,6 +132,25 @@ return 0; } +static inline int inet_ifa_match_local_prefixlen(struct ifaddrmsg *ifm, + struct in_ifaddr *ifa) +{ + int real_prefixlen = IFA_REAL_DEL_PREFIX(ifm->ifa_prefixlen); + + /* + * Since the prefix length hasn't been taken into account in + * previous kernel versions, parts of the userspace rely on the fact + * that the deletion of an address without specifying a prefix works. + * We cannot break this and thus a prefix length of 32 still represents + * a wildcard if no exact match is requested. + */ + if (real_prefixlen != 32 || ifm->ifa_prefixlen & IFA_PREFIX_EXACT_DEL) + if (real_prefixlen != ifa->ifa_prefixlen) + return 0; + + return 1; +} + #define for_primary_ifa(in_dev) { struct in_ifaddr *ifa; \ for (ifa = (in_dev)->ifa_list; ifa && !(ifa->ifa_flags&IFA_F_SECONDARY); ifa = ifa->ifa_next) diff -Nru linux-2.6.11-bk3.orig/include/linux/rtnetlink.h linux-2.6.11-bk3/include/linux/rtnetlink.h --- linux-2.6.11-bk3.orig/include/linux/rtnetlink.h 2005-03-08 16:28:04.000000000 +0100 +++ linux-2.6.11-bk3/include/linux/rtnetlink.h 2005-03-08 14:17:49.000000000 +0100 @@ -396,6 +396,19 @@ #define IFA_MAX (__IFA_MAX - 1) +/* + * Quirk for IPv4 address deletion to allow exact deletion of equal + * addresses varying only in prefix length. A explicit exact comparison + * of the prefix length will only be done if IFA_PREFIX_EXACT_DEL is + * ORed to ifa_prefixlen. + * + * Note: This special treatment is only understood while deleting + * addresses and will lead to unexpected behaviour if used + * otherwise. + */ +#define IFA_PREFIX_EXACT_DEL 0x40 +#define IFA_REAL_DEL_PREFIX(l) ((l) & 0x3f) + /* ifa_flags */ #define IFA_F_SECONDARY 0x01 diff -Nru linux-2.6.11-bk3.orig/net/ipv4/devinet.c linux-2.6.11-bk3/net/ipv4/devinet.c --- linux-2.6.11-bk3.orig/net/ipv4/devinet.c 2005-03-08 13:10:44.000000000 +0100 +++ linux-2.6.11-bk3/net/ipv4/devinet.c 2005-03-08 16:29:49.000000000 +0100 @@ -389,6 +389,7 @@ struct in_device *in_dev; struct ifaddrmsg *ifm = NLMSG_DATA(nlh); struct in_ifaddr *ifa, **ifap; + int real_prefixlen = IFA_REAL_DEL_PREFIX(ifm->ifa_prefixlen); ASSERT_RTNL(); @@ -399,12 +400,13 @@ for (ifap = &in_dev->ifa_list; (ifa = *ifap) != NULL; ifap = &ifa->ifa_next) { if ((rta[IFA_LOCAL - 1] && + (!inet_ifa_match_local_prefixlen(ifm, ifa) || memcmp(RTA_DATA(rta[IFA_LOCAL - 1]), - &ifa->ifa_local, 4)) || + &ifa->ifa_local, 4))) || (rta[IFA_LABEL - 1] && rtattr_strcmp(rta[IFA_LABEL - 1], ifa->ifa_label)) || (rta[IFA_ADDRESS - 1] && - (ifm->ifa_prefixlen != ifa->ifa_prefixlen || + (real_prefixlen != ifa->ifa_prefixlen || !inet_ifa_match(*(u32*)RTA_DATA(rta[IFA_ADDRESS - 1]), ifa)))) continue; From bennybbz@yahoo.fr Tue Mar 8 08:36:47 2005 Received: with ECARTIS (v1.0.0; list netdev); Tue, 08 Mar 2005 08:36:50 -0800 (PST) Received: from web26606.mail.ukl.yahoo.com (web26606.mail.ukl.yahoo.com [217.146.176.56]) by oss.sgi.com (8.13.0/8.13.0) with SMTP id j28GakKr010685 for ; Tue, 8 Mar 2005 08:36:47 -0800 Received: (qmail 96673 invoked by uid 60001); 8 Mar 2005 16:36:40 -0000 Message-ID: <20050308163640.96671.qmail@web26606.mail.ukl.yahoo.com> Received: from [63.87.1.243] by web26606.mail.ukl.yahoo.com via HTTP; Tue, 08 Mar 2005 17:36:40 CET Date: Tue, 8 Mar 2005 17:36:40 +0100 (CET) From: BZ Benny Subject: Ethernet header???? To: netdev MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Virus-Scanned: ClamAV 0.83/755/Mon Mar 7 17:00:18 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 2661 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: bennybbz@yahoo.fr Precedence: bulk X-list: netdev Content-Length: 357 Lines: 19 Hi all, is there some fonctions for displaying ethernet headers, the protocol used... and the paylod. I'm using an ethertap device. And I want to see what data I'm receiving from my TAP device. regards benny Découvrez le nouveau Yahoo! Mail : 250 Mo d'espace de stockage pour vos mails ! Créez votre Yahoo! Mail sur http://fr.mail.yahoo.com/ From ak@muc.de Tue Mar 8 09:00:56 2005 Received: with ECARTIS (v1.0.0; list netdev); Tue, 08 Mar 2005 09:01:02 -0800 (PST) Received: from one.firstfloor.org (one.firstfloor.org [213.235.205.2]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j28H0u2h012919 for ; Tue, 8 Mar 2005 09:00:56 -0800 Received: by one.firstfloor.org (Postfix, from userid 502) id 04DACD033E; Tue, 8 Mar 2005 18:00:49 +0100 (CET) To: Baruch Even Cc: shemminger@osdl.org, netdev@oss.sgi.com Subject: Re: netif_rx packet dumping References: <20050303123811.4d934249@dxpl.pdx.osdl.net> <42278122.6000000@ev-en.org> <20050303133659.0d224e61.davem@davemloft.net> <42278554.2090902@ev-en.org> <20050303135718.2e1a0170.davem@davemloft.net> <422DC7CE.2040800@ev-en.org> From: Andi Kleen Date: Tue, 08 Mar 2005 18:00:49 +0100 In-Reply-To: <422DC7CE.2040800@ev-en.org> (Baruch Even's message of "Tue, 08 Mar 2005 15:42:06 +0000") Message-ID: User-Agent: Gnus/5.110002 (No Gnus v0.2) Emacs/21.3 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Virus-Scanned: ClamAV 0.83/755/Mon Mar 7 17:00:18 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 2662 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: ak@muc.de Precedence: bulk X-list: netdev Content-Length: 331 Lines: 10 Baruch Even writes: > > I can squeeze the tcp_skb_cb to one pointer at the expense of extra > work to remove a packet from the list (the other pointer is the prev > pointer). You could also use a xor list in theory. But I'm not sure it's worth it. Increasing cb by 4 bytes shouldn't be a very big issue. -Andi From steve@services.navaho.net Tue Mar 8 09:25:13 2005 Received: with ECARTIS (v1.0.0; list netdev); Tue, 08 Mar 2005 09:25:17 -0800 (PST) Received: from services.navaho.net (fairchild-194.adsl.newnet.co.uk [213.131.187.194]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j28HPBKT014445 for ; Tue, 8 Mar 2005 09:25:12 -0800 Received: from [10.101.0.42] (helo=[10.101.0.42] ident=[U2FsdGVkX1//9AP2yfuIaH0pJDiF147FgAwom6aV4UE=]) by services.navaho.net with esmtp (Exim 4.43) id 1D8iSE-0004M6-VF for netdev@oss.sgi.com; Tue, 08 Mar 2005 17:25:11 +0000 Date: Tue, 8 Mar 2005 17:25:10 +0000 (GMT) From: Steve Hill X-X-Sender: steve@sorbus2.navaho To: netdev@oss.sgi.com Subject: IPSEC Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Virus-Scanned: ClamAV 0.83/755/Mon Mar 7 17:00:18 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 2663 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: steve@services.navaho.net Precedence: bulk X-list: netdev Content-Length: 4314 Lines: 88 This might not be the right place for me to post (is there a better place to ask about ipsec problems using the 2.6 kernel's built in IPSEC support?). Anyway, I'm hoping someone can help here: I'm trying to connect 2 boxes together in transport mode using PSKs with Racoon (I'll migrate to X.509 certs and tunnel mode once I've got this working). I'm on the 2.6.10 Fedora Core 3 kernel with Racoon 0.5 and I'm running in AH and ESP mode. When the 2 machines set up the SAs with eachother, Racoon thinks everything's ok and logs that the ESP and AH sessions are established in both directions, however on one of the machines the SAD only contains 3 entries: (this is setkey -D dumped from the machine with IP address "a.b.c.d"): a.b.c.d w.x.y.z esp mode=transport spi=230360363(0x0dbb052b) reqid=0(0x00000000) E: 3des-cbc c3f07995 d878c486 55b181ee 15aa670d a4b96fc1 d4099a9c A: hmac-sha1 0533aed9 4591125c 6ae8e740 51f3b066 fc5222fc seq=0x00000000 replay=4 flags=0x00000000 state=mature created: Mar 8 17:05:19 2005 current: Mar 8 17:05:21 2005 diff: 2(s) hard: 3600(s) soft: 2880(s) last: hard: 0(s) soft: 0(s) current: 0(bytes) hard: 0(bytes) soft: 0(bytes) allocated: 0 hard: 0 soft: 0 sadb_seq=2 pid=3704 refcnt=0 w.x.y.z a.b.c.d esp mode=transport spi=261919355(0x0f9c927b) reqid=0(0x00000000) E: 3des-cbc b1051e37 4482da28 adc8aee8 92046dda 2c5e3dc1 11e62536 A: hmac-sha1 ea69668e 42cbca96 22b0d941 6bfa5f2d bb39be74 seq=0x00000000 replay=4 flags=0x00000000 state=mature created: Mar 8 17:05:19 2005 current: Mar 8 17:05:21 2005 diff: 2(s) hard: 3600(s) soft: 2880(s) last: hard: 0(s) soft: 0(s) current: 0(bytes) hard: 0(bytes) soft: 0(bytes) allocated: 0 hard: 0 soft: 0 sadb_seq=1 pid=3704 refcnt=0 w.x.y.z a.b.c.d ah mode=transport spi=2363330(0x00240fc2) reqid=0(0x00000000) A: hmac-sha1 702e8bf2 1aa44422 0f46ae1d b213d871 4fc6c57b seq=0x00000000 replay=4 flags=0x00000000 state=mature created: Mar 8 17:05:19 2005 current: Mar 8 17:05:21 2005 diff: 2(s) hard: 3600(s) soft: 2880(s) last: hard: 0(s) soft: 0(s) current: 0(bytes) hard: 0(bytes) soft: 0(bytes) allocated: 0 hard: 0 soft: 0 sadb_seq=0 pid=3704 refcnt=0 As you can see, the outbound AH SA isn't in the SAD even though Racoon claims it's all fine. Since this is reliably reproduced I have done some debugging on the kernel side but I've ended up rather confused. During the negotiation, xfrm_state_add is successfully called for both outbound SAs. I added some printk() statements to see what it was doing and ended up with: xfrm_state_add: Called with seq: 00e74298, Family: 2, seq 1, proto 51 __xfrm_find_acq_byseq: Returned NULL __xfrm_state_insert: Called with seq: 00e74298 xfrm_state_add: Called with seq: 0dbb052b, Family: 2, seq 1, proto 50 __xfrm_find_acq_byseq: Returned 00e74298 __xfrm_state_insert: Called with seq: 0dbb052b xfrm_state_delete: Called with seq: 00e74298 From this logging it seems the AH SA has been added to the SAD ok, but then the ESP SA is added and it has the same sequence number (1) as the AH SA so the AH SA gets deleted. The xfrm_state_add() function does: x1 = __xfrm_find_acq_byseq(x->km.seq); ... xfrm_state_delete(x1); And this is responsible for deleting the AH SA due to it's matching sequence number. I'm not sure what's at fault here - what generates the sequence number? I presume from the checking that's done here that the sequence number is always expected to be unique, so it seems that either a unique sequence number is never being generated or Racoon is plain not using it. (Correct me if I'm wrong here). Any help would be appreciated - I've been battling with this problem for several days. Thanks. - Steve Hill (BSc) Senior Software Developer Email: steve@navaho.co.uk Navaho Technologies Ltd. Tel: +44-870-7034015 From kaber@trash.net Tue Mar 8 09:44:47 2005 Received: with ECARTIS (v1.0.0; list netdev); Tue, 08 Mar 2005 09:44:52 -0800 (PST) Received: from kaber.coreworks.de ([62.206.217.67]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j28Hikhl016201 for ; Tue, 8 Mar 2005 09:44:47 -0800 Received: from localhost ([127.0.0.1]) by kaber.coreworks.de with esmtp (Exim 4.50) id 1D8il5-0001Ia-TN; Tue, 08 Mar 2005 18:44:39 +0100 Message-ID: <422DE487.5020800@trash.net> Date: Tue, 08 Mar 2005 18:44:39 +0100 From: Patrick McHardy User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.7.5) Gecko/20050106 Debian/1.7.5-1 X-Accept-Language: en MIME-Version: 1.0 To: Steve Hill CC: netdev@oss.sgi.com, "David S. Miller" Subject: Re: IPSEC References: In-Reply-To: Content-Type: multipart/mixed; boundary="------------030604010306070804050703" X-Virus-Scanned: ClamAV 0.83/755/Mon Mar 7 17:00:18 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 2664 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: kaber@trash.net Precedence: bulk X-list: netdev Content-Length: 1315 Lines: 43 This is a multi-part message in MIME format. --------------030604010306070804050703 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Steve Hill wrote: > then the ESP SA is added and it has the same sequence number (1) as the > AH SA so the AH SA gets deleted. > > The xfrm_state_add() function does: > x1 = __xfrm_find_acq_byseq(x->km.seq); > ... > xfrm_state_delete(x1); > And this is responsible for deleting the AH SA due to it's matching > sequence number. This is a bug in the kernel, __xfrm_find_acq_byseq should only return XFRM_STATE_ACQ states. This patch should fix it. Signed-off-by: Patrick McHardy --------------030604010306070804050703 Content-Type: text/plain; name="x" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="x" ===== net/xfrm/xfrm_state.c 1.55 vs edited ===== --- 1.55/net/xfrm/xfrm_state.c 2005-03-07 06:23:53 +01:00 +++ edited/net/xfrm/xfrm_state.c 2005-03-08 18:42:13 +01:00 @@ -609,7 +609,7 @@ for (i = 0; i < XFRM_DST_HSIZE; i++) { list_for_each_entry(x, xfrm_state_bydst+i, bydst) { - if (x->km.seq == seq) { + if (x->km.seq == seq && x->km.state == XFRM_STATE_ACQ) { xfrm_state_hold(x); return x; } --------------030604010306070804050703-- From greearb@candelatech.com Tue Mar 8 09:45:32 2005 Received: with ECARTIS (v1.0.0; list netdev); Tue, 08 Mar 2005 09:45:39 -0800 (PST) Received: from www.lanforge.com (ns1.lanforge.com [66.165.47.210]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j28HjWVc016425 for ; Tue, 8 Mar 2005 09:45:32 -0800 Received: from [4.33.45.22] (evrtwa1-ar2-4-33-045-022.evrtwa1.dsl-verizon.net [4.33.45.22]) (authenticated bits=0) by www.lanforge.com (8.12.8/8.12.8) with ESMTP id j28I8RLH015966; Tue, 8 Mar 2005 10:08:28 -0800 Message-ID: <422DE4B0.6040201@candelatech.com> Date: Tue, 08 Mar 2005 09:45:20 -0800 From: Ben Greear Organization: Candela Technologies User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.7.3) Gecko/20041020 X-Accept-Language: en-us, en MIME-Version: 1.0 To: hadi@cyberus.ca CC: Patrick McHardy , leo@yuriev.ru, Lennert Buytenhek , shemminger@osdl.org, netdev@oss.sgi.com Subject: Re: [leo@yuriev.ru: [PATCH] ethernet-bridge: update skb->priority in case forwarded frame has VLAN-header] References: <20050305141225.GA5180@xi.wantstofly.org> <4229D98F.9010008@trash.net> <422A0C21.3050709@candelatech.com> <1110199696.1094.1299.camel@jzny.localdomain> <1110238537.1043.62.camel@jzny.localdomain> <422CE983.7060305@trash.net> <1110241190.1043.100.camel@jzny.localdomain> <422D1E26.1010902@trash.net> <1110287626.1043.146.camel@jzny.localdomain> In-Reply-To: <1110287626.1043.146.camel@jzny.localdomain> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV 0.83/755/Mon Mar 7 17:00:18 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 2665 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: greearb@candelatech.com Precedence: bulk X-list: netdev Content-Length: 976 Lines: 30 jamal wrote: > On Mon, 2005-03-07 at 22:38, Patrick McHardy wrote: > >>jamal wrote: >> >>>Indeed that looks bad. But wouldnt have helped if we started at 0 >>>either. You need monotonically increasing values to make proper >>>sense. So i suppose to do proper qos with L2, one must install the prio >>>qdisc and rewrite the priomap. >> >>One reason more to move it to an optional ebtables target. Or leave it >>all to prio + u32. But I guess a CLASSIFY target similar to iptables >>could also be useful otherwise. > > > I think you still want (perhaps the vlan) driver to come up with some > sane defaults. From what i read from bgrear he has arbitrary values. By default, everything is mapped to priority of zero, but the user can specify a mapping to any integer they desire. If you have some suggestions for some defaults better than zero, I'm willing to consider it. Ben -- Ben Greear Candela Technologies Inc http://www.candelatech.com From baruch@ev-en.org Tue Mar 8 10:02:25 2005 Received: with ECARTIS (v1.0.0; list netdev); Tue, 08 Mar 2005 10:02:30 -0800 (PST) Received: from galon.ev-en.org (rrcs-24-123-59-149.central.biz.rr.com [24.123.59.149]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j28I2OO7018011 for ; Tue, 8 Mar 2005 10:02:25 -0800 Received: by galon.ev-en.org (Postfix, from userid 105) id 8725611A84F; Tue, 8 Mar 2005 20:02:14 +0200 (IST) Received: from [10.220.3.66] (hamilton.nuim.ie [149.157.192.252]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by galon.ev-en.org (Postfix) with ESMTP id 0EC7411A696; Tue, 8 Mar 2005 20:01:04 +0200 (IST) Message-ID: <422DE85D.1010901@ev-en.org> Date: Tue, 08 Mar 2005 18:01:01 +0000 From: Baruch Even User-Agent: Debian Thunderbird 1.0 (X11/20050116) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Andi Kleen Cc: shemminger@osdl.org, netdev@oss.sgi.com Subject: Re: netif_rx packet dumping References: <20050303123811.4d934249@dxpl.pdx.osdl.net> <42278122.6000000@ev-en.org> <20050303133659.0d224e61.davem@davemloft.net> <42278554.2090902@ev-en.org> <20050303135718.2e1a0170.davem@davemloft.net> <422DC7CE.2040800@ev-en.org> In-Reply-To: X-Enigmail-Version: 0.90.0.0 X-Enigmail-Supports: pgp-inline, pgp-mime Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV 0.83/755/Mon Mar 7 17:00:18 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 2666 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: baruch@ev-en.org Precedence: bulk X-list: netdev Content-Length: 623 Lines: 18 Andi Kleen wrote: > Baruch Even writes: > >>I can squeeze the tcp_skb_cb to one pointer at the expense of extra >>work to remove a packet from the list (the other pointer is the prev >>pointer). > > You could also use a xor list in theory. But I'm not sure it's worth it. > Increasing cb by 4 bytes shouldn't be a very big issue. If increasing the cb by 4 bytes is ok, it would make my life easier and the code simpler. But I don't think it would also be a big issue to remove the prev pointer. Now, if we can agree on increasing the tcp_sock by 20 bytes I'll be able to continue my work. Baruch From davem@davemloft.net Tue Mar 8 10:09:44 2005 Received: with ECARTIS (v1.0.0; list netdev); Tue, 08 Mar 2005 10:09:50 -0800 (PST) Received: from cheetah.davemloft.net (mail@dsl027-180-174.sfo1.dsl.speakeasy.net [216.27.180.174]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j28I9iqI018781 for ; Tue, 8 Mar 2005 10:09:44 -0800 Received: from localhost ([127.0.0.1] helo=cheetah.davemloft.net ident=davem) by cheetah.davemloft.net with smtp (Exim 3.36 #1 (Debian)) id 1D8j8g-00014d-00; Tue, 08 Mar 2005 10:09:02 -0800 Date: Tue, 8 Mar 2005 10:09:02 -0800 From: "David S. Miller" To: Andi Kleen Cc: baruch@ev-en.org, shemminger@osdl.org, netdev@oss.sgi.com Subject: Re: netif_rx packet dumping Message-Id: <20050308100902.24b67b2f.davem@davemloft.net> In-Reply-To: References: <20050303123811.4d934249@dxpl.pdx.osdl.net> <42278122.6000000@ev-en.org> <20050303133659.0d224e61.davem@davemloft.net> <42278554.2090902@ev-en.org> <20050303135718.2e1a0170.davem@davemloft.net> <422DC7CE.2040800@ev-en.org> X-Mailer: Sylpheed version 1.0.1 (GTK+ 1.2.10; sparc-unknown-linux-gnu) X-Face: "_;p5u5aPsO,_Vsx"^v-pEq09'CU4&Dc1$fQExov$62l60cgCc%FnIwD=.UF^a>?5'9Kn[;433QFVV9M..2eN.@4ZWPGbdi<=?[:T>y?SD(R*-3It"Vj:)"dP Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV 0.83/755/Mon Mar 7 17:00:18 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 2667 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: davem@davemloft.net Precedence: bulk X-list: netdev Content-Length: 653 Lines: 17 On Tue, 08 Mar 2005 18:00:49 +0100 Andi Kleen wrote: > Baruch Even writes: > > > > I can squeeze the tcp_skb_cb to one pointer at the expense of extra > > work to remove a packet from the list (the other pointer is the prev > > pointer). > > You could also use a xor list in theory. But I'm not sure it's worth it. > Increasing cb by 4 bytes shouldn't be a very big issue. Going from "40" to "44" takes 64-bit platforms onto another cache line for struct sk_buff, as I stated in another email. And every time I let this happen, I get an email from David Mosberger because it shows up in performance tests on ia64. :-) From ak@muc.de Tue Mar 8 10:18:47 2005 Received: with ECARTIS (v1.0.0; list netdev); Tue, 08 Mar 2005 10:18:50 -0800 (PST) Received: from colin2.muc.de (qmailr@colin2.muc.de [193.149.48.15]) by oss.sgi.com (8.13.0/8.13.0) with SMTP id j28IIjNa019467 for ; Tue, 8 Mar 2005 10:18:46 -0800 Received: (qmail 38557 invoked by uid 3709); 8 Mar 2005 18:18:44 -0000 Date: 8 Mar 2005 19:18:44 +0100 Date: Tue, 8 Mar 2005 19:18:44 +0100 From: Andi Kleen To: "David S. Miller" Cc: baruch@ev-en.org, shemminger@osdl.org, netdev@oss.sgi.com Subject: Re: netif_rx packet dumping Message-ID: <20050308181844.GA37392@muc.de> References: <20050303123811.4d934249@dxpl.pdx.osdl.net> <42278122.6000000@ev-en.org> <20050303133659.0d224e61.davem@davemloft.net> <42278554.2090902@ev-en.org> <20050303135718.2e1a0170.davem@davemloft.net> <422DC7CE.2040800@ev-en.org> <20050308100902.24b67b2f.davem@davemloft.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20050308100902.24b67b2f.davem@davemloft.net> User-Agent: Mutt/1.4.1i X-Virus-Scanned: ClamAV 0.83/755/Mon Mar 7 17:00:18 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 2668 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: ak@muc.de Precedence: bulk X-list: netdev Content-Length: 1190 Lines: 27 > > You could also use a xor list in theory. But I'm not sure it's worth it. > > Increasing cb by 4 bytes shouldn't be a very big issue. > > Going from "40" to "44" takes 64-bit platforms onto another cache line > for struct sk_buff, as I stated in another email. > > And every time I let this happen, I get an email from David Mosberger because > it shows up in performance tests on ia64. :-) Ok, then use a XOR list or trim some other field. There are some other savings possible e.g. from a quick look: - skb->list is afaik totally unnecessary and probably even unused. - struct timeval could be an optimized structure using 32bit for the sub second part. (would need moving it somewhere else, otherwise alignment doesn't help) - Are really three device pointers needed? Perhaps things can be a bit optimized here. - Hippi could be finally changed to use skb->cb instead of its private field. - is skb->security still needed? It should be obsolete with ->sec_path, no? Would only help together with the timestamp optimization. Of course these all wouldn't change the number of cache lines significantly, but it would possible allow other optimizations that need new fields. -Andi From greearb@candelatech.com Tue Mar 8 10:27:41 2005 Received: with ECARTIS (v1.0.0; list netdev); Tue, 08 Mar 2005 10:27:45 -0800 (PST) Received: from www.lanforge.com (ns1.lanforge.com [66.165.47.210]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j28IRePN020117 for ; Tue, 8 Mar 2005 10:27:41 -0800 Received: from [4.33.45.22] (evrtwa1-ar2-4-33-045-022.evrtwa1.dsl-verizon.net [4.33.45.22]) (authenticated bits=0) by www.lanforge.com (8.12.8/8.12.8) with ESMTP id j28IoPLH016586; Tue, 8 Mar 2005 10:50:25 -0800 Message-ID: <422DEE85.5010302@candelatech.com> Date: Tue, 08 Mar 2005 10:27:17 -0800 From: Ben Greear Organization: Candela Technologies User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.7.3) Gecko/20041020 X-Accept-Language: en-us, en MIME-Version: 1.0 To: "David S. Miller" CC: Andi Kleen , baruch@ev-en.org, shemminger@osdl.org, netdev@oss.sgi.com Subject: Re: netif_rx packet dumping References: <20050303123811.4d934249@dxpl.pdx.osdl.net> <42278122.6000000@ev-en.org> <20050303133659.0d224e61.davem@davemloft.net> <42278554.2090902@ev-en.org> <20050303135718.2e1a0170.davem@davemloft.net> <422DC7CE.2040800@ev-en.org> <20050308100902.24b67b2f.davem@davemloft.net> In-Reply-To: <20050308100902.24b67b2f.davem@davemloft.net> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV 0.83/755/Mon Mar 7 17:00:18 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 2669 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: greearb@candelatech.com Precedence: bulk X-list: netdev Content-Length: 1532 Lines: 54 David S. Miller wrote: > On Tue, 08 Mar 2005 18:00:49 +0100 > Andi Kleen wrote: > > >>Baruch Even writes: >> >>>I can squeeze the tcp_skb_cb to one pointer at the expense of extra >>>work to remove a packet from the list (the other pointer is the prev >>>pointer). >> >>You could also use a xor list in theory. But I'm not sure it's worth it. >>Increasing cb by 4 bytes shouldn't be a very big issue. > > > Going from "40" to "44" takes 64-bit platforms onto another cache line > for struct sk_buff, as I stated in another email. Seems like we might could squish the sk_buff a bit: Do we really need 32-bits for the mac-len: unsigned int len, data_len, mac_len, csum; Some of these flags could be collapsed into a single field and we could do bit-shift operations for the single flags we care about. This would also make it easier to add new flags as desired w/out growing the structure. unsigned char local_df, cloned, pkt_type, ip_summed; The priority could probably be 16 bits as well, do we really need more than 65k different priorities: __u32 priority; Of course...this might be things for 2.7 since lots of modules will probably be accessing these fields. Maybe to get started we could add macros to grab the flags and such so that when we finally do collapse things into a single flags field the external code doesn't have to know or care? Thanks, Ben -- Ben Greear Candela Technologies Inc http://www.candelatech.com From andre@tomt.net Tue Mar 8 10:35:39 2005 Received: with ECARTIS (v1.0.0; list netdev); Tue, 08 Mar 2005 10:35:45 -0800 (PST) Received: from mx1.skjellin.no (mail1.skjellin.no [80.239.42.67]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j28IZcgV020853 for ; Tue, 8 Mar 2005 10:35:39 -0800 Received: from localhost (localhost [127.0.0.1]) by mx1.skjellin.no (Postfix) with ESMTP id 2C4CB88502; Tue, 8 Mar 2005 19:35:40 +0100 (CET) Received: from puppen.pasop.tomt.net (gw-fe-1.pasop.tomt.net [10.255.1.1]) by mail1.skjellin.no (Postfix) with ESMTP id 9D879884E2; Tue, 8 Mar 2005 19:35:39 +0100 (CET) Received: from [10.255.1.10] (slurv.pasop.tomt.net [10.255.1.10]) by puppen.pasop.tomt.net (Postfix) with ESMTP id 2D0CF22AA3; Tue, 8 Mar 2005 19:35:37 +0100 (CET) Message-ID: <422DF07D.7010908@tomt.net> Date: Tue, 08 Mar 2005 19:35:41 +0100 From: Andre Tomt User-Agent: Mozilla Thunderbird 1.0 (Windows/20041206) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Michal Vanco Cc: linux-kernel@vger.kernel.org, Netdev Subject: Re: 2.6.11 on AMD64 traps References: <200503081900.18686.vanco@satro.sk> In-Reply-To: <200503081900.18686.vanco@satro.sk> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV 0.83/755/Mon Mar 7 17:00:18 2005 on oss.sgi.com X-Virus-Scanned: by amavisd-new-20030616-p10 (Debian) at skjellin.no X-Virus-Status: Clean X-archive-position: 2670 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: andre@tomt.net Precedence: bulk X-list: netdev Content-Length: 1972 Lines: 44 [just adding netdev to CC, from LKML] Michal Vanco wrote: > Hello, > > I see this problem running 2.6.11 on dual AMD64: > > Running quagga routing daemon (ospf+bgp) and issuing "netstat -rn |wc -l" command > while quagga tries to load more than 154000 routes from its bgp neighbours causes this trap: > > Unable to handle kernel paging request at 00000000007f5c60 RIP: > {fib_get_next+181} > PGD 3a112067 PUD 3a115067 PMD 0 > Oops: 0000 [1] SMP > CPU 1 > Modules linked in: > Pid: 2537, comm: netstat Not tainted 2.6.11-mv > RIP: 0010:[] {fib_get_next+181} > RSP: 0018:ffff81003a13fe90 EFLAGS: 00010206 > RAX: ffff81003a74c000 RBX: 0000000000000000 RCX: ffff81003a13ff50 > RDX: 00000000007f5c60 RSI: 0000000000000000 RDI: ffff81003a004d00 > RBP: ffff81003a13fed8 R08: ffff81003f3ff7c0 R09: 0000000000000800 > R10: 00007fffffffefe0 R11: 0000000000000246 R12: ffff810002231480 > R13: 00002aaaaab08000 R14: 0000000000000400 R15: ffff8100022314a8 > FS: 00002aaaaae00620(0000) GS:ffffffff806195c0(0000) knlGS:0000000000000000 > CS: 0010 DS: 0000 ES: 0000 CR0: 000000008005003b > CR2: 00000000007f5c60 CR3: 000000003a12e000 CR4: 00000000000006e0 > Process netstat (pid: 2537, threadinfo ffff81003a13e000, task ffff81003a66a760) > Stack: ffffffff8041bf0f ffff810002231480 ffff81003a67ac80 0000000000000000 > ffffffff8019576b 0000000000000000 ffff81003a13ff50 00002aaaaab08000 > 00000000000006f7 00000000000006f8 > Call Trace:{fib_seq_start+63} {seq_read+219} > {vfs_read+191} {sys_read+83} > {system_call+126} > > Code: 48 8b 0a 0f 18 09 48 8b 72 10 48 8b 06 0f 18 08 48 8d 42 10 > RIP {fib_get_next+181} RSP > CR2: 00000000007f5c60 > > I saw the same issue on 2.6.10 before. I'm not a kernel hacker but it sounds like > locking problem. But may be I'm totally wrong in this. > > michal From tgraf@suug.ch Tue Mar 8 10:37:41 2005 Received: with ECARTIS (v1.0.0; list netdev); Tue, 08 Mar 2005 10:37:45 -0800 (PST) Received: from b.mx.projectdream.org (eth0-0.arisu.projectdream.org [194.158.4.191]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j28IbeAJ021312 for ; Tue, 8 Mar 2005 10:37:41 -0800 Received: from postel.suug.ch (postel.suug.ch [195.134.158.23]) (using TLSv1 with cipher EDH-RSA-DES-CBC3-SHA (168/168 bits)) (No client certificate requested) by b.mx.projectdream.org (Postfix) with ESMTP id 5CD8E84; Tue, 8 Mar 2005 19:37:17 +0100 (CET) Received: by postel.suug.ch (Postfix, from userid 10001) id AC3641C0EA; Tue, 8 Mar 2005 19:37:59 +0100 (CET) Date: Tue, 8 Mar 2005 19:37:59 +0100 From: Thomas Graf To: Andi Kleen Cc: "David S. Miller" , baruch@ev-en.org, shemminger@osdl.org, netdev@oss.sgi.com Subject: Re: netif_rx packet dumping Message-ID: <20050308183759.GE31837@postel.suug.ch> References: <20050303123811.4d934249@dxpl.pdx.osdl.net> <42278122.6000000@ev-en.org> <20050303133659.0d224e61.davem@davemloft.net> <42278554.2090902@ev-en.org> <20050303135718.2e1a0170.davem@davemloft.net> <422DC7CE.2040800@ev-en.org> <20050308100902.24b67b2f.davem@davemloft.net> <20050308181844.GA37392@muc.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20050308181844.GA37392@muc.de> X-Virus-Scanned: ClamAV 0.83/755/Mon Mar 7 17:00:18 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 2671 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: tgraf@suug.ch Precedence: bulk X-list: netdev Content-Length: 1218 Lines: 28 * Andi Kleen <20050308181844.GA37392@muc.de> 2005-03-08 19:18 > There are some other savings possible e.g. from a quick look: > - skb->list is afaik totally unnecessary and probably even unused. > - struct timeval could be an optimized structure using 32bit > for the sub second part. > (would need moving it somewhere else, otherwise alignment doesn't help) > - Are really three device pointers needed? Perhaps things can > be a bit optimized here. Likely that real_dev can be moved to cb. I would like to keep indev though, it really helps at policy routing decisions. > - Hippi could be finally changed to use skb->cb instead of its > private field. Definitely. > - is skb->security still needed? It should be obsolete with ->sec_path, no? > Would only help together with the timestamp optimization. security has been unused for quite some time as far as I can see. Anyone going for a patch? Otherwise I'll give it a try. Speaking of it, I see tcp_sock is marginal over 2**10 on 32 bit archs and Stephen's plans to outsource the cc bits brings us closer to the border. Would it be worth to try and get it below 2**10? I spotted some places for optimizations but not enough to really save the needed amount. From hno@marasystems.com Tue Mar 8 10:39:54 2005 Received: with ECARTIS (v1.0.0; list netdev); Tue, 08 Mar 2005 10:39:58 -0800 (PST) Received: from filer.marasystems.com (marasystems.com [83.241.133.2]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j28IdqV4021966 for ; Tue, 8 Mar 2005 10:39:53 -0800 Received: from localhost (henrik@localhost) by filer.marasystems.com (8.11.6/8.11.6) with ESMTP id j28IY5b05448; Tue, 8 Mar 2005 19:34:06 +0100 Date: Tue, 8 Mar 2005 19:34:05 +0100 (CET) From: Henrik Nordstrom To: jamal cc: Zdenek Radouch , Steve Iribarne , Eran Mann , Thomas Graf , Andi Kleen , Martin Mares , netdev@oss.sgi.com, linux-net@vger.kernel.org Subject: Re: Do you know the TCP stack? (127.x.x.x routing) In-Reply-To: <1110288879.1050.167.camel@jzny.localdomain> Message-ID: References: <422C0B50.20500@mrv.com> <20050306173145.GQ31837@postel.suug.ch> <3sp35g$7hpm0@smtp04.mrf.mail.rcn.net> <422C0B50.20500@mrv.com> <3sp35g$7rsc1@smtp04.mrf.mail.rcn.net> <1110288879.1050.167.camel@jzny.localdomain> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Virus-Scanned: ClamAV 0.83/755/Mon Mar 7 17:00:18 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 2672 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: hno@marasystems.com Precedence: bulk X-list: netdev Content-Length: 918 Lines: 25 On Tue, 8 Mar 2005, jamal wrote: > Lets see, your requirements are: > a) packets within a chasis subnet shall stay within a chasis subnet > b) the outside (of the chasis) world shall never discover whats inside > the chasis (example ARPs will fail to resolve etc) > Did i miss anything else? Yes. c) The chassis components must interact properly with other external equipment using public or RFC1918 addresses. So while yes, it may be possible to use RFC1918 addresses, but only if the network administrator connecting the chassi first enters a RFC1918 network he has reserved for "equipment internal" use into the chassis configuration to ensure the internal addressing within the chassis does not conflict with the addressing used on his private network. This even if these addresses is never seen anywhere outside of the chassis (except possibly diagnostics channels into the chassis). Regards Henrik From hno@marasystems.com Tue Mar 8 10:41:12 2005 Received: with ECARTIS (v1.0.0; list netdev); Tue, 08 Mar 2005 10:41:15 -0800 (PST) Received: from filer.marasystems.com (marasystems.com [83.241.133.2]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j28IfAHJ022374 for ; Tue, 8 Mar 2005 10:41:11 -0800 Received: from localhost (henrik@localhost) by filer.marasystems.com (8.11.6/8.11.6) with ESMTP id j28Ie3e05472; Tue, 8 Mar 2005 19:40:03 +0100 Date: Tue, 8 Mar 2005 19:40:03 +0100 (CET) From: Henrik Nordstrom To: jamal cc: Martin Mares , Zdenek Radouch , Steve Iribarne , Eran Mann , Thomas Graf , Andi Kleen , netdev@oss.sgi.com, linux-net@vger.kernel.org Subject: Re: Do you know the TCP stack? (127.x.x.x routing) In-Reply-To: <1110291470.1043.211.camel@jzny.localdomain> Message-ID: References: <20050306173145.GQ31837@postel.suug.ch> <3sp35g$7hpm0@smtp04.mrf.mail.rcn.net> <422C0B50.20500@mrv.com> <3sp35g$7rsc1@smtp04.mrf.mail.rcn.net> <1110288879.1050.167.camel@jzny.localdomain> <20050308135134.GA20607@atrey.karlin.mff.cuni.cz> <1110290300.1050.190.camel@jzny.localdomain> <20050308140301.GC20607@atrey.karlin.mff.cuni.cz> <1110291470.1043.211.camel@jzny.localdomain> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Virus-Scanned: ClamAV 0.83/755/Mon Mar 7 17:00:18 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 2673 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: hno@marasystems.com Precedence: bulk X-list: netdev Content-Length: 706 Lines: 19 On Tue, 8 Mar 2005, jamal wrote: > Aha! Thanks for clarifying this. So the problem domain is: "IP address > conflict" detection and somehow this is seen as a resolution to that > problem. > So what happens when you put tow or three of Zdenek's boxes in one > location? Back to square 1? Not if the 127.X addresses never leaves the Zdenek's boxes, when thinking in terms that each set of boxes communicating using 127.X addresses is a single chassis, seen as a single box to the network admin. > Except this wont be practical for IPV4 since those addresses are scarce. > May make sense for V6 though (becomes like MAC addresses on NICS). IPv6 already have link local addressing IIRC. Regards Henrik From arnaldo.melo@gmail.com Tue Mar 8 10:52:04 2005 Received: with ECARTIS (v1.0.0; list netdev); Tue, 08 Mar 2005 10:52:10 -0800 (PST) Received: from rproxy.gmail.com (rproxy.gmail.com [64.233.170.194]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j28Iq3da023719 for ; Tue, 8 Mar 2005 10:52:04 -0800 Received: by rproxy.gmail.com with SMTP id c51so1544470rne for ; Tue, 08 Mar 2005 10:52:01 -0800 (PST) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:reply-to:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:references; b=NrF77u0Od6h6SUT0biLuU/NkOdo887hju75QRJesePewJe+jkJH1Bqv9q9xi4kprJJpPlhFMHMzbuLzS8u6ZuiZ1mzyhejGYGK5eVYD0AM41rZWimdvjXXyj7qu4nFERfBRqh/nrZoOMxmPex3xhFH+sjq67u5Aveam6g3XBiG8= Received: by 10.38.181.13 with SMTP id d13mr58860rnf; Tue, 08 Mar 2005 10:51:58 -0800 (PST) Received: by 10.54.10.49 with HTTP; Tue, 8 Mar 2005 10:51:58 -0800 (PST) Message-ID: <39e6f6c705030810515795ccb6@mail.gmail.com> Date: Tue, 8 Mar 2005 15:51:58 -0300 From: Arnaldo Carvalho de Melo Reply-To: acme@conectiva.com.br To: Thomas Graf Subject: Re: netif_rx packet dumping Cc: Andi Kleen , "David S. Miller" , baruch@ev-en.org, shemminger@osdl.org, netdev@oss.sgi.com In-Reply-To: <20050308183759.GE31837@postel.suug.ch> Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit References: <20050303123811.4d934249@dxpl.pdx.osdl.net> <42278122.6000000@ev-en.org> <20050303133659.0d224e61.davem@davemloft.net> <42278554.2090902@ev-en.org> <20050303135718.2e1a0170.davem@davemloft.net> <422DC7CE.2040800@ev-en.org> <20050308100902.24b67b2f.davem@davemloft.net> <20050308181844.GA37392@muc.de> <20050308183759.GE31837@postel.suug.ch> X-Virus-Scanned: ClamAV 0.83/755/Mon Mar 7 17:00:18 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 2674 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: arnaldo.melo@gmail.com Precedence: bulk X-list: netdev Content-Length: 930 Lines: 24 On Tue, 8 Mar 2005 19:37:59 +0100, Thomas Graf wrote: > Speaking of it, I see tcp_sock is marginal over 2**10 on 32 bit archs and > Stephen's plans to outsource the cc bits brings us closer to the border. > Would it be worth to try and get it below 2**10? I spotted some places > for optimizations but not enough to really save the needed amount. sk_protinfo, sk_slab, sk_zapped are going away when I finish my connection_sock-2.6 series. sk_protinfo isn't needed if all proto families use the sk_alloc + kmalloc, i.e. specifying the size of the proto specific socket (like tcp_sock) in "zero_it" and passing NULL in the slab parameter, like I did with bluetooth today and will do with the ham radio, the last ones using sk_protinfo. sk_slab will be get from only in sk->sk_prot->slab. sk_zapped was just a debugging member that got reused, and can be turned into a SOCK_ZAPPED in sk_flags. -- - Arnaldo From jgarzik@pobox.com Tue Mar 8 11:32:16 2005 Received: with ECARTIS (v1.0.0; list netdev); Tue, 08 Mar 2005 11:32:54 -0800 (PST) Received: from parcelfarce.linux.theplanet.co.uk (IDENT:93@parcelfarce.linux.theplanet.co.uk [195.92.249.252]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j28JWA8X025277 for ; Tue, 8 Mar 2005 11:32:11 -0800 Received: from [69.134.152.124] (helo=[10.10.10.88]) by parcelfarce.linux.theplanet.co.uk with asmtp (TLSv1:AES256-SHA:256) (Exim 4.33) id 1D8kQx-0000Nc-QT; Tue, 08 Mar 2005 19:32:09 +0000 Message-ID: <422DFDA1.6080108@pobox.com> Date: Tue, 08 Mar 2005 14:31:45 -0500 From: Jeff Garzik User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.3) Gecko/20040922 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Andrew Morton , Linus Torvalds CC: Netdev , Linux Kernel Subject: [BK PATCHES] 2.6.x net driver updates Content-Type: multipart/mixed; boundary="------------040800020201020107010706" X-Virus-Scanned: ClamAV 0.83/755/Mon Mar 7 17:00:18 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 2675 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: jgarzik@pobox.com Precedence: bulk X-list: netdev Content-Length: 390953 Lines: 11834 This is a multi-part message in MIME format. --------------040800020201020107010706 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Changes: * viro's iomap/iomem updates * ham, mv643xx, orinoco updates * sis900, via-rhine updates --------------040800020201020107010706 Content-Type: text/plain; name="changelog.txt" Content-Transfer-Encoding: 8bit Content-Disposition: inline; filename="changelog.txt" Please do a bk pull bk://gkernel.bkbits.net/net-drivers-2.6 This will update the following files: drivers/net/Kconfig | 5 drivers/net/fealnx.c | 275 +-- drivers/net/hamradio/6pack.c | 4 drivers/net/hamradio/baycom_epp.c | 53 drivers/net/hamradio/baycom_par.c | 8 drivers/net/hamradio/baycom_ser_fdx.c | 7 drivers/net/hamradio/baycom_ser_hdx.c | 7 drivers/net/hamradio/bpqether.c | 19 drivers/net/hamradio/dmascc.c | 2073 +++++++++++++------------- drivers/net/hamradio/hdlcdrv.c | 48 drivers/net/hamradio/mkiss.c | 12 drivers/net/hamradio/yam.c | 38 drivers/net/mv643xx_eth.c | 2687 +++++++++++++++++++--------------- drivers/net/mv643xx_eth.h | 641 +++----- drivers/net/sis900.c | 216 +- drivers/net/via-rhine.c | 4 drivers/net/wireless/airport.c | 22 drivers/net/wireless/hermes.c | 72 drivers/net/wireless/hermes.h | 64 drivers/net/wireless/orinoco.c | 419 +++-- drivers/net/wireless/orinoco.h | 37 drivers/net/wireless/orinoco_cs.c | 49 drivers/net/wireless/orinoco_pci.c | 124 - drivers/net/wireless/orinoco_plx.c | 235 +- drivers/net/wireless/orinoco_tmd.c | 150 + include/linux/mv643xx.h | 448 ++++- 26 files changed, 4187 insertions(+), 3530 deletions(-) through these ChangeSets: : o [netdrvr mv643xx] Big rename o [netdrvr mv643xx] Rename MV_READ => mv_read and MV_WRITE => mv_write o [netdrvr mv643xx] Additional whitespace cleanups, mostly changing spaces to tabs in comments o [netdrvr mv643xx] Run mv643xx_eth.[ch] through scripts/Lindent o [netdrvr mv643xx] Add a function to detect at runtime whether a PHY is attached to the specified port, and use it to cause the probe routine to fail when there is no PHY. o [netdrvr mv643xx] This one liner removes a spurious left paren fixing an obvious syntax error in the #ifndef MV64340_NAPI case o [netdrvr mv643xx] Add support for PHYs/boards that don't support autonegotiation o [netdrvr mv643xx] With this patch, the driver now calls netif_carrier_off/netif_carrier_on o [netdrvr mv643xx] This patch cleans up the handling of receive skb sizing : o sis900.c net poll support : o Possible VIA-Rhine free irq issue Alexander Viro: o fealnx iomem annotations, switch to io{read,write} o wireless iomem annotations and fixes, switch to io{read,write} Andrew Morton: o VIA-Rhine: undork whitespace Dale Farnsworth: o mv643xx: remove superfluous function, mv643xx_set_ethtool_ops o mv643xx: raise size of receive skbs to allow for an optional VLAN tag o [netdrvr mv643xx] Remove call to msleep() while locks are held. We don't really need to wait for the link to come up. It was a workaround to avoid a transient error message, "Virtual device %s asks to queue packet!\n", in dev_queue_xmit() when called by ic_bootp_send_if(). This happens because right after opening the network device, there is a pending PHY status change interrupt causing the driver to call netif_stop_queue(). A half second later, the link comes up and all is well. We could have moved the call to msleep() to mv643xx_eth_open() to perpetuate the workaround, but I think it's best to remove it entirely. o [netdrvr mv643xx] Ensure that we only change the Port Serial Control Reg while the port is disabled. o [netdrvr mv643xx] Add ethtool support to the mv643xx ethernet driver o [netdrvr mv643xx] Enable the mv643xx ethernet support on platforms using the MV64360 chip o [netdrvr mv643xx] Disable tcp/udp checksum offload to hardware. It generally works, but the hardware appears to generate the wrong checksum if the hw checksum generation wasn't used in the previous packet sent. o [netdrvr mv643xx] We already set ETH_TX_ENABLE_INTERRUPT whenever we set ETH_TX_LAST_DESC o [netdrvr mv643xx] Update tx_bytes statistic when using hw tcp/udp checksum generation o [netdrvr mv643xx] Call netif_carrier_off when closing the driver o [netdrvr mv643xx] Trivial. Remove repeated comment o [netdrvr mv643xx] Clear transmit l4i_chk even when the hardware ignores it o [netdrvr mv643xx] Increment tx_ring_skbs before calling eth_port_send, since o [netdrvr mv643xx] Fix handling of unaligned tiny fragments not handled by hardware Check all fragments instead of just the last. o [netdrvr mv643xx] Fix a few places I missed in the previous rename patch o [netdrvr mv643xx] This patch simplifies the mv64340_eth_set_rx_mode function without changing its behavior. o [netdrvr mv643xx] This patch makes the use of the MV64340_RX_QUEUE_FILL_ON_TASK config macro more consistent, though the macro remains undefined, since the feature still does not work properly. o [netdrvr mv643xx] This patch adds support for passing additional parameters via the platform_device interface. These additional parameters are: o [netdrvr mv643xx] This patch adds device driver model support to the mv643xx_eth driver o [netdrvr mv643xx] This patch replaces the use of the pci_map_* functions with the corresponding dma_map_* functions. o [netdrvr mv643xx] This patch fixes the code that enables hardware checksum generation o [netdrvr mv643xx] This patch removes spin delays (count to 1000000, ugh) and instead waits with udelay or msleep for hardware flags to change. o [netdrvr mv643xx] This patch removes code that is redundant or useless Daniele Venzano: o sis900: chiprev i/o cleanups o sis900: debugging output update o sis900 printk audit o sis900: version bump; remove broken URL o sis900: add infrastructure needed for standard netif messages David Gibson: o Orinoco driver updates - cleanup PCI initialization o Orinoco driver updates - PCMCIA initialization cleanups o Orinoco driver updates - update version and changelog o Orinoco driver updates - update firmware detection o Orinoco driver updates - WEP updates o Orinoco driver updates - delay Tx wake o Orinoco driver updates - prohibit IBSS with no ESSID o Orinoco driver updates - update is_ethersnap() o Orinoco driver updates - PCMCIA initialization cleanups o Orinoco driver updates - use modern module_parm() o Orinoco driver updates - cleanup PCI initialization o Orinoco driver updates - cleanup low-level code o Orinoco driver updates - add free_orinocodev() o Orinoco driver updates - use mdelay()/ssleep() more o Orinoco driver updates - update printk()s o Orinoco driver updates - use netif_carrier_*() Ralf Bächle: o Remove unused MAXBPQDEV definition o Sparse fixes for drivers/net/hamradio o Reformat DMASCC driver o Use netdev_priv in baycom_epp driver o Use netdev_priv in baycom_ser_fdx driver o Use netdev_priv in hdlcdrv driver o Use netdev_priv in baycom_ser_hdx driver o Use netdev_priv in baycom_par driver o Use netdev_priv in bpqether driver o Use netdev_priv in mkiss driver o Use netdev_priv in YAM driver --------------040800020201020107010706 Content-Type: text/plain; name="patch" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="patch" diff -Nru a/drivers/net/Kconfig b/drivers/net/Kconfig --- a/drivers/net/Kconfig 2005-03-08 14:29:45 -05:00 +++ b/drivers/net/Kconfig 2005-03-08 14:29:45 -05:00 @@ -2066,10 +2066,11 @@ config MV643XX_ETH tristate "MV-643XX Ethernet support" - depends on MOMENCO_OCELOT_C || MOMENCO_JAGUAR_ATX || MOMENCO_OCELOT_3 + depends on MOMENCO_OCELOT_C || MOMENCO_JAGUAR_ATX || MV64360 || MOMENCO_OCELOT_3 help This driver supports the gigabit Ethernet on the Marvell MV643XX - chipset which is used in the Momenco Ocelot C and Jaguar ATX. + chipset which is used in the Momenco Ocelot C and Jaguar ATX and + Pegasos II, amongst other PPC and MIPS boards. config MV643XX_ETH_0 bool "MV-643XX Port 0" diff -Nru a/drivers/net/fealnx.c b/drivers/net/fealnx.c --- a/drivers/net/fealnx.c 2005-03-08 14:29:45 -05:00 +++ b/drivers/net/fealnx.c 2005-03-08 14:29:45 -05:00 @@ -102,21 +102,6 @@ #define USE_IO_OPS #endif -#ifdef USE_IO_OPS -#undef readb -#undef readw -#undef readl -#undef writeb -#undef writew -#undef writel -#define readb inb -#define readw inw -#define readl inl -#define writeb outb -#define writew outw -#define writel outl -#endif - /* Kernel compatibility defines, some common to David Hinds' PCMCIA package. */ /* This is only in the support-all-kernels source code. */ @@ -444,6 +429,7 @@ int mii_cnt; /* MII device addresses. */ unsigned char phys[2]; /* MII device addresses. */ struct mii_if_info mii; + void __iomem *mem; }; @@ -468,23 +454,23 @@ static void reset_rx_descriptors(struct net_device *dev); static void reset_tx_descriptors(struct net_device *dev); -static void stop_nic_rx(long ioaddr, long crvalue) +static void stop_nic_rx(void __iomem *ioaddr, long crvalue) { int delay = 0x1000; - writel(crvalue & ~(CR_W_RXEN), ioaddr + TCRRCR); + iowrite32(crvalue & ~(CR_W_RXEN), ioaddr + TCRRCR); while (--delay) { - if ( (readl(ioaddr + TCRRCR) & CR_R_RXSTOP) == CR_R_RXSTOP) + if ( (ioread32(ioaddr + TCRRCR) & CR_R_RXSTOP) == CR_R_RXSTOP) break; } } -static void stop_nic_rxtx(long ioaddr, long crvalue) +static void stop_nic_rxtx(void __iomem *ioaddr, long crvalue) { int delay = 0x1000; - writel(crvalue & ~(CR_W_RXEN+CR_W_TXEN), ioaddr + TCRRCR); + iowrite32(crvalue & ~(CR_W_RXEN+CR_W_TXEN), ioaddr + TCRRCR); while (--delay) { - if ( (readl(ioaddr + TCRRCR) & (CR_R_RXSTOP+CR_R_TXSTOP)) + if ( (ioread32(ioaddr + TCRRCR) & (CR_R_RXSTOP+CR_R_TXSTOP)) == (CR_R_RXSTOP+CR_R_TXSTOP) ) break; } @@ -498,11 +484,17 @@ int i, option, err, irq; static int card_idx = -1; char boardname[12]; - long ioaddr; + void __iomem *ioaddr; + unsigned long len; unsigned int chip_id = ent->driver_data; struct net_device *dev; void *ring_space; dma_addr_t ring_dma; +#ifdef USE_IO_OPS + int bar = 0; +#else + int bar = 1; +#endif /* when built into the kernel, we only print version if device is found */ #ifndef MODULE @@ -520,14 +512,10 @@ if (i) return i; pci_set_master(pdev); -#ifdef USE_IO_OPS - ioaddr = pci_resource_len(pdev, 0); -#else - ioaddr = pci_resource_len(pdev, 1); -#endif - if (ioaddr < MIN_REGION_SIZE) { + len = pci_resource_len(pdev, bar); + if (len < MIN_REGION_SIZE) { printk(KERN_ERR "%s: region size %ld too small, aborting\n", - boardname, ioaddr); + boardname, len); return -ENODEV; } @@ -536,17 +524,12 @@ irq = pdev->irq; -#ifdef USE_IO_OPS - ioaddr = pci_resource_start(pdev, 0); -#else - ioaddr = (long) ioremap(pci_resource_start(pdev, 1), - pci_resource_len(pdev, 1)); + ioaddr = pci_iomap(pdev, bar, len); if (!ioaddr) { err = -ENOMEM; goto err_out_res; } -#endif - + dev = alloc_etherdev(sizeof(struct netdev_private)); if (!dev) { err = -ENOMEM; @@ -557,16 +540,17 @@ /* read ethernet id */ for (i = 0; i < 6; ++i) - dev->dev_addr[i] = readb(ioaddr + PAR0 + i); + dev->dev_addr[i] = ioread8(ioaddr + PAR0 + i); /* Reset the chip to erase previous misconfiguration. */ - writel(0x00000001, ioaddr + BCR); + iowrite32(0x00000001, ioaddr + BCR); - dev->base_addr = ioaddr; + dev->base_addr = (unsigned long)ioaddr; dev->irq = irq; /* Make certain the descriptor lists are aligned. */ - np = dev->priv; + np = netdev_priv(dev); + np->mem = ioaddr; spin_lock_init(&np->lock); np->pci_dev = pdev; np->flags = skel_netdrv_tbl[chip_id].flags; @@ -635,7 +619,7 @@ np->phys[0] = 32; /* 89/6/23 add, (begin) */ /* get phy type */ - if (readl(ioaddr + PHYIDENTIFIER) == MysonPHYID) + if (ioread32(ioaddr + PHYIDENTIFIER) == MysonPHYID) np->PHYType = MysonPHY; else np->PHYType = OtherPHY; @@ -670,7 +654,7 @@ if (np->flags == HAS_MII_XCVR) mdio_write(dev, np->phys[0], MII_ADVERTISE, ADVERTISE_FULL); else - writel(ADVERTISE_FULL, ioaddr + ANARANLPAR); + iowrite32(ADVERTISE_FULL, ioaddr + ANARANLPAR); np->mii.force_media = 1; } @@ -689,7 +673,7 @@ if (err) goto err_out_free_tx; - printk(KERN_INFO "%s: %s at 0x%lx, ", + printk(KERN_INFO "%s: %s at %p, ", dev->name, skel_netdrv_tbl[chip_id].chip_name, ioaddr); for (i = 0; i < 5; i++) printk("%2.2x:", dev->dev_addr[i]); @@ -704,10 +688,8 @@ err_out_free_dev: free_netdev(dev); err_out_unmap: -#ifndef USE_IO_OPS - iounmap((void *)ioaddr); + pci_iounmap(pdev, ioaddr); err_out_res: -#endif pci_release_regions(pdev); return err; } @@ -718,16 +700,14 @@ struct net_device *dev = pci_get_drvdata(pdev); if (dev) { - struct netdev_private *np = dev->priv; + struct netdev_private *np = netdev_priv(dev); pci_free_consistent(pdev, TX_TOTAL_SIZE, np->tx_ring, np->tx_ring_dma); pci_free_consistent(pdev, RX_TOTAL_SIZE, np->rx_ring, np->rx_ring_dma); unregister_netdev(dev); -#ifndef USE_IO_OPS - iounmap((void *)dev->base_addr); -#endif + pci_iounmap(pdev, np->mem); free_netdev(dev); pci_release_regions(pdev); pci_set_drvdata(pdev, NULL); @@ -736,14 +716,14 @@ } -static ulong m80x_send_cmd_to_phy(long miiport, int opcode, int phyad, int regad) +static ulong m80x_send_cmd_to_phy(void __iomem *miiport, int opcode, int phyad, int regad) { ulong miir; int i; unsigned int mask, data; /* enable MII output */ - miir = (ulong) readl(miiport); + miir = (ulong) ioread32(miiport); miir &= 0xfffffff0; miir |= MASK_MIIR_MII_WRITE + MASK_MIIR_MII_MDO; @@ -752,11 +732,11 @@ for (i = 0; i < 32; i++) { /* low MDC; MDO is already high (miir) */ miir &= ~MASK_MIIR_MII_MDC; - writel(miir, miiport); + iowrite32(miir, miiport); /* high MDC */ miir |= MASK_MIIR_MII_MDC; - writel(miir, miiport); + iowrite32(miir, miiport); } /* calculate ST+OP+PHYAD+REGAD+TA */ @@ -770,10 +750,10 @@ if (mask & data) miir |= MASK_MIIR_MII_MDO; - writel(miir, miiport); + iowrite32(miir, miiport); /* high MDC */ miir |= MASK_MIIR_MII_MDC; - writel(miir, miiport); + iowrite32(miir, miiport); udelay(30); /* next */ @@ -787,7 +767,8 @@ static int mdio_read(struct net_device *dev, int phyad, int regad) { - long miiport = dev->base_addr + MANAGEMENT; + struct netdev_private *np = netdev_priv(dev); + void __iomem *miiport = np->mem + MANAGEMENT; ulong miir; unsigned int mask, data; @@ -799,16 +780,16 @@ while (mask) { /* low MDC */ miir &= ~MASK_MIIR_MII_MDC; - writel(miir, miiport); + iowrite32(miir, miiport); /* read MDI */ - miir = readl(miiport); + miir = ioread32(miiport); if (miir & MASK_MIIR_MII_MDI) data |= mask; /* high MDC, and wait */ miir |= MASK_MIIR_MII_MDC; - writel(miir, miiport); + iowrite32(miir, miiport); udelay(30); /* next */ @@ -817,7 +798,7 @@ /* low MDC */ miir &= ~MASK_MIIR_MII_MDC; - writel(miir, miiport); + iowrite32(miir, miiport); return data & 0xffff; } @@ -825,7 +806,8 @@ static void mdio_write(struct net_device *dev, int phyad, int regad, int data) { - long miiport = dev->base_addr + MANAGEMENT; + struct netdev_private *np = netdev_priv(dev); + void __iomem *miiport = np->mem + MANAGEMENT; ulong miir; unsigned int mask; @@ -838,11 +820,11 @@ miir &= ~(MASK_MIIR_MII_MDC + MASK_MIIR_MII_MDO); if (mask & data) miir |= MASK_MIIR_MII_MDO; - writel(miir, miiport); + iowrite32(miir, miiport); /* high MDC */ miir |= MASK_MIIR_MII_MDC; - writel(miir, miiport); + iowrite32(miir, miiport); /* next */ mask >>= 1; @@ -850,29 +832,29 @@ /* low MDC */ miir &= ~MASK_MIIR_MII_MDC; - writel(miir, miiport); + iowrite32(miir, miiport); } static int netdev_open(struct net_device *dev) { - struct netdev_private *np = dev->priv; - long ioaddr = dev->base_addr; + struct netdev_private *np = netdev_priv(dev); + void __iomem *ioaddr = np->mem; int i; - writel(0x00000001, ioaddr + BCR); /* Reset */ + iowrite32(0x00000001, ioaddr + BCR); /* Reset */ if (request_irq(dev->irq, &intr_handler, SA_SHIRQ, dev->name, dev)) return -EAGAIN; for (i = 0; i < 3; i++) - writew(((unsigned short*)dev->dev_addr)[i], + iowrite16(((unsigned short*)dev->dev_addr)[i], ioaddr + PAR0 + i*2); init_ring(dev); - writel(np->rx_ring_dma, ioaddr + RXLBA); - writel(np->tx_ring_dma, ioaddr + TXLBA); + iowrite32(np->rx_ring_dma, ioaddr + RXLBA); + iowrite32(np->tx_ring_dma, ioaddr + TXLBA); /* Initialize other registers. */ /* Configure the PCI bus bursts and FIFO thresholds. @@ -933,12 +915,12 @@ np->crvalue |= CR_W_ENH; /* set enhanced bit */ np->imrvalue |= ETI; } - writel(np->bcrvalue, ioaddr + BCR); + iowrite32(np->bcrvalue, ioaddr + BCR); if (dev->if_port == 0) dev->if_port = np->default_port; - writel(0, ioaddr + RXPDR); + iowrite32(0, ioaddr + RXPDR); // 89/9/1 modify, // np->crvalue = 0x00e40001; /* tx store and forward, tx/rx enable */ np->crvalue |= 0x00e40001; /* tx store and forward, tx/rx enable */ @@ -951,8 +933,8 @@ netif_start_queue(dev); /* Clear and Enable interrupts by setting the interrupt mask. */ - writel(FBE | TUNF | CNTOVF | RBU | TI | RI, ioaddr + ISR); - writel(np->imrvalue, ioaddr + IMR); + iowrite32(FBE | TUNF | CNTOVF | RBU | TI | RI, ioaddr + ISR); + iowrite32(np->imrvalue, ioaddr + IMR); if (debug) printk(KERN_DEBUG "%s: Done netdev_open().\n", dev->name); @@ -980,14 +962,14 @@ /* input : dev... pointer to the adapter block. */ /* output : none. */ { - struct netdev_private *np = dev->priv; + struct netdev_private *np = netdev_priv(dev); unsigned int i, DelayTime = 0x1000; np->linkok = 0; if (np->PHYType == MysonPHY) { for (i = 0; i < DelayTime; ++i) { - if (readl(dev->base_addr + BMCRSR) & LinkIsUp2) { + if (ioread32(np->mem + BMCRSR) & LinkIsUp2) { np->linkok = 1; return; } @@ -1007,14 +989,14 @@ static void getlinktype(struct net_device *dev) { - struct netdev_private *np = dev->priv; + struct netdev_private *np = netdev_priv(dev); if (np->PHYType == MysonPHY) { /* 3-in-1 case */ - if (readl(dev->base_addr + TCRRCR) & CR_R_FD) + if (ioread32(np->mem + TCRRCR) & CR_R_FD) np->duplexmode = 2; /* full duplex */ else np->duplexmode = 1; /* half duplex */ - if (readl(dev->base_addr + TCRRCR) & CR_R_PS10) + if (ioread32(np->mem + TCRRCR) & CR_R_PS10) np->line_speed = 1; /* 10M */ else np->line_speed = 2; /* 100M */ @@ -1110,7 +1092,7 @@ /* Take lock before calling this */ static void allocate_rx_buffers(struct net_device *dev) { - struct netdev_private *np = dev->priv; + struct netdev_private *np = netdev_priv(dev); /* allocate skb for rx buffers */ while (np->really_rx_count != RX_RING_SIZE) { @@ -1136,16 +1118,16 @@ static void netdev_timer(unsigned long data) { struct net_device *dev = (struct net_device *) data; - struct netdev_private *np = dev->priv; - long ioaddr = dev->base_addr; + struct netdev_private *np = netdev_priv(dev); + void __iomem *ioaddr = np->mem; int old_crvalue = np->crvalue; unsigned int old_linkok = np->linkok; unsigned long flags; if (debug) printk(KERN_DEBUG "%s: Media selection timer tick, status %8.8x " - "config %8.8x.\n", dev->name, readl(ioaddr + ISR), - readl(ioaddr + TCRRCR)); + "config %8.8x.\n", dev->name, ioread32(ioaddr + ISR), + ioread32(ioaddr + TCRRCR)); spin_lock_irqsave(&np->lock, flags); @@ -1155,7 +1137,7 @@ getlinktype(dev); if (np->crvalue != old_crvalue) { stop_nic_rxtx(ioaddr, np->crvalue); - writel(np->crvalue, ioaddr + TCRRCR); + iowrite32(np->crvalue, ioaddr + TCRRCR); } } } @@ -1173,22 +1155,23 @@ /* Reset chip and disable rx, tx and interrupts */ static void reset_and_disable_rxtx(struct net_device *dev) { - long ioaddr = dev->base_addr; + struct netdev_private *np = netdev_priv(dev); + void __iomem *ioaddr = np->mem; int delay=51; /* Reset the chip's Tx and Rx processes. */ stop_nic_rxtx(ioaddr, 0); /* Disable interrupts by clearing the interrupt mask. */ - writel(0, ioaddr + IMR); + iowrite32(0, ioaddr + IMR); /* Reset the chip to erase previous misconfiguration. */ - writel(0x00000001, ioaddr + BCR); + iowrite32(0x00000001, ioaddr + BCR); /* Ueimor: wait for 50 PCI cycles (and flush posted writes btw). We surely wait too long (address+data phase). Who cares? */ while (--delay) { - readl(ioaddr + BCR); + ioread32(ioaddr + BCR); rmb(); } } @@ -1198,33 +1181,33 @@ /* Restore chip after reset */ static void enable_rxtx(struct net_device *dev) { - struct netdev_private *np = dev->priv; - long ioaddr = dev->base_addr; + struct netdev_private *np = netdev_priv(dev); + void __iomem *ioaddr = np->mem; reset_rx_descriptors(dev); - writel(np->tx_ring_dma + ((char*)np->cur_tx - (char*)np->tx_ring), + iowrite32(np->tx_ring_dma + ((char*)np->cur_tx - (char*)np->tx_ring), ioaddr + TXLBA); - writel(np->rx_ring_dma + ((char*)np->cur_rx - (char*)np->rx_ring), + iowrite32(np->rx_ring_dma + ((char*)np->cur_rx - (char*)np->rx_ring), ioaddr + RXLBA); - writel(np->bcrvalue, ioaddr + BCR); + iowrite32(np->bcrvalue, ioaddr + BCR); - writel(0, ioaddr + RXPDR); + iowrite32(0, ioaddr + RXPDR); __set_rx_mode(dev); /* changes np->crvalue, writes it into TCRRCR */ /* Clear and Enable interrupts by setting the interrupt mask. */ - writel(FBE | TUNF | CNTOVF | RBU | TI | RI, ioaddr + ISR); - writel(np->imrvalue, ioaddr + IMR); + iowrite32(FBE | TUNF | CNTOVF | RBU | TI | RI, ioaddr + ISR); + iowrite32(np->imrvalue, ioaddr + IMR); - writel(0, ioaddr + TXPDR); + iowrite32(0, ioaddr + TXPDR); } static void reset_timer(unsigned long data) { struct net_device *dev = (struct net_device *) data; - struct netdev_private *np = dev->priv; + struct netdev_private *np = netdev_priv(dev); unsigned long flags; printk(KERN_WARNING "%s: resetting tx and rx machinery\n", dev->name); @@ -1247,13 +1230,13 @@ static void tx_timeout(struct net_device *dev) { - struct netdev_private *np = dev->priv; - long ioaddr = dev->base_addr; + struct netdev_private *np = netdev_priv(dev); + void __iomem *ioaddr = np->mem; unsigned long flags; int i; printk(KERN_WARNING "%s: Transmit timed out, status %8.8x," - " resetting...\n", dev->name, readl(ioaddr + ISR)); + " resetting...\n", dev->name, ioread32(ioaddr + ISR)); { printk(KERN_DEBUG " Rx ring %p: ", np->rx_ring); @@ -1282,7 +1265,7 @@ /* Initialize the Rx and Tx rings, along with various 'dev' bits. */ static void init_ring(struct net_device *dev) { - struct netdev_private *np = dev->priv; + struct netdev_private *np = netdev_priv(dev); int i; /* initialize rx variables */ @@ -1346,7 +1329,7 @@ static int start_tx(struct sk_buff *skb, struct net_device *dev) { - struct netdev_private *np = dev->priv; + struct netdev_private *np = netdev_priv(dev); unsigned long flags; spin_lock_irqsave(&np->lock, flags); @@ -1413,7 +1396,7 @@ if (np->free_tx_count < 2) netif_stop_queue(dev); ++np->really_tx_count; - writel(0, dev->base_addr + TXPDR); + iowrite32(0, np->mem + TXPDR); dev->trans_start = jiffies; spin_unlock_irqrestore(&np->lock, flags); @@ -1425,7 +1408,7 @@ /* Chip probably hosed tx ring. Clean up. */ static void reset_tx_descriptors(struct net_device *dev) { - struct netdev_private *np = dev->priv; + struct netdev_private *np = netdev_priv(dev); struct fealnx_desc *cur; int i; @@ -1460,7 +1443,7 @@ /* Take lock and stop rx before calling this */ static void reset_rx_descriptors(struct net_device *dev) { - struct netdev_private *np = dev->priv; + struct netdev_private *np = netdev_priv(dev); struct fealnx_desc *cur = np->cur_rx; int i; @@ -1472,8 +1455,8 @@ cur = cur->next_desc_logical; } - writel(np->rx_ring_dma + ((char*)np->cur_rx - (char*)np->rx_ring), - dev->base_addr + RXLBA); + iowrite32(np->rx_ring_dma + ((char*)np->cur_rx - (char*)np->rx_ring), + np->mem + RXLBA); } @@ -1482,21 +1465,21 @@ static irqreturn_t intr_handler(int irq, void *dev_instance, struct pt_regs *rgs) { struct net_device *dev = (struct net_device *) dev_instance; - struct netdev_private *np = dev->priv; - long ioaddr = dev->base_addr; + struct netdev_private *np = netdev_priv(dev); + void __iomem *ioaddr = np->mem; long boguscnt = max_interrupt_work; unsigned int num_tx = 0; int handled = 0; spin_lock(&np->lock); - writel(0, ioaddr + IMR); + iowrite32(0, ioaddr + IMR); do { - u32 intr_status = readl(ioaddr + ISR); + u32 intr_status = ioread32(ioaddr + ISR); /* Acknowledge all of the current interrupt sources ASAP. */ - writel(intr_status, ioaddr + ISR); + iowrite32(intr_status, ioaddr + ISR); if (debug) printk(KERN_DEBUG "%s: Interrupt, status %4.4x.\n", dev->name, @@ -1517,15 +1500,15 @@ // }; if (intr_status & TUNF) - writel(0, ioaddr + TXPDR); + iowrite32(0, ioaddr + TXPDR); if (intr_status & CNTOVF) { /* missed pkts */ - np->stats.rx_missed_errors += readl(ioaddr + TALLY) & 0x7fff; + np->stats.rx_missed_errors += ioread32(ioaddr + TALLY) & 0x7fff; /* crc error */ np->stats.rx_crc_errors += - (readl(ioaddr + TALLY) & 0x7fff0000) >> 16; + (ioread32(ioaddr + TALLY) & 0x7fff0000) >> 16; } if (intr_status & (RI | RBU)) { @@ -1534,7 +1517,7 @@ else { stop_nic_rx(ioaddr, np->crvalue); reset_rx_descriptors(dev); - writel(np->crvalue, ioaddr + TCRRCR); + iowrite32(np->crvalue, ioaddr + TCRRCR); } } @@ -1605,7 +1588,7 @@ if (np->crvalue & CR_W_ENH) { long data; - data = readl(ioaddr + TSR); + data = ioread32(ioaddr + TSR); np->stats.tx_errors += (data & 0xff000000) >> 24; np->stats.tx_aborted_errors += (data & 0xff000000) >> 24; np->stats.tx_window_errors += (data & 0x00ff0000) >> 16; @@ -1635,16 +1618,16 @@ /* read the tally counters */ /* missed pkts */ - np->stats.rx_missed_errors += readl(ioaddr + TALLY) & 0x7fff; + np->stats.rx_missed_errors += ioread32(ioaddr + TALLY) & 0x7fff; /* crc error */ - np->stats.rx_crc_errors += (readl(ioaddr + TALLY) & 0x7fff0000) >> 16; + np->stats.rx_crc_errors += (ioread32(ioaddr + TALLY) & 0x7fff0000) >> 16; if (debug) printk(KERN_DEBUG "%s: exiting interrupt, status=%#4.4x.\n", - dev->name, readl(ioaddr + ISR)); + dev->name, ioread32(ioaddr + ISR)); - writel(np->imrvalue, ioaddr + IMR); + iowrite32(np->imrvalue, ioaddr + IMR); spin_unlock(&np->lock); @@ -1656,8 +1639,8 @@ for clarity and better register allocation. */ static int netdev_rx(struct net_device *dev) { - struct netdev_private *np = dev->priv; - long ioaddr = dev->base_addr; + struct netdev_private *np = netdev_priv(dev); + void __iomem *ioaddr = np->mem; /* If EOP is set on the next entry, it's a new packet. Send it up. */ while (!(np->cur_rx->status & RXOWN) && np->cur_rx->skbuff) { @@ -1725,7 +1708,7 @@ } else { /* rx error, need to reset this chip */ stop_nic_rx(ioaddr, np->crvalue); reset_rx_descriptors(dev); - writel(np->crvalue, ioaddr + TCRRCR); + iowrite32(np->crvalue, ioaddr + TCRRCR); } break; /* exit the while loop */ } @@ -1793,13 +1776,13 @@ static struct net_device_stats *get_stats(struct net_device *dev) { - long ioaddr = dev->base_addr; - struct netdev_private *np = dev->priv; + struct netdev_private *np = netdev_priv(dev); + void __iomem *ioaddr = np->mem; /* The chip only need report frame silently dropped. */ if (netif_running(dev)) { - np->stats.rx_missed_errors += readl(ioaddr + TALLY) & 0x7fff; - np->stats.rx_crc_errors += (readl(ioaddr + TALLY) & 0x7fff0000) >> 16; + np->stats.rx_missed_errors += ioread32(ioaddr + TALLY) & 0x7fff; + np->stats.rx_crc_errors += (ioread32(ioaddr + TALLY) & 0x7fff0000) >> 16; } return &np->stats; @@ -1809,7 +1792,7 @@ /* for dev->set_multicast_list */ static void set_rx_mode(struct net_device *dev) { - spinlock_t *lp = &((struct netdev_private *)dev->priv)->lock; + spinlock_t *lp = &((struct netdev_private *)netdev_priv(dev))->lock; unsigned long flags; spin_lock_irqsave(lp, flags); __set_rx_mode(dev); @@ -1820,8 +1803,8 @@ /* Take lock before calling */ static void __set_rx_mode(struct net_device *dev) { - struct netdev_private *np = dev->priv; - long ioaddr = dev->base_addr; + struct netdev_private *np = netdev_priv(dev); + void __iomem *ioaddr = np->mem; u32 mc_filter[2]; /* Multicast hash filter */ u32 rx_mode; @@ -1851,16 +1834,16 @@ stop_nic_rxtx(ioaddr, np->crvalue); - writel(mc_filter[0], ioaddr + MAR0); - writel(mc_filter[1], ioaddr + MAR1); + iowrite32(mc_filter[0], ioaddr + MAR0); + iowrite32(mc_filter[1], ioaddr + MAR1); np->crvalue &= ~CR_W_RXMODEMASK; np->crvalue |= rx_mode; - writel(np->crvalue, ioaddr + TCRRCR); + iowrite32(np->crvalue, ioaddr + TCRRCR); } static void netdev_get_drvinfo(struct net_device *dev, struct ethtool_drvinfo *info) { - struct netdev_private *np = dev->priv; + struct netdev_private *np = netdev_priv(dev); strcpy(info->driver, DRV_NAME); strcpy(info->version, DRV_VERSION); @@ -1869,7 +1852,7 @@ static int netdev_get_settings(struct net_device *dev, struct ethtool_cmd *cmd) { - struct netdev_private *np = dev->priv; + struct netdev_private *np = netdev_priv(dev); int rc; spin_lock_irq(&np->lock); @@ -1881,7 +1864,7 @@ static int netdev_set_settings(struct net_device *dev, struct ethtool_cmd *cmd) { - struct netdev_private *np = dev->priv; + struct netdev_private *np = netdev_priv(dev); int rc; spin_lock_irq(&np->lock); @@ -1893,13 +1876,13 @@ static int netdev_nway_reset(struct net_device *dev) { - struct netdev_private *np = dev->priv; + struct netdev_private *np = netdev_priv(dev); return mii_nway_restart(&np->mii); } static u32 netdev_get_link(struct net_device *dev) { - struct netdev_private *np = dev->priv; + struct netdev_private *np = netdev_priv(dev); return mii_link_ok(&np->mii); } @@ -1927,7 +1910,7 @@ static int mii_ioctl(struct net_device *dev, struct ifreq *rq, int cmd) { - struct netdev_private *np = dev->priv; + struct netdev_private *np = netdev_priv(dev); int rc; if (!netif_running(dev)) @@ -1943,14 +1926,14 @@ static int netdev_close(struct net_device *dev) { - long ioaddr = dev->base_addr; - struct netdev_private *np = dev->priv; + struct netdev_private *np = netdev_priv(dev); + void __iomem *ioaddr = np->mem; int i; netif_stop_queue(dev); /* Disable interrupts by clearing the interrupt mask. */ - writel(0x0000, ioaddr + IMR); + iowrite32(0x0000, ioaddr + IMR); /* Stop the chip's Tx and Rx processes. */ stop_nic_rxtx(ioaddr, 0); diff -Nru a/drivers/net/hamradio/6pack.c b/drivers/net/hamradio/6pack.c --- a/drivers/net/hamradio/6pack.c 2005-03-08 14:29:45 -05:00 +++ b/drivers/net/hamradio/6pack.c 2005-03-08 14:29:45 -05:00 @@ -756,12 +756,12 @@ switch(cmd) { case SIOCGIFNAME: - err = copy_to_user((void *) arg, dev->name, + err = copy_to_user((void __user *) arg, dev->name, strlen(dev->name) + 1) ? -EFAULT : 0; break; case SIOCGIFENCAP: - err = put_user(0, (int __user *)arg); + err = put_user(0, (int __user *) arg); break; case SIOCSIFENCAP: diff -Nru a/drivers/net/hamradio/baycom_epp.c b/drivers/net/hamradio/baycom_epp.c --- a/drivers/net/hamradio/baycom_epp.c 2005-03-08 14:29:45 -05:00 +++ b/drivers/net/hamradio/baycom_epp.c 2005-03-08 14:29:45 -05:00 @@ -68,25 +68,7 @@ /* --------------------------------------------------------------------- */ static const char paranoia_str[] = KERN_ERR -"baycom_epp: bad magic number for hdlcdrv_state struct in routine %s\n"; - -#define baycom_paranoia_check(dev,routine,retval) \ -({ \ - if (!dev || !dev->priv || ((struct baycom_state *)dev->priv)->magic != BAYCOM_MAGIC) { \ - printk(paranoia_str, routine); \ - return retval; \ - } \ -}) - -#define baycom_paranoia_check_void(dev,routine) \ -({ \ - if (!dev || !dev->priv || ((struct baycom_state *)dev->priv)->magic != BAYCOM_MAGIC) { \ - printk(paranoia_str, routine); \ - return; \ - } \ -}) - -/* --------------------------------------------------------------------- */ + "baycom_epp: bad magic number for hdlcdrv_state struct in routine %s\n"; static const char bc_drvname[] = "baycom_epp"; static const char bc_drvinfo[] = KERN_INFO "baycom_epp: (C) 1998-2000 Thomas Sailer, HB9JNX/AE4WA\n" @@ -747,7 +729,6 @@ unsigned int time1 = 0, time2 = 0, time3 = 0; int cnt, cnt2; - baycom_paranoia_check_void(dev, "epp_bh"); bc = netdev_priv(dev); if (!bc->work_running) return; @@ -863,10 +844,8 @@ static int baycom_send_packet(struct sk_buff *skb, struct net_device *dev) { - struct baycom_state *bc; + struct baycom_state *bc = netdev_priv(dev); - baycom_paranoia_check(dev, "baycom_send_packet", 0); - bc = netdev_priv(dev); if (skb->data[0] != 0) { do_kiss_params(bc, skb->data, skb->len); dev_kfree_skb(skb); @@ -899,10 +878,8 @@ static struct net_device_stats *baycom_get_stats(struct net_device *dev) { - struct baycom_state *bc; + struct baycom_state *bc = netdev_priv(dev); - baycom_paranoia_check(dev, "baycom_get_stats", NULL); - bc = netdev_priv(dev); /* * Get the current statistics. This may be called with the * card open or closed. @@ -915,10 +892,8 @@ static void epp_wakeup(void *handle) { struct net_device *dev = (struct net_device *)handle; - struct baycom_state *bc; + struct baycom_state *bc = netdev_priv(dev); - baycom_paranoia_check_void(dev, "epp_wakeup"); - bc = netdev_priv(dev); printk(KERN_DEBUG "baycom_epp: %s: why am I being woken up?\n", dev->name); if (!parport_claim(bc->pdev)) printk(KERN_DEBUG "baycom_epp: %s: I'm broken.\n", dev->name); @@ -937,16 +912,13 @@ static int epp_open(struct net_device *dev) { - struct baycom_state *bc; - struct parport *pp; + struct baycom_state *bc = netdev_priv(dev); + struct parport *pp = parport_find_base(dev->base_addr); unsigned int i, j; unsigned char tmp[128]; unsigned char stat; unsigned long tstart; - baycom_paranoia_check(dev, "epp_open", -ENXIO); - bc = netdev_priv(dev); - pp = parport_find_base(dev->base_addr); if (!pp) { printk(KERN_ERR "%s: parport at 0x%lx unknown\n", bc_drvname, dev->base_addr); return -ENXIO; @@ -1055,13 +1027,10 @@ static int epp_close(struct net_device *dev) { - struct baycom_state *bc; - struct parport *pp; + struct baycom_state *bc = netdev_priv(dev); + struct parport *pp = bc->pdev->port; unsigned char tmp[1]; - baycom_paranoia_check(dev, "epp_close", -EINVAL); - bc = netdev_priv(dev); - pp = bc->pdev->port; bc->work_running = 0; flush_scheduled_work(); bc->stat = EPP_DCDBIT; @@ -1117,11 +1086,9 @@ static int baycom_ioctl(struct net_device *dev, struct ifreq *ifr, int cmd) { - struct baycom_state *bc; + struct baycom_state *bc = netdev_priv(dev); struct hdlcdrv_ioctl hi; - baycom_paranoia_check(dev, "baycom_ioctl", -EINVAL); - bc = netdev_priv(dev); if (cmd != SIOCDEVPRIVATE) return -ENOIOCTLCMD; @@ -1354,7 +1321,7 @@ free_netdev(dev); break; } - if (set_hw && baycom_setmode(dev->priv, mode[i])) + if (set_hw && baycom_setmode(netdev_priv(dev), mode[i])) set_hw = 0; baycom_device[i] = dev; found++; diff -Nru a/drivers/net/hamradio/baycom_par.c b/drivers/net/hamradio/baycom_par.c --- a/drivers/net/hamradio/baycom_par.c 2005-03-08 14:29:45 -05:00 +++ b/drivers/net/hamradio/baycom_par.c 2005-03-08 14:29:45 -05:00 @@ -85,6 +85,7 @@ #include #include +#include #include #include @@ -415,12 +416,11 @@ struct baycom_state *bc; struct baycom_ioctl bi; - if (!dev || !dev->priv || - ((struct baycom_state *)dev->priv)->hdrv.magic != HDLCDRV_MAGIC) { - printk(KERN_ERR "bc_ioctl: invalid device struct\n"); + if (!dev) return -EINVAL; - } + bc = netdev_priv(dev); + BUG_ON(bc->hdrv.magic != HDLCDRV_MAGIC); if (cmd != SIOCDEVPRIVATE) return -ENOIOCTLCMD; diff -Nru a/drivers/net/hamradio/baycom_ser_fdx.c b/drivers/net/hamradio/baycom_ser_fdx.c --- a/drivers/net/hamradio/baycom_ser_fdx.c 2005-03-08 14:29:45 -05:00 +++ b/drivers/net/hamradio/baycom_ser_fdx.c 2005-03-08 14:29:45 -05:00 @@ -530,12 +530,11 @@ struct baycom_state *bc; struct baycom_ioctl bi; - if (!dev || !dev->priv || - ((struct baycom_state *)dev->priv)->hdrv.magic != HDLCDRV_MAGIC) { - printk(KERN_ERR "bc_ioctl: invalid device struct\n"); + if (!dev) return -EINVAL; - } + bc = netdev_priv(dev); + BUG_ON(bc->hdrv.magic != HDLCDRV_MAGIC); if (cmd != SIOCDEVPRIVATE) return -ENOIOCTLCMD; diff -Nru a/drivers/net/hamradio/baycom_ser_hdx.c b/drivers/net/hamradio/baycom_ser_hdx.c --- a/drivers/net/hamradio/baycom_ser_hdx.c 2005-03-08 14:29:45 -05:00 +++ b/drivers/net/hamradio/baycom_ser_hdx.c 2005-03-08 14:29:45 -05:00 @@ -570,12 +570,11 @@ struct baycom_state *bc; struct baycom_ioctl bi; - if (!dev || !dev->priv || - ((struct baycom_state *)dev->priv)->hdrv.magic != HDLCDRV_MAGIC) { - printk(KERN_ERR "bc_ioctl: invalid device struct\n"); + if (!dev) return -EINVAL; - } + bc = netdev_priv(dev); + BUG_ON(bc->hdrv.magic != HDLCDRV_MAGIC); if (cmd != SIOCDEVPRIVATE) return -ENOIOCTLCMD; diff -Nru a/drivers/net/hamradio/bpqether.c b/drivers/net/hamradio/bpqether.c --- a/drivers/net/hamradio/bpqether.c 2005-03-08 14:29:45 -05:00 +++ b/drivers/net/hamradio/bpqether.c 2005-03-08 14:29:45 -05:00 @@ -112,8 +112,6 @@ }; -#define MAXBPQDEV 100 - struct bpqdev { struct list_head bpq_list; /* list of bpq devices chain */ struct net_device *ethdev; /* link to ethernet device */ @@ -134,7 +132,7 @@ */ static inline struct net_device *bpq_get_ether_dev(struct net_device *dev) { - struct bpqdev *bpq = (struct bpqdev *) dev->priv; + struct bpqdev *bpq = netdev_priv(dev); return bpq ? bpq->ethdev : NULL; } @@ -191,7 +189,7 @@ * we check the source address of the sender. */ - bpq = (struct bpqdev *)dev->priv; + bpq = netdev_priv(dev); eth = eth_hdr(skb); @@ -281,7 +279,7 @@ *ptr++ = (size + 5) % 256; *ptr++ = (size + 5) / 256; - bpq = (struct bpqdev *)dev->priv; + bpq = netdev_priv(dev); if ((dev = bpq_get_ether_dev(dev)) == NULL) { bpq->stats.tx_dropped++; @@ -305,7 +303,7 @@ */ static struct net_device_stats *bpq_get_stats(struct net_device *dev) { - struct bpqdev *bpq = (struct bpqdev *) dev->priv; + struct bpqdev *bpq = netdev_priv(dev); return &bpq->stats; } @@ -332,15 +330,12 @@ static int bpq_ioctl(struct net_device *dev, struct ifreq *ifr, int cmd) { struct bpq_ethaddr __user *ethaddr = ifr->ifr_data; - struct bpqdev *bpq = dev->priv; + struct bpqdev *bpq = netdev_priv(dev); struct bpq_req req; if (!capable(CAP_NET_ADMIN)) return -EPERM; - if (bpq == NULL) /* woops! */ - return -ENODEV; - switch (cmd) { case SIOCSBPQETHOPT: if (copy_from_user(&req, ifr->ifr_data, sizeof(struct bpq_req))) @@ -525,7 +520,7 @@ return -ENOMEM; - bpq = ndev->priv; + bpq = netdev_priv(ndev); dev_hold(edev); bpq->ethdev = edev; bpq->axdev = ndev; @@ -554,7 +549,7 @@ static void bpq_free_device(struct net_device *ndev) { - struct bpqdev *bpq = ndev->priv; + struct bpqdev *bpq = netdev_priv(ndev); dev_put(bpq->ethdev); list_del_rcu(&bpq->bpq_list); diff -Nru a/drivers/net/hamradio/dmascc.c b/drivers/net/hamradio/dmascc.c --- a/drivers/net/hamradio/dmascc.c 2005-03-08 14:29:45 -05:00 +++ b/drivers/net/hamradio/dmascc.c 2005-03-08 14:29:45 -05:00 @@ -1,6 +1,4 @@ /* - * $Id: dmascc.c,v 1.27 2000/06/01 14:46:23 oe1kib Exp $ - * * Driver for high-speed SCC boards (those with DMA support) * Copyright (C) 1997-2000 Klaus Kudielka * @@ -19,7 +17,6 @@ * You should have received a copy of the GNU General Public License * along with this program; if not, write to the Free Software * Foundation, Inc., 675 Mass Ave, Cambridge, MA 02139, USA. - * */ @@ -49,9 +46,9 @@ /* Number of buffers per channel */ -#define NUM_TX_BUF 2 /* NUM_TX_BUF >= 1 (min. 2 recommended) */ -#define NUM_RX_BUF 6 /* NUM_RX_BUF >= 1 (min. 2 recommended) */ -#define BUF_SIZE 1576 /* BUF_SIZE >= mtu + hard_header_len */ +#define NUM_TX_BUF 2 /* NUM_TX_BUF >= 1 (min. 2 recommended) */ +#define NUM_RX_BUF 6 /* NUM_RX_BUF >= 1 (min. 2 recommended) */ +#define BUF_SIZE 1576 /* BUF_SIZE >= mtu + hard_header_len */ /* Cards supported */ @@ -67,7 +64,7 @@ #define HARDWARE { HW_PI, HW_PI2, HW_TWIN, HW_S5 } -#define TMR_0_HZ 25600 /* Frequency of timer 0 */ +#define TMR_0_HZ 25600 /* Frequency of timer 0 */ #define TYPE_PI 0 #define TYPE_PI2 1 @@ -164,69 +161,69 @@ /* Data types */ struct scc_param { - int pclk_hz; /* frequency of BRG input (don't change) */ - int brg_tc; /* BRG terminal count; BRG disabled if < 0 */ - int nrzi; /* 0 (nrz), 1 (nrzi) */ - int clocks; /* see dmascc_cfg documentation */ - int txdelay; /* [1/TMR_0_HZ] */ - int txtimeout; /* [1/HZ] */ - int txtail; /* [1/TMR_0_HZ] */ - int waittime; /* [1/TMR_0_HZ] */ - int slottime; /* [1/TMR_0_HZ] */ - int persist; /* 1 ... 256 */ - int dma; /* -1 (disable), 0, 1, 3 */ - int txpause; /* [1/TMR_0_HZ] */ - int rtsoff; /* [1/TMR_0_HZ] */ - int dcdon; /* [1/TMR_0_HZ] */ - int dcdoff; /* [1/TMR_0_HZ] */ + int pclk_hz; /* frequency of BRG input (don't change) */ + int brg_tc; /* BRG terminal count; BRG disabled if < 0 */ + int nrzi; /* 0 (nrz), 1 (nrzi) */ + int clocks; /* see dmascc_cfg documentation */ + int txdelay; /* [1/TMR_0_HZ] */ + int txtimeout; /* [1/HZ] */ + int txtail; /* [1/TMR_0_HZ] */ + int waittime; /* [1/TMR_0_HZ] */ + int slottime; /* [1/TMR_0_HZ] */ + int persist; /* 1 ... 256 */ + int dma; /* -1 (disable), 0, 1, 3 */ + int txpause; /* [1/TMR_0_HZ] */ + int rtsoff; /* [1/TMR_0_HZ] */ + int dcdon; /* [1/TMR_0_HZ] */ + int dcdoff; /* [1/TMR_0_HZ] */ }; struct scc_hardware { - char *name; - int io_region; - int io_delta; - int io_size; - int num_devs; - int scc_offset; - int tmr_offset; - int tmr_hz; - int pclk_hz; + char *name; + int io_region; + int io_delta; + int io_size; + int num_devs; + int scc_offset; + int tmr_offset; + int tmr_hz; + int pclk_hz; }; struct scc_priv { - int type; - int chip; - struct net_device *dev; - struct scc_info *info; - struct net_device_stats stats; - int channel; - int card_base, scc_cmd, scc_data; - int tmr_cnt, tmr_ctrl, tmr_mode; - struct scc_param param; - char rx_buf[NUM_RX_BUF][BUF_SIZE]; - int rx_len[NUM_RX_BUF]; - int rx_ptr; - struct work_struct rx_work; - int rx_head, rx_tail, rx_count; - int rx_over; - char tx_buf[NUM_TX_BUF][BUF_SIZE]; - int tx_len[NUM_TX_BUF]; - int tx_ptr; - int tx_head, tx_tail, tx_count; - int state; - unsigned long tx_start; - int rr0; - spinlock_t *register_lock; /* Per scc_info */ - spinlock_t ring_lock; + int type; + int chip; + struct net_device *dev; + struct scc_info *info; + struct net_device_stats stats; + int channel; + int card_base, scc_cmd, scc_data; + int tmr_cnt, tmr_ctrl, tmr_mode; + struct scc_param param; + char rx_buf[NUM_RX_BUF][BUF_SIZE]; + int rx_len[NUM_RX_BUF]; + int rx_ptr; + struct work_struct rx_work; + int rx_head, rx_tail, rx_count; + int rx_over; + char tx_buf[NUM_TX_BUF][BUF_SIZE]; + int tx_len[NUM_TX_BUF]; + int tx_ptr; + int tx_head, tx_tail, tx_count; + int state; + unsigned long tx_start; + int rr0; + spinlock_t *register_lock; /* Per scc_info */ + spinlock_t ring_lock; }; struct scc_info { - int irq_used; - int twin_serial_cfg; - struct net_device *dev[2]; - struct scc_priv priv[2]; - struct scc_info *next; - spinlock_t register_lock; /* Per device register lock */ + int irq_used; + int twin_serial_cfg; + struct net_device *dev[2]; + struct scc_priv priv[2]; + struct scc_info *next; + spinlock_t register_lock; /* Per device register lock */ }; @@ -252,7 +249,7 @@ static inline unsigned char random(void); static inline void z8530_isr(struct scc_info *info); -static irqreturn_t scc_isr(int irq, void *dev_id, struct pt_regs * regs); +static irqreturn_t scc_isr(int irq, void *dev_id, struct pt_regs *regs); static void rx_isr(struct scc_priv *priv); static void special_condition(struct scc_priv *priv, int rc); static void rx_bh(void *arg); @@ -264,12 +261,15 @@ /* Initialization variables */ static int io[MAX_NUM_DEVS] __initdata = { 0, }; + /* Beware! hw[] is also used in cleanup_module(). */ static struct scc_hardware hw[NUM_TYPES] __initdata_or_module = HARDWARE; static char ax25_broadcast[7] __initdata = - { 'Q'<<1, 'S'<<1, 'T'<<1, ' '<<1, ' '<<1, ' '<<1, '0'<<1 }; + { 'Q' << 1, 'S' << 1, 'T' << 1, ' ' << 1, ' ' << 1, ' ' << 1, +'0' << 1 }; static char ax25_test[7] __initdata = - { 'L'<<1, 'I'<<1, 'N'<<1, 'U'<<1, 'X'<<1, ' '<<1, '1'<<1 }; + { 'L' << 1, 'I' << 1, 'N' << 1, 'U' << 1, 'X' << 1, ' ' << 1, +'1' << 1 }; /* Global variables */ @@ -283,143 +283,164 @@ MODULE_PARM(io, "1-" __MODULE_STRING(MAX_NUM_DEVS) "i"); MODULE_LICENSE("GPL"); -static void __exit dmascc_exit(void) { - int i; - struct scc_info *info; - - while (first) { - info = first; - - /* Unregister devices */ - for (i = 0; i < 2; i++) - unregister_netdev(info->dev[i]); - - /* Reset board */ - if (info->priv[0].type == TYPE_TWIN) - outb(0, info->dev[0]->base_addr + TWIN_SERIAL_CFG); - write_scc(&info->priv[0], R9, FHWRES); - release_region(info->dev[0]->base_addr, - hw[info->priv[0].type].io_size); - - for (i = 0; i < 2; i++) - free_netdev(info->dev[i]); - - /* Free memory */ - first = info->next; - kfree(info); - } +static void __exit dmascc_exit(void) +{ + int i; + struct scc_info *info; + + while (first) { + info = first; + + /* Unregister devices */ + for (i = 0; i < 2; i++) + unregister_netdev(info->dev[i]); + + /* Reset board */ + if (info->priv[0].type == TYPE_TWIN) + outb(0, info->dev[0]->base_addr + TWIN_SERIAL_CFG); + write_scc(&info->priv[0], R9, FHWRES); + release_region(info->dev[0]->base_addr, + hw[info->priv[0].type].io_size); + + for (i = 0; i < 2; i++) + free_netdev(info->dev[i]); + + /* Free memory */ + first = info->next; + kfree(info); + } } #ifndef MODULE -void __init dmascc_setup(char *str, int *ints) { - int i; +void __init dmascc_setup(char *str, int *ints) +{ + int i; - for (i = 0; i < MAX_NUM_DEVS && i < ints[0]; i++) - io[i] = ints[i+1]; + for (i = 0; i < MAX_NUM_DEVS && i < ints[0]; i++) + io[i] = ints[i + 1]; } #endif -static int __init dmascc_init(void) { - int h, i, j, n; - int base[MAX_NUM_DEVS], tcmd[MAX_NUM_DEVS], t0[MAX_NUM_DEVS], - t1[MAX_NUM_DEVS]; - unsigned t_val; - unsigned long time, start[MAX_NUM_DEVS], delay[MAX_NUM_DEVS], - counting[MAX_NUM_DEVS]; - - /* Initialize random number generator */ - rand = jiffies; - /* Cards found = 0 */ - n = 0; - /* Warning message */ - if (!io[0]) printk(KERN_INFO "dmascc: autoprobing (dangerous)\n"); - - /* Run autodetection for each card type */ - for (h = 0; h < NUM_TYPES; h++) { - - if (io[0]) { - /* User-specified I/O address regions */ - for (i = 0; i < hw[h].num_devs; i++) base[i] = 0; - for (i = 0; i < MAX_NUM_DEVS && io[i]; i++) { - j = (io[i] - hw[h].io_region) / hw[h].io_delta; - if (j >= 0 && - j < hw[h].num_devs && - hw[h].io_region + j * hw[h].io_delta == io[i]) { - base[j] = io[i]; - } - } - } else { - /* Default I/O address regions */ - for (i = 0; i < hw[h].num_devs; i++) { - base[i] = hw[h].io_region + i * hw[h].io_delta; - } - } - - /* Check valid I/O address regions */ - for (i = 0; i < hw[h].num_devs; i++) - if (base[i]) { - if (!request_region(base[i], hw[h].io_size, "dmascc")) - base[i] = 0; - else { - tcmd[i] = base[i] + hw[h].tmr_offset + TMR_CTRL; - t0[i] = base[i] + hw[h].tmr_offset + TMR_CNT0; - t1[i] = base[i] + hw[h].tmr_offset + TMR_CNT1; - } - } - - /* Start timers */ - for (i = 0; i < hw[h].num_devs; i++) - if (base[i]) { - /* Timer 0: LSB+MSB, Mode 3, TMR_0_HZ */ - outb(0x36, tcmd[i]); - outb((hw[h].tmr_hz/TMR_0_HZ) & 0xFF, t0[i]); - outb((hw[h].tmr_hz/TMR_0_HZ) >> 8, t0[i]); - /* Timer 1: LSB+MSB, Mode 0, HZ/10 */ - outb(0x70, tcmd[i]); - outb((TMR_0_HZ/HZ*10) & 0xFF, t1[i]); - outb((TMR_0_HZ/HZ*10) >> 8, t1[i]); - start[i] = jiffies; - delay[i] = 0; - counting[i] = 1; - /* Timer 2: LSB+MSB, Mode 0 */ - outb(0xb0, tcmd[i]); - } - time = jiffies; - /* Wait until counter registers are loaded */ - udelay(2000000/TMR_0_HZ); - - /* Timing loop */ - while (jiffies - time < 13) { - for (i = 0; i < hw[h].num_devs; i++) - if (base[i] && counting[i]) { - /* Read back Timer 1: latch; read LSB; read MSB */ - outb(0x40, tcmd[i]); - t_val = inb(t1[i]) + (inb(t1[i]) << 8); - /* Also check whether counter did wrap */ - if (t_val == 0 || t_val > TMR_0_HZ/HZ*10) counting[i] = 0; - delay[i] = jiffies - start[i]; - } - } - - /* Evaluate measurements */ - for (i = 0; i < hw[h].num_devs; i++) - if (base[i]) { - if ((delay[i] >= 9 && delay[i] <= 11)&& - /* Ok, we have found an adapter */ - (setup_adapter(base[i], h, n) == 0)) - n++; - else - release_region(base[i], hw[h].io_size); - } - - } /* NUM_TYPES */ +static int __init dmascc_init(void) +{ + int h, i, j, n; + int base[MAX_NUM_DEVS], tcmd[MAX_NUM_DEVS], t0[MAX_NUM_DEVS], + t1[MAX_NUM_DEVS]; + unsigned t_val; + unsigned long time, start[MAX_NUM_DEVS], delay[MAX_NUM_DEVS], + counting[MAX_NUM_DEVS]; + + /* Initialize random number generator */ + rand = jiffies; + /* Cards found = 0 */ + n = 0; + /* Warning message */ + if (!io[0]) + printk(KERN_INFO "dmascc: autoprobing (dangerous)\n"); + + /* Run autodetection for each card type */ + for (h = 0; h < NUM_TYPES; h++) { + + if (io[0]) { + /* User-specified I/O address regions */ + for (i = 0; i < hw[h].num_devs; i++) + base[i] = 0; + for (i = 0; i < MAX_NUM_DEVS && io[i]; i++) { + j = (io[i] - + hw[h].io_region) / hw[h].io_delta; + if (j >= 0 && j < hw[h].num_devs + && hw[h].io_region + + j * hw[h].io_delta == io[i]) { + base[j] = io[i]; + } + } + } else { + /* Default I/O address regions */ + for (i = 0; i < hw[h].num_devs; i++) { + base[i] = + hw[h].io_region + i * hw[h].io_delta; + } + } - /* If any adapter was successfully initialized, return ok */ - if (n) return 0; + /* Check valid I/O address regions */ + for (i = 0; i < hw[h].num_devs; i++) + if (base[i]) { + if (!request_region + (base[i], hw[h].io_size, "dmascc")) + base[i] = 0; + else { + tcmd[i] = + base[i] + hw[h].tmr_offset + + TMR_CTRL; + t0[i] = + base[i] + hw[h].tmr_offset + + TMR_CNT0; + t1[i] = + base[i] + hw[h].tmr_offset + + TMR_CNT1; + } + } + + /* Start timers */ + for (i = 0; i < hw[h].num_devs; i++) + if (base[i]) { + /* Timer 0: LSB+MSB, Mode 3, TMR_0_HZ */ + outb(0x36, tcmd[i]); + outb((hw[h].tmr_hz / TMR_0_HZ) & 0xFF, + t0[i]); + outb((hw[h].tmr_hz / TMR_0_HZ) >> 8, + t0[i]); + /* Timer 1: LSB+MSB, Mode 0, HZ/10 */ + outb(0x70, tcmd[i]); + outb((TMR_0_HZ / HZ * 10) & 0xFF, t1[i]); + outb((TMR_0_HZ / HZ * 10) >> 8, t1[i]); + start[i] = jiffies; + delay[i] = 0; + counting[i] = 1; + /* Timer 2: LSB+MSB, Mode 0 */ + outb(0xb0, tcmd[i]); + } + time = jiffies; + /* Wait until counter registers are loaded */ + udelay(2000000 / TMR_0_HZ); + + /* Timing loop */ + while (jiffies - time < 13) { + for (i = 0; i < hw[h].num_devs; i++) + if (base[i] && counting[i]) { + /* Read back Timer 1: latch; read LSB; read MSB */ + outb(0x40, tcmd[i]); + t_val = + inb(t1[i]) + (inb(t1[i]) << 8); + /* Also check whether counter did wrap */ + if (t_val == 0 + || t_val > TMR_0_HZ / HZ * 10) + counting[i] = 0; + delay[i] = jiffies - start[i]; + } + } - /* If no adapter found, return error */ - printk(KERN_INFO "dmascc: no adapters found\n"); - return -EIO; + /* Evaluate measurements */ + for (i = 0; i < hw[h].num_devs; i++) + if (base[i]) { + if ((delay[i] >= 9 && delay[i] <= 11) && + /* Ok, we have found an adapter */ + (setup_adapter(base[i], h, n) == 0)) + n++; + else + release_region(base[i], + hw[h].io_size); + } + + } /* NUM_TYPES */ + + /* If any adapter was successfully initialized, return ok */ + if (n) + return 0; + + /* If no adapter found, return error */ + printk(KERN_INFO "dmascc: no adapters found\n"); + return -EIO; } module_init(dmascc_init); @@ -452,8 +473,8 @@ info = kmalloc(sizeof(struct scc_info), GFP_KERNEL | GFP_DMA); if (!info) { printk(KERN_ERR "dmascc: " - "could not allocate memory for %s at %#3x\n", - hw[type].name, card_base); + "could not allocate memory for %s at %#3x\n", + hw[type].name, card_base); goto out; } @@ -463,16 +484,16 @@ info->dev[0] = alloc_netdev(0, "", dev_setup); if (!info->dev[0]) { printk(KERN_ERR "dmascc: " - "could not allocate memory for %s at %#3x\n", - hw[type].name, card_base); + "could not allocate memory for %s at %#3x\n", + hw[type].name, card_base); goto out1; } info->dev[1] = alloc_netdev(0, "", dev_setup); if (!info->dev[1]) { printk(KERN_ERR "dmascc: " - "could not allocate memory for %s at %#3x\n", - hw[type].name, card_base); + "could not allocate memory for %s at %#3x\n", + hw[type].name, card_base); goto out2; } spin_lock_init(&info->register_lock); @@ -526,7 +547,8 @@ outb(0, tmr_base + TMR_CNT1); /* Wait and detect IRQ */ - time = jiffies; while (jiffies - time < 2 + HZ / TMR_0_HZ); + time = jiffies; + while (jiffies - time < 2 + HZ / TMR_0_HZ); irq = probe_irq_off(irqs); /* Clear pending interrupt, disable interrupts */ @@ -539,8 +561,9 @@ } if (irq <= 0) { - printk(KERN_ERR "dmascc: could not find irq of %s at %#3x (irq=%d)\n", - hw[type].name, card_base, irq); + printk(KERN_ERR + "dmascc: could not find irq of %s at %#3x (irq=%d)\n", + hw[type].name, card_base, irq); goto out3; } @@ -568,7 +591,7 @@ priv->param.dma = -1; INIT_WORK(&priv->rx_work, rx_bh, priv); dev->priv = priv; - sprintf(dev->name, "dmascc%i", 2*n+i); + sprintf(dev->name, "dmascc%i", 2 * n + i); SET_MODULE_OWNER(dev); dev->base_addr = card_base; dev->irq = irq; @@ -583,820 +606,888 @@ } if (register_netdev(info->dev[0])) { printk(KERN_ERR "dmascc: could not register %s\n", - info->dev[0]->name); + info->dev[0]->name); goto out3; } if (register_netdev(info->dev[1])) { printk(KERN_ERR "dmascc: could not register %s\n", - info->dev[1]->name); + info->dev[1]->name); goto out4; } info->next = first; first = info; - printk(KERN_INFO "dmascc: found %s (%s) at %#3x, irq %d\n", hw[type].name, - chipnames[chip], card_base, irq); + printk(KERN_INFO "dmascc: found %s (%s) at %#3x, irq %d\n", + hw[type].name, chipnames[chip], card_base, irq); return 0; -out4: + out4: unregister_netdev(info->dev[0]); -out3: + out3: if (info->priv[0].type == TYPE_TWIN) outb(0, info->dev[0]->base_addr + TWIN_SERIAL_CFG); write_scc(&info->priv[0], R9, FHWRES); free_netdev(info->dev[1]); -out2: + out2: free_netdev(info->dev[0]); -out1: + out1: kfree(info); -out: + out: return -1; } /* Driver functions */ -static void write_scc(struct scc_priv *priv, int reg, int val) { - unsigned long flags; - switch (priv->type) { - case TYPE_S5: - if (reg) outb(reg, priv->scc_cmd); - outb(val, priv->scc_cmd); - return; - case TYPE_TWIN: - if (reg) outb_p(reg, priv->scc_cmd); - outb_p(val, priv->scc_cmd); - return; - default: - spin_lock_irqsave(priv->register_lock, flags); - outb_p(0, priv->card_base + PI_DREQ_MASK); - if (reg) outb_p(reg, priv->scc_cmd); - outb_p(val, priv->scc_cmd); - outb(1, priv->card_base + PI_DREQ_MASK); - spin_unlock_irqrestore(priv->register_lock, flags); - return; - } -} - - -static void write_scc_data(struct scc_priv *priv, int val, int fast) { - unsigned long flags; - switch (priv->type) { - case TYPE_S5: - outb(val, priv->scc_data); - return; - case TYPE_TWIN: - outb_p(val, priv->scc_data); - return; - default: - if (fast) outb_p(val, priv->scc_data); - else { - spin_lock_irqsave(priv->register_lock, flags); - outb_p(0, priv->card_base + PI_DREQ_MASK); - outb_p(val, priv->scc_data); - outb(1, priv->card_base + PI_DREQ_MASK); - spin_unlock_irqrestore(priv->register_lock, flags); - } - return; - } -} - - -static int read_scc(struct scc_priv *priv, int reg) { - int rc; - unsigned long flags; - switch (priv->type) { - case TYPE_S5: - if (reg) outb(reg, priv->scc_cmd); - return inb(priv->scc_cmd); - case TYPE_TWIN: - if (reg) outb_p(reg, priv->scc_cmd); - return inb_p(priv->scc_cmd); - default: - spin_lock_irqsave(priv->register_lock, flags); - outb_p(0, priv->card_base + PI_DREQ_MASK); - if (reg) outb_p(reg, priv->scc_cmd); - rc = inb_p(priv->scc_cmd); - outb(1, priv->card_base + PI_DREQ_MASK); - spin_unlock_irqrestore(priv->register_lock, flags); - return rc; - } -} - - -static int read_scc_data(struct scc_priv *priv) { - int rc; - unsigned long flags; - switch (priv->type) { - case TYPE_S5: - return inb(priv->scc_data); - case TYPE_TWIN: - return inb_p(priv->scc_data); - default: - spin_lock_irqsave(priv->register_lock, flags); - outb_p(0, priv->card_base + PI_DREQ_MASK); - rc = inb_p(priv->scc_data); - outb(1, priv->card_base + PI_DREQ_MASK); - spin_unlock_irqrestore(priv->register_lock, flags); - return rc; - } -} - - -static int scc_open(struct net_device *dev) { - struct scc_priv *priv = dev->priv; - struct scc_info *info = priv->info; - int card_base = priv->card_base; - - /* Request IRQ if not already used by other channel */ - if (!info->irq_used) { - if (request_irq(dev->irq, scc_isr, 0, "dmascc", info)) { - return -EAGAIN; - } - } - info->irq_used++; - - /* Request DMA if required */ - if (priv->param.dma >= 0) { - if (request_dma(priv->param.dma, "dmascc")) { - if (--info->irq_used == 0) free_irq(dev->irq, info); - return -EAGAIN; - } else { - unsigned long flags = claim_dma_lock(); - clear_dma_ff(priv->param.dma); - release_dma_lock(flags); - } - } - - /* Initialize local variables */ - priv->rx_ptr = 0; - priv->rx_over = 0; - priv->rx_head = priv->rx_tail = priv->rx_count = 0; - priv->state = IDLE; - priv->tx_head = priv->tx_tail = priv->tx_count = 0; - priv->tx_ptr = 0; - - /* Reset channel */ - write_scc(priv, R9, (priv->channel ? CHRB : CHRA) | MIE | NV); - /* X1 clock, SDLC mode */ - write_scc(priv, R4, SDLC | X1CLK); - /* DMA */ - write_scc(priv, R1, EXT_INT_ENAB | WT_FN_RDYFN); - /* 8 bit RX char, RX disable */ - write_scc(priv, R3, Rx8); - /* 8 bit TX char, TX disable */ - write_scc(priv, R5, Tx8); - /* SDLC address field */ - write_scc(priv, R6, 0); - /* SDLC flag */ - write_scc(priv, R7, FLAG); - switch (priv->chip) { - case Z85C30: - /* Select WR7' */ - write_scc(priv, R15, SHDLCE); - /* Auto EOM reset */ - write_scc(priv, R7, AUTOEOM); - write_scc(priv, R15, 0); - break; - case Z85230: - /* Select WR7' */ - write_scc(priv, R15, SHDLCE); - /* The following bits are set (see 2.5.2.1): - - Automatic EOM reset - - Interrupt request if RX FIFO is half full - This bit should be ignored in DMA mode (according to the - documentation), but actually isn't. The receiver doesn't work if - it is set. Thus, we have to clear it in DMA mode. - - Interrupt/DMA request if TX FIFO is completely empty - a) If set, the ESCC behaves as if it had no TX FIFO (Z85C30 - compatibility). - b) If cleared, DMA requests may follow each other very quickly, - filling up the TX FIFO. - Advantage: TX works even in case of high bus latency. - Disadvantage: Edge-triggered DMA request circuitry may miss - a request. No more data is delivered, resulting - in a TX FIFO underrun. - Both PI2 and S5SCC/DMA seem to work fine with TXFIFOE cleared. - The PackeTwin doesn't. I don't know about the PI, but let's - assume it behaves like the PI2. - */ - if (priv->param.dma >= 0) { - if (priv->type == TYPE_TWIN) write_scc(priv, R7, AUTOEOM | TXFIFOE); - else write_scc(priv, R7, AUTOEOM); - } else { - write_scc(priv, R7, AUTOEOM | RXFIFOH); - } - write_scc(priv, R15, 0); - break; - } - /* Preset CRC, NRZ(I) encoding */ - write_scc(priv, R10, CRCPS | (priv->param.nrzi ? NRZI : NRZ)); - - /* Configure baud rate generator */ - if (priv->param.brg_tc >= 0) { - /* Program BR generator */ - write_scc(priv, R12, priv->param.brg_tc & 0xFF); - write_scc(priv, R13, (priv->param.brg_tc>>8) & 0xFF); - /* BRG source = SYS CLK; enable BRG; DTR REQ function (required by - PackeTwin, not connected on the PI2); set DPLL source to BRG */ - write_scc(priv, R14, SSBR | DTRREQ | BRSRC | BRENABL); - /* Enable DPLL */ - write_scc(priv, R14, SEARCH | DTRREQ | BRSRC | BRENABL); - } else { - /* Disable BR generator */ - write_scc(priv, R14, DTRREQ | BRSRC); - } - - /* Configure clocks */ - if (priv->type == TYPE_TWIN) { - /* Disable external TX clock receiver */ - outb((info->twin_serial_cfg &= - ~(priv->channel ? TWIN_EXTCLKB : TWIN_EXTCLKA)), - card_base + TWIN_SERIAL_CFG); - } - write_scc(priv, R11, priv->param.clocks); - if ((priv->type == TYPE_TWIN) && !(priv->param.clocks & TRxCOI)) { - /* Enable external TX clock receiver */ - outb((info->twin_serial_cfg |= - (priv->channel ? TWIN_EXTCLKB : TWIN_EXTCLKA)), - card_base + TWIN_SERIAL_CFG); - } - - /* Configure PackeTwin */ - if (priv->type == TYPE_TWIN) { - /* Assert DTR, enable interrupts */ - outb((info->twin_serial_cfg |= TWIN_EI | - (priv->channel ? TWIN_DTRB_ON : TWIN_DTRA_ON)), - card_base + TWIN_SERIAL_CFG); - } - - /* Read current status */ - priv->rr0 = read_scc(priv, R0); - /* Enable DCD interrupt */ - write_scc(priv, R15, DCDIE); - - netif_start_queue(dev); - - return 0; -} - - -static int scc_close(struct net_device *dev) { - struct scc_priv *priv = dev->priv; - struct scc_info *info = priv->info; - int card_base = priv->card_base; - - netif_stop_queue(dev); - - if (priv->type == TYPE_TWIN) { - /* Drop DTR */ - outb((info->twin_serial_cfg &= - (priv->channel ? ~TWIN_DTRB_ON : ~TWIN_DTRA_ON)), - card_base + TWIN_SERIAL_CFG); - } - - /* Reset channel, free DMA and IRQ */ - write_scc(priv, R9, (priv->channel ? CHRB : CHRA) | MIE | NV); - if (priv->param.dma >= 0) { - if (priv->type == TYPE_TWIN) outb(0, card_base + TWIN_DMA_CFG); - free_dma(priv->param.dma); - } - if (--info->irq_used == 0) free_irq(dev->irq, info); - - return 0; -} - - -static int scc_ioctl(struct net_device *dev, struct ifreq *ifr, int cmd) { - struct scc_priv *priv = dev->priv; - - switch (cmd) { - case SIOCGSCCPARAM: - if (copy_to_user(ifr->ifr_data, &priv->param, sizeof(struct scc_param))) - return -EFAULT; - return 0; - case SIOCSSCCPARAM: - if (!capable(CAP_NET_ADMIN)) return -EPERM; - if (netif_running(dev)) return -EAGAIN; - if (copy_from_user(&priv->param, ifr->ifr_data, sizeof(struct scc_param))) - return -EFAULT; - return 0; - default: - return -EINVAL; - } -} - - -static int scc_send_packet(struct sk_buff *skb, struct net_device *dev) { - struct scc_priv *priv = dev->priv; - unsigned long flags; - int i; - - /* Temporarily stop the scheduler feeding us packets */ - netif_stop_queue(dev); - - /* Transfer data to DMA buffer */ - i = priv->tx_head; - memcpy(priv->tx_buf[i], skb->data+1, skb->len-1); - priv->tx_len[i] = skb->len-1; - - /* Clear interrupts while we touch our circular buffers */ - - spin_lock_irqsave(&priv->ring_lock, flags); - /* Move the ring buffer's head */ - priv->tx_head = (i + 1) % NUM_TX_BUF; - priv->tx_count++; - - /* If we just filled up the last buffer, leave queue stopped. - The higher layers must wait until we have a DMA buffer - to accept the data. */ - if (priv->tx_count < NUM_TX_BUF) netif_wake_queue(dev); - - /* Set new TX state */ - if (priv->state == IDLE) { - /* Assert RTS, start timer */ - priv->state = TX_HEAD; - priv->tx_start = jiffies; - write_scc(priv, R5, TxCRC_ENAB | RTS | TxENAB | Tx8); - write_scc(priv, R15, 0); - start_timer(priv, priv->param.txdelay, 0); - } - - /* Turn interrupts back on and free buffer */ - spin_unlock_irqrestore(&priv->ring_lock, flags); - dev_kfree_skb(skb); - - return 0; -} - - -static struct net_device_stats *scc_get_stats(struct net_device *dev) { - struct scc_priv *priv = dev->priv; - - return &priv->stats; -} - - -static int scc_set_mac_address(struct net_device *dev, void *sa) { - memcpy(dev->dev_addr, ((struct sockaddr *)sa)->sa_data, dev->addr_len); - return 0; -} - - -static inline void tx_on(struct scc_priv *priv) { - int i, n; - unsigned long flags; - - if (priv->param.dma >= 0) { - n = (priv->chip == Z85230) ? 3 : 1; - /* Program DMA controller */ - flags = claim_dma_lock(); - set_dma_mode(priv->param.dma, DMA_MODE_WRITE); - set_dma_addr(priv->param.dma, (int) priv->tx_buf[priv->tx_tail]+n); - set_dma_count(priv->param.dma, priv->tx_len[priv->tx_tail]-n); - release_dma_lock(flags); - /* Enable TX underrun interrupt */ - write_scc(priv, R15, TxUIE); - /* Configure DREQ */ - if (priv->type == TYPE_TWIN) - outb((priv->param.dma == 1) ? TWIN_DMA_HDX_T1 : TWIN_DMA_HDX_T3, - priv->card_base + TWIN_DMA_CFG); - else - write_scc(priv, R1, EXT_INT_ENAB | WT_FN_RDYFN | WT_RDY_ENAB); - /* Write first byte(s) */ - spin_lock_irqsave(priv->register_lock, flags); - for (i = 0; i < n; i++) - write_scc_data(priv, priv->tx_buf[priv->tx_tail][i], 1); - enable_dma(priv->param.dma); - spin_unlock_irqrestore(priv->register_lock, flags); - } else { - write_scc(priv, R15, TxUIE); - write_scc(priv, R1, EXT_INT_ENAB | WT_FN_RDYFN | TxINT_ENAB); - tx_isr(priv); - } - /* Reset EOM latch if we do not have the AUTOEOM feature */ - if (priv->chip == Z8530) write_scc(priv, R0, RES_EOM_L); -} - - -static inline void rx_on(struct scc_priv *priv) { - unsigned long flags; - - /* Clear RX FIFO */ - while (read_scc(priv, R0) & Rx_CH_AV) read_scc_data(priv); - priv->rx_over = 0; - if (priv->param.dma >= 0) { - /* Program DMA controller */ - flags = claim_dma_lock(); - set_dma_mode(priv->param.dma, DMA_MODE_READ); - set_dma_addr(priv->param.dma, (int) priv->rx_buf[priv->rx_head]); - set_dma_count(priv->param.dma, BUF_SIZE); - release_dma_lock(flags); - enable_dma(priv->param.dma); - /* Configure PackeTwin DMA */ - if (priv->type == TYPE_TWIN) { - outb((priv->param.dma == 1) ? TWIN_DMA_HDX_R1 : TWIN_DMA_HDX_R3, - priv->card_base + TWIN_DMA_CFG); - } - /* Sp. cond. intr. only, ext int enable, RX DMA enable */ - write_scc(priv, R1, EXT_INT_ENAB | INT_ERR_Rx | - WT_RDY_RT | WT_FN_RDYFN | WT_RDY_ENAB); - } else { - /* Reset current frame */ - priv->rx_ptr = 0; - /* Intr. on all Rx characters and Sp. cond., ext int enable */ - write_scc(priv, R1, EXT_INT_ENAB | INT_ALL_Rx | WT_RDY_RT | - WT_FN_RDYFN); - } - write_scc(priv, R0, ERR_RES); - write_scc(priv, R3, RxENABLE | Rx8 | RxCRC_ENAB); -} - - -static inline void rx_off(struct scc_priv *priv) { - /* Disable receiver */ - write_scc(priv, R3, Rx8); - /* Disable DREQ / RX interrupt */ - if (priv->param.dma >= 0 && priv->type == TYPE_TWIN) - outb(0, priv->card_base + TWIN_DMA_CFG); - else - write_scc(priv, R1, EXT_INT_ENAB | WT_FN_RDYFN); - /* Disable DMA */ - if (priv->param.dma >= 0) disable_dma(priv->param.dma); -} - - -static void start_timer(struct scc_priv *priv, int t, int r15) { - unsigned long flags; - - outb(priv->tmr_mode, priv->tmr_ctrl); - if (t == 0) { - tm_isr(priv); - } else if (t > 0) { - save_flags(flags); - cli(); - outb(t & 0xFF, priv->tmr_cnt); - outb((t >> 8) & 0xFF, priv->tmr_cnt); - if (priv->type != TYPE_TWIN) { - write_scc(priv, R15, r15 | CTSIE); - priv->rr0 |= CTS; - } - restore_flags(flags); - } -} - - -static inline unsigned char random(void) { - /* See "Numerical Recipes in C", second edition, p. 284 */ - rand = rand * 1664525L + 1013904223L; - return (unsigned char) (rand >> 24); -} - -static inline void z8530_isr(struct scc_info *info) { - int is, i = 100; - - while ((is = read_scc(&info->priv[0], R3)) && i--) { - if (is & CHARxIP) { - rx_isr(&info->priv[0]); - } else if (is & CHATxIP) { - tx_isr(&info->priv[0]); - } else if (is & CHAEXT) { - es_isr(&info->priv[0]); - } else if (is & CHBRxIP) { - rx_isr(&info->priv[1]); - } else if (is & CHBTxIP) { - tx_isr(&info->priv[1]); - } else { - es_isr(&info->priv[1]); - } - write_scc(&info->priv[0], R0, RES_H_IUS); - i++; - } - if (i < 0) { - printk(KERN_ERR "dmascc: stuck in ISR with RR3=0x%02x.\n", is); - } - /* Ok, no interrupts pending from this 8530. The INT line should - be inactive now. */ -} - - -static irqreturn_t scc_isr(int irq, void *dev_id, struct pt_regs * regs) { - struct scc_info *info = dev_id; - - spin_lock(info->priv[0].register_lock); - /* At this point interrupts are enabled, and the interrupt under service - is already acknowledged, but masked off. - - Interrupt processing: We loop until we know that the IRQ line is - low. If another positive edge occurs afterwards during the ISR, - another interrupt will be triggered by the interrupt controller - as soon as the IRQ level is enabled again (see asm/irq.h). - - Bottom-half handlers will be processed after scc_isr(). This is - important, since we only have small ringbuffers and want new data - to be fetched/delivered immediately. */ - - if (info->priv[0].type == TYPE_TWIN) { - int is, card_base = info->priv[0].card_base; - while ((is = ~inb(card_base + TWIN_INT_REG)) & - TWIN_INT_MSK) { - if (is & TWIN_SCC_MSK) { - z8530_isr(info); - } else if (is & TWIN_TMR1_MSK) { - inb(card_base + TWIN_CLR_TMR1); - tm_isr(&info->priv[0]); - } else { - inb(card_base + TWIN_CLR_TMR2); - tm_isr(&info->priv[1]); - } - } - } else z8530_isr(info); - spin_unlock(info->priv[0].register_lock); - return IRQ_HANDLED; -} - - -static void rx_isr(struct scc_priv *priv) { - if (priv->param.dma >= 0) { - /* Check special condition and perform error reset. See 2.4.7.5. */ - special_condition(priv, read_scc(priv, R1)); - write_scc(priv, R0, ERR_RES); - } else { - /* Check special condition for each character. Error reset not necessary. - Same algorithm for SCC and ESCC. See 2.4.7.1 and 2.4.7.4. */ - int rc; - while (read_scc(priv, R0) & Rx_CH_AV) { - rc = read_scc(priv, R1); - if (priv->rx_ptr < BUF_SIZE) - priv->rx_buf[priv->rx_head][priv->rx_ptr++] = - read_scc_data(priv); - else { - priv->rx_over = 2; - read_scc_data(priv); - } - special_condition(priv, rc); - } - } -} - - -static void special_condition(struct scc_priv *priv, int rc) { - int cb; - unsigned long flags; - - /* See Figure 2-15. Only overrun and EOF need to be checked. */ - - if (rc & Rx_OVR) { - /* Receiver overrun */ - priv->rx_over = 1; - if (priv->param.dma < 0) write_scc(priv, R0, ERR_RES); - } else if (rc & END_FR) { - /* End of frame. Get byte count */ - if (priv->param.dma >= 0) { - flags = claim_dma_lock(); - cb = BUF_SIZE - get_dma_residue(priv->param.dma) - 2; - release_dma_lock(flags); - } else { - cb = priv->rx_ptr - 2; - } - if (priv->rx_over) { - /* We had an overrun */ - priv->stats.rx_errors++; - if (priv->rx_over == 2) priv->stats.rx_length_errors++; - else priv->stats.rx_fifo_errors++; - priv->rx_over = 0; - } else if (rc & CRC_ERR) { - /* Count invalid CRC only if packet length >= minimum */ - if (cb >= 15) { - priv->stats.rx_errors++; - priv->stats.rx_crc_errors++; - } - } else { - if (cb >= 15) { - if (priv->rx_count < NUM_RX_BUF - 1) { - /* Put good frame in FIFO */ - priv->rx_len[priv->rx_head] = cb; - priv->rx_head = (priv->rx_head + 1) % NUM_RX_BUF; - priv->rx_count++; - schedule_work(&priv->rx_work); +static void write_scc(struct scc_priv *priv, int reg, int val) +{ + unsigned long flags; + switch (priv->type) { + case TYPE_S5: + if (reg) + outb(reg, priv->scc_cmd); + outb(val, priv->scc_cmd); + return; + case TYPE_TWIN: + if (reg) + outb_p(reg, priv->scc_cmd); + outb_p(val, priv->scc_cmd); + return; + default: + spin_lock_irqsave(priv->register_lock, flags); + outb_p(0, priv->card_base + PI_DREQ_MASK); + if (reg) + outb_p(reg, priv->scc_cmd); + outb_p(val, priv->scc_cmd); + outb(1, priv->card_base + PI_DREQ_MASK); + spin_unlock_irqrestore(priv->register_lock, flags); + return; + } +} + + +static void write_scc_data(struct scc_priv *priv, int val, int fast) +{ + unsigned long flags; + switch (priv->type) { + case TYPE_S5: + outb(val, priv->scc_data); + return; + case TYPE_TWIN: + outb_p(val, priv->scc_data); + return; + default: + if (fast) + outb_p(val, priv->scc_data); + else { + spin_lock_irqsave(priv->register_lock, flags); + outb_p(0, priv->card_base + PI_DREQ_MASK); + outb_p(val, priv->scc_data); + outb(1, priv->card_base + PI_DREQ_MASK); + spin_unlock_irqrestore(priv->register_lock, flags); + } + return; + } +} + + +static int read_scc(struct scc_priv *priv, int reg) +{ + int rc; + unsigned long flags; + switch (priv->type) { + case TYPE_S5: + if (reg) + outb(reg, priv->scc_cmd); + return inb(priv->scc_cmd); + case TYPE_TWIN: + if (reg) + outb_p(reg, priv->scc_cmd); + return inb_p(priv->scc_cmd); + default: + spin_lock_irqsave(priv->register_lock, flags); + outb_p(0, priv->card_base + PI_DREQ_MASK); + if (reg) + outb_p(reg, priv->scc_cmd); + rc = inb_p(priv->scc_cmd); + outb(1, priv->card_base + PI_DREQ_MASK); + spin_unlock_irqrestore(priv->register_lock, flags); + return rc; + } +} + + +static int read_scc_data(struct scc_priv *priv) +{ + int rc; + unsigned long flags; + switch (priv->type) { + case TYPE_S5: + return inb(priv->scc_data); + case TYPE_TWIN: + return inb_p(priv->scc_data); + default: + spin_lock_irqsave(priv->register_lock, flags); + outb_p(0, priv->card_base + PI_DREQ_MASK); + rc = inb_p(priv->scc_data); + outb(1, priv->card_base + PI_DREQ_MASK); + spin_unlock_irqrestore(priv->register_lock, flags); + return rc; + } +} + + +static int scc_open(struct net_device *dev) +{ + struct scc_priv *priv = dev->priv; + struct scc_info *info = priv->info; + int card_base = priv->card_base; + + /* Request IRQ if not already used by other channel */ + if (!info->irq_used) { + if (request_irq(dev->irq, scc_isr, 0, "dmascc", info)) { + return -EAGAIN; + } + } + info->irq_used++; + + /* Request DMA if required */ + if (priv->param.dma >= 0) { + if (request_dma(priv->param.dma, "dmascc")) { + if (--info->irq_used == 0) + free_irq(dev->irq, info); + return -EAGAIN; + } else { + unsigned long flags = claim_dma_lock(); + clear_dma_ff(priv->param.dma); + release_dma_lock(flags); + } + } + + /* Initialize local variables */ + priv->rx_ptr = 0; + priv->rx_over = 0; + priv->rx_head = priv->rx_tail = priv->rx_count = 0; + priv->state = IDLE; + priv->tx_head = priv->tx_tail = priv->tx_count = 0; + priv->tx_ptr = 0; + + /* Reset channel */ + write_scc(priv, R9, (priv->channel ? CHRB : CHRA) | MIE | NV); + /* X1 clock, SDLC mode */ + write_scc(priv, R4, SDLC | X1CLK); + /* DMA */ + write_scc(priv, R1, EXT_INT_ENAB | WT_FN_RDYFN); + /* 8 bit RX char, RX disable */ + write_scc(priv, R3, Rx8); + /* 8 bit TX char, TX disable */ + write_scc(priv, R5, Tx8); + /* SDLC address field */ + write_scc(priv, R6, 0); + /* SDLC flag */ + write_scc(priv, R7, FLAG); + switch (priv->chip) { + case Z85C30: + /* Select WR7' */ + write_scc(priv, R15, SHDLCE); + /* Auto EOM reset */ + write_scc(priv, R7, AUTOEOM); + write_scc(priv, R15, 0); + break; + case Z85230: + /* Select WR7' */ + write_scc(priv, R15, SHDLCE); + /* The following bits are set (see 2.5.2.1): + - Automatic EOM reset + - Interrupt request if RX FIFO is half full + This bit should be ignored in DMA mode (according to the + documentation), but actually isn't. The receiver doesn't work if + it is set. Thus, we have to clear it in DMA mode. + - Interrupt/DMA request if TX FIFO is completely empty + a) If set, the ESCC behaves as if it had no TX FIFO (Z85C30 + compatibility). + b) If cleared, DMA requests may follow each other very quickly, + filling up the TX FIFO. + Advantage: TX works even in case of high bus latency. + Disadvantage: Edge-triggered DMA request circuitry may miss + a request. No more data is delivered, resulting + in a TX FIFO underrun. + Both PI2 and S5SCC/DMA seem to work fine with TXFIFOE cleared. + The PackeTwin doesn't. I don't know about the PI, but let's + assume it behaves like the PI2. + */ + if (priv->param.dma >= 0) { + if (priv->type == TYPE_TWIN) + write_scc(priv, R7, AUTOEOM | TXFIFOE); + else + write_scc(priv, R7, AUTOEOM); + } else { + write_scc(priv, R7, AUTOEOM | RXFIFOH); + } + write_scc(priv, R15, 0); + break; + } + /* Preset CRC, NRZ(I) encoding */ + write_scc(priv, R10, CRCPS | (priv->param.nrzi ? NRZI : NRZ)); + + /* Configure baud rate generator */ + if (priv->param.brg_tc >= 0) { + /* Program BR generator */ + write_scc(priv, R12, priv->param.brg_tc & 0xFF); + write_scc(priv, R13, (priv->param.brg_tc >> 8) & 0xFF); + /* BRG source = SYS CLK; enable BRG; DTR REQ function (required by + PackeTwin, not connected on the PI2); set DPLL source to BRG */ + write_scc(priv, R14, SSBR | DTRREQ | BRSRC | BRENABL); + /* Enable DPLL */ + write_scc(priv, R14, SEARCH | DTRREQ | BRSRC | BRENABL); } else { - priv->stats.rx_errors++; - priv->stats.rx_over_errors++; + /* Disable BR generator */ + write_scc(priv, R14, DTRREQ | BRSRC); + } + + /* Configure clocks */ + if (priv->type == TYPE_TWIN) { + /* Disable external TX clock receiver */ + outb((info->twin_serial_cfg &= + ~(priv->channel ? TWIN_EXTCLKB : TWIN_EXTCLKA)), + card_base + TWIN_SERIAL_CFG); + } + write_scc(priv, R11, priv->param.clocks); + if ((priv->type == TYPE_TWIN) && !(priv->param.clocks & TRxCOI)) { + /* Enable external TX clock receiver */ + outb((info->twin_serial_cfg |= + (priv->channel ? TWIN_EXTCLKB : TWIN_EXTCLKA)), + card_base + TWIN_SERIAL_CFG); + } + + /* Configure PackeTwin */ + if (priv->type == TYPE_TWIN) { + /* Assert DTR, enable interrupts */ + outb((info->twin_serial_cfg |= TWIN_EI | + (priv->channel ? TWIN_DTRB_ON : TWIN_DTRA_ON)), + card_base + TWIN_SERIAL_CFG); + } + + /* Read current status */ + priv->rr0 = read_scc(priv, R0); + /* Enable DCD interrupt */ + write_scc(priv, R15, DCDIE); + + netif_start_queue(dev); + + return 0; +} + + +static int scc_close(struct net_device *dev) +{ + struct scc_priv *priv = dev->priv; + struct scc_info *info = priv->info; + int card_base = priv->card_base; + + netif_stop_queue(dev); + + if (priv->type == TYPE_TWIN) { + /* Drop DTR */ + outb((info->twin_serial_cfg &= + (priv->channel ? ~TWIN_DTRB_ON : ~TWIN_DTRA_ON)), + card_base + TWIN_SERIAL_CFG); + } + + /* Reset channel, free DMA and IRQ */ + write_scc(priv, R9, (priv->channel ? CHRB : CHRA) | MIE | NV); + if (priv->param.dma >= 0) { + if (priv->type == TYPE_TWIN) + outb(0, card_base + TWIN_DMA_CFG); + free_dma(priv->param.dma); + } + if (--info->irq_used == 0) + free_irq(dev->irq, info); + + return 0; +} + + +static int scc_ioctl(struct net_device *dev, struct ifreq *ifr, int cmd) +{ + struct scc_priv *priv = dev->priv; + + switch (cmd) { + case SIOCGSCCPARAM: + if (copy_to_user + (ifr->ifr_data, &priv->param, + sizeof(struct scc_param))) + return -EFAULT; + return 0; + case SIOCSSCCPARAM: + if (!capable(CAP_NET_ADMIN)) + return -EPERM; + if (netif_running(dev)) + return -EAGAIN; + if (copy_from_user + (&priv->param, ifr->ifr_data, + sizeof(struct scc_param))) + return -EFAULT; + return 0; + default: + return -EINVAL; + } +} + + +static int scc_send_packet(struct sk_buff *skb, struct net_device *dev) +{ + struct scc_priv *priv = dev->priv; + unsigned long flags; + int i; + + /* Temporarily stop the scheduler feeding us packets */ + netif_stop_queue(dev); + + /* Transfer data to DMA buffer */ + i = priv->tx_head; + memcpy(priv->tx_buf[i], skb->data + 1, skb->len - 1); + priv->tx_len[i] = skb->len - 1; + + /* Clear interrupts while we touch our circular buffers */ + + spin_lock_irqsave(&priv->ring_lock, flags); + /* Move the ring buffer's head */ + priv->tx_head = (i + 1) % NUM_TX_BUF; + priv->tx_count++; + + /* If we just filled up the last buffer, leave queue stopped. + The higher layers must wait until we have a DMA buffer + to accept the data. */ + if (priv->tx_count < NUM_TX_BUF) + netif_wake_queue(dev); + + /* Set new TX state */ + if (priv->state == IDLE) { + /* Assert RTS, start timer */ + priv->state = TX_HEAD; + priv->tx_start = jiffies; + write_scc(priv, R5, TxCRC_ENAB | RTS | TxENAB | Tx8); + write_scc(priv, R15, 0); + start_timer(priv, priv->param.txdelay, 0); + } + + /* Turn interrupts back on and free buffer */ + spin_unlock_irqrestore(&priv->ring_lock, flags); + dev_kfree_skb(skb); + + return 0; +} + + +static struct net_device_stats *scc_get_stats(struct net_device *dev) +{ + struct scc_priv *priv = dev->priv; + + return &priv->stats; +} + + +static int scc_set_mac_address(struct net_device *dev, void *sa) +{ + memcpy(dev->dev_addr, ((struct sockaddr *) sa)->sa_data, + dev->addr_len); + return 0; +} + + +static inline void tx_on(struct scc_priv *priv) +{ + int i, n; + unsigned long flags; + + if (priv->param.dma >= 0) { + n = (priv->chip == Z85230) ? 3 : 1; + /* Program DMA controller */ + flags = claim_dma_lock(); + set_dma_mode(priv->param.dma, DMA_MODE_WRITE); + set_dma_addr(priv->param.dma, + (int) priv->tx_buf[priv->tx_tail] + n); + set_dma_count(priv->param.dma, + priv->tx_len[priv->tx_tail] - n); + release_dma_lock(flags); + /* Enable TX underrun interrupt */ + write_scc(priv, R15, TxUIE); + /* Configure DREQ */ + if (priv->type == TYPE_TWIN) + outb((priv->param.dma == + 1) ? TWIN_DMA_HDX_T1 : TWIN_DMA_HDX_T3, + priv->card_base + TWIN_DMA_CFG); + else + write_scc(priv, R1, + EXT_INT_ENAB | WT_FN_RDYFN | + WT_RDY_ENAB); + /* Write first byte(s) */ + spin_lock_irqsave(priv->register_lock, flags); + for (i = 0; i < n; i++) + write_scc_data(priv, + priv->tx_buf[priv->tx_tail][i], 1); + enable_dma(priv->param.dma); + spin_unlock_irqrestore(priv->register_lock, flags); + } else { + write_scc(priv, R15, TxUIE); + write_scc(priv, R1, + EXT_INT_ENAB | WT_FN_RDYFN | TxINT_ENAB); + tx_isr(priv); + } + /* Reset EOM latch if we do not have the AUTOEOM feature */ + if (priv->chip == Z8530) + write_scc(priv, R0, RES_EOM_L); +} + + +static inline void rx_on(struct scc_priv *priv) +{ + unsigned long flags; + + /* Clear RX FIFO */ + while (read_scc(priv, R0) & Rx_CH_AV) + read_scc_data(priv); + priv->rx_over = 0; + if (priv->param.dma >= 0) { + /* Program DMA controller */ + flags = claim_dma_lock(); + set_dma_mode(priv->param.dma, DMA_MODE_READ); + set_dma_addr(priv->param.dma, + (int) priv->rx_buf[priv->rx_head]); + set_dma_count(priv->param.dma, BUF_SIZE); + release_dma_lock(flags); + enable_dma(priv->param.dma); + /* Configure PackeTwin DMA */ + if (priv->type == TYPE_TWIN) { + outb((priv->param.dma == + 1) ? TWIN_DMA_HDX_R1 : TWIN_DMA_HDX_R3, + priv->card_base + TWIN_DMA_CFG); + } + /* Sp. cond. intr. only, ext int enable, RX DMA enable */ + write_scc(priv, R1, EXT_INT_ENAB | INT_ERR_Rx | + WT_RDY_RT | WT_FN_RDYFN | WT_RDY_ENAB); + } else { + /* Reset current frame */ + priv->rx_ptr = 0; + /* Intr. on all Rx characters and Sp. cond., ext int enable */ + write_scc(priv, R1, EXT_INT_ENAB | INT_ALL_Rx | WT_RDY_RT | + WT_FN_RDYFN); + } + write_scc(priv, R0, ERR_RES); + write_scc(priv, R3, RxENABLE | Rx8 | RxCRC_ENAB); +} + + +static inline void rx_off(struct scc_priv *priv) +{ + /* Disable receiver */ + write_scc(priv, R3, Rx8); + /* Disable DREQ / RX interrupt */ + if (priv->param.dma >= 0 && priv->type == TYPE_TWIN) + outb(0, priv->card_base + TWIN_DMA_CFG); + else + write_scc(priv, R1, EXT_INT_ENAB | WT_FN_RDYFN); + /* Disable DMA */ + if (priv->param.dma >= 0) + disable_dma(priv->param.dma); +} + + +static void start_timer(struct scc_priv *priv, int t, int r15) +{ + unsigned long flags; + + outb(priv->tmr_mode, priv->tmr_ctrl); + if (t == 0) { + tm_isr(priv); + } else if (t > 0) { + save_flags(flags); + cli(); + outb(t & 0xFF, priv->tmr_cnt); + outb((t >> 8) & 0xFF, priv->tmr_cnt); + if (priv->type != TYPE_TWIN) { + write_scc(priv, R15, r15 | CTSIE); + priv->rr0 |= CTS; + } + restore_flags(flags); + } +} + + +static inline unsigned char random(void) +{ + /* See "Numerical Recipes in C", second edition, p. 284 */ + rand = rand * 1664525L + 1013904223L; + return (unsigned char) (rand >> 24); +} + +static inline void z8530_isr(struct scc_info *info) +{ + int is, i = 100; + + while ((is = read_scc(&info->priv[0], R3)) && i--) { + if (is & CHARxIP) { + rx_isr(&info->priv[0]); + } else if (is & CHATxIP) { + tx_isr(&info->priv[0]); + } else if (is & CHAEXT) { + es_isr(&info->priv[0]); + } else if (is & CHBRxIP) { + rx_isr(&info->priv[1]); + } else if (is & CHBTxIP) { + tx_isr(&info->priv[1]); + } else { + es_isr(&info->priv[1]); + } + write_scc(&info->priv[0], R0, RES_H_IUS); + i++; + } + if (i < 0) { + printk(KERN_ERR "dmascc: stuck in ISR with RR3=0x%02x.\n", + is); + } + /* Ok, no interrupts pending from this 8530. The INT line should + be inactive now. */ +} + + +static irqreturn_t scc_isr(int irq, void *dev_id, struct pt_regs *regs) +{ + struct scc_info *info = dev_id; + + spin_lock(info->priv[0].register_lock); + /* At this point interrupts are enabled, and the interrupt under service + is already acknowledged, but masked off. + + Interrupt processing: We loop until we know that the IRQ line is + low. If another positive edge occurs afterwards during the ISR, + another interrupt will be triggered by the interrupt controller + as soon as the IRQ level is enabled again (see asm/irq.h). + + Bottom-half handlers will be processed after scc_isr(). This is + important, since we only have small ringbuffers and want new data + to be fetched/delivered immediately. */ + + if (info->priv[0].type == TYPE_TWIN) { + int is, card_base = info->priv[0].card_base; + while ((is = ~inb(card_base + TWIN_INT_REG)) & + TWIN_INT_MSK) { + if (is & TWIN_SCC_MSK) { + z8530_isr(info); + } else if (is & TWIN_TMR1_MSK) { + inb(card_base + TWIN_CLR_TMR1); + tm_isr(&info->priv[0]); + } else { + inb(card_base + TWIN_CLR_TMR2); + tm_isr(&info->priv[1]); + } + } + } else + z8530_isr(info); + spin_unlock(info->priv[0].register_lock); + return IRQ_HANDLED; +} + + +static void rx_isr(struct scc_priv *priv) +{ + if (priv->param.dma >= 0) { + /* Check special condition and perform error reset. See 2.4.7.5. */ + special_condition(priv, read_scc(priv, R1)); + write_scc(priv, R0, ERR_RES); + } else { + /* Check special condition for each character. Error reset not necessary. + Same algorithm for SCC and ESCC. See 2.4.7.1 and 2.4.7.4. */ + int rc; + while (read_scc(priv, R0) & Rx_CH_AV) { + rc = read_scc(priv, R1); + if (priv->rx_ptr < BUF_SIZE) + priv->rx_buf[priv->rx_head][priv-> + rx_ptr++] = + read_scc_data(priv); + else { + priv->rx_over = 2; + read_scc_data(priv); + } + special_condition(priv, rc); + } + } +} + + +static void special_condition(struct scc_priv *priv, int rc) +{ + int cb; + unsigned long flags; + + /* See Figure 2-15. Only overrun and EOF need to be checked. */ + + if (rc & Rx_OVR) { + /* Receiver overrun */ + priv->rx_over = 1; + if (priv->param.dma < 0) + write_scc(priv, R0, ERR_RES); + } else if (rc & END_FR) { + /* End of frame. Get byte count */ + if (priv->param.dma >= 0) { + flags = claim_dma_lock(); + cb = BUF_SIZE - get_dma_residue(priv->param.dma) - + 2; + release_dma_lock(flags); + } else { + cb = priv->rx_ptr - 2; + } + if (priv->rx_over) { + /* We had an overrun */ + priv->stats.rx_errors++; + if (priv->rx_over == 2) + priv->stats.rx_length_errors++; + else + priv->stats.rx_fifo_errors++; + priv->rx_over = 0; + } else if (rc & CRC_ERR) { + /* Count invalid CRC only if packet length >= minimum */ + if (cb >= 15) { + priv->stats.rx_errors++; + priv->stats.rx_crc_errors++; + } + } else { + if (cb >= 15) { + if (priv->rx_count < NUM_RX_BUF - 1) { + /* Put good frame in FIFO */ + priv->rx_len[priv->rx_head] = cb; + priv->rx_head = + (priv->rx_head + + 1) % NUM_RX_BUF; + priv->rx_count++; + schedule_work(&priv->rx_work); + } else { + priv->stats.rx_errors++; + priv->stats.rx_over_errors++; + } + } + } + /* Get ready for new frame */ + if (priv->param.dma >= 0) { + flags = claim_dma_lock(); + set_dma_addr(priv->param.dma, + (int) priv->rx_buf[priv->rx_head]); + set_dma_count(priv->param.dma, BUF_SIZE); + release_dma_lock(flags); + } else { + priv->rx_ptr = 0; + } + } +} + + +static void rx_bh(void *arg) +{ + struct scc_priv *priv = arg; + int i = priv->rx_tail; + int cb; + unsigned long flags; + struct sk_buff *skb; + unsigned char *data; + + spin_lock_irqsave(&priv->ring_lock, flags); + while (priv->rx_count) { + spin_unlock_irqrestore(&priv->ring_lock, flags); + cb = priv->rx_len[i]; + /* Allocate buffer */ + skb = dev_alloc_skb(cb + 1); + if (skb == NULL) { + /* Drop packet */ + priv->stats.rx_dropped++; + } else { + /* Fill buffer */ + data = skb_put(skb, cb + 1); + data[0] = 0; + memcpy(&data[1], priv->rx_buf[i], cb); + skb->dev = priv->dev; + skb->protocol = ntohs(ETH_P_AX25); + skb->mac.raw = skb->data; + netif_rx(skb); + priv->dev->last_rx = jiffies; + priv->stats.rx_packets++; + priv->stats.rx_bytes += cb; + } + spin_lock_irqsave(&priv->ring_lock, flags); + /* Move tail */ + priv->rx_tail = i = (i + 1) % NUM_RX_BUF; + priv->rx_count--; + } + spin_unlock_irqrestore(&priv->ring_lock, flags); +} + + +static void tx_isr(struct scc_priv *priv) +{ + int i = priv->tx_tail, p = priv->tx_ptr; + + /* Suspend TX interrupts if we don't want to send anything. + See Figure 2-22. */ + if (p == priv->tx_len[i]) { + write_scc(priv, R0, RES_Tx_P); + return; + } + + /* Write characters */ + while ((read_scc(priv, R0) & Tx_BUF_EMP) && p < priv->tx_len[i]) { + write_scc_data(priv, priv->tx_buf[i][p++], 0); + } + + /* Reset EOM latch of Z8530 */ + if (!priv->tx_ptr && p && priv->chip == Z8530) + write_scc(priv, R0, RES_EOM_L); + + priv->tx_ptr = p; +} + + +static void es_isr(struct scc_priv *priv) +{ + int i, rr0, drr0, res; + unsigned long flags; + + /* Read status, reset interrupt bit (open latches) */ + rr0 = read_scc(priv, R0); + write_scc(priv, R0, RES_EXT_INT); + drr0 = priv->rr0 ^ rr0; + priv->rr0 = rr0; + + /* Transmit underrun (2.4.9.6). We can't check the TxEOM flag, since + it might have already been cleared again by AUTOEOM. */ + if (priv->state == TX_DATA) { + /* Get remaining bytes */ + i = priv->tx_tail; + if (priv->param.dma >= 0) { + disable_dma(priv->param.dma); + flags = claim_dma_lock(); + res = get_dma_residue(priv->param.dma); + release_dma_lock(flags); + } else { + res = priv->tx_len[i] - priv->tx_ptr; + priv->tx_ptr = 0; + } + /* Disable DREQ / TX interrupt */ + if (priv->param.dma >= 0 && priv->type == TYPE_TWIN) + outb(0, priv->card_base + TWIN_DMA_CFG); + else + write_scc(priv, R1, EXT_INT_ENAB | WT_FN_RDYFN); + if (res) { + /* Update packet statistics */ + priv->stats.tx_errors++; + priv->stats.tx_fifo_errors++; + /* Other underrun interrupts may already be waiting */ + write_scc(priv, R0, RES_EXT_INT); + write_scc(priv, R0, RES_EXT_INT); + } else { + /* Update packet statistics */ + priv->stats.tx_packets++; + priv->stats.tx_bytes += priv->tx_len[i]; + /* Remove frame from FIFO */ + priv->tx_tail = (i + 1) % NUM_TX_BUF; + priv->tx_count--; + /* Inform upper layers */ + netif_wake_queue(priv->dev); + } + /* Switch state */ + write_scc(priv, R15, 0); + if (priv->tx_count && + (jiffies - priv->tx_start) < priv->param.txtimeout) { + priv->state = TX_PAUSE; + start_timer(priv, priv->param.txpause, 0); + } else { + priv->state = TX_TAIL; + start_timer(priv, priv->param.txtail, 0); + } + } + + /* DCD transition */ + if (drr0 & DCD) { + if (rr0 & DCD) { + switch (priv->state) { + case IDLE: + case WAIT: + priv->state = DCD_ON; + write_scc(priv, R15, 0); + start_timer(priv, priv->param.dcdon, 0); + } + } else { + switch (priv->state) { + case RX_ON: + rx_off(priv); + priv->state = DCD_OFF; + write_scc(priv, R15, 0); + start_timer(priv, priv->param.dcdoff, 0); + } + } + } + + /* CTS transition */ + if ((drr0 & CTS) && (~rr0 & CTS) && priv->type != TYPE_TWIN) + tm_isr(priv); + +} + + +static void tm_isr(struct scc_priv *priv) +{ + switch (priv->state) { + case TX_HEAD: + case TX_PAUSE: + tx_on(priv); + priv->state = TX_DATA; + break; + case TX_TAIL: + write_scc(priv, R5, TxCRC_ENAB | Tx8); + priv->state = RTS_OFF; + if (priv->type != TYPE_TWIN) + write_scc(priv, R15, 0); + start_timer(priv, priv->param.rtsoff, 0); + break; + case RTS_OFF: + write_scc(priv, R15, DCDIE); + priv->rr0 = read_scc(priv, R0); + if (priv->rr0 & DCD) { + priv->stats.collisions++; + rx_on(priv); + priv->state = RX_ON; + } else { + priv->state = WAIT; + start_timer(priv, priv->param.waittime, DCDIE); + } + break; + case WAIT: + if (priv->tx_count) { + priv->state = TX_HEAD; + priv->tx_start = jiffies; + write_scc(priv, R5, + TxCRC_ENAB | RTS | TxENAB | Tx8); + write_scc(priv, R15, 0); + start_timer(priv, priv->param.txdelay, 0); + } else { + priv->state = IDLE; + if (priv->type != TYPE_TWIN) + write_scc(priv, R15, DCDIE); + } + break; + case DCD_ON: + case DCD_OFF: + write_scc(priv, R15, DCDIE); + priv->rr0 = read_scc(priv, R0); + if (priv->rr0 & DCD) { + rx_on(priv); + priv->state = RX_ON; + } else { + priv->state = WAIT; + start_timer(priv, + random() / priv->param.persist * + priv->param.slottime, DCDIE); + } + break; } - } - } - /* Get ready for new frame */ - if (priv->param.dma >= 0) { - flags = claim_dma_lock(); - set_dma_addr(priv->param.dma, (int) priv->rx_buf[priv->rx_head]); - set_dma_count(priv->param.dma, BUF_SIZE); - release_dma_lock(flags); - } else { - priv->rx_ptr = 0; - } - } -} - - -static void rx_bh(void *arg) { - struct scc_priv *priv = arg; - int i = priv->rx_tail; - int cb; - unsigned long flags; - struct sk_buff *skb; - unsigned char *data; - - spin_lock_irqsave(&priv->ring_lock, flags); - while (priv->rx_count) { - spin_unlock_irqrestore(&priv->ring_lock, flags); - cb = priv->rx_len[i]; - /* Allocate buffer */ - skb = dev_alloc_skb(cb+1); - if (skb == NULL) { - /* Drop packet */ - priv->stats.rx_dropped++; - } else { - /* Fill buffer */ - data = skb_put(skb, cb+1); - data[0] = 0; - memcpy(&data[1], priv->rx_buf[i], cb); - skb->dev = priv->dev; - skb->protocol = ntohs(ETH_P_AX25); - skb->mac.raw = skb->data; - netif_rx(skb); - priv->dev->last_rx = jiffies; - priv->stats.rx_packets++; - priv->stats.rx_bytes += cb; - } - spin_lock_irqsave(&priv->ring_lock, flags); - /* Move tail */ - priv->rx_tail = i = (i + 1) % NUM_RX_BUF; - priv->rx_count--; - } - spin_unlock_irqrestore(&priv->ring_lock, flags); -} - - -static void tx_isr(struct scc_priv *priv) { - int i = priv->tx_tail, p = priv->tx_ptr; - - /* Suspend TX interrupts if we don't want to send anything. - See Figure 2-22. */ - if (p == priv->tx_len[i]) { - write_scc(priv, R0, RES_Tx_P); - return; - } - - /* Write characters */ - while ((read_scc(priv, R0) & Tx_BUF_EMP) && p < priv->tx_len[i]) { - write_scc_data(priv, priv->tx_buf[i][p++], 0); - } - - /* Reset EOM latch of Z8530 */ - if (!priv->tx_ptr && p && priv->chip == Z8530) - write_scc(priv, R0, RES_EOM_L); - - priv->tx_ptr = p; -} - - -static void es_isr(struct scc_priv *priv) { - int i, rr0, drr0, res; - unsigned long flags; - - /* Read status, reset interrupt bit (open latches) */ - rr0 = read_scc(priv, R0); - write_scc(priv, R0, RES_EXT_INT); - drr0 = priv->rr0 ^ rr0; - priv->rr0 = rr0; - - /* Transmit underrun (2.4.9.6). We can't check the TxEOM flag, since - it might have already been cleared again by AUTOEOM. */ - if (priv->state == TX_DATA) { - /* Get remaining bytes */ - i = priv->tx_tail; - if (priv->param.dma >= 0) { - disable_dma(priv->param.dma); - flags = claim_dma_lock(); - res = get_dma_residue(priv->param.dma); - release_dma_lock(flags); - } else { - res = priv->tx_len[i] - priv->tx_ptr; - priv->tx_ptr = 0; - } - /* Disable DREQ / TX interrupt */ - if (priv->param.dma >= 0 && priv->type == TYPE_TWIN) - outb(0, priv->card_base + TWIN_DMA_CFG); - else - write_scc(priv, R1, EXT_INT_ENAB | WT_FN_RDYFN); - if (res) { - /* Update packet statistics */ - priv->stats.tx_errors++; - priv->stats.tx_fifo_errors++; - /* Other underrun interrupts may already be waiting */ - write_scc(priv, R0, RES_EXT_INT); - write_scc(priv, R0, RES_EXT_INT); - } else { - /* Update packet statistics */ - priv->stats.tx_packets++; - priv->stats.tx_bytes += priv->tx_len[i]; - /* Remove frame from FIFO */ - priv->tx_tail = (i + 1) % NUM_TX_BUF; - priv->tx_count--; - /* Inform upper layers */ - netif_wake_queue(priv->dev); - } - /* Switch state */ - write_scc(priv, R15, 0); - if (priv->tx_count && - (jiffies - priv->tx_start) < priv->param.txtimeout) { - priv->state = TX_PAUSE; - start_timer(priv, priv->param.txpause, 0); - } else { - priv->state = TX_TAIL; - start_timer(priv, priv->param.txtail, 0); - } - } - - /* DCD transition */ - if (drr0 & DCD) { - if (rr0 & DCD) { - switch (priv->state) { - case IDLE: - case WAIT: - priv->state = DCD_ON; - write_scc(priv, R15, 0); - start_timer(priv, priv->param.dcdon, 0); - } - } else { - switch (priv->state) { - case RX_ON: - rx_off(priv); - priv->state = DCD_OFF; - write_scc(priv, R15, 0); - start_timer(priv, priv->param.dcdoff, 0); - } - } - } - - /* CTS transition */ - if ((drr0 & CTS) && (~rr0 & CTS) && priv->type != TYPE_TWIN) - tm_isr(priv); - -} - - -static void tm_isr(struct scc_priv *priv) { - switch (priv->state) { - case TX_HEAD: - case TX_PAUSE: - tx_on(priv); - priv->state = TX_DATA; - break; - case TX_TAIL: - write_scc(priv, R5, TxCRC_ENAB | Tx8); - priv->state = RTS_OFF; - if (priv->type != TYPE_TWIN) write_scc(priv, R15, 0); - start_timer(priv, priv->param.rtsoff, 0); - break; - case RTS_OFF: - write_scc(priv, R15, DCDIE); - priv->rr0 = read_scc(priv, R0); - if (priv->rr0 & DCD) { - priv->stats.collisions++; - rx_on(priv); - priv->state = RX_ON; - } else { - priv->state = WAIT; - start_timer(priv, priv->param.waittime, DCDIE); - } - break; - case WAIT: - if (priv->tx_count) { - priv->state = TX_HEAD; - priv->tx_start = jiffies; - write_scc(priv, R5, TxCRC_ENAB | RTS | TxENAB | Tx8); - write_scc(priv, R15, 0); - start_timer(priv, priv->param.txdelay, 0); - } else { - priv->state = IDLE; - if (priv->type != TYPE_TWIN) write_scc(priv, R15, DCDIE); - } - break; - case DCD_ON: - case DCD_OFF: - write_scc(priv, R15, DCDIE); - priv->rr0 = read_scc(priv, R0); - if (priv->rr0 & DCD) { - rx_on(priv); - priv->state = RX_ON; - } else { - priv->state = WAIT; - start_timer(priv, - random()/priv->param.persist*priv->param.slottime, - DCDIE); - } - break; - } } diff -Nru a/drivers/net/hamradio/hdlcdrv.c b/drivers/net/hamradio/hdlcdrv.c --- a/drivers/net/hamradio/hdlcdrv.c 2005-03-08 14:29:45 -05:00 +++ b/drivers/net/hamradio/hdlcdrv.c 2005-03-08 14:29:45 -05:00 @@ -427,27 +427,10 @@ * ===================== network driver interface ========================= */ -static inline int hdlcdrv_paranoia_check(struct net_device *dev, - const char *routine) -{ - if (!dev || !dev->priv || - ((struct hdlcdrv_state *)dev->priv)->magic != HDLCDRV_MAGIC) { - printk(KERN_ERR "hdlcdrv: bad magic number for hdlcdrv_state " - "struct in routine %s\n", routine); - return 1; - } - return 0; -} - -/* --------------------------------------------------------------------- */ - static int hdlcdrv_send_packet(struct sk_buff *skb, struct net_device *dev) { - struct hdlcdrv_state *sm; + struct hdlcdrv_state *sm = netdev_priv(dev); - if (hdlcdrv_paranoia_check(dev, "hdlcdrv_send_packet")) - return 0; - sm = (struct hdlcdrv_state *)dev->priv; if (skb->data[0] != 0) { do_kiss_params(sm, skb->data, skb->len); dev_kfree_skb(skb); @@ -475,11 +458,8 @@ static struct net_device_stats *hdlcdrv_get_stats(struct net_device *dev) { - struct hdlcdrv_state *sm; + struct hdlcdrv_state *sm = netdev_priv(dev); - if (hdlcdrv_paranoia_check(dev, "hdlcdrv_get_stats")) - return NULL; - sm = (struct hdlcdrv_state *)dev->priv; /* * Get the current statistics. This may be called with the * card open or closed. @@ -499,13 +479,9 @@ static int hdlcdrv_open(struct net_device *dev) { - struct hdlcdrv_state *s; + struct hdlcdrv_state *s = netdev_priv(dev); int i; - if (hdlcdrv_paranoia_check(dev, "hdlcdrv_open")) - return -EINVAL; - s = (struct hdlcdrv_state *)dev->priv; - if (!s->ops || !s->ops->open) return -ENODEV; @@ -540,13 +516,9 @@ static int hdlcdrv_close(struct net_device *dev) { - struct hdlcdrv_state *s; + struct hdlcdrv_state *s = netdev_priv(dev); int i = 0; - if (hdlcdrv_paranoia_check(dev, "hdlcdrv_close")) - return -EINVAL; - s = (struct hdlcdrv_state *)dev->priv; - netif_stop_queue(dev); if (s->ops && s->ops->close) @@ -562,12 +534,8 @@ static int hdlcdrv_ioctl(struct net_device *dev, struct ifreq *ifr, int cmd) { - struct hdlcdrv_state *s; + struct hdlcdrv_state *s = netdev_priv(dev); struct hdlcdrv_ioctl bi; - - if (hdlcdrv_paranoia_check(dev, "hdlcdrv_ioctl")) - return -EINVAL; - s = (struct hdlcdrv_state *)dev->priv; if (cmd != SIOCDEVPRIVATE) { if (s->ops && s->ops->ioctl) @@ -698,7 +666,7 @@ static const struct hdlcdrv_channel_params dflt_ch_params = { 20, 2, 10, 40, 0 }; - struct hdlcdrv_state *s = dev->priv; + struct hdlcdrv_state *s = netdev_priv(dev); /* * initialize the hdlcdrv_state struct @@ -782,7 +750,7 @@ /* * initialize part of the hdlcdrv_state struct */ - s = dev->priv; + s = netdev_priv(dev); s->magic = HDLCDRV_MAGIC; s->ops = ops; dev->base_addr = baseaddr; @@ -803,7 +771,7 @@ void hdlcdrv_unregister(struct net_device *dev) { - struct hdlcdrv_state *s = dev->priv; + struct hdlcdrv_state *s = netdev_priv(dev); BUG_ON(s->magic != HDLCDRV_MAGIC); diff -Nru a/drivers/net/hamradio/mkiss.c b/drivers/net/hamradio/mkiss.c --- a/drivers/net/hamradio/mkiss.c 2005-03-08 14:29:45 -05:00 +++ b/drivers/net/hamradio/mkiss.c 2005-03-08 14:29:45 -05:00 @@ -419,7 +419,7 @@ /* Encapsulate an AX.25 packet and kick it into a TTY queue. */ static int ax_xmit(struct sk_buff *skb, struct net_device *dev) { - struct ax_disp *ax = (struct ax_disp *) dev->priv; + struct ax_disp *ax = netdev_priv(dev); if (!netif_running(dev)) { printk(KERN_ERR "mkiss: %s: xmit call when iface is down\n", dev->name); @@ -483,7 +483,7 @@ /* Open the low-level part of the AX25 channel. Easy! */ static int ax_open(struct net_device *dev) { - struct ax_disp *ax = (struct ax_disp *) dev->priv; + struct ax_disp *ax = netdev_priv(dev); unsigned long len; if (ax->tty == NULL) @@ -534,7 +534,7 @@ /* Close the low-level part of the AX25 channel. Easy! */ static int ax_close(struct net_device *dev) { - struct ax_disp *ax = (struct ax_disp *) dev->priv; + struct ax_disp *ax = netdev_priv(dev); if (ax->tty == NULL) return -EBUSY; @@ -634,7 +634,7 @@ static struct net_device_stats *ax_get_stats(struct net_device *dev) { static struct net_device_stats stats; - struct ax_disp *ax = (struct ax_disp *) dev->priv; + struct ax_disp *ax = netdev_priv(dev); memset(&stats, 0, sizeof(struct net_device_stats)); @@ -827,7 +827,7 @@ static int ax_open_dev(struct net_device *dev) { - struct ax_disp *ax = (struct ax_disp *) dev->priv; + struct ax_disp *ax = netdev_priv(dev); if (ax->tty == NULL) return -ENODEV; @@ -839,7 +839,7 @@ /* Initialize the driver. Called by network startup. */ static int ax25_init(struct net_device *dev) { - struct ax_disp *ax = (struct ax_disp *) dev->priv; + struct ax_disp *ax = netdev_priv(dev); static char ax25_bcast[AX25_ADDR_LEN] = {'Q'<<1,'S'<<1,'T'<<1,' '<<1,' '<<1,' '<<1,'0'<<1}; diff -Nru a/drivers/net/hamradio/yam.c b/drivers/net/hamradio/yam.c --- a/drivers/net/hamradio/yam.c 2005-03-08 14:29:45 -05:00 +++ b/drivers/net/hamradio/yam.c 2005-03-08 14:29:45 -05:00 @@ -442,7 +442,7 @@ static void yam_set_uart(struct net_device *dev) { - struct yam_port *yp = (struct yam_port *) dev->priv; + struct yam_port *yp = netdev_priv(dev); int divisor = 115200 / yp->baudrate; outb(0, IER(dev->base_addr)); @@ -565,7 +565,7 @@ static int yam_send_packet(struct sk_buff *skb, struct net_device *dev) { - struct yam_port *yp = dev->priv; + struct yam_port *yp = netdev_priv(dev); skb_queue_tail(&yp->send_queue, skb); dev->trans_start = jiffies; @@ -592,12 +592,11 @@ static void yam_arbitrate(struct net_device *dev) { - struct yam_port *yp = dev->priv; + struct yam_port *yp = netdev_priv(dev); - if (!yp || yp->magic != YAM_MAGIC - || yp->tx_state != TX_OFF || skb_queue_empty(&yp->send_queue)) { + if (yp->magic != YAM_MAGIC || yp->tx_state != TX_OFF || + skb_queue_empty(&yp->send_queue)) return; - } /* tx_state is TX_OFF and there is data to send */ if (yp->dupmode) { @@ -725,7 +724,7 @@ for (i = 0; i < NR_PORTS; i++) { dev = yam_devs[i]; - yp = dev->priv; + yp = netdev_priv(dev); if (!netif_running(dev)) continue; @@ -784,8 +783,8 @@ static int yam_seq_show(struct seq_file *seq, void *v) { - const struct net_device *dev = v; - const struct yam_port *yp = dev->priv; + struct net_device *dev = v; + const struct yam_port *yp = netdev_priv(dev); seq_printf(seq, "Device %s\n", dev->name); seq_printf(seq, " Up %d\n", netif_running(dev)); @@ -838,10 +837,10 @@ { struct yam_port *yp; - if (!dev || !dev->priv) + if (!dev) return NULL; - yp = (struct yam_port *) dev->priv; + yp = netdev_priv(dev); if (yp->magic != YAM_MAGIC) return NULL; @@ -856,14 +855,14 @@ static int yam_open(struct net_device *dev) { - struct yam_port *yp = (struct yam_port *) dev->priv; + struct yam_port *yp = netdev_priv(dev); enum uart u; int i; int ret=0; printk(KERN_INFO "Trying %s at iobase 0x%lx irq %u\n", dev->name, dev->base_addr, dev->irq); - if (!dev || !yp || !yp->bitrate) + if (!dev || !yp->bitrate) return -ENXIO; if (!dev->base_addr || dev->base_addr > 0x1000 - YAM_EXTENT || dev->irq < 2 || dev->irq > 15) { @@ -900,7 +899,7 @@ /* Reset overruns for all ports - FPGA programming makes overruns */ for (i = 0; i < NR_PORTS; i++) { struct net_device *dev = yam_devs[i]; - struct yam_port *yp = dev->priv; + struct yam_port *yp = netdev_priv(dev); inb(LSR(dev->base_addr)); yp->stats.rx_fifo_errors = 0; } @@ -919,10 +918,11 @@ static int yam_close(struct net_device *dev) { struct sk_buff *skb; - struct yam_port *yp = (struct yam_port *) dev->priv; + struct yam_port *yp = netdev_priv(dev); - if (!dev || !yp) + if (!dev) return -EINVAL; + /* * disable interrupts */ @@ -944,7 +944,7 @@ static int yam_ioctl(struct net_device *dev, struct ifreq *ifr, int cmd) { - struct yam_port *yp = (struct yam_port *) dev->priv; + struct yam_port *yp = netdev_priv(dev); struct yamdrv_ioctl_cfg yi; struct yamdrv_ioctl_mcs *ym; int ioctl_cmd; @@ -952,7 +952,7 @@ if (copy_from_user(&ioctl_cmd, ifr->ifr_data, sizeof(int))) return -EFAULT; - if (yp == NULL || yp->magic != YAM_MAGIC) + if (yp->magic != YAM_MAGIC) return -EINVAL; if (!capable(CAP_NET_ADMIN)) @@ -1091,7 +1091,7 @@ static void yam_setup(struct net_device *dev) { - struct yam_port *yp = dev->priv; + struct yam_port *yp = netdev_priv(dev); yp->magic = YAM_MAGIC; yp->bitrate = DEFAULT_BITRATE; diff -Nru a/drivers/net/mv643xx_eth.c b/drivers/net/mv643xx_eth.c --- a/drivers/net/mv643xx_eth.c 2005-03-08 14:29:45 -05:00 +++ b/drivers/net/mv643xx_eth.c 2005-03-08 14:29:45 -05:00 @@ -1,5 +1,5 @@ /* - * drivers/net/mv64340_eth.c - Driver for MV64340X ethernet ports + * drivers/net/mv643xx_eth.c - Driver for MV643XX ethernet ports * Copyright (C) 2002 Matthew Dharm * * Based on the 64360 driver from: @@ -10,6 +10,12 @@ * * Copyright (C) 2003 Ralf Baechle * + * Copyright (C) 2004-2005 MontaVista Software, Inc. + * Dale Farnsworth + * + * Copyright (C) 2004 Steven J. Hill + * + * * This program is free software; you can redistribute it and/or * modify it under the terms of the GNU General Public License * as published by the Free Software Foundation; either version 2 @@ -24,80 +30,100 @@ * along with this program; if not, write to the Free Software * Foundation, Inc., 59 Temple Place - Suite 330, Boston, MA 02111-1307, USA. */ -#include -#include -#include -#include -#include -#include -#include -#include -#include -#include -#include -#include -#include -#include #include -#include -#include -#include -#include -#include +#include #include -#include +#include #include -#include #include +#include +#include #include #include #include #include +#include #include "mv643xx_eth.h" /* - * The first part is the high level driver of the gigE ethernet ports. + * The first part is the high level driver of the gigE ethernet ports. */ -/* Definition for configuring driver */ -#undef MV64340_RX_QUEUE_FILL_ON_TASK - /* Constants */ -#define EXTRA_BYTES 32 -#define WRAP ETH_HLEN + 2 + 4 + 16 -#define BUFFER_MTU dev->mtu + WRAP +#define VLAN_HLEN 4 +#define FCS_LEN 4 +#define WRAP NET_IP_ALIGN + ETH_HLEN + VLAN_HLEN + FCS_LEN +#define RX_SKB_SIZE ((dev->mtu + WRAP + 7) & ~0x7) + #define INT_CAUSE_UNMASK_ALL 0x0007ffff #define INT_CAUSE_UNMASK_ALL_EXT 0x0011ffff -#ifdef MV64340_RX_FILL_ON_TASK +#ifdef MV643XX_RX_QUEUE_FILL_ON_TASK #define INT_CAUSE_MASK_ALL 0x00000000 #define INT_CAUSE_CHECK_BITS INT_CAUSE_UNMASK_ALL #define INT_CAUSE_CHECK_BITS_EXT INT_CAUSE_UNMASK_ALL_EXT #endif +#ifdef MV643XX_CHECKSUM_OFFLOAD_TX +#define MAX_DESCS_PER_SKB (MAX_SKB_FRAGS + 1) +#else +#define MAX_DESCS_PER_SKB 1 +#endif + +#define PHY_WAIT_ITERATIONS 1000 /* 1000 iterations * 10uS = 10mS max */ +#define PHY_WAIT_MICRO_SECONDS 10 + /* Static function declarations */ -static int mv64340_eth_real_open(struct net_device *); -static int mv64340_eth_real_stop(struct net_device *); -static int mv64340_eth_change_mtu(struct net_device *, int); -static struct net_device_stats *mv64340_eth_get_stats(struct net_device *); +static int eth_port_link_is_up(unsigned int eth_port_num); +static void eth_port_uc_addr_get(struct net_device *dev, + unsigned char *MacAddr); +static int mv643xx_eth_real_open(struct net_device *); +static int mv643xx_eth_real_stop(struct net_device *); +static int mv643xx_eth_change_mtu(struct net_device *, int); +static struct net_device_stats *mv643xx_eth_get_stats(struct net_device *); static void eth_port_init_mac_tables(unsigned int eth_port_num); -#ifdef MV64340_NAPI -static int mv64340_poll(struct net_device *dev, int *budget); +#ifdef MV643XX_NAPI +static int mv643xx_poll(struct net_device *dev, int *budget); #endif +static void ethernet_phy_set(unsigned int eth_port_num, int phy_addr); +static int ethernet_phy_detect(unsigned int eth_port_num); +static struct ethtool_ops mv643xx_ethtool_ops; + +static char mv643xx_driver_name[] = "mv643xx_eth"; +static char mv643xx_driver_version[] = "1.0"; + +static void __iomem *mv643xx_eth_shared_base; + +/* used to protect MV643XX_ETH_SMI_REG, which is shared across ports */ +static spinlock_t mv643xx_eth_phy_lock = SPIN_LOCK_UNLOCKED; + +static inline u32 mv_read(int offset) +{ + void *__iomem reg_base; + + reg_base = mv643xx_eth_shared_base - MV643XX_ETH_SHARED_REGS; + + return readl(reg_base + offset); +} + +static inline void mv_write(int offset, u32 data) +{ + void * __iomem reg_base; -unsigned char prom_mac_addr_base[6]; -unsigned long mv64340_sram_base; + reg_base = mv643xx_eth_shared_base - MV643XX_ETH_SHARED_REGS; + writel(data, reg_base + offset); +} /* * Changes MTU (maximum transfer unit) of the gigabit ethenret port * - * Input : pointer to ethernet interface network device structure - * new mtu size - * Output : 0 upon success, -EINVAL upon failure + * Input : pointer to ethernet interface network device structure + * new mtu size + * Output : 0 upon success, -EINVAL upon failure */ -static int mv64340_eth_change_mtu(struct net_device *dev, int new_mtu) +static int mv643xx_eth_change_mtu(struct net_device *dev, int new_mtu) { - struct mv64340_private *mp = netdev_priv(dev); + struct mv643xx_private *mp = netdev_priv(dev); unsigned long flags; spin_lock_irqsave(&mp->lock, flags); @@ -108,21 +134,21 @@ } dev->mtu = new_mtu; - /* + /* * Stop then re-open the interface. This will allocate RX skb's with * the new MTU. * There is a possible danger that the open will not successed, due * to memory is full, which might fail the open function. */ if (netif_running(dev)) { - if (mv64340_eth_real_stop(dev)) + if (mv643xx_eth_real_stop(dev)) printk(KERN_ERR - "%s: Fatal error on stopping device\n", - dev->name); - if (mv64340_eth_real_open(dev)) + "%s: Fatal error on stopping device\n", + dev->name); + if (mv643xx_eth_real_open(dev)) printk(KERN_ERR - "%s: Fatal error on opening device\n", - dev->name); + "%s: Fatal error on opening device\n", + dev->name); } spin_unlock_irqrestore(&mp->lock, flags); @@ -130,17 +156,17 @@ } /* - * mv64340_eth_rx_task - * + * mv643xx_eth_rx_task + * * Fills / refills RX queue on a certain gigabit ethernet port * - * Input : pointer to ethernet interface network device structure - * Output : N/A + * Input : pointer to ethernet interface network device structure + * Output : N/A */ -static void mv64340_eth_rx_task(void *data) +static void mv643xx_eth_rx_task(void *data) { - struct net_device *dev = (struct net_device *) data; - struct mv64340_private *mp = netdev_priv(dev); + struct net_device *dev = (struct net_device *)data; + struct mv643xx_private *mp = netdev_priv(dev); struct pkt_info pkt_info; struct sk_buff *skb; @@ -148,28 +174,18 @@ panic("%s: Error in test_set_bit / clear_bit", dev->name); while (mp->rx_ring_skbs < (mp->rx_ring_size - 5)) { - /* The +8 for buffer allignment and another 32 byte extra */ - - skb = dev_alloc_skb(BUFFER_MTU + 8 + EXTRA_BYTES); + skb = dev_alloc_skb(RX_SKB_SIZE); if (!skb) - /* Better luck next time */ break; mp->rx_ring_skbs++; pkt_info.cmd_sts = ETH_RX_ENABLE_INTERRUPT; - pkt_info.byte_cnt = dev->mtu + ETH_HLEN + 4 + 2 + EXTRA_BYTES; - /* Allign buffer to 8 bytes */ - if (pkt_info.byte_cnt & ~0x7) { - pkt_info.byte_cnt &= ~0x7; - pkt_info.byte_cnt += 8; - } - pkt_info.buf_ptr = - pci_map_single(0, skb->data, - dev->mtu + ETH_HLEN + 4 + 2 + EXTRA_BYTES, - PCI_DMA_FROMDEVICE); + pkt_info.byte_cnt = RX_SKB_SIZE; + pkt_info.buf_ptr = dma_map_single(NULL, skb->data, RX_SKB_SIZE, + DMA_FROM_DEVICE); pkt_info.return_info = skb; if (eth_rx_return_buff(mp, &pkt_info) != ETH_OK) { printk(KERN_ERR - "%s: Error allocating RX Ring\n", dev->name); + "%s: Error allocating RX Ring\n", dev->name); break; } skb_reserve(skb, 2); @@ -186,46 +202,45 @@ add_timer(&mp->timeout); mp->rx_timer_flag = 1; } -#if MV64340_RX_QUEUE_FILL_ON_TASK +#ifdef MV643XX_RX_QUEUE_FILL_ON_TASK else { /* Return interrupts */ - MV_WRITE(MV64340_ETH_INTERRUPT_MASK_REG(mp->port_num), - INT_CAUSE_UNMASK_ALL); + mv_write(MV643XX_ETH_INTERRUPT_MASK_REG(mp->port_num), + INT_CAUSE_UNMASK_ALL); } #endif } /* - * mv64340_eth_rx_task_timer_wrapper - * + * mv643xx_eth_rx_task_timer_wrapper + * * Timer routine to wake up RX queue filling task. This function is * used only in case the RX queue is empty, and all alloc_skb has * failed (due to out of memory event). * - * Input : pointer to ethernet interface network device structure - * Output : N/A + * Input : pointer to ethernet interface network device structure + * Output : N/A */ -static void mv64340_eth_rx_task_timer_wrapper(unsigned long data) +static void mv643xx_eth_rx_task_timer_wrapper(unsigned long data) { - struct net_device *dev = (struct net_device *) data; - struct mv64340_private *mp = netdev_priv(dev); + struct net_device *dev = (struct net_device *)data; + struct mv643xx_private *mp = netdev_priv(dev); mp->rx_timer_flag = 0; - mv64340_eth_rx_task((void *) data); + mv643xx_eth_rx_task((void *)data); } - /* - * mv64340_eth_update_mac_address - * + * mv643xx_eth_update_mac_address + * * Update the MAC address of the port in the address table * - * Input : pointer to ethernet interface network device structure - * Output : N/A + * Input : pointer to ethernet interface network device structure + * Output : N/A */ -static void mv64340_eth_update_mac_address(struct net_device *dev) +static void mv643xx_eth_update_mac_address(struct net_device *dev) { - struct mv64340_private *mp = netdev_priv(dev); + struct mv643xx_private *mp = netdev_priv(dev); unsigned int port_num = mp->port_num; eth_port_init_mac_tables(port_num); @@ -234,64 +249,59 @@ } /* - * mv64340_eth_set_rx_mode - * + * mv643xx_eth_set_rx_mode + * * Change from promiscuos to regular rx mode * - * Input : pointer to ethernet interface network device structure - * Output : N/A + * Input : pointer to ethernet interface network device structure + * Output : N/A */ -static void mv64340_eth_set_rx_mode(struct net_device *dev) +static void mv643xx_eth_set_rx_mode(struct net_device *dev) { - struct mv64340_private *mp = netdev_priv(dev); + struct mv643xx_private *mp = netdev_priv(dev); + u32 config_reg; - if (dev->flags & IFF_PROMISC) { - ethernet_set_config_reg - (mp->port_num, - ethernet_get_config_reg(mp->port_num) | - ETH_UNICAST_PROMISCUOUS_MODE); - } else { - ethernet_set_config_reg - (mp->port_num, - ethernet_get_config_reg(mp->port_num) & - ~(unsigned int) ETH_UNICAST_PROMISCUOUS_MODE); - } + config_reg = ethernet_get_config_reg(mp->port_num); + if (dev->flags & IFF_PROMISC) + config_reg |= (u32) MV643XX_ETH_UNICAST_PROMISCUOUS_MODE; + else + config_reg &= ~(u32) MV643XX_ETH_UNICAST_PROMISCUOUS_MODE; + ethernet_set_config_reg(mp->port_num, config_reg); } - /* - * mv64340_eth_set_mac_address - * + * mv643xx_eth_set_mac_address + * * Change the interface's mac address. * No special hardware thing should be done because interface is always * put in promiscuous mode. * - * Input : pointer to ethernet interface network device structure and - * a pointer to the designated entry to be added to the cache. - * Output : zero upon success, negative upon failure + * Input : pointer to ethernet interface network device structure and + * a pointer to the designated entry to be added to the cache. + * Output : zero upon success, negative upon failure */ -static int mv64340_eth_set_mac_address(struct net_device *dev, void *addr) +static int mv643xx_eth_set_mac_address(struct net_device *dev, void *addr) { int i; for (i = 0; i < 6; i++) /* +2 is for the offset of the HW addr type */ - dev->dev_addr[i] = ((unsigned char *) addr)[i + 2]; - mv64340_eth_update_mac_address(dev); + dev->dev_addr[i] = ((unsigned char *)addr)[i + 2]; + mv643xx_eth_update_mac_address(dev); return 0; } /* - * mv64340_eth_tx_timeout - * + * mv643xx_eth_tx_timeout + * * Called upon a timeout on transmitting a packet * - * Input : pointer to ethernet interface network device structure. - * Output : N/A + * Input : pointer to ethernet interface network device structure. + * Output : N/A */ -static void mv64340_eth_tx_timeout(struct net_device *dev) +static void mv643xx_eth_tx_timeout(struct net_device *dev) { - struct mv64340_private *mp = netdev_priv(dev); + struct mv643xx_private *mp = netdev_priv(dev); printk(KERN_INFO "%s: TX timeout ", dev->name); @@ -300,31 +310,31 @@ } /* - * mv64340_eth_tx_timeout_task + * mv643xx_eth_tx_timeout_task * * Actual routine to reset the adapter when a timeout on Tx has occurred */ -static void mv64340_eth_tx_timeout_task(struct net_device *dev) +static void mv643xx_eth_tx_timeout_task(struct net_device *dev) { - struct mv64340_private *mp = netdev_priv(dev); + struct mv643xx_private *mp = netdev_priv(dev); - netif_device_detach(dev); - eth_port_reset(mp->port_num); - eth_port_start(mp); - netif_device_attach(dev); + netif_device_detach(dev); + eth_port_reset(mp->port_num); + eth_port_start(mp); + netif_device_attach(dev); } /* - * mv64340_eth_free_tx_queue + * mv643xx_eth_free_tx_queue * - * Input : dev - a pointer to the required interface + * Input : dev - a pointer to the required interface * - * Output : 0 if was able to release skb , nonzero otherwise + * Output : 0 if was able to release skb , nonzero otherwise */ -static int mv64340_eth_free_tx_queue(struct net_device *dev, - unsigned int eth_int_cause_ext) +static int mv643xx_eth_free_tx_queue(struct net_device *dev, + unsigned int eth_int_cause_ext) { - struct mv64340_private *mp = netdev_priv(dev); + struct mv643xx_private *mp = netdev_priv(dev); struct net_device_stats *stats = &mp->stats; struct pkt_info pkt_info; int released = 1; @@ -341,33 +351,36 @@ stats->tx_errors++; } - /* + /* * If return_info is different than 0, release the skb. * The case where return_info is not 0 is only in case * when transmitted a scatter/gather packet, where only * last skb releases the whole chain. */ if (pkt_info.return_info) { - dev_kfree_skb_irq((struct sk_buff *) - pkt_info.return_info); - released = 0; if (skb_shinfo(pkt_info.return_info)->nr_frags) - pci_unmap_page(NULL, pkt_info.buf_ptr, - pkt_info.byte_cnt, PCI_DMA_TODEVICE); + dma_unmap_page(NULL, pkt_info.buf_ptr, + pkt_info.byte_cnt, + DMA_TO_DEVICE); + else + dma_unmap_single(NULL, pkt_info.buf_ptr, + pkt_info.byte_cnt, + DMA_TO_DEVICE); - if (mp->tx_ring_skbs != 1) - mp->tx_ring_skbs--; - } else - pci_unmap_page(NULL, pkt_info.buf_ptr, - pkt_info.byte_cnt, PCI_DMA_TODEVICE); - - /* - * Decrement the number of outstanding skbs counter on - * the TX queue. - */ - if (mp->tx_ring_skbs == 0) - panic("ERROR - TX outstanding SKBs counter is corrupted"); + dev_kfree_skb_irq(pkt_info.return_info); + released = 0; + /* + * Decrement the number of outstanding skbs counter on + * the TX queue. + */ + if (mp->tx_ring_skbs == 0) + panic("ERROR - TX outstanding SKBs" + " counter is corrupted"); + mp->tx_ring_skbs--; + } else + dma_unmap_page(NULL, pkt_info.buf_ptr, + pkt_info.byte_cnt, DMA_TO_DEVICE); } spin_unlock(&mp->lock); @@ -376,60 +389,59 @@ } /* - * mv64340_eth_receive + * mv643xx_eth_receive * * This function is forward packets that are received from the port's * queues toward kernel core or FastRoute them to another interface. * - * Input : dev - a pointer to the required interface - * max - maximum number to receive (0 means unlimted) + * Input : dev - a pointer to the required interface + * max - maximum number to receive (0 means unlimted) * - * Output : number of served packets + * Output : number of served packets */ -#ifdef MV64340_NAPI -static int mv64340_eth_receive_queue(struct net_device *dev, unsigned int max, - int budget) +#ifdef MV643XX_NAPI +static int mv643xx_eth_receive_queue(struct net_device *dev, int budget) #else -static int mv64340_eth_receive_queue(struct net_device *dev, unsigned int max) +static int mv643xx_eth_receive_queue(struct net_device *dev) #endif { - struct mv64340_private *mp = netdev_priv(dev); + struct mv643xx_private *mp = netdev_priv(dev); struct net_device_stats *stats = &mp->stats; unsigned int received_packets = 0; struct sk_buff *skb; struct pkt_info pkt_info; -#ifdef MV64340_NAPI +#ifdef MV643XX_NAPI while (eth_port_receive(mp, &pkt_info) == ETH_OK && budget > 0) { #else - while ((--max) && eth_port_receive(mp, &pkt_info) == ETH_OK) { + while (eth_port_receive(mp, &pkt_info) == ETH_OK) { #endif mp->rx_ring_skbs--; received_packets++; -#ifdef MV64340_NAPI +#ifdef MV643XX_NAPI budget--; #endif /* Update statistics. Note byte count includes 4 byte CRC count */ stats->rx_packets++; stats->rx_bytes += pkt_info.byte_cnt; - skb = (struct sk_buff *) pkt_info.return_info; + skb = pkt_info.return_info; /* * In case received a packet without first / last bits on OR * the error summary bit is on, the packets needs to be dropeed. */ if (((pkt_info.cmd_sts - & (ETH_RX_FIRST_DESC | ETH_RX_LAST_DESC)) != - (ETH_RX_FIRST_DESC | ETH_RX_LAST_DESC)) - || (pkt_info.cmd_sts & ETH_ERROR_SUMMARY)) { + & (ETH_RX_FIRST_DESC | ETH_RX_LAST_DESC)) != + (ETH_RX_FIRST_DESC | ETH_RX_LAST_DESC)) + || (pkt_info.cmd_sts & ETH_ERROR_SUMMARY)) { stats->rx_dropped++; if ((pkt_info.cmd_sts & (ETH_RX_FIRST_DESC | - ETH_RX_LAST_DESC)) != - (ETH_RX_FIRST_DESC | ETH_RX_LAST_DESC)) { + ETH_RX_LAST_DESC)) != + (ETH_RX_FIRST_DESC | ETH_RX_LAST_DESC)) { if (net_ratelimit()) printk(KERN_ERR - "%s: Received packet spread on multiple" - " descriptors\n", - dev->name); + "%s: Received packet spread " + "on multiple descriptors\n", + dev->name); } if (pkt_info.cmd_sts & ETH_ERROR_SUMMARY) stats->rx_errors++; @@ -445,11 +457,11 @@ if (pkt_info.cmd_sts & ETH_LAYER_4_CHECKSUM_OK) { skb->ip_summed = CHECKSUM_UNNECESSARY; - skb->csum = htons((pkt_info.cmd_sts - & 0x0007fff8) >> 3); + skb->csum = htons( + (pkt_info.cmd_sts & 0x0007fff8) >> 3); } skb->protocol = eth_type_trans(skb, dev); -#ifdef MV64340_NAPI +#ifdef MV643XX_NAPI netif_receive_skb(skb); #else netif_rx(skb); @@ -461,74 +473,74 @@ } /* - * mv64340_eth_int_handler + * mv643xx_eth_int_handler * * Main interrupt handler for the gigbit ethernet ports * - * Input : irq - irq number (not used) - * dev_id - a pointer to the required interface's data structure - * regs - not used - * Output : N/A + * Input : irq - irq number (not used) + * dev_id - a pointer to the required interface's data structure + * regs - not used + * Output : N/A */ -static irqreturn_t mv64340_eth_int_handler(int irq, void *dev_id, - struct pt_regs *regs) +static irqreturn_t mv643xx_eth_int_handler(int irq, void *dev_id, + struct pt_regs *regs) { - struct net_device *dev = (struct net_device *) dev_id; - struct mv64340_private *mp = netdev_priv(dev); + struct net_device *dev = (struct net_device *)dev_id; + struct mv643xx_private *mp = netdev_priv(dev); u32 eth_int_cause, eth_int_cause_ext = 0; unsigned int port_num = mp->port_num; /* Read interrupt cause registers */ - eth_int_cause = MV_READ(MV64340_ETH_INTERRUPT_CAUSE_REG(port_num)) & - INT_CAUSE_UNMASK_ALL; + eth_int_cause = mv_read(MV643XX_ETH_INTERRUPT_CAUSE_REG(port_num)) & + INT_CAUSE_UNMASK_ALL; if (eth_int_cause & BIT1) - eth_int_cause_ext = - MV_READ(MV64340_ETH_INTERRUPT_CAUSE_EXTEND_REG(port_num)) & - INT_CAUSE_UNMASK_ALL_EXT; + eth_int_cause_ext = mv_read( + MV643XX_ETH_INTERRUPT_CAUSE_EXTEND_REG(port_num)) & + INT_CAUSE_UNMASK_ALL_EXT; -#ifdef MV64340_NAPI +#ifdef MV643XX_NAPI if (!(eth_int_cause & 0x0007fffd)) { - /* Dont ack the Rx interrupt */ + /* Dont ack the Rx interrupt */ #endif /* - * Clear specific ethernet port intrerrupt registers by + * Clear specific ethernet port intrerrupt registers by * acknowleding relevant bits. */ - MV_WRITE(MV64340_ETH_INTERRUPT_CAUSE_REG(port_num), - ~eth_int_cause); + mv_write(MV643XX_ETH_INTERRUPT_CAUSE_REG(port_num), + ~eth_int_cause); if (eth_int_cause_ext != 0x0) - MV_WRITE(MV64340_ETH_INTERRUPT_CAUSE_EXTEND_REG(port_num), - ~eth_int_cause_ext); + mv_write(MV643XX_ETH_INTERRUPT_CAUSE_EXTEND_REG + (port_num), ~eth_int_cause_ext); /* UDP change : We may need this */ if ((eth_int_cause_ext & 0x0000ffff) && - (mv64340_eth_free_tx_queue(dev, eth_int_cause_ext) == 0) && - (MV64340_TX_QUEUE_SIZE > mp->tx_ring_skbs + 1)) - netif_wake_queue(dev); -#ifdef MV64340_NAPI + (mv643xx_eth_free_tx_queue(dev, eth_int_cause_ext) == 0) && + (mp->tx_ring_size > mp->tx_ring_skbs + MAX_DESCS_PER_SKB)) + netif_wake_queue(dev); +#ifdef MV643XX_NAPI } else { if (netif_rx_schedule_prep(dev)) { /* Mask all the interrupts */ - MV_WRITE(MV64340_ETH_INTERRUPT_MASK_REG(port_num),0); - MV_WRITE(MV64340_ETH_INTERRUPT_EXTEND_MASK_REG(port_num), 0); + mv_write(MV643XX_ETH_INTERRUPT_MASK_REG(port_num), 0); + mv_write(MV643XX_ETH_INTERRUPT_EXTEND_MASK_REG + (port_num), 0); __netif_rx_schedule(dev); } #else - { if (eth_int_cause & (BIT2 | BIT11)) - mv64340_eth_receive_queue(dev, 0); + mv643xx_eth_receive_queue(dev, 0); /* - * After forwarded received packets to upper layer, add a task + * After forwarded received packets to upper layer, add a task * in an interrupts enabled context that refills the RX ring * with skb's. */ -#if MV64340_RX_QUEUE_FILL_ON_TASK +#ifdef MV643XX_RX_QUEUE_FILL_ON_TASK /* Unmask all interrupts on ethernet port */ - MV_WRITE(MV64340_ETH_INTERRUPT_MASK_REG(port_num), - INT_CAUSE_MASK_ALL); + mv_write(MV643XX_ETH_INTERRUPT_MASK_REG(port_num), + INT_CAUSE_MASK_ALL); queue_task(&mp->rx_task, &tq_immediate); mark_bh(IMMEDIATE_BH); #else @@ -538,25 +550,15 @@ } /* PHY status changed */ if (eth_int_cause_ext & (BIT16 | BIT20)) { - unsigned int phy_reg_data; - - /* Check Link status on ethernet port */ - eth_port_read_smi_reg(port_num, 1, &phy_reg_data); - if (!(phy_reg_data & 0x20)) { - netif_stop_queue(dev); - } else { + if (eth_port_link_is_up(port_num)) { + netif_carrier_on(dev); netif_wake_queue(dev); - - /* - * Start all TX queues on ethernet port. This is good in - * case of previous packets where not transmitted, due - * to link down and this command re-enables all TX - * queues. - * Note that it is possible to get a TX resource error - * interrupt after issuing this, since not all TX queues - * are enabled, or has anything to send. - */ - MV_WRITE(MV64340_ETH_TRANSMIT_QUEUE_COMMAND_REG(port_num), 1); + /* Start TX queue */ + mv_write(MV643XX_ETH_TRANSMIT_QUEUE_COMMAND_REG + (port_num), 1); + } else { + netif_carrier_off(dev); + netif_stop_queue(dev); } } @@ -570,7 +572,7 @@ return IRQ_HANDLED; } -#ifdef MV64340_COAL +#ifdef MV643XX_COAL /* * eth_port_set_rx_coal - Sets coalescing interrupt mechanism on RX path @@ -584,9 +586,9 @@ * , and the required delay of the interrupt in usec. * * INPUT: - * unsigned int eth_port_num Ethernet port number - * unsigned int t_clk t_clk of the MV-643xx chip in HZ units - * unsigned int delay Delay in usec + * unsigned int eth_port_num Ethernet port number + * unsigned int t_clk t_clk of the MV-643xx chip in HZ units + * unsigned int delay Delay in usec * * OUTPUT: * Interrupt coalescing mechanism value is set in MV-643xx chip. @@ -596,15 +598,15 @@ * */ static unsigned int eth_port_set_rx_coal(unsigned int eth_port_num, - unsigned int t_clk, unsigned int delay) + unsigned int t_clk, unsigned int delay) { unsigned int coal = ((t_clk / 1000000) * delay) / 64; /* Set RX Coalescing mechanism */ - MV_WRITE(MV64340_ETH_SDMA_CONFIG_REG(eth_port_num), - ((coal & 0x3fff) << 8) | - (MV_READ(MV64340_ETH_SDMA_CONFIG_REG(eth_port_num)) - & 0xffc000ff)); + mv_write(MV643XX_ETH_SDMA_CONFIG_REG(eth_port_num), + ((coal & 0x3fff) << 8) | + (mv_read(MV643XX_ETH_SDMA_CONFIG_REG(eth_port_num)) + & 0xffc000ff)); return coal; } @@ -618,13 +620,13 @@ * This parameter is a timeout counter, that counts in 64 t_clk * chunks ; that when timeout event occurs a maskable interrupt * occurs. - * The parameter is calculated using the t_cLK frequency of the + * The parameter is calculated using the t_cLK frequency of the * MV-643xx chip and the required delay in the interrupt in uSec * * INPUT: - * unsigned int eth_port_num Ethernet port number - * unsigned int t_clk t_clk of the MV-643xx chip in HZ units - * unsigned int delay Delay in uSeconds + * unsigned int eth_port_num Ethernet port number + * unsigned int t_clk t_clk of the MV-643xx chip in HZ units + * unsigned int delay Delay in uSeconds * * OUTPUT: * Interrupt coalescing mechanism value is set in MV-643xx chip. @@ -634,48 +636,48 @@ * */ static unsigned int eth_port_set_tx_coal(unsigned int eth_port_num, - unsigned int t_clk, unsigned int delay) + unsigned int t_clk, unsigned int delay) { unsigned int coal; coal = ((t_clk / 1000000) * delay) / 64; /* Set TX Coalescing mechanism */ - MV_WRITE(MV64340_ETH_TX_FIFO_URGENT_THRESHOLD_REG(eth_port_num), - coal << 4); + mv_write(MV643XX_ETH_TX_FIFO_URGENT_THRESHOLD_REG(eth_port_num), + coal << 4); return coal; } /* - * mv64340_eth_open + * mv643xx_eth_open * * This function is called when openning the network device. The function * should initialize all the hardware, initialize cyclic Rx/Tx * descriptors chain and buffers and allocate an IRQ to the network * device. * - * Input : a pointer to the network device structure + * Input : a pointer to the network device structure * - * Output : zero of success , nonzero if fails. + * Output : zero of success , nonzero if fails. */ -static int mv64340_eth_open(struct net_device *dev) +static int mv643xx_eth_open(struct net_device *dev) { - struct mv64340_private *mp = netdev_priv(dev); + struct mv643xx_private *mp = netdev_priv(dev); unsigned int port_num = mp->port_num; - int err = err; + int err; spin_lock_irq(&mp->lock); - err = request_irq(dev->irq, mv64340_eth_int_handler, - SA_INTERRUPT | SA_SAMPLE_RANDOM, dev->name, dev); + err = request_irq(dev->irq, mv643xx_eth_int_handler, + SA_INTERRUPT | SA_SAMPLE_RANDOM, dev->name, dev); if (err) { - printk(KERN_ERR "Can not assign IRQ number to MV64340_eth%d\n", - port_num); + printk(KERN_ERR "Can not assign IRQ number to MV643XX_eth%d\n", + port_num); err = -EAGAIN; goto out; } - if (mv64340_eth_real_open(dev)) { + if (mv643xx_eth_real_open(dev)) { printk("%s: Error opening interface\n", dev->name); err = -EBUSY; goto out_free; @@ -698,66 +700,35 @@ * ether_init_rx_desc_ring - Curve a Rx chain desc list and buffer in memory. * * DESCRIPTION: - * This function prepares a Rx chained list of descriptors and packet - * buffers in a form of a ring. The routine must be called after port - * initialization routine and before port start routine. - * The Ethernet SDMA engine uses CPU bus addresses to access the various - * devices in the system (i.e. DRAM). This function uses the ethernet - * struct 'virtual to physical' routine (set by the user) to set the ring - * with physical addresses. + * This function prepares a Rx chained list of descriptors and packet + * buffers in a form of a ring. The routine must be called after port + * initialization routine and before port start routine. + * The Ethernet SDMA engine uses CPU bus addresses to access the various + * devices in the system (i.e. DRAM). This function uses the ethernet + * struct 'virtual to physical' routine (set by the user) to set the ring + * with physical addresses. * * INPUT: - * struct mv64340_private *mp Ethernet Port Control srtuct. - * int rx_desc_num Number of Rx descriptors - * int rx_buff_size Size of Rx buffer - * unsigned int rx_desc_base_addr Rx descriptors memory area base addr. - * unsigned int rx_buff_base_addr Rx buffer memory area base addr. + * struct mv643xx_private *mp Ethernet Port Control srtuct. * * OUTPUT: - * The routine updates the Ethernet port control struct with information - * regarding the Rx descriptors and buffers. + * The routine updates the Ethernet port control struct with information + * regarding the Rx descriptors and buffers. * * RETURN: - * false if the given descriptors memory area is not aligned according to - * Ethernet SDMA specifications. - * true otherwise. + * None. */ -static int ether_init_rx_desc_ring(struct mv64340_private * mp, - unsigned long rx_buff_base_addr) +static void ether_init_rx_desc_ring(struct mv643xx_private *mp) { - unsigned long buffer_addr = rx_buff_base_addr; volatile struct eth_rx_desc *p_rx_desc; int rx_desc_num = mp->rx_ring_size; - unsigned long rx_desc_base_addr = (unsigned long) mp->p_rx_desc_area; - int rx_buff_size = 1536; /* Dummy, will be replaced later */ int i; - p_rx_desc = (struct eth_rx_desc *) rx_desc_base_addr; - - /* Rx desc Must be 4LW aligned (i.e. Descriptor_Address[3:0]=0000). */ - if (rx_buff_base_addr & 0xf) - return 0; - - /* Rx buffers are limited to 64K bytes and Minimum size is 8 bytes */ - if ((rx_buff_size < 8) || (rx_buff_size > RX_BUFFER_MAX_SIZE)) - return 0; - - /* Rx buffers must be 64-bit aligned. */ - if ((rx_buff_base_addr + rx_buff_size) & 0x7) - return 0; - - /* initialize the Rx descriptors ring */ + /* initialize the next_desc_ptr links in the Rx descriptors ring */ + p_rx_desc = (struct eth_rx_desc *)mp->p_rx_desc_area; for (i = 0; i < rx_desc_num; i++) { - p_rx_desc[i].buf_size = rx_buff_size; - p_rx_desc[i].byte_cnt = 0x0000; - p_rx_desc[i].cmd_sts = - ETH_BUFFER_OWNED_BY_DMA | ETH_RX_ENABLE_INTERRUPT; p_rx_desc[i].next_desc_ptr = mp->rx_desc_dma + ((i + 1) % rx_desc_num) * sizeof(struct eth_rx_desc); - p_rx_desc[i].buf_ptr = buffer_addr; - - mp->rx_skb[i] = NULL; - buffer_addr += rx_buff_size; } /* Save Rx desc pointer to driver struct. */ @@ -766,293 +737,288 @@ mp->rx_desc_area_size = rx_desc_num * sizeof(struct eth_rx_desc); + /* Add the queue to the list of RX queues of this port */ mp->port_rx_queue_command |= 1; - - return 1; } /* * ether_init_tx_desc_ring - Curve a Tx chain desc list and buffer in memory. * * DESCRIPTION: - * This function prepares a Tx chained list of descriptors and packet - * buffers in a form of a ring. The routine must be called after port - * initialization routine and before port start routine. - * The Ethernet SDMA engine uses CPU bus addresses to access the various - * devices in the system (i.e. DRAM). This function uses the ethernet - * struct 'virtual to physical' routine (set by the user) to set the ring - * with physical addresses. + * This function prepares a Tx chained list of descriptors and packet + * buffers in a form of a ring. The routine must be called after port + * initialization routine and before port start routine. + * The Ethernet SDMA engine uses CPU bus addresses to access the various + * devices in the system (i.e. DRAM). This function uses the ethernet + * struct 'virtual to physical' routine (set by the user) to set the ring + * with physical addresses. * * INPUT: - * struct mv64340_private *mp Ethernet Port Control srtuct. - * int tx_desc_num Number of Tx descriptors - * int tx_buff_size Size of Tx buffer - * unsigned int tx_desc_base_addr Tx descriptors memory area base addr. + * struct mv643xx_private *mp Ethernet Port Control srtuct. * * OUTPUT: - * The routine updates the Ethernet port control struct with information - * regarding the Tx descriptors and buffers. + * The routine updates the Ethernet port control struct with information + * regarding the Tx descriptors and buffers. * * RETURN: - * false if the given descriptors memory area is not aligned according to - * Ethernet SDMA specifications. - * true otherwise. + * None. */ -static int ether_init_tx_desc_ring(struct mv64340_private *mp) +static void ether_init_tx_desc_ring(struct mv643xx_private *mp) { - unsigned long tx_desc_base_addr = (unsigned long) mp->p_tx_desc_area; int tx_desc_num = mp->tx_ring_size; struct eth_tx_desc *p_tx_desc; int i; - /* Tx desc Must be 4LW aligned (i.e. Descriptor_Address[3:0]=0000). */ - if (tx_desc_base_addr & 0xf) - return 0; - - /* save the first desc pointer to link with the last descriptor */ - p_tx_desc = (struct eth_tx_desc *) tx_desc_base_addr; - - /* Initialize the Tx descriptors ring */ + /* Initialize the next_desc_ptr links in the Tx descriptors ring */ + p_tx_desc = (struct eth_tx_desc *)mp->p_tx_desc_area; for (i = 0; i < tx_desc_num; i++) { - p_tx_desc[i].byte_cnt = 0x0000; - p_tx_desc[i].l4i_chk = 0x0000; - p_tx_desc[i].cmd_sts = 0x00000000; p_tx_desc[i].next_desc_ptr = mp->tx_desc_dma + ((i + 1) % tx_desc_num) * sizeof(struct eth_tx_desc); - p_tx_desc[i].buf_ptr = 0x00000000; - mp->tx_skb[i] = NULL; } - /* Set Tx desc pointer in driver struct. */ mp->tx_curr_desc_q = 0; mp->tx_used_desc_q = 0; -#ifdef MV64340_CHECKSUM_OFFLOAD_TX - mp->tx_first_desc_q = 0; +#ifdef MV643XX_CHECKSUM_OFFLOAD_TX + mp->tx_first_desc_q = 0; #endif - /* Init Tx ring base and size parameters */ - mp->tx_desc_area_size = tx_desc_num * sizeof(struct eth_tx_desc); + + mp->tx_desc_area_size = tx_desc_num * sizeof(struct eth_tx_desc); /* Add the queue to the list of Tx queues of this port */ mp->port_tx_queue_command |= 1; - - return 1; } -/* Helper function for mv64340_eth_open */ -static int mv64340_eth_real_open(struct net_device *dev) +/* Helper function for mv643xx_eth_open */ +static int mv643xx_eth_real_open(struct net_device *dev) { - struct mv64340_private *mp = netdev_priv(dev); + struct mv643xx_private *mp = netdev_priv(dev); unsigned int port_num = mp->port_num; - u32 phy_reg_data; unsigned int size; /* Stop RX Queues */ - MV_WRITE(MV64340_ETH_RECEIVE_QUEUE_COMMAND_REG(port_num), - 0x0000ff00); + mv_write(MV643XX_ETH_RECEIVE_QUEUE_COMMAND_REG(port_num), 0x0000ff00); /* Clear the ethernet port interrupts */ - MV_WRITE(MV64340_ETH_INTERRUPT_CAUSE_REG(port_num), 0); - MV_WRITE(MV64340_ETH_INTERRUPT_CAUSE_EXTEND_REG(port_num), 0); + mv_write(MV643XX_ETH_INTERRUPT_CAUSE_REG(port_num), 0); + mv_write(MV643XX_ETH_INTERRUPT_CAUSE_EXTEND_REG(port_num), 0); /* Unmask RX buffer and TX end interrupt */ - MV_WRITE(MV64340_ETH_INTERRUPT_MASK_REG(port_num), - INT_CAUSE_UNMASK_ALL); + mv_write(MV643XX_ETH_INTERRUPT_MASK_REG(port_num), + INT_CAUSE_UNMASK_ALL); /* Unmask phy and link status changes interrupts */ - MV_WRITE(MV64340_ETH_INTERRUPT_EXTEND_MASK_REG(port_num), - INT_CAUSE_UNMASK_ALL_EXT); + mv_write(MV643XX_ETH_INTERRUPT_EXTEND_MASK_REG(port_num), + INT_CAUSE_UNMASK_ALL_EXT); /* Set the MAC Address */ memcpy(mp->port_mac_addr, dev->dev_addr, 6); eth_port_init(mp); - INIT_WORK(&mp->rx_task, (void (*)(void *)) mv64340_eth_rx_task, dev); + INIT_WORK(&mp->rx_task, (void (*)(void *))mv643xx_eth_rx_task, dev); memset(&mp->timeout, 0, sizeof(struct timer_list)); - mp->timeout.function = mv64340_eth_rx_task_timer_wrapper; - mp->timeout.data = (unsigned long) dev; + mp->timeout.function = mv643xx_eth_rx_task_timer_wrapper; + mp->timeout.data = (unsigned long)dev; mp->rx_task_busy = 0; mp->rx_timer_flag = 0; + /* Allocate RX and TX skb rings */ + mp->rx_skb = kmalloc(sizeof(*mp->rx_skb) * mp->rx_ring_size, + GFP_KERNEL); + if (!mp->rx_skb) { + printk(KERN_ERR "%s: Cannot allocate Rx skb ring\n", dev->name); + return -ENOMEM; + } + mp->tx_skb = kmalloc(sizeof(*mp->tx_skb) * mp->tx_ring_size, + GFP_KERNEL); + if (!mp->tx_skb) { + printk(KERN_ERR "%s: Cannot allocate Tx skb ring\n", dev->name); + kfree(mp->rx_skb); + return -ENOMEM; + } + /* Allocate TX ring */ mp->tx_ring_skbs = 0; - mp->tx_ring_size = MV64340_TX_QUEUE_SIZE; size = mp->tx_ring_size * sizeof(struct eth_tx_desc); mp->tx_desc_area_size = size; - /* Assumes allocated ring is 16 bytes alligned */ - mp->p_tx_desc_area = pci_alloc_consistent(NULL, size, &mp->tx_desc_dma); + if (mp->tx_sram_size) { + mp->p_tx_desc_area = ioremap(mp->tx_sram_addr, + mp->tx_sram_size); + mp->tx_desc_dma = mp->tx_sram_addr; + } else + mp->p_tx_desc_area = dma_alloc_coherent(NULL, size, + &mp->tx_desc_dma, + GFP_KERNEL); + if (!mp->p_tx_desc_area) { printk(KERN_ERR "%s: Cannot allocate Tx Ring (size %d bytes)\n", - dev->name, size); + dev->name, size); + kfree(mp->rx_skb); + kfree(mp->tx_skb); return -ENOMEM; } - memset((void *) mp->p_tx_desc_area, 0, mp->tx_desc_area_size); + BUG_ON((u32) mp->p_tx_desc_area & 0xf); /* check 16-byte alignment */ + memset((void *)mp->p_tx_desc_area, 0, mp->tx_desc_area_size); - /* Dummy will be replaced upon real tx */ ether_init_tx_desc_ring(mp); /* Allocate RX ring */ - /* Meantime RX Ring are fixed - but must be configurable by user */ - mp->rx_ring_size = MV64340_RX_QUEUE_SIZE; mp->rx_ring_skbs = 0; size = mp->rx_ring_size * sizeof(struct eth_rx_desc); mp->rx_desc_area_size = size; - /* Assumes allocated ring is 16 bytes aligned */ - - mp->p_rx_desc_area = pci_alloc_consistent(NULL, size, &mp->rx_desc_dma); + if (mp->rx_sram_size) { + mp->p_rx_desc_area = ioremap(mp->rx_sram_addr, + mp->rx_sram_size); + mp->rx_desc_dma = mp->rx_sram_addr; + } else + mp->p_rx_desc_area = dma_alloc_coherent(NULL, size, + &mp->rx_desc_dma, + GFP_KERNEL); if (!mp->p_rx_desc_area) { printk(KERN_ERR "%s: Cannot allocate Rx ring (size %d bytes)\n", - dev->name, size); + dev->name, size); printk(KERN_ERR "%s: Freeing previously allocated TX queues...", - dev->name); - pci_free_consistent(0, mp->tx_desc_area_size, - (void *) mp->p_tx_desc_area, - mp->tx_desc_dma); + dev->name); + if (mp->rx_sram_size) + iounmap(mp->p_rx_desc_area); + else + dma_free_coherent(NULL, mp->tx_desc_area_size, + mp->p_tx_desc_area, mp->tx_desc_dma); + kfree(mp->rx_skb); + kfree(mp->tx_skb); return -ENOMEM; } - memset(mp->p_rx_desc_area, 0, size); + memset((void *)mp->p_rx_desc_area, 0, size); - if (!(ether_init_rx_desc_ring(mp, 0))) - panic("%s: Error initializing RX Ring", dev->name); + ether_init_rx_desc_ring(mp); - mv64340_eth_rx_task(dev); /* Fill RX ring with skb's */ + mv643xx_eth_rx_task(dev); /* Fill RX ring with skb's */ eth_port_start(mp); /* Interrupt Coalescing */ -#ifdef MV64340_COAL +#ifdef MV643XX_COAL mp->rx_int_coal = - eth_port_set_rx_coal(port_num, 133000000, MV64340_RX_COAL); + eth_port_set_rx_coal(port_num, 133000000, MV643XX_RX_COAL); #endif mp->tx_int_coal = - eth_port_set_tx_coal (port_num, 133000000, MV64340_TX_COAL); + eth_port_set_tx_coal(port_num, 133000000, MV643XX_TX_COAL); - /* Increase the Rx side buffer size */ - - MV_WRITE (MV64340_ETH_PORT_SERIAL_CONTROL_REG(port_num), (0x5 << 17) | - (MV_READ(MV64340_ETH_PORT_SERIAL_CONTROL_REG(port_num)) - & 0xfff1ffff)); - - /* Check Link status on phy */ - eth_port_read_smi_reg(port_num, 1, &phy_reg_data); - if (!(phy_reg_data & 0x20)) - netif_stop_queue(dev); - else - netif_start_queue(dev); + netif_start_queue(dev); return 0; } -static void mv64340_eth_free_tx_rings(struct net_device *dev) +static void mv643xx_eth_free_tx_rings(struct net_device *dev) { - struct mv64340_private *mp = netdev_priv(dev); + struct mv643xx_private *mp = netdev_priv(dev); unsigned int port_num = mp->port_num; unsigned int curr; /* Stop Tx Queues */ - MV_WRITE(MV64340_ETH_TRANSMIT_QUEUE_COMMAND_REG(port_num), - 0x0000ff00); + mv_write(MV643XX_ETH_TRANSMIT_QUEUE_COMMAND_REG(port_num), 0x0000ff00); - /* Free TX rings */ /* Free outstanding skb's on TX rings */ - for (curr = 0; - (mp->tx_ring_skbs) && (curr < MV64340_TX_QUEUE_SIZE); - curr++) { + for (curr = 0; mp->tx_ring_skbs && curr < mp->tx_ring_size; curr++) { if (mp->tx_skb[curr]) { dev_kfree_skb(mp->tx_skb[curr]); mp->tx_ring_skbs--; } } - if (mp->tx_ring_skbs != 0) + if (mp->tx_ring_skbs) printk("%s: Error on Tx descriptor free - could not free %d" - " descriptors\n", dev->name, - mp->tx_ring_skbs); - pci_free_consistent(0, mp->tx_desc_area_size, - (void *) mp->p_tx_desc_area, mp->tx_desc_dma); + " descriptors\n", dev->name, mp->tx_ring_skbs); + + /* Free TX ring */ + if (mp->tx_sram_size) + iounmap(mp->p_tx_desc_area); + else + dma_free_coherent(NULL, mp->tx_desc_area_size, + mp->p_tx_desc_area, mp->tx_desc_dma); } -static void mv64340_eth_free_rx_rings(struct net_device *dev) +static void mv643xx_eth_free_rx_rings(struct net_device *dev) { - struct mv64340_private *mp = netdev_priv(dev); + struct mv643xx_private *mp = netdev_priv(dev); unsigned int port_num = mp->port_num; int curr; /* Stop RX Queues */ - MV_WRITE(MV64340_ETH_RECEIVE_QUEUE_COMMAND_REG(port_num), - 0x0000ff00); + mv_write(MV643XX_ETH_RECEIVE_QUEUE_COMMAND_REG(port_num), 0x0000ff00); - /* Free RX rings */ /* Free preallocated skb's on RX rings */ - for (curr = 0; - mp->rx_ring_skbs && (curr < MV64340_RX_QUEUE_SIZE); - curr++) { + for (curr = 0; mp->rx_ring_skbs && curr < mp->rx_ring_size; curr++) { if (mp->rx_skb[curr]) { dev_kfree_skb(mp->rx_skb[curr]); mp->rx_ring_skbs--; } } - if (mp->rx_ring_skbs != 0) + if (mp->rx_ring_skbs) printk(KERN_ERR - "%s: Error in freeing Rx Ring. %d skb's still" - " stuck in RX Ring - ignoring them\n", dev->name, - mp->rx_ring_skbs); - pci_free_consistent(0, mp->rx_desc_area_size, - (void *) mp->p_rx_desc_area, - mp->rx_desc_dma); + "%s: Error in freeing Rx Ring. %d skb's still" + " stuck in RX Ring - ignoring them\n", dev->name, + mp->rx_ring_skbs); + /* Free RX ring */ + if (mp->rx_sram_size) + iounmap(mp->p_rx_desc_area); + else + dma_free_coherent(NULL, mp->rx_desc_area_size, + mp->p_rx_desc_area, mp->rx_desc_dma); } /* - * mv64340_eth_stop + * mv643xx_eth_stop * - * This function is used when closing the network device. - * It updates the hardware, + * This function is used when closing the network device. + * It updates the hardware, * release all memory that holds buffers and descriptors and release the IRQ. - * Input : a pointer to the device structure - * Output : zero if success , nonzero if fails + * Input : a pointer to the device structure + * Output : zero if success , nonzero if fails */ -/* Helper function for mv64340_eth_stop */ +/* Helper function for mv643xx_eth_stop */ -static int mv64340_eth_real_stop(struct net_device *dev) +static int mv643xx_eth_real_stop(struct net_device *dev) { - struct mv64340_private *mp = netdev_priv(dev); + struct mv643xx_private *mp = netdev_priv(dev); unsigned int port_num = mp->port_num; + netif_carrier_off(dev); netif_stop_queue(dev); - mv64340_eth_free_tx_rings(dev); - mv64340_eth_free_rx_rings(dev); + mv643xx_eth_free_tx_rings(dev); + mv643xx_eth_free_rx_rings(dev); eth_port_reset(mp->port_num); /* Disable ethernet port interrupts */ - MV_WRITE(MV64340_ETH_INTERRUPT_CAUSE_REG(port_num), 0); - MV_WRITE(MV64340_ETH_INTERRUPT_CAUSE_EXTEND_REG(port_num), 0); + mv_write(MV643XX_ETH_INTERRUPT_CAUSE_REG(port_num), 0); + mv_write(MV643XX_ETH_INTERRUPT_CAUSE_EXTEND_REG(port_num), 0); /* Mask RX buffer and TX end interrupt */ - MV_WRITE(MV64340_ETH_INTERRUPT_MASK_REG(port_num), 0); + mv_write(MV643XX_ETH_INTERRUPT_MASK_REG(port_num), 0); /* Mask phy and link status changes interrupts */ - MV_WRITE(MV64340_ETH_INTERRUPT_EXTEND_MASK_REG(port_num), 0); + mv_write(MV643XX_ETH_INTERRUPT_EXTEND_MASK_REG(port_num), 0); return 0; } -static int mv64340_eth_stop(struct net_device *dev) +static int mv643xx_eth_stop(struct net_device *dev) { - struct mv64340_private *mp = netdev_priv(dev); + struct mv643xx_private *mp = netdev_priv(dev); spin_lock_irq(&mp->lock); - mv64340_eth_real_stop(dev); + mv643xx_eth_real_stop(dev); free_irq(dev->irq, dev); spin_unlock_irq(&mp->lock); @@ -1060,59 +1026,64 @@ return 0; } -#ifdef MV64340_NAPI -static void mv64340_tx(struct net_device *dev) +#ifdef MV643XX_NAPI +static void mv643xx_tx(struct net_device *dev) { - struct mv64340_private *mp = netdev_priv(dev); - struct pkt_info pkt_info; + struct mv643xx_private *mp = netdev_priv(dev); + struct pkt_info pkt_info; while (eth_tx_return_desc(mp, &pkt_info) == ETH_OK) { if (pkt_info.return_info) { - dev_kfree_skb_irq((struct sk_buff *) - pkt_info.return_info); - if (skb_shinfo(pkt_info.return_info)->nr_frags) - pci_unmap_page(NULL, pkt_info.buf_ptr, - pkt_info.byte_cnt, - PCI_DMA_TODEVICE); - - if (mp->tx_ring_skbs != 1) - mp->tx_ring_skbs--; - } else - pci_unmap_page(NULL, pkt_info.buf_ptr, pkt_info.byte_cnt, - PCI_DMA_TODEVICE); + if (skb_shinfo(pkt_info.return_info)->nr_frags) + dma_unmap_page(NULL, pkt_info.buf_ptr, + pkt_info.byte_cnt, + DMA_TO_DEVICE); + else + dma_unmap_single(NULL, pkt_info.buf_ptr, + pkt_info.byte_cnt, + DMA_TO_DEVICE); + + dev_kfree_skb_irq(pkt_info.return_info); + + if (mp->tx_ring_skbs) + mp->tx_ring_skbs--; + } else + dma_unmap_page(NULL, pkt_info.buf_ptr, + pkt_info.byte_cnt, DMA_TO_DEVICE); } if (netif_queue_stopped(dev) && - MV64340_TX_QUEUE_SIZE > mp->tx_ring_skbs + 1) - netif_wake_queue(dev); + mp->tx_ring_size > mp->tx_ring_skbs + MAX_DESCS_PER_SKB) + netif_wake_queue(dev); } /* - * mv64340_poll + * mv643xx_poll * * This function is used in case of NAPI */ -static int mv64340_poll(struct net_device *dev, int *budget) +static int mv643xx_poll(struct net_device *dev, int *budget) { - struct mv64340_private *mp = netdev_priv(dev); - int done = 1, orig_budget, work_done; + struct mv643xx_private *mp = netdev_priv(dev); + int done = 1, orig_budget, work_done; unsigned int port_num = mp->port_num; unsigned long flags; -#ifdef MV64340_TX_FAST_REFILL +#ifdef MV643XX_TX_FAST_REFILL if (++mp->tx_clean_threshold > 5) { spin_lock_irqsave(&mp->lock, flags); - mv64340_tx(dev); + mv643xx_tx(dev); mp->tx_clean_threshold = 0; spin_unlock_irqrestore(&mp->lock, flags); } #endif - if ((u32)(MV_READ(MV64340_ETH_RX_CURRENT_QUEUE_DESC_PTR_0(port_num))) != (u32)mp->rx_used_desc_q) { + if ((mv_read(MV643XX_ETH_RX_CURRENT_QUEUE_DESC_PTR_0(port_num))) + != (u32) mp->rx_used_desc_q) { orig_budget = *budget; if (orig_budget > dev->quota) orig_budget = dev->quota; - work_done = mv64340_eth_receive_queue(dev, 0, orig_budget); + work_done = mv643xx_eth_receive_queue(dev, orig_budget); mp->rx_task.func(dev); *budget -= work_done; dev->quota -= work_done; @@ -1123,12 +1094,12 @@ if (done) { spin_lock_irqsave(&mp->lock, flags); __netif_rx_complete(dev); - MV_WRITE(MV64340_ETH_INTERRUPT_CAUSE_REG(port_num),0); - MV_WRITE(MV64340_ETH_INTERRUPT_CAUSE_EXTEND_REG(port_num),0); - MV_WRITE(MV64340_ETH_INTERRUPT_MASK_REG(port_num), + mv_write(MV643XX_ETH_INTERRUPT_CAUSE_REG(port_num), 0); + mv_write(MV643XX_ETH_INTERRUPT_CAUSE_EXTEND_REG(port_num), 0); + mv_write(MV643XX_ETH_INTERRUPT_MASK_REG(port_num), INT_CAUSE_UNMASK_ALL); - MV_WRITE(MV64340_ETH_INTERRUPT_EXTEND_MASK_REG(port_num), - INT_CAUSE_UNMASK_ALL_EXT); + mv_write(MV643XX_ETH_INTERRUPT_EXTEND_MASK_REG(port_num), + INT_CAUSE_UNMASK_ALL_EXT); spin_unlock_irqrestore(&mp->lock, flags); } @@ -1137,19 +1108,19 @@ #endif /* - * mv64340_eth_start_xmit + * mv643xx_eth_start_xmit * - * This function is queues a packet in the Tx descriptor for + * This function is queues a packet in the Tx descriptor for * required port. * - * Input : skb - a pointer to socket buffer - * dev - a pointer to the required port + * Input : skb - a pointer to socket buffer + * dev - a pointer to the required port * - * Output : zero upon success + * Output : zero upon success */ -static int mv64340_eth_start_xmit(struct sk_buff *skb, struct net_device *dev) +static int mv643xx_eth_start_xmit(struct sk_buff *skb, struct net_device *dev) { - struct mv64340_private *mp = netdev_priv(dev); + struct mv643xx_private *mp = netdev_priv(dev); struct net_device_stats *stats = &mp->stats; ETH_FUNC_RET_STATUS status; unsigned long flags; @@ -1157,119 +1128,195 @@ if (netif_queue_stopped(dev)) { printk(KERN_ERR - "%s: Tried sending packet when interface is stopped\n", - dev->name); + "%s: Tried sending packet when interface is stopped\n", + dev->name); return 1; } /* This is a hard error, log it. */ - if ((MV64340_TX_QUEUE_SIZE - mp->tx_ring_skbs) <= - (skb_shinfo(skb)->nr_frags + 1)) { + if ((mp->tx_ring_size - mp->tx_ring_skbs) <= + (skb_shinfo(skb)->nr_frags + 1)) { netif_stop_queue(dev); printk(KERN_ERR - "%s: Bug in mv64340_eth - Trying to transmit when" - " queue full !\n", dev->name); + "%s: Bug in mv643xx_eth - Trying to transmit when" + " queue full !\n", dev->name); return 1; } /* Paranoid check - this shouldn't happen */ if (skb == NULL) { stats->tx_dropped++; + printk(KERN_ERR "mv64320_eth paranoid check failed\n"); return 1; } spin_lock_irqsave(&mp->lock, flags); /* Update packet info data structure -- DMA owned, first last */ -#ifdef MV64340_CHECKSUM_OFFLOAD_TX - if (!skb_shinfo(skb)->nr_frags || (skb_shinfo(skb)->nr_frags > 3)) { -#endif - pkt_info.cmd_sts = ETH_TX_ENABLE_INTERRUPT | - ETH_TX_FIRST_DESC | ETH_TX_LAST_DESC; +#ifdef MV643XX_CHECKSUM_OFFLOAD_TX + if (!skb_shinfo(skb)->nr_frags) { +linear: + if (skb->ip_summed != CHECKSUM_HW) { + pkt_info.cmd_sts = ETH_TX_ENABLE_INTERRUPT | + ETH_TX_FIRST_DESC | ETH_TX_LAST_DESC; + pkt_info.l4i_chk = 0; + } else { + u32 ipheader = skb->nh.iph->ihl << 11; + pkt_info.cmd_sts = ETH_TX_ENABLE_INTERRUPT | + ETH_TX_FIRST_DESC | ETH_TX_LAST_DESC | + ETH_GEN_TCP_UDP_CHECKSUM | + ETH_GEN_IP_V_4_CHECKSUM | ipheader; + /* CPU already calculated pseudo header checksum. */ + if (skb->nh.iph->protocol == IPPROTO_UDP) { + pkt_info.cmd_sts |= ETH_UDP_FRAME; + pkt_info.l4i_chk = skb->h.uh->check; + } else if (skb->nh.iph->protocol == IPPROTO_TCP) + pkt_info.l4i_chk = skb->h.th->check; + else { + printk(KERN_ERR + "%s: chksum proto != TCP or UDP\n", + dev->name); + spin_unlock_irqrestore(&mp->lock, flags); + return 1; + } + } pkt_info.byte_cnt = skb->len; - pkt_info.buf_ptr = pci_map_single(0, skb->data, skb->len, - PCI_DMA_TODEVICE); - - + pkt_info.buf_ptr = dma_map_single(NULL, skb->data, skb->len, + DMA_TO_DEVICE); pkt_info.return_info = skb; + mp->tx_ring_skbs++; status = eth_port_send(mp, &pkt_info); if ((status == ETH_ERROR) || (status == ETH_QUEUE_FULL)) printk(KERN_ERR "%s: Error on transmitting packet\n", - dev->name); - mp->tx_ring_skbs++; -#ifdef MV64340_CHECKSUM_OFFLOAD_TX + dev->name); + stats->tx_bytes += pkt_info.byte_cnt; } else { - unsigned int frag; - u32 ipheader; + unsigned int frag; + u32 ipheader; - /* first frag which is skb header */ - pkt_info.byte_cnt = skb_headlen(skb); - pkt_info.buf_ptr = pci_map_single(0, skb->data, - skb_headlen(skb), PCI_DMA_TODEVICE); - pkt_info.return_info = 0; - ipheader = skb->nh.iph->ihl << 11; - pkt_info.cmd_sts = ETH_TX_FIRST_DESC | - ETH_GEN_TCP_UDP_CHECKSUM | - ETH_GEN_IP_V_4_CHECKSUM | - ipheader; - /* CPU already calculated pseudo header checksum. So, use it */ - pkt_info.l4i_chk = skb->h.th->check; - status = eth_port_send(mp, &pkt_info); + /* Since hardware can't handle unaligned fragments smaller + * than 9 bytes, if we find any, we linearize the skb + * and start again. When I've seen it, it's always been + * the first frag (probably near the end of the page), + * but we check all frags to be safe. + */ + for (frag = 0; frag < skb_shinfo(skb)->nr_frags; frag++) { + skb_frag_t *fragp; + + fragp = &skb_shinfo(skb)->frags[frag]; + if (fragp->size <= 8 && fragp->page_offset & 0x7) { + skb_linearize(skb, GFP_ATOMIC); + printk(KERN_DEBUG "%s: unaligned tiny fragment" + "%d of %d, fixed\n", + dev->name, frag, + skb_shinfo(skb)->nr_frags); + goto linear; + } + } + + /* first frag which is skb header */ + pkt_info.byte_cnt = skb_headlen(skb); + pkt_info.buf_ptr = dma_map_single(NULL, skb->data, + skb_headlen(skb), + DMA_TO_DEVICE); + pkt_info.l4i_chk = 0; + pkt_info.return_info = 0; + pkt_info.cmd_sts = ETH_TX_FIRST_DESC; + + if (skb->ip_summed == CHECKSUM_HW) { + ipheader = skb->nh.iph->ihl << 11; + pkt_info.cmd_sts |= ETH_GEN_TCP_UDP_CHECKSUM | + ETH_GEN_IP_V_4_CHECKSUM | ipheader; + /* CPU already calculated pseudo header checksum. */ + if (skb->nh.iph->protocol == IPPROTO_UDP) { + pkt_info.cmd_sts |= ETH_UDP_FRAME; + pkt_info.l4i_chk = skb->h.uh->check; + } else if (skb->nh.iph->protocol == IPPROTO_TCP) + pkt_info.l4i_chk = skb->h.th->check; + else { + printk(KERN_ERR + "%s: chksum proto != TCP or UDP\n", + dev->name); + spin_unlock_irqrestore(&mp->lock, flags); + return 1; + } + } + + status = eth_port_send(mp, &pkt_info); if (status != ETH_OK) { - if ((status == ETH_ERROR)) - printk(KERN_ERR "%s: Error on transmitting packet\n", dev->name); - if (status == ETH_QUEUE_FULL) - printk("Error on Queue Full \n"); - if (status == ETH_QUEUE_LAST_RESOURCE) - printk("Tx resource error \n"); + if ((status == ETH_ERROR)) + printk(KERN_ERR + "%s: Error on transmitting packet\n", + dev->name); + if (status == ETH_QUEUE_FULL) + printk("Error on Queue Full \n"); + if (status == ETH_QUEUE_LAST_RESOURCE) + printk("Tx resource error \n"); } + stats->tx_bytes += pkt_info.byte_cnt; + + /* Check for the remaining frags */ + for (frag = 0; frag < skb_shinfo(skb)->nr_frags; frag++) { + skb_frag_t *this_frag = &skb_shinfo(skb)->frags[frag]; + pkt_info.l4i_chk = 0x0000; + pkt_info.cmd_sts = 0x00000000; + + /* Last Frag enables interrupt and frees the skb */ + if (frag == (skb_shinfo(skb)->nr_frags - 1)) { + pkt_info.cmd_sts |= ETH_TX_ENABLE_INTERRUPT | + ETH_TX_LAST_DESC; + pkt_info.return_info = skb; + mp->tx_ring_skbs++; + } else { + pkt_info.return_info = 0; + } + pkt_info.l4i_chk = 0; + pkt_info.byte_cnt = this_frag->size; - /* Check for the remaining frags */ - for (frag = 0; frag < skb_shinfo(skb)->nr_frags; frag++) { - skb_frag_t *this_frag = &skb_shinfo(skb)->frags[frag]; - pkt_info.l4i_chk = 0x0000; - pkt_info.cmd_sts = 0x00000000; - - /* Last Frag enables interrupt and frees the skb */ - if (frag == (skb_shinfo(skb)->nr_frags - 1)) { - pkt_info.cmd_sts |= ETH_TX_ENABLE_INTERRUPT | - ETH_TX_LAST_DESC; - pkt_info.return_info = skb; - mp->tx_ring_skbs++; - } - else { - pkt_info.return_info = 0; - } - pkt_info.byte_cnt = this_frag->size; - if (this_frag->size < 8) - printk("%d : \n", skb_shinfo(skb)->nr_frags); - - pkt_info.buf_ptr = pci_map_page(NULL, this_frag->page, - this_frag->page_offset, - this_frag->size, PCI_DMA_TODEVICE); + pkt_info.buf_ptr = dma_map_page(NULL, this_frag->page, + this_frag->page_offset, + this_frag->size, + DMA_TO_DEVICE); - status = eth_port_send(mp, &pkt_info); + status = eth_port_send(mp, &pkt_info); if (status != ETH_OK) { - if ((status == ETH_ERROR)) - printk(KERN_ERR "%s: Error on transmitting packet\n", dev->name); + if ((status == ETH_ERROR)) + printk(KERN_ERR "%s: Error on " + "transmitting packet\n", + dev->name); - if (status == ETH_QUEUE_LAST_RESOURCE) - printk("Tx resource error \n"); + if (status == ETH_QUEUE_LAST_RESOURCE) + printk("Tx resource error \n"); - if (status == ETH_QUEUE_FULL) - printk("Queue is full \n"); + if (status == ETH_QUEUE_FULL) + printk("Queue is full \n"); } - } - } + stats->tx_bytes += pkt_info.byte_cnt; + } + } +#else + pkt_info.cmd_sts = ETH_TX_ENABLE_INTERRUPT | ETH_TX_FIRST_DESC | + ETH_TX_LAST_DESC; + pkt_info.l4i_chk = 0; + pkt_info.byte_cnt = skb->len; + pkt_info.buf_ptr = dma_map_single(NULL, skb->data, skb->len, + DMA_TO_DEVICE); + pkt_info.return_info = skb; + mp->tx_ring_skbs++; + status = eth_port_send(mp, &pkt_info); + if ((status == ETH_ERROR) || (status == ETH_QUEUE_FULL)) + printk(KERN_ERR "%s: Error on transmitting packet\n", + dev->name); + stats->tx_bytes += pkt_info.byte_cnt; #endif /* Check if TX queue can handle another skb. If not, then * signal higher layers to stop requesting TX */ - if (MV64340_TX_QUEUE_SIZE <= (mp->tx_ring_skbs + 1)) - /* + if (mp->tx_ring_size <= (mp->tx_ring_skbs + MAX_DESCS_PER_SKB)) + /* * Stop getting skb's from upper layers. * Getting skb's from upper layers will be enabled again after * packets are released. @@ -1277,7 +1324,6 @@ netif_stop_queue(dev); /* Update statistics and start of transmittion time */ - stats->tx_bytes += skb->len; stats->tx_packets++; dev->trans_start = jiffies; @@ -1287,212 +1333,302 @@ } /* - * mv64340_eth_get_stats + * mv643xx_eth_get_stats * * Returns a pointer to the interface statistics. * - * Input : dev - a pointer to the required interface + * Input : dev - a pointer to the required interface * - * Output : a pointer to the interface's statistics + * Output : a pointer to the interface's statistics */ -static struct net_device_stats *mv64340_eth_get_stats(struct net_device *dev) +static struct net_device_stats *mv643xx_eth_get_stats(struct net_device *dev) { - struct mv64340_private *mp = netdev_priv(dev); + struct mv643xx_private *mp = netdev_priv(dev); return &mp->stats; } /*/ - * mv64340_eth_init - * - * First function called after registering the network device. - * It's purpose is to initialize the device as an ethernet device, - * fill the structure that was given in registration with pointers - * to functions, and setting the MAC address of the interface + * mv643xx_eth_probe * - * Input : number of port to initialize - * Output : -ENONMEM if failed , 0 if success - */ -static struct net_device *mv64340_eth_init(int port_num) -{ - struct mv64340_private *mp; + * First function called after registering the network device. + * It's purpose is to initialize the device as an ethernet device, + * fill the ethernet device structure with pointers * to functions, + * and set the MAC address of the interface + * + * Input : struct device * + * Output : -ENOMEM if failed , 0 if success + */ +static int mv643xx_eth_probe(struct device *ddev) +{ + struct platform_device *pdev = to_platform_device(ddev); + struct mv643xx_eth_platform_data *pd; + int port_num = pdev->id; + struct mv643xx_private *mp; struct net_device *dev; + u8 *p; + struct resource *res; int err; - dev = alloc_etherdev(sizeof(struct mv64340_private)); + dev = alloc_etherdev(sizeof(struct mv643xx_private)); if (!dev) - return NULL; + return -ENOMEM; + + dev_set_drvdata(ddev, dev); mp = netdev_priv(dev); - dev->irq = ETH_PORT0_IRQ_NUM + port_num; + res = platform_get_resource(pdev, IORESOURCE_IRQ, 0); + BUG_ON(!res); + dev->irq = res->start; - dev->open = mv64340_eth_open; - dev->stop = mv64340_eth_stop; - dev->hard_start_xmit = mv64340_eth_start_xmit; - dev->get_stats = mv64340_eth_get_stats; - dev->set_mac_address = mv64340_eth_set_mac_address; - dev->set_multicast_list = mv64340_eth_set_rx_mode; + mp->port_num = port_num; + + dev->open = mv643xx_eth_open; + dev->stop = mv643xx_eth_stop; + dev->hard_start_xmit = mv643xx_eth_start_xmit; + dev->get_stats = mv643xx_eth_get_stats; + dev->set_mac_address = mv643xx_eth_set_mac_address; + dev->set_multicast_list = mv643xx_eth_set_rx_mode; /* No need to Tx Timeout */ - dev->tx_timeout = mv64340_eth_tx_timeout; -#ifdef MV64340_NAPI - dev->poll = mv64340_poll; - dev->weight = 64; + dev->tx_timeout = mv643xx_eth_tx_timeout; +#ifdef MV643XX_NAPI + dev->poll = mv643xx_poll; + dev->weight = 64; #endif dev->watchdog_timeo = 2 * HZ; - dev->tx_queue_len = MV64340_TX_QUEUE_SIZE; + dev->tx_queue_len = mp->tx_ring_size; dev->base_addr = 0; - dev->change_mtu = mv64340_eth_change_mtu; + dev->change_mtu = mv643xx_eth_change_mtu; + SET_ETHTOOL_OPS(dev, &mv643xx_ethtool_ops); -#ifdef MV64340_CHECKSUM_OFFLOAD_TX +#ifdef MV643XX_CHECKSUM_OFFLOAD_TX #ifdef MAX_SKB_FRAGS - /* - * Zero copy can only work if we use Discovery II memory. Else, we will - * have to map the buffers to ISA memory which is only 16 MB - */ - dev->features = NETIF_F_SG | NETIF_F_IP_CSUM | NETIF_F_HW_CSUM; + /* + * Zero copy can only work if we use Discovery II memory. Else, we will + * have to map the buffers to ISA memory which is only 16 MB + */ + dev->features = NETIF_F_SG | NETIF_F_IP_CSUM | NETIF_F_HW_CSUM; #endif #endif - mp->port_num = port_num; - /* Configure the timeout task */ - INIT_WORK(&mp->tx_timeout_task, - (void (*)(void *))mv64340_eth_tx_timeout_task, dev); + INIT_WORK(&mp->tx_timeout_task, + (void (*)(void *))mv643xx_eth_tx_timeout_task, dev); spin_lock_init(&mp->lock); - /* set MAC addresses */ - memcpy(dev->dev_addr, prom_mac_addr_base, 6); - dev->dev_addr[5] += port_num; + /* set default config values */ + eth_port_uc_addr_get(dev, dev->dev_addr); + mp->port_config = MV643XX_ETH_PORT_CONFIG_DEFAULT_VALUE; + mp->port_config_extend = MV643XX_ETH_PORT_CONFIG_EXTEND_DEFAULT_VALUE; + mp->port_sdma_config = MV643XX_ETH_PORT_SDMA_CONFIG_DEFAULT_VALUE; + mp->port_serial_control = MV643XX_ETH_PORT_SERIAL_CONTROL_DEFAULT_VALUE; + mp->rx_ring_size = MV643XX_ETH_PORT_DEFAULT_RECEIVE_QUEUE_SIZE; + mp->tx_ring_size = MV643XX_ETH_PORT_DEFAULT_TRANSMIT_QUEUE_SIZE; + + pd = pdev->dev.platform_data; + if (pd) { + if (pd->mac_addr != NULL) + memcpy(dev->dev_addr, pd->mac_addr, 6); + + if (pd->phy_addr || pd->force_phy_addr) + ethernet_phy_set(port_num, pd->phy_addr); + + if (pd->port_config || pd->force_port_config) + mp->port_config = pd->port_config; + + if (pd->port_config_extend || pd->force_port_config_extend) + mp->port_config_extend = pd->port_config_extend; + + if (pd->port_sdma_config || pd->force_port_sdma_config) + mp->port_sdma_config = pd->port_sdma_config; + + if (pd->port_serial_control || pd->force_port_serial_control) + mp->port_serial_control = pd->port_serial_control; + + if (pd->rx_queue_size) + mp->rx_ring_size = pd->rx_queue_size; + + if (pd->tx_queue_size) + mp->tx_ring_size = pd->tx_queue_size; + + if (pd->tx_sram_size) { + mp->tx_sram_size = pd->tx_sram_size; + mp->tx_sram_addr = pd->tx_sram_addr; + } + + if (pd->rx_sram_size) { + mp->rx_sram_size = pd->rx_sram_size; + mp->rx_sram_addr = pd->rx_sram_addr; + } + } + + err = ethernet_phy_detect(port_num); + if (err) { + pr_debug("MV643xx ethernet port %d: " + "No PHY detected at addr %d\n", + port_num, ethernet_phy_get(port_num)); + return err; + } err = register_netdev(dev); if (err) - goto out_free_dev; + goto out; - printk(KERN_NOTICE "%s: port %d with MAC address %02x:%02x:%02x:%02x:%02x:%02x\n", - dev->name, port_num, - dev->dev_addr[0], dev->dev_addr[1], dev->dev_addr[2], - dev->dev_addr[3], dev->dev_addr[4], dev->dev_addr[5]); + p = dev->dev_addr; + printk(KERN_NOTICE + "%s: port %d with MAC address %02x:%02x:%02x:%02x:%02x:%02x\n", + dev->name, port_num, p[0], p[1], p[2], p[3], p[4], p[5]); if (dev->features & NETIF_F_SG) - printk("Scatter Gather Enabled "); + printk(KERN_NOTICE "%s: Scatter Gather Enabled\n", dev->name); if (dev->features & NETIF_F_IP_CSUM) - printk("TX TCP/IP Checksumming Supported \n"); + printk(KERN_NOTICE "%s: TX TCP/IP Checksumming Supported\n", + dev->name); + +#ifdef MV643XX_CHECKSUM_OFFLOAD_TX + printk(KERN_NOTICE "%s: RX TCP/UDP Checksum Offload ON \n", dev->name); +#endif - printk("RX TCP/UDP Checksum Offload ON, \n"); - printk("TX and RX Interrupt Coalescing ON \n"); +#ifdef MV643XX_COAL + printk(KERN_NOTICE "%s: TX and RX Interrupt Coalescing ON \n", + dev->name); +#endif -#ifdef MV64340_NAPI - printk("RX NAPI Enabled \n"); +#ifdef MV643XX_NAPI + printk(KERN_NOTICE "%s: RX NAPI Enabled \n", dev->name); #endif - return dev; + return 0; -out_free_dev: +out: free_netdev(dev); - return NULL; + return err; } -static void mv64340_eth_remove(struct net_device *dev) +static int mv643xx_eth_remove(struct device *ddev) { - struct mv64340_private *mp = netdev_priv(dev); + struct net_device *dev = dev_get_drvdata(ddev); unregister_netdev(dev); flush_scheduled_work(); + free_netdev(dev); + dev_set_drvdata(ddev, NULL); + return 0; +} + +static int mv643xx_eth_shared_probe(struct device *ddev) +{ + struct platform_device *pdev = to_platform_device(ddev); + struct resource *res; + + printk(KERN_NOTICE "MV-643xx 10/100/1000 Ethernet Driver\n"); + + res = platform_get_resource(pdev, IORESOURCE_MEM, 0); + if (res == NULL) + return -ENODEV; + + mv643xx_eth_shared_base = ioremap(res->start, + MV643XX_ETH_SHARED_REGS_SIZE); + if (mv643xx_eth_shared_base == NULL) + return -ENOMEM; + + return 0; + +} + +static int mv643xx_eth_shared_remove(struct device *ddev) +{ + iounmap(mv643xx_eth_shared_base); + mv643xx_eth_shared_base = NULL; + + return 0; } -static struct net_device *mv64340_dev0; -static struct net_device *mv64340_dev1; -static struct net_device *mv64340_dev2; +static struct device_driver mv643xx_eth_driver = { + .name = MV643XX_ETH_NAME, + .bus = &platform_bus_type, + .probe = mv643xx_eth_probe, + .remove = mv643xx_eth_remove, +}; + +static struct device_driver mv643xx_eth_shared_driver = { + .name = MV643XX_ETH_SHARED_NAME, + .bus = &platform_bus_type, + .probe = mv643xx_eth_shared_probe, + .remove = mv643xx_eth_shared_remove, +}; /* - * mv64340_init_module + * mv643xx_init_module * * Registers the network drivers into the Linux kernel * - * Input : N/A + * Input : N/A * - * Output : N/A + * Output : N/A */ -static int __init mv64340_init_module(void) +static int __init mv643xx_init_module(void) { - printk(KERN_NOTICE "MV-643xx 10/100/1000 Ethernet Driver\n"); + int rc; -#ifdef CONFIG_MV643XX_ETH_0 - mv64340_dev0 = mv64340_eth_init(0); - if (!mv64340_dev0) { - printk(KERN_ERR - "Error registering MV-64360 ethernet port 0\n"); - } -#endif -#ifdef CONFIG_MV643XX_ETH_1 - mv64340_dev1 = mv64340_eth_init(1); - if (!mv64340_dev1) { - printk(KERN_ERR - "Error registering MV-64360 ethernet port 1\n"); - } -#endif -#ifdef CONFIG_MV643XX_ETH_2 - mv64340_dev2 = mv64340_eth_init(2); - if (!mv64340_dev2) { - printk(KERN_ERR - "Error registering MV-64360 ethernet port 2\n"); + rc = driver_register(&mv643xx_eth_shared_driver); + if (!rc) { + rc = driver_register(&mv643xx_eth_driver); + if (rc) + driver_unregister(&mv643xx_eth_shared_driver); } -#endif - return 0; + return rc; } /* - * mv64340_cleanup_module + * mv643xx_cleanup_module * * Registers the network drivers into the Linux kernel * - * Input : N/A + * Input : N/A * - * Output : N/A + * Output : N/A */ -static void __exit mv64340_cleanup_module(void) +static void __exit mv643xx_cleanup_module(void) { - if (mv64340_dev2) - mv64340_eth_remove(mv64340_dev2); - if (mv64340_dev1) - mv64340_eth_remove(mv64340_dev1); - if (mv64340_dev0) - mv64340_eth_remove(mv64340_dev0); + driver_unregister(&mv643xx_eth_driver); + driver_unregister(&mv643xx_eth_shared_driver); } -module_init(mv64340_init_module); -module_exit(mv64340_cleanup_module); +module_init(mv643xx_init_module); +module_exit(mv643xx_cleanup_module); MODULE_LICENSE("GPL"); -MODULE_AUTHOR("Rabeeh Khoury, Assaf Hoffman, Matthew Dharm and Manish Lachwani"); -MODULE_DESCRIPTION("Ethernet driver for Marvell MV64340"); +MODULE_AUTHOR( "Rabeeh Khoury, Assaf Hoffman, Matthew Dharm, Manish Lachwani" + " and Dale Farnsworth"); +MODULE_DESCRIPTION("Ethernet driver for Marvell MV643XX"); /* - * The second part is the low level driver of the gigE ethernet ports. + * The second part is the low level driver of the gigE ethernet ports. */ /* * Marvell's Gigabit Ethernet controller low level driver * * DESCRIPTION: - * This file introduce low level API to Marvell's Gigabit Ethernet + * This file introduce low level API to Marvell's Gigabit Ethernet * controller. This Gigabit Ethernet Controller driver API controls * 1) Operations (i.e. port init, start, reset etc'). * 2) Data flow (i.e. port send, receive etc'). * Each Gigabit Ethernet port is controlled via - * struct mv64340_private. + * struct mv643xx_private. * This struct includes user configuration information as well as * driver internal data needed for its operations. * - * Supported Features: + * Supported Features: * - This low level driver is OS independent. Allocating memory for * the descriptor rings and buffers are not within the scope of * this driver. @@ -1509,12 +1645,12 @@ * - PHY access and control API. * - Port control register configuration API. * - Full control over Unicast and Multicast MAC configurations. - * + * * Operation flow: * * Initialization phase - * This phase complete the initialization of the the mv64340_private - * struct. + * This phase complete the initialization of the the + * mv643xx_private struct. * User information regarding port configuration has to be set * prior to calling the port initialization routine. * @@ -1523,7 +1659,7 @@ * access to DRAM and internal SRAM memory spaces. * * Driver ring initialization - * Allocating memory for the descriptor rings and buffers is not + * Allocating memory for the descriptor rings and buffers is not * within the scope of this driver. Thus, the user is required to * allocate memory for the descriptors ring and buffers. Those * memory parameters are used by the Rx and Tx ring initialization @@ -1531,49 +1667,50 @@ * of a ring. * Note: Pay special attention to alignment issues when using * cached descriptors/buffers. In this phase the driver store - * information in the mv64340_private struct regarding each queue + * information in the mv643xx_private struct regarding each queue * ring. * - * Driver start + * Driver start * This phase prepares the Ethernet port for Rx and Tx activity. - * It uses the information stored in the mv64340_private struct to + * It uses the information stored in the mv643xx_private struct to * initialize the various port registers. * * Data flow: * All packet references to/from the driver are done using - * struct pkt_info. - * This struct is a unified struct used with Rx and Tx operations. + * struct pkt_info. + * This struct is a unified struct used with Rx and Tx operations. * This way the user is not required to be familiar with neither * Tx nor Rx descriptors structures. * The driver's descriptors rings are management by indexes. * Those indexes controls the ring resources and used to indicate * a SW resource error: - * 'current' - * This index points to the current available resource for use. For - * example in Rx process this index will point to the descriptor - * that will be passed to the user upon calling the receive routine. - * In Tx process, this index will point to the descriptor + * 'current' + * This index points to the current available resource for use. For + * example in Rx process this index will point to the descriptor + * that will be passed to the user upon calling the receive + * routine. In Tx process, this index will point to the descriptor * that will be assigned with the user packet info and transmitted. - * 'used' - * This index points to the descriptor that need to restore its + * 'used' + * This index points to the descriptor that need to restore its * resources. For example in Rx process, using the Rx buffer return * API will attach the buffer returned in packet info to the * descriptor pointed by 'used'. In Tx process, using the Tx * descriptor return will merely return the user packet info with - * the command status of the transmitted buffer pointed by the + * the command status of the transmitted buffer pointed by the * 'used' index. Nevertheless, it is essential to use this routine * to update the 'used' index. * 'first' - * This index supports Tx Scatter-Gather. It points to the first - * descriptor of a packet assembled of multiple buffers. For example - * when in middle of Such packet we have a Tx resource error the - * 'curr' index get the value of 'first' to indicate that the ring - * returned to its state before trying to transmit this packet. + * This index supports Tx Scatter-Gather. It points to the first + * descriptor of a packet assembled of multiple buffers. For + * example when in middle of Such packet we have a Tx resource + * error the 'curr' index get the value of 'first' to indicate + * that the ring returned to its state before trying to transmit + * this packet. * * Receive operation: * The eth_port_receive API set the packet information struct, - * passed by the caller, with received information from the - * 'current' SDMA descriptor. + * passed by the caller, with received information from the + * 'current' SDMA descriptor. * It is the user responsibility to return this resource back * to the Rx descriptor ring to enable the reuse of this source. * Return Rx resource is done using the eth_rx_return_buff API. @@ -1594,27 +1731,21 @@ * * EXTERNAL INTERFACE * - * Prior to calling the initialization routine eth_port_init() the user - * must set the following fields under mv64340_private struct: - * port_num User Ethernet port number. - * port_mac_addr[6] User defined port MAC address. - * port_config User port configuration value. - * port_config_extend User port config extend value. - * port_sdma_config User port SDMA config value. - * port_serial_control User port serial control value. - * - * This driver introduce a set of default values: - * PORT_CONFIG_VALUE Default port configuration value - * PORT_CONFIG_EXTEND_VALUE Default port extend configuration value - * PORT_SDMA_CONFIG_VALUE Default sdma control value - * PORT_SERIAL_CONTROL_VALUE Default port serial control value + * Prior to calling the initialization routine eth_port_init() the user + * must set the following fields under mv643xx_private struct: + * port_num User Ethernet port number. + * port_mac_addr[6] User defined port MAC address. + * port_config User port configuration value. + * port_config_extend User port config extend value. + * port_sdma_config User port SDMA config value. + * port_serial_control User port serial control value. * * This driver data flow is done using the struct pkt_info which - * is a unified struct for Rx and Tx operations: + * is a unified struct for Rx and Tx operations: * * byte_cnt Tx/Rx descriptor buffer byte count. * l4i_chk CPU provided TCP Checksum. For Tx operation - * only. + * only. * cmd_sts Tx/Rx descriptor command status. * buf_ptr Tx/Rx descriptor buffer pointer. * return_info Tx/Rx user resource return information. @@ -1623,70 +1754,44 @@ /* defines */ /* SDMA command macros */ #define ETH_ENABLE_TX_QUEUE(eth_port) \ - MV_WRITE(MV64340_ETH_TRANSMIT_QUEUE_COMMAND_REG(eth_port), 1) - -#define ETH_DISABLE_TX_QUEUE(eth_port) \ - MV_WRITE(MV64340_ETH_TRANSMIT_QUEUE_COMMAND_REG(eth_port), \ - (1 << 8)) - -#define ETH_ENABLE_RX_QUEUE(rx_queue, eth_port) \ - MV_WRITE(MV64340_ETH_RECEIVE_QUEUE_COMMAND_REG(eth_port), \ - (1 << rx_queue)) - -#define ETH_DISABLE_RX_QUEUE(rx_queue, eth_port) \ - MV_WRITE(MV64340_ETH_RECEIVE_QUEUE_COMMAND_REG(eth_port), \ - (1 << (8 + rx_queue))) - -#define LINK_UP_TIMEOUT 100000 -#define PHY_BUSY_TIMEOUT 10000000 + mv_write(MV643XX_ETH_TRANSMIT_QUEUE_COMMAND_REG(eth_port), 1) /* locals */ /* PHY routines */ static int ethernet_phy_get(unsigned int eth_port_num); +static void ethernet_phy_set(unsigned int eth_port_num, int phy_addr); /* Ethernet Port routines */ static int eth_port_uc_addr(unsigned int eth_port_num, unsigned char uc_nibble, - int option); + int option); /* * eth_port_init - Initialize the Ethernet port driver * * DESCRIPTION: - * This function prepares the ethernet port to start its activity: - * 1) Completes the ethernet port driver struct initialization toward port - * start routine. - * 2) Resets the device to a quiescent state in case of warm reboot. - * 3) Enable SDMA access to all four DRAM banks as well as internal SRAM. - * 4) Clean MAC tables. The reset status of those tables is unknown. - * 5) Set PHY address. - * Note: Call this routine prior to eth_port_start routine and after - * setting user values in the user fields of Ethernet port control - * struct. + * This function prepares the ethernet port to start its activity: + * 1) Completes the ethernet port driver struct initialization toward port + * start routine. + * 2) Resets the device to a quiescent state in case of warm reboot. + * 3) Enable SDMA access to all four DRAM banks as well as internal SRAM. + * 4) Clean MAC tables. The reset status of those tables is unknown. + * 5) Set PHY address. + * Note: Call this routine prior to eth_port_start routine and after + * setting user values in the user fields of Ethernet port control + * struct. * * INPUT: - * struct mv64340_private *mp Ethernet port control struct + * struct mv643xx_private *mp Ethernet port control struct * * OUTPUT: - * See description. + * See description. * * RETURN: - * None. + * None. */ -static void eth_port_init(struct mv64340_private * mp) +static void eth_port_init(struct mv643xx_private *mp) { - mp->port_config = PORT_CONFIG_VALUE; - mp->port_config_extend = PORT_CONFIG_EXTEND_VALUE; -#if defined(__BIG_ENDIAN) - mp->port_sdma_config = PORT_SDMA_CONFIG_VALUE; -#elif defined(__LITTLE_ENDIAN) - mp->port_sdma_config = PORT_SDMA_CONFIG_VALUE | - ETH_BLM_RX_NO_SWAP | ETH_BLM_TX_NO_SWAP; -#else -#error One of __LITTLE_ENDIAN or __BIG_ENDIAN must be defined! -#endif - mp->port_serial_control = PORT_SERIAL_CONTROL_VALUE; - mp->port_rx_queue_command = 0; mp->port_tx_queue_command = 0; @@ -1704,77 +1809,73 @@ * eth_port_start - Start the Ethernet port activity. * * DESCRIPTION: - * This routine prepares the Ethernet port for Rx and Tx activity: - * 1. Initialize Tx and Rx Current Descriptor Pointer for each queue that - * has been initialized a descriptor's ring (using - * ether_init_tx_desc_ring for Tx and ether_init_rx_desc_ring for Rx) - * 2. Initialize and enable the Ethernet configuration port by writing to - * the port's configuration and command registers. - * 3. Initialize and enable the SDMA by writing to the SDMA's - * configuration and command registers. After completing these steps, - * the ethernet port SDMA can starts to perform Rx and Tx activities. + * This routine prepares the Ethernet port for Rx and Tx activity: + * 1. Initialize Tx and Rx Current Descriptor Pointer for each queue that + * has been initialized a descriptor's ring (using + * ether_init_tx_desc_ring for Tx and ether_init_rx_desc_ring for Rx) + * 2. Initialize and enable the Ethernet configuration port by writing to + * the port's configuration and command registers. + * 3. Initialize and enable the SDMA by writing to the SDMA's + * configuration and command registers. After completing these steps, + * the ethernet port SDMA can starts to perform Rx and Tx activities. * - * Note: Each Rx and Tx queue descriptor's list must be initialized prior - * to calling this function (use ether_init_tx_desc_ring for Tx queues - * and ether_init_rx_desc_ring for Rx queues). + * Note: Each Rx and Tx queue descriptor's list must be initialized prior + * to calling this function (use ether_init_tx_desc_ring for Tx queues + * and ether_init_rx_desc_ring for Rx queues). * * INPUT: - * struct mv64340_private *mp Ethernet port control struct + * struct mv643xx_private *mp Ethernet port control struct * * OUTPUT: - * Ethernet port is ready to receive and transmit. + * Ethernet port is ready to receive and transmit. * * RETURN: - * false if the port PHY is not up. - * true otherwise. + * None. */ -static int eth_port_start(struct mv64340_private *mp) +static void eth_port_start(struct mv643xx_private *mp) { - unsigned int eth_port_num = mp->port_num; + unsigned int port_num = mp->port_num; int tx_curr_desc, rx_curr_desc; - unsigned int phy_reg_data; /* Assignment of Tx CTRP of given queue */ tx_curr_desc = mp->tx_curr_desc_q; - MV_WRITE(MV64340_ETH_TX_CURRENT_QUEUE_DESC_PTR_0(eth_port_num), - (struct eth_tx_desc *) mp->tx_desc_dma + tx_curr_desc); + mv_write(MV643XX_ETH_TX_CURRENT_QUEUE_DESC_PTR_0(port_num), + (u32)((struct eth_tx_desc *)mp->tx_desc_dma + tx_curr_desc)); /* Assignment of Rx CRDP of given queue */ rx_curr_desc = mp->rx_curr_desc_q; - MV_WRITE(MV64340_ETH_RX_CURRENT_QUEUE_DESC_PTR_0(eth_port_num), - (struct eth_rx_desc *) mp->rx_desc_dma + rx_curr_desc); + mv_write(MV643XX_ETH_RX_CURRENT_QUEUE_DESC_PTR_0(port_num), + (u32)((struct eth_rx_desc *)mp->rx_desc_dma + rx_curr_desc)); /* Add the assigned Ethernet address to the port's address table */ - eth_port_uc_addr_set(mp->port_num, mp->port_mac_addr); + eth_port_uc_addr_set(port_num, mp->port_mac_addr); /* Assign port configuration and command. */ - MV_WRITE(MV64340_ETH_PORT_CONFIG_REG(eth_port_num), - mp->port_config); + mv_write(MV643XX_ETH_PORT_CONFIG_REG(port_num), mp->port_config); - MV_WRITE(MV64340_ETH_PORT_CONFIG_EXTEND_REG(eth_port_num), - mp->port_config_extend); + mv_write(MV643XX_ETH_PORT_CONFIG_EXTEND_REG(port_num), + mp->port_config_extend); - MV_WRITE(MV64340_ETH_PORT_SERIAL_CONTROL_REG(eth_port_num), - mp->port_serial_control); - MV_SET_REG_BITS(MV64340_ETH_PORT_SERIAL_CONTROL_REG(eth_port_num), - ETH_SERIAL_PORT_ENABLE); + /* Increase the Rx side buffer size if supporting GigE */ + if (mp->port_serial_control & MV643XX_ETH_SET_GMII_SPEED_TO_1000) + mv_write(MV643XX_ETH_PORT_SERIAL_CONTROL_REG(port_num), + (mp->port_serial_control & 0xfff1ffff) | (0x5 << 17)); + else + mv_write(MV643XX_ETH_PORT_SERIAL_CONTROL_REG(port_num), + mp->port_serial_control); + + mv_write(MV643XX_ETH_PORT_SERIAL_CONTROL_REG(port_num), + mv_read(MV643XX_ETH_PORT_SERIAL_CONTROL_REG(port_num)) | + MV643XX_ETH_SERIAL_PORT_ENABLE); /* Assign port SDMA configuration */ - MV_WRITE(MV64340_ETH_SDMA_CONFIG_REG(eth_port_num), - mp->port_sdma_config); + mv_write(MV643XX_ETH_SDMA_CONFIG_REG(port_num), + mp->port_sdma_config); /* Enable port Rx. */ - MV_WRITE(MV64340_ETH_RECEIVE_QUEUE_COMMAND_REG(eth_port_num), - mp->port_rx_queue_command); - - /* Check if link is up */ - eth_port_read_smi_reg(eth_port_num, 1, &phy_reg_data); - - if (!(phy_reg_data & 0x20)) - return 0; - - return 1; + mv_write(MV643XX_ETH_RECEIVE_QUEUE_COMMAND_REG(port_num), + mp->port_rx_queue_command); } /* @@ -1784,29 +1885,29 @@ * This function Set the port Ethernet MAC address. * * INPUT: - * unsigned int eth_port_num Port number. - * char * p_addr Address to be set + * unsigned int eth_port_num Port number. + * char * p_addr Address to be set * * OUTPUT: - * Set MAC address low and high registers. also calls eth_port_uc_addr() - * To set the unicast table with the proper information. + * Set MAC address low and high registers. also calls eth_port_uc_addr() + * To set the unicast table with the proper information. * * RETURN: * N/A. * */ static void eth_port_uc_addr_set(unsigned int eth_port_num, - unsigned char *p_addr) + unsigned char *p_addr) { unsigned int mac_h; unsigned int mac_l; mac_l = (p_addr[4] << 8) | (p_addr[5]); - mac_h = (p_addr[0] << 24) | (p_addr[1] << 16) | - (p_addr[2] << 8) | (p_addr[3] << 0); + mac_h = (p_addr[0] << 24) | (p_addr[1] << 16) | (p_addr[2] << 8) | + (p_addr[3] << 0); - MV_WRITE(MV64340_ETH_MAC_ADDR_LOW(eth_port_num), mac_l); - MV_WRITE(MV64340_ETH_MAC_ADDR_HIGH(eth_port_num), mac_h); + mv_write(MV643XX_ETH_MAC_ADDR_LOW(eth_port_num), mac_l); + mv_write(MV643XX_ETH_MAC_ADDR_HIGH(eth_port_num), mac_h); /* Accept frames of this address */ eth_port_uc_addr(eth_port_num, p_addr[5], ACCEPT_MAC_ADDR); @@ -1815,29 +1916,64 @@ } /* + * eth_port_uc_addr_get - This function retrieves the port Unicast address + * (MAC address) from the ethernet hw registers. + * + * DESCRIPTION: + * This function retrieves the port Ethernet MAC address. + * + * INPUT: + * unsigned int eth_port_num Port number. + * char *MacAddr pointer where the MAC address is stored + * + * OUTPUT: + * Copy the MAC address to the location pointed to by MacAddr + * + * RETURN: + * N/A. + * + */ +static void eth_port_uc_addr_get(struct net_device *dev, unsigned char *p_addr) +{ + struct mv643xx_private *mp = netdev_priv(dev); + unsigned int mac_h; + unsigned int mac_l; + + mac_h = mv_read(MV643XX_ETH_MAC_ADDR_HIGH(mp->port_num)); + mac_l = mv_read(MV643XX_ETH_MAC_ADDR_LOW(mp->port_num)); + + p_addr[0] = (mac_h >> 24) & 0xff; + p_addr[1] = (mac_h >> 16) & 0xff; + p_addr[2] = (mac_h >> 8) & 0xff; + p_addr[3] = mac_h & 0xff; + p_addr[4] = (mac_l >> 8) & 0xff; + p_addr[5] = mac_l & 0xff; +} + +/* * eth_port_uc_addr - This function Set the port unicast address table * * DESCRIPTION: - * This function locates the proper entry in the Unicast table for the - * specified MAC nibble and sets its properties according to function + * This function locates the proper entry in the Unicast table for the + * specified MAC nibble and sets its properties according to function * parameters. * * INPUT: - * unsigned int eth_port_num Port number. - * unsigned char uc_nibble Unicast MAC Address last nibble. - * int option 0 = Add, 1 = remove address. + * unsigned int eth_port_num Port number. + * unsigned char uc_nibble Unicast MAC Address last nibble. + * int option 0 = Add, 1 = remove address. * * OUTPUT: * This function add/removes MAC addresses from the port unicast address - * table. + * table. * * RETURN: * true is output succeeded. * false if option parameter is invalid. * */ -static int eth_port_uc_addr(unsigned int eth_port_num, - unsigned char uc_nibble, int option) +static int eth_port_uc_addr(unsigned int eth_port_num, unsigned char uc_nibble, + int option) { unsigned int unicast_reg; unsigned int tbl_offset; @@ -1850,29 +1986,26 @@ switch (option) { case REJECT_MAC_ADDR: - /* Clear accepts frame bit at specified unicast DA table entry */ - unicast_reg = MV_READ((MV64340_ETH_DA_FILTER_UNICAST_TABLE_BASE - (eth_port_num) + tbl_offset)); + /* Clear accepts frame bit at given unicast DA table entry */ + unicast_reg = mv_read((MV643XX_ETH_DA_FILTER_UNICAST_TABLE_BASE + (eth_port_num) + tbl_offset)); unicast_reg &= (0x0E << (8 * reg_offset)); - MV_WRITE( - (MV64340_ETH_DA_FILTER_UNICAST_TABLE_BASE - (eth_port_num) + tbl_offset), unicast_reg); + mv_write((MV643XX_ETH_DA_FILTER_UNICAST_TABLE_BASE + (eth_port_num) + tbl_offset), unicast_reg); break; case ACCEPT_MAC_ADDR: /* Set accepts frame bit at unicast DA filter table entry */ unicast_reg = - MV_READ( - (MV64340_ETH_DA_FILTER_UNICAST_TABLE_BASE - (eth_port_num) + tbl_offset)); + mv_read((MV643XX_ETH_DA_FILTER_UNICAST_TABLE_BASE + (eth_port_num) + tbl_offset)); unicast_reg |= (0x01 << (8 * reg_offset)); - MV_WRITE( - (MV64340_ETH_DA_FILTER_UNICAST_TABLE_BASE - (eth_port_num) + tbl_offset), unicast_reg); + mv_write((MV643XX_ETH_DA_FILTER_UNICAST_TABLE_BASE + (eth_port_num) + tbl_offset), unicast_reg); break; @@ -1887,17 +2020,17 @@ * eth_port_init_mac_tables - Clear all entrance in the UC, SMC and OMC tables * * DESCRIPTION: - * Go through all the DA filter tables (Unicast, Special Multicast & - * Other Multicast) and set each entry to 0. + * Go through all the DA filter tables (Unicast, Special Multicast & + * Other Multicast) and set each entry to 0. * * INPUT: - * unsigned int eth_port_num Ethernet Port number. + * unsigned int eth_port_num Ethernet Port number. * * OUTPUT: - * Multicast and Unicast packets are rejected. + * Multicast and Unicast packets are rejected. * * RETURN: - * None. + * None. */ static void eth_port_init_mac_tables(unsigned int eth_port_num) { @@ -1905,18 +2038,16 @@ /* Clear DA filter unicast table (Ex_dFUT) */ for (table_index = 0; table_index <= 0xC; table_index += 4) - MV_WRITE( - (MV64340_ETH_DA_FILTER_UNICAST_TABLE_BASE - (eth_port_num) + table_index), 0); + mv_write((MV643XX_ETH_DA_FILTER_UNICAST_TABLE_BASE + (eth_port_num) + table_index), 0); for (table_index = 0; table_index <= 0xFC; table_index += 4) { /* Clear DA filter special multicast table (Ex_dFSMT) */ - MV_WRITE( - (MV64340_ETH_DA_FILTER_SPECIAL_MULTICAST_TABLE_BASE - (eth_port_num) + table_index), 0); + mv_write((MV643XX_ETH_DA_FILTER_SPECIAL_MULTICAST_TABLE_BASE + (eth_port_num) + table_index), 0); /* Clear DA filter other multicast table (Ex_dFOMT) */ - MV_WRITE((MV64340_ETH_DA_FILTER_OTHER_MULTICAST_TABLE_BASE - (eth_port_num) + table_index), 0); + mv_write((MV643XX_ETH_DA_FILTER_OTHER_MULTICAST_TABLE_BASE + (eth_port_num) + table_index), 0); } } @@ -1924,17 +2055,17 @@ * eth_clear_mib_counters - Clear all MIB counters * * DESCRIPTION: - * This function clears all MIB counters of a specific ethernet port. - * A read from the MIB counter will reset the counter. + * This function clears all MIB counters of a specific ethernet port. + * A read from the MIB counter will reset the counter. * * INPUT: - * unsigned int eth_port_num Ethernet Port number. + * unsigned int eth_port_num Ethernet Port number. * * OUTPUT: - * After reading all MIB counters, the counters resets. + * After reading all MIB counters, the counters resets. * * RETURN: - * MIB counter value. + * MIB counter value. * */ static void eth_clear_mib_counters(unsigned int eth_port_num) @@ -1942,72 +2073,155 @@ int i; /* Perform dummy reads from MIB counters */ - for (i = ETH_MIB_GOOD_OCTETS_RECEIVED_LOW; i < ETH_MIB_LATE_COLLISION; i += 4) - MV_READ(MV64340_ETH_MIB_COUNTERS_BASE(eth_port_num) + i); + for (i = ETH_MIB_GOOD_OCTETS_RECEIVED_LOW; i < ETH_MIB_LATE_COLLISION; + i += 4) + mv_read(MV643XX_ETH_MIB_COUNTERS_BASE(eth_port_num) + i); +} + +static inline u32 read_mib(struct mv643xx_private *mp, int offset) +{ + return mv_read(MV643XX_ETH_MIB_COUNTERS_BASE(mp->port_num) + offset); } +static void eth_update_mib_counters(struct mv643xx_private *mp) +{ + struct mv643xx_mib_counters *p = &mp->mib_counters; + int offset; + + p->good_octets_received += + read_mib(mp, ETH_MIB_GOOD_OCTETS_RECEIVED_LOW); + p->good_octets_received += + (u64)read_mib(mp, ETH_MIB_GOOD_OCTETS_RECEIVED_HIGH) << 32; + + for (offset = ETH_MIB_BAD_OCTETS_RECEIVED; + offset <= ETH_MIB_FRAMES_1024_TO_MAX_OCTETS; + offset += 4) + *(u32 *)((char *)p + offset) = read_mib(mp, offset); + + p->good_octets_sent += read_mib(mp, ETH_MIB_GOOD_OCTETS_SENT_LOW); + p->good_octets_sent += + (u64)read_mib(mp, ETH_MIB_GOOD_OCTETS_SENT_HIGH) << 32; + + for (offset = ETH_MIB_GOOD_FRAMES_SENT; + offset <= ETH_MIB_LATE_COLLISION; + offset += 4) + *(u32 *)((char *)p + offset) = read_mib(mp, offset); +} + +/* + * ethernet_phy_detect - Detect whether a phy is present + * + * DESCRIPTION: + * This function tests whether there is a PHY present on + * the specified port. + * + * INPUT: + * unsigned int eth_port_num Ethernet Port number. + * + * OUTPUT: + * None + * + * RETURN: + * 0 on success + * -ENODEV on failure + * + */ +static int ethernet_phy_detect(unsigned int port_num) +{ + unsigned int phy_reg_data0; + int auto_neg; + + eth_port_read_smi_reg(port_num, 0, &phy_reg_data0); + auto_neg = phy_reg_data0 & 0x1000; + phy_reg_data0 ^= 0x1000; /* invert auto_neg */ + eth_port_write_smi_reg(port_num, 0, phy_reg_data0); + + eth_port_read_smi_reg(port_num, 0, &phy_reg_data0); + if ((phy_reg_data0 & 0x1000) == auto_neg) + return -ENODEV; /* change didn't take */ + + phy_reg_data0 ^= 0x1000; + eth_port_write_smi_reg(port_num, 0, phy_reg_data0); + return 0; +} /* * ethernet_phy_get - Get the ethernet port PHY address. * * DESCRIPTION: - * This routine returns the given ethernet port PHY address. + * This routine returns the given ethernet port PHY address. * * INPUT: - * unsigned int eth_port_num Ethernet Port number. + * unsigned int eth_port_num Ethernet Port number. * * OUTPUT: - * None. + * None. * * RETURN: - * PHY address. + * PHY address. * */ static int ethernet_phy_get(unsigned int eth_port_num) { unsigned int reg_data; - reg_data = MV_READ(MV64340_ETH_PHY_ADDR_REG); + reg_data = mv_read(MV643XX_ETH_PHY_ADDR_REG); return ((reg_data >> (5 * eth_port_num)) & 0x1f); } /* + * ethernet_phy_set - Set the ethernet port PHY address. + * + * DESCRIPTION: + * This routine sets the given ethernet port PHY address. + * + * INPUT: + * unsigned int eth_port_num Ethernet Port number. + * int phy_addr PHY address. + * + * OUTPUT: + * None. + * + * RETURN: + * None. + * + */ +static void ethernet_phy_set(unsigned int eth_port_num, int phy_addr) +{ + u32 reg_data; + int addr_shift = 5 * eth_port_num; + + reg_data = mv_read(MV643XX_ETH_PHY_ADDR_REG); + reg_data &= ~(0x1f << addr_shift); + reg_data |= (phy_addr & 0x1f) << addr_shift; + mv_write(MV643XX_ETH_PHY_ADDR_REG, reg_data); +} + +/* * ethernet_phy_reset - Reset Ethernet port PHY. * * DESCRIPTION: - * This routine utilize the SMI interface to reset the ethernet port PHY. - * The routine waits until the link is up again or link up is timeout. + * This routine utilizes the SMI interface to reset the ethernet port PHY. * * INPUT: - * unsigned int eth_port_num Ethernet Port number. + * unsigned int eth_port_num Ethernet Port number. * * OUTPUT: - * The ethernet port PHY renew its link. + * The PHY is reset. * * RETURN: - * None. + * None. * */ -static int ethernet_phy_reset(unsigned int eth_port_num) +static void ethernet_phy_reset(unsigned int eth_port_num) { - unsigned int time_out = 50; unsigned int phy_reg_data; /* Reset the PHY */ eth_port_read_smi_reg(eth_port_num, 0, &phy_reg_data); phy_reg_data |= 0x8000; /* Set bit 15 to reset the PHY */ eth_port_write_smi_reg(eth_port_num, 0, phy_reg_data); - - /* Poll on the PHY LINK */ - do { - eth_port_read_smi_reg(eth_port_num, 1, &phy_reg_data); - - if (time_out-- == 0) - return 0; - } while (!(phy_reg_data & 0x20)); - - return 1; } /* @@ -2015,381 +2229,358 @@ * * DESCRIPTION: * This routine resets the chip by aborting any SDMA engine activity and - * clearing the MIB counters. The Receiver and the Transmit unit are in - * idle state after this command is performed and the port is disabled. + * clearing the MIB counters. The Receiver and the Transmit unit are in + * idle state after this command is performed and the port is disabled. * * INPUT: - * unsigned int eth_port_num Ethernet Port number. + * unsigned int eth_port_num Ethernet Port number. * * OUTPUT: - * Channel activity is halted. + * Channel activity is halted. * * RETURN: - * None. + * None. * */ -static void eth_port_reset(unsigned int eth_port_num) +static void eth_port_reset(unsigned int port_num) { unsigned int reg_data; /* Stop Tx port activity. Check port Tx activity. */ - reg_data = - MV_READ(MV64340_ETH_TRANSMIT_QUEUE_COMMAND_REG(eth_port_num)); + reg_data = mv_read(MV643XX_ETH_TRANSMIT_QUEUE_COMMAND_REG(port_num)); if (reg_data & 0xFF) { /* Issue stop command for active channels only */ - MV_WRITE(MV64340_ETH_TRANSMIT_QUEUE_COMMAND_REG - (eth_port_num), (reg_data << 8)); + mv_write(MV643XX_ETH_TRANSMIT_QUEUE_COMMAND_REG(port_num), + (reg_data << 8)); /* Wait for all Tx activity to terminate. */ - do { - /* Check port cause register that all Tx queues are stopped */ - reg_data = - MV_READ - (MV64340_ETH_TRANSMIT_QUEUE_COMMAND_REG - (eth_port_num)); - } - while (reg_data & 0xFF); + /* Check port cause register that all Tx queues are stopped */ + while (mv_read(MV643XX_ETH_TRANSMIT_QUEUE_COMMAND_REG(port_num)) + & 0xFF) + udelay(10); } /* Stop Rx port activity. Check port Rx activity. */ - reg_data = - MV_READ(MV64340_ETH_RECEIVE_QUEUE_COMMAND_REG - (eth_port_num)); + reg_data = mv_read(MV643XX_ETH_RECEIVE_QUEUE_COMMAND_REG(port_num)); if (reg_data & 0xFF) { /* Issue stop command for active channels only */ - MV_WRITE(MV64340_ETH_RECEIVE_QUEUE_COMMAND_REG - (eth_port_num), (reg_data << 8)); + mv_write(MV643XX_ETH_RECEIVE_QUEUE_COMMAND_REG(port_num), + (reg_data << 8)); /* Wait for all Rx activity to terminate. */ - do { - /* Check port cause register that all Rx queues are stopped */ - reg_data = - MV_READ - (MV64340_ETH_RECEIVE_QUEUE_COMMAND_REG - (eth_port_num)); - } - while (reg_data & 0xFF); + /* Check port cause register that all Rx queues are stopped */ + while (mv_read(MV643XX_ETH_RECEIVE_QUEUE_COMMAND_REG(port_num)) + & 0xFF) + udelay(10); } - /* Clear all MIB counters */ - eth_clear_mib_counters(eth_port_num); + eth_clear_mib_counters(port_num); /* Reset the Enable bit in the Configuration Register */ - reg_data = - MV_READ(MV64340_ETH_PORT_SERIAL_CONTROL_REG (eth_port_num)); - reg_data &= ~ETH_SERIAL_PORT_ENABLE; - MV_WRITE(MV64340_ETH_PORT_SERIAL_CONTROL_REG(eth_port_num), reg_data); - - return; + reg_data = mv_read(MV643XX_ETH_PORT_SERIAL_CONTROL_REG(port_num)); + reg_data &= ~MV643XX_ETH_SERIAL_PORT_ENABLE; + mv_write(MV643XX_ETH_PORT_SERIAL_CONTROL_REG(port_num), reg_data); } /* * ethernet_set_config_reg - Set specified bits in configuration register. * * DESCRIPTION: - * This function sets specified bits in the given ethernet - * configuration register. + * This function sets specified bits in the given ethernet + * configuration register. * * INPUT: - * unsigned int eth_port_num Ethernet Port number. - * unsigned int value 32 bit value. + * unsigned int eth_port_num Ethernet Port number. + * unsigned int value 32 bit value. * * OUTPUT: - * The set bits in the value parameter are set in the configuration - * register. + * The set bits in the value parameter are set in the configuration + * register. * * RETURN: - * None. + * None. * */ static void ethernet_set_config_reg(unsigned int eth_port_num, - unsigned int value) + unsigned int value) { unsigned int eth_config_reg; - eth_config_reg = - MV_READ(MV64340_ETH_PORT_CONFIG_REG(eth_port_num)); + eth_config_reg = mv_read(MV643XX_ETH_PORT_CONFIG_REG(eth_port_num)); eth_config_reg |= value; - MV_WRITE(MV64340_ETH_PORT_CONFIG_REG(eth_port_num), - eth_config_reg); + mv_write(MV643XX_ETH_PORT_CONFIG_REG(eth_port_num), eth_config_reg); +} + +static int eth_port_autoneg_supported(unsigned int eth_port_num) +{ + unsigned int phy_reg_data0; + + eth_port_read_smi_reg(eth_port_num, 0, &phy_reg_data0); + + return phy_reg_data0 & 0x1000; +} + +static int eth_port_link_is_up(unsigned int eth_port_num) +{ + unsigned int phy_reg_data1; + + eth_port_read_smi_reg(eth_port_num, 1, &phy_reg_data1); + + if (eth_port_autoneg_supported(eth_port_num)) { + if (phy_reg_data1 & 0x20) /* auto-neg complete */ + return 1; + } else if (phy_reg_data1 & 0x4) /* link up */ + return 1; + + return 0; } /* * ethernet_get_config_reg - Get the port configuration register * * DESCRIPTION: - * This function returns the configuration register value of the given - * ethernet port. + * This function returns the configuration register value of the given + * ethernet port. * * INPUT: - * unsigned int eth_port_num Ethernet Port number. + * unsigned int eth_port_num Ethernet Port number. * * OUTPUT: - * None. + * None. * * RETURN: - * Port configuration register value. + * Port configuration register value. */ static unsigned int ethernet_get_config_reg(unsigned int eth_port_num) { unsigned int eth_config_reg; - eth_config_reg = MV_READ(MV64340_ETH_PORT_CONFIG_EXTEND_REG - (eth_port_num)); + eth_config_reg = mv_read(MV643XX_ETH_PORT_CONFIG_EXTEND_REG + (eth_port_num)); return eth_config_reg; } - /* * eth_port_read_smi_reg - Read PHY registers * * DESCRIPTION: - * This routine utilize the SMI interface to interact with the PHY in - * order to perform PHY register read. + * This routine utilize the SMI interface to interact with the PHY in + * order to perform PHY register read. * * INPUT: - * unsigned int eth_port_num Ethernet Port number. - * unsigned int phy_reg PHY register address offset. - * unsigned int *value Register value buffer. + * unsigned int port_num Ethernet Port number. + * unsigned int phy_reg PHY register address offset. + * unsigned int *value Register value buffer. * * OUTPUT: - * Write the value of a specified PHY register into given buffer. + * Write the value of a specified PHY register into given buffer. * * RETURN: - * false if the PHY is busy or read data is not in valid state. - * true otherwise. + * false if the PHY is busy or read data is not in valid state. + * true otherwise. * */ -static int eth_port_read_smi_reg(unsigned int eth_port_num, - unsigned int phy_reg, unsigned int *value) +static void eth_port_read_smi_reg(unsigned int port_num, + unsigned int phy_reg, unsigned int *value) { - int phy_addr = ethernet_phy_get(eth_port_num); - unsigned int time_out = PHY_BUSY_TIMEOUT; - unsigned int reg_value; - - /* first check that it is not busy */ - do { - reg_value = MV_READ(MV64340_ETH_SMI_REG); - if (time_out-- == 0) - return 0; - } while (reg_value & ETH_SMI_BUSY); - - /* not busy */ - - MV_WRITE(MV64340_ETH_SMI_REG, - (phy_addr << 16) | (phy_reg << 21) | ETH_SMI_OPCODE_READ); - - time_out = PHY_BUSY_TIMEOUT; /* initialize the time out var again */ + int phy_addr = ethernet_phy_get(port_num); + unsigned long flags; + int i; - do { - reg_value = MV_READ(MV64340_ETH_SMI_REG); - if (time_out-- == 0) - return 0; - } while (reg_value & ETH_SMI_READ_VALID); + /* the SMI register is a shared resource */ + spin_lock_irqsave(&mv643xx_eth_phy_lock, flags); - /* Wait for the data to update in the SMI register */ - for (time_out = 0; time_out < PHY_BUSY_TIMEOUT; time_out++); + /* wait for the SMI register to become available */ + for (i = 0; mv_read(MV643XX_ETH_SMI_REG) & ETH_SMI_BUSY; i++) { + if (i == PHY_WAIT_ITERATIONS) { + printk("mv643xx PHY busy timeout, port %d\n", port_num); + goto out; + } + udelay(PHY_WAIT_MICRO_SECONDS); + } - reg_value = MV_READ(MV64340_ETH_SMI_REG); + mv_write(MV643XX_ETH_SMI_REG, + (phy_addr << 16) | (phy_reg << 21) | ETH_SMI_OPCODE_READ); - *value = reg_value & 0xffff; + /* now wait for the data to be valid */ + for (i = 0; !(mv_read(MV643XX_ETH_SMI_REG) & ETH_SMI_READ_VALID); i++) { + if (i == PHY_WAIT_ITERATIONS) { + printk("mv643xx PHY read timeout, port %d\n", port_num); + goto out; + } + udelay(PHY_WAIT_MICRO_SECONDS); + } - return 1; + *value = mv_read(MV643XX_ETH_SMI_REG) & 0xffff; +out: + spin_unlock_irqrestore(&mv643xx_eth_phy_lock, flags); } /* * eth_port_write_smi_reg - Write to PHY registers * * DESCRIPTION: - * This routine utilize the SMI interface to interact with the PHY in - * order to perform writes to PHY registers. + * This routine utilize the SMI interface to interact with the PHY in + * order to perform writes to PHY registers. * * INPUT: - * unsigned int eth_port_num Ethernet Port number. - * unsigned int phy_reg PHY register address offset. - * unsigned int value Register value. + * unsigned int eth_port_num Ethernet Port number. + * unsigned int phy_reg PHY register address offset. + * unsigned int value Register value. * * OUTPUT: - * Write the given value to the specified PHY register. + * Write the given value to the specified PHY register. * * RETURN: - * false if the PHY is busy. - * true otherwise. + * false if the PHY is busy. + * true otherwise. * */ -static int eth_port_write_smi_reg(unsigned int eth_port_num, - unsigned int phy_reg, unsigned int value) +static void eth_port_write_smi_reg(unsigned int eth_port_num, + unsigned int phy_reg, unsigned int value) { - unsigned int time_out = PHY_BUSY_TIMEOUT; - unsigned int reg_value; int phy_addr; + int i; + unsigned long flags; phy_addr = ethernet_phy_get(eth_port_num); - /* first check that it is not busy */ - do { - reg_value = MV_READ(MV64340_ETH_SMI_REG); - if (time_out-- == 0) - return 0; - } while (reg_value & ETH_SMI_BUSY); - - /* not busy */ - MV_WRITE(MV64340_ETH_SMI_REG, (phy_addr << 16) | (phy_reg << 21) | - ETH_SMI_OPCODE_WRITE | (value & 0xffff)); + /* the SMI register is a shared resource */ + spin_lock_irqsave(&mv643xx_eth_phy_lock, flags); - return 1; + /* wait for the SMI register to become available */ + for (i = 0; mv_read(MV643XX_ETH_SMI_REG) & ETH_SMI_BUSY; i++) { + if (i == PHY_WAIT_ITERATIONS) { + printk("mv643xx PHY busy timeout, port %d\n", + eth_port_num); + goto out; + } + udelay(PHY_WAIT_MICRO_SECONDS); + } + + mv_write(MV643XX_ETH_SMI_REG, (phy_addr << 16) | (phy_reg << 21) | + ETH_SMI_OPCODE_WRITE | (value & 0xffff)); +out: + spin_unlock_irqrestore(&mv643xx_eth_phy_lock, flags); } /* * eth_port_send - Send an Ethernet packet * * DESCRIPTION: - * This routine send a given packet described by p_pktinfo parameter. It - * supports transmitting of a packet spaned over multiple buffers. The - * routine updates 'curr' and 'first' indexes according to the packet - * segment passed to the routine. In case the packet segment is first, - * the 'first' index is update. In any case, the 'curr' index is updated. - * If the routine get into Tx resource error it assigns 'curr' index as - * 'first'. This way the function can abort Tx process of multiple - * descriptors per packet. + * This routine send a given packet described by p_pktinfo parameter. It + * supports transmitting of a packet spaned over multiple buffers. The + * routine updates 'curr' and 'first' indexes according to the packet + * segment passed to the routine. In case the packet segment is first, + * the 'first' index is update. In any case, the 'curr' index is updated. + * If the routine get into Tx resource error it assigns 'curr' index as + * 'first'. This way the function can abort Tx process of multiple + * descriptors per packet. * * INPUT: - * struct mv64340_private *mp Ethernet Port Control srtuct. - * struct pkt_info *p_pkt_info User packet buffer. + * struct mv643xx_private *mp Ethernet Port Control srtuct. + * struct pkt_info *p_pkt_info User packet buffer. * * OUTPUT: - * Tx ring 'curr' and 'first' indexes are updated. + * Tx ring 'curr' and 'first' indexes are updated. * * RETURN: - * ETH_QUEUE_FULL in case of Tx resource error. + * ETH_QUEUE_FULL in case of Tx resource error. * ETH_ERROR in case the routine can not access Tx desc ring. * ETH_QUEUE_LAST_RESOURCE if the routine uses the last Tx resource. - * ETH_OK otherwise. + * ETH_OK otherwise. * */ -#ifdef MV64340_CHECKSUM_OFFLOAD_TX +#ifdef MV643XX_CHECKSUM_OFFLOAD_TX /* * Modified to include the first descriptor pointer in case of SG */ -static ETH_FUNC_RET_STATUS eth_port_send(struct mv64340_private * mp, - struct pkt_info * p_pkt_info) +static ETH_FUNC_RET_STATUS eth_port_send(struct mv643xx_private *mp, + struct pkt_info *p_pkt_info) { int tx_desc_curr, tx_desc_used, tx_first_desc, tx_next_desc; - volatile struct eth_tx_desc *current_descriptor; - volatile struct eth_tx_desc *first_descriptor; - u32 command_status, first_chip_ptr; + struct eth_tx_desc *current_descriptor; + struct eth_tx_desc *first_descriptor; + u32 command; /* Do not process Tx ring in case of Tx ring resource error */ if (mp->tx_resource_err) return ETH_QUEUE_FULL; + /* + * The hardware requires that each buffer that is <= 8 bytes + * in length must be aligned on an 8 byte boundary. + */ + if (p_pkt_info->byte_cnt <= 8 && p_pkt_info->buf_ptr & 0x7) { + printk(KERN_ERR + "mv643xx_eth port %d: packet size <= 8 problem\n", + mp->port_num); + return ETH_ERROR; + } + /* Get the Tx Desc ring indexes */ tx_desc_curr = mp->tx_curr_desc_q; tx_desc_used = mp->tx_used_desc_q; current_descriptor = &mp->p_tx_desc_area[tx_desc_curr]; - if (current_descriptor == NULL) - return ETH_ERROR; - tx_next_desc = (tx_desc_curr + 1) % MV64340_TX_QUEUE_SIZE; - command_status = p_pkt_info->cmd_sts | ETH_ZERO_PADDING | ETH_GEN_CRC; + tx_next_desc = (tx_desc_curr + 1) % mp->tx_ring_size; + + current_descriptor->buf_ptr = p_pkt_info->buf_ptr; + current_descriptor->byte_cnt = p_pkt_info->byte_cnt; + current_descriptor->l4i_chk = p_pkt_info->l4i_chk; + mp->tx_skb[tx_desc_curr] = p_pkt_info->return_info; - if (command_status & ETH_TX_FIRST_DESC) { + command = p_pkt_info->cmd_sts | ETH_ZERO_PADDING | ETH_GEN_CRC | + ETH_BUFFER_OWNED_BY_DMA; + if (command & ETH_TX_FIRST_DESC) { tx_first_desc = tx_desc_curr; mp->tx_first_desc_q = tx_first_desc; + first_descriptor = current_descriptor; + mp->tx_first_command = command; + } else { + tx_first_desc = mp->tx_first_desc_q; + first_descriptor = &mp->p_tx_desc_area[tx_first_desc]; + BUG_ON(first_descriptor == NULL); + current_descriptor->cmd_sts = command; + } - /* fill first descriptor */ - first_descriptor = &mp->p_tx_desc_area[tx_desc_curr]; - first_descriptor->l4i_chk = p_pkt_info->l4i_chk; - first_descriptor->cmd_sts = command_status; - first_descriptor->byte_cnt = p_pkt_info->byte_cnt; - first_descriptor->buf_ptr = p_pkt_info->buf_ptr; - first_descriptor->next_desc_ptr = mp->tx_desc_dma + - tx_next_desc * sizeof(struct eth_tx_desc); + if (command & ETH_TX_LAST_DESC) { wmb(); - } else { - tx_first_desc = mp->tx_first_desc_q; - first_descriptor = &mp->p_tx_desc_area[tx_first_desc]; - if (first_descriptor == NULL) { - printk("First desc is NULL !!\n"); - return ETH_ERROR; - } - if (command_status & ETH_TX_LAST_DESC) - current_descriptor->next_desc_ptr = 0x00000000; - else { - command_status |= ETH_BUFFER_OWNED_BY_DMA; - current_descriptor->next_desc_ptr = mp->tx_desc_dma + - tx_next_desc * sizeof(struct eth_tx_desc); - } - } - - if (p_pkt_info->byte_cnt < 8) { - printk(" < 8 problem \n"); - return ETH_ERROR; - } - - current_descriptor->buf_ptr = p_pkt_info->buf_ptr; - current_descriptor->byte_cnt = p_pkt_info->byte_cnt; - current_descriptor->l4i_chk = p_pkt_info->l4i_chk; - current_descriptor->cmd_sts = command_status; - - mp->tx_skb[tx_desc_curr] = (struct sk_buff*) p_pkt_info->return_info; - - wmb(); - - /* Set last desc with DMA ownership and interrupt enable. */ - if (command_status & ETH_TX_LAST_DESC) { - current_descriptor->cmd_sts = command_status | - ETH_TX_ENABLE_INTERRUPT | - ETH_BUFFER_OWNED_BY_DMA; + first_descriptor->cmd_sts = mp->tx_first_command; - if (!(command_status & ETH_TX_FIRST_DESC)) - first_descriptor->cmd_sts |= ETH_BUFFER_OWNED_BY_DMA; wmb(); - - first_chip_ptr = MV_READ(MV64340_ETH_CURRENT_SERVED_TX_DESC_PTR(mp->port_num)); - - /* Apply send command */ - if (first_chip_ptr == 0x00000000) - MV_WRITE(MV64340_ETH_TX_CURRENT_QUEUE_DESC_PTR_0(mp->port_num), (struct eth_tx_desc *) mp->tx_desc_dma + tx_first_desc); - - ETH_ENABLE_TX_QUEUE(mp->port_num); + ETH_ENABLE_TX_QUEUE(mp->port_num); /* * Finish Tx packet. Update first desc in case of Tx resource * error */ - tx_first_desc = tx_next_desc; - mp->tx_first_desc_q = tx_first_desc; - } else { - if (! (command_status & ETH_TX_FIRST_DESC) ) { - current_descriptor->cmd_sts = command_status; - wmb(); - } + tx_first_desc = tx_next_desc; + mp->tx_first_desc_q = tx_first_desc; } - /* Check for ring index overlap in the Tx desc ring */ - if (tx_next_desc == tx_desc_used) { - mp->tx_resource_err = 1; - mp->tx_curr_desc_q = tx_first_desc; + /* Check for ring index overlap in the Tx desc ring */ + if (tx_next_desc == tx_desc_used) { + mp->tx_resource_err = 1; + mp->tx_curr_desc_q = tx_first_desc; - return ETH_QUEUE_LAST_RESOURCE; + return ETH_QUEUE_LAST_RESOURCE; } - mp->tx_curr_desc_q = tx_next_desc; - wmb(); + mp->tx_curr_desc_q = tx_next_desc; - return ETH_OK; + return ETH_OK; } #else -static ETH_FUNC_RET_STATUS eth_port_send(struct mv64340_private * mp, - struct pkt_info * p_pkt_info) +static ETH_FUNC_RET_STATUS eth_port_send(struct mv643xx_private *mp, + struct pkt_info *p_pkt_info) { int tx_desc_curr; int tx_desc_used; - volatile struct eth_tx_desc* current_descriptor; + struct eth_tx_desc *current_descriptor; unsigned int command_status; /* Do not process Tx ring in case of Tx ring resource error */ @@ -2401,39 +2592,24 @@ tx_desc_used = mp->tx_used_desc_q; current_descriptor = &mp->p_tx_desc_area[tx_desc_curr]; - if (current_descriptor == NULL) - return ETH_ERROR; - command_status = p_pkt_info->cmd_sts | ETH_ZERO_PADDING | ETH_GEN_CRC; - -/* XXX Is this for real ?!?!? */ - /* Buffers with a payload smaller than 8 bytes must be aligned to a - * 64-bit boundary. We use the memory allocated for Tx descriptor. - * This memory is located in TX_BUF_OFFSET_IN_DESC offset within the - * Tx descriptor. */ - if (p_pkt_info->byte_cnt <= 8) { - printk(KERN_ERR - "You have failed in the < 8 bytes errata - fixme\n"); - return ETH_ERROR; - } current_descriptor->buf_ptr = p_pkt_info->buf_ptr; current_descriptor->byte_cnt = p_pkt_info->byte_cnt; - mp->tx_skb[tx_desc_curr] = (struct sk_buff *) p_pkt_info->return_info; - - mb(); + mp->tx_skb[tx_desc_curr] = p_pkt_info->return_info; /* Set last desc with DMA ownership and interrupt enable. */ + wmb(); current_descriptor->cmd_sts = command_status | ETH_BUFFER_OWNED_BY_DMA | ETH_TX_ENABLE_INTERRUPT; - /* Apply send command */ + wmb(); ETH_ENABLE_TX_QUEUE(mp->port_num); /* Finish Tx packet. Update first desc in case of Tx resource error */ - tx_desc_curr = (tx_desc_curr + 1) % MV64340_TX_QUEUE_SIZE; + tx_desc_curr = (tx_desc_curr + 1) % mp->tx_ring_size; /* Update the current descriptor */ - mp->tx_curr_desc_q = tx_desc_curr; + mp->tx_curr_desc_q = tx_desc_curr; /* Check for ring index overlap in the Tx desc ring */ if (tx_desc_curr == tx_desc_used) { @@ -2450,62 +2626,55 @@ * * DESCRIPTION: * This routine returns the transmitted packet information to the caller. - * It uses the 'first' index to support Tx desc return in case a transmit - * of a packet spanned over multiple buffer still in process. - * In case the Tx queue was in "resource error" condition, where there are - * no available Tx resources, the function resets the resource error flag. + * It uses the 'first' index to support Tx desc return in case a transmit + * of a packet spanned over multiple buffer still in process. + * In case the Tx queue was in "resource error" condition, where there are + * no available Tx resources, the function resets the resource error flag. * * INPUT: - * struct mv64340_private *mp Ethernet Port Control srtuct. - * struct pkt_info *p_pkt_info User packet buffer. + * struct mv643xx_private *mp Ethernet Port Control srtuct. + * struct pkt_info *p_pkt_info User packet buffer. * * OUTPUT: - * Tx ring 'first' and 'used' indexes are updated. + * Tx ring 'first' and 'used' indexes are updated. * * RETURN: * ETH_ERROR in case the routine can not access Tx desc ring. - * ETH_RETRY in case there is transmission in process. + * ETH_RETRY in case there is transmission in process. * ETH_END_OF_JOB if the routine has nothing to release. - * ETH_OK otherwise. + * ETH_OK otherwise. * */ -static ETH_FUNC_RET_STATUS eth_tx_return_desc(struct mv64340_private * mp, - struct pkt_info * p_pkt_info) +static ETH_FUNC_RET_STATUS eth_tx_return_desc(struct mv643xx_private *mp, + struct pkt_info *p_pkt_info) { - int tx_desc_used, tx_desc_curr; -#ifdef MV64340_CHECKSUM_OFFLOAD_TX - int tx_first_desc; + int tx_desc_used; +#ifdef MV643XX_CHECKSUM_OFFLOAD_TX + int tx_busy_desc = mp->tx_first_desc_q; +#else + int tx_busy_desc = mp->tx_curr_desc_q; #endif - volatile struct eth_tx_desc *p_tx_desc_used; + struct eth_tx_desc *p_tx_desc_used; unsigned int command_status; /* Get the Tx Desc ring indexes */ - tx_desc_curr = mp->tx_curr_desc_q; tx_desc_used = mp->tx_used_desc_q; -#ifdef MV64340_CHECKSUM_OFFLOAD_TX - tx_first_desc = mp->tx_first_desc_q; -#endif + p_tx_desc_used = &mp->p_tx_desc_area[tx_desc_used]; - /* XXX Sanity check */ + /* Sanity check */ if (p_tx_desc_used == NULL) return ETH_ERROR; + /* Stop release. About to overlap the current available Tx descriptor */ + if (tx_desc_used == tx_busy_desc && !mp->tx_resource_err) + return ETH_END_OF_JOB; + command_status = p_tx_desc_used->cmd_sts; /* Still transmitting... */ -#ifndef MV64340_CHECKSUM_OFFLOAD_TX if (command_status & (ETH_BUFFER_OWNED_BY_DMA)) return ETH_RETRY; -#endif - /* Stop release. About to overlap the current available Tx descriptor */ -#ifdef MV64340_CHECKSUM_OFFLOAD_TX - if (tx_desc_used == tx_first_desc && !mp->tx_resource_err) - return ETH_END_OF_JOB; -#else - if (tx_desc_used == tx_desc_curr && !mp->tx_resource_err) - return ETH_END_OF_JOB; -#endif /* Pass the packet information to the caller */ p_pkt_info->cmd_sts = command_status; @@ -2513,7 +2682,7 @@ mp->tx_skb[tx_desc_used] = NULL; /* Update the next descriptor to release. */ - mp->tx_used_desc_q = (tx_desc_used + 1) % MV64340_TX_QUEUE_SIZE; + mp->tx_used_desc_q = (tx_desc_used + 1) % mp->tx_ring_size; /* Any Tx return cancels the Tx resource error status */ mp->tx_resource_err = 0; @@ -2525,30 +2694,30 @@ * eth_port_receive - Get received information from Rx ring. * * DESCRIPTION: - * This routine returns the received data to the caller. There is no - * data copying during routine operation. All information is returned - * using pointer to packet information struct passed from the caller. - * If the routine exhausts Rx ring resources then the resource error flag - * is set. + * This routine returns the received data to the caller. There is no + * data copying during routine operation. All information is returned + * using pointer to packet information struct passed from the caller. + * If the routine exhausts Rx ring resources then the resource error flag + * is set. * * INPUT: - * struct mv64340_private *mp Ethernet Port Control srtuct. - * struct pkt_info *p_pkt_info User packet buffer. + * struct mv643xx_private *mp Ethernet Port Control srtuct. + * struct pkt_info *p_pkt_info User packet buffer. * * OUTPUT: - * Rx ring current and used indexes are updated. + * Rx ring current and used indexes are updated. * * RETURN: * ETH_ERROR in case the routine can not access Rx desc ring. * ETH_QUEUE_FULL if Rx ring resources are exhausted. * ETH_END_OF_JOB if there is no received data. - * ETH_OK otherwise. + * ETH_OK otherwise. */ -static ETH_FUNC_RET_STATUS eth_port_receive(struct mv64340_private * mp, - struct pkt_info * p_pkt_info) +static ETH_FUNC_RET_STATUS eth_port_receive(struct mv643xx_private *mp, + struct pkt_info *p_pkt_info) { int rx_next_curr_desc, rx_curr_desc, rx_used_desc; - volatile struct eth_rx_desc * p_rx_desc; + volatile struct eth_rx_desc *p_rx_desc; unsigned int command_status; /* Do not process Rx ring in case of Rx ring resource error */ @@ -2563,6 +2732,7 @@ /* The following parameters are used to save readings from memory */ command_status = p_rx_desc->cmd_sts; + rmb(); /* Nothing to receive... */ if (command_status & (ETH_BUFFER_OWNED_BY_DMA)) @@ -2575,18 +2745,17 @@ p_pkt_info->l4i_chk = p_rx_desc->buf_size; /* Clean the return info field to indicate that the packet has been */ - /* moved to the upper layers */ + /* moved to the upper layers */ mp->rx_skb[rx_curr_desc] = NULL; /* Update current index in data structure */ - rx_next_curr_desc = (rx_curr_desc + 1) % MV64340_RX_QUEUE_SIZE; + rx_next_curr_desc = (rx_curr_desc + 1) % mp->rx_ring_size; mp->rx_curr_desc_q = rx_next_curr_desc; /* Rx descriptors exhausted. Set the Rx ring resource error flag */ if (rx_next_curr_desc == rx_used_desc) mp->rx_resource_err = 1; - mb(); return ETH_OK; } @@ -2594,27 +2763,27 @@ * eth_rx_return_buff - Returns a Rx buffer back to the Rx ring. * * DESCRIPTION: - * This routine returns a Rx buffer back to the Rx ring. It retrieves the - * next 'used' descriptor and attached the returned buffer to it. - * In case the Rx ring was in "resource error" condition, where there are - * no available Rx resources, the function resets the resource error flag. + * This routine returns a Rx buffer back to the Rx ring. It retrieves the + * next 'used' descriptor and attached the returned buffer to it. + * In case the Rx ring was in "resource error" condition, where there are + * no available Rx resources, the function resets the resource error flag. * * INPUT: - * struct mv64340_private *mp Ethernet Port Control srtuct. - * struct pkt_info *p_pkt_info Information on the returned buffer. + * struct mv643xx_private *mp Ethernet Port Control srtuct. + * struct pkt_info *p_pkt_info Information on returned buffer. * * OUTPUT: * New available Rx resource in Rx descriptor ring. * * RETURN: * ETH_ERROR in case the routine can not access Rx desc ring. - * ETH_OK otherwise. + * ETH_OK otherwise. */ -static ETH_FUNC_RET_STATUS eth_rx_return_buff(struct mv64340_private * mp, - struct pkt_info * p_pkt_info) +static ETH_FUNC_RET_STATUS eth_rx_return_buff(struct mv643xx_private *mp, + struct pkt_info *p_pkt_info) { int used_rx_desc; /* Where to return Rx resource */ - volatile struct eth_rx_desc* p_used_rx_desc; + volatile struct eth_rx_desc *p_used_rx_desc; /* Get 'used' Rx descriptor */ used_rx_desc = mp->rx_used_desc_q; @@ -2625,20 +2794,240 @@ mp->rx_skb[used_rx_desc] = p_pkt_info->return_info; /* Flush the write pipe */ - mb(); /* Return the descriptor to DMA ownership */ + wmb(); p_used_rx_desc->cmd_sts = - ETH_BUFFER_OWNED_BY_DMA | ETH_RX_ENABLE_INTERRUPT; - - /* Flush descriptor and CPU pipe */ - mb(); + ETH_BUFFER_OWNED_BY_DMA | ETH_RX_ENABLE_INTERRUPT; + wmb(); /* Move the used descriptor pointer to the next descriptor */ - mp->rx_used_desc_q = (used_rx_desc + 1) % MV64340_RX_QUEUE_SIZE; + mp->rx_used_desc_q = (used_rx_desc + 1) % mp->rx_ring_size; /* Any Rx return cancels the Rx resource error status */ mp->rx_resource_err = 0; return ETH_OK; } + +/************* Begin ethtool support *************************/ + +struct mv643xx_stats { + char stat_string[ETH_GSTRING_LEN]; + int sizeof_stat; + int stat_offset; +}; + +#define MV643XX_STAT(m) sizeof(((struct mv643xx_private *)0)->m), \ + offsetof(struct mv643xx_private, m) + +static const struct mv643xx_stats mv643xx_gstrings_stats[] = { + { "rx_packets", MV643XX_STAT(stats.rx_packets) }, + { "tx_packets", MV643XX_STAT(stats.tx_packets) }, + { "rx_bytes", MV643XX_STAT(stats.rx_bytes) }, + { "tx_bytes", MV643XX_STAT(stats.tx_bytes) }, + { "rx_errors", MV643XX_STAT(stats.rx_errors) }, + { "tx_errors", MV643XX_STAT(stats.tx_errors) }, + { "rx_dropped", MV643XX_STAT(stats.rx_dropped) }, + { "tx_dropped", MV643XX_STAT(stats.tx_dropped) }, + { "good_octets_received", MV643XX_STAT(mib_counters.good_octets_received) }, + { "bad_octets_received", MV643XX_STAT(mib_counters.bad_octets_received) }, + { "internal_mac_transmit_err", MV643XX_STAT(mib_counters.internal_mac_transmit_err) }, + { "good_frames_received", MV643XX_STAT(mib_counters.good_frames_received) }, + { "bad_frames_received", MV643XX_STAT(mib_counters.bad_frames_received) }, + { "broadcast_frames_received", MV643XX_STAT(mib_counters.broadcast_frames_received) }, + { "multicast_frames_received", MV643XX_STAT(mib_counters.multicast_frames_received) }, + { "frames_64_octets", MV643XX_STAT(mib_counters.frames_64_octets) }, + { "frames_65_to_127_octets", MV643XX_STAT(mib_counters.frames_65_to_127_octets) }, + { "frames_128_to_255_octets", MV643XX_STAT(mib_counters.frames_128_to_255_octets) }, + { "frames_256_to_511_octets", MV643XX_STAT(mib_counters.frames_256_to_511_octets) }, + { "frames_512_to_1023_octets", MV643XX_STAT(mib_counters.frames_512_to_1023_octets) }, + { "frames_1024_to_max_octets", MV643XX_STAT(mib_counters.frames_1024_to_max_octets) }, + { "good_octets_sent", MV643XX_STAT(mib_counters.good_octets_sent) }, + { "good_frames_sent", MV643XX_STAT(mib_counters.good_frames_sent) }, + { "excessive_collision", MV643XX_STAT(mib_counters.excessive_collision) }, + { "multicast_frames_sent", MV643XX_STAT(mib_counters.multicast_frames_sent) }, + { "broadcast_frames_sent", MV643XX_STAT(mib_counters.broadcast_frames_sent) }, + { "unrec_mac_control_received", MV643XX_STAT(mib_counters.unrec_mac_control_received) }, + { "fc_sent", MV643XX_STAT(mib_counters.fc_sent) }, + { "good_fc_received", MV643XX_STAT(mib_counters.good_fc_received) }, + { "bad_fc_received", MV643XX_STAT(mib_counters.bad_fc_received) }, + { "undersize_received", MV643XX_STAT(mib_counters.undersize_received) }, + { "fragments_received", MV643XX_STAT(mib_counters.fragments_received) }, + { "oversize_received", MV643XX_STAT(mib_counters.oversize_received) }, + { "jabber_received", MV643XX_STAT(mib_counters.jabber_received) }, + { "mac_receive_error", MV643XX_STAT(mib_counters.mac_receive_error) }, + { "bad_crc_event", MV643XX_STAT(mib_counters.bad_crc_event) }, + { "collision", MV643XX_STAT(mib_counters.collision) }, + { "late_collision", MV643XX_STAT(mib_counters.late_collision) }, +}; + +#define MV643XX_STATS_LEN \ + sizeof(mv643xx_gstrings_stats) / sizeof(struct mv643xx_stats) + +static int +mv643xx_get_settings(struct net_device *netdev, struct ethtool_cmd *ecmd) +{ + struct mv643xx_private *mp = netdev->priv; + int port_num = mp->port_num; + int autoneg = eth_port_autoneg_supported(port_num); + int mode_10_bit; + int auto_duplex; + int half_duplex = 0; + int full_duplex = 0; + int auto_speed; + int speed_10 = 0; + int speed_100 = 0; + int speed_1000 = 0; + + u32 pcs = mv_read(MV643XX_ETH_PORT_SERIAL_CONTROL_REG(port_num)); + u32 psr = mv_read(MV643XX_ETH_PORT_STATUS_REG(port_num)); + + mode_10_bit = psr & MV643XX_ETH_PORT_STATUS_MODE_10_BIT; + + if (mode_10_bit) { + ecmd->supported = SUPPORTED_10baseT_Half; + } else { + ecmd->supported = (SUPPORTED_10baseT_Half | + SUPPORTED_10baseT_Full | + SUPPORTED_100baseT_Half | + SUPPORTED_100baseT_Full | + SUPPORTED_1000baseT_Full | + (autoneg ? SUPPORTED_Autoneg : 0) | + SUPPORTED_TP); + + auto_duplex = !(pcs & MV643XX_ETH_DISABLE_AUTO_NEG_FOR_DUPLX); + auto_speed = !(pcs & MV643XX_ETH_DISABLE_AUTO_NEG_SPEED_GMII); + + ecmd->advertising = ADVERTISED_TP; + + if (autoneg) { + ecmd->advertising |= ADVERTISED_Autoneg; + + if (auto_duplex) { + half_duplex = 1; + full_duplex = 1; + } else { + if (pcs & MV643XX_ETH_SET_FULL_DUPLEX_MODE) + full_duplex = 1; + else + half_duplex = 1; + } + + if (auto_speed) { + speed_10 = 1; + speed_100 = 1; + speed_1000 = 1; + } else { + if (pcs & MV643XX_ETH_SET_GMII_SPEED_TO_1000) + speed_1000 = 1; + else if (pcs & MV643XX_ETH_SET_MII_SPEED_TO_100) + speed_100 = 1; + else + speed_10 = 1; + } + + if (speed_10 & half_duplex) + ecmd->advertising |= ADVERTISED_10baseT_Half; + if (speed_10 & full_duplex) + ecmd->advertising |= ADVERTISED_10baseT_Full; + if (speed_100 & half_duplex) + ecmd->advertising |= ADVERTISED_100baseT_Half; + if (speed_100 & full_duplex) + ecmd->advertising |= ADVERTISED_100baseT_Full; + if (speed_1000) + ecmd->advertising |= ADVERTISED_1000baseT_Full; + } + } + + ecmd->port = PORT_TP; + ecmd->phy_address = ethernet_phy_get(port_num); + + ecmd->transceiver = XCVR_EXTERNAL; + + if (netif_carrier_ok(netdev)) { + if (mode_10_bit) + ecmd->speed = SPEED_10; + else { + if (psr & MV643XX_ETH_PORT_STATUS_GMII_1000) + ecmd->speed = SPEED_1000; + else if (psr & MV643XX_ETH_PORT_STATUS_MII_100) + ecmd->speed = SPEED_100; + else + ecmd->speed = SPEED_10; + } + + if (psr & MV643XX_ETH_PORT_STATUS_FULL_DUPLEX) + ecmd->duplex = DUPLEX_FULL; + else + ecmd->duplex = DUPLEX_HALF; + } else { + ecmd->speed = -1; + ecmd->duplex = -1; + } + + ecmd->autoneg = autoneg ? AUTONEG_ENABLE : AUTONEG_DISABLE; + return 0; +} + +static void +mv643xx_get_drvinfo(struct net_device *netdev, + struct ethtool_drvinfo *drvinfo) +{ + strncpy(drvinfo->driver, mv643xx_driver_name, 32); + strncpy(drvinfo->version, mv643xx_driver_version, 32); + strncpy(drvinfo->fw_version, "N/A", 32); + strncpy(drvinfo->bus_info, "mv643xx", 32); + drvinfo->n_stats = MV643XX_STATS_LEN; +} + +static int +mv643xx_get_stats_count(struct net_device *netdev) +{ + return MV643XX_STATS_LEN; +} + +static void +mv643xx_get_ethtool_stats(struct net_device *netdev, + struct ethtool_stats *stats, uint64_t *data) +{ + struct mv643xx_private *mp = netdev->priv; + int i; + + eth_update_mib_counters(mp); + + for(i = 0; i < MV643XX_STATS_LEN; i++) { + char *p = (char *)mp+mv643xx_gstrings_stats[i].stat_offset; + data[i] = (mv643xx_gstrings_stats[i].sizeof_stat == + sizeof(uint64_t)) ? *(uint64_t *)p : *(uint32_t *)p; + } +} + +static void +mv643xx_get_strings(struct net_device *netdev, uint32_t stringset, uint8_t *data) +{ + int i; + + switch(stringset) { + case ETH_SS_STATS: + for (i=0; i < MV643XX_STATS_LEN; i++) { + memcpy(data + i * ETH_GSTRING_LEN, + mv643xx_gstrings_stats[i].stat_string, + ETH_GSTRING_LEN); + } + break; + } +} + +static struct ethtool_ops mv643xx_ethtool_ops = { + .get_settings = mv643xx_get_settings, + .get_drvinfo = mv643xx_get_drvinfo, + .get_link = ethtool_op_get_link, + .get_sg = ethtool_op_get_sg, + .set_sg = ethtool_op_set_sg, + .get_strings = mv643xx_get_strings, + .get_stats_count = mv643xx_get_stats_count, + .get_ethtool_stats = mv643xx_get_ethtool_stats, +}; + +/************* End ethtool support *************************/ diff -Nru a/drivers/net/mv643xx_eth.h b/drivers/net/mv643xx_eth.h --- a/drivers/net/mv643xx_eth.h 2005-03-08 14:29:45 -05:00 +++ b/drivers/net/mv643xx_eth.h 2005-03-08 14:29:45 -05:00 @@ -1,5 +1,5 @@ -#ifndef __MV64340_ETH_H__ -#define __MV64340_ETH_H__ +#ifndef __MV643XX_ETH_H__ +#define __MV643XX_ETH_H__ #include #include @@ -46,17 +46,16 @@ * The first part is the high level driver of the gigE ethernet ports. */ -#define ETH_PORT0_IRQ_NUM 48 /* main high register, bit0 */ -#define ETH_PORT1_IRQ_NUM ETH_PORT0_IRQ_NUM+1 /* main high register, bit1 */ -#define ETH_PORT2_IRQ_NUM ETH_PORT0_IRQ_NUM+2 /* main high register, bit1 */ - -/* Checksum offload for Tx works */ -#define MV64340_CHECKSUM_OFFLOAD_TX -#define MV64340_NAPI -#define MV64340_TX_FAST_REFILL -#undef MV64340_COAL +/* Checksum offload for Tx works for most packets, but + * fails if previous packet sent did not use hw csum + */ +#undef MV643XX_CHECKSUM_OFFLOAD_TX +#define MV643XX_NAPI +#define MV643XX_TX_FAST_REFILL +#undef MV643XX_RX_QUEUE_FILL_ON_TASK /* Does not work, yet */ +#undef MV643XX_COAL -/* +/* * Number of RX / TX descriptors on RX / TX rings. * Note that allocating RX descriptors is done by allocating the RX * ring AND a preallocated RX buffers (skb's) for each descriptor. @@ -65,89 +64,35 @@ */ /* Default TX ring size is 1000 descriptors */ -#define MV64340_TX_QUEUE_SIZE 1000 +#define MV643XX_DEFAULT_TX_QUEUE_SIZE 1000 /* Default RX ring size is 400 descriptors */ -#define MV64340_RX_QUEUE_SIZE 400 +#define MV643XX_DEFAULT_RX_QUEUE_SIZE 400 -#define MV64340_TX_COAL 100 -#ifdef MV64340_COAL -#define MV64340_RX_COAL 100 +#define MV643XX_TX_COAL 100 +#ifdef MV643XX_COAL +#define MV643XX_RX_COAL 100 #endif - /* - * The second part is the low level driver of the gigE ethernet ports. * + * The second part is the low level driver of the gigE ethernet ports. */ - /* - * Header File for : MV-643xx network interface header + * Header File for : MV-643xx network interface header * * DESCRIPTION: - * This header file contains macros typedefs and function declaration for - * the Marvell Gig Bit Ethernet Controller. + * This header file contains macros typedefs and function declaration for + * the Marvell Gig Bit Ethernet Controller. * * DEPENDENCIES: - * None. + * None. * */ -/* Default port configuration value */ -#define PORT_CONFIG_VALUE \ - ETH_UNICAST_NORMAL_MODE | \ - ETH_DEFAULT_RX_QUEUE_0 | \ - ETH_DEFAULT_RX_ARP_QUEUE_0 | \ - ETH_RECEIVE_BC_IF_NOT_IP_OR_ARP | \ - ETH_RECEIVE_BC_IF_IP | \ - ETH_RECEIVE_BC_IF_ARP | \ - ETH_CAPTURE_TCP_FRAMES_DIS | \ - ETH_CAPTURE_UDP_FRAMES_DIS | \ - ETH_DEFAULT_RX_TCP_QUEUE_0 | \ - ETH_DEFAULT_RX_UDP_QUEUE_0 | \ - ETH_DEFAULT_RX_BPDU_QUEUE_0 - -/* Default port extend configuration value */ -#define PORT_CONFIG_EXTEND_VALUE \ - ETH_SPAN_BPDU_PACKETS_AS_NORMAL | \ - ETH_PARTITION_DISABLE - - -/* Default sdma control value */ -#define PORT_SDMA_CONFIG_VALUE \ - ETH_RX_BURST_SIZE_16_64BIT | \ - GT_ETH_IPG_INT_RX(0) | \ - ETH_TX_BURST_SIZE_16_64BIT; - -#define GT_ETH_IPG_INT_RX(value) \ - ((value & 0x3fff) << 8) - -/* Default port serial control value */ -#define PORT_SERIAL_CONTROL_VALUE \ - ETH_FORCE_LINK_PASS | \ - ETH_ENABLE_AUTO_NEG_FOR_DUPLX | \ - ETH_DISABLE_AUTO_NEG_FOR_FLOW_CTRL | \ - ETH_ADV_SYMMETRIC_FLOW_CTRL | \ - ETH_FORCE_FC_MODE_NO_PAUSE_DIS_TX | \ - ETH_FORCE_BP_MODE_NO_JAM | \ - BIT9 | \ - ETH_DO_NOT_FORCE_LINK_FAIL | \ - ETH_RETRANSMIT_16_ATTEMPTS | \ - ETH_ENABLE_AUTO_NEG_SPEED_GMII | \ - ETH_DTE_ADV_0 | \ - ETH_DISABLE_AUTO_NEG_BYPASS | \ - ETH_AUTO_NEG_NO_CHANGE | \ - ETH_MAX_RX_PACKET_9700BYTE | \ - ETH_CLR_EXT_LOOPBACK | \ - ETH_SET_FULL_DUPLEX_MODE | \ - ETH_ENABLE_FLOW_CTRL_TX_RX_IN_FULL_DUPLEX - -#define RX_BUFFER_MAX_SIZE 0x4000000 -#define TX_BUFFER_MAX_SIZE 0x4000000 - /* MAC accepet/reject macros */ -#define ACCEPT_MAC_ADDR 0 -#define REJECT_MAC_ADDR 1 +#define ACCEPT_MAC_ADDR 0 +#define REJECT_MAC_ADDR 1 /* Buffer offset from buffer pointer */ #define RX_BUF_OFFSET 0x2 @@ -155,277 +100,132 @@ /* Gigabit Ethernet Unit Global Registers */ /* MIB Counters register definitions */ -#define ETH_MIB_GOOD_OCTETS_RECEIVED_LOW 0x0 -#define ETH_MIB_GOOD_OCTETS_RECEIVED_HIGH 0x4 -#define ETH_MIB_BAD_OCTETS_RECEIVED 0x8 -#define ETH_MIB_INTERNAL_MAC_TRANSMIT_ERR 0xc -#define ETH_MIB_GOOD_FRAMES_RECEIVED 0x10 -#define ETH_MIB_BAD_FRAMES_RECEIVED 0x14 -#define ETH_MIB_BROADCAST_FRAMES_RECEIVED 0x18 -#define ETH_MIB_MULTICAST_FRAMES_RECEIVED 0x1c -#define ETH_MIB_FRAMES_64_OCTETS 0x20 -#define ETH_MIB_FRAMES_65_TO_127_OCTETS 0x24 -#define ETH_MIB_FRAMES_128_TO_255_OCTETS 0x28 -#define ETH_MIB_FRAMES_256_TO_511_OCTETS 0x2c -#define ETH_MIB_FRAMES_512_TO_1023_OCTETS 0x30 -#define ETH_MIB_FRAMES_1024_TO_MAX_OCTETS 0x34 -#define ETH_MIB_GOOD_OCTETS_SENT_LOW 0x38 -#define ETH_MIB_GOOD_OCTETS_SENT_HIGH 0x3c -#define ETH_MIB_GOOD_FRAMES_SENT 0x40 -#define ETH_MIB_EXCESSIVE_COLLISION 0x44 -#define ETH_MIB_MULTICAST_FRAMES_SENT 0x48 -#define ETH_MIB_BROADCAST_FRAMES_SENT 0x4c -#define ETH_MIB_UNREC_MAC_CONTROL_RECEIVED 0x50 -#define ETH_MIB_FC_SENT 0x54 -#define ETH_MIB_GOOD_FC_RECEIVED 0x58 -#define ETH_MIB_BAD_FC_RECEIVED 0x5c -#define ETH_MIB_UNDERSIZE_RECEIVED 0x60 -#define ETH_MIB_FRAGMENTS_RECEIVED 0x64 -#define ETH_MIB_OVERSIZE_RECEIVED 0x68 -#define ETH_MIB_JABBER_RECEIVED 0x6c -#define ETH_MIB_MAC_RECEIVE_ERROR 0x70 -#define ETH_MIB_BAD_CRC_EVENT 0x74 -#define ETH_MIB_COLLISION 0x78 -#define ETH_MIB_LATE_COLLISION 0x7c +#define ETH_MIB_GOOD_OCTETS_RECEIVED_LOW 0x0 +#define ETH_MIB_GOOD_OCTETS_RECEIVED_HIGH 0x4 +#define ETH_MIB_BAD_OCTETS_RECEIVED 0x8 +#define ETH_MIB_INTERNAL_MAC_TRANSMIT_ERR 0xc +#define ETH_MIB_GOOD_FRAMES_RECEIVED 0x10 +#define ETH_MIB_BAD_FRAMES_RECEIVED 0x14 +#define ETH_MIB_BROADCAST_FRAMES_RECEIVED 0x18 +#define ETH_MIB_MULTICAST_FRAMES_RECEIVED 0x1c +#define ETH_MIB_FRAMES_64_OCTETS 0x20 +#define ETH_MIB_FRAMES_65_TO_127_OCTETS 0x24 +#define ETH_MIB_FRAMES_128_TO_255_OCTETS 0x28 +#define ETH_MIB_FRAMES_256_TO_511_OCTETS 0x2c +#define ETH_MIB_FRAMES_512_TO_1023_OCTETS 0x30 +#define ETH_MIB_FRAMES_1024_TO_MAX_OCTETS 0x34 +#define ETH_MIB_GOOD_OCTETS_SENT_LOW 0x38 +#define ETH_MIB_GOOD_OCTETS_SENT_HIGH 0x3c +#define ETH_MIB_GOOD_FRAMES_SENT 0x40 +#define ETH_MIB_EXCESSIVE_COLLISION 0x44 +#define ETH_MIB_MULTICAST_FRAMES_SENT 0x48 +#define ETH_MIB_BROADCAST_FRAMES_SENT 0x4c +#define ETH_MIB_UNREC_MAC_CONTROL_RECEIVED 0x50 +#define ETH_MIB_FC_SENT 0x54 +#define ETH_MIB_GOOD_FC_RECEIVED 0x58 +#define ETH_MIB_BAD_FC_RECEIVED 0x5c +#define ETH_MIB_UNDERSIZE_RECEIVED 0x60 +#define ETH_MIB_FRAGMENTS_RECEIVED 0x64 +#define ETH_MIB_OVERSIZE_RECEIVED 0x68 +#define ETH_MIB_JABBER_RECEIVED 0x6c +#define ETH_MIB_MAC_RECEIVE_ERROR 0x70 +#define ETH_MIB_BAD_CRC_EVENT 0x74 +#define ETH_MIB_COLLISION 0x78 +#define ETH_MIB_LATE_COLLISION 0x7c /* Port serial status reg (PSR) */ -#define ETH_INTERFACE_GMII_MII 0 -#define ETH_INTERFACE_PCM BIT0 -#define ETH_LINK_IS_DOWN 0 -#define ETH_LINK_IS_UP BIT1 -#define ETH_PORT_AT_HALF_DUPLEX 0 -#define ETH_PORT_AT_FULL_DUPLEX BIT2 -#define ETH_RX_FLOW_CTRL_DISABLED 0 -#define ETH_RX_FLOW_CTRL_ENBALED BIT3 -#define ETH_GMII_SPEED_100_10 0 -#define ETH_GMII_SPEED_1000 BIT4 -#define ETH_MII_SPEED_10 0 -#define ETH_MII_SPEED_100 BIT5 -#define ETH_NO_TX 0 -#define ETH_TX_IN_PROGRESS BIT7 -#define ETH_BYPASS_NO_ACTIVE 0 -#define ETH_BYPASS_ACTIVE BIT8 -#define ETH_PORT_NOT_AT_PARTITION_STATE 0 -#define ETH_PORT_AT_PARTITION_STATE BIT9 -#define ETH_PORT_TX_FIFO_NOT_EMPTY 0 -#define ETH_PORT_TX_FIFO_EMPTY BIT10 - - -/* These macros describes the Port configuration reg (Px_cR) bits */ -#define ETH_UNICAST_NORMAL_MODE 0 -#define ETH_UNICAST_PROMISCUOUS_MODE BIT0 -#define ETH_DEFAULT_RX_QUEUE_0 0 -#define ETH_DEFAULT_RX_QUEUE_1 BIT1 -#define ETH_DEFAULT_RX_QUEUE_2 BIT2 -#define ETH_DEFAULT_RX_QUEUE_3 (BIT2 | BIT1) -#define ETH_DEFAULT_RX_QUEUE_4 BIT3 -#define ETH_DEFAULT_RX_QUEUE_5 (BIT3 | BIT1) -#define ETH_DEFAULT_RX_QUEUE_6 (BIT3 | BIT2) -#define ETH_DEFAULT_RX_QUEUE_7 (BIT3 | BIT2 | BIT1) -#define ETH_DEFAULT_RX_ARP_QUEUE_0 0 -#define ETH_DEFAULT_RX_ARP_QUEUE_1 BIT4 -#define ETH_DEFAULT_RX_ARP_QUEUE_2 BIT5 -#define ETH_DEFAULT_RX_ARP_QUEUE_3 (BIT5 | BIT4) -#define ETH_DEFAULT_RX_ARP_QUEUE_4 BIT6 -#define ETH_DEFAULT_RX_ARP_QUEUE_5 (BIT6 | BIT4) -#define ETH_DEFAULT_RX_ARP_QUEUE_6 (BIT6 | BIT5) -#define ETH_DEFAULT_RX_ARP_QUEUE_7 (BIT6 | BIT5 | BIT4) -#define ETH_RECEIVE_BC_IF_NOT_IP_OR_ARP 0 -#define ETH_REJECT_BC_IF_NOT_IP_OR_ARP BIT7 -#define ETH_RECEIVE_BC_IF_IP 0 -#define ETH_REJECT_BC_IF_IP BIT8 -#define ETH_RECEIVE_BC_IF_ARP 0 -#define ETH_REJECT_BC_IF_ARP BIT9 -#define ETH_TX_AM_NO_UPDATE_ERROR_SUMMARY BIT12 -#define ETH_CAPTURE_TCP_FRAMES_DIS 0 -#define ETH_CAPTURE_TCP_FRAMES_EN BIT14 -#define ETH_CAPTURE_UDP_FRAMES_DIS 0 -#define ETH_CAPTURE_UDP_FRAMES_EN BIT15 -#define ETH_DEFAULT_RX_TCP_QUEUE_0 0 -#define ETH_DEFAULT_RX_TCP_QUEUE_1 BIT16 -#define ETH_DEFAULT_RX_TCP_QUEUE_2 BIT17 -#define ETH_DEFAULT_RX_TCP_QUEUE_3 (BIT17 | BIT16) -#define ETH_DEFAULT_RX_TCP_QUEUE_4 BIT18 -#define ETH_DEFAULT_RX_TCP_QUEUE_5 (BIT18 | BIT16) -#define ETH_DEFAULT_RX_TCP_QUEUE_6 (BIT18 | BIT17) -#define ETH_DEFAULT_RX_TCP_QUEUE_7 (BIT18 | BIT17 | BIT16) -#define ETH_DEFAULT_RX_UDP_QUEUE_0 0 -#define ETH_DEFAULT_RX_UDP_QUEUE_1 BIT19 -#define ETH_DEFAULT_RX_UDP_QUEUE_2 BIT20 -#define ETH_DEFAULT_RX_UDP_QUEUE_3 (BIT20 | BIT19) -#define ETH_DEFAULT_RX_UDP_QUEUE_4 (BIT21 -#define ETH_DEFAULT_RX_UDP_QUEUE_5 (BIT21 | BIT19) -#define ETH_DEFAULT_RX_UDP_QUEUE_6 (BIT21 | BIT20) -#define ETH_DEFAULT_RX_UDP_QUEUE_7 (BIT21 | BIT20 | BIT19) -#define ETH_DEFAULT_RX_BPDU_QUEUE_0 0 -#define ETH_DEFAULT_RX_BPDU_QUEUE_1 BIT22 -#define ETH_DEFAULT_RX_BPDU_QUEUE_2 BIT23 -#define ETH_DEFAULT_RX_BPDU_QUEUE_3 (BIT23 | BIT22) -#define ETH_DEFAULT_RX_BPDU_QUEUE_4 BIT24 -#define ETH_DEFAULT_RX_BPDU_QUEUE_5 (BIT24 | BIT22) -#define ETH_DEFAULT_RX_BPDU_QUEUE_6 (BIT24 | BIT23) -#define ETH_DEFAULT_RX_BPDU_QUEUE_7 (BIT24 | BIT23 | BIT22) - - -/* These macros describes the Port configuration extend reg (Px_cXR) bits*/ -#define ETH_CLASSIFY_EN BIT0 -#define ETH_SPAN_BPDU_PACKETS_AS_NORMAL 0 -#define ETH_SPAN_BPDU_PACKETS_TO_RX_QUEUE_7 BIT1 -#define ETH_PARTITION_DISABLE 0 -#define ETH_PARTITION_ENABLE BIT2 - - -/* Tx/Rx queue command reg (RQCR/TQCR)*/ -#define ETH_QUEUE_0_ENABLE BIT0 -#define ETH_QUEUE_1_ENABLE BIT1 -#define ETH_QUEUE_2_ENABLE BIT2 -#define ETH_QUEUE_3_ENABLE BIT3 -#define ETH_QUEUE_4_ENABLE BIT4 -#define ETH_QUEUE_5_ENABLE BIT5 -#define ETH_QUEUE_6_ENABLE BIT6 -#define ETH_QUEUE_7_ENABLE BIT7 -#define ETH_QUEUE_0_DISABLE BIT8 -#define ETH_QUEUE_1_DISABLE BIT9 -#define ETH_QUEUE_2_DISABLE BIT10 -#define ETH_QUEUE_3_DISABLE BIT11 -#define ETH_QUEUE_4_DISABLE BIT12 -#define ETH_QUEUE_5_DISABLE BIT13 -#define ETH_QUEUE_6_DISABLE BIT14 -#define ETH_QUEUE_7_DISABLE BIT15 - - -/* These macros describes the Port Sdma configuration reg (SDCR) bits */ -#define ETH_RIFB BIT0 -#define ETH_RX_BURST_SIZE_1_64BIT 0 -#define ETH_RX_BURST_SIZE_2_64BIT BIT1 -#define ETH_RX_BURST_SIZE_4_64BIT BIT2 -#define ETH_RX_BURST_SIZE_8_64BIT (BIT2 | BIT1) -#define ETH_RX_BURST_SIZE_16_64BIT BIT3 -#define ETH_BLM_RX_NO_SWAP BIT4 -#define ETH_BLM_RX_BYTE_SWAP 0 -#define ETH_BLM_TX_NO_SWAP BIT5 -#define ETH_BLM_TX_BYTE_SWAP 0 -#define ETH_DESCRIPTORS_BYTE_SWAP BIT6 -#define ETH_DESCRIPTORS_NO_SWAP 0 -#define ETH_TX_BURST_SIZE_1_64BIT 0 -#define ETH_TX_BURST_SIZE_2_64BIT BIT22 -#define ETH_TX_BURST_SIZE_4_64BIT BIT23 -#define ETH_TX_BURST_SIZE_8_64BIT (BIT23 | BIT22) -#define ETH_TX_BURST_SIZE_16_64BIT BIT24 - - - -/* These macros describes the Port serial control reg (PSCR) bits */ -#define ETH_SERIAL_PORT_DISABLE 0 -#define ETH_SERIAL_PORT_ENABLE BIT0 -#define ETH_FORCE_LINK_PASS BIT1 -#define ETH_DO_NOT_FORCE_LINK_PASS 0 -#define ETH_ENABLE_AUTO_NEG_FOR_DUPLX 0 -#define ETH_DISABLE_AUTO_NEG_FOR_DUPLX BIT2 -#define ETH_ENABLE_AUTO_NEG_FOR_FLOW_CTRL 0 -#define ETH_DISABLE_AUTO_NEG_FOR_FLOW_CTRL BIT3 -#define ETH_ADV_NO_FLOW_CTRL 0 -#define ETH_ADV_SYMMETRIC_FLOW_CTRL BIT4 -#define ETH_FORCE_FC_MODE_NO_PAUSE_DIS_TX 0 -#define ETH_FORCE_FC_MODE_TX_PAUSE_DIS BIT5 -#define ETH_FORCE_BP_MODE_NO_JAM 0 -#define ETH_FORCE_BP_MODE_JAM_TX BIT7 -#define ETH_FORCE_BP_MODE_JAM_TX_ON_RX_ERR BIT8 -#define ETH_FORCE_LINK_FAIL 0 -#define ETH_DO_NOT_FORCE_LINK_FAIL BIT10 -#define ETH_RETRANSMIT_16_ATTEMPTS 0 -#define ETH_RETRANSMIT_FOREVER BIT11 -#define ETH_DISABLE_AUTO_NEG_SPEED_GMII BIT13 -#define ETH_ENABLE_AUTO_NEG_SPEED_GMII 0 -#define ETH_DTE_ADV_0 0 -#define ETH_DTE_ADV_1 BIT14 -#define ETH_DISABLE_AUTO_NEG_BYPASS 0 -#define ETH_ENABLE_AUTO_NEG_BYPASS BIT15 -#define ETH_AUTO_NEG_NO_CHANGE 0 -#define ETH_RESTART_AUTO_NEG BIT16 -#define ETH_MAX_RX_PACKET_1518BYTE 0 -#define ETH_MAX_RX_PACKET_1522BYTE BIT17 -#define ETH_MAX_RX_PACKET_1552BYTE BIT18 -#define ETH_MAX_RX_PACKET_9022BYTE (BIT18 | BIT17) -#define ETH_MAX_RX_PACKET_9192BYTE BIT19 -#define ETH_MAX_RX_PACKET_9700BYTE (BIT19 | BIT17) -#define ETH_SET_EXT_LOOPBACK BIT20 -#define ETH_CLR_EXT_LOOPBACK 0 -#define ETH_SET_FULL_DUPLEX_MODE BIT21 -#define ETH_SET_HALF_DUPLEX_MODE 0 -#define ETH_ENABLE_FLOW_CTRL_TX_RX_IN_FULL_DUPLEX BIT22 -#define ETH_DISABLE_FLOW_CTRL_TX_RX_IN_FULL_DUPLEX 0 -#define ETH_SET_GMII_SPEED_TO_10_100 0 -#define ETH_SET_GMII_SPEED_TO_1000 BIT23 -#define ETH_SET_MII_SPEED_TO_10 0 -#define ETH_SET_MII_SPEED_TO_100 BIT24 - +#define ETH_INTERFACE_GMII_MII 0 +#define ETH_INTERFACE_PCM BIT0 +#define ETH_LINK_IS_DOWN 0 +#define ETH_LINK_IS_UP BIT1 +#define ETH_PORT_AT_HALF_DUPLEX 0 +#define ETH_PORT_AT_FULL_DUPLEX BIT2 +#define ETH_RX_FLOW_CTRL_DISABLED 0 +#define ETH_RX_FLOW_CTRL_ENBALED BIT3 +#define ETH_GMII_SPEED_100_10 0 +#define ETH_GMII_SPEED_1000 BIT4 +#define ETH_MII_SPEED_10 0 +#define ETH_MII_SPEED_100 BIT5 +#define ETH_NO_TX 0 +#define ETH_TX_IN_PROGRESS BIT7 +#define ETH_BYPASS_NO_ACTIVE 0 +#define ETH_BYPASS_ACTIVE BIT8 +#define ETH_PORT_NOT_AT_PARTITION_STATE 0 +#define ETH_PORT_AT_PARTITION_STATE BIT9 +#define ETH_PORT_TX_FIFO_NOT_EMPTY 0 +#define ETH_PORT_TX_FIFO_EMPTY BIT10 + +#define ETH_DEFAULT_RX_BPDU_QUEUE_3 (BIT23 | BIT22) +#define ETH_DEFAULT_RX_BPDU_QUEUE_4 BIT24 +#define ETH_DEFAULT_RX_BPDU_QUEUE_5 (BIT24 | BIT22) +#define ETH_DEFAULT_RX_BPDU_QUEUE_6 (BIT24 | BIT23) +#define ETH_DEFAULT_RX_BPDU_QUEUE_7 (BIT24 | BIT23 | BIT22) /* SMI reg */ -#define ETH_SMI_BUSY BIT28 /* 0 - Write, 1 - Read */ -#define ETH_SMI_READ_VALID BIT27 /* 0 - Write, 1 - Read */ +#define ETH_SMI_BUSY BIT28 /* 0 - Write, 1 - Read */ +#define ETH_SMI_READ_VALID BIT27 /* 0 - Write, 1 - Read */ #define ETH_SMI_OPCODE_WRITE 0 /* Completion of Read operation */ -#define ETH_SMI_OPCODE_READ BIT26 /* Operation is in progress */ +#define ETH_SMI_OPCODE_READ BIT26 /* Operation is in progress */ /* SDMA command status fields macros */ /* Tx & Rx descriptors status */ -#define ETH_ERROR_SUMMARY (BIT0) +#define ETH_ERROR_SUMMARY (BIT0) /* Tx & Rx descriptors command */ -#define ETH_BUFFER_OWNED_BY_DMA (BIT31) +#define ETH_BUFFER_OWNED_BY_DMA (BIT31) /* Tx descriptors status */ -#define ETH_LC_ERROR (0 ) -#define ETH_UR_ERROR (BIT1 ) -#define ETH_RL_ERROR (BIT2 ) -#define ETH_LLC_SNAP_FORMAT (BIT9 ) +#define ETH_LC_ERROR (0 ) +#define ETH_UR_ERROR (BIT1 ) +#define ETH_RL_ERROR (BIT2 ) +#define ETH_LLC_SNAP_FORMAT (BIT9 ) /* Rx descriptors status */ -#define ETH_CRC_ERROR (0 ) -#define ETH_OVERRUN_ERROR (BIT1 ) -#define ETH_MAX_FRAME_LENGTH_ERROR (BIT2 ) -#define ETH_RESOURCE_ERROR ((BIT2 | BIT1)) -#define ETH_VLAN_TAGGED (BIT19) -#define ETH_BPDU_FRAME (BIT20) -#define ETH_TCP_FRAME_OVER_IP_V_4 (0 ) -#define ETH_UDP_FRAME_OVER_IP_V_4 (BIT21) -#define ETH_OTHER_FRAME_TYPE (BIT22) -#define ETH_LAYER_2_IS_ETH_V_2 (BIT23) -#define ETH_FRAME_TYPE_IP_V_4 (BIT24) -#define ETH_FRAME_HEADER_OK (BIT25) -#define ETH_RX_LAST_DESC (BIT26) -#define ETH_RX_FIRST_DESC (BIT27) -#define ETH_UNKNOWN_DESTINATION_ADDR (BIT28) -#define ETH_RX_ENABLE_INTERRUPT (BIT29) -#define ETH_LAYER_4_CHECKSUM_OK (BIT30) +#define ETH_CRC_ERROR (0 ) +#define ETH_OVERRUN_ERROR (BIT1 ) +#define ETH_MAX_FRAME_LENGTH_ERROR (BIT2 ) +#define ETH_RESOURCE_ERROR ((BIT2 | BIT1)) +#define ETH_VLAN_TAGGED (BIT19) +#define ETH_BPDU_FRAME (BIT20) +#define ETH_TCP_FRAME_OVER_IP_V_4 (0 ) +#define ETH_UDP_FRAME_OVER_IP_V_4 (BIT21) +#define ETH_OTHER_FRAME_TYPE (BIT22) +#define ETH_LAYER_2_IS_ETH_V_2 (BIT23) +#define ETH_FRAME_TYPE_IP_V_4 (BIT24) +#define ETH_FRAME_HEADER_OK (BIT25) +#define ETH_RX_LAST_DESC (BIT26) +#define ETH_RX_FIRST_DESC (BIT27) +#define ETH_UNKNOWN_DESTINATION_ADDR (BIT28) +#define ETH_RX_ENABLE_INTERRUPT (BIT29) +#define ETH_LAYER_4_CHECKSUM_OK (BIT30) /* Rx descriptors byte count */ -#define ETH_FRAME_FRAGMENTED (BIT2) +#define ETH_FRAME_FRAGMENTED (BIT2) /* Tx descriptors command */ #define ETH_LAYER_4_CHECKSUM_FIRST_DESC (BIT10) -#define ETH_FRAME_SET_TO_VLAN (BIT15) -#define ETH_TCP_FRAME (0 ) -#define ETH_UDP_FRAME (BIT16) -#define ETH_GEN_TCP_UDP_CHECKSUM (BIT17) -#define ETH_GEN_IP_V_4_CHECKSUM (BIT18) -#define ETH_ZERO_PADDING (BIT19) -#define ETH_TX_LAST_DESC (BIT20) -#define ETH_TX_FIRST_DESC (BIT21) -#define ETH_GEN_CRC (BIT22) -#define ETH_TX_ENABLE_INTERRUPT (BIT23) -#define ETH_AUTO_MODE (BIT30) +#define ETH_FRAME_SET_TO_VLAN (BIT15) +#define ETH_TCP_FRAME (0 ) +#define ETH_UDP_FRAME (BIT16) +#define ETH_GEN_TCP_UDP_CHECKSUM (BIT17) +#define ETH_GEN_IP_V_4_CHECKSUM (BIT18) +#define ETH_ZERO_PADDING (BIT19) +#define ETH_TX_LAST_DESC (BIT20) +#define ETH_TX_FIRST_DESC (BIT21) +#define ETH_GEN_CRC (BIT22) +#define ETH_TX_ENABLE_INTERRUPT (BIT23) +#define ETH_AUTO_MODE (BIT30) /* typedefs */ typedef enum _eth_func_ret_status { - ETH_OK, /* Returned as expected. */ - ETH_ERROR, /* Fundamental error. */ - ETH_RETRY, /* Could not process request. Try later. */ - ETH_END_OF_JOB, /* Ring has nothing to process. */ - ETH_QUEUE_FULL, /* Ring resource error. */ - ETH_QUEUE_LAST_RESOURCE /* Ring resources about to exhaust. */ + ETH_OK, /* Returned as expected. */ + ETH_ERROR, /* Fundamental error. */ + ETH_RETRY, /* Could not process request. Try later.*/ + ETH_END_OF_JOB, /* Ring has nothing to process. */ + ETH_QUEUE_FULL, /* Ring resource error. */ + ETH_QUEUE_LAST_RESOURCE /* Ring resources about to exhaust. */ } ETH_FUNC_RET_STATUS; typedef enum _eth_target { @@ -441,66 +241,103 @@ */ #if defined(__BIG_ENDIAN) struct eth_rx_desc { - u16 byte_cnt; /* Descriptor buffer byte count */ - u16 buf_size; /* Buffer size */ - u32 cmd_sts; /* Descriptor command status */ - u32 next_desc_ptr; /* Next descriptor pointer */ - u32 buf_ptr; /* Descriptor buffer pointer */ + u16 byte_cnt; /* Descriptor buffer byte count */ + u16 buf_size; /* Buffer size */ + u32 cmd_sts; /* Descriptor command status */ + u32 next_desc_ptr; /* Next descriptor pointer */ + u32 buf_ptr; /* Descriptor buffer pointer */ }; struct eth_tx_desc { - u16 byte_cnt; /* buffer byte count */ - u16 l4i_chk; /* CPU provided TCP checksum */ - u32 cmd_sts; /* Command/status field */ - u32 next_desc_ptr; /* Pointer to next descriptor */ - u32 buf_ptr; /* pointer to buffer for this descriptor */ + u16 byte_cnt; /* buffer byte count */ + u16 l4i_chk; /* CPU provided TCP checksum */ + u32 cmd_sts; /* Command/status field */ + u32 next_desc_ptr; /* Pointer to next descriptor */ + u32 buf_ptr; /* pointer to buffer for this descriptor*/ }; #elif defined(__LITTLE_ENDIAN) struct eth_rx_desc { - u32 cmd_sts; /* Descriptor command status */ - u16 buf_size; /* Buffer size */ - u16 byte_cnt; /* Descriptor buffer byte count */ - u32 buf_ptr; /* Descriptor buffer pointer */ - u32 next_desc_ptr; /* Next descriptor pointer */ + u32 cmd_sts; /* Descriptor command status */ + u16 buf_size; /* Buffer size */ + u16 byte_cnt; /* Descriptor buffer byte count */ + u32 buf_ptr; /* Descriptor buffer pointer */ + u32 next_desc_ptr; /* Next descriptor pointer */ }; struct eth_tx_desc { - u32 cmd_sts; /* Command/status field */ - u16 l4i_chk; /* CPU provided TCP checksum */ - u16 byte_cnt; /* buffer byte count */ - u32 buf_ptr; /* pointer to buffer for this descriptor */ - u32 next_desc_ptr; /* Pointer to next descriptor */ + u32 cmd_sts; /* Command/status field */ + u16 l4i_chk; /* CPU provided TCP checksum */ + u16 byte_cnt; /* buffer byte count */ + u32 buf_ptr; /* pointer to buffer for this descriptor*/ + u32 next_desc_ptr; /* Pointer to next descriptor */ }; #else #error One of __BIG_ENDIAN or __LITTLE_ENDIAN must be defined #endif -/* Unified struct for Rx and Tx operations. The user is not required to */ -/* be familier with neither Tx nor Rx descriptors. */ +/* Unified struct for Rx and Tx operations. The user is not required to */ +/* be familier with neither Tx nor Rx descriptors. */ struct pkt_info { - unsigned short byte_cnt; /* Descriptor buffer byte count */ - unsigned short l4i_chk; /* Tx CPU provided TCP Checksum */ - unsigned int cmd_sts; /* Descriptor command status */ - dma_addr_t buf_ptr; /* Descriptor buffer pointer */ - struct sk_buff * return_info; /* User resource return information */ + unsigned short byte_cnt; /* Descriptor buffer byte count */ + unsigned short l4i_chk; /* Tx CPU provided TCP Checksum */ + unsigned int cmd_sts; /* Descriptor command status */ + dma_addr_t buf_ptr; /* Descriptor buffer pointer */ + struct sk_buff *return_info; /* User resource return information */ }; - /* Ethernet port specific infomation */ -struct mv64340_private { - int port_num; /* User Ethernet port number */ - u8 port_mac_addr[6]; /* User defined port MAC address. */ - u32 port_config; /* User port configuration value */ - u32 port_config_extend; /* User port config extend value */ - u32 port_sdma_config; /* User port SDMA config value */ - u32 port_serial_control; /* User port serial control value */ - u32 port_tx_queue_command; /* Port active Tx queues summary */ - u32 port_rx_queue_command; /* Port active Rx queues summary */ +struct mv643xx_mib_counters { + u64 good_octets_received; + u32 bad_octets_received; + u32 internal_mac_transmit_err; + u32 good_frames_received; + u32 bad_frames_received; + u32 broadcast_frames_received; + u32 multicast_frames_received; + u32 frames_64_octets; + u32 frames_65_to_127_octets; + u32 frames_128_to_255_octets; + u32 frames_256_to_511_octets; + u32 frames_512_to_1023_octets; + u32 frames_1024_to_max_octets; + u64 good_octets_sent; + u32 good_frames_sent; + u32 excessive_collision; + u32 multicast_frames_sent; + u32 broadcast_frames_sent; + u32 unrec_mac_control_received; + u32 fc_sent; + u32 good_fc_received; + u32 bad_fc_received; + u32 undersize_received; + u32 fragments_received; + u32 oversize_received; + u32 jabber_received; + u32 mac_receive_error; + u32 bad_crc_event; + u32 collision; + u32 late_collision; +}; + +struct mv643xx_private { + int port_num; /* User Ethernet port number */ + u8 port_mac_addr[6]; /* User defined port MAC address.*/ + u32 port_config; /* User port configuration value*/ + u32 port_config_extend; /* User port config extend value*/ + u32 port_sdma_config; /* User port SDMA config value */ + u32 port_serial_control; /* User port serial control value */ + u32 port_tx_queue_command; /* Port active Tx queues summary*/ + u32 port_rx_queue_command; /* Port active Rx queues summary*/ + + u32 rx_sram_addr; /* Base address of rx sram area */ + u32 rx_sram_size; /* Size of rx sram area */ + u32 tx_sram_addr; /* Base address of tx sram area */ + u32 tx_sram_size; /* Size of tx sram area */ - int rx_resource_err; /* Rx ring resource error flag */ - int tx_resource_err; /* Tx ring resource error flag */ + int rx_resource_err; /* Rx ring resource error flag */ + int tx_resource_err; /* Tx ring resource error flag */ /* Tx/Rx rings managment indexes fields. For driver use */ @@ -509,30 +346,32 @@ /* Next available and first returning Tx resource */ int tx_curr_desc_q, tx_used_desc_q; -#ifdef MV64340_CHECKSUM_OFFLOAD_TX - int tx_first_desc_q; +#ifdef MV643XX_CHECKSUM_OFFLOAD_TX + int tx_first_desc_q; + u32 tx_first_command; #endif -#ifdef MV64340_TX_FAST_REFILL - u32 tx_clean_threshold; +#ifdef MV643XX_TX_FAST_REFILL + u32 tx_clean_threshold; #endif - volatile struct eth_rx_desc * p_rx_desc_area; - dma_addr_t rx_desc_dma; - unsigned int rx_desc_area_size; - struct sk_buff * rx_skb[MV64340_RX_QUEUE_SIZE]; - - volatile struct eth_tx_desc * p_tx_desc_area; - dma_addr_t tx_desc_dma; - unsigned int tx_desc_area_size; - struct sk_buff * tx_skb[MV64340_TX_QUEUE_SIZE]; + struct eth_rx_desc *p_rx_desc_area; + dma_addr_t rx_desc_dma; + unsigned int rx_desc_area_size; + struct sk_buff **rx_skb; + + struct eth_tx_desc *p_tx_desc_area; + dma_addr_t tx_desc_dma; + unsigned int tx_desc_area_size; + struct sk_buff **tx_skb; - struct work_struct tx_timeout_task; + struct work_struct tx_timeout_task; /* - * Former struct mv64340_eth_priv members start here + * Former struct mv643xx_eth_priv members start here */ struct net_device_stats stats; + struct mv643xx_mib_counters mib_counters; spinlock_t lock; /* Size of Tx Ring per queue */ unsigned int tx_ring_size; @@ -544,13 +383,13 @@ unsigned int rx_ring_skbs; /* - * rx_task used to fill RX ring out of bottom half context + * rx_task used to fill RX ring out of bottom half context */ struct work_struct rx_task; - /* - * Used in case RX Ring is empty, which can be caused when - * system does not have resources (skb's) + /* + * Used in case RX Ring is empty, which can be caused when + * system does not have resources (skb's) */ struct timer_list timeout; long rx_task_busy __attribute__ ((aligned(SMP_CACHE_BYTES))); @@ -563,9 +402,9 @@ /* ethernet.h API list */ /* Port operation control routines */ -static void eth_port_init(struct mv64340_private *mp); +static void eth_port_init(struct mv643xx_private *mp); static void eth_port_reset(unsigned int eth_port_num); -static int eth_port_start(struct mv64340_private *mp); +static void eth_port_start(struct mv643xx_private *mp); static void ethernet_set_config_reg(unsigned int eth_port_num, unsigned int value); @@ -576,26 +415,24 @@ unsigned char *p_addr); /* PHY and MIB routines */ -static int ethernet_phy_reset(unsigned int eth_port_num); +static void ethernet_phy_reset(unsigned int eth_port_num); + +static void eth_port_write_smi_reg(unsigned int eth_port_num, + unsigned int phy_reg, unsigned int value); -static int eth_port_write_smi_reg(unsigned int eth_port_num, - unsigned int phy_reg, - unsigned int value); - -static int eth_port_read_smi_reg(unsigned int eth_port_num, - unsigned int phy_reg, - unsigned int *value); +static void eth_port_read_smi_reg(unsigned int eth_port_num, + unsigned int phy_reg, unsigned int *value); static void eth_clear_mib_counters(unsigned int eth_port_num); /* Port data flow control routines */ -static ETH_FUNC_RET_STATUS eth_port_send(struct mv64340_private *mp, - struct pkt_info * p_pkt_info); -static ETH_FUNC_RET_STATUS eth_tx_return_desc(struct mv64340_private *mp, - struct pkt_info * p_pkt_info); -static ETH_FUNC_RET_STATUS eth_port_receive(struct mv64340_private *mp, - struct pkt_info * p_pkt_info); -static ETH_FUNC_RET_STATUS eth_rx_return_buff(struct mv64340_private *mp, - struct pkt_info * p_pkt_info); +static ETH_FUNC_RET_STATUS eth_port_send(struct mv643xx_private *mp, + struct pkt_info *p_pkt_info); +static ETH_FUNC_RET_STATUS eth_tx_return_desc(struct mv643xx_private *mp, + struct pkt_info *p_pkt_info); +static ETH_FUNC_RET_STATUS eth_port_receive(struct mv643xx_private *mp, + struct pkt_info *p_pkt_info); +static ETH_FUNC_RET_STATUS eth_rx_return_buff(struct mv643xx_private *mp, + struct pkt_info *p_pkt_info); -#endif /* __MV64340_ETH_H__ */ +#endif /* __MV643XX_ETH_H__ */ diff -Nru a/drivers/net/sis900.c b/drivers/net/sis900.c --- a/drivers/net/sis900.c 2005-03-08 14:29:45 -05:00 +++ b/drivers/net/sis900.c 2005-03-08 14:29:45 -05:00 @@ -1,6 +1,6 @@ /* sis900.c: A SiS 900/7016 PCI Fast Ethernet driver for Linux. Copyright 1999 Silicon Integrated System Corporation - Revision: 1.08.06 Sep. 24 2002 + Revision: 1.08.08 Jan. 22 2005 Modified from the driver which is originally written by Donald Becker. @@ -16,8 +16,8 @@ preliminary Rev. 1.0 Nov. 10, 1998 SiS 7014 Single Chip 100BASE-TX/10BASE-T Physical Layer Solution, preliminary Rev. 1.0 Jan. 18, 1998 - http://www.sis.com.tw/support/databook.htm + Rev 1.08.08 Jan. 22 2005 Daniele Venzano use netif_msg for debugging messages Rev 1.08.07 Nov. 2 2003 Daniele Venzano add suspend/resume support Rev 1.08.06 Sep. 24 2002 Mufasa Yang bug fix for Tx timeout & add SiS963 support Rev 1.08.05 Jun. 6 2002 Mufasa Yang bug fix for read_eeprom & Tx descriptor over-boundary @@ -74,7 +74,7 @@ #include "sis900.h" #define SIS900_MODULE_NAME "sis900" -#define SIS900_DRV_VERSION "v1.08.07 11/02/2003" +#define SIS900_DRV_VERSION "v1.08.08 Jan. 22 2005" static char version[] __devinitdata = KERN_INFO "sis900.c: " SIS900_DRV_VERSION "\n"; @@ -82,8 +82,13 @@ static int max_interrupt_work = 40; static int multicast_filter_limit = 128; -#define sis900_debug debug -static int sis900_debug; +static int sis900_debug = -1; /* Use SIS900_DEF_MSG as value */ + +#define SIS900_DEF_MSG \ + (NETIF_MSG_DRV | \ + NETIF_MSG_LINK | \ + NETIF_MSG_RX_ERR | \ + NETIF_MSG_TX_ERR) /* Time in jiffies before concluding the transmitter is hung. */ #define TX_TIMEOUT (4*HZ) @@ -160,6 +165,8 @@ struct timer_list timer; /* Link status detection timer. */ u8 autong_complete; /* 1: auto-negotiate complete */ + u32 msg_enable; + unsigned int cur_rx, dirty_rx; /* producer/comsumer pointers for Tx/Rx ring */ unsigned int cur_tx, dirty_tx; @@ -174,6 +181,7 @@ unsigned int tx_full; /* The Tx queue is full. */ u8 host_bridge_rev; + u8 chipset_rev; }; MODULE_AUTHOR("Jim Huang , Ollie Lho "); @@ -182,11 +190,12 @@ module_param(multicast_filter_limit, int, 0444); module_param(max_interrupt_work, int, 0444); -module_param(debug, int, 0444); +module_param(sis900_debug, int, 0444); MODULE_PARM_DESC(multicast_filter_limit, "SiS 900/7016 maximum number of filtered multicast addresses"); MODULE_PARM_DESC(max_interrupt_work, "SiS 900/7016 maximum events handled per interrupt"); -MODULE_PARM_DESC(debug, "SiS 900/7016 debug level (2-4)"); +MODULE_PARM_DESC(sis900_debug, "SiS 900/7016 bitmapped debugging message level"); +static void sis900_poll(struct net_device *dev); static int sis900_open(struct net_device *net_dev); static int sis900_mii_probe (struct net_device * net_dev); static void sis900_init_rxfilter (struct net_device * net_dev); @@ -235,7 +244,7 @@ /* check to see if we have sane EEPROM */ signature = (u16) read_eeprom(ioaddr, EEPROMSignature); if (signature == 0xffff || signature == 0x0000) { - printk (KERN_INFO "%s: Error EERPOM read %x\n", + printk (KERN_WARNING "%s: Error EERPOM read %x\n", net_dev->name, signature); return 0; } @@ -268,7 +277,7 @@ if (!isa_bridge) isa_bridge = pci_get_device(PCI_VENDOR_ID_SI, 0x0018, isa_bridge); if (!isa_bridge) { - printk("%s: Can not find ISA bridge\n", net_dev->name); + printk(KERN_WARNING "%s: Can not find ISA bridge\n", net_dev->name); return 0; } pci_read_config_byte(isa_bridge, 0x48, ®); @@ -386,7 +395,6 @@ void *ring_space; long ioaddr; int i, ret; - u8 revision; char *card_name = card_names[pci_id->driver_data]; /* when built into the kernel, we only print version if device is found */ @@ -456,35 +464,50 @@ net_dev->tx_timeout = sis900_tx_timeout; net_dev->watchdog_timeo = TX_TIMEOUT; net_dev->ethtool_ops = &sis900_ethtool_ops; - + +#ifdef CONFIG_NET_POLL_CONTROLLER + net_dev->poll_controller = &sis900_poll; +#endif + + if (sis900_debug > 0) + sis_priv->msg_enable = sis900_debug; + else + sis_priv->msg_enable = SIS900_DEF_MSG; + ret = register_netdev(net_dev); if (ret) goto err_unmap_rx; /* Get Mac address according to the chip revision */ - pci_read_config_byte(pci_dev, PCI_CLASS_REVISION, &revision); + pci_read_config_byte(pci_dev, PCI_CLASS_REVISION, &(sis_priv->chipset_rev)); + if(netif_msg_probe(sis_priv)) + printk(KERN_DEBUG "%s: detected revision %2.2x, " + "trying to get MAC address...\n", + net_dev->name, sis_priv->chipset_rev); + ret = 0; - - if (revision == SIS630E_900_REV) + if (sis_priv->chipset_rev == SIS630E_900_REV) ret = sis630e_get_mac_addr(pci_dev, net_dev); - else if ((revision > 0x81) && (revision <= 0x90) ) + else if ((sis_priv->chipset_rev > 0x81) && (sis_priv->chipset_rev <= 0x90) ) ret = sis635_get_mac_addr(pci_dev, net_dev); - else if (revision == SIS96x_900_REV) + else if (sis_priv->chipset_rev == SIS96x_900_REV) ret = sis96x_get_mac_addr(pci_dev, net_dev); else ret = sis900_get_mac_addr(pci_dev, net_dev); if (ret == 0) { + printk(KERN_WARNING "%s: Cannot read MAC address.\n", net_dev->name); ret = -ENODEV; goto err_out_unregister; } /* 630ET : set the mii access mode as software-mode */ - if (revision == SIS630ET_900_REV) + if (sis_priv->chipset_rev == SIS630ET_900_REV) outl(ACCESSMODE | inl(ioaddr + cr), ioaddr + cr); /* probe for mii transceiver */ if (sis900_mii_probe(net_dev) == 0) { + printk(KERN_WARNING "%s: Error probing MII device.\n", net_dev->name); ret = -ENODEV; goto err_out_unregister; } @@ -536,7 +559,6 @@ u16 poll_bit = MII_STAT_LINK, status = 0; unsigned long timeout = jiffies + 5 * HZ; int phy_addr; - u8 revision; sis_priv->mii = NULL; @@ -550,12 +572,16 @@ for(i = 0; i < 2; i++) mii_status = mdio_read(net_dev, phy_addr, MII_STATUS); - if (mii_status == 0xffff || mii_status == 0x0000) - /* the mii is not accessible, try next one */ + if (mii_status == 0xffff || mii_status == 0x0000) { + if (netif_msg_probe(sis_priv)) + printk(KERN_DEBUG "%s: MII at address %d" + " not accessible\n", + net_dev->name, phy_addr); continue; + } if ((mii_phy = kmalloc(sizeof(struct mii_phy), GFP_KERNEL)) == NULL) { - printk(KERN_INFO "Cannot allocate mem for struct mii_phy\n"); + printk(KERN_WARNING "Cannot allocate mem for struct mii_phy\n"); mii_phy = sis_priv->first_mii; while (mii_phy) { struct mii_phy *phy; @@ -581,9 +607,11 @@ if (mii_chip_table[i].phy_types == MIX) mii_phy->phy_types = (mii_status & (MII_STAT_CAN_TX_FDX | MII_STAT_CAN_TX)) ? LAN : HOME; - printk(KERN_INFO "%s: %s transceiver found at address %d.\n", - net_dev->name, mii_chip_table[i].name, - phy_addr); + printk(KERN_INFO "%s: %s transceiver found " + "at address %d.\n", + net_dev->name, + mii_chip_table[i].name, + phy_addr); break; } @@ -627,8 +655,7 @@ } } - pci_read_config_byte(sis_priv->pci_dev, PCI_CLASS_REVISION, &revision); - if (revision == SIS630E_900_REV) { + if (sis_priv->chipset_rev == SIS630E_900_REV) { /* SiS 630E has some bugs on default value of PHY registers */ mdio_write(net_dev, sis_priv->cur_phy, MII_ANADV, 0x05e1); mdio_write(net_dev, sis_priv->cur_phy, MII_CONFIG1, 0x22); @@ -930,6 +957,20 @@ return status; } +#ifdef CONFIG_NET_POLL_CONTROLLER +/* + * Polling 'interrupt' - used by things like netconsole to send skbs + * without having to re-enable interrupts. It's not called while + * the interrupt routine is executing. +*/ +static void sis900_poll(struct net_device *dev) +{ + disable_irq(dev->irq); + sis900_interrupt(dev->irq, dev, NULL); + enable_irq(dev->irq); +} +#endif + /** * sis900_open - open sis900 device * @net_dev: the net device to open @@ -943,15 +984,13 @@ { struct sis900_private *sis_priv = net_dev->priv; long ioaddr = net_dev->base_addr; - u8 revision; int ret; /* Soft reset the chip. */ sis900_reset(net_dev); /* Equalizer workaround Rule */ - pci_read_config_byte(sis_priv->pci_dev, PCI_CLASS_REVISION, &revision); - sis630_set_eq(net_dev, revision); + sis630_set_eq(net_dev, sis_priv->chipset_rev); ret = request_irq(net_dev->irq, &sis900_interrupt, SA_SHIRQ, net_dev->name, net_dev); @@ -999,6 +1038,7 @@ static void sis900_init_rxfilter (struct net_device * net_dev) { + struct sis900_private *sis_priv = net_dev->priv; long ioaddr = net_dev->base_addr; u32 rfcrSave; u32 i; @@ -1016,8 +1056,8 @@ outl((i << RFADDR_shift), ioaddr + rfcr); outl(w, ioaddr + rfdr); - if (sis900_debug > 2) { - printk(KERN_INFO "%s: Receive Filter Addrss[%d]=%x\n", + if (netif_msg_hw(sis_priv)) { + printk(KERN_DEBUG "%s: Receive Filter Addrss[%d]=%x\n", net_dev->name, i, inl(ioaddr + rfdr)); } } @@ -1054,8 +1094,8 @@ /* load Transmit Descriptor Register */ outl(sis_priv->tx_ring_dma, ioaddr + txdp); - if (sis900_debug > 2) - printk(KERN_INFO "%s: TX descriptor register loaded with: %8.8x\n", + if (netif_msg_hw(sis_priv)) + printk(KERN_DEBUG "%s: TX descriptor register loaded with: %8.8x\n", net_dev->name, inl(ioaddr + txdp)); } @@ -1108,8 +1148,8 @@ /* load Receive Descriptor Register */ outl(sis_priv->rx_ring_dma, ioaddr + rxdp); - if (sis900_debug > 2) - printk(KERN_INFO "%s: RX descriptor register loaded with: %8.8x\n", + if (netif_msg_hw(sis_priv)) + printk(KERN_DEBUG "%s: RX descriptor register loaded with: %8.8x\n", net_dev->name, inl(ioaddr + rxdp)); } @@ -1219,7 +1259,6 @@ struct mii_phy *mii_phy = sis_priv->mii; static int next_tick = 5*HZ; u16 status; - u8 revision; if (!sis_priv->autong_complete){ int speed, duplex = 0; @@ -1227,9 +1266,7 @@ sis900_read_mode(net_dev, &speed, &duplex); if (duplex){ sis900_set_mode(net_dev->base_addr, speed, duplex); - pci_read_config_byte(sis_priv->pci_dev, - PCI_CLASS_REVISION, &revision); - sis630_set_eq(net_dev, revision); + sis630_set_eq(net_dev, sis_priv->chipset_rev); netif_start_queue(net_dev); } @@ -1256,16 +1293,15 @@ /* Link ON -> OFF */ if (!(status & MII_STAT_LINK)){ netif_carrier_off(net_dev); - printk(KERN_INFO "%s: Media Link Off\n", net_dev->name); + if(netif_msg_link(sis_priv)) + printk(KERN_INFO "%s: Media Link Off\n", net_dev->name); /* Change mode issue */ if ((mii_phy->phy_id0 == 0x001D) && ((mii_phy->phy_id1 & 0xFFF0) == 0x8000)) sis900_reset_phy(net_dev, sis_priv->cur_phy); - pci_read_config_byte(sis_priv->pci_dev, - PCI_CLASS_REVISION, &revision); - sis630_set_eq(net_dev, revision); + sis630_set_eq(net_dev, sis_priv->chipset_rev); goto LookForLink; } @@ -1371,7 +1407,8 @@ status = mdio_read(net_dev, phy_addr, MII_STATUS); if (!(status & MII_STAT_LINK)){ - printk(KERN_INFO "%s: Media Link Off\n", net_dev->name); + if(netif_msg_link(sis_priv)) + printk(KERN_INFO "%s: Media Link Off\n", net_dev->name); sis_priv->autong_complete = 1; netif_carrier_off(net_dev); return; @@ -1433,7 +1470,8 @@ *speed = HW_SPEED_100_MBPS; } - printk(KERN_INFO "%s: Media Link On %s %s-duplex \n", + if(netif_msg_link(sis_priv)) + printk(KERN_INFO "%s: Media Link On %s %s-duplex \n", net_dev->name, *speed == HW_SPEED_100_MBPS ? "100mbps" : "10mbps", @@ -1456,8 +1494,9 @@ unsigned long flags; int i; - printk(KERN_INFO "%s: Transmit timeout, status %8.8x %8.8x \n", - net_dev->name, inl(ioaddr + cr), inl(ioaddr + isr)); + if(netif_msg_tx_err(sis_priv)) + printk(KERN_INFO "%s: Transmit timeout, status %8.8x %8.8x \n", + net_dev->name, inl(ioaddr + cr), inl(ioaddr + isr)); /* Disable interrupts by clearing the interrupt mask. */ outl(0x0000, ioaddr + imr); @@ -1558,8 +1597,8 @@ net_dev->trans_start = jiffies; - if (sis900_debug > 3) - printk(KERN_INFO "%s: Queued Tx packet at %p size %d " + if (netif_msg_tx_queued(sis_priv)) + printk(KERN_DEBUG "%s: Queued Tx packet at %p size %d " "to slot %d.\n", net_dev->name, skb->data, (int)skb->len, entry); @@ -1606,20 +1645,22 @@ /* something strange happened !!! */ if (status & HIBERR) { - printk(KERN_INFO "%s: Abnormal interrupt," - "status %#8.8x.\n", net_dev->name, status); + if(netif_msg_intr(sis_priv)) + printk(KERN_INFO "%s: Abnormal interrupt," + "status %#8.8x.\n", net_dev->name, status); break; } if (--boguscnt < 0) { - printk(KERN_INFO "%s: Too much work at interrupt, " - "interrupt status = %#8.8x.\n", - net_dev->name, status); + if(netif_msg_intr(sis_priv)) + printk(KERN_INFO "%s: Too much work at interrupt, " + "interrupt status = %#8.8x.\n", + net_dev->name, status); break; } } while (1); - if (sis900_debug > 3) - printk(KERN_INFO "%s: exiting interrupt, " + if(netif_msg_intr(sis_priv)) + printk(KERN_DEBUG "%s: exiting interrupt, " "interrupt status = 0x%#8.8x.\n", net_dev->name, inl(ioaddr + isr)); @@ -1644,8 +1685,8 @@ unsigned int entry = sis_priv->cur_rx % NUM_RX_DESC; u32 rx_status = sis_priv->rx_ring[entry].cmdsts; - if (sis900_debug > 3) - printk(KERN_INFO "sis900_rx, cur_rx:%4.4d, dirty_rx:%4.4d " + if (netif_msg_rx_status(sis_priv)) + printk(KERN_DEBUG "sis900_rx, cur_rx:%4.4d, dirty_rx:%4.4d " "status:0x%8.8x\n", sis_priv->cur_rx, sis_priv->dirty_rx, rx_status); @@ -1656,8 +1697,8 @@ if (rx_status & (ABORT|OVERRUN|TOOLONG|RUNT|RXISERR|CRCERR|FAERR)) { /* corrupted packet received */ - if (sis900_debug > 3) - printk(KERN_INFO "%s: Corrupted packet " + if (netif_msg_rx_err(sis_priv)) + printk(KERN_DEBUG "%s: Corrupted packet " "received, buffer status = 0x%8.8x.\n", net_dev->name, rx_status); sis_priv->stats.rx_errors++; @@ -1678,9 +1719,10 @@ some unknow bugs, it is possible that we are working on NULL sk_buff :-( */ if (sis_priv->rx_skbuff[entry] == NULL) { - printk(KERN_INFO "%s: NULL pointer " - "encountered in Rx ring, skipping\n", - net_dev->name); + if (netif_msg_rx_err(sis_priv)) + printk(KERN_INFO "%s: NULL pointer " + "encountered in Rx ring, skipping\n", + net_dev->name); break; } @@ -1707,9 +1749,10 @@ * "hole" on the buffer ring, it is not clear * how the hardware will react to this kind * of degenerated buffer */ - printk(KERN_INFO "%s: Memory squeeze," - "deferring packet.\n", - net_dev->name); + if (netif_msg_rx_status(sis_priv)) + printk(KERN_INFO "%s: Memory squeeze," + "deferring packet.\n", + net_dev->name); sis_priv->rx_skbuff[entry] = NULL; /* reset buffer descriptor state */ sis_priv->rx_ring[entry].cmdsts = 0; @@ -1743,9 +1786,10 @@ * "hole" on the buffer ring, it is not clear * how the hardware will react to this kind * of degenerated buffer */ - printk(KERN_INFO "%s: Memory squeeze," - "deferring packet.\n", - net_dev->name); + if (netif_msg_rx_err(sis_priv)) + printk(KERN_INFO "%s: Memory squeeze," + "deferring packet.\n", + net_dev->name); sis_priv->stats.rx_dropped++; break; } @@ -1794,8 +1838,8 @@ if (tx_status & (ABORT | UNDERRUN | OWCOLL)) { /* packet unsuccessfully transmitted */ - if (sis900_debug > 3) - printk(KERN_INFO "%s: Transmit " + if (netif_msg_tx_err(sis_priv)) + printk(KERN_DEBUG "%s: Transmit " "error, Tx status %8.8x.\n", net_dev->name, tx_status); sis_priv->stats.tx_errors++; @@ -1906,8 +1950,22 @@ strcpy (info->bus_info, pci_name(sis_priv->pci_dev)); } +static u32 sis900_get_msglevel(struct net_device *net_dev) +{ + struct sis900_private *sis_priv = net_dev->priv; + return sis_priv->msg_enable; +} + +static void sis900_set_msglevel(struct net_device *net_dev, u32 value) +{ + struct sis900_private *sis_priv = net_dev->priv; + sis_priv->msg_enable = value; +} + static struct ethtool_ops sis900_ethtool_ops = { - .get_drvinfo = sis900_get_drvinfo, + .get_drvinfo = sis900_get_drvinfo, + .get_msglevel = sis900_get_msglevel, + .set_msglevel = sis900_set_msglevel, }; /** @@ -2048,12 +2106,10 @@ case IF_PORT_AUI: /* AUI */ case IF_PORT_100BASEFX: /* 100BaseFx */ /* These Modes are not supported (are they?)*/ - printk(KERN_INFO "Not supported"); return -EOPNOTSUPP; break; default: - printk(KERN_INFO "Invalid"); return -EINVAL; } } @@ -2099,11 +2155,10 @@ u16 mc_filter[16] = {0}; /* 256/128 bits multicast hash table */ int i, table_entries; u32 rx_mode; - u8 revision; /* 635 Hash Table entires = 256(2^16) */ - pci_read_config_byte(sis_priv->pci_dev, PCI_CLASS_REVISION, &revision); - if((revision >= SIS635A_900_REV) || (revision == SIS900B_900_REV)) + if((sis_priv->chipset_rev >= SIS635A_900_REV) || + (sis_priv->chipset_rev == SIS900B_900_REV)) table_entries = 16; else table_entries = 8; @@ -2129,7 +2184,7 @@ mclist && i < net_dev->mc_count; i++, mclist = mclist->next) { unsigned int bit_nr = - sis900_mcast_bitnr(mclist->dmi_addr, revision); + sis900_mcast_bitnr(mclist->dmi_addr, sis_priv->chipset_rev); mc_filter[bit_nr >> 4] |= (1 << (bit_nr & 0xf)); } } @@ -2175,7 +2230,6 @@ long ioaddr = net_dev->base_addr; int i = 0; u32 status = TxRCMP | RxRCMP; - u8 revision; outl(0, ioaddr + ier); outl(0, ioaddr + imr); @@ -2188,8 +2242,8 @@ status ^= (inl(isr + ioaddr) & status); } - pci_read_config_byte(sis_priv->pci_dev, PCI_CLASS_REVISION, &revision); - if( (revision >= SIS635A_900_REV) || (revision == SIS900B_900_REV) ) + if( (sis_priv->chipset_rev >= SIS635A_900_REV) || + (sis_priv->chipset_rev == SIS900B_900_REV) ) outl(PESEL | RND_CNT, ioaddr + cfg); else outl(PESEL, ioaddr + cfg); diff -Nru a/drivers/net/via-rhine.c b/drivers/net/via-rhine.c --- a/drivers/net/via-rhine.c 2005-03-08 14:29:45 -05:00 +++ b/drivers/net/via-rhine.c 2005-03-08 14:29:45 -05:00 @@ -1197,8 +1197,10 @@ dev->name, rp->pdev->irq); rc = alloc_ring(dev); - if (rc) + if (rc) { + free_irq(rp->pdev->irq, dev); return rc; + } alloc_rbufs(dev); alloc_tbufs(dev); rhine_chip_reset(dev); diff -Nru a/drivers/net/wireless/airport.c b/drivers/net/wireless/airport.c --- a/drivers/net/wireless/airport.c 2005-03-08 14:29:45 -05:00 +++ b/drivers/net/wireless/airport.c 2005-03-08 14:29:45 -05:00 @@ -28,7 +28,6 @@ #include #include #include -#include #include #include @@ -45,7 +44,7 @@ struct airport { struct macio_dev *mdev; - void *vaddr; + void __iomem *vaddr; int irq_requested; int ndev_registered; }; @@ -150,7 +149,7 @@ ssleep(1); macio_set_drvdata(mdev, NULL); - free_netdev(dev); + free_orinocodev(dev); return 0; } @@ -194,14 +193,14 @@ hermes_t *hw; if (macio_resource_count(mdev) < 1 || macio_irq_count(mdev) < 1) { - printk(KERN_ERR PFX "wrong interrupt/addresses in OF tree\n"); + printk(KERN_ERR PFX "Wrong interrupt/addresses in OF tree\n"); return -ENODEV; } /* Allocate space for private device-specific data */ dev = alloc_orinocodev(sizeof(*card), airport_hard_reset); if (! dev) { - printk(KERN_ERR PFX "can't allocate device datas\n"); + printk(KERN_ERR PFX "Cannot allocate network device\n"); return -ENODEV; } priv = netdev_priv(dev); @@ -212,7 +211,7 @@ if (macio_request_resource(mdev, 0, "airport")) { printk(KERN_ERR PFX "can't request IO resource !\n"); - free_netdev(dev); + free_orinocodev(dev); return -EBUSY; } @@ -224,16 +223,15 @@ /* Setup interrupts & base address */ dev->irq = macio_irq(mdev, 0); phys_addr = macio_resource_start(mdev, 0); /* Physical address */ - printk(KERN_DEBUG PFX "Airport at physical address %lx\n", phys_addr); + printk(KERN_DEBUG PFX "Physical address %lx\n", phys_addr); dev->base_addr = phys_addr; card->vaddr = ioremap(phys_addr, AIRPORT_IO_LEN); if (!card->vaddr) { - printk(PFX "ioremap() failed\n"); + printk(KERN_ERR PFX "ioremap() failed\n"); goto failed; } - hermes_struct_init(hw, (ulong)card->vaddr, - HERMES_MEM, HERMES_16BIT_REGSPACING); + hermes_struct_init(hw, card->vaddr, HERMES_16BIT_REGSPACING); /* Power up card */ pmac_call_feature(PMAC_FTR_AIRPORT_ENABLE, macio_get_of_node(mdev), 0, 1); @@ -242,7 +240,7 @@ /* Reset it before we get the interrupt */ hermes_init(hw); - if (request_irq(dev->irq, orinoco_interrupt, 0, "Airport", dev)) { + if (request_irq(dev->irq, orinoco_interrupt, 0, dev->name, dev)) { printk(KERN_ERR PFX "Couldn't get IRQ %d\n", dev->irq); goto failed; } @@ -253,7 +251,7 @@ printk(KERN_ERR PFX "register_netdev() failed\n"); goto failed; } - printk(KERN_DEBUG PFX "card registered for interface %s\n", dev->name); + printk(KERN_DEBUG PFX "Card registered for interface %s\n", dev->name); card->ndev_registered = 1; return 0; failed: diff -Nru a/drivers/net/wireless/hermes.c b/drivers/net/wireless/hermes.c --- a/drivers/net/wireless/hermes.c 2005-03-08 14:29:45 -05:00 +++ b/drivers/net/wireless/hermes.c 2005-03-08 14:29:45 -05:00 @@ -48,6 +48,7 @@ #include #include #include +#include #include #include "hermes.h" @@ -67,8 +68,7 @@ * Debugging helpers */ -#define IO_TYPE(hw) ((hw)->io_space ? "IO " : "MEM ") -#define DMSG(stuff...) do {printk(KERN_DEBUG "hermes @ %s0x%x: " , IO_TYPE(hw), hw->iobase); \ +#define DMSG(stuff...) do {printk(KERN_DEBUG "hermes @ %p: " , hw->iobase); \ printk(stuff);} while (0) #undef HERMES_DEBUG @@ -123,11 +123,9 @@ * Function definitions */ -void hermes_struct_init(hermes_t *hw, ulong address, - int io_space, int reg_spacing) +void hermes_struct_init(hermes_t *hw, void __iomem *address, int reg_spacing) { hw->iobase = address; - hw->io_space = io_space; hw->reg_spacing = reg_spacing; hw->inten = 0x0; @@ -200,9 +198,9 @@ } if (! (reg & HERMES_EV_CMD)) { - printk(KERN_ERR "hermes @ %s0x%lx: " + printk(KERN_ERR "hermes @ %p: " "Timeout waiting for card to reset (reg=0x%04x)!\n", - IO_TYPE(hw), hw->iobase, reg); + hw->iobase, reg); err = -ETIMEDOUT; goto out; } @@ -235,13 +233,16 @@ err = hermes_issue_cmd(hw, cmd, parm0); if (err) { if (! hermes_present(hw)) { - printk(KERN_WARNING "hermes @ %s0x%lx: " - "Card removed while issuing command.\n", - IO_TYPE(hw), hw->iobase); + if (net_ratelimit()) + printk(KERN_WARNING "hermes @ %p: " + "Card removed while issuing command " + "0x%04x.\n", hw->iobase, cmd); err = -ENODEV; } else - printk(KERN_ERR "hermes @ %s0x%lx: Error %d issuing command.\n", - IO_TYPE(hw), hw->iobase, err); + if (net_ratelimit()) + printk(KERN_ERR "hermes @ %p: " + "Error %d issuing command 0x%04x.\n", + hw->iobase, err, cmd); goto out; } @@ -254,17 +255,16 @@ } if (! hermes_present(hw)) { - printk(KERN_WARNING "hermes @ %s0x%lx: " - "Card removed while waiting for command completion.\n", - IO_TYPE(hw), hw->iobase); + printk(KERN_WARNING "hermes @ %p: Card removed " + "while waiting for command 0x%04x completion.\n", + hw->iobase, cmd); err = -ENODEV; goto out; } if (! (reg & HERMES_EV_CMD)) { - printk(KERN_ERR "hermes @ %s0x%lx: " - "Timeout waiting for command completion.\n", - IO_TYPE(hw), hw->iobase); + printk(KERN_ERR "hermes @ %p: Timeout waiting for " + "command 0x%04x completion.\n", hw->iobase, cmd); err = -ETIMEDOUT; goto out; } @@ -309,16 +309,16 @@ } if (! hermes_present(hw)) { - printk(KERN_WARNING "hermes @ %s0x%lx: " + printk(KERN_WARNING "hermes @ %p: " "Card removed waiting for frame allocation.\n", - IO_TYPE(hw), hw->iobase); + hw->iobase); return -ENODEV; } if (! (reg & HERMES_EV_ALLOC)) { - printk(KERN_ERR "hermes @ %s0x%lx: " + printk(KERN_ERR "hermes @ %p: " "Timeout waiting for frame allocation\n", - IO_TYPE(hw), hw->iobase); + hw->iobase); return -ETIMEDOUT; } @@ -383,12 +383,17 @@ reg = hermes_read_reg(hw, oreg); } - if (reg & HERMES_OFFSET_BUSY) { - return -ETIMEDOUT; - } + if (reg != offset) { + printk(KERN_ERR "hermes @ %p: BAP%d offset %s: " + "reg=0x%x id=0x%x offset=0x%x\n", hw->iobase, bap, + (reg & HERMES_OFFSET_BUSY) ? "timeout" : "error", + reg, id, offset); + + if (reg & HERMES_OFFSET_BUSY) { + return -ETIMEDOUT; + } - if (reg & HERMES_OFFSET_ERR) { - return -EIO; + return -EIO; /* error or wrong offset */ } return 0; @@ -476,7 +481,7 @@ rlength = hermes_read_reg(hw, dreg); if (! rlength) - return -ENOENT; + return -ENODATA; rtype = hermes_read_reg(hw, dreg); @@ -484,14 +489,13 @@ *length = rlength; if (rtype != rid) - printk(KERN_WARNING "hermes @ %s0x%lx: " - "hermes_read_ltv(): rid (0x%04x) does not match type (0x%04x)\n", - IO_TYPE(hw), hw->iobase, rid, rtype); + printk(KERN_WARNING "hermes @ %p: %s(): " + "rid (0x%04x) does not match type (0x%04x)\n", + hw->iobase, __FUNCTION__, rid, rtype); if (HERMES_RECLEN_TO_BYTES(rlength) > bufsize) - printk(KERN_WARNING "hermes @ %s0x%lx: " + printk(KERN_WARNING "hermes @ %p: " "Truncating LTV record from %d to %d bytes. " - "(rid=0x%04x, len=0x%04x)\n", - IO_TYPE(hw), hw->iobase, + "(rid=0x%04x, len=0x%04x)\n", hw->iobase, HERMES_RECLEN_TO_BYTES(rlength), bufsize, rid, rlength); nwords = min((unsigned)rlength - 1, bufsize / 2); diff -Nru a/drivers/net/wireless/hermes.h b/drivers/net/wireless/hermes.h --- a/drivers/net/wireless/hermes.h 2005-03-08 14:29:45 -05:00 +++ b/drivers/net/wireless/hermes.h 2005-03-08 14:29:45 -05:00 @@ -340,14 +340,11 @@ #ifdef __KERNEL__ /* Timeouts */ -#define HERMES_BAP_BUSY_TIMEOUT (500) /* In iterations of ~1us */ +#define HERMES_BAP_BUSY_TIMEOUT (10000) /* In iterations of ~1us */ /* Basic control structure */ typedef struct hermes { - unsigned long iobase; - int io_space; /* 1 if we IO-mapped IO, 0 for memory-mapped IO? */ -#define HERMES_IO 1 -#define HERMES_MEM 0 + void __iomem *iobase; int reg_spacing; #define HERMES_16BIT_REGSPACING 0 #define HERMES_32BIT_REGSPACING 1 @@ -362,21 +359,15 @@ } hermes_t; /* Register access convenience macros */ -#define hermes_read_reg(hw, off) ((hw)->io_space ? \ - inw((hw)->iobase + ( (off) << (hw)->reg_spacing )) : \ - readw((hw)->iobase + ( (off) << (hw)->reg_spacing ))) -#define hermes_write_reg(hw, off, val) do { \ - if ((hw)->io_space) \ - outw_p((val), (hw)->iobase + ((off) << (hw)->reg_spacing)); \ - else \ - writew((val), (hw)->iobase + ((off) << (hw)->reg_spacing)); \ - } while (0) +#define hermes_read_reg(hw, off) \ + (ioread16((hw)->iobase + ( (off) << (hw)->reg_spacing ))) +#define hermes_write_reg(hw, off, val) \ + (iowrite16((val), (hw)->iobase + ((off) << (hw)->reg_spacing))) #define hermes_read_regn(hw, name) hermes_read_reg((hw), HERMES_##name) #define hermes_write_regn(hw, name, val) hermes_write_reg((hw), HERMES_##name, (val)) /* Function prototypes */ -void hermes_struct_init(hermes_t *hw, ulong address, int io_space, - int reg_spacing); +void hermes_struct_init(hermes_t *hw, void __iomem *address, int reg_spacing); int hermes_init(hermes_t *hw); int hermes_docmd_wait(hermes_t *hw, u16 cmd, u16 parm0, struct hermes_response *resp); @@ -430,41 +421,13 @@ static inline void hermes_read_words(struct hermes *hw, int off, void *buf, unsigned count) { off = off << hw->reg_spacing; - - if (hw->io_space) { - insw(hw->iobase + off, buf, count); - } else { - unsigned i; - u16 *p; - - /* This needs to *not* byteswap (like insw()) but - * readw() does byteswap hence the conversion. I hope - * gcc is smart enough to fold away the two swaps on - * big-endian platforms. */ - for (i = 0, p = buf; i < count; i++) { - *p++ = cpu_to_le16(readw(hw->iobase + off)); - } - } + ioread16_rep(hw->iobase + off, buf, count); } static inline void hermes_write_words(struct hermes *hw, int off, const void *buf, unsigned count) { off = off << hw->reg_spacing; - - if (hw->io_space) { - outsw(hw->iobase + off, buf, count); - } else { - unsigned i; - const u16 *p; - - /* This needs to *not* byteswap (like outsw()) but - * writew() does byteswap hence the conversion. I - * hope gcc is smart enough to fold away the two swaps - * on big-endian platforms. */ - for (i = 0, p = buf; i < count; i++) { - writew(le16_to_cpu(*p++), hw->iobase + off); - } - } + iowrite16_rep(hw->iobase + off, buf, count); } static inline void hermes_clear_words(struct hermes *hw, int off, unsigned count) @@ -473,13 +436,8 @@ off = off << hw->reg_spacing; - if (hw->io_space) { - for (i = 0; i < count; i++) - outw(0, hw->iobase + off); - } else { - for (i = 0; i < count; i++) - writew(0, hw->iobase + off); - } + for (i = 0; i < count; i++) + iowrite16(0, hw->iobase + off); } #define HERMES_READ_RECORD(hw, bap, rid, buf) \ diff -Nru a/drivers/net/wireless/orinoco.c b/drivers/net/wireless/orinoco.c --- a/drivers/net/wireless/orinoco.c 2005-03-08 14:29:45 -05:00 +++ b/drivers/net/wireless/orinoco.c 2005-03-08 14:29:45 -05:00 @@ -393,6 +393,29 @@ * in the rx_dropped statistics. * o Provided a module parameter to suppress linkstatus messages. * + * v0.13e -> v0.14alpha1 - 30 Sep 2003 - David Gibson + * o Replaced priv->connected logic with netif_carrier_on/off() + * calls. + * o Remove has_ibss_any and never set the CREATEIBSS RID when + * the ESSID is empty. Too many firmwares break if we do. + * o 2.6 merges: Replace pdev->slot_name with pci_name(), remove + * __devinitdata from PCI ID tables, use free_netdev(). + * o Enabled shared-key authentication for Agere firmware (from + * Robert J. Moore + * o Move netif_wake_queue() (back) to the Tx completion from the + * ALLOC event. This seems to prevent/mitigate the rolling + * error -110 problems at least on some Intersil firmwares. + * Theoretically reduces performance, but I can't measure it. + * Patch from Andrew Tridgell + * + * v0.14alpha1 -> v0.14alpha2 - 20 Oct 2003 - David Gibson + * o Correctly turn off shared-key authentication when requested + * (bugfix from Robert J. Moore). + * o Correct airport sleep interfaces for current 2.6 kernels. + * o Add code for key change without disabling/enabling the MAC + * port. This is supposed to allow 802.1x to work sanely, but + * doesn't seem to yet. + * * TODO * o New wireless extensions API (patch from Moustafa * Youssef, updated by Jim Carter and Pavel Roskin). @@ -461,12 +484,14 @@ /* Level of debugging. Used in the macros in orinoco.h */ #ifdef ORINOCO_DEBUG int orinoco_debug = ORINOCO_DEBUG; -module_param(orinoco_debug, int, 0); +module_param(orinoco_debug, int, 0644); +MODULE_PARM_DESC(orinoco_debug, "Debug level"); EXPORT_SYMBOL(orinoco_debug); #endif static int suppress_linkstatus; /* = 0 */ -module_param(suppress_linkstatus, bool, 0); +module_param(suppress_linkstatus, bool, 0644); +MODULE_PARM_DESC(suppress_linkstatus, "Don't log link status changes"); /********************************************************************/ /* Compile time configuration and compatibility stuff */ @@ -784,7 +809,7 @@ return 1; } - if (! priv->connected) { + if (! netif_carrier_ok(dev)) { /* Oops, the firmware hasn't established a connection, silently drop the packet (this seems to be the safest approach). */ @@ -805,8 +830,9 @@ desc.tx_control = cpu_to_le16(HERMES_TXCTRL_TX_OK | HERMES_TXCTRL_TX_EX); err = hermes_bap_pwrite(hw, USER_BAP, &desc, sizeof(desc), txfid, 0); if (err) { - printk(KERN_ERR "%s: Error %d writing Tx descriptor to BAP\n", - dev->name, err); + if (net_ratelimit()) + printk(KERN_ERR "%s: Error %d writing Tx descriptor " + "to BAP\n", dev->name, err); stats->tx_errors++; goto fail; } @@ -836,8 +862,9 @@ err = hermes_bap_pwrite(hw, USER_BAP, &hdr, sizeof(hdr), txfid, HERMES_802_3_OFFSET); if (err) { - printk(KERN_ERR "%s: Error %d writing packet header to BAP\n", - dev->name, err); + if (net_ratelimit()) + printk(KERN_ERR "%s: Error %d writing packet " + "header to BAP\n", dev->name, err); stats->tx_errors++; goto fail; } @@ -897,8 +924,6 @@ printk(KERN_WARNING "%s: Allocate event on unexpected fid (%04X)\n", dev->name, fid); return; - } else { - netif_wake_queue(dev); } hermes_write_regn(hw, ALLOCFID, DUMMY_FID); @@ -911,6 +936,8 @@ stats->tx_packets++; + netif_wake_queue(dev); + hermes_write_regn(hw, TXCOMPLFID, DUMMY_FID); } @@ -937,6 +964,7 @@ stats->tx_errors++; + netif_wake_queue(dev); hermes_write_regn(hw, TXCOMPLFID, DUMMY_FID); } @@ -962,15 +990,17 @@ /* Does the frame have a SNAP header indicating it should be * de-encapsulated to Ethernet-II? */ -static inline int is_ethersnap(struct header_struct *hdr) +static inline int is_ethersnap(void *_hdr) { + u8 *hdr = _hdr; + /* We de-encapsulate all packets which, a) have SNAP headers * (i.e. SSAP=DSAP=0xaa and CTRL=0x3 in the 802.2 LLC header * and where b) the OUI of the SNAP header is 00:00:00 or * 00:00:f8 - we need both because different APs appear to use * different OUIs for some reason */ - return (memcmp(&hdr->dsap, &encaps_hdr, 5) == 0) - && ( (hdr->oui[2] == 0x00) || (hdr->oui[2] == 0xf8) ); + return (memcmp(hdr, &encaps_hdr, 5) == 0) + && ( (hdr[5] == 0x00) || (hdr[5] == 0xf8) ); } static inline void orinoco_spy_gather(struct net_device *dev, u_char *mac, @@ -1269,6 +1299,7 @@ case HERMES_INQ_LINKSTATUS: { struct hermes_linkstatus linkstatus; u16 newstatus; + int connected; if (len != sizeof(linkstatus)) { printk(KERN_WARNING "%s: Unexpected size for linkstatus frame (%d bytes)\n", @@ -1280,15 +1311,14 @@ len / 2); newstatus = le16_to_cpu(linkstatus.linkstatus); - if ( (newstatus == HERMES_LINKSTATUS_CONNECTED) - || (newstatus == HERMES_LINKSTATUS_AP_CHANGE) - || (newstatus == HERMES_LINKSTATUS_AP_IN_RANGE) ) - priv->connected = 1; - else if ( (newstatus == HERMES_LINKSTATUS_NOT_CONNECTED) - || (newstatus == HERMES_LINKSTATUS_DISCONNECTED) - || (newstatus == HERMES_LINKSTATUS_AP_OUT_OF_RANGE) - || (newstatus == HERMES_LINKSTATUS_ASSOC_FAILED) ) - priv->connected = 0; + connected = (newstatus == HERMES_LINKSTATUS_CONNECTED) + || (newstatus == HERMES_LINKSTATUS_AP_CHANGE) + || (newstatus == HERMES_LINKSTATUS_AP_IN_RANGE); + + if (connected) + netif_carrier_on(dev); + else + netif_carrier_off(dev); if (newstatus != priv->last_linkstatus) print_linkstatus(dev, newstatus); @@ -1297,8 +1327,8 @@ } break; default: - printk(KERN_DEBUG "%s: Unknown information frame received " - "(type %04x).\n", dev->name, type); + printk(KERN_DEBUG "%s: Unknown information frame received: " + "type 0x%04x, length %d\n", dev->name, type, len); /* We don't actually do anything about it */ break; } @@ -1307,7 +1337,7 @@ static void __orinoco_ev_infdrop(struct net_device *dev, hermes_t *hw) { if (net_ratelimit()) - printk(KERN_WARNING "%s: Information frame lost.\n", dev->name); + printk(KERN_DEBUG "%s: Information frame lost.\n", dev->name); } /********************************************************************/ @@ -1366,8 +1396,8 @@ } /* firmware will have to reassociate */ + netif_carrier_off(dev); priv->last_linkstatus = 0xffff; - priv->connected = 0; return 0; } @@ -1430,55 +1460,46 @@ return err; } -static int __orinoco_hw_setup_wep(struct orinoco_private *priv) +/* Change the WEP keys and/or the current keys. Can be called + * either from __orinoco_hw_setup_wep() or directly from + * orinoco_ioctl_setiwencode(). In the later case the association + * with the AP is not broken (if the firmware can handle it), + * which is needed for 802.1x implementations. */ +static int __orinoco_hw_setup_wepkeys(struct orinoco_private *priv) { hermes_t *hw = &priv->hw; int err = 0; - int master_wep_flag; - int auth_flag; switch (priv->firmware_type) { - case FIRMWARE_TYPE_AGERE: /* Agere style WEP */ - if (priv->wep_on) { - err = hermes_write_wordrec(hw, USER_BAP, - HERMES_RID_CNFTXKEY_AGERE, - priv->tx_key); - if (err) - return err; - - err = HERMES_WRITE_RECORD(hw, USER_BAP, - HERMES_RID_CNFWEPKEYS_AGERE, - &priv->keys); - if (err) - return err; - } + case FIRMWARE_TYPE_AGERE: + err = HERMES_WRITE_RECORD(hw, USER_BAP, + HERMES_RID_CNFWEPKEYS_AGERE, + &priv->keys); + if (err) + return err; err = hermes_write_wordrec(hw, USER_BAP, - HERMES_RID_CNFWEPENABLED_AGERE, - priv->wep_on); + HERMES_RID_CNFTXKEY_AGERE, + priv->tx_key); if (err) return err; break; - - case FIRMWARE_TYPE_INTERSIL: /* Intersil style WEP */ - case FIRMWARE_TYPE_SYMBOL: /* Symbol style WEP */ - master_wep_flag = 0; /* Off */ - if (priv->wep_on) { + case FIRMWARE_TYPE_INTERSIL: + case FIRMWARE_TYPE_SYMBOL: + { int keylen; int i; - /* Fudge around firmware weirdness */ + /* Force uniform key length to work around firmware bugs */ keylen = le16_to_cpu(priv->keys[priv->tx_key].len); + if (keylen > LARGE_KEY_SIZE) { + printk(KERN_ERR "%s: BUG: Key %d has oversize length %d.\n", + priv->ndev->name, priv->tx_key, keylen); + return -E2BIG; + } + /* Write all 4 keys */ for(i = 0; i < ORINOCO_MAX_KEYS; i++) { -/* int keylen = le16_to_cpu(priv->keys[i].len); */ - - if (keylen > LARGE_KEY_SIZE) { - printk(KERN_ERR "%s: BUG: Key %d has oversize length %d.\n", - priv->ndev->name, i, keylen); - return -E2BIG; - } - err = hermes_write_ltv(hw, USER_BAP, HERMES_RID_CNFDEFAULTKEY0 + i, HERMES_BYTES_TO_RECLEN(keylen), @@ -1493,27 +1514,63 @@ priv->tx_key); if (err) return err; - - if (priv->wep_restrict) { - auth_flag = 2; - master_wep_flag = 3; - } else { - /* Authentication is where Intersil and Symbol - * firmware differ... */ - auth_flag = 1; - if (priv->firmware_type == FIRMWARE_TYPE_SYMBOL) - master_wep_flag = 3; /* Symbol */ - else - master_wep_flag = 1; /* Intersil */ - } + } + break; + } + return 0; +} + +static int __orinoco_hw_setup_wep(struct orinoco_private *priv) +{ + hermes_t *hw = &priv->hw; + int err = 0; + int master_wep_flag; + int auth_flag; + + if (priv->wep_on) + __orinoco_hw_setup_wepkeys(priv); + + if (priv->wep_restrict) + auth_flag = HERMES_AUTH_SHARED_KEY; + else + auth_flag = HERMES_AUTH_OPEN; + + switch (priv->firmware_type) { + case FIRMWARE_TYPE_AGERE: /* Agere style WEP */ + if (priv->wep_on) { + /* Enable the shared-key authentication. */ + err = hermes_write_wordrec(hw, USER_BAP, + HERMES_RID_CNFAUTHENTICATION_AGERE, + auth_flag); + } + err = hermes_write_wordrec(hw, USER_BAP, + HERMES_RID_CNFWEPENABLED_AGERE, + priv->wep_on); + if (err) + return err; + break; + + case FIRMWARE_TYPE_INTERSIL: /* Intersil style WEP */ + case FIRMWARE_TYPE_SYMBOL: /* Symbol style WEP */ + if (priv->wep_on) { + if (priv->wep_restrict || + (priv->firmware_type == FIRMWARE_TYPE_SYMBOL)) + master_wep_flag = HERMES_WEP_PRIVACY_INVOKED | + HERMES_WEP_EXCL_UNENCRYPTED; + else + master_wep_flag = HERMES_WEP_PRIVACY_INVOKED; err = hermes_write_wordrec(hw, USER_BAP, HERMES_RID_CNFAUTHENTICATION, auth_flag); if (err) return err; - } + } else + master_wep_flag = 0; + + if (priv->iw_mode == IW_MODE_MONITOR) + master_wep_flag |= HERMES_WEP_HOST_DECRYPT; /* Master WEP setting : on/off */ err = hermes_write_wordrec(hw, USER_BAP, @@ -1523,13 +1580,6 @@ return err; break; - - default: - if (priv->wep_on) { - printk(KERN_ERR "%s: WEP enabled, although not supported!\n", - priv->ndev->name); - return -EINVAL; - } } return 0; @@ -1574,21 +1624,26 @@ } if (priv->has_ibss) { - err = hermes_write_wordrec(hw, USER_BAP, - HERMES_RID_CNFCREATEIBSS, - priv->createibss); - if (err) { - printk(KERN_ERR "%s: Error %d setting CREATEIBSS\n", dev->name, err); - return err; - } + u16 createibss; - if ((strlen(priv->desired_essid) == 0) && (priv->createibss) - && (!priv->has_ibss_any)) { + if ((strlen(priv->desired_essid) == 0) && (priv->createibss)) { printk(KERN_WARNING "%s: This firmware requires an " "ESSID in IBSS-Ad-Hoc mode.\n", dev->name); /* With wvlan_cs, in this case, we would crash. * hopefully, this driver will behave better... * Jean II */ + createibss = 0; + } else { + createibss = priv->createibss; + } + + err = hermes_write_wordrec(hw, USER_BAP, + HERMES_RID_CNFCREATEIBSS, + createibss); + if (err) { + printk(KERN_ERR "%s: Error %d setting CREATEIBSS\n", + dev->name, err); + return err; } } @@ -1785,7 +1840,8 @@ } if (p) - printk(KERN_WARNING "Multicast list is longer than mc_count\n"); + printk(KERN_WARNING "%s: Multicast list is " + "longer than mc_count\n", dev->name); err = hermes_write_ltv(hw, USER_BAP, HERMES_RID_CNFGROUPADDRESSES, HERMES_BYTES_TO_RECLEN(priv->mc_count * ETH_ALEN), @@ -1878,7 +1934,7 @@ priv->hw_unavailable++; priv->last_linkstatus = 0xffff; /* firmware will have to reassociate */ - priv->connected = 0; + netif_carrier_off(dev); orinoco_unlock(priv, &flags); @@ -2014,51 +2070,81 @@ /* Initialization */ /********************************************************************/ -struct sta_id { +struct comp_id { u16 id, variant, major, minor; } __attribute__ ((packed)); -static int determine_firmware_type(struct net_device *dev, struct sta_id *sta_id) +static inline fwtype_t determine_firmware_type(struct comp_id *nic_id) { - /* FIXME: this is fundamentally broken */ - unsigned int firmver = ((u32)sta_id->major << 16) | sta_id->minor; - - if (sta_id->variant == 1) + if (nic_id->id < 0x8000) return FIRMWARE_TYPE_AGERE; - else if ((sta_id->variant == 2) && - ((firmver == 0x10001) || (firmver == 0x20001))) + else if (nic_id->id == 0x8000 && nic_id->major == 0) return FIRMWARE_TYPE_SYMBOL; else return FIRMWARE_TYPE_INTERSIL; } -static void determine_firmware(struct net_device *dev) +/* Set priv->firmware type, determine firmware properties */ +static int determine_firmware(struct net_device *dev) { struct orinoco_private *priv = netdev_priv(dev); hermes_t *hw = &priv->hw; int err; - struct sta_id sta_id; + struct comp_id nic_id, sta_id; unsigned int firmver; char tmp[SYMBOL_MAX_VER_LEN+1]; + /* Get the hardware version */ + err = HERMES_READ_RECORD(hw, USER_BAP, HERMES_RID_NICID, &nic_id); + if (err) { + printk(KERN_ERR "%s: Cannot read hardware identity: error %d\n", + dev->name, err); + return err; + } + + le16_to_cpus(&nic_id.id); + le16_to_cpus(&nic_id.variant); + le16_to_cpus(&nic_id.major); + le16_to_cpus(&nic_id.minor); + printk(KERN_DEBUG "%s: Hardware identity %04x:%04x:%04x:%04x\n", + dev->name, nic_id.id, nic_id.variant, + nic_id.major, nic_id.minor); + + priv->firmware_type = determine_firmware_type(&nic_id); + /* Get the firmware version */ err = HERMES_READ_RECORD(hw, USER_BAP, HERMES_RID_STAID, &sta_id); if (err) { - printk(KERN_WARNING "%s: Error %d reading firmware info. Wildly guessing capabilities...\n", + printk(KERN_ERR "%s: Cannot read station identity: error %d\n", dev->name, err); - memset(&sta_id, 0, sizeof(sta_id)); + return err; } le16_to_cpus(&sta_id.id); le16_to_cpus(&sta_id.variant); le16_to_cpus(&sta_id.major); le16_to_cpus(&sta_id.minor); - printk(KERN_DEBUG "%s: Station identity %04x:%04x:%04x:%04x\n", + printk(KERN_DEBUG "%s: Station identity %04x:%04x:%04x:%04x\n", dev->name, sta_id.id, sta_id.variant, sta_id.major, sta_id.minor); - if (! priv->firmware_type) - priv->firmware_type = determine_firmware_type(dev, &sta_id); + switch (sta_id.id) { + case 0x15: + printk(KERN_ERR "%s: Primary firmware is active\n", + dev->name); + return -ENODEV; + case 0x14b: + printk(KERN_ERR "%s: Tertiary firmware is active\n", + dev->name); + return -ENODEV; + case 0x1f: /* Intersil, Agere, Symbol Spectrum24 */ + case 0x21: /* Symbol Spectrum24 Trilogy */ + break; + default: + printk(KERN_NOTICE "%s: Unknown station ID, please report\n", + dev->name); + break; + } /* Default capabilities */ priv->has_sensitivity = 1; @@ -2066,7 +2152,6 @@ priv->has_preamble = 0; priv->has_port3 = 1; priv->has_ibss = 1; - priv->has_ibss_any = 0; priv->has_wep = 0; priv->has_big_wep = 0; @@ -2075,14 +2160,12 @@ case FIRMWARE_TYPE_AGERE: /* Lucent Wavelan IEEE, Lucent Orinoco, Cabletron RoamAbout, ELSA, Melco, HP, IBM, Dell 1150, Compaq 110/210 */ - printk(KERN_DEBUG "%s: Looks like a Lucent/Agere firmware " - "version %d.%02d\n", dev->name, - sta_id.major, sta_id.minor); + snprintf(priv->fw_name, sizeof(priv->fw_name) - 1, + "Lucent/Agere %d.%02d", sta_id.major, sta_id.minor); firmver = ((unsigned long)sta_id.major << 16) | sta_id.minor; priv->has_ibss = (firmver >= 0x60006); - priv->has_ibss_any = (firmver >= 0x60010); priv->has_wep = (firmver >= 0x40020); priv->has_big_wep = 1; /* FIXME: this is wrong - how do we tell Gold cards from the others? */ @@ -2121,14 +2204,15 @@ tmp[SYMBOL_MAX_VER_LEN] = '\0'; } - printk(KERN_DEBUG "%s: Looks like a Symbol firmware " - "version [%s] (parsing to %X)\n", dev->name, - tmp, firmver); + snprintf(priv->fw_name, sizeof(priv->fw_name) - 1, + "Symbol %s", tmp); priv->has_ibss = (firmver >= 0x20000); priv->has_wep = (firmver >= 0x15012); priv->has_big_wep = (firmver >= 0x20000); - priv->has_pm = (firmver >= 0x20000) && (firmver < 0x22000); + priv->has_pm = (firmver >= 0x20000 && firmver < 0x22000) || + (firmver >= 0x29000 && firmver < 0x30000) || + firmver >= 0x31000; priv->has_preamble = (firmver >= 0x20000); priv->ibss_port = 4; /* Tested with Intel firmware : 0x20015 => Jean II */ @@ -2140,9 +2224,9 @@ * different and less well tested */ /* D-Link MAC : 00:40:05:* */ /* Addtron MAC : 00:90:D1:* */ - printk(KERN_DEBUG "%s: Looks like an Intersil firmware " - "version %d.%d.%d\n", dev->name, - sta_id.major, sta_id.minor, sta_id.variant); + snprintf(priv->fw_name, sizeof(priv->fw_name) - 1, + "Intersil %d.%d.%d", sta_id.major, sta_id.minor, + sta_id.variant); firmver = ((unsigned long)sta_id.major << 16) | ((unsigned long)sta_id.minor << 8) | sta_id.variant; @@ -2160,9 +2244,11 @@ priv->ibss_port = 1; } break; - default: - break; } + printk(KERN_DEBUG "%s: Firmware determined as %s\n", dev->name, + priv->fw_name); + + return 0; } static int orinoco_init(struct net_device *dev) @@ -2188,7 +2274,12 @@ goto out; } - determine_firmware(dev); + err = determine_firmware(dev); + if (err != 0) { + printk(KERN_ERR "%s: Incompatible firmware, aborting\n", + dev->name); + goto out; + } if (priv->has_port3) printk(KERN_DEBUG "%s: Ad-hoc demo mode supported\n", dev->name); @@ -2388,13 +2479,18 @@ * hardware */ INIT_WORK(&priv->reset_work, (void (*)(void *))orinoco_reset, dev); + netif_carrier_off(dev); priv->last_linkstatus = 0xffff; - priv->connected = 0; return dev; } +void free_orinocodev(struct net_device *dev) +{ + free_netdev(dev); +} + /********************************************************************/ /* Wireless extensions */ /********************************************************************/ @@ -2686,11 +2782,17 @@ int err = 0; char keybuf[ORINOCO_MAX_KEY_SIZE]; unsigned long flags; - + + if (! priv->has_wep) + return -EOPNOTSUPP; + if (erq->pointer) { - /* We actually have a key to set */ - if ( (erq->length < SMALL_KEY_SIZE) || (erq->length > ORINOCO_MAX_KEY_SIZE) ) - return -EINVAL; + /* We actually have a key to set - check its length */ + if (erq->length > LARGE_KEY_SIZE) + return -E2BIG; + + if ( (erq->length > SMALL_KEY_SIZE) && !priv->has_big_wep ) + return -E2BIG; if (copy_from_user(keybuf, erq->pointer, erq->length)) return -EFAULT; @@ -2698,19 +2800,8 @@ if (orinoco_lock(priv, &flags) != 0) return -EBUSY; - + if (erq->pointer) { - if (erq->length > ORINOCO_MAX_KEY_SIZE) { - err = -E2BIG; - goto out; - } - - if ( (erq->length > LARGE_KEY_SIZE) - || ( ! priv->has_big_wep && (erq->length > SMALL_KEY_SIZE)) ) { - err = -EINVAL; - goto out; - } - if ((index < 0) || (index >= ORINOCO_MAX_KEYS)) index = priv->tx_key; @@ -2721,7 +2812,7 @@ xlen = SMALL_KEY_SIZE; } else xlen = 0; - + /* Switch on WEP if off */ if ((!enable) && (xlen > 0)) { setindex = index; @@ -2745,10 +2836,9 @@ setindex = index; } } - + if (erq->flags & IW_ENCODE_DISABLED) enable = 0; - /* Only for Prism2 & Symbol cards (so far) - Jean II */ if (erq->flags & IW_ENCODE_OPEN) restricted = 0; if (erq->flags & IW_ENCODE_RESTRICTED) @@ -2761,6 +2851,15 @@ memcpy(priv->keys[index].data, keybuf, erq->length); } priv->tx_key = setindex; + + /* Try fast key change if connected and only keys are changed */ + if (priv->wep_on && enable && (priv->wep_restrict == restricted) && + netif_carrier_ok(dev)) { + err = __orinoco_hw_setup_wepkeys(priv); + /* No need to commit if successful */ + goto out; + } + priv->wep_on = enable; priv->wep_restrict = restricted; @@ -2778,6 +2877,9 @@ char keybuf[ORINOCO_MAX_KEY_SIZE]; unsigned long flags; + if (! priv->has_wep) + return -EOPNOTSUPP; + if (orinoco_lock(priv, &flags) != 0) return -EBUSY; @@ -2788,23 +2890,18 @@ if (! priv->wep_on) erq->flags |= IW_ENCODE_DISABLED; erq->flags |= index + 1; - - /* Only for symbol cards - Jean II */ - if (priv->firmware_type != FIRMWARE_TYPE_AGERE) { - if(priv->wep_restrict) - erq->flags |= IW_ENCODE_RESTRICTED; - else - erq->flags |= IW_ENCODE_OPEN; - } + + if (priv->wep_restrict) + erq->flags |= IW_ENCODE_RESTRICTED; + else + erq->flags |= IW_ENCODE_OPEN; xlen = le16_to_cpu(priv->keys[index].len); erq->length = xlen; - if (erq->pointer) { - memcpy(keybuf, priv->keys[index].data, ORINOCO_MAX_KEY_SIZE); - } - + memcpy(keybuf, priv->keys[index].data, ORINOCO_MAX_KEY_SIZE); + orinoco_unlock(priv, &flags); if (erq->pointer) { @@ -3045,8 +3142,9 @@ priv->mwo_robust = 0; else { if (frq->fixed) - printk(KERN_WARNING "%s: Fixed fragmentation not \ -supported on this firmware. Using MWO robust instead.\n", dev->name); + printk(KERN_WARNING "%s: Fixed fragmentation is " + "not supported on this firmware. " + "Using MWO robust instead.\n", dev->name); priv->mwo_robust = 1; } } else { @@ -3518,7 +3616,7 @@ } /* Copy stats */ /* In theory, we should disable irqs while copying the stats - * because the rx path migh update it in the middle... + * because the rx path might update it in the middle... * Bah, who care ? - Jean II */ memcpy(&spy_stat, priv->spy_stat, sizeof(struct iw_quality) * IW_MAX_SPY); @@ -3609,22 +3707,12 @@ break; case SIOCSIWENCODE: - if (! priv->has_wep) { - err = -EOPNOTSUPP; - break; - } - err = orinoco_ioctl_setiwencode(dev, &wrq->u.encoding); if (! err) changed = 1; break; case SIOCGIWENCODE: - if (! priv->has_wep) { - err = -EOPNOTSUPP; - break; - } - if (! capable(CAP_NET_ADMIN)) { err = -EPERM; break; @@ -4127,6 +4215,7 @@ /********************************************************************/ EXPORT_SYMBOL(alloc_orinocodev); +EXPORT_SYMBOL(free_orinocodev); EXPORT_SYMBOL(__orinoco_up); EXPORT_SYMBOL(__orinoco_down); diff -Nru a/drivers/net/wireless/orinoco.h b/drivers/net/wireless/orinoco.h --- a/drivers/net/wireless/orinoco.h 2005-03-08 14:29:45 -05:00 +++ b/drivers/net/wireless/orinoco.h 2005-03-08 14:29:45 -05:00 @@ -7,7 +7,7 @@ #ifndef _ORINOCO_H #define _ORINOCO_H -#define DRIVER_VERSION "0.13e" +#define DRIVER_VERSION "0.14alpha2" #include #include @@ -30,6 +30,12 @@ char data[ORINOCO_MAX_KEY_SIZE]; } __attribute__ ((packed)); +typedef enum { + FIRMWARE_TYPE_AGERE, + FIRMWARE_TYPE_INTERSIL, + FIRMWARE_TYPE_SYMBOL +} fwtype_t; + struct orinoco_private { void *card; /* Pointer to card dependent structure */ int (*hard_reset)(struct orinoco_private *); @@ -42,7 +48,6 @@ /* driver state */ int open; u16 last_linkstatus; - int connected; /* Net device stuff */ struct net_device *ndev; @@ -54,19 +59,22 @@ u16 txfid; /* Capabilities of the hardware/firmware */ - int firmware_type; -#define FIRMWARE_TYPE_AGERE 1 -#define FIRMWARE_TYPE_INTERSIL 2 -#define FIRMWARE_TYPE_SYMBOL 3 - int has_ibss, has_port3, has_ibss_any, ibss_port; - int has_wep, has_big_wep; - int has_mwo; - int has_pm; - int has_preamble; - int has_sensitivity; + fwtype_t firmware_type; + char fw_name[32]; + int ibss_port; int nicbuf_size; u16 channel_mask; - int broken_disableport; + + /* Boolean capabilities */ + unsigned int has_ibss:1; + unsigned int has_port3:1; + unsigned int has_wep:1; + unsigned int has_big_wep:1; + unsigned int has_mwo:1; + unsigned int has_pm:1; + unsigned int has_preamble:1; + unsigned int has_sensitivity:1; + unsigned int broken_disableport:1; /* Configuration paramaters */ u32 iw_mode; @@ -108,6 +116,7 @@ extern struct net_device *alloc_orinocodev(int sizeof_card, int (*hard_reset)(struct orinoco_private *)); +extern void free_orinocodev(struct net_device *dev); extern int __orinoco_up(struct net_device *dev); extern int __orinoco_down(struct net_device *dev); extern int orinoco_stop(struct net_device *dev); @@ -127,7 +136,7 @@ { spin_lock_irqsave(&priv->lock, *flags); if (priv->hw_unavailable) { - printk(KERN_DEBUG "orinoco_lock() called with hw_unavailable (dev=%p)\n", + DEBUG(1, "orinoco_lock() called with hw_unavailable (dev=%p)\n", priv->ndev); spin_unlock_irqrestore(&priv->lock, *flags); return -EBUSY; diff -Nru a/drivers/net/wireless/orinoco_cs.c b/drivers/net/wireless/orinoco_cs.c --- a/drivers/net/wireless/orinoco_cs.c 2005-03-08 14:29:45 -05:00 +++ b/drivers/net/wireless/orinoco_cs.c 2005-03-08 14:29:45 -05:00 @@ -57,8 +57,8 @@ /* Some D-Link cards have buggy CIS. They do work at 5v properly, but * don't have any CIS entry for it. This workaround it... */ static int ignore_cis_vcc; /* = 0 */ - module_param(ignore_cis_vcc, int, 0); +MODULE_PARM_DESC(ignore_cis_vcc, "Allow voltage mismatch between card and socket"); /********************************************************************/ /* Magic constants */ @@ -128,6 +128,7 @@ if (err) return err; + msleep(100); clear_bit(0, &card->hard_reset_in_progress); return 0; @@ -166,9 +167,10 @@ link->priv = dev; /* Interrupt setup */ - link->irq.Attributes = IRQ_TYPE_EXCLUSIVE; + link->irq.Attributes = IRQ_TYPE_EXCLUSIVE | IRQ_HANDLE_PRESENT; link->irq.IRQInfo1 = IRQ_LEVEL_ID; - link->irq.Handler = NULL; + link->irq.Handler = orinoco_interrupt; + link->irq.Instance = dev; /* General socket configuration defaults can go here. In this * client, we assume very little, and rely on the CIS for @@ -235,7 +237,7 @@ dev); unregister_netdev(dev); } - free_netdev(dev); + free_orinocodev(dev); } /* orinoco_cs_detach */ /* @@ -262,6 +264,7 @@ cisinfo_t info; tuple_t tuple; cisparse_t parse; + void __iomem *mem; CS_CHECK(ValidateCIS, pcmcia_validate_cis(handle, &info)); @@ -308,8 +311,8 @@ cistpl_cftable_entry_t *cfg = &(parse.cftable_entry); cistpl_cftable_entry_t dflt = { .index = 0 }; - if (pcmcia_get_tuple_data(handle, &tuple) != 0 || - pcmcia_parse_tuple(handle, &tuple, &parse) != 0) + if ( (pcmcia_get_tuple_data(handle, &tuple) != 0) + || (pcmcia_parse_tuple(handle, &tuple, &parse) != 0)) goto next_entry; if (cfg->flags & CISTPL_CFTABLE_DEFAULT) @@ -348,8 +351,7 @@ dflt.vpp1.param[CISTPL_POWER_VNOM] / 10000; /* Do we need to allocate an interrupt? */ - if (cfg->irq.IRQInfo1 || dflt.irq.IRQInfo1) - link->conf.Attributes |= CONF_ENABLE_IRQ; + link->conf.Attributes |= CONF_ENABLE_IRQ; /* IO window settings */ link->io.NumPorts1 = link->io.NumPorts2 = 0; @@ -390,7 +392,7 @@ last_ret = pcmcia_get_next_tuple(handle, &tuple); if (last_ret == CS_NO_MORE_ITEMS) { printk(KERN_ERR PFX "GetNextTuple(): No matching " - "CIS configuration, maybe you need the " + "CIS configuration. Maybe you need the " "ignore_cis_vcc=1 parameter.\n"); goto cs_failed; } @@ -401,20 +403,16 @@ * a handler to the interrupt, unless the 'Handler' member of * the irq structure is initialized. */ - if (link->conf.Attributes & CONF_ENABLE_IRQ) { - link->irq.Attributes = IRQ_TYPE_EXCLUSIVE | IRQ_HANDLE_PRESENT; - link->irq.IRQInfo1 = IRQ_LEVEL_ID; - link->irq.Handler = orinoco_interrupt; - link->irq.Instance = dev; - - CS_CHECK(RequestIRQ, pcmcia_request_irq(link->handle, &link->irq)); - } + CS_CHECK(RequestIRQ, pcmcia_request_irq(link->handle, &link->irq)); /* We initialize the hermes structure before completing PCMCIA * configuration just in case the interrupt handler gets * called. */ - hermes_struct_init(hw, link->io.BasePort1, - HERMES_IO, HERMES_16BIT_REGSPACING); + mem = ioport_map(link->io.BasePort1, link->io.NumPorts1); + if (!mem) + goto cs_failed; + + hermes_struct_init(hw, mem, HERMES_16BIT_REGSPACING); /* * This actually configures the PCMCIA socket -- setting up @@ -430,8 +428,6 @@ SET_MODULE_OWNER(dev); card->node.major = card->node.minor = 0; - /* register_netdev will give us an ethX name */ - dev->name[0] = '\0'; SET_NETDEV_DEV(dev, &handle_to_dev(handle)); /* Tell the stack we exist */ if (register_netdev(dev) != 0) { @@ -454,8 +450,7 @@ if (link->conf.Vpp1) printk(", Vpp %d.%d", link->conf.Vpp1 / 10, link->conf.Vpp1 % 10); - if (link->conf.Attributes & CONF_ENABLE_IRQ) - printk(", irq %d", link->irq.AssignedIRQ); + printk(", irq %d", link->irq.AssignedIRQ); if (link->io.NumPorts1) printk(", io 0x%04x-0x%04x", link->io.BasePort1, link->io.BasePort1 + link->io.NumPorts1 - 1); @@ -498,6 +493,8 @@ if (link->irq.AssignedIRQ) pcmcia_release_irq(link->handle, &link->irq); link->state &= ~DEV_CONFIG; + if (priv->hw.iobase) + ioport_unmap(priv->hw.iobase); } /* orinoco_cs_release */ /* @@ -519,12 +516,12 @@ case CS_EVENT_CARD_REMOVAL: link->state &= ~DEV_PRESENT; if (link->state & DEV_CONFIG) { - orinoco_lock(priv, &flags); + unsigned long flags; + spin_lock_irqsave(&priv->lock, flags); netif_device_detach(dev); priv->hw_unavailable++; - - orinoco_unlock(priv, &flags); + spin_unlock_irqrestore(&priv->lock, flags); } break; diff -Nru a/drivers/net/wireless/orinoco_pci.c b/drivers/net/wireless/orinoco_pci.c --- a/drivers/net/wireless/orinoco_pci.c 2005-03-08 14:29:45 -05:00 +++ b/drivers/net/wireless/orinoco_pci.c 2005-03-08 14:29:45 -05:00 @@ -129,6 +129,11 @@ #define HERMES_PCI_COR_OFFT (500) /* ms */ #define HERMES_PCI_COR_BUSYT (500) /* ms */ +/* Orinoco PCI specific data */ +struct orinoco_pci_card { + void __iomem *pci_ioaddr; +}; + /* * Do a soft reset of the PCI card using the Configuration Option Register * We need this to get going... @@ -151,25 +156,11 @@ /* Assert the reset until the card notice */ hermes_write_regn(hw, PCI_COR, HERMES_PCI_COR_MASK); - printk(KERN_NOTICE "Reset done"); - timeout = jiffies + (HERMES_PCI_COR_ONT * HZ / 1000); - while(time_before(jiffies, timeout)) { - printk("."); - mdelay(1); - } - printk(";\n"); - //mdelay(HERMES_PCI_COR_ONT); + mdelay(HERMES_PCI_COR_ONT); /* Give time for the card to recover from this hard effort */ hermes_write_regn(hw, PCI_COR, 0x0000); - printk(KERN_NOTICE "Clear Reset"); - timeout = jiffies + (HERMES_PCI_COR_OFFT * HZ / 1000); - while(time_before(jiffies, timeout)) { - printk("."); - mdelay(1); - } - printk(";\n"); - //mdelay(HERMES_PCI_COR_OFFT); + mdelay(HERMES_PCI_COR_OFFT); /* The card is ready when it's no longer busy */ timeout = jiffies + (HERMES_PCI_COR_BUSYT * HZ / 1000); @@ -178,12 +169,12 @@ mdelay(1); reg = hermes_read_regn(hw, CMD); } - /* Did we timeout ? */ - if(time_after_eq(jiffies, timeout)) { + + /* Still busy? */ + if (reg & HERMES_CMD_BUSY) { printk(KERN_ERR PFX "Busy timeout\n"); return -ETIMEDOUT; } - printk(KERN_NOTICE "pci_cor : reg = 0x%X - %lX - %lX\n", reg, timeout, jiffies); return 0; } @@ -196,84 +187,93 @@ { int err = 0; unsigned long pci_iorange; - u16 *pci_ioaddr = NULL; + u16 __iomem *pci_ioaddr = NULL; unsigned long pci_iolen; struct orinoco_private *priv = NULL; + struct orinoco_pci_card *card; struct net_device *dev = NULL; err = pci_enable_device(pdev); - if (err) - return -EIO; + if (err) { + printk(KERN_ERR PFX "Cannot enable PCI device\n"); + return err; + } + + err = pci_request_regions(pdev, DRIVER_NAME); + if (err != 0) { + printk(KERN_ERR PFX "Cannot obtain PCI resources\n"); + goto fail_resources; + } /* Resource 0 is mapped to the hermes registers */ pci_iorange = pci_resource_start(pdev, 0); pci_iolen = pci_resource_len(pdev, 0); pci_ioaddr = ioremap(pci_iorange, pci_iolen); - if (! pci_iorange) - goto fail; + if (!pci_iorange) { + printk(KERN_ERR PFX "Cannot remap hardware registers\n"); + goto fail_map; + } /* Allocate network device */ - dev = alloc_orinocodev(0, NULL); + dev = alloc_orinocodev(sizeof(*card), orinoco_pci_cor_reset); if (! dev) { err = -ENOMEM; - goto fail; + goto fail_alloc; } priv = netdev_priv(dev); - dev->base_addr = (unsigned long) pci_ioaddr; + card = priv->card; + card->pci_ioaddr = pci_ioaddr; dev->mem_start = pci_iorange; dev->mem_end = pci_iorange + pci_iolen - 1; SET_MODULE_OWNER(dev); SET_NETDEV_DEV(dev, &pdev->dev); - printk(KERN_DEBUG PFX - "Detected Orinoco/Prism2 PCI device at %s, mem:0x%lX to 0x%lX -> 0x%p, irq:%d\n", - pci_name(pdev), dev->mem_start, dev->mem_end, pci_ioaddr, pdev->irq); + hermes_struct_init(&priv->hw, pci_ioaddr, HERMES_32BIT_REGSPACING); - hermes_struct_init(&priv->hw, dev->base_addr, - HERMES_MEM, HERMES_32BIT_REGSPACING); - pci_set_drvdata(pdev, dev); + printk(KERN_DEBUG PFX "Detected device %s, mem:0x%lx-0x%lx, irq %d\n", + pci_name(pdev), dev->mem_start, dev->mem_end, pdev->irq); err = request_irq(pdev->irq, orinoco_interrupt, SA_SHIRQ, dev->name, dev); if (err) { - printk(KERN_ERR PFX "Error allocating IRQ %d.\n", - pdev->irq); + printk(KERN_ERR PFX "Cannot allocate IRQ %d\n", pdev->irq); err = -EBUSY; - goto fail; + goto fail_irq; } dev->irq = pdev->irq; /* Perform a COR reset to start the card */ - if(orinoco_pci_cor_reset(priv) != 0) { - printk(KERN_ERR "%s: Failed to start the card\n", dev->name); - err = -ETIMEDOUT; + err = orinoco_pci_cor_reset(priv); + if (err) { + printk(KERN_ERR PFX "Initial reset failed\n"); goto fail; } - /* Override the normal firmware detection - the Prism 2.5 PCI - * cards look like Lucent firmware but are actually Intersil */ - priv->firmware_type = FIRMWARE_TYPE_INTERSIL; - err = register_netdev(dev); if (err) { - printk(KERN_ERR "%s: Failed to register net device\n", dev->name); + printk(KERN_ERR PFX "Failed to register net device\n"); goto fail; } + pci_set_drvdata(pdev, dev); + return 0; fail: - if (dev) { - if (dev->irq) - free_irq(dev->irq, dev); + free_irq(pdev->irq, dev); - free_netdev(dev); - } + fail_irq: + pci_set_drvdata(pdev, NULL); + free_orinocodev(dev); - if (pci_ioaddr) - iounmap(pci_ioaddr); + fail_alloc: + iounmap(pci_ioaddr); + fail_map: + pci_release_regions(pdev); + + fail_resources: pci_disable_device(pdev); return err; @@ -283,18 +283,14 @@ { struct net_device *dev = pci_get_drvdata(pdev); struct orinoco_private *priv = netdev_priv(dev); + struct orinoco_pci_card *card = priv->card; unregister_netdev(dev); - - if (dev->irq) - free_irq(dev->irq, dev); - - if (priv->hw.iobase) - iounmap((unsigned char *) priv->hw.iobase); - + free_irq(dev->irq, dev); pci_set_drvdata(pdev, NULL); - free_netdev(dev); - + free_orinocodev(dev); + iounmap(card->pci_ioaddr); + pci_release_regions(pdev); pci_disable_device(pdev); } @@ -326,6 +322,9 @@ orinoco_unlock(priv, &flags); + pci_save_state(pdev); + pci_set_power_state(pdev, 3); + return 0; } @@ -338,6 +337,9 @@ printk(KERN_DEBUG "%s: Orinoco-PCI waking up\n", dev->name); + pci_set_power_state(pdev, 0); + pci_restore_state(pdev); + err = orinoco_reinit_firmware(dev); if (err) { printk(KERN_ERR "%s: Error %d re-initializing firmware on orinoco_pci_resume()\n", @@ -368,6 +370,8 @@ {0x1260, 0x3872, PCI_ANY_ID, PCI_ANY_ID,}, /* Intersil Prism 2.5 */ {0x1260, 0x3873, PCI_ANY_ID, PCI_ANY_ID,}, + /* Samsung MagicLAN SWL-2210P */ + {0x167d, 0xa000, PCI_ANY_ID, PCI_ANY_ID,}, {0,}, }; diff -Nru a/drivers/net/wireless/orinoco_plx.c b/drivers/net/wireless/orinoco_plx.c --- a/drivers/net/wireless/orinoco_plx.c 2005-03-08 14:29:45 -05:00 +++ b/drivers/net/wireless/orinoco_plx.c 2005-03-08 14:29:45 -05:00 @@ -142,146 +142,199 @@ #include "hermes.h" #include "orinoco.h" -#define COR_OFFSET (0x3e0/2) /* COR attribute offset of Prism2 PC card */ +#define COR_OFFSET (0x3e0) /* COR attribute offset of Prism2 PC card */ #define COR_VALUE (COR_LEVEL_REQ | COR_FUNC_ENA) /* Enable PC card with interrupt in level trigger */ +#define COR_RESET (0x80) /* reset bit in the COR register */ +#define PLX_RESET_TIME (500) /* milliseconds */ #define PLX_INTCSR 0x4c /* Interrupt Control & Status Register */ #define PLX_INTCSR_INTEN (1<<6) /* Interrupt Enable bit */ -static const u16 cis_magic[] = { - 0x0001, 0x0003, 0x0000, 0x0000, 0x00ff, 0x0017, 0x0004, 0x0067 +static const u8 cis_magic[] = { + 0x01, 0x03, 0x00, 0x00, 0xff, 0x17, 0x04, 0x67 }; +/* Orinoco PLX specific data */ +struct orinoco_plx_card { + void __iomem *attr_mem; +}; + +/* + * Do a soft reset of the card using the Configuration Option Register + */ +static int orinoco_plx_cor_reset(struct orinoco_private *priv) +{ + hermes_t *hw = &priv->hw; + struct orinoco_plx_card *card = priv->card; + u8 __iomem *attr_mem = card->attr_mem; + unsigned long timeout; + u16 reg; + + writeb(COR_VALUE | COR_RESET, attr_mem + COR_OFFSET); + mdelay(1); + + writeb(COR_VALUE, attr_mem + COR_OFFSET); + mdelay(1); + + /* Just in case, wait more until the card is no longer busy */ + timeout = jiffies + (PLX_RESET_TIME * HZ / 1000); + reg = hermes_read_regn(hw, CMD); + while (time_before(jiffies, timeout) && (reg & HERMES_CMD_BUSY)) { + mdelay(1); + reg = hermes_read_regn(hw, CMD); + } + + /* Did we timeout ? */ + if (reg & HERMES_CMD_BUSY) { + printk(KERN_ERR PFX "Busy timeout\n"); + return -ETIMEDOUT; + } + + return 0; +} + + static int orinoco_plx_init_one(struct pci_dev *pdev, const struct pci_device_id *ent) { int err = 0; - u16 *attr_mem = NULL; - u32 reg, addr; + u8 __iomem *attr_mem = NULL; + u32 csr_reg, plx_addr; struct orinoco_private *priv = NULL; + struct orinoco_plx_card *card; unsigned long pccard_ioaddr = 0; unsigned long pccard_iolen = 0; struct net_device *dev = NULL; + void __iomem *mem; int i; err = pci_enable_device(pdev); - if (err) - return -EIO; - - /* Resource 2 is mapped to the PCMCIA space */ - attr_mem = ioremap(pci_resource_start(pdev, 2), PAGE_SIZE); - if (! attr_mem) - goto fail; - - printk(KERN_DEBUG "orinoco_plx: CIS: "); - for (i = 0; i < 16; i++) { - printk("%02X:", (int)attr_mem[i]); + if (err) { + printk(KERN_ERR PFX "Cannot enable PCI device\n"); + return err; } - printk("\n"); - /* Verify whether PC card is present */ - /* FIXME: we probably need to be smarted about this */ - if (memcmp(attr_mem, cis_magic, sizeof(cis_magic)) != 0) { - printk(KERN_ERR "orinoco_plx: The CIS value of Prism2 PC card is invalid.\n"); - err = -EIO; - goto fail; + err = pci_request_regions(pdev, DRIVER_NAME); + if (err != 0) { + printk(KERN_ERR PFX "Cannot obtain PCI resources\n"); + goto fail_resources; } - /* PCMCIA COR is the first byte following CIS: this write should - * enable I/O mode and select level-triggered interrupts */ - attr_mem[COR_OFFSET] = COR_VALUE; - mdelay(1); - reg = attr_mem[COR_OFFSET]; - if (reg != COR_VALUE) { - printk(KERN_ERR "orinoco_plx: Error setting COR value (reg=%x)\n", reg); - goto fail; - } - - iounmap(attr_mem); - attr_mem = NULL; /* done with this now, it seems */ + /* Resource 1 is mapped to PLX-specific registers */ + plx_addr = pci_resource_start(pdev, 1); - /* bjoern: We need to tell the card to enable interrupts, in - case the serial eprom didn't do this already. See the - PLX9052 data book, p8-1 and 8-24 for reference. */ - addr = pci_resource_start(pdev, 1); - reg = 0; - reg = inl(addr+PLX_INTCSR); - if (reg & PLX_INTCSR_INTEN) - printk(KERN_DEBUG "orinoco_plx: " - "Local Interrupt already enabled\n"); - else { - reg |= PLX_INTCSR_INTEN; - outl(reg, addr+PLX_INTCSR); - reg = inl(addr+PLX_INTCSR); - if(!(reg & PLX_INTCSR_INTEN)) { - printk(KERN_ERR "orinoco_plx: " - "Couldn't enable Local Interrupts\n"); - goto fail; - } + /* Resource 2 is mapped to the PCMCIA attribute memory */ + attr_mem = ioremap(pci_resource_start(pdev, 2), + pci_resource_len(pdev, 2)); + if (!attr_mem) { + printk(KERN_ERR PFX "Cannot remap PCMCIA space\n"); + goto fail_map_attr; } - /* and 3 to the PCMCIA slot I/O address space */ + /* Resource 3 is mapped to the PCMCIA I/O address space */ pccard_ioaddr = pci_resource_start(pdev, 3); pccard_iolen = pci_resource_len(pdev, 3); - if (! request_region(pccard_ioaddr, pccard_iolen, DRIVER_NAME)) { - printk(KERN_ERR "orinoco_plx: I/O resource 0x%lx @ 0x%lx busy\n", - pccard_iolen, pccard_ioaddr); - pccard_ioaddr = 0; - err = -EBUSY; - goto fail; + + mem = pci_iomap(pdev, 3, 0); + if (!mem) { + err = -ENOMEM; + goto fail_map_io; } /* Allocate network device */ - dev = alloc_orinocodev(0, NULL); - if (! dev) { + dev = alloc_orinocodev(sizeof(*card), orinoco_plx_cor_reset); + if (!dev) { + printk(KERN_ERR PFX "Cannot allocate network device\n"); err = -ENOMEM; - goto fail; + goto fail_alloc; } priv = netdev_priv(dev); + card = priv->card; + card->attr_mem = attr_mem; dev->base_addr = pccard_ioaddr; SET_MODULE_OWNER(dev); SET_NETDEV_DEV(dev, &pdev->dev); + hermes_struct_init(&priv->hw, mem, HERMES_16BIT_REGSPACING); + printk(KERN_DEBUG PFX "Detected Orinoco/Prism2 PLX device " "at %s irq:%d, io addr:0x%lx\n", pci_name(pdev), pdev->irq, pccard_ioaddr); - hermes_struct_init(&(priv->hw), dev->base_addr, HERMES_IO, - HERMES_16BIT_REGSPACING); - pci_set_drvdata(pdev, dev); - err = request_irq(pdev->irq, orinoco_interrupt, SA_SHIRQ, dev->name, dev); if (err) { - printk(KERN_ERR PFX "Error allocating IRQ %d.\n", pdev->irq); + printk(KERN_ERR PFX "Cannot allocate IRQ %d\n", pdev->irq); err = -EBUSY; - goto fail; + goto fail_irq; } dev->irq = pdev->irq; + /* bjoern: We need to tell the card to enable interrupts, in + case the serial eprom didn't do this already. See the + PLX9052 data book, p8-1 and 8-24 for reference. */ + csr_reg = inl(plx_addr + PLX_INTCSR); + if (!(csr_reg & PLX_INTCSR_INTEN)) { + csr_reg |= PLX_INTCSR_INTEN; + outl(csr_reg, plx_addr + PLX_INTCSR); + csr_reg = inl(plx_addr + PLX_INTCSR); + if (!(csr_reg & PLX_INTCSR_INTEN)) { + printk(KERN_ERR PFX "Cannot enable interrupts\n"); + goto fail; + } + } + + err = orinoco_plx_cor_reset(priv); + if (err) { + printk(KERN_ERR PFX "Initial reset failed\n"); + goto fail; + } + + printk(KERN_DEBUG PFX "CIS: "); + for (i = 0; i < 16; i++) { + printk("%02X:", readb(attr_mem + 2*i)); + } + printk("\n"); + + /* Verify whether a supported PC card is present */ + /* FIXME: we probably need to be smarted about this */ + for (i = 0; i < sizeof(cis_magic); i++) { + if (cis_magic[i] != readb(attr_mem +2*i)) { + printk(KERN_ERR PFX "The CIS value of Prism2 PC " + "card is unexpected\n"); + err = -EIO; + goto fail; + } + } + err = register_netdev(dev); - if (err) + if (err) { + printk(KERN_ERR PFX "Cannot register network device\n"); goto fail; + } + + pci_set_drvdata(pdev, dev); return 0; fail: - printk(KERN_DEBUG PFX "init_one(), FAIL!\n"); + free_irq(pdev->irq, dev); - if (dev) { - if (dev->irq) - free_irq(dev->irq, dev); - - free_netdev(dev); - } + fail_irq: + pci_set_drvdata(pdev, NULL); + free_orinocodev(dev); - if (pccard_ioaddr) - release_region(pccard_ioaddr, pccard_iolen); + fail_alloc: + pci_iounmap(pdev, mem); + + fail_map_io: + iounmap(attr_mem); - if (attr_mem) - iounmap(attr_mem); + fail_map_attr: + pci_release_regions(pdev); + fail_resources: pci_disable_device(pdev); return err; @@ -290,20 +343,19 @@ static void __devexit orinoco_plx_remove_one(struct pci_dev *pdev) { struct net_device *dev = pci_get_drvdata(pdev); + struct orinoco_private *priv = netdev_priv(dev); + struct orinoco_plx_card *card = priv->card; + u8 __iomem *attr_mem = card->attr_mem; BUG_ON(! dev); unregister_netdev(dev); - - if (dev->irq) - free_irq(dev->irq, dev); - + free_irq(dev->irq, dev); pci_set_drvdata(pdev, NULL); - - free_netdev(dev); - - release_region(pci_resource_start(pdev, 3), pci_resource_len(pdev, 3)); - + free_orinocodev(dev); + pci_iounmap(pdev, priv->hw.iobase); + iounmap(attr_mem); + pci_release_regions(pdev); pci_disable_device(pdev); } @@ -352,8 +404,7 @@ static void __exit orinoco_plx_exit(void) { pci_unregister_driver(&orinoco_plx_driver); - current->state = TASK_UNINTERRUPTIBLE; - schedule_timeout(HZ); + ssleep(1); } module_init(orinoco_plx_init); diff -Nru a/drivers/net/wireless/orinoco_tmd.c b/drivers/net/wireless/orinoco_tmd.c --- a/drivers/net/wireless/orinoco_tmd.c 2005-03-08 14:29:45 -05:00 +++ b/drivers/net/wireless/orinoco_tmd.c 2005-03-08 14:29:45 -05:00 @@ -79,90 +79,137 @@ #include "orinoco.h" #define COR_VALUE (COR_LEVEL_REQ | COR_FUNC_ENA) /* Enable PC card with interrupt in level trigger */ +#define COR_RESET (0x80) /* reset bit in the COR register */ +#define TMD_RESET_TIME (500) /* milliseconds */ + +/* Orinoco TMD specific data */ +struct orinoco_tmd_card { + u32 tmd_io; +}; + + +/* + * Do a soft reset of the card using the Configuration Option Register + */ +static int orinoco_tmd_cor_reset(struct orinoco_private *priv) +{ + hermes_t *hw = &priv->hw; + struct orinoco_tmd_card *card = priv->card; + u32 addr = card->tmd_io; + unsigned long timeout; + u16 reg; + + outb(COR_VALUE | COR_RESET, addr); + mdelay(1); + + outb(COR_VALUE, addr); + mdelay(1); + + /* Just in case, wait more until the card is no longer busy */ + timeout = jiffies + (TMD_RESET_TIME * HZ / 1000); + reg = hermes_read_regn(hw, CMD); + while (time_before(jiffies, timeout) && (reg & HERMES_CMD_BUSY)) { + mdelay(1); + reg = hermes_read_regn(hw, CMD); + } + + /* Did we timeout ? */ + if (reg & HERMES_CMD_BUSY) { + printk(KERN_ERR PFX "Busy timeout\n"); + return -ETIMEDOUT; + } + + return 0; +} + static int orinoco_tmd_init_one(struct pci_dev *pdev, const struct pci_device_id *ent) { int err = 0; - u32 reg, addr; struct orinoco_private *priv = NULL; - unsigned long pccard_ioaddr = 0; - unsigned long pccard_iolen = 0; + struct orinoco_tmd_card *card; struct net_device *dev = NULL; + void __iomem *mem; err = pci_enable_device(pdev); - if (err) - return -EIO; + if (err) { + printk(KERN_ERR PFX "Cannot enable PCI device\n"); + return err; + } - printk(KERN_DEBUG PFX "TMD setup\n"); - pccard_ioaddr = pci_resource_start(pdev, 2); - pccard_iolen = pci_resource_len(pdev, 2); - if (! request_region(pccard_ioaddr, pccard_iolen, DRIVER_NAME)) { - printk(KERN_ERR PFX "I/O resource at 0x%lx len 0x%lx busy\n", - pccard_ioaddr, pccard_iolen); - pccard_ioaddr = 0; - err = -EBUSY; - goto fail; + err = pci_request_regions(pdev, DRIVER_NAME); + if (err != 0) { + printk(KERN_ERR PFX "Cannot obtain PCI resources\n"); + goto fail_resources; } - addr = pci_resource_start(pdev, 1); - outb(COR_VALUE, addr); - mdelay(1); - reg = inb(addr); - if (reg != COR_VALUE) { - printk(KERN_ERR PFX "Error setting TMD COR values %x should be %x\n", reg, COR_VALUE); - err = -EIO; - goto fail; + + mem = pci_iomap(pdev, 2, 0); + if (! mem) { + err = -ENOMEM; + goto fail_iomap; } /* Allocate network device */ - dev = alloc_orinocodev(0, NULL); + dev = alloc_orinocodev(sizeof(*card), orinoco_tmd_cor_reset); if (! dev) { + printk(KERN_ERR PFX "Cannot allocate network device\n"); err = -ENOMEM; - goto fail; + goto fail_alloc; } priv = netdev_priv(dev); - dev->base_addr = pccard_ioaddr; + card = priv->card; + card->tmd_io = pci_resource_start(pdev, 1); + dev->base_addr = pci_resource_start(pdev, 2); SET_MODULE_OWNER(dev); SET_NETDEV_DEV(dev, &pdev->dev); + hermes_struct_init(&priv->hw, mem, HERMES_16BIT_REGSPACING); + printk(KERN_DEBUG PFX "Detected Orinoco/Prism2 TMD device " "at %s irq:%d, io addr:0x%lx\n", pci_name(pdev), pdev->irq, - pccard_ioaddr); - - hermes_struct_init(&(priv->hw), dev->base_addr, - HERMES_IO, HERMES_16BIT_REGSPACING); - pci_set_drvdata(pdev, dev); + dev->base_addr); err = request_irq(pdev->irq, orinoco_interrupt, SA_SHIRQ, dev->name, dev); if (err) { - printk(KERN_ERR PFX "Error allocating IRQ %d.\n", - pdev->irq); + printk(KERN_ERR PFX "Cannot allocate IRQ %d\n", pdev->irq); err = -EBUSY; - goto fail; + goto fail_irq; } dev->irq = pdev->irq; + err = orinoco_tmd_cor_reset(priv); + if (err) { + printk(KERN_ERR PFX "Initial reset failed\n"); + goto fail; + } + err = register_netdev(dev); - if (err) + if (err) { + printk(KERN_ERR PFX "Cannot register network device\n"); goto fail; + } + + pci_set_drvdata(pdev, dev); return 0; fail: - printk(KERN_DEBUG PFX "init_one(), FAIL!\n"); + free_irq(pdev->irq, dev); - if (dev) { - if (dev->irq) - free_irq(dev->irq, dev); - - free_netdev(dev); - } + fail_irq: + pci_set_drvdata(pdev, NULL); + free_orinocodev(dev); + + fail_alloc: + pci_iounmap(pdev, mem); - if (pccard_ioaddr) - release_region(pccard_ioaddr, pccard_iolen); + fail_iomap: + pci_release_regions(pdev); + fail_resources: pci_disable_device(pdev); return err; @@ -171,20 +218,16 @@ static void __devexit orinoco_tmd_remove_one(struct pci_dev *pdev) { struct net_device *dev = pci_get_drvdata(pdev); + struct orinoco_private *priv = dev->priv; BUG_ON(! dev); unregister_netdev(dev); - - if (dev->irq) - free_irq(dev->irq, dev); - + free_irq(dev->irq, dev); pci_set_drvdata(pdev, NULL); - - free_netdev(dev); - - release_region(pci_resource_start(pdev, 2), pci_resource_len(pdev, 2)); - + free_orinocodev(dev); + pci_iounmap(pdev, priv->hw.iobase); + pci_release_regions(pdev); pci_disable_device(pdev); } @@ -218,8 +261,7 @@ static void __exit orinoco_tmd_exit(void) { pci_unregister_driver(&orinoco_tmd_driver); - current->state = TASK_UNINTERRUPTIBLE; - schedule_timeout(HZ); + ssleep(1); } module_init(orinoco_tmd_init); diff -Nru a/include/linux/mv643xx.h b/include/linux/mv643xx.h --- a/include/linux/mv643xx.h 2005-03-08 14:29:45 -05:00 +++ b/include/linux/mv643xx.h 2005-03-08 14:29:45 -05:00 @@ -1,5 +1,5 @@ /* - * mv64340.h - MV-64340 Internal registers definition file. + * mv643xx.h - MV-643XX Internal registers definition file. * * Copyright 2002 Momentum Computer, Inc. * Author: Matthew Dharm @@ -10,8 +10,8 @@ * Free Software Foundation; either version 2 of the License, or (at your * option) any later version. */ -#ifndef __ASM_MV64340_H -#define __ASM_MV64340_H +#ifndef __ASM_MV643XX_H +#define __ASM_MV643XX_H #ifdef __MIPS__ #include @@ -662,116 +662,119 @@ /* Ethernet Unit Registers */ /****************************************/ -#define MV64340_ETH_PHY_ADDR_REG 0x2000 -#define MV64340_ETH_SMI_REG 0x2004 -#define MV64340_ETH_UNIT_DEFAULT_ADDR_REG 0x2008 -#define MV64340_ETH_UNIT_DEFAULTID_REG 0x200c -#define MV64340_ETH_UNIT_INTERRUPT_CAUSE_REG 0x2080 -#define MV64340_ETH_UNIT_INTERRUPT_MASK_REG 0x2084 -#define MV64340_ETH_UNIT_INTERNAL_USE_REG 0x24fc -#define MV64340_ETH_UNIT_ERROR_ADDR_REG 0x2094 -#define MV64340_ETH_BAR_0 0x2200 -#define MV64340_ETH_BAR_1 0x2208 -#define MV64340_ETH_BAR_2 0x2210 -#define MV64340_ETH_BAR_3 0x2218 -#define MV64340_ETH_BAR_4 0x2220 -#define MV64340_ETH_BAR_5 0x2228 -#define MV64340_ETH_SIZE_REG_0 0x2204 -#define MV64340_ETH_SIZE_REG_1 0x220c -#define MV64340_ETH_SIZE_REG_2 0x2214 -#define MV64340_ETH_SIZE_REG_3 0x221c -#define MV64340_ETH_SIZE_REG_4 0x2224 -#define MV64340_ETH_SIZE_REG_5 0x222c -#define MV64340_ETH_HEADERS_RETARGET_BASE_REG 0x2230 -#define MV64340_ETH_HEADERS_RETARGET_CONTROL_REG 0x2234 -#define MV64340_ETH_HIGH_ADDR_REMAP_REG_0 0x2280 -#define MV64340_ETH_HIGH_ADDR_REMAP_REG_1 0x2284 -#define MV64340_ETH_HIGH_ADDR_REMAP_REG_2 0x2288 -#define MV64340_ETH_HIGH_ADDR_REMAP_REG_3 0x228c -#define MV64340_ETH_BASE_ADDR_ENABLE_REG 0x2290 -#define MV64340_ETH_ACCESS_PROTECTION_REG(port) (0x2294 + (port<<2)) -#define MV64340_ETH_MIB_COUNTERS_BASE(port) (0x3000 + (port<<7)) -#define MV64340_ETH_PORT_CONFIG_REG(port) (0x2400 + (port<<10)) -#define MV64340_ETH_PORT_CONFIG_EXTEND_REG(port) (0x2404 + (port<<10)) -#define MV64340_ETH_MII_SERIAL_PARAMETRS_REG(port) (0x2408 + (port<<10)) -#define MV64340_ETH_GMII_SERIAL_PARAMETRS_REG(port) (0x240c + (port<<10)) -#define MV64340_ETH_VLAN_ETHERTYPE_REG(port) (0x2410 + (port<<10)) -#define MV64340_ETH_MAC_ADDR_LOW(port) (0x2414 + (port<<10)) -#define MV64340_ETH_MAC_ADDR_HIGH(port) (0x2418 + (port<<10)) -#define MV64340_ETH_SDMA_CONFIG_REG(port) (0x241c + (port<<10)) -#define MV64340_ETH_DSCP_0(port) (0x2420 + (port<<10)) -#define MV64340_ETH_DSCP_1(port) (0x2424 + (port<<10)) -#define MV64340_ETH_DSCP_2(port) (0x2428 + (port<<10)) -#define MV64340_ETH_DSCP_3(port) (0x242c + (port<<10)) -#define MV64340_ETH_DSCP_4(port) (0x2430 + (port<<10)) -#define MV64340_ETH_DSCP_5(port) (0x2434 + (port<<10)) -#define MV64340_ETH_DSCP_6(port) (0x2438 + (port<<10)) -#define MV64340_ETH_PORT_SERIAL_CONTROL_REG(port) (0x243c + (port<<10)) -#define MV64340_ETH_VLAN_PRIORITY_TAG_TO_PRIORITY(port) (0x2440 + (port<<10)) -#define MV64340_ETH_PORT_STATUS_REG(port) (0x2444 + (port<<10)) -#define MV64340_ETH_TRANSMIT_QUEUE_COMMAND_REG(port) (0x2448 + (port<<10)) -#define MV64340_ETH_TX_QUEUE_FIXED_PRIORITY(port) (0x244c + (port<<10)) -#define MV64340_ETH_PORT_TX_TOKEN_BUCKET_RATE_CONFIG(port) (0x2450 + (port<<10)) -#define MV64340_ETH_MAXIMUM_TRANSMIT_UNIT(port) (0x2458 + (port<<10)) -#define MV64340_ETH_PORT_MAXIMUM_TOKEN_BUCKET_SIZE(port) (0x245c + (port<<10)) -#define MV64340_ETH_INTERRUPT_CAUSE_REG(port) (0x2460 + (port<<10)) -#define MV64340_ETH_INTERRUPT_CAUSE_EXTEND_REG(port) (0x2464 + (port<<10)) -#define MV64340_ETH_INTERRUPT_MASK_REG(port) (0x2468 + (port<<10)) -#define MV64340_ETH_INTERRUPT_EXTEND_MASK_REG(port) (0x246c + (port<<10)) -#define MV64340_ETH_RX_FIFO_URGENT_THRESHOLD_REG(port) (0x2470 + (port<<10)) -#define MV64340_ETH_TX_FIFO_URGENT_THRESHOLD_REG(port) (0x2474 + (port<<10)) -#define MV64340_ETH_RX_MINIMAL_FRAME_SIZE_REG(port) (0x247c + (port<<10)) -#define MV64340_ETH_RX_DISCARDED_FRAMES_COUNTER(port) (0x2484 + (port<<10) -#define MV64340_ETH_PORT_DEBUG_0_REG(port) (0x248c + (port<<10)) -#define MV64340_ETH_PORT_DEBUG_1_REG(port) (0x2490 + (port<<10)) -#define MV64340_ETH_PORT_INTERNAL_ADDR_ERROR_REG(port) (0x2494 + (port<<10)) -#define MV64340_ETH_INTERNAL_USE_REG(port) (0x24fc + (port<<10)) -#define MV64340_ETH_RECEIVE_QUEUE_COMMAND_REG(port) (0x2680 + (port<<10)) -#define MV64340_ETH_CURRENT_SERVED_TX_DESC_PTR(port) (0x2684 + (port<<10)) -#define MV64340_ETH_RX_CURRENT_QUEUE_DESC_PTR_0(port) (0x260c + (port<<10)) -#define MV64340_ETH_RX_CURRENT_QUEUE_DESC_PTR_1(port) (0x261c + (port<<10)) -#define MV64340_ETH_RX_CURRENT_QUEUE_DESC_PTR_2(port) (0x262c + (port<<10)) -#define MV64340_ETH_RX_CURRENT_QUEUE_DESC_PTR_3(port) (0x263c + (port<<10)) -#define MV64340_ETH_RX_CURRENT_QUEUE_DESC_PTR_4(port) (0x264c + (port<<10)) -#define MV64340_ETH_RX_CURRENT_QUEUE_DESC_PTR_5(port) (0x265c + (port<<10)) -#define MV64340_ETH_RX_CURRENT_QUEUE_DESC_PTR_6(port) (0x266c + (port<<10)) -#define MV64340_ETH_RX_CURRENT_QUEUE_DESC_PTR_7(port) (0x267c + (port<<10)) -#define MV64340_ETH_TX_CURRENT_QUEUE_DESC_PTR_0(port) (0x26c0 + (port<<10)) -#define MV64340_ETH_TX_CURRENT_QUEUE_DESC_PTR_1(port) (0x26c4 + (port<<10)) -#define MV64340_ETH_TX_CURRENT_QUEUE_DESC_PTR_2(port) (0x26c8 + (port<<10)) -#define MV64340_ETH_TX_CURRENT_QUEUE_DESC_PTR_3(port) (0x26cc + (port<<10)) -#define MV64340_ETH_TX_CURRENT_QUEUE_DESC_PTR_4(port) (0x26d0 + (port<<10)) -#define MV64340_ETH_TX_CURRENT_QUEUE_DESC_PTR_5(port) (0x26d4 + (port<<10)) -#define MV64340_ETH_TX_CURRENT_QUEUE_DESC_PTR_6(port) (0x26d8 + (port<<10)) -#define MV64340_ETH_TX_CURRENT_QUEUE_DESC_PTR_7(port) (0x26dc + (port<<10)) -#define MV64340_ETH_TX_QUEUE_0_TOKEN_BUCKET_COUNT(port) (0x2700 + (port<<10)) -#define MV64340_ETH_TX_QUEUE_1_TOKEN_BUCKET_COUNT(port) (0x2710 + (port<<10)) -#define MV64340_ETH_TX_QUEUE_2_TOKEN_BUCKET_COUNT(port) (0x2720 + (port<<10)) -#define MV64340_ETH_TX_QUEUE_3_TOKEN_BUCKET_COUNT(port) (0x2730 + (port<<10)) -#define MV64340_ETH_TX_QUEUE_4_TOKEN_BUCKET_COUNT(port) (0x2740 + (port<<10)) -#define MV64340_ETH_TX_QUEUE_5_TOKEN_BUCKET_COUNT(port) (0x2750 + (port<<10)) -#define MV64340_ETH_TX_QUEUE_6_TOKEN_BUCKET_COUNT(port) (0x2760 + (port<<10)) -#define MV64340_ETH_TX_QUEUE_7_TOKEN_BUCKET_COUNT(port) (0x2770 + (port<<10)) -#define MV64340_ETH_TX_QUEUE_0_TOKEN_BUCKET_CONFIG(port) (0x2704 + (port<<10)) -#define MV64340_ETH_TX_QUEUE_1_TOKEN_BUCKET_CONFIG(port) (0x2714 + (port<<10)) -#define MV64340_ETH_TX_QUEUE_2_TOKEN_BUCKET_CONFIG(port) (0x2724 + (port<<10)) -#define MV64340_ETH_TX_QUEUE_3_TOKEN_BUCKET_CONFIG(port) (0x2734 + (port<<10)) -#define MV64340_ETH_TX_QUEUE_4_TOKEN_BUCKET_CONFIG(port) (0x2744 + (port<<10)) -#define MV64340_ETH_TX_QUEUE_5_TOKEN_BUCKET_CONFIG(port) (0x2754 + (port<<10)) -#define MV64340_ETH_TX_QUEUE_6_TOKEN_BUCKET_CONFIG(port) (0x2764 + (port<<10)) -#define MV64340_ETH_TX_QUEUE_7_TOKEN_BUCKET_CONFIG(port) (0x2774 + (port<<10)) -#define MV64340_ETH_TX_QUEUE_0_ARBITER_CONFIG(port) (0x2708 + (port<<10)) -#define MV64340_ETH_TX_QUEUE_1_ARBITER_CONFIG(port) (0x2718 + (port<<10)) -#define MV64340_ETH_TX_QUEUE_2_ARBITER_CONFIG(port) (0x2728 + (port<<10)) -#define MV64340_ETH_TX_QUEUE_3_ARBITER_CONFIG(port) (0x2738 + (port<<10)) -#define MV64340_ETH_TX_QUEUE_4_ARBITER_CONFIG(port) (0x2748 + (port<<10)) -#define MV64340_ETH_TX_QUEUE_5_ARBITER_CONFIG(port) (0x2758 + (port<<10)) -#define MV64340_ETH_TX_QUEUE_6_ARBITER_CONFIG(port) (0x2768 + (port<<10)) -#define MV64340_ETH_TX_QUEUE_7_ARBITER_CONFIG(port) (0x2778 + (port<<10)) -#define MV64340_ETH_PORT_TX_TOKEN_BUCKET_COUNT(port) (0x2780 + (port<<10)) -#define MV64340_ETH_DA_FILTER_SPECIAL_MULTICAST_TABLE_BASE(port) (0x3400 + (port<<10)) -#define MV64340_ETH_DA_FILTER_OTHER_MULTICAST_TABLE_BASE(port) (0x3500 + (port<<10)) -#define MV64340_ETH_DA_FILTER_UNICAST_TABLE_BASE(port) (0x3600 + (port<<10)) +#define MV643XX_ETH_SHARED_REGS 0x2000 +#define MV643XX_ETH_SHARED_REGS_SIZE 0x2000 + +#define MV643XX_ETH_PHY_ADDR_REG 0x2000 +#define MV643XX_ETH_SMI_REG 0x2004 +#define MV643XX_ETH_UNIT_DEFAULT_ADDR_REG 0x2008 +#define MV643XX_ETH_UNIT_DEFAULTID_REG 0x200c +#define MV643XX_ETH_UNIT_INTERRUPT_CAUSE_REG 0x2080 +#define MV643XX_ETH_UNIT_INTERRUPT_MASK_REG 0x2084 +#define MV643XX_ETH_UNIT_INTERNAL_USE_REG 0x24fc +#define MV643XX_ETH_UNIT_ERROR_ADDR_REG 0x2094 +#define MV643XX_ETH_BAR_0 0x2200 +#define MV643XX_ETH_BAR_1 0x2208 +#define MV643XX_ETH_BAR_2 0x2210 +#define MV643XX_ETH_BAR_3 0x2218 +#define MV643XX_ETH_BAR_4 0x2220 +#define MV643XX_ETH_BAR_5 0x2228 +#define MV643XX_ETH_SIZE_REG_0 0x2204 +#define MV643XX_ETH_SIZE_REG_1 0x220c +#define MV643XX_ETH_SIZE_REG_2 0x2214 +#define MV643XX_ETH_SIZE_REG_3 0x221c +#define MV643XX_ETH_SIZE_REG_4 0x2224 +#define MV643XX_ETH_SIZE_REG_5 0x222c +#define MV643XX_ETH_HEADERS_RETARGET_BASE_REG 0x2230 +#define MV643XX_ETH_HEADERS_RETARGET_CONTROL_REG 0x2234 +#define MV643XX_ETH_HIGH_ADDR_REMAP_REG_0 0x2280 +#define MV643XX_ETH_HIGH_ADDR_REMAP_REG_1 0x2284 +#define MV643XX_ETH_HIGH_ADDR_REMAP_REG_2 0x2288 +#define MV643XX_ETH_HIGH_ADDR_REMAP_REG_3 0x228c +#define MV643XX_ETH_BASE_ADDR_ENABLE_REG 0x2290 +#define MV643XX_ETH_ACCESS_PROTECTION_REG(port) (0x2294 + (port<<2)) +#define MV643XX_ETH_MIB_COUNTERS_BASE(port) (0x3000 + (port<<7)) +#define MV643XX_ETH_PORT_CONFIG_REG(port) (0x2400 + (port<<10)) +#define MV643XX_ETH_PORT_CONFIG_EXTEND_REG(port) (0x2404 + (port<<10)) +#define MV643XX_ETH_MII_SERIAL_PARAMETRS_REG(port) (0x2408 + (port<<10)) +#define MV643XX_ETH_GMII_SERIAL_PARAMETRS_REG(port) (0x240c + (port<<10)) +#define MV643XX_ETH_VLAN_ETHERTYPE_REG(port) (0x2410 + (port<<10)) +#define MV643XX_ETH_MAC_ADDR_LOW(port) (0x2414 + (port<<10)) +#define MV643XX_ETH_MAC_ADDR_HIGH(port) (0x2418 + (port<<10)) +#define MV643XX_ETH_SDMA_CONFIG_REG(port) (0x241c + (port<<10)) +#define MV643XX_ETH_DSCP_0(port) (0x2420 + (port<<10)) +#define MV643XX_ETH_DSCP_1(port) (0x2424 + (port<<10)) +#define MV643XX_ETH_DSCP_2(port) (0x2428 + (port<<10)) +#define MV643XX_ETH_DSCP_3(port) (0x242c + (port<<10)) +#define MV643XX_ETH_DSCP_4(port) (0x2430 + (port<<10)) +#define MV643XX_ETH_DSCP_5(port) (0x2434 + (port<<10)) +#define MV643XX_ETH_DSCP_6(port) (0x2438 + (port<<10)) +#define MV643XX_ETH_PORT_SERIAL_CONTROL_REG(port) (0x243c + (port<<10)) +#define MV643XX_ETH_VLAN_PRIORITY_TAG_TO_PRIORITY(port) (0x2440 + (port<<10)) +#define MV643XX_ETH_PORT_STATUS_REG(port) (0x2444 + (port<<10)) +#define MV643XX_ETH_TRANSMIT_QUEUE_COMMAND_REG(port) (0x2448 + (port<<10)) +#define MV643XX_ETH_TX_QUEUE_FIXED_PRIORITY(port) (0x244c + (port<<10)) +#define MV643XX_ETH_PORT_TX_TOKEN_BUCKET_RATE_CONFIG(port) (0x2450 + (port<<10)) +#define MV643XX_ETH_MAXIMUM_TRANSMIT_UNIT(port) (0x2458 + (port<<10)) +#define MV643XX_ETH_PORT_MAXIMUM_TOKEN_BUCKET_SIZE(port) (0x245c + (port<<10)) +#define MV643XX_ETH_INTERRUPT_CAUSE_REG(port) (0x2460 + (port<<10)) +#define MV643XX_ETH_INTERRUPT_CAUSE_EXTEND_REG(port) (0x2464 + (port<<10)) +#define MV643XX_ETH_INTERRUPT_MASK_REG(port) (0x2468 + (port<<10)) +#define MV643XX_ETH_INTERRUPT_EXTEND_MASK_REG(port) (0x246c + (port<<10)) +#define MV643XX_ETH_RX_FIFO_URGENT_THRESHOLD_REG(port) (0x2470 + (port<<10)) +#define MV643XX_ETH_TX_FIFO_URGENT_THRESHOLD_REG(port) (0x2474 + (port<<10)) +#define MV643XX_ETH_RX_MINIMAL_FRAME_SIZE_REG(port) (0x247c + (port<<10)) +#define MV643XX_ETH_RX_DISCARDED_FRAMES_COUNTER(port) (0x2484 + (port<<10) +#define MV643XX_ETH_PORT_DEBUG_0_REG(port) (0x248c + (port<<10)) +#define MV643XX_ETH_PORT_DEBUG_1_REG(port) (0x2490 + (port<<10)) +#define MV643XX_ETH_PORT_INTERNAL_ADDR_ERROR_REG(port) (0x2494 + (port<<10)) +#define MV643XX_ETH_INTERNAL_USE_REG(port) (0x24fc + (port<<10)) +#define MV643XX_ETH_RECEIVE_QUEUE_COMMAND_REG(port) (0x2680 + (port<<10)) +#define MV643XX_ETH_CURRENT_SERVED_TX_DESC_PTR(port) (0x2684 + (port<<10)) +#define MV643XX_ETH_RX_CURRENT_QUEUE_DESC_PTR_0(port) (0x260c + (port<<10)) +#define MV643XX_ETH_RX_CURRENT_QUEUE_DESC_PTR_1(port) (0x261c + (port<<10)) +#define MV643XX_ETH_RX_CURRENT_QUEUE_DESC_PTR_2(port) (0x262c + (port<<10)) +#define MV643XX_ETH_RX_CURRENT_QUEUE_DESC_PTR_3(port) (0x263c + (port<<10)) +#define MV643XX_ETH_RX_CURRENT_QUEUE_DESC_PTR_4(port) (0x264c + (port<<10)) +#define MV643XX_ETH_RX_CURRENT_QUEUE_DESC_PTR_5(port) (0x265c + (port<<10)) +#define MV643XX_ETH_RX_CURRENT_QUEUE_DESC_PTR_6(port) (0x266c + (port<<10)) +#define MV643XX_ETH_RX_CURRENT_QUEUE_DESC_PTR_7(port) (0x267c + (port<<10)) +#define MV643XX_ETH_TX_CURRENT_QUEUE_DESC_PTR_0(port) (0x26c0 + (port<<10)) +#define MV643XX_ETH_TX_CURRENT_QUEUE_DESC_PTR_1(port) (0x26c4 + (port<<10)) +#define MV643XX_ETH_TX_CURRENT_QUEUE_DESC_PTR_2(port) (0x26c8 + (port<<10)) +#define MV643XX_ETH_TX_CURRENT_QUEUE_DESC_PTR_3(port) (0x26cc + (port<<10)) +#define MV643XX_ETH_TX_CURRENT_QUEUE_DESC_PTR_4(port) (0x26d0 + (port<<10)) +#define MV643XX_ETH_TX_CURRENT_QUEUE_DESC_PTR_5(port) (0x26d4 + (port<<10)) +#define MV643XX_ETH_TX_CURRENT_QUEUE_DESC_PTR_6(port) (0x26d8 + (port<<10)) +#define MV643XX_ETH_TX_CURRENT_QUEUE_DESC_PTR_7(port) (0x26dc + (port<<10)) +#define MV643XX_ETH_TX_QUEUE_0_TOKEN_BUCKET_COUNT(port) (0x2700 + (port<<10)) +#define MV643XX_ETH_TX_QUEUE_1_TOKEN_BUCKET_COUNT(port) (0x2710 + (port<<10)) +#define MV643XX_ETH_TX_QUEUE_2_TOKEN_BUCKET_COUNT(port) (0x2720 + (port<<10)) +#define MV643XX_ETH_TX_QUEUE_3_TOKEN_BUCKET_COUNT(port) (0x2730 + (port<<10)) +#define MV643XX_ETH_TX_QUEUE_4_TOKEN_BUCKET_COUNT(port) (0x2740 + (port<<10)) +#define MV643XX_ETH_TX_QUEUE_5_TOKEN_BUCKET_COUNT(port) (0x2750 + (port<<10)) +#define MV643XX_ETH_TX_QUEUE_6_TOKEN_BUCKET_COUNT(port) (0x2760 + (port<<10)) +#define MV643XX_ETH_TX_QUEUE_7_TOKEN_BUCKET_COUNT(port) (0x2770 + (port<<10)) +#define MV643XX_ETH_TX_QUEUE_0_TOKEN_BUCKET_CONFIG(port) (0x2704 + (port<<10)) +#define MV643XX_ETH_TX_QUEUE_1_TOKEN_BUCKET_CONFIG(port) (0x2714 + (port<<10)) +#define MV643XX_ETH_TX_QUEUE_2_TOKEN_BUCKET_CONFIG(port) (0x2724 + (port<<10)) +#define MV643XX_ETH_TX_QUEUE_3_TOKEN_BUCKET_CONFIG(port) (0x2734 + (port<<10)) +#define MV643XX_ETH_TX_QUEUE_4_TOKEN_BUCKET_CONFIG(port) (0x2744 + (port<<10)) +#define MV643XX_ETH_TX_QUEUE_5_TOKEN_BUCKET_CONFIG(port) (0x2754 + (port<<10)) +#define MV643XX_ETH_TX_QUEUE_6_TOKEN_BUCKET_CONFIG(port) (0x2764 + (port<<10)) +#define MV643XX_ETH_TX_QUEUE_7_TOKEN_BUCKET_CONFIG(port) (0x2774 + (port<<10)) +#define MV643XX_ETH_TX_QUEUE_0_ARBITER_CONFIG(port) (0x2708 + (port<<10)) +#define MV643XX_ETH_TX_QUEUE_1_ARBITER_CONFIG(port) (0x2718 + (port<<10)) +#define MV643XX_ETH_TX_QUEUE_2_ARBITER_CONFIG(port) (0x2728 + (port<<10)) +#define MV643XX_ETH_TX_QUEUE_3_ARBITER_CONFIG(port) (0x2738 + (port<<10)) +#define MV643XX_ETH_TX_QUEUE_4_ARBITER_CONFIG(port) (0x2748 + (port<<10)) +#define MV643XX_ETH_TX_QUEUE_5_ARBITER_CONFIG(port) (0x2758 + (port<<10)) +#define MV643XX_ETH_TX_QUEUE_6_ARBITER_CONFIG(port) (0x2768 + (port<<10)) +#define MV643XX_ETH_TX_QUEUE_7_ARBITER_CONFIG(port) (0x2778 + (port<<10)) +#define MV643XX_ETH_PORT_TX_TOKEN_BUCKET_COUNT(port) (0x2780 + (port<<10)) +#define MV643XX_ETH_DA_FILTER_SPECIAL_MULTICAST_TABLE_BASE(port) (0x3400 + (port<<10)) +#define MV643XX_ETH_DA_FILTER_OTHER_MULTICAST_TABLE_BASE(port) (0x3500 + (port<<10)) +#define MV643XX_ETH_DA_FILTER_UNICAST_TABLE_BASE(port) (0x3600 + (port<<10)) /*******************************************/ /* CUNIT Registers */ @@ -1090,4 +1093,221 @@ u32 retries; }; -#endif /* __ASM_MV64340_H */ +/* These macros describe Ethernet Port configuration reg (Px_cR) bits */ +#define MV643XX_ETH_UNICAST_NORMAL_MODE 0 +#define MV643XX_ETH_UNICAST_PROMISCUOUS_MODE (1<<0) +#define MV643XX_ETH_DEFAULT_RX_QUEUE_0 0 +#define MV643XX_ETH_DEFAULT_RX_QUEUE_1 (1<<1) +#define MV643XX_ETH_DEFAULT_RX_QUEUE_2 (1<<2) +#define MV643XX_ETH_DEFAULT_RX_QUEUE_3 ((1<<2) | (1<<1)) +#define MV643XX_ETH_DEFAULT_RX_QUEUE_4 (1<<3) +#define MV643XX_ETH_DEFAULT_RX_QUEUE_5 ((1<<3) | (1<<1)) +#define MV643XX_ETH_DEFAULT_RX_QUEUE_6 ((1<<3) | (1<<2)) +#define MV643XX_ETH_DEFAULT_RX_QUEUE_7 ((1<<3) | (1<<2) | (1<<1)) +#define MV643XX_ETH_DEFAULT_RX_ARP_QUEUE_0 0 +#define MV643XX_ETH_DEFAULT_RX_ARP_QUEUE_1 (1<<4) +#define MV643XX_ETH_DEFAULT_RX_ARP_QUEUE_2 (1<<5) +#define MV643XX_ETH_DEFAULT_RX_ARP_QUEUE_3 ((1<<5) | (1<<4)) +#define MV643XX_ETH_DEFAULT_RX_ARP_QUEUE_4 (1<<6) +#define MV643XX_ETH_DEFAULT_RX_ARP_QUEUE_5 ((1<<6) | (1<<4)) +#define MV643XX_ETH_DEFAULT_RX_ARP_QUEUE_6 ((1<<6) | (1<<5)) +#define MV643XX_ETH_DEFAULT_RX_ARP_QUEUE_7 ((1<<6) | (1<<5) | (1<<4)) +#define MV643XX_ETH_RECEIVE_BC_IF_NOT_IP_OR_ARP 0 +#define MV643XX_ETH_REJECT_BC_IF_NOT_IP_OR_ARP (1<<7) +#define MV643XX_ETH_RECEIVE_BC_IF_IP 0 +#define MV643XX_ETH_REJECT_BC_IF_IP (1<<8) +#define MV643XX_ETH_RECEIVE_BC_IF_ARP 0 +#define MV643XX_ETH_REJECT_BC_IF_ARP (1<<9) +#define MV643XX_ETH_TX_AM_NO_UPDATE_ERROR_SUMMARY (1<<12) +#define MV643XX_ETH_CAPTURE_TCP_FRAMES_DIS 0 +#define MV643XX_ETH_CAPTURE_TCP_FRAMES_EN (1<<14) +#define MV643XX_ETH_CAPTURE_UDP_FRAMES_DIS 0 +#define MV643XX_ETH_CAPTURE_UDP_FRAMES_EN (1<<15) +#define MV643XX_ETH_DEFAULT_RX_TCP_QUEUE_0 0 +#define MV643XX_ETH_DEFAULT_RX_TCP_QUEUE_1 (1<<16) +#define MV643XX_ETH_DEFAULT_RX_TCP_QUEUE_2 (1<<17) +#define MV643XX_ETH_DEFAULT_RX_TCP_QUEUE_3 ((1<<17) | (1<<16)) +#define MV643XX_ETH_DEFAULT_RX_TCP_QUEUE_4 (1<<18) +#define MV643XX_ETH_DEFAULT_RX_TCP_QUEUE_5 ((1<<18) | (1<<16)) +#define MV643XX_ETH_DEFAULT_RX_TCP_QUEUE_6 ((1<<18) | (1<<17)) +#define MV643XX_ETH_DEFAULT_RX_TCP_QUEUE_7 ((1<<18) | (1<<17) | (1<<16)) +#define MV643XX_ETH_DEFAULT_RX_UDP_QUEUE_0 0 +#define MV643XX_ETH_DEFAULT_RX_UDP_QUEUE_1 (1<<19) +#define MV643XX_ETH_DEFAULT_RX_UDP_QUEUE_2 (1<<20) +#define MV643XX_ETH_DEFAULT_RX_UDP_QUEUE_3 ((1<<20) | (1<<19)) +#define MV643XX_ETH_DEFAULT_RX_UDP_QUEUE_4 ((1<<21) +#define MV643XX_ETH_DEFAULT_RX_UDP_QUEUE_5 ((1<<21) | (1<<19)) +#define MV643XX_ETH_DEFAULT_RX_UDP_QUEUE_6 ((1<<21) | (1<<20)) +#define MV643XX_ETH_DEFAULT_RX_UDP_QUEUE_7 ((1<<21) | (1<<20) | (1<<19)) +#define MV643XX_ETH_DEFAULT_RX_BPDU_QUEUE_0 0 +#define MV643XX_ETH_DEFAULT_RX_BPDU_QUEUE_1 (1<<22) +#define MV643XX_ETH_DEFAULT_RX_BPDU_QUEUE_2 (1<<23) +#define MV643XX_ETH_DEFAULT_RX_BPDU_QUEUE_3 ((1<<23) | (1<<22)) +#define MV643XX_ETH_DEFAULT_RX_BPDU_QUEUE_4 (1<<24) +#define MV643XX_ETH_DEFAULT_RX_BPDU_QUEUE_5 ((1<<24) | (1<<22)) +#define MV643XX_ETH_DEFAULT_RX_BPDU_QUEUE_6 ((1<<24) | (1<<23)) +#define MV643XX_ETH_DEFAULT_RX_BPDU_QUEUE_7 ((1<<24) | (1<<23) | (1<<22)) + +#define MV643XX_ETH_PORT_CONFIG_DEFAULT_VALUE \ + MV643XX_ETH_UNICAST_NORMAL_MODE | \ + MV643XX_ETH_DEFAULT_RX_QUEUE_0 | \ + MV643XX_ETH_DEFAULT_RX_ARP_QUEUE_0 | \ + MV643XX_ETH_RECEIVE_BC_IF_NOT_IP_OR_ARP | \ + MV643XX_ETH_RECEIVE_BC_IF_IP | \ + MV643XX_ETH_RECEIVE_BC_IF_ARP | \ + MV643XX_ETH_CAPTURE_TCP_FRAMES_DIS | \ + MV643XX_ETH_CAPTURE_UDP_FRAMES_DIS | \ + MV643XX_ETH_DEFAULT_RX_TCP_QUEUE_0 | \ + MV643XX_ETH_DEFAULT_RX_UDP_QUEUE_0 | \ + MV643XX_ETH_DEFAULT_RX_BPDU_QUEUE_0 + +/* These macros describe Ethernet Port configuration extend reg (Px_cXR) bits*/ +#define MV643XX_ETH_CLASSIFY_EN (1<<0) +#define MV643XX_ETH_SPAN_BPDU_PACKETS_AS_NORMAL 0 +#define MV643XX_ETH_SPAN_BPDU_PACKETS_TO_RX_QUEUE_7 (1<<1) +#define MV643XX_ETH_PARTITION_DISABLE 0 +#define MV643XX_ETH_PARTITION_ENABLE (1<<2) + +#define MV643XX_ETH_PORT_CONFIG_EXTEND_DEFAULT_VALUE \ + MV643XX_ETH_SPAN_BPDU_PACKETS_AS_NORMAL | \ + MV643XX_ETH_PARTITION_DISABLE + +/* These macros describe Ethernet Port Sdma configuration reg (SDCR) bits */ +#define MV643XX_ETH_RIFB (1<<0) +#define MV643XX_ETH_RX_BURST_SIZE_1_64BIT 0 +#define MV643XX_ETH_RX_BURST_SIZE_2_64BIT (1<<1) +#define MV643XX_ETH_RX_BURST_SIZE_4_64BIT (1<<2) +#define MV643XX_ETH_RX_BURST_SIZE_8_64BIT ((1<<2) | (1<<1)) +#define MV643XX_ETH_RX_BURST_SIZE_16_64BIT (1<<3) +#define MV643XX_ETH_BLM_RX_NO_SWAP (1<<4) +#define MV643XX_ETH_BLM_RX_BYTE_SWAP 0 +#define MV643XX_ETH_BLM_TX_NO_SWAP (1<<5) +#define MV643XX_ETH_BLM_TX_BYTE_SWAP 0 +#define MV643XX_ETH_DESCRIPTORS_BYTE_SWAP (1<<6) +#define MV643XX_ETH_DESCRIPTORS_NO_SWAP 0 +#define MV643XX_ETH_TX_BURST_SIZE_1_64BIT 0 +#define MV643XX_ETH_TX_BURST_SIZE_2_64BIT (1<<22) +#define MV643XX_ETH_TX_BURST_SIZE_4_64BIT (1<<23) +#define MV643XX_ETH_TX_BURST_SIZE_8_64BIT ((1<<23) | (1<<22)) +#define MV643XX_ETH_TX_BURST_SIZE_16_64BIT (1<<24) + +#define MV643XX_ETH_IPG_INT_RX(value) ((value & 0x3fff) << 8) + +#define MV643XX_ETH_PORT_SDMA_CONFIG_DEFAULT_VALUE \ + MV643XX_ETH_RX_BURST_SIZE_4_64BIT | \ + MV643XX_ETH_IPG_INT_RX(0) | \ + MV643XX_ETH_TX_BURST_SIZE_4_64BIT + +/* These macros describe Ethernet Port serial control reg (PSCR) bits */ +#define MV643XX_ETH_SERIAL_PORT_DISABLE 0 +#define MV643XX_ETH_SERIAL_PORT_ENABLE (1<<0) +#define MV643XX_ETH_FORCE_LINK_PASS (1<<1) +#define MV643XX_ETH_DO_NOT_FORCE_LINK_PASS 0 +#define MV643XX_ETH_ENABLE_AUTO_NEG_FOR_DUPLX 0 +#define MV643XX_ETH_DISABLE_AUTO_NEG_FOR_DUPLX (1<<2) +#define MV643XX_ETH_ENABLE_AUTO_NEG_FOR_FLOW_CTRL 0 +#define MV643XX_ETH_DISABLE_AUTO_NEG_FOR_FLOW_CTRL (1<<3) +#define MV643XX_ETH_ADV_NO_FLOW_CTRL 0 +#define MV643XX_ETH_ADV_SYMMETRIC_FLOW_CTRL (1<<4) +#define MV643XX_ETH_FORCE_FC_MODE_NO_PAUSE_DIS_TX 0 +#define MV643XX_ETH_FORCE_FC_MODE_TX_PAUSE_DIS (1<<5) +#define MV643XX_ETH_FORCE_BP_MODE_NO_JAM 0 +#define MV643XX_ETH_FORCE_BP_MODE_JAM_TX (1<<7) +#define MV643XX_ETH_FORCE_BP_MODE_JAM_TX_ON_RX_ERR (1<<8) +#define MV643XX_ETH_FORCE_LINK_FAIL 0 +#define MV643XX_ETH_DO_NOT_FORCE_LINK_FAIL (1<<10) +#define MV643XX_ETH_RETRANSMIT_16_ATTEMPTS 0 +#define MV643XX_ETH_RETRANSMIT_FOREVER (1<<11) +#define MV643XX_ETH_DISABLE_AUTO_NEG_SPEED_GMII (1<<13) +#define MV643XX_ETH_ENABLE_AUTO_NEG_SPEED_GMII 0 +#define MV643XX_ETH_DTE_ADV_0 0 +#define MV643XX_ETH_DTE_ADV_1 (1<<14) +#define MV643XX_ETH_DISABLE_AUTO_NEG_BYPASS 0 +#define MV643XX_ETH_ENABLE_AUTO_NEG_BYPASS (1<<15) +#define MV643XX_ETH_AUTO_NEG_NO_CHANGE 0 +#define MV643XX_ETH_RESTART_AUTO_NEG (1<<16) +#define MV643XX_ETH_MAX_RX_PACKET_1518BYTE 0 +#define MV643XX_ETH_MAX_RX_PACKET_1522BYTE (1<<17) +#define MV643XX_ETH_MAX_RX_PACKET_1552BYTE (1<<18) +#define MV643XX_ETH_MAX_RX_PACKET_9022BYTE ((1<<18) | (1<<17)) +#define MV643XX_ETH_MAX_RX_PACKET_9192BYTE (1<<19) +#define MV643XX_ETH_MAX_RX_PACKET_9700BYTE ((1<<19) | (1<<17)) +#define MV643XX_ETH_SET_EXT_LOOPBACK (1<<20) +#define MV643XX_ETH_CLR_EXT_LOOPBACK 0 +#define MV643XX_ETH_SET_FULL_DUPLEX_MODE (1<<21) +#define MV643XX_ETH_SET_HALF_DUPLEX_MODE 0 +#define MV643XX_ETH_ENABLE_FLOW_CTRL_TX_RX_IN_FULL_DUPLEX (1<<22) +#define MV643XX_ETH_DISABLE_FLOW_CTRL_TX_RX_IN_FULL_DUPLEX 0 +#define MV643XX_ETH_SET_GMII_SPEED_TO_10_100 0 +#define MV643XX_ETH_SET_GMII_SPEED_TO_1000 (1<<23) +#define MV643XX_ETH_SET_MII_SPEED_TO_10 0 +#define MV643XX_ETH_SET_MII_SPEED_TO_100 (1<<24) + +#define MV643XX_ETH_PORT_SERIAL_CONTROL_DEFAULT_VALUE \ + MV643XX_ETH_DO_NOT_FORCE_LINK_PASS | \ + MV643XX_ETH_ENABLE_AUTO_NEG_FOR_DUPLX | \ + MV643XX_ETH_DISABLE_AUTO_NEG_FOR_FLOW_CTRL | \ + MV643XX_ETH_ADV_SYMMETRIC_FLOW_CTRL | \ + MV643XX_ETH_FORCE_FC_MODE_NO_PAUSE_DIS_TX | \ + MV643XX_ETH_FORCE_BP_MODE_NO_JAM | \ + (1<<9) /* reserved */ | \ + MV643XX_ETH_DO_NOT_FORCE_LINK_FAIL | \ + MV643XX_ETH_RETRANSMIT_16_ATTEMPTS | \ + MV643XX_ETH_ENABLE_AUTO_NEG_SPEED_GMII | \ + MV643XX_ETH_DTE_ADV_0 | \ + MV643XX_ETH_DISABLE_AUTO_NEG_BYPASS | \ + MV643XX_ETH_AUTO_NEG_NO_CHANGE | \ + MV643XX_ETH_MAX_RX_PACKET_9700BYTE | \ + MV643XX_ETH_CLR_EXT_LOOPBACK | \ + MV643XX_ETH_SET_FULL_DUPLEX_MODE | \ + MV643XX_ETH_ENABLE_FLOW_CTRL_TX_RX_IN_FULL_DUPLEX + +/* These macros describe Ethernet Serial Status reg (PSR) bits */ +#define MV643XX_ETH_PORT_STATUS_MODE_10_BIT (1<<0) +#define MV643XX_ETH_PORT_STATUS_LINK_UP (1<<1) +#define MV643XX_ETH_PORT_STATUS_FULL_DUPLEX (1<<2) +#define MV643XX_ETH_PORT_STATUS_FLOW_CONTROL (1<<3) +#define MV643XX_ETH_PORT_STATUS_GMII_1000 (1<<4) +#define MV643XX_ETH_PORT_STATUS_MII_100 (1<<5) +/* PSR bit 6 is undocumented */ +#define MV643XX_ETH_PORT_STATUS_TX_IN_PROGRESS (1<<7) +#define MV643XX_ETH_PORT_STATUS_AUTONEG_BYPASSED (1<<8) +#define MV643XX_ETH_PORT_STATUS_PARTITION (1<<9) +#define MV643XX_ETH_PORT_STATUS_TX_FIFO_EMPTY (1<<10) +/* PSR bits 11-31 are reserved */ + +#define MV643XX_ETH_PORT_DEFAULT_TRANSMIT_QUEUE_SIZE 800 +#define MV643XX_ETH_PORT_DEFAULT_RECEIVE_QUEUE_SIZE 400 + +#define MV643XX_ETH_DESC_SIZE 64 + +#define MV643XX_ETH_SHARED_NAME "mv643xx_eth_shared" +#define MV643XX_ETH_NAME "mv643xx_eth" + +struct mv643xx_eth_platform_data { + /* + * Non-values for mac_addr, phy_addr, port_config, etc. + * override the default value. Setting the corresponding + * force_* field, causes the default value to be overridden + * even when zero. + */ + unsigned int force_phy_addr:1; + unsigned int force_port_config:1; + unsigned int force_port_config_extend:1; + unsigned int force_port_sdma_config:1; + unsigned int force_port_serial_control:1; + int phy_addr; + char *mac_addr; /* pointer to mac address */ + u32 port_config; + u32 port_config_extend; + u32 port_sdma_config; + u32 port_serial_control; + u32 tx_queue_size; + u32 rx_queue_size; + u32 tx_sram_addr; + u32 tx_sram_size; + u32 rx_sram_addr; + u32 rx_sram_size; +}; + +#endif /* __ASM_MV643XX_H */ --------------040800020201020107010706-- From akpm@osdl.org Tue Mar 8 11:49:29 2005 Received: with ECARTIS (v1.0.0; list netdev); Tue, 08 Mar 2005 11:49:35 -0800 (PST) Received: from smtp.osdl.org (fire.osdl.org [65.172.181.4]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j28JnTq2026096 for ; Tue, 8 Mar 2005 11:49:29 -0800 Received: from shell0.pdx.osdl.net (fw.osdl.org [65.172.181.6]) by smtp.osdl.org (8.12.8/8.12.8) with ESMTP id j28JnGqi029466 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO); Tue, 8 Mar 2005 11:49:19 -0800 Received: from bix (shell0.pdx.osdl.net [10.9.0.31]) by shell0.pdx.osdl.net (8.13.1/8.11.6) with SMTP id j28JnFqv020871; Tue, 8 Mar 2005 11:49:16 -0800 Date: Tue, 8 Mar 2005 11:48:51 -0800 From: Andrew Morton To: oray@lucent.com Cc: linuxppc-dev@ozlabs.org, netdev@oss.sgi.com Subject: Re: [Bugme-new] [Bug 4310] New: ppc 8260 fcc ethernet driver cannot read LXT971 PHY id Message-Id: <20050308114851.1f997476.akpm@osdl.org> In-Reply-To: <200503081415.j28EF9CG002475@fire-1.osdl.org> References: <200503081415.j28EF9CG002475@fire-1.osdl.org> X-Mailer: Sylpheed version 0.9.7 (GTK+ 1.2.10; i386-redhat-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Received-SPF: pass (domain of akpm@osdl.org designates 65.172.181.6 as permitted sender) X-MIMEDefang-Filter: osdl$Revision: 1.104 $ X-Scanned-By: MIMEDefang 2.36 X-Virus-Scanned: ClamAV 0.83/755/Mon Mar 7 17:00:18 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 2676 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: akpm@osdl.org Precedence: bulk X-list: netdev Content-Length: 2201 Lines: 55 I'm not sure that we have a maintainer for fcc_enet.c. Could you please send in a tested diff? bugme-daemon@osdl.org wrote: > > http://bugme.osdl.org/show_bug.cgi?id=4310 > > Summary: ppc 8260 fcc ethernet driver cannot read LXT971 PHY id > Kernel Version: 2.6.10 > Status: NEW > Severity: normal > Owner: platform_ppc-32@kernel-bugs.osdl.org > Submitter: oray@lucent.com > > > Distribution: www.kernel.org > Hardware Environment: Target: PowerPC 8260 custom board > Software Environment: Red Hat 9 cross development using ELDK 3.1 distribution. > Problem Description: Fast ethernet driver (fcc_enet.c) initialization fails to > read a valid id from registers 2 and 3 of the LXT971 PHY device and calls the > panic routine. The bug is in the mii_send_receive() function. During the read > phase, per LXT971 data sheet, the device starts driving the MDIO line after the > rising edge of the MDC clock and it could take up to 150ns before the data > settles. The driver reads the MDIO line before waiting for the data to settle > down and thus reads in garbage. I fixed the problem by moving the sampling of > the MDIO line to after the MDC clock is taken low. The code snippet follows: > > > for (i = 0, off = 15; i < 16; i++, off--) > { > #define FCC_8260_BUG > FCC_PDATC_MDC(1); > retval <<= 1; > #ifndef FCC_8260_BUG > if (io->iop_pdatc & fip->fc_mdio) > retval++; > udelay(1); > FCC_PDATC_MDC(0); > #else > udelay(1); > FCC_PDATC_MDC(0); > if (io->iop_pdatc & fip->fc_mdio) > retval++; > #endif > udelay(1); > #undef FCC_8260_BUG > } > > > Steps to reproduce: Is likely to happen on an 8260 target with any kind of PHY, > not just the LXT971, hooked up to the FCC port. > > ------- You are receiving this mail because: ------- > You are on the CC list for the bug, or are watching someone who is. From hadi@cyberus.ca Tue Mar 8 13:17:24 2005 Received: with ECARTIS (v1.0.0; list netdev); Tue, 08 Mar 2005 13:17:31 -0800 (PST) Received: from mx02.cybersurf.com (mx02.cybersurf.com [209.197.145.105]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j28LHMsQ000840 for ; Tue, 8 Mar 2005 13:17:23 -0800 Received: from mail.cyberus.ca ([209.197.145.21]) by mx02.cybersurf.com with esmtp (Exim 4.30) id 1D8m4u-0005Tg-Qz for netdev@oss.sgi.com; Tue, 08 Mar 2005 16:17:20 -0500 Received: from [216.209.86.2] (helo=[10.0.0.9]) by mail.cyberus.ca with esmtp (Exim 4.20) id 1D8m4p-0008Em-2y; Tue, 08 Mar 2005 16:17:15 -0500 Subject: Re: Do you know the TCP stack? (127.x.x.x routing) From: jamal Reply-To: hadi@cyberus.ca To: Henrik Nordstrom Cc: Martin Mares , Zdenek Radouch , Steve Iribarne , Eran Mann , Thomas Graf , Andi Kleen , netdev@oss.sgi.com, linux-net@vger.kernel.org In-Reply-To: References: <20050306173145.GQ31837@postel.suug.ch> <3sp35g$7hpm0@smtp04.mrf.mail.rcn.net> <422C0B50.20500@mrv.com> <3sp35g$7rsc1@smtp04.mrf.mail.rcn.net> <1110288879.1050.167.camel@jzny.localdomain> <20050308135134.GA20607@atrey.karlin.mff.cuni.cz> <1110290300.1050.190.camel@jzny.localdomain> <20050308140301.GC20607@atrey.karlin.mff.cuni.cz> <1110291470.1043.211.camel@jzny.localdomain> Content-Type: text/plain Organization: jamalopolous Message-Id: <1110316631.1084.57.camel@jzny.localdomain> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.2.2 Date: 08 Mar 2005 16:17:11 -0500 Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV 0.83/755/Mon Mar 7 17:00:18 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 2677 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: hadi@cyberus.ca Precedence: bulk X-list: netdev Content-Length: 1346 Lines: 33 On Tue, 2005-03-08 at 13:40, Henrik Nordstrom wrote: [..] > Not if the 127.X addresses never leaves the Zdenek's boxes, when thinking > in terms that each set of boxes communicating using 127.X addresses is a > single chassis, seen as a single box to the network admin. > Henrik, so what is the difference between this and using any random block of addresses?;-> If the packets never leave the box i can use IBM's block of addresses if i wanted - no need to sweat this far (with hacking the kernel). If Zdenek is going to put more than one box then theres nothing magical; he will have to sit down and configure one of the boxes manually - no escape there. If he puts only a single box then he may likely get away with it. > > Except this wont be practical for IPV4 since those addresses are scarce. > > May make sense for V6 though (becomes like MAC addresses on NICS). > > IPv6 already have link local addressing IIRC. > indeed that is what is needed in this case if the problem is address conflict resolution. An equivalent for v4 (called zeroconf) is at: http://www.zeroconf.org/ It is unfortunate though because Apple has been claiming it has patented this v4 linklocal scheme - and if i recall the person who wrote the Linux code eventually took it off their web page (cant even seem to find the web page anymore). cheers, jamal From hadi@cyberus.ca Tue Mar 8 13:43:57 2005 Received: with ECARTIS (v1.0.0; list netdev); Tue, 08 Mar 2005 13:44:04 -0800 (PST) Received: from mx03.cybersurf.com (mx03.cybersurf.com [209.197.145.106]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j28LhsX1002375 for ; Tue, 8 Mar 2005 13:43:57 -0800 Received: from mail.cyberus.ca ([209.197.145.21]) by mx03.cybersurf.com with esmtp (Exim 4.30) id 1D8mUa-00041j-19 for netdev@oss.sgi.com; Tue, 08 Mar 2005 16:43:52 -0500 Received: from [216.209.86.2] (helo=[10.0.0.9]) by mail.cyberus.ca with esmtp (Exim 4.20) id 1D8mUS-00045b-VA; Tue, 08 Mar 2005 16:43:45 -0500 Subject: Re: [leo@yuriev.ru: [PATCH] ethernet-bridge: update skb->priority in case forwarded frame has VLAN-header] From: jamal Reply-To: hadi@cyberus.ca To: Ben Greear Cc: Patrick McHardy , leo@yuriev.ru, Lennert Buytenhek , shemminger@osdl.org, netdev@oss.sgi.com In-Reply-To: <422DE4B0.6040201@candelatech.com> References: <20050305141225.GA5180@xi.wantstofly.org> <4229D98F.9010008@trash.net> <422A0C21.3050709@candelatech.com> <1110199696.1094.1299.camel@jzny.localdomain> <1110238537.1043.62.camel@jzny.localdomain> <422CE983.7060305@trash.net> <1110241190.1043.100.camel@jzny.localdomain> <422D1E26.1010902@trash.net> <1110287626.1043.146.camel@jzny.localdomain> <422DE4B0.6040201@candelatech.com> Content-Type: text/plain Organization: jamalopolous Message-Id: <1110318221.1078.80.camel@jzny.localdomain> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.2.2 Date: 08 Mar 2005 16:43:41 -0500 Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV 0.83/755/Mon Mar 7 17:00:18 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 2678 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: hadi@cyberus.ca Precedence: bulk X-list: netdev Content-Length: 709 Lines: 22 On Tue, 2005-03-08 at 12:45, Ben Greear wrote: [..] > jamal wrote: > > I think you still want (perhaps the vlan) driver to come up with some > > sane defaults. From what i read from bgrear he has arbitrary values. > > By default, everything is mapped to priority of zero, but the user can > specify a mapping to any integer they desire. > > If you have some suggestions for some defaults better than zero, I'm > willing to consider it. > Everything going to zero may not be such a bad default. You could do better by creating a map that resembles what the default 3 band scheduler does. Just keep in mind that the reverse semantics of priorities. If you need help we can take it offline. cheers, jamal From hadi@cyberus.ca Tue Mar 8 14:02:11 2005 Received: with ECARTIS (v1.0.0; list netdev); Tue, 08 Mar 2005 14:02:15 -0800 (PST) Received: from mx02.cybersurf.com (mx02.cybersurf.com [209.197.145.105]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j28M2AX8005831 for ; Tue, 8 Mar 2005 14:02:11 -0800 Received: from mail.cyberus.ca ([209.197.145.21]) by mx02.cybersurf.com with esmtp (Exim 4.30) id 1D8mmG-0001Qf-Qj for netdev@oss.sgi.com; Tue, 08 Mar 2005 17:02:08 -0500 Received: from [216.209.86.2] (helo=[10.0.0.9]) by mail.cyberus.ca with esmtp (Exim 4.20) id 1D8mmC-0006g8-Kj; Tue, 08 Mar 2005 17:02:04 -0500 Subject: Re: netif_rx packet dumping From: jamal Reply-To: hadi@cyberus.ca To: Baruch Even Cc: Stephen Hemminger , John Heffner , "David S. Miller" , rhee@eos.ncsu.edu, Yee-Ting.Li@nuim.ie, netdev@oss.sgi.com In-Reply-To: <422DCB14.1040805@ev-en.org> References: <20050303123811.4d934249@dxpl.pdx.osdl.net> <20050303125556.6850cfe5.davem@davemloft.net> <1109884688.1090.282.camel@jzny.localdomain> <20050303132143.7eef517c@dxpl.pdx.osdl.net> <1109885065.1098.285.camel@jzny.localdomain> <20050303133237.5d64578f.davem@davemloft.net> <20050303135416.0d6e7708@dxpl.pdx.osdl.net> <1109888811.1092.352.camel@jzny.localdomain> <20050303151606.3587394f@dxpl.pdx.osdl.net> <4227A23C.5050300@ev-en.org> <1109907956.1092.476.camel@jzny.localdomain> <42282098.8010506@ev-en.org> <1110203711.1088.1393.camel@jzny.localdomain> <422DCB14.1040805@ev-en.org> Content-Type: multipart/mixed; boundary="=-6YeoS9RYbwAs2WPMZJ1Y" Organization: jamalopolous Message-Id: <1110319320.1078.97.camel@jzny.localdomain> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.2.2 Date: 08 Mar 2005 17:02:01 -0500 X-Virus-Scanned: ClamAV 0.83/755/Mon Mar 7 17:00:18 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 2679 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: hadi@cyberus.ca Precedence: bulk X-list: netdev Content-Length: 5497 Lines: 142 --=-6YeoS9RYbwAs2WPMZJ1Y Content-Type: text/plain Content-Transfer-Encoding: 7bit On Tue, 2005-03-08 at 10:56, Baruch Even wrote: > jamal wrote: > > > > Were the processors tied to NICs? > > No. These are single CPU machines (with HT). > You have SMP. > > In other words the whole queue was infact dedicated just for your one > > flow - thats why you can call this queue a transient burst queue. > > Indeed, For a router or a web server handling several thousand flows it > might be different, but I don't expect it handles a single packet in one > ms (or more) as it happens for the current end-system ack handling code. > I think it would be interesting as well to see more than one flow; maybe go upto 16 (1, 2, 4, 8, 16) and if theres anything to observe you should see it. > > Do you still have the data that shows how many packets were dropped > > during this period. Do you still have the experimental data? I am > > particulary interested in seeing the softnet stats as well as tcp > > netstats. > > No, These tests were not run by me, I'll probably rerun similar tests as > well to base my work on, send me in private how do I get the stats from > the kernel and I'll add it to my test scripts. > I will be more than happy to help. Let me know when you are ready. > > I think your main problem was the huge amounts of SACK on the writequeue > > and the resultant processing i.e section 1.1 and how you resolved that. > > That is my main guess as well, the original work was done rather > quickly, we are now reorganizing thoughts and redoing the tests in a > more orderly fashion. > I have attached the little patch i forgot to last time where you can adjust. Adjust the lo_cong parameter in /proc to tune the number of packets in which the congestion valve gets opened. Make sure you are within range of the other parameters like no_cong etc. Or you can change that check to be using no_cong instead. > > I dont see any issue in dropping ACKs, many of them even for such large > > windows as you have - TCPs ACKs are cummulative. It is true if you drop > > "large" enough amounts of ACKS, you will end up in timeouts - but large > > enough in your case must be in the minimal 1000 packets. And to say you > > dropped a 1000 packets while processing 300 means you were taking too > > long processing the 300. > > With the current code SACK processing takes a long time, so it is > possible that it happened to drop more than a thousand packets while > handling 300. I think that after the fixing of the SACK code, the rest > might work without getting to much into the ingress queue. But that > might still change when we go to even higher speeds. > Sure. I am not questioning fixing the SACK code - I dont think it was envisioned that someone was going to have 1000 outstanding SACKs in _one_ flow. But an interesting test case would be to fix the SACK processing then retest without getting rid of the congestion valve. Again, shall i repeat you really should be using NAPI? ;-> > > Then what would be really interesting is to see the perfomance you get > > from multiple flows with and without congestion. > > We'd need to get a very high speed link for multiple high speed flows. > Get a couple of PCs and hook them back to back. > > I am not against a the benchmarky nature of the single flow and tuning > > for that, but we should also look at a wider scope at the effect before > > you handwave based on the result of one testcase. > > I can't say I didn't handwave, but then, there is little experimentation > done to see if the other claims are correct and that AFQ is really > needed so early in the packet receive stage. There are also voices that > say AFQ sucks and causes more damage than good, I don't remember details > currently. > Its not totaly AFQ, The idea is that code is measuring (based on history) how busy the system is. What Stephen and I were discussing is that you may wanna totaly punish new flows coming in instead of the one flow that already is flowing when the going gets tough (i.e congestion detected). However, this maybe too big unneeded a hack when we have NAPI which will do just fine for you. > > So if i was you i would repeat 1.2 with the fix from 1.1 as well as > > tying the NIC to one CPU. And it would be a good idea to present more > > detailed results - not just tcp windows fluctuating (you may not need > > them for the paper, but would be useful to see for debugging purposes > > other parameters). > > I'd be happy to hear what other benchmarks you would like to see, I > currently intend to add some ack processing time analysis and oprofile > information. With possibly showing the size of the ingress queue as a > measure as well. > > Making it as thorough as possible is one of my goals. Input is always > welcome. > Good - and thanks for not being defensive; your work can only get better this way. Ping me when you have ported to 2.6.11 and are ready to do the testing. cheers, jamal --=-6YeoS9RYbwAs2WPMZJ1Y Content-Disposition: attachment; filename=cong_p Content-Type: text/plain; name=cong_p; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit --- 2611-mod/net/core/dev.c 2005/03/07 12:26:21 1.1 +++ 2611-mod/net/core/dev.c 2005/03/07 12:30:19 @@ -1742,6 +1742,9 @@ if (work >= quota || jiffies - start_time > 1) break; + if (queue->throttle && work >= lo_cong) + queue->throttle = 0; + } backlog_dev->quota -= work; --=-6YeoS9RYbwAs2WPMZJ1Y-- From shemminger@osdl.org Tue Mar 8 14:08:26 2005 Received: with ECARTIS (v1.0.0; list netdev); Tue, 08 Mar 2005 14:08:30 -0800 (PST) Received: from smtp.osdl.org (fire.osdl.org [65.172.181.4]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j28M8QR1006503 for ; Tue, 8 Mar 2005 14:08:26 -0800 Received: from shell0.pdx.osdl.net (fw.osdl.org [65.172.181.6]) by smtp.osdl.org (8.12.8/8.12.8) with ESMTP id j28M89qi009316 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO); Tue, 8 Mar 2005 14:08:12 -0800 Received: from dxpl.pdx.osdl.net (dxpl.pdx.osdl.net [172.20.1.103]) by shell0.pdx.osdl.net (8.13.1/8.11.6) with ESMTP id j28M893Y027567; Tue, 8 Mar 2005 14:08:09 -0800 Date: Tue, 8 Mar 2005 14:08:26 -0800 From: Stephen Hemminger To: Robert Olsson Cc: netdev@oss.sgi.com Subject: pktgen: causing lots of errors in console log Message-ID: <20050308140826.451435e5@dxpl.pdx.osdl.net> Organization: Open Source Development Lab X-Mailer: Sylpheed-Claws 1.0.1 (GTK+ 1.2.10; x86_64-unknown-linux-gnu) X-Face: &@E+xe?c%:&e4D{>f1O<&U>2qwRREG5!}7R4;D<"NO^UI2mJ[eEOA2*3>(`Th.yP,VDPo9$ /`~cw![cmj~~jWe?AHY7D1S+\}5brN0k*NE?pPh_'_d>6;XGG[\KDRViCfumZT3@[ Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Received-SPF: pass (domain of shemminger@osdl.org designates 65.172.181.6 as permitted sender) X-MIMEDefang-Filter: osdl$Revision: 1.104 $ X-Scanned-By: MIMEDefang 2.36 X-Virus-Scanned: ClamAV 0.83/755/Mon Mar 7 17:00:18 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 2680 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: shemminger@osdl.org Precedence: bulk X-list: netdev Content-Length: 1012 Lines: 28 Getting two types of console messages when using pktgen and 2.6.11 and the pktgen-conf-1-1 script. 1. Errors from IPV4 KERNEL: assertion (!idev->ifa_list) failed at net/ipv4/devinet.c (122) KERNEL: assertion (!idev->mc_list) failed at net/ipv4/devinet.c (123) Freeing alive in_device ffff81007e96a400 2. Cliff is getting this with e1000 and pktgen-conf-1-2 looks like calling schedule_timeout with lock held. scheduling while atomic: pktgen.conf-2-1/0x00000001/3772 [] schedule+0x672/0x680 [] dnotify_parent+0x3a/0xb0 [] _spin_lock+0x16/0x90 [] _spin_unlock_irqrestore+0xf/0x30 [] __mod_timer+0xe9/0x130 [] schedule_timeout+0x72/0xd0 [] process_timeout+0x0/0x10 [] _spin_lock+0x16/0x90 [] proc_thread_write+0x20a/0x2f0 [pktgen] [] _spin_lock+0x16/0x90 [] proc_file_write+0x37/0x50 [] vfs_write+0xae/0x130 [] sys_write+0x51/0x80 [] syscall_call+0x7/0xb From ak@muc.de Tue Mar 8 14:16:38 2005 Received: with ECARTIS (v1.0.0; list netdev); Tue, 08 Mar 2005 14:16:43 -0800 (PST) Received: from colin2.muc.de (qmailr@colin2.muc.de [193.149.48.15]) by oss.sgi.com (8.13.0/8.13.0) with SMTP id j28MGbxK007416 for ; Tue, 8 Mar 2005 14:16:38 -0800 Received: (qmail 95979 invoked by uid 3709); 8 Mar 2005 22:16:36 -0000 Date: 8 Mar 2005 23:16:36 +0100 Date: Tue, 8 Mar 2005 23:16:36 +0100 From: Andi Kleen To: Thomas Graf Cc: "David S. Miller" , baruch@ev-en.org, shemminger@osdl.org, netdev@oss.sgi.com Subject: Re: netif_rx packet dumping Message-ID: <20050308221636.GA94879@muc.de> References: <20050303123811.4d934249@dxpl.pdx.osdl.net> <42278122.6000000@ev-en.org> <20050303133659.0d224e61.davem@davemloft.net> <42278554.2090902@ev-en.org> <20050303135718.2e1a0170.davem@davemloft.net> <422DC7CE.2040800@ev-en.org> <20050308100902.24b67b2f.davem@davemloft.net> <20050308181844.GA37392@muc.de> <20050308183759.GE31837@postel.suug.ch> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20050308183759.GE31837@postel.suug.ch> User-Agent: Mutt/1.4.1i X-Virus-Scanned: ClamAV 0.83/755/Mon Mar 7 17:00:18 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 2681 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: ak@muc.de Precedence: bulk X-list: netdev Content-Length: 1035 Lines: 26 On Tue, Mar 08, 2005 at 07:37:59PM +0100, Thomas Graf wrote: > * Andi Kleen <20050308181844.GA37392@muc.de> 2005-03-08 19:18 > > There are some other savings possible e.g. from a quick look: > > - skb->list is afaik totally unnecessary and probably even unused. I was wrong on that. Removing skb->list would be worthy, but needs a lot of changes. [BTW there seems to be large cleanup potential in skb list functions; lots of cruft and even some unused functions around and the locking is prehistoric too. In case anybody is interested in a useful cleanup project] > > - struct timeval could be an optimized structure using 32bit > > for the sub second part. > > (would need moving it somewhere else, otherwise alignment doesn't help) > > - Are really three device pointers needed? Perhaps things can > > be a bit optimized here. > > Likely that real_dev can be moved to cb. I would like to keep indev > though, it really helps at policy routing decisions. Moving to cb is useless, you just would need to enlarge it then. -Andi From hadi@cyberus.ca Tue Mar 8 14:21:39 2005 Received: with ECARTIS (v1.0.0; list netdev); Tue, 08 Mar 2005 14:21:44 -0800 (PST) Received: from mx02.cybersurf.com (mx02.cybersurf.com [209.197.145.105]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j28MLcAA008023 for ; Tue, 8 Mar 2005 14:21:38 -0800 Received: from mail.cyberus.ca ([209.197.145.21]) by mx02.cybersurf.com with esmtp (Exim 4.30) id 1D8n56-0002D0-Fa for netdev@oss.sgi.com; Tue, 08 Mar 2005 17:21:36 -0500 Received: from [216.209.86.2] (helo=[10.0.0.9]) by mail.cyberus.ca with esmtp (Exim 4.20) id 1D8n50-00015J-MY; Tue, 08 Mar 2005 17:21:30 -0500 Subject: Re: [RFC] neighbour tables configuration via rtnetlink From: jamal Reply-To: hadi@cyberus.ca To: Thomas Graf Cc: netdev@oss.sgi.com, benjamin.zores@loria.fr In-Reply-To: <20050308142713.GB31837@postel.suug.ch> References: <20050305172257.GN31837@postel.suug.ch> <1110202499.1094.1371.camel@jzny.localdomain> <20050307142622.GT31837@postel.suug.ch> <1110240219.1044.83.camel@jzny.localdomain> <20050308013718.GZ31837@postel.suug.ch> <1110290055.1043.183.camel@jzny.localdomain> <20050308142713.GB31837@postel.suug.ch> Content-Type: text/plain Organization: jamalopolous Message-Id: <1110320486.1077.117.camel@jzny.localdomain> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.2.2 Date: 08 Mar 2005 17:21:27 -0500 Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV 0.83/755/Mon Mar 7 17:00:18 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 2682 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: hadi@cyberus.ca Precedence: bulk X-list: netdev Content-Length: 4282 Lines: 96 On Tue, 2005-03-08 at 09:27, Thomas Graf wrote: > * jamal <1110290055.1043.183.camel@jzny.localdomain> 2005-03-08 08:54 [..] > > Possibily yes, I'm not quite sure why it would involve a shell at least Ok, I could be wrong - if you use some xml library that has xslt library then you should be fine. > it is quite simple to work around using one but I tend to agree. What I'm > aiming for is some kind of generic request record format acting as base > for logging, distribution, whatever purpose and I think that is what you > mean with the "layer above libnl" so we're probably heading into the same > direction with minor differences in how to actually do it. > I am thinking API. And the reason i sensed you and the gnome guy had a good fit was he had this API, it may have to be refined. > I'll keep on experimenting with it hoping to present some more detailed > results soon so we can redraw once we have some prototype and numbers. > makes sense > > There is no byte order issues with ASCII. > > Obviously yes, it depends on at which layer the transformation is done > and that's the point I'm still unsure. The obvious way is to do it in > the actual module implementations of libnl and have the produced XML > protocol being aware of every single configuration bit. Another way > is to describe the actual netlink requests in a half-binary format and > do the transformation later. The latter saves a lot of transformation > work because everything in between doesn't need to be aware of all the > configuration possibilities. However, the transformation to other > protocol types gets more complicated. I haven't found any arguments > for either way that would convice me to head for one direction so I > planned to find out by experimenting. > Well, xml transfered from remote configuration machine. application takes xml and through some magic layer (either xslt transform etc) makes a change a call to gnome-dudes API. Gnome-dude's api calls libnl. libnl calls netlink to kernel. Since the remote calls terminate at the layer above gnome-dude you shouldnt have to worry. > > Yes, i remember that code now. They do use ioctls. > > Unfortunately your libnl is not backward compatible and a lot of > > embedded devices are 2.4.x based. Ive mentioned this before. You need to > > provide a ioctl interface for some things as well and perhaps provide a > > compile flag to select between the two. > > Indeed, I'm not sure how to solve this properly though. libnl's scope > is already quite huge and it might be better to build another layer on > top of it (maybe the one you mentioned) which abstracts the whole network > configuration in a nice API automatically doing the right thing (tm) > by checking kernel capabilities an choose netlink/ioctl/ethtool/... > or whatever is appropriate. Well, use netlink at all times. But for sucess you MUST have backward compatibility. And this may mean a compile config (make config) which has a selection to use ioctls when they are available (only two i can really think of in rtnelink that are reklevant are IFLA and IFA). > > On completion, I thin they had some basic stuff working which is a good > > start (If i recall they could set ip addresses and routes). > > From what the source tells me, interface and routing has been partially > implemented which is a nice start. The code could be merged into the > above mentioned library acting as interface for netconf to interact > with the kernel. > Well, i think theres a very clean separation. They have a few functions which convert from XML to add routes etc. Thats the part that needs to call "api above libnl" which calls libnl IMO. in other words you are providing these services to them. > > The problem is i think you are trying to do all layers. > > I'm thinking in all layers to not miss anything important but it should > definitely be spread across various independant parts. > Understood - I am just saying this is huuge amounts of work; you may wanna involve the gnome guy and let him worry about "the layer above libnl". I would be more than happy to participate in the discussions for what the API should be (many many opinions based on experience) without necessarily commiting that i will have time to code anything. cheers, jamal From kaber@trash.net Tue Mar 8 14:36:22 2005 Received: with ECARTIS (v1.0.0; list netdev); Tue, 08 Mar 2005 14:36:26 -0800 (PST) Received: from kaber.coreworks.de ([62.206.217.67]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j28MaLLS008835 for ; Tue, 8 Mar 2005 14:36:21 -0800 Received: from localhost ([127.0.0.1]) by kaber.coreworks.de with esmtp (Exim 4.50) id 1D8nJ8-0004c9-Hl; Tue, 08 Mar 2005 23:36:06 +0100 Message-ID: <422E28D6.1070103@trash.net> Date: Tue, 08 Mar 2005 23:36:06 +0100 From: Patrick McHardy User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.7.5) Gecko/20050106 Debian/1.7.5-1 X-Accept-Language: en MIME-Version: 1.0 To: Herbert Xu CC: Andreas Unterluggauer , netdev@oss.sgi.com Subject: Re: Fw: [Bugme-new] [Bug 4138] New: ipsec with racoon in transport mode with esp and ah hangs (problem is in xfrm_state_add) References: <200501311640.16118.au@unterluggauer.org> <20050131211102.GA20323@gondor.apana.org.au> In-Reply-To: <20050131211102.GA20323@gondor.apana.org.au> Content-Type: multipart/mixed; boundary="------------000802070007090409010108" X-Virus-Scanned: ClamAV 0.83/755/Mon Mar 7 17:00:18 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 2683 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: kaber@trash.net Precedence: bulk X-list: netdev Content-Length: 1799 Lines: 51 This is a multi-part message in MIME format. --------------000802070007090409010108 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Herbert Xu wrote: > Hi Andreas: > > On Mon, Jan 31, 2005 at 03:40:16PM +0000, Andreas Unterluggauer wrote: > >>2005-01-31 16:29:58: DEBUG: === >>2005-01-31 16:29:58: DEBUG: get pfkey ADD message >>andi: libipsec/pfkey.c, pfkey_check: start (msg->sadb_msg_satype: 3) >>2005-01-31 16:29:58: DEBUG: andi: in pfkey.c, pk_recvadd: msg->sadb_msg_seq 2, msg->sadb_msg_type: ADD >>2005-01-31 16:29:58: INFO: IPsec-SA established: ESP/Transport 192.168.2.5->192.168.2.3 spi=103868257(0x630e761) >>2005-01-31 16:29:58: DEBUG: === > > > Does the machine hang at this point in time? If not, then this is > simply a racoon bug. Although the acquire message carries a policy > with it, it's really only acquiring a single SA. Therefore, only > the SA being acquired should be added with that sequence number. You're right, but I think there is also kernel misbehaviour here that is fixed by the patch for __xfrm_state_find_acq_byseq() I sent to Dave earlier. Andreas, can you try this patch please ? Regards Patrick --------------000802070007090409010108 Content-Type: text/plain; name="x" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="x" ===== net/xfrm/xfrm_state.c 1.55 vs edited ===== --- 1.55/net/xfrm/xfrm_state.c 2005-03-07 06:23:53 +01:00 +++ edited/net/xfrm/xfrm_state.c 2005-03-08 18:42:13 +01:00 @@ -609,7 +609,7 @@ for (i = 0; i < XFRM_DST_HSIZE; i++) { list_for_each_entry(x, xfrm_state_bydst+i, bydst) { - if (x->km.seq == seq) { + if (x->km.seq == seq && x->km.state == XFRM_STATE_ACQ) { xfrm_state_hold(x); return x; } --------------000802070007090409010108-- From herbert@gondor.apana.org.au Tue Mar 8 15:01:01 2005 Received: with ECARTIS (v1.0.0; list netdev); Tue, 08 Mar 2005 15:01:07 -0800 (PST) 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 j28N0vTQ009999 for ; Tue, 8 Mar 2005 15:01:00 -0800 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 1D8ngq-0008Nw-00; Wed, 09 Mar 2005 10:00:36 +1100 Received: from herbert by gondolin.me.apana.org.au with local (Exim 3.36 #1 (Debian)) id 1D8ngO-00079Q-00; Wed, 09 Mar 2005 10:00:08 +1100 Date: Wed, 9 Mar 2005 10:00:08 +1100 To: Patrick McHardy Cc: Andreas Unterluggauer , netdev@oss.sgi.com Subject: Re: Fw: [Bugme-new] [Bug 4138] New: ipsec with racoon in transport mode with esp and ah hangs (problem is in xfrm_state_add) Message-ID: <20050308230008.GA27450@gondor.apana.org.au> References: <200501311640.16118.au@unterluggauer.org> <20050131211102.GA20323@gondor.apana.org.au> <422E28D6.1070103@trash.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <422E28D6.1070103@trash.net> User-Agent: Mutt/1.5.6+20040907i From: Herbert Xu X-Virus-Scanned: ClamAV 0.83/755/Mon Mar 7 17:00:18 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 2684 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: herbert@gondor.apana.org.au Precedence: bulk X-list: netdev Content-Length: 533 Lines: 14 On Tue, Mar 08, 2005 at 11:36:06PM +0100, Patrick McHardy wrote: > > You're right, but I think there is also kernel misbehaviour here that > is fixed by the patch for __xfrm_state_find_acq_byseq() I sent to Dave > earlier. Andreas, can you try this patch please ? Good catch. That should also make racoon work. 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 afleming@freescale.com Tue Mar 8 15:11:12 2005 Received: with ECARTIS (v1.0.0; list netdev); Tue, 08 Mar 2005 15:11:17 -0800 (PST) Received: from az33egw01.freescale.net (az33egw01.freescale.net [192.88.158.102]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j28NBB9V010699 for ; Tue, 8 Mar 2005 15:11:12 -0800 Received: from az33smr02.freescale.net (az33smr02.freescale.net [10.64.34.200]) by az33egw01.freescale.net (8.12.11/az33egw01) with ESMTP id j28ND83B022177 for ; Tue, 8 Mar 2005 16:13:08 -0700 (MST) Received: from [10.82.17.56] ([10.82.17.56]) by az33smr02.freescale.net (8.13.1/8.13.0) with ESMTP id j28NCKoL000096; Tue, 8 Mar 2005 17:12:20 -0600 (CST) Mime-Version: 1.0 (Apple Message framework v619.2) To: Netdev Message-Id: Content-Type: multipart/mixed; boundary=Apple-Mail-1-1019768010 Cc: Kumar Gala Subject: PATCH: Some random ethtool fixes From: Andy Fleming Date: Tue, 8 Mar 2005 17:11:10 -0600 X-Mailer: Apple Mail (2.619.2) X-Virus-Scanned: ClamAV 0.83/755/Mon Mar 7 17:00:18 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 2685 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: afleming@freescale.com Precedence: bulk X-list: netdev Content-Length: 2533 Lines: 70 --Apple-Mail-1-1019768010 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII; format=flowed The patch I sent out earlier had some other changes which were just little bug fixes, and I have distilled those into this patch. This patch applies on ethtool.c (from the application). It fixes these problems: * Allows ethtool -s to set the negotiated speed to 1000 (full/half) * Causes ethtool -s ethN autoneg on to enable gigabit speeds as well as the others * Fixes a spelling error where external was spelled "externel" --Apple-Mail-1-1019768010 Content-Transfer-Encoding: 7bit Content-Type: application/octet-stream; x-unix-mode=0644; name="ethtool_20050308.patch" Content-Disposition: attachment; filename=ethtool_20050308.patch Index: ethtool.c =================================================================== RCS file: /cvsroot/gkernel/ethtool/ethtool.c,v retrieving revision 1.50 diff -u -r1.50 ethtool.c --- ethtool.c 2 Jul 2004 15:35:09 -0000 1.50 +++ ethtool.c 8 Mar 2005 23:01:51 -0000 @@ -681,13 +681,21 @@ else if (speed_wanted == SPEED_100 && duplex_wanted == DUPLEX_FULL) advertising_wanted = ADVERTISED_100baseT_Full; - else + else if (speed_wanted == SPEED_1000 && + duplex_wanted == DUPLEX_HALF) + advertising_wanted = ADVERTISED_1000baseT_Half; + else if (speed_wanted == SPEED_1000 && + duplex_wanted == DUPLEX_FULL) + advertising_wanted = ADVERTISED_1000baseT_Full; + else { /* auto negotiate without forcing */ advertising_wanted = ADVERTISED_100baseT_Full | ADVERTISED_100baseT_Half | ADVERTISED_10baseT_Full | - ADVERTISED_100baseT_Half; - + ADVERTISED_10baseT_Half | + ADVERTISED_1000baseT_Half | + ADVERTISED_1000baseT_Full; + } } if (devname == NULL) { @@ -857,7 +865,7 @@ fprintf(stdout, "internal\n"); break; case XCVR_EXTERNAL: - fprintf(stdout, "externel\n"); + fprintf(stdout, "external\n"); break; default: fprintf(stdout, "Unknown!\n"); --Apple-Mail-1-1019768010-- From sim@netnation.com Tue Mar 8 17:45:16 2005 Received: with ECARTIS (v1.0.0; list netdev); Tue, 08 Mar 2005 17:45:20 -0800 (PST) Received: from peace.netnation.com (newpeace.netnation.com [204.174.223.7]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j291jGvj019186 for ; Tue, 8 Mar 2005 17:45:16 -0800 Received: from sim by peace.netnation.com with local (Exim 4.34) id 1D8qGC-0002gn-Qr; Tue, 08 Mar 2005 17:45:16 -0800 Date: Tue, 8 Mar 2005 17:45:16 -0800 From: Simon Kirby To: Robert Olsson , netdev@oss.sgi.com Subject: Re: Route cache performance Message-ID: <20050309014516.GA806@netnation.com> References: <20050301220743.GF2554@netnation.com> <16940.9990.975632.115834@robur.slu.se> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <16940.9990.975632.115834@robur.slu.se> User-Agent: Mutt/1.5.6+20040907i X-Virus-Scanned: ClamAV 0.83/755/Mon Mar 7 17:00:18 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 2686 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: sim@netnation.com Precedence: bulk X-list: netdev Content-Length: 2467 Lines: 54 On Mon, Mar 07, 2005 at 11:03:50AM +0100, Robert Olsson wrote: > FYI. The preroute12 was incomplete... There is a number 13. Hi Robert, Interesting patch! I haven't had a chance to try it yet, but I have been thinking about this sort of approach for some time. I'm wondering, though, if this patch would ever be accepted upstream. The preroute patches make it now require a full slow route lookup before checking the route cache, right? Eg: ip_route_input() is replaced with a call to ip_route_input_nohash() which then might fall back on ip_route_input() which checks the route cache. The nohash function, however, still appears to have to do the full fib_lookup() which is the same as doing at least one slow route lookup for every packet. The random src/dst DoS case really kills the route cache because of the rehashing, locking, and memory allocation and freeing. I see that the RCU lists and locking now makes it very difficult to recycle the entries, so I think this patch is probably the right idea for now (although the route cache should probably still be optimized where possible). I was wondering if instead it makes sense to still check the route cache first, but insert the bypass code as in ip_route_input_nohash() between where the slow route lookup is done and the dst cache entry is created. In other words: - The route cache is checked first. Entries in the route cache will continue immediately as they do now. - Entries not in the route cache will trigger a slow route lookup as they do now. - Routes which are "INPUT" or "OUTPUT" routes (eg: in or out of the local machine) will be added to the route cache as normal. - Routes which are "FORWARD" routes will NOT be added to the route cache (and thus fall back to "slow" lookups up each time as with the preroute patch). These slow lookups will be faster than maintaining route cache entries for these packets which we don't ever learn an MSS for anyway. In fact, a heuristic could maybe be added to make the route cache bypass conditional so that it only occurs when the table is full or there are too many cache misses, or something. This would maintain the route cache performance in normal conditions but remove the route cache overhead in spoofed src/dst type DoS loads that kill us today. My guess is this would be an even simpler patch as some of the preroute patch is a duplication of ip_route_input_slow() that has to happen in this case anyway. Simon- From afleming@freescale.com Tue Mar 8 17:47:57 2005 Received: with ECARTIS (v1.0.0; list netdev); Tue, 08 Mar 2005 17:48:00 -0800 (PST) Received: from az33egw01.freescale.net (az33egw01.freescale.net [192.88.158.102]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j291lu5j019601 for ; Tue, 8 Mar 2005 17:47:56 -0800 Received: from az33smr02.freescale.net (az33smr02.freescale.net [10.64.34.200]) by az33egw01.freescale.net (8.12.11/az33egw01) with ESMTP id j291nrP5017222; Tue, 8 Mar 2005 18:49:53 -0700 (MST) Received: from [10.82.17.56] ([10.82.17.56]) by az33smr02.freescale.net (8.13.1/8.13.0) with ESMTP id j291n5A2027594; Tue, 8 Mar 2005 19:49:05 -0600 (CST) Mime-Version: 1.0 (Apple Message framework v619.2) To: Netdev , Embedded PPC Linux list Message-Id: <1107b64b01fb8e9a6c84359bb56881a6@freescale.com> Content-Type: multipart/mixed; boundary=Apple-Mail-3-1029171143 Cc: Kumar Gala Subject: RFC: PHY Abstraction Layer II From: Andy Fleming Date: Tue, 8 Mar 2005 19:47:53 -0600 X-Mailer: Apple Mail (2.619.2) X-Virus-Scanned: ClamAV 0.83/755/Mon Mar 7 17:00:18 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 2687 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: afleming@freescale.com Precedence: bulk X-list: netdev Content-Length: 79181 Lines: 3060 --Apple-Mail-3-1029171143 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII; format=flowed I've finally gotten all of ebs's suggestions into the PHY code. Here is the new version. It has the following improvements: * All PHYs now determine speed,duplex, etc using the same generic code, rather than PHY-specific registers. * The genphy driver works for gigabit PHYs now, as well. In theory, if your PHY isn't broken in some way (I've encountered a number that are), you should be able to just use genphy. * The genphy driver now detects what features the PHY has, rather than relying on arbitrarily hard-coded values * Pause negotiation and advertising has been added * PHY read and write functions now return errors if the bus read/write functions return errors. These errors are handled properly, and should not cause any problem. It is the bus's responsibility, however, to make sure that the PHY is started again once the error is cleared. This patch contains just the PHY code. A later email will contain the gianfar driver and 85xx patches, which will serve as an example for how to use the PHY code. A note about size: I did some rough size comparisons, and it looks like this code adds ~10 K to the binary size of the kernel (for PPC 32, 85xx). However, that's a rough estimate, since my tree includes features added to the gianfar driver (eg: ethtool support for setting speed/duplex). --Apple-Mail-3-1029171143 Content-Transfer-Encoding: 7bit Content-Type: application/octet-stream; x-unix-mode=0644; name="phy_only_20050308.patch" Content-Disposition: attachment; filename=phy_only_20050308.patch diff -Nru a/drivers/net/Kconfig b/drivers/net/Kconfig --- a/drivers/net/Kconfig 2005-03-08 19:12:44 -06:00 +++ b/drivers/net/Kconfig 2005-03-08 19:12:44 -06:00 @@ -153,6 +153,8 @@ source "drivers/net/arcnet/Kconfig" endif +source "drivers/net/phy/Kconfig" + # # Ethernet # @@ -2056,6 +2058,8 @@ config GIANFAR tristate "Gianfar Ethernet" depends on 85xx || 83xx + select PHYLIB + select PHYCONTROL help This driver supports the Gigabit TSEC on the MPC85xx family of chips, and the FEC on the 8540 diff -Nru a/drivers/net/Makefile b/drivers/net/Makefile --- a/drivers/net/Makefile 2005-03-08 19:12:44 -06:00 +++ b/drivers/net/Makefile 2005-03-08 19:12:44 -06:00 @@ -12,7 +12,7 @@ obj-$(CONFIG_BONDING) += bonding/ obj-$(CONFIG_GIANFAR) += gianfar_driver.o -gianfar_driver-objs := gianfar.o gianfar_ethtool.o gianfar_phy.o +gianfar_driver-objs := gianfar.o gianfar_ethtool.o gianfar_mii.o # # link order important here @@ -63,6 +63,7 @@ # obj-$(CONFIG_MII) += mii.o +obj-$(CONFIG_PHYLIB) += phy/ obj-$(CONFIG_SUNDANCE) += sundance.o obj-$(CONFIG_HAMACHI) += hamachi.o diff -Nru a/drivers/net/phy/Kconfig b/drivers/net/phy/Kconfig --- /dev/null Wed Dec 31 16:00:00 196900 +++ b/drivers/net/phy/Kconfig 2005-03-08 19:12:45 -06:00 @@ -0,0 +1,57 @@ +# +# PHY Layer Configuration +# + +menu "PHY device support" + +config PHYLIB + bool "PHY Device support and infrastructure" + depends on NET_ETHERNET + help + Ethernet controllers are usually attached to PHY + devices. This option provides infrastructure for + managing PHY devices. + +config PHYCONTROL + bool "Support for automatically handling PHY state changes" + depends on PHYLIB + help + Adds code to perform all the work for keeping PHY link + state (speed/duplex/etc) up-to-date. Also handles + interrupts. + +comment "MII PHY device drivers" + depends on PHYLIB + +config MARVELL_PHY + bool "Drivers for Marvell PHYs" + depends on PHYLIB + ---help--- + Currently has a driver for the 88E1011S + +config DAVICOM_PHY + bool "Drivers for Davicom PHYs" + depends on PHYLIB + ---help--- + Currently supports dm9161e and dm9131 + +config QSEMI_PHY + bool "Drivers for Quality Semiconductor PHYs" + depends on PHYLIB + ---help--- + Currently supports the qs6612 + +config LXT_PHY + bool "Drivers for the Intel LXT PHYs" + depends on PHYLIB + ---help--- + Currently supports the lxt970, lxt971 + +config CICADA_PHY + bool "Drivers for the Cicada PHYs" + depends on PHYLIB + ---help--- + Currently supports the cis8204 + +endmenu + diff -Nru a/drivers/net/phy/Makefile b/drivers/net/phy/Makefile --- /dev/null Wed Dec 31 16:00:00 196900 +++ b/drivers/net/phy/Makefile 2005-03-08 19:12:45 -06:00 @@ -0,0 +1,9 @@ +# Makefile for Linux PHY drivers + +obj-$(CONFIG_PHYLIB) += phy.o phy_device.o mdio_bus.o + +obj-$(CONFIG_MARVELL_PHY) += marvell.o +obj-$(CONFIG_DAVICOM_PHY) += davicom.o +obj-$(CONFIG_CICADA_PHY) += cicada.o +obj-$(CONFIG_LXT_PHY) += lxt.o +obj-$(CONFIG_QSEMI_PHY) += qsemi.o diff -Nru a/drivers/net/phy/cicada.c b/drivers/net/phy/cicada.c --- /dev/null Wed Dec 31 16:00:00 196900 +++ b/drivers/net/phy/cicada.c 2005-03-08 19:12:45 -06:00 @@ -0,0 +1,134 @@ +/* + * drivers/net/phy/cicada.c + * + * Driver for Cicada PHYs + * + * Author: Andy Fleming + * + * Copyright (c) 2004 Freescale Semiconductor, Inc. + * + * This program is free software; you can redistribute it and/or modify it + * under the terms of the GNU General Public License as published by the + * Free Software Foundation; either version 2 of the License, or (at your + * option) any later version. + * + */ +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include + +#include +#include +#include + +/* Cicada Extended Control Register 1 */ +#define MII_CIS8201_EXT_CON1 0x17 +#define MII_CIS8201_EXTCON1_INIT 0x0000 + +/* Cicada Interrupt Mask Register */ +#define MII_CIS8201_IMASK 0x19 +#define MII_CIS8201_IMASK_IEN 0x8000 +#define MII_CIS8201_IMASK_SPEED 0x4000 +#define MII_CIS8201_IMASK_LINK 0x2000 +#define MII_CIS8201_IMASK_DUPLEX 0x1000 +#define MII_CIS8201_IMASK_MASK 0xf000 + +/* Cicada Interrupt Status Register */ +#define MII_CIS8201_ISTAT 0x1a +#define MII_CIS8201_ISTAT_STATUS 0x8000 +#define MII_CIS8201_ISTAT_SPEED 0x4000 +#define MII_CIS8201_ISTAT_LINK 0x2000 +#define MII_CIS8201_ISTAT_DUPLEX 0x1000 + +/* Cicada Auxiliary Control/Status Register */ +#define MII_CIS8201_AUX_CONSTAT 0x1c +#define MII_CIS8201_AUXCONSTAT_INIT 0x0004 +#define MII_CIS8201_AUXCONSTAT_DUPLEX 0x0020 +#define MII_CIS8201_AUXCONSTAT_SPEED 0x0018 +#define MII_CIS8201_AUXCONSTAT_GBIT 0x0010 +#define MII_CIS8201_AUXCONSTAT_100 0x0008 + + +static int cis820x_probe(struct phy_device *phydev) +{ + int err; + + err = phy_write(phydev, MII_CIS8201_AUX_CONSTAT, + MII_CIS8201_AUXCONSTAT_INIT); + + if (err < 0) + return err; + + err = phy_write(phydev, MII_CIS8201_EXT_CON1, + MII_CIS8201_EXTCON1_INIT); + + return err; +} + +static int cis820x_ack_interrupt(struct phy_device *phydev) +{ + int err = phy_read(phydev, MII_CIS8201_ISTAT); + + return (err < 0) ? err : 0; +} + +static int cis820x_config_intr(struct phy_device *phydev) +{ + int err; + + if(phydev->interrupts == PHY_INTERRUPT_ENABLED) + err = phy_write(phydev, MII_CIS8201_IMASK, + MII_CIS8201_IMASK_MASK); + else + err = phy_write(phydev, MII_CIS8201_IMASK, 0); + + return err; +} + +/* Cicada 820x */ +static struct phy_driver cis8204_driver = { + 0x000fc440, + "Cicada Cis8204", + 0x000fffc0, + .features = PHY_GBIT_FEATURES, + .flags = PHY_HAS_INTERRUPT, + .probe = &cis820x_probe, + .config_aneg = &genphy_config_aneg, + .read_status = &genphy_read_status, + .ack_interrupt = &cis820x_ack_interrupt, + .config_intr = &cis820x_config_intr, +}; + +int __init cis8204_init(void) +{ + int retval; + + retval = phy_driver_register(&cis8204_driver); + + return retval; +} + +static void __exit cis8204_exit(void) +{ + phy_driver_unregister(&cis8204_driver); +} + +module_init(cis8204_init); +module_exit(cis8204_exit); diff -Nru a/drivers/net/phy/davicom.c b/drivers/net/phy/davicom.c --- /dev/null Wed Dec 31 16:00:00 196900 +++ b/drivers/net/phy/davicom.c 2005-03-08 19:12:45 -06:00 @@ -0,0 +1,275 @@ +/* + * drivers/net/phy/davicom.c + * + * Driver for Davicom PHYs + * + * Author: Andy Fleming + * + * Copyright (c) 2004 Freescale Semiconductor, Inc. + * + * This program is free software; you can redistribute it and/or modify it + * under the terms of the GNU General Public License as published by the + * Free Software Foundation; either version 2 of the License, or (at your + * option) any later version. + * + */ +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include + +#include +#include +#include + +#define MII_DM9161_SCR 0x10 +#define MII_DM9161_SCR_INIT 0x0610 + +/* DM9161 Interrupt Register */ +#define MII_DM9161_INTR 0x15 +#define MII_DM9161_INTR_PEND 0x8000 +#define MII_DM9161_INTR_DPLX_MASK 0x0800 +#define MII_DM9161_INTR_SPD_MASK 0x0400 +#define MII_DM9161_INTR_LINK_MASK 0x0200 +#define MII_DM9161_INTR_MASK 0x0100 +#define MII_DM9161_INTR_DPLX_CHANGE 0x0010 +#define MII_DM9161_INTR_SPD_CHANGE 0x0008 +#define MII_DM9161_INTR_LINK_CHANGE 0x0004 +#define MII_DM9161_INTR_INIT 0x0000 +#define MII_DM9161_INTR_STOP \ +(MII_DM9161_INTR_DPLX_MASK | MII_DM9161_INTR_SPD_MASK \ + | MII_DM9161_INTR_LINK_MASK | MII_DM9161_INTR_MASK) + +/* DM9161 10BT Configuration/Status */ +#define MII_DM9161_10BTCSR 0x12 +#define MII_DM9161_10BTCSR_INIT 0x7800 + +struct dm9161_private { + struct timer_list timer; + int resetdone; +}; + +#define DM9161_DELAY 1 +int dm9161_config_intr(struct phy_device *phydev) +{ + int temp; + + temp = phy_read(phydev, MII_DM9161_INTR); + + if (temp < 0) + return temp; + + if(PHY_INTERRUPT_ENABLED == phydev->interrupts ) + temp &= ~(MII_DM9161_INTR_STOP); + else + temp |= MII_DM9161_INTR_STOP; + + temp = phy_write(phydev, MII_DM9161_INTR, temp); + + return temp; +} + + +#if 0 +static void dm9161_timer(unsigned long data) +{ + struct phy_device *phydev = (struct phy_device *)data; + struct dm9161_private *priv = phydev->priv; + int status = phy_read(phydev, MII_BMSR); + + if (status < 0) { + mod_timer(&priv->timer, jiffies + DM9161_DELAY * HZ); + return; + } + + spin_lock(&phydev->lock); + if (status & BMSR_ANEGCOMPLETE) { + if (PHY_PENDING == phydev->state) + phydev->state = PHY_UP; + else + phydev->state = PHY_READY; + } else + mod_timer(&priv->timer, jiffies + DM9161_DELAY * HZ); + + spin_unlock(&phydev->lock); +} +#endif + + +static int dm9161_config_aneg(struct phy_device *phydev) +{ + int err; + + /* Isolate the PHY */ + err = phy_write(phydev, MII_BMCR, BMCR_ISOLATE); + + if (err < 0) + return err; + + /* Configure the new settings */ + err = genphy_config_advert(phydev); + + if (err < 0) + return err; + + /* Reconnect the PHY, and enable Autonegotiation */ + err = phy_write(phydev, MII_BMCR, BMCR_ANENABLE); + + if (err < 0) + return err; + +#if 0 + /* Start a timer for DM9161_DELAY seconds to wait + * for the PHY to be ready */ + init_timer(&priv->timer); + priv->timer.function = &dm9161_timer; + priv->timer.data = (unsigned long) phydev; + mod_timer(&priv->timer, jiffies + DM9161_DELAY * HZ); +#endif + + return 0; +} + +static int dm9161_probe(struct phy_device *phydev) +{ + struct dm9161_private *priv; + int err; + + /* Allocate the private data structure */ + priv = kmalloc(sizeof(struct dm9161_private), GFP_KERNEL); + + if (NULL == priv) + return -ENOMEM; + + phydev->priv = priv; + + /* Reset is not done yet */ + priv->resetdone = 0; + + /* Isolate the PHY */ + err = phy_write(phydev, MII_BMCR, BMCR_ISOLATE); + + if (err < 0) + return err; + + /* Do not bypass the scrambler/descrambler */ + err = phy_write(phydev, MII_DM9161_SCR, MII_DM9161_SCR_INIT); + + if (err < 0) + return err; + + /* Clear 10BTCSR to default */ + err = phy_write(phydev, MII_DM9161_10BTCSR, MII_DM9161_10BTCSR_INIT); + + if (err < 0) + return err; + + /* Reconnect the PHY, and enable Autonegotiation */ + err = phy_write(phydev, MII_BMCR, BMCR_ANENABLE); + + if (err < 0) + return err; + +#if 0 + phydev->state = PHY_STARTING; + + /* Start a timer for DM9161_DELAY seconds to wait + * for the PHY to be ready */ + init_timer(&priv->timer); + priv->timer.function = &dm9161_timer; + priv->timer.data = (unsigned long) phydev; + mod_timer(&priv->timer, jiffies + DM9161_DELAY * HZ); + + printk(KERN_INFO "Bringing up a Davicom PHY, this could take" + " a while...\n"); +#endif + return 0; +} + +static void dm9161_remove(struct phy_device *phydev) +{ + struct dm9161_private *priv = phydev->priv; + +// del_timer_sync(&priv->timer); + kfree(priv); +} + +static int dm9161_ack_interrupt(struct phy_device *phydev) +{ + int err = phy_read(phydev, MII_DM9161_INTR); + + return (err < 0) ? err : 0; +} + +static struct phy_driver dm9161_driver = { + .phy_id = 0x0181b880, + .name = "Davicom DM9161E", + .phy_id_mask = 0x0ffffff0, + .features = PHY_BASIC_FEATURES, + .probe = dm9161_probe, + .config_aneg = dm9161_config_aneg, + .read_status = genphy_read_status, + .remove = dm9161_remove, +}; + +static struct phy_driver dm9131_driver = { + .phy_id = 0x00181b80, + .name = "Davicom DM9131", + .phy_id_mask = 0x0ffffff0, + .features = PHY_BASIC_FEATURES, + .flags = PHY_HAS_INTERRUPT, + .config_aneg = genphy_config_aneg, + .read_status = genphy_read_status, + .ack_interrupt = dm9161_ack_interrupt, + .config_intr = dm9161_config_intr, +}; + +int __init dm9161_init(void) +{ + int retval; + + retval = phy_driver_register(&dm9161_driver); + + return retval; +} + +static void __exit dm9161_exit(void) +{ + phy_driver_unregister(&dm9161_driver); +} + +module_init(dm9161_init); +module_exit(dm9161_exit); + +int __init dm9131_init(void) +{ + int retval; + + retval = phy_driver_register(&dm9131_driver); + + return retval; +} + +static void __exit dm9131_exit(void) +{ + phy_driver_unregister(&dm9131_driver); +} + +module_init(dm9131_init); +module_exit(dm9131_exit); diff -Nru a/drivers/net/phy/lxt.c b/drivers/net/phy/lxt.c --- /dev/null Wed Dec 31 16:00:00 196900 +++ b/drivers/net/phy/lxt.c 2005-03-08 19:12:45 -06:00 @@ -0,0 +1,179 @@ +/* + * drivers/net/phy/lxt.c + * + * Driver for Intel LXT PHYs + * + * Author: Andy Fleming + * + * Copyright (c) 2004 Freescale Semiconductor, Inc. + * + * This program is free software; you can redistribute it and/or modify it + * under the terms of the GNU General Public License as published by the + * Free Software Foundation; either version 2 of the License, or (at your + * option) any later version. + * + */ +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include + +#include +#include +#include + +/* The Level one LXT970 is used by many boards */ + +#define MII_LXT970_IER 17 /* Interrupt Enable Register */ + +#define MII_LXT970_IER_IEN 0x0002 + +#define MII_LXT970_ISR 18 /* Interrupt Status Register */ + +#define MII_LXT970_CONFIG 19 /* Configuration Register */ + +/* ------------------------------------------------------------------------- */ +/* The Level one LXT971 is used on some of my custom boards */ + +/* register definitions for the 971 */ +#define MII_LXT971_IER 18 /* Interrupt Enable Register */ +#define MII_LXT971_IER_IEN 0x00f2 + +#define MII_LXT971_ISR 19 /* Interrupt Status Register */ + + +static int lxt970_ack_interrupt(struct phy_device *phydev) +{ + int err; + + err = phy_read(phydev, MII_BMSR); + + if (err < 0) + return err; + + err = phy_read(phydev, MII_LXT970_ISR); + + if (err < 0) + return err; + + return 0; +} + +static int lxt970_config_intr(struct phy_device *phydev) +{ + int err; + + if(phydev->interrupts == PHY_INTERRUPT_ENABLED) + err = phy_write(phydev, MII_LXT970_IER, MII_LXT970_IER_IEN); + else + err = phy_write(phydev, MII_LXT970_IER, 0); + + return err; +} + +static int lxt970_probe(struct phy_device *phydev) +{ + int err; + + err = phy_write(phydev, MII_LXT970_CONFIG, 0); + + return err; +} + + +static int lxt971_ack_interrupt(struct phy_device *phydev) +{ + int err = phy_read(phydev, MII_LXT971_ISR); + + if (err < 0) + return err; + + return 0; +} + +static int lxt971_config_intr(struct phy_device *phydev) +{ + int err; + + if(phydev->interrupts == PHY_INTERRUPT_ENABLED) + err = phy_write(phydev, MII_LXT971_IER, MII_LXT971_IER_IEN); + else + err = phy_write(phydev, MII_LXT971_IER, 0); + + return err; +} + +static struct phy_driver lxt970_driver = { + .phy_id = 0x07810000, + .name = "LXT970", + .phy_id_mask = 0x0fffffff, + .features = PHY_BASIC_FEATURES, + .flags = PHY_HAS_INTERRUPT, + .probe = lxt970_probe, + .config_aneg = genphy_config_aneg, + .read_status = genphy_read_status, + .ack_interrupt = lxt970_ack_interrupt, + .config_intr = lxt970_config_intr, +}; + +static struct phy_driver lxt971_driver = { + .phy_id = 0x0001378e, + .name = "LXT971", + .phy_id_mask = 0x0fffffff, + .features = PHY_BASIC_FEATURES, + .flags = PHY_HAS_INTERRUPT, + .config_aneg = genphy_config_aneg, + .read_status = genphy_read_status, + .ack_interrupt = lxt971_ack_interrupt, + .config_intr = lxt971_config_intr, +}; + +int __init lxt970_init(void) +{ + int retval; + + retval = phy_driver_register(&lxt970_driver); + + return retval; +} + +static void __exit lxt970_exit(void) +{ + phy_driver_unregister(&lxt970_driver); +} + +module_init(lxt970_init); +module_exit(lxt970_exit); + +int __init lxt971_init(void) +{ + int retval; + + retval = phy_driver_register(&lxt971_driver); + + return retval; +} + +static void __exit lxt971_exit(void) +{ + phy_driver_unregister(&lxt971_driver); +} + +module_init(lxt971_init); +module_exit(lxt971_exit); diff -Nru a/drivers/net/phy/marvell.c b/drivers/net/phy/marvell.c --- /dev/null Wed Dec 31 16:00:00 196900 +++ b/drivers/net/phy/marvell.c 2005-03-08 19:12:45 -06:00 @@ -0,0 +1,139 @@ +/* + * drivers/net/phy/marvell.c + * + * Driver for Marvell PHYs + * + * Author: Andy Fleming + * + * Copyright (c) 2004 Freescale Semiconductor, Inc. + * + * This program is free software; you can redistribute it and/or modify it + * under the terms of the GNU General Public License as published by the + * Free Software Foundation; either version 2 of the License, or (at your + * option) any later version. + * + */ +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include + +#include +#include +#include + +#define MII_M1011_IEVENT 0x13 +#define MII_M1011_IEVENT_CLEAR 0x0000 + +#define MII_M1011_IMASK 0x12 +#define MII_M1011_IMASK_INIT 0x6400 +#define MII_M1011_IMASK_CLEAR 0x0000 + +static int marvell_ack_interrupt(struct phy_device *phydev) +{ + int err; + + /* Clear the interrupts by reading the reg */ + err = phy_read(phydev, MII_M1011_IEVENT); + + if (err < 0) + return err; + + return 0; +} + +static int marvell_config_intr(struct phy_device *phydev) +{ + int err; + + if(phydev->interrupts == PHY_INTERRUPT_ENABLED) + err = phy_write(phydev, MII_M1011_IMASK, MII_M1011_IMASK_INIT); + else + err = phy_write(phydev, MII_M1011_IMASK, MII_M1011_IMASK_CLEAR); + + return err; +} + +static int marvell_config_aneg(struct phy_device *phydev) +{ + int err; + + /* The Marvell PHY has an errata which requires + * that certain registers get written in order + * to restart autonegotiation */ + err = phy_write(phydev, MII_BMCR, BMCR_RESET); + + if (err < 0) + return err; + + err = phy_write(phydev, 0x1d, 0x1f); + if (err < 0) + return err; + + err = phy_write(phydev, 0x1e, 0x200c); + if (err < 0) + return err; + + err = phy_write(phydev, 0x1d, 0x5); + if (err < 0) + return err; + + err = phy_write(phydev, 0x1e, 0); + if (err < 0) + return err; + + err = phy_write(phydev, 0x1e, 0x100); + if (err < 0) + return err; + + + err = genphy_config_aneg(phydev); + + return err; +} + + +static struct phy_driver m88e1101_driver = { + .phy_id = 0x01410c00, + .phy_id_mask = 0xffffff00, + .name = "Marvell 88E1101", + .features = PHY_GBIT_FEATURES, + .flags = PHY_HAS_INTERRUPT, + .config_aneg = &marvell_config_aneg, + .read_status = &genphy_read_status, + .ack_interrupt = &marvell_ack_interrupt, + .config_intr = &marvell_config_intr, +}; + +int __init marvell_init(void) +{ + int retval; + + retval = phy_driver_register(&m88e1101_driver); + + return retval; +} + +static void __exit marvell_exit(void) +{ + phy_driver_unregister(&m88e1101_driver); +} + +module_init(marvell_init); +module_exit(marvell_exit); diff -Nru a/drivers/net/phy/mdio_bus.c b/drivers/net/phy/mdio_bus.c --- /dev/null Wed Dec 31 16:00:00 196900 +++ b/drivers/net/phy/mdio_bus.c 2005-03-08 19:12:45 -06:00 @@ -0,0 +1,178 @@ +/* + * drivers/net/phy/mdio_bus.c + * + * MDIO Bus interface + * + * Author: Andy Fleming + * + * Copyright (c) 2004 Freescale Semiconductor, Inc. + * + * This program is free software; you can redistribute it and/or modify it + * under the terms of the GNU General Public License as published by the + * Free Software Foundation; either version 2 of the License, or (at your + * option) any later version. + * + */ +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include + +#include +#include +#include + +/* register_mdiobus + * bus: The bus being registered + * + * description: Called by a bus driver to bring up all the PHYs + * on the bus, and attach them to the bus + */ +int register_mdiobus(struct mii_bus *bus) +{ + int i; + int err = 0; + + spin_lock_init(&bus->mdio_lock); + + if (NULL == bus || NULL == bus->name || + NULL == bus->read || + NULL == bus->write) + return -EINVAL; + + if (bus->reset) + bus->reset(bus); + + for (i=0; i < PHY_MAX_ADDR; i++) { + struct phy_device *phydev; + + phydev = get_phy_device(bus, i); + + /* There's a PHY at this address + * We need to set: + * 1) IRQ + * 2) bus_id + * 3) parent + * 4) bus + * 5) mii_bus + * And, we need to register it */ + if (phydev) { + phydev->irq = bus->irq[i]; + + phydev->dev.parent = bus->dev; + + phydev->dev.bus = &mdio_bus_type; + + phydev->bus = bus; + + sprintf(phydev->dev.bus_id, "phy%d:%d", bus->id, i); + + err = device_register(&phydev->dev); + + if (err) + printk("phy %d did not register (%d)\n", + i, err); + + /* If get_phy_device returned NULL, it may be + * because an error occurred. If so, we return + * that error */ + } else if (errno) + return errno; + + bus->phy_map[i] = phydev; + } + + pr_info("%s: probed\n", bus->name); + + return err; +} +EXPORT_SYMBOL(register_mdiobus); + +void unregister_mdiobus(struct mii_bus *bus) +{ + int i; + + for (i=0; i < PHY_MAX_ADDR; i++) + if (bus->phy_map[i]) { + device_unregister(&bus->phy_map[i]->dev); + kfree(bus->phy_map[i]); + } + +} +EXPORT_SYMBOL(unregister_mdiobus); + +/* mdio_bus_match + * dev: a PHY device + * drv: a PHY driver + * + * description: Given a PHY device, and a PHY driver, return 1 if + * the driver supports the device. Otherwise, return 0 + */ +int mdio_bus_match(struct device *dev, struct device_driver *drv) +{ + struct phy_device *phydev = to_phy_device(dev); + struct phy_driver *phydrv = to_phy_driver(drv); + + return (phydrv->phy_id == (phydev->phy_id & phydrv->phy_id_mask)); +} + +/* Suspend and resume. Copied from platform_suspend and + * platform_resume + */ +static int mdio_bus_suspend(struct device * dev, u32 state) +{ + int ret = 0; + + if (dev->driver && dev->driver->suspend) { + ret = dev->driver->suspend(dev, state, SUSPEND_DISABLE); + if (ret == 0) + ret = dev->driver->suspend(dev, state, SUSPEND_SAVE_STATE); + if (ret == 0) + ret = dev->driver->suspend(dev, state, SUSPEND_POWER_DOWN); + } + return ret; +} + +static int mdio_bus_resume(struct device * dev) +{ + int ret = 0; + + if (dev->driver && dev->driver->resume) { + ret = dev->driver->resume(dev, RESUME_POWER_ON); + if (ret == 0) + ret = dev->driver->resume(dev, RESUME_RESTORE_STATE); + if (ret == 0) + ret = dev->driver->resume(dev, RESUME_ENABLE); + } + return ret; +} + +struct bus_type mdio_bus_type = { + .name = "mdio_bus", + .match = mdio_bus_match, + .suspend= mdio_bus_suspend, + .resume = mdio_bus_resume, +}; + +int __init mdio_bus_init(void) +{ + return bus_register(&mdio_bus_type); +} + +subsys_initcall(mdio_bus_init); diff -Nru a/drivers/net/phy/phy.c b/drivers/net/phy/phy.c --- /dev/null Wed Dec 31 16:00:00 196900 +++ b/drivers/net/phy/phy.c 2005-03-08 19:12:45 -06:00 @@ -0,0 +1,625 @@ +/* + * drivers/net/phy/phy.c + * + * Framework for configuring and reading PHY devices + * Based on code in sungem_phy.c and gianfar_phy.c + * + * Author: Andy Fleming + * + * Copyright (c) 2004 Freescale Semiconductor, Inc. + * + * This program is free software; you can redistribute it and/or modify it + * under the terms of the GNU General Public License as published by the + * Free Software Foundation; either version 2 of the License, or (at your + * option) any later version. + * + */ +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include + +#include +#include +#include + +int phy_read(struct phy_device *phydev, u16 regnum); +int phy_write(struct phy_device *phydev, u16 regnum, u16 val); + +/* Convenience functions for reading a given PHY register. + * This MUST NOT be called from interrupt context, + * because the bus read function may sleep + * or generally lock up. */ +int phy_read(struct phy_device *phydev, u16 regnum) +{ + int retval; + struct mii_bus *bus = phydev->bus; + + spin_lock_bh(&bus->mdio_lock); + retval = bus->read(bus, phydev->addr, regnum); + spin_unlock_bh(&bus->mdio_lock); + + return retval; +} + +int phy_write(struct phy_device *phydev, u16 regnum, u16 val) +{ + int err; + struct mii_bus *bus = phydev->bus; + + spin_lock_bh(&bus->mdio_lock); + err = bus->write(bus, phydev->addr, regnum, val); + spin_unlock_bh(&bus->mdio_lock); + + return err; +} + + +int phy_clear_interrupt(struct phy_device *phydev) +{ + int err = 0; + + if (phydev->drv->ack_interrupt) + err = phydev->drv->ack_interrupt(phydev); + + return err; +} + + +int phy_config_interrupt(struct phy_device *phydev, u32 interrupts) +{ + int err = 0; + + phydev->interrupts = interrupts; + if (phydev->drv->config_intr) + err = phydev->drv->config_intr(phydev); + + return err; +} + + +static inline int phy_read_status(struct phy_device *phydev) +{ + return phydev->drv->read_status(phydev); +} + +/* phy_aneg_done + * + * description: Reads the status register and returns 0 either if + * auto-negotiation is incomplete, or if there was an error. + * Returns BMSR_ANEGCOMPLETE if auto-negotiation is done. + * Must be called with phydev->lock locked. + */ +static inline int phy_aneg_done(struct phy_device *phydev) +{ + int retval; + + retval = phy_read(phydev, MII_BMSR); + + if (retval < 0) + return retval; + + return retval & BMSR_ANEGCOMPLETE; +} + +/* phy_start_aneg + * phydev: The PHY on which to initiate auto-negotiation + * + * description: Calls the PHY driver's config_aneg, and then + * sets the PHY state to PHY_AN if auto-negotiation is enabled, + * and to PHY_FORCING if auto-negotiation is disabled. Unless + * the PHY is currently HALTED. + */ +int phy_start_aneg(struct phy_device *phydev) +{ + int err = 0; + + spin_lock(&phydev->lock); + + if (AUTONEG_DISABLE == phydev->autoneg) + phy_sanitize_settings(phydev); + + err = phydev->drv->config_aneg(phydev); + + if (err < 0) + return err; + + if (phydev->state != PHY_HALTED) { + if (AUTONEG_ENABLE == phydev->autoneg) { + phydev->state = PHY_AN; + phydev->link_timeout = PHY_AN_TIMEOUT; + } else { + phydev->state = PHY_FORCING; + phydev->link_timeout = PHY_FORCE_TIMEOUT; + } + } + + spin_unlock(&phydev->lock); + + return err; +} + + +/* A structure for mapping a particular speed and duplex + * combination to a particular SUPPORTED and ADVERTISED value */ +struct phy_setting { + int speed; + int duplex; + u32 setting; +}; + +/* A mapping of all SUPPORTED settings to speed/duplex */ +static struct phy_setting settings[] = { + { .speed = 10000, .duplex = DUPLEX_FULL, + .setting = SUPPORTED_10000baseT_Full, + }, + { .speed = SPEED_1000, .duplex = DUPLEX_FULL, + .setting = SUPPORTED_1000baseT_Full, + }, + { .speed = SPEED_1000, .duplex = DUPLEX_HALF, + .setting = SUPPORTED_1000baseT_Half, + }, + { .speed = SPEED_100, .duplex = DUPLEX_FULL, + .setting = SUPPORTED_100baseT_Full, + }, + { .speed = SPEED_100, .duplex = DUPLEX_HALF, + .setting = SUPPORTED_100baseT_Half, + }, + { .speed = SPEED_10, .duplex = DUPLEX_FULL, + .setting = SUPPORTED_10baseT_Full, + }, + { .speed = SPEED_10, .duplex = DUPLEX_HALF, + .setting = SUPPORTED_10baseT_Half, + }, +}; + +#define MAX_NUM_SETTINGS (sizeof(settings)/sizeof(struct phy_setting)) + +/* phy_find_setting + * speed: desired speed of setting + * duplex: desired duplex of setting + * + * description: Searches the settings array for the setting which + * matches the desired speed and duplex, and returns the index + * of that setting. Returns the index of the last setting if + * none of the others match. + */ +static inline int phy_find_setting(int speed, int duplex) +{ + int idx = 0; + + while (idx < MAX_NUM_SETTINGS && + (settings[idx].speed != speed || + settings[idx].duplex != duplex)) + idx++; + + return idx < MAX_NUM_SETTINGS ? idx : MAX_NUM_SETTINGS - 1; +} + +/* phy_find_valid + * idx: The first index in settings[] to search + * features: A mask of the valid settings + * + * description: Returns the index of the first valid setting less + * than or equal to the one pointed to by idx, as determined by + * the mask in features. Returns the index of the last setting + * if nothing else matches. + */ +static inline int phy_find_valid(int idx, u32 features) +{ + while (idx < MAX_NUM_SETTINGS && !(settings[idx].setting & features)) + idx++; + + return idx < MAX_NUM_SETTINGS ? idx : MAX_NUM_SETTINGS - 1; +} + +/* phy_sanitize_settings + * phydev: The PHY in question + * + * description: Make sure the PHY is set to supported speeds and + * duplexes. Drop down by one in this order: 1000/FULL, + * 1000/HALF, 100/FULL, 100/HALF, 10/FULL, 10/HALF + */ +void phy_sanitize_settings(struct phy_device *phydev) +{ + u32 features = phydev->supported; + int idx; + + /* Sanitize settings based on PHY capabilities */ + if ((features & SUPPORTED_Autoneg) == 0) + phydev->autoneg = 0; + + idx = phy_find_valid(phy_find_setting(phydev->speed, phydev->duplex), + features); + + phydev->speed = settings[idx].speed; + phydev->duplex = settings[idx].duplex; +} + +/* phy_force_reduction + * phydev: The PHY in question + * + * description: Reduces the speed/duplex settings by + * one notch. The order is so: + * 1000/FULL, 1000/HALF, 100/FULL, 100/HALF, + * 10/FULL, 10/HALF. The function bottoms out at 10/HALF. + */ +void phy_force_reduction(struct phy_device *phydev) +{ + int idx; + + idx = phy_find_setting(phydev->speed, phydev->duplex); + + idx++; + + idx = phy_find_valid(idx, phydev->supported); + + phydev->speed = settings[idx].speed; + phydev->duplex = settings[idx].duplex; + + pr_info("Trying %d/%s\n", phydev->speed, + DUPLEX_FULL == phydev->duplex ? "FULL" : "HALF"); +} + +#ifdef CONFIG_PHYCONTROL +/* phy_error: + * + * Moves the PHY to the HALTED state in response to a read + * or write error, and tells the controller the link is down. + * Must not be called from interrupt context, or while the + * phydev->lock is held. + */ +void phy_error(struct phy_device *phydev) +{ + spin_lock(&phydev->lock); + phydev->state = PHY_HALTED; + spin_unlock(&phydev->lock); +} + +/* phy_interrupt + * irq: Interrupt number + * phy_dat: PHY device which caused the interrupt (presumably) + * regs: -- + * + * description: When a PHY interrupt occurs, the handler disables + * interrupts, and schedules a work task to clear the interrupt. + */ +static irqreturn_t phy_interrupt(int irq, void *phy_dat, struct pt_regs *regs) +{ + struct phy_device *phydev = phy_dat; + + /* The MDIO bus is not allowed to be written in interrupt + * context, so we need to disable the irq here. A work + * queue will write the PHY to disable and clear the + * interrupt, and then reenable the irq line. */ + disable_irq_nosync(irq); + + schedule_work(&phydev->phy_queue); + + return IRQ_HANDLED; +} + +/* phy_start_interrupts + * phydev: The PHY whose interrupts are being enabled + * + * description: Request the interrupt for the given PHY. If + * this fails, then we set irq to -1 so that we do polling. + * Otherwise, we enable the interrupts in the PHY. + * Returns 0 on success. + */ +int phy_start_interrupts(struct phy_device *phydev) +{ + int err = 0; + + if (request_irq(phydev->irq, phy_interrupt, + SA_SHIRQ, + "phy_interrupt", + phydev) < 0) { + printk(KERN_ERR "%s: Can't get IRQ %d (PHY)\n", + phydev->bus->name, + phydev->irq); + phydev->irq = -1; + return 0; + } + + err = phy_clear_interrupt(phydev); + + if (err < 0) + return err; + + err = phy_config_interrupt(phydev, PHY_INTERRUPT_ENABLED); + + return err; +} + +/* Scheduled by the phy_interrupt/timer to handle PHY changes */ +void phy_change(void *data) +{ + int err; + struct phy_device *phydev = data; + + /* Disable PHY interrupts */ + err = phy_config_interrupt(phydev, PHY_INTERRUPT_DISABLED); + + if (err) + goto phy_err; + + /* Clear the interrupt */ + err = phy_clear_interrupt(phydev); + + if (err) + goto phy_err; + + spin_lock(&phydev->lock); + if ((PHY_RUNNING == phydev->state) || (PHY_NOLINK == phydev->state)) + phydev->state = PHY_CHANGELINK; + spin_unlock(&phydev->lock); + + enable_irq(phydev->irq); + + /* Reenable interrupts */ + err = phy_config_interrupt(phydev, PHY_INTERRUPT_ENABLED); + + if (err) + goto irq_enable_err; + + return; + +irq_enable_err: + disable_irq(phydev->irq); +phy_err: + phy_error(phydev); +} + +/* Bring down the PHY link, and stop checking the status. */ +void phy_stop(struct phy_device *phydev) +{ + spin_lock(&phydev->lock); + + if (PHY_HALTED == phydev->state) { + spin_unlock(&phydev->lock); + return; + } + + if (phydev->irq != -1) { + /* Clear any pending interrupts */ + phy_clear_interrupt(phydev); + + /* Disable PHY Interrupts */ + phy_config_interrupt(phydev, PHY_INTERRUPT_DISABLED); + } + + phydev->state = PHY_HALTED; + + spin_unlock(&phydev->lock); +} + + +/* phy_start + * phydev: The PHY device being started + * + * description: Indicates the attached device's readiness to + * handle PHY-related work. Used during startup to start the + * PHY, and after a call to phy_stop() to resume operation. + * Also used to indicate the MDIO bus has cleared an error + * condition. + */ +void phy_start(struct phy_device *phydev) +{ + spin_lock(&phydev->lock); + + switch (phydev->state) { + case PHY_STARTING: + phydev->state = PHY_PENDING; + break; + case PHY_READY: + phydev->state = PHY_UP; + break; + case PHY_HALTED: + phydev->state = PHY_RESUMING; + default: + break; + } + spin_unlock(&phydev->lock); +} +EXPORT_SYMBOL(phy_stop); +EXPORT_SYMBOL(phy_start); + +/* PHY timer which handles the state machine */ +void phy_timer(unsigned long data) +{ + struct phy_device *phydev = (struct phy_device *)data; + int needs_aneg = 0; + int err = 0; + + spin_lock(&phydev->lock); + + if (phydev->adjust_state) + phydev->adjust_state(phydev->attached_dev); + + switch(phydev->state) { + case PHY_DOWN: + case PHY_STARTING: + case PHY_READY: + case PHY_PENDING: + break; + case PHY_UP: + needs_aneg = 1; + + phydev->link_timeout = PHY_AN_TIMEOUT; + + if (phydev->irq != -1) + err = phy_start_interrupts(phydev); + + break; + case PHY_AN: + /* Check if negotiation is done. Break + * if there's an error */ + err = phy_aneg_done(phydev); + if (err < 0) + break; + + /* If auto-negotiation is done, we change to + * either RUNNING, or NOLINK */ + if (err > 0) { + err = phy_read_status(phydev); + + if (err) + break; + + if (phydev->link) + phydev->state = PHY_RUNNING; + else + phydev->state = PHY_NOLINK; + + phydev->adjust_link(phydev->attached_dev); + + } else if (0 == phydev->link_timeout--) { + /* The counter expired, so either we + * switch to forced mode, or the + * magic_aneg bit exists, and we try aneg + * again */ + if (!(phydev->drv->flags & PHY_HAS_MAGICANEG)) { + int idx; + + /* We'll start from the + * fastest speed, and work + * our way down */ + idx = phy_find_valid(0, + phydev->supported); + + phydev->speed = settings[idx].speed; + phydev->duplex = settings[idx].duplex; + + phydev->autoneg = AUTONEG_DISABLE; + phydev->state = PHY_FORCING; + phydev->link_timeout = + PHY_FORCE_TIMEOUT; + + pr_info("Trying %d/%s\n", phydev->speed, + DUPLEX_FULL == + phydev->duplex ? + "FULL" : "HALF"); + } + + needs_aneg = 1; + } + break; + case PHY_NOLINK: + err = phy_read_status(phydev); + + if (err) + break; + + if (phydev->link) { + phydev->state = PHY_RUNNING; + phydev->adjust_link(phydev->attached_dev); + } + break; + case PHY_FORCING: + err = phy_read_status(phydev); + + if (err) + break; + + if (phydev->link) { + phydev->state = PHY_RUNNING; + } else { + if (0 == phydev->link_timeout--) { + phy_force_reduction(phydev); + needs_aneg = 1; + } + } + + phydev->adjust_link(phydev->attached_dev); + break; + case PHY_RUNNING: + /* Only register a CHANGE if we aren't + * using interrupts */ + if (-1 == phydev->irq) + phydev->state = PHY_CHANGELINK; + break; + case PHY_CHANGELINK: + err = phy_read_status(phydev); + + if (err) + break; + + if (phydev->link) + phydev->state = PHY_RUNNING; + else { + phydev->state = PHY_NOLINK; + } + + phydev->adjust_link(phydev->attached_dev); + + if (-1 != phydev->irq) + err = phy_config_interrupt(phydev, + PHY_INTERRUPT_ENABLED); + break; + case PHY_HALTED: + if (phydev->link) { + phydev->link = 0; + phydev->adjust_link(phydev->attached_dev); + } + break; + case PHY_RESUMING: + + err = phy_clear_interrupt(phydev); + + if (err) + break; + + err = phy_config_interrupt(phydev, + PHY_INTERRUPT_ENABLED); + + if (err) + break; + + if (AUTONEG_ENABLE == phydev->autoneg) { + err = phy_aneg_done(phydev); + if (err < 0) + break; + + /* err > 0 if AN is done. + * Otherwise, it's 0, and we're + * still waiting for AN */ + if (err > 0) { + phydev->state = PHY_RUNNING; + } else { + phydev->state = PHY_AN; + phydev->link_timeout = PHY_AN_TIMEOUT; + } + } else + phydev->state = PHY_RUNNING; + break; + } + + spin_unlock(&phydev->lock); + + if (needs_aneg) + err = phy_start_aneg(phydev); + + if (err < 0) + phy_error(phydev); + + mod_timer(&phydev->phy_timer, jiffies + PHY_STATE_TIME * HZ); +} + +#endif /* CONFIG_PHYCONTROL */ diff -Nru a/drivers/net/phy/phy_device.c b/drivers/net/phy/phy_device.c --- /dev/null Wed Dec 31 16:00:00 196900 +++ b/drivers/net/phy/phy_device.c 2005-03-08 19:12:45 -06:00 @@ -0,0 +1,735 @@ +/* + * drivers/net/phy/phy_device.c + * + * Framework for finding and configuring PHYs. + * Also contains generic PHY driver + * + * Author: Andy Fleming + * + * Copyright (c) 2004 Freescale Semiconductor, Inc. + * + * This program is free software; you can redistribute it and/or modify it + * under the terms of the GNU General Public License as published by the + * Free Software Foundation; either version 2 of the License, or (at your + * option) any later version. + * + */ +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include + +#include +#include +#include + +/* get_phy_device + * bus: The bus the PHY is on + * addr: The address of the desired PHY device + * + * description: Reads the ID registers of the desired PHY, + * then allocates and returns the phy_device which + * represents it. + */ +struct phy_device * get_phy_device(struct mii_bus *bus, uint addr) +{ + int phy_reg; + u32 phy_id; + struct phy_device *dev = NULL; + + errno = 0; + + /* Grab the bits from PHYIR1, and put them + * in the upper half */ + phy_reg = bus->read(bus, addr, MII_PHYSID1); + + if (phy_reg < 0) { + errno = phy_reg; + return NULL; + } + + phy_id = (phy_reg & 0xffff) << 16; + + /* Grab the bits from PHYIR2, and put them in the lower half */ + phy_reg = bus->read(bus, addr, MII_PHYSID2); + + if (phy_reg < 0) { + errno = phy_reg; + return NULL; + } + + phy_id |= (phy_reg & 0xffff); + + /* If the phy_id is all Fs, there is no device there */ + if (0xffffffff == phy_id) + return NULL; + + /* Otherwise, we allocate the device, and initialize the + * default values */ + dev = kmalloc(sizeof(*dev), GFP_KERNEL); + + if (NULL == dev) { + errno = -ENOMEM; + return NULL; + } + + memset(dev, 0, sizeof(*dev)); + + dev->speed = 0; + dev->duplex = -1; + dev->pause = dev->asym_pause = 0; + dev->link = 1; + + dev->autoneg = AUTONEG_ENABLE; + + dev->addr = addr; + dev->phy_id = phy_id; + dev->bus = bus; + + dev->state = PHY_DOWN; + + spin_lock_init(&dev->lock); + + INIT_WORK(&dev->phy_queue, phy_change, dev); + + return dev; +} + +/* phy_prepare_link: + * phydev: The PHY device whose link is being prepped + * adjust_link: The link change handler for the controller + * + * description: Tells the PHY infrastructure to handle the + * gory details on monitoring link status (whether through + * polling or an interrupt), and to call back to the + * connected device driver when the link status changes. + * If you want to monitor your own link state, don't call + * this function */ +void phy_prepare_link(struct phy_device *phydev, + void (*handler)(struct device *)) +{ + phydev->adjust_link = handler; +} + +#ifdef CONFIG_PHYCONTROL +/* phy_start_machine: + * phydev: The PHY device whose state machine is being started + * handler: The callback function for state change notifications. + * + * description: The PHY infrastructure can run a state machine + * which tracks whether the PHY is starting up, negotiating, + * etc. This function starts the timer which tracks the state + * of the PHY. If you want to be notified when the state + * changes, pass in the callback, otherwise, pass NULL. If you + * want to maintain your own state machine, do not call this + * function. */ +void phy_start_machine(struct phy_device *phydev, + void (*handler)(struct device *)) +{ + phydev->adjust_state = handler; + + init_timer(&phydev->phy_timer); + phydev->phy_timer.function = &phy_timer; + phydev->phy_timer.data = (unsigned long) phydev; + mod_timer(&phydev->phy_timer, jiffies + HZ); +} + +/* phy_stop_machine + * + * description: Stops the state machine timer, sets the state to + * UP (unless it wasn't up yet), and then frees the interrupt, + * if it is in use. This function must be called BEFORE + * phy_detach. + */ +void phy_stop_machine(struct phy_device *phydev) +{ + del_timer_sync(&phydev->phy_timer); + + spin_lock(&phydev->lock); + if (phydev->state > PHY_UP) + phydev->state = PHY_UP; + spin_unlock(&phydev->lock); + + if (phydev->irq != -1) { + phy_config_interrupt(phydev, PHY_INTERRUPT_DISABLED); + phy_clear_interrupt(phydev); + free_irq(phydev->irq, phydev); + } + + phydev->adjust_state = NULL; +} + + +/* phy_connect: + * dev: The requesting device + * phy_id: The name of the requested PHY device + * adjust_link: A callback function for handling link status + * changes + * + * description: Convenience function for connecting ethernet (or + * other) devices to PHY devices. The default behavior is for + * the PHY infrastructure to handle everything, and only notify + * the connected driver when the link status changes. If you + * don't want, or can't use the provided functionality, you may + * choose to call only the subset of functions which provide + * the desired functionality. + */ +struct phy_device * phy_connect(struct device *dev, const char *phy_id, + void (*handler)(struct device *)) +{ + struct phy_device *phydev; + + phydev = phy_attach(dev, phy_id); + + if (NULL == phydev) + return phydev; + + phy_prepare_link(phydev, handler); + + phy_start_machine(phydev, NULL); + + return phydev; +} +EXPORT_SYMBOL(phy_connect); + +void phy_disconnect(struct phy_device *phydev) +{ + phy_stop_machine(phydev); + + phydev->adjust_link = NULL; + + phy_detach(phydev); +} +EXPORT_SYMBOL(phy_disconnect); + +#endif /* CONFIG_PHYCONTROL */ + +/* phy_attach: + * dev: The requesting device + * phy_id: The name of the requested PHY device + * + * description: Called by drivers to attach to a particular PHY + * device. The phy_device is found, and properly hooked up + * to the phy_driver. If no driver is attached, then the + * genphy_driver is used. The phy_device is given a ptr to + * the attaching device, and given a callback for link status + * change. The phy_device is returned to the attaching + * driver. + */ +struct phy_device *phy_attach(struct device *dev, const char *phy_id) +{ + struct phy_device *phydev = NULL; + struct bus_type *bus = &mdio_bus_type; + struct list_head *entry; + + /* Search the list of PHY devices on the mdio bus for the + * PHY with the requested name */ + list_for_each(entry, &bus->devices.list) + { + struct device *d = container_of(entry, struct device, bus_list); + + if (!strcmp(phy_id, d->bus_id)) { + phydev = to_phy_device(d); + break; + } + } + + if (NULL == phydev) { + printk(KERN_ERR "%s not found\n", phy_id); + errno = -ENODEV; + return NULL; + } + + /* Assume that if there is no driver, that it doesn't + * exist, and we should use the genphy driver. */ + if (NULL == phydev->dev.driver) { + int err; + down_write(&phydev->dev.bus->subsys.rwsem); + phydev->dev.driver = &genphy_driver.driver; + + err = phydev->dev.driver->probe(&phydev->dev); + + if (err < 0) { + errno = err; + return NULL; + } + + device_bind_driver(&phydev->dev); + up_write(&phydev->dev.bus->subsys.rwsem); + } + + if (phydev->attached_dev) { + printk(KERN_ERR "%s: %s already attached\n", + dev->bus_id, phy_id); + errno = -EBUSY; + return NULL; + } + + phydev->attached_dev = dev; + + return phydev; +} +EXPORT_SYMBOL(phy_attach); + +void phy_detach(struct phy_device *phydev) +{ + phydev->attached_dev = NULL; + + /* If the device had no specific driver before (i.e. - it + * was using the generic driver), we unbind the device + * from the generic driver so that there's a chance a + * real driver could be loaded */ + if (phydev->dev.driver == &genphy_driver.driver) { + down_write(&phydev->dev.bus->subsys.rwsem); + device_release_driver(&phydev->dev); + up_write(&phydev->dev.bus->subsys.rwsem); + } +} +EXPORT_SYMBOL(phy_detach); + + +/* Generic PHY support and helper functions */ + +/* genphy_config_advert + * + * description: Writes MII_ADVERTISE with the appropriate values, + * after sanitizing the values to make sure we only advertise + * what is supported + */ +int genphy_config_advert(struct phy_device *phydev) +{ + u32 advertise; + int adv; + int err; + + /* Only allow advertising what + * this PHY supports */ + phydev->advertising &= phydev->supported; + advertise = phydev->advertising; + + /* Setup standard advertisement */ + adv = phy_read(phydev, MII_ADVERTISE); + + if (adv < 0) + return adv; + + adv &= ~(ADVERTISE_ALL | ADVERTISE_100BASE4 | ADVERTISE_PAUSE_CAP | + ADVERTISE_PAUSE_ASYM); + if (advertise & ADVERTISED_10baseT_Half) + adv |= ADVERTISE_10HALF; + if (advertise & ADVERTISED_10baseT_Full) + adv |= ADVERTISE_10FULL; + if (advertise & ADVERTISED_100baseT_Half) + adv |= ADVERTISE_100HALF; + if (advertise & ADVERTISED_100baseT_Full) + adv |= ADVERTISE_100FULL; + if (advertise & ADVERTISED_Pause) + adv |= ADVERTISE_PAUSE_CAP; + if (advertise & ADVERTISED_Asym_Pause) + adv |= ADVERTISE_PAUSE_ASYM; + + err = phy_write(phydev, MII_ADVERTISE, adv); + + if (err < 0) + return err; + + /* Configure gigabit if it's supported */ + if (phydev->supported & (SUPPORTED_1000baseT_Half | + SUPPORTED_1000baseT_Full)) { + adv = phy_read(phydev, MII_CTRL1000); + + if (adv < 0) + return adv; + + adv &= ~(ADVERTISE_1000FULL | ADVERTISE_1000HALF); + if (advertise & SUPPORTED_1000baseT_Half) + adv |= ADVERTISE_1000HALF; + if (advertise & SUPPORTED_1000baseT_Full) + adv |= ADVERTISE_1000FULL; + err = phy_write(phydev, MII_CTRL1000, adv); + + if (err < 0) + return err; + } + + return adv; +} + + +/* genphy_setup_forced + * + * description: Configures MII_BMCR to force speed/duplex + * to the values in phydev. Assumes that the values are valid. + * Please see phy_sanitize_settings() */ +int genphy_setup_forced(struct phy_device *phydev) +{ + int ctl = phy_read(phydev, MII_BMCR); + + if (ctl < 0) + return ctl; + + phydev->pause = phydev->asym_pause = 0; + + ctl &= ~(BMCR_FULLDPLX|BMCR_SPEED100|BMCR_SPEED1000|BMCR_ANENABLE); + ctl |= BMCR_RESET; + + if (SPEED_1000 == phydev->speed) + ctl |= BMCR_SPEED1000; + else if (SPEED_100 == phydev->speed) + ctl |= BMCR_SPEED100; + + if (DUPLEX_FULL == phydev->duplex) + ctl |= BMCR_FULLDPLX; + + ctl = phy_write(phydev, MII_BMCR, ctl); + + return ctl; +} + + +/* Enable and Restart Autonegotiation */ +int genphy_restart_aneg(struct phy_device *phydev) +{ + int ctl; + + ctl = phy_read(phydev, MII_BMCR); + + if (ctl < 0) + return ctl; + + ctl |= (BMCR_ANENABLE | BMCR_ANRESTART); + + ctl = phy_write(phydev, MII_BMCR, ctl); + + return ctl; +} + + +/* genphy_config_aneg + * + * description: If auto-negotiation is enabled, we configure the + * advertising, and then restart auto-negotiation. If it is not + * enabled, then we write the BMCR + */ +int genphy_config_aneg(struct phy_device *phydev) +{ + int err = 0; + + if (AUTONEG_ENABLE == phydev->autoneg) { + err = genphy_config_advert(phydev); + + if (err < 0) + return err; + + err = genphy_restart_aneg(phydev); + } else + err = genphy_setup_forced(phydev); + + return err; +} + + +/* genphy_update_link + * + * description: Update the value in phydev->link to reflect the + * current link value. In order to do this, we need to read + * the status register twice, keeping the second value + */ +int genphy_update_link(struct phy_device *phydev) +{ + int status; + + /* Do a fake read */ + status = phy_read(phydev, MII_BMSR); + + if (status < 0) + return status; + + /* Read link and autonegotiation status */ + status = phy_read(phydev, MII_BMSR); + + if (status < 0) + return status; + + if ((status & BMSR_LSTATUS) == 0) + phydev->link = 0; + else + phydev->link = 1; + + return 0; +} + +/* genphy_read_status + * + * description: Check the link, then figure out the current state + * by comparing what we advertise with what the link partner + * advertises. Start by checking the gigabit possibilities, + * then move on to 10/100. + */ +int genphy_read_status(struct phy_device *phydev) +{ + int adv; + int err; + int lpa; + int lpagb = 0; + + /* Update the link, but return if there + * was an error */ + err = genphy_update_link(phydev); + if (err) + return err; + + if (AUTONEG_ENABLE == phydev->autoneg) { + if (phydev->supported & (SUPPORTED_1000baseT_Half + | SUPPORTED_1000baseT_Full)) { + lpagb = phy_read(phydev, MII_STAT1000); + + if (lpagb < 0) + return lpagb; + + adv = phy_read(phydev, MII_CTRL1000); + + if (adv < 0) + return adv; + + lpagb &= adv << 2; + } + + lpa = phy_read(phydev, MII_LPA); + + if (lpa < 0) + return lpa; + + adv = phy_read(phydev, MII_ADVERTISE); + + if (adv < 0) + return adv; + + lpa &= adv; + + phydev->speed = SPEED_10; + phydev->duplex = DUPLEX_HALF; + phydev->pause = phydev->asym_pause = 0; + + if (lpagb & (LPA_1000FULL | LPA_1000HALF)) { + phydev->speed = SPEED_1000; + + if (lpagb & LPA_1000FULL) + phydev->duplex = DUPLEX_FULL; + } else if (lpa & (LPA_100FULL | LPA_100HALF)) { + phydev->speed = SPEED_100; + + if (lpa & LPA_100FULL) + phydev->duplex = DUPLEX_FULL; + } else + if (lpa & LPA_10FULL) + phydev->duplex = DUPLEX_FULL; + + if (phydev->duplex == DUPLEX_FULL){ + phydev->pause = lpa & LPA_PAUSE_CAP ? 1 : 0; + phydev->asym_pause = lpa & LPA_PAUSE_ASYM ? 1 : 0; + } + } else { + int bmcr = phy_read(phydev, MII_BMCR); + if (bmcr < 0) + return bmcr; + + if (bmcr & BMCR_FULLDPLX) + phydev->duplex = DUPLEX_FULL; + else + phydev->duplex = DUPLEX_HALF; + + if (bmcr & BMCR_SPEED1000) + phydev->speed = SPEED_1000; + else if (bmcr & BMCR_SPEED100) + phydev->speed = SPEED_100; + else + phydev->speed = SPEED_10; + + phydev->pause = phydev->asym_pause = 0; + } + + return 0; +} + + +static int genphy_probe(struct phy_device *phydev) +{ + u32 val; + u32 features; + + /* For now, I'll claim that the generic driver supports + * all possible port types */ + features = (SUPPORTED_TP | SUPPORTED_MII + | SUPPORTED_AUI | SUPPORTED_FIBRE | + SUPPORTED_BNC); + + /* Do we support autonegotiation? */ + val = phy_read(phydev, MII_BMSR); + + if (val < 0) + return val; + + if (val & BMSR_ANEGCAPABLE) + features |= SUPPORTED_Autoneg; + + if (val & BMSR_100FULL) + features |= SUPPORTED_100baseT_Full; + if (val & BMSR_100HALF) + features |= SUPPORTED_100baseT_Half; + if (val & BMSR_10FULL) + features |= SUPPORTED_10baseT_Full; + if (val & BMSR_10HALF) + features |= SUPPORTED_10baseT_Half; + + if (val & BMSR_ESTATEN) { + val = phy_read(phydev, MII_ESTATUS); + + if (val < 0) + return val; + + if (val & ESTATUS_1000_TFULL) + features |= SUPPORTED_1000baseT_Full; + if (val & ESTATUS_1000_THALF) + features |= SUPPORTED_1000baseT_Half; + } + + phydev->supported = features; + phydev->advertising = features; + + return 0; +} + + +/* phy_probe + * dev: The device belonging to a PHY device + * + * description: Take care of setting up the phy_device structure, + * set the state to READY (the driver's probe function should + * set it to STARTING if needed). + */ +int phy_probe(struct device *dev) +{ + struct phy_device *phydev; + struct phy_driver *phydrv; + struct device_driver *drv; + int err = 0; + + phydev = to_phy_device(dev); + + /* Make sure the driver is held. + * XXX -- Is this correct? */ + drv = get_driver(phydev->dev.driver); + phydrv = to_phy_driver(drv); + phydev->drv = phydrv; + + /* Disable the interrupt if the PHY doesn't support it */ + if (!(phydrv->flags & PHY_HAS_INTERRUPT)) + phydev->irq = -1; + + spin_lock(&phydev->lock); + + /* Start out supporting everything. Eventually, + * a controller will attach, and may modify one + * or both of these values */ + phydev->supported = phydrv->features; + phydev->advertising = phydrv->features; + + /* Set the state to READY by default */ + phydev->state = PHY_READY; + + if (phydev->drv->probe) + err = phydev->drv->probe(phydev); + + spin_unlock(&phydev->lock); + + return err; +} + +int phy_remove(struct device *dev) +{ + struct phy_device *phydev; + + phydev = to_phy_device(dev); + + spin_lock(&phydev->lock); + phydev->state = PHY_DOWN; + spin_unlock(&phydev->lock); + + if (phydev->drv->remove) + phydev->drv->remove(phydev); + + put_driver(phydev->dev.driver); + phydev->drv = NULL; + + return 0; +} + +int phy_driver_register(struct phy_driver *new_driver) +{ + int retval; + + memset(&new_driver->driver, 0, sizeof(new_driver->driver)); + new_driver->driver.name = new_driver->name; + new_driver->driver.bus = &mdio_bus_type; + new_driver->driver.probe = phy_probe; + new_driver->driver.remove = phy_remove; + + retval = driver_register(&new_driver->driver); + + if (!retval) + pr_info("%s: Registered new driver\n", new_driver->name); + else + printk(KERN_ERR "%s: Error %d in registering driver\n", + new_driver->name, retval); + + return retval; +} + +void phy_driver_unregister(struct phy_driver *drv) +{ + driver_unregister(&drv->driver); +} + +struct phy_driver genphy_driver = { + .phy_id = 0xffffffff, + .phy_id_mask = 0xffffffff, + .name = "Generic PHY", + .probe = genphy_probe, + .features = 0, + .config_aneg = genphy_config_aneg, + .read_status = genphy_read_status, +}; + +static int __init genphy_init(void) +{ + int retval; + + retval = phy_driver_register(&genphy_driver); + + return retval; +} + +static void __exit genphy_exit(void) +{ + phy_driver_unregister(&genphy_driver); +} + +module_init(genphy_init); +module_exit(genphy_exit); diff -Nru a/drivers/net/phy/qsemi.c b/drivers/net/phy/qsemi.c --- /dev/null Wed Dec 31 16:00:00 196900 +++ b/drivers/net/phy/qsemi.c 2005-03-08 19:12:45 -06:00 @@ -0,0 +1,143 @@ +/* + * drivers/net/phy/qsemi.c + * + * Driver for Quality Semiconductor PHYs + * + * Author: Andy Fleming + * + * Copyright (c) 2004 Freescale Semiconductor, Inc. + * + * This program is free software; you can redistribute it and/or modify it + * under the terms of the GNU General Public License as published by the + * Free Software Foundation; either version 2 of the License, or (at your + * option) any later version. + * + */ +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include + +#include +#include +#include + +/* ------------------------------------------------------------------------- */ +/* The Quality Semiconductor QS6612 is used on the RPX CLLF */ + +/* register definitions */ + +#define MII_QS6612_MCR 17 /* Mode Control Register */ +#define MII_QS6612_FTR 27 /* Factory Test Register */ +#define MII_QS6612_MCO 28 /* Misc. Control Register */ +#define MII_QS6612_ISR 29 /* Interrupt Source Register */ +#define MII_QS6612_IMR 30 /* Interrupt Mask Register */ +#define MII_QS6612_IMR_INIT 0x003a +#define MII_QS6612_PCR 31 /* 100BaseTx PHY Control Reg. */ + +#define QS6612_PCR_AN_COMPLETE 0x1000 +#define QS6612_PCR_RLBEN 0x0200 +#define QS6612_PCR_DCREN 0x0100 +#define QS6612_PCR_4B5BEN 0x0040 +#define QS6612_PCR_TX_ISOLATE 0x0020 +#define QS6612_PCR_MLT3_DIS 0x0002 +#define QS6612_PCR_SCRM_DESCRM 0x0001 + + +/* Returns 0, unless there's a write error */ +int qs6612_probe(struct phy_device *phydev) +{ + /* The PHY powers up isolated on the RPX, + * so send a command to allow operation. + * XXX - My docs indicate this should be 0x0940 + * ...or something. The current value sets three + * reserved bits, bit 11, which specifies it should be + * set to one, bit 10, which specifies it should be set + * to 0, and bit 7, which doesn't specify. However, my + * docs are preliminary, and I will leave it like this + * until someone more knowledgable corrects me or it. + * -- Andy Fleming + */ + return phy_write(phydev, MII_QS6612_PCR, 0x0dc0); +} + +int qs6612_ack_interrupt(struct phy_device *phydev) +{ + int err; + + err = phy_read(phydev, MII_QS6612_ISR); + + if (err < 0) + return err; + + err = phy_read(phydev, MII_BMSR); + + if (err < 0) + return err; + + err = phy_read(phydev, MII_EXPANSION); + + if (err < 0) + return err; + + return 0; +} + +int qs6612_config_intr(struct phy_device *phydev) +{ + int err; + if (phydev->interrupts == PHY_INTERRUPT_ENABLED) + err = phy_write(phydev, MII_QS6612_IMR, + MII_QS6612_IMR_INIT); + else + err = phy_write(phydev, MII_QS6612_IMR, 0); + + return err; + +} + +static struct phy_driver qs6612_driver = { + .phy_id = 0x00181440, + .name = "QS6612", + .phy_id_mask = 0xfffffff0, + .features = PHY_BASIC_FEATURES, + .flags = PHY_HAS_INTERRUPT, + .probe = qs6612_probe, + .config_aneg = genphy_config_aneg, + .read_status = genphy_read_status, + .ack_interrupt = qs6612_ack_interrupt, + .config_intr = qs6612_config_intr, +}; + +int __init qs6612_init(void) +{ + int retval; + + retval = phy_driver_register(&qs6612_driver); + + return retval; +} + +static void __exit qs6612_exit(void) +{ + phy_driver_unregister(&qs6612_driver); +} + +module_init(qs6612_init); +module_exit(qs6612_exit); diff -Nru a/include/linux/ethtool.h b/include/linux/ethtool.h --- a/include/linux/ethtool.h 2005-03-08 19:12:44 -06:00 +++ b/include/linux/ethtool.h 2005-03-08 19:12:44 -06:00 @@ -389,6 +389,7 @@ #define ETHTOOL_GTSO 0x0000001e /* Get TSO enable (ethtool_value) */ #define ETHTOOL_STSO 0x0000001f /* Set TSO enable (ethtool_value) */ + /* compatibility with older code */ #define SPARC_ETH_GSET ETHTOOL_GSET #define SPARC_ETH_SSET ETHTOOL_SSET @@ -407,6 +408,8 @@ #define SUPPORTED_FIBRE (1 << 10) #define SUPPORTED_BNC (1 << 11) #define SUPPORTED_10000baseT_Full (1 << 12) +#define SUPPORTED_Pause (1 << 13) +#define SUPPORTED_Asym_Pause (1 << 14) /* Indicates what features are advertised by the interface. */ #define ADVERTISED_10baseT_Half (1 << 0) @@ -422,6 +425,8 @@ #define ADVERTISED_FIBRE (1 << 10) #define ADVERTISED_BNC (1 << 11) #define ADVERTISED_10000baseT_Full (1 << 12) +#define ADVERTISED_Pause (1 << 13) +#define ADVERTISED_Asym_Pause (1 << 14) /* The following are all involved in forcing a particular link * mode for the device for setting things. When getting the diff -Nru a/include/linux/fsl_devices.h b/include/linux/fsl_devices.h --- a/include/linux/fsl_devices.h 2005-03-08 19:12:45 -06:00 +++ b/include/linux/fsl_devices.h 2005-03-08 19:12:45 -06:00 @@ -47,13 +47,19 @@ struct gianfar_platform_data { /* device specific information */ u32 device_flags; - u32 phy_reg_addr; /* board specific information */ u32 board_flags; - u32 phyid; - u32 interruptPHY; + const char *bus_id; u8 mac_addr[6]; +}; + +struct gianfar_mdio_data { + /* device specific information */ + u32 paddr; + + /* board specific information */ + int irq[32]; }; /* Flags related to gianfar device features */ diff -Nru a/include/linux/mii.h b/include/linux/mii.h --- a/include/linux/mii.h 2005-03-08 19:12:44 -06:00 +++ b/include/linux/mii.h 2005-03-08 19:12:44 -06:00 @@ -22,6 +22,7 @@ #define MII_EXPANSION 0x06 /* Expansion register */ #define MII_CTRL1000 0x09 /* 1000BASE-T control */ #define MII_STAT1000 0x0a /* 1000BASE-T status */ +#define MII_ESTATUS 0x0f /* Extended Status */ #define MII_DCOUNTER 0x12 /* Disconnect counter */ #define MII_FCSCOUNTER 0x13 /* False carrier counter */ #define MII_NWAYTEST 0x14 /* N-way auto-neg test reg */ @@ -54,7 +55,10 @@ #define BMSR_ANEGCAPABLE 0x0008 /* Able to do auto-negotiation */ #define BMSR_RFAULT 0x0010 /* Remote fault detected */ #define BMSR_ANEGCOMPLETE 0x0020 /* Auto-negotiation complete */ -#define BMSR_RESV 0x07c0 /* Unused... */ +#define BMSR_RESV 0x00c0 /* Unused... */ +#define BMSR_ESTATEN 0x0100 /* Extended Status in R15 */ +#define BMSR_100FULL2 0x0200 /* Can do 100BASE-T2 HDX */ +#define BMSR_100HALF2 0x0400 /* Can do 100BASE-T2 FDX */ #define BMSR_10HALF 0x0800 /* Can do 10mbps, half-duplex */ #define BMSR_10FULL 0x1000 /* Can do 10mbps, full-duplex */ #define BMSR_100HALF 0x2000 /* Can do 100mbps, half-duplex */ @@ -105,6 +109,9 @@ #define EXPANSION_NPCAPABLE 0x0008 /* Link partner supports npage */ #define EXPANSION_MFAULTS 0x0010 /* Multiple faults detected */ #define EXPANSION_RESV 0xffe0 /* Unused... */ + +#define ESTATUS_1000_TFULL 0x2000 /* Can do 1000BT Full */ +#define ESTATUS_1000_THALF 0x1000 /* Can do 1000BT Half */ /* N-way test register. */ #define NWAYTEST_RESV1 0x00ff /* Unused... */ diff -Nru a/include/linux/phy.h b/include/linux/phy.h --- /dev/null Wed Dec 31 16:00:00 196900 +++ b/include/linux/phy.h 2005-03-08 19:12:45 -06:00 @@ -0,0 +1,352 @@ +/* + * include/linux/phy.h + * + * Framework and drivers for configuring and reading different PHYs + * Based on code in sungem_phy.c and gianfar_phy.c + * + * Author: Andy Fleming + * + * Copyright (c) 2004 Freescale Semiconductor, Inc. + * + * This program is free software; you can redistribute it and/or modify it + * under the terms of the GNU General Public License as published by the + * Free Software Foundation; either version 2 of the License, or (at your + * option) any later version. + * + */ + +#ifndef __PHY_H +#define __PHY_H + +#include +#include + +#define PHY_BASIC_FEATURES (SUPPORTED_10baseT_Half | \ + SUPPORTED_10baseT_Full | \ + SUPPORTED_100baseT_Half | \ + SUPPORTED_100baseT_Full | \ + SUPPORTED_Autoneg | \ + SUPPORTED_TP | \ + SUPPORTED_MII) + +#define PHY_GBIT_FEATURES (PHY_BASIC_FEATURES | \ + SUPPORTED_1000baseT_Half | \ + SUPPORTED_1000baseT_Full) + +#define PHY_HAS_INTERRUPT 0x00000001 +#define PHY_HAS_MAGICANEG 0x00000002 + +#define MII_BUS_MAX 4 + + +#define PHY_INIT_TIMEOUT 100000 +#define PHY_STATE_TIME 1 +#define PHY_FORCE_TIMEOUT 10 +#define PHY_AN_TIMEOUT 10 + +#define PHY_MAX_ADDR 32 + +/* The Bus class for PHYs. Devices which provide access to + * PHYs should register using this structure */ +struct mii_bus { + const char *name; + int id; + void *priv; + int (*read)(struct mii_bus *bus, int phy_id, int regnum); + int (*write)(struct mii_bus *bus, int phy_id, int regnum, u16 val); + int (*reset)(struct mii_bus *bus); + + /* A lock to ensure that only one thing can read/write + * the MDIO bus at a time */ + spinlock_t mdio_lock; + + struct device *dev; + + /* list of all PHYs on bus */ + struct phy_device *phy_map[PHY_MAX_ADDR]; + + /* Pointer to an array of interrupts, each PHY's + * interrupt at the index matching its address */ + int *irq; +}; + +#define PHY_INTERRUPT_DISABLED 0x0 +#define PHY_INTERRUPT_ENABLED 0x80000000 + +/* PHY state machine states: + * + * DOWN: PHY device and driver are not ready for anything. probe + * should be called if and only if the PHY is in this state, + * given that the PHY device exists. + * - PHY driver probe function will, depending on the PHY, set + * the state to STARTING or READY + * + * STARTING: PHY device is coming up, and the ethernet driver is + * not ready. PHY drivers may set this in the probe function. + * If they do, they are responsible for making sure the state is + * eventually set to indicate whether the PHY is UP or READY, + * depending on the state when the PHY is done starting up. + * - PHY driver will set the state to READY + * - start will set the state to PENDING + * + * READY: PHY is ready to send and receive packets, but the + * controller is not. By default, PHYs which do not implement + * probe will be set to this state by phy_probe(). If the PHY + * driver knows the PHY is ready, and the PHY state is STARTING, + * then it sets this STATE. + * - start will set the state to UP + * + * PENDING: PHY device is coming up, but the ethernet driver is + * ready. phy_start will set this state if the PHY state is + * STARTING. + * - PHY driver will set the state to UP when the PHY is ready + * + * UP: The PHY and attached device are ready to do work. + * Interrupts should be started here. + * - timer moves to AN + * + * AN: The PHY is currently negotiating the link state. Link is + * therefore down for now. phy_timer will set this state when it + * detects the state is UP. config_aneg will set this state + * whenever called with phydev->autoneg set to AUTONEG_ENABLE. + * - If autonegotiation finishes, but there's no link, it sets + * the state to NOLINK. + * - If aneg finishes with link, it sets the state to RUNNING, + * and calls adjust_link + * - If autonegotiation did not finish after an arbitrary amount + * of time, autonegotiation should be tried again if the PHY + * supports "magic" autonegotiation (back to AN) + * - If it didn't finish, and no magic_aneg, move to FORCING. + * + * NOLINK: PHY is up, but not currently plugged in. + * - If the timer notes that the link comes back, we move to RUNNING + * - config_aneg moves to AN + * - phy_stop moves to HALTED + * + * FORCING: PHY is being configured with forced settings + * - if link is up, move to RUNNING + * - If link is down, we drop to the next highest setting, and + * retry (FORCING) after a timeout + * - phy_stop moves to HALTED + * + * RUNNING: PHY is currently up, running, and possibly sending + * and/or receiving packets + * - timer will set CHANGELINK if we're polling (this ensures the + * link state is polled every other cycle of this state machine, + * which makes it every other second) + * - irq will set CHANGELINK + * - config_aneg will set AN + * - phy_stop moves to HALTED + * + * CHANGELINK: PHY experienced a change in link state + * - timer moves to RUNNING if link + * - timer moves to NOLINK if the link is down + * - phy_stop moves to HALTED + * + * HALTED: PHY is up, but no polling or interrupts are done. Or + * PHY is in an error state. + * + * - phy_start moves to RESUMING + * + * RESUMING: PHY was halted, but now wants to run again. + * - If we are forcing, or aneg is done, timer moves to RUNNING + * - If aneg is not done, timer moves to AN + * - phy_stop moves to HALTED + */ +enum phy_state { + PHY_DOWN=0, + PHY_STARTING, + PHY_READY, + PHY_PENDING, + PHY_UP, + PHY_AN, + PHY_RUNNING, + PHY_NOLINK, + PHY_FORCING, + PHY_CHANGELINK, + PHY_HALTED, + PHY_RESUMING +}; + +/* phy_device: An instance of a PHY + * + * drv: Pointer to the driver for this PHY instance + * bus: Pointer to the bus this PHY is on + * dev: driver model device structure for this PHY + * phy_id: UID for this device found during discovery + * state: state of the PHY for management purposes + * addr: Bus address of PHY + * link_timeout: The number of timer firings to wait before the + * giving up on the current attempt at acquiring a link + * irq: IRQ number of the PHY's interrupt (-1 if none) + * phy_timer: The timer for handling the state machine + * phy_queue: A work_queue for the interrupt + * attached_dev: The attached enet driver's device instance ptr + * adjust_link: Callback for the enet controller to respond to + * changes in the link state. + * adjust_state: Callback for the enet driver to respond to + * changes in the state machine. + * + * speed, duplex, pause, supported, advertising, and + * autoneg are used like in mii_if_info + * + * interrupts currently only supports enabled or disabled, + * but could be changed in the future to support enabling + * and disabling specific interrupts + * + * Contains some infrastructure for polling and interrupt + * handling, as well as handling shifts in PHY hardware state + */ +struct phy_device { + /* Information about the PHY type */ + /* And management functions */ + struct phy_driver *drv; + + struct mii_bus *bus; + + struct device dev; + + u32 phy_id; + + enum phy_state state; + + /* Bus address of the PHY (0-32) */ + int addr; + + /* forced speed & duplex (no autoneg) + * partner speed & duplex & pause (autoneg) + */ + int speed; + int duplex; + int pause; + int asym_pause; + + /* The most recently read link state */ + int link; + + /* Enabled Interrupts */ + u32 interrupts; + + /* Union of PHY and Attached devices' supported modes */ + /* See mii.h for more info */ + u32 supported; + u32 advertising; + + int autoneg; + + int link_timeout; + + /* Interrupt number for this PHY + * -1 means no interrupt */ + int irq; + + /* private data pointer */ + /* For use by PHYs to maintain extra state */ + void *priv; + + /* Interrupt and Polling infrastructure */ + struct work_struct phy_queue; + struct timer_list phy_timer; + + spinlock_t lock; + + struct device *attached_dev; + + void (*adjust_link)(struct device *dev); + + void (*adjust_state)(struct device *dev); +}; +#define to_phy_device(d) container_of(d, struct phy_device, dev) + +/* struct phy_driver: Driver structure for a particular PHY type + * + * phy_id: The result of reading the UID registers of this PHY + * type, and ANDing them with the phy_id_mask. This driver + * only works for PHYs with IDs which match this field + * name: The friendly name of this PHY type + * phy_id_mask: Defines the important bits of the phy_id + * features: A list of features (speed, duplex, etc) supported + * by this PHY + * flags: A bitfield defining certain other features this PHY + * supports (like interrupts) + * + * The drivers must implement config_aneg and read_status. All + * other functions are optional. Note that none of these + * functions should be called from interrupt time. The goal is + * for the bus read/write functions to be able to block when the + * bus transaction is happening, and be freed up by an interrupt + * (The MPC85xx has this ability, though it is not currently + * supported in the driver). + */ +struct phy_driver { + u32 phy_id; + char *name; + unsigned int phy_id_mask; + u32 features; + u32 flags; + + /* Called to initialize the PHY */ + int (*probe)(struct phy_device *phydev); + + /* PHY Power Management */ + int (*suspend)(struct phy_device *phydev); + int (*resume)(struct phy_device *phydev); + + /* Configures the advertisement and resets + * autonegotiation if phydev->autoneg is on, + * forces the speed to the current settings in phydev + * if phydev->autoneg is off */ + int (*config_aneg)(struct phy_device *phydev); + + /* Determines the negotiated speed and duplex */ + int (*read_status)(struct phy_device *phydev); + + /* Clears any pending interrupts */ + int (*ack_interrupt)(struct phy_device *phydev); + + /* Enables or disables interrupts */ + int (*config_intr)(struct phy_device *phydev); + + /* Clears up any memory if needed */ + void (*remove)(struct phy_device *phydev); + + struct device_driver driver; +}; +#define to_phy_driver(d) container_of(d, struct phy_driver, driver) + +int phy_read(struct phy_device *phydev, u16 regnum); +int phy_write(struct phy_device *phydev, u16 regnum, u16 val); +struct phy_device* get_phy_device(struct mii_bus *bus, uint addr); +int phy_clear_interrupt(struct phy_device *phydev); +int phy_config_interrupt(struct phy_device *phydev, u32 interrupts); +struct phy_device * phy_attach(struct device *dev, const char *phy_id); +struct phy_device * phy_connect(struct device *dev, const char *phy_id, + void (*handler)(struct device *)); +void phy_disconnect(struct phy_device *phydev); +void phy_detach(struct phy_device *phydev); +void phy_start(struct phy_device *phydev); +void phy_stop(struct phy_device *phydev); +int phy_start_aneg(struct phy_device *phydev); +int register_mdiobus(struct mii_bus *bus); +void phy_change(void *data); +void phy_timer(unsigned long data); +void phy_sanitize_settings(struct phy_device *phydev); + +int genphy_config_advert(struct phy_device *phydev); +int genphy_setup_forced(struct phy_device *phydev); +int genphy_restart_aneg(struct phy_device *phydev); +int gbit_config_aneg(struct phy_device *phydev); +int genphy_config_aneg(struct phy_device *phydev); +int genphy_update_link(struct phy_device *phydev); +int genphy_read_status(struct phy_device *phydev); +void phy_driver_unregister(struct phy_driver *drv); +int phy_driver_register(struct phy_driver *new_driver); +void phy_prepare_link(struct phy_device *phydev, + void (*adjust_link)(struct device *)); +void phy_start_machine(struct phy_device *phydev, + void (*handler)(struct device *)); +void phy_stop_machine(struct phy_device *phydev); + +extern struct bus_type mdio_bus_type; +extern struct phy_driver genphy_driver; +#endif /* __PHY_H */ --Apple-Mail-3-1029171143 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII; format=flowed Andy Fleming Open Source Team Freescale Semiconductor, Inc --Apple-Mail-3-1029171143-- From benh@kernel.crashing.org Tue Mar 8 18:18:44 2005 Received: with ECARTIS (v1.0.0; list netdev); Tue, 08 Mar 2005 18:18:48 -0800 (PST) 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 j292IiBq021229 for ; Tue, 8 Mar 2005 18:18:44 -0800 Received: from gaston (localhost [127.0.0.1]) by gate.crashing.org (8.12.8/8.12.8) with ESMTP id j292GlgJ001215; Tue, 8 Mar 2005 20:16:48 -0600 Subject: Re: RFC: PHY Abstraction Layer II From: Benjamin Herrenschmidt To: Andy Fleming Cc: Netdev , Embedded PPC Linux list In-Reply-To: <1107b64b01fb8e9a6c84359bb56881a6@freescale.com> References: <1107b64b01fb8e9a6c84359bb56881a6@freescale.com> Content-Type: text/plain Date: Wed, 09 Mar 2005 13:14:16 +1100 Message-Id: <1110334456.32556.21.camel@gaston> Mime-Version: 1.0 X-Mailer: Evolution 2.0.3 Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV 0.83/755/Mon Mar 7 17:00:18 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 2688 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 Content-Length: 1978 Lines: 46 On Tue, 2005-03-08 at 19:47 -0600, Andy Fleming wrote: > I've finally gotten all of ebs's suggestions into the PHY code. Here > is the new version. It has the following improvements: > > * All PHYs now determine speed,duplex, etc using the same generic code, > rather than PHY-specific registers. Some PHY are doing a better job with PHY specific registers I think ... The gigabit for example isn't standard, and some PHYs sort-of manage to deal with non-autoneg hubs in such a way that the "normal" aneg doesn't succeeds, but the phy specific stuff does work. At least from stuff I've been told a while ago, I have no direct experience here. > * The genphy driver works for gigabit PHYs now, as well. In theory, if > your PHY isn't broken in some way (I've encountered a number that are), > you should be able to just use genphy. Isn't the speed reporting of gigabit an implementation specific bit in lots of PHYs ? > * The genphy driver now detects what features the PHY has, rather than > relying on arbitrarily hard-coded values > > * Pause negotiation and advertising has been added > > * PHY read and write functions now return errors if the bus read/write > functions return errors. These errors are handled properly, and should > not cause any problem. It is the bus's responsibility, however, to > make sure that the PHY is started again once the error is cleared. > > This patch contains just the PHY code. A later email will contain the > gianfar driver and 85xx patches, which will serve as an example for how > to use the PHY code. > > A note about size: I did some rough size comparisons, and it looks > like this code adds ~10 K to the binary size of the kernel (for PPC 32, > 85xx). However, that's a rough estimate, since my tree includes > features added to the gianfar driver (eg: ethtool support for setting > speed/duplex). I'll have a closer look when I find some time, see if it makes sense to adapt sungem or not. Ben. From davem@davemloft.net Tue Mar 8 19:43:06 2005 Received: with ECARTIS (v1.0.0; list netdev); Tue, 08 Mar 2005 19:43:11 -0800 (PST) Received: from cheetah.davemloft.net (mail@dsl027-180-174.sfo1.dsl.speakeasy.net [216.27.180.174]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j293h3HV025564 for ; Tue, 8 Mar 2005 19:43:06 -0800 Received: from localhost ([127.0.0.1] helo=cheetah.davemloft.net ident=davem) by cheetah.davemloft.net with smtp (Exim 3.36 #1 (Debian)) id 1D8s5d-00048d-00; Tue, 08 Mar 2005 19:42:29 -0800 Date: Tue, 8 Mar 2005 19:42:29 -0800 From: "David S. Miller" To: Benjamin Herrenschmidt Cc: afleming@freescale.com, netdev@oss.sgi.com, linuxppc-embedded@ozlabs.org Subject: Re: RFC: PHY Abstraction Layer II Message-Id: <20050308194229.41c23707.davem@davemloft.net> In-Reply-To: <1110334456.32556.21.camel@gaston> References: <1107b64b01fb8e9a6c84359bb56881a6@freescale.com> <1110334456.32556.21.camel@gaston> X-Mailer: Sylpheed version 1.0.1 (GTK+ 1.2.10; sparc-unknown-linux-gnu) X-Face: "_;p5u5aPsO,_Vsx"^v-pEq09'CU4&Dc1$fQExov$62l60cgCc%FnIwD=.UF^a>?5'9Kn[;433QFVV9M..2eN.@4ZWPGbdi<=?[:T>y?SD(R*-3It"Vj:)"dP Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV 0.83/755/Mon Mar 7 17:00:18 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 2689 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: davem@davemloft.net Precedence: bulk X-list: netdev Content-Length: 376 Lines: 10 On Wed, 09 Mar 2005 13:14:16 +1100 Benjamin Herrenschmidt wrote: > I'll have a closer look when I find some time, see if it makes sense to > adapt sungem or not. Especially because of the Broadcom PHYs I bet it doesn't. Too many chips have to reset the MAC, or do other fancy stuff when programming the PHY to make this genphy thing very useful. From benh@kernel.crashing.org Tue Mar 8 19:54:50 2005 Received: with ECARTIS (v1.0.0; list netdev); Tue, 08 Mar 2005 19:54:54 -0800 (PST) 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 j293smdB026301 for ; Tue, 8 Mar 2005 19:54:50 -0800 Received: from gaston (localhost [127.0.0.1]) by gate.crashing.org (8.12.8/8.12.8) with ESMTP id j293qlgJ002258; Tue, 8 Mar 2005 21:52:48 -0600 Subject: Re: RFC: PHY Abstraction Layer II From: Benjamin Herrenschmidt To: "David S. Miller" Cc: afleming@freescale.com, netdev@oss.sgi.com, linuxppc-embedded@ozlabs.org In-Reply-To: <20050308194229.41c23707.davem@davemloft.net> References: <1107b64b01fb8e9a6c84359bb56881a6@freescale.com> <1110334456.32556.21.camel@gaston> <20050308194229.41c23707.davem@davemloft.net> Content-Type: text/plain Date: Wed, 09 Mar 2005 14:50:14 +1100 Message-Id: <1110340214.32524.32.camel@gaston> Mime-Version: 1.0 X-Mailer: Evolution 2.0.3 Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV 0.83/755/Mon Mar 7 17:00:18 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 2690 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 Content-Length: 837 Lines: 23 On Tue, 2005-03-08 at 19:42 -0800, David S. Miller wrote: > On Wed, 09 Mar 2005 13:14:16 +1100 > Benjamin Herrenschmidt wrote: > > > I'll have a closer look when I find some time, see if it makes sense to > > adapt sungem or not. > > Especially because of the Broadcom PHYs I bet it doesn't. > > Too many chips have to reset the MAC, or do other fancy stuff > when programming the PHY to make this genphy thing very useful. Oh, I think genphy is just a generic driver, but his layer has hooks for other PHY drivers (wasn't it based on sungem_phy in the first place ?) I discussed several steps of the design with Andy, the idea was to have something a bit like sungem_phy.c with addditional common library for doing the link polling & fallback stuff etc... that could be easily shared by drivers. Ben. From zdenek@rcn.com Tue Mar 8 21:36:59 2005 Received: with ECARTIS (v1.0.0; list netdev); Tue, 08 Mar 2005 21:37:02 -0800 (PST) Received: from smtp04.mrf.mail.rcn.net (smtp04.mrf.mail.rcn.net [207.172.4.63]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j295awfh001759 for ; Tue, 8 Mar 2005 21:36:58 -0800 Received: from 209-150-50-115.c3-0.nwt-ubr3.sbo-nwt.ma.cable.rcn.com (HELO funex) (209.150.50.115) by smtp04.mrf.mail.rcn.net with SMTP; 09 Mar 2005 00:36:59 -0500 Message-Id: <3sp35g$850t0@smtp04.mrf.mail.rcn.net> X-IronPort-AV: i="3.90,148,1107752400"; d="scan'208"; a="8553376:sNHT23335016" X-Sender: zdenek@pop.rcn.com X-Mailer: QUALCOMM Windows Eudora Pro Version 4.0 Date: Wed, 09 Mar 2005 00:33:56 -0500 To: hadi@cyberus.ca From: Zdenek Radouch Subject: Re: Do you know the TCP stack? (127.x.x.x routing) Cc: Eran Mann , Thomas Graf , Andi Kleen , Martin Mares , netdev@oss.sgi.com, linux-net@vger.kernel.org In-Reply-To: <1110288879.1050.167.camel@jzny.localdomain> References: <3sp35g$7rsc1@smtp04.mrf.mail.rcn.net> <422C0B50.20500@mrv.com> <20050306173145.GQ31837@postel.suug.ch> <3sp35g$7hpm0@smtp04.mrf.mail.rcn.net> <422C0B50.20500@mrv.com> <3sp35g$7rsc1@smtp04.mrf.mail.rcn.net> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" X-Virus-Scanned: ClamAV 0.83/755/Mon Mar 7 17:00:18 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 2691 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: zdenek@rcn.com Precedence: bulk X-list: netdev Content-Length: 3503 Lines: 99 At 08:34 AM 3/8/05 -0500, jamal wrote: >PS:- anyone not copying me in the responses while addressing me - i >didnt see your response. > >On Mon, 2005-03-07 at 22:15, Zdenek Radouch wrote: > >> RFC 1918 trivializes the IP addressing by boxing >> all hosts into either a "private" or "public" category, >> based on their need to access the Internet. >> > >sure. And the semantics are: dont route "private" addresses >if they stray on the "public network". In other words, it is left to the >network setup to resolve this. > >> The major thing the RFC misses is the fact that internal >> to one of these "public" or "private" hosts, you may have >> another, "even more private" network, for example one >> that connects the cards within the chassis. > >But why is this more "even more private"? Because the hosting device may be sitting on a "private" net, with which you don't want to interfere. >Surely you can use 10.x addresses just fine within a chasis. Not if the admin's SNMP/CLI client machine lives on a 10.x net. >Nothing makes 127.x addresses not usable in NATs or not be routable >once you start attching them to non-hostlocal interfaces. That's true (if I got the multiple negatives right ;-)) But what's the point you're trying to make? > >> Such network >> must be (for obvious reasons) completely hidden >> from the outside, and thus cannot come from the >> "outside" address space. This "outside" space is a union >> of the "public" and "private" IP addresses. >> Guess what's left? How 'bout 127.0.0.0. >> > >Lets see, your requirements are: >a) packets within a chasis subnet shall stay within a chasis subnet >b) the outside (of the chasis) world shall never discover whats inside >the chasis (example ARPs will fail to resolve etc) > >Did i miss anything else? Yes, a fundamental point. The "outside" of the chassis is your customer's network. The only thing you know about that network is that it is *not* 127.x. Consequently, if you don't want to interfere with the outside you must use 127.x. > >Seems to me you are relying on obscurity of 127.x As I said previously and shown above, 127 is the only one left, it has not been randomly selected. > to achieve goals which >you could achieve just as easily with a 10.x address or even a public >address. Is this correct? No. > In otherwords it doesnt matter what addresses >you use for internal chassis. What matters is how you set the route >tables etc. >I respect your desire to use whatever address range, but show me one >think i couldnt do with a 10.x in the chasis that you can now achieve >with a 127.x .. I think this will bring some clarity for me. > You couldn't walk in the NOC and tell them: "You can't use the 10.x net to manage your equipment - my box is already using that net". As a few people already pointed out, subnetting the 127 net is a common practice if you are making multi-card communication equipment, especially routers. Often, these systems must be able to communicate with the external world, either as "public" hosts, or as "private", i.e., NAT'd hosts. Because of this, the internal networks may not ever have either public or RFC 1918 addresses. For the same reason, the internal network cannot ever be "configurable", since the configured address/net would become inaccessible on the outside (it would be routed to the internal network). Note that this has nothing to do with the fact that the 127 address "never leaves the box". Hope this clarifies the issue. -Z From boian@bonev.com Wed Mar 9 00:15:07 2005 Received: with ECARTIS (v1.0.0; list netdev); Wed, 09 Mar 2005 00:15:18 -0800 (PST) Received: from mx.cisbg.com (ns.cisbg.com [195.69.109.188]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j298F3Ng032601 for ; Wed, 9 Mar 2005 00:15:06 -0800 Received: from orange.bonev.com (orange.bonev.com [195.69.108.254]) by mx.cisbg.com (8.13.1/8.13.1) with SMTP id j298F0ix004864 for ; Wed, 9 Mar 2005 10:15:01 +0200 Received: (qmail 5356 invoked by uid 99); 9 Mar 2005 08:15:01 -0000 Message-ID: <20050309081501.5354.qmail@orange.bonev.com> Mime-Version: 1.0 Received: from firewall.cisbg.com (195.69.108.252) by mail.bonev.com with HTTP; Wed, 9 Mar 2005 10:15:01 +0200 From: Boian Bonev To: netdev@oss.sgi.com Subject: GRE Ethernet tunneling Date: Wed, 9 Mar 2005 10:15:01 +0200 Content-Type: multipart/mixed; boundary="=_1_1110356101_5352" Content-Transfer-Encoding: 8bit X-BIS.BG-Antispam-Check: Yes X-Scanned-By: MIMEDefang 2.48 on 195.69.109.187 X-Virus-Scanned: ClamAV 0.83/755/Mon Mar 7 17:00:18 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 2692 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: boian@bonev.com Precedence: bulk X-list: netdev Content-Length: 2418 Lines: 57 This is a MIME-formatted message. If you see this text it means that your E-mail software does not support MIME-formatted messages. --=_1_1110356101_5352 Content-Type: text/plain; charset=windows-1251 Content-Transfer-Encoding: quoted-printable hi, first to explain why i need to make this stuff in kernel space: - userland ethernet tunneling provides more features like encryption but= not high performance and low latency - low MHz cpus choke on high traffic with userland tunnels (have a look = at WRAP boards at www.pcengines.ch) - since we have many setups with 802.11a cards and 802.11a protocol does= not support direct bridging of interfaces the lack of kernel ethernet tu= nnel limits linux use in this area btw. mikrotik (www.mikrotik.com - a linux based closed source router os) = implements a tunnel called eoip the gre way btw2. 802.11a cards support mtus over 1500 so at least software fragmenta= tion may be avoided. i am not sure what happens at lower layers but it pe= rforms without much cpu usage increase or speed loss before writing here i have made a concept proof - i cloned the ip_gre.c m= odule and changed: - device creation to be ethernet alike (mtu 1500, ARPHRD_ETHER, hard_hea= der, etc) - the protocol to be IPPROTO_GRE+1 (just for testing - not to interferre= with existing gre tunnels) - removed all code that mangled ttl, ecn, mtu etc - GRE protocol to 0x6558 (Ethernet over GRE) then i dirty patched iproute to manage the new interfaces and here i disc= overed something not very clean in interface management by iproute - when= listing interfaces iproute performs a SIOCGIFHWADDR and checks for ARPHR= D_TUNNEL... this may be clean for ip tunnels but it cant work for etherne= t tunnels. now i am looking for a clean way to identify ethernet tunnels in iproute:= - if i change the type to APRHRD_TUNNEL this will break consistency with= both userland utils and kernel side. - SIOCDEVPRIVATE + x is not appropriate because it may conflict with som= e real ethernet device - dev->flags are all defined - dev->priv_flags in not visible in userspace i need help to choose a clean and consistent strategy for iproute <---> k= ernel comm then i will be able to integrate my concept proof code into ip_gre.c another thing that comes to mind is to implement a small subset ot ethtoo= l ioctls but this does not seem consistent to me... b. --=_1_1110356101_5352-- From domen@coderock.org Wed Mar 9 00:16:56 2005 Received: with ECARTIS (v1.0.0; list netdev); Wed, 09 Mar 2005 00:17:04 -0800 (PST) Received: from trashy.coderock.org (postfix@coderock.org [193.77.147.115]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j298GsCq000507 for ; Wed, 9 Mar 2005 00:16:55 -0800 Received: by trashy.coderock.org (Postfix, from userid 780) id 9C43E1F24D; Wed, 9 Mar 2005 09:16:50 +0100 (CET) Received: from localhost (localhost [127.0.0.1]) by trashy.coderock.org (Postfix) with ESMTP id BCFCF1F248; Wed, 9 Mar 2005 09:16:49 +0100 (CET) Received: from localhost (coderock.org [193.77.147.115]) by trashy.coderock.org (Postfix) with ESMTP id 417B71F245; Wed, 9 Mar 2005 09:16:46 +0100 (CET) Date: Wed, 9 Mar 2005 09:16:45 +0100 From: Domen Puncer To: Ganesh Venkatesan Cc: jgarzik@pobox.com, netdev@oss.sgi.com, nacc@us.ibm.com, janitor@sternwelten.at Subject: Re: [patch 04/26] net/ixgb_osdep: replace schedule_timeout() with msleep() Message-ID: <20050309081645.GC10041@nd47.coderock.org> References: <20050306103248.7C3A21F1F0@trashy.coderock.org> <5fc59ff305030805243de69624@mail.gmail.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <5fc59ff305030805243de69624@mail.gmail.com> User-Agent: Mutt/1.4.2.1i X-Virus-Scanned: ClamAV 0.83/755/Mon Mar 7 17:00:18 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 2693 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: domen@coderock.org Precedence: bulk X-list: netdev Content-Length: 1992 Lines: 50 On 08/03/05 05:24 -0800, Ganesh Venkatesan wrote: > No. This would not work. You cannot replace msec_delay with msleep. > You probably could replace the set_current_task/schedule_timeout with > msleep. msleep does not check for the correct context, and if one were > to call msec_delay from interrupt context, the kernel would panic. And that would be wrong? Guess what BUG() does. > > ganesh. > > > On Sun, 06 Mar 2005 11:32:48 +0100, domen@coderock.org > wrote: > > > > > > Use msleep() instead of schedule_timeout() > > to guarantee the task delays as expected. I was told earlier that the > > in_interrupt() check is not necessary. It would be nice to get some > > verification of this (i.e. the driver functions the same without it). > > > > Signed-off-by: Nishanth Aravamudan > > Signed-off-by: Maximilian Attems > > Signed-off-by: Domen Puncer > > --- > > > > kj-domen/drivers/net/ixgb/ixgb_osdep.h | 8 +------- > > 1 files changed, 1 insertion(+), 7 deletions(-) > > > > diff -puN drivers/net/ixgb/ixgb_osdep.h~msleep-drivers_net_ixgb_ixgb_osdep drivers/net/ixgb/ixgb_osdep.h > > --- kj/drivers/net/ixgb/ixgb_osdep.h~msleep-drivers_net_ixgb_ixgb_osdep 2005-03-05 16:09:27.000000000 +0100 > > +++ kj-domen/drivers/net/ixgb/ixgb_osdep.h 2005-03-05 16:09:27.000000000 +0100 > > @@ -41,13 +41,7 @@ > > #include > > > > #ifndef msec_delay > > -#define msec_delay(x) do { if(in_interrupt()) { \ > > - /* Don't mdelay in interrupt context! */ \ > > - BUG(); \ > > - } else { \ > > - set_current_state(TASK_UNINTERRUPTIBLE); \ > > - schedule_timeout((x * HZ)/1000 + 2); \ > > - } } while(0) > > +#define msec_delay(x) msleep(x) > > #endif > > > > #define PCI_COMMAND_REGISTER PCI_COMMAND > > _ > > > > From webvenza@libero.it Wed Mar 9 00:24:08 2005 Received: with ECARTIS (v1.0.0; list netdev); Wed, 09 Mar 2005 00:24:22 -0800 (PST) Received: from localhost.localdomain (foobar@adsl-166-231.38-151.net24.it [151.38.231.166]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j298O6I6004876 for ; Wed, 9 Mar 2005 00:24:07 -0800 Received: from localhost.localdomain (localhost.localdomain [127.0.0.1]) by localhost.localdomain (Postfix) with ESMTP id 73FA72EE3F; Wed, 9 Mar 2005 09:26:57 +0100 (CET) MIME-Version: 1.0 Content-Type: multipart/mixed; charset="us-ascii"; boundary="===============1810774141==" Content-Transfer-Encoding: 7bit User-Agent: Python patchbomber v. 0.0.0.0.0.1 Message-ID: <20050309082657.14465.18016@localhost.localdomain> Subject: [PATCH 1/1] Fix default phy selection after initialization From: Daniele Venzano To: netdev@oss.sgi.com, jgarzik@pobox.com Date: Wed, 9 Mar 2005 09:26:57 +0100 (CET) X-Virus-Scanned: ClamAV 0.83/755/Mon Mar 7 17:00:18 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 2694 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: webvenza@libero.it Precedence: bulk X-list: netdev Content-Length: 1506 Lines: 51 This is a MIME message, see the first attachment for the text and the second for the patch --===============1810774141== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Previous patch correct only 99% of the time, the default phy can change during normal operation, but the mii_info struct wosn't updated. With the attached patch it is (to be applied on top of previous). For the locking issue it seems that not only sis900_timer is affected. Mii access is scattered all over the driver without locking, so I think there is need of a lot more work. Signed-off-by: Daniele Venzano --===============1810774141== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Index: sis900.c =================================================================== --- a/drivers/net/sis900.c (revision 98) +++ b/drivers/net/sis900.c (revision 99) @@ -514,8 +514,6 @@ static int __devinit sis900_probe(struct goto err_out_unregister; } - sis_priv->mii_info.phy_id = sis_priv->cur_phy; - /* save our host bridge revision */ dev = pci_get_device(PCI_VENDOR_ID_SI, PCI_DEVICE_ID_SI_630, NULL); if (dev) { @@ -725,6 +723,8 @@ static u16 sis900_default_phy(struct net net_dev->name,sis_priv->cur_phy); } + sis_priv->mii_info.phy_id = sis_priv->cur_phy; + status = mdio_read(net_dev, sis_priv->cur_phy, MII_CONTROL); status &= (~MII_CNTL_ISOLATE); --===============1810774141==-- From hno@marasystems.com Wed Mar 9 01:09:42 2005 Received: with ECARTIS (v1.0.0; list netdev); Wed, 09 Mar 2005 01:09:47 -0800 (PST) Received: from filer.marasystems.com (marasystems.com [83.241.133.2]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j2999edQ006953 for ; Wed, 9 Mar 2005 01:09:41 -0800 Received: from localhost (henrik@localhost) by filer.marasystems.com (8.11.6/8.11.6) with ESMTP id j2999Fu14213; Wed, 9 Mar 2005 10:09:15 +0100 Date: Wed, 9 Mar 2005 10:09:15 +0100 (CET) From: Henrik Nordstrom To: jamal cc: Martin Mares , Zdenek Radouch , Steve Iribarne , Eran Mann , Thomas Graf , Andi Kleen , netdev@oss.sgi.com, linux-net@vger.kernel.org Subject: Re: Do you know the TCP stack? (127.x.x.x routing) In-Reply-To: <1110316631.1084.57.camel@jzny.localdomain> Message-ID: References: <20050306173145.GQ31837@postel.suug.ch> <3sp35g$7hpm0@smtp04.mrf.mail.rcn.net> <422C0B50.20500@mrv.com> <3sp35g$7rsc1@smtp04.mrf.mail.rcn.net> <1110288879.1050.167.camel@jzny.localdomain> <20050308135134.GA20607@atrey.karlin.mff.cuni.cz> <1110290300.1050.190.camel@jzny.localdomain> <20050308140301.GC20607@atrey.karlin.mff.cuni.cz> <1110291470.1043.211.camel@jzny.localdomain> <1110316631.1084.57.camel@jzny.localdomain> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Virus-Scanned: ClamAV 0.83/755/Mon Mar 7 17:00:18 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 2695 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: hno@marasystems.com Precedence: bulk X-list: netdev Content-Length: 1959 Lines: 44 On Tue, 8 Mar 2005, jamal wrote: > Henrik, so what is the difference between this and using any random > block of addresses?;-> If the packets never leave the box i can use > IBM's block of addresses if i wanted - no need to sweat this far (with > hacking the kernel). Not if you want to maintain sane routing tables within the box and still be able for IBM to connect the box to their network. Some components of the box will need to sit both in the external and internal environments. > If Zdenek is going to put more than one box then theres nothing magical; > he will have to sit down and configure one of the boxes manually - no > escape there. No, as the packets never leaves his box in the first place there is no problem with multiple boxes. They will never share the internal network segment where the addresses are seen. He is building a multi-node box (single box, multiple internal nodes, some external intefaces) using TCP/IP for the internal communication between the nodes within the box. For this communication he propose the use of a part of the 127/8 address space, but only for the communication within his multinode box. Not for communication visible outside of the box. > If he puts only a single box then he may likely get away with it. > >>> Except this wont be practical for IPV4 since those addresses are scarce. >>> May make sense for V6 though (becomes like MAC addresses on NICS). >> >> IPv6 already have link local addressing IIRC. >> > > indeed that is what is needed in this case if the problem is address > conflict resolution. An equivalent for v4 (called zeroconf) is at: > http://www.zeroconf.org/ Unfortunately this does not apply to multihomed hosts, but provides an interesting address range which may be useable as an alternative to 127.X for the discussed purpose assuming hosts on the local network outside of the box is not using IPv4LL addresses in communication involving the box. Regards Henrik From Robert.Olsson@data.slu.se Wed Mar 9 03:10:05 2005 Received: with ECARTIS (v1.0.0; list netdev); Wed, 09 Mar 2005 03:10:09 -0800 (PST) Received: from mx1.slu.se (mx1.slu.se [130.238.96.70]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j29BA33I013365 for ; Wed, 9 Mar 2005 03:10:04 -0800 Received: from robur.slu.se (robur.slu.se [130.238.98.12]) by mx1.slu.se (8.13.1/8.13.1) with ESMTP id j29BA2I0025456 for ; Wed, 9 Mar 2005 12:10:02 +0100 Received: by robur.slu.se (Postfix, from userid 1000) id 0A653EE1E9; Wed, 9 Mar 2005 12:10:01 +0100 (CET) From: Robert Olsson MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <16942.55689.924299.906304@robur.slu.se> Date: Wed, 9 Mar 2005 12:10:01 +0100 To: Stephen Hemminger Cc: Robert Olsson , netdev@oss.sgi.com Subject: pktgen: causing lots of errors in console log In-Reply-To: <20050308140826.451435e5@dxpl.pdx.osdl.net> References: <20050308140826.451435e5@dxpl.pdx.osdl.net> X-Mailer: VM 7.18 under Emacs 21.3.1 X-Scanned-By: MIMEDefang 2.48 on 130.238.96.70 X-Virus-Scanned: ClamAV 0.83/755/Mon Mar 7 17:00:18 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 2696 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: Robert.Olsson@data.slu.se Precedence: bulk X-list: netdev Content-Length: 893 Lines: 42 Hello! Stephen Hemminger writes: > 1. Errors from IPV4 > Freeing alive in_device ffff81007e96a400 Try: --- net/core/pktgen.c.orig 2005-03-09 10:15:01.000000000 +0100 +++ net/core/pktgen.c 2005-03-09 10:24:19.000000000 +0100 @@ -151,7 +151,7 @@ #include -#define VERSION "pktgen v2.58: Packet Generator for packet performance testing.\n" +#define VERSION "pktgen v2.59: Packet Generator for packet performance testing.\n" /* #define PG_DEBUG(a) a */ #define PG_DEBUG(a) @@ -1682,7 +1682,7 @@ pkt_dev->saddr_min = in_dev->ifa_list->ifa_address; pkt_dev->saddr_max = pkt_dev->saddr_min; } - in_dev_put(in_dev); + __in_dev_put(in_dev); } rcu_read_unlock(); } > 2. Cliff is getting this with e1000 and pktgen-conf-1-2 > looks like calling schedule_timeout with lock held. > Need to reproduce this one... --ro From Robert.Olsson@data.slu.se Wed Mar 9 04:05:28 2005 Received: with ECARTIS (v1.0.0; list netdev); Wed, 09 Mar 2005 04:05:39 -0800 (PST) Received: from mx1.slu.se (mx1.slu.se [130.238.96.70]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j29C5QAe016366 for ; Wed, 9 Mar 2005 04:05:27 -0800 Received: from robur.slu.se (robur.slu.se [130.238.98.12]) by mx1.slu.se (8.13.1/8.13.1) with ESMTP id j29C5OBL003299; Wed, 9 Mar 2005 13:05:24 +0100 Received: by robur.slu.se (Postfix, from userid 1000) id 61CD2EE1E9; Wed, 9 Mar 2005 13:05:24 +0100 (CET) From: Robert Olsson MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <16942.59012.365490.619623@robur.slu.se> Date: Wed, 9 Mar 2005 13:05:24 +0100 To: Simon Kirby Cc: Robert Olsson , netdev@oss.sgi.com Subject: Re: Route cache performance In-Reply-To: <20050309014516.GA806@netnation.com> References: <20050301220743.GF2554@netnation.com> <16940.9990.975632.115834@robur.slu.se> <20050309014516.GA806@netnation.com> X-Mailer: VM 7.18 under Emacs 21.3.1 X-Scanned-By: MIMEDefang 2.48 on 130.238.96.70 X-Virus-Scanned: ClamAV 0.83/755/Mon Mar 7 17:00:18 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 2697 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: Robert.Olsson@data.slu.se Precedence: bulk X-list: netdev Content-Length: 3038 Lines: 68 Simon Kirby writes: > Interesting patch! I haven't had a chance to try it yet, but I have > been thinking about this sort of approach for some time. > > I'm wondering, though, if this patch would ever be accepted upstream. > The preroute patches make it now require a full slow route lookup > before checking the route cache, right? Eg: ip_route_input() is > replaced with a call to ip_route_input_nohash() which then might fall > back on ip_route_input() which checks the route cache. The nohash > function, however, still appears to have to do the full fib_lookup() > which is the same as doing at least one slow route lookup for every > packet. Well the intention with the patch was to be able to test performance w/o route hash as many poeple think if just route hash goes away all things will be fine. Jamal and I starting hacking on this at OLS 2004 and it was used to test LC-trie. IMO there is still no definitive answer and even the answer is dependent of other things i.e how much can we improve FIB lookup etc, Also a bit interesting is those DDOS stories/cases being heard, This as I'm involved in configuring and solving practical routing problems but never seen DDOS at the levels reported. We should design for worst case but not for something that's totally broke. > The random src/dst DoS case really kills the route cache because of the > rehashing, locking, and memory allocation and freeing. I see that the > RCU lists and locking now makes it very difficult to recycle the entries, > so I think this patch is probably the right idea for now (although the > route cache should probably still be optimized where possible). To some extent true... but you have the patches to test and copare with pure FIB lookup yourself. Try single and DDOS and compare. DDOS forces a lot of FIB lookups still and keeps your L2 cache very busy you see degradation here to. I have some results to compare with, Also route hash can be improved and of course it can tuned but it needs some effort. BTW I have some patches somewhere that makes input route hash per device a bit NAPI thinking to get fairness in case of DDOS etc. I heard some examples of intelligent dropping at DDOS attacks in the PREROUTE hook. > I was wondering if instead it makes sense to still check the route cache > first, but insert the bypass code as in ip_route_input_nohash() between > where the slow route lookup is done and the dst cache entry is created. > In other words: > > - The route cache is checked first. Entries in the route cache will > continue immediately as they do now. > > - Entries not in the route cache will trigger a slow route lookup as they > do now. > > - Routes which are "INPUT" or "OUTPUT" routes (eg: in or out of the local > machine) will be added to the route cache as normal. Maybe a variant. You have to lookup the hash and could still hold src/local_IPs/tos entries so we open for DDOS again? We have some experiments to do... --ro From hadi@cyberus.ca Wed Mar 9 04:39:35 2005 Received: with ECARTIS (v1.0.0; list netdev); Wed, 09 Mar 2005 04:39:39 -0800 (PST) Received: from mx04.cybersurf.com (mx04.cybersurf.com [209.197.145.108]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j29CdYHq021530 for ; Wed, 9 Mar 2005 04:39:35 -0800 Received: from mail.cyberus.ca ([209.197.145.21]) by mx01.cybersurf.com with esmtp (Exim 4.30) id 1D90TJ-0008OE-OS for netdev@oss.sgi.com; Wed, 09 Mar 2005 07:39:29 -0500 Received: from [24.103.99.32] (helo=[10.0.0.9]) by mail.cyberus.ca with esmtp (Exim 4.20) id 1D90TG-0007Sn-EF; Wed, 09 Mar 2005 07:39:26 -0500 Subject: Re: Do you know the TCP stack? (127.x.x.x routing) From: jamal Reply-To: hadi@cyberus.ca To: Henrik Nordstrom Cc: Martin Mares , Zdenek Radouch , Steve Iribarne , Eran Mann , Thomas Graf , Andi Kleen , netdev@oss.sgi.com, linux-net@vger.kernel.org In-Reply-To: References: <20050306173145.GQ31837@postel.suug.ch> <3sp35g$7hpm0@smtp04.mrf.mail.rcn.net> <422C0B50.20500@mrv.com> <3sp35g$7rsc1@smtp04.mrf.mail.rcn.net> <1110288879.1050.167.camel@jzny.localdomain> <20050308135134.GA20607@atrey.karlin.mff.cuni.cz> <1110290300.1050.190.camel@jzny.localdomain> <20050308140301.GC20607@atrey.karlin.mff.cuni.cz> <1110291470.1043.211.camel@jzny.localdomain> <1110316631.1084.57.camel@jzny.localdomain> Content-Type: text/plain Organization: jamalopolous Message-Id: <1110371962.1088.90.camel@jzny.localdomain> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.2.2 Date: 09 Mar 2005 07:39:22 -0500 Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV 0.83/757/Tue Mar 8 15:14:36 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 2698 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: hadi@cyberus.ca Precedence: bulk X-list: netdev Content-Length: 3104 Lines: 74 Zdenek - This includes a response to your email as well. On Wed, 2005-03-09 at 04:09, Henrik Nordstrom wrote: > On Tue, 8 Mar 2005, jamal wrote: > > > Henrik, so what is the difference between this and using any random > > block of addresses?;-> If the packets never leave the box i can use > > IBM's block of addresses if i wanted - no need to sweat this far (with > > hacking the kernel). > > Not if you want to maintain sane routing tables within the box and still > be able for IBM to connect the box to their network. Some components of > the box will need to sit both in the external and internal environments. > For the record i have built or helped build many many such boxes... I am afraid this 127.x panacea is begining to sound like the tale of some insane emperor who was naked but people around him sucking up to him telling him how fine his clothes looked. I am having a very hard time seeing the rationale - infact its driving me nuts, so please bear with me. Lets list the options and assume there are two sets of addresses those for inside the chasis and those for outside: 1) Addresses for intra-chasis communication. The addresses used by the blades are intrachasis relevant only and the packets never leave the box. The blades are interconnected via some L2/VLAN/bridge within the chasis. Conclusion: If these packets never leave the box - no ARP will ever see them and no dynamic routing protocol will ever advertise them - therefore no IP address collision. You can use _whatever_ address you want, private public, IBMs, intels etc. Do we agree on this? In other words hack not needed here. 2) The addresses for chasis-outside world communication. You have one or more dedicated gateways to connect between the outside of the chasis to inside. There are many tricks you could use to somehow get the packets to/from the internal blades: NAT, forward, have aliases inside the chasis which get forwarded etc. Lets not discuss about how the the packets finaly make it outside, rather just assume these packets make it outside the chasis then lets explore using either 127.x or RFC1918 addresses. a) using private addresses implies possibility of conflict of addresses within customer's network. To quote Zdenek: You couldn't walk in the NOC and tell them: "You can't use the 10.x net to manage your equipment - my box is already using that net". Conclusion: You walk into the NOC and say "can i use 10.0.0.x/22 subnet" they say "no thats going to collide use 10.0.0.0/28" Summary: You may need to go to your box and reconfigure its external looking addresses. a') Using 127.x addresses. You -> NOC "can i use 127.0.0.x/22 subnet" they say either "sorry, our routers cant route 127.x" or "no Zdenek was here before you, thats going to collide use 127.0.0.0/28" Same conclusion as 2a) Do you see the problem? I dont see the difference between 2a) and 2a') I also dont see the reason you need 127.x for 1) since you could have used any address for the intra-chasis (I have seen people use many differrent addresses). So tell me what i am missing! cheers, jamal From oray@lucent.com Wed Mar 9 05:35:52 2005 Received: with ECARTIS (v1.0.0; list netdev); Wed, 09 Mar 2005 05:35:58 -0800 (PST) Received: from ihemail1.lucent.com (ihemail1.lucent.com [192.11.222.161]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j29DZqOV023949 for ; Wed, 9 Mar 2005 05:35:52 -0800 Received: from nj7460exch001h.wins.lucent.com (h135-17-42-36.lucent.com [135.17.42.36]) by ihemail1.lucent.com (8.12.11/8.12.11) with ESMTP id j29DZjqe029029 for ; Wed, 9 Mar 2005 07:35:45 -0600 (CST) Received: by nj7460exch001h.ho.lucent.com with Internet Mail Service (5.5.2657.72) id ; Wed, 9 Mar 2005 08:35:44 -0500 Message-ID: From: "Balasaygun, Oray (Oray)" To: "'Andrew Morton'" , "Balasaygun, Oray (Oray)" Cc: linuxppc-dev@ozlabs.org, netdev@oss.sgi.com, "Nikoonezhad, Danesh (Danesh)" Subject: RE: [Bugme-new] [Bug 4310] New: ppc 8260 fcc ethernet driver cann ot read LXT971 PHY id Date: Wed, 9 Mar 2005 08:35:42 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: multipart/mixed; boundary="----_=_NextPart_000_01C524AC.E3CA6D1A" X-Virus-Scanned: ClamAV 0.83/757/Tue Mar 8 15:14:36 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 2699 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: oray@lucent.com Precedence: bulk X-list: netdev Content-Length: 7613 Lines: 213 This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_000_01C524AC.E3CA6D1A Content-Type: text/plain Hi, Attached please find the diff output of the fcc_enet.c that I am running with and the original 2.6.10 version of it. There are 3 category of differences: 1. The fix for Bug 4310 that I reported: these are the last 6 lines of the diffout file. 2. The fcc_enet.c, as distributed in 2.6.10, does not compile. Evidently the 2.6 kernel no longer supports the schedule_task() and "struct tq_struct" to go with it. Lines 73 through and including 96 of the diffout file show the changes I made to port schedule_task() into tasklet_schedule(). I should have reported this as a bug too but I forgot about it. 3. The rest of the lines in the diffout file are for the purpose of customizing fcc_enet.c to work with my custom board. These changes are conditional on CONFIG_EON8260 being defined. Oray Balasaygun -----Original Message----- From: Andrew Morton [mailto:akpm@osdl.org] Sent: Tuesday, March 08, 2005 2:49 PM To: oray@lucent.com Cc: linuxppc-dev@ozlabs.org; netdev@oss.sgi.com Subject: Re: [Bugme-new] [Bug 4310] New: ppc 8260 fcc ethernet driver cannot read LXT971 PHY id I'm not sure that we have a maintainer for fcc_enet.c. Could you please send in a tested diff? bugme-daemon@osdl.org wrote: > > http://bugme.osdl.org/show_bug.cgi?id=4310 > > Summary: ppc 8260 fcc ethernet driver cannot read LXT971 PHY id > Kernel Version: 2.6.10 > Status: NEW > Severity: normal > Owner: platform_ppc-32@kernel-bugs.osdl.org > Submitter: oray@lucent.com > > > Distribution: www.kernel.org > Hardware Environment: Target: PowerPC 8260 custom board > Software Environment: Red Hat 9 cross development using ELDK 3.1 distribution. > Problem Description: Fast ethernet driver (fcc_enet.c) initialization fails to > read a valid id from registers 2 and 3 of the LXT971 PHY device and calls the > panic routine. The bug is in the mii_send_receive() function. During the read > phase, per LXT971 data sheet, the device starts driving the MDIO line after the > rising edge of the MDC clock and it could take up to 150ns before the data > settles. The driver reads the MDIO line before waiting for the data to settle > down and thus reads in garbage. I fixed the problem by moving the sampling of > the MDIO line to after the MDC clock is taken low. The code snippet follows: > > > for (i = 0, off = 15; i < 16; i++, off--) > { > #define FCC_8260_BUG > FCC_PDATC_MDC(1); > retval <<= 1; > #ifndef FCC_8260_BUG > if (io->iop_pdatc & fip->fc_mdio) > retval++; > udelay(1); > FCC_PDATC_MDC(0); > #else > udelay(1); > FCC_PDATC_MDC(0); > if (io->iop_pdatc & fip->fc_mdio) > retval++; > #endif > udelay(1); > #undef FCC_8260_BUG > } > > > Steps to reproduce: Is likely to happen on an 8260 target with any kind of PHY, > not just the LXT971, hooked up to the FCC port. > > ------- You are receiving this mail because: ------- > You are on the CC list for the bug, or are watching someone who is. ------_=_NextPart_000_01C524AC.E3CA6D1A Content-Type: application/octet-stream; name="diffout" Content-Transfer-Encoding: quoted-printable Content-Disposition: attachment; filename="diffout" 180,227d179=0A= < #ifdef CONFIG_EON8260=0A= < =0A= < #define MAKE_BITMASK(n) (1 << (31-n))=0A= < =0A= < #define PA8 MAKE_BITMASK(8)=0A= < #define PA9 MAKE_BITMASK(9)=0A= < =0A= < #define PB18 MAKE_BITMASK(18)=0A= < #define PB19 MAKE_BITMASK(19)=0A= < #define PB20 MAKE_BITMASK(20)=0A= < #define PB21 MAKE_BITMASK(21)=0A= < #define PB22 MAKE_BITMASK(22)=0A= < #define PB23 MAKE_BITMASK(23)=0A= < #define PB24 MAKE_BITMASK(24)=0A= < #define PB25 MAKE_BITMASK(25)=0A= < #define PB26 MAKE_BITMASK(26)=0A= < #define PB27 MAKE_BITMASK(27)=0A= < #define PB28 MAKE_BITMASK(28)=0A= < #define PB29 MAKE_BITMASK(29)=0A= < #define PB30 MAKE_BITMASK(30)=0A= < #define PB31 MAKE_BITMASK(31)=0A= < =0A= < #define PB2_TXER PB31=0A= < #define PB2_RXDV PB30=0A= < #define PB2_TXEN PB29=0A= < #define PB2_RXER PB28=0A= < #define PB2_COL PB27=0A= < #define PB2_CRS PB26=0A= < #define PB2_TXDAT (PB22 | PB23 | PB24 | PB25)=0A= < #define PB2_RXDAT (PB18 | PB19 | PB20 | PB21)=0A= < #define PB2_PSORB0 (PB2_RXDAT | PB2_TXDAT | PB2_CRS | PB2_COL | = \=0A= < PB2_RXER | PB2_RXDV | PB2_TXER)=0A= < #define PB2_PSORB1 (PB2_TXEN)=0A= < #define PB2_DIRB0 (PB2_RXDAT | PB2_CRS | PB2_COL | PB2_RXER | = PB2_RXDV)=0A= < #define PB2_DIRB1 (PB2_TXDAT | PB2_TXEN | PB2_TXER)=0A= < =0A= < /* CLK16 (PC16) is receive, CLK15 (PC17) is transmit */=0A= < =0A= < #define PC_F2RXCLK ((uint)0x00008000)=0A= < #define PC_F2TXCLK ((uint)0x00004000)=0A= < =0A= < #define CMXFCR_TF2CS_CLK15 0x00060000 /* Transmit FCC2 Clock Source = is CLK15 */=0A= < #define CMXFCR_RF2CS_CLK16 0x00380000 /* Receive FCC2 Clock Source = is CLK16 */=0A= < #define CMX2_CLK_ROUTE (CMXFCR_RF2CS_CLK16 | CMXFCR_TF2CS_CLK15)=0A= < #define CMX2_CLK_MASK ((uint)0x00ff0000)=0A= < =0A= < #else /* #ifdef CONFIG_EON8260 */=0A= < =0A= 259,260d210=0A= < #endif /* #ifdef CONFIG_EON8260 */=0A= < =0A= 287,291c237=0A= < #if defined (CONFIG_EON8260)=0A= < /* EON8260 has MDIO and MDCK on PC31 and PC30 respectively */=0A= < #define PC_MDIO ((uint)0x00000001)=0A= < #define PC_MDCK ((uint)0x00000002)=0A= < #elif defined (CONFIG_TQM8260)=0A= ---=0A= > #ifdef CONFIG_TQM8260=0A= 325c271=0A= < # if defined(CONFIG_TQM8260) || defined(CONFIG_ADS8272) || = defined(CONFIG_EON8260)=0A= ---=0A= > # if defined(CONFIG_TQM8260) || defined(CONFIG_ADS8272)=0A= 334c280=0A= < # if defined(CONFIG_TQM8260) || defined(CONFIG_ADS8272) || = defined(CONFIG_EON8260)=0A= ---=0A= > # if defined(CONFIG_TQM8260) || defined(CONFIG_ADS8272)=0A= 345c291=0A= < # if defined(CONFIG_TQM8260) || defined(CONFIG_ADS8272) || = defined(CONFIG_EON8260)=0A= ---=0A= > # if defined(CONFIG_TQM8260) || defined(CONFIG_ADS8272)=0A= 386c332=0A= < struct tasklet_struct phy_task;=0A= ---=0A= > struct tq_struct phy_task;=0A= 1303c1249=0A= < fep->phy_task.func =3D (void *)mii_relink;=0A= ---=0A= > fep->phy_task.routine =3D (void *)mii_relink;=0A= 1305c1251=0A= < tasklet_schedule(&fep->phy_task);=0A= ---=0A= > schedule_task(&fep->phy_task);=0A= 1312c1258=0A= < fep->phy_task.func =3D (void *)mii_display_config;=0A= ---=0A= > fep->phy_task.routine =3D (void *)mii_display_config;=0A= 1314c1260=0A= < tasklet_schedule(&fep->phy_task);=0A= ---=0A= > schedule_task(&fep->phy_task);=0A= 1521,1523d1466=0A= < cep->phy_task.next =3D NULL;=0A= < cep->phy_task.state =3D 0;=0A= < cep->phy_task.count.counter =3D 0;=0A= 1758,1762d1700=0A= < #if defined(CONFIG_EON8260)=0A= < for (i=3D5; i>=3D0; i--) {=0A= < *eap++ =3D dev->dev_addr[i] =3D = bd->bi_enetaddr[i];=0A= < }=0A= < #else /* if defined(CONFIG_EON8260) */=0A= 1783d1720=0A= < #endif /* if defined(CONFIG_EON8260) */=0A= 2006,2007d1942=0A= < udelay(1);=0A= < FCC_PDATC_MDC(0);=0A= 2010a1946,1947=0A= > FCC_PDATC_MDC(0);=0A= > udelay(1);=0A= ------_=_NextPart_000_01C524AC.E3CA6D1A-- From zdenek@rcn.com Wed Mar 9 05:42:14 2005 Received: with ECARTIS (v1.0.0; list netdev); Wed, 09 Mar 2005 05:42:18 -0800 (PST) Received: from smtp01.mrf.mail.rcn.net (smtp01.mrf.mail.rcn.net [207.172.4.60]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j29DgEV7024749 for ; Wed, 9 Mar 2005 05:42:14 -0800 Received: from 209-150-50-115.c3-0.nwt-ubr3.sbo-nwt.ma.cable.rcn.com ([209.150.50.115] helo=funex) by smtp01.mrf.mail.rcn.net with smtp (Exim 3.35 #7) id 1D91Rz-0004wp-00; Wed, 09 Mar 2005 08:42:11 -0500 X-Sender: zdenek@pop.rcn.com X-Mailer: QUALCOMM Windows Eudora Pro Version 4.0 Date: Wed, 09 Mar 2005 08:39:10 -0500 To: hadi@cyberus.ca, Henrik Nordstrom From: Zdenek Radouch Subject: Re: Do you know the TCP stack? (127.x.x.x routing) Cc: Martin Mares , Eran Mann , Thomas Graf , Andi Kleen , netdev@oss.sgi.com, linux-net@vger.kernel.org In-Reply-To: <1110371962.1088.90.camel@jzny.localdomain> References: <20050306173145.GQ31837@postel.suug.ch> <3sp35g$7hpm0@smtp04.mrf.mail.rcn.net> <422C0B50.20500@mrv.com> <3sp35g$7rsc1@smtp04.mrf.mail.rcn.net> <1110288879.1050.167.camel@jzny.localdomain> <20050308135134.GA20607@atrey.karlin.mff.cuni.cz> <1110290300.1050.190.camel@jzny.localdomain> <20050308140301.GC20607@atrey.karlin.mff.cuni.cz> <1110291470.1043.211.camel@jzny.localdomain> <1110316631.1084.57.camel@jzny.localdomain> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Message-Id: X-Virus-Scanned: ClamAV 0.83/757/Tue Mar 8 15:14:36 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 2700 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: zdenek@rcn.com Precedence: bulk X-list: netdev Content-Length: 2221 Lines: 54 At 07:39 AM 3/9/05 -0500, jamal wrote: >... >Lets list the options and assume there are two sets of addresses those >for inside the chasis and those for outside: > >1) Addresses for intra-chasis communication. >The addresses used by the blades are intrachasis relevant only and the >packets never leave the box. The blades are interconnected via some >L2/VLAN/bridge within the chasis. > >Conclusion: >If these packets never leave the box - no ARP will ever see them and no >dynamic routing protocol will ever advertise them - therefore no IP >address collision. You can use _whatever_ address you want, private >public, IBMs, intels etc. Do we agree on this? In other words hack not >needed here. No, I do not agree - you really need to re-read my last post carefully, making sure you understand what I am saying. Other people have illustrated the problem as well. Imagine a simple gateway, connecting two parts of your company - the east interface connects to a corporate net with a default gateway, the west net is the software dept. net. Now imagine that you give your internal line card in this simple gateway a "_whatever_" address, say 18.7.22.69. Your gateway now has a route 18.7.22.69/32 -> dev linecard Now please tell me what happens when a guy on the west net tries to check his MIT evening class schedule. >a) using private addresses implies possibility of conflict of addresses >within customer's network. To quote Zdenek: >You couldn't walk in the NOC and tell them: "You can't use the 10.x >net to manage your equipment - my box is already using that net". >Conclusion: >You walk into the NOC and say "can i use 10.0.0.x/22 subnet" they say "no >thats going to collide use 10.0.0.0/28" In real world, where you pay for addresses and for people's time, no one will give you *their* address for *your* interconnect. Not a public address, and not a RFC1918 address. Your interconnect is your problem, they are neither interested nor paid to deal with your design issues. >a') Using 127.x addresses. You -> NOC "can i use 127.0.0.x/22 subnet" I know I can use it. I own it as per RFC 3330. >So tell me what i am missing! Experience of having built a router. Sorry to be so blunt. -Zdenek From hadi@cyberus.ca Wed Mar 9 06:18:26 2005 Received: with ECARTIS (v1.0.0; list netdev); Wed, 09 Mar 2005 06:18:30 -0800 (PST) Received: from mx03.cybersurf.com (mx03.cybersurf.com [209.197.145.106]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j29EIOad026883 for ; Wed, 9 Mar 2005 06:18:25 -0800 Received: from mail.cyberus.ca ([209.197.145.21]) by mx03.cybersurf.com with esmtp (Exim 4.30) id 1D920z-0003fr-IL for netdev@oss.sgi.com; Wed, 09 Mar 2005 09:18:21 -0500 Received: from [24.103.99.32] (helo=[10.0.0.9]) by mail.cyberus.ca with esmtp (Exim 4.20) id 1D920u-0004cK-4n; Wed, 09 Mar 2005 09:18:16 -0500 Subject: Re: Do you know the TCP stack? (127.x.x.x routing) From: jamal Reply-To: hadi@cyberus.ca To: Zdenek Radouch Cc: Henrik Nordstrom , Martin Mares , Eran Mann , Thomas Graf , Andi Kleen , netdev@oss.sgi.com, linux-net@vger.kernel.org In-Reply-To: References: <20050306173145.GQ31837@postel.suug.ch> <3sp35g$7hpm0@smtp04.mrf.mail.rcn.net> <422C0B50.20500@mrv.com> <3sp35g$7rsc1@smtp04.mrf.mail.rcn.net> <1110288879.1050.167.camel@jzny.localdomain> <20050308135134.GA20607@atrey.karlin.mff.cuni.cz> <1110290300.1050.190.camel@jzny.localdomain> <20050308140301.GC20607@atrey.karlin.mff.cuni.cz> <1110291470.1043.211.camel@jzny.localdomain> <1110316631.1084.57.camel@jzny.localdomain> Content-Type: text/plain Organization: jamalopolous Message-Id: <1110377889.1090.124.camel@jzny.localdomain> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.2.2 Date: 09 Mar 2005 09:18:10 -0500 Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV 0.83/757/Tue Mar 8 15:14:36 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 2701 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: hadi@cyberus.ca Precedence: bulk X-list: netdev Content-Length: 2953 Lines: 74 On Wed, 2005-03-09 at 08:39, Zdenek Radouch wrote: > At 07:39 AM 3/9/05 -0500, jamal wrote: [..] > Imagine a simple gateway, connecting two parts of your company > - the east > interface connects to a corporate net with a default gateway, the west net > is the software dept. net. Now imagine that you give your internal line card > in this simple gateway a "_whatever_" address, say 18.7.22.69. > Your gateway now has a route 18.7.22.69/32 -> dev linecard > Now please tell me what happens when a guy on the west net tries > to check his MIT evening class schedule. Are we still talking about the same problem? The linecards addresses and interconnect interfaces are "internal". They are never advertised/seen outside of the chasis. So if you choose 18.7.22.69/32 to use internally you make sure it is never advertised to the outside world as belonging to you. If you have to advertise it or actually know it is used, then you must deal with the conflict. Of course, there are "externally" visible addresses which are seen outside the chasis; How you end up connecting internal inter-line card is your problem - lets say there are more than one ways and infact you may never even need to use IP. > >a) using private addresses implies possibility of conflict of addresses > >within customer's network. To quote Zdenek: > >You couldn't walk in the NOC and tell them: "You can't use the 10.x > >net to manage your equipment - my box is already using that net". > >Conclusion: > >You walk into the NOC and say "can i use 10.0.0.x/22 subnet" they say "no > >thats going to collide use 10.0.0.0/28" > > In real world, where you pay for addresses and for people's time, no one > will give you *their* address for *your* interconnect. Not a public address, > and not a RFC1918 address. Your interconnect is your problem, > they are neither interested nor paid to deal with your design issues. > I dont think i was saying anything different. > > >a') Using 127.x addresses. You -> NOC "can i use 127.0.0.x/22 subnet" > > I know I can use it. I own it as per RFC 3330. > RFC 3300 does not give you any rights to use it the way you are. To quote RFC 3300: -- A datagram sent by a higher level protocol to an address anywhere within this block should loop back inside the host. --- > >So tell me what i am missing! > > Experience of having built a router. Sorry to be so blunt. > Youd be the first person to ever accuse me of that. Lets say I have never needed this hack; the key is to be able to clearly demarcate what are _internal and external interfaces as well as what are internal and external IP addresses_. Yes, you can do it with Linux. What you seem to be counting on is you being the only person ever using the hack. In other words, survival via obscurity. If the router upstream from you used the same hack you end up being in trouble. You seem to be getting angry, it may be time to end the discussion. cheers, jamal From rmocius@auste.elnet.lt Wed Mar 9 06:30:30 2005 Received: with ECARTIS (v1.0.0; list netdev); Wed, 09 Mar 2005 06:30:34 -0800 (PST) Received: from mail01.mail.esat.net (mail01.mail.esat.net [193.120.142.6]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j29EUTxM027851 for ; Wed, 9 Mar 2005 06:30:30 -0800 Received: from sachsen-adsl.adsl.esat.net (RIMAS) [193.120.73.6] by mail01.mail.esat.net with smtp id 1D92Cg-0003Ss-00; Wed, 09 Mar 2005 14:30:26 +0000 Message-ID: <00c301c524b4$938cd240$6e69690a@RIMAS> From: "Remus" To: Cc: , "Nguyen Dinh Nam" , "Andre Tomt" , , "Andy Furniss" , "Damion de Soto" References: <1107123123.8021.80.camel@jzny.localdomain> <0fcf01c5077f$579e4b80$6e69690a@RIMAS> <1107174142.8021.121.camel@jzny.localdomain> Subject: Re: dummy as IMQ replacement Date: Wed, 9 Mar 2005 14:30:42 -0000 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=original Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.2180 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 X-Virus-Scanned: ClamAV 0.83/757/Tue Mar 8 15:14:36 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 2702 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: rmocius@auste.elnet.lt Precedence: bulk X-list: netdev Content-Length: 1079 Lines: 39 Hi Jamal, I have problem with iproute2: 1) if I use current iproute2 I get this error when I run this command: tc filter add dev eth2 parent ffff: protocol ip prio 10 u32 match u32 0 0 flowid 1:1 action ipt -j MARK --set-mark 1 action mirred egress redirect dev dummy0 /usr/local/lib/iptables/libipt_mark.so: undefined symbol: register_match failed to find target MARK bad action parsing parse_action: bad value (11:ipt)! Illegal "action" 2) if I use iproute2-2.6.9-jamal I get this error: tc filter add dev eth2 parent ffff: protocol ip prio 10 u32 match u32 0 0 flowid 1:1 action ipt -j MARK --set-mark 1 action mirred egress redirect dev dummy0 bad action type ipt Usage: ... gact [RAND] [INDEX] Where: ACTION := reclassify | drop | continue | pass RAND := random RANDTYPE := netrand | determVAL : = value not exceeding 10000INDEX := index value used bad action parsing parse_action: bad value (11:ipt)! Illegal "action" Any ideas? May I use some iptables command to forward all incomming traffic to dummy? Regards Remus From hadi@cyberus.ca Wed Mar 9 06:39:07 2005 Received: with ECARTIS (v1.0.0; list netdev); Wed, 09 Mar 2005 06:39:10 -0800 (PST) Received: from mx03.cybersurf.com (mx03.cybersurf.com [209.197.145.106]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j29Ed69h028736 for ; Wed, 9 Mar 2005 06:39:06 -0800 Received: from mail.cyberus.ca ([209.197.145.21]) by mx03.cybersurf.com with esmtp (Exim 4.30) id 1D92L1-0006Ar-K0 for netdev@oss.sgi.com; Wed, 09 Mar 2005 09:39:03 -0500 Received: from [24.103.99.32] (helo=[10.0.0.9]) by mail.cyberus.ca with esmtp (Exim 4.20) id 1D92Kx-0007tR-NB; Wed, 09 Mar 2005 09:38:59 -0500 Subject: Re: dummy as IMQ replacement From: jamal Reply-To: hadi@cyberus.ca To: Remus Cc: netdev@oss.sgi.com, Nguyen Dinh Nam , Andre Tomt , syrius.ml@no-log.org, Andy Furniss , Damion de Soto In-Reply-To: <00c301c524b4$938cd240$6e69690a@RIMAS> References: <1107123123.8021.80.camel@jzny.localdomain> <0fcf01c5077f$579e4b80$6e69690a@RIMAS> <1107174142.8021.121.camel@jzny.localdomain> <00c301c524b4$938cd240$6e69690a@RIMAS> Content-Type: text/plain Organization: jamalopolous Message-Id: <1110379135.1091.143.camel@jzny.localdomain> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.2.2 Date: 09 Mar 2005 09:38:56 -0500 Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV 0.83/757/Tue Mar 8 15:14:36 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 2703 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: hadi@cyberus.ca Precedence: bulk X-list: netdev Content-Length: 952 Lines: 27 On Wed, 2005-03-09 at 09:30, Remus wrote: > Hi Jamal, > > > I have problem with iproute2: > 1) if I use current iproute2 I get this error when I run this command: > tc filter add dev eth2 parent ffff: protocol ip prio 10 u32 match u32 0 0 > flowid 1:1 action ipt -j MARK --set-mark 1 action mirred egress redirect dev > dummy0 > /usr/local/lib/iptables/libipt_mark.so: undefined symbol: register_match > failed to find target MARK > That should work. Dont bother with iproute2-2.6.9-jamal. What version of iptables are you using? Unfortunately i have to keep track of changes happening in iptables as well and they keep changing the interface from under me. Try to use the same iptables version as the one whose headers are found in the iproute2 version you are using. I have to go to work - so wont have time to look at this for sometime. Maybe some of the netfilter folks like Patrick can solve it for you before i get back. cheers, jamal From steve.iribarne@dilithiumnetworks.com Wed Mar 9 07:01:36 2005 Received: with ECARTIS (v1.0.0; list netdev); Wed, 09 Mar 2005 07:01:40 -0800 (PST) Received: from DHOST001-17.DEX001.intermedia.net (dhost001-17.intermedia.net [64.78.61.64]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j29F1ZIe030066 for ; Wed, 9 Mar 2005 07:01:36 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Subject: RE: Do you know the TCP stack? (127.x.x.x routing) Date: Wed, 9 Mar 2005 07:01:34 -0800 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Do you know the TCP stack? (127.x.x.x routing) Thread-Index: AcUkpQnSI8AczuPTQgK6no7frABYCgAELU1A From: "Steve Iribarne" To: , "Henrik Nordstrom" Cc: "Martin Mares" , "Zdenek Radouch" , "Eran Mann" , "Thomas Graf" , "Andi Kleen" , , X-Virus-Scanned: ClamAV 0.83/757/Tue Mar 8 15:14:36 2005 on oss.sgi.com X-Virus-Status: Clean Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by oss.sgi.com id j29F1ZIe030066 X-archive-position: 2704 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: steve.iribarne@dilithiumnetworks.com Precedence: bulk X-list: netdev Content-Length: 4585 Lines: 123 First off, apologies for the all the cc's on this. I hate doing it, but I will only do it for this post! -> 1) Addresses for intra-chasis communication. -> The addresses used by the blades are intrachasis relevant only and the -> packets never leave the box. The blades are interconnected via some -> L2/VLAN/bridge within the chasis. -> Big assumption here. The VLAN/Bridge/Router that I have in my chassis is hooked up to a switch. The switch will NOT send the packets on my mgmt VLAN out over the network. (see below for more details on this.. in the "what am I missing" section ) -> Conclusion: -> If these packets never leave the box - no ARP will ever see them and no -> dynamic routing protocol will ever advertise them - therefore no IP -> address collision. You can use _whatever_ address you want, private -> public, IBMs, intels etc. Do we agree on this? In other words hack not -> needed here. Wrong. Packets need to leave each blade. You cannot treat the blades as a private entity. You must ARP to find out the other blades MAC address. -> -> 2) The addresses for chasis-outside world communication. You have one or -> more dedicated gateways to connect between the outside of the chasis to -> inside. -> There are many tricks you could use to somehow get the packets to/from -> the internal blades: NAT, forward, have aliases inside the chasis which -> get forwarded etc. Lets not discuss about how the the packets finaly -> make it outside, rather just assume these packets make it outside the -> chasis then lets explore using either 127.x or RFC1918 addresses. -> -> a) using private addresses implies possibility of conflict of addresses -> within customer's network. To quote Zdenek: -> You couldn't walk in the NOC and tell them: "You can't use the 10.x -> net to manage your equipment - my box is already using that net". -> Conclusion: -> You walk into the NOC and say "can i use 10.0.0.x/22 subnet" they say "no -> thats going to collide use 10.0.0.0/28" -> Summary: You may need to go to your box and reconfigure its external -> looking -> addresses. -> I _use_ to do exactly what you stated above. When RFC 1918 first came out I used the 10 net. 1st bug: Customer had the same 10.100.xx.xx/24 net that I had and my inter-system communication wouldn't work, because all my routes got screwed up. (i.e the SNMP sub-agents couldn't talk with the master). 1st response to bug: Well can you use another network address range? Customer response: Hell no. Solution to bug1: Easy, let the user configure the mgmt network ip address. Customers answer to bug1 solution: Get the hell out of here; you don't do out-of-band mgmt. Do you know what a security risk this is for me? Blah blah blah.... Even though all inter-chassis communication was done securely, I couldn't convince them. I had a customer boot me out of his office and boot our company out **because** of my design. Not a good feeling. -> a') Using 127.x addresses. You -> NOC "can i use 127.0.0.x/22 subnet" -> they say either "sorry, our routers cant route 127.x" or "no Zdenek -> was here before you, thats going to collide use 127.0.0.0/28" -> This is __EXACTLY__ the behavior we want. I want routers to drop those packets. My inter-chassis communication better NOT go through a router. -> So tell me what i am missing! -> Experience. You are missing a big key factor. The routing part of what you are saying is sound. The big thing you are not getting is how the "applications", telnet, snmp, ssh, Linux-HA, etc.. will interact with your system. You do NOT want to rewrite those applications to have some knowledge of your system. They want to connect to an IP address and that better work (off-the-shelf). Therefore, As a kernel programmer, it's easier for me to make sure the 127.xx net works and sends the 127.xx packets to the proper network. In conclusion: It seems that Zdenek and I have been down this road _many_ times. I have shipped over 10 different routers/chassis systems. I speak from experience and experience alone. I don't claim to be the smartest person in the world, but I know what works. This post started with a simple question of "can I do this". The answer I believe has been posted a long time ago. I am not about to change the way that I do my inter-chassis communications until the IEEE or RFC community give me an address change for inter-chassis communication. (which I believe is coming down the road). And would you please subscribe to the list so I don't have the cc the world every time? Thanks. -stv From hadi@cyberus.ca Wed Mar 9 08:00:34 2005 Received: with ECARTIS (v1.0.0; list netdev); Wed, 09 Mar 2005 08:00:39 -0800 (PST) Received: from mx03.cybersurf.com (mx03.cybersurf.com [209.197.145.106]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j29G0XWL032229 for ; Wed, 9 Mar 2005 08:00:34 -0800 Received: from mail.cyberus.ca ([209.197.145.21]) by mx03.cybersurf.com with esmtp (Exim 4.30) id 1D93bq-0003Gx-QQ for netdev@oss.sgi.com; Wed, 09 Mar 2005 11:00:30 -0500 Received: from [216.209.86.2] (helo=[10.0.0.9]) by mail.cyberus.ca with esmtp (Exim 4.20) id 1D93bQ-0004KJ-Vz; Wed, 09 Mar 2005 11:00:05 -0500 Subject: RE: Do you know the TCP stack? (127.x.x.x routing) From: jamal Reply-To: hadi@cyberus.ca To: Steve Iribarne Cc: Henrik Nordstrom , Martin Mares , Zdenek Radouch , Eran Mann , Thomas Graf , Andi Kleen , netdev@oss.sgi.com, linux-net@vger.kernel.org In-Reply-To: References: Content-Type: text/plain Organization: jamalopolous Message-Id: <1110384000.1077.33.camel@jzny.localdomain> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.2.2 Date: 09 Mar 2005 11:00:01 -0500 Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV 0.83/757/Tue Mar 8 15:14:36 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 2705 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: hadi@cyberus.ca Precedence: bulk X-list: netdev Content-Length: 5119 Lines: 141 On Wed, 2005-03-09 at 10:01, Steve Iribarne wrote: > First off, apologies for the all the cc's on this. I hate doing it, but > I will only do it for this post! > I am not on linux-net - if you insist that i join just so i can see your post then you are being unreasonable. I am not on Linux kernel either. Theres other reasons why multi CCs are useful. Sometimes the list never echoes back the response - case in point my post this morning that was responded to by Zdenek was not echoed upto this point on netdev - it may show up sometime tonight. > -> 1) Addresses for intra-chasis communication. > -> The addresses used by the blades are intrachasis relevant only and > the > -> packets never leave the box. The blades are interconnected via some > -> L2/VLAN/bridge within the chasis. > -> > > Big assumption here. The VLAN/Bridge/Router that I have in my chassis > is hooked up to a switch. The switch will NOT send the packets on my > mgmt VLAN out over the network. > > (see below for more details on this.. in the "what am I missing" section > ) > Your blades --> VLANX/SubnetX --> [some L3 switch] -->VLANY/SubnetY -->outside The Blades discovery etc happens within the collision domain of VLANX. To go across from VLANX<->VLANY you may need either to L3 forward, NAT, tunnel etc. If you do pure L3 forwarding then your blades addresses are accessible outside. In other words all this is a config choice. You may have more than one VLAN for management etc within your blades but thats beside the point. > > -> Conclusion: > -> If these packets never leave the box - no ARP will ever see them and > no > -> dynamic routing protocol will ever advertise them - therefore no IP > -> address collision. You can use _whatever_ address you want, private > -> public, IBMs, intels etc. Do we agree on this? In other words hack > not > -> needed here. > > Wrong. Packets need to leave each blade. You cannot treat the blades > as a private entity. You must ARP to find out the other blades MAC > address. > Read what i wrote again and cross reference with the diagram. ARP is only L2 switched. It would be wise to configure the blade IP addresses to be within the same subnet - in which case the only route you need on your blades is a link scope one and perhaps a default GW pointing to your L3 device. > -> thats going to collide use 10.0.0.0/28" > -> Summary: You may need to go to your box and reconfigure its external > -> looking > -> addresses. > -> > > I _use_ to do exactly what you stated above. When RFC 1918 first came > out I used the 10 net. [..] > Solution to bug1: Easy, let the user configure the mgmt network ip > address. > Customers answer to bug1 solution: Get the hell out of here; you don't > do out-of-band mgmt. Do you know what a security risk this is for me? > Blah blah blah.... Even though all inter-chassis communication was done > securely, I couldn't convince them. I had a customer boot me out of his > office and boot our company out **because** of my design. Not a good > feeling. A customer should be able to say, "heres an address you can use for management". The rest of it is your problem really. There are no bugs, but there are config issues. > > -> a') Using 127.x addresses. You -> NOC "can i use 127.0.0.x/22 subnet" > -> they say either "sorry, our routers cant route 127.x" or "no Zdenek > -> was here before you, thats going to collide use 127.0.0.0/28" > -> > > This is __EXACTLY__ the behavior we want. I want routers to drop those > packets. My inter-chassis communication better NOT go through a router. > The interchassis does not go through a router at all (other than the one in your chasis which may be used to do L3). Let me draw that diagram again: Your blades --> VLANX/SubnetX --> [some L3 switch] -->VLANY/SubnetY -->outside i.e the only way it would fo out is if you allowed it at the L3 switch or NAT device etc. So let me quote you above: --- I _use_ to do exactly what you stated above. When RFC 1918 first came out I used the 10 net. --- Its just a matter of time before you say "oh, thats what i do now for 127.x". This is the point i have been trying to make all along. > -> So tell me what i am missing! > -> > > Experience. I think you are making some very big assumption ;-> Please dont go this path unless you wish to end this thread. Btw, i do believe what you and Zdenek are trying to solve are _very_ different problems. He is trying to build a distributed router of some form; i.e his blades are infact line-cards where traffic comes in. You on the other hand seem to have the blades doing computes (i.e they are not router line cards). The point is this: Whatever you folks are doing, probably inherited from some other projects more than likely using some other OS is not necessary in Linux. I respect your desire to use those addresses if it makes you comfortable - I just vehemently disagree it is needed. So i hope you dont show up with the patch and ask for its inclusion. cheers, jamal From bennybbz@yahoo.fr Wed Mar 9 08:37:29 2005 Received: with ECARTIS (v1.0.0; list netdev); Wed, 09 Mar 2005 08:37:32 -0800 (PST) Received: from web26608.mail.ukl.yahoo.com (web26608.mail.ukl.yahoo.com [217.146.176.58]) by oss.sgi.com (8.13.0/8.13.0) with SMTP id j29GbRRC005289 for ; Wed, 9 Mar 2005 08:37:28 -0800 Received: (qmail 40254 invoked by uid 60001); 9 Mar 2005 16:37:22 -0000 Message-ID: <20050309163722.40252.qmail@web26608.mail.ukl.yahoo.com> Received: from [63.87.1.243] by web26608.mail.ukl.yahoo.com via HTTP; Wed, 09 Mar 2005 17:37:22 CET Date: Wed, 9 Mar 2005 17:37:22 +0100 (CET) From: BZ Benny Subject: Adresse Resolution ??? To: netdev MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Virus-Scanned: ClamAV 0.83/757/Tue Mar 8 15:14:36 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 2706 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: bennybbz@yahoo.fr Precedence: bulk X-list: netdev Content-Length: 698 Lines: 27 Hi all, actually , I understand that when ethernet layer receives data from IP it checks form MAC address in ARP table located inthe IP layer. is the ARP table in the IP layer? if it is, the ethernet layer( the ethernet Driver of the device) send a request to the IP layer for corespondance between IP adresse and MAC address. when it receives the MAC adresse of the destination It puts it in the the ethernet header. and send the packet. what I wanted to know is how ethernet layer in linux ask IP layer for the target MAC address? regards benny Découvrez le nouveau Yahoo! Mail : 250 Mo d'espace de stockage pour vos mails ! Créez votre Yahoo! Mail sur http://fr.mail.yahoo.com/ From steve@services.navaho.net Wed Mar 9 09:01:50 2005 Received: with ECARTIS (v1.0.0; list netdev); Wed, 09 Mar 2005 09:01:56 -0800 (PST) Received: from services.navaho.net (fairchild-194.adsl.newnet.co.uk [213.131.187.194]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j29H1nf4006803 for ; Wed, 9 Mar 2005 09:01:50 -0800 Received: from [10.101.0.42] (helo=[10.101.0.42] ident=[U2FsdGVkX19C9KVWkZ/Q9a+HCvMdO2yitSJMHS5ZeM0=]) by services.navaho.net with esmtp (Exim 4.43) id 1D94Z8-0008W6-Q2; Wed, 09 Mar 2005 17:01:46 +0000 Date: Wed, 9 Mar 2005 17:01:46 +0000 (GMT) From: Steve Hill X-X-Sender: steve@sorbus2.navaho To: Patrick McHardy cc: netdev@oss.sgi.com, "David S. Miller" Subject: Re: IPSEC In-Reply-To: <422DE487.5020800@trash.net> Message-ID: References: <422DE487.5020800@trash.net> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Virus-Scanned: ClamAV 0.83/757/Tue Mar 8 15:14:36 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 2707 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: steve@services.navaho.net Precedence: bulk X-list: netdev Content-Length: 430 Lines: 12 On Tue, 8 Mar 2005, Patrick McHardy wrote: > This is a bug in the kernel, __xfrm_find_acq_byseq should only return > XFRM_STATE_ACQ states. This patch should fix it. Thanks - just tested the patch against the current 2.6.10 Fedora 3 kernel and it works well. - Steve Hill (BSc) Senior Software Developer Email: steve@navaho.co.uk Navaho Technologies Ltd. Tel: +44-870-7034015 From afleming@freescale.com Wed Mar 9 09:17:57 2005 Received: with ECARTIS (v1.0.0; list netdev); Wed, 09 Mar 2005 09:18:01 -0800 (PST) Received: from az33egw01.freescale.net (az33egw01.freescale.net [192.88.158.102]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j29HHvek019784 for ; Wed, 9 Mar 2005 09:17:57 -0800 Received: from az33smr02.freescale.net (az33smr02.freescale.net [10.64.34.200]) by az33egw01.freescale.net (8.12.11/az33egw01) with ESMTP id j29HJrpv021929; Wed, 9 Mar 2005 10:19:53 -0700 (MST) Received: from [10.82.17.56] ([10.82.17.56]) by az33smr02.freescale.net (8.13.1/8.13.0) with ESMTP id j29HJ5w3024709; Wed, 9 Mar 2005 11:19:05 -0600 (CST) In-Reply-To: <1110334456.32556.21.camel@gaston> References: <1107b64b01fb8e9a6c84359bb56881a6@freescale.com> <1110334456.32556.21.camel@gaston> Mime-Version: 1.0 (Apple Message framework v619.2) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: Content-Transfer-Encoding: 7bit Cc: Netdev , Embedded PPC Linux list From: Andy Fleming Subject: Re: RFC: PHY Abstraction Layer II Date: Wed, 9 Mar 2005 11:17:54 -0600 To: Benjamin Herrenschmidt X-Mailer: Apple Mail (2.619.2) X-Virus-Scanned: ClamAV 0.83/757/Tue Mar 8 15:14:36 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 2708 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: afleming@freescale.com Precedence: bulk X-list: netdev Content-Length: 1354 Lines: 38 On Mar 8, 2005, at 20:14, Benjamin Herrenschmidt wrote: > On Tue, 2005-03-08 at 19:47 -0600, Andy Fleming wrote: >> I've finally gotten all of ebs's suggestions into the PHY code. Here >> is the new version. It has the following improvements: >> >> * All PHYs now determine speed,duplex, etc using the same generic >> code, >> rather than PHY-specific registers. > > Some PHY are doing a better job with PHY specific registers I think ... > The gigabit for example isn't standard, and some PHYs sort-of manage to > deal with non-autoneg hubs in such a way that the "normal" aneg doesn't > succeeds, but the phy specific stuff does work. At least from stuff > I've > been told a while ago, I have no direct experience here. Ah, I should have been a little more clear. All the currently implemented PHY drivers are just using the generic read_status function. Different PHYs can assign their read_status function to be PHY-specific > >> * The genphy driver works for gigabit PHYs now, as well. In theory, >> if >> your PHY isn't broken in some way (I've encountered a number that >> are), >> you should be able to just use genphy. > > Isn't the speed reporting of gigabit an implementation specific bit in > lots of PHYs ? Well, it looks like there are some standard bits which say whether the PHY supports gigabit. I used those. Andy From jgarzik@pobox.com Wed Mar 9 09:22:29 2005 Received: with ECARTIS (v1.0.0; list netdev); Wed, 09 Mar 2005 09:22:46 -0800 (PST) Received: from parcelfarce.linux.theplanet.co.uk (IDENT:93@parcelfarce.linux.theplanet.co.uk [195.92.249.252]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j29HMRt4020376 for ; Wed, 9 Mar 2005 09:22:27 -0800 Received: from [69.134.152.124] (helo=[10.10.10.88]) by parcelfarce.linux.theplanet.co.uk with asmtp (TLSv1:AES256-SHA:256) (Exim 4.33) id 1D94t5-0004gm-8g; Wed, 09 Mar 2005 17:22:26 +0000 Message-ID: <422F30BA.5010809@pobox.com> Date: Wed, 09 Mar 2005 12:22:02 -0500 From: Jeff Garzik User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.3) Gecko/20040922 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Andrew Morton , Linus Torvalds CC: Netdev , Linux Kernel Subject: [BK PATCHES] 2.6.x net driver updates Content-Type: multipart/mixed; boundary="------------000406070700040303060608" X-Virus-Scanned: ClamAV 0.83/757/Tue Mar 8 15:14:36 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 2709 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: jgarzik@pobox.com Precedence: bulk X-list: netdev Content-Length: 110373 Lines: 3311 This is a multi-part message in MIME format. --------------000406070700040303060608 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Janitorial and viro-authored stuff. --------------000406070700040303060608 Content-Type: text/plain; name="changelog.txt" Content-Transfer-Encoding: 8bit Content-Disposition: inline; filename="changelog.txt" Please do a bk pull bk://gkernel.bkbits.net/net-drivers-2.6 This will update the following files: include/linux/dp83840.h | 41 -------- drivers/net/3c503.c | 67 +++++++------ drivers/net/3c509.c | 4 drivers/net/3c515.c | 32 ++---- drivers/net/3c527.c | 2 drivers/net/amd8111e.c | 4 drivers/net/arcnet/arc-rawmode.c | 4 drivers/net/arcnet/arc-rimi.c | 14 +- drivers/net/arcnet/arcnet.c | 30 ++--- drivers/net/arcnet/com20020.c | 6 - drivers/net/arcnet/com90io.c | 4 drivers/net/arcnet/com90xx.c | 8 - drivers/net/arcnet/rfc1051.c | 8 - drivers/net/arcnet/rfc1201.c | 12 +- drivers/net/bonding/bond_3ad.c | 2 drivers/net/bonding/bond_3ad.h | 1 drivers/net/bonding/bond_alb.c | 4 drivers/net/cs89x0.c | 4 drivers/net/depca.c | 4 drivers/net/dgrs.c | 6 - drivers/net/eepro100.c | 10 - drivers/net/es3210.c | 32 +++--- drivers/net/ethertap.c | 4 drivers/net/ewrk3.c | 87 +++++++++-------- drivers/net/ioc3-eth.c | 1 drivers/net/irda/act200l-sir.c | 3 drivers/net/irda/irtty-sir.c | 4 drivers/net/irda/ma600-sir.c | 12 -- drivers/net/irda/sir_dev.c | 4 drivers/net/irda/tekram-sir.c | 3 drivers/net/loopback.c | 2 drivers/net/lp486e.c | 8 - drivers/net/ni65.c | 3 drivers/net/ns83820.c | 3 drivers/net/pcmcia/ibmtr_cs.c | 7 - drivers/net/pcmcia/xirc2ps_cs.c | 23 +--- drivers/net/ppp_deflate.c | 4 drivers/net/ppp_generic.c | 2 drivers/net/pppoe.c | 2 drivers/net/s2io.c | 75 ++++++-------- drivers/net/s2io.h | 8 - drivers/net/sb1000.c | 28 ++--- drivers/net/shaper.c | 2 drivers/net/slhc.c | 27 ----- drivers/net/smc-mca.c | 37 ++++--- drivers/net/smc-ultra.c | 34 +++--- drivers/net/smc-ultra32.c | 30 +++-- drivers/net/tokenring/ibmtr.c | 158 ++++++++++++++----------------- drivers/net/tulip/interrupt.c | 2 drivers/net/tun.c | 4 drivers/net/via-rhine.c | 2 drivers/net/via-velocity.c | 2 drivers/net/wan/cosa.c | 7 - drivers/net/wd.c | 36 ++++--- drivers/net/wireless/airo.c | 25 +--- drivers/net/wireless/prism54/isl_ioctl.c | 2 drivers/net/wireless/ray_cs.c | 5 drivers/net/wireless/strip.c | 16 +-- include/linux/ibmtr.h | 15 +- include/net/slhc_vj.h | 3 60 files changed, 454 insertions(+), 535 deletions(-) through these ChangeSets: Adrian Bunk: o drivers/net/via-rhine.c: make a variable static const o drivers/net/sb1000.c: make some variables static o drivers/net/lp486e.c: make some code static o drivers/net/3c509.c: make 2 structs static o drivers/net/3c527.c: make a struct static o drivers/net/amd8111e.c: make 2 functions static o drivers/net/loopback.c: make a function static o drivers/net/ethertap.c: make 2 functions static o drivers/net/dgrs.c: make 3 functions static o drivers/net/depca.c: make 2 structs static o drivers/net/bonding/: make 3 functions static o drivers/net/s2io.c: cleanups o drivers/net/pppoe.c: make a struct static o drivers/net/ppp_deflate.c: make 2 structs static o drivers/net/via-velocity.c: make a function static o drivers/net/tun.c: make 2 functions static o drivers/net/tulip/interrupt.c: make a variable static o drivers/net/shaper.c: make a variable static o drivers/net/slhc.c: remove 2 functions o remove dp83840.h Alexander Viro: o 3c503 (iomem + isa-ectomy) o ibmtr 2/2: ibmtr annotations - the rest o ibmtr 1/2: iomem annotations - trivial part o es3210 iomem annotions and isa-ectomy o ewrk3 iomem annotations + isa-ectomy o wd iomem annotations + isa-ectomy o smc-ultra32 iomem annotations + isa-ectomy o smc-ultra iomem annotations + isa-ectomy o smc-mca iomem annotations and isa-ectomy Domen Puncer: o net/ewrk3: replace schedule_timeout() with msleep_interruptible() o net/tekram-sir: replace schedule_timeout() with msleep() o net/ns83820: replace schedule_timeout() with msleep() o net/ni65: replace schedule_timeout() with msleep() o net/sir_dev: replace schedule_timeout() with msleep() o net/xirc2ps_cs: replace Wait() with msleep() o net/ma600-sir: replace schedule_timeout() with msleep() o net/irtty-sir: replace schedule_timeout() with msleep() o net/act2001-sir: replace schedule_timeout() with msleep() o arcnet: remove casts François Romieu: o strip: use of netdev_priv Nishanth Aravamudan: o net/cosa: replace schedule_timeout() with msleep() o net/airo: replace schedule_timeout() with msleep()/ssleep() o net/cs89x0: replace schedule_timeout() with msleep() Paul Mackerras: o remove bogus exports in ppp Pavel Machek: o eepro100 kill obsolete ifdefs Randy Dunlap: o sb1000: reduce ioctl stack usage o ray_cs: reduce stack usage (sockaddr) o prism54: use NULL for pointer Steffen Klassert: o Add MODULE_VERSION to the 3c515 driver o Use netdev_priv in the 3c515 driver --------------000406070700040303060608 Content-Type: text/plain; name="patch" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="patch" diff -Nru a/drivers/net/3c503.c b/drivers/net/3c503.c --- a/drivers/net/3c503.c 2005-03-09 12:20:51 -05:00 +++ b/drivers/net/3c503.c 2005-03-09 12:20:51 -05:00 @@ -103,8 +103,15 @@ return -ENXIO; for (addr = addrs; *addr; addr++) { - unsigned base_bits = isa_readb(*addr); - int i = ffs(base_bits) - 1; + void __iomem *p = ioremap(*addr, 1); + unsigned base_bits; + int i; + + if (!p) + continue; + base_bits = readb(p); + iounmap(p); + i = ffs(base_bits) - 1; if (i == -1 || base_bits != (1 << i)) continue; if (el2_probe1(dev, netcard_portlist[i]) == 0) @@ -145,6 +152,8 @@ { /* NB: el2_close() handles free_irq */ release_region(dev->base_addr, EL2_IO_EXTENT); + if (ei_status.mem) + iounmap(ei_status.mem); } #ifndef MODULE @@ -262,42 +271,46 @@ if ((membase_reg & 0xf0) == 0) { dev->mem_start = 0; ei_status.name = "3c503-PIO"; + ei_status.mem = NULL; } else { dev->mem_start = ((membase_reg & 0xc0) ? 0xD8000 : 0xC8000) + ((membase_reg & 0xA0) ? 0x4000 : 0); - #define EL2_MEMSIZE (EL2_MB1_STOP_PG - EL2_MB1_START_PG)*256 + ei_status.mem = ioremap(dev->mem_start, EL2_MEMSIZE); + #ifdef EL2MEMTEST /* This has never found an error, but someone might care. Note that it only tests the 2nd 8kB on 16kB 3c503/16 cards between card addr. 0x2000 and 0x3fff. */ { /* Check the card's memory. */ - unsigned long mem_base = dev->mem_start; + void __iomem *mem_base = ei_status.mem; unsigned int test_val = 0xbbadf00d; - isa_writel(0xba5eba5e, mem_base); + writel(0xba5eba5e, mem_base); for (i = sizeof(test_val); i < EL2_MEMSIZE; i+=sizeof(test_val)) { - isa_writel(test_val, mem_base + i); - if (isa_readl(mem_base) != 0xba5eba5e - || isa_readl(mem_base + i) != test_val) { + writel(test_val, mem_base + i); + if (readl(mem_base) != 0xba5eba5e + || readl(mem_base + i) != test_val) { printk("3c503: memory failure or memory address conflict.\n"); dev->mem_start = 0; ei_status.name = "3c503-PIO"; + iounmap(mem_base); + ei_status.mem = NULL; break; } test_val += 0x55555555; - isa_writel(0, mem_base + i); + writel(0, mem_base + i); } } #endif /* EL2MEMTEST */ if (dev->mem_start) - dev->mem_end = ei_status.rmem_end = dev->mem_start + EL2_MEMSIZE; + dev->mem_end = dev->mem_start + EL2_MEMSIZE; if (wordlength) { /* No Tx pages to skip over to get to Rx */ - ei_status.rmem_start = dev->mem_start; + ei_status.priv = 0; ei_status.name = "3c503/16"; } else { - ei_status.rmem_start = TX_PAGES*256 + dev->mem_start; + ei_status.priv = TX_PAGES * 256; ei_status.name = "3c503"; } } @@ -471,16 +484,16 @@ unsigned short int *wrd; int boguscount; /* timeout counter */ unsigned short word; /* temporary for better machine code */ + void __iomem *base = ei_status.mem; if (ei_status.word16) /* Tx packets go into bank 0 on EL2/16 card */ outb(EGACFR_RSEL|EGACFR_TCM, E33G_GACFR); else outb(EGACFR_NORM, E33G_GACFR); - if (dev->mem_start) { /* Shared memory transfer */ - unsigned long dest_addr = dev->mem_start + - ((start_page - ei_status.tx_start_page) << 8); - isa_memcpy_toio(dest_addr, buf, count); + if (base) { /* Shared memory transfer */ + memcpy_toio(base + ((start_page - ei_status.tx_start_page) << 8), + buf, count); outb(EGACFR_NORM, E33G_GACFR); /* Back to bank1 in case on bank0 */ return; } @@ -541,11 +554,12 @@ el2_get_8390_hdr(struct net_device *dev, struct e8390_pkt_hdr *hdr, int ring_page) { int boguscount; - unsigned long hdr_start = dev->mem_start + ((ring_page - EL2_MB1_START_PG)<<8); + void __iomem *base = ei_status.mem; unsigned short word; - if (dev->mem_start) { /* Use the shared memory. */ - isa_memcpy_fromio(hdr, hdr_start, sizeof(struct e8390_pkt_hdr)); + if (base) { /* Use the shared memory. */ + void __iomem *hdr_start = base + ((ring_page - EL2_MB1_START_PG)<<8); + memcpy_fromio(hdr, hdr_start, sizeof(struct e8390_pkt_hdr)); hdr->count = le16_to_cpu(hdr->count); return; } @@ -581,23 +595,22 @@ el2_block_input(struct net_device *dev, int count, struct sk_buff *skb, int ring_offset) { int boguscount = 0; + void __iomem *base = ei_status.mem; unsigned short int *buf; unsigned short word; - int end_of_ring = ei_status.rmem_end; - /* Maybe enable shared memory just be to be safe... nahh.*/ - if (dev->mem_start) { /* Use the shared memory. */ + if (base) { /* Use the shared memory. */ ring_offset -= (EL2_MB1_START_PG<<8); - if (dev->mem_start + ring_offset + count > end_of_ring) { + if (ring_offset + count > EL2_MEMSIZE) { /* We must wrap the input move. */ - int semi_count = end_of_ring - (dev->mem_start + ring_offset); - isa_memcpy_fromio(skb->data, dev->mem_start + ring_offset, semi_count); + int semi_count = EL2_MEMSIZE - ring_offset; + memcpy_fromio(skb->data, base + ring_offset, semi_count); count -= semi_count; - isa_memcpy_fromio(skb->data + semi_count, ei_status.rmem_start, count); + memcpy_fromio(skb->data + semi_count, base + ei_status.priv, count); } else { /* Packet is in one chunk -- we can copy + cksum. */ - isa_eth_io_copy_and_sum(skb, dev->mem_start + ring_offset, count, 0); + eth_io_copy_and_sum(skb, base + ring_offset, count, 0); } return; } diff -Nru a/drivers/net/3c509.c b/drivers/net/3c509.c --- a/drivers/net/3c509.c 2005-03-09 12:20:51 -05:00 +++ b/drivers/net/3c509.c 2005-03-09 12:20:51 -05:00 @@ -214,7 +214,7 @@ #endif #ifdef CONFIG_EISA -struct eisa_device_id el3_eisa_ids[] = { +static struct eisa_device_id el3_eisa_ids[] = { { "TCM5092" }, { "TCM5093" }, { "" } @@ -222,7 +222,7 @@ static int el3_eisa_probe (struct device *device); -struct eisa_driver el3_eisa_driver = { +static struct eisa_driver el3_eisa_driver = { .id_table = el3_eisa_ids, .driver = { .name = "3c509", diff -Nru a/drivers/net/3c515.c b/drivers/net/3c515.c --- a/drivers/net/3c515.c 2005-03-09 12:20:51 -05:00 +++ b/drivers/net/3c515.c 2005-03-09 12:20:51 -05:00 @@ -86,6 +86,7 @@ MODULE_AUTHOR("Donald Becker "); MODULE_DESCRIPTION("3Com 3c515 Corkscrew driver"); MODULE_LICENSE("GPL"); +MODULE_VERSION(DRV_VERSION); /* "Knobs" for adjusting internal parameters. */ /* Put out somewhat more debugging messages. (0 - no msg, 1 minimal msgs). */ @@ -472,7 +473,7 @@ static void cleanup_card(struct net_device *dev) { - struct corkscrew_private *vp = (struct corkscrew_private *) dev->priv; + struct corkscrew_private *vp = netdev_priv(dev); list_del_init(&vp->list); if (dev->dma) free_dma(dev->dma); @@ -570,7 +571,7 @@ static void corkscrew_setup(struct net_device *dev, int ioaddr, struct pnp_dev *idev, int card_number) { - struct corkscrew_private *vp = (struct corkscrew_private *) dev->priv; + struct corkscrew_private *vp = netdev_priv(dev); unsigned int eeprom[0x40], checksum = 0; /* EEPROM contents */ int i; int irq; @@ -696,8 +697,7 @@ static int corkscrew_open(struct net_device *dev) { int ioaddr = dev->base_addr; - struct corkscrew_private *vp = - (struct corkscrew_private *) dev->priv; + struct corkscrew_private *vp = netdev_priv(dev); union wn3_config config; int i; @@ -862,7 +862,7 @@ { #ifdef AUTOMEDIA struct net_device *dev = (struct net_device *) data; - struct corkscrew_private *vp = (struct corkscrew_private *) dev->priv; + struct corkscrew_private *vp = netdev_priv(dev); int ioaddr = dev->base_addr; unsigned long flags; int ok = 0; @@ -954,8 +954,7 @@ static void corkscrew_timeout(struct net_device *dev) { int i; - struct corkscrew_private *vp = - (struct corkscrew_private *) dev->priv; + struct corkscrew_private *vp = netdev_priv(dev); int ioaddr = dev->base_addr; printk(KERN_WARNING @@ -994,8 +993,7 @@ static int corkscrew_start_xmit(struct sk_buff *skb, struct net_device *dev) { - struct corkscrew_private *vp = - (struct corkscrew_private *) dev->priv; + struct corkscrew_private *vp = netdev_priv(dev); int ioaddr = dev->base_addr; /* Block a timer-based transmit from overlapping. */ @@ -1123,14 +1121,13 @@ { /* Use the now-standard shared IRQ implementation. */ struct net_device *dev = dev_id; - struct corkscrew_private *lp; + struct corkscrew_private *lp = netdev_priv(dev); int ioaddr, status; int latency; int i = max_interrupt_work; ioaddr = dev->base_addr; latency = inb(ioaddr + Timer); - lp = (struct corkscrew_private *) dev->priv; spin_lock(&lp->lock); @@ -1262,7 +1259,7 @@ static int corkscrew_rx(struct net_device *dev) { - struct corkscrew_private *vp = (struct corkscrew_private *) dev->priv; + struct corkscrew_private *vp = netdev_priv(dev); int ioaddr = dev->base_addr; int i; short rx_status; @@ -1329,8 +1326,7 @@ static int boomerang_rx(struct net_device *dev) { - struct corkscrew_private *vp = - (struct corkscrew_private *) dev->priv; + struct corkscrew_private *vp = netdev_priv(dev); int entry = vp->cur_rx % RX_RING_SIZE; int ioaddr = dev->base_addr; int rx_status; @@ -1420,8 +1416,7 @@ static int corkscrew_close(struct net_device *dev) { - struct corkscrew_private *vp = - (struct corkscrew_private *) dev->priv; + struct corkscrew_private *vp = netdev_priv(dev); int ioaddr = dev->base_addr; int i; @@ -1476,7 +1471,7 @@ static struct net_device_stats *corkscrew_get_stats(struct net_device *dev) { - struct corkscrew_private *vp = (struct corkscrew_private *) dev->priv; + struct corkscrew_private *vp = netdev_priv(dev); unsigned long flags; if (netif_running(dev)) { @@ -1496,8 +1491,7 @@ */ static void update_stats(int ioaddr, struct net_device *dev) { - struct corkscrew_private *vp = - (struct corkscrew_private *) dev->priv; + struct corkscrew_private *vp = netdev_priv(dev); /* Unlike the 3c5x9 we need not turn off stats updates while reading. */ /* Switch to the stats window, and read everything. */ diff -Nru a/drivers/net/3c527.c b/drivers/net/3c527.c --- a/drivers/net/3c527.c 2005-03-09 12:20:51 -05:00 +++ b/drivers/net/3c527.c 2005-03-09 12:20:51 -05:00 @@ -197,7 +197,7 @@ char *name; }; -const struct mca_adapters_t mc32_adapters[] = { +static const struct mca_adapters_t mc32_adapters[] = { { 0x0041, "3COM EtherLink MC/32" }, { 0x8EF5, "IBM High Performance Lan Adapter" }, { 0x0000, NULL } diff -Nru a/drivers/net/amd8111e.c b/drivers/net/amd8111e.c --- a/drivers/net/amd8111e.c 2005-03-09 12:20:51 -05:00 +++ b/drivers/net/amd8111e.c 2005-03-09 12:20:51 -05:00 @@ -1489,7 +1489,7 @@ amd8111e crc generator implementation is different from the kernel ether_crc() function. */ -int amd8111e_ether_crc(int len, char* mac_addr) +static int amd8111e_ether_crc(int len, char* mac_addr) { int i,byte; unsigned char octet; @@ -1717,7 +1717,7 @@ /* This function changes the mtu of the device. It restarts the device to initialize the descriptor with new receive buffers. */ -int amd8111e_change_mtu(struct net_device *dev, int new_mtu) +static int amd8111e_change_mtu(struct net_device *dev, int new_mtu) { struct amd8111e_priv *lp = netdev_priv(dev); int err; diff -Nru a/drivers/net/arcnet/arc-rawmode.c b/drivers/net/arcnet/arc-rawmode.c --- a/drivers/net/arcnet/arc-rawmode.c 2005-03-09 12:20:51 -05:00 +++ b/drivers/net/arcnet/arc-rawmode.c 2005-03-09 12:20:51 -05:00 @@ -87,7 +87,7 @@ static void rx(struct net_device *dev, int bufnum, struct archdr *pkthdr, int length) { - struct arcnet_local *lp = (struct arcnet_local *) dev->priv; + struct arcnet_local *lp = dev->priv; struct sk_buff *skb; struct archdr *pkt = pkthdr; int ofs; @@ -168,7 +168,7 @@ static int prepare_tx(struct net_device *dev, struct archdr *pkt, int length, int bufnum) { - struct arcnet_local *lp = (struct arcnet_local *) dev->priv; + struct arcnet_local *lp = dev->priv; struct arc_hardware *hard = &pkt->hard; int ofs; diff -Nru a/drivers/net/arcnet/arc-rimi.c b/drivers/net/arcnet/arc-rimi.c --- a/drivers/net/arcnet/arc-rimi.c 2005-03-09 12:20:51 -05:00 +++ b/drivers/net/arcnet/arc-rimi.c 2005-03-09 12:20:51 -05:00 @@ -230,7 +230,7 @@ */ static int arcrimi_reset(struct net_device *dev, int really_reset) { - struct arcnet_local *lp = (struct arcnet_local *) dev->priv; + struct arcnet_local *lp = dev->priv; void __iomem *ioaddr = lp->mem_start + 0x800; BUGMSG(D_INIT, "Resetting %s (status=%02Xh)\n", dev->name, ASTATUS()); @@ -251,7 +251,7 @@ static void arcrimi_setmask(struct net_device *dev, int mask) { - struct arcnet_local *lp = (struct arcnet_local *) dev->priv; + struct arcnet_local *lp = dev->priv; void __iomem *ioaddr = lp->mem_start + 0x800; AINTMASK(mask); @@ -259,7 +259,7 @@ static int arcrimi_status(struct net_device *dev) { - struct arcnet_local *lp = (struct arcnet_local *) dev->priv; + struct arcnet_local *lp = dev->priv; void __iomem *ioaddr = lp->mem_start + 0x800; return ASTATUS(); @@ -267,7 +267,7 @@ static void arcrimi_command(struct net_device *dev, int cmd) { - struct arcnet_local *lp = (struct arcnet_local *) dev->priv; + struct arcnet_local *lp = dev->priv; void __iomem *ioaddr = lp->mem_start + 0x800; ACOMMAND(cmd); @@ -276,7 +276,7 @@ static void arcrimi_copy_to_card(struct net_device *dev, int bufnum, int offset, void *buf, int count) { - struct arcnet_local *lp = (struct arcnet_local *) dev->priv; + struct arcnet_local *lp = dev->priv; void __iomem *memaddr = lp->mem_start + 0x800 + bufnum * 512 + offset; TIME("memcpy_toio", count, memcpy_toio(memaddr, buf, count)); } @@ -285,7 +285,7 @@ static void arcrimi_copy_from_card(struct net_device *dev, int bufnum, int offset, void *buf, int count) { - struct arcnet_local *lp = (struct arcnet_local *) dev->priv; + struct arcnet_local *lp = dev->priv; void __iomem *memaddr = lp->mem_start + 0x800 + bufnum * 512 + offset; TIME("memcpy_fromio", count, memcpy_fromio(buf, memaddr, count)); } @@ -331,7 +331,7 @@ static void __exit arc_rimi_exit(void) { struct net_device *dev = my_dev; - struct arcnet_local *lp = (struct arcnet_local *) dev->priv; + struct arcnet_local *lp = dev->priv; unregister_netdev(dev); iounmap(lp->mem_start); diff -Nru a/drivers/net/arcnet/arcnet.c b/drivers/net/arcnet/arcnet.c --- a/drivers/net/arcnet/arcnet.c 2005-03-09 12:20:51 -05:00 +++ b/drivers/net/arcnet/arcnet.c 2005-03-09 12:20:51 -05:00 @@ -181,7 +181,7 @@ void arcnet_dump_packet(struct net_device *dev, int bufnum, char *desc, int take_arcnet_lock) { - struct arcnet_local *lp = (struct arcnet_local *) dev->priv; + struct arcnet_local *lp = dev->priv; int i, length; unsigned long flags = 0; static uint8_t buf[512]; @@ -244,7 +244,7 @@ */ static void release_arcbuf(struct net_device *dev, int bufnum) { - struct arcnet_local *lp = (struct arcnet_local *) dev->priv; + struct arcnet_local *lp = dev->priv; int i; lp->buf_queue[lp->first_free_buf++] = bufnum; @@ -266,7 +266,7 @@ */ static int get_arcbuf(struct net_device *dev) { - struct arcnet_local *lp = (struct arcnet_local *) dev->priv; + struct arcnet_local *lp = dev->priv; int buf = -1, i; if (!atomic_dec_and_test(&lp->buf_lock)) { @@ -367,7 +367,7 @@ */ static int arcnet_open(struct net_device *dev) { - struct arcnet_local *lp = (struct arcnet_local *) dev->priv; + struct arcnet_local *lp = dev->priv; int count, newmtu, error; BUGMSG(D_INIT,"opened."); @@ -467,7 +467,7 @@ /* The inverse routine to arcnet_open - shuts down the card. */ static int arcnet_close(struct net_device *dev) { - struct arcnet_local *lp = (struct arcnet_local *) dev->priv; + struct arcnet_local *lp = dev->priv; netif_stop_queue(dev); @@ -488,7 +488,7 @@ unsigned short type, void *daddr, void *saddr, unsigned len) { - struct arcnet_local *lp = (struct arcnet_local *) dev->priv; + struct arcnet_local *lp = dev->priv; uint8_t _daddr, proto_num; struct ArcProto *proto; @@ -546,7 +546,7 @@ static int arcnet_rebuild_header(struct sk_buff *skb) { struct net_device *dev = skb->dev; - struct arcnet_local *lp = (struct arcnet_local *) dev->priv; + struct arcnet_local *lp = dev->priv; int status = 0; /* default is failure */ unsigned short type; uint8_t daddr=0; @@ -591,7 +591,7 @@ /* Called by the kernel in order to transmit a packet. */ static int arcnet_send_packet(struct sk_buff *skb, struct net_device *dev) { - struct arcnet_local *lp = (struct arcnet_local *) dev->priv; + struct arcnet_local *lp = dev->priv; struct archdr *pkt; struct arc_rfc1201 *soft; struct ArcProto *proto; @@ -674,7 +674,7 @@ */ static int go_tx(struct net_device *dev) { - struct arcnet_local *lp = (struct arcnet_local *) dev->priv; + struct arcnet_local *lp = dev->priv; BUGMSG(D_DURING, "go_tx: status=%Xh, intmask=%Xh, next_tx=%d, cur_tx=%d\n", ASTATUS(), lp->intmask, lp->next_tx, lp->cur_tx); @@ -705,7 +705,7 @@ static void arcnet_timeout(struct net_device *dev) { unsigned long flags; - struct arcnet_local *lp = (struct arcnet_local *) dev->priv; + struct arcnet_local *lp = dev->priv; int status = ASTATUS(); char *msg; @@ -754,7 +754,7 @@ BUGMSG(D_DURING, "in arcnet_interrupt\n"); - lp = (struct arcnet_local *) dev->priv; + lp = dev->priv; if (!lp) BUG(); @@ -989,7 +989,7 @@ */ void arcnet_rx(struct net_device *dev, int bufnum) { - struct arcnet_local *lp = (struct arcnet_local *) dev->priv; + struct arcnet_local *lp = dev->priv; struct archdr pkt; struct arc_rfc1201 *soft; int length, ofs; @@ -1053,7 +1053,7 @@ */ static struct net_device_stats *arcnet_get_stats(struct net_device *dev) { - struct arcnet_local *lp = (struct arcnet_local *) dev->priv; + struct arcnet_local *lp = dev->priv; return &lp->stats; } @@ -1070,7 +1070,7 @@ static int null_build_header(struct sk_buff *skb, struct net_device *dev, unsigned short type, uint8_t daddr) { - struct arcnet_local *lp = (struct arcnet_local *) dev->priv; + struct arcnet_local *lp = dev->priv; BUGMSG(D_PROTO, "tx: can't build header for encap %02Xh; load a protocol driver.\n", @@ -1085,7 +1085,7 @@ static int null_prepare_tx(struct net_device *dev, struct archdr *pkt, int length, int bufnum) { - struct arcnet_local *lp = (struct arcnet_local *) dev->priv; + struct arcnet_local *lp = dev->priv; struct arc_hardware newpkt; BUGMSG(D_PROTO, "tx: no encap for this host; load a protocol driver.\n"); diff -Nru a/drivers/net/arcnet/com20020.c b/drivers/net/arcnet/com20020.c --- a/drivers/net/arcnet/com20020.c 2005-03-09 12:20:51 -05:00 +++ b/drivers/net/arcnet/com20020.c 2005-03-09 12:20:51 -05:00 @@ -159,7 +159,7 @@ /* Initialize the rest of the device structure. */ - lp = (struct arcnet_local *) dev->priv; + lp = dev->priv; lp->hw.owner = THIS_MODULE; lp->hw.command = com20020_command; @@ -233,7 +233,7 @@ */ static int com20020_reset(struct net_device *dev, int really_reset) { - struct arcnet_local *lp = (struct arcnet_local *) dev->priv; + struct arcnet_local *lp = dev->priv; u_int ioaddr = dev->base_addr; u_char inbyte; @@ -300,7 +300,7 @@ static void com20020_close(struct net_device *dev) { - struct arcnet_local *lp = (struct arcnet_local *) dev->priv; + struct arcnet_local *lp = dev->priv; int ioaddr = dev->base_addr; /* disable transmitter */ diff -Nru a/drivers/net/arcnet/com90io.c b/drivers/net/arcnet/com90io.c --- a/drivers/net/arcnet/com90io.c 2005-03-09 12:20:51 -05:00 +++ b/drivers/net/arcnet/com90io.c 2005-03-09 12:20:51 -05:00 @@ -248,7 +248,7 @@ return -EBUSY; } - lp = (struct arcnet_local *) (dev->priv); + lp = dev->priv; lp->card_name = "COM90xx I/O"; lp->hw.command = com90io_command; lp->hw.status = com90io_status; @@ -290,7 +290,7 @@ */ static int com90io_reset(struct net_device *dev, int really_reset) { - struct arcnet_local *lp = (struct arcnet_local *) dev->priv; + struct arcnet_local *lp = dev->priv; short ioaddr = dev->base_addr; BUGMSG(D_INIT, "Resetting %s (status=%02Xh)\n", dev->name, ASTATUS()); diff -Nru a/drivers/net/arcnet/com90xx.c b/drivers/net/arcnet/com90xx.c --- a/drivers/net/arcnet/com90xx.c 2005-03-09 12:20:51 -05:00 +++ b/drivers/net/arcnet/com90xx.c 2005-03-09 12:20:51 -05:00 @@ -529,7 +529,7 @@ */ int com90xx_reset(struct net_device *dev, int really_reset) { - struct arcnet_local *lp = (struct arcnet_local *) dev->priv; + struct arcnet_local *lp = dev->priv; short ioaddr = dev->base_addr; BUGMSG(D_INIT, "Resetting (status=%02Xh)\n", ASTATUS()); @@ -565,7 +565,7 @@ static void com90xx_copy_to_card(struct net_device *dev, int bufnum, int offset, void *buf, int count) { - struct arcnet_local *lp = (struct arcnet_local *) dev->priv; + struct arcnet_local *lp = dev->priv; void __iomem *memaddr = lp->mem_start + bufnum * 512 + offset; TIME("memcpy_toio", count, memcpy_toio(memaddr, buf, count)); } @@ -574,7 +574,7 @@ static void com90xx_copy_from_card(struct net_device *dev, int bufnum, int offset, void *buf, int count) { - struct arcnet_local *lp = (struct arcnet_local *) dev->priv; + struct arcnet_local *lp = dev->priv; void __iomem *memaddr = lp->mem_start + bufnum * 512 + offset; TIME("memcpy_fromio", count, memcpy_fromio(buf, memaddr, count)); } @@ -600,7 +600,7 @@ for (count = 0; count < numcards; count++) { dev = cards[count]; - lp = (struct arcnet_local *) dev->priv; + lp = dev->priv; unregister_netdev(dev); free_irq(dev->irq, dev); diff -Nru a/drivers/net/arcnet/rfc1051.c b/drivers/net/arcnet/rfc1051.c --- a/drivers/net/arcnet/rfc1051.c 2005-03-09 12:20:51 -05:00 +++ b/drivers/net/arcnet/rfc1051.c 2005-03-09 12:20:51 -05:00 @@ -88,7 +88,7 @@ */ static unsigned short type_trans(struct sk_buff *skb, struct net_device *dev) { - struct arcnet_local *lp = (struct arcnet_local *) dev->priv; + struct arcnet_local *lp = dev->priv; struct archdr *pkt = (struct archdr *) skb->data; struct arc_rfc1051 *soft = &pkt->soft.rfc1051; int hdr_size = ARC_HDR_SIZE + RFC1051_HDR_SIZE; @@ -125,7 +125,7 @@ static void rx(struct net_device *dev, int bufnum, struct archdr *pkthdr, int length) { - struct arcnet_local *lp = (struct arcnet_local *) dev->priv; + struct arcnet_local *lp = dev->priv; struct sk_buff *skb; struct archdr *pkt = pkthdr; int ofs; @@ -169,7 +169,7 @@ static int build_header(struct sk_buff *skb, struct net_device *dev, unsigned short type, uint8_t daddr) { - struct arcnet_local *lp = (struct arcnet_local *) dev->priv; + struct arcnet_local *lp = dev->priv; int hdr_size = ARC_HDR_SIZE + RFC1051_HDR_SIZE; struct archdr *pkt = (struct archdr *) skb_push(skb, hdr_size); struct arc_rfc1051 *soft = &pkt->soft.rfc1051; @@ -220,7 +220,7 @@ static int prepare_tx(struct net_device *dev, struct archdr *pkt, int length, int bufnum) { - struct arcnet_local *lp = (struct arcnet_local *) dev->priv; + struct arcnet_local *lp = dev->priv; struct arc_hardware *hard = &pkt->hard; int ofs; diff -Nru a/drivers/net/arcnet/rfc1201.c b/drivers/net/arcnet/rfc1201.c --- a/drivers/net/arcnet/rfc1201.c 2005-03-09 12:20:51 -05:00 +++ b/drivers/net/arcnet/rfc1201.c 2005-03-09 12:20:51 -05:00 @@ -92,7 +92,7 @@ { struct archdr *pkt = (struct archdr *) skb->data; struct arc_rfc1201 *soft = &pkt->soft.rfc1201; - struct arcnet_local *lp = (struct arcnet_local *) dev->priv; + struct arcnet_local *lp = dev->priv; int hdr_size = ARC_HDR_SIZE + RFC1201_HDR_SIZE; /* Pull off the arcnet header. */ @@ -134,7 +134,7 @@ static void rx(struct net_device *dev, int bufnum, struct archdr *pkthdr, int length) { - struct arcnet_local *lp = (struct arcnet_local *) dev->priv; + struct arcnet_local *lp = dev->priv; struct sk_buff *skb; struct archdr *pkt = pkthdr; struct arc_rfc1201 *soft = &pkthdr->soft.rfc1201; @@ -376,7 +376,7 @@ static int build_header(struct sk_buff *skb, struct net_device *dev, unsigned short type, uint8_t daddr) { - struct arcnet_local *lp = (struct arcnet_local *) dev->priv; + struct arcnet_local *lp = dev->priv; int hdr_size = ARC_HDR_SIZE + RFC1201_HDR_SIZE; struct archdr *pkt = (struct archdr *) skb_push(skb, hdr_size); struct arc_rfc1201 *soft = &pkt->soft.rfc1201; @@ -443,7 +443,7 @@ static void load_pkt(struct net_device *dev, struct arc_hardware *hard, struct arc_rfc1201 *soft, int softlen, int bufnum) { - struct arcnet_local *lp = (struct arcnet_local *) dev->priv; + struct arcnet_local *lp = dev->priv; int ofs; /* assume length <= XMTU: someone should have handled that by now. */ @@ -476,7 +476,7 @@ static int prepare_tx(struct net_device *dev, struct archdr *pkt, int length, int bufnum) { - struct arcnet_local *lp = (struct arcnet_local *) dev->priv; + struct arcnet_local *lp = dev->priv; const int maxsegsize = XMTU - RFC1201_HDR_SIZE; struct Outgoing *out; @@ -511,7 +511,7 @@ static int continue_tx(struct net_device *dev, int bufnum) { - struct arcnet_local *lp = (struct arcnet_local *) dev->priv; + struct arcnet_local *lp = dev->priv; struct Outgoing *out = &lp->outgoing; struct arc_hardware *hard = &out->pkt->hard; struct arc_rfc1201 *soft = &out->pkt->soft.rfc1201, *newsoft; diff -Nru a/drivers/net/bonding/bond_3ad.c b/drivers/net/bonding/bond_3ad.c --- a/drivers/net/bonding/bond_3ad.c 2005-03-09 12:20:51 -05:00 +++ b/drivers/net/bonding/bond_3ad.c 2005-03-09 12:20:51 -05:00 @@ -2175,7 +2175,7 @@ * received frames (loopback). Since only the payload is given to this * function, it check for loopback. */ -void bond_3ad_rx_indication(struct lacpdu *lacpdu, struct slave *slave, u16 length) +static void bond_3ad_rx_indication(struct lacpdu *lacpdu, struct slave *slave, u16 length) { struct port *port; diff -Nru a/drivers/net/bonding/bond_3ad.h b/drivers/net/bonding/bond_3ad.h --- a/drivers/net/bonding/bond_3ad.h 2005-03-09 12:20:51 -05:00 +++ b/drivers/net/bonding/bond_3ad.h 2005-03-09 12:20:51 -05:00 @@ -290,7 +290,6 @@ int bond_3ad_bind_slave(struct slave *slave); void bond_3ad_unbind_slave(struct slave *slave); void bond_3ad_state_machine_handler(struct bonding *bond); -void bond_3ad_rx_indication(struct lacpdu *lacpdu, struct slave *slave, u16 length); void bond_3ad_adapter_speed_changed(struct slave *slave); void bond_3ad_adapter_duplex_changed(struct slave *slave); void bond_3ad_handle_link_change(struct slave *slave, char link); diff -Nru a/drivers/net/bonding/bond_alb.c b/drivers/net/bonding/bond_alb.c --- a/drivers/net/bonding/bond_alb.c 2005-03-09 12:20:51 -05:00 +++ b/drivers/net/bonding/bond_alb.c 2005-03-09 12:20:51 -05:00 @@ -275,7 +275,7 @@ } /* Caller must hold bond lock for read */ -struct slave *tlb_choose_channel(struct bonding *bond, u32 hash_index, u32 skb_len) +static struct slave *tlb_choose_channel(struct bonding *bond, u32 hash_index, u32 skb_len) { struct alb_bond_info *bond_info = &(BOND_ALB_INFO(bond)); struct tlb_client_info *hash_table; @@ -627,7 +627,7 @@ } /* Caller must hold both bond and ptr locks for read */ -struct slave *rlb_choose_channel(struct sk_buff *skb, struct bonding *bond) +static struct slave *rlb_choose_channel(struct sk_buff *skb, struct bonding *bond) { struct alb_bond_info *bond_info = &(BOND_ALB_INFO(bond)); struct arp_pkt *arp = (struct arp_pkt *)skb->nh.raw; diff -Nru a/drivers/net/cs89x0.c b/drivers/net/cs89x0.c --- a/drivers/net/cs89x0.c 2005-03-09 12:20:51 -05:00 +++ b/drivers/net/cs89x0.c 2005-03-09 12:20:51 -05:00 @@ -136,6 +136,7 @@ #include #include #include +#include #include #include @@ -909,8 +910,7 @@ writereg(dev, PP_SelfCTL, readreg(dev, PP_SelfCTL) | POWER_ON_RESET); /* wait 30 ms */ - current->state = TASK_INTERRUPTIBLE; - schedule_timeout(30*HZ/1000); + msleep(30); #ifndef CONFIG_ARCH_IXDP2X01 if (lp->chip_type != CS8900) { diff -Nru a/drivers/net/depca.c b/drivers/net/depca.c --- a/drivers/net/depca.c 2005-03-09 12:20:51 -05:00 +++ b/drivers/net/depca.c 2005-03-09 12:20:51 -05:00 @@ -342,14 +342,14 @@ static int depca_device_remove (struct device *device); #ifdef CONFIG_EISA -struct eisa_device_id depca_eisa_ids[] = { +static struct eisa_device_id depca_eisa_ids[] = { { "DEC4220", de422 }, { "" } }; static int depca_eisa_probe (struct device *device); -struct eisa_driver depca_eisa_driver = { +static struct eisa_driver depca_eisa_driver = { .id_table = depca_eisa_ids, .driver = { .name = depca_string, diff -Nru a/drivers/net/dgrs.c b/drivers/net/dgrs.c --- a/drivers/net/dgrs.c 2005-03-09 12:20:51 -05:00 +++ b/drivers/net/dgrs.c 2005-03-09 12:20:51 -05:00 @@ -454,7 +454,7 @@ * up some state variables to let the host CPU continue doing * other things until a DMA completion interrupt comes along. */ -void +static void dgrs_rcv_frame( struct net_device *dev0, DGRS_PRIV *priv0, @@ -1150,7 +1150,7 @@ /* * Probe (init) a board */ -int __init +static int __init dgrs_probe1(struct net_device *dev) { DGRS_PRIV *priv = (DGRS_PRIV *) dev->priv; @@ -1228,7 +1228,7 @@ return rc; } -int __init +static int __init dgrs_initclone(struct net_device *dev) { DGRS_PRIV *priv = (DGRS_PRIV *) dev->priv; diff -Nru a/drivers/net/eepro100.c b/drivers/net/eepro100.c --- a/drivers/net/eepro100.c 2005-03-09 12:20:51 -05:00 +++ b/drivers/net/eepro100.c 2005-03-09 12:20:51 -05:00 @@ -152,16 +152,6 @@ #define RUN_AT(x) (jiffies + (x)) -/* ACPI power states don't universally work (yet) */ -#ifndef CONFIG_PM -#undef pci_set_power_state -#define pci_set_power_state null_set_power_state -static inline int null_set_power_state(struct pci_dev *dev, int state) -{ - return 0; -} -#endif /* CONFIG_PM */ - #define netdevice_start(dev) #define netdevice_stop(dev) #define netif_set_tx_timeout(dev, tf, tm) \ diff -Nru a/drivers/net/es3210.c b/drivers/net/es3210.c --- a/drivers/net/es3210.c 2005-03-09 12:20:51 -05:00 +++ b/drivers/net/es3210.c 2005-03-09 12:20:51 -05:00 @@ -159,6 +159,7 @@ { free_irq(dev->irq, dev); release_region(dev->base_addr, ES_IO_EXTENT); + iounmap(ei_status.mem); } #ifndef MODULE @@ -271,9 +272,14 @@ printk(" assigning "); } - dev->mem_end = ei_status.rmem_end = dev->mem_start - + (ES_STOP_PG - ES_START_PG)*256; - ei_status.rmem_start = dev->mem_start + TX_PAGES*256; + ei_status.mem = ioremap(dev->mem_start, (ES_STOP_PG - ES_START_PG)*256); + if (!ei_status.mem) { + printk("ioremap failed - giving up\n"); + retval = -ENXIO; + goto out1; + } + + dev->mem_end = dev->mem_start + (ES_STOP_PG - ES_START_PG)*256; printk("mem %#lx-%#lx\n", dev->mem_start, dev->mem_end-1); @@ -353,8 +359,8 @@ static void es_get_8390_hdr(struct net_device *dev, struct e8390_pkt_hdr *hdr, int ring_page) { - unsigned long hdr_start = dev->mem_start + ((ring_page - ES_START_PG)<<8); - isa_memcpy_fromio(hdr, hdr_start, sizeof(struct e8390_pkt_hdr)); + void __iomem *hdr_start = ei_status.mem + ((ring_page - ES_START_PG)<<8); + memcpy_fromio(hdr, hdr_start, sizeof(struct e8390_pkt_hdr)); hdr->count = (hdr->count + 3) & ~3; /* Round up allocation. */ } @@ -367,27 +373,27 @@ static void es_block_input(struct net_device *dev, int count, struct sk_buff *skb, int ring_offset) { - unsigned long xfer_start = dev->mem_start + ring_offset - (ES_START_PG<<8); + void __iomem *xfer_start = ei_status.mem + ring_offset - ES_START_PG*256; - if (xfer_start + count > ei_status.rmem_end) { + if (ring_offset + count > ES_STOP_PG*256) { /* Packet wraps over end of ring buffer. */ - int semi_count = ei_status.rmem_end - xfer_start; - isa_memcpy_fromio(skb->data, xfer_start, semi_count); + int semi_count = ES_STOP_PG*256 - ring_offset; + memcpy_fromio(skb->data, xfer_start, semi_count); count -= semi_count; - isa_memcpy_fromio(skb->data + semi_count, ei_status.rmem_start, count); + memcpy_fromio(skb->data + semi_count, ei_status.mem, count); } else { /* Packet is in one chunk. */ - isa_eth_io_copy_and_sum(skb, xfer_start, count, 0); + eth_io_copy_and_sum(skb, xfer_start, count, 0); } } static void es_block_output(struct net_device *dev, int count, const unsigned char *buf, int start_page) { - unsigned long shmem = dev->mem_start + ((start_page - ES_START_PG)<<8); + void __iomem *shmem = ei_status.mem + ((start_page - ES_START_PG)<<8); count = (count + 3) & ~3; /* Round up to doubleword */ - isa_memcpy_toio(shmem, buf, count); + memcpy_toio(shmem, buf, count); } static int es_open(struct net_device *dev) diff -Nru a/drivers/net/ethertap.c b/drivers/net/ethertap.c --- a/drivers/net/ethertap.c 2005-03-09 12:20:51 -05:00 +++ b/drivers/net/ethertap.c 2005-03-09 12:20:51 -05:00 @@ -343,7 +343,7 @@ } -int __init ethertap_init(void) +static int __init ethertap_init(void) { int i, err = 0; @@ -371,7 +371,7 @@ } module_init(ethertap_init); -void __exit ethertap_cleanup(void) +static void __exit ethertap_cleanup(void) { int i; diff -Nru a/drivers/net/ewrk3.c b/drivers/net/ewrk3.c --- a/drivers/net/ewrk3.c 2005-03-09 12:20:51 -05:00 +++ b/drivers/net/ewrk3.c 2005-03-09 12:20:51 -05:00 @@ -273,6 +273,7 @@ struct ewrk3_private { char adapter_name[80]; /* Name exported to /proc/ioports */ u_long shmem_base; /* Shared memory start address */ + void __iomem *shmem; u_long shmem_length; /* Shared memory window length */ struct net_device_stats stats; /* Public stats */ struct ewrk3_stats pktStats; /* Private stats counters */ @@ -281,7 +282,7 @@ u_char lemac; /* Chip rev. level */ u_char hard_strapped; /* Don't allow a full open */ u_char txc; /* Transmit cut through */ - u_char *mctbl; /* Pointer to the multicast table */ + void __iomem *mctbl; /* Pointer to the multicast table */ u_char led_mask; /* Used to reserve LED access for ethtool */ spinlock_t hw_lock; }; @@ -535,6 +536,9 @@ lp = netdev_priv(dev); lp->shmem_base = mem_start; + lp->shmem = ioremap(mem_start, shmem_length); + if (!lp->shmem) + return -ENOMEM; lp->shmem_length = shmem_length; lp->lemac = lemac; lp->hard_strapped = hard_strapped; @@ -590,6 +594,7 @@ } else { printk(", but incorrect IRQ line detected.\n"); } + iounmap(lp->shmem); return -ENXIO; } @@ -768,7 +773,7 @@ { struct ewrk3_private *lp = netdev_priv(dev); u_long iobase = dev->base_addr; - u_long buf = 0; + void __iomem *buf = NULL; u_char icr; u_char page; @@ -801,13 +806,13 @@ if (lp->shmem_length == IO_ONLY) { outb (page, EWRK3_IOPR); } else if (lp->shmem_length == SHMEM_2K) { - buf = lp->shmem_base; + buf = lp->shmem; outb (page, EWRK3_MPR); } else if (lp->shmem_length == SHMEM_32K) { - buf = ((((short) page << 11) & 0x7800) + lp->shmem_base); + buf = (((short) page << 11) & 0x7800) + lp->shmem; outb ((page >> 4), EWRK3_MPR); } else if (lp->shmem_length == SHMEM_64K) { - buf = ((((short) page << 11) & 0xf800) + lp->shmem_base); + buf = (((short) page << 11) & 0xf800) + lp->shmem; outb ((page >> 5), EWRK3_MPR); } else { printk (KERN_ERR "%s: Oops - your private data area is hosed!\n", @@ -831,30 +836,28 @@ } outb (page, EWRK3_TQ); /* Start sending pkt */ } else { - isa_writeb ((char) (TCR_QMODE | TCR_PAD | TCR_IFC), buf); /* ctrl byte */ + writeb ((char) (TCR_QMODE | TCR_PAD | TCR_IFC), buf); /* ctrl byte */ buf += 1; - isa_writeb ((char) (skb->len & 0xff), buf); /* length (16 bit xfer) */ + writeb ((char) (skb->len & 0xff), buf); /* length (16 bit xfer) */ buf += 1; if (lp->txc) { - isa_writeb ((char) - (((skb->len >> 8) & 0xff) | XCT), buf); + writeb(((skb->len >> 8) & 0xff) | XCT, buf); buf += 1; - isa_writeb (0x04, buf); /* index byte */ + writeb (0x04, buf); /* index byte */ buf += 1; - isa_writeb (0x00, (buf + skb->len)); /* Write the XCT flag */ - isa_memcpy_toio (buf, skb->data, PRELOAD); /* Write PRELOAD bytes */ + writeb (0x00, (buf + skb->len)); /* Write the XCT flag */ + memcpy_toio (buf, skb->data, PRELOAD); /* Write PRELOAD bytes */ outb (page, EWRK3_TQ); /* Start sending pkt */ - isa_memcpy_toio (buf + PRELOAD, + memcpy_toio (buf + PRELOAD, skb->data + PRELOAD, skb->len - PRELOAD); - isa_writeb (0xff, (buf + skb->len)); /* Write the XCT flag */ + writeb (0xff, (buf + skb->len)); /* Write the XCT flag */ } else { - isa_writeb ((char) - ((skb->len >> 8) & 0xff), buf); + writeb ((skb->len >> 8) & 0xff, buf); buf += 1; - isa_writeb (0x04, buf); /* index byte */ + writeb (0x04, buf); /* index byte */ buf += 1; - isa_memcpy_toio (buf, skb->data, skb->len); /* Write data bytes */ + memcpy_toio (buf, skb->data, skb->len); /* Write data bytes */ outb (page, EWRK3_TQ); /* Start sending pkt */ } } @@ -940,7 +943,7 @@ u_long iobase = dev->base_addr; int i, status = 0; u_char page; - u_long buf = 0; + void __iomem *buf = NULL; while (inb(EWRK3_RQC) && !status) { /* Whilst there's incoming data */ if ((page = inb(EWRK3_RQ)) < lp->mPage) { /* Get next entry's buffer page */ @@ -950,13 +953,13 @@ if (lp->shmem_length == IO_ONLY) { outb(page, EWRK3_IOPR); } else if (lp->shmem_length == SHMEM_2K) { - buf = lp->shmem_base; + buf = lp->shmem; outb(page, EWRK3_MPR); } else if (lp->shmem_length == SHMEM_32K) { - buf = ((((short) page << 11) & 0x7800) + lp->shmem_base); + buf = (((short) page << 11) & 0x7800) + lp->shmem; outb((page >> 4), EWRK3_MPR); } else if (lp->shmem_length == SHMEM_64K) { - buf = ((((short) page << 11) & 0xf800) + lp->shmem_base); + buf = (((short) page << 11) & 0xf800) + lp->shmem; outb((page >> 5), EWRK3_MPR); } else { status = -1; @@ -972,9 +975,9 @@ pkt_len = inb(EWRK3_DATA); pkt_len |= ((u_short) inb(EWRK3_DATA) << 8); } else { - rx_status = isa_readb(buf); + rx_status = readb(buf); buf += 1; - pkt_len = isa_readw(buf); + pkt_len = readw(buf); buf += 3; } @@ -1001,7 +1004,7 @@ *p++ = inb(EWRK3_DATA); } } else { - isa_memcpy_fromio(p, buf, pkt_len); + memcpy_fromio(p, buf, pkt_len); } for (i = 1; i < EWRK3_PKT_STAT_SZ - 1; i++) { @@ -1153,9 +1156,9 @@ csr = inb(EWRK3_CSR); if (lp->shmem_length == IO_ONLY) { - lp->mctbl = (char *) PAGE0_HTE; + lp->mctbl = NULL; } else { - lp->mctbl = (char *) (lp->shmem_base + PAGE0_HTE); + lp->mctbl = lp->shmem + PAGE0_HTE; } csr &= ~(CSR_PME | CSR_MCE); @@ -1184,7 +1187,7 @@ u_long iobase = dev->base_addr; int i; char *addrs, bit, byte; - short *p = (short *) lp->mctbl; + short __iomem *p = lp->mctbl; u16 hashcode; u32 crc; @@ -1192,7 +1195,7 @@ if (lp->shmem_length == IO_ONLY) { outb(0, EWRK3_IOPR); - outw(EEPROM_OFFSET(lp->mctbl), EWRK3_PIR1); + outw(PAGE0_HTE, EWRK3_PIR1); } else { outb(0, EWRK3_MPR); } @@ -1202,7 +1205,7 @@ if (lp->shmem_length == IO_ONLY) { outb(0xff, EWRK3_DATA); } else { /* memset didn't work here */ - isa_writew(0xffff, (int) p); + writew(0xffff, p); p++; i++; } @@ -1219,8 +1222,8 @@ outb(0x00, EWRK3_DATA); } } else { - isa_memset_io((int) lp->mctbl, 0, (HASH_TABLE_LEN >> 3)); - isa_writeb(0x80, (int) (lp->mctbl + (HASH_TABLE_LEN >> 4) - 1)); + memset_io(lp->mctbl, 0, HASH_TABLE_LEN >> 3); + writeb(0x80, lp->mctbl + (HASH_TABLE_LEN >> 4) - 1); } /* Update table */ @@ -1237,13 +1240,13 @@ if (lp->shmem_length == IO_ONLY) { u_char tmp; - outw((short) ((long) lp->mctbl) + byte, EWRK3_PIR1); + outw(PAGE0_HTE + byte, EWRK3_PIR1); tmp = inb(EWRK3_DATA); tmp |= bit; - outw((short) ((long) lp->mctbl) + byte, EWRK3_PIR1); + outw(PAGE0_HTE + byte, EWRK3_PIR1); outb(tmp, EWRK3_DATA); } else { - isa_writeb(isa_readb((int)(lp->mctbl + byte)) | bit, (int)(lp->mctbl + byte)); + writeb(readb(lp->mctbl + byte) | bit, lp->mctbl + byte); } } } @@ -1654,8 +1657,7 @@ /* Wait a little while */ spin_unlock_irqrestore(&lp->hw_lock, flags); - set_current_state(TASK_UNINTERRUPTIBLE); - schedule_timeout(HZ>>2); + msleep(250); spin_lock_irqsave(&lp->hw_lock, flags); /* Exit if we got a signal */ @@ -1784,7 +1786,7 @@ } } else { outb(0, EWRK3_MPR); - isa_memcpy_fromio(tmp->addr, lp->shmem_base + PAGE0_HTE, (HASH_TABLE_LEN >> 3)); + memcpy_fromio(tmp->addr, lp->shmem + PAGE0_HTE, (HASH_TABLE_LEN >> 3)); } spin_unlock_irqrestore(&lp->hw_lock, flags); @@ -1954,10 +1956,13 @@ int i; for( i=0; ibase_addr, EWRK3_TOTAL_SIZE); - free_netdev(ewrk3_devs[i]); + struct net_device *dev = ewrk3_devs[i]; + struct ewrk3_private *lp = netdev_priv(dev); ewrk3_devs[i] = NULL; + unregister_netdev(dev); + release_region(dev->base_addr, EWRK3_TOTAL_SIZE); + iounmap(lp->shmem); + free_netdev(dev); } } diff -Nru a/drivers/net/ioc3-eth.c b/drivers/net/ioc3-eth.c --- a/drivers/net/ioc3-eth.c 2005-03-09 12:20:51 -05:00 +++ b/drivers/net/ioc3-eth.c 2005-03-09 12:20:51 -05:00 @@ -56,7 +56,6 @@ #include #include #include -#include #include #include diff -Nru a/drivers/net/irda/act200l-sir.c b/drivers/net/irda/act200l-sir.c --- a/drivers/net/irda/act200l-sir.c 2005-03-09 12:20:51 -05:00 +++ b/drivers/net/irda/act200l-sir.c 2005-03-09 12:20:51 -05:00 @@ -177,8 +177,7 @@ /* Write control bytes */ sirdev_raw_write(dev, control, 3); - set_current_state(TASK_UNINTERRUPTIBLE); - schedule_timeout(msecs_to_jiffies(5)); + msleep(5); /* Go back to normal mode */ sirdev_set_dtr_rts(dev, TRUE, TRUE); diff -Nru a/drivers/net/irda/irtty-sir.c b/drivers/net/irda/irtty-sir.c --- a/drivers/net/irda/irtty-sir.c 2005-03-09 12:20:51 -05:00 +++ b/drivers/net/irda/irtty-sir.c 2005-03-09 12:20:51 -05:00 @@ -32,6 +32,7 @@ #include #include #include +#include #include #include @@ -97,8 +98,7 @@ unlock_kernel(); } else { - set_task_state(current, TASK_UNINTERRUPTIBLE); - schedule_timeout(msecs_to_jiffies(USBSERIAL_TX_DONE_DELAY)); + msleep(USBSERIAL_TX_DONE_DELAY); } } diff -Nru a/drivers/net/irda/ma600-sir.c b/drivers/net/irda/ma600-sir.c --- a/drivers/net/irda/ma600-sir.c 2005-03-09 12:20:51 -05:00 +++ b/drivers/net/irda/ma600-sir.c 2005-03-09 12:20:51 -05:00 @@ -191,8 +191,7 @@ sirdev_raw_write(dev, &byte, sizeof(byte)); /* Wait at least 10ms: fake wait_until_sent - 10 bits at 9600 baud*/ - set_current_state(TASK_UNINTERRUPTIBLE); - schedule_timeout(msecs_to_jiffies(15)); /* old ma600 uses 15ms */ + msleep(15); /* old ma600 uses 15ms */ #if 1 /* read-back of the control byte. ma600 is the first dongle driver @@ -215,8 +214,7 @@ sirdev_set_dtr_rts(dev, TRUE, TRUE); /* Wait at least 10ms */ - set_current_state(TASK_UNINTERRUPTIBLE); - schedule_timeout(msecs_to_jiffies(10)); + msleep(10); /* dongle is now switched to the new speed */ dev->speed = speed; @@ -245,13 +243,11 @@ /* Reset the dongle : set DTR low for 10 ms */ sirdev_set_dtr_rts(dev, FALSE, TRUE); - set_current_state(TASK_UNINTERRUPTIBLE); - schedule_timeout(msecs_to_jiffies(10)); + msleep(10); /* Go back to normal mode */ sirdev_set_dtr_rts(dev, TRUE, TRUE); - set_current_state(TASK_UNINTERRUPTIBLE); - schedule_timeout(msecs_to_jiffies(10)); + msleep(10); dev->speed = 9600; /* That's the dongle-default */ diff -Nru a/drivers/net/irda/sir_dev.c b/drivers/net/irda/sir_dev.c --- a/drivers/net/irda/sir_dev.c 2005-03-09 12:20:51 -05:00 +++ b/drivers/net/irda/sir_dev.c 2005-03-09 12:20:51 -05:00 @@ -15,6 +15,7 @@ #include #include #include +#include #include #include @@ -73,8 +74,7 @@ spin_lock_irqsave(&dev->tx_lock, flags); /* serialize with other tx operations */ while (dev->tx_buff.len > 0) { /* wait until tx idle */ spin_unlock_irqrestore(&dev->tx_lock, flags); - set_current_state(TASK_UNINTERRUPTIBLE); - schedule_timeout(msecs_to_jiffies(10)); + msleep(10); spin_lock_irqsave(&dev->tx_lock, flags); } diff -Nru a/drivers/net/irda/tekram-sir.c b/drivers/net/irda/tekram-sir.c --- a/drivers/net/irda/tekram-sir.c 2005-03-09 12:20:51 -05:00 +++ b/drivers/net/irda/tekram-sir.c 2005-03-09 12:20:51 -05:00 @@ -210,8 +210,7 @@ sirdev_set_dtr_rts(dev, FALSE, TRUE); /* Should sleep 1 ms */ - set_current_state(TASK_UNINTERRUPTIBLE); - schedule_timeout(msecs_to_jiffies(1)); + msleep(1); /* Set DTR, Set RTS */ sirdev_set_dtr_rts(dev, TRUE, TRUE); diff -Nru a/drivers/net/loopback.c b/drivers/net/loopback.c --- a/drivers/net/loopback.c 2005-03-09 12:20:51 -05:00 +++ b/drivers/net/loopback.c 2005-03-09 12:20:51 -05:00 @@ -184,7 +184,7 @@ return stats; } -u32 loopback_get_link(struct net_device *dev) +static u32 loopback_get_link(struct net_device *dev) { return 1; } diff -Nru a/drivers/net/lp486e.c b/drivers/net/lp486e.c --- a/drivers/net/lp486e.c 2005-03-09 12:20:51 -05:00 +++ b/drivers/net/lp486e.c 2005-03-09 12:20:51 -05:00 @@ -112,8 +112,10 @@ CmdDiagnose = 7 }; -char *CUcmdnames[8] = { "NOP", "IASetup", "Configure", "MulticastList", - "Tx", "TDR", "Dump", "Diagnose" }; +#if 0 +static const char *CUcmdnames[8] = { "NOP", "IASetup", "Configure", "MulticastList", + "Tx", "TDR", "Dump", "Diagnose" }; +#endif /* Status word bits */ #define STAT_CX 0x8000 /* The CU finished executing a command @@ -960,7 +962,7 @@ (unsigned char) add[12], (unsigned char) add[13]); } -int __init lp486e_probe(struct net_device *dev) { +static int __init lp486e_probe(struct net_device *dev) { struct i596_private *lp; unsigned char eth_addr[6] = { 0, 0xaa, 0, 0, 0, 0 }; unsigned char *bios; diff -Nru a/drivers/net/ni65.c b/drivers/net/ni65.c --- a/drivers/net/ni65.c 2005-03-09 12:20:51 -05:00 +++ b/drivers/net/ni65.c 2005-03-09 12:20:51 -05:00 @@ -526,8 +526,7 @@ ni65_init_lance(p,dev->dev_addr,0,0); irq_mask = probe_irq_on(); writereg(CSR0_INIT|CSR0_INEA,CSR0); /* trigger interrupt */ - set_current_state(TASK_UNINTERRUPTIBLE); - schedule_timeout(HZ/50); + msleep(20); dev->irq = probe_irq_off(irq_mask); if(!dev->irq) { diff -Nru a/drivers/net/ns83820.c b/drivers/net/ns83820.c --- a/drivers/net/ns83820.c 2005-03-09 12:20:51 -05:00 +++ b/drivers/net/ns83820.c 2005-03-09 12:20:51 -05:00 @@ -2007,8 +2007,7 @@ if (reset_phy) { printk(KERN_INFO "%s: resetting phy\n", ndev->name); writel(dev->CFG_cache | CFG_PHY_RST, dev->base + CFG); - set_current_state(TASK_UNINTERRUPTIBLE); - schedule_timeout((HZ+99)/100); + msleep(10); writel(dev->CFG_cache, dev->base + CFG); } diff -Nru a/drivers/net/pcmcia/ibmtr_cs.c b/drivers/net/pcmcia/ibmtr_cs.c --- a/drivers/net/pcmcia/ibmtr_cs.c 2005-03-09 12:20:51 -05:00 +++ b/drivers/net/pcmcia/ibmtr_cs.c 2005-03-09 12:20:51 -05:00 @@ -343,7 +343,8 @@ CS_CHECK(MapMemPage, pcmcia_map_mem_page(info->sram_win_handle, &mem)); ti->sram_base = mem.CardOffset >> 12; - ti->sram_virt = (u_long)ioremap(req.Base, req.Size); + ti->sram_virt = ioremap(req.Base, req.Size); + ti->sram_phys = req.Base; CS_CHECK(RequestConfiguration, pcmcia_request_configuration(link->handle, &link->conf)); @@ -401,7 +402,7 @@ pcmcia_release_irq(link->handle, &link->irq); if (link->win) { struct tok_info *ti = netdev_priv(dev); - iounmap((void *)ti->mmio); + iounmap(ti->mmio); pcmcia_release_window(link->win); pcmcia_release_window(info->sram_win_handle); } @@ -433,7 +434,7 @@ if (link->state & DEV_CONFIG) { /* set flag to bypass normal interrupt code */ struct tok_info *priv = netdev_priv(dev); - priv->sram_virt |= 1; + priv->sram_phys |= 1; netif_device_detach(dev); } break; diff -Nru a/drivers/net/pcmcia/xirc2ps_cs.c b/drivers/net/pcmcia/xirc2ps_cs.c --- a/drivers/net/pcmcia/xirc2ps_cs.c 2005-03-09 12:20:51 -05:00 +++ b/drivers/net/pcmcia/xirc2ps_cs.c 2005-03-09 12:20:51 -05:00 @@ -415,11 +415,6 @@ #define PutByte(reg,value) outb((value), ioaddr+(reg)) #define PutWord(reg,value) outw((value), ioaddr+(reg)) -#define Wait(n) do { \ - set_current_state(TASK_UNINTERRUPTIBLE); \ - schedule_timeout(n); \ -} while (0) - /*====== Functions used for debugging =================================*/ #if defined(PCMCIA_DEBUG) && 0 /* reading regs may change system status */ static void @@ -1707,12 +1702,12 @@ SelectPage(4); udelay(1); PutByte(XIRCREG4_GPR1, 0); /* clear bit 0: power down */ - Wait(HZ/25); /* wait 40 msec */ + msleep(40); /* wait 40 msec */ if (local->mohawk) PutByte(XIRCREG4_GPR1, 1); /* set bit 0: power up */ else PutByte(XIRCREG4_GPR1, 1 | 4); /* set bit 0: power up, bit 2: AIC */ - Wait(HZ/50); /* wait 20 msec */ + msleep(20); /* wait 20 msec */ } static void @@ -1726,9 +1721,9 @@ hardreset(dev); PutByte(XIRCREG_CR, SoftReset); /* set */ - Wait(HZ/50); /* wait 20 msec */ + msleep(20); /* wait 20 msec */ PutByte(XIRCREG_CR, 0); /* clear */ - Wait(HZ/25); /* wait 40 msec */ + msleep(40); /* wait 40 msec */ if (local->mohawk) { SelectPage(4); /* set pin GP1 and GP2 to output (0x0c) @@ -1739,7 +1734,7 @@ } /* give the circuits some time to power up */ - Wait(HZ/2); /* about 500ms */ + msleep(500); /* about 500ms */ local->last_ptr_value = 0; local->silicon = local->mohawk ? (GetByte(XIRCREG4_BOV) & 0x70) >> 4 @@ -1758,7 +1753,7 @@ SelectPage(0x42); PutByte(XIRCREG42_SWC1, 0x80); } - Wait(HZ/25); /* wait 40 msec to let it complete */ + msleep(40); /* wait 40 msec to let it complete */ #ifdef PCMCIA_DEBUG if (pc_debug) { @@ -1817,7 +1812,7 @@ printk(KERN_INFO "%s: MII selected\n", dev->name); SelectPage(2); PutByte(XIRCREG2_MSR, GetByte(XIRCREG2_MSR) | 0x08); - Wait(HZ/50); + msleep(20); } else { printk(KERN_INFO "%s: MII detected; using 10mbs\n", dev->name); @@ -1826,7 +1821,7 @@ PutByte(XIRCREG42_SWC1, 0xC0); else /* enable 10BaseT */ PutByte(XIRCREG42_SWC1, 0x80); - Wait(HZ/25); /* wait 40 msec to let it complete */ + msleep(40); /* wait 40 msec to let it complete */ } if (full_duplex) PutByte(XIRCREG1_ECR, GetByte(XIRCREG1_ECR | FullDuplex)); @@ -1919,7 +1914,7 @@ * Fixme: Better to use a timer here! */ for (i=0; i < 35; i++) { - Wait(HZ/10); /* wait 100 msec */ + msleep(100); /* wait 100 msec */ status = mii_rd(ioaddr, 0, 1); if ((status & 0x0020) && (status & 0x0004)) break; diff -Nru a/drivers/net/ppp_deflate.c b/drivers/net/ppp_deflate.c --- a/drivers/net/ppp_deflate.c 2005-03-09 12:20:51 -05:00 +++ b/drivers/net/ppp_deflate.c 2005-03-09 12:20:51 -05:00 @@ -600,7 +600,7 @@ /* * Procedures exported to if_ppp.c. */ -struct compressor ppp_deflate = { +static struct compressor ppp_deflate = { .compress_proto = CI_DEFLATE, .comp_alloc = z_comp_alloc, .comp_free = z_comp_free, @@ -618,7 +618,7 @@ .owner = THIS_MODULE }; -struct compressor ppp_deflate_draft = { +static struct compressor ppp_deflate_draft = { .compress_proto = CI_DEFLATE_DRAFT, .comp_alloc = z_comp_alloc, .comp_free = z_comp_free, diff -Nru a/drivers/net/ppp_generic.c b/drivers/net/ppp_generic.c --- a/drivers/net/ppp_generic.c 2005-03-09 12:20:51 -05:00 +++ b/drivers/net/ppp_generic.c 2005-03-09 12:20:51 -05:00 @@ -2741,8 +2741,6 @@ EXPORT_SYMBOL(ppp_output_wakeup); EXPORT_SYMBOL(ppp_register_compressor); EXPORT_SYMBOL(ppp_unregister_compressor); -EXPORT_SYMBOL(all_ppp_units); /* for debugging */ -EXPORT_SYMBOL(all_channels); /* for debugging */ MODULE_LICENSE("GPL"); MODULE_ALIAS_CHARDEV_MAJOR(PPP_MAJOR); MODULE_ALIAS("/dev/ppp"); diff -Nru a/drivers/net/pppoe.c b/drivers/net/pppoe.c --- a/drivers/net/pppoe.c 2005-03-09 12:20:51 -05:00 +++ b/drivers/net/pppoe.c 2005-03-09 12:20:51 -05:00 @@ -1036,7 +1036,7 @@ read_unlock_bh(&pppoe_hash_lock); } -struct seq_operations pppoe_seq_ops = { +static struct seq_operations pppoe_seq_ops = { .start = pppoe_seq_start, .next = pppoe_seq_next, .stop = pppoe_seq_stop, diff -Nru a/drivers/net/s2io.c b/drivers/net/s2io.c --- a/drivers/net/s2io.c 2005-03-09 12:20:51 -05:00 +++ b/drivers/net/s2io.c 2005-03-09 12:20:51 -05:00 @@ -1350,7 +1350,7 @@ * */ -void fix_mac_address(nic_t * sp) +static void fix_mac_address(nic_t * sp) { XENA_dev_config_t __iomem *bar0 = sp->bar0; u64 val64; @@ -1506,7 +1506,7 @@ * Return Value: void */ -void free_tx_buffers(struct s2io_nic *nic) +static void free_tx_buffers(struct s2io_nic *nic) { struct net_device *dev = nic->dev; struct sk_buff *skb; @@ -1597,7 +1597,7 @@ * SUCCESS on success or an appropriate -ve value on failure. */ -int fill_rx_buffers(struct s2io_nic *nic, int ring_no) +static int fill_rx_buffers(struct s2io_nic *nic, int ring_no) { struct net_device *dev = nic->dev; struct sk_buff *skb; @@ -2422,7 +2422,7 @@ * SUCCESS on success and FAILURE on failure. */ -int wait_for_cmd_complete(nic_t * sp) +static int wait_for_cmd_complete(nic_t * sp) { XENA_dev_config_t __iomem *bar0 = sp->bar0; int ret = FAILURE, cnt = 0; @@ -2452,7 +2452,7 @@ * void. */ -void s2io_reset(nic_t * sp) +static void s2io_reset(nic_t * sp) { XENA_dev_config_t __iomem *bar0 = sp->bar0; u64 val64; @@ -2504,7 +2504,7 @@ * SUCCESS on success and FAILURE on failure. */ -int s2io_set_swapper(nic_t * sp) +static int s2io_set_swapper(nic_t * sp) { struct net_device *dev = sp->dev; XENA_dev_config_t __iomem *bar0 = sp->bar0; @@ -2598,7 +2598,7 @@ * file on failure. */ -int s2io_open(struct net_device *dev) +static int s2io_open(struct net_device *dev) { nic_t *sp = dev->priv; int err = 0; @@ -2650,7 +2650,7 @@ * file on failure. */ -int s2io_close(struct net_device *dev) +static int s2io_close(struct net_device *dev) { nic_t *sp = dev->priv; @@ -2677,7 +2677,7 @@ * 0 on success & 1 on failure. */ -int s2io_xmit(struct sk_buff *skb, struct net_device *dev) +static int s2io_xmit(struct sk_buff *skb, struct net_device *dev) { nic_t *sp = dev->priv; u16 frg_cnt, frg_len, i, queue, queue_len, put_off, get_off; @@ -2897,7 +2897,7 @@ * pointer to the updated net_device_stats structure. */ -struct net_device_stats *s2io_get_stats(struct net_device *dev) +static struct net_device_stats *s2io_get_stats(struct net_device *dev) { nic_t *sp = dev->priv; mac_info_t *mac_control; @@ -3150,7 +3150,7 @@ * return 0 on success. */ -int s2io_ethtool_gset(struct net_device *dev, struct ethtool_cmd *info) +static int s2io_ethtool_gset(struct net_device *dev, struct ethtool_cmd *info) { nic_t *sp = dev->priv; info->supported = (SUPPORTED_10000baseT_Full | SUPPORTED_FIBRE); @@ -3347,8 +3347,8 @@ * int, returns 0 on Success */ -int s2io_ethtool_setpause_data(struct net_device *dev, - struct ethtool_pauseparam *ep) +static int s2io_ethtool_setpause_data(struct net_device *dev, + struct ethtool_pauseparam *ep) { u64 val64; nic_t *sp = dev->priv; @@ -3463,8 +3463,8 @@ * int 0 on success */ -int s2io_ethtool_geeprom(struct net_device *dev, - struct ethtool_eeprom *eeprom, u8 * data_buf) +static int s2io_ethtool_geeprom(struct net_device *dev, + struct ethtool_eeprom *eeprom, u8 * data_buf) { u32 data, i, valid; nic_t *sp = dev->priv; @@ -3961,19 +3961,20 @@ tmp_stats[i++] = stat_info->rmac_err_tcp; } -int s2io_ethtool_get_regs_len(struct net_device *dev) +static int s2io_ethtool_get_regs_len(struct net_device *dev) { return (XENA_REG_SPACE); } -u32 s2io_ethtool_get_rx_csum(struct net_device * dev) +static u32 s2io_ethtool_get_rx_csum(struct net_device * dev) { nic_t *sp = dev->priv; return (sp->rx_csum); } -int s2io_ethtool_set_rx_csum(struct net_device *dev, u32 data) + +static int s2io_ethtool_set_rx_csum(struct net_device *dev, u32 data) { nic_t *sp = dev->priv; @@ -3984,17 +3985,19 @@ return 0; } -int s2io_get_eeprom_len(struct net_device *dev) + +static int s2io_get_eeprom_len(struct net_device *dev) { return (XENA_EEPROM_SPACE); } -int s2io_ethtool_self_test_count(struct net_device *dev) +static int s2io_ethtool_self_test_count(struct net_device *dev) { return (S2IO_TEST_LEN); } -void s2io_ethtool_get_strings(struct net_device *dev, - u32 stringset, u8 * data) + +static void s2io_ethtool_get_strings(struct net_device *dev, + u32 stringset, u8 * data) { switch (stringset) { case ETH_SS_TEST: @@ -4005,12 +4008,13 @@ sizeof(ethtool_stats_keys)); } } + static int s2io_ethtool_get_stats_count(struct net_device *dev) { return (S2IO_STAT_LEN); } -int s2io_ethtool_op_set_tx_csum(struct net_device *dev, u32 data) +static int s2io_ethtool_op_set_tx_csum(struct net_device *dev, u32 data) { if (data) dev->features |= NETIF_F_IP_CSUM; @@ -4066,7 +4070,7 @@ * function returns OP NOT SUPPORTED value. */ -int s2io_ioctl(struct net_device *dev, struct ifreq *rq, int cmd) +static int s2io_ioctl(struct net_device *dev, struct ifreq *rq, int cmd) { return -EOPNOTSUPP; } @@ -4082,7 +4086,7 @@ * file on failure. */ -int s2io_change_mtu(struct net_device *dev, int new_mtu) +static int s2io_change_mtu(struct net_device *dev, int new_mtu) { nic_t *sp = dev->priv; XENA_dev_config_t __iomem *bar0 = sp->bar0; @@ -4476,7 +4480,7 @@ * void. */ -void s2io_link(nic_t * sp, int link) +static void s2io_link(nic_t * sp, int link) { struct net_device *dev = (struct net_device *) sp->dev; @@ -4493,23 +4497,6 @@ } /** - * get_xena_rev_id - to identify revision ID of xena. - * @pdev : PCI Dev structure - * Description: - * Function to identify the Revision ID of xena. - * Return value: - * returns the revision ID of the device. - */ - -int get_xena_rev_id(struct pci_dev *pdev) -{ - u8 id = 0; - int ret; - ret = pci_read_config_byte(pdev, PCI_REVISION_ID, (u8 *) & id); - return id; -} - -/** * s2io_init_pci -Initialization of PCI and PCI-X configuration registers . * @sp : private member of the device structure, which is a pointer to the * s2io_nic structure. @@ -4962,7 +4949,7 @@ * Description: This function is the cleanup routine for the driver. It unregist * ers the driver. */ -void s2io_closer(void) +static void s2io_closer(void) { pci_unregister_driver(&s2io_driver); DBG_PRINT(INIT_DBG, "cleanup done\n"); diff -Nru a/drivers/net/s2io.h b/drivers/net/s2io.h --- a/drivers/net/s2io.h 2005-03-09 12:20:51 -05:00 +++ b/drivers/net/s2io.h 2005-03-09 12:20:51 -05:00 @@ -848,7 +848,7 @@ static void alarm_intr_handler(struct s2io_nic *sp); static int s2io_starter(void); -void s2io_closer(void); +static void s2io_closer(void); static void s2io_tx_watchdog(struct net_device *dev); static void s2io_tasklet(unsigned long dev_addr); static void s2io_set_multicast(struct net_device *dev); @@ -858,13 +858,13 @@ static int rx_osm_handler(nic_t * sp, RxD_t * rxdp, int ring_no, buffAdd_t * ba); #endif -void s2io_link(nic_t * sp, int link); -void s2io_reset(nic_t * sp); +static void s2io_link(nic_t * sp, int link); +static void s2io_reset(nic_t * sp); #ifdef CONFIG_S2IO_NAPI static int s2io_poll(struct net_device *dev, int *budget); #endif static void s2io_init_pci(nic_t * sp); -int s2io_set_mac_addr(struct net_device *dev, u8 * addr); +static int s2io_set_mac_addr(struct net_device *dev, u8 * addr); static irqreturn_t s2io_isr(int irq, void *dev_id, struct pt_regs *regs); static int verify_xena_quiescence(u64 val64, int flag); static struct ethtool_ops netdev_ethtool_ops; diff -Nru a/drivers/net/sb1000.c b/drivers/net/sb1000.c --- a/drivers/net/sb1000.c 2005-03-09 12:20:51 -05:00 +++ b/drivers/net/sb1000.c 2005-03-09 12:20:51 -05:00 @@ -57,9 +57,9 @@ #include #ifdef SB1000_DEBUG -int sb1000_debug = SB1000_DEBUG; +static int sb1000_debug = SB1000_DEBUG; #else -int sb1000_debug = 1; +static int sb1000_debug = 1; #endif static const int SB1000_IO_EXTENT = 8; @@ -116,15 +116,15 @@ static inline int sb1000_end_get_set_command(const int ioaddr[], const char* name); static inline int sb1000_activate(const int ioaddr[], const char* name); -static inline int sb1000_get_firmware_version(const int ioaddr[], +static int sb1000_get_firmware_version(const int ioaddr[], const char* name, unsigned char version[], int do_end); -static inline int sb1000_get_frequency(const int ioaddr[], const char* name, +static int sb1000_get_frequency(const int ioaddr[], const char* name, int* frequency); -static inline int sb1000_set_frequency(const int ioaddr[], const char* name, +static int sb1000_set_frequency(const int ioaddr[], const char* name, int frequency); -static inline int sb1000_get_PIDs(const int ioaddr[], const char* name, +static int sb1000_get_PIDs(const int ioaddr[], const char* name, short PID[]); -static inline int sb1000_set_PIDs(const int ioaddr[], const char* name, +static int sb1000_set_PIDs(const int ioaddr[], const char* name, const short PID[]); /* SB1000 commands for frame rx interrupt */ @@ -252,7 +252,7 @@ * SB1000 hardware routines to be used during open/configuration phases */ -const int TimeOutJiffies = (875 * HZ) / 100; +static const int TimeOutJiffies = (875 * HZ) / 100; static inline void nicedelay(unsigned long usecs) { @@ -363,7 +363,7 @@ /* * SB1000 hardware routines to be used during frame rx interrupt */ -const int Sb1000TimeOutJiffies = 7 * HZ; +static const int Sb1000TimeOutJiffies = 7 * HZ; /* Card Wait For Ready (to be used during frame rx) */ static inline int @@ -552,7 +552,7 @@ } /* get SB1000 firmware version */ -static inline int +static int sb1000_get_firmware_version(const int ioaddr[], const char* name, unsigned char version[], int do_end) { @@ -575,7 +575,7 @@ } /* get SB1000 frequency */ -static inline int +static int sb1000_get_frequency(const int ioaddr[], const char* name, int* frequency) { unsigned char st[7]; @@ -592,7 +592,7 @@ } /* set SB1000 frequency */ -static inline int +static int sb1000_set_frequency(const int ioaddr[], const char* name, int frequency) { unsigned char st[7]; @@ -622,7 +622,7 @@ } /* get SB1000 PIDs */ -static inline int +static int sb1000_get_PIDs(const int ioaddr[], const char* name, short PID[]) { unsigned char st[7]; @@ -656,7 +656,7 @@ } /* set SB1000 PIDs */ -static inline int +static int sb1000_set_PIDs(const int ioaddr[], const char* name, const short PID[]) { unsigned char st[7]; diff -Nru a/drivers/net/shaper.c b/drivers/net/shaper.c --- a/drivers/net/shaper.c 2005-03-09 12:20:51 -05:00 +++ b/drivers/net/shaper.c 2005-03-09 12:20:51 -05:00 @@ -96,7 +96,7 @@ }; #define SHAPERCB(skb) ((struct shaper_cb *) ((skb)->cb)) -int sh_debug; /* Debug flag */ +static int sh_debug; /* Debug flag */ #define SHAPER_BANNER "CymruNet Traffic Shaper BETA 0.04 for Linux 2.1\n" diff -Nru a/drivers/net/slhc.c b/drivers/net/slhc.c --- a/drivers/net/slhc.c 2005-03-09 12:20:51 -05:00 +++ b/drivers/net/slhc.c 2005-03-09 12:20:51 -05:00 @@ -693,33 +693,6 @@ } -void slhc_i_status(struct slcompress *comp) -{ - if (comp != NULLSLCOMPR) { - printk("\t%d Cmp, %d Uncmp, %d Bad, %d Tossed\n", - comp->sls_i_compressed, - comp->sls_i_uncompressed, - comp->sls_i_error, - comp->sls_i_tossed); - } -} - - -void slhc_o_status(struct slcompress *comp) -{ - if (comp != NULLSLCOMPR) { - printk("\t%d Cmp, %d Uncmp, %d AsIs, %d NotTCP\n", - comp->sls_o_compressed, - comp->sls_o_uncompressed, - comp->sls_o_tcp, - comp->sls_o_nontcp); - printk("\t%10d Searches, %10d Misses\n", - comp->sls_o_searches, - comp->sls_o_misses); - } -} - -/* Should this be surrounded with "#ifdef CONFIG_MODULES" ? */ /* VJ header compression */ EXPORT_SYMBOL(slhc_init); EXPORT_SYMBOL(slhc_free); diff -Nru a/drivers/net/smc-mca.c b/drivers/net/smc-mca.c --- a/drivers/net/smc-mca.c 2005-03-09 12:20:51 -05:00 +++ b/drivers/net/smc-mca.c 2005-03-09 12:20:51 -05:00 @@ -310,9 +310,13 @@ ei_status.rx_start_page = START_PG + TX_PAGES; ei_status.stop_page = num_pages; - ei_status.rmem_start = dev->mem_start + TX_PAGES * 256; - dev->mem_end = ei_status.rmem_end = - dev->mem_start + (ei_status.stop_page - START_PG) * 256; + ei_status.mem = ioremap(dev->mem_start, (ei_status.stop_page - START_PG) * 256); + if (!ei_status.mem) { + rc = -ENOMEM; + goto err_release_region; + } + + dev->mem_end = dev->mem_start + (ei_status.stop_page - START_PG) * 256; printk(", IRQ %d memory %#lx-%#lx.\n", dev->irq, dev->mem_start, dev->mem_end - 1); @@ -334,10 +338,12 @@ rc = register_netdev(dev); if (rc) - goto err_release_region; + goto err_unmap; return 0; +err_unmap: + iounmap(ei_status.mem); err_release_region: release_region(ioaddr, ULTRA_IO_EXTENT); err_unclaim: @@ -395,13 +401,13 @@ static void ultramca_get_8390_hdr(struct net_device *dev, struct e8390_pkt_hdr *hdr, int ring_page) { - unsigned long hdr_start = dev->mem_start + ((ring_page - START_PG) << 8); + void __iomem *hdr_start = ei_status.mem + ((ring_page - START_PG) << 8); #ifdef notdef /* Officially this is what we are doing, but the readl() is faster */ - isa_memcpy_fromio(hdr, hdr_start, sizeof(struct e8390_pkt_hdr)); + memcpy_fromio(hdr, hdr_start, sizeof(struct e8390_pkt_hdr)); #else - ((unsigned int*)hdr)[0] = isa_readl(hdr_start); + ((unsigned int*)hdr)[0] = readl(hdr_start); #endif } @@ -411,17 +417,17 @@ static void ultramca_block_input(struct net_device *dev, int count, struct sk_buff *skb, int ring_offset) { - unsigned long xfer_start = dev->mem_start + ring_offset - (START_PG << 8); + void __iomem *xfer_start = ei_status.mem + ring_offset - START_PG * 256; - if (xfer_start + count > ei_status.rmem_end) { + if (ring_offset + count > ei_status.stop_page * 256) { /* We must wrap the input move. */ - int semi_count = ei_status.rmem_end - xfer_start; - isa_memcpy_fromio(skb->data, xfer_start, semi_count); + int semi_count = ei_status.stop_page * 256 - ring_offset; + memcpy_fromio(skb->data, xfer_start, semi_count); count -= semi_count; - isa_memcpy_fromio(skb->data + semi_count, ei_status.rmem_start, count); + memcpy_fromio(skb->data + semi_count, ei_status.mem + TX_PAGES * 256, count); } else { /* Packet is in one chunk -- we can copy + cksum. */ - isa_eth_io_copy_and_sum(skb, xfer_start, count, 0); + eth_io_copy_and_sum(skb, xfer_start, count, 0); } } @@ -429,9 +435,9 @@ static void ultramca_block_output(struct net_device *dev, int count, const unsigned char *buf, int start_page) { - unsigned long shmem = dev->mem_start + ((start_page - START_PG) << 8); + void __iomem *shmem = ei_status.mem + ((start_page - START_PG) << 8); - isa_memcpy_toio(shmem, buf, count); + memcpy_toio(shmem, buf, count); } static int ultramca_close_card(struct net_device *dev) @@ -466,6 +472,7 @@ unregister_netdev(dev); mca_device_set_claim(mca_dev, 0); release_region(ioaddr, ULTRA_IO_EXTENT); + iounmap(ei_status.mem); free_netdev(dev); } return 0; diff -Nru a/drivers/net/smc-ultra.c b/drivers/net/smc-ultra.c --- a/drivers/net/smc-ultra.c 2005-03-09 12:20:51 -05:00 +++ b/drivers/net/smc-ultra.c 2005-03-09 12:20:51 -05:00 @@ -176,6 +176,7 @@ pnp_device_detach(idev); #endif release_region(dev->base_addr - ULTRA_NIC_OFFSET, ULTRA_IO_EXTENT); + iounmap(ei_status.mem); } #ifndef MODULE @@ -294,9 +295,14 @@ ei_status.rx_start_page = START_PG + TX_PAGES; ei_status.stop_page = num_pages; - ei_status.rmem_start = dev->mem_start + TX_PAGES*256; - dev->mem_end = ei_status.rmem_end - = dev->mem_start + (ei_status.stop_page - START_PG)*256; + ei_status.mem = ioremap(dev->mem_start, (ei_status.stop_page - START_PG)*256); + if (!ei_status.mem) { + printk(", failed to ioremap.\n"); + retval = -ENOMEM; + goto out; + } + + dev->mem_end = dev->mem_start + (ei_status.stop_page - START_PG)*256; if (piomode) { printk(",%s IRQ %d programmed-I/O mode.\n", @@ -430,16 +436,16 @@ static void ultra_get_8390_hdr(struct net_device *dev, struct e8390_pkt_hdr *hdr, int ring_page) { - unsigned long hdr_start = dev->mem_start + ((ring_page - START_PG)<<8); + void __iomem *hdr_start = ei_status.mem + ((ring_page - START_PG)<<8); outb(ULTRA_MEMENB, dev->base_addr - ULTRA_NIC_OFFSET); /* shmem on */ #ifdef __BIG_ENDIAN /* Officially this is what we are doing, but the readl() is faster */ /* unfortunately it isn't endian aware of the struct */ - isa_memcpy_fromio(hdr, hdr_start, sizeof(struct e8390_pkt_hdr)); + memcpy_fromio(hdr, hdr_start, sizeof(struct e8390_pkt_hdr)); hdr->count = le16_to_cpu(hdr->count); #else - ((unsigned int*)hdr)[0] = isa_readl(hdr_start); + ((unsigned int*)hdr)[0] = readl(hdr_start); #endif outb(0x00, dev->base_addr - ULTRA_NIC_OFFSET); /* shmem off */ } @@ -450,20 +456,20 @@ static void ultra_block_input(struct net_device *dev, int count, struct sk_buff *skb, int ring_offset) { - unsigned long xfer_start = dev->mem_start + ring_offset - (START_PG<<8); + void __iomem *xfer_start = ei_status.mem + ring_offset - (START_PG<<8); /* Enable shared memory. */ outb(ULTRA_MEMENB, dev->base_addr - ULTRA_NIC_OFFSET); - if (xfer_start + count > ei_status.rmem_end) { + if (ring_offset + count > ei_status.stop_page*256) { /* We must wrap the input move. */ - int semi_count = ei_status.rmem_end - xfer_start; - isa_memcpy_fromio(skb->data, xfer_start, semi_count); + int semi_count = ei_status.stop_page*256 - ring_offset; + memcpy_fromio(skb->data, xfer_start, semi_count); count -= semi_count; - isa_memcpy_fromio(skb->data + semi_count, ei_status.rmem_start, count); + memcpy_fromio(skb->data + semi_count, ei_status.mem + TX_PAGES * 256, count); } else { /* Packet is in one chunk -- we can copy + cksum. */ - isa_eth_io_copy_and_sum(skb, xfer_start, count, 0); + eth_io_copy_and_sum(skb, xfer_start, count, 0); } outb(0x00, dev->base_addr - ULTRA_NIC_OFFSET); /* Disable memory. */ @@ -473,12 +479,12 @@ ultra_block_output(struct net_device *dev, int count, const unsigned char *buf, int start_page) { - unsigned long shmem = dev->mem_start + ((start_page - START_PG)<<8); + void __iomem *shmem = ei_status.mem + ((start_page - START_PG)<<8); /* Enable shared memory. */ outb(ULTRA_MEMENB, dev->base_addr - ULTRA_NIC_OFFSET); - isa_memcpy_toio(shmem, buf, count); + memcpy_toio(shmem, buf, count); outb(0x00, dev->base_addr - ULTRA_NIC_OFFSET); /* Disable memory. */ } diff -Nru a/drivers/net/smc-ultra32.c b/drivers/net/smc-ultra32.c --- a/drivers/net/smc-ultra32.c 2005-03-09 12:20:51 -05:00 +++ b/drivers/net/smc-ultra32.c 2005-03-09 12:20:51 -05:00 @@ -104,6 +104,7 @@ int ioaddr = dev->base_addr - ULTRA32_NIC_OFFSET; /* NB: ultra32_close_card() does free_irq */ release_region(ioaddr, ULTRA32_IO_EXTENT); + iounmap(ei_status.mem); } /* Probe for the Ultra32. This looks like a 8013 with the station @@ -259,8 +260,13 @@ /* All Ultra32 cards have 32KB memory with an 8KB window. */ ei_status.stop_page = 128; - ei_status.rmem_start = dev->mem_start + TX_PAGES*256; - dev->mem_end = ei_status.rmem_end = dev->mem_start + 0x1fff; + ei_status.mem = ioremap(dev->mem_start, 0x2000); + if (!ei_status.mem) { + printk(", failed to ioremap.\n"); + retval = -ENOMEM; + goto out; + } + dev->mem_end = dev->mem_start + 0x1fff; printk(", IRQ %d, 32KB memory, 8KB window at 0x%lx-0x%lx.\n", dev->irq, dev->mem_start, dev->mem_end); @@ -345,7 +351,7 @@ struct e8390_pkt_hdr *hdr, int ring_page) { - unsigned long hdr_start = dev->mem_start + ((ring_page & 0x1f) << 8); + void __iomem *hdr_start = ei_status.mem + ((ring_page & 0x1f) << 8); unsigned int RamReg = dev->base_addr - ULTRA32_NIC_OFFSET + ULTRA32_CFG3; /* Select correct 8KB Window. */ @@ -354,10 +360,10 @@ #ifdef __BIG_ENDIAN /* Officially this is what we are doing, but the readl() is faster */ /* unfortunately it isn't endian aware of the struct */ - isa_memcpy_fromio(hdr, hdr_start, sizeof(struct e8390_pkt_hdr)); + memcpy_fromio(hdr, hdr_start, sizeof(struct e8390_pkt_hdr)); hdr->count = le16_to_cpu(hdr->count); #else - ((unsigned int*)hdr)[0] = isa_readl(hdr_start); + ((unsigned int*)hdr)[0] = readl(hdr_start); #endif } @@ -371,26 +377,26 @@ struct sk_buff *skb, int ring_offset) { - unsigned long xfer_start = dev->mem_start + (ring_offset & 0x1fff); + void __iomem *xfer_start = ei_status.mem + (ring_offset & 0x1fff); unsigned int RamReg = dev->base_addr - ULTRA32_NIC_OFFSET + ULTRA32_CFG3; if ((ring_offset & ~0x1fff) != ((ring_offset + count - 1) & ~0x1fff)) { int semi_count = 8192 - (ring_offset & 0x1FFF); - isa_memcpy_fromio(skb->data, xfer_start, semi_count); + memcpy_fromio(skb->data, xfer_start, semi_count); count -= semi_count; if (ring_offset < 96*256) { /* Select next 8KB Window. */ ring_offset += semi_count; outb(ei_status.reg0 | ((ring_offset & 0x6000) >> 13), RamReg); - isa_memcpy_fromio(skb->data + semi_count, dev->mem_start, count); + memcpy_fromio(skb->data + semi_count, ei_status.mem, count); } else { /* Select first 8KB Window. */ outb(ei_status.reg0, RamReg); - isa_memcpy_fromio(skb->data + semi_count, ei_status.rmem_start, count); + memcpy_fromio(skb->data + semi_count, ei_status.mem + TX_PAGES * 256, count); } } else { /* Packet is in one chunk -- we can copy + cksum. */ - isa_eth_io_copy_and_sum(skb, xfer_start, count, 0); + eth_io_copy_and_sum(skb, xfer_start, count, 0); } } @@ -399,13 +405,13 @@ const unsigned char *buf, int start_page) { - unsigned long xfer_start = dev->mem_start + (start_page<<8); + void __iomem *xfer_start = ei_status.mem + (start_page<<8); unsigned int RamReg = dev->base_addr - ULTRA32_NIC_OFFSET + ULTRA32_CFG3; /* Select first 8KB Window. */ outb(ei_status.reg0, RamReg); - isa_memcpy_toio(xfer_start, buf, count); + memcpy_toio(xfer_start, buf, count); } #ifdef MODULE diff -Nru a/drivers/net/tokenring/ibmtr.c b/drivers/net/tokenring/ibmtr.c --- a/drivers/net/tokenring/ibmtr.c 2005-03-09 12:20:51 -05:00 +++ b/drivers/net/tokenring/ibmtr.c 2005-03-09 12:20:51 -05:00 @@ -227,7 +227,7 @@ printk("\n"); } -static void __devinit HWPrtChanID(void * pcid, short stride) +static void __devinit HWPrtChanID(void __iomem *pcid, short stride) { short i, j; for (i = 0, j = 0; i < 24; i++, j += stride) @@ -239,15 +239,16 @@ * going away. */ -static void __devinit find_turbo_adapters(int *iolist) { +static void __devinit find_turbo_adapters(int *iolist) +{ int ram_addr; int index=0; - void *chanid; + void __iomem *chanid; int found_turbo=0; unsigned char *tchanid, ctemp; int i, j; unsigned long jif; - void *ram_mapped ; + void __iomem *ram_mapped ; if (turbo_searched == 1) return; turbo_searched=1; @@ -328,8 +329,8 @@ { struct tok_info *ti = (struct tok_info *) dev->priv; - iounmap((u32 *)ti->mmio); - iounmap((u32 *)ti->sram_virt); + iounmap(ti->mmio); + iounmap(ti->sram_virt); } #endif } @@ -383,9 +384,9 @@ { unsigned char segment, intr=0, irq=0, i, j, cardpresent=NOTOK, temp=0; - void * t_mmio = NULL; + void __iomem * t_mmio = NULL; struct tok_info *ti = dev->priv; - void *cd_chanid; + void __iomem *cd_chanid; unsigned char *tchanid, ctemp; #ifndef PCMCIA unsigned char t_irq=0; @@ -428,7 +429,7 @@ */ #ifdef PCMCIA iounmap(t_mmio); - t_mmio = (void *)ti->mmio; /*BMS to get virtual address */ + t_mmio = ti->mmio; /*BMS to get virtual address */ irq = ti->irq; /*BMS to display the irq! */ #endif cd_chanid = (CHANNEL_ID + t_mmio); /* for efficiency */ @@ -515,7 +516,7 @@ if (intr == 3) irq = 11; ti->global_int_enable = 0; ti->adapter_int_enable = 0; - ti->sram_virt=(__u32)(inb(PIOaddr+ADAPTRESETREL) & 0xfe) << 12; + ti->sram_phys=(__u32)(inb(PIOaddr+ADAPTRESETREL) & 0xfe) << 12; break; case TR_ISAPNP: if (!t_irq) { @@ -533,7 +534,7 @@ kfree(ti); return -ENODEV; } - ti->sram_virt = + ti->sram_phys = ((__u32)readb(ti->mmio+ACA_OFFSET+ACA_RW+RRR_EVEN)<<12); ti->adapter_int_enable = PIOaddr + ADAPTINTREL; break; @@ -542,7 +543,7 @@ if (ibmtr_debug_trace & TRC_INIT) { /* just report int */ DPRINTK("irq=%d", irq); - printk(", sram_virt=0x%x", ti->sram_virt); + printk(", sram_phys=0x%x", ti->sram_phys); if(ibmtr_debug_trace&TRC_INITV){ /* full chat in verbose only */ DPRINTK(", ti->mmio=%p", ti->mmio); printk(", segment=%02X", segment); @@ -681,7 +682,7 @@ ibmtr_mem_base = chk_base; } } - else ti->sram_base = ti->sram_virt >> 12; + else ti->sram_base = ti->sram_phys >> 12; /* The PCMCIA has already got the interrupt line and the io port, so no chance of anybody else getting it - MLP */ @@ -893,7 +894,7 @@ */ dev->flags &= ~IFF_RUNNING; - ti->sram_virt &= ~1; /* to reverse what we do in tok_close */ + ti->sram_phys &= ~1; /* to reverse what we do in tok_close */ /* init the spinlock */ spin_lock_init(&ti->lock); init_timer(&ti->tr_timer); @@ -1068,7 +1069,7 @@ /* unloading the module from memory, and then if a timer pops, ouch */ del_timer_sync(&ti->tr_timer); outb(0, dev->base_addr + ADAPTRESET); - ti->sram_virt |= 1; + ti->sram_phys |= 1; ti->open_status = CLOSED; netif_stop_queue(dev); @@ -1094,30 +1095,33 @@ "IMPL force received","Duplicate modifier", "No monitor detected","Monitor contention failed for RPL"}; -void dir_open_adapter (struct net_device *dev) { +static void __iomem *map_address(struct tok_info *ti, unsigned index, __u8 *page) +{ + if (ti->page_mask) { + *page = (index >> 8) & ti->page_mask; + index &= ~(ti->page_mask << 8); + } + return ti->sram_virt + index; +} +void dir_open_adapter (struct net_device *dev) +{ struct tok_info *ti = (struct tok_info *) dev->priv; unsigned char ret_code; __u16 err; - ti->srb = ntohs(readw(ti->init_srb + SRB_ADDRESS_OFST)); - ti->ssb = ntohs(readw(ti->init_srb + SSB_ADDRESS_OFST)); - ti->arb = ntohs(readw(ti->init_srb + ARB_ADDRESS_OFST)); - ti->asb = ntohs(readw(ti->init_srb + ASB_ADDRESS_OFST)); - if (ti->page_mask) { - ti->srb_page = (ti->srb >> 8) & ti->page_mask; - ti->srb &= ~(ti->page_mask << 8); - ti->ssb_page = (ti->ssb >> 8) & ti->page_mask; - ti->ssb &= ~(ti->page_mask << 8); - ti->arb_page = (ti->arb >> 8) & ti->page_mask; - ti->arb &= ~(ti->page_mask << 8); - ti->asb_page = (ti->asb >> 8) & ti->page_mask; - ti->asb &= ~(ti->page_mask << 8); - } - ti->srb += ti->sram_virt; - ti->ssb += ti->sram_virt; - ti->arb += ti->sram_virt; - ti->asb += ti->sram_virt; + ti->srb = map_address(ti, + ntohs(readw(ti->init_srb + SRB_ADDRESS_OFST)), + &ti->srb_page); + ti->ssb = map_address(ti, + ntohs(readw(ti->init_srb + SSB_ADDRESS_OFST)), + &ti->ssb_page); + ti->arb = map_address(ti, + ntohs(readw(ti->init_srb + ARB_ADDRESS_OFST)), + &ti->arb_page); + ti->asb = map_address(ti, + ntohs(readw(ti->init_srb + ASB_ADDRESS_OFST)), + &ti->asb_page); ti->current_skb = NULL; ret_code = readb(ti->init_srb + RETCODE_OFST); err = ntohs(readw(ti->init_srb + OPEN_ERROR_CODE_OFST)); @@ -1188,7 +1192,7 @@ DPRINTK("Int from tok_driver, dev : %p irq%d regs=%p\n", dev,irq,regs); #endif ti = (struct tok_info *) dev->priv; - if (ti->sram_virt & 1) + if (ti->sram_phys & 1) return IRQ_NONE; /* PCMCIA card extraction flag */ spin_lock(&(ti->lock)); #ifdef ENABLE_PAGING @@ -1220,15 +1224,11 @@ if (status & ADAP_CHK_INT) { int i; - __u32 check_reason; + void __iomem *check_reason; __u8 check_reason_page = 0; - check_reason = - ntohs(readw(ti->mmio+ ACA_OFFSET+ACA_RW + WWCR_EVEN)); - if (ti->page_mask) { - check_reason_page = (check_reason >> 8) & ti->page_mask; - check_reason &= ~(ti->page_mask << 8); - } - check_reason += ti->sram_virt; + check_reason = map_address(ti, + ntohs(readw(ti->mmio+ ACA_OFFSET+ACA_RW + WWCR_EVEN)), + &check_reason_page); SET_PAGE(check_reason_page); DPRINTK("Adapter check interrupt\n"); @@ -1517,23 +1517,20 @@ /* we assign the shared-ram address for ISA devices */ writeb(ti->sram_base, ti->mmio + ACA_OFFSET + ACA_RW + RRR_EVEN); #ifndef PCMCIA - ti->sram_virt = (u32)ioremap(((__u32)ti->sram_base << 12), ti->avail_shared_ram); + ti->sram_virt = ioremap(((__u32)ti->sram_base << 12), ti->avail_shared_ram); #endif - ti->init_srb = ntohs(readw(ti->mmio + ACA_OFFSET + WRBR_EVEN)); - if (ti->page_mask) { - ti->init_srb_page = (ti->init_srb >> 8) & ti->page_mask; - ti->init_srb &= ~(ti->page_mask << 8); - } - ti->init_srb += ti->sram_virt; + ti->init_srb = map_address(ti, + ntohs(readw(ti->mmio + ACA_OFFSET + WRBR_EVEN)), + &ti->init_srb_page); if (ti->page_mask && ti->avail_shared_ram == 127) { - int last_512 = 0xfe00, i; - int last_512_page=0; - last_512_page=(last_512>>8)&ti->page_mask; - last_512 &= ~(ti->page_mask << 8); + void __iomem *last_512; + __u8 last_512_page=0; + int i; + last_512 = map_address(ti, 0xfe00, &last_512_page); /* initialize high section of ram (if necessary) */ SET_PAGE(last_512_page); for (i = 0; i < 512; i++) - writeb(0, ti->sram_virt + last_512 + i); + writeb(0, last_512 + i); } SET_PAGE(ti->init_srb_page); @@ -1542,7 +1539,7 @@ int i; DPRINTK("ti->init_srb_page=0x%x\n", ti->init_srb_page); - DPRINTK("init_srb(%x):", (ti->init_srb) ); + DPRINTK("init_srb(%p):", ti->init_srb ); for (i = 0; i < 20; i++) printk("%02X ", (int) readb(ti->init_srb + i)); printk("\n"); @@ -1579,6 +1576,7 @@ struct trh_hdr *trhdr = (struct trh_hdr *) ti->current_skb->data; unsigned int hdr_len; __u32 dhb=0,dhb_base; + void __iomem *dhbuf = NULL; unsigned char xmit_command; int i,dhb_len=0x4000,src_len,src_offset; struct trllc *llc; @@ -1600,7 +1598,7 @@ dhb_page = (dhb_base >> 8) & ti->page_mask; dhb=dhb_base & ~(ti->page_mask << 8); } - dhb += ti->sram_virt; + dhbuf = ti->sram_virt + dhb; /* Figure out the size of the 802.5 header */ if (!(trhdr->saddr[0] & 0x80)) /* RIF present? */ @@ -1626,12 +1624,12 @@ writew(htons(0x11), ti->asb + FRAME_LENGTH_OFST); writeb(0x0e, ti->asb + HEADER_LENGTH_OFST); SET_PAGE(dhb_page); - writeb(AC, dhb); - writeb(LLC_FRAME, dhb + 1); + writeb(AC, dhbuf); + writeb(LLC_FRAME, dhbuf + 1); for (i = 0; i < TR_ALEN; i++) - writeb((int) 0x0FF, dhb + i + 2); + writeb((int) 0x0FF, dhbuf + i + 2); for (i = 0; i < TR_ALEN; i++) - writeb(0, dhb + i + TR_ALEN + 2); + writeb(0, dhbuf + i + TR_ALEN + 2); writeb(RESP_IN_ASB, ti->mmio + ACA_OFFSET + ACA_SET + ISRA_ODD); return; } @@ -1650,10 +1648,10 @@ dhb=dhb & ~(ti->page_mask << 8); dhb_len=0x4000-dhb; /* remaining size of this page */ } - dhb+=ti->sram_virt; + dhbuf = ti->sram_virt + dhb; SET_PAGE(dhb_page); if (src_len > dhb_len) { - memcpy_toio(dhb,&ti->current_skb->data[src_offset], + memcpy_toio(dhbuf,&ti->current_skb->data[src_offset], dhb_len); src_len -= dhb_len; src_offset += dhb_len; @@ -1661,7 +1659,7 @@ dhb=dhb_base; continue; } - memcpy_toio(dhb, &ti->current_skb->data[src_offset], src_len); + memcpy_toio(dhbuf, &ti->current_skb->data[src_offset], src_len); break; } writeb(RESP_IN_ASB, ti->mmio + ACA_OFFSET + ACA_SET + ISRA_ODD); @@ -1689,9 +1687,9 @@ static void tr_rx(struct net_device *dev) { struct tok_info *ti = (struct tok_info *) dev->priv; - __u32 rbuffer, rbufdata; + __u32 rbuffer; + void __iomem *rbuf, *rbufdata, *llc; __u8 rbuffer_page = 0; - __u32 llc; unsigned char *data; unsigned int rbuffer_len, lan_hdr_len, hdr_len, ip_len, length; unsigned char dlc_hdr_len; @@ -1705,11 +1703,7 @@ SET_PAGE(ti->arb_page); memcpy_fromio(&rarb, ti->arb, sizeof(rarb)); rbuffer = ntohs(rarb.rec_buf_addr) ; - if (ti->page_mask) { - rbuffer_page = (rbuffer >> 8) & ti->page_mask; - rbuffer &= ~(ti->page_mask << 8); - } - rbuffer += ti->sram_virt; + rbuf = map_address(ti, rbuffer, &rbuffer_page); SET_PAGE(ti->asb_page); @@ -1728,7 +1722,7 @@ hdr_len = lan_hdr_len + sizeof(struct trllc) + sizeof(struct iphdr); SET_PAGE(rbuffer_page); - llc = (rbuffer + offsetof(struct rec_buf, data) + lan_hdr_len); + llc = rbuf + offsetof(struct rec_buf, data) + lan_hdr_len; #if TR_VERBOSE DPRINTK("offsetof data: %02X lan_hdr_len: %02X\n", @@ -1759,9 +1753,7 @@ if (!IPv4_p) { - __u32 trhhdr; - - trhhdr = (rbuffer + offsetof(struct rec_buf, data)); + void __iomem *trhhdr = rbuf + offsetof(struct rec_buf, data); DPRINTK("Probably non-IP frame received.\n"); DPRINTK("ssap: %02X dsap: %02X " @@ -1793,8 +1785,8 @@ skb_put(skb, length); skb->dev = dev; data = skb->data; - rbuffer_len = ntohs(readw(rbuffer + offsetof(struct rec_buf, buf_len))); - rbufdata = rbuffer + offsetof(struct rec_buf, data); + rbuffer_len = ntohs(readw(rbuf + offsetof(struct rec_buf, buf_len))); + rbufdata = rbuf + offsetof(struct rec_buf, data); if (IPv4_p) { /* Copy the headers without checksumming */ @@ -1822,20 +1814,16 @@ data,lengthpage_mask) { - rbuffer_page = (rbuffer >> 8) & ti->page_mask; - rbuffer &= ~(ti->page_mask << 8); - } - rbuffer += ti->sram_virt; + rbuf = map_address(ti, rbuffer, &rbuffer_page); SET_PAGE(rbuffer_page); - rbuffer_len = ntohs(readw(rbuffer + BUFFER_LENGTH_OFST)); - rbufdata = rbuffer + offsetof(struct rec_buf, data); + rbuffer_len = ntohs(readw(rbuf + BUFFER_LENGTH_OFST)); + rbufdata = rbuf + offsetof(struct rec_buf, data); } SET_PAGE(ti->asb_page); diff -Nru a/drivers/net/tulip/interrupt.c b/drivers/net/tulip/interrupt.c --- a/drivers/net/tulip/interrupt.c 2005-03-09 12:20:51 -05:00 +++ b/drivers/net/tulip/interrupt.c 2005-03-09 12:20:51 -05:00 @@ -26,7 +26,7 @@ #define MIT_SIZE 15 #define MIT_TABLE 15 /* We use 0 or max */ -unsigned int mit_table[MIT_SIZE+1] = +static unsigned int mit_table[MIT_SIZE+1] = { /* CRS11 21143 hardware Mitigation Control Interrupt We use only RX mitigation we other techniques for diff -Nru a/drivers/net/tun.c b/drivers/net/tun.c --- a/drivers/net/tun.c 2005-03-09 12:20:51 -05:00 +++ b/drivers/net/tun.c 2005-03-09 12:20:51 -05:00 @@ -843,7 +843,7 @@ .set_rx_csum = tun_set_rx_csum }; -int __init tun_init(void) +static int __init tun_init(void) { int ret = 0; @@ -856,7 +856,7 @@ return ret; } -void tun_cleanup(void) +static void tun_cleanup(void) { struct tun_struct *tun, *nxt; diff -Nru a/drivers/net/via-rhine.c b/drivers/net/via-rhine.c --- a/drivers/net/via-rhine.c 2005-03-09 12:20:51 -05:00 +++ b/drivers/net/via-rhine.c 2005-03-09 12:20:51 -05:00 @@ -390,7 +390,7 @@ #ifdef USE_MMIO /* Registers we check that mmio and reg are the same. */ -int mmio_verify_registers[] = { +static const int mmio_verify_registers[] = { RxConfig, TxConfig, IntrEnable, ConfigA, ConfigB, ConfigC, ConfigD, 0 }; diff -Nru a/drivers/net/via-velocity.c b/drivers/net/via-velocity.c --- a/drivers/net/via-velocity.c 2005-03-09 12:20:51 -05:00 +++ b/drivers/net/via-velocity.c 2005-03-09 12:20:51 -05:00 @@ -3096,7 +3096,7 @@ * we are interested in. */ -u16 wol_calc_crc(int size, u8 * pattern, u8 *mask_pattern) +static u16 wol_calc_crc(int size, u8 * pattern, u8 *mask_pattern) { u16 crc = 0xFFFF; u8 mask; diff -Nru a/drivers/net/wan/cosa.c b/drivers/net/wan/cosa.c --- a/drivers/net/wan/cosa.c 2005-03-09 12:20:51 -05:00 +++ b/drivers/net/wan/cosa.c 2005-03-09 12:20:51 -05:00 @@ -543,7 +543,7 @@ * FIXME: When this code is not used as module, we should * probably call udelay() instead of the interruptible sleep. */ - current->state = TASK_INTERRUPTIBLE; + set_current_state(TASK_INTERRUPTIBLE); cosa_putstatus(cosa, SR_TX_INT_ENA); schedule_timeout(30); irq = probe_irq_off(irqs); @@ -1564,8 +1564,7 @@ cosa_getdata8(cosa); cosa_putstatus(cosa, SR_RST); #ifdef MODULE - current->state = TASK_INTERRUPTIBLE; - schedule_timeout(HZ/2); + msleep(500); #else udelay(5*100000); #endif @@ -1618,7 +1617,7 @@ return r; } /* sleep if not ready to read */ - current->state = TASK_INTERRUPTIBLE; + set_current_state(TASK_INTERRUPTIBLE); schedule_timeout(1); } printk(KERN_INFO "cosa: timeout in get_wait_data (status 0x%x)\n", diff -Nru a/drivers/net/wd.c b/drivers/net/wd.c --- a/drivers/net/wd.c 2005-03-09 12:20:51 -05:00 +++ b/drivers/net/wd.c 2005-03-09 12:20:51 -05:00 @@ -131,6 +131,7 @@ { free_irq(dev->irq, dev); release_region(dev->base_addr - WD_NIC_OFFSET, WD_IO_EXTENT); + iounmap(ei_status.mem); } #ifndef MODULE @@ -317,16 +318,22 @@ ei_status.rx_start_page = WD_START_PG + TX_PAGES; /* Don't map in the shared memory until the board is actually opened. */ - ei_status.rmem_start = dev->mem_start + TX_PAGES*256; /* Some cards (eg WD8003EBT) can be jumpered for more (32k!) memory. */ if (dev->mem_end != 0) { ei_status.stop_page = (dev->mem_end - dev->mem_start)/256; + ei_status.priv = dev->mem_end - dev->mem_start; } else { ei_status.stop_page = word16 ? WD13_STOP_PG : WD03_STOP_PG; dev->mem_end = dev->mem_start + (ei_status.stop_page - WD_START_PG)*256; + ei_status.priv = (ei_status.stop_page - WD_START_PG)*256; + } + + ei_status.mem = ioremap(dev->mem_start, ei_status.priv); + if (!ei_status.mem) { + free_irq(dev->irq, dev); + return -ENOMEM; } - ei_status.rmem_end = dev->mem_end; printk(" %s, IRQ %d, shared memory at %#lx-%#lx.\n", model_name, dev->irq, dev->mem_start, dev->mem_end-1); @@ -397,7 +404,7 @@ { int wd_cmdreg = dev->base_addr - WD_NIC_OFFSET; /* WD_CMDREG */ - unsigned long hdr_start = dev->mem_start + ((ring_page - WD_START_PG)<<8); + void __iomem *hdr_start = ei_status.mem + ((ring_page - WD_START_PG)<<8); /* We'll always get a 4 byte header read followed by a packet read, so we enable 16 bit mode before the header, and disable after the body. */ @@ -407,10 +414,10 @@ #ifdef __BIG_ENDIAN /* Officially this is what we are doing, but the readl() is faster */ /* unfortunately it isn't endian aware of the struct */ - isa_memcpy_fromio(hdr, hdr_start, sizeof(struct e8390_pkt_hdr)); + memcpy_fromio(hdr, hdr_start, sizeof(struct e8390_pkt_hdr)); hdr->count = le16_to_cpu(hdr->count); #else - ((unsigned int*)hdr)[0] = isa_readl(hdr_start); + ((unsigned int*)hdr)[0] = readl(hdr_start); #endif } @@ -423,17 +430,18 @@ wd_block_input(struct net_device *dev, int count, struct sk_buff *skb, int ring_offset) { int wd_cmdreg = dev->base_addr - WD_NIC_OFFSET; /* WD_CMDREG */ - unsigned long xfer_start = dev->mem_start + ring_offset - (WD_START_PG<<8); + unsigned long offset = ring_offset - (WD_START_PG<<8); + void __iomem *xfer_start = ei_status.mem + offset; - if (xfer_start + count > ei_status.rmem_end) { + if (offset + count > ei_status.priv) { /* We must wrap the input move. */ - int semi_count = ei_status.rmem_end - xfer_start; - isa_memcpy_fromio(skb->data, xfer_start, semi_count); + int semi_count = ei_status.priv - offset; + memcpy_fromio(skb->data, xfer_start, semi_count); count -= semi_count; - isa_memcpy_fromio(skb->data + semi_count, ei_status.rmem_start, count); + memcpy_fromio(skb->data + semi_count, ei_status.mem + TX_PAGES * 256, count); } else { /* Packet is in one chunk -- we can copy + cksum. */ - isa_eth_io_copy_and_sum(skb, xfer_start, count, 0); + eth_io_copy_and_sum(skb, xfer_start, count, 0); } /* Turn off 16 bit access so that reboot works. ISA brain-damage */ @@ -446,16 +454,16 @@ int start_page) { int wd_cmdreg = dev->base_addr - WD_NIC_OFFSET; /* WD_CMDREG */ - long shmem = dev->mem_start + ((start_page - WD_START_PG)<<8); + void __iomem *shmem = ei_status.mem + ((start_page - WD_START_PG)<<8); if (ei_status.word16) { /* Turn on and off 16 bit access so that reboot works. */ outb(ISA16 | ei_status.reg5, wd_cmdreg+WD_CMDREG5); - isa_memcpy_toio(shmem, buf, count); + memcpy_toio(shmem, buf, count); outb(ei_status.reg5, wd_cmdreg+WD_CMDREG5); } else - isa_memcpy_toio(shmem, buf, count); + memcpy_toio(shmem, buf, count); } diff -Nru a/drivers/net/wireless/airo.c b/drivers/net/wireless/airo.c --- a/drivers/net/wireless/airo.c 2005-03-09 12:20:51 -05:00 +++ b/drivers/net/wireless/airo.c 2005-03-09 12:20:51 -05:00 @@ -1698,9 +1698,8 @@ issuecommand(ai, &cmd, &rsp); up(&ai->sem); /* Let the command take effect */ - set_current_state (TASK_INTERRUPTIBLE); ai->task = current; - schedule_timeout (3*HZ); + ssleep(3); ai->task = NULL; } rc = PC4500_readrid(ai, first ? RID_BSSLISTFIRST : RID_BSSLISTNEXT, @@ -2685,11 +2684,9 @@ return -1; waitbusy (ai); OUT4500(ai,COMMAND,CMD_SOFTRESET); - set_current_state (TASK_UNINTERRUPTIBLE); - schedule_timeout (HZ/5); + msleep(200); waitbusy (ai); - set_current_state (TASK_UNINTERRUPTIBLE); - schedule_timeout (HZ/5); + msleep(200); if (lock) up(&ai->sem); return 0; @@ -5516,12 +5513,12 @@ } else { OUT4500(ai, EVACK, EV_AWAKEN); OUT4500(ai, EVACK, EV_AWAKEN); - schedule_timeout(HZ/10); + msleep(100); } set_bit (FLAG_COMMIT, &ai->flags); disable_MAC(ai, 0); - schedule_timeout (HZ/5); + msleep(200); if (ai->SSID) { writeSsidRid(ai, ai->SSID, 0); kfree(ai->SSID); @@ -7470,8 +7467,7 @@ OUT4500(ai,COMMAND,CMD_SOFTRESET); - set_current_state (TASK_UNINTERRUPTIBLE); - schedule_timeout (HZ); /* WAS 600 12/7/00 */ + ssleep(1); /* WAS 600 12/7/00 */ if(!waitbusy (ai)){ printk(KERN_INFO "Waitbusy hang AFTER RESET\n"); @@ -7498,8 +7494,7 @@ OUT4500(ai, SWS3, FLASH_COMMAND); OUT4500(ai, COMMAND,0); } - set_current_state (TASK_UNINTERRUPTIBLE); - schedule_timeout (HZ/2); /* 500ms delay */ + msleep(500); /* 500ms delay */ if(!waitbusy(ai)) { clear_bit (FLAG_FLASHING, &ai->flags); @@ -7609,8 +7604,7 @@ int flashrestart(struct airo_info *ai,struct net_device *dev){ int i,status; - set_current_state (TASK_UNINTERRUPTIBLE); - schedule_timeout (HZ); /* Added 12/7/00 */ + ssleep(1); /* Added 12/7/00 */ clear_bit (FLAG_FLASHING, &ai->flags); if (test_bit(FLAG_MPI, &ai->flags)) { status = mpi_init_descriptors(ai); @@ -7625,8 +7619,7 @@ ( ai, 2312, i >= MAX_FIDS / 2 ); } - set_current_state (TASK_UNINTERRUPTIBLE); - schedule_timeout (HZ); /* Added 12/7/00 */ + ssleep(1); /* Added 12/7/00 */ return status; } #endif /* CISCO_EXT */ diff -Nru a/drivers/net/wireless/prism54/isl_ioctl.c b/drivers/net/wireless/prism54/isl_ioctl.c --- a/drivers/net/wireless/prism54/isl_ioctl.c 2005-03-09 12:20:51 -05:00 +++ b/drivers/net/wireless/prism54/isl_ioctl.c 2005-03-09 12:20:51 -05:00 @@ -1750,7 +1750,7 @@ u8 wpa_ie[MAX_WPA_IE_LEN]; int wpa_ie_len; size_t len = 0; /* u16, better? */ - u8 *payload = 0, *pos = 0; + u8 *payload = NULL, *pos = NULL; int ret; /* I think all trapable objects are listed here. diff -Nru a/drivers/net/wireless/ray_cs.c b/drivers/net/wireless/ray_cs.c --- a/drivers/net/wireless/ray_cs.c 2005-03-09 12:20:51 -05:00 +++ b/drivers/net/wireless/ray_cs.c 2005-03-09 12:20:51 -05:00 @@ -1215,6 +1215,9 @@ #if WIRELESS_EXT > 7 struct iwreq *wrq = (struct iwreq *) ifr; #endif /* WIRELESS_EXT > 7 */ +#ifdef WIRELESS_SPY + struct sockaddr address[IW_MAX_SPY]; +#endif /* WIRELESS_SPY */ if (!(link->state & DEV_PRESENT)) { DEBUG(2,"ray_dev_ioctl - device not present\n"); @@ -1511,7 +1514,6 @@ /* If there is some addresses to copy */ if(local->spy_number > 0) { - struct sockaddr address[IW_MAX_SPY]; int i; /* Copy addresses to the driver */ @@ -1551,7 +1553,6 @@ /* If the user want to have the addresses back... */ if((local->spy_number > 0) && (wrq->u.data.pointer != (caddr_t) 0)) { - struct sockaddr address[IW_MAX_SPY]; int i; /* Copy addresses from the lp structure */ diff -Nru a/drivers/net/wireless/strip.c b/drivers/net/wireless/strip.c --- a/drivers/net/wireless/strip.c 2005-03-09 12:20:51 -05:00 +++ b/drivers/net/wireless/strip.c 2005-03-09 12:20:51 -05:00 @@ -876,7 +876,7 @@ */ static int strip_change_mtu(struct net_device *dev, int new_mtu) { - struct strip *strip_info = dev->priv; + struct strip *strip_info = netdev_priv(dev); int old_mtu = strip_info->mtu; unsigned char *orbuff = strip_info->rx_buff; unsigned char *osbuff = strip_info->sx_buff; @@ -1563,7 +1563,7 @@ /* Encapsulate a datagram and kick it into a TTY queue. */ static int strip_xmit(struct sk_buff *skb, struct net_device *dev) { - struct strip *strip_info = (struct strip *) (dev->priv); + struct strip *strip_info = netdev_priv(dev); if (!netif_running(dev)) { printk(KERN_ERR "%s: xmit call when iface is down\n", @@ -1639,7 +1639,7 @@ unsigned short type, void *daddr, void *saddr, unsigned len) { - struct strip *strip_info = (struct strip *) (dev->priv); + struct strip *strip_info = netdev_priv(dev); STRIP_Header *header = (STRIP_Header *) skb_push(skb, sizeof(STRIP_Header)); /*printk(KERN_INFO "%s: strip_header 0x%04X %s\n", dev->name, type, @@ -1648,7 +1648,7 @@ header->src_addr = strip_info->true_dev_addr; header->protocol = htons(type); - /*HexDump("strip_header", (struct strip *)(dev->priv), skb->data, skb->data + skb->len); */ + /*HexDump("strip_header", netdev_priv(dev), skb->data, skb->data + skb->len); */ if (!daddr) return (-dev->hard_header_len); @@ -2400,7 +2400,7 @@ static int strip_set_mac_address(struct net_device *dev, void *addr) { - struct strip *strip_info = (struct strip *) (dev->priv); + struct strip *strip_info = netdev_priv(dev); struct sockaddr *sa = addr; printk(KERN_INFO "%s: strip_set_dev_mac_address called\n", dev->name); set_mac_address(strip_info, (MetricomAddress *) sa->sa_data); @@ -2409,8 +2409,8 @@ static struct net_device_stats *strip_get_stats(struct net_device *dev) { + struct strip *strip_info = netdev_priv(dev); static struct net_device_stats stats; - struct strip *strip_info = (struct strip *) (dev->priv); memset(&stats, 0, sizeof(struct net_device_stats)); @@ -2454,7 +2454,7 @@ static int strip_open_low(struct net_device *dev) { - struct strip *strip_info = (struct strip *) (dev->priv); + struct strip *strip_info = netdev_priv(dev); if (strip_info->tty == NULL) return (-ENODEV); @@ -2487,7 +2487,7 @@ static int strip_close_low(struct net_device *dev) { - struct strip *strip_info = (struct strip *) (dev->priv); + struct strip *strip_info = netdev_priv(dev); if (strip_info->tty == NULL) return -EBUSY; diff -Nru a/include/linux/dp83840.h b/include/linux/dp83840.h --- a/include/linux/dp83840.h 2005-03-09 12:20:51 -05:00 +++ /dev/null Wed Dec 31 16:00:00 196900 @@ -1,41 +0,0 @@ -/* - * linux/dp83840.h: definitions for DP83840 MII-compatible transceivers - * - * Copyright (C) 1996, 1999 David S. Miller (davem@redhat.com) - */ -#ifndef __LINUX_DP83840_H -#define __LINUX_DP83840_H - -#include - -/* - * Data sheets and programming docs for the DP83840 are available at - * from http://www.national.com/ - * - * The DP83840 is capable of both 10 and 100Mbps ethernet, in both - * half and full duplex mode. It also supports auto negotiation. - * - * But.... THIS THING IS A PAIN IN THE ASS TO PROGRAM! - * Debugging eeprom burnt code is more fun than programming this chip! - */ - -/* First, the MII register numbers (actually DP83840 register numbers). */ -#define MII_CSCONFIG 0x17 /* CS configuration */ - -/* The Carrier Sense config register. */ -#define CSCONFIG_RESV1 0x0001 /* Unused... */ -#define CSCONFIG_LED4 0x0002 /* Pin for full-dplx LED4 */ -#define CSCONFIG_LED1 0x0004 /* Pin for conn-status LED1 */ -#define CSCONFIG_RESV2 0x0008 /* Unused... */ -#define CSCONFIG_TCVDISAB 0x0010 /* Turns off the transceiver */ -#define CSCONFIG_DFBYPASS 0x0020 /* Bypass disconnect function */ -#define CSCONFIG_GLFORCE 0x0040 /* Good link force for 100mbps */ -#define CSCONFIG_CLKTRISTATE 0x0080 /* Tristate 25m clock */ -#define CSCONFIG_RESV3 0x0700 /* Unused... */ -#define CSCONFIG_ENCODE 0x0800 /* 1=MLT-3, 0=binary */ -#define CSCONFIG_RENABLE 0x1000 /* Repeater mode enable */ -#define CSCONFIG_TCDISABLE 0x2000 /* Disable timeout counter */ -#define CSCONFIG_RESV4 0x4000 /* Unused... */ -#define CSCONFIG_NDISABLE 0x8000 /* Disable NRZI */ - -#endif /* __LINUX_DP83840_H */ diff -Nru a/include/linux/ibmtr.h b/include/linux/ibmtr.h --- a/include/linux/ibmtr.h 2005-03-09 12:20:51 -05:00 +++ b/include/linux/ibmtr.h 2005-03-09 12:20:51 -05:00 @@ -169,7 +169,7 @@ struct tok_info { unsigned char irq; - void *mmio; + void __iomem *mmio; unsigned char hw_address[32]; unsigned char adapter_type; unsigned char data_rate; @@ -192,12 +192,13 @@ /* Additions by Peter De Schrijver */ unsigned char page_mask; /* mask to select RAM page to Map*/ unsigned char mapped_ram_size; /* size of RAM page */ - __u32 sram_virt; /* Shared memory base address */ - __u32 init_srb; /* Initial System Request Block address */ - __u32 srb; /* System Request Block address */ - __u32 ssb; /* System Status Block address */ - __u32 arb; /* Adapter Request Block address */ - __u32 asb; /* Adapter Status Block address */ + __u32 sram_phys; /* Shared memory base address */ + void __iomem *sram_virt; /* Shared memory base address */ + void __iomem *init_srb; /* Initial System Request Block address */ + void __iomem *srb; /* System Request Block address */ + void __iomem *ssb; /* System Status Block address */ + void __iomem *arb; /* Adapter Request Block address */ + void __iomem *asb; /* Adapter Status Block address */ __u8 init_srb_page; __u8 srb_page; __u8 ssb_page; diff -Nru a/include/net/slhc_vj.h b/include/net/slhc_vj.h --- a/include/net/slhc_vj.h 2005-03-09 12:20:51 -05:00 +++ b/include/net/slhc_vj.h 2005-03-09 12:20:51 -05:00 @@ -185,7 +185,4 @@ int isize)); int slhc_toss __ARGS((struct slcompress *comp)); -void slhc_i_status __ARGS((struct slcompress *comp)); -void slhc_o_status __ARGS((struct slcompress *comp)); - #endif /* _SLHC_H */ --------------000406070700040303060608-- From afleming@freescale.com Wed Mar 9 09:24:47 2005 Received: with ECARTIS (v1.0.0; list netdev); Wed, 09 Mar 2005 09:24:52 -0800 (PST) Received: from az33egw02.freescale.net (az33egw02.freescale.net [192.88.158.103]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j29HOl6j020955 for ; Wed, 9 Mar 2005 09:24:47 -0800 Received: from az33smr01.freescale.net (az33smr01.freescale.net [10.64.34.199]) by az33egw02.freescale.net (8.12.11/az33egw02) with ESMTP id j29HQ3s2026340; Wed, 9 Mar 2005 10:26:03 -0700 (MST) Received: from [10.82.17.56] ([10.82.17.56]) by az33smr01.freescale.net (8.13.1/8.13.0) with ESMTP id j29HQ7fL003342; Wed, 9 Mar 2005 11:26:08 -0600 (CST) In-Reply-To: <1110340214.32524.32.camel@gaston> References: <1107b64b01fb8e9a6c84359bb56881a6@freescale.com> <1110334456.32556.21.camel@gaston> <20050308194229.41c23707.davem@davemloft.net> <1110340214.32524.32.camel@gaston> Mime-Version: 1.0 (Apple Message framework v619.2) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <57a429f8eb807987d88b06129861d507@freescale.com> Content-Transfer-Encoding: 7bit Cc: netdev@oss.sgi.com, "David S. Miller" , linuxppc-embedded@ozlabs.org From: Andy Fleming Subject: Re: RFC: PHY Abstraction Layer II Date: Wed, 9 Mar 2005 11:24:44 -0600 To: Benjamin Herrenschmidt X-Mailer: Apple Mail (2.619.2) X-Virus-Scanned: ClamAV 0.83/757/Tue Mar 8 15:14:36 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 2710 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: afleming@freescale.com Precedence: bulk X-list: netdev Content-Length: 1457 Lines: 37 On Mar 8, 2005, at 21:50, Benjamin Herrenschmidt wrote: > On Tue, 2005-03-08 at 19:42 -0800, David S. Miller wrote: >> On Wed, 09 Mar 2005 13:14:16 +1100 >> Benjamin Herrenschmidt wrote: >> >>> I'll have a closer look when I find some time, see if it makes sense >>> to >>> adapt sungem or not. >> >> Especially because of the Broadcom PHYs I bet it doesn't. >> >> Too many chips have to reset the MAC, or do other fancy stuff >> when programming the PHY to make this genphy thing very useful. > > Oh, I think genphy is just a generic driver, but his layer has hooks > for > other PHY drivers (wasn't it based on sungem_phy in the first place ?) Definitely. Much of this code was culled from the sungem and ibm_emac drivers, with some input from mii.c. The genphy driver is just one of the 6 PHY drivers in the patch I sent (the others are Marvell, Davicom, Cicada, QS, LXT). Actually, several of those files have multiple drivers in them. The genphy driver is the fallback driver. It exists for those PHYs which never get a driver, but don't need special attention. > > I discussed several steps of the design with Andy, the idea was to have > something a bit like sungem_phy.c with addditional common library for > doing the link polling & fallback stuff etc... that could be easily > shared by drivers. Yup. I look forward to your input on how well the code meshes with what people need for their drivers. From shemminger@osdl.org Wed Mar 9 09:26:18 2005 Received: with ECARTIS (v1.0.0; list netdev); Wed, 09 Mar 2005 09:26:23 -0800 (PST) Received: from smtp.osdl.org (fire.osdl.org [65.172.181.4]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j29HQIX4021466 for ; Wed, 9 Mar 2005 09:26:18 -0800 Received: from shell0.pdx.osdl.net (fw.osdl.org [65.172.181.6]) by smtp.osdl.org (8.12.8/8.12.8) with ESMTP id j29HQBqi007080 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO); Wed, 9 Mar 2005 09:26:12 -0800 Received: from dxpl.pdx.osdl.net (dxpl.pdx.osdl.net [172.20.1.103]) by shell0.pdx.osdl.net (8.13.1/8.11.6) with ESMTP id j29HQBEH007617; Wed, 9 Mar 2005 09:26:11 -0800 Date: Wed, 9 Mar 2005 09:26:28 -0800 From: Stephen Hemminger To: "David S. Miller" Cc: netdev@oss.sgi.com Subject: [PATCH] rearrange netdevice structure to save space Message-ID: <20050309092628.3c9014db@dxpl.pdx.osdl.net> Organization: Open Source Development Lab X-Mailer: Sylpheed-Claws 1.0.1 (GTK+ 1.2.10; x86_64-unknown-linux-gnu) X-Face: &@E+xe?c%:&e4D{>f1O<&U>2qwRREG5!}7R4;D<"NO^UI2mJ[eEOA2*3>(`Th.yP,VDPo9$ /`~cw![cmj~~jWe?AHY7D1S+\}5brN0k*NE?pPh_'_d>6;XGG[\KDRViCfumZT3@[ Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Received-SPF: pass (domain of shemminger@osdl.org designates 65.172.181.6 as permitted sender) X-MIMEDefang-Filter: osdl$Revision: 1.104 $ X-Scanned-By: MIMEDefang 2.36 X-Virus-Scanned: ClamAV 0.83/757/Tue Mar 8 15:14:36 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 2711 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: shemminger@osdl.org Precedence: bulk X-list: netdev Content-Length: 1104 Lines: 28 Trivial reordering of netdevice structure to save four bytes. Signed-off-by: Stephen Hemminger diff -Nru a/include/linux/netdevice.h b/include/linux/netdevice.h --- a/include/linux/netdevice.h 2005-03-09 09:04:56 -08:00 +++ b/include/linux/netdevice.h 2005-03-09 09:04:56 -08:00 @@ -328,9 +328,7 @@ unsigned short flags; /* interface flags (a la BSD) */ unsigned short gflags; unsigned short priv_flags; /* Like 'flags' but invisible to userspace. */ - unsigned short unused_alignment_fixer; /* Because we need priv_flags, - * and we want to be 32-bit aligned. - */ + unsigned short padded; /* How much padding added by alloc_netdev() */ unsigned mtu; /* interface MTU value */ unsigned short type; /* interface hardware type */ @@ -487,8 +485,6 @@ /* class/net/name entry */ struct class_device class_dev; - /* how much padding had been added by alloc_netdev() */ - int padded; }; #define NETDEV_ALIGN 32 From steve.iribarne@dilithiumnetworks.com Wed Mar 9 09:33:56 2005 Received: with ECARTIS (v1.0.0; list netdev); Wed, 09 Mar 2005 09:34:00 -0800 (PST) Received: from DHOST001-17.DEX001.intermedia.net (dhost001-17.intermedia.net [64.78.61.64]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j29HXrVT022188 for ; Wed, 9 Mar 2005 09:33:56 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Subject: RE: Do you know the TCP stack? (127.x.x.x routing) Date: Wed, 9 Mar 2005 09:33:52 -0800 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Do you know the TCP stack? (127.x.x.x routing) Thread-Index: AcUkwR1ChgCnSVXeQ+eNcxdZryx9/gACINlQ From: "Steve Iribarne" To: Cc: "Henrik Nordstrom" , "Martin Mares" , "Zdenek Radouch" , "Eran Mann" , "Thomas Graf" , "Andi Kleen" , , X-Virus-Scanned: ClamAV 0.83/757/Tue Mar 8 15:14:36 2005 on oss.sgi.com X-Virus-Status: Clean Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by oss.sgi.com id j29HXrVT022188 X-archive-position: 2712 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: steve.iribarne@dilithiumnetworks.com Precedence: bulk X-list: netdev Content-Length: 3343 Lines: 100 -> Your blades --> VLANX/SubnetX -> --> [some L3 switch] umm.. I have a L2 switch... not L3 switch. -> Read what i wrote again and cross reference with the diagram. ARP is -> only L2 switched. It would be wise to configure the blade IP addresses -> to be within the same subnet - in which case the only route you need on -> your blades is a link scope one and perhaps a default GW pointing to -> your L3 device. -> L2 device. > -> Its just a matter of time before you say "oh, thats what i do now for -> 127.x". This is the point i have been trying to make all along. -> -> > -> So tell me what i am missing! -> > -> -> > -> > Experience. -> -> I think you are making some very big assumption ;-> Please dont go this -> path unless you wish to end this thread. -> Ok. I won't. -> Btw, i do believe what you and Zdenek are trying to solve are _very_ -> different problems. He is trying to build a distributed router of some -> form; i.e his blades are infact line-cards where traffic comes in. -> You on the other hand seem to have the blades doing computes (i.e they -> are not router line cards). Nope. I'm in a very similar situation. I don't have "line-cards" per-se. Not like xDSL or the type of line cards I've worked on in the past, but my boards **DO** have both mgmt traffic and network traffic coming into them. I have signaling traffic, bearer traffic and network mgmt traffic. Very much the same. I have basically 5 VLANS setup. 4 of which get tagged at the switch so that when the packets come inside the chassis, I know how to handle them. 1 of the VLANS is for mgmt communication. Like I said, it works great. The 127.xx net I will NEVER need to talk to outside of my chassis and when I do chassis to chassis redundancy I use a different scheme. So I will never run into the "gee, someone else is using the 127.xx net" because as long as my applications know how to get to the 127.xx net the traffic will be sent to the proper ports and get tagged with the proper vlan ID. I wish my setup was easy enough to just draw a quick picture. But it aint, sorry. -> -> The point is this: Whatever you folks are doing, probably inherited from -> some other projects more than likely using some other OS is not -> necessary in Linux. I respect your desire to use those addresses if it -> makes you comfortable - I just vehemently disagree it is needed. Nope. Wrote the project from scratch using Embedded Linux. Again, if you can show me a way of doing this, I'm all ears, but so far, you haven't shown me any other way around it. Believe me. I've tried and tried to find another solution to this problem. And I can't emphasis enough that telling a customer, "Pick a network address range that I can use" is NOT, I have to repeat, NOT a solution. The will NEVER NEVER NEVER go for it. Maybe your customers will but mine wont. My customers are RBOCs and the like. Anyone dealing with them knows what I am talking about. -> So i hope you dont show up with the patch and ask for its inclusion. -> Nope. Never will. I don't think the big boys (Alan Cox, Linus and the like) would never let it happen because there is no RFC on it. There will be someday. I do know that there are ideas floating around right now that will soon become the beginnings of the RFC. -> cheers, -> jamal From maxk@qualcomm.com Wed Mar 9 09:37:54 2005 Received: with ECARTIS (v1.0.0; list netdev); Wed, 09 Mar 2005 09:38:01 -0800 (PST) Received: from ithilien.qualcomm.com (ithilien.qualcomm.com [129.46.51.59]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j29Hbr4s022741 for ; Wed, 9 Mar 2005 09:37:54 -0800 Received: from magus.qualcomm.com (magus.qualcomm.com [129.46.61.148]) by ithilien.qualcomm.com (8.12.10/8.12.5/1.0) with ESMTP id j29HZgXO005685; Wed, 9 Mar 2005 09:35:42 -0800 (PST) Received: from [129.46.90.158] (workie.qualcomm.com [129.46.90.158]) by magus.qualcomm.com (8.12.10/8.12.5/1.0) with ESMTP id j29HZbfX014355; Wed, 9 Mar 2005 09:35:39 -0800 (PST) Message-ID: <422F33E9.4030401@qualcomm.com> Date: Wed, 09 Mar 2005 09:35:37 -0800 From: Max Krasnyansky User-Agent: Mozilla Thunderbird 0.9 (X11/20041127) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Arnaldo Carvalho de Melo CC: marcel@holtmann.org, davem@davemloft.net, netdev@oss.sgi.com Subject: Re: [PATCH][BLUETOOTH] kill bt_sock_alloc References: <20050308094937.GA9468@conectiva.com.br> <20050308095209.GB9468@conectiva.com.br> In-Reply-To: <20050308095209.GB9468@conectiva.com.br> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-PMX-Version: 4.7.0.111621 X-Virus-Scanned: ClamAV 0.83/757/Tue Mar 8 15:14:36 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 2713 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: maxk@qualcomm.com Precedence: bulk X-list: netdev Content-Length: 410 Lines: 17 Arnaldo Carvalho de Melo wrote: > Em Tue, Mar 08, 2005 at 06:49:37AM -0300, Arnaldo Carvalho de Melo escreveu: > >>Hi, >> >> Please take a look and if acceptable pull from: >> >>bk://kernel.bkbits.net/acme/connection_sock-2.6 > > > Sorry, now with the patch attached. Looks good to me. Marcel I'd suggest for you to apply this patch. It helps in reducing overall size of the socket structures. Thanks Max From arnaldo.melo@gmail.com Wed Mar 9 09:44:07 2005 Received: with ECARTIS (v1.0.0; list netdev); Wed, 09 Mar 2005 09:44:11 -0800 (PST) Received: from wproxy.gmail.com (wproxy.gmail.com [64.233.184.199]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j29Hi6UY023380 for ; Wed, 9 Mar 2005 09:44:06 -0800 Received: by wproxy.gmail.com with SMTP id 71so142550wri for ; Wed, 09 Mar 2005 09:43:58 -0800 (PST) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:reply-to:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:references; b=D8tBlGCblFnS2GOze7OaDLwArecVFgvsf30kb8mkiWyujjRMW6W9BIWOpdMRfaTi4rzGN2gk8RjJpFMQGfLrWESYEFIhm6sXDushKal7afMQHRUJ6iuu9IlaPpBvkiYmLwtaAyLd2w49oc9aa5qEERApO2C03nwI/ebjMPnCCsU= Received: by 10.54.84.17 with SMTP id h17mr123411wrb; Wed, 09 Mar 2005 09:43:55 -0800 (PST) Received: by 10.54.10.49 with HTTP; Wed, 9 Mar 2005 09:43:54 -0800 (PST) Message-ID: <39e6f6c7050309094379d155e@mail.gmail.com> Date: Wed, 9 Mar 2005 14:43:54 -0300 From: Arnaldo Carvalho de Melo Reply-To: acme@conectiva.com.br To: Max Krasnyansky Subject: Re: [PATCH][BLUETOOTH] kill bt_sock_alloc Cc: marcel@holtmann.org, davem@davemloft.net, netdev@oss.sgi.com In-Reply-To: <422F33E9.4030401@qualcomm.com> Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit References: <20050308094937.GA9468@conectiva.com.br> <20050308095209.GB9468@conectiva.com.br> <422F33E9.4030401@qualcomm.com> X-Virus-Scanned: ClamAV 0.83/757/Tue Mar 8 15:14:36 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 2714 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: arnaldo.melo@gmail.com Precedence: bulk X-list: netdev Content-Length: 907 Lines: 26 On Wed, 09 Mar 2005 09:35:37 -0800, Max Krasnyansky wrote: > Arnaldo Carvalho de Melo wrote: > > Em Tue, Mar 08, 2005 at 06:49:37AM -0300, Arnaldo Carvalho de Melo escreveu: > > > >>Hi, > >> > >> Please take a look and if acceptable pull from: > >> > >>bk://kernel.bkbits.net/acme/connection_sock-2.6 > > > > > > Sorry, now with the patch attached. > > Looks good to me. Marcel I'd suggest for you to apply this patch. > It helps in reducing overall size of the socket structures. Please note that there are further space savings to tap into in the bt_sock class hierarchy, as not all of the bt_sock descendants needs things like bt_sock::accept_q, etc And when the "kill sk_protinfo" series is finished, there will be further space savings, as the same bt_sock descendants that don't use accept_q will not need to have struct connection_sock in its definition. -- - Arnaldo From oxymoron@waste.org Wed Mar 9 09:53:03 2005 Received: with ECARTIS (v1.0.0; list netdev); Wed, 09 Mar 2005 09:53:07 -0800 (PST) Received: from waste.org (waste.org [216.27.176.166]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j29Hr3fK024343 for ; Wed, 9 Mar 2005 09:53:03 -0800 Received: from waste.org (localhost [127.0.0.1]) by waste.org (8.13.2/8.13.2/Debian-1) with ESMTP id j29Hq9Hf022342 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Wed, 9 Mar 2005 11:52:09 -0600 Received: (from oxymoron@localhost) by waste.org (8.13.2/8.13.2/Submit) id j29Hq9mq022339; Wed, 9 Mar 2005 11:52:09 -0600 Date: Wed, 9 Mar 2005 09:52:09 -0800 From: Matt Mackall To: jamal Cc: Zdenek Radouch , Henrik Nordstrom , Martin Mares , Eran Mann , Thomas Graf , Andi Kleen , netdev@oss.sgi.com, linux-net@vger.kernel.org Subject: Re: Do you know the TCP stack? (127.x.x.x routing) Message-ID: <20050309175209.GX3163@waste.org> References: <1110288879.1050.167.camel@jzny.localdomain> <20050308135134.GA20607@atrey.karlin.mff.cuni.cz> <1110290300.1050.190.camel@jzny.localdomain> <20050308140301.GC20607@atrey.karlin.mff.cuni.cz> <1110291470.1043.211.camel@jzny.localdomain> <1110316631.1084.57.camel@jzny.localdomain> <1110377889.1090.124.camel@jzny.localdomain> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1110377889.1090.124.camel@jzny.localdomain> User-Agent: Mutt/1.5.6+20040907i X-Virus-Scanned: ClamAV 0.83/757/Tue Mar 8 15:14:36 2005 on oss.sgi.com X-Virus-Scanned: by amavisd-new X-Virus-Status: Clean X-archive-position: 2715 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: mpm@selenic.com Precedence: bulk X-list: netdev Content-Length: 1840 Lines: 40 On Wed, Mar 09, 2005 at 09:18:10AM -0500, jamal wrote: > On Wed, 2005-03-09 at 08:39, Zdenek Radouch wrote: > > At 07:39 AM 3/9/05 -0500, jamal wrote: > > [..] > > Imagine a simple gateway, connecting two parts of your company > > - the east > > interface connects to a corporate net with a default gateway, the west net > > is the software dept. net. Now imagine that you give your internal line card > > in this simple gateway a "_whatever_" address, say 18.7.22.69. > > Your gateway now has a route 18.7.22.69/32 -> dev linecard > > Now please tell me what happens when a guy on the west net tries > > to check his MIT evening class schedule. > > Are we still talking about the same problem? The linecards addresses and > interconnect interfaces are "internal". They are never advertised/seen > outside of the chasis. So if you choose 18.7.22.69/32 to use internally > you make sure it is never advertised to the outside world as belonging > to you. If you have to advertise it or actually know it is used, then > you must deal with the conflict. Jamal, he's building a router. A router must be transparent to _all_ addresses that might be seen outside the "box". Reconfiguring such internal details per installation is not acceptable. It would not be ok if 18.7.22.69 mysteriously disappeared when the customer hammered random addresses through it, even if said address was 'owned' by the vendor. The customer might be testing their own equipment for net deployment! The only addresses he might not legitimately see on the wire are the loopback ones. The routers I worked on at Cisco that had internal networks did exactly this, by the way. > If the router upstream from you used the same hack you end up being in > trouble. Uh, why? The 127 packets never leave the "box". -- Mathematics is the supreme nostalgia of our time. From marcel@holtmann.org Wed Mar 9 10:24:49 2005 Received: with ECARTIS (v1.0.0; list netdev); Wed, 09 Mar 2005 10:24:52 -0800 (PST) Received: from mail.holtmann.net (root@coyote.holtmann.net [217.160.111.169]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j29IOm31025676 for ; Wed, 9 Mar 2005 10:24:48 -0800 Received: from [192.168.1.12] ([82.133.105.205]) by mail.holtmann.net (8.12.3/8.12.3/Debian-7.1) with ESMTP id j29IOrhH015470 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NO); Wed, 9 Mar 2005 19:24:54 +0100 Subject: Re: [PATCH][BLUETOOTH] kill bt_sock_alloc From: Marcel Holtmann To: Max Krasnyansky Cc: Arnaldo Carvalho de Melo , davem@davemloft.net, netdev@oss.sgi.com In-Reply-To: <422F33E9.4030401@qualcomm.com> References: <20050308094937.GA9468@conectiva.com.br> <20050308095209.GB9468@conectiva.com.br> <422F33E9.4030401@qualcomm.com> Content-Type: text/plain Date: Wed, 09 Mar 2005 19:24:13 +0100 Message-Id: <1110392653.5462.40.camel@notepaq> Mime-Version: 1.0 X-Mailer: Evolution 2.0.4 Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV 0.83/757/Tue Mar 8 15:14:36 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 2716 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: marcel@holtmann.org Precedence: bulk X-list: netdev Content-Length: 271 Lines: 14 Hi Max, > > Sorry, now with the patch attached. > > Looks good to me. Marcel I'd suggest for you to apply this patch. > It helps in reducing overall size of the socket structures. I didn't got the time to review and test it. Will do that next week. Regards Marcel From acme@conectiva.com.br Wed Mar 9 10:43:23 2005 Received: with ECARTIS (v1.0.0; list netdev); Wed, 09 Mar 2005 10:43:27 -0800 (PST) Received: from orion.netbank.com.br (orion.netbank.com.br [200.203.199.90]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j29IhMPB026611 for ; Wed, 9 Mar 2005 10:43:23 -0800 Received: from [200.138.46.56] (helo=oops.ghostprotocols.net) by orion.netbank.com.br with asmtp (Exim 3.33 #1) id 1D968x-0004Hy-00; Wed, 09 Mar 2005 15:42:51 -0300 Received: by oops.ghostprotocols.net (Postfix, from userid 500) id 15FFB1462D; Wed, 9 Mar 2005 15:43:15 -0300 (BRT) Date: Wed, 9 Mar 2005 15:43:15 -0300 From: Arnaldo Carvalho de Melo To: Marcel Holtmann Cc: Max Krasnyansky , davem@davemloft.net, netdev@oss.sgi.com Subject: Re: [PATCH][BLUETOOTH] kill bt_sock_alloc Message-ID: <20050309184314.GA29053@conectiva.com.br> References: <20050308094937.GA9468@conectiva.com.br> <20050308095209.GB9468@conectiva.com.br> <422F33E9.4030401@qualcomm.com> <1110392653.5462.40.camel@notepaq> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1110392653.5462.40.camel@notepaq> X-Url: http://advogato.org/person/acme User-Agent: Mutt/1.5.6i X-Virus-Scanned: ClamAV 0.83/757/Tue Mar 8 15:14:36 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 2717 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: acme@conectiva.com.br Precedence: bulk X-list: netdev Content-Length: 759 Lines: 19 Em Wed, Mar 09, 2005 at 07:24:13PM +0100, Marcel Holtmann escreveu: > Hi Max, > > > > Sorry, now with the patch attached. > > > > Looks good to me. Marcel I'd suggest for you to apply this patch. > > It helps in reducing overall size of the socket structures. > > I didn't got the time to review and test it. Will do that next week. OK, take your time, but the changes are rather small, I left renaming all the _pinfo (l2cap_pinfo, for instance) to _sock (for consistency with all the other net families) to keep the patch small. For now I'll work on doing this same change to the HAM radio protocols, coordinating with Ralf Baechle and then wait for your comments to finally kill sk_protinfo and move on to introduce struct connection_sock. - Arnaldo From jgarzik@pobox.com Wed Mar 9 10:48:08 2005 Received: with ECARTIS (v1.0.0; list netdev); Wed, 09 Mar 2005 10:48:14 -0800 (PST) Received: from parcelfarce.linux.theplanet.co.uk (IDENT:93@parcelfarce.linux.theplanet.co.uk [195.92.249.252]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j29Im7CY027202 for ; Wed, 9 Mar 2005 10:48:08 -0800 Received: from [69.134.152.124] (helo=[10.10.10.88]) by parcelfarce.linux.theplanet.co.uk with asmtp (TLSv1:AES256-SHA:256) (Exim 4.33) id 1D96E2-0007mG-O1; Wed, 09 Mar 2005 18:48:06 +0000 Message-ID: <422F44D8.3010009@pobox.com> Date: Wed, 09 Mar 2005 13:47:52 -0500 From: Jeff Garzik User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.3) Gecko/20040922 X-Accept-Language: en-us, en MIME-Version: 1.0 To: "David S. Miller" , netdev@oss.sgi.com CC: Stephen Hemminger Subject: [PATCH] kill ->accept_fastpath hook References: <20050309092628.3c9014db@dxpl.pdx.osdl.net> In-Reply-To: <20050309092628.3c9014db@dxpl.pdx.osdl.net> Content-Type: multipart/mixed; boundary="------------070304060109090902000902" X-Virus-Scanned: ClamAV 0.83/757/Tue Mar 8 15:14:36 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 2718 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: jgarzik@pobox.com Precedence: bulk X-list: netdev Content-Length: 1830 Lines: 59 This is a multi-part message in MIME format. --------------070304060109090902000902 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Stephen Hemminger wrote: > Trivial reordering of netdevice structure to save four bytes. > > Signed-off-by: Stephen Hemminger If we are twiddling struct net_device, might as well kill this hook. Never called AFAICS, and only assigned -- to a no-op stub -- in one driver. Signed-off-by: Jeff Garzik --------------070304060109090902000902 Content-Type: text/plain; name="patch" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="patch" ===== include/linux/netdevice.h 1.99 vs edited ===== --- 1.99/include/linux/netdevice.h 2005-02-11 00:54:25 -05:00 +++ edited/include/linux/netdevice.h 2005-03-09 13:26:25 -05:00 @@ -469,7 +469,6 @@ int (*hard_header_parse)(struct sk_buff *skb, unsigned char *haddr); int (*neigh_setup)(struct net_device *dev, struct neigh_parms *); - int (*accept_fastpath)(struct net_device *, struct dst_entry*); #ifdef CONFIG_NETPOLL int netpoll_rx; #endif ===== net/bridge/br_device.c 1.17 vs edited ===== --- 1.17/net/bridge/br_device.c 2004-07-29 17:40:51 -04:00 +++ edited/net/bridge/br_device.c 2005-03-09 13:26:08 -05:00 @@ -83,11 +83,6 @@ return 0; } -static int br_dev_accept_fastpath(struct net_device *dev, struct dst_entry *dst) -{ - return -1; -} - void br_dev_setup(struct net_device *dev) { memset(dev->dev_addr, 0, ETH_ALEN); @@ -103,7 +98,6 @@ dev->destructor = free_netdev; SET_MODULE_OWNER(dev); dev->stop = br_dev_stop; - dev->accept_fastpath = br_dev_accept_fastpath; dev->tx_queue_len = 0; dev->set_mac_address = NULL; dev->priv_flags = IFF_EBRIDGE; --------------070304060109090902000902-- From shemminger@osdl.org Wed Mar 9 10:55:42 2005 Received: with ECARTIS (v1.0.0; list netdev); Wed, 09 Mar 2005 10:55:46 -0800 (PST) Received: from smtp.osdl.org (fire.osdl.org [65.172.181.4]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j29Itfkm027889 for ; Wed, 9 Mar 2005 10:55:41 -0800 Received: from shell0.pdx.osdl.net (fw.osdl.org [65.172.181.6]) by smtp.osdl.org (8.12.8/8.12.8) with ESMTP id j29ItYqi014884 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO); Wed, 9 Mar 2005 10:55:35 -0800 Received: from dxpl.pdx.osdl.net (dxpl.pdx.osdl.net [172.20.1.103]) by shell0.pdx.osdl.net (8.13.1/8.11.6) with ESMTP id j29ItYwj012542; Wed, 9 Mar 2005 10:55:34 -0800 Date: Wed, 9 Mar 2005 10:55:51 -0800 From: Stephen Hemminger To: Jeff Garzik Cc: "David S. Miller" , netdev@oss.sgi.com Subject: Re: [PATCH] kill ->accept_fastpath hook Message-ID: <20050309105551.09a7926c@dxpl.pdx.osdl.net> In-Reply-To: <422F44D8.3010009@pobox.com> References: <20050309092628.3c9014db@dxpl.pdx.osdl.net> <422F44D8.3010009@pobox.com> Organization: Open Source Development Lab X-Mailer: Sylpheed-Claws 1.0.1 (GTK+ 1.2.10; x86_64-unknown-linux-gnu) X-Face: &@E+xe?c%:&e4D{>f1O<&U>2qwRREG5!}7R4;D<"NO^UI2mJ[eEOA2*3>(`Th.yP,VDPo9$ /`~cw![cmj~~jWe?AHY7D1S+\}5brN0k*NE?pPh_'_d>6;XGG[\KDRViCfumZT3@[ Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Received-SPF: pass (domain of shemminger@osdl.org designates 65.172.181.6 as permitted sender) X-MIMEDefang-Filter: osdl$Revision: 1.104 $ X-Scanned-By: MIMEDefang 2.36 X-Virus-Scanned: ClamAV 0.83/757/Tue Mar 8 15:14:36 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 2719 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: shemminger@osdl.org Precedence: bulk X-list: netdev Content-Length: 454 Lines: 14 On Wed, 09 Mar 2005 13:47:52 -0500 Jeff Garzik wrote: > Stephen Hemminger wrote: > > Trivial reordering of netdevice structure to save four bytes. > > > > Signed-off-by: Stephen Hemminger > > If we are twiddling struct net_device, might as well kill this hook. > Never called AFAICS, and only assigned -- to a no-op stub -- in one driver. > > Signed-off-by: Jeff Garzik > yes, kill it. From shemminger@osdl.org Wed Mar 9 11:11:07 2005 Received: with ECARTIS (v1.0.0; list netdev); Wed, 09 Mar 2005 11:11:13 -0800 (PST) Received: from smtp.osdl.org (fire.osdl.org [65.172.181.4]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j29JB7g5028813 for ; Wed, 9 Mar 2005 11:11:07 -0800 Received: from shell0.pdx.osdl.net (fw.osdl.org [65.172.181.6]) by smtp.osdl.org (8.12.8/8.12.8) with ESMTP id j29JAwqi016128 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO); Wed, 9 Mar 2005 11:10:59 -0800 Received: from dxpl.pdx.osdl.net (dxpl.pdx.osdl.net [172.20.1.103]) by shell0.pdx.osdl.net (8.13.1/8.11.6) with ESMTP id j29JAwFb013419; Wed, 9 Mar 2005 11:10:58 -0800 Date: Wed, 9 Mar 2005 11:11:16 -0800 From: Stephen Hemminger To: Robert Olsson Cc: Robert Olsson , netdev@oss.sgi.com Subject: Re: pktgen: causing lots of errors in console log Message-ID: <20050309111116.2a026b8e@dxpl.pdx.osdl.net> In-Reply-To: <16942.55689.924299.906304@robur.slu.se> References: <20050308140826.451435e5@dxpl.pdx.osdl.net> <16942.55689.924299.906304@robur.slu.se> Organization: Open Source Development Lab X-Mailer: Sylpheed-Claws 1.0.1 (GTK+ 1.2.10; x86_64-unknown-linux-gnu) X-Face: &@E+xe?c%:&e4D{>f1O<&U>2qwRREG5!}7R4;D<"NO^UI2mJ[eEOA2*3>(`Th.yP,VDPo9$ /`~cw![cmj~~jWe?AHY7D1S+\}5brN0k*NE?pPh_'_d>6;XGG[\KDRViCfumZT3@[ Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Received-SPF: pass (domain of shemminger@osdl.org designates 65.172.181.6 as permitted sender) X-MIMEDefang-Filter: osdl$Revision: 1.104 $ X-Scanned-By: MIMEDefang 2.36 X-Virus-Scanned: ClamAV 0.83/757/Tue Mar 8 15:14:36 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 2720 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: shemminger@osdl.org Precedence: bulk X-list: netdev Content-Length: 899 Lines: 36 On Wed, 9 Mar 2005 12:10:01 +0100 Robert Olsson wrote: > > Hello! > > > Stephen Hemminger writes: > > 1. Errors from IPV4 > > Freeing alive in_device ffff81007e96a400 > > Try: > > --- net/core/pktgen.c.orig 2005-03-09 10:15:01.000000000 +0100 > +++ net/core/pktgen.c 2005-03-09 10:24:19.000000000 +0100 > @@ -151,7 +151,7 @@ > #include > > > -#define VERSION "pktgen v2.58: Packet Generator for packet performance testing.\n" > +#define VERSION "pktgen v2.59: Packet Generator for packet performance testing.\n" > > /* #define PG_DEBUG(a) a */ > #define PG_DEBUG(a) > @@ -1682,7 +1682,7 @@ > pkt_dev->saddr_min = in_dev->ifa_list->ifa_address; > pkt_dev->saddr_max = pkt_dev->saddr_min; > } > - in_dev_put(in_dev); > + __in_dev_put(in_dev); > } > rcu_read_unlock(); > } > This fixes the messages. From shemminger@osdl.org Wed Mar 9 11:37:18 2005 Received: with ECARTIS (v1.0.0; list netdev); Wed, 09 Mar 2005 11:37:25 -0800 (PST) Received: from smtp.osdl.org (fire.osdl.org [65.172.181.4]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j29JbI3T029775 for ; Wed, 9 Mar 2005 11:37:18 -0800 Received: from shell0.pdx.osdl.net (fw.osdl.org [65.172.181.6]) by smtp.osdl.org (8.12.8/8.12.8) with ESMTP id j29Jaxqi018553 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO); Wed, 9 Mar 2005 11:37:00 -0800 Received: from dxpl.pdx.osdl.net (dxpl.pdx.osdl.net [172.20.1.103]) by shell0.pdx.osdl.net (8.13.1/8.11.6) with ESMTP id j29Jaxcw014941; Wed, 9 Mar 2005 11:36:59 -0800 Date: Wed, 9 Mar 2005 11:34:02 -0800 From: Stephen Hemminger To: Francois Romieu Cc: netdev@oss.sgi.com Subject: [PATCH 4/5] r8169: ethtool message level control Message-ID: <20050309113402.05d25e49@dxpl.pdx.osdl.net> Organization: Open Source Development Lab X-Mailer: Sylpheed-Claws 1.0.1 (GTK+ 1.2.10; x86_64-unknown-linux-gnu) X-Face: &@E+xe?c%:&e4D{>f1O<&U>2qwRREG5!}7R4;D<"NO^UI2mJ[eEOA2*3>(`Th.yP,VDPo9$ /`~cw![cmj~~jWe?AHY7D1S+\}5brN0k*NE?pPh_'_d>6;XGG[\KDRViCfumZT3@[ Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Received-SPF: pass (domain of shemminger@osdl.org designates 65.172.181.6 as permitted sender) X-MIMEDefang-Filter: osdl$Revision: 1.104 $ X-Scanned-By: MIMEDefang 2.36 X-Virus-Scanned: ClamAV 0.83/757/Tue Mar 8 15:14:36 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 2725 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: shemminger@osdl.org Precedence: bulk X-list: netdev Content-Length: 5607 Lines: 178 Add ethtool message level control support. This is the standard way to enable/disable console log messages. Also, ratelimit the too much work at interrupt message, so if under massive packet load the console doesn't get flooded. Signed-off-by: Stephen Hemminger diff -Nru a/drivers/net/r8169.c b/drivers/net/r8169.c --- a/drivers/net/r8169.c 2005-03-09 11:25:04 -08:00 +++ b/drivers/net/r8169.c 2005-03-09 11:25:04 -08:00 @@ -188,6 +188,9 @@ MODULE_DEVICE_TABLE(pci, rtl8169_pci_tbl); static int rx_copybreak = 200; +static int debug = 3; +static const u32 default_msg = NETIF_MSG_DRV | NETIF_MSG_PROBE | + NETIF_MSG_LINK | NETIF_MSG_IFUP| NETIF_MSG_IFDOWN; enum RTL8169_registers { MAC0 = 0, /* Ethernet hardware address. */ @@ -390,6 +393,7 @@ struct pci_dev *pci_dev; /* Index of PCI device */ struct net_device_stats stats; /* statistics of net device */ spinlock_t lock; /* spin lock flag */ + int msg_enable; int chipset; int mac_version; int phy_version; @@ -425,6 +429,8 @@ module_param_array(media, int, &num_media, 0); module_param(rx_copybreak, int, 0); MODULE_PARM_DESC(rx_copybreak, "copy breakpoint for copy-only-tiny-frames"); +module_param(debug, int, 0); +MODULE_PARM_DESC(debug, "Debug level (0=none,...,16=all)"); MODULE_LICENSE("GPL"); MODULE_VERSION(RTL8169_VERSION); @@ -547,9 +553,13 @@ spin_lock_irqsave(&tp->lock, flags); if (tp->link_ok(ioaddr)) { netif_carrier_on(dev); - printk(KERN_INFO PFX "%s: link up\n", dev->name); - } else + if (netif_msg_ifup(tp)) + printk(KERN_INFO PFX "%s: link up\n", dev->name); + } else { + if (netif_msg_ifdown(tp)) + printk(KERN_INFO PFX "%s: link down\n", dev->name); netif_carrier_off(dev); + } spin_unlock_irqrestore(&tp->lock, flags); } @@ -875,12 +885,26 @@ spin_unlock_irqrestore(&tp->lock, flags); } +static u32 rtl8169_get_msglevel(struct net_device *dev) +{ + struct rtl8169_private *tp = netdev_priv(dev); + return tp->msg_enable; +} + +static void rtl8169_set_msglevel(struct net_device *dev, u32 value) +{ + struct rtl8169_private *tp = netdev_priv(dev); + tp->msg_enable = value; +} + static struct ethtool_ops rtl8169_ethtool_ops = { .get_drvinfo = rtl8169_get_drvinfo, .get_regs_len = rtl8169_get_regs_len, .get_link = ethtool_op_get_link, .get_settings = rtl8169_get_settings, .set_settings = rtl8169_set_settings, + .get_msglevel = rtl8169_get_msglevel, + .set_msglevel = rtl8169_set_msglevel, .get_rx_csum = rtl8169_get_rx_csum, .set_rx_csum = rtl8169_set_rx_csum, .get_tx_csum = ethtool_op_get_tx_csum, @@ -1095,7 +1119,8 @@ if (tp->link_ok(ioaddr)) goto out_unlock; - printk(KERN_WARNING PFX "%s: PHY reset until link up\n", dev->name); + if (netif_msg_link(tp)) + printk(KERN_WARNING PFX "%s: PHY reset until link up\n", dev->name); tp->phy_reset_enable(ioaddr); @@ -1180,6 +1205,7 @@ SET_MODULE_OWNER(dev); SET_NETDEV_DEV(dev, &pdev->dev); tp = netdev_priv(dev); + tp->msg_enable = netif_msg_init(debug, default_msg); /* enable device (incl. PCI PM wakeup and hotplug setup) */ rc = pci_enable_device(pdev); @@ -1395,20 +1421,22 @@ return rc; } - printk(KERN_DEBUG "%s: Identified chip type is '%s'.\n", dev->name, - rtl_chip_info[tp->chipset].name); + if (netif_msg_probe(tp)) + printk(KERN_DEBUG "%s: Identified chip type is '%s'.\n", dev->name, + rtl_chip_info[tp->chipset].name); pci_set_drvdata(pdev, dev); - printk(KERN_INFO "%s: %s at 0x%lx, " - "%2.2x:%2.2x:%2.2x:%2.2x:%2.2x:%2.2x, " - "IRQ %d\n", - dev->name, - rtl_chip_info[ent->driver_data].name, - dev->base_addr, - dev->dev_addr[0], dev->dev_addr[1], - dev->dev_addr[2], dev->dev_addr[3], - dev->dev_addr[4], dev->dev_addr[5], dev->irq); + if (netif_msg_probe(tp)) + printk(KERN_INFO "%s: %s at 0x%lx, " + "%2.2x:%2.2x:%2.2x:%2.2x:%2.2x:%2.2x, " + "IRQ %d\n", + dev->name, + rtl_chip_info[ent->driver_data].name, + dev->base_addr, + dev->dev_addr[0], dev->dev_addr[1], + dev->dev_addr[2], dev->dev_addr[3], + dev->dev_addr[4], dev->dev_addr[5], dev->irq); rtl8169_hw_phy_config(dev); @@ -1431,7 +1459,7 @@ rtl8169_set_speed(dev, autoneg, speed, duplex); - if (RTL_R8(PHYstatus) & TBI_Enable) + if (RTL_R8(PHYstatus) & TBI_Enable && netif_msg_link(tp)) printk(KERN_INFO PFX "%s: TBI auto-negotiating\n", dev->name); return 0; @@ -2185,8 +2213,10 @@ if (status & DescOwn) break; - if (status & RxRES) { - printk(KERN_INFO "%s: Rx ERROR!!!\n", dev->name); + if (unlikely(status & RxRES)) { + if (netif_msg_rx_err(tp)) + printk(KERN_INFO "%s: Rx ERROR statu=%x!\n", + dev->name, status); tp->stats.rx_errors++; if (status & (RxRWT | RxRUNT)) tp->stats.rx_length_errors++; @@ -2314,8 +2344,9 @@ } while (boguscnt > 0); if (boguscnt <= 0) { - printk(KERN_WARNING "%s: Too much work at interrupt!\n", - dev->name); + if (net_ratelimit()) + printk(KERN_WARNING "%s: Too much work at interrupt!\n", + dev->name); /* Clear all interrupt sources. */ RTL_W16(IntrStatus, 0xffff); } @@ -2409,8 +2440,9 @@ if (dev->flags & IFF_PROMISC) { /* Unconditionally log net taps. */ - printk(KERN_NOTICE "%s: Promiscuous mode enabled.\n", - dev->name); + if (netif_msg_link(tp)) + printk(KERN_NOTICE "%s: Promiscuous mode enabled.\n", + dev->name); rx_mode = AcceptBroadcast | AcceptMulticast | AcceptMyPhys | AcceptAllPhys; From shemminger@osdl.org Wed Mar 9 11:37:13 2005 Received: with ECARTIS (v1.0.0; list netdev); Wed, 09 Mar 2005 11:37:21 -0800 (PST) Received: from smtp.osdl.org (fire.osdl.org [65.172.181.4]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j29JbDKa029765 for ; Wed, 9 Mar 2005 11:37:13 -0800 Received: from shell0.pdx.osdl.net (fw.osdl.org [65.172.181.6]) by smtp.osdl.org (8.12.8/8.12.8) with ESMTP id j29Jb0qi018557 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO); Wed, 9 Mar 2005 11:37:00 -0800 Received: from dxpl.pdx.osdl.net (dxpl.pdx.osdl.net [172.20.1.103]) by shell0.pdx.osdl.net (8.13.1/8.11.6) with ESMTP id j29Jb0iG014947; Wed, 9 Mar 2005 11:37:00 -0800 Date: Wed, 9 Mar 2005 11:36:47 -0800 From: Stephen Hemminger To: Francois Romieu Cc: netdev@oss.sgi.com Subject: [PATCH 2/5] r8169: add NAPI suffix Message-ID: <20050309113647.174b1b5c@dxpl.pdx.osdl.net> Organization: Open Source Development Lab X-Mailer: Sylpheed-Claws 1.0.1 (GTK+ 1.2.10; x86_64-unknown-linux-gnu) X-Face: &@E+xe?c%:&e4D{>f1O<&U>2qwRREG5!}7R4;D<"NO^UI2mJ[eEOA2*3>(`Th.yP,VDPo9$ /`~cw![cmj~~jWe?AHY7D1S+\}5brN0k*NE?pPh_'_d>6;XGG[\KDRViCfumZT3@[ Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Received-SPF: pass (domain of shemminger@osdl.org designates 65.172.181.6 as permitted sender) X-MIMEDefang-Filter: osdl$Revision: 1.104 $ X-Scanned-By: MIMEDefang 2.36 X-Virus-Scanned: ClamAV 0.83/757/Tue Mar 8 15:14:36 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 2723 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: shemminger@osdl.org Precedence: bulk X-list: netdev Content-Length: 820 Lines: 31 To tell if driver is configured for NAPI or not, put -NAPI on driver version rather than putting message on console. Signed-off-by: Stephen Hemminger diff -Nru a/drivers/net/r8169.c b/drivers/net/r8169.c --- a/drivers/net/r8169.c 2005-03-09 11:24:24 -08:00 +++ b/drivers/net/r8169.c 2005-03-09 11:24:24 -08:00 @@ -69,7 +69,13 @@ #include #include -#define RTL8169_VERSION "2.2LK" +#ifdef CONFIG_R8169_NAPI +#define NAPI_SUFFIX "-NAPI" +#else +#define NAPI_SUFFIX "" +#endif + +#define RTL8169_VERSION "2.2LK" NAPI_SUFFIX #define MODULENAME "r8169" #define PFX MODULENAME ": " @@ -1364,7 +1370,6 @@ #ifdef CONFIG_R8169_NAPI dev->poll = rtl8169_poll; dev->weight = R8169_NAPI_WEIGHT; - printk(KERN_INFO PFX "NAPI enabled\n"); #endif #ifdef CONFIG_R8169_VLAN From shemminger@osdl.org Wed Mar 9 11:37:13 2005 Received: with ECARTIS (v1.0.0; list netdev); Wed, 09 Mar 2005 11:37:21 -0800 (PST) Received: from smtp.osdl.org (fire.osdl.org [65.172.181.4]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j29JbDW2029764 for ; Wed, 9 Mar 2005 11:37:13 -0800 Received: from shell0.pdx.osdl.net (fw.osdl.org [65.172.181.6]) by smtp.osdl.org (8.12.8/8.12.8) with ESMTP id j29Jaxqi018551 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO); Wed, 9 Mar 2005 11:37:00 -0800 Received: from dxpl.pdx.osdl.net (dxpl.pdx.osdl.net [172.20.1.103]) by shell0.pdx.osdl.net (8.13.1/8.11.6) with ESMTP id j29Jax6J014938; Wed, 9 Mar 2005 11:36:59 -0800 Date: Wed, 9 Mar 2005 11:29:25 -0800 From: Stephen Hemminger To: Francois Romieu Cc: netdev@oss.sgi.com Subject: [PATCH 1/5] r8169: auto detect 32-bit slot Message-ID: <20050309112925.7f7900ab@dxpl.pdx.osdl.net> Organization: Open Source Development Lab X-Mailer: Sylpheed-Claws 1.0.1 (GTK+ 1.2.10; x86_64-unknown-linux-gnu) X-Face: &@E+xe?c%:&e4D{>f1O<&U>2qwRREG5!}7R4;D<"NO^UI2mJ[eEOA2*3>(`Th.yP,VDPo9$ /`~cw![cmj~~jWe?AHY7D1S+\}5brN0k*NE?pPh_'_d>6;XGG[\KDRViCfumZT3@[ Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Received-SPF: pass (domain of shemminger@osdl.org designates 65.172.181.6 as permitted sender) X-MIMEDefang-Filter: osdl$Revision: 1.104 $ X-Scanned-By: MIMEDefang 2.36 X-Virus-Scanned: ClamAV 0.83/757/Tue Mar 8 15:14:36 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 2722 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: shemminger@osdl.org Precedence: bulk X-list: netdev Content-Length: 1792 Lines: 64 Change driver to auto-detect when the board is in a 32-bit PCI slot and avoid setting 64-bit dma mask. The module parameter method is no longer needed. Signed-off-by: Stephen Hemminger diff -Nru a/drivers/net/r8169.c b/drivers/net/r8169.c --- a/drivers/net/r8169.c 2005-03-09 11:23:58 -08:00 +++ b/drivers/net/r8169.c 2005-03-09 11:23:58 -08:00 @@ -182,7 +182,6 @@ MODULE_DEVICE_TABLE(pci, rtl8169_pci_tbl); static int rx_copybreak = 200; -static int use_dac; enum RTL8169_registers { MAC0 = 0, /* Ethernet hardware address. */ @@ -419,8 +418,6 @@ MODULE_DESCRIPTION("RealTek RTL-8169 Gigabit Ethernet driver"); module_param_array(media, int, &num_media, 0); module_param(rx_copybreak, int, 0); -module_param(use_dac, int, 0); -MODULE_PARM_DESC(use_dac, "Enable PCI DAC. Unsafe on 32 bit PCI slot."); MODULE_LICENSE("GPL"); MODULE_VERSION(RTL8169_VERSION); @@ -1224,18 +1221,6 @@ tp->cp_cmd = PCIMulRW | RxChkSum; - if ((sizeof(dma_addr_t) > 4) && - !pci_set_dma_mask(pdev, DMA_64BIT_MASK) && use_dac) { - tp->cp_cmd |= PCIDAC; - dev->features |= NETIF_F_HIGHDMA; - } else { - rc = pci_set_dma_mask(pdev, DMA_32BIT_MASK); - if (rc < 0) { - printk(KERN_ERR PFX "DMA configuration failed.\n"); - goto err_out_free_res; - } - } - pci_set_master(pdev); /* ioremap MMIO region */ @@ -1278,6 +1263,19 @@ i++; } tp->chipset = i; + + if ((sizeof(dma_addr_t) > 4) && + (RTL_R32(Config2) & (1<<3)) && + !pci_set_dma_mask(pdev, DMA_64BIT_MASK)) { + tp->cp_cmd |= PCIDAC; + dev->features |= NETIF_F_HIGHDMA; + } else { + rc = pci_set_dma_mask(pdev, DMA_32BIT_MASK); + if (rc < 0) { + printk(KERN_ERR PFX "DMA configuration failed.\n"); + goto err_out_free_res; + } + } *ioaddr_out = ioaddr; *dev_out = dev; From shemminger@osdl.org Wed Mar 9 11:37:12 2005 Received: with ECARTIS (v1.0.0; list netdev); Wed, 09 Mar 2005 11:37:19 -0800 (PST) Received: from smtp.osdl.org (fire.osdl.org [65.172.181.4]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j29JbCsY029763 for ; Wed, 9 Mar 2005 11:37:12 -0800 Received: from shell0.pdx.osdl.net (fw.osdl.org [65.172.181.6]) by smtp.osdl.org (8.12.8/8.12.8) with ESMTP id j29Jb0qi018559 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO); Wed, 9 Mar 2005 11:37:00 -0800 Received: from dxpl.pdx.osdl.net (dxpl.pdx.osdl.net [172.20.1.103]) by shell0.pdx.osdl.net (8.13.1/8.11.6) with ESMTP id j29Jb04P014950; Wed, 9 Mar 2005 11:37:00 -0800 Date: Wed, 9 Mar 2005 11:37:00 -0800 From: Stephen Hemminger To: Francois Romieu Cc: netdev@oss.sgi.com Subject: [PATCH 3/5] r8169: rx_copybreak description Message-ID: <20050309113700.21a31d84@dxpl.pdx.osdl.net> Organization: Open Source Development Lab X-Mailer: Sylpheed-Claws 1.0.1 (GTK+ 1.2.10; x86_64-unknown-linux-gnu) X-Face: &@E+xe?c%:&e4D{>f1O<&U>2qwRREG5!}7R4;D<"NO^UI2mJ[eEOA2*3>(`Th.yP,VDPo9$ /`~cw![cmj~~jWe?AHY7D1S+\}5brN0k*NE?pPh_'_d>6;XGG[\KDRViCfumZT3@[ Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Received-SPF: pass (domain of shemminger@osdl.org designates 65.172.181.6 as permitted sender) X-MIMEDefang-Filter: osdl$Revision: 1.104 $ X-Scanned-By: MIMEDefang 2.36 X-Virus-Scanned: ClamAV 0.83/757/Tue Mar 8 15:14:36 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 2721 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: shemminger@osdl.org Precedence: bulk X-list: netdev Content-Length: 573 Lines: 15 Add module parameter description for copybreak. Signed-off-by: Stephen Hemminger diff -Nru a/drivers/net/r8169.c b/drivers/net/r8169.c --- a/drivers/net/r8169.c 2005-03-09 11:24:43 -08:00 +++ b/drivers/net/r8169.c 2005-03-09 11:24:43 -08:00 @@ -424,6 +424,7 @@ MODULE_DESCRIPTION("RealTek RTL-8169 Gigabit Ethernet driver"); module_param_array(media, int, &num_media, 0); module_param(rx_copybreak, int, 0); +MODULE_PARM_DESC(rx_copybreak, "copy breakpoint for copy-only-tiny-frames"); MODULE_LICENSE("GPL"); MODULE_VERSION(RTL8169_VERSION); From shemminger@osdl.org Wed Mar 9 11:37:13 2005 Received: with ECARTIS (v1.0.0; list netdev); Wed, 09 Mar 2005 11:37:21 -0800 (PST) Received: from smtp.osdl.org (fire.osdl.org [65.172.181.4]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j29JbDFw029766 for ; Wed, 9 Mar 2005 11:37:13 -0800 Received: from shell0.pdx.osdl.net (fw.osdl.org [65.172.181.6]) by smtp.osdl.org (8.12.8/8.12.8) with ESMTP id j29Jaxqi018555 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO); Wed, 9 Mar 2005 11:37:00 -0800 Received: from dxpl.pdx.osdl.net (dxpl.pdx.osdl.net [172.20.1.103]) by shell0.pdx.osdl.net (8.13.1/8.11.6) with ESMTP id j29JaxJF014944; Wed, 9 Mar 2005 11:36:59 -0800 Date: Wed, 9 Mar 2005 11:36:26 -0800 From: Stephen Hemminger To: Francois Romieu Cc: netdev@oss.sgi.com Subject: [PATCH 5/5] r8169: ethtool hardware statistics support Message-ID: <20050309113626.6708c93e@dxpl.pdx.osdl.net> Organization: Open Source Development Lab X-Mailer: Sylpheed-Claws 1.0.1 (GTK+ 1.2.10; x86_64-unknown-linux-gnu) X-Face: &@E+xe?c%:&e4D{>f1O<&U>2qwRREG5!}7R4;D<"NO^UI2mJ[eEOA2*3>(`Th.yP,VDPo9$ /`~cw![cmj~~jWe?AHY7D1S+\}5brN0k*NE?pPh_'_d>6;XGG[\KDRViCfumZT3@[ Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Received-SPF: pass (domain of shemminger@osdl.org designates 65.172.181.6 as permitted sender) X-MIMEDefang-Filter: osdl$Revision: 1.104 $ X-Scanned-By: MIMEDefang 2.36 X-Virus-Scanned: ClamAV 0.83/757/Tue Mar 8 15:14:36 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 2724 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: shemminger@osdl.org Precedence: bulk X-list: netdev Content-Length: 3659 Lines: 139 Add ethtool support for dumping the chip statistics. There aren't lots of statistics available, but this is what is available according to the RealTek documentation. Signed-off-by: Stephen Hemminger diff -Nru a/drivers/net/r8169.c b/drivers/net/r8169.c --- a/drivers/net/r8169.c 2005-03-09 11:26:04 -08:00 +++ b/drivers/net/r8169.c 2005-03-09 11:26:04 -08:00 @@ -195,6 +195,8 @@ enum RTL8169_registers { MAC0 = 0, /* Ethernet hardware address. */ MAR0 = 8, /* Multicast filter. */ + CounterAddrLow = 0x10, + CounterAddrHigh = 0x14, TxDescStartAddrLow = 0x20, TxDescStartAddrHigh = 0x24, TxHDescStartAddrLow = 0x28, @@ -336,6 +338,9 @@ /* _TBICSRBit */ TBILinkOK = 0x02000000, + + /* DumpCounterCommand */ + CounterDump = 0x8, }; enum _DescStatusBit { @@ -897,6 +902,100 @@ tp->msg_enable = value; } +static const char rtl8169_gstrings[][ETH_GSTRING_LEN] = { + "tx_packets", + "rx_packets", + "tx_errors", + "rx_errors", + "rx_missed", + "align_errors", + "tx_single_collisions", + "tx_multi_collisions", + "unicast", + "broadcast", + "multicast", + "tx_aborted", + "tx_underrun", +}; + +struct rtl8169_counters { + u64 tx_packets; + u64 rx_packets; + u64 tx_errors; + u32 rx_errors; + u16 rx_missed; + u16 align_errors; + u32 tx_one_collision; + u32 tx_multi_collision; + u64 rx_unicast; + u64 rx_broadcast; + u32 rx_multicast; + u16 tx_aborted; + u16 tx_underun; +}; + +static int rtl8169_get_stats_count(struct net_device *dev) +{ + return 13; +} + +static void rtl8169_get_ethtool_stats(struct net_device *dev, + struct ethtool_stats *stats, u64 *data) +{ + struct rtl8169_private *tp = netdev_priv(dev); + struct rtl8169_counters *counters; + void __iomem *ioaddr = tp->mmio_addr; + int i; + dma_addr_t paddr; + u32 cmd; + + ASSERT_RTNL(); + + counters = pci_alloc_consistent(tp->pci_dev, sizeof(*counters), + &paddr); + if (!counters) + return; + + RTL_W32(CounterAddrHigh, (u64)paddr >> 32); + cmd = (u64) paddr & DMA_32BIT_MASK; + RTL_W32(CounterAddrLow, cmd); + RTL_W32(CounterAddrLow, cmd | CounterDump); + + for (i = 0; i < 1000; i++) { + if (!RTL_R32(CounterAddrLow) & CounterDump) + break; + udelay(10); + } + RTL_W32(CounterAddrLow, 0); + RTL_W32(CounterAddrHigh, 0); + + data[0] = le64_to_cpu(counters->tx_packets); + data[1] = le64_to_cpu(counters->rx_packets); + data[2] = le64_to_cpu(counters->tx_errors); + data[3] = le32_to_cpu(counters->rx_errors); + data[4] = le16_to_cpu(counters->rx_missed); + data[5] = le16_to_cpu(counters->align_errors); + data[6] = le32_to_cpu(counters->tx_one_collision); + data[7] = le32_to_cpu(counters->tx_multi_collision); + data[8] = le64_to_cpu(counters->rx_unicast); + data[9] = le64_to_cpu(counters->rx_broadcast); + data[10] = le32_to_cpu(counters->rx_multicast); + data[11] = le16_to_cpu(counters->tx_aborted); + data[12] = le16_to_cpu(counters->tx_underun); + + pci_free_consistent(tp->pci_dev, sizeof(*counters), counters, paddr); +} + +static void rtl8169_get_strings(struct net_device *dev, u32 stringset, u8 *data) +{ + switch(stringset) { + case ETH_SS_STATS: + memcpy(data, *rtl8169_gstrings, sizeof(rtl8169_gstrings)); + break; + } +} + + static struct ethtool_ops rtl8169_ethtool_ops = { .get_drvinfo = rtl8169_get_drvinfo, .get_regs_len = rtl8169_get_regs_len, @@ -914,6 +1013,9 @@ .get_tso = ethtool_op_get_tso, .set_tso = ethtool_op_set_tso, .get_regs = rtl8169_get_regs, + .get_strings = rtl8169_get_strings, + .get_stats_count = rtl8169_get_stats_count, + .get_ethtool_stats = rtl8169_get_ethtool_stats, }; static void rtl8169_write_gmii_reg_bit(void __iomem *ioaddr, int reg, int bitnum, From hadi@cyberus.ca Wed Mar 9 11:40:45 2005 Received: with ECARTIS (v1.0.0; list netdev); Wed, 09 Mar 2005 11:40:49 -0800 (PST) Received: from mx03.cybersurf.com (mx03.cybersurf.com [209.197.145.106]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j29JeihM032354 for ; Wed, 9 Mar 2005 11:40:45 -0800 Received: from mail.cyberus.ca ([209.197.145.21]) by mx03.cybersurf.com with esmtp (Exim 4.30) id 1D972x-00081w-LL for netdev@oss.sgi.com; Wed, 09 Mar 2005 14:40:43 -0500 Received: from [216.209.86.2] (helo=[10.0.0.9]) by mail.cyberus.ca with esmtp (Exim 4.20) id 1D972p-00051b-Fb; Wed, 09 Mar 2005 14:40:35 -0500 Subject: RE: Do you know the TCP stack? (127.x.x.x routing) From: jamal Reply-To: hadi@cyberus.ca To: Steve Iribarne Cc: Henrik Nordstrom , Martin Mares , Zdenek Radouch , Eran Mann , Thomas Graf , Andi Kleen , netdev@oss.sgi.com, linux-net@vger.kernel.org In-Reply-To: References: Content-Type: text/plain Organization: jamalopolous Message-Id: <1110397231.1078.143.camel@jzny.localdomain> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.2.2 Date: 09 Mar 2005 14:40:31 -0500 Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV 0.83/757/Tue Mar 8 15:14:36 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 2726 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: hadi@cyberus.ca Precedence: bulk X-list: netdev Content-Length: 3677 Lines: 83 On Wed, 2005-03-09 at 12:33, Steve Iribarne wrote: > -> Your blades --> VLANX/SubnetX > -> --> [some L3 switch] > > umm.. I have a L2 switch... not L3 switch. > Lets go over this slowly so we can hopefully resolve why we dont see eye to eye. I am not sure why i am spending all this energy on this. Lets get the diagrams better: 1) your case: Your blades <--> VLANX/SubnetX <--> [some L2 switch] <--> VLANY/SubnetY <--> outside world You probably have redundancy etc in some ATCA||2.16 setup with links going to two internal switches - but lets also ignore that - just assume the simple switch for now for sake of clarity. You may also have many VLANs in/out like you said "signaling traffic, bearer traffic and network mgmt traffic", but the two internal vs external interfaces i showed above should suffice to indicate the general picture. Agreed? To sumarize, for you to get to/from the outside world to your blades you go via L2 switch with a "few" interfaces to the ouside world. In your case the "internal" interface is the VLANX port(s) facing the switch. The "external" interface is the port(s) on VLANY facing the outside. 2) Note this is slightly different from Zdenek, which is: Outside <->one or more interfaces <-> [LinecardX] <-->[swicth/fabric] Outside <->one or more interfaces <-> [LinecardY] <-->[swicth/fabric] . . In other words each line card has many interfaces that come into the box. It is not unusual to find 12-48 interface line cards. The "switch" aka "fabric" connects these line cards (and perhaps some control plane blade(s)). Typically such a switch will not run IP but rather some other internal thing like CSIX or SPI-x etc. In both setups, if you do run IP internally, it does make sense not "leak" internal traffic to the outside world with such addresses. In both cases you both try hard (and i am sure succeed) to not leak those packets out - In your case its a simple separation of collision domains. The only way you can get from internal to external is if infact you have L2 connectivity between the two (since you said you dont have L3 switching in your chasis). By making the 127.x routable in linux of all places - which is where i started disagreeing, you introduce some challenges with hope that 127.x obscurity is going to help. To avoid confusion and have Zdenek respond when i am talking to you or viceversa lets make the two as separate issues: 1) In your case i saw no reason for you to use 127.x - you could have achieved the same with 10.x. Your internal packets will never leak out. You say you will have collisions with customer; but then if i understood correctly you said these internal packets never the box. So my conclusion was you didnt need the hack. 2)Zdenek's case Just avoiding the leak is not good enough if the 127.x is routable and someone else is using it and he has to route such packets. In such a case, even if Zdenek hides the internal network at some point he will have to route a packet coming into linecardX, port A to linecardY, port B. And for this reason he cant totaly avoid collision. This is why i called it survival via obscurity. Note: I am not questioning his technique but i would never use it myself. Lets say we can achieve the same goal in a different way. > Again, if you can show me a way of doing this, I'm all ears, but so far, > you haven't shown me any other way around it. Believe me. I've tried > and tried to find another solution to this problem. > Lets talk about this when we are clear what the problem is. Fix up the diagram above if it is wrong, then we can talk. cheers, jamal From tgraf@suug.ch Wed Mar 9 11:45:03 2005 Received: with ECARTIS (v1.0.0; list netdev); Wed, 09 Mar 2005 11:45:07 -0800 (PST) Received: from b.mx.projectdream.org (eth0-0.arisu.projectdream.org [194.158.4.191]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j29Jj2nW000430 for ; Wed, 9 Mar 2005 11:45:03 -0800 Received: from postel.suug.ch (postel.suug.ch [195.134.158.23]) (using TLSv1 with cipher EDH-RSA-DES-CBC3-SHA (168/168 bits)) (No client certificate requested) by b.mx.projectdream.org (Postfix) with ESMTP id 812DF8C; Wed, 9 Mar 2005 20:44:38 +0100 (CET) Received: by postel.suug.ch (Postfix, from userid 10001) id 388F01C0EA; Wed, 9 Mar 2005 20:45:21 +0100 (CET) Date: Wed, 9 Mar 2005 20:45:21 +0100 From: Thomas Graf To: "David S. Miller" Cc: netdev@oss.sgi.com Subject: [PATCHSET] [NET] Various sock struct reorderings Message-ID: <20050309194521.GH31837@postel.suug.ch> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline X-Virus-Scanned: ClamAV 0.83/757/Tue Mar 8 15:14:36 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 2727 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: tgraf@suug.ch Precedence: bulk X-list: netdev Content-Length: 511 Lines: 15 The following patchset reorders various sock structures to avoid padding and shrinks various oversized fields to save space. This will probably break various external modules so maybe we should defer this. Savings on my x86 box: rawv6_sock: 696 -> 668 udpv6_sock: 668 -> 640 tcpv6_sock: 1232 -> 1192 unix_sock: 464 -> 452 raw_sock: 548 -> 524 udp_sock: 556 -> 532 tcp_sock: 1120 -> 1084 sock: 388 -> 376 I didn't benchmark any cachline effects though. From kaber@trash.net Wed Mar 9 11:45:48 2005 Received: with ECARTIS (v1.0.0; list netdev); Wed, 09 Mar 2005 11:45:56 -0800 (PST) Received: from kaber.coreworks.de ([62.206.217.67]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j29JjlC2000698 for ; Wed, 9 Mar 2005 11:45:48 -0800 Received: from localhost ([127.0.0.1]) by kaber.coreworks.de with esmtp (Exim 4.50) id 1D977f-0008Uq-O7; Wed, 09 Mar 2005 20:45:35 +0100 Message-ID: <422F525F.90404@trash.net> Date: Wed, 09 Mar 2005 20:45:35 +0100 From: Patrick McHardy User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.7.5) Gecko/20050106 Debian/1.7.5-1 X-Accept-Language: en MIME-Version: 1.0 To: Andre Tomt CC: Michal Vanco , linux-kernel@vger.kernel.org, Netdev , "David S. Miller" Subject: Re: 2.6.11 on AMD64 traps References: <200503081900.18686.vanco@satro.sk> <422DF07D.7010908@tomt.net> In-Reply-To: <422DF07D.7010908@tomt.net> Content-Type: multipart/mixed; boundary="------------050304030002040403080208" X-Virus-Scanned: ClamAV 0.83/757/Tue Mar 8 15:14:36 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 2728 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: kaber@trash.net Precedence: bulk X-list: netdev Content-Length: 1962 Lines: 70 This is a multi-part message in MIME format. --------------050304030002040403080208 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit > Michal Vanco wrote: >> >> I see this problem running 2.6.11 on dual AMD64: >> >> Running quagga routing daemon (ospf+bgp) and issuing "netstat -rn |wc >> -l" command >> while quagga tries to load more than 154000 routes from its bgp >> neighbours causes this trap: This patch should fix it. The crash is caused by stale pointers, the pointers in fib_iter_state are not reloaded after seq->stop() followed by seq->start(pos > 0). --------------050304030002040403080208 Content-Type: text/plain; name="x" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="x" # This is a BitKeeper generated diff -Nru style patch. # # ChangeSet # 2005/03/09 20:41:46+01:00 kaber@coreworks.de # [IPV4]: Fix crash while reading /proc/net/route caused by stale pointers # # Signed-off-by: Patrick McHardy # # net/ipv4/fib_hash.c # 2005/03/09 20:41:37+01:00 kaber@coreworks.de +11 -1 # [IPV4]: Fix crash while reading /proc/net/route caused by stale pointers # # Signed-off-by: Patrick McHardy # diff -Nru a/net/ipv4/fib_hash.c b/net/ipv4/fib_hash.c --- a/net/ipv4/fib_hash.c 2005-03-09 20:43:55 +01:00 +++ b/net/ipv4/fib_hash.c 2005-03-09 20:43:55 +01:00 @@ -919,13 +919,23 @@ return fa; } +static struct fib_alias *fib_get_idx(struct seq_file *seq, loff_t pos) +{ + struct fib_alias *fa = fib_get_first(seq); + + if (fa) + while (pos && (fa = fib_get_next(seq))) + --pos; + return pos ? NULL : fa; +} + static void *fib_seq_start(struct seq_file *seq, loff_t *pos) { void *v = NULL; read_lock(&fib_hash_lock); if (ip_fib_main_table) - v = *pos ? fib_get_next(seq) : SEQ_START_TOKEN; + v = *pos ? fib_get_idx(seq, *pos - 1) : SEQ_START_TOKEN; return v; } --------------050304030002040403080208-- From tgraf@suug.ch Wed Mar 9 11:46:01 2005 Received: with ECARTIS (v1.0.0; list netdev); Wed, 09 Mar 2005 11:46:07 -0800 (PST) Received: from b.mx.projectdream.org (eth0-0.arisu.projectdream.org [194.158.4.191]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j29Jk0ZU000916 for ; Wed, 9 Mar 2005 11:46:00 -0800 Received: from postel.suug.ch (postel.suug.ch [195.134.158.23]) (using TLSv1 with cipher EDH-RSA-DES-CBC3-SHA (168/168 bits)) (No client certificate requested) by b.mx.projectdream.org (Postfix) with ESMTP id 099DA8C; Wed, 9 Mar 2005 20:45:38 +0100 (CET) Received: by postel.suug.ch (Postfix, from userid 10001) id 521B61C0EA; Wed, 9 Mar 2005 20:46:21 +0100 (CET) Date: Wed, 9 Mar 2005 20:46:21 +0100 From: Thomas Graf To: "David S. Miller" Cc: netdev@oss.sgi.com Subject: [PATCH 1/11] [NET] Reorder struct inet_sock Message-ID: <20050309194621.GI31837@postel.suug.ch> References: <20050309194521.GH31837@postel.suug.ch> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20050309194521.GH31837@postel.suug.ch> X-Virus-Scanned: ClamAV 0.83/757/Tue Mar 8 15:14:36 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 2729 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: tgraf@suug.ch Precedence: bulk X-list: netdev Content-Length: 1262 Lines: 40 tos: int -> 8bit uc_ttl: int -> 16 bit cmsg_flags: int -> 16 bit hdrincl: 8bit -> 1 bit mc_loop: 8bit -> 1 bit Saves 12 bytes together with the reordering. Signed-off-by: Thomas Graf diff -Nru linux-2.6.11-rc4.orig/include/linux/ip.h linux-2.6.11-rc4/include/linux/ip.h --- linux-2.6.11-rc4.orig/include/linux/ip.h 2005-03-08 18:11:22.000000000 +0100 +++ linux-2.6.11-rc4/include/linux/ip.h 2005-03-08 20:26:37.000000000 +0100 @@ -121,18 +121,18 @@ __u16 dport; /* Destination port */ __u16 num; /* Local port */ __u32 saddr; /* Sending source */ - int uc_ttl; /* Unicast TTL */ - int tos; /* TOS */ - unsigned cmsg_flags; + __s16 uc_ttl; /* Unicast TTL */ + __u16 cmsg_flags; struct ip_options *opt; __u16 sport; /* Source port */ - unsigned char hdrincl; /* Include headers ? */ + __u16 id; /* ID counter for DF pkts */ + __u8 tos; /* TOS */ __u8 mc_ttl; /* Multicasting TTL */ - __u8 mc_loop; /* Loopback */ __u8 pmtudisc; - __u16 id; /* ID counter for DF pkts */ unsigned recverr : 1, - freebind : 1; + freebind : 1, + hdrincl : 1, + mc_loop : 1; int mc_index; /* Multicast device index */ __u32 mc_addr; struct ip_mc_socklist *mc_list; /* Group array */ From tgraf@suug.ch Wed Mar 9 11:46:52 2005 Received: with ECARTIS (v1.0.0; list netdev); Wed, 09 Mar 2005 11:47:00 -0800 (PST) Received: from b.mx.projectdream.org (eth0-0.arisu.projectdream.org [194.158.4.191]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j29JkpS8001675 for ; Wed, 9 Mar 2005 11:46:51 -0800 Received: from postel.suug.ch (postel.suug.ch [195.134.158.23]) (using TLSv1 with cipher EDH-RSA-DES-CBC3-SHA (168/168 bits)) (No client certificate requested) by b.mx.projectdream.org (Postfix) with ESMTP id BAAEF8C; Wed, 9 Mar 2005 20:46:28 +0100 (CET) Received: by postel.suug.ch (Postfix, from userid 10001) id 1E94D1C0EA; Wed, 9 Mar 2005 20:47:12 +0100 (CET) Date: Wed, 9 Mar 2005 20:47:12 +0100 From: Thomas Graf To: "David S. Miller" Cc: netdev@oss.sgi.com Subject: [PATCH 2/11] [NET] Convert sk_zapped into SOCK_ZAPPED flag Message-ID: <20050309194711.GJ31837@postel.suug.ch> References: <20050309194521.GH31837@postel.suug.ch> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20050309194521.GH31837@postel.suug.ch> X-Virus-Scanned: ClamAV 0.83/757/Tue Mar 8 15:14:36 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 2730 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: tgraf@suug.ch Precedence: bulk X-list: netdev Content-Length: 24831 Lines: 875 Signed-off-by: Thomas Graf diff -Nru linux-2.6.11-rc4.orig/include/net/sock.h linux-2.6.11-rc4/include/net/sock.h --- linux-2.6.11-rc4.orig/include/net/sock.h 2005-03-08 18:11:24.000000000 +0100 +++ linux-2.6.11-rc4/include/net/sock.h 2005-03-08 23:56:08.000000000 +0100 @@ -115,7 +115,6 @@ /** * struct sock - network layer representation of sockets * @__sk_common - shared layout with tcp_tw_bucket - * @sk_zapped - ax25 & ipx means !linked * @sk_shutdown - mask of %SEND_SHUTDOWN and/or %RCV_SHUTDOWN * @sk_use_write_queue - wheter to call sk->sk_write_space in sock_wfree * @sk_userlocks - %SO_SNDBUF and %SO_RCVBUF settings @@ -191,7 +190,6 @@ #define sk_node __sk_common.skc_node #define sk_bind_node __sk_common.skc_bind_node #define sk_refcnt __sk_common.skc_refcnt - volatile unsigned char sk_zapped; unsigned char sk_shutdown; unsigned char sk_use_write_queue; unsigned char sk_userlocks; @@ -391,6 +389,7 @@ SOCK_DESTROY, SOCK_BROADCAST, SOCK_TIMESTAMP, + SOCK_ZAPPED, }; static inline void sock_set_flag(struct sock *sk, enum sock_flags flag) diff -Nru linux-2.6.11-rc4.orig/net/appletalk/ddp.c linux-2.6.11-rc4/net/appletalk/ddp.c --- linux-2.6.11-rc4.orig/net/appletalk/ddp.c 2005-03-08 18:11:29.000000000 +0100 +++ linux-2.6.11-rc4/net/appletalk/ddp.c 2005-03-08 23:51:06.000000000 +0100 @@ -1041,7 +1041,7 @@ sk_set_owner(sk, THIS_MODULE); /* Checksums on by default */ - sk->sk_zapped = 1; + sock_set_flag(sk, SOCK_ZAPPED); out: return rc; } @@ -1120,7 +1120,7 @@ n = atalk_pick_and_bind_port(sk, &sat); if (!n) - sk->sk_zapped = 0; + sock_reset_flag(sk, SOCK_ZAPPED); out: return n; } @@ -1132,7 +1132,8 @@ struct sock *sk = sock->sk; struct atalk_sock *at = at_sk(sk); - if (!sk->sk_zapped || addr_len != sizeof(struct sockaddr_at)) + if (!sock_flag(sk, SOCK_ZAPPED) || + addr_len != sizeof(struct sockaddr_at)) return -EINVAL; if (addr->sat_family != AF_APPLETALK) @@ -1167,7 +1168,7 @@ return -EADDRINUSE; } - sk->sk_zapped = 0; + sock_reset_flag(sk, SOCK_ZAPPED); return 0; } @@ -1202,7 +1203,7 @@ #endif } - if (sk->sk_zapped) + if (sock_flag(sk, SOCK_ZAPPED)) if (atalk_autobind(sk) < 0) return -EBUSY; @@ -1229,7 +1230,7 @@ struct sock *sk = sock->sk; struct atalk_sock *at = at_sk(sk); - if (sk->sk_zapped) + if (sock_flag(sk, SOCK_ZAPPED)) if (atalk_autobind(sk) < 0) return -ENOBUFS; @@ -1551,7 +1552,7 @@ return -EMSGSIZE; if (usat) { - if (sk->sk_zapped) + if (sock_flag(sk, SOCK_ZAPPED)) if (atalk_autobind(sk) < 0) return -EBUSY; diff -Nru linux-2.6.11-rc4.orig/net/ax25/af_ax25.c linux-2.6.11-rc4/net/ax25/af_ax25.c --- linux-2.6.11-rc4.orig/net/ax25/af_ax25.c 2005-03-08 18:11:28.000000000 +0100 +++ linux-2.6.11-rc4/net/ax25/af_ax25.c 2005-03-08 23:51:06.000000000 +0100 @@ -871,7 +871,9 @@ sk->sk_debug = osk->sk_debug; sk->sk_state = TCP_ESTABLISHED; sk->sk_sleep = osk->sk_sleep; - sk->sk_zapped = osk->sk_zapped; + + if (sock_flag(osk, SOCK_ZAPPED)) + sock_set_flag(sk, SOCK_ZAPPED); oax25 = ax25_sk(osk); @@ -1025,7 +1027,7 @@ lock_sock(sk); ax25 = ax25_sk(sk); - if (!sk->sk_zapped) { + if (!sock_flag(sk, SOCK_ZAPPED)) { err = -EINVAL; goto out; } @@ -1059,7 +1061,7 @@ done: ax25_cb_add(ax25); - sk->sk_zapped = 0; + sock_reset_flag(sk, SOCK_ZAPPED); out: release_sock(sk); @@ -1172,7 +1174,7 @@ * the socket is already bound, check to see if the device has * been filled in, error if it hasn't. */ - if (sk->sk_zapped) { + if (sock_flag(sk, SOCK_ZAPPED)) { /* check if we can remove this feature. It is broken. */ printk(KERN_WARNING "ax25_connect(): %s uses autobind, please contact jreuter@yaina.de\n", current->comm); @@ -1420,7 +1422,7 @@ lock_sock(sk); ax25 = ax25_sk(sk); - if (sk->sk_zapped) { + if (sock_flag(sk, SOCK_ZAPPED)) err = -EADDRNOTAVAIL; goto out; } diff -Nru linux-2.6.11-rc4.orig/net/ax25/ax25_route.c linux-2.6.11-rc4/net/ax25/ax25_route.c --- linux-2.6.11-rc4.orig/net/ax25/ax25_route.c 2005-03-08 18:11:28.000000000 +0100 +++ linux-2.6.11-rc4/net/ax25/ax25_route.c 2005-03-08 23:51:06.000000000 +0100 @@ -455,7 +455,7 @@ if (ax25->sk != NULL) { bh_lock_sock(ax25->sk); - ax25->sk->sk_zapped = 0; + sock_reset_flag(ax25->sk, SOCK_ZAPPED); bh_unlock_sock(ax25->sk); } diff -Nru linux-2.6.11-rc4.orig/net/bluetooth/af_bluetooth.c linux-2.6.11-rc4/net/bluetooth/af_bluetooth.c --- linux-2.6.11-rc4.orig/net/bluetooth/af_bluetooth.c 2005-03-08 18:11:28.000000000 +0100 +++ linux-2.6.11-rc4/net/bluetooth/af_bluetooth.c 2005-03-08 23:51:06.000000000 +0100 @@ -130,7 +130,7 @@ sock_init_data(sock, sk); INIT_LIST_HEAD(&bt_sk(sk)->accept_q); - sk->sk_zapped = 0; + sock_reset_flag(sk, SOCK_ZAPPED); sk->sk_protocol = proto; sk->sk_state = BT_OPEN; diff -Nru linux-2.6.11-rc4.orig/net/bluetooth/l2cap.c linux-2.6.11-rc4/net/bluetooth/l2cap.c --- linux-2.6.11-rc4.orig/net/bluetooth/l2cap.c 2005-03-08 18:11:28.000000000 +0100 +++ linux-2.6.11-rc4/net/bluetooth/l2cap.c 2005-03-08 23:51:06.000000000 +0100 @@ -280,7 +280,7 @@ l2cap_sock_close(sk); parent->sk_state = BT_CLOSED; - parent->sk_zapped = 1; + sock_set_flag(parent, SOCK_ZAPPED); } /* Kill socket (only if zapped and orphan) @@ -288,7 +288,7 @@ */ static void l2cap_sock_kill(struct sock *sk) { - if (!sk->sk_zapped || sk->sk_socket) + if (!sock_flag(sk, SOCK_ZAPPED) || sk->sk_socket) return; BT_DBG("sk %p state %d", sk, sk->sk_state); @@ -333,7 +333,7 @@ break; default: - sk->sk_zapped = 1; + sock_set_flag(sk, SOCK_ZAPPED); break; } } @@ -1062,7 +1062,7 @@ } sk->sk_state = BT_CLOSED; - sk->sk_zapped = 1; + sock_set_flag(sk, SOCK_ZAPPED); if (err) sk->sk_err = err; @@ -1424,7 +1424,7 @@ /* Check if we already have channel with that dcid */ if (__l2cap_get_chan_by_dcid(list, scid)) { write_unlock(&list->lock); - sk->sk_zapped = 1; + sock_set_flag(sk, SOCK_ZAPPED); l2cap_sock_kill(sk); goto response; } diff -Nru linux-2.6.11-rc4.orig/net/bluetooth/rfcomm/sock.c linux-2.6.11-rc4/net/bluetooth/rfcomm/sock.c --- linux-2.6.11-rc4.orig/net/bluetooth/rfcomm/sock.c 2005-03-08 18:11:28.000000000 +0100 +++ linux-2.6.11-rc4/net/bluetooth/rfcomm/sock.c 2005-03-08 23:51:06.000000000 +0100 @@ -105,7 +105,7 @@ parent = bt_sk(sk)->parent; if (parent) { if (d->state == BT_CLOSED) { - sk->sk_zapped = 1; + sock_set_flag(sk, SOCK_ZAPPED); bt_accept_unlink(sk); } parent->sk_data_ready(parent, 0); @@ -117,7 +117,7 @@ bh_unlock_sock(sk); - if (parent && sk->sk_zapped) { + if (parent && sock_flag(sk, SOCK_ZAPPED)) { /* We have to drop DLC lock here, otherwise * rfcomm_sock_destruct() will dead lock. */ rfcomm_dlc_unlock(d); @@ -214,7 +214,7 @@ } parent->sk_state = BT_CLOSED; - parent->sk_zapped = 1; + sock_set_flag(parent, SOCK_ZAPPED); } /* Kill socket (only if zapped and orphan) @@ -222,7 +222,7 @@ */ static void rfcomm_sock_kill(struct sock *sk) { - if (!sk->sk_zapped || sk->sk_socket) + if (!sock_flag(sk, SOCK_ZAPPED) || sk->sk_socket) return; BT_DBG("sk %p state %d refcnt %d", sk, sk->sk_state, atomic_read(&sk->sk_refcnt)); @@ -251,7 +251,7 @@ rfcomm_dlc_close(d, 0); default: - sk->sk_zapped = 1; + sock_set_flag(sk, SOCK_ZAPPED); break; } } diff -Nru linux-2.6.11-rc4.orig/net/bluetooth/sco.c linux-2.6.11-rc4/net/bluetooth/sco.c --- linux-2.6.11-rc4.orig/net/bluetooth/sco.c 2005-03-08 18:11:28.000000000 +0100 +++ linux-2.6.11-rc4/net/bluetooth/sco.c 2005-03-08 23:51:06.000000000 +0100 @@ -352,7 +352,7 @@ } parent->sk_state = BT_CLOSED; - parent->sk_zapped = 1; + sock_set_flag(sk, SOCK_ZAPPED); } /* Kill socket (only if zapped and orphan) @@ -360,7 +360,7 @@ */ static void sco_sock_kill(struct sock *sk) { - if (!sk->sk_zapped || sk->sk_socket) + if (!sock_flag(sk, SOCK_ZAPPED) || sk->sk_socket) return; BT_DBG("sk %p state %d", sk, sk->sk_state); @@ -399,7 +399,7 @@ break; default: - sk->sk_zapped = 1; + sock_set_flag(sk, SOCK_ZAPPED); break; }; @@ -778,7 +778,7 @@ sk->sk_err = err; sk->sk_state_change(sk); - sk->sk_zapped = 1; + sock_set_flag(sk, SOCK_ZAPPED); } static void sco_conn_ready(struct sco_conn *conn) diff -Nru linux-2.6.11-rc4.orig/net/core/sock.c linux-2.6.11-rc4/net/core/sock.c --- linux-2.6.11-rc4.orig/net/core/sock.c 2005-03-08 18:11:27.000000000 +0100 +++ linux-2.6.11-rc4/net/core/sock.c 2005-03-08 23:51:06.000000000 +0100 @@ -1186,9 +1186,10 @@ sk->sk_rcvbuf = sysctl_rmem_default; sk->sk_sndbuf = sysctl_wmem_default; sk->sk_state = TCP_CLOSE; - sk->sk_zapped = 1; sk->sk_socket = sock; + sock_set_flag(sk, SOCK_ZAPPED); + if(sock) { sk->sk_type = sock->type; diff -Nru linux-2.6.11-rc4.orig/net/decnet/af_decnet.c linux-2.6.11-rc4/net/decnet/af_decnet.c --- linux-2.6.11-rc4.orig/net/decnet/af_decnet.c 2005-03-08 18:11:29.000000000 +0100 +++ linux-2.6.11-rc4/net/decnet/af_decnet.c 2005-03-08 23:51:06.000000000 +0100 @@ -750,14 +750,13 @@ rv = -EINVAL; lock_sock(sk); - if (sk->sk_zapped) { + if (sock_flag(sk, SOCK_ZAPPED)) { memcpy(&scp->addr, saddr, addr_len); - sk->sk_zapped = 0; + sock_reset_flag(sk, SOCK_ZAPPED); rv = dn_hash_sock(sk); - if (rv) { - sk->sk_zapped = 1; - } + if (rv) + sock_set_flag(sk, SOCK_ZAPPED); } release_sock(sk); @@ -771,7 +770,7 @@ struct dn_scp *scp = DN_SK(sk); int rv; - sk->sk_zapped = 0; + sock_reset_flag(sk, SOCK_ZAPPED); scp->addr.sdn_flags = 0; scp->addr.sdn_objnum = 0; @@ -795,9 +794,8 @@ rv = dn_dev_bind_default((dn_address *)scp->addr.sdn_add.a_addr); if (rv == 0) { rv = dn_hash_sock(sk); - if (rv) { - sk->sk_zapped = 1; - } + if (rv) + sock_set_flag(sk, SOCK_ZAPPED); } return rv; @@ -922,7 +920,7 @@ if (addr->sdn_flags & SDF_WILD) goto out; - if (sk->sk_zapped) { + if (sock_flag(sk, SOCK_ZAPPED)) { err = dn_auto_bind(sk->sk_socket); if (err) goto out; @@ -1141,7 +1139,7 @@ lock_sock(newsk); err = dn_hash_sock(newsk); if (err == 0) { - newsk->sk_zapped = 0; + sock_reset_flag(newsk, SOCK_ZAPPED); dn_send_conn_ack(newsk); /* @@ -1259,7 +1257,7 @@ lock_sock(sk); - if (sk->sk_zapped) + if (sock_flag(sk, SOCK_ZAPPED)) goto out; if ((DN_SK(sk)->state != DN_O) || (sk->sk_state == TCP_LISTEN)) @@ -1671,7 +1669,7 @@ lock_sock(sk); - if (sk->sk_zapped) { + if (sock_flag(sk, SOCK_ZAPPED)) { rv = -EADDRNOTAVAIL; goto out; } diff -Nru linux-2.6.11-rc4.orig/net/econet/af_econet.c linux-2.6.11-rc4/net/econet/af_econet.c --- linux-2.6.11-rc4.orig/net/econet/af_econet.c 2005-03-08 18:11:29.000000000 +0100 +++ linux-2.6.11-rc4/net/econet/af_econet.c 2005-03-08 23:51:06.000000000 +0100 @@ -583,7 +583,7 @@ sk_set_owner(sk, THIS_MODULE); eo = ec_sk(sk); - sk->sk_zapped = 0; + sock_reset_flag(sk, SOCK_ZAPPED); sk->sk_family = PF_ECONET; eo->num = protocol; diff -Nru linux-2.6.11-rc4.orig/net/ipx/af_ipx.c linux-2.6.11-rc4/net/ipx/af_ipx.c --- linux-2.6.11-rc4.orig/net/ipx/af_ipx.c 2005-03-08 18:11:28.000000000 +0100 +++ linux-2.6.11-rc4/net/ipx/af_ipx.c 2005-03-08 23:51:06.000000000 +0100 @@ -310,7 +310,7 @@ s->sk_error_report(s); ipxs->intrfc = NULL; ipxs->port = 0; - s->sk_zapped = 1; /* Indicates it is no longer bound */ + sock_set_flag(s, SOCK_ZAPPED); /* Indicates it is no longer bound */ sk_del_node_init(s); } INIT_HLIST_HEAD(&intrfc->if_sklist); @@ -1427,7 +1427,7 @@ struct sockaddr_ipx *addr = (struct sockaddr_ipx *)uaddr; int rc = -EINVAL; - if (!sk->sk_zapped || addr_len != sizeof(struct sockaddr_ipx)) + if (!sock_flag(sk, SOCK_ZAPPED) || addr_len != sizeof(struct sockaddr_ipx)) goto out; intrfc = ipxitf_find_using_net(addr->sipx_network); @@ -1505,7 +1505,7 @@ #endif /* CONFIG_IPX_INTERN */ ipxitf_insert_socket(intrfc, sk); - sk->sk_zapped = 0; + sock_reset_flag(sk, SOCK_ZAPPED); rc = 0; out_put: @@ -1774,7 +1774,7 @@ } rc = -ENOTCONN; - if (sk->sk_zapped) + if (sock_flag(sk, SOCK_ZAPPED)) goto out; skb = skb_recv_datagram(sk, flags & ~MSG_DONTWAIT, diff -Nru linux-2.6.11-rc4.orig/net/llc/af_llc.c linux-2.6.11-rc4/net/llc/af_llc.c --- linux-2.6.11-rc4.orig/net/llc/af_llc.c 2005-03-08 18:11:28.000000000 +0100 +++ linux-2.6.11-rc4/net/llc/af_llc.c 2005-03-08 23:51:06.000000000 +0100 @@ -180,7 +180,7 @@ llc->laddr.lsap, llc->daddr.lsap); if (!llc_send_disc(sk)) llc_ui_wait_for_disc(sk, sk->sk_rcvtimeo); - if (!sk->sk_zapped) + if (!sock_flag(sk, SOCK_ZAPPED)) llc_sap_remove_socket(llc->sap, sk); release_sock(sk); if (llc->sap && hlist_empty(&llc->sap->sk_list.list)) { @@ -248,7 +248,7 @@ struct llc_sap *sap; int rc = -EINVAL; - if (!sk->sk_zapped) + if (!sock_flag(sk, SOCK_ZAPPED)) goto out; rc = -ENODEV; llc->dev = dev_getfirstbyhwtype(addr->sllc_arphrd); @@ -266,7 +266,8 @@ memcpy(&llc->addr, addr, sizeof(llc->addr)); /* assign new connection to its SAP */ llc_sap_add_socket(sap, sk); - rc = sk->sk_zapped = 0; + sock_reset_flag(sk, SOCK_ZAPPED); + rc = 0; out: return rc; } @@ -298,7 +299,7 @@ int rc = -EINVAL; dprintk("%s: binding %02X\n", __FUNCTION__, addr->sllc_sap); - if (!sk->sk_zapped || addrlen != sizeof(*addr)) + if (!sock_flag(sk, SOCK_ZAPPED) || addrlen != sizeof(*addr)) goto out; rc = -EAFNOSUPPORT; if (addr->sllc_family != AF_LLC) @@ -339,7 +340,8 @@ memcpy(&llc->addr, addr, sizeof(llc->addr)); /* assign new connection to its SAP */ llc_sap_add_socket(sap, sk); - rc = sk->sk_zapped = 0; + sock_reset_flag(sk, SOCK_ZAPPED); + rc = 0; out: return rc; } @@ -406,7 +408,7 @@ if (addr->sllc_family != AF_LLC) goto out; /* bind connection to sap if user hasn't done it. */ - if (sk->sk_zapped) { + if (sock_flag(sk, SOCK_ZAPPED)) { /* bind to sap with null dev, exclusive */ rc = llc_ui_autobind(sock, addr); if (rc) @@ -459,7 +461,7 @@ if (sk->sk_type != SOCK_STREAM) goto out; rc = -EAGAIN; - if (sk->sk_zapped) + if (sock_flag(sk, SOCK_ZAPPED)) goto out; rc = 0; if (!(unsigned)backlog) /* BSDism */ @@ -638,7 +640,7 @@ newsk = skb->sk; /* attach connection to a new socket. */ llc_ui_sk_init(newsock, newsk); - newsk->sk_zapped = 0; + sock_reset_flag(newsk, SOCK_ZAPPED); newsk->sk_state = TCP_ESTABLISHED; newsock->state = SS_CONNECTED; llc = llc_sk(sk); @@ -749,7 +751,7 @@ addr = &llc->addr; } /* must bind connection to sap if user hasn't done it. */ - if (sk->sk_zapped) { + if (sock_flag(sk, SOCK_ZAPPED)) { /* bind to sap with null dev, exclusive. */ rc = llc_ui_autobind(sock, addr); if (rc) @@ -823,7 +825,7 @@ int rc = 0; lock_sock(sk); - if (sk->sk_zapped) + if (sock_flag(sk, SOCK_ZAPPED)) goto out; *uaddrlen = sizeof(sllc); memset(uaddr, 0, *uaddrlen); diff -Nru linux-2.6.11-rc4.orig/net/netrom/af_netrom.c linux-2.6.11-rc4/net/netrom/af_netrom.c --- linux-2.6.11-rc4.orig/net/netrom/af_netrom.c 2005-03-08 18:11:29.000000000 +0100 +++ linux-2.6.11-rc4/net/netrom/af_netrom.c 2005-03-08 23:51:06.000000000 +0100 @@ -479,7 +479,9 @@ sk->sk_debug = osk->sk_debug; sk->sk_state = TCP_ESTABLISHED; sk->sk_sleep = osk->sk_sleep; - sk->sk_zapped = osk->sk_zapped; + + if (sock_flag(osk, SOCK_ZAPPED)) + sock_set_flag(sk, SOCK_ZAPPED); skb_queue_head_init(&nr->ack_queue); skb_queue_head_init(&nr->reseq_queue); @@ -559,7 +561,7 @@ ax25_address *user, *source; lock_sock(sk); - if (!sk->sk_zapped) { + if (!sock_flag(sk, SOCK_ZAPPED)) { release_sock(sk); return -EINVAL; } @@ -611,7 +613,7 @@ nr->device = dev; nr_insert_socket(sk); - sk->sk_zapped = 0; + sock_reset_flag(sk, SOCK_ZAPPED); dev_put(dev); release_sock(sk); SOCK_DEBUG(sk, "NET/ROM: socket is bound\n"); @@ -656,8 +658,8 @@ release_sock(sk); return -EINVAL; } - if (sk->sk_zapped) { /* Must bind first - autobinding in this may or may not work */ - sk->sk_zapped = 0; + if (sock_flag(sk, SOCK_ZAPPED)) { /* Must bind first - autobinding in this may or may not work */ + sock_reset_flag(sk, SOCK_ZAPPED); if ((dev = nr_dev_first()) == NULL) { release_sock(sk); @@ -1024,7 +1026,7 @@ return -EINVAL; lock_sock(sk); - if (sk->sk_zapped) { + if (sock_flag(sk, SOCK_ZAPPED)) { err = -EADDRNOTAVAIL; goto out; } diff -Nru linux-2.6.11-rc4.orig/net/rose/af_rose.c linux-2.6.11-rc4/net/rose/af_rose.c --- linux-2.6.11-rc4.orig/net/rose/af_rose.c 2005-03-08 18:11:28.000000000 +0100 +++ linux-2.6.11-rc4/net/rose/af_rose.c 2005-03-08 23:51:06.000000000 +0100 @@ -575,7 +575,9 @@ sk->sk_debug = osk->sk_debug; sk->sk_state = TCP_ESTABLISHED; sk->sk_sleep = osk->sk_sleep; - sk->sk_zapped = osk->sk_zapped; + + if (sock_flag(osk, SOCK_ZAPPED)) + sock_set_flag(sk, SOCK_ZAPPED); init_timer(&rose->timer); init_timer(&rose->idletimer); @@ -648,7 +650,7 @@ ax25_address *user, *source; int n; - if (!sk->sk_zapped) + if (!sock_flag(sk, SOCK_ZAPPED)) return -EINVAL; if (addr_len != sizeof(struct sockaddr_rose) && addr_len != sizeof(struct full_sockaddr_rose)) @@ -693,7 +695,7 @@ rose_insert_socket(sk); - sk->sk_zapped = 0; + sock_reset_flag(sk, SOCK_ZAPPED); SOCK_DEBUG(sk, "ROSE: socket is bound\n"); return 0; } @@ -749,8 +751,8 @@ if (!rose->lci) return -ENETUNREACH; - if (sk->sk_zapped) { /* Must bind first - autobinding in this may or may not work */ - sk->sk_zapped = 0; + if (sock_flag(sk, SOCK_ZAPPED)) { /* Must bind first - autobinding in this may or may not work */ + sock_reset_flag(sk, SOCK_ZAPPED); if ((dev = rose_dev_first()) == NULL) return -ENETUNREACH; @@ -1023,7 +1025,7 @@ if (msg->msg_flags & ~(MSG_DONTWAIT|MSG_EOR|MSG_CMSG_COMPAT)) return -EINVAL; - if (sk->sk_zapped) + if (sock_flag(sk, SOCK_ZAPPED)) return -EADDRNOTAVAIL; if (sk->sk_shutdown & SEND_SHUTDOWN) { diff -Nru linux-2.6.11-rc4.orig/net/sctp/ipv6.c linux-2.6.11-rc4/net/sctp/ipv6.c --- linux-2.6.11-rc4.orig/net/sctp/ipv6.c 2005-03-08 18:11:28.000000000 +0100 +++ linux-2.6.11-rc4/net/sctp/ipv6.c 2005-03-08 23:51:06.000000000 +0100 @@ -609,11 +609,11 @@ newsk->sk_reuse = sk->sk_reuse; newsk->sk_destruct = inet_sock_destruct; - newsk->sk_zapped = 0; newsk->sk_family = PF_INET6; newsk->sk_protocol = IPPROTO_SCTP; newsk->sk_backlog_rcv = sk->sk_prot->backlog_rcv; newsk->sk_shutdown = sk->sk_shutdown; + sock_reset_flag(sk, SOCK_ZAPPED); newsctp6sk = (struct sctp6_sock *)newsk; inet_sk(newsk)->pinet6 = &newsctp6sk->inet6; diff -Nru linux-2.6.11-rc4.orig/net/sctp/protocol.c linux-2.6.11-rc4/net/sctp/protocol.c --- linux-2.6.11-rc4.orig/net/sctp/protocol.c 2005-03-08 18:11:28.000000000 +0100 +++ linux-2.6.11-rc4/net/sctp/protocol.c 2005-03-08 23:51:06.000000000 +0100 @@ -570,10 +570,10 @@ newsk->sk_shutdown = sk->sk_shutdown; newsk->sk_destruct = inet_sock_destruct; - newsk->sk_zapped = 0; newsk->sk_family = PF_INET; newsk->sk_protocol = IPPROTO_SCTP; newsk->sk_backlog_rcv = sk->sk_prot->backlog_rcv; + sock_reset_flag(newsk, SOCK_ZAPPED); newinet = inet_sk(newsk); diff -Nru linux-2.6.11-rc4.orig/net/sunrpc/xprt.c linux-2.6.11-rc4/net/sunrpc/xprt.c --- linux-2.6.11-rc4.orig/net/sunrpc/xprt.c 2005-03-08 18:11:28.000000000 +0100 +++ linux-2.6.11-rc4/net/sunrpc/xprt.c 2005-03-08 23:51:06.000000000 +0100 @@ -1044,7 +1044,8 @@ dprintk("RPC: tcp_state_change client %p...\n", xprt); dprintk("RPC: state %x conn %d dead %d zapped %d\n", sk->sk_state, xprt_connected(xprt), - sock_flag(sk, SOCK_DEAD), sk->sk_zapped); + sock_flag(sk, SOCK_DEAD), + sock_flag(sk, SOCK_ZAPPED)); switch (sk->sk_state) { case TCP_ESTABLISHED: diff -Nru linux-2.6.11-rc4.orig/net/wanrouter/af_wanpipe.c linux-2.6.11-rc4/net/wanrouter/af_wanpipe.c --- linux-2.6.11-rc4.orig/net/wanrouter/af_wanpipe.c 2005-03-08 18:11:28.000000000 +0100 +++ linux-2.6.11-rc4/net/wanrouter/af_wanpipe.c 2005-03-08 23:51:06.000000000 +0100 @@ -394,7 +394,7 @@ chan->lcn = mbox_ptr->cmd.lcn; card->u.x.svc_to_dev_map[(chan->lcn%MAX_X25_LCN)] = dev; - newsk->sk_zapped = 0; + sock_reset_flag(newsk, SOCK_ZAPPED); newwp->num = htons(X25_PROT); if (wanpipe_do_bind(newsk, dev, newwp->num)) { @@ -546,7 +546,7 @@ int ifindex, err, reserve = 0; - if (!sk->sk_zapped) + if (!sock_flag(sk, SOCK_ZAPPED)) return -ENETDOWN; if (sk->sk_state != WANSOCK_CONNECTED) @@ -672,7 +672,7 @@ return; } - if (sk->sk_state != WANSOCK_CONNECTED || !sk->sk_zapped) { + if (sk->sk_state != WANSOCK_CONNECTED || !sock_flag(sk, SOCK_ZAPPED)) { clear_bit(0, &wp->timer); DBG_PRINTK(KERN_INFO "wansock: Tx Timer, State not CONNECTED\n"); return; @@ -865,7 +865,7 @@ struct net_device *dev; wanpipe_common_t *chan=NULL; - sk->sk_zapped = 0; + sock_reset_flag(sk, SOCK_ZAPPED); sk->sk_state = WANSOCK_DISCONNECTED; wp_sk(sk)->dev = NULL; @@ -914,7 +914,7 @@ chan->mbox = wp->mbox; chan->tx_timer = &wp->tx_timer; wp->dev = dev; - sk->sk_zapped = 1; + sock_set_flag(sk, SOCK_ZAPPED); clear_bit(0,&chan->common_critical); } @@ -964,7 +964,7 @@ */ if (wp->num == htons(X25_PROT) && - sk->sk_state != WANSOCK_DISCONNECTED && sk->sk_zapped) { + sk->sk_state != WANSOCK_DISCONNECTED && sock_flag(sk, SOCK_ZAPPED)) { struct net_device *dev = dev_get_by_index(sk->sk_bound_dev_if); wanpipe_common_t *chan; if (dev){ @@ -1075,15 +1075,15 @@ } kfree_skb(skb); } - if (sk->sk_zapped) + if (sock_flag(sk, SOCK_ZAPPED)) wanpipe_unlink_card(sk); }else{ - if (sk->sk_zapped) + if (sock_flag(sk, SOCK_ZAPPED)) wanpipe_unlink_driver(sk); } sk->sk_state = WANSOCK_DISCONNECTED; sk->sk_bound_dev_if = 0; - sk->sk_zapped = 0; + sock_reset_flag(sk, SOCK_ZAPPED); wp = wp_sk(sk); if (wp && wp->mbox) { @@ -1261,7 +1261,7 @@ wanpipe_common_t *chan=NULL; int err=0; - if (sk->sk_zapped) { + if (sock_flag(sk, SOCK_ZAPPED)) { err = -EALREADY; goto bind_unlock_exit; } @@ -1515,7 +1515,7 @@ sock->ops = &wanpipe_ops; sock_init_data(sock,sk); - sk->sk_zapped = 0; + sock_reset_flag(sk, SOCK_ZAPPED); sk->sk_family = PF_WANPIPE; wp_sk(sk)->num = protocol; sk->sk_state = WANSOCK_DISCONNECTED; @@ -1721,7 +1721,7 @@ case NETDEV_UNREGISTER: if (dev->ifindex == sk->sk_bound_dev_if) { printk(KERN_INFO "wansock: Device down %s\n",dev->name); - if (sk->sk_zapped) { + if (sock_flag(sk, SOCK_ZAPPED)) { wanpipe_unlink_driver(sk); sk->sk_err = ENETDOWN; sk->sk_error_report(sk); @@ -1737,7 +1737,7 @@ break; case NETDEV_UP: if (dev->ifindex == sk->sk_bound_dev_if && - po->num && !sk->sk_zapped) { + po->num && !sock_flag(sk, SOCK_ZAPPED)) { printk(KERN_INFO "wansock: Registering Device: %s\n", dev->name); wanpipe_link_driver(dev,sk); @@ -2160,7 +2160,7 @@ card->sk=sk; card->func=wanpipe_listen_rcv; - sk->sk_zapped = 1; + sock_set_flag(sk, SOCK_ZAPPED); return 0; } @@ -2504,7 +2504,7 @@ dev_put(dev); - if (!sk->sk_zapped) /* Must bind first - autobinding does not work */ + if (!sock_flag(sk, SOCK_ZAPPED)) /* Must bind first - autobinding does not work */ return -EINVAL; sock->state = SS_CONNECTING; diff -Nru linux-2.6.11-rc4.orig/net/x25/af_x25.c linux-2.6.11-rc4/net/x25/af_x25.c --- linux-2.6.11-rc4.orig/net/x25/af_x25.c 2005-03-08 18:11:28.000000000 +0100 +++ linux-2.6.11-rc4/net/x25/af_x25.c 2005-03-08 23:51:06.000000000 +0100 @@ -528,9 +528,11 @@ sk->sk_debug = osk->sk_debug; sk->sk_state = TCP_ESTABLISHED; sk->sk_sleep = osk->sk_sleep; - sk->sk_zapped = osk->sk_zapped; sk->sk_backlog_rcv = osk->sk_backlog_rcv; + if (sock_flag(osk, SOCK_ZAPPED)) + sock_set_flag(sk, SOCK_ZAPPED); + ox25 = x25_sk(osk); x25->t21 = ox25->t21; x25->t22 = ox25->t22; @@ -588,14 +590,14 @@ struct sock *sk = sock->sk; struct sockaddr_x25 *addr = (struct sockaddr_x25 *)uaddr; - if (!sk->sk_zapped || + if (!sock_flag(sk, SOCK_ZAPPED) || addr_len != sizeof(struct sockaddr_x25) || addr->sx25_family != AF_X25) return -EINVAL; x25_sk(sk)->source_addr = addr->sx25_addr; x25_insert_socket(sk); - sk->sk_zapped = 0; + sock_reset_flag(sk, SOCK_ZAPPED); SOCK_DEBUG(sk, "x25_bind: socket is bound\n"); return 0; @@ -679,7 +681,7 @@ goto out_put_neigh; rc = -EINVAL; - if (sk->sk_zapped) /* Must bind first - autobinding does not work */ + if (sock_flag(sk, SOCK_ZAPPED)) /* Must bind first - autobinding does not work */ goto out_put_neigh; if (!strcmp(x25->source_addr.x25_addr, null_x25_address.x25_addr)) @@ -942,7 +944,7 @@ goto out; rc = -EADDRNOTAVAIL; - if (sk->sk_zapped) + if (sock_flag(sk, SOCK_ZAPPED)) goto out; rc = -EPIPE; From tgraf@suug.ch Wed Mar 9 11:47:23 2005 Received: with ECARTIS (v1.0.0; list netdev); Wed, 09 Mar 2005 11:47:28 -0800 (PST) Received: from b.mx.projectdream.org (eth0-0.arisu.projectdream.org [194.158.4.191]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j29JlMPZ002053 for ; Wed, 9 Mar 2005 11:47:22 -0800 Received: from postel.suug.ch (postel.suug.ch [195.134.158.23]) (using TLSv1 with cipher EDH-RSA-DES-CBC3-SHA (168/168 bits)) (No client certificate requested) by b.mx.projectdream.org (Postfix) with ESMTP id 08ED28C; Wed, 9 Mar 2005 20:47:00 +0100 (CET) Received: by postel.suug.ch (Postfix, from userid 10001) id 5E9961C0EA; Wed, 9 Mar 2005 20:47:43 +0100 (CET) Date: Wed, 9 Mar 2005 20:47:43 +0100 From: Thomas Graf To: "David S. Miller" Cc: netdev@oss.sgi.com Subject: [PATCH 3/11] [NET] Convert sk_user_write_queue into SOCK_USE_WRITE_QUEUE flag Message-ID: <20050309194743.GK31837@postel.suug.ch> References: <20050309194521.GH31837@postel.suug.ch> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20050309194521.GH31837@postel.suug.ch> X-Virus-Scanned: ClamAV 0.83/757/Tue Mar 8 15:14:36 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 2731 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: tgraf@suug.ch Precedence: bulk X-list: netdev Content-Length: 3180 Lines: 78 Signed-off-by: Thomas Graf diff -Nru linux-2.6.11-rc4.orig/include/net/sock.h linux-2.6.11-rc4/include/net/sock.h --- linux-2.6.11-rc4.orig/include/net/sock.h 2005-03-09 00:21:18.000000000 +0100 +++ linux-2.6.11-rc4/include/net/sock.h 2005-03-09 00:21:55.000000000 +0100 @@ -116,7 +116,6 @@ * struct sock - network layer representation of sockets * @__sk_common - shared layout with tcp_tw_bucket * @sk_shutdown - mask of %SEND_SHUTDOWN and/or %RCV_SHUTDOWN - * @sk_use_write_queue - wheter to call sk->sk_write_space in sock_wfree * @sk_userlocks - %SO_SNDBUF and %SO_RCVBUF settings * @sk_lock - synchronizer * @sk_rcvbuf - size of receive buffer in bytes @@ -191,7 +190,6 @@ #define sk_bind_node __sk_common.skc_bind_node #define sk_refcnt __sk_common.skc_refcnt unsigned char sk_shutdown; - unsigned char sk_use_write_queue; unsigned char sk_userlocks; socket_lock_t sk_lock; int sk_rcvbuf; @@ -390,6 +388,7 @@ SOCK_BROADCAST, SOCK_TIMESTAMP, SOCK_ZAPPED, + SOCK_USE_WRITE_QUEUE, /* wheter to call sk->sk_write_space in sock_wfree */ }; static inline void sock_set_flag(struct sock *sk, enum sock_flags flag) diff -Nru linux-2.6.11-rc4.orig/net/core/sock.c linux-2.6.11-rc4/net/core/sock.c --- linux-2.6.11-rc4.orig/net/core/sock.c 2005-03-09 00:21:19.000000000 +0100 +++ linux-2.6.11-rc4/net/core/sock.c 2005-03-09 00:19:39.000000000 +0100 @@ -709,7 +709,7 @@ /* In case it might be waiting for more memory. */ atomic_sub(skb->truesize, &sk->sk_wmem_alloc); - if (!sk->sk_use_write_queue) + if (!sock_flag(sk, SOCK_USE_WRITE_QUEUE)) sk->sk_write_space(sk); sock_put(sk); } diff -Nru linux-2.6.11-rc4.orig/net/ipv4/tcp_ipv4.c linux-2.6.11-rc4/net/ipv4/tcp_ipv4.c --- linux-2.6.11-rc4.orig/net/ipv4/tcp_ipv4.c 2005-03-08 18:11:28.000000000 +0100 +++ linux-2.6.11-rc4/net/ipv4/tcp_ipv4.c 2005-03-09 00:19:55.000000000 +0100 @@ -2064,7 +2064,7 @@ sk->sk_state = TCP_CLOSE; sk->sk_write_space = sk_stream_write_space; - sk->sk_use_write_queue = 1; + sock_set_flag(sk, SOCK_USE_WRITE_QUEUE); tp->af_specific = &ipv4_specific; diff -Nru linux-2.6.11-rc4.orig/net/ipv6/tcp_ipv6.c linux-2.6.11-rc4/net/ipv6/tcp_ipv6.c --- linux-2.6.11-rc4.orig/net/ipv6/tcp_ipv6.c 2005-03-08 18:11:28.000000000 +0100 +++ linux-2.6.11-rc4/net/ipv6/tcp_ipv6.c 2005-03-09 00:20:06.000000000 +0100 @@ -2027,7 +2027,7 @@ tp->af_specific = &ipv6_specific; sk->sk_write_space = sk_stream_write_space; - sk->sk_use_write_queue = 1; + sock_set_flag(sk, SOCK_USE_WRITE_QUEUE); sk->sk_sndbuf = sysctl_tcp_wmem[1]; sk->sk_rcvbuf = sysctl_tcp_rmem[1]; diff -Nru linux-2.6.11-rc4.orig/net/sctp/endpointola.c linux-2.6.11-rc4/net/sctp/endpointola.c --- linux-2.6.11-rc4.orig/net/sctp/endpointola.c 2005-03-08 18:11:28.000000000 +0100 +++ linux-2.6.11-rc4/net/sctp/endpointola.c 2005-03-09 00:20:42.000000000 +0100 @@ -126,7 +126,7 @@ /* Use SCTP specific send buffer space queues. */ sk->sk_write_space = sctp_write_space; - sk->sk_use_write_queue = 1; + sock_set_flag(sk, SOCK_USE_WRITE_QUEUE); /* Initialize the secret key used with cookie. */ get_random_bytes(&ep->secret_key[0], SCTP_SECRET_SIZE); From tgraf@suug.ch Wed Mar 9 11:47:59 2005 Received: with ECARTIS (v1.0.0; list netdev); Wed, 09 Mar 2005 11:48:04 -0800 (PST) Received: from b.mx.projectdream.org (eth0-0.arisu.projectdream.org [194.158.4.191]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j29JlwLD002728 for ; Wed, 9 Mar 2005 11:47:59 -0800 Received: from postel.suug.ch (postel.suug.ch [195.134.158.23]) (using TLSv1 with cipher EDH-RSA-DES-CBC3-SHA (168/168 bits)) (No client certificate requested) by b.mx.projectdream.org (Postfix) with ESMTP id 60AF48C; Wed, 9 Mar 2005 20:47:36 +0100 (CET) Received: by postel.suug.ch (Postfix, from userid 10001) id BA3EC1C0EA; Wed, 9 Mar 2005 20:48:19 +0100 (CET) Date: Wed, 9 Mar 2005 20:48:19 +0100 From: Thomas Graf To: "David S. Miller" Cc: netdev@oss.sgi.com Subject: [PATCH 4/11] [NET] Convert sk_debug into SOCK_DBG flag Message-ID: <20050309194819.GL31837@postel.suug.ch> References: <20050309194521.GH31837@postel.suug.ch> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20050309194521.GH31837@postel.suug.ch> X-Virus-Scanned: ClamAV 0.83/757/Tue Mar 8 15:14:36 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 2732 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: tgraf@suug.ch Precedence: bulk X-list: netdev Content-Length: 5668 Lines: 161 Signed-off-by: Thomas Graf diff -Nru linux-2.6.11-rc4.orig/include/net/sock.h linux-2.6.11-rc4/include/net/sock.h --- linux-2.6.11-rc4.orig/include/net/sock.h 2005-03-09 00:40:06.000000000 +0100 +++ linux-2.6.11-rc4/include/net/sock.h 2005-03-09 00:49:23.000000000 +0100 @@ -61,10 +61,10 @@ * the other protocols. */ -/* Define this to get the sk->sk_debug debugging facility. */ +/* Define this to get the SOCK_DBG debugging facility. */ #define SOCK_DEBUGGING #ifdef SOCK_DEBUGGING -#define SOCK_DEBUG(sk, msg...) do { if ((sk) && ((sk)->sk_debug)) \ +#define SOCK_DEBUG(sk, msg...) do { if ((sk) && sock_flag((sk), SOCK_DBG)) \ printk(KERN_DEBUG msg); } while (0) #else #define SOCK_DEBUG(sk, msg...) do { } while (0) @@ -134,7 +134,6 @@ * @sk_sndbuf - size of send buffer in bytes * @sk_flags - %SO_LINGER (l_onoff), %SO_BROADCAST, %SO_KEEPALIVE, %SO_OOBINLINE settings * @sk_no_check - %SO_NO_CHECK setting, wether or not checkup packets - * @sk_debug - %SO_DEBUG setting * @sk_rcvtstamp - %SO_TIMESTAMP setting * @sk_no_largesend - whether to sent large segments or not * @sk_route_caps - route capabilities (e.g. %NETIF_F_TSO) @@ -208,7 +207,6 @@ int sk_sndbuf; unsigned long sk_flags; char sk_no_check; - unsigned char sk_debug; unsigned char sk_rcvtstamp; unsigned char sk_no_largesend; int sk_route_caps; @@ -389,6 +387,7 @@ SOCK_TIMESTAMP, SOCK_ZAPPED, SOCK_USE_WRITE_QUEUE, /* wheter to call sk->sk_write_space in sock_wfree */ + SOCK_DBG, /* %SO_DEBUG setting */ }; static inline void sock_set_flag(struct sock *sk, enum sock_flags flag) diff -Nru linux-2.6.11-rc4.orig/net/ax25/af_ax25.c linux-2.6.11-rc4/net/ax25/af_ax25.c --- linux-2.6.11-rc4.orig/net/ax25/af_ax25.c 2005-03-09 00:21:19.000000000 +0100 +++ linux-2.6.11-rc4/net/ax25/af_ax25.c 2005-03-09 00:43:51.000000000 +0100 @@ -868,10 +868,12 @@ sk->sk_protocol = osk->sk_protocol; sk->sk_rcvbuf = osk->sk_rcvbuf; sk->sk_sndbuf = osk->sk_sndbuf; - sk->sk_debug = osk->sk_debug; sk->sk_state = TCP_ESTABLISHED; sk->sk_sleep = osk->sk_sleep; + if (sock_flag(osk, SOCK_DBG)) + sock_set_flag(sk, SOCK_DBG); + if (sock_flag(osk, SOCK_ZAPPED)) sock_set_flag(sk, SOCK_ZAPPED); diff -Nru linux-2.6.11-rc4.orig/net/core/sock.c linux-2.6.11-rc4/net/core/sock.c --- linux-2.6.11-rc4.orig/net/core/sock.c 2005-03-09 00:40:06.000000000 +0100 +++ linux-2.6.11-rc4/net/core/sock.c 2005-03-09 00:45:23.000000000 +0100 @@ -228,8 +228,10 @@ { ret = -EACCES; } + else if (valbool) + sock_set_flag(sk, SOCK_DBG); else - sk->sk_debug = valbool; + sock_reset_flag(sk, SOCK_DBG); break; case SO_REUSEADDR: sk->sk_reuse = valbool; @@ -463,7 +465,7 @@ switch(optname) { case SO_DEBUG: - v.val = sk->sk_debug; + v.val = sock_flag(sk, SOCK_DBG); break; case SO_DONTROUTE: diff -Nru linux-2.6.11-rc4.orig/net/netrom/af_netrom.c linux-2.6.11-rc4/net/netrom/af_netrom.c --- linux-2.6.11-rc4.orig/net/netrom/af_netrom.c 2005-03-09 00:21:19.000000000 +0100 +++ linux-2.6.11-rc4/net/netrom/af_netrom.c 2005-03-09 00:46:08.000000000 +0100 @@ -476,13 +476,15 @@ sk->sk_protocol = osk->sk_protocol; sk->sk_rcvbuf = osk->sk_rcvbuf; sk->sk_sndbuf = osk->sk_sndbuf; - sk->sk_debug = osk->sk_debug; sk->sk_state = TCP_ESTABLISHED; sk->sk_sleep = osk->sk_sleep; if (sock_flag(osk, SOCK_ZAPPED)) sock_set_flag(sk, SOCK_ZAPPED); + if (sock_flag(osk, SOCK_DBG)) + sock_set_flag(sk, SOCK_DBG); + skb_queue_head_init(&nr->ack_queue); skb_queue_head_init(&nr->reseq_queue); skb_queue_head_init(&nr->frag_queue); diff -Nru linux-2.6.11-rc4.orig/net/rose/af_rose.c linux-2.6.11-rc4/net/rose/af_rose.c --- linux-2.6.11-rc4.orig/net/rose/af_rose.c 2005-03-09 00:21:19.000000000 +0100 +++ linux-2.6.11-rc4/net/rose/af_rose.c 2005-03-09 00:46:28.000000000 +0100 @@ -572,13 +572,15 @@ sk->sk_protocol = osk->sk_protocol; sk->sk_rcvbuf = osk->sk_rcvbuf; sk->sk_sndbuf = osk->sk_sndbuf; - sk->sk_debug = osk->sk_debug; sk->sk_state = TCP_ESTABLISHED; sk->sk_sleep = osk->sk_sleep; if (sock_flag(osk, SOCK_ZAPPED)) sock_set_flag(sk, SOCK_ZAPPED); + if (sock_flag(osk, SOCK_DBG)) + sock_set_flag(sk, SOCK_DBG); + init_timer(&rose->timer); init_timer(&rose->idletimer); diff -Nru linux-2.6.11-rc4.orig/net/wanrouter/af_wanpipe.c linux-2.6.11-rc4/net/wanrouter/af_wanpipe.c --- linux-2.6.11-rc4.orig/net/wanrouter/af_wanpipe.c 2005-03-09 00:21:19.000000000 +0100 +++ linux-2.6.11-rc4/net/wanrouter/af_wanpipe.c 2005-03-09 00:46:50.000000000 +0100 @@ -468,10 +468,12 @@ wp_sk(sk)->num = wp_sk(osk)->num; sk->sk_rcvbuf = osk->sk_rcvbuf; sk->sk_sndbuf = osk->sk_sndbuf; - sk->sk_debug = osk->sk_debug; sk->sk_state = WANSOCK_CONNECTING; sk->sk_sleep = osk->sk_sleep; + if (sock_flag(osk, SOCK_DBG)) + sock_set_flag(sk, SOCK_DBG); + return sk; } diff -Nru linux-2.6.11-rc4.orig/net/x25/af_x25.c linux-2.6.11-rc4/net/x25/af_x25.c --- linux-2.6.11-rc4.orig/net/x25/af_x25.c 2005-03-09 00:21:19.000000000 +0100 +++ linux-2.6.11-rc4/net/x25/af_x25.c 2005-03-09 00:47:10.000000000 +0100 @@ -525,13 +525,15 @@ sk->sk_protocol = osk->sk_protocol; sk->sk_rcvbuf = osk->sk_rcvbuf; sk->sk_sndbuf = osk->sk_sndbuf; - sk->sk_debug = osk->sk_debug; sk->sk_state = TCP_ESTABLISHED; sk->sk_sleep = osk->sk_sleep; sk->sk_backlog_rcv = osk->sk_backlog_rcv; if (sock_flag(osk, SOCK_ZAPPED)) sock_set_flag(sk, SOCK_ZAPPED); + + if (sock_flag(osk, SOCK_DBG)) + sock_set_flag(sk, SOCK_DBG); ox25 = x25_sk(osk); x25->t21 = ox25->t21; From jgarzik@pobox.com Wed Mar 9 11:48:18 2005 Received: with ECARTIS (v1.0.0; list netdev); Wed, 09 Mar 2005 11:48:23 -0800 (PST) Received: from parcelfarce.linux.theplanet.co.uk (IDENT:93@parcelfarce.linux.theplanet.co.uk [195.92.249.252]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j29JmHbp003057 for ; Wed, 9 Mar 2005 11:48:18 -0800 Received: from [69.134.152.124] (helo=[10.10.10.88]) by parcelfarce.linux.theplanet.co.uk with asmtp (TLSv1:AES256-SHA:256) (Exim 4.33) id 1D97AE-00017q-ND; Wed, 09 Mar 2005 19:48:14 +0000 Message-ID: <422F52ED.2060606@pobox.com> Date: Wed, 09 Mar 2005 14:47:57 -0500 From: Jeff Garzik User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.3) Gecko/20040922 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Stephen Hemminger CC: Francois Romieu , netdev@oss.sgi.com Subject: Re: [PATCH 1/5] r8169: auto detect 32-bit slot References: <20050309112925.7f7900ab@dxpl.pdx.osdl.net> In-Reply-To: <20050309112925.7f7900ab@dxpl.pdx.osdl.net> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV 0.83/757/Tue Mar 8 15:14:36 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 2733 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: jgarzik@pobox.com Precedence: bulk X-list: netdev Content-Length: 280 Lines: 9 Stephen Hemminger wrote: > Change driver to auto-detect when the board is in a 32-bit PCI slot and > avoid setting 64-bit dma mask. The module parameter method is no longer needed. > > Signed-off-by: Stephen Hemminger need to set consistent DMA mask too From tgraf@suug.ch Wed Mar 9 11:48:27 2005 Received: with ECARTIS (v1.0.0; list netdev); Wed, 09 Mar 2005 11:48:32 -0800 (PST) Received: from b.mx.projectdream.org (eth0-0.arisu.projectdream.org [194.158.4.191]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j29JmPNS003215 for ; Wed, 9 Mar 2005 11:48:26 -0800 Received: from postel.suug.ch (postel.suug.ch [195.134.158.23]) (using TLSv1 with cipher EDH-RSA-DES-CBC3-SHA (168/168 bits)) (No client certificate requested) by b.mx.projectdream.org (Postfix) with ESMTP id 57FBC8C; Wed, 9 Mar 2005 20:48:03 +0100 (CET) Received: by postel.suug.ch (Postfix, from userid 10001) id A1CDF1C0EA; Wed, 9 Mar 2005 20:48:46 +0100 (CET) Date: Wed, 9 Mar 2005 20:48:46 +0100 From: Thomas Graf To: "David S. Miller" Cc: netdev@oss.sgi.com Subject: [PATCH 5/11] [NET] Convert sk_rcvtstamp into SOCK_RCVTSTAMP flag Message-ID: <20050309194846.GM31837@postel.suug.ch> References: <20050309194521.GH31837@postel.suug.ch> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20050309194521.GH31837@postel.suug.ch> X-Virus-Scanned: ClamAV 0.83/757/Tue Mar 8 15:14:36 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 2734 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: tgraf@suug.ch Precedence: bulk X-list: netdev Content-Length: 2255 Lines: 65 Signed-off-by: Thomas Graf diff -Nru linux-2.6.11-rc4.orig/include/net/sock.h linux-2.6.11-rc4/include/net/sock.h --- linux-2.6.11-rc4.orig/include/net/sock.h 2005-03-09 00:53:32.000000000 +0100 +++ linux-2.6.11-rc4/include/net/sock.h 2005-03-09 01:01:33.000000000 +0100 @@ -134,7 +134,6 @@ * @sk_sndbuf - size of send buffer in bytes * @sk_flags - %SO_LINGER (l_onoff), %SO_BROADCAST, %SO_KEEPALIVE, %SO_OOBINLINE settings * @sk_no_check - %SO_NO_CHECK setting, wether or not checkup packets - * @sk_rcvtstamp - %SO_TIMESTAMP setting * @sk_no_largesend - whether to sent large segments or not * @sk_route_caps - route capabilities (e.g. %NETIF_F_TSO) * @sk_lingertime - %SO_LINGER l_linger setting @@ -207,7 +206,6 @@ int sk_sndbuf; unsigned long sk_flags; char sk_no_check; - unsigned char sk_rcvtstamp; unsigned char sk_no_largesend; int sk_route_caps; unsigned long sk_lingertime; @@ -388,6 +386,7 @@ SOCK_ZAPPED, SOCK_USE_WRITE_QUEUE, /* wheter to call sk->sk_write_space in sock_wfree */ SOCK_DBG, /* %SO_DEBUG setting */ + SOCK_RCVTSTAMP, /* %SO_TIMESTAMP setting */ }; static inline void sock_set_flag(struct sock *sk, enum sock_flags flag) @@ -1237,7 +1236,7 @@ sock_recv_timestamp(struct msghdr *msg, struct sock *sk, struct sk_buff *skb) { struct timeval *stamp = &skb->stamp; - if (sk->sk_rcvtstamp) { + if (sock_flag(sk, SOCK_RCVTSTAMP)) { /* Race occurred between timestamp enabling and packet receiving. Fill in the current time for now. */ if (stamp->tv_sec == 0) diff -Nru linux-2.6.11-rc4.orig/net/core/sock.c linux-2.6.11-rc4/net/core/sock.c --- linux-2.6.11-rc4.orig/net/core/sock.c 2005-03-09 00:53:32.000000000 +0100 +++ linux-2.6.11-rc4/net/core/sock.c 2005-03-09 00:58:43.000000000 +0100 @@ -339,9 +339,11 @@ break; case SO_TIMESTAMP: - sk->sk_rcvtstamp = valbool; - if (valbool) + if (valbool) { + sock_set_flag(sk, SOCK_RCVTSTAMP); sock_enable_timestamp(sk); + } else + sock_reset_flag(sk, SOCK_RCVTSTAMP); break; case SO_RCVLOWAT: @@ -525,7 +527,7 @@ break; case SO_TIMESTAMP: - v.val = sk->sk_rcvtstamp; + v.val = sock_flag(sk, SOCK_RCVTSTAMP); break; case SO_RCVTIMEO: From tgraf@suug.ch Wed Mar 9 11:48:59 2005 Received: with ECARTIS (v1.0.0; list netdev); Wed, 09 Mar 2005 11:49:03 -0800 (PST) Received: from b.mx.projectdream.org (eth0-0.arisu.projectdream.org [194.158.4.191]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j29JmwLG003832 for ; Wed, 9 Mar 2005 11:48:58 -0800 Received: from postel.suug.ch (postel.suug.ch [195.134.158.23]) (using TLSv1 with cipher EDH-RSA-DES-CBC3-SHA (168/168 bits)) (No client certificate requested) by b.mx.projectdream.org (Postfix) with ESMTP id D57A78C; Wed, 9 Mar 2005 20:48:35 +0100 (CET) Received: by postel.suug.ch (Postfix, from userid 10001) id 2F3BD1C0EA; Wed, 9 Mar 2005 20:49:19 +0100 (CET) Date: Wed, 9 Mar 2005 20:49:19 +0100 From: Thomas Graf To: "David S. Miller" Cc: netdev@oss.sgi.com Subject: [PATCH 6/11] [NET] Convert sk_no_largesend into SOCK_NO_LARGESEND flag Message-ID: <20050309194919.GN31837@postel.suug.ch> References: <20050309194521.GH31837@postel.suug.ch> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20050309194521.GH31837@postel.suug.ch> X-Virus-Scanned: ClamAV 0.83/757/Tue Mar 8 15:14:36 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 2735 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: tgraf@suug.ch Precedence: bulk X-list: netdev Content-Length: 4600 Lines: 117 Signed-off-by: Thomas Graf diff -Nru linux-2.6.11-rc4.orig/include/net/sock.h linux-2.6.11-rc4/include/net/sock.h --- linux-2.6.11-rc4.orig/include/net/sock.h 2005-03-09 01:03:45.000000000 +0100 +++ linux-2.6.11-rc4/include/net/sock.h 2005-03-09 01:08:01.000000000 +0100 @@ -134,7 +134,6 @@ * @sk_sndbuf - size of send buffer in bytes * @sk_flags - %SO_LINGER (l_onoff), %SO_BROADCAST, %SO_KEEPALIVE, %SO_OOBINLINE settings * @sk_no_check - %SO_NO_CHECK setting, wether or not checkup packets - * @sk_no_largesend - whether to sent large segments or not * @sk_route_caps - route capabilities (e.g. %NETIF_F_TSO) * @sk_lingertime - %SO_LINGER l_linger setting * @sk_hashent - hash entry in several tables (e.g. tcp_ehash) @@ -206,7 +205,6 @@ int sk_sndbuf; unsigned long sk_flags; char sk_no_check; - unsigned char sk_no_largesend; int sk_route_caps; unsigned long sk_lingertime; int sk_hashent; @@ -387,6 +385,7 @@ SOCK_USE_WRITE_QUEUE, /* wheter to call sk->sk_write_space in sock_wfree */ SOCK_DBG, /* %SO_DEBUG setting */ SOCK_RCVTSTAMP, /* %SO_TIMESTAMP setting */ + SOCK_NO_LARGESEND, /* whether to sent large segments or not */ }; static inline void sock_set_flag(struct sock *sk, enum sock_flags flag) diff -Nru linux-2.6.11-rc4.orig/include/net/tcp.h linux-2.6.11-rc4/include/net/tcp.h --- linux-2.6.11-rc4.orig/include/net/tcp.h 2005-03-08 18:11:24.000000000 +0100 +++ linux-2.6.11-rc4/include/net/tcp.h 2005-03-09 01:06:29.000000000 +0100 @@ -1914,7 +1914,7 @@ { sk->sk_route_caps = dst->dev->features; if (sk->sk_route_caps & NETIF_F_TSO) { - if (sk->sk_no_largesend || dst->header_len) + if (sock_flag(sk, SOCK_NO_LARGESEND) || dst->header_len) sk->sk_route_caps &= ~NETIF_F_TSO; } } diff -Nru linux-2.6.11-rc4.orig/include/net/tcp_ecn.h linux-2.6.11-rc4/include/net/tcp_ecn.h --- linux-2.6.11-rc4.orig/include/net/tcp_ecn.h 2005-03-08 18:11:24.000000000 +0100 +++ linux-2.6.11-rc4/include/net/tcp_ecn.h 2005-03-09 01:06:42.000000000 +0100 @@ -33,7 +33,7 @@ if (sysctl_tcp_ecn && !(sk->sk_route_caps & NETIF_F_TSO)) { TCP_SKB_CB(skb)->flags |= TCPCB_FLAG_ECE|TCPCB_FLAG_CWR; tp->ecn_flags = TCP_ECN_OK; - sk->sk_no_largesend = 1; + sock_set_flag(sk, SOCK_NO_LARGESEND); } } diff -Nru linux-2.6.11-rc4.orig/net/ipv4/tcp_input.c linux-2.6.11-rc4/net/ipv4/tcp_input.c --- linux-2.6.11-rc4.orig/net/ipv4/tcp_input.c 2005-03-08 18:11:28.000000000 +0100 +++ linux-2.6.11-rc4/net/ipv4/tcp_input.c 2005-03-09 01:07:20.000000000 +0100 @@ -977,7 +977,7 @@ * Not good, but alternative is to resegment the queue. */ if (sk->sk_route_caps & NETIF_F_TSO) { sk->sk_route_caps &= ~NETIF_F_TSO; - sk->sk_no_largesend = 1; + sock_set_flag(sk, SOCK_NO_LARGESEND); tp->mss_cache = tp->mss_cache_std; } @@ -4507,7 +4507,7 @@ TCP_ECN_rcv_synack(tp, th); if (tp->ecn_flags&TCP_ECN_OK) - sk->sk_no_largesend = 1; + sock_set_flag(sk, SOCK_NO_LARGESEND); tp->snd_wl1 = TCP_SKB_CB(skb)->seq; tcp_ack(sk, skb, FLAG_SLOWPATH); @@ -4645,7 +4645,7 @@ TCP_ECN_rcv_syn(tp, th); if (tp->ecn_flags&TCP_ECN_OK) - sk->sk_no_largesend = 1; + sock_set_flag(sk, SOCK_NO_LARGESEND); tcp_sync_mss(sk, tp->pmtu_cookie); tcp_initialize_rcv_mss(sk); diff -Nru linux-2.6.11-rc4.orig/net/ipv4/tcp_minisocks.c linux-2.6.11-rc4/net/ipv4/tcp_minisocks.c --- linux-2.6.11-rc4.orig/net/ipv4/tcp_minisocks.c 2005-03-08 18:11:28.000000000 +0100 +++ linux-2.6.11-rc4/net/ipv4/tcp_minisocks.c 2005-03-09 01:07:30.000000000 +0100 @@ -841,7 +841,7 @@ newtp->rx_opt.mss_clamp = req->mss; TCP_ECN_openreq_child(newtp, req); if (newtp->ecn_flags&TCP_ECN_OK) - newsk->sk_no_largesend = 1; + sock_set_flag(newsk, SOCK_NO_LARGESEND); tcp_ca_init(newtp); diff -Nru linux-2.6.11-rc4.orig/net/ipv4/tcp_output.c linux-2.6.11-rc4/net/ipv4/tcp_output.c --- linux-2.6.11-rc4.orig/net/ipv4/tcp_output.c 2005-03-08 18:11:28.000000000 +0100 +++ linux-2.6.11-rc4/net/ipv4/tcp_output.c 2005-03-09 01:07:56.000000000 +0100 @@ -1040,7 +1040,7 @@ if (sk->sk_route_caps & NETIF_F_TSO) { sk->sk_route_caps &= ~NETIF_F_TSO; - sk->sk_no_largesend = 1; + sock_set_flag(sk, SOCK_NO_LARGESEND); tp->mss_cache = tp->mss_cache_std; } @@ -1669,7 +1669,7 @@ /* SWS override triggered forced fragmentation. * Disable TSO, the connection is too sick. */ if (sk->sk_route_caps & NETIF_F_TSO) { - sk->sk_no_largesend = 1; + sock_set_flag(sk, SOCK_NO_LARGESEND); sk->sk_route_caps &= ~NETIF_F_TSO; tp->mss_cache = tp->mss_cache_std; } From tgraf@suug.ch Wed Mar 9 11:49:37 2005 Received: with ECARTIS (v1.0.0; list netdev); Wed, 09 Mar 2005 11:49:41 -0800 (PST) Received: from b.mx.projectdream.org (eth0-0.arisu.projectdream.org [194.158.4.191]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j29JnaNe004563 for ; Wed, 9 Mar 2005 11:49:36 -0800 Received: from postel.suug.ch (postel.suug.ch [195.134.158.23]) (using TLSv1 with cipher EDH-RSA-DES-CBC3-SHA (168/168 bits)) (No client certificate requested) by b.mx.projectdream.org (Postfix) with ESMTP id CDE608C; Wed, 9 Mar 2005 20:49:13 +0100 (CET) Received: by postel.suug.ch (Postfix, from userid 10001) id 2EE431C0EA; Wed, 9 Mar 2005 20:49:57 +0100 (CET) Date: Wed, 9 Mar 2005 20:49:57 +0100 From: Thomas Graf To: "David S. Miller" Cc: netdev@oss.sgi.com Subject: [PATCH 7/11] [NET] Convert sk_localroute into SOCK_LOCALROUTE flag Message-ID: <20050309194957.GO31837@postel.suug.ch> References: <20050309194521.GH31837@postel.suug.ch> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20050309194521.GH31837@postel.suug.ch> X-Virus-Scanned: ClamAV 0.83/757/Tue Mar 8 15:14:36 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 2736 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: tgraf@suug.ch Precedence: bulk X-list: netdev Content-Length: 4042 Lines: 105 Also converts two manual routing TOS calculations to use the correct macro. Signed-off-by: Thomas Graf diff -Nru linux-2.6.11-rc4.orig/include/net/route.h linux-2.6.11-rc4/include/net/route.h --- linux-2.6.11-rc4.orig/include/net/route.h 2005-03-08 18:11:24.000000000 +0100 +++ linux-2.6.11-rc4/include/net/route.h 2005-03-09 01:24:35.000000000 +0100 @@ -44,7 +44,7 @@ /* RTO_CONN is not used (being alias for 0), but preserved not to break * some modules referring to it. */ -#define RT_CONN_FLAGS(sk) (RT_TOS(inet_sk(sk)->tos) | sk->sk_localroute) +#define RT_CONN_FLAGS(sk) (RT_TOS(inet_sk(sk)->tos) | sock_flag(sk, SOCK_LOCALROUTE)) struct inet_peer; struct rtable diff -Nru linux-2.6.11-rc4.orig/include/net/sock.h linux-2.6.11-rc4/include/net/sock.h --- linux-2.6.11-rc4.orig/include/net/sock.h 2005-03-09 01:09:59.000000000 +0100 +++ linux-2.6.11-rc4/include/net/sock.h 2005-03-09 01:28:42.000000000 +0100 @@ -147,7 +147,6 @@ * @sk_max_ack_backlog - listen backlog set in listen() * @sk_priority - %SO_PRIORITY setting * @sk_type - socket type (%SOCK_STREAM, etc) - * @sk_localroute - route locally only, %SO_DONTROUTE setting * @sk_protocol - which protocol this socket belongs in this network family * @sk_peercred - %SO_PEERCRED setting * @sk_rcvlowat - %SO_RCVLOWAT setting @@ -226,7 +225,6 @@ unsigned short sk_max_ack_backlog; __u32 sk_priority; unsigned short sk_type; - unsigned char sk_localroute; unsigned char sk_protocol; struct ucred sk_peercred; int sk_rcvlowat; @@ -386,6 +384,7 @@ SOCK_DBG, /* %SO_DEBUG setting */ SOCK_RCVTSTAMP, /* %SO_TIMESTAMP setting */ SOCK_NO_LARGESEND, /* whether to sent large segments or not */ + SOCK_LOCALROUTE, /* route locally only, %SO_DONTROUTE setting */ }; static inline void sock_set_flag(struct sock *sk, enum sock_flags flag) diff -Nru linux-2.6.11-rc4.orig/net/core/sock.c linux-2.6.11-rc4/net/core/sock.c --- linux-2.6.11-rc4.orig/net/core/sock.c 2005-03-09 01:03:45.000000000 +0100 +++ linux-2.6.11-rc4/net/core/sock.c 2005-03-09 01:25:16.000000000 +0100 @@ -241,7 +241,10 @@ ret = -ENOPROTOOPT; break; case SO_DONTROUTE: - sk->sk_localroute = valbool; + if (valbool) + sock_set_flag(sk, SOCK_LOCALROUTE); + else + sock_reset_flag(sk, SOCK_LOCALROUTE); break; case SO_BROADCAST: sock_valbool_flag(sk, SOCK_BROADCAST, valbool); @@ -471,7 +474,7 @@ break; case SO_DONTROUTE: - v.val = sk->sk_localroute; + v.val = sock_flag(sk, SOCK_LOCALROUTE); break; case SO_BROADCAST: diff -Nru linux-2.6.11-rc4.orig/net/ipv4/raw.c linux-2.6.11-rc4/net/ipv4/raw.c --- linux-2.6.11-rc4.orig/net/ipv4/raw.c 2005-03-08 18:11:28.000000000 +0100 +++ linux-2.6.11-rc4/net/ipv4/raw.c 2005-03-09 01:26:29.000000000 +0100 @@ -457,7 +457,7 @@ daddr = ipc.opt->faddr; } } - tos = RT_TOS(inet->tos) | sk->sk_localroute; + tos = RT_CONN_FLAGS(sk); if (msg->msg_flags & MSG_DONTROUTE) tos |= RTO_ONLINK; diff -Nru linux-2.6.11-rc4.orig/net/ipv4/tcp_ipv4.c linux-2.6.11-rc4/net/ipv4/tcp_ipv4.c --- linux-2.6.11-rc4.orig/net/ipv4/tcp_ipv4.c 2005-03-09 00:40:06.000000000 +0100 +++ linux-2.6.11-rc4/net/ipv4/tcp_ipv4.c 2005-03-09 01:27:06.000000000 +0100 @@ -1866,7 +1866,7 @@ /* Query new route. */ err = ip_route_connect(&rt, daddr, 0, - RT_TOS(inet->tos) | sk->sk_localroute, + RT_CONN_FLAGS(sk), sk->sk_bound_dev_if, IPPROTO_TCP, inet->sport, inet->dport, sk); diff -Nru linux-2.6.11-rc4.orig/net/ipv4/udp.c linux-2.6.11-rc4/net/ipv4/udp.c --- linux-2.6.11-rc4.orig/net/ipv4/udp.c 2005-03-08 18:11:28.000000000 +0100 +++ linux-2.6.11-rc4/net/ipv4/udp.c 2005-03-09 01:27:32.000000000 +0100 @@ -574,7 +574,8 @@ connected = 0; } tos = RT_TOS(inet->tos); - if (sk->sk_localroute || (msg->msg_flags & MSG_DONTROUTE) || + if (sock_flag(sk, SOCK_LOCALROUTE) || + (msg->msg_flags & MSG_DONTROUTE) || (ipc.opt && ipc.opt->is_strictroute)) { tos |= RTO_ONLINK; connected = 0; From jgarzik@pobox.com Wed Mar 9 11:50:27 2005 Received: with ECARTIS (v1.0.0; list netdev); Wed, 09 Mar 2005 11:50:31 -0800 (PST) Received: from parcelfarce.linux.theplanet.co.uk (IDENT:93@parcelfarce.linux.theplanet.co.uk [195.92.249.252]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j29JoQ7x005264 for ; Wed, 9 Mar 2005 11:50:26 -0800 Received: from [69.134.152.124] (helo=[10.10.10.88]) by parcelfarce.linux.theplanet.co.uk with asmtp (TLSv1:AES256-SHA:256) (Exim 4.33) id 1D97CL-0001BW-NG; Wed, 09 Mar 2005 19:50:25 +0000 Message-ID: <422F5372.8070308@pobox.com> Date: Wed, 09 Mar 2005 14:50:10 -0500 From: Jeff Garzik User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.3) Gecko/20040922 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Stephen Hemminger CC: Francois Romieu , netdev@oss.sgi.com Subject: Re: [PATCH 4/5] r8169: ethtool message level control References: <20050309113402.05d25e49@dxpl.pdx.osdl.net> In-Reply-To: <20050309113402.05d25e49@dxpl.pdx.osdl.net> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV 0.83/757/Tue Mar 8 15:14:36 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 2738 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: jgarzik@pobox.com Precedence: bulk X-list: netdev Content-Length: 779 Lines: 21 Stephen Hemminger wrote: > Add ethtool message level control support. This is the standard way > to enable/disable console log messages. Also, ratelimit the too much > work at interrupt message, so if under massive packet load the console > doesn't get flooded. > > Signed-off-by: Stephen Hemminger > > diff -Nru a/drivers/net/r8169.c b/drivers/net/r8169.c > --- a/drivers/net/r8169.c 2005-03-09 11:25:04 -08:00 > +++ b/drivers/net/r8169.c 2005-03-09 11:25:04 -08:00 > @@ -188,6 +188,9 @@ > MODULE_DEVICE_TABLE(pci, rtl8169_pci_tbl); > > static int rx_copybreak = 200; > +static int debug = 3; > +static const u32 default_msg = NETIF_MSG_DRV | NETIF_MSG_PROBE | > + NETIF_MSG_LINK | NETIF_MSG_IFUP| NETIF_MSG_IFDOWN; whitespace breakage? From tgraf@suug.ch Wed Mar 9 11:50:13 2005 Received: with ECARTIS (v1.0.0; list netdev); Wed, 09 Mar 2005 11:50:16 -0800 (PST) Received: from b.mx.projectdream.org (eth0-0.arisu.projectdream.org [194.158.4.191]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j29JoCm7005114 for ; Wed, 9 Mar 2005 11:50:12 -0800 Received: from postel.suug.ch (postel.suug.ch [195.134.158.23]) (using TLSv1 with cipher EDH-RSA-DES-CBC3-SHA (168/168 bits)) (No client certificate requested) by b.mx.projectdream.org (Postfix) with ESMTP id 612348C; Wed, 9 Mar 2005 20:49:48 +0100 (CET) Received: by postel.suug.ch (Postfix, from userid 10001) id B82911C0EA; Wed, 9 Mar 2005 20:50:31 +0100 (CET) Date: Wed, 9 Mar 2005 20:50:31 +0100 From: Thomas Graf To: "David S. Miller" Cc: netdev@oss.sgi.com Subject: [PATCH 8/11] [NET] Convert sk_queue_shrunk into SOCK_QUEUE_SHRUNK flag Message-ID: <20050309195031.GP31837@postel.suug.ch> References: <20050309194521.GH31837@postel.suug.ch> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20050309194521.GH31837@postel.suug.ch> X-Virus-Scanned: ClamAV 0.83/757/Tue Mar 8 15:14:36 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 2737 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: tgraf@suug.ch Precedence: bulk X-list: netdev Content-Length: 3113 Lines: 76 Signed-off-by: Thomas Graf diff -Nru linux-2.6.11-rc4.orig/include/net/sock.h linux-2.6.11-rc4/include/net/sock.h --- linux-2.6.11-rc4.orig/include/net/sock.h 2005-03-09 01:31:21.000000000 +0100 +++ linux-2.6.11-rc4/include/net/sock.h 2005-03-09 02:48:15.000000000 +0100 @@ -164,7 +164,6 @@ * @sk_sndmsg_off - cached offset for sendmsg * @sk_send_head - front of stuff to transmit * @sk_write_pending - a write to stream socket waits to start - * @sk_queue_shrunk - write queue has been shrunk recently * @sk_state_change - callback to indicate change in the state of the sock * @sk_data_ready - callback to indicate there is data to be processed * @sk_write_space - callback to indicate there is bf sending space available @@ -243,7 +242,6 @@ struct sk_buff *sk_send_head; int sk_write_pending; void *sk_security; - __u8 sk_queue_shrunk; /* three bytes hole, try to pack */ void (*sk_state_change)(struct sock *sk); void (*sk_data_ready)(struct sock *sk, int bytes); @@ -385,6 +383,7 @@ SOCK_RCVTSTAMP, /* %SO_TIMESTAMP setting */ SOCK_NO_LARGESEND, /* whether to sent large segments or not */ SOCK_LOCALROUTE, /* route locally only, %SO_DONTROUTE setting */ + SOCK_QUEUE_SHRUNK, /* write queue has been shrunk recently */ }; static inline void sock_set_flag(struct sock *sk, enum sock_flags flag) @@ -449,7 +448,7 @@ static inline void sk_stream_free_skb(struct sock *sk, struct sk_buff *skb) { - sk->sk_queue_shrunk = 1; + sock_set_flag(sk, SOCK_QUEUE_SHRUNK); sk->sk_wmem_queued -= skb->truesize; sk->sk_forward_alloc += skb->truesize; __kfree_skb(skb); diff -Nru linux-2.6.11-rc4.orig/net/ipv4/tcp_input.c linux-2.6.11-rc4/net/ipv4/tcp_input.c --- linux-2.6.11-rc4.orig/net/ipv4/tcp_input.c 2005-03-09 01:09:59.000000000 +0100 +++ linux-2.6.11-rc4/net/ipv4/tcp_input.c 2005-03-09 02:48:13.000000000 +0100 @@ -3935,7 +3935,7 @@ /* When incoming ACK allowed to free some skb from write_queue, - * we remember this event in flag sk->sk_queue_shrunk and wake up socket + * we remember this event in flag SOCK_QUEUE_SHRUNK and wake up socket * on the exit from tcp input handler. * * PROBLEM: sndbuf expansion does not work well with largesend. @@ -3963,8 +3963,8 @@ static inline void tcp_check_space(struct sock *sk) { - if (sk->sk_queue_shrunk) { - sk->sk_queue_shrunk = 0; + if (sock_flag(sk, SOCK_QUEUE_SHRUNK)) { + sock_reset_flag(sk, SOCK_QUEUE_SHRUNK); if (sk->sk_socket && test_bit(SOCK_NOSPACE, &sk->sk_socket->flags)) tcp_new_space(sk); diff -Nru linux-2.6.11-rc4.orig/net/ipv4/tcp_output.c linux-2.6.11-rc4/net/ipv4/tcp_output.c --- linux-2.6.11-rc4.orig/net/ipv4/tcp_output.c 2005-03-09 01:09:59.000000000 +0100 +++ linux-2.6.11-rc4/net/ipv4/tcp_output.c 2005-03-09 02:47:14.000000000 +0100 @@ -593,9 +593,9 @@ skb->ip_summed = CHECKSUM_HW; skb->truesize -= len; - sk->sk_queue_shrunk = 1; sk->sk_wmem_queued -= len; sk->sk_forward_alloc += len; + sock_set_flag(sk, SOCK_QUEUE_SHRUNK); /* Any change of skb->len requires recalculation of tso * factor and mss. From tgraf@suug.ch Wed Mar 9 11:50:45 2005 Received: with ECARTIS (v1.0.0; list netdev); Wed, 09 Mar 2005 11:50:49 -0800 (PST) Received: from b.mx.projectdream.org (eth0-0.arisu.projectdream.org [194.158.4.191]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j29Joi7G005546 for ; Wed, 9 Mar 2005 11:50:44 -0800 Received: from postel.suug.ch (postel.suug.ch [195.134.158.23]) (using TLSv1 with cipher EDH-RSA-DES-CBC3-SHA (168/168 bits)) (No client certificate requested) by b.mx.projectdream.org (Postfix) with ESMTP id C0B208C; Wed, 9 Mar 2005 20:50:21 +0100 (CET) Received: by postel.suug.ch (Postfix, from userid 10001) id 167281C0EA; Wed, 9 Mar 2005 20:51:05 +0100 (CET) Date: Wed, 9 Mar 2005 20:51:04 +0100 From: Thomas Graf To: "David S. Miller" Cc: netdev@oss.sgi.com Subject: [PATCH 9/11] [NET] Reorder struct sock Message-ID: <20050309195104.GQ31837@postel.suug.ch> References: <20050309194521.GH31837@postel.suug.ch> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20050309194521.GH31837@postel.suug.ch> X-Virus-Scanned: ClamAV 0.83/757/Tue Mar 8 15:14:36 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 2739 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: tgraf@suug.ch Precedence: bulk X-list: netdev Content-Length: 2564 Lines: 83 Reorders struct sock to avoid padding and shrinks the following fields to more appropriate sizes saving 12 bytes and some more on 64bit architectures. sk_shutdown: char -> 2 bits sk_no_checks: char -> 2 bits sk_userlocks: char -> 4 bits Signed-off-by: Thomas Graf --- linux-2.6.11-rc4.orig/include/net/sock.h 2005-03-09 15:22:43.000000000 +0100 +++ linux-2.6.11-rc4/include/net/sock.h 2005-03-09 15:33:33.000000000 +0100 @@ -184,28 +184,30 @@ #define sk_node __sk_common.skc_node #define sk_bind_node __sk_common.skc_bind_node #define sk_refcnt __sk_common.skc_refcnt - unsigned char sk_shutdown; - unsigned char sk_userlocks; - socket_lock_t sk_lock; + unsigned char sk_shutdown : 2, + sk_no_check : 2, + sk_userlocks : 4; + unsigned char sk_protocol; + unsigned short sk_type; int sk_rcvbuf; + socket_lock_t sk_lock; wait_queue_head_t *sk_sleep; struct dst_entry *sk_dst_cache; - rwlock_t sk_dst_lock; struct xfrm_policy *sk_policy[2]; + rwlock_t sk_dst_lock; atomic_t sk_rmem_alloc; - struct sk_buff_head sk_receive_queue; atomic_t sk_wmem_alloc; - struct sk_buff_head sk_write_queue; atomic_t sk_omem_alloc; + struct sk_buff_head sk_receive_queue; + struct sk_buff_head sk_write_queue; int sk_wmem_queued; int sk_forward_alloc; unsigned int sk_allocation; int sk_sndbuf; - unsigned long sk_flags; - char sk_no_check; int sk_route_caps; - unsigned long sk_lingertime; int sk_hashent; + unsigned long sk_flags; + unsigned long sk_lingertime; /* * The backlog queue is special, it is always used with * the per-socket spinlock held and requires low latency @@ -215,16 +217,14 @@ struct sk_buff *head; struct sk_buff *tail; } sk_backlog; - rwlock_t sk_callback_lock; struct sk_buff_head sk_error_queue; struct proto *sk_prot; + rwlock_t sk_callback_lock; int sk_err, sk_err_soft; unsigned short sk_ack_backlog; unsigned short sk_max_ack_backlog; __u32 sk_priority; - unsigned short sk_type; - unsigned char sk_protocol; struct ucred sk_peercred; int sk_rcvlowat; long sk_rcvtimeo; @@ -238,11 +238,10 @@ void *sk_user_data; struct module *sk_owner; struct page *sk_sndmsg_page; - __u32 sk_sndmsg_off; struct sk_buff *sk_send_head; + __u32 sk_sndmsg_off; int sk_write_pending; void *sk_security; - /* three bytes hole, try to pack */ void (*sk_state_change)(struct sock *sk); void (*sk_data_ready)(struct sock *sk, int bytes); void (*sk_write_space)(struct sock *sk); From tgraf@suug.ch Wed Mar 9 11:51:22 2005 Received: with ECARTIS (v1.0.0; list netdev); Wed, 09 Mar 2005 11:51:26 -0800 (PST) Received: from b.mx.projectdream.org (eth0-0.arisu.projectdream.org [194.158.4.191]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j29JpL7Z006207 for ; Wed, 9 Mar 2005 11:51:22 -0800 Received: from postel.suug.ch (postel.suug.ch [195.134.158.23]) (using TLSv1 with cipher EDH-RSA-DES-CBC3-SHA (168/168 bits)) (No client certificate requested) by b.mx.projectdream.org (Postfix) with ESMTP id 350DE8C; Wed, 9 Mar 2005 20:50:59 +0100 (CET) Received: by postel.suug.ch (Postfix, from userid 10001) id 8AAAE1C0EA; Wed, 9 Mar 2005 20:51:42 +0100 (CET) Date: Wed, 9 Mar 2005 20:51:42 +0100 From: Thomas Graf To: "David S. Miller" Cc: netdev@oss.sgi.com Subject: [PATCH 10/11] [NET] Reorder struct ipv6_pinfo Message-ID: <20050309195142.GR31837@postel.suug.ch> References: <20050309194521.GH31837@postel.suug.ch> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20050309194521.GH31837@postel.suug.ch> X-Virus-Scanned: ClamAV 0.83/757/Tue Mar 8 15:14:36 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 2740 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: tgraf@suug.ch Precedence: bulk X-list: netdev Content-Length: 812 Lines: 31 Converts hop_limit and mcast_hops to signed 16 bits types saving 4 bytes on 32bit archs and another 4 bytes on 64bit archs. Signed-off-by: Thomas Graf --- linux-2.6.11-rc4.orig/include/linux/ipv6.h 2005-03-09 19:05:01.000000000 +0100 +++ linux-2.6.11-rc4/include/linux/ipv6.h 2005-03-09 19:06:08.000000000 +0100 @@ -209,8 +209,8 @@ __u32 flow_label; __u32 frag_size; - int hop_limit; - int mcast_hops; + __s16 hop_limit; + __s16 mcast_hops; int mcast_oif; /* pktoption flags */ @@ -233,10 +233,11 @@ pmtudisc:2, ipv6only:1; + __u32 dst_cookie; + struct ipv6_mc_socklist *ipv6_mc_list; struct ipv6_ac_socklist *ipv6_ac_list; struct ipv6_fl_socklist *ipv6_fl_list; - __u32 dst_cookie; struct ipv6_txoptions *opt; struct sk_buff *pktoptions; From tgraf@suug.ch Wed Mar 9 11:51:56 2005 Received: with ECARTIS (v1.0.0; list netdev); Wed, 09 Mar 2005 11:52:02 -0800 (PST) Received: from b.mx.projectdream.org (eth0-0.arisu.projectdream.org [194.158.4.191]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j29Jptv1006836 for ; Wed, 9 Mar 2005 11:51:55 -0800 Received: from postel.suug.ch (postel.suug.ch [195.134.158.23]) (using TLSv1 with cipher EDH-RSA-DES-CBC3-SHA (168/168 bits)) (No client certificate requested) by b.mx.projectdream.org (Postfix) with ESMTP id CC0318C; Wed, 9 Mar 2005 20:51:32 +0100 (CET) Received: by postel.suug.ch (Postfix, from userid 10001) id 218831C0EA; Wed, 9 Mar 2005 20:52:16 +0100 (CET) Date: Wed, 9 Mar 2005 20:52:16 +0100 From: Thomas Graf To: "David S. Miller" Cc: netdev@oss.sgi.com Subject: [PATCH 11/11] [NET] Reorder struct tcp_options_received Message-ID: <20050309195216.GS31837@postel.suug.ch> References: <20050309194521.GH31837@postel.suug.ch> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20050309194521.GH31837@postel.suug.ch> X-Virus-Scanned: ClamAV 0.83/757/Tue Mar 8 15:14:36 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 2741 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: tgraf@suug.ch Precedence: bulk X-list: netdev Content-Length: 3512 Lines: 87 Reorders struct tcp_options_received to avoid padding and shrinks the following fields to more appropriate sizes saving 8 bytes. saw_tstamp: char -> 1 bit tstamp_ok: char -> 1 bit sack_ok: char -> 4 bits wscale_ok: char -> 1 bit snd_wscale: u8 -> 4 bits rcv_wscale: u8 -> 4 bits dsack: u8 -> 1 bit Signed-off-by: Thomas Graf diff -Nru linux-2.6.11-rc4.orig/include/linux/tcp.h linux-2.6.11-rc4/include/linux/tcp.h --- linux-2.6.11-rc4.orig/include/linux/tcp.h 2005-03-09 14:16:28.000000000 +0100 +++ linux-2.6.11-rc4/include/linux/tcp.h 2005-03-09 17:07:48.000000000 +0100 @@ -216,17 +216,16 @@ __u32 ts_recent; /* Time stamp to echo next */ __u32 rcv_tsval; /* Time stamp value */ __u32 rcv_tsecr; /* Time stamp echo reply */ - char saw_tstamp; /* Saw TIMESTAMP on last packet */ - char tstamp_ok; /* TIMESTAMP seen on SYN packet */ - char sack_ok; /* SACK seen on SYN packet */ - char wscale_ok; /* Wscale seen on SYN packet */ - __u8 snd_wscale; /* Window scaling received from sender */ - __u8 rcv_wscale; /* Window scaling to send to receiver */ + __u16 saw_tstamp : 1, /* Saw TIMESTAMP on last packet */ + tstamp_ok : 1, /* TIMESTAMP seen on SYN packet */ + dsack : 1, /* D-SACK is scheduled */ + wscale_ok : 1, /* Wscale seen on SYN packet */ + sack_ok : 4, /* SACK seen on SYN packet */ + snd_wscale : 4, /* Window scaling received from sender */ + rcv_wscale : 4; /* Window scaling to send to receiver */ /* SACKs data */ - __u8 dsack; /* D-SACK is scheduled */ __u8 eff_sacks; /* Size of SACK array to send with next packet */ __u8 num_sacks; /* Number of SACK blocks */ - __u8 __pad; __u16 user_mss; /* mss requested by user in ioctl */ __u16 mss_clamp; /* Maximal mss, negotiated at connection setup */ }; diff -Nru linux-2.6.11-rc4.orig/net/ipv4/tcp_input.c linux-2.6.11-rc4/net/ipv4/tcp_input.c --- linux-2.6.11-rc4.orig/net/ipv4/tcp_input.c 2005-03-09 15:22:43.000000000 +0100 +++ linux-2.6.11-rc4/net/ipv4/tcp_input.c 2005-03-09 16:59:40.000000000 +0100 @@ -3018,15 +3018,16 @@ case TCPOPT_WINDOW: if(opsize==TCPOLEN_WINDOW && th->syn && !estab) if (sysctl_tcp_window_scaling) { + __u8 snd_wscale = *(__u8 *) ptr; opt_rx->wscale_ok = 1; - opt_rx->snd_wscale = *(__u8 *)ptr; - if(opt_rx->snd_wscale > 14) { + if (snd_wscale > 14) { if(net_ratelimit()) printk(KERN_INFO "tcp_parse_options: Illegal window " "scaling value %d >14 received.\n", - opt_rx->snd_wscale); - opt_rx->snd_wscale = 14; + snd_wscale); + snd_wscale = 14; } + opt_rx->snd_wscale = snd_wscale; } break; case TCPOPT_TIMESTAMP: diff -Nru linux-2.6.11-rc4.orig/net/ipv4/tcp_output.c linux-2.6.11-rc4/net/ipv4/tcp_output.c --- linux-2.6.11-rc4.orig/net/ipv4/tcp_output.c 2005-03-09 15:22:43.000000000 +0100 +++ linux-2.6.11-rc4/net/ipv4/tcp_output.c 2005-03-09 16:44:59.000000000 +0100 @@ -1427,6 +1427,7 @@ { struct dst_entry *dst = __sk_dst_get(sk); struct tcp_sock *tp = tcp_sk(sk); + __u8 rcv_wscale; /* We'll fix this up when we get a response from the other end. * See tcp_input.c:tcp_rcv_state_process case TCP_SYN_SENT. @@ -1451,8 +1452,9 @@ &tp->rcv_wnd, &tp->window_clamp, sysctl_tcp_window_scaling, - &tp->rx_opt.rcv_wscale); + &rcv_wscale); + tp->rx_opt.rcv_wscale = rcv_wscale; tp->rcv_ssthresh = tp->rcv_wnd; sk->sk_err = 0; From jgarzik@pobox.com Wed Mar 9 11:53:30 2005 Received: with ECARTIS (v1.0.0; list netdev); Wed, 09 Mar 2005 11:53:35 -0800 (PST) Received: from parcelfarce.linux.theplanet.co.uk (IDENT:93@parcelfarce.linux.theplanet.co.uk [195.92.249.252]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j29JrTEr008065 for ; Wed, 9 Mar 2005 11:53:30 -0800 Received: from [69.134.152.124] (helo=[10.10.10.88]) by parcelfarce.linux.theplanet.co.uk with asmtp (TLSv1:AES256-SHA:256) (Exim 4.33) id 1D97FI-0001H1-GD; Wed, 09 Mar 2005 19:53:28 +0000 Message-ID: <422F542A.3020907@pobox.com> Date: Wed, 09 Mar 2005 14:53:14 -0500 From: Jeff Garzik User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.3) Gecko/20040922 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Stephen Hemminger CC: Francois Romieu , netdev@oss.sgi.com Subject: Re: [PATCH 5/5] r8169: ethtool hardware statistics support References: <20050309113626.6708c93e@dxpl.pdx.osdl.net> In-Reply-To: <20050309113626.6708c93e@dxpl.pdx.osdl.net> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV 0.83/757/Tue Mar 8 15:14:36 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 2742 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: jgarzik@pobox.com Precedence: bulk X-list: netdev Content-Length: 3604 Lines: 132 Stephen Hemminger wrote: > Add ethtool support for dumping the chip statistics. There aren't lots > of statistics available, but this is what is available according to the RealTek > documentation. > > Signed-off-by: Stephen Hemminger > > diff -Nru a/drivers/net/r8169.c b/drivers/net/r8169.c > --- a/drivers/net/r8169.c 2005-03-09 11:26:04 -08:00 > +++ b/drivers/net/r8169.c 2005-03-09 11:26:04 -08:00 > @@ -195,6 +195,8 @@ > enum RTL8169_registers { > MAC0 = 0, /* Ethernet hardware address. */ > MAR0 = 8, /* Multicast filter. */ > + CounterAddrLow = 0x10, > + CounterAddrHigh = 0x14, > TxDescStartAddrLow = 0x20, > TxDescStartAddrHigh = 0x24, > TxHDescStartAddrLow = 0x28, > @@ -336,6 +338,9 @@ > > /* _TBICSRBit */ > TBILinkOK = 0x02000000, > + > + /* DumpCounterCommand */ > + CounterDump = 0x8, > }; > > enum _DescStatusBit { > @@ -897,6 +902,100 @@ > tp->msg_enable = value; > } > > +static const char rtl8169_gstrings[][ETH_GSTRING_LEN] = { > + "tx_packets", > + "rx_packets", > + "tx_errors", > + "rx_errors", > + "rx_missed", > + "align_errors", > + "tx_single_collisions", > + "tx_multi_collisions", > + "unicast", > + "broadcast", > + "multicast", > + "tx_aborted", > + "tx_underrun", > +}; > + > +struct rtl8169_counters { > + u64 tx_packets; > + u64 rx_packets; > + u64 tx_errors; > + u32 rx_errors; > + u16 rx_missed; > + u16 align_errors; > + u32 tx_one_collision; > + u32 tx_multi_collision; > + u64 rx_unicast; > + u64 rx_broadcast; > + u32 rx_multicast; > + u16 tx_aborted; > + u16 tx_underun; > +}; > + > +static int rtl8169_get_stats_count(struct net_device *dev) > +{ > + return 13; > +} maintenance: use a constant, not a magic number. > +static void rtl8169_get_ethtool_stats(struct net_device *dev, > + struct ethtool_stats *stats, u64 *data) > +{ > + struct rtl8169_private *tp = netdev_priv(dev); whitespace breakage > + struct rtl8169_counters *counters; > + void __iomem *ioaddr = tp->mmio_addr; > + int i; > + dma_addr_t paddr; > + u32 cmd; > + > + ASSERT_RTNL(); > + > + counters = pci_alloc_consistent(tp->pci_dev, sizeof(*counters), > + &paddr); > + if (!counters) > + return; > + > + RTL_W32(CounterAddrHigh, (u64)paddr >> 32); > + cmd = (u64) paddr & DMA_32BIT_MASK; > + RTL_W32(CounterAddrLow, cmd); > + RTL_W32(CounterAddrLow, cmd | CounterDump); > + > + for (i = 0; i < 1000; i++) { > + if (!RTL_R32(CounterAddrLow) & CounterDump) > + break; > + udelay(10); > + } > + RTL_W32(CounterAddrLow, 0); > + RTL_W32(CounterAddrHigh, 0); > + > + data[0] = le64_to_cpu(counters->tx_packets); > + data[1] = le64_to_cpu(counters->rx_packets); > + data[2] = le64_to_cpu(counters->tx_errors); > + data[3] = le32_to_cpu(counters->rx_errors); > + data[4] = le16_to_cpu(counters->rx_missed); > + data[5] = le16_to_cpu(counters->align_errors); > + data[6] = le32_to_cpu(counters->tx_one_collision); > + data[7] = le32_to_cpu(counters->tx_multi_collision); > + data[8] = le64_to_cpu(counters->rx_unicast); > + data[9] = le64_to_cpu(counters->rx_broadcast); > + data[10] = le32_to_cpu(counters->rx_multicast); > + data[11] = le16_to_cpu(counters->tx_aborted); > + data[12] = le16_to_cpu(counters->tx_underun); use the "i++" indexing method found in other drivers. The above code becomes an immediate PITA when you want to insert a new stat near the top (such as a software-generate stat). Also, it's nice to add a BUG (or WARN_ON) check like the check found in other drivers. That helps you ensure that the R8169_STATS_COUNT equals the number of entries you added to the data output. Jeff From kaber@trash.net Wed Mar 9 11:54:16 2005 Received: with ECARTIS (v1.0.0; list netdev); Wed, 09 Mar 2005 11:54:20 -0800 (PST) Received: from kaber.coreworks.de ([62.206.217.67]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j29JsG8G008415 for ; Wed, 9 Mar 2005 11:54:16 -0800 Received: from localhost ([127.0.0.1]) by kaber.coreworks.de with esmtp (Exim 4.50) id 1D97Fy-000072-0b; Wed, 09 Mar 2005 20:54:10 +0100 Message-ID: <422F5461.4080008@trash.net> Date: Wed, 09 Mar 2005 20:54:09 +0100 From: Patrick McHardy User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.7.5) Gecko/20050106 Debian/1.7.5-1 X-Accept-Language: en MIME-Version: 1.0 To: Thomas Graf CC: "David S. Miller" , netdev@oss.sgi.com Subject: Re: [PATCH 2/11] [NET] Convert sk_zapped into SOCK_ZAPPED flag References: <20050309194521.GH31837@postel.suug.ch> <20050309194711.GJ31837@postel.suug.ch> In-Reply-To: <20050309194711.GJ31837@postel.suug.ch> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV 0.83/757/Tue Mar 8 15:14:36 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 2743 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: kaber@trash.net Precedence: bulk X-list: netdev Content-Length: 353 Lines: 16 Thomas Graf wrote: > - volatile unsigned char sk_zapped; > unsigned char sk_shutdown; > unsigned char sk_use_write_queue; > unsigned char sk_userlocks; > @@ -391,6 +389,7 @@ > SOCK_DESTROY, > SOCK_BROADCAST, > SOCK_TIMESTAMP, > + SOCK_ZAPPED, What about volatile ? sock_set_flag() uses __set_bit(), so its not the same. Regards Patrick From tgraf@suug.ch Wed Mar 9 11:56:30 2005 Received: with ECARTIS (v1.0.0; list netdev); Wed, 09 Mar 2005 11:56:34 -0800 (PST) Received: from b.mx.projectdream.org (eth0-0.arisu.projectdream.org [194.158.4.191]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j29JuUlJ009113 for ; Wed, 9 Mar 2005 11:56:30 -0800 Received: from postel.suug.ch (postel.suug.ch [195.134.158.23]) (using TLSv1 with cipher EDH-RSA-DES-CBC3-SHA (168/168 bits)) (No client certificate requested) by b.mx.projectdream.org (Postfix) with ESMTP id 7243F8C; Wed, 9 Mar 2005 20:56:07 +0100 (CET) Received: by postel.suug.ch (Postfix, from userid 10001) id BF93C1C0EA; Wed, 9 Mar 2005 20:56:49 +0100 (CET) Date: Wed, 9 Mar 2005 20:56:49 +0100 From: Thomas Graf To: Patrick McHardy Cc: "David S. Miller" , netdev@oss.sgi.com Subject: Re: [PATCH 2/11] [NET] Convert sk_zapped into SOCK_ZAPPED flag Message-ID: <20050309195649.GT31837@postel.suug.ch> References: <20050309194521.GH31837@postel.suug.ch> <20050309194711.GJ31837@postel.suug.ch> <422F5461.4080008@trash.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <422F5461.4080008@trash.net> X-Virus-Scanned: ClamAV 0.83/757/Tue Mar 8 15:14:36 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 2744 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: tgraf@suug.ch Precedence: bulk X-list: netdev Content-Length: 572 Lines: 18 * Patrick McHardy <422F5461.4080008@trash.net> 2005-03-09 20:54 > Thomas Graf wrote: > >- volatile unsigned char sk_zapped; > > unsigned char sk_shutdown; > > unsigned char sk_use_write_queue; > > unsigned char sk_userlocks; > >@@ -391,6 +389,7 @@ > > SOCK_DESTROY, > > SOCK_BROADCAST, > > SOCK_TIMESTAMP, > >+ SOCK_ZAPPED, > > What about volatile ? sock_set_flag() uses __set_bit(), so its not > the same. I thought about this for a while but couldn't find a reason why it shouldn't work. Actually I don't even see any reason for having sk_zapped be volatile. From remco@slashme.org Wed Mar 9 12:01:15 2005 Received: with ECARTIS (v1.0.0; list netdev); Wed, 09 Mar 2005 12:01:19 -0800 (PST) Received: from services1.virtu.nl (services1.virtu.nl [217.114.97.2]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j29K1EJx009784 for ; Wed, 9 Mar 2005 12:01:15 -0800 Received: from slashme.org ([217.114.97.241] helo=localhost ident=mail) by services1.virtu.nl with esmtp (Exim 3.35 #1 (Debian)) id 1D97Mm-0005y3-00; Wed, 09 Mar 2005 21:01:12 +0100 Received: from remco (helo=localhost) by localhost with local-esmtp (Exim 3.35 #1 (Debian)) id 1D97Mm-00065U-00; Wed, 09 Mar 2005 21:01:12 +0100 Date: Wed, 9 Mar 2005 21:01:12 +0100 (CET) From: Remco van Mook X-X-Sender: remco@localhost Reply-To: remco@virtu.nl To: netdev@oss.sgi.com cc: jamal , ahu@ds9a.nl Subject: Re: bridge between ppp and ethernet - 1 IP address and assign it to another host Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Virus-Scanned: ClamAV 0.83/757/Tue Mar 8 15:14:36 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 2745 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: remco@slashme.org Precedence: bulk X-list: netdev Content-Length: 1036 Lines: 30 I've been toying with the suggestion to do something with routing table 0 to accomplish this, and I can report it works, standard 2.6.10 kernel. Here's how I did it: Assuming a linux system, connected to a local network 172.16.0.0/24, own address 172.16.0.13, 'ppp' ip address to be assigned to a system that has ip address 172.16.0.4 On the box that establishes the PPP connection: 1) establish ppp connection, get IP address, say 192.168.0.2 2) ip route del local 192.168.0.2 3) ip route add 192.168.0.2 via 172.16.0.4 On the other box, 172.16.0.4: 1) ip addr add 192.168.0.2 dev eth0 2) ip route add 0/0 via 172.16.0.13 I didn't bother assigning the IP address for the other box dynamically; that might still pose a challenge - outside the scope of netdev IMHO. Optionally you might want to SNAT outbound traffic on the PPP interface to enforce the correct IP address. Of course the solution doesn't actually 'bridge' the traffic, you get another visible hop, but the effect is almost the same. Kind regards, Remco van Mook From kaber@trash.net Wed Mar 9 12:05:57 2005 Received: with ECARTIS (v1.0.0; list netdev); Wed, 09 Mar 2005 12:06:01 -0800 (PST) Received: from kaber.coreworks.de ([62.206.217.67]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j29K5uqS010358 for ; Wed, 9 Mar 2005 12:05:56 -0800 Received: from localhost ([127.0.0.1]) by kaber.coreworks.de with esmtp (Exim 4.50) id 1D97RG-0000AW-Fj; Wed, 09 Mar 2005 21:05:50 +0100 Message-ID: <422F571E.2020708@trash.net> Date: Wed, 09 Mar 2005 21:05:50 +0100 From: Patrick McHardy User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.7.5) Gecko/20050106 Debian/1.7.5-1 X-Accept-Language: en MIME-Version: 1.0 To: Thomas Graf CC: "David S. Miller" , netdev@oss.sgi.com Subject: Re: [PATCH 2/11] [NET] Convert sk_zapped into SOCK_ZAPPED flag References: <20050309194521.GH31837@postel.suug.ch> <20050309194711.GJ31837@postel.suug.ch> <422F5461.4080008@trash.net> <20050309195649.GT31837@postel.suug.ch> In-Reply-To: <20050309195649.GT31837@postel.suug.ch> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV 0.83/757/Tue Mar 8 15:14:36 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 2746 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: kaber@trash.net Precedence: bulk X-list: netdev Content-Length: 643 Lines: 24 Thomas Graf wrote: > * Patrick McHardy <422F5461.4080008@trash.net> 2005-03-09 20:54 >> >>What about volatile ? sock_set_flag() uses __set_bit(), so its not >>the same. > > > I thought about this for a while but couldn't find a reason > why it shouldn't work. Actually I don't even see any reason for > having sk_zapped be volatile. You're probably right. I believe this piece of code from 2.4 is the reason for it beeing volatile: #ifdef TCP_DEBUG if (sk->zapped) { printk(KERN_DEBUG "TCP: double destroy sk=%p\n", sk); sock_hold(sk); } sk->zapped = 1; #endif Regards Patrick From ak@muc.de Wed Mar 9 12:16:12 2005 Received: with ECARTIS (v1.0.0; list netdev); Wed, 09 Mar 2005 12:16:17 -0800 (PST) Received: from one.firstfloor.org (one.firstfloor.org [213.235.205.2]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j29KG9CP011028 for ; Wed, 9 Mar 2005 12:16:12 -0800 Received: by one.firstfloor.org (Postfix, from userid 502) id 692C5D033E; Wed, 9 Mar 2005 21:16:05 +0100 (CET) To: Stephen Hemminger Cc: netdev@oss.sgi.com Subject: Re: [PATCH 1/5] r8169: auto detect 32-bit slot References: <20050309112925.7f7900ab@dxpl.pdx.osdl.net> From: Andi Kleen Date: Wed, 09 Mar 2005 21:16:05 +0100 In-Reply-To: <20050309112925.7f7900ab@dxpl.pdx.osdl.net> (Stephen Hemminger's message of "Wed, 9 Mar 2005 11:29:25 -0800") Message-ID: User-Agent: Gnus/5.110002 (No Gnus v0.2) Emacs/21.3 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Virus-Scanned: ClamAV 0.83/757/Tue Mar 8 15:14:36 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 2747 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: ak@muc.de Precedence: bulk X-list: netdev Content-Length: 308 Lines: 10 Stephen Hemminger writes: > Change driver to auto-detect when the board is in a 32-bit PCI slot and > avoid setting 64-bit dma mask. The module parameter method is no longer needed. Hmm? It doesn't support DAC? Normally on PCI a 64bit slot is not needed for 64bit addresses. -Andi From jgarzik@pobox.com Wed Mar 9 12:18:09 2005 Received: with ECARTIS (v1.0.0; list netdev); Wed, 09 Mar 2005 12:18:13 -0800 (PST) Received: from parcelfarce.linux.theplanet.co.uk (IDENT:93@parcelfarce.linux.theplanet.co.uk [195.92.249.252]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j29KI8dX011414 for ; Wed, 9 Mar 2005 12:18:08 -0800 Received: from [69.134.152.124] (helo=[10.10.10.88]) by parcelfarce.linux.theplanet.co.uk with asmtp (TLSv1:AES256-SHA:256) (Exim 4.33) id 1D97d8-0001y1-F8; Wed, 09 Mar 2005 20:18:06 +0000 Message-ID: <422F59E8.2090707@pobox.com> Date: Wed, 09 Mar 2005 15:17:44 -0500 From: Jeff Garzik User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.3) Gecko/20040922 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Andrew Morton , Linus Torvalds CC: stable@kernel.org, Netdev , Linux Kernel Subject: [BK PATCHES] 2.6.x net driver oops fixes Content-Type: multipart/mixed; boundary="------------020208010505070903000204" X-Virus-Scanned: ClamAV 0.83/757/Tue Mar 8 15:14:36 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 2748 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: jgarzik@pobox.com Precedence: bulk X-list: netdev Content-Length: 6064 Lines: 209 This is a multi-part message in MIME format. --------------020208010505070903000204 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit --------------020208010505070903000204 Content-Type: text/plain; name="changelog.txt" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="changelog.txt" Please do a bk pull bk://gkernel.bkbits.net/net-drivers-2.6 This will update the following files: drivers/net/sis900.c | 41 +++++++++++++++++++++-------------------- drivers/net/via-rhine.c | 3 +++ 2 files changed, 24 insertions(+), 20 deletions(-) through these ChangeSets: Herbert Xu: o sis900 kernel oops fix Olof Johansson: o [VIA RHINE] older chips oops on shutdown --------------020208010505070903000204 Content-Type: text/plain; name="patch" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="patch" diff -Nru a/drivers/net/sis900.c b/drivers/net/sis900.c --- a/drivers/net/sis900.c 2005-03-09 15:16:53 -05:00 +++ b/drivers/net/sis900.c 2005-03-09 15:16:53 -05:00 @@ -245,7 +245,7 @@ signature = (u16) read_eeprom(ioaddr, EEPROMSignature); if (signature == 0xffff || signature == 0x0000) { printk (KERN_WARNING "%s: Error EERPOM read %x\n", - net_dev->name, signature); + pci_name(pci_dev), signature); return 0; } @@ -277,7 +277,8 @@ if (!isa_bridge) isa_bridge = pci_get_device(PCI_VENDOR_ID_SI, 0x0018, isa_bridge); if (!isa_bridge) { - printk(KERN_WARNING "%s: Can not find ISA bridge\n", net_dev->name); + printk(KERN_WARNING "%s: Can not find ISA bridge\n", + pci_name(pci_dev)); return 0; } pci_read_config_byte(isa_bridge, 0x48, ®); @@ -396,6 +397,7 @@ long ioaddr; int i, ret; char *card_name = card_names[pci_id->driver_data]; + const char *dev_name = pci_name(pci_dev); /* when built into the kernel, we only print version if device is found */ #ifndef MODULE @@ -473,17 +475,13 @@ sis_priv->msg_enable = sis900_debug; else sis_priv->msg_enable = SIS900_DEF_MSG; - - ret = register_netdev(net_dev); - if (ret) - goto err_unmap_rx; /* Get Mac address according to the chip revision */ pci_read_config_byte(pci_dev, PCI_CLASS_REVISION, &(sis_priv->chipset_rev)); if(netif_msg_probe(sis_priv)) printk(KERN_DEBUG "%s: detected revision %2.2x, " "trying to get MAC address...\n", - net_dev->name, sis_priv->chipset_rev); + dev_name, sis_priv->chipset_rev); ret = 0; if (sis_priv->chipset_rev == SIS630E_900_REV) @@ -496,9 +494,9 @@ ret = sis900_get_mac_addr(pci_dev, net_dev); if (ret == 0) { - printk(KERN_WARNING "%s: Cannot read MAC address.\n", net_dev->name); + printk(KERN_WARNING "%s: Cannot read MAC address.\n", dev_name); ret = -ENODEV; - goto err_out_unregister; + goto err_unmap_rx; } /* 630ET : set the mii access mode as software-mode */ @@ -507,9 +505,10 @@ /* probe for mii transceiver */ if (sis900_mii_probe(net_dev) == 0) { - printk(KERN_WARNING "%s: Error probing MII device.\n", net_dev->name); + printk(KERN_WARNING "%s: Error probing MII device.\n", + dev_name); ret = -ENODEV; - goto err_out_unregister; + goto err_unmap_rx; } /* save our host bridge revision */ @@ -519,6 +518,10 @@ pci_dev_put(dev); } + ret = register_netdev(net_dev); + if (ret) + goto err_unmap_rx; + /* print some information about our NIC */ printk(KERN_INFO "%s: %s at %#lx, IRQ %d, ", net_dev->name, card_name, ioaddr, net_dev->irq); @@ -528,8 +531,6 @@ return 0; - err_out_unregister: - unregister_netdev(net_dev); err_unmap_rx: pci_free_consistent(pci_dev, RX_TOTAL_SIZE, sis_priv->rx_ring, sis_priv->rx_ring_dma); @@ -556,6 +557,7 @@ static int __init sis900_mii_probe(struct net_device * net_dev) { struct sis900_private * sis_priv = net_dev->priv; + const char *dev_name = pci_name(sis_priv->pci_dev); u16 poll_bit = MII_STAT_LINK, status = 0; unsigned long timeout = jiffies + 5 * HZ; int phy_addr; @@ -576,7 +578,7 @@ if (netif_msg_probe(sis_priv)) printk(KERN_DEBUG "%s: MII at address %d" " not accessible\n", - net_dev->name, phy_addr); + dev_name, phy_addr); continue; } @@ -609,7 +611,7 @@ (mii_status & (MII_STAT_CAN_TX_FDX | MII_STAT_CAN_TX)) ? LAN : HOME; printk(KERN_INFO "%s: %s transceiver found " "at address %d.\n", - net_dev->name, + dev_name, mii_chip_table[i].name, phy_addr); break; @@ -617,14 +619,13 @@ if( !mii_chip_table[i].phy_id1 ) { printk(KERN_INFO "%s: Unknown PHY transceiver found at address %d.\n", - net_dev->name, phy_addr); + dev_name, phy_addr); mii_phy->phy_types = UNKNOWN; } } if (sis_priv->mii == NULL) { - printk(KERN_INFO "%s: No MII transceivers found!\n", - net_dev->name); + printk(KERN_INFO "%s: No MII transceivers found!\n", dev_name); return 0; } @@ -649,7 +650,7 @@ poll_bit ^= (mdio_read(net_dev, sis_priv->cur_phy, MII_STATUS) & poll_bit); if (time_after_eq(jiffies, timeout)) { printk(KERN_WARNING "%s: reset phy and link down now\n", - net_dev->name); + dev_name); return -ETIME; } } @@ -718,7 +719,7 @@ sis_priv->mii = default_phy; sis_priv->cur_phy = default_phy->phy_addr; printk(KERN_INFO "%s: Using transceiver found at address %d as default\n", - net_dev->name,sis_priv->cur_phy); + pci_name(sis_priv->pci_dev), sis_priv->cur_phy); } status = mdio_read(net_dev, sis_priv->cur_phy, MII_CONTROL); diff -Nru a/drivers/net/via-rhine.c b/drivers/net/via-rhine.c --- a/drivers/net/via-rhine.c 2005-03-09 15:16:53 -05:00 +++ b/drivers/net/via-rhine.c 2005-03-09 15:16:53 -05:00 @@ -1901,6 +1901,9 @@ struct rhine_private *rp = netdev_priv(dev); void __iomem *ioaddr = rp->base; + if (!(rp->quirks & rqWOL)) + return; /* Nothing to do for non-WOL adapters */ + rhine_power_init(dev); /* Make sure we use pattern 0, 1 and not 4, 5 */ --------------020208010505070903000204-- From jgarzik@pobox.com Wed Mar 9 12:21:52 2005 Received: with ECARTIS (v1.0.0; list netdev); Wed, 09 Mar 2005 12:21:55 -0800 (PST) Received: from parcelfarce.linux.theplanet.co.uk (IDENT:93@parcelfarce.linux.theplanet.co.uk [195.92.249.252]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j29KLpbk015454 for ; Wed, 9 Mar 2005 12:21:51 -0800 Received: from [69.134.152.124] (helo=[10.10.10.88]) by parcelfarce.linux.theplanet.co.uk with asmtp (TLSv1:AES256-SHA:256) (Exim 4.33) id 1D97gb-00023b-FJ; Wed, 09 Mar 2005 20:21:41 +0000 Message-ID: <422F5AC3.1010103@pobox.com> Date: Wed, 09 Mar 2005 15:21:23 -0500 From: Jeff Garzik User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.3) Gecko/20040922 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Herbert Xu CC: Adrian Bunk , akpm@osdl.org, davem@davemloft.net, netdev@oss.sgi.com Subject: Re: [patch 1/3] fix buggy IEEE80211_CRYPT_* selects References: <200503041237.j24Cbb69026470@shell0.pdx.osdl.net> <42289BDF.1080409@pobox.com> <20050304221014.GJ3327@stusta.de> <4228DF62.4000205@pobox.com> <20050304230718.GL3327@stusta.de> <20050306090936.GA31890@gondor.apana.org.au> <422B4552.5000504@pobox.com> <20050306210937.GA3233@gondor.apana.org.au> In-Reply-To: <20050306210937.GA3233@gondor.apana.org.au> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV 0.83/757/Tue Mar 8 15:14:36 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 2749 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: jgarzik@pobox.com Precedence: bulk X-list: netdev Content-Length: 431 Lines: 16 Herbert Xu wrote: > On Sun, Mar 06, 2005 at 01:00:50PM -0500, Jeff Garzik wrote: > >>I would rather fix Kconfig. If we are selecting X_1 -- which explicitly >>depends on X -- when Kconfig should automatically select X. > > > That would be nice to have. However, until such a patch is integrated > we need to write Kconfig entries that work properly. Who has contacted the Kconfig maintainer, and asked about this? Jeff From tgraf@suug.ch Wed Mar 9 12:23:34 2005 Received: with ECARTIS (v1.0.0; list netdev); Wed, 09 Mar 2005 12:23:39 -0800 (PST) Received: from b.mx.projectdream.org (eth0-0.arisu.projectdream.org [194.158.4.191]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j29KNXQv015932 for ; Wed, 9 Mar 2005 12:23:33 -0800 Received: from postel.suug.ch (postel.suug.ch [195.134.158.23]) (using TLSv1 with cipher EDH-RSA-DES-CBC3-SHA (168/168 bits)) (No client certificate requested) by b.mx.projectdream.org (Postfix) with ESMTP id 76B9B8D; Wed, 9 Mar 2005 21:23:10 +0100 (CET) Received: by postel.suug.ch (Postfix, from userid 10001) id CB45E1C0EA; Wed, 9 Mar 2005 21:23:53 +0100 (CET) Date: Wed, 9 Mar 2005 21:23:53 +0100 From: Thomas Graf To: Patrick McHardy Cc: "David S. Miller" , netdev@oss.sgi.com Subject: Re: [PATCH 2/11] [NET] Convert sk_zapped into SOCK_ZAPPED flag Message-ID: <20050309202353.GU31837@postel.suug.ch> References: <20050309194521.GH31837@postel.suug.ch> <20050309194711.GJ31837@postel.suug.ch> <422F5461.4080008@trash.net> <20050309195649.GT31837@postel.suug.ch> <422F571E.2020708@trash.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <422F571E.2020708@trash.net> X-Virus-Scanned: ClamAV 0.83/757/Tue Mar 8 15:14:36 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 2750 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: tgraf@suug.ch Precedence: bulk X-list: netdev Content-Length: 937 Lines: 27 * Patrick McHardy <422F571E.2020708@trash.net> 2005-03-09 21:05 > Thomas Graf wrote: > >* Patrick McHardy <422F5461.4080008@trash.net> 2005-03-09 20:54 > >> > >>What about volatile ? sock_set_flag() uses __set_bit(), so its not > >>the same. > > > > > >I thought about this for a while but couldn't find a reason > >why it shouldn't work. Actually I don't even see any reason for > >having sk_zapped be volatile. > > You're probably right. I believe this piece of code from 2.4 is the > reason for it beeing volatile: > > #ifdef TCP_DEBUG > if (sk->zapped) { > printk(KERN_DEBUG "TCP: double destroy sk=%p\n", sk); > sock_hold(sk); > } > sk->zapped = 1; > #endif Yes, this makes sense. I haven't spotted any places in 2.6 where any of the flags I've converted would suffer from a reordering. Since all the flags have been chars the missing atomicy shouldn't be an issue either. From jgarzik@pobox.com Wed Mar 9 12:24:09 2005 Received: with ECARTIS (v1.0.0; list netdev); Wed, 09 Mar 2005 12:24:16 -0800 (PST) Received: from parcelfarce.linux.theplanet.co.uk (IDENT:93@parcelfarce.linux.theplanet.co.uk [195.92.249.252]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j29KO8q2016232 for ; Wed, 9 Mar 2005 12:24:09 -0800 Received: from [69.134.152.124] (helo=[10.10.10.88]) by parcelfarce.linux.theplanet.co.uk with asmtp (TLSv1:AES256-SHA:256) (Exim 4.33) id 1D97iw-0002L6-MN; Wed, 09 Mar 2005 20:24:07 +0000 Message-ID: <422F5B56.2030405@pobox.com> Date: Wed, 09 Mar 2005 15:23:50 -0500 From: Jeff Garzik User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.3) Gecko/20040922 X-Accept-Language: en-us, en MIME-Version: 1.0 To: domen@coderock.org CC: netdev@oss.sgi.com, nacc@us.ibm.com Subject: Re: [patch 16/26] net/sb1000: replace nicedelay() with ssleep() References: <20050306103329.9BCC41E46E@trashy.coderock.org> In-Reply-To: <20050306103329.9BCC41E46E@trashy.coderock.org> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV 0.83/757/Tue Mar 8 15:14:36 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 2751 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: jgarzik@pobox.com Precedence: bulk X-list: netdev Content-Length: 2853 Lines: 77 domen@coderock.org wrote: > Use ssleep() instead of nicedelay() > to guarantee the task delays as expected. Remove the prototype and > definition of nicedelay(). This is a very weird function, because it is > called to sleep in terms of usecs, but always sleeps for 1 second, > completely ignoring the parameter. I have gone ahead and followed suit, > just sleeping for a second in all cases, but maybe someone with the > hardware could tell me if perhaps the paramter *should* matter. Additionally, > nicedelay() is called in TASK_INTERRUPTIBLE state, but doesn't deal with signals > in case these longer delays do not complete, so I believe ssleep() is more > appropriate. > > Signed-off-by: Nishanth Aravamudan > Signed-off-by: Domen Puncer > --- > > > kj-domen/drivers/net/sb1000.c | 14 +++----------- > 1 files changed, 3 insertions(+), 11 deletions(-) > > diff -puN drivers/net/sb1000.c~ssleep-drivers_net_sb1000 drivers/net/sb1000.c > --- kj/drivers/net/sb1000.c~ssleep-drivers_net_sb1000 2005-03-05 16:11:16.000000000 +0100 > +++ kj-domen/drivers/net/sb1000.c 2005-03-05 16:11:16.000000000 +0100 > @@ -90,7 +90,6 @@ static int sb1000_close(struct net_devic > > > /* SB1000 hardware routines to be used during open/configuration phases */ > -static inline void nicedelay(unsigned long usecs); > static inline int card_wait_for_busy_clear(const int ioaddr[], > const char* name); > static inline int card_wait_for_ready(const int ioaddr[], const char* name, > @@ -254,13 +253,6 @@ static struct pnp_driver sb1000_driver = > > const int TimeOutJiffies = (875 * HZ) / 100; > > -static inline void nicedelay(unsigned long usecs) > -{ > - current->state = TASK_INTERRUPTIBLE; > - schedule_timeout(HZ); > - return; > -} > - > /* Card Wait For Busy Clear (cannot be used during an interrupt) */ > static inline int > card_wait_for_busy_clear(const int ioaddr[], const char* name) > @@ -475,7 +467,7 @@ sb1000_reset(const int ioaddr[], const c > udelay(1000); > outb(0x0, port); > inb(port); > - nicedelay(60000); > + ssleep(1); > outb(0x4, port); > inb(port); > udelay(1000); > @@ -537,7 +529,7 @@ sb1000_activate(const int ioaddr[], cons > const unsigned char Command0[6] = {0x80, 0x11, 0x00, 0x00, 0x00, 0x00}; > const unsigned char Command1[6] = {0x80, 0x16, 0x00, 0x00, 0x00, 0x00}; > > - nicedelay(50000); > + ssleep(1); > if ((status = card_send_command(ioaddr, name, Command0, st))) > return status; > if ((status = card_send_command(ioaddr, name, Command1, st))) > @@ -944,7 +936,7 @@ sb1000_open(struct net_device *dev) > /* initialize sb1000 */ > if ((status = sb1000_reset(ioaddr, name))) > return status; > - nicedelay(200000); > + ssleep(1); obviously incorrect, as you converted 60000, 50000, and 200000 usecs all into "1 second". Jeff From vanco@satro.sk Wed Mar 9 12:24:38 2005 Received: with ECARTIS (v1.0.0; list netdev); Wed, 09 Mar 2005 12:24:45 -0800 (PST) Received: from mail.satronet.sk (mail.satronet.sk [217.144.16.198]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j29KOb7w016491 for ; Wed, 9 Mar 2005 12:24:37 -0800 Received: from localhost (localhost.localdomain [127.0.0.1]) by mail.satronet.sk (Postfix) with ESMTP id 8EF8516057030; Wed, 9 Mar 2005 21:24:36 +0100 (CET) Received: from mail.satronet.sk ([127.0.0.1]) by localhost (mail [127.0.0.1]) (amavisd-new, port 10024) with LMTP id 15843-03-8; Wed, 9 Mar 2005 21:24:33 +0100 (CET) Received: from [10.1.14.226] (strojar.garda.sk [147.175.8.5]) (using TLSv1 with cipher RC4-MD5 (128/128 bits)) (No client certificate requested) by mail.satronet.sk (Postfix) with ESMTP id 6A9A116056656; Wed, 9 Mar 2005 21:24:33 +0100 (CET) From: Michal Vanco Organization: Satro, s.r.o. To: netdev@oss.sgi.com Subject: Re: 2.6.11 on AMD64 traps Date: Wed, 9 Mar 2005 21:24:34 +0100 User-Agent: KMail/1.7.2 Cc: Patrick McHardy , Andre Tomt , linux-kernel@vger.kernel.org, "David S. Miller" References: <200503081900.18686.vanco@satro.sk> <422DF07D.7010908@tomt.net> <422F525F.90404@trash.net> In-Reply-To: <422F525F.90404@trash.net> MIME-Version: 1.0 Content-Type: multipart/signed; boundary="nextPart1903376.zXjrLv5dby"; protocol="application/pgp-signature"; micalg=pgp-sha1 Content-Transfer-Encoding: 7bit Message-Id: <200503092124.35190.vanco@satro.sk> X-Virus-Scanned: ClamAV 0.83/757/Tue Mar 8 15:14:36 2005 on oss.sgi.com X-Virus-Scanned: by ANTIvirus at satronet.sk X-Virus-Status: Clean X-archive-position: 2752 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: vanco@satro.sk Precedence: bulk X-list: netdev Content-Length: 1392 Lines: 55 --nextPart1903376.zXjrLv5dby Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline On Wednesday 09 March 2005 20:45, Patrick McHardy wrote: > > Michal Vanco wrote: > >> I see this problem running 2.6.11 on dual AMD64: > >> > >> Running quagga routing daemon (ospf+bgp) and issuing "netstat -rn |wc > >> -l" command > >> while quagga tries to load more than 154000 routes from its bgp > >> neighbours causes this trap: > > This patch should fix it. The crash is caused by stale pointers, > the pointers in fib_iter_state are not reloaded after seq->stop() > followed by seq->start(pos > 0). Well. Trap vanished after applying this patch, but another weird thing occu= rs: # ip route show | wc -l 156033 # date; time ip route show > /dev/null; date; time netstat -rn > /dev/null Wed Mar 9 22:15:21 CET 2005 real 0m0.656s user 0m0.415s sys 0m0.242s Wed Mar 9 22:15:22 CET 2005 real 6m41.472s user 0m1.261s sys 6m40.143s regards, =2D-=20 Ing. Michal Van=C4=8Do Network Engineer SATRO s.r.o. e-mail: vanco@satro.sk --nextPart1903376.zXjrLv5dby Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.0 (GNU/Linux) iD8DBQBCL1uDSBxxqpMaGkMRAqKtAKDbWteVSdcPVqH09x6ah6WAIUdcvgCdEULr p5lFlgeARv7hYiXkAz7mMMY= =KAOp -----END PGP SIGNATURE----- --nextPart1903376.zXjrLv5dby-- From jgarzik@pobox.com Wed Mar 9 12:25:58 2005 Received: with ECARTIS (v1.0.0; list netdev); Wed, 09 Mar 2005 12:26:04 -0800 (PST) Received: from parcelfarce.linux.theplanet.co.uk (IDENT:93@parcelfarce.linux.theplanet.co.uk [195.92.249.252]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j29KPvdi017333 for ; Wed, 9 Mar 2005 12:25:58 -0800 Received: from [69.134.152.124] (helo=[10.10.10.88]) by parcelfarce.linux.theplanet.co.uk with asmtp (TLSv1:AES256-SHA:256) (Exim 4.33) id 1D97ki-0002Mz-DE; Wed, 09 Mar 2005 20:25:56 +0000 Message-ID: <422F5BC6.9020802@pobox.com> Date: Wed, 09 Mar 2005 15:25:42 -0500 From: Jeff Garzik User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.3) Gecko/20040922 X-Accept-Language: en-us, en MIME-Version: 1.0 To: domen@coderock.org CC: netdev@oss.sgi.com, sfeldma@pobox.com, janitor@sternwelten.at, "David S. Miller" Subject: Re: [patch 11/26] janitor: net/tg3: pci_find_device to pci_dev_present References: <20050306103312.3155B1E46E@trashy.coderock.org> In-Reply-To: <20050306103312.3155B1E46E@trashy.coderock.org> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV 0.83/757/Tue Mar 8 15:14:36 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 2753 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: jgarzik@pobox.com Precedence: bulk X-list: netdev Content-Length: 2210 Lines: 58 domen@coderock.org wrote: > Replace pci_find_device with pci_dev_present. Compile tested. > > Signed-off-by: Scott Feldman > Signed-off-by: Maximilian Attems > Signed-off-by: Domen Puncer > --- > > > kj-domen/drivers/net/tg3.c | 24 ++++++++++++++---------- > 1 files changed, 14 insertions(+), 10 deletions(-) > > diff -puN drivers/net/tg3.c~remove-pci-find-device-drivers_net_tg3 drivers/net/tg3.c > --- kj/drivers/net/tg3.c~remove-pci-find-device-drivers_net_tg3 2005-03-05 16:09:45.000000000 +0100 > +++ kj-domen/drivers/net/tg3.c 2005-03-05 16:09:45.000000000 +0100 > @@ -7829,6 +7829,19 @@ static int __devinit tg3_is_sun_570X(str > > static int __devinit tg3_get_invariants(struct tg3 *tp) > { > + static struct pci_device_id write_reorder_chipsets[] = { > + { PCI_DEVICE(PCI_VENDOR_ID_INTEL, > + PCI_DEVICE_ID_INTEL_82801AA_8) }, > + { PCI_DEVICE(PCI_VENDOR_ID_INTEL, > + PCI_DEVICE_ID_INTEL_82801AB_8) }, > + { PCI_DEVICE(PCI_VENDOR_ID_INTEL, > + PCI_DEVICE_ID_INTEL_82801BA_11) }, > + { PCI_DEVICE(PCI_VENDOR_ID_INTEL, > + PCI_DEVICE_ID_INTEL_82801BA_6) }, > + { PCI_DEVICE(PCI_VENDOR_ID_AMD, > + PCI_DEVICE_ID_AMD_FE_GATE_700C) }, > + { }, > + }; > u32 misc_ctrl_reg; > u32 cacheline_sz_reg; > u32 pci_state_reg, grc_misc_cfg; > @@ -7847,16 +7860,7 @@ static int __devinit tg3_get_invariants( > * every mailbox register write to force the writes to be > * posted to the chip in order. > */ > - if (pci_find_device(PCI_VENDOR_ID_INTEL, > - PCI_DEVICE_ID_INTEL_82801AA_8, NULL) || > - pci_find_device(PCI_VENDOR_ID_INTEL, > - PCI_DEVICE_ID_INTEL_82801AB_8, NULL) || > - pci_find_device(PCI_VENDOR_ID_INTEL, > - PCI_DEVICE_ID_INTEL_82801BA_11, NULL) || > - pci_find_device(PCI_VENDOR_ID_INTEL, > - PCI_DEVICE_ID_INTEL_82801BA_6, NULL) || > - pci_find_device(PCI_VENDOR_ID_AMD, > - PCI_DEVICE_ID_AMD_FE_GATE_700C, NULL)) > + if (pci_dev_present(write_reorder_chipsets)) > tp->tg3_flags |= TG3_FLAG_MBOX_WRITE_REORDER; seems OK to me. DaveM should be applying this, though. Jeff From jgarzik@pobox.com Wed Mar 9 12:26:35 2005 Received: with ECARTIS (v1.0.0; list netdev); Wed, 09 Mar 2005 12:26:44 -0800 (PST) Received: from parcelfarce.linux.theplanet.co.uk (IDENT:93@parcelfarce.linux.theplanet.co.uk [195.92.249.252]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j29KQYqK017758 for ; Wed, 9 Mar 2005 12:26:35 -0800 Received: from [69.134.152.124] (helo=[10.10.10.88]) by parcelfarce.linux.theplanet.co.uk with asmtp (TLSv1:AES256-SHA:256) (Exim 4.33) id 1D97lK-0002Nm-1Y; Wed, 09 Mar 2005 20:26:34 +0000 Message-ID: <422F5BEC.5060909@pobox.com> Date: Wed, 09 Mar 2005 15:26:20 -0500 From: Jeff Garzik User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.3) Gecko/20040922 X-Accept-Language: en-us, en MIME-Version: 1.0 To: domen@coderock.org CC: netdev@oss.sgi.com, nacc@us.ibm.com, acme@conectiva.com.br, janitor@sternwelten.at Subject: Re: [patch 07/26] net/cycx_drv: replace delay_cycx() with msleep_interruptible() References: <20050306103258.6FC481E46E@trashy.coderock.org> In-Reply-To: <20050306103258.6FC481E46E@trashy.coderock.org> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV 0.83/757/Tue Mar 8 15:14:36 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 2754 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: jgarzik@pobox.com Precedence: bulk X-list: netdev Content-Length: 1740 Lines: 45 domen@coderock.org wrote: > Use msleep_interruptible() instead of delay_cycx() > to guarantee the task delays as expected. Remove the prototype and > definition of delay_cycx(). > > Signed-off-by: Nishanth Aravamudan > Acked-by: Arnaldo Carvalho de Melo > Signed-off-by: Maximilian Attems > Signed-off-by: Domen Puncer > --- > > > kj-domen/drivers/net/wan/cycx_drv.c | 24 ++++++++---------------- > 1 files changed, 8 insertions(+), 16 deletions(-) > > diff -puN drivers/net/wan/cycx_drv.c~msleep_interruptible-drivers_net_wan_cycx_drv drivers/net/wan/cycx_drv.c > --- kj/drivers/net/wan/cycx_drv.c~msleep_interruptible-drivers_net_wan_cycx_drv 2005-03-05 16:09:34.000000000 +0100 > +++ kj-domen/drivers/net/wan/cycx_drv.c 2005-03-05 16:09:34.000000000 +0100 > @@ -56,7 +56,7 @@ > #include /* for jiffies, HZ, etc. */ > #include /* API definitions */ > #include /* CYCX firmware module definitions */ > -#include /* udelay */ > +#include /* udelay, msleep */ > #include /* read[wl], write[wl], ioremap, iounmap */ > > #define MOD_VERSION 0 > @@ -74,7 +74,6 @@ static int reset_cyc2x(void __iomem *add > static int detect_cyc2x(void __iomem *addr); > > /* Miscellaneous functions */ > -static void delay_cycx(int sec); > static int get_option_index(long *optlist, long optval); > static u16 checksum(u8 *buf, u32 len); > > @@ -259,7 +258,7 @@ static int memory_exists(void __iomem *a > if (readw(addr + 0x10) == TEST_PATTERN) > return 1; > > - delay_cycx(1); > + msleep_interruptible(1000); use ssleep_interruptible From kaber@trash.net Wed Mar 9 12:35:02 2005 Received: with ECARTIS (v1.0.0; list netdev); Wed, 09 Mar 2005 12:35:05 -0800 (PST) Received: from kaber.coreworks.de ([62.206.217.67]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j29KZ1Mc018642 for ; Wed, 9 Mar 2005 12:35:02 -0800 Received: from localhost ([127.0.0.1]) by kaber.coreworks.de with esmtp (Exim 4.50) id 1D97tQ-0000FT-51; Wed, 09 Mar 2005 21:34:56 +0100 Message-ID: <422F5DF0.6060904@trash.net> Date: Wed, 09 Mar 2005 21:34:56 +0100 From: Patrick McHardy User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.7.5) Gecko/20050106 Debian/1.7.5-1 X-Accept-Language: en MIME-Version: 1.0 To: Michal Vanco CC: netdev@oss.sgi.com, Andre Tomt , linux-kernel@vger.kernel.org, "David S. Miller" Subject: Re: 2.6.11 on AMD64 traps References: <200503081900.18686.vanco@satro.sk> <422DF07D.7010908@tomt.net> <422F525F.90404@trash.net> <200503092124.35190.vanco@satro.sk> In-Reply-To: <200503092124.35190.vanco@satro.sk> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV 0.83/757/Tue Mar 8 15:14:36 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 2755 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: kaber@trash.net Precedence: bulk X-list: netdev Content-Length: 751 Lines: 28 Michal Vanco wrote: > On Wednesday 09 March 2005 20:45, Patrick McHardy wrote: >> >>This patch should fix it. The crash is caused by stale pointers, >>the pointers in fib_iter_state are not reloaded after seq->stop() >>followed by seq->start(pos > 0). > > Well. Trap vanished after applying this patch, but another weird thing occurs: > > # ip route show | wc -l > 156033 > # date; time ip route show > /dev/null; date; time netstat -rn > /dev/null > Wed Mar 9 22:15:21 CET 2005 > > real 0m0.656s > user 0m0.415s > sys 0m0.242s > Wed Mar 9 22:15:22 CET 2005 > > real 6m41.472s > user 0m1.261s > sys 6m40.143s Yes, I know it is totally inefficient. Just use ip route, which doesn't suffer from this problem. Regards Patrick From vanco@satro.sk Wed Mar 9 12:42:50 2005 Received: with ECARTIS (v1.0.0; list netdev); Wed, 09 Mar 2005 12:42:54 -0800 (PST) Received: from mail.satronet.sk (mail.satronet.sk [217.144.16.198]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j29Kgn07019257 for ; Wed, 9 Mar 2005 12:42:50 -0800 Received: from localhost (localhost.localdomain [127.0.0.1]) by mail.satronet.sk (Postfix) with ESMTP id CD3FF1605A1B0 for ; Wed, 9 Mar 2005 21:42:48 +0100 (CET) Received: from mail.satronet.sk ([127.0.0.1]) by localhost (mail [127.0.0.1]) (amavisd-new, port 10024) with LMTP id 16194-01-14 for ; Wed, 9 Mar 2005 21:42:47 +0100 (CET) Received: from [10.1.14.226] (strojar.garda.sk [147.175.8.5]) (using TLSv1 with cipher RC4-MD5 (128/128 bits)) (No client certificate requested) by mail.satronet.sk (Postfix) with ESMTP id B5EB016056656 for ; Wed, 9 Mar 2005 21:42:47 +0100 (CET) From: Michal Vanco Organization: Satro, s.r.o. To: netdev@oss.sgi.com Subject: Re: 2.6.11 on AMD64 traps Date: Wed, 9 Mar 2005 21:42:49 +0100 User-Agent: KMail/1.7.2 References: <200503081900.18686.vanco@satro.sk> <200503092124.35190.vanco@satro.sk> <422F5DF0.6060904@trash.net> In-Reply-To: <422F5DF0.6060904@trash.net> MIME-Version: 1.0 Content-Type: multipart/signed; boundary="nextPart1338469.ckzsfZg8Zz"; protocol="application/pgp-signature"; micalg=pgp-sha1 Content-Transfer-Encoding: 7bit Message-Id: <200503092142.50027.vanco@satro.sk> X-Virus-Scanned: ClamAV 0.83/757/Tue Mar 8 15:14:36 2005 on oss.sgi.com X-Virus-Scanned: by ANTIvirus at satronet.sk X-Virus-Status: Clean X-archive-position: 2756 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: vanco@satro.sk Precedence: bulk X-list: netdev Content-Length: 1489 Lines: 57 --nextPart1338469.ckzsfZg8Zz Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline On Wednesday 09 March 2005 21:34, Patrick McHardy wrote: > Michal Vanco wrote: > > On Wednesday 09 March 2005 20:45, Patrick McHardy wrote: > >>This patch should fix it. The crash is caused by stale pointers, > >>the pointers in fib_iter_state are not reloaded after seq->stop() > >>followed by seq->start(pos > 0). > > > > Well. Trap vanished after applying this patch, but another weird thing > > occurs: > > > > # ip route show | wc -l > > 156033 > > # date; time ip route show > /dev/null; date; time netstat -rn > > > /dev/null Wed Mar 9 22:15:21 CET 2005 > > > > real 0m0.656s > > user 0m0.415s > > sys 0m0.242s > > Wed Mar 9 22:15:22 CET 2005 > > > > real 6m41.472s > > user 0m1.261s > > sys 6m40.143s > > Yes, I know it is totally inefficient. Just use ip route, which doesn't > suffer from this problem. > Sure. Can (or will) this ever be fixed to any usable state also with netsta= t? Is this problem related only to AMD64? regards, =2D-=20 Ing. Michal Van=C4=8Do Network Engineer SATRO s.r.o. e-mail: vanco@satro.sk --nextPart1338469.ckzsfZg8Zz Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.0 (GNU/Linux) iD8DBQBCL1/JSBxxqpMaGkMRAncMAKC0uP10O/lE1ssSDeb8Bg1v4TXQlwCfVo5h fq/IsEk9ojedms9RJPDdDtw= =alsO -----END PGP SIGNATURE----- --nextPart1338469.ckzsfZg8Zz-- From kaber@trash.net Wed Mar 9 13:05:33 2005 Received: with ECARTIS (v1.0.0; list netdev); Wed, 09 Mar 2005 13:05:36 -0800 (PST) Received: from kaber.coreworks.de ([62.206.217.67]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j29L5WJM020346 for ; Wed, 9 Mar 2005 13:05:32 -0800 Received: from localhost ([127.0.0.1]) by kaber.coreworks.de with esmtp (Exim 4.50) id 1D98Mx-0000KP-6B; Wed, 09 Mar 2005 22:05:27 +0100 Message-ID: <422F6517.6070301@trash.net> Date: Wed, 09 Mar 2005 22:05:27 +0100 From: Patrick McHardy User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.7.5) Gecko/20050106 Debian/1.7.5-1 X-Accept-Language: en MIME-Version: 1.0 To: Michal Vanco CC: netdev@oss.sgi.com Subject: Re: 2.6.11 on AMD64 traps References: <200503081900.18686.vanco@satro.sk> <200503092124.35190.vanco@satro.sk> <422F5DF0.6060904@trash.net> <200503092142.50027.vanco@satro.sk> In-Reply-To: <200503092142.50027.vanco@satro.sk> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV 0.83/757/Tue Mar 8 15:14:36 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 2757 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: kaber@trash.net Precedence: bulk X-list: netdev Content-Length: 694 Lines: 18 Michal Vanco wrote: > On Wednesday 09 March 2005 21:34, Patrick McHardy wrote: >> >>Yes, I know it is totally inefficient. Just use ip route, which doesn't >>suffer from this problem. > > Sure. Can (or will) this ever be fixed to any usable state also with netstat? > Is this problem related only to AMD64? Maybe. To start dumping entries of an open hashed hash-table at a specific position we need to skip all entries before that position by walking over them. This results in quadratic time complexity. It might be possible to improve this by cacheing the last position in fib_iter_state even between ->stop() and ->start() calls and using generation IDs for invalidation. Regards Patrick From vanco@satro.sk Wed Mar 9 13:17:01 2005 Received: with ECARTIS (v1.0.0; list netdev); Wed, 09 Mar 2005 13:17:04 -0800 (PST) Received: from mail.satronet.sk (mail.satronet.sk [217.144.16.198]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j29LH0ne021000 for ; Wed, 9 Mar 2005 13:17:01 -0800 Received: from localhost (localhost.localdomain [127.0.0.1]) by mail.satronet.sk (Postfix) with ESMTP id DDA5A16057030; Wed, 9 Mar 2005 22:16:59 +0100 (CET) Received: from mail.satronet.sk ([127.0.0.1]) by localhost (mail [127.0.0.1]) (amavisd-new, port 10024) with LMTP id 16689-03-2; Wed, 9 Mar 2005 22:16:58 +0100 (CET) Received: from [10.1.14.226] (strojar.garda.sk [147.175.8.5]) (using TLSv1 with cipher RC4-MD5 (128/128 bits)) (No client certificate requested) by mail.satronet.sk (Postfix) with ESMTP id DF05816056656; Wed, 9 Mar 2005 22:16:58 +0100 (CET) From: Michal Vanco Organization: Satro, s.r.o. To: netdev@oss.sgi.com Subject: Re: 2.6.11 on AMD64 traps Date: Wed, 9 Mar 2005 22:17:00 +0100 User-Agent: KMail/1.7.2 Cc: Patrick McHardy References: <200503081900.18686.vanco@satro.sk> <200503092142.50027.vanco@satro.sk> <422F6517.6070301@trash.net> In-Reply-To: <422F6517.6070301@trash.net> MIME-Version: 1.0 Content-Type: multipart/signed; boundary="nextPart2112481.KRQqhVlnu6"; protocol="application/pgp-signature"; micalg=pgp-sha1 Content-Transfer-Encoding: 7bit Message-Id: <200503092217.01106.vanco@satro.sk> X-Virus-Scanned: ClamAV 0.83/757/Tue Mar 8 15:14:36 2005 on oss.sgi.com X-Virus-Scanned: by ANTIvirus at satronet.sk X-Virus-Status: Clean X-archive-position: 2758 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: vanco@satro.sk Precedence: bulk X-list: netdev Content-Length: 1230 Lines: 40 --nextPart2112481.KRQqhVlnu6 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline On Wednesday 09 March 2005 22:05, Patrick McHardy wrote: > Michal Vanco wrote: > > On Wednesday 09 March 2005 21:34, Patrick McHardy wrote: > >>Yes, I know it is totally inefficient. Just use ip route, which doesn't > >>suffer from this problem. > > > > Sure. Can (or will) this ever be fixed to any usable state also with > > netstat? Is this problem related only to AMD64? > > Maybe. To start dumping entries of an open hashed hash-table at a > specific position we need to skip all entries before that position by > walking over them. This results in quadratic time complexity. It might > be possible to improve this by cacheing the last position in > fib_iter_state even between ->stop() and ->start() calls and using > generation IDs for invalidation. > Ok. Thank's for help. regards, Michal --nextPart2112481.KRQqhVlnu6 Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.0 (GNU/Linux) iD4DBQBCL2fNSBxxqpMaGkMRAssVAJdZmGvV0Q1or0ISlwKD2ouVrqwoAJ9pw3VQ +UIGlGHHGjOsRVZkLThTDg== =JAAy -----END PGP SIGNATURE----- --nextPart2112481.KRQqhVlnu6-- From nacc@us.ibm.com Wed Mar 9 13:18:42 2005 Received: with ECARTIS (v1.0.0; list netdev); Wed, 09 Mar 2005 13:18:47 -0800 (PST) Received: from e3.ny.us.ibm.com (e3.ny.us.ibm.com [32.97.182.143]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j29LIfM2021395 for ; Wed, 9 Mar 2005 13:18:41 -0800 Received: from d01relay04.pok.ibm.com (d01relay04.pok.ibm.com [9.56.227.236]) by e3.ny.us.ibm.com (8.12.11/8.12.11) with ESMTP id j29LIaP5028349 for ; Wed, 9 Mar 2005 16:18:36 -0500 Received: from d01av02.pok.ibm.com (d01av02.pok.ibm.com [9.56.224.216]) by d01relay04.pok.ibm.com (8.12.10/NCO/VER6.6) with ESMTP id j29LIa15238692 for ; Wed, 9 Mar 2005 16:18:36 -0500 Received: from d01av02.pok.ibm.com (loopback [127.0.0.1]) by d01av02.pok.ibm.com (8.12.11/8.12.11) with ESMTP id j29LIZCK001323 for ; Wed, 9 Mar 2005 16:18:35 -0500 Received: from joust (joust.beaverton.ibm.com [9.47.17.68]) by d01av02.pok.ibm.com (8.12.11/8.12.11) with ESMTP id j29LIZ9X001313; Wed, 9 Mar 2005 16:18:35 -0500 Received: by joust (Postfix, from userid 1000) id 282C64F8A4; Wed, 9 Mar 2005 13:18:34 -0800 (PST) Date: Wed, 9 Mar 2005 13:18:34 -0800 From: Nishanth Aravamudan To: Jeff Garzik Cc: domen@coderock.org, netdev@oss.sgi.com, acme@conectiva.com.br, janitor@sternwelten.at Subject: Re: [patch 07/26] net/cycx_drv: replace delay_cycx() with msleep_interruptible() Message-ID: <20050309211834.GE3685@us.ibm.com> References: <20050306103258.6FC481E46E@trashy.coderock.org> <422F5BEC.5060909@pobox.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <422F5BEC.5060909@pobox.com> X-Operating-System: Linux 2.6.11 (i686) User-Agent: Mutt/1.5.6+20040907i X-Virus-Scanned: ClamAV 0.83/757/Tue Mar 8 15:14:36 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 2759 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: nacc@us.ibm.com Precedence: bulk X-list: netdev Content-Length: 2288 Lines: 60 On Wed, Mar 09, 2005 at 03:26:20PM -0500, Jeff Garzik wrote: > domen@coderock.org wrote: > >Use msleep_interruptible() instead of delay_cycx() > >to guarantee the task delays as expected. Remove the prototype and > >definition of delay_cycx(). > > > >Signed-off-by: Nishanth Aravamudan > >Acked-by: Arnaldo Carvalho de Melo > >Signed-off-by: Maximilian Attems > >Signed-off-by: Domen Puncer > >--- > > > > > > kj-domen/drivers/net/wan/cycx_drv.c | 24 ++++++++---------------- > > 1 files changed, 8 insertions(+), 16 deletions(-) > > > >diff -puN > >drivers/net/wan/cycx_drv.c~msleep_interruptible-drivers_net_wan_cycx_drv > >drivers/net/wan/cycx_drv.c > >--- > >kj/drivers/net/wan/cycx_drv.c~msleep_interruptible-drivers_net_wan_cycx_drv 2005-03-05 16:09:34.000000000 +0100 > >+++ kj-domen/drivers/net/wan/cycx_drv.c 2005-03-05 > >16:09:34.000000000 +0100 > >@@ -56,7 +56,7 @@ > > #include /* for jiffies, HZ, etc. */ > > #include /* API definitions */ > > #include /* CYCX firmware module definitions */ > >-#include /* udelay */ > >+#include /* udelay, msleep */ > > #include /* read[wl], write[wl], ioremap, iounmap */ > > > > #define MOD_VERSION 0 > >@@ -74,7 +74,6 @@ static int reset_cyc2x(void __iomem *add > > static int detect_cyc2x(void __iomem *addr); > > > > /* Miscellaneous functions */ > >-static void delay_cycx(int sec); > > static int get_option_index(long *optlist, long optval); > > static u16 checksum(u8 *buf, u32 len); > > > >@@ -259,7 +258,7 @@ static int memory_exists(void __iomem *a > > if (readw(addr + 0x10) == TEST_PATTERN) > > return 1; > > > >- delay_cycx(1); > >+ msleep_interruptible(1000); > > use ssleep_interruptible ssleep_interruptible() doesn't exist; there was much discussion of whether it should, but then we ran into issues of: ssleep_interruptible(1) -> msleep_interruptible(1000), which returns, say, 452, i.e. 452 milliseconds left in sleep. Should ssleep_interruptible() return 452 and thus take seconds as a parameter and milliseconds as a return value or should it return 0? or 1? It was all to confusing for me :) Thanks, Nish From nacc@us.ibm.com Wed Mar 9 13:19:46 2005 Received: with ECARTIS (v1.0.0; list netdev); Wed, 09 Mar 2005 13:19:50 -0800 (PST) Received: from e5.ny.us.ibm.com (e5.ny.us.ibm.com [32.97.182.145]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j29LJjjL022039 for ; Wed, 9 Mar 2005 13:19:46 -0800 Received: from d01relay02.pok.ibm.com (d01relay02.pok.ibm.com [9.56.227.234]) by e5.ny.us.ibm.com (8.12.11/8.12.11) with ESMTP id j29LJekq031694 for ; Wed, 9 Mar 2005 16:19:40 -0500 Received: from d01av02.pok.ibm.com (d01av02.pok.ibm.com [9.56.224.216]) by d01relay02.pok.ibm.com (8.12.10/NCO/VER6.6) with ESMTP id j29LJenA070414 for ; Wed, 9 Mar 2005 16:19:40 -0500 Received: from d01av02.pok.ibm.com (loopback [127.0.0.1]) by d01av02.pok.ibm.com (8.12.11/8.12.11) with ESMTP id j29LJeYA004401 for ; Wed, 9 Mar 2005 16:19:40 -0500 Received: from joust (joust.beaverton.ibm.com [9.47.17.68]) by d01av02.pok.ibm.com (8.12.11/8.12.11) with ESMTP id j29LJdOP004382; Wed, 9 Mar 2005 16:19:40 -0500 Received: by joust (Postfix, from userid 1000) id EE24D4F8A4; Wed, 9 Mar 2005 13:19:38 -0800 (PST) Date: Wed, 9 Mar 2005 13:19:38 -0800 From: Nishanth Aravamudan To: Jeff Garzik Cc: domen@coderock.org, netdev@oss.sgi.com Subject: Re: [patch 16/26] net/sb1000: replace nicedelay() with ssleep() Message-ID: <20050309211938.GF3685@us.ibm.com> References: <20050306103329.9BCC41E46E@trashy.coderock.org> <422F5B56.2030405@pobox.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <422F5B56.2030405@pobox.com> X-Operating-System: Linux 2.6.11 (i686) User-Agent: Mutt/1.5.6+20040907i X-Virus-Scanned: ClamAV 0.83/757/Tue Mar 8 15:14:36 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 2760 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: nacc@us.ibm.com Precedence: bulk X-list: netdev Content-Length: 3214 Lines: 87 On Wed, Mar 09, 2005 at 03:23:50PM -0500, Jeff Garzik wrote: > domen@coderock.org wrote: > >Use ssleep() instead of nicedelay() > >to guarantee the task delays as expected. Remove the prototype and > >definition of nicedelay(). This is a very weird function, because it is > >called to sleep in terms of usecs, but always sleeps for 1 second, > >completely ignoring the parameter. I have gone ahead and followed suit, > >just sleeping for a second in all cases, but maybe someone with the > >hardware could tell me if perhaps the paramter *should* matter. > >Additionally, > >nicedelay() is called in TASK_INTERRUPTIBLE state, but doesn't deal with > >signals > >in case these longer delays do not complete, so I believe ssleep() is more > >appropriate. > > > >Signed-off-by: Nishanth Aravamudan > >Signed-off-by: Domen Puncer > >--- > > > > > > kj-domen/drivers/net/sb1000.c | 14 +++----------- > > 1 files changed, 3 insertions(+), 11 deletions(-) > > > >diff -puN drivers/net/sb1000.c~ssleep-drivers_net_sb1000 > >drivers/net/sb1000.c > >--- kj/drivers/net/sb1000.c~ssleep-drivers_net_sb1000 2005-03-05 > >16:11:16.000000000 +0100 > >+++ kj-domen/drivers/net/sb1000.c 2005-03-05 16:11:16.000000000 +0100 > >@@ -90,7 +90,6 @@ static int sb1000_close(struct net_devic > > > > > > /* SB1000 hardware routines to be used during open/configuration phases */ > >-static inline void nicedelay(unsigned long usecs); > > static inline int card_wait_for_busy_clear(const int ioaddr[], > > const char* name); > > static inline int card_wait_for_ready(const int ioaddr[], const char* > > name, > >@@ -254,13 +253,6 @@ static struct pnp_driver sb1000_driver = > > > > const int TimeOutJiffies = (875 * HZ) / 100; > > > >-static inline void nicedelay(unsigned long usecs) > >-{ > >- current->state = TASK_INTERRUPTIBLE; > >- schedule_timeout(HZ); > >- return; > >-} > >- > > /* Card Wait For Busy Clear (cannot be used during an interrupt) */ > > static inline int > > card_wait_for_busy_clear(const int ioaddr[], const char* name) > >@@ -475,7 +467,7 @@ sb1000_reset(const int ioaddr[], const c > > udelay(1000); > > outb(0x0, port); > > inb(port); > >- nicedelay(60000); > >+ ssleep(1); > > outb(0x4, port); > > inb(port); > > udelay(1000); > >@@ -537,7 +529,7 @@ sb1000_activate(const int ioaddr[], cons > > const unsigned char Command0[6] = {0x80, 0x11, 0x00, 0x00, 0x00, > > 0x00}; > > const unsigned char Command1[6] = {0x80, 0x16, 0x00, 0x00, 0x00, > > 0x00}; > > > >- nicedelay(50000); > >+ ssleep(1); > > if ((status = card_send_command(ioaddr, name, Command0, st))) > > return status; > > if ((status = card_send_command(ioaddr, name, Command1, st))) > >@@ -944,7 +936,7 @@ sb1000_open(struct net_device *dev) > > /* initialize sb1000 */ > > if ((status = sb1000_reset(ioaddr, name))) > > return status; > >- nicedelay(200000); > >+ ssleep(1); > > obviously incorrect, as you converted 60000, 50000, and 200000 usecs all > into "1 second". Except that nicdelay() blatantly ignored the parameter. I asked several times about this function and got no response. nicedelay() requests a second delay currently, so I used ssleep(). Thanks, Nish From greearb@candelatech.com Wed Mar 9 13:35:52 2005 Received: with ECARTIS (v1.0.0; list netdev); Wed, 09 Mar 2005 13:35:57 -0800 (PST) Received: from www.lanforge.com (ns1.lanforge.com [66.165.47.210]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j29LZqOb022862 for ; Wed, 9 Mar 2005 13:35:52 -0800 Received: from [4.33.45.22] (evrtwa1-ar2-4-33-045-022.evrtwa1.dsl-verizon.net [4.33.45.22]) (authenticated bits=0) by www.lanforge.com (8.12.8/8.12.8) with ESMTP id j29Lx7LH003878 for ; Wed, 9 Mar 2005 13:59:07 -0800 Message-ID: <422F6C37.8090202@candelatech.com> Date: Wed, 09 Mar 2005 13:35:51 -0800 From: Ben Greear Organization: Candela Technologies User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.7.3) Gecko/20041020 X-Accept-Language: en-us, en MIME-Version: 1.0 To: "'netdev@oss.sgi.com'" Subject: ethtool -d no longer works for e1000 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV 0.83/757/Tue Mar 8 15:14:36 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 2761 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: greearb@candelatech.com Precedence: bulk X-list: netdev Content-Length: 385 Lines: 16 I tried this with FC2's 2.6.10-1.770_FC2smp kernel and with my own slightly hacked 2.6.11 kernel. Both give this response: ethtool -d eth0 Cannot dump registers: Success I am quite certain this used to work, and used to show me the PCI bus speed and other nice details... Thanks, Ben -- Ben Greear Candela Technologies Inc http://www.candelatech.com From romieu@fr.zoreil.com Wed Mar 9 13:41:04 2005 Received: with ECARTIS (v1.0.0; list netdev); Wed, 09 Mar 2005 13:41:10 -0800 (PST) Received: from fr.zoreil.com (electric-eye.fr.zoreil.com [213.41.134.224]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j29Lf3Bc023603 for ; Wed, 9 Mar 2005 13:41:04 -0800 Received: from electric-eye.fr.zoreil.com (localhost.localdomain [127.0.0.1]) by fr.zoreil.com (8.13.1/8.12.1) with ESMTP id j29LeSb0009635; Wed, 9 Mar 2005 22:40:28 +0100 Received: (from romieu@localhost) by electric-eye.fr.zoreil.com (8.13.1/8.13.1/Submit) id j29LeNob009634; Wed, 9 Mar 2005 22:40:23 +0100 Date: Wed, 9 Mar 2005 22:40:23 +0100 From: Francois Romieu To: Andi Kleen Cc: Stephen Hemminger , netdev@oss.sgi.com Subject: Re: [PATCH 1/5] r8169: auto detect 32-bit slot Message-ID: <20050309214023.GA9502@electric-eye.fr.zoreil.com> References: <20050309112925.7f7900ab@dxpl.pdx.osdl.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.1i X-Organisation: Land of Sunshine Inc. X-Virus-Scanned: ClamAV 0.83/757/Tue Mar 8 15:14:36 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 2762 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: romieu@fr.zoreil.com Precedence: bulk X-list: netdev Content-Length: 215 Lines: 11 Andi Kleen : [...] > Hmm? It doesn't support DAC? It does but it is unstable for everybody (except Jon Mason, go figure) on amd64. Stephen, on which kind of system was this change tested ? -- Ueimor From jdmason@us.ibm.com Wed Mar 9 13:45:23 2005 Received: with ECARTIS (v1.0.0; list netdev); Wed, 09 Mar 2005 13:45:26 -0800 (PST) Received: from e33.co.us.ibm.com (e33.co.us.ibm.com [32.97.110.131]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j29LjMoC024209 for ; Wed, 9 Mar 2005 13:45:23 -0800 Received: from westrelay01.boulder.ibm.com (westrelay01.boulder.ibm.com [9.17.195.10]) by e33.co.us.ibm.com (8.12.10/8.12.9) with ESMTP id j29LjG4I716554 for ; Wed, 9 Mar 2005 16:45:17 -0500 Received: from d03av01.boulder.ibm.com (d03av01.boulder.ibm.com [9.17.195.167]) by westrelay01.boulder.ibm.com (8.12.10/NCO/VER6.6) with ESMTP id j29LjGtF172926 for ; Wed, 9 Mar 2005 14:45:16 -0700 Received: from d03av01.boulder.ibm.com (loopback [127.0.0.1]) by d03av01.boulder.ibm.com (8.12.11/8.12.11) with ESMTP id j29LjGQk032688 for ; Wed, 9 Mar 2005 14:45:16 -0700 Received: from dreadnought.austin.ibm.com (dreadnought.austin.ibm.com [9.41.94.123]) by d03av01.boulder.ibm.com (8.12.11/8.12.11) with ESMTP id j29LjF0Y032678; Wed, 9 Mar 2005 14:45:16 -0700 From: Jon Mason Organization: IBM To: Stephen Hemminger Subject: Re: [PATCH 5/5] r8169: ethtool hardware statistics support Date: Wed, 9 Mar 2005 15:37:30 -0600 User-Agent: KMail/1.7.2 Cc: Francois Romieu , netdev@oss.sgi.com References: <20050309113626.6708c93e@dxpl.pdx.osdl.net> In-Reply-To: <20050309113626.6708c93e@dxpl.pdx.osdl.net> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200503091537.30899.jdmason@us.ibm.com> X-Virus-Scanned: ClamAV 0.83/757/Tue Mar 8 15:14:36 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 2763 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: jdmason@us.ibm.com Precedence: bulk X-list: netdev Content-Length: 78 Lines: 1 Does this patch fix the problem of bogus statistics if the interface is down? From shemminger@osdl.org Wed Mar 9 13:53:36 2005 Received: with ECARTIS (v1.0.0; list netdev); Wed, 09 Mar 2005 13:53:39 -0800 (PST) Received: from smtp.osdl.org (fire.osdl.org [65.172.181.4]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j29Lraqg024810 for ; Wed, 9 Mar 2005 13:53:36 -0800 Received: from shell0.pdx.osdl.net (fw.osdl.org [65.172.181.6]) by smtp.osdl.org (8.12.8/8.12.8) with ESMTP id j29LrSqi030537 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO); Wed, 9 Mar 2005 13:53:28 -0800 Received: from dxpl.pdx.osdl.net (dxpl.pdx.osdl.net [172.20.1.103]) by shell0.pdx.osdl.net (8.13.1/8.11.6) with ESMTP id j29LrRtu023294; Wed, 9 Mar 2005 13:53:27 -0800 Date: Wed, 9 Mar 2005 13:53:45 -0800 From: Stephen Hemminger To: Jon Mason Cc: Francois Romieu , netdev@oss.sgi.com Subject: Re: [PATCH 5/5] r8169: ethtool hardware statistics support Message-ID: <20050309135345.5efae9b6@dxpl.pdx.osdl.net> In-Reply-To: <200503091537.30899.jdmason@us.ibm.com> References: <20050309113626.6708c93e@dxpl.pdx.osdl.net> <200503091537.30899.jdmason@us.ibm.com> Organization: Open Source Development Lab X-Mailer: Sylpheed-Claws 1.0.1 (GTK+ 1.2.10; x86_64-unknown-linux-gnu) X-Face: &@E+xe?c%:&e4D{>f1O<&U>2qwRREG5!}7R4;D<"NO^UI2mJ[eEOA2*3>(`Th.yP,VDPo9$ /`~cw![cmj~~jWe?AHY7D1S+\}5brN0k*NE?pPh_'_d>6;XGG[\KDRViCfumZT3@[ Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Received-SPF: pass (domain of shemminger@osdl.org designates 65.172.181.6 as permitted sender) X-MIMEDefang-Filter: osdl$Revision: 1.104 $ X-Scanned-By: MIMEDefang 2.36 X-Virus-Scanned: ClamAV 0.83/757/Tue Mar 8 15:14:36 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 2764 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: shemminger@osdl.org Precedence: bulk X-list: netdev Content-Length: 271 Lines: 6 On Wed, 9 Mar 2005 15:37:30 -0600 Jon Mason wrote: > Does this patch fix the problem of bogus statistics if the interface is down I see no problem when interface is down. It returns all zero's because the device is reset on probe (and on shutdown). From shemminger@osdl.org Wed Mar 9 13:55:37 2005 Received: with ECARTIS (v1.0.0; list netdev); Wed, 09 Mar 2005 13:55:41 -0800 (PST) Received: from smtp.osdl.org (fire.osdl.org [65.172.181.4]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j29LtaPj025351 for ; Wed, 9 Mar 2005 13:55:36 -0800 Received: from shell0.pdx.osdl.net (fw.osdl.org [65.172.181.6]) by smtp.osdl.org (8.12.8/8.12.8) with ESMTP id j29LtCqi030676 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO); Wed, 9 Mar 2005 13:55:12 -0800 Received: from dxpl.pdx.osdl.net (dxpl.pdx.osdl.net [172.20.1.103]) by shell0.pdx.osdl.net (8.13.1/8.11.6) with ESMTP id j29LtCPY023425; Wed, 9 Mar 2005 13:55:12 -0800 Date: Wed, 9 Mar 2005 13:55:30 -0800 From: Stephen Hemminger To: Francois Romieu Cc: Andi Kleen , netdev@oss.sgi.com Subject: Re: [PATCH 1/5] r8169: auto detect 32-bit slot Message-ID: <20050309135530.5c5c80b6@dxpl.pdx.osdl.net> In-Reply-To: <20050309214023.GA9502@electric-eye.fr.zoreil.com> References: <20050309112925.7f7900ab@dxpl.pdx.osdl.net> <20050309214023.GA9502@electric-eye.fr.zoreil.com> Organization: Open Source Development Lab X-Mailer: Sylpheed-Claws 1.0.1 (GTK+ 1.2.10; x86_64-unknown-linux-gnu) X-Face: &@E+xe?c%:&e4D{>f1O<&U>2qwRREG5!}7R4;D<"NO^UI2mJ[eEOA2*3>(`Th.yP,VDPo9$ /`~cw![cmj~~jWe?AHY7D1S+\}5brN0k*NE?pPh_'_d>6;XGG[\KDRViCfumZT3@[ Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Received-SPF: pass (domain of shemminger@osdl.org designates 65.172.181.6 as permitted sender) X-MIMEDefang-Filter: osdl$Revision: 1.104 $ X-Scanned-By: MIMEDefang 2.36 X-Virus-Scanned: ClamAV 0.83/757/Tue Mar 8 15:14:36 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 2765 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: shemminger@osdl.org Precedence: bulk X-list: netdev Content-Length: 387 Lines: 14 On Wed, 9 Mar 2005 22:40:23 +0100 Francois Romieu wrote: > Andi Kleen : > [...] > > Hmm? It doesn't support DAC? > > It does but it is unstable for everybody (except Jon Mason, go figure) on > amd64. > > Stephen, on which kind of system was this change tested ? I tested on old Celeron with Netgear card. I could try Amd and/or Xeon if you want. From steve.iribarne@dilithiumnetworks.com Wed Mar 9 13:57:09 2005 Received: with ECARTIS (v1.0.0; list netdev); Wed, 09 Mar 2005 13:57:15 -0800 (PST) Received: from DHOST001-17.DEX001.intermedia.net (dhost001-17.intermedia.net [64.78.61.64]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j29Lv7ZQ025820 for ; Wed, 9 Mar 2005 13:57:07 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Subject: RE: Do you know the TCP stack? (127.x.x.x routing) Date: Wed, 9 Mar 2005 13:57:06 -0800 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Do you know the TCP stack? (127.x.x.x routing) Thread-Index: AcUk39/2uZSShn9aSCqXuURmWdkpcgAD88XQ From: "Steve Iribarne" To: Cc: "Henrik Nordstrom" , "Martin Mares" , "Zdenek Radouch" , "Eran Mann" , "Thomas Graf" , "Andi Kleen" , , X-Virus-Scanned: ClamAV 0.83/757/Tue Mar 8 15:14:36 2005 on oss.sgi.com X-Virus-Status: Clean Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by oss.sgi.com id j29Lv7ZQ025820 X-archive-position: 2766 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: steve.iribarne@dilithiumnetworks.com Precedence: bulk X-list: netdev Content-Length: 7028 Lines: 211 It's not the routing of the packet that gets screwed up. It's the applications that my "intra" communication use. I do this... I have a redundant system. So two Ethernet switches that go to either a switch/hubbed/routed network. Not controlled by me, but by my customers. So you have duplicate three wire coming into both ends of my chassis. ------ net 1 --------| | ---- net 1 ---- | | ------- net 2 -------| Chassis 21 slots | ----- net 2 ---- | | ------- net 3 -------| | ---- net 3 ---- all three of those "outside" nets get to me by either a bridge, router or hub. My 19 boards internal need to talk to each other ALONG with talking to the outside world. Boards in slot 1/21 are the switches. so boards 2-20 are my linux blades that talk to each other. The switch is configured to have the VLANS. Management traffic I tag on a VLAN. So when my host controller or any of the other linux blades need to do host communication, they talk to ip address 127.100.xx.xx which is associated with a VLAN tagged interface. Traffic being sent to the outside world is tagged as it comes in from the outside world (so I know where it came from), and sent to the proper board. L2 switching stuff. Traffic that I send back out to the outside world is tagged when it leaves one of my blades so the switch knows which port to send it back out on. (net 1, net 2 or net 3) Ok.. that being said... The _only_ way I can have normal applications (ie. ping, telnet, nfs) to work and _guarantee_ not intra communication problems is if I use the 127.xx net. I'm not sure what you are not getting. I'm not talking about basic routing. I'm talking about getting applications not to collide. Let me give you and example. If I were to use the 10.100.xx.xx network for example. I have an snmp master-agent/sub-agent configuration. So I have a host controller with the 10.100.0.1 address and my subagents are 10.100.0. Everything works great, everyone is happy, until someone from the outside world (say net 2) tries to telnet to me with a host address of say 10.100.0.73. Well, my host controller will route that packet onto my private network. So when I go to respond to the telnet request I will tag it for my internal network because that is what the FIB routing tells it to do. There it is. I'm not going to spend anymore time on this, and neither should you. Like I said, I've been doing this for a darn long time, and I have, as yet, to see anyone who can make this problem just work. Other than the way I did it. (I along with many others) have a happy day. -stv -> -----Original Message----- -> From: jamal [mailto:hadi@cyberus.ca] -> Sent: Wednesday, March 09, 2005 11:41 AM -> To: Steve Iribarne -> Cc: Henrik Nordstrom; Martin Mares; Zdenek Radouch; Eran Mann; Thomas -> Graf; Andi Kleen; netdev@oss.sgi.com; linux-net@vger.kernel.org -> Subject: RE: Do you know the TCP stack? (127.x.x.x routing) -> -> On Wed, 2005-03-09 at 12:33, Steve Iribarne wrote: -> > -> Your blades --> VLANX/SubnetX -> > -> --> [some L3 switch] -> > -> > umm.. I have a L2 switch... not L3 switch. -> > -> -> Lets go over this slowly so we can hopefully resolve why we dont see eye -> to eye. I am not sure why i am spending all this energy on this. -> -> Lets get the diagrams better: -> -> 1) your case: -> Your blades <--> VLANX/SubnetX -> <--> [some L2 switch] -> <--> VLANY/SubnetY <--> outside world -> -> You probably have redundancy etc in some ATCA||2.16 setup with links -> going to -> two internal switches - but lets also ignore that - just assume the -> simple -> switch for now for sake of clarity. You may also have many VLANs in/out -> like you -> said "signaling traffic, bearer traffic and network mgmt traffic", but -> the -> two internal vs external interfaces i showed above should suffice to -> indicate -> the general picture. Agreed? -> -> To sumarize, for you to get to/from the outside world to your blades you -> go -> via L2 switch with a "few" interfaces to the ouside world. -> In your case the "internal" interface is the VLANX port(s) facing the -> switch. -> The "external" interface is the port(s) on VLANY facing the outside. -> -> 2) Note this is slightly different from Zdenek, which is: -> -> Outside <->one or more interfaces <-> [LinecardX] <-->[swicth/fabric] -> Outside <->one or more interfaces <-> [LinecardY] <-->[swicth/fabric] -> . -> . -> -> In other words each line card has many interfaces that come into the -> box. -> It is not unusual to find 12-48 interface line cards. The "switch" aka -> "fabric" -> connects these line cards (and perhaps some control plane blade(s)). -> Typically such -> a switch will not run IP but rather some other internal thing like CSIX -> or SPI-x etc. -> -> In both setups, if you do run IP internally, it does make sense not -> "leak" internal -> traffic to the outside world with such addresses. -> In both cases you both try hard (and i am sure succeed) to not leak those -> packets -> out - In your case its a simple separation of collision domains. The only -> way you can -> get from internal to external is if infact you have L2 connectivity -> between the two -> (since you said you dont have L3 switching in your chasis). -> -> By making the 127.x routable in linux of all places - which is where i -> started -> disagreeing, you introduce some challenges with hope that 127.x obscurity -> is -> going to help. -> -> To avoid confusion and have Zdenek respond when i am talking to you or -> viceversa -> lets make the two as separate issues: -> -> 1) In your case i saw no reason for you to use 127.x - you could have -> achieved the -> same with 10.x. Your internal packets will never leak out. You say you -> will have collisions -> with customer; but then if i understood correctly you said these internal -> packets never -> the box. So my conclusion was you didnt need the hack. -> -> 2)Zdenek's case -> -> Just avoiding the leak is not good enough if the 127.x is routable and -> someone else -> is using it and he has to route such packets. In such a case, even if -> Zdenek hides -> the internal network at some point he will have to route a packet -> coming into -> linecardX, port A to linecardY, port B. -> And for this reason he cant totaly avoid collision. This is why i called -> it survival -> via obscurity. -> -> Note: I am not questioning his technique but i would never use it -> myself. Lets say we can achieve the same goal in a different way. -> -> > Again, if you can show me a way of doing this, I'm all ears, but so -> far, -> > you haven't shown me any other way around it. Believe me. I've tried -> > and tried to find another solution to this problem. -> > -> -> Lets talk about this when we are clear what the problem is. Fix up the -> diagram above if it is wrong, then we can talk. -> -> cheers, -> jamal From ganesh.venkatesan@gmail.com Wed Mar 9 14:09:51 2005 Received: with ECARTIS (v1.0.0; list netdev); Wed, 09 Mar 2005 14:09:56 -0800 (PST) Received: from wproxy.gmail.com (wproxy.gmail.com [64.233.184.192]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j29M9prP026677 for ; Wed, 9 Mar 2005 14:09:51 -0800 Received: by wproxy.gmail.com with SMTP id 69so435886wri for ; Wed, 09 Mar 2005 14:09:45 -0800 (PST) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:reply-to:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:references; b=EamM/tc9/i8W/zO5E+w6lJPlaz6JD4HtLepzG3LhMr97qtxmC8QYPusZ/rP8E7+U9GgzxqOLS/z8aEeZbDcqVboeIISrQPaA3Hxc0ttg8w/nuo9fjSjwpHsf7I0lIK7BvBVRB+Xo5tLcSbuv3bGcYYGJiGfLrFYDllvaOFOJh/A= Received: by 10.54.45.14 with SMTP id s14mr1184645wrs; Wed, 09 Mar 2005 14:09:45 -0800 (PST) Received: by 10.54.29.37 with HTTP; Wed, 9 Mar 2005 14:09:45 -0800 (PST) Message-ID: <5fc59ff3050309140910f3e492@mail.gmail.com> Date: Wed, 9 Mar 2005 14:09:45 -0800 From: Ganesh Venkatesan Reply-To: Ganesh Venkatesan To: Ben Greear Subject: Re: ethtool -d no longer works for e1000 Cc: "netdev@oss.sgi.com" In-Reply-To: <422F6C37.8090202@candelatech.com> Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit References: <422F6C37.8090202@candelatech.com> X-Virus-Scanned: ClamAV 0.83/757/Tue Mar 8 15:14:36 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 2767 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: ganesh.venkatesan@gmail.com Precedence: bulk X-list: netdev Content-Length: 649 Lines: 26 Ben: Are you using the e1000 that is included in the 2.6.11 kernel? ethtool -d eth? works fine for me. What else is different in your env? ganesh. On Wed, 09 Mar 2005 13:35:51 -0800, Ben Greear wrote: > I tried this with FC2's 2.6.10-1.770_FC2smp kernel and with my own > slightly hacked 2.6.11 kernel. Both give this response: > > ethtool -d eth0 > Cannot dump registers: Success > > I am quite certain this used to work, and used to show me > the PCI bus speed and other nice details... > > Thanks, > Ben > > -- > Ben Greear > Candela Technologies Inc http://www.candelatech.com > > From jdmason@us.ibm.com Wed Mar 9 14:16:55 2005 Received: with ECARTIS (v1.0.0; list netdev); Wed, 09 Mar 2005 14:16:59 -0800 (PST) Received: from e34.co.us.ibm.com (e34.co.us.ibm.com [32.97.110.132]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j29MGswU027698 for ; Wed, 9 Mar 2005 14:16:54 -0800 Received: from westrelay01.boulder.ibm.com (westrelay01.boulder.ibm.com [9.17.195.10]) by e34.co.us.ibm.com (8.12.10/8.12.9) with ESMTP id j29MGnKN490344 for ; Wed, 9 Mar 2005 17:16:49 -0500 Received: from d03av01.boulder.ibm.com (d03av01.boulder.ibm.com [9.17.195.167]) by westrelay01.boulder.ibm.com (8.12.10/NCO/VER6.6) with ESMTP id j29MGmtF179184 for ; Wed, 9 Mar 2005 15:16:48 -0700 Received: from d03av01.boulder.ibm.com (loopback [127.0.0.1]) by d03av01.boulder.ibm.com (8.12.11/8.12.11) with ESMTP id j29MGmNu013605 for ; Wed, 9 Mar 2005 15:16:48 -0700 Received: from dreadnought.austin.ibm.com (dreadnought.austin.ibm.com [9.41.94.123]) by d03av01.boulder.ibm.com (8.12.11/8.12.11) with ESMTP id j29MGmKX013590; Wed, 9 Mar 2005 15:16:48 -0700 From: Jon Mason Organization: IBM To: Francois Romieu Subject: Re: [PATCH 1/5] r8169: auto detect 32-bit slot Date: Wed, 9 Mar 2005 16:08:59 -0600 User-Agent: KMail/1.7.2 Cc: Andi Kleen , Stephen Hemminger , netdev@oss.sgi.com References: <20050309112925.7f7900ab@dxpl.pdx.osdl.net> <20050309214023.GA9502@electric-eye.fr.zoreil.com> In-Reply-To: <20050309214023.GA9502@electric-eye.fr.zoreil.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200503091608.59122.jdmason@us.ibm.com> X-Virus-Scanned: ClamAV 0.83/757/Tue Mar 8 15:14:36 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 2768 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: jdmason@us.ibm.com Precedence: bulk X-list: netdev Content-Length: 378 Lines: 19 On Wednesday 09 March 2005 03:40 pm, Francois Romieu wrote: > Andi Kleen : > [...] > > > Hmm? It doesn't support DAC? > > It does but it is unstable for everybody (except Jon Mason, go figure) on > amd64. Just lucky, I guess. I can give it a try again. > Stephen, on which kind of system was this change tested ? > > -- > Ueimor -- Jon Mason jdmason@us.ibm.com From shemminger@osdl.org Wed Mar 9 14:24:39 2005 Received: with ECARTIS (v1.0.0; list netdev); Wed, 09 Mar 2005 14:24:44 -0800 (PST) Received: from smtp.osdl.org (fire.osdl.org [65.172.181.4]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j29MOcGi028734 for ; Wed, 9 Mar 2005 14:24:38 -0800 Received: from shell0.pdx.osdl.net (fw.osdl.org [65.172.181.6]) by smtp.osdl.org (8.12.8/8.12.8) with ESMTP id j29MOWqi000832 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO); Wed, 9 Mar 2005 14:24:32 -0800 Received: from dxpl.pdx.osdl.net (dxpl.pdx.osdl.net [172.20.1.103]) by shell0.pdx.osdl.net (8.13.1/8.11.6) with ESMTP id j29MOVS3025489; Wed, 9 Mar 2005 14:24:32 -0800 Date: Wed, 9 Mar 2005 14:24:49 -0800 From: Stephen Hemminger To: Jeff Garzik Cc: netdev@oss.sgi.com Subject: [PATCH] ethtool: add skge register dump Message-ID: <20050309142449.4682340b@dxpl.pdx.osdl.net> Organization: Open Source Development Lab X-Mailer: Sylpheed-Claws 1.0.1 (GTK+ 1.2.10; x86_64-unknown-linux-gnu) X-Face: &@E+xe?c%:&e4D{>f1O<&U>2qwRREG5!}7R4;D<"NO^UI2mJ[eEOA2*3>(`Th.yP,VDPo9$ /`~cw![cmj~~jWe?AHY7D1S+\}5brN0k*NE?pPh_'_d>6;XGG[\KDRViCfumZT3@[ Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Received-SPF: pass (domain of shemminger@osdl.org designates 65.172.181.6 as permitted sender) X-MIMEDefang-Filter: osdl$Revision: 1.104 $ X-Scanned-By: MIMEDefang 2.36 X-Virus-Scanned: ClamAV 0.83/757/Tue Mar 8 15:14:36 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 2769 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: shemminger@osdl.org Precedence: bulk X-list: netdev Content-Length: 7963 Lines: 235 The new skge driver supports ethtool register dump. Here is the new code for the ethtool command to decode it. ----------- diff -Nru a/Makefile.am b/Makefile.am --- a/Makefile.am 2005-03-09 14:23:01 -08:00 +++ b/Makefile.am 2005-03-09 14:23:01 -08:00 @@ -6,7 +6,7 @@ sbin_PROGRAMS = ethtool ethtool_SOURCES = de2104x.c ethtool.c ethtool-copy.h ethtool-util.h natsemi.c \ e1000.c realtek.c e100.c tg3.c amd8111e.c pcnet32.c \ - fec_8xx.c + fec_8xx.c skge.c dist-hook: cp $(top_srcdir)/ethtool.spec $(distdir) diff -Nru a/ethtool-util.h b/ethtool-util.h --- a/ethtool-util.h 2005-03-09 14:23:01 -08:00 +++ b/ethtool-util.h 2005-03-09 14:23:01 -08:00 @@ -39,4 +39,7 @@ /* Motorola 8xx FEC Ethernet controller */ int fec_8xx_dump_regs(struct ethtool_drvinfo *info, struct ethtool_regs *regs); +/* SysKonnect Gigabit Yukon Family */ +int skge_dump_regs(struct ethtool_drvinfo *info, struct ethtool_regs *regs); + #endif diff -Nru a/ethtool.c b/ethtool.c --- a/ethtool.c 2005-03-09 14:23:01 -08:00 +++ b/ethtool.c 2005-03-09 14:23:01 -08:00 @@ -1012,6 +1012,7 @@ { "amd8111e", amd8111e_dump_regs }, { "pcnet32", pcnet32_dump_regs }, { "fec_8xx", fec_8xx_dump_regs }, + { "skge", skge_dump_regs }, }; static int dump_regs(struct ethtool_drvinfo *info, struct ethtool_regs *regs) diff -Nru a/skge.c b/skge.c --- /dev/null Wed Dec 31 16:00:00 196900 +++ b/skge.c 2005-03-09 14:23:01 -08:00 @@ -0,0 +1,193 @@ +/* + * Copyright (C) 2004 + * Stephen Hemminger + */ + +#include + +#include "ethtool-util.h" + +static void dump_addr(int n, const u8 *a) +{ + int i; + + printf("Addr %d ", n); + for (i = 0; i < 6; i++) + printf("%02X%c", a[i], i == 5 ? '\n' : ' '); +} + +static void dump_timer(const char *name, const void *p) +{ + const u8 *a = p; + const u32 *r = p; + + printf("%s\n", name); + printf("\tInit 0x%08X Value 0x%08X\n", r[0], r[1]); + printf("\tTest 0x%02X Control 0x%02X\n", a[8], a[9]); +} + +static void dump_queue(const char *name, const void *a, int rx) +{ + struct desc { + u_int32_t ctl; + u_int32_t next; + u_int32_t data_lo; + u_int32_t data_hi; + u_int32_t status; + u_int32_t timestamp; + u_int16_t csum2; + u_int16_t csum1; + u_int16_t csum2_start; + u_int16_t csum1_start; + u_int32_t addr_lo; + u_int32_t addr_hi; + u_int32_t count_lo; + u_int32_t count_hi; + u_int32_t byte_count; + u_int32_t csr; + u_int32_t flag; + }; + const struct desc *d = a; + + printf("\n%s\n", name); + printf("---------------\n"); + printf("Descriptor Address 0x%08X%08X\n", + d->addr_hi, d->addr_lo); + printf("Address Counter 0x%08X%08X\n", + d->count_hi, d->count_lo); + printf("Current Byte Counter %d\n", d->byte_count); + printf("BMU Control/Status 0x%08X\n", d->csr); + printf("Flag & FIFO Address 0x%08X\n", d->flag); + printf("\n"); + printf("Control 0x%08X\n", d->ctl); + printf("Next 0x%08X\n", d->next); + printf("Data 0x%08X%08X\n", + d->data_hi, d->data_lo); + printf("Status 0x%08X\n", d->status); + printf("Timestamp 0x%08X\n", d->timestamp); + if (rx) { + printf("Csum1 Offset %4d Positon %d\n", + d->csum1, d->csum1_start); + printf("Csum2 Offset %4d Positon %d\n", + d->csum2, d->csum2_start); + } else + printf("Csum Start 0x%04X Pos %4d Write %d\n", + d->csum1, d->csum2_start, d->csum1_start); + +} + +static void dump_ram(const char *name, const void *p) +{ + const u32 *r = p; + + printf("\n%s\n", name); + printf("---------------\n"); + printf("Start Address 0x%08X\n", r[0]); + printf("End Address 0x%08X\n", r[1]); + printf("Write Pointer 0x%08X\n", r[2]); + printf("Read Pointer 0x%08X\n", r[3]); + printf("Upper Threshold/Pause Packets 0x%08X\n", r[4]); + printf("Lower Threshold/Pause Packets 0x%08X\n", r[5]); + printf("Upper Threshold/High Priority 0x%08X\n", r[6]); + printf("Lower Threshold/High Priority 0x%08X\n", r[7]); + printf("Packet Counter 0x%08X\n", r[8]); + printf("Level 0x%08X\n", r[9]); + printf("Test 0x%08X\n", r[10]); +} + +#if 0 +static void dump_fifo(const char *name, const void *p) +{ + const u32 *r = p; + + printf("\n%s\n", name); + printf("---------------\n"); + printf("End Address 0x%08X\n", r[0]); + printf("Write Pointer 0x%08X\n", r[1]); + printf("Read Pointer 0x%08X\n", r[2]); + printf("Packet Counter 0x%08X\n", r[3]); + printf("Level 0x%08X\n", r[4]); + printf("Control 0x%08X\n", r[5]); + printf("Control/Test 0x%08X\n", r[6]); + dump_timer("LED", p + 0x20); +} +#endif + +int skge_dump_regs(struct ethtool_drvinfo *info, struct ethtool_regs *regs) +{ + const u32 *r = (const u32 *) regs->data; + int dual = !(regs->data[0x11a] & 1); + + printf("Control Registers\n"); + printf("-----------------\n"); + + printf("Register Access Port 0x%08X\n", r[0]); + printf("LED Control/Status 0x%08X\n", r[1]); + printf("Interrupt Source 0x%08X\n", r[2]); + printf("Interrupt Mask 0x%08X\n", r[3]); + printf("Interrupt Hardware Error Source 0x%08X\n", r[4]); + printf("Interrupt Hardware Error Mask 0x%08X\n", r[5]); + printf("Special Interrupt Source 0x%08X\n", r[6]); + + printf("\nBus Management Unit\n"); + printf("-------------------\n"); + printf("CSR Receive Queue 1 0x%08X\n", r[24]); + printf("CSR Sync Queue 1 0x%08X\n", r[26]); + printf("CSR Async Queue 1 0x%08X\n", r[27]); + if (dual) { + printf("CSR Receive Queue 2 0x%08X\n", r[25]); + printf("CSR Async Queue 2 0x%08X\n", r[29]); + printf("CSR Sync Queue 2 0x%08X\n", r[28]); + } + + printf("\nMAC Address\n"); + printf("-------------\n"); + dump_addr(1, regs->data + 0x100); + dump_addr(2, regs->data + 0x108); + dump_addr(3, regs->data + 0x110); + printf("\n"); + + printf("Connector type 0x%02X\n", + regs->data[0x118]); + printf("PMD type 0x%02X\n", + regs->data[0x119]); + printf("Configuration 0x%02X\n", + regs->data[0x11a]); + printf("Chip Revision 0x%02X\n", + regs->data[0x11b]); + + dump_timer("Timer", regs->data + 0x130); + dump_timer("IRQ Moderation", regs->data +0x140); + dump_timer("Blink Source", regs->data +0x170); + + dump_queue("Receive Queue 1", regs->data +0x400, 1); + dump_queue("Sync Transmit Queue 1", regs->data +0x600, 0); + dump_queue("Async Transmit Queue 1", regs->data +0x680, 0); + if (dual) { + dump_queue("Receive Queue 2", regs->data +0x480, 1); + dump_queue("Async Transmit Queue 2", regs->data +0x780, 0); + dump_queue("Sync Transmit Queue 2", regs->data +0x700, 0); + } + + dump_ram("Receive RAMbuffer 1", regs->data+0x800); + dump_ram("Sync Transmit RAMbuffer 1", regs->data+0xa00); + dump_ram("Async Transmit RAMbuffer 1", regs->data+0xa80); + if (dual) { + dump_ram("Receive RAMbuffer 2", regs->data+0x880); + dump_ram("Sync Transmit RAMbuffer 2", regs->data+0xb00); + dump_ram("Async Transmit RAMbuffer 21", regs->data+0xb80); + } + +#if 0 + dump_fifo("Receive MAC FIFO 1", regs->data+0xc00); + dump_fifo("Transmit MAC FIFO 1", regs->data+0xd00); + if (dual) { + dump_fifo("Receive MAC FIFO 2", regs->data+0xc80); + dump_fifo("Transmit MAC FIFO 2", regs->data+0xd80); + } + + dump_timer("Descriptor Poll", regs->data+0xe00); +#endif + return 0; + +} From cramerj@intel.com Wed Mar 9 14:26:04 2005 Received: with ECARTIS (v1.0.0; list netdev); Wed, 09 Mar 2005 14:26:09 -0800 (PST) Received: from orsfmr002.jf.intel.com (fmr17.intel.com [134.134.136.16]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j29MQ4R3029114 for ; Wed, 9 Mar 2005 14:26:04 -0800 Received: from orsfmr100.jf.intel.com (orsfmr100.jf.intel.com [10.7.209.16]) by orsfmr002.jf.intel.com (8.12.10/8.12.10/d: major-outer.mc,v 1.1 2004/09/17 17:50:56 root Exp $) with ESMTP id j29MPsuq022216; Wed, 9 Mar 2005 22:25:54 GMT Received: from orsmsxvs040.jf.intel.com (orsmsxvs040.jf.intel.com [192.168.65.206]) by orsfmr100.jf.intel.com (8.12.10/8.12.10/d: major-inner.mc,v 1.2 2004/09/17 18:05:01 root Exp $) with SMTP id j29MPnpk030254; Wed, 9 Mar 2005 22:25:54 GMT Received: from orsmsx331.amr.corp.intel.com ([192.168.65.56]) by orsmsxvs040.jf.intel.com (SAVSMTP 3.1.7.47) with SMTP id M2005030914255414546 ; Wed, 09 Mar 2005 14:25:54 -0800 Received: from orsmsx405.amr.corp.intel.com ([192.168.65.46]) by orsmsx331.amr.corp.intel.com with Microsoft SMTPSVC(6.0.3790.211); Wed, 9 Mar 2005 14:25:54 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Subject: RE: ethtool -d no longer works for e1000 Date: Wed, 9 Mar 2005 14:25:53 -0800 Message-ID: <76FA8CF8F1F53240BB5B962A3385A5800256F510@orsmsx405> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: ethtool -d no longer works for e1000 Thread-Index: AcUk8BCw5dmYOIzNRCWVJ5y2KcGRgwABpT6Q From: "cramerj" To: "Ben Greear" , X-OriginalArrivalTime: 09 Mar 2005 22:25:54.0274 (UTC) FILETIME=[F51C1420:01C524F6] X-Scanned-By: MIMEDefang 2.44 X-Virus-Scanned: ClamAV 0.83/757/Tue Mar 8 15:14:36 2005 on oss.sgi.com X-Virus-Status: Clean Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by oss.sgi.com id j29MQ4R3029114 X-archive-position: 2770 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: cramerj@intel.com Precedence: bulk X-list: netdev Content-Length: 769 Lines: 30 Perhaps the network interface enumeration changed with these kernels? Is the e1000 part still eth0? -Jeb > -----Original Message----- > From: netdev-bounce@oss.sgi.com [mailto:netdev-bounce@oss.sgi.com] On > Behalf Of Ben Greear > Sent: Wednesday, March 09, 2005 1:36 PM > To: 'netdev@oss.sgi.com' > Subject: ethtool -d no longer works for e1000 > > I tried this with FC2's 2.6.10-1.770_FC2smp kernel and with my own > slightly hacked 2.6.11 kernel. Both give this response: > > ethtool -d eth0 > Cannot dump registers: Success > > I am quite certain this used to work, and used to show me > the PCI bus speed and other nice details... > > Thanks, > Ben > > -- > Ben Greear > Candela Technologies Inc http://www.candelatech.com > From hno@marasystems.com Wed Mar 9 14:35:28 2005 Received: with ECARTIS (v1.0.0; list netdev); Wed, 09 Mar 2005 14:35:31 -0800 (PST) Received: from filer.marasystems.com (marasystems.com [83.241.133.2]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j29MZQ1E029948 for ; Wed, 9 Mar 2005 14:35:27 -0800 Received: from localhost (henrik@localhost) by filer.marasystems.com (8.11.6/8.11.6) with ESMTP id j29MYhB17826; Wed, 9 Mar 2005 23:34:43 +0100 Date: Wed, 9 Mar 2005 23:34:43 +0100 (CET) From: Henrik Nordstrom To: jamal cc: Martin Mares , Zdenek Radouch , Steve Iribarne , Eran Mann , Thomas Graf , Andi Kleen , netdev@oss.sgi.com, linux-net@vger.kernel.org Subject: Re: Do you know the TCP stack? (127.x.x.x routing) In-Reply-To: <1110371962.1088.90.camel@jzny.localdomain> Message-ID: References: <20050306173145.GQ31837@postel.suug.ch> <3sp35g$7hpm0@smtp04.mrf.mail.rcn.net> <422C0B50.20500@mrv.com> <3sp35g$7rsc1@smtp04.mrf.mail.rcn.net> <1110288879.1050.167.camel@jzny.localdomain> <20050308135134.GA20607@atrey.karlin.mff.cuni.cz> <1110290300.1050.190.camel@jzny.localdomain> <20050308140301.GC20607@atrey.karlin.mff.cuni.cz> <1110291470.1043.211.camel@jzny.localdomain> <1110316631.1084.57.camel@jzny.localdomain> <1110371962.1088.90.camel@jzny.localdomain> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Virus-Scanned: ClamAV 0.83/757/Tue Mar 8 15:14:36 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 2771 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: hno@marasystems.com Precedence: bulk X-list: netdev Content-Length: 2815 Lines: 68 On Wed, 9 Mar 2005, jamal wrote: > I am afraid this 127.x panacea is begining to sound like the tale of > some insane emperor who was naked but people around him sucking up to > him telling him how fine his clothes looked. I am having a very hard > time seeing the rationale - infact its driving me nuts, so please bear > with me. yes, if it wasn't for routing conflicts when a node is in both the external and the chassis network. If Linux could manage different IP stacks per interface this would not be a problem, but as it is today the same IP stack is used for all interfaces making dual homing (not routing) a bit troublesome when the same addresses may be in both networks.. > within customer's network. To quote Zdenek: > You couldn't walk in the NOC and tell them: "You can't use the 10.x > net to manage your equipment - my box is already using that net". > Conclusion: > You walk into the NOC and say "can i use 10.0.0.x/22 subnet" they say "no > thats going to collide use 10.0.0.0/28" > Summary: You may need to go to your box and reconfigure its external looking > addresses. Yes. But also it's internal in order to maintain any sanity in the nodes connected to both worlds. > a') Using 127.x addresses. You -> NOC "can i use 127.0.0.x/22 subnet" > they say either "sorry, our routers cant route 127.x" or "no Zdenek > was here before you, thats going to collide use 127.0.0.0/28" This has never been a topic. The use of the 127.X addresses is purely for inter-chassis communication, never visible outside of the chassis. By using the 127.X addresses for intra-chassis communication you are guaranteed that there is never conflicts with addresses used on the LAN, and the routing tables of the chassis nodes which needs to speak to both worlds can be maintained sane without requiring configuration of the chassis-internal network not even visible to the administrator. The available choices are in reality (not exlusive, pick any number) a) Ask IANA for an address block for intra-chassis communication and hope the local LAN is not abusing these addresses. b) use the IPv4 link-local address block already registered, with the condition that this is not used on the local LAN to avoid collisions. c) Use 127.X. Ensures that no matter what the local LAN looks like behaviour of the externally connected nodes will be what is expected (can handle any valid IP, except for 127.X which they are not expected to handle) d) Use a configureable address block. e) Reimplement the IP stack in Linux to have separate IP stacks per interface, and modify all applications to not only specify the destination IP but also which interface to use when talking to either the internal network or external world. f) Not use IPv4 for the intra-chassis communication. Regards Henrik From romieu@fr.zoreil.com Wed Mar 9 14:41:01 2005 Received: with ECARTIS (v1.0.0; list netdev); Wed, 09 Mar 2005 14:41:04 -0800 (PST) Received: from fr.zoreil.com (electric-eye.fr.zoreil.com [213.41.134.224]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j29MexhF030553 for ; Wed, 9 Mar 2005 14:41:00 -0800 Received: from electric-eye.fr.zoreil.com (localhost.localdomain [127.0.0.1]) by fr.zoreil.com (8.13.1/8.12.1) with ESMTP id j29MdpL7011178; Wed, 9 Mar 2005 23:39:51 +0100 Received: (from romieu@localhost) by electric-eye.fr.zoreil.com (8.13.1/8.13.1/Submit) id j29MdhaA011177; Wed, 9 Mar 2005 23:39:43 +0100 Date: Wed, 9 Mar 2005 23:39:43 +0100 From: Francois Romieu To: Jon Mason Cc: Andi Kleen , Stephen Hemminger , netdev@oss.sgi.com Subject: Re: [PATCH 1/5] r8169: auto detect 32-bit slot Message-ID: <20050309223943.GB9502@electric-eye.fr.zoreil.com> References: <20050309112925.7f7900ab@dxpl.pdx.osdl.net> <20050309214023.GA9502@electric-eye.fr.zoreil.com> <200503091608.59122.jdmason@us.ibm.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200503091608.59122.jdmason@us.ibm.com> User-Agent: Mutt/1.4.1i X-Organisation: Land of Sunshine Inc. X-Virus-Scanned: ClamAV 0.83/757/Tue Mar 8 15:14:36 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 2772 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: romieu@fr.zoreil.com Precedence: bulk X-list: netdev Content-Length: 159 Lines: 8 Jon Mason : [... > Just lucky, I guess. I can give it a try again. The content of the Config2 register could be interesting. -- Ueimor From andre@tomt.net Wed Mar 9 14:59:37 2005 Received: with ECARTIS (v1.0.0; list netdev); Wed, 09 Mar 2005 14:59:41 -0800 (PST) Received: from mx1.skjellin.no (mail1.skjellin.no [80.239.42.67]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j29Mxatj031510 for ; Wed, 9 Mar 2005 14:59:37 -0800 Received: from localhost (localhost [127.0.0.1]) by mx1.skjellin.no (Postfix) with ESMTP id F1DB788566; Wed, 9 Mar 2005 23:59:55 +0100 (CET) Received: from puppen.pasop.tomt.net (gw-fe-1.pasop.tomt.net [10.255.1.1]) by mail1.skjellin.no (Postfix) with ESMTP id 7CB2B88561; Wed, 9 Mar 2005 23:59:55 +0100 (CET) Received: from [10.255.1.10] (slurv.pasop.tomt.net [10.255.1.10]) by puppen.pasop.tomt.net (Postfix) with ESMTP id 4F51B22AD2; Wed, 9 Mar 2005 23:59:35 +0100 (CET) Message-ID: <422F7FDC.2090202@tomt.net> Date: Wed, 09 Mar 2005 23:59:40 +0100 From: Andre Tomt User-Agent: Mozilla Thunderbird 1.0 (Windows/20041206) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Ben Greear Cc: "'netdev@oss.sgi.com'" Subject: Re: ethtool -d no longer works for e1000 References: <422F6C37.8090202@candelatech.com> In-Reply-To: <422F6C37.8090202@candelatech.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV 0.83/757/Tue Mar 8 15:14:36 2005 on oss.sgi.com X-Virus-Scanned: by amavisd-new-20030616-p10 (Debian) at skjellin.no X-Virus-Status: Clean X-archive-position: 2773 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: andre@tomt.net Precedence: bulk X-list: netdev Content-Length: 398 Lines: 12 Ben Greear wrote: > I tried this with FC2's 2.6.10-1.770_FC2smp kernel and with my own > slightly hacked 2.6.11 kernel. Both give this response: > > ethtool -d eth0 > Cannot dump registers: Success > > I am quite certain this used to work, and used to show me > the PCI bus speed and other nice details... Works fine here. Only thing is that CSA adapters seems to come up as 32bit 33Mhz PCI. From greearb@candelatech.com Wed Mar 9 15:02:47 2005 Received: with ECARTIS (v1.0.0; list netdev); Wed, 09 Mar 2005 15:02:51 -0800 (PST) Received: from www.lanforge.com (ns1.lanforge.com [66.165.47.210]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j29N2kTh032029 for ; Wed, 9 Mar 2005 15:02:47 -0800 Received: from [4.33.45.22] (evrtwa1-ar2-4-33-045-022.evrtwa1.dsl-verizon.net [4.33.45.22]) (authenticated bits=0) by www.lanforge.com (8.12.8/8.12.8) with ESMTP id j29NQ1LH005006; Wed, 9 Mar 2005 15:26:02 -0800 Message-ID: <422F8095.1010801@candelatech.com> Date: Wed, 09 Mar 2005 15:02:45 -0800 From: Ben Greear Organization: Candela Technologies User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.7.3) Gecko/20041020 X-Accept-Language: en-us, en MIME-Version: 1.0 To: cramerj CC: netdev@oss.sgi.com Subject: Re: ethtool -d no longer works for e1000 References: <76FA8CF8F1F53240BB5B962A3385A5800256F510@orsmsx405> In-Reply-To: <76FA8CF8F1F53240BB5B962A3385A5800256F510@orsmsx405> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV 0.83/757/Tue Mar 8 15:14:36 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 2774 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: greearb@candelatech.com Precedence: bulk X-list: netdev Content-Length: 271 Lines: 11 cramerj wrote: > Perhaps the network interface enumeration changed with these kernels? > Is the e1000 part still eth0? Nope, nothing but 4 e1000 interfaces in this machine. -- Ben Greear Candela Technologies Inc http://www.candelatech.com From romieu@fr.zoreil.com Wed Mar 9 15:09:02 2005 Received: with ECARTIS (v1.0.0; list netdev); Wed, 09 Mar 2005 15:09:07 -0800 (PST) Received: from fr.zoreil.com (electric-eye.fr.zoreil.com [213.41.134.224]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j29N90t0032703 for ; Wed, 9 Mar 2005 15:09:01 -0800 Received: from electric-eye.fr.zoreil.com (localhost.localdomain [127.0.0.1]) by fr.zoreil.com (8.13.1/8.12.1) with ESMTP id j29N8Ed0012144; Thu, 10 Mar 2005 00:08:14 +0100 Received: (from romieu@localhost) by electric-eye.fr.zoreil.com (8.13.1/8.13.1/Submit) id j29N891r012143; Thu, 10 Mar 2005 00:08:09 +0100 Date: Thu, 10 Mar 2005 00:08:09 +0100 From: Francois Romieu To: Stephen Hemminger Cc: Andi Kleen , netdev@oss.sgi.com Subject: Re: [PATCH 1/5] r8169: auto detect 32-bit slot Message-ID: <20050309230809.GC9502@electric-eye.fr.zoreil.com> References: <20050309112925.7f7900ab@dxpl.pdx.osdl.net> <20050309214023.GA9502@electric-eye.fr.zoreil.com> <20050309135530.5c5c80b6@dxpl.pdx.osdl.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20050309135530.5c5c80b6@dxpl.pdx.osdl.net> User-Agent: Mutt/1.4.1i X-Organisation: Land of Sunshine Inc. X-Virus-Scanned: ClamAV 0.83/757/Tue Mar 8 15:14:36 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 2775 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: romieu@fr.zoreil.com Precedence: bulk X-list: netdev Content-Length: 1015 Lines: 25 Stephen Hemminger : [...] > I tested on old Celeron with Netgear card. I could try Amd and/or Xeon > if you want. If the systems are 64 bit, one would need to know how the driver behaves when DAC is forced and: 1) the Netgear card is in a 32 bit slot, dma to highmem is enabled and used 2) the Netgear card is in a 32 bit slot, dma to highmem is enabled and unused 3) the Netgear card is in a 32 bit slot, dma to highmem is disabled 4) the Netgear card is in a 64 bit slot, dma to highmem is enabled and used 5) the Netgear card is in a 64 bit slot, dma to highmem is enabled and unused 6) the Netgear card is in a 64 bit slot, dma to highmem is disabled + the content of the Config2 register for 1-6. If the amd64 hosts a built-in 8169, add the behavior with highmem disabled or enabled + variable amount of memory. As it still leaves some archs in the cold + DAC ought not to be dependant on the bus width + a few "broken" adapters exist, the patch makes me a bit sceptical. -- Ueimor From greearb@candelatech.com Wed Mar 9 15:09:36 2005 Received: with ECARTIS (v1.0.0; list netdev); Wed, 09 Mar 2005 15:09:39 -0800 (PST) Received: from www.lanforge.com (ns1.lanforge.com [66.165.47.210]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j29N9aRU000491 for ; Wed, 9 Mar 2005 15:09:36 -0800 Received: from [4.33.45.22] (evrtwa1-ar2-4-33-045-022.evrtwa1.dsl-verizon.net [4.33.45.22]) (authenticated bits=0) by www.lanforge.com (8.12.8/8.12.8) with ESMTP id j29NWnLH005065; Wed, 9 Mar 2005 15:32:50 -0800 Message-ID: <422F822D.9010707@candelatech.com> Date: Wed, 09 Mar 2005 15:09:33 -0800 From: Ben Greear Organization: Candela Technologies User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.7.3) Gecko/20041020 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Ganesh Venkatesan CC: "netdev@oss.sgi.com" Subject: Re: ethtool -d no longer works for e1000 References: <422F6C37.8090202@candelatech.com> <5fc59ff3050309140910f3e492@mail.gmail.com> In-Reply-To: <5fc59ff3050309140910f3e492@mail.gmail.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV 0.83/757/Tue Mar 8 15:14:36 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 2776 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: greearb@candelatech.com Precedence: bulk X-list: netdev Content-Length: 959 Lines: 34 Ganesh Venkatesan wrote: > Ben: > > Are you using the e1000 that is included in the 2.6.11 kernel? ethtool > -d eth? works fine for me. What else is different in your env? I have patched the e1000 in my 2.6.11 kernel, but I see this -d problem on other un-patched systems as well, so it can't be (just) my patches that are the problem. I also tried this on my x86-64 opteron system, running FC3. I have not hacked up this kernel or user-space tools at all :) [root@grok lanforge]# ethtool -i eth3 driver: e1000 version: 5.5.4-k2-NAPI firmware-version: N/A bus-info: 0000:02:08.0 [root@grok lanforge]# ethtool -d eth3 Cannot dump registers: Success [root@grok lanforge]# uname -a Linux grok 2.6.10-1.766_FC3smp #1 SMP Wed Feb 9 23:17:48 EST 2005 x86_64 x86_64 x86_64 GNU/Linux I'm using ethtool 1.8 on this system. What version of ethtool are you using? -- Ben Greear Candela Technologies Inc http://www.candelatech.com From linux-netdev@gmane.org Wed Mar 9 15:14:57 2005 Received: with ECARTIS (v1.0.0; list netdev); Wed, 09 Mar 2005 15:15:03 -0800 (PST) Received: from ciao.gmane.org (main.gmane.org [80.91.229.2]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j29NEuqn001809 for ; Wed, 9 Mar 2005 15:14:57 -0800 Received: from root by ciao.gmane.org with local (Exim 4.43) id 1D9AK4-0000kP-4q for netdev@oss.sgi.com; Thu, 10 Mar 2005 00:10:36 +0100 Received: from 69.15.40.50 ([69.15.40.50]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Thu, 10 Mar 2005 00:10:36 +0100 Received: from lunz by 69.15.40.50 with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Thu, 10 Mar 2005 00:10:36 +0100 X-Injected-Via-Gmane: http://gmane.org/ To: netdev@oss.sgi.com From: Jason Lunz Subject: Re: Do you know the TCP stack? (127.x.x.x routing) Date: Wed, 9 Mar 2005 16:46:02 +0000 (UTC) Organization: PBR Streetgang Message-ID: References: <20050306173145.GQ31837@postel.suug.ch> <3sp35g$7hpm0@smtp04.mrf.mail.rcn.net> <422C0B50.20500@mrv.com> <3sp35g$7rsc1@smtp04.mrf.mail.rcn.net> <1110288879.1050.167.camel@jzny.localdomain> <20050308135134.GA20607@atrey.karlin.mff.cuni.cz> <1110290300.1050.190.camel@jzny.localdomain> <20050308140301.GC20607@atrey.karlin.mff.cuni.cz> <1110291470.1043.211.camel@jzny.localdomain> <1110316631.1084.57.camel@jzny.localdomain> <1110377889.1090.124.camel@jzny.localdomain> X-Complaints-To: usenet@sea.gmane.org X-Gmane-NNTP-Posting-Host: 69.15.40.50 User-Agent: slrn/0.9.8.1 (Debian) X-Gmane-MailScanner: Found to be clean Cc: linux-net@vger.kernel.org X-Gmane-MailScanner: Found to be clean X-MailScanner-From: linux-netdev@m.gmane.org X-MailScanner-To: netdev@oss.sgi.com X-Virus-Scanned: ClamAV 0.83/757/Tue Mar 8 15:14:36 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 2777 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: lunz@falooley.org Precedence: bulk X-list: netdev Content-Length: 1345 Lines: 24 hadi@cyberus.ca said: > Are we still talking about the same problem? The linecards addresses > and interconnect interfaces are "internal". They are never > advertised/seen outside of the chasis. So if you choose 18.7.22.69/32 > to use internally you make sure it is never advertised to the outside > world as belonging to you. If you have to advertise it or actually > know it is used, then you must deal with the conflict. I think you're both in agreement, however violently you try not to be. The question, though, is: *How* do you configure the nodes within the chassis such that the internal IPs (whatever they are) _stay_ internal, and any non-127/8 addressing can be used for the external interfaces? I've done something similar, for example, using policy routing and the arp sysctls. Suppose you have a machine with 2 interfaces, and you want IP routing to happen on each of the two interfaces as independently as possible. My solution involves using the "iif" modifier in your routing rules ("ip rule" rules) to send packets to two completely different routing tables, and making sure arp doesn't bleed across the two interfaces. I don't know whether policy routing gives enough control to do this in a general fashion; i did it only for very specific types of traffic. But I suspect you could come up with something workable. Jason From shemminger@osdl.org Wed Mar 9 15:16:01 2005 Received: with ECARTIS (v1.0.0; list netdev); Wed, 09 Mar 2005 15:16:06 -0800 (PST) Received: from smtp.osdl.org (fire.osdl.org [65.172.181.4]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j29NG1YX002078 for ; Wed, 9 Mar 2005 15:16:01 -0800 Received: from shell0.pdx.osdl.net (fw.osdl.org [65.172.181.6]) by smtp.osdl.org (8.12.8/8.12.8) with ESMTP id j29NFrqi006202 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO); Wed, 9 Mar 2005 15:15:53 -0800 Received: from dxpl.pdx.osdl.net (dxpl.pdx.osdl.net [172.20.1.103]) by shell0.pdx.osdl.net (8.13.1/8.11.6) with ESMTP id j29NFrEo028569; Wed, 9 Mar 2005 15:15:53 -0800 Date: Wed, 9 Mar 2005 15:16:11 -0800 From: Stephen Hemminger To: Francois Romieu Cc: netdev@oss.sgi.com Subject: Re: [PATCH 1/5] r8169: auto detect 32-bit slot Message-ID: <20050309151611.431accce@dxpl.pdx.osdl.net> In-Reply-To: <20050309230809.GC9502@electric-eye.fr.zoreil.com> References: <20050309112925.7f7900ab@dxpl.pdx.osdl.net> <20050309214023.GA9502@electric-eye.fr.zoreil.com> <20050309135530.5c5c80b6@dxpl.pdx.osdl.net> <20050309230809.GC9502@electric-eye.fr.zoreil.com> Organization: Open Source Development Lab X-Mailer: Sylpheed-Claws 1.0.1 (GTK+ 1.2.10; x86_64-unknown-linux-gnu) X-Face: &@E+xe?c%:&e4D{>f1O<&U>2qwRREG5!}7R4;D<"NO^UI2mJ[eEOA2*3>(`Th.yP,VDPo9$ /`~cw![cmj~~jWe?AHY7D1S+\}5brN0k*NE?pPh_'_d>6;XGG[\KDRViCfumZT3@[ Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Received-SPF: pass (domain of shemminger@osdl.org designates 65.172.181.6 as permitted sender) X-MIMEDefang-Filter: osdl$Revision: 1.104 $ X-Scanned-By: MIMEDefang 2.36 X-Virus-Scanned: ClamAV 0.83/757/Tue Mar 8 15:14:36 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 2778 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: shemminger@osdl.org Precedence: bulk X-list: netdev Content-Length: 1435 Lines: 30 On Thu, 10 Mar 2005 00:08:09 +0100 Francois Romieu wrote: > Stephen Hemminger : > [...] > > I tested on old Celeron with Netgear card. I could try Amd and/or Xeon > > if you want. > > If the systems are 64 bit, one would need to know how the driver behaves > when DAC is forced and: > 1) the Netgear card is in a 32 bit slot, dma to highmem is enabled and used > 2) the Netgear card is in a 32 bit slot, dma to highmem is enabled and unused > 3) the Netgear card is in a 32 bit slot, dma to highmem is disabled > 4) the Netgear card is in a 64 bit slot, dma to highmem is enabled and used > 5) the Netgear card is in a 64 bit slot, dma to highmem is enabled and unused > 6) the Netgear card is in a 64 bit slot, dma to highmem is disabled > > + the content of the Config2 register for 1-6. > > If the amd64 hosts a built-in 8169, add the behavior with highmem disabled or > enabled + variable amount of memory. > > As it still leaves some archs in the cold + DAC ought not to be dependant > on the bus width + a few "broken" adapters exist, the patch makes me a bit > sceptical. Okay, the motivation was to try and get rid of the module parameter. I hate to see more parameters, and really don't like it when different drivers start to do things in different ways. Don't really have enough background to know which adapters and arch combinations are broken; so just drop the patch. From ak@muc.de Wed Mar 9 15:20:27 2005 Received: with ECARTIS (v1.0.0; list netdev); Wed, 09 Mar 2005 15:20:30 -0800 (PST) Received: from colin2.muc.de (qmailr@colin2.muc.de [193.149.48.15]) by oss.sgi.com (8.13.0/8.13.0) with SMTP id j29NKPTM003073 for ; Wed, 9 Mar 2005 15:20:26 -0800 Received: (qmail 72000 invoked by uid 3709); 9 Mar 2005 23:20:24 -0000 Date: 10 Mar 2005 00:20:24 +0100 Date: Thu, 10 Mar 2005 00:20:24 +0100 From: Andi Kleen To: Francois Romieu Cc: Stephen Hemminger , netdev@oss.sgi.com Subject: Re: [PATCH 1/5] r8169: auto detect 32-bit slot Message-ID: <20050309232024.GC63395@muc.de> References: <20050309112925.7f7900ab@dxpl.pdx.osdl.net> <20050309214023.GA9502@electric-eye.fr.zoreil.com> <20050309135530.5c5c80b6@dxpl.pdx.osdl.net> <20050309230809.GC9502@electric-eye.fr.zoreil.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20050309230809.GC9502@electric-eye.fr.zoreil.com> User-Agent: Mutt/1.4.1i X-Virus-Scanned: ClamAV 0.83/757/Tue Mar 8 15:14:36 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 2779 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: ak@muc.de Precedence: bulk X-list: netdev Content-Length: 1455 Lines: 35 On Thu, Mar 10, 2005 at 12:08:09AM +0100, Francois Romieu wrote: > Stephen Hemminger : > [...] > > I tested on old Celeron with Netgear card. I could try Amd and/or Xeon > > if you want. > > If the systems are 64 bit, one would need to know how the driver behaves > when DAC is forced and: The concept of "64bit systems" is useless here anyways. Even on a 32bit system with highmem like i386 you can get >32bit addresses to deal with. One usecase for that would be sendfile() out of user space. This is widely used these days. > 1) the Netgear card is in a 32 bit slot, dma to highmem is enabled and used > 2) the Netgear card is in a 32 bit slot, dma to highmem is enabled and unused > 3) the Netgear card is in a 32 bit slot, dma to highmem is disabled > 4) the Netgear card is in a 64 bit slot, dma to highmem is enabled and used > 5) the Netgear card is in a 64 bit slot, dma to highmem is enabled and unused > 6) the Netgear card is in a 64 bit slot, dma to highmem is disabled Again are you sure it depends on 64bit slots? Normally 64bit slots only offer more bandwidth, but the address protocol is the same as 32bit and both support DAC in the same way. > > + the content of the Config2 register for 1-6. > > If the amd64 hosts a built-in 8169, add the behavior with highmem disabled or > enabled + variable amount of memory. You really should forget about amd64 or not, all that counts is sizeof(dma_addr_t) -Andi From jdmason@us.ibm.com Wed Mar 9 15:21:48 2005 Received: with ECARTIS (v1.0.0; list netdev); Wed, 09 Mar 2005 15:21:54 -0800 (PST) Received: from e34.co.us.ibm.com (e34.co.us.ibm.com [32.97.110.132]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j29NLlgV003595 for ; Wed, 9 Mar 2005 15:21:48 -0800 Received: from westrelay03.boulder.ibm.com (westrelay03.boulder.ibm.com [9.17.195.12]) by e34.co.us.ibm.com (8.12.10/8.12.9) with ESMTP id j29NLgKN254526 for ; Wed, 9 Mar 2005 18:21:42 -0500 Received: from d03av01.boulder.ibm.com (d03av01.boulder.ibm.com [9.17.195.167]) by westrelay03.boulder.ibm.com (8.12.10/NCO/VER6.6) with ESMTP id j29NLgb0131286 for ; Wed, 9 Mar 2005 16:21:42 -0700 Received: from d03av01.boulder.ibm.com (loopback [127.0.0.1]) by d03av01.boulder.ibm.com (8.12.11/8.12.11) with ESMTP id j29NLfED028356 for ; Wed, 9 Mar 2005 16:21:41 -0700 Received: from dreadnought.austin.ibm.com (dreadnought.austin.ibm.com [9.41.94.123]) by d03av01.boulder.ibm.com (8.12.11/8.12.11) with ESMTP id j29NLfNU028345; Wed, 9 Mar 2005 16:21:41 -0700 From: Jon Mason Organization: IBM To: Ben Greear Subject: Re: ethtool -d no longer works for e1000 Date: Wed, 9 Mar 2005 17:13:55 -0600 User-Agent: KMail/1.7.2 Cc: Ganesh Venkatesan , "netdev@oss.sgi.com" References: <422F6C37.8090202@candelatech.com> <5fc59ff3050309140910f3e492@mail.gmail.com> <422F822D.9010707@candelatech.com> In-Reply-To: <422F822D.9010707@candelatech.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200503091713.55454.jdmason@us.ibm.com> X-Virus-Scanned: ClamAV 0.83/757/Tue Mar 8 15:14:36 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 2780 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: jdmason@us.ibm.com Precedence: bulk X-list: netdev Content-Length: 3720 Lines: 98 I don't see this problem at all on my 2.6.11-rc4-mm1 kernel (Athlon64 proc). # ethtool -i eth0 driver: e1000 version: 5.7.6-k2 firmware-version: N/A bus-info: 0000:00:07.0 # ethtool -d eth0 MAC Registers ------------- 0x00000: CTRL (Device control register) 0x00F00249 Duplex: full Endian mode (buffers): little Link reset: reset Set link up: 1 Invert Loss-Of-Signal: no Receive flow control: disabled Transmit flow control: disabled VLAN mode: disabled Auto speed detect: disabled Speed select: 1000Mb/s Force speed: no Force duplex: no 0x00008: STATUS (Device status register) 0x0000C343 Duplex: full Link up: link config TBI mode: disabled Link speed: 100Mb/s Bus type: PCI Bus speed: 33MHz Bus width: 32-bit 0x00100: RCTL (Receive control register) 0x00008002 Receiver: enabled Store bad packets: disabled Unicast promiscuous: disabled Multicast promiscuous: disabled Long packet: disabled Descriptor minimum threshold size: 1/2 Broadcast accept mode: accept VLAN filter: disabled Cononical form indicator: disabled Discard pause frames: filtered Pass MAC control frames: don't pass Receive buffer size: 2048 0x02808: RDLEN (Receive desc length) 0x00001000 0x02810: RDH (Receive desc head) 0x00000003 0x02818: RDT (Receive desc tail) 0x00000000 0x02820: RDTR (Receive delay timer) 0x00000000 0x00400: TCTL (Transmit ctrl register) 0x000400FA Transmitter: enabled Pad short packets: enabled Software XOFF Transmission: disabled Re-transmit on late collision: disabled 0x03808: TDLEN (Transmit desc length) 0x00001000 0x03810: TDH (Transmit desc head) 0x000000D8 0x03818: TDT (Transmit desc tail) 0x000000D8 0x03820: TIDV (Transmit delay timer) 0x00000040 PHY type: M88 # uname -a Linux victory 2.6.11-rc4-mm1 #4 Fri Feb 25 18:19:43 CST 2005 x86_64 AMD Athlon(tm) 64 Processor 3200+ AuthenticAMD GNU/Linux On Wednesday 09 March 2005 05:09 pm, Ben Greear wrote: > Ganesh Venkatesan wrote: > > Ben: > > > > Are you using the e1000 that is included in the 2.6.11 kernel? ethtool > > -d eth? works fine for me. What else is different in your env? > > I have patched the e1000 in my 2.6.11 kernel, but I see this -d problem > on other un-patched systems as well, so it can't be (just) my patches > that are the problem. > > I also tried this on my x86-64 opteron system, running FC3. I > have not hacked up this kernel or user-space tools at all :) > > [root@grok lanforge]# ethtool -i eth3 > driver: e1000 > version: 5.5.4-k2-NAPI > firmware-version: N/A > bus-info: 0000:02:08.0 > [root@grok lanforge]# ethtool -d eth3 > Cannot dump registers: Success > [root@grok lanforge]# uname -a > Linux grok 2.6.10-1.766_FC3smp #1 SMP Wed Feb 9 23:17:48 EST 2005 x86_64 > x86_64 x86_64 GNU/Linux > > > I'm using ethtool 1.8 on this system. > > > What version of ethtool are you using? -- Jon Mason jdmason@us.ibm.com From kaber@trash.net Wed Mar 9 15:27:13 2005 Received: with ECARTIS (v1.0.0; list netdev); Wed, 09 Mar 2005 15:27:17 -0800 (PST) Received: from kaber.coreworks.de ([62.206.217.67]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j29NRCei004249 for ; Wed, 9 Mar 2005 15:27:13 -0800 Received: from localhost ([127.0.0.1]) by kaber.coreworks.de with esmtp (Exim 4.50) id 1D9Aa1-0001Kz-DS; Thu, 10 Mar 2005 00:27:05 +0100 Message-ID: <422F8649.8050707@trash.net> Date: Thu, 10 Mar 2005 00:27:05 +0100 From: Patrick McHardy User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.7.5) Gecko/20050106 Debian/1.7.5-1 X-Accept-Language: en MIME-Version: 1.0 To: Michal Vanco CC: netdev@oss.sgi.com Subject: Re: 2.6.11 on AMD64 traps References: <200503081900.18686.vanco@satro.sk> <200503092142.50027.vanco@satro.sk> <422F6517.6070301@trash.net> <200503092217.01106.vanco@satro.sk> In-Reply-To: <200503092217.01106.vanco@satro.sk> Content-Type: multipart/mixed; boundary="------------030903050501090506050905" X-Virus-Scanned: ClamAV 0.83/757/Tue Mar 8 15:14:36 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 2781 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: kaber@trash.net Precedence: bulk X-list: netdev Content-Length: 4059 Lines: 154 This is a multi-part message in MIME format. --------------030903050501090506050905 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Michal Vanco wrote: > On Wednesday 09 March 2005 22:05, Patrick McHardy wrote: > >>>Sure. Can (or will) this ever be fixed to any usable state also with >>>netstat? Is this problem related only to AMD64? >> >>Maybe. To start dumping entries of an open hashed hash-table at a >>specific position we need to skip all entries before that position by >>walking over them. This results in quadratic time complexity. It might >>be possible to improve this by cacheing the last position in >>fib_iter_state even between ->stop() and ->start() calls and using >>generation IDs for invalidation. And here it is. Could you redo your timing-test with this patch please? Thanks Patrick --------------030903050501090506050905 Content-Type: text/plain; name="x" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="x" # This is a BitKeeper generated diff -Nru style patch. # # ChangeSet # 2005/03/10 00:07:21+01:00 kaber@coreworks.de # [IPV4]: Speed up sequential reading of /proc/net/route # # Cacheing the current position reduces complexity from O(n^2) # to O(n). # # Signed-off-by: Patrick McHardy # # net/ipv4/fib_hash.c # 2005/03/10 00:07:11+01:00 kaber@coreworks.de +22 -1 # [IPV4]: Speed up sequential reading of /proc/net/route # # Cacheing the current position reduces complexity from O(n^2) # to O(n). # # Signed-off-by: Patrick McHardy # diff -Nru a/net/ipv4/fib_hash.c b/net/ipv4/fib_hash.c --- a/net/ipv4/fib_hash.c 2005-03-10 00:07:43 +01:00 +++ b/net/ipv4/fib_hash.c 2005-03-10 00:07:43 +01:00 @@ -93,6 +93,7 @@ } static DEFINE_RWLOCK(fib_hash_lock); +static unsigned int fib_hash_genid; #define FZ_MAX_DIVISOR ((PAGE_SIZE<fz_hashmask = new_hashmask; fz->fz_divisor = new_divisor; fn_rebuild_zone(fz, old_ht, old_divisor); + fib_hash_genid++; write_unlock_bh(&fib_hash_lock); fz_hash_free(old_ht, old_divisor); @@ -236,6 +238,7 @@ table->fn_zones[i]->fz_next = fz; } table->fn_zones[z] = fz; + fib_hash_genid++; write_unlock_bh(&fib_hash_lock); return fz; } @@ -451,6 +454,7 @@ fa->fa_scope = r->rtm_scope; state = fa->fa_state; fa->fa_state &= ~FA_S_ACCESSED; + fib_hash_genid++; write_unlock_bh(&fib_hash_lock); fib_release_info(fi_drop); @@ -515,6 +519,7 @@ fib_insert_node(fz, new_f); list_add_tail(&new_fa->fa_list, (fa ? &fa->fa_list : &f->fn_alias)); + fib_hash_genid++; write_unlock_bh(&fib_hash_lock); if (new_f) @@ -600,6 +605,7 @@ hlist_del(&f->fn_hash); kill_fn = 1; } + fib_hash_genid++; write_unlock_bh(&fib_hash_lock); if (fa->fa_state & FA_S_ACCESSED) @@ -637,6 +643,7 @@ hlist_del(&f->fn_hash); kill_f = 1; } + fib_hash_genid++; write_unlock_bh(&fib_hash_lock); fn_free_alias(fa); @@ -801,6 +808,9 @@ struct hlist_head *hash_head; struct fib_node *fn; struct fib_alias *fa; + loff_t pos; + unsigned int genid; + int valid; }; static struct fib_alias *fib_get_first(struct seq_file *seq) @@ -812,6 +822,9 @@ iter->hash_head = NULL; iter->fn = NULL; iter->fa = NULL; + iter->pos = 0; + iter->genid = fib_hash_genid; + iter->valid = 1; for (iter->zone = table->fn_zone_list; iter->zone; iter->zone = iter->zone->fz_next) { @@ -916,12 +929,20 @@ } } out: + iter->pos++; return fa; } static struct fib_alias *fib_get_idx(struct seq_file *seq, loff_t pos) { - struct fib_alias *fa = fib_get_first(seq); + struct fib_iter_state *iter = seq->private; + struct fib_alias *fa; + + if (iter->valid && pos >= iter->pos && iter->genid == fib_hash_genid) { + fa = iter->fa; + pos -= iter->pos; + } else + fa = fib_get_first(seq); if (fa) while (pos && (fa = fib_get_next(seq))) --------------030903050501090506050905-- From greearb@candelatech.com Wed Mar 9 15:31:07 2005 Received: with ECARTIS (v1.0.0; list netdev); Wed, 09 Mar 2005 15:31:12 -0800 (PST) Received: from www.lanforge.com (ns1.lanforge.com [66.165.47.210]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j29NV7kF004807 for ; Wed, 9 Mar 2005 15:31:07 -0800 Received: from [4.33.45.22] (evrtwa1-ar2-4-33-045-022.evrtwa1.dsl-verizon.net [4.33.45.22]) (authenticated bits=0) by www.lanforge.com (8.12.8/8.12.8) with ESMTP id j29NsKLH005390; Wed, 9 Mar 2005 15:54:20 -0800 Message-ID: <422F8737.7050002@candelatech.com> Date: Wed, 09 Mar 2005 15:31:03 -0800 From: Ben Greear Organization: Candela Technologies User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.7.3) Gecko/20041020 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Jon Mason CC: Ganesh Venkatesan , "netdev@oss.sgi.com" Subject: Re: ethtool -d no longer works for e1000 References: <422F6C37.8090202@candelatech.com> <5fc59ff3050309140910f3e492@mail.gmail.com> <422F822D.9010707@candelatech.com> <200503091713.55454.jdmason@us.ibm.com> In-Reply-To: <200503091713.55454.jdmason@us.ibm.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV 0.83/757/Tue Mar 8 15:14:36 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 2782 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: greearb@candelatech.com Precedence: bulk X-list: netdev Content-Length: 386 Lines: 14 Jon Mason wrote: > I don't see this problem at all on my 2.6.11-rc4-mm1 kernel (Athlon64 proc). I think I see the problem. ethtool -d eth0 works for me, but ethtool -d eth1 does not, even with both are e1000 NICs. It appears it cannot handle reading the second NIC for some reason? Ben -- Ben Greear Candela Technologies Inc http://www.candelatech.com From greearb@candelatech.com Wed Mar 9 15:42:08 2005 Received: with ECARTIS (v1.0.0; list netdev); Wed, 09 Mar 2005 15:42:17 -0800 (PST) Received: from www.lanforge.com (ns1.lanforge.com [66.165.47.210]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j29Ng6hp005527 for ; Wed, 9 Mar 2005 15:42:08 -0800 Received: from [4.33.45.22] (evrtwa1-ar2-4-33-045-022.evrtwa1.dsl-verizon.net [4.33.45.22]) (authenticated bits=0) by www.lanforge.com (8.12.8/8.12.8) with ESMTP id j2A05JLH005528; Wed, 9 Mar 2005 16:05:20 -0800 Message-ID: <422F89CB.2070705@candelatech.com> Date: Wed, 09 Mar 2005 15:42:03 -0800 From: Ben Greear Organization: Candela Technologies User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.7.3) Gecko/20041020 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Jon Mason CC: Ganesh Venkatesan , "netdev@oss.sgi.com" Subject: Re: ethtool -d no longer works for e1000 References: <422F6C37.8090202@candelatech.com> <5fc59ff3050309140910f3e492@mail.gmail.com> <422F822D.9010707@candelatech.com> <200503091713.55454.jdmason@us.ibm.com> <422F8737.7050002@candelatech.com> In-Reply-To: <422F8737.7050002@candelatech.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV 0.83/757/Tue Mar 8 15:14:36 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 2783 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: greearb@candelatech.com Precedence: bulk X-list: netdev Content-Length: 655 Lines: 26 Ben Greear wrote: > Jon Mason wrote: > >> I don't see this problem at all on my 2.6.11-rc4-mm1 kernel (Athlon64 >> proc). > > > I think I see the problem. ethtool -d eth0 works for me, > but ethtool -d eth1 does not, even with both are e1000 > NICs. It appears it cannot handle reading the second NIC for > some reason? Errr, my bad. The problem is more that the dual-port pro/1000 NICs don't seem to work, but the built-in e1000s do. The chipset that does not work correctly is: 82546GB The NICs with chipset: 82541EI seem to work just fine. Ben -- Ben Greear Candela Technologies Inc http://www.candelatech.com From akpm@osdl.org Wed Mar 9 15:49:39 2005 Received: with ECARTIS (v1.0.0; list netdev); Wed, 09 Mar 2005 15:49:44 -0800 (PST) Received: from smtp.osdl.org (fire.osdl.org [65.172.181.4]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j29Nndwo006140 for ; Wed, 9 Mar 2005 15:49:39 -0800 Received: from shell0.pdx.osdl.net (fw.osdl.org [65.172.181.6]) by smtp.osdl.org (8.12.8/8.12.8) with ESMTP id j29NnTqi009785 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO); Wed, 9 Mar 2005 15:49:29 -0800 Received: from bix (shell0.pdx.osdl.net [10.9.0.31]) by shell0.pdx.osdl.net (8.13.1/8.11.6) with SMTP id j29NnSXj030362; Wed, 9 Mar 2005 15:49:28 -0800 Date: Wed, 9 Mar 2005 15:49:02 -0800 From: Andrew Morton To: "Balasaygun, Oray (Oray)" Cc: oray@lucent.com, linuxppc-dev@ozlabs.org, netdev@oss.sgi.com, dnikoonezhad@lucent.com Subject: Re: [Bugme-new] [Bug 4310] New: ppc 8260 fcc ethernet driver cann ot read LXT971 PHY id Message-Id: <20050309154902.2451d190.akpm@osdl.org> In-Reply-To: References: X-Mailer: Sylpheed version 0.9.7 (GTK+ 1.2.10; i386-redhat-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Received-SPF: pass (domain of akpm@osdl.org designates 65.172.181.6 as permitted sender) X-MIMEDefang-Filter: osdl$Revision: 1.104 $ X-Scanned-By: MIMEDefang 2.36 X-Virus-Scanned: ClamAV 0.83/757/Tue Mar 8 15:14:36 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 2784 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: akpm@osdl.org Precedence: bulk X-list: netdev Content-Length: 8017 Lines: 240 "Balasaygun, Oray (Oray)" wrote: > > Attached please find the diff output of the fcc_enet.c that I am running with and the original 2.6.10 version of it. Patch looks reasonable, if unconvnetionally presented ;) Thanks. I fixed a bit of whitespace and converted mii_display_config() and mii_relink() to take an unsigned long arguments as they're now a tasklet callback. Perhaps you could retest this sometime, please? From: "Balasaygun, Oray (Oray)" - fix for Bug 4310 - The fcc_enet.c, as distributed in 2.6.10, does not compile. Evidently the 2.6 kernel no longer supports the schedule_task() and "struct tq_struct" to go with it. Lines 73 through and including 96 of the diffout file show the changes I made to port schedule_task() into tasklet_schedule(). I should have reported this as a bug too but I forgot about it. - customize fcc_enet.c to work with my custom board. These changes are conditional on CONFIG_EON8260 being defined. Signed-off-by: Andrew Morton --- 25-akpm/arch/ppc/8260_io/fcc_enet.c | 91 ++++++++++++++++++++++++++++++------ 1 files changed, 78 insertions(+), 13 deletions(-) diff -puN arch/ppc/8260_io/fcc_enet.c~ppc-8260-fcc-ethernet-driver-cannot-read-lxt971-phy-id arch/ppc/8260_io/fcc_enet.c --- 25/arch/ppc/8260_io/fcc_enet.c~ppc-8260-fcc-ethernet-driver-cannot-read-lxt971-phy-id 2005-03-09 15:40:26.000000000 -0800 +++ 25-akpm/arch/ppc/8260_io/fcc_enet.c 2005-03-09 15:47:23.000000000 -0800 @@ -177,6 +177,54 @@ static int fcc_enet_set_mac_address(stru #define CMX1_CLK_MASK ((uint)0xff000000) #endif +#ifdef CONFIG_EON8260 + +#define MAKE_BITMASK(n) (1 << (31-n)) + +#define PA8 MAKE_BITMASK(8) +#define PA9 MAKE_BITMASK(9) + +#define PB18 MAKE_BITMASK(18) +#define PB19 MAKE_BITMASK(19) +#define PB20 MAKE_BITMASK(20) +#define PB21 MAKE_BITMASK(21) +#define PB22 MAKE_BITMASK(22) +#define PB23 MAKE_BITMASK(23) +#define PB24 MAKE_BITMASK(24) +#define PB25 MAKE_BITMASK(25) +#define PB26 MAKE_BITMASK(26) +#define PB27 MAKE_BITMASK(27) +#define PB28 MAKE_BITMASK(28) +#define PB29 MAKE_BITMASK(29) +#define PB30 MAKE_BITMASK(30) +#define PB31 MAKE_BITMASK(31) + +#define PB2_TXER PB31 +#define PB2_RXDV PB30 +#define PB2_TXEN PB29 +#define PB2_RXER PB28 +#define PB2_COL PB27 +#define PB2_CRS PB26 +#define PB2_TXDAT (PB22 | PB23 | PB24 | PB25) +#define PB2_RXDAT (PB18 | PB19 | PB20 | PB21) +#define PB2_PSORB0 (PB2_RXDAT | PB2_TXDAT | PB2_CRS | PB2_COL | \ + PB2_RXER | PB2_RXDV | PB2_TXER) +#define PB2_PSORB1 (PB2_TXEN) +#define PB2_DIRB0 (PB2_RXDAT | PB2_CRS | PB2_COL | PB2_RXER | PB2_RXDV) +#define PB2_DIRB1 (PB2_TXDAT | PB2_TXEN | PB2_TXER) + +/* CLK16 (PC16) is receive, CLK15 (PC17) is transmit */ + +#define PC_F2RXCLK ((uint)0x00008000) +#define PC_F2TXCLK ((uint)0x00004000) + +#define CMXFCR_TF2CS_CLK15 0x00060000 /* Transmit FCC2 Clock Source is CLK15 */ +#define CMXFCR_RF2CS_CLK16 0x00380000 /* Receive FCC2 Clock Source is CLK16 */ +#define CMX2_CLK_ROUTE (CMXFCR_RF2CS_CLK16 | CMXFCR_TF2CS_CLK15) +#define CMX2_CLK_MASK ((uint)0x00ff0000) + +#else /* #ifdef CONFIG_EON8260 */ + /* I/O Pin assignment for FCC2. I don't yet know the best way to do this, * but there is little variation among the choices. */ @@ -208,6 +256,8 @@ static int fcc_enet_set_mac_address(stru #define CMX2_CLK_MASK ((uint)0x00ff0000) #endif +#endif /* #ifdef CONFIG_EON8260 */ + /* I/O Pin assignment for FCC3. I don't yet know the best way to do this, * but there is little variation among the choices. */ @@ -234,7 +284,11 @@ static int fcc_enet_set_mac_address(stru /* MII status/control serial interface. */ -#ifdef CONFIG_TQM8260 +#if defined (CONFIG_EON8260) +/* EON8260 has MDIO and MDCK on PC31 and PC30 respectively */ +#define PC_MDIO ((uint)0x00000001) +#define PC_MDCK ((uint)0x00000002) +#elif defined (CONFIG_TQM8260) /* TQM8260 has MDIO and MDCK on PC30 and PC31 respectively */ #define PC_MDIO ((uint)0x00000002) #define PC_MDCK ((uint)0x00000001) @@ -268,7 +322,7 @@ static fcc_info_t fcc_ports[] = { #ifdef CONFIG_FCC1_ENET { 0, CPM_CR_FCC1_SBLOCK, CPM_CR_FCC1_PAGE, PROFF_FCC1, SIU_INT_FCC1, (PC_F1RXCLK | PC_F1TXCLK), CMX1_CLK_ROUTE, CMX1_CLK_MASK, -# if defined(CONFIG_TQM8260) || defined(CONFIG_ADS8272) +# if defined(CONFIG_TQM8260) || defined(CONFIG_ADS8272) || defined(CONFIG_EON8260) PC_MDIO, PC_MDCK }, # else 0x00000004, 0x00000100 }, @@ -277,7 +331,7 @@ static fcc_info_t fcc_ports[] = { #ifdef CONFIG_FCC2_ENET { 1, CPM_CR_FCC2_SBLOCK, CPM_CR_FCC2_PAGE, PROFF_FCC2, SIU_INT_FCC2, (PC_F2RXCLK | PC_F2TXCLK), CMX2_CLK_ROUTE, CMX2_CLK_MASK, -# if defined(CONFIG_TQM8260) || defined(CONFIG_ADS8272) +# if defined(CONFIG_TQM8260) || defined(CONFIG_ADS8272) || defined(CONFIG_EON8260) PC_MDIO, PC_MDCK }, # elif defined(CONFIG_EST8260) || defined(CONFIG_ADS8260) 0x00400000, 0x00200000 }, @@ -288,7 +342,7 @@ static fcc_info_t fcc_ports[] = { #ifdef CONFIG_FCC3_ENET { 2, CPM_CR_FCC3_SBLOCK, CPM_CR_FCC3_PAGE, PROFF_FCC3, SIU_INT_FCC3, (PC_F3RXCLK | PC_F3TXCLK), CMX3_CLK_ROUTE, CMX3_CLK_MASK, -# if defined(CONFIG_TQM8260) || defined(CONFIG_ADS8272) +# if defined(CONFIG_TQM8260) || defined(CONFIG_ADS8272) || defined(CONFIG_EON8260) PC_MDIO, PC_MDCK }, # else 0x00000001, 0x00000040 }, @@ -329,7 +383,7 @@ struct fcc_enet_private { uint phy_id_done; uint phy_status; phy_info_t *phy; - struct tq_struct phy_task; + struct tasklet_struct phy_task; uint sequence_done; @@ -1191,8 +1245,9 @@ static void mii_display_status(struct ne printk(".\n"); } -static void mii_display_config(struct net_device *dev) +static void mii_display_config(unsigned long arg) { + struct net_device *dev = (struct net_device *)arg; volatile struct fcc_enet_private *fep = dev->priv; uint s = fep->phy_status; @@ -1222,8 +1277,9 @@ static void mii_display_config(struct ne fep->sequence_done = 1; } -static void mii_relink(struct net_device *dev) +static void mii_relink(unsigned long arg) { + struct net_device *dev = (struct net_device *)arg; struct fcc_enet_private *fep = dev->priv; int duplex; @@ -1246,18 +1302,18 @@ static void mii_queue_relink(uint mii_re { struct fcc_enet_private *fep = dev->priv; - fep->phy_task.routine = (void *)mii_relink; + fep->phy_task.func = mii_relink; fep->phy_task.data = dev; - schedule_task(&fep->phy_task); + tasklet_schedule(&fep->phy_task); } static void mii_queue_config(uint mii_reg, struct net_device *dev) { struct fcc_enet_private *fep = dev->priv; - fep->phy_task.routine = (void *)mii_display_config; + fep->phy_task.func = mii_display_config; fep->phy_task.data = dev; - schedule_task(&fep->phy_task); + tasklet_schedule(&fep->phy_task); } @@ -1464,6 +1520,9 @@ static int __init fec_enet_init(void) return -ENOMEM; cep = dev->priv; + cep->phy_task.next = NULL; + cep->phy_task.state = 0; + cep->phy_task.count.counter = 0; spin_lock_init(&cep->lock); cep->fip = fip; @@ -1698,6 +1757,11 @@ init_fcc_param(fcc_info_t *fip, struct n * non-static part of the address. */ eap = (unsigned char *)&(ep->fen_paddrh); +#if defined(CONFIG_EON8260) + for (i = 5; i >=0 ; i--) { + *eap++ = dev->dev_addr[i] = bd->bi_enetaddr[i]; + } +#else /* if defined(CONFIG_EON8260) */ for (i=5; i>=0; i--) { #ifdef CONFIG_SBC82xx if (i == 5) { @@ -1718,6 +1782,7 @@ init_fcc_param(fcc_info_t *fip, struct n *eap++ = dev->dev_addr[i] = bd->bi_enetaddr[i]; } } +#endif /* if defined(CONFIG_EON8260) */ ep->fen_taddrh = 0; ep->fen_taddrm = 0; @@ -1940,10 +2005,10 @@ mii_send_receive(fcc_info_t *fip, uint c { FCC_PDATC_MDC(1); retval <<= 1; - if (io->iop_pdatc & fip->fc_mdio) - retval++; udelay(1); FCC_PDATC_MDC(0); + if (io->iop_pdatc & fip->fc_mdio) + retval++; udelay(1); } } _ From vanco@satro.sk Wed Mar 9 15:50:08 2005 Received: with ECARTIS (v1.0.0; list netdev); Wed, 09 Mar 2005 15:50:13 -0800 (PST) Received: from mail.satronet.sk (mail.satronet.sk [217.144.16.198]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j29No6VX006330 for ; Wed, 9 Mar 2005 15:50:08 -0800 Received: from localhost (localhost.localdomain [127.0.0.1]) by mail.satronet.sk (Postfix) with ESMTP id 4D1B416057030; Thu, 10 Mar 2005 00:50:05 +0100 (CET) Received: from mail.satronet.sk ([127.0.0.1]) by localhost (mail [127.0.0.1]) (amavisd-new, port 10024) with LMTP id 17797-04-4; Thu, 10 Mar 2005 00:50:03 +0100 (CET) Received: from [10.1.14.215] (strojar.garda.sk [147.175.8.5]) (using TLSv1 with cipher RC4-MD5 (128/128 bits)) (No client certificate requested) by mail.satronet.sk (Postfix) with ESMTP id 4E2BC16056657; Thu, 10 Mar 2005 00:50:03 +0100 (CET) From: Michal Vanco Organization: Satro, s.r.o. To: netdev@oss.sgi.com Subject: Re: 2.6.11 on AMD64 traps Date: Thu, 10 Mar 2005 00:50:05 +0100 User-Agent: KMail/1.7.2 Cc: Patrick McHardy References: <200503081900.18686.vanco@satro.sk> <200503092217.01106.vanco@satro.sk> <422F8649.8050707@trash.net> In-Reply-To: <422F8649.8050707@trash.net> MIME-Version: 1.0 Content-Type: multipart/signed; boundary="nextPart1432720.iW0JzFStEf"; protocol="application/pgp-signature"; micalg=pgp-sha1 Content-Transfer-Encoding: 7bit Message-Id: <200503100050.05582.vanco@satro.sk> X-Virus-Scanned: ClamAV 0.83/757/Tue Mar 8 15:14:36 2005 on oss.sgi.com X-Virus-Scanned: by ANTIvirus at satronet.sk X-Virus-Status: Clean X-archive-position: 2785 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: vanco@satro.sk Precedence: bulk X-list: netdev Content-Length: 1658 Lines: 61 --nextPart1432720.iW0JzFStEf Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline On Thursday 10 March 2005 00:27, Patrick McHardy wrote: > Michal Vanco wrote: > > On Wednesday 09 March 2005 22:05, Patrick McHardy wrote: > >>>Sure. Can (or will) this ever be fixed to any usable state also with > >>>netstat? Is this problem related only to AMD64? > >> > >>Maybe. To start dumping entries of an open hashed hash-table at a > >>specific position we need to skip all entries before that position by > >>walking over them. This results in quadratic time complexity. It might > >>be possible to improve this by cacheing the last position in > >>fib_iter_state even between ->stop() and ->start() calls and using > >>generation IDs for invalidation. > > And here it is. Could you redo your timing-test with this patch please? Wonderfull: # time ip route show | wc -l; time netstat -rn | wc -l 155991 real 0m1.110s user 0m0.441s sys 0m1.100s 155991 real 0m1.435s user 0m1.026s sys 0m0.436s It seems that netlink is still little bit faster than /proc, but it doesn't= =20 make any sense in case like this. Will this patch be included in future kernels? Great job. Thank you for help. Best regards, =2D-=20 Ing. Michal Van=C4=8Do Network Engineer SATRO s.r.o. e-mail: vanco@satro.sk --nextPart1432720.iW0JzFStEf Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.0 (GNU/Linux) iD8DBQBCL4utSBxxqpMaGkMRAqPHAJ4mGD7K/P+/Ay9JEcMzRMHMmmUv6ACgk3d2 aRMFyFDVbqG8s8dSMSmJgNc= =Ep8t -----END PGP SIGNATURE----- --nextPart1432720.iW0JzFStEf-- From boian@bonev.com Wed Mar 9 15:51:27 2005 Received: with ECARTIS (v1.0.0; list netdev); Wed, 09 Mar 2005 15:51:31 -0800 (PST) Received: from mx.cisbg.com (ns.cisbg.com [195.69.109.188]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j29NpQLs007001 for ; Wed, 9 Mar 2005 15:51:26 -0800 Received: from orange.bonev.com (orange.bonev.com [195.69.108.254]) by mx.cisbg.com (8.13.1/8.13.1) with SMTP id j29NpL9e021379 for ; Thu, 10 Mar 2005 01:51:22 +0200 Received: (qmail 7543 invoked by uid 99); 9 Mar 2005 23:51:22 -0000 Message-ID: <20050309235122.7541.qmail@orange.bonev.com> Mime-Version: 1.0 Received: from firewall.cisbg.com (195.69.108.252) by mail.bonev.com with HTTP; Thu, 10 Mar 2005 01:51:21 +0200 From: Boian Bonev Cc: linux-net@vger.kernel.org To: Jason Lunz , netdev@oss.sgi.com Subject: Re: Do you know the TCP stack? (127.x.x.x routing) Date: Thu, 10 Mar 2005 01:51:21 +0200 Content-Type: multipart/mixed; boundary="=_1_1110412282_7539" Content-Transfer-Encoding: 8bit X-BIS.BG-Antispam-Check: Yes X-Scanned-By: MIMEDefang 2.48 on 195.69.109.187 X-Virus-Scanned: ClamAV 0.83/757/Tue Mar 8 15:14:36 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 2786 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: boian@bonev.com Precedence: bulk X-list: netdev Content-Length: 2174 Lines: 38 This is a MIME-formatted message. If you see this text it means that your E-mail software does not support MIME-formatted messages. --=_1_1110412282_7539 Content-Type: text/plain; charset=windows-1251 Content-Transfer-Encoding: 7bit > The question, though, is: *How* do you configure the nodes within the > chassis such that the internal IPs (whatever they are) _stay_ internal, > and any non-127/8 addressing can be used for the external interfaces? > > I've done something similar, for example, using policy routing and the > arp sysctls. Suppose you have a machine with 2 interfaces, and you want > IP routing to happen on each of the two interfaces as independently as > possible. My solution involves using the "iif" modifier in your routing > rules ("ip rule" rules) to send packets to two completely different > routing tables, and making sure arp doesn't bleed across the two > interfaces. I don't know whether policy routing gives enough control to > do this in a general fashion; i did it only for very specific types of > traffic. But I suspect you could come up with something workable. you can do that but you omit the interface addresses - suppose ext net is 10.20.10.1/24, internal is 10.10.10.1/24, no matter what routing policies and rules you put, both interface ips will be visible from both interfaces. now imagine you have another external net 10.30.10.1/24 and customer wants to route e.g. 10.10.0.0/16 from 10.20.10.1/24 via 10.30.10.5... at least host 10.10.10.1 will not route but arrive locally to your blade host btw. i have seen recently on iptables' patch-o-matic some module that could by condition route traffic to local addresses to another host. anyway the whole thing is doable with any kind of addresses but just imagine what nightmare startup ruleset you will have on each box; then modify your custom rules to conform that hell ruleset and... imho it will be much more easy to create a custom transport over ethernet (in case your ext network could share addresses form that protocol also) and forget about ipv4 for internal implementation. thus you'd have at least better security between worlds ;-) b. --=_1_1110412282_7539-- From tgraf@suug.ch Wed Mar 9 15:57:13 2005 Received: with ECARTIS (v1.0.0; list netdev); Wed, 09 Mar 2005 15:57:18 -0800 (PST) Received: from b.mx.projectdream.org (eth0-0.arisu.projectdream.org [194.158.4.191]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j29NvBRF007748 for ; Wed, 9 Mar 2005 15:57:12 -0800 Received: from postel.suug.ch (postel.suug.ch [195.134.158.23]) (using TLSv1 with cipher EDH-RSA-DES-CBC3-SHA (168/168 bits)) (No client certificate requested) by b.mx.projectdream.org (Postfix) with ESMTP id 36C67F; Thu, 10 Mar 2005 00:56:48 +0100 (CET) Received: by postel.suug.ch (Postfix, from userid 10001) id 0CC8F1C0EA; Thu, 10 Mar 2005 00:57:29 +0100 (CET) Date: Thu, 10 Mar 2005 00:57:28 +0100 From: Thomas Graf To: Ben Greear Cc: "David S. Miller" , Andi Kleen , baruch@ev-en.org, shemminger@osdl.org, netdev@oss.sgi.com Subject: Re: netif_rx packet dumping Message-ID: <20050309235728.GV31837@postel.suug.ch> References: <20050303123811.4d934249@dxpl.pdx.osdl.net> <42278122.6000000@ev-en.org> <20050303133659.0d224e61.davem@davemloft.net> <42278554.2090902@ev-en.org> <20050303135718.2e1a0170.davem@davemloft.net> <422DC7CE.2040800@ev-en.org> <20050308100902.24b67b2f.davem@davemloft.net> <422DEE85.5010302@candelatech.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <422DEE85.5010302@candelatech.com> X-Virus-Scanned: ClamAV 0.83/757/Tue Mar 8 15:14:36 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 2787 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: tgraf@suug.ch Precedence: bulk X-list: netdev Content-Length: 5056 Lines: 144 * Ben Greear <422DEE85.5010302@candelatech.com> 2005-03-08 10:27 > Seems like we might could squish the sk_buff a bit: > > Do we really need 32-bits for the mac-len: > > unsigned int len, > data_len, > mac_len, > csum; Yes, I guess it can be 16-bits. > Some of these flags could be collapsed into a single field and we > could do bit-shift operations for the single flags we care about. > This would also make it easier to add new flags as desired w/out > growing the structure. > > unsigned char local_df, > cloned, > pkt_type, > ip_summed; I changed them to be :1, less work and doesn't have to be atomic anyway. > The priority could probably be 16 bits as well, do we really need more > than 65k different priorities: > > __u32 priority; We use skb->priority to map to tc handles which is by definition 32-bits, not really used at the moment but it will be of use again soon. > Of course...this might be things for 2.7 since lots of modules will probably > be accessing these fields. Maybe to get started we could add macros to grab > the flags and such so that when we finally do collapse things into a single > flags field the external code doesn't have to know or care? I attached a small patch below saving 4 bytes and leaving some room for additional flags. The removal of security has indeed potential to break external modules. diff -Nru linux-2.6.11-bk5.orig/include/linux/skbuff.h linux-2.6.11-bk5/include/linux/skbuff.h --- linux-2.6.11-bk5.orig/include/linux/skbuff.h 2005-03-09 22:00:23.000000000 +0100 +++ linux-2.6.11-bk5/include/linux/skbuff.h 2005-03-10 00:48:46.000000000 +0100 @@ -250,16 +250,16 @@ unsigned int len, data_len, - mac_len, csum; - unsigned char local_df, + unsigned short mac_len, + protocol; + unsigned char pkt_type, + local_df:1, cloned:1, - nohdr:1, - pkt_type, - ip_summed; + ip_summed:2, + nohdr:1; + /* 20 bits spare */ __u32 priority; - unsigned short protocol, - security; void (*destructor)(struct sk_buff *skb); #ifdef CONFIG_NETFILTER diff -Nru linux-2.6.11-bk5.orig/include/linux/tc_ematch/tc_em_meta.h linux-2.6.11-bk5/include/linux/tc_ematch/tc_em_meta.h --- linux-2.6.11-bk5.orig/include/linux/tc_ematch/tc_em_meta.h 2005-03-09 22:00:23.000000000 +0100 +++ linux-2.6.11-bk5/include/linux/tc_ematch/tc_em_meta.h 2005-03-09 23:34:28.000000000 +0100 @@ -45,7 +45,7 @@ TCF_META_ID_REALDEV, TCF_META_ID_PRIORITY, TCF_META_ID_PROTOCOL, - TCF_META_ID_SECURITY, + TCF_META_ID_SECURITY, /* obsolete */ TCF_META_ID_PKTTYPE, TCF_META_ID_PKTLEN, TCF_META_ID_DATALEN, diff -Nru linux-2.6.11-bk5.orig/net/core/skbuff.c linux-2.6.11-bk5/net/core/skbuff.c --- linux-2.6.11-bk5.orig/net/core/skbuff.c 2005-03-09 22:00:39.000000000 +0100 +++ linux-2.6.11-bk5/net/core/skbuff.c 2005-03-09 23:33:54.000000000 +0100 @@ -359,7 +359,6 @@ C(ip_summed); C(priority); C(protocol); - C(security); n->destructor = NULL; #ifdef CONFIG_NETFILTER C(nfmark); @@ -427,7 +426,6 @@ new->pkt_type = old->pkt_type; new->stamp = old->stamp; new->destructor = NULL; - new->security = old->security; #ifdef CONFIG_NETFILTER new->nfmark = old->nfmark; new->nfcache = old->nfcache; diff -Nru linux-2.6.11-bk5.orig/net/ipv4/ip_output.c linux-2.6.11-bk5/net/ipv4/ip_output.c --- linux-2.6.11-bk5.orig/net/ipv4/ip_output.c 2005-03-09 22:00:40.000000000 +0100 +++ linux-2.6.11-bk5/net/ipv4/ip_output.c 2005-03-09 23:41:40.000000000 +0100 @@ -388,7 +388,6 @@ to->pkt_type = from->pkt_type; to->priority = from->priority; to->protocol = from->protocol; - to->security = from->security; dst_release(to->dst); to->dst = dst_clone(from->dst); to->dev = from->dev; diff -Nru linux-2.6.11-bk5.orig/net/ipv6/ip6_output.c linux-2.6.11-bk5/net/ipv6/ip6_output.c --- linux-2.6.11-bk5.orig/net/ipv6/ip6_output.c 2005-03-09 22:00:42.000000000 +0100 +++ linux-2.6.11-bk5/net/ipv6/ip6_output.c 2005-03-09 23:46:01.000000000 +0100 @@ -462,7 +462,6 @@ to->pkt_type = from->pkt_type; to->priority = from->priority; to->protocol = from->protocol; - to->security = from->security; dst_release(to->dst); to->dst = dst_clone(from->dst); to->dev = from->dev; diff -Nru linux-2.6.11-bk5.orig/net/sched/em_meta.c linux-2.6.11-bk5/net/sched/em_meta.c --- linux-2.6.11-bk5.orig/net/sched/em_meta.c 2005-03-09 22:00:41.000000000 +0100 +++ linux-2.6.11-bk5/net/sched/em_meta.c 2005-03-09 23:34:16.000000000 +0100 @@ -204,11 +204,6 @@ dst->value = skb->protocol; } -META_COLLECTOR(int_security) -{ - dst->value = skb->security; -} - META_COLLECTOR(int_pkttype) { dst->value = skb->pkt_type; @@ -311,7 +306,6 @@ [TCF_META_ID_REALDEV] = { .get = meta_int_realdev }, [TCF_META_ID_PRIORITY] = { .get = meta_int_priority }, [TCF_META_ID_PROTOCOL] = { .get = meta_int_protocol }, - [TCF_META_ID_SECURITY] = { .get = meta_int_security }, [TCF_META_ID_PKTTYPE] = { .get = meta_int_pkttype }, [TCF_META_ID_PKTLEN] = { .get = meta_int_pktlen }, [TCF_META_ID_DATALEN] = { .get = meta_int_datalen }, From kaber@trash.net Wed Mar 9 15:58:04 2005 Received: with ECARTIS (v1.0.0; list netdev); Wed, 09 Mar 2005 15:58:09 -0800 (PST) Received: from kaber.coreworks.de ([62.206.217.67]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j29Nw1LQ008072 for ; Wed, 9 Mar 2005 15:58:04 -0800 Received: from localhost ([127.0.0.1]) by kaber.coreworks.de with esmtp (Exim 4.50) id 1D9B3s-0003zu-TL; Thu, 10 Mar 2005 00:57:56 +0100 Message-ID: <422F8D84.8010103@trash.net> Date: Thu, 10 Mar 2005 00:57:56 +0100 From: Patrick McHardy User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.7.5) Gecko/20050106 Debian/1.7.5-1 X-Accept-Language: en MIME-Version: 1.0 To: Michal Vanco CC: netdev@oss.sgi.com Subject: Re: 2.6.11 on AMD64 traps References: <200503081900.18686.vanco@satro.sk> <200503092217.01106.vanco@satro.sk> <422F8649.8050707@trash.net> <200503100050.05582.vanco@satro.sk> In-Reply-To: <200503100050.05582.vanco@satro.sk> Content-Type: multipart/mixed; boundary="------------050607000507010902070700" X-Virus-Scanned: ClamAV 0.83/757/Tue Mar 8 15:14:36 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 2788 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: kaber@trash.net Precedence: bulk X-list: netdev Content-Length: 4323 Lines: 171 This is a multi-part message in MIME format. --------------050607000507010902070700 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Michal Vanco wrote: > On Thursday 10 March 2005 00:27, Patrick McHardy wrote: > >>And here it is. Could you redo your timing-test with this patch please? > > Wonderfull: > > # time ip route show | wc -l; time netstat -rn | wc -l > 155991 > > real 0m1.110s > user 0m0.441s > sys 0m1.100s > 155991 > > real 0m1.435s > user 0m1.026s > sys 0m0.436s > > It seems that netlink is still little bit faster than /proc, but it doesn't > make any sense in case like this. The system time is higher with netlink. It also repeatedly needs to skip over the entries, its just not as bad as with seq_file because more entries are dumped at once. dumping over netlink could be improved in a simlar way, but there is no room in netlink_callback->args for the pointers and the genid. > Will this patch be included in future kernels? I hope so. Dave, are you fine with making /proc more efficient than netlink ? :) Regards Patrick --------------050607000507010902070700 Content-Type: text/plain; name="x" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="x" # This is a BitKeeper generated diff -Nru style patch. # # ChangeSet # 2005/03/10 00:07:21+01:00 kaber@coreworks.de # [IPV4]: Speed up sequential reading of /proc/net/route # # Cacheing the current position reduces complexity from O(n^2) # to O(n). # # Signed-off-by: Patrick McHardy # # net/ipv4/fib_hash.c # 2005/03/10 00:07:11+01:00 kaber@coreworks.de +22 -1 # [IPV4]: Speed up sequential reading of /proc/net/route # # Cacheing the current position reduces complexity from O(n^2) # to O(n). # # Signed-off-by: Patrick McHardy # diff -Nru a/net/ipv4/fib_hash.c b/net/ipv4/fib_hash.c --- a/net/ipv4/fib_hash.c 2005-03-10 00:07:43 +01:00 +++ b/net/ipv4/fib_hash.c 2005-03-10 00:07:43 +01:00 @@ -93,6 +93,7 @@ } static DEFINE_RWLOCK(fib_hash_lock); +static unsigned int fib_hash_genid; #define FZ_MAX_DIVISOR ((PAGE_SIZE<fz_hashmask = new_hashmask; fz->fz_divisor = new_divisor; fn_rebuild_zone(fz, old_ht, old_divisor); + fib_hash_genid++; write_unlock_bh(&fib_hash_lock); fz_hash_free(old_ht, old_divisor); @@ -236,6 +238,7 @@ table->fn_zones[i]->fz_next = fz; } table->fn_zones[z] = fz; + fib_hash_genid++; write_unlock_bh(&fib_hash_lock); return fz; } @@ -451,6 +454,7 @@ fa->fa_scope = r->rtm_scope; state = fa->fa_state; fa->fa_state &= ~FA_S_ACCESSED; + fib_hash_genid++; write_unlock_bh(&fib_hash_lock); fib_release_info(fi_drop); @@ -515,6 +519,7 @@ fib_insert_node(fz, new_f); list_add_tail(&new_fa->fa_list, (fa ? &fa->fa_list : &f->fn_alias)); + fib_hash_genid++; write_unlock_bh(&fib_hash_lock); if (new_f) @@ -600,6 +605,7 @@ hlist_del(&f->fn_hash); kill_fn = 1; } + fib_hash_genid++; write_unlock_bh(&fib_hash_lock); if (fa->fa_state & FA_S_ACCESSED) @@ -637,6 +643,7 @@ hlist_del(&f->fn_hash); kill_f = 1; } + fib_hash_genid++; write_unlock_bh(&fib_hash_lock); fn_free_alias(fa); @@ -801,6 +808,9 @@ struct hlist_head *hash_head; struct fib_node *fn; struct fib_alias *fa; + loff_t pos; + unsigned int genid; + int valid; }; static struct fib_alias *fib_get_first(struct seq_file *seq) @@ -812,6 +822,9 @@ iter->hash_head = NULL; iter->fn = NULL; iter->fa = NULL; + iter->pos = 0; + iter->genid = fib_hash_genid; + iter->valid = 1; for (iter->zone = table->fn_zone_list; iter->zone; iter->zone = iter->zone->fz_next) { @@ -916,12 +929,20 @@ } } out: + iter->pos++; return fa; } static struct fib_alias *fib_get_idx(struct seq_file *seq, loff_t pos) { - struct fib_alias *fa = fib_get_first(seq); + struct fib_iter_state *iter = seq->private; + struct fib_alias *fa; + + if (iter->valid && pos >= iter->pos && iter->genid == fib_hash_genid) { + fa = iter->fa; + pos -= iter->pos; + } else + fa = fib_get_first(seq); if (fa) while (pos && (fa = fib_get_next(seq))) --------------050607000507010902070700-- From shemminger@osdl.org Wed Mar 9 16:03:26 2005 Received: with ECARTIS (v1.0.0; list netdev); Wed, 09 Mar 2005 16:03:32 -0800 (PST) Received: from smtp.osdl.org (fire.osdl.org [65.172.181.4]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j2A03QpA008904 for ; Wed, 9 Mar 2005 16:03:26 -0800 Received: from shell0.pdx.osdl.net (fw.osdl.org [65.172.181.6]) by smtp.osdl.org (8.12.8/8.12.8) with ESMTP id j2A03Cqi011051 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO); Wed, 9 Mar 2005 16:03:13 -0800 Received: from dxpl.pdx.osdl.net (dxpl.pdx.osdl.net [172.20.1.103]) by shell0.pdx.osdl.net (8.13.1/8.11.6) with ESMTP id j2A03CaM031093; Wed, 9 Mar 2005 16:03:12 -0800 Date: Wed, 9 Mar 2005 16:03:30 -0800 From: Stephen Hemminger To: Thomas Graf Cc: Ben Greear , "David S. Miller" , Andi Kleen , baruch@ev-en.org, netdev@oss.sgi.com Subject: Re: netif_rx packet dumping Message-ID: <20050309160330.2f9688e1@dxpl.pdx.osdl.net> In-Reply-To: <20050309235728.GV31837@postel.suug.ch> References: <20050303123811.4d934249@dxpl.pdx.osdl.net> <42278122.6000000@ev-en.org> <20050303133659.0d224e61.davem@davemloft.net> <42278554.2090902@ev-en.org> <20050303135718.2e1a0170.davem@davemloft.net> <422DC7CE.2040800@ev-en.org> <20050308100902.24b67b2f.davem@davemloft.net> <422DEE85.5010302@candelatech.com> <20050309235728.GV31837@postel.suug.ch> Organization: Open Source Development Lab X-Mailer: Sylpheed-Claws 1.0.1 (GTK+ 1.2.10; x86_64-unknown-linux-gnu) X-Face: &@E+xe?c%:&e4D{>f1O<&U>2qwRREG5!}7R4;D<"NO^UI2mJ[eEOA2*3>(`Th.yP,VDPo9$ /`~cw![cmj~~jWe?AHY7D1S+\}5brN0k*NE?pPh_'_d>6;XGG[\KDRViCfumZT3@[ Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Received-SPF: pass (domain of shemminger@osdl.org designates 65.172.181.6 as permitted sender) X-MIMEDefang-Filter: osdl$Revision: 1.104 $ X-Scanned-By: MIMEDefang 2.36 X-Virus-Scanned: ClamAV 0.83/757/Tue Mar 8 15:14:36 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 2789 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: shemminger@osdl.org Precedence: bulk X-list: netdev Content-Length: 426 Lines: 9 On Thu, 10 Mar 2005 00:57:28 +0100 Thomas Graf wrote: > > Of course...this might be things for 2.7 since lots of modules will probably > > be accessing these fields. Maybe to get started we could add macros to grab > > the flags and such so that when we finally do collapse things into a single > > flags field the external code doesn't have to know or care? Their may never be a 2.7, don't wait that long. From hadi@cyberus.ca Wed Mar 9 16:12:08 2005 Received: with ECARTIS (v1.0.0; list netdev); Wed, 09 Mar 2005 16:12:13 -0800 (PST) Received: from mx04.cybersurf.com (mx04.cybersurf.com [209.197.145.108]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j2A0C7rq009542 for ; Wed, 9 Mar 2005 16:12:08 -0800 Received: from mail.cyberus.ca ([209.197.145.21]) by mx01.cybersurf.com with esmtp (Exim 4.30) id 1D9BHZ-0002WH-Da for netdev@oss.sgi.com; Wed, 09 Mar 2005 19:12:05 -0500 Received: from [24.103.99.32] (helo=[10.0.0.9]) by mail.cyberus.ca with esmtp (Exim 4.20) id 1D9BH5-0000aA-32; Wed, 09 Mar 2005 19:11:35 -0500 Subject: RE: Do you know the TCP stack? (127.x.x.x routing) From: jamal Reply-To: hadi@cyberus.ca To: Steve Iribarne Cc: Henrik Nordstrom , Martin Mares , Zdenek Radouch , Eran Mann , Thomas Graf , Andi Kleen , netdev@oss.sgi.com, linux-net@vger.kernel.org In-Reply-To: References: Content-Type: text/plain Organization: jamalopolous Message-Id: <1110413490.1110.42.camel@jzny.localdomain> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.2.2 Date: 09 Mar 2005 19:11:30 -0500 Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV 0.83/757/Tue Mar 8 15:14:36 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 2790 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: hadi@cyberus.ca Precedence: bulk X-list: netdev Content-Length: 569 Lines: 17 On Wed, 2005-03-09 at 16:57, Steve Iribarne wrote: > There it is. I'm not going to spend anymore time on this, and neither > should you. Like I said, I've been doing this for a darn long time, and > I have, as yet, to see anyone who can make this problem just work. > Other than the way I did it. (I along with many others) > Lets end this thread - we are clearly never gonna get to a consensus. Whoever asked the question on how to expose loopback got their answer and you say you are not pushing the patch - so we are all one big happy family. cheers, jamal From lunz@reflexsecurity.com Wed Mar 9 16:23:57 2005 Received: with ECARTIS (v1.0.0; list netdev); Wed, 09 Mar 2005 16:24:00 -0800 (PST) Received: from crown.reflexsecurity.com (crown.reflexsecurity.com [69.15.40.52]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j2A0NuwD013616 for ; Wed, 9 Mar 2005 16:23:56 -0800 Received: from knob.localnet ([192.168.0.104]) by crown.reflexsecurity.com with smtp (Exim 3.35 #1 (Debian)) id 1D9BSz-00021V-00; Wed, 09 Mar 2005 19:23:53 -0500 Received: (nullmailer pid 14933 invoked by uid 1000); Thu, 10 Mar 2005 00:23:51 -0000 Date: Wed, 9 Mar 2005 19:23:51 -0500 From: Jason Lunz To: Boian Bonev Cc: netdev@oss.sgi.com, linux-net@vger.kernel.org Subject: Re: Do you know the TCP stack? (127.x.x.x routing) Message-ID: <20050310002351.GE16930@knob.localnet> References: <20050309235122.7541.qmail@orange.bonev.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20050309235122.7541.qmail@orange.bonev.com> User-Agent: Mutt/1.5.6+20040907i X-Virus-Scanned: ClamAV 0.83/757/Tue Mar 8 15:14:36 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 2791 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: lunz@falooley.org Precedence: bulk X-list: netdev Content-Length: 957 Lines: 21 On Thu, Mar 10, 2005 at 1:51AM +0200, Boian Bonev wrote: > you can do that but you omit the interface addresses - suppose ext net > is 10.20.10.1/24, internal is 10.10.10.1/24, no matter what routing > policies and rules you put, both interface ips will be visible from > both interfaces. What do you mean by "visible"? If you're referring to arp, the arp sysctls are probably adequate, and there's arpfilter if not. > now imagine you have another external net 10.30.10.1/24 and customer > wants to route e.g. 10.10.0.0/16 from 10.20.10.1/24 via 10.30.10.5... > at least host 10.10.10.1 will not route but arrive locally to your > blade host Not if you take 10.10.10.1 out of the "local" routing table, and policy route that traffic only through tables that don't consider 10.10.10.1 local. I'm not saying it's trivial, but if you set your rules up right, you can make some packets be routed by *completely different routing tables* than others. Jason From hadi@cyberus.ca Wed Mar 9 16:31:04 2005 Received: with ECARTIS (v1.0.0; list netdev); Wed, 09 Mar 2005 16:31:08 -0800 (PST) Received: from mx01.cybersurf.com (mx01.cybersurf.com [209.197.145.104]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j2A0V3eW014216 for ; Wed, 9 Mar 2005 16:31:04 -0800 Received: from mail.cyberus.ca ([209.197.145.21]) by mx01.cybersurf.com with esmtp (Exim 4.30) id 1D9BZn-000642-QP for netdev@oss.sgi.com; Wed, 09 Mar 2005 17:30:55 -0700 Received: from [24.103.99.32] (helo=[10.0.0.9]) by mail.cyberus.ca with esmtp (Exim 4.20) id 1D9BZs-0003Qt-7Z; Wed, 09 Mar 2005 19:31:00 -0500 Subject: Re: bridge between ppp and ethernet - 1 IP address and assign it to another host From: jamal Reply-To: hadi@cyberus.ca To: remco@virtu.nl Cc: netdev@oss.sgi.com, ahu@ds9a.nl In-Reply-To: References: Content-Type: text/plain Organization: jamalopolous Message-Id: <1110414655.1109.56.camel@jzny.localdomain> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.2.2 Date: 09 Mar 2005 19:30:56 -0500 Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV 0.83/757/Tue Mar 8 15:14:36 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 2792 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: hadi@cyberus.ca Precedence: bulk X-list: netdev Content-Length: 1406 Lines: 43 nice solution but maybe challenging to get to work with braindead windoz machines. My thinking is if you have to use windoz then you probably wanna hide everything from them - which may require kernel hacking (I think it is worth it ;->). cheers, jamal On Wed, 2005-03-09 at 15:01, Remco van Mook wrote: > I've been toying with the suggestion to do something with routing table 0 to > accomplish this, and I can report it works, standard 2.6.10 kernel. Here's how > I did it: > > Assuming a linux system, connected to a local network 172.16.0.0/24, own > address 172.16.0.13, 'ppp' ip address to be assigned to a system that has > ip address 172.16.0.4 > > On the box that establishes the PPP connection: > 1) establish ppp connection, get IP address, say 192.168.0.2 > 2) ip route del local 192.168.0.2 > 3) ip route add 192.168.0.2 via 172.16.0.4 > > On the other box, 172.16.0.4: > > 1) ip addr add 192.168.0.2 dev eth0 > 2) ip route add 0/0 via 172.16.0.13 > > I didn't bother assigning the IP address for the other box dynamically; that > might still pose a challenge - outside the scope of netdev IMHO. > > Optionally you might want to SNAT outbound traffic on the PPP interface to > enforce the correct IP address. Of course the solution doesn't actually > 'bridge' the traffic, you get another visible hop, but the effect is almost > the same. > > Kind regards, > > Remco van Mook > From cramerj@intel.com Wed Mar 9 16:36:00 2005 Received: with ECARTIS (v1.0.0; list netdev); Wed, 09 Mar 2005 16:36:05 -0800 (PST) Received: from orsfmr003.jf.intel.com (fmr18.intel.com [134.134.136.17]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j2A0a0BO015197 for ; Wed, 9 Mar 2005 16:36:00 -0800 Received: from orsfmr100.jf.intel.com (orsfmr100.jf.intel.com [10.7.209.16]) by orsfmr003.jf.intel.com (8.12.10/8.12.10/d: major-outer.mc,v 1.1 2004/09/17 17:50:56 root Exp $) with ESMTP id j2A0Zrfg020539; Thu, 10 Mar 2005 00:35:53 GMT Received: from orsmsxvs041.jf.intel.com (orsmsxvs041.jf.intel.com [192.168.65.54]) by orsfmr100.jf.intel.com (8.12.10/8.12.10/d: major-inner.mc,v 1.2 2004/09/17 18:05:01 root Exp $) with SMTP id j2A0Zrpg020524; Thu, 10 Mar 2005 00:35:53 GMT Received: from orsmsx331.amr.corp.intel.com ([192.168.65.56]) by orsmsxvs041.jf.intel.com (SAVSMTP 3.1.7.47) with SMTP id M2005030916355207955 ; Wed, 09 Mar 2005 16:35:52 -0800 Received: from orsmsx405.amr.corp.intel.com ([192.168.65.46]) by orsmsx331.amr.corp.intel.com with Microsoft SMTPSVC(6.0.3790.211); Wed, 9 Mar 2005 16:35:48 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Subject: RE: ethtool -d no longer works for e1000 Date: Wed, 9 Mar 2005 16:35:47 -0800 Message-ID: <76FA8CF8F1F53240BB5B962A3385A5800256F787@orsmsx405> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: ethtool -d no longer works for e1000 Thread-Index: AcUlAbLuSvfhASemSfikF1cIghcqcwABfYLg From: "cramerj" To: "Ben Greear" , "Jon Mason" Cc: "Ganesh Venkatesan" , X-OriginalArrivalTime: 10 Mar 2005 00:35:48.0653 (UTC) FILETIME=[1AEBEDD0:01C52509] X-Scanned-By: MIMEDefang 2.44 X-Virus-Scanned: ClamAV 0.83/757/Tue Mar 8 15:14:36 2005 on oss.sgi.com X-Virus-Status: Clean Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by oss.sgi.com id j2A0a0BO015197 X-archive-position: 2793 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: cramerj@intel.com Precedence: bulk X-list: netdev Content-Length: 1611 Lines: 51 Ah! Yes, if you're running ethtool 1.8, then this was an issue (or rather, an annoyance) in e1000.c where we would default to mac_type = e1000_undefined for any newer hardware. Continuous updates to this file for every piece of hardware we released got old pretty quick. We've since changed the default mac_type to e1000_82543, which has a basic set of registers that haven't changed with each hardware release. And although the e1000_82546 mac_type exists, it isn't yet being assigned to the 82546GB hardware (again, see e1000.c), thus the error. Long story short, an updated ethtool should do the trick. Thanks, -Jeb > -----Original Message----- > From: netdev-bounce@oss.sgi.com [mailto:netdev-bounce@oss.sgi.com] On > Behalf Of Ben Greear > Sent: Wednesday, March 09, 2005 3:42 PM > To: Jon Mason > Cc: Ganesh Venkatesan; netdev@oss.sgi.com > Subject: Re: ethtool -d no longer works for e1000 > > Ben Greear wrote: > > Jon Mason wrote: > > > >> I don't see this problem at all on my 2.6.11-rc4-mm1 kernel (Athlon64 > >> proc). > > > > > > I think I see the problem. ethtool -d eth0 works for me, > > but ethtool -d eth1 does not, even with both are e1000 > > NICs. It appears it cannot handle reading the second NIC for > > some reason? > > Errr, my bad. The problem is more that the dual-port pro/1000 NICs > don't seem to work, but the built-in e1000s do. > > The chipset that does not work correctly is: 82546GB > > The NICs with chipset: 82541EI seem to work just fine. > > Ben > > > -- > Ben Greear > Candela Technologies Inc http://www.candelatech.com > From davem@davemloft.net Wed Mar 9 16:43:59 2005 Received: with ECARTIS (v1.0.0; list netdev); Wed, 09 Mar 2005 16:44:04 -0800 (PST) Received: from cheetah.davemloft.net (mail@dsl027-180-174.sfo1.dsl.speakeasy.net [216.27.180.174]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j2A0hxFc016191 for ; Wed, 9 Mar 2005 16:43:59 -0800 Received: from localhost ([127.0.0.1] helo=cheetah.davemloft.net ident=davem) by cheetah.davemloft.net with smtp (Exim 3.36 #1 (Debian)) id 1D9BlY-0002Id-00; Wed, 09 Mar 2005 16:43:04 -0800 Date: Wed, 9 Mar 2005 16:43:04 -0800 From: "David S. Miller" To: Patrick McHardy Cc: vanco@satro.sk, netdev@oss.sgi.com Subject: Re: 2.6.11 on AMD64 traps Message-Id: <20050309164304.5902e558.davem@davemloft.net> In-Reply-To: <422F8D84.8010103@trash.net> References: <200503081900.18686.vanco@satro.sk> <200503092217.01106.vanco@satro.sk> <422F8649.8050707@trash.net> <200503100050.05582.vanco@satro.sk> <422F8D84.8010103@trash.net> X-Mailer: Sylpheed version 1.0.1 (GTK+ 1.2.10; sparc-unknown-linux-gnu) X-Face: "_;p5u5aPsO,_Vsx"^v-pEq09'CU4&Dc1$fQExov$62l60cgCc%FnIwD=.UF^a>?5'9Kn[;433QFVV9M..2eN.@4ZWPGbdi<=?[:T>y?SD(R*-3It"Vj:)"dP Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV 0.83/757/Tue Mar 8 15:14:36 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 2794 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: davem@davemloft.net Precedence: bulk X-list: netdev Content-Length: 315 Lines: 10 On Thu, 10 Mar 2005 00:57:56 +0100 Patrick McHardy wrote: > > Will this patch be included in future kernels? > > I hope so. Dave, are you fine with making /proc more efficient than > netlink ? :) No objection :-) I'll hit this on my next pass over my 2.6.x backlog which should start tonight. From romieu@fr.zoreil.com Wed Mar 9 16:49:01 2005 Received: with ECARTIS (v1.0.0; list netdev); Wed, 09 Mar 2005 16:49:07 -0800 (PST) Received: from fr.zoreil.com (electric-eye.fr.zoreil.com [213.41.134.224]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j2A0n0if016996 for ; Wed, 9 Mar 2005 16:49:00 -0800 Received: from electric-eye.fr.zoreil.com (localhost.localdomain [127.0.0.1]) by fr.zoreil.com (8.13.1/8.12.1) with ESMTP id j2A0jUEX013976; Thu, 10 Mar 2005 01:45:30 +0100 Received: (from romieu@localhost) by electric-eye.fr.zoreil.com (8.13.1/8.13.1/Submit) id j2A0jPIG013975; Thu, 10 Mar 2005 01:45:25 +0100 Date: Thu, 10 Mar 2005 01:45:25 +0100 From: Francois Romieu To: Andi Kleen Cc: Stephen Hemminger , netdev@oss.sgi.com Subject: Re: [PATCH 1/5] r8169: auto detect 32-bit slot Message-ID: <20050310004525.GA12735@electric-eye.fr.zoreil.com> References: <20050309112925.7f7900ab@dxpl.pdx.osdl.net> <20050309214023.GA9502@electric-eye.fr.zoreil.com> <20050309135530.5c5c80b6@dxpl.pdx.osdl.net> <20050309230809.GC9502@electric-eye.fr.zoreil.com> <20050309232024.GC63395@muc.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20050309232024.GC63395@muc.de> User-Agent: Mutt/1.4.1i X-Organisation: Land of Sunshine Inc. X-Virus-Scanned: ClamAV 0.83/757/Tue Mar 8 15:14:36 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 2795 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: romieu@fr.zoreil.com Precedence: bulk X-list: netdev Content-Length: 1120 Lines: 29 Andi Kleen : [...] > The concept of "64bit systems" is useless here anyways. Even on a 32bit > system with highmem like i386 you can get >32bit addresses to deal > with. One usecase for that would be sendfile() out of user space. > This is widely used these days. The combination "32 bit system with weird addressing mode + r8169 adapter" has accounted for 0 bug/success report so far and I do not know a single tester for it anyway. Whence my narrow-minded view of the issue :o) [...] > Again are you sure it depends on 64bit slots? Normally 64bit slots > only offer more bandwidth, but the address protocol is the same > as 32bit and both support DAC in the same way. I do not know. The 8169 includes a register which tells (various things +) the bus width. Without further documentation, I do not see how the relevance of this register can be established/discarded if the aforementioned test-cases are not experienced. [...] > You really should forget about amd64 or not, all that counts is > sizeof(dma_addr_t) (assuming the on-board 8169 is wired correctly, be it on-board or not, yes) -- Ueimor From jdmason@us.ibm.com Wed Mar 9 16:54:42 2005 Received: with ECARTIS (v1.0.0; list netdev); Wed, 09 Mar 2005 16:54:47 -0800 (PST) Received: from e32.co.us.ibm.com (e32.co.us.ibm.com [32.97.110.130]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j2A0sgqw017764 for ; Wed, 9 Mar 2005 16:54:42 -0800 Received: from westrelay03.boulder.ibm.com (westrelay03.boulder.ibm.com [9.17.195.12]) by e32.co.us.ibm.com (8.12.10/8.12.9) with ESMTP id j2A0sa5j264528 for ; Wed, 9 Mar 2005 19:54:36 -0500 Received: from d03av01.boulder.ibm.com (d03av01.boulder.ibm.com [9.17.195.167]) by westrelay03.boulder.ibm.com (8.12.10/NCO/VER6.6) with ESMTP id j2A0sab0118450 for ; Wed, 9 Mar 2005 17:54:36 -0700 Received: from d03av01.boulder.ibm.com (loopback [127.0.0.1]) by d03av01.boulder.ibm.com (8.12.11/8.12.11) with ESMTP id j2A0sZhX003751 for ; Wed, 9 Mar 2005 17:54:36 -0700 Received: from sig-9-49-138-99.mts.ibm.com (sig-9-49-138-99.mts.ibm.com [9.49.138.99]) by d03av01.boulder.ibm.com (8.12.11/8.12.11) with ESMTP id j2A0sZ4e003746; Wed, 9 Mar 2005 17:54:35 -0700 From: Jon Mason Organization: IBM To: "cramerj" Subject: Re: ethtool -d no longer works for e1000 Date: Wed, 9 Mar 2005 18:54:34 -0600 User-Agent: KMail/1.7.2 Cc: "Ben Greear" , "Ganesh Venkatesan" , netdev@oss.sgi.com References: <76FA8CF8F1F53240BB5B962A3385A5800256F787@orsmsx405> In-Reply-To: <76FA8CF8F1F53240BB5B962A3385A5800256F787@orsmsx405> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200503091854.34466.jdmason@us.ibm.com> X-Virus-Scanned: ClamAV 0.83/757/Tue Mar 8 15:14:36 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 2796 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: jdmason@us.ibm.com Precedence: bulk X-list: netdev Content-Length: 792 Lines: 19 On Wednesday 09 March 2005 06:35 pm, cramerj wrote: > Ah! Yes, if you're running ethtool 1.8, then this was an issue (or > rather, an annoyance) in e1000.c where we would default to mac_type = > e1000_undefined for any newer hardware. Continuous updates to this file > for every piece of hardware we released got old pretty quick. We've > since changed the default mac_type to e1000_82543, which has a basic set > of registers that haven't changed with each hardware release. And > although the e1000_82546 mac_type exists, it isn't yet being assigned to > the 82546GB hardware (again, see e1000.c), thus the error. > > Long story short, an updated ethtool should do the trick. > > Thanks, > -Jeb Ah, I am running ethtool 3 on a 82545 chip, that is probably why mine works. Thanks, Jon From hadi@znyx.com Wed Mar 9 17:08:04 2005 Received: with ECARTIS (v1.0.0; list netdev); Wed, 09 Mar 2005 17:08:08 -0800 (PST) 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 j2A1842s018888 for ; Wed, 9 Mar 2005 17:08:04 -0800 Received: from [127.0.0.1] ([208.2.156.2]) by lotus.znyx.com (Lotus Domino Release 5.0.11) with ESMTP id 2005030917072536:6394 ; Wed, 9 Mar 2005 17:07:25 -0800 Subject: Re: dummy as IMQ replacement From: Jamal Hadi Salim Reply-To: hadi@znyx.com To: Remus Cc: netdev@oss.sgi.com, Nguyen Dinh Nam , Andre Tomt , syrius.ml@no-log.org, Andy Furniss , Damion de Soto In-Reply-To: <1110379135.1091.143.camel@jzny.localdomain> References: <1107123123.8021.80.camel@jzny.localdomain> <0fcf01c5077f$579e4b80$6e69690a@RIMAS> <1107174142.8021.121.camel@jzny.localdomain> <00c301c524b4$938cd240$6e69690a@RIMAS> <1110379135.1091.143.camel@jzny.localdomain> Organization: ZNYX Networks Message-Id: <1110416767.1111.76.camel@jzny.localdomain> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.2.2 Date: 09 Mar 2005 20:06:07 -0500 X-MIMETrack: Itemize by SMTP Server on Lotus/Znyx(Release 5.0.11 |July 24, 2002) at 03/09/2005 05:07:25 PM, Serialize by Router on Lotus/Znyx(Release 5.0.11 |July 24, 2002) at 03/09/2005 05:09:20 PM, Serialize complete at 03/09/2005 05:09:20 PM Content-Type: multipart/mixed; boundary="=-XPicLd45+Kfs/6uczpzT" X-Virus-Scanned: ClamAV 0.83/757/Tue Mar 8 15:14:36 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 2797 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: hadi@znyx.com Precedence: bulk X-list: netdev Content-Length: 1077 Lines: 49 --=-XPicLd45+Kfs/6uczpzT Content-Transfer-Encoding: 7bit Content-Type: text/plain Hi Remus, Please try this patch on top of latest iproute2. Credit to Patrick for spoting it. I dont know when or who made this change - in any case it doesnt matter if it works for you. cheers, On Wed, 2005-03-09 at 09:38, jamal wrote: > I have to go to work - so wont have time to look at this for sometime. > Maybe some of the netfilter folks like Patrick can solve it for you > before i get back. > > cheers, > jamal > --=-XPicLd45+Kfs/6uczpzT Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=ipt-p Content-Type: text/plain; name=ipt-p; charset=ISO-8859-1 --- iproute2-a/tc/m_ipt.c 2005/03/10 00:59:38 1.1 +++ iproute2-b/tc/m_ipt.c 2005/03/10 01:00:05 @@ -72,7 +72,6 @@ static unsigned int global_option_offset = 0; #define OPTION_OFFSET 256 -#if 0 /* no clue why register match is within targets figure out later. Talk to Harald -- JHS */ @@ -91,7 +90,6 @@ t_list = me; } -#endif void exit_tryhelp(int status) --=-XPicLd45+Kfs/6uczpzT-- From jamie@shareable.org Wed Mar 9 17:48:14 2005 Received: with ECARTIS (v1.0.0; list netdev); Wed, 09 Mar 2005 17:48:18 -0800 (PST) Received: from mail.shareable.org (mail.shareable.org [81.29.64.88]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j2A1mDgB020479 for ; Wed, 9 Mar 2005 17:48:14 -0800 Received: from mail.shareable.org (localhost [127.0.0.1]) by mail.shareable.org (8.12.8/8.12.8) with ESMTP id j2A1lwmf013340; Thu, 10 Mar 2005 01:47:58 GMT Received: (from jamie@localhost) by mail.shareable.org (8.12.8/8.12.8/Submit) id j2A1lvh7013338; Thu, 10 Mar 2005 01:47:57 GMT Date: Thu, 10 Mar 2005 01:47:57 +0000 From: Jamie Lokier To: Henrik Nordstrom Cc: jamal , Martin Mares , Zdenek Radouch , Steve Iribarne , Eran Mann , Thomas Graf , Andi Kleen , netdev@oss.sgi.com, linux-net@vger.kernel.org Subject: Re: Do you know the TCP stack? (127.x.x.x routing) Message-ID: <20050310014757.GC12990@mail.shareable.org> References: <1110288879.1050.167.camel@jzny.localdomain> <20050308135134.GA20607@atrey.karlin.mff.cuni.cz> <1110290300.1050.190.camel@jzny.localdomain> <20050308140301.GC20607@atrey.karlin.mff.cuni.cz> <1110291470.1043.211.camel@jzny.localdomain> <1110316631.1084.57.camel@jzny.localdomain> <1110371962.1088.90.camel@jzny.localdomain> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.1i X-Virus-Scanned: ClamAV 0.83/757/Tue Mar 8 15:14:36 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 2798 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: jamie@shareable.org Precedence: bulk X-list: netdev Content-Length: 1223 Lines: 28 Henrik Nordstrom wrote: > If Linux could manage different IP stacks per interface this would not be > a problem, but as it is today the same IP stack is used for all interfaces > making dual homing (not routing) a bit troublesome when the same addresses > may be in both networks.. Indeed, I have exactly the same problem with a device that must simultaneously connect to: - the local customer-site ethernet - the local customer-site 802.11 wireless and auto-configure both interfaces using DHCP to connect to hosts on the internet as best as possible through all available interfaces. There is absolutely no guarantee that I won't see a network or even address conflict on the two interfaces, as they may be _separate_ networks each behind a NAT to the outside world over ADSL. In fact, it's quite likely that DHCP for each interface will provide a 192.168.0.0/24 address, as that seems to be the typical setup of both kinds of ADSL NAT router... Any suggestion of asking customer-site to specially configure their network rather defeats the point, which is a device which automatically tries available connections, using DHCP, and routes its traffic over whichever one works best at any time. -- Jamie From mcgrof@ruslug.rutgers.edu Wed Mar 9 18:50:57 2005 Received: with ECARTIS (v1.0.0; list netdev); Wed, 09 Mar 2005 18:51:00 -0800 (PST) Received: from ruslug.rutgers.edu (ruslug.rutgers.edu [128.6.24.131]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j2A2obvG022289 for ; Wed, 9 Mar 2005 18:50:57 -0800 Received: by ruslug.rutgers.edu (Postfix, from userid 503) id 6E20EF9928; Wed, 9 Mar 2005 21:50:36 -0500 (EST) Date: Wed, 9 Mar 2005 21:50:36 -0500 To: Jeff Garzik Cc: Netdev , "Luis R. Rodriguez" Subject: wireless 2.6 work Message-ID: <20050310025036.GE17854@ruslug.rutgers.edu> Mail-Followup-To: Jeff Garzik , Netdev Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="qtZFehHsKgwS5rPz" Content-Disposition: inline User-Agent: Mutt/1.3.28i X-Operating-System: 2.4.18-1-686 Organization: Rutgers University Student Linux Users Group From: mcgrof@ruslug.rutgers.edu (Luis R. Rodriguez) X-Virus-Scanned: ClamAV 0.83/757/Tue Mar 8 15:14:36 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 2799 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: mcgrof@ruslug.rutgers.edu Precedence: bulk X-list: netdev Content-Length: 1699 Lines: 54 --qtZFehHsKgwS5rPz Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Jeff, I'm sick off the low activiity and slow support on wireless we have. I know you're busy so I wanted to offer my help in helping around work on wireless-2.6, now that I have time after work, and before I commit myself to anything else. It's a bit suicidal, but oh well. Oh yeah and I'll also start using bitkeeper due to the recent clarifications on the license of its usage. I'll willing to review as much patches as I have to and also hopefully write documentation on writing new wireless drivers. That said, if I can be of any assistance, where what you like me to start on? Here's what's on my agenda so far: * Help cleanup new ralink driver, start using ieee802211 and get into wirel= ess-2.6. * Push prism54's new WPA and WDS support into wireless-2.6 * Start seeing what I can use off of ieee80211 for prism54, clean it, and move to wireless-2.6 * Start incorporating WPA through wpa_supplicant onto as many drivers * Start standardizing all things a bit, as bitched about and well pointed o= ut by Dan Williams * Listen to Jouni, he's the man Ideally I think Jouni should be the guy doing all this but I think he just has no time. Luis --=20 GnuPG Key fingerprint =3D 113F B290 C6D2 0251 4D84 A34A 6ADD 4937 E20A 525E --qtZFehHsKgwS5rPz Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.4 (GNU/Linux) iD8DBQFCL7X8at1JN+IKUl4RAvk3AJ0QQqWpNIwDCdsWYCS6hiXHuq1vlgCfVWW9 L+uWdSVstIk5JZ3618V9sAw= =PhGp -----END PGP SIGNATURE----- --qtZFehHsKgwS5rPz-- From mcgrof@ruslug.rutgers.edu Wed Mar 9 19:02:27 2005 Received: with ECARTIS (v1.0.0; list netdev); Wed, 09 Mar 2005 19:02:31 -0800 (PST) Received: from ruslug.rutgers.edu (ruslug.rutgers.edu [128.6.24.131]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j2A32Qi3023090 for ; Wed, 9 Mar 2005 19:02:27 -0800 Received: by ruslug.rutgers.edu (Postfix, from userid 503) id 65C98F9928; Wed, 9 Mar 2005 22:02:26 -0500 (EST) Date: Wed, 9 Mar 2005 22:02:26 -0500 To: Jeff Garzik , Netdev Cc: "Luis R. Rodriguez" Subject: Re: wireless 2.6 work Message-ID: <20050310030226.GH17854@ruslug.rutgers.edu> Mail-Followup-To: Jeff Garzik , Netdev References: <20050310025036.GE17854@ruslug.rutgers.edu> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="pQhZXvAqiZgbeUkD" Content-Disposition: inline In-Reply-To: <20050310025036.GE17854@ruslug.rutgers.edu> User-Agent: Mutt/1.3.28i X-Operating-System: 2.4.18-1-686 Organization: Rutgers University Student Linux Users Group From: mcgrof@ruslug.rutgers.edu (Luis R. Rodriguez) X-Virus-Scanned: ClamAV 0.83/757/Tue Mar 8 15:14:36 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 2800 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: mcgrof@ruslug.rutgers.edu Precedence: bulk X-list: netdev Content-Length: 875 Lines: 31 --pQhZXvAqiZgbeUkD Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Wed, Mar 09, 2005 at 09:50:36PM -0500, Luis R. Rodriguez wrote: > I'll willing to review as much patches as I have to and also hopefully > write documentation on writing new wireless drivers. That said, if I can > be of any assistance, where what you like me to start on? Besides on my horrible grammar, that is. /me makes note of ispell "i" on mutt --=20 GnuPG Key fingerprint =3D 113F B290 C6D2 0251 4D84 A34A 6ADD 4937 E20A 525E --pQhZXvAqiZgbeUkD Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.4 (GNU/Linux) iD8DBQFCL7jCat1JN+IKUl4RAt2OAJ99NBwDq3Ss69JTDrQ02Wl8Nri57ACglXLE MxT2tNcNH3ADFhQRYAERgSE= =rP2j -----END PGP SIGNATURE----- --pQhZXvAqiZgbeUkD-- From jdmason@us.ibm.com Wed Mar 9 20:14:24 2005 Received: with ECARTIS (v1.0.0; list netdev); Wed, 09 Mar 2005 20:14:30 -0800 (PST) Received: from e35.co.us.ibm.com (e35.co.us.ibm.com [32.97.110.133]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j2A4EIcS025014 for ; Wed, 9 Mar 2005 20:14:24 -0800 Received: from westrelay03.boulder.ibm.com (westrelay03.boulder.ibm.com [9.17.195.12]) by e35.co.us.ibm.com (8.12.10/8.12.9) with ESMTP id j2A4ECLg599928 for ; Wed, 9 Mar 2005 23:14:12 -0500 Received: from d03av01.boulder.ibm.com (d03av01.boulder.ibm.com [9.17.195.167]) by westrelay03.boulder.ibm.com (8.12.10/NCO/VER6.6) with ESMTP id j2A4ECb0171198 for ; Wed, 9 Mar 2005 21:14:12 -0700 Received: from d03av01.boulder.ibm.com (loopback [127.0.0.1]) by d03av01.boulder.ibm.com (8.12.11/8.12.11) with ESMTP id j2A4EBhM004160 for ; Wed, 9 Mar 2005 21:14:12 -0700 Received: from sig-9-49-138-99.mts.ibm.com (sig-9-49-138-99.mts.ibm.com [9.49.138.99]) by d03av01.boulder.ibm.com (8.12.11/8.12.11) with ESMTP id j2A4EBdq004154; Wed, 9 Mar 2005 21:14:11 -0700 From: Jon Mason Organization: IBM To: Francois Romieu Subject: Re: [PATCH 1/5] r8169: auto detect 32-bit slot Date: Wed, 9 Mar 2005 22:14:10 -0600 User-Agent: KMail/1.7.2 Cc: Andi Kleen , Stephen Hemminger , netdev@oss.sgi.com References: <20050309112925.7f7900ab@dxpl.pdx.osdl.net> <200503091608.59122.jdmason@us.ibm.com> <20050309223943.GB9502@electric-eye.fr.zoreil.com> In-Reply-To: <20050309223943.GB9502@electric-eye.fr.zoreil.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200503092214.10348.jdmason@us.ibm.com> X-Virus-Scanned: ClamAV 0.83/757/Tue Mar 8 15:14:36 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 2801 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: jdmason@us.ibm.com Precedence: bulk X-list: netdev Content-Length: 475 Lines: 15 [...] > The content of the Config2 register could be interesting. I did a quick test and my 2 adapters (integrated and stand-alone) fail the DAC test. + if ((sizeof(dma_addr_t) > 4) && + (RTL_R32(Config2) & (1<<3)) && + !pci_set_dma_mask(pdev, DMA_64BIT_MASK)) { For the above, I get 8 0 1 respectively. So, my adapters fail because of the 64bit slot test. If you like, I can try my stand-alone adapter in a 64bit slot of a ppc64 system. From jdmason@us.ibm.com Wed Mar 9 20:22:00 2005 Received: with ECARTIS (v1.0.0; list netdev); Wed, 09 Mar 2005 20:22:04 -0800 (PST) Received: from e33.co.us.ibm.com (e33.co.us.ibm.com [32.97.110.131]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j2A4Lu1V029119 for ; Wed, 9 Mar 2005 20:22:00 -0800 Received: from d03relay05.boulder.ibm.com (d03relay05.boulder.ibm.com [9.17.195.107]) by e33.co.us.ibm.com (8.12.10/8.12.9) with ESMTP id j2A4Lo4I615822 for ; Wed, 9 Mar 2005 23:21:50 -0500 Received: from d03av01.boulder.ibm.com (d03av01.boulder.ibm.com [9.17.195.167]) by d03relay05.boulder.ibm.com (8.12.10/NCO/VER6.6) with ESMTP id j2A4LoZJ178804 for ; Wed, 9 Mar 2005 21:21:50 -0700 Received: from d03av01.boulder.ibm.com (loopback [127.0.0.1]) by d03av01.boulder.ibm.com (8.12.11/8.12.11) with ESMTP id j2A4LnRQ011901 for ; Wed, 9 Mar 2005 21:21:49 -0700 Received: from sig-9-49-138-99.mts.ibm.com (sig-9-49-138-99.mts.ibm.com [9.49.138.99]) by d03av01.boulder.ibm.com (8.12.11/8.12.11) with ESMTP id j2A4LnsY011882; Wed, 9 Mar 2005 21:21:49 -0700 From: Jon Mason Organization: IBM To: Stephen Hemminger Subject: Re: [PATCH 5/5] r8169: ethtool hardware statistics support Date: Wed, 9 Mar 2005 22:21:48 -0600 User-Agent: KMail/1.7.2 Cc: Francois Romieu , netdev@oss.sgi.com References: <20050309113626.6708c93e@dxpl.pdx.osdl.net> <200503091537.30899.jdmason@us.ibm.com> <20050309135345.5efae9b6@dxpl.pdx.osdl.net> In-Reply-To: <20050309135345.5efae9b6@dxpl.pdx.osdl.net> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200503092221.48487.jdmason@us.ibm.com> X-Virus-Scanned: ClamAV 0.83/757/Tue Mar 8 15:14:36 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 2802 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: jdmason@us.ibm.com Precedence: bulk X-list: netdev Content-Length: 819 Lines: 23 On Wednesday 09 March 2005 03:53 pm, Stephen Hemminger wrote: > On Wed, 9 Mar 2005 15:37:30 -0600 > > Jon Mason wrote: > > Does this patch fix the problem of bogus statistics if the interface is > > down > > I see no problem when interface is down. It returns all zero's because > the device is reset on probe (and on shutdown). I can confirm that I see no statistic errors either. I believe the faulty code in Richard's patch was: + if (RTL_R32(StatsAddrLow) & DumpStats) + return; /* no stats - took too long */ Which returned before the stats were populated (leaving garbage). Since your patch lacks this, we see no problem. If this is true, there is probably a problem on 8139cp, which has a similar error path in its cp_get_ethtool_stats function. Thanks, Jon From davem@davemloft.net Wed Mar 9 20:29:48 2005 Received: with ECARTIS (v1.0.0; list netdev); Wed, 09 Mar 2005 20:29:53 -0800 (PST) Received: from cheetah.davemloft.net (mail@dsl027-180-174.sfo1.dsl.speakeasy.net [216.27.180.174]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j2A4TldX029715 for ; Wed, 9 Mar 2005 20:29:48 -0800 Received: from localhost ([127.0.0.1] helo=cheetah.davemloft.net ident=davem) by cheetah.davemloft.net with smtp (Exim 3.36 #1 (Debian)) id 1D9FHq-0003iO-00; Wed, 09 Mar 2005 20:28:38 -0800 Date: Wed, 9 Mar 2005 20:28:37 -0800 From: "David S. Miller" To: Bart De Schuymer Cc: netdev@oss.sgi.com, netfilter-devel@lists.netfilter.org, rusty@rustcorp.com.au, kaber@trash.net, snort2004@mail.ru, ak@suse.de, bridge@osdl.org, gandalf@wlug.westbo.se, dwmw2@infradead.org, shemminger@osdl.org Subject: Re: [PATCH/RFC] Reduce call chain length in netfilter (take 2) Message-Id: <20050309202837.1adca300.davem@davemloft.net> In-Reply-To: <1108314982.4662.2.camel@localhost.localdomain> References: <1108314982.4662.2.camel@localhost.localdomain> X-Mailer: Sylpheed version 1.0.1 (GTK+ 1.2.10; sparc-unknown-linux-gnu) X-Face: "_;p5u5aPsO,_Vsx"^v-pEq09'CU4&Dc1$fQExov$62l60cgCc%FnIwD=.UF^a>?5'9Kn[;433QFVV9M..2eN.@4ZWPGbdi<=?[:T>y?SD(R*-3It"Vj:)"dP Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV 0.83/757/Tue Mar 8 15:14:36 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 2803 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: davem@davemloft.net Precedence: bulk X-list: netdev Content-Length: 1232 Lines: 24 On Sun, 13 Feb 2005 18:16:21 +0100 Bart De Schuymer wrote: > This is a second try to fix the long chain call lengths in netfilter. > The difference with the previous patch is that I got rid of the extra > argument. I somehow didn't see it could be done without using the 'int > *ret2' argument. > > A comment on the number of arguments to nf_hook_slow: I don't think the > number of arguments should be decreased. For the bridge-nf code, f.e., > the indev argument does not equal (*pskb)->dev (this is an answer to a > question of Rusty in the old thread). > > A comment on the argument change of nf_hook_slow (sk_buff * to sk_buff > **) and the bad influence on tail call optimization possibilities. From > the discussion in the old thread it became clear that no tail call is > generated for the current code. So, I don't see why this is a reason not > to accept the patch. Furthermore, if gcc ever would become able of doing > the current code with a tail call, it should be very easy to change the > code back to the original. In the meantime, I think this patch is the > best known solution. I agree with your analysis of the situation and have applied your patch, thanks for keeping this going Bart. From davem@davemloft.net Wed Mar 9 20:37:14 2005 Received: with ECARTIS (v1.0.0; list netdev); Wed, 09 Mar 2005 20:37:19 -0800 (PST) Received: from cheetah.davemloft.net (mail@dsl027-180-174.sfo1.dsl.speakeasy.net [216.27.180.174]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j2A4bDbp030338 for ; Wed, 9 Mar 2005 20:37:13 -0800 Received: from localhost ([127.0.0.1] helo=cheetah.davemloft.net ident=davem) by cheetah.davemloft.net with smtp (Exim 3.36 #1 (Debian)) id 1D9FPB-0003kr-00; Wed, 09 Mar 2005 20:36:13 -0800 Date: Wed, 9 Mar 2005 20:36:12 -0800 From: "David S. Miller" To: Wensong Zhang Cc: netdev@oss.sgi.com Subject: Re: [PATCH] [IPVS] Fixed that the WRR scheduler works correctly when server is updated or overloaded Message-Id: <20050309203612.6228f0a8.davem@davemloft.net> In-Reply-To: References: X-Mailer: Sylpheed version 1.0.1 (GTK+ 1.2.10; sparc-unknown-linux-gnu) X-Face: "_;p5u5aPsO,_Vsx"^v-pEq09'CU4&Dc1$fQExov$62l60cgCc%FnIwD=.UF^a>?5'9Kn[;433QFVV9M..2eN.@4ZWPGbdi<=?[:T>y?SD(R*-3It"Vj:)"dP Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV 0.83/757/Tue Mar 8 15:14:36 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 2804 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: davem@davemloft.net Precedence: bulk X-list: netdev Content-Length: 282 Lines: 9 On Tue, 15 Feb 2005 01:00:38 +0800 (CST) Wensong Zhang wrote: > Here is the patch to make the WRR scheduler work correctly when server is > updated with new weight or marked overloaded. Please check and apply it to > kernel 2.6. Applied, thanks Wensong. From davem@davemloft.net Wed Mar 9 20:39:01 2005 Received: with ECARTIS (v1.0.0; list netdev); Wed, 09 Mar 2005 20:39:05 -0800 (PST) Received: from cheetah.davemloft.net (mail@dsl027-180-174.sfo1.dsl.speakeasy.net [216.27.180.174]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j2A4cxbh030796 for ; Wed, 9 Mar 2005 20:39:01 -0800 Received: from localhost ([127.0.0.1] helo=cheetah.davemloft.net ident=davem) by cheetah.davemloft.net with smtp (Exim 3.36 #1 (Debian)) id 1D9FQa-0003lC-00; Wed, 09 Mar 2005 20:37:40 -0800 Date: Wed, 9 Mar 2005 20:37:40 -0800 From: "David S. Miller" To: Wensong Zhang Cc: netdev@oss.sgi.com, ja@ssi.bg Subject: Re: [PATCH] [IPVS] update mark->cw in the WRR scheduler while service is updated Message-Id: <20050309203740.5e8d2a0a.davem@davemloft.net> In-Reply-To: References: X-Mailer: Sylpheed version 1.0.1 (GTK+ 1.2.10; sparc-unknown-linux-gnu) X-Face: "_;p5u5aPsO,_Vsx"^v-pEq09'CU4&Dc1$fQExov$62l60cgCc%FnIwD=.UF^a>?5'9Kn[;433QFVV9M..2eN.@4ZWPGbdi<=?[:T>y?SD(R*-3It"Vj:)"dP Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV 0.83/757/Tue Mar 8 15:14:36 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 2805 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: davem@davemloft.net Precedence: bulk X-list: netdev Content-Length: 295 Lines: 8 On Tue, 15 Feb 2005 16:03:10 +0800 (CST) Wensong Zhang wrote: > This is the patch for the WRR scheduler in IPVS of kernel 2.4. It's a fix > for better performance when server weight is adjusted. Please check and > apply it to kernel 2.4. Also applied, thanks Wensong. From davem@davemloft.net Wed Mar 9 20:41:30 2005 Received: with ECARTIS (v1.0.0; list netdev); Wed, 09 Mar 2005 20:41:35 -0800 (PST) Received: from cheetah.davemloft.net (mail@dsl027-180-174.sfo1.dsl.speakeasy.net [216.27.180.174]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j2A4fUkj031363 for ; Wed, 9 Mar 2005 20:41:30 -0800 Received: from localhost ([127.0.0.1] helo=cheetah.davemloft.net ident=davem) by cheetah.davemloft.net with smtp (Exim 3.36 #1 (Debian)) id 1D9FSr-0003oD-00; Wed, 09 Mar 2005 20:40:01 -0800 Date: Wed, 9 Mar 2005 20:40:01 -0800 From: "David S. Miller" To: Herbert Xu Cc: yoshfuji@linux-ipv6.org, netdev@oss.sgi.com Subject: Re: [IPV4] Make loopback idev stick around Message-Id: <20050309204001.5b5997ad.davem@davemloft.net> In-Reply-To: <20050216101245.GA32341@gondor.apana.org.au> References: <20050205053030.GA17412@gondor.apana.org.au> <20050205053532.GA17474@gondor.apana.org.au> <20050215144121.702767c5.davem@davemloft.net> <20050216101245.GA32341@gondor.apana.org.au> X-Mailer: Sylpheed version 1.0.1 (GTK+ 1.2.10; sparc-unknown-linux-gnu) X-Face: "_;p5u5aPsO,_Vsx"^v-pEq09'CU4&Dc1$fQExov$62l60cgCc%FnIwD=.UF^a>?5'9Kn[;433QFVV9M..2eN.@4ZWPGbdi<=?[:T>y?SD(R*-3It"Vj:)"dP Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV 0.83/757/Tue Mar 8 15:14:36 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 2806 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: davem@davemloft.net Precedence: bulk X-list: netdev Content-Length: 302 Lines: 11 On Wed, 16 Feb 2005 21:12:45 +1100 Herbert Xu wrote: > Let's also clean up loopback's ipv6 structure in addrconf_cleanup > even though it never happens currently :) > > Signed-off-by: Herbert Xu Seems sane to me. Applied, thanks Herbert. From davem@davemloft.net Wed Mar 9 20:50:57 2005 Received: with ECARTIS (v1.0.0; list netdev); Wed, 09 Mar 2005 20:51:02 -0800 (PST) Received: from cheetah.davemloft.net (mail@dsl027-180-174.sfo1.dsl.speakeasy.net [216.27.180.174]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j2A4oq8i032081 for ; Wed, 9 Mar 2005 20:50:56 -0800 Received: from localhost ([127.0.0.1] helo=cheetah.davemloft.net ident=davem) by cheetah.davemloft.net with smtp (Exim 3.36 #1 (Debian)) id 1D9FcJ-0003ri-00; Wed, 09 Mar 2005 20:49:47 -0800 Date: Wed, 9 Mar 2005 20:49:47 -0800 From: "David S. Miller" To: Patrick McHardy Cc: herbert@gondor.apana.org.au, netdev@oss.sgi.com Subject: Re: [XFRM]: Fix ICMP tempsel Message-Id: <20050309204947.2618d278.davem@davemloft.net> In-Reply-To: <4217266F.6090700@trash.net> References: <4217266F.6090700@trash.net> X-Mailer: Sylpheed version 1.0.1 (GTK+ 1.2.10; sparc-unknown-linux-gnu) X-Face: "_;p5u5aPsO,_Vsx"^v-pEq09'CU4&Dc1$fQExov$62l60cgCc%FnIwD=.UF^a>?5'9Kn[;433QFVV9M..2eN.@4ZWPGbdi<=?[:T>y?SD(R*-3It"Vj:)"dP Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV 0.83/757/Tue Mar 8 15:14:36 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 2807 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: davem@davemloft.net Precedence: bulk X-list: netdev Content-Length: 567 Lines: 15 On Sat, 19 Feb 2005 12:43:43 +0100 Patrick McHardy wrote: > The selector ports are initialized to fl_ip_sport/fl_ip_dport instead > of xfrm_flowi_sport(fl)/xfrm_flowi_dport(fl). This is wrong for ICMP, > type and code should be stored in sport and dport, in struct flowi both > are contained in fl_ip_sport. This resulted in a long thread, many newer versions of the patch trying to clean this up in other ways, but then we determined that this original patch was the best and safest fix for now. So I applied this first patch. Thanks everyone. From davem@davemloft.net Wed Mar 9 21:15:08 2005 Received: with ECARTIS (v1.0.0; list netdev); Wed, 09 Mar 2005 21:15:15 -0800 (PST) Received: from cheetah.davemloft.net (mail@dsl027-180-174.sfo1.dsl.speakeasy.net [216.27.180.174]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j2A5F8vN000804 for ; Wed, 9 Mar 2005 21:15:08 -0800 Received: from localhost ([127.0.0.1] helo=cheetah.davemloft.net ident=davem) by cheetah.davemloft.net with smtp (Exim 3.36 #1 (Debian)) id 1D9Fz1-00042x-00; Wed, 09 Mar 2005 21:13:15 -0800 Date: Wed, 9 Mar 2005 21:13:15 -0800 From: "David S. Miller" To: Herbert Xu Cc: kuznet@ms2.inr.ac.ru, shemminger@osdl.org, mostrows@speakeasy.net, netdev@oss.sgi.com Subject: Re: pppoe and receive checksum offload Message-Id: <20050309211315.2dc86d44.davem@davemloft.net> In-Reply-To: <20050301010424.GA14851@gondor.apana.org.au> References: <20050224155906.73890361@dxpl.pdx.osdl.net> <20050228113106.GA3268@gondor.apana.org.au> <20050228113938.GA3393@gondor.apana.org.au> <20050228140401.GA27937@yakov.inr.ac.ru> <20050301010424.GA14851@gondor.apana.org.au> X-Mailer: Sylpheed version 1.0.1 (GTK+ 1.2.10; sparc-unknown-linux-gnu) X-Face: "_;p5u5aPsO,_Vsx"^v-pEq09'CU4&Dc1$fQExov$62l60cgCc%FnIwD=.UF^a>?5'9Kn[;433QFVV9M..2eN.@4ZWPGbdi<=?[:T>y?SD(R*-3It"Vj:)"dP Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV 0.83/757/Tue Mar 8 15:14:36 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 2808 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: davem@davemloft.net Precedence: bulk X-list: netdev Content-Length: 626 Lines: 18 On Tue, 1 Mar 2005 12:04:24 +1100 Herbert Xu wrote: > On Mon, Feb 28, 2005 at 05:04:01PM +0300, Alexey Kuznetsov wrote: > > > > ppp_input() could do the same thing. It does not, hence suggested patch > > is corrrect minimal solution. > > Agreed. We should use Stephen's patch for 2.6.11. > > For 2.6.12, does this patch look sane? As usual, I'd love to get > some better names for the new helper functions. I'm not so picky about the names. Patch applied, thanks Herbert :-) If Stephen cares, he can try to submit his patch for 2.6.11.x via stable@kernel.org, I have no problem with that. From davem@davemloft.net Wed Mar 9 21:15:45 2005 Received: with ECARTIS (v1.0.0; list netdev); Wed, 09 Mar 2005 21:15:49 -0800 (PST) Received: from cheetah.davemloft.net (mail@dsl027-180-174.sfo1.dsl.speakeasy.net [216.27.180.174]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j2A5Fi8J000954 for ; Wed, 9 Mar 2005 21:15:45 -0800 Received: from localhost ([127.0.0.1] helo=cheetah.davemloft.net ident=davem) by cheetah.davemloft.net with smtp (Exim 3.36 #1 (Debian)) id 1D9G0a-00043n-00; Wed, 09 Mar 2005 21:14:52 -0800 Date: Wed, 9 Mar 2005 21:14:52 -0800 From: "David S. Miller" To: Stephen Hemminger Cc: netdev@oss.sgi.com Subject: Re: [PATCH] remove dead extern's in netdevice.h Message-Id: <20050309211452.40ed9d8e.davem@davemloft.net> In-Reply-To: <20050302105902.72f2b983@dxpl.pdx.osdl.net> References: <20050302105902.72f2b983@dxpl.pdx.osdl.net> X-Mailer: Sylpheed version 1.0.1 (GTK+ 1.2.10; sparc-unknown-linux-gnu) X-Face: "_;p5u5aPsO,_Vsx"^v-pEq09'CU4&Dc1$fQExov$62l60cgCc%FnIwD=.UF^a>?5'9Kn[;433QFVV9M..2eN.@4ZWPGbdi<=?[:T>y?SD(R*-3It"Vj:)"dP Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV 0.83/757/Tue Mar 8 15:14:36 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 2809 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: davem@davemloft.net Precedence: bulk X-list: netdev Content-Length: 292 Lines: 11 On Wed, 2 Mar 2005 10:59:02 -0800 Stephen Hemminger wrote: > The following definitions are historical relics. > > Signed-off-by: Stephen Hemminger Good catch, I missed this when we ripped out the hw flow control stuff. Applied, thanks Stephen. From davem@davemloft.net Wed Mar 9 21:17:33 2005 Received: with ECARTIS (v1.0.0; list netdev); Wed, 09 Mar 2005 21:17:37 -0800 (PST) Received: from cheetah.davemloft.net (mail@dsl027-180-174.sfo1.dsl.speakeasy.net [216.27.180.174]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j2A5HTFt001747 for ; Wed, 9 Mar 2005 21:17:33 -0800 Received: from localhost ([127.0.0.1] helo=cheetah.davemloft.net ident=davem) by cheetah.davemloft.net with smtp (Exim 3.36 #1 (Debian)) id 1D9G2C-00044A-00; Wed, 09 Mar 2005 21:16:32 -0800 Date: Wed, 9 Mar 2005 21:16:32 -0800 From: "David S. Miller" To: Sridhar Samudrala Cc: nhorman@redhat.com, netdev@oss.sgi.com, lksctp-developers@lists.sourceforge.net Subject: Re: [Patch] sctp: add receive buffer accounting to sctp (fwd) Message-Id: <20050309211632.6f70fe41.davem@davemloft.net> In-Reply-To: References: X-Mailer: Sylpheed version 1.0.1 (GTK+ 1.2.10; sparc-unknown-linux-gnu) X-Face: "_;p5u5aPsO,_Vsx"^v-pEq09'CU4&Dc1$fQExov$62l60cgCc%FnIwD=.UF^a>?5'9Kn[;433QFVV9M..2eN.@4ZWPGbdi<=?[:T>y?SD(R*-3It"Vj:)"dP Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV 0.83/757/Tue Mar 8 15:14:36 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 2810 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: davem@davemloft.net Precedence: bulk X-list: netdev Content-Length: 362 Lines: 12 On Thu, 3 Mar 2005 00:32:12 +0530 (IST) Sridhar Samudrala wrote: > Please apply the following SCTP patch submitted by Neil. > > Signed-off-by: Sridhar Samudrala This patch doesn't apply cleanly right now. Could you please cook up a fresh version, and also supply a 2.4.x version of the patch as well? Thanks a lot Sridhar. From davem@davemloft.net Wed Mar 9 21:22:44 2005 Received: with ECARTIS (v1.0.0; list netdev); Wed, 09 Mar 2005 21:22:49 -0800 (PST) Received: from cheetah.davemloft.net (mail@dsl027-180-174.sfo1.dsl.speakeasy.net [216.27.180.174]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j2A5Mgg0002878 for ; Wed, 9 Mar 2005 21:22:44 -0800 Received: from localhost ([127.0.0.1] helo=cheetah.davemloft.net ident=davem) by cheetah.davemloft.net with smtp (Exim 3.36 #1 (Debian)) id 1D9G7F-00045G-00; Wed, 09 Mar 2005 21:21:45 -0800 Date: Wed, 9 Mar 2005 21:21:45 -0800 From: "David S. Miller" To: yoshfuji@linux-ipv6.org Cc: tgraf@suug.ch, netdev@oss.sgi.com Subject: Re: [PATCH 1/2] [NEIGH]: rtnetlink neighbour cleanups Message-Id: <20050309212145.6835d667.davem@davemloft.net> In-Reply-To: <20050304.114550.47830081.yoshfuji@linux-ipv6.org> References: <20050304022940.GB31837@postel.suug.ch> <20050304.114550.47830081.yoshfuji@linux-ipv6.org> X-Mailer: Sylpheed version 1.0.1 (GTK+ 1.2.10; sparc-unknown-linux-gnu) X-Face: "_;p5u5aPsO,_Vsx"^v-pEq09'CU4&Dc1$fQExov$62l60cgCc%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 X-Virus-Scanned: ClamAV 0.83/757/Tue Mar 8 15:14:36 2005 on oss.sgi.com X-Virus-Status: Clean Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by oss.sgi.com id j2A5Mgg0002878 X-archive-position: 2811 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: davem@davemloft.net Precedence: bulk X-list: netdev Content-Length: 360 Lines: 11 On Fri, 04 Mar 2005 11:45:50 +0900 (JST) YOSHIFUJI Hideaki / $B5HF#1QL@(B wrote: > In article <20050304022940.GB31837@postel.suug.ch> (at Fri, 4 Mar 2005 03:29:40 +0100), Thomas Graf says: > > > Signed-off-by: Thomas Graf > Acked-by: Hideaki YOSHIFUJI Applied, thanks. From davem@davemloft.net Wed Mar 9 21:23:34 2005 Received: with ECARTIS (v1.0.0; list netdev); Wed, 09 Mar 2005 21:23:38 -0800 (PST) Received: from cheetah.davemloft.net (mail@dsl027-180-174.sfo1.dsl.speakeasy.net [216.27.180.174]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j2A5NY1q003248 for ; Wed, 9 Mar 2005 21:23:34 -0800 Received: from localhost ([127.0.0.1] helo=cheetah.davemloft.net ident=davem) by cheetah.davemloft.net with smtp (Exim 3.36 #1 (Debian)) id 1D9G89-00045c-00; Wed, 09 Mar 2005 21:22:41 -0800 Date: Wed, 9 Mar 2005 21:22:41 -0800 From: "David S. Miller" To: Thomas Graf Cc: netdev@oss.sgi.com Subject: Re: [PATCH 2/2] [NEIGH]: Provide number of probes to userspace Message-Id: <20050309212241.251912d6.davem@davemloft.net> In-Reply-To: <20050304023121.GC31837@postel.suug.ch> References: <20050304023121.GC31837@postel.suug.ch> X-Mailer: Sylpheed version 1.0.1 (GTK+ 1.2.10; sparc-unknown-linux-gnu) X-Face: "_;p5u5aPsO,_Vsx"^v-pEq09'CU4&Dc1$fQExov$62l60cgCc%FnIwD=.UF^a>?5'9Kn[;433QFVV9M..2eN.@4ZWPGbdi<=?[:T>y?SD(R*-3It"Vj:)"dP Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV 0.83/757/Tue Mar 8 15:14:36 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 2812 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: davem@davemloft.net Precedence: bulk X-list: netdev Content-Length: 230 Lines: 8 On Fri, 4 Mar 2005 03:31:21 +0100 Thomas Graf wrote: > Provides number of probes done so far to userspace, quite useful for debugging. > > Signed-off-by: Thomas Graf Also applied, thanks Thomas. From jgarzik@pobox.com Wed Mar 9 21:37:32 2005 Received: with ECARTIS (v1.0.0; list netdev); Wed, 09 Mar 2005 21:37:39 -0800 (PST) Received: from parcelfarce.linux.theplanet.co.uk (IDENT:93@parcelfarce.linux.theplanet.co.uk [195.92.249.252]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j2A5bVZC004228 for ; Wed, 9 Mar 2005 21:37:31 -0800 Received: from [69.134.152.124] (helo=[10.10.10.88]) by parcelfarce.linux.theplanet.co.uk with asmtp (TLSv1:AES256-SHA:256) (Exim 4.33) id 1D9GMT-00041A-Fx; Thu, 10 Mar 2005 05:37:30 +0000 Message-ID: <422FDD07.9060808@pobox.com> Date: Thu, 10 Mar 2005 00:37:11 -0500 From: Jeff Garzik User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.3) Gecko/20040922 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Netdev CC: Linux Kernel , Andrew Morton Subject: netdev-2.6 queue updated Content-Type: multipart/mixed; boundary="------------020605000903000002010804" X-Virus-Scanned: ClamAV 0.83/757/Tue Mar 8 15:14:36 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 2813 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: jgarzik@pobox.com Precedence: bulk X-list: netdev Content-Length: 7113 Lines: 182 This is a multi-part message in MIME format. --------------020605000903000002010804 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit All the stuff that was waiting for Linus has been sent. Here's what's sitting around in the netdev-2.6 to "stew" for a bit: * wireless-2.6 tree (bk://gkernel.bkbits.net/wireless-2.6) * 8139cp updates * starfire update * 8139too iomap conversion * natsemi long/short cable option (no longer needed?) * new skge driver from Stephen Hemminger BK URL, Patch URL, and changelog attached. Note that the patch is diff'd against 2.6.11-bk6, which will not exist until four hours after this email is sent. Jeff --------------020605000903000002010804 Content-Type: text/plain; name="netdev-2.6.txt" Content-Transfer-Encoding: 8bit Content-Disposition: inline; filename="netdev-2.6.txt" BK users: bk pull bk://gkernel.bkbits.net/netdev-2.6 Patch: http://www.kernel.org/pub/linux/kernel/people/jgarzik/patchkits/2.6/2.6.11-bk6-netdev1.patch.bz2 This will update the following files: drivers/net/wireless/ieee802_11.h | 78 MAINTAINERS | 7 drivers/net/8139cp.c | 100 drivers/net/8139too.c | 194 - drivers/net/Kconfig | 12 drivers/net/Makefile | 1 drivers/net/natsemi.c | 11 drivers/net/skge.c | 3385 ++++++++++++++++++++++ drivers/net/skge.h | 3005 +++++++++++++++++++ drivers/net/starfire.c | 142 drivers/net/starfire_firmware.h | 346 ++ drivers/net/wireless/Kconfig | 2 drivers/net/wireless/Makefile | 2 drivers/net/wireless/atmel.c | 62 drivers/net/wireless/hostap/Kconfig | 104 drivers/net/wireless/hostap/Makefile | 8 drivers/net/wireless/hostap/hostap.c | 1205 +++++++ drivers/net/wireless/hostap/hostap.h | 57 drivers/net/wireless/hostap/hostap_80211.h | 107 drivers/net/wireless/hostap/hostap_80211_rx.c | 1080 +++++++ drivers/net/wireless/hostap/hostap_80211_tx.c | 522 +++ drivers/net/wireless/hostap/hostap_ap.c | 3259 +++++++++++++++++++++ drivers/net/wireless/hostap/hostap_ap.h | 272 + drivers/net/wireless/hostap/hostap_common.h | 556 +++ drivers/net/wireless/hostap/hostap_config.h | 86 drivers/net/wireless/hostap/hostap_crypt.c | 167 + drivers/net/wireless/hostap/hostap_crypt.h | 50 drivers/net/wireless/hostap/hostap_crypt_ccmp.c | 486 +++ drivers/net/wireless/hostap/hostap_crypt_tkip.c | 696 ++++ drivers/net/wireless/hostap/hostap_crypt_wep.c | 281 + drivers/net/wireless/hostap/hostap_cs.c | 785 +++++ drivers/net/wireless/hostap/hostap_download.c | 761 +++++ drivers/net/wireless/hostap/hostap_hw.c | 3607 +++++++++++++++++++++++ drivers/net/wireless/hostap/hostap_info.c | 469 +++ drivers/net/wireless/hostap/hostap_ioctl.c | 3624 ++++++++++++++++++++++++ drivers/net/wireless/hostap/hostap_pci.c | 452 ++ drivers/net/wireless/hostap/hostap_plx.c | 611 ++++ drivers/net/wireless/hostap/hostap_proc.c | 466 +++ drivers/net/wireless/hostap/hostap_wlan.h | 1071 +++++++ drivers/net/wireless/orinoco.c | 11 drivers/net/wireless/wl3501.h | 4 include/linux/pci_ids.h | 3 include/net/ieee80211.h | 887 +++++ include/net/ieee80211_crypt.h | 86 net/Kconfig | 2 net/Makefile | 1 net/ieee80211/Kconfig | 67 net/ieee80211/Makefile | 11 net/ieee80211/ieee80211_crypt.c | 259 + net/ieee80211/ieee80211_crypt_ccmp.c | 470 +++ net/ieee80211/ieee80211_crypt_tkip.c | 708 ++++ net/ieee80211/ieee80211_crypt_wep.c | 272 + net/ieee80211/ieee80211_module.c | 268 + net/ieee80211/ieee80211_rx.c | 1206 +++++++ net/ieee80211/ieee80211_tx.c | 448 ++ net/ieee80211/ieee80211_wx.c | 471 +++ 56 files changed, 32947 insertions(+), 356 deletions(-) through these ChangeSets: : o ieee80211 subsystem : o wireless-2.6 cleanup : o [netdrvr 8139cp] add PCI ID Adrian Bunk: o net/ieee80211/Kconfig: don't describe what gets selected Alexander Viro: o hostap __user annotations Felipe Damasio: o 8139cp net driver: add MODULE_VERSION François Romieu: o ieee80211: offset_in_page() removal o ieee80211: C99 initialization for eap_types o ieee80211: failure of ieee80211_crypto_init() o 8139cp: SG support fixes Greg Kroah-Hartman: o net drivers: convert pci_dev->slot_name usage to pci_name() Jeff Garzik: o [netdrvr starfire] Add GPL'd firmware, remove compat code o [wireless hostap] update for new pci_save_state() o [netdrvr 8139cp] TSO support Joshua Kwan: o hostap: fix Kconfig typos and missing select CRYPTO Jouni Malinen: o Host AP: Replaced MODULE_PARM with module_param* o Host AP: Replaced direct dev->priv references with netdev_priv(dev) o Host AP: Updated to use Linux wireless extensions v17 o Host AP: pci_register_driver() return value changes o Host AP: Fix netif_carrier_off() in non-client modes o Host AP: Fix PRISM2_IO_DEBUG o Host AP: Use void __iomem * with {read,write}{b,w} o Host AP: Fix card enabling after firmware download o Host AP: Do not bridge packets to unauthorized ports o Host AP: Fix compilation with PRISM2_NO_STATION_MODES defined o Host AP: Prevent STAs from associating using AP address o Host AP: Fix hw address changing for wifi# interface o Host AP: Remove ioctl debug messages o Host AP: Ignore (Re)AssocResp messages silently o Host AP: Fix interface packet counters o Host AP: Disable EAPOL TX/RX debug messages o fix hostap crypto bugs o Add HostAP wireless driver Olaf Kirch: o natsemi: long cable, short cable Pekka Enberg: o 8139too: use iomap for pio/mmio Steffen Klassert: o 8139cp - add netpoll support Stephen Hemminger: o skge: change driver version o skge: fix race with receive interrupt and NAPI o skge: use lockless transmit o skge: interrupt coalecsing related fixes o skge: only allow tx/rx csum on Yukon chipset o skge: use array for port irq masks o skge: use chip MIB stats for packet and byte counts o skge: simplify definition of wake on lan support o skge: suspend/resume related state management o skge: remove unneeded include's o skge: spelling and whitespace o skge: use PFX string o skge driver (0.5) o 8139cp - module_param --------------020605000903000002010804-- From util@deuroconsult.ro Wed Mar 9 22:54:23 2005 Received: with ECARTIS (v1.0.0; list netdev); Wed, 09 Mar 2005 22:54:34 -0800 (PST) Received: from webhosting.rdsbv.ro (webhosting.rdsbv.ro [213.157.185.164]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j2A6sGHq007094 for ; Wed, 9 Mar 2005 22:54:22 -0800 Received: from webhosting.rdsbv.ro (localhost [127.0.0.1]) by webhosting.rdsbv.ro (8.13.3/8.13.3) with ESMTP id j2A6mfkD029218 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 10 Mar 2005 08:48:41 +0200 Received: from localhost (util@localhost) by webhosting.rdsbv.ro (8.13.3/8.13.3/Submit) with ESMTP id j2A6mYAt029210; Thu, 10 Mar 2005 08:48:34 +0200 X-Authentication-Warning: webhosting.rdsbv.ro: util owned process doing -bs Date: Thu, 10 Mar 2005 08:48:34 +0200 (EET) From: "Catalin(ux aka Dino) BOIE" X-X-Sender: util@webhosting.rdsbv.ro To: Steve Iribarne cc: hadi@cyberus.ca, Henrik Nordstrom , Martin Mares , Zdenek Radouch , Eran Mann , Thomas Graf , Andi Kleen , netdev@oss.sgi.com, linux-net@vger.kernel.org Subject: RE: Do you know the TCP stack? (127.x.x.x routing) In-Reply-To: Message-ID: References: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Virus-Scanned: ClamAV 0.83/757/Tue Mar 8 15:14:36 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 2814 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: util@deuroconsult.ro Precedence: bulk X-list: netdev Content-Length: 1200 Lines: 28 > 1st bug: Customer had the same 10.100.xx.xx/24 net that I had and my > inter-system communication wouldn't work, because all my routes got > screwed up. (i.e the SNMP sub-agents couldn't talk with the master). > > 1st response to bug: Well can you use another network address range? > Customer response: Hell no. > > Solution to bug1: Easy, let the user configure the mgmt network ip > address. > Customers answer to bug1 solution: Get the hell out of here; you don't > do out-of-band mgmt. Do you know what a security risk this is for me? > Blah blah blah.... Even though all inter-chassis communication was done > securely, I couldn't convince them. I had a customer boot me out of his > office and boot our company out **because** of my design. Not a good > feeling. You say that a client will not allow you to use net 10. OK, but, the same client would not allow you to use 127/8 because they use it! What I'm saying is that 10.0.0.0/8 and 127.0.0.0/8 are the same. The customer can use them. You assume that the client will not use 127/8. Why? This is wrong. You can use it, the client can use it. --- Catalin(ux aka Dino) BOIE catab at deuroconsult.ro http://kernel.umbrella.ro/ From util@deuroconsult.ro Wed Mar 9 22:59:35 2005 Received: with ECARTIS (v1.0.0; list netdev); Wed, 09 Mar 2005 22:59:42 -0800 (PST) Received: from webhosting.rdsbv.ro (webhosting.rdsbv.ro [213.157.185.164]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j2A6xVx8007632 for ; Wed, 9 Mar 2005 22:59:33 -0800 Received: from webhosting.rdsbv.ro (localhost [127.0.0.1]) by webhosting.rdsbv.ro (8.13.3/8.13.3) with ESMTP id j2A6vV8S029844 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 10 Mar 2005 08:57:31 +0200 Received: from localhost (util@localhost) by webhosting.rdsbv.ro (8.13.3/8.13.3/Submit) with ESMTP id j2A6vUUG029839; Thu, 10 Mar 2005 08:57:30 +0200 X-Authentication-Warning: webhosting.rdsbv.ro: util owned process doing -bs Date: Thu, 10 Mar 2005 08:57:30 +0200 (EET) From: "Catalin(ux aka Dino) BOIE" X-X-Sender: util@webhosting.rdsbv.ro To: Matt Mackall cc: jamal , Zdenek Radouch , Henrik Nordstrom , Martin Mares , Eran Mann , Thomas Graf , Andi Kleen , netdev@oss.sgi.com, linux-net@vger.kernel.org Subject: Re: Do you know the TCP stack? (127.x.x.x routing) In-Reply-To: <20050309175209.GX3163@waste.org> Message-ID: References: <1110288879.1050.167.camel@jzny.localdomain> <20050308135134.GA20607@atrey.karlin.mff.cuni.cz> <1110290300.1050.190.camel@jzny.localdomain> <20050308140301.GC20607@atrey.karlin.mff.cuni.cz> <1110291470.1043.211.camel@jzny.localdomain> <1110316631.1084.57.camel@jzny.localdomain> <1110377889.1090.124.camel@jzny.localdomain> <20050309175209.GX3163@waste.org> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Virus-Scanned: ClamAV 0.83/757/Tue Mar 8 15:14:36 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 2815 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: util@deuroconsult.ro Precedence: bulk X-list: netdev Content-Length: 214 Lines: 10 > > Uh, why? The 127 packets never leave the "box". So you are allowed to use 127/8 but your client cannot break this rule. Why? --- Catalin(ux aka Dino) BOIE catab at deuroconsult.ro http://kernel.umbrella.ro/ From kumar.gala@freescale.com Wed Mar 9 23:30:08 2005 Received: with ECARTIS (v1.0.0; list netdev); Wed, 09 Mar 2005 23:30:13 -0800 (PST) Received: from de01egw02.freescale.net (de01egw02.freescale.net [192.88.165.103]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j2A7U86Q008750 for ; Wed, 9 Mar 2005 23:30:08 -0800 Received: from de01smr01.am.mot.com (de01smr01.freescale.net [10.208.0.31]) by de01egw02.freescale.net (8.12.11/de01egw02) with ESMTP id j2A7V7tA005068; Thu, 10 Mar 2005 00:31:07 -0700 (MST) Received: from [192.168.1.101] ([10.214.72.40]) by de01smr01.am.mot.com (8.13.1/8.13.0) with ESMTP id j2A7Vdxw020718; Thu, 10 Mar 2005 01:31:39 -0600 (CST) In-Reply-To: References: Mime-Version: 1.0 (Apple Message framework v619.2) Content-Type: text/plain; charset=ISO-8859-1; format=flowed Message-Id: <1047a05d13208f6f49df5590040d3c16@freescale.com> Cc: inuxppc-embedded List , Netdev From: Kumar Gala Subject: Re: [PATCH] gianfar: Update Marvell PHY name Date: Thu, 10 Mar 2005 01:30:02 -0600 To: Jeff Garzik X-Mailer: Apple Mail (2.619.2) X-Virus-Scanned: ClamAV 0.83/757/Tue Mar 8 15:14:36 2005 on oss.sgi.com X-Virus-Status: Clean Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by oss.sgi.com id j2A7U86Q008750 X-archive-position: 2816 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: kumar.gala@freescale.com Precedence: bulk X-list: netdev Content-Length: 1145 Lines: 36 Jeff, Just wondering if this got lost? Might be moot depending what likelihood of getting Andy's PHY Abstraction Layer changes into the kernel. - kumar On Mar 4, 2005, at 1:55 AM, Kumar Gala wrote: > Jeff, > > This patch updates the name identifier to list both of the Marvell PHYs > that are supported. > > Signed-off-by: Kumar Gala > > --- > diff -Nru a/drivers/net/gianfar_phy.c b/drivers/net/gianfar_phy.c > --- a/drivers/net/gianfar_phy.c 2005-03-02 14:20:27 -06:00 > +++ b/drivers/net/gianfar_phy.c 2005-03-02 14:20:27 -06:00 > @@ -572,7 +572,7 @@ >  static struct phy_info phy_info_marvell = { >         .phy_id         = 0x01410c00, >         .phy_id_mask    = 0xffffff00, > -       .name           = "Marvell 88E1101", > +       .name           = "Marvell 88E1101/88E1111", >         .features       = MII_GBIT_FEATURES, >         .config_aneg    = &marvell_config_aneg, >         .read_status    = &marvell_read_status, > _______________________________________________ > Linuxppc-embedded mailing list > Linuxppc-embedded@ozlabs.org > https://ozlabs.org/mailman/listinfo/linuxppc-embedded From ak@muc.de Thu Mar 10 00:33:11 2005 Received: with ECARTIS (v1.0.0; list netdev); Thu, 10 Mar 2005 00:33:15 -0800 (PST) Received: from colin2.muc.de (qmailr@colin2.muc.de [193.149.48.15]) by oss.sgi.com (8.13.0/8.13.0) with SMTP id j2A8XA3b014362 for ; Thu, 10 Mar 2005 00:33:11 -0800 Received: (qmail 690 invoked by uid 3709); 10 Mar 2005 08:33:09 -0000 Date: 10 Mar 2005 09:33:09 +0100 Date: Thu, 10 Mar 2005 09:33:09 +0100 From: Andi Kleen To: Thomas Graf Cc: Ben Greear , "David S. Miller" , baruch@ev-en.org, shemminger@osdl.org, netdev@oss.sgi.com Subject: Re: netif_rx packet dumping Message-ID: <20050310083309.GA510@muc.de> References: <20050303123811.4d934249@dxpl.pdx.osdl.net> <42278122.6000000@ev-en.org> <20050303133659.0d224e61.davem@davemloft.net> <42278554.2090902@ev-en.org> <20050303135718.2e1a0170.davem@davemloft.net> <422DC7CE.2040800@ev-en.org> <20050308100902.24b67b2f.davem@davemloft.net> <422DEE85.5010302@candelatech.com> <20050309235728.GV31837@postel.suug.ch> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20050309235728.GV31837@postel.suug.ch> User-Agent: Mutt/1.4.1i X-Virus-Scanned: ClamAV 0.83/757/Tue Mar 8 15:14:36 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 2817 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: ak@muc.de Precedence: bulk X-list: netdev Content-Length: 222 Lines: 7 > I attached a small patch below saving 4 bytes and leaving some room for > additional flags. The removal of security has indeed potential to break > external modules. And? The Linux kernel never had a stable ABI. -Andi From rmocius@auste.elnet.lt Thu Mar 10 01:18:38 2005 Received: with ECARTIS (v1.0.0; list netdev); Thu, 10 Mar 2005 01:18:44 -0800 (PST) Received: from mail01.mail.esat.net (mail01.mail.esat.net [193.120.142.6]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j2A9IbLg016520 for ; Thu, 10 Mar 2005 01:18:37 -0800 Received: from sachsen-adsl.adsl.esat.net (RIMAS) [193.120.73.6] by mail01.mail.esat.net with smtp id 1D9JoQ-0003fL-00; Thu, 10 Mar 2005 09:18:34 +0000 Message-ID: <025501c52552$2dbf87c0$6e69690a@RIMAS> From: "Remus" To: Cc: "jamal" , , "Nguyen Dinh Nam" , "Andre Tomt" , , "Andy Furniss" , "Damion de Soto" References: <1107123123.8021.80.camel@jzny.localdomain> <0fcf01c5077f$579e4b80$6e69690a@RIMAS> <1107174142.8021.121.camel@jzny.localdomain> <00c301c524b4$938cd240$6e69690a@RIMAS> <1110379135.1091.143.camel@jzny.localdomain> <1110416767.1111.76.camel@jzny.localdomain> Subject: Re: dummy as IMQ replacement Date: Thu, 10 Mar 2005 09:18:53 -0000 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=original Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.2180 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 X-Virus-Scanned: ClamAV 0.83/757/Tue Mar 8 15:14:36 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 2818 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: rmocius@auste.elnet.lt Precedence: bulk X-list: netdev Content-Length: 1342 Lines: 51 Hi Jamal, Thanks for the patch. That error is gone but I got a new error: ifconfig dummy0 up tc qdisc add dev eth2 ingress tc filter add dev eth2 parent ffff: protocol ip prio 10 u32 match u32 0 0 flowid 1:1 action ipt -j MARK --set-mark 1 action mirred egress redirect dev dummy0 iptables: calloc failed: Cannot allocate memory I use 2.6.11.2 kernel patched with your dummy patch, iptables 1.3.1 and the latest iproute2 patched with the pacth you sent yesterday. Regards Remus ----- Original Message ----- From: "Jamal Hadi Salim" To: "Remus" Cc: ; "Nguyen Dinh Nam" ; "Andre Tomt" ; ; "Andy Furniss" ; "Damion de Soto" Sent: Thursday, March 10, 2005 1:06 AM Subject: Re: dummy as IMQ replacement > Hi Remus, > > Please try this patch on top of latest iproute2. Credit to Patrick for > spoting it. I dont know when or who made this change - in any case it > doesnt matter if it works for you. > > cheers, > > On Wed, 2005-03-09 at 09:38, jamal wrote: > >> I have to go to work - so wont have time to look at this for sometime. >> Maybe some of the netfilter folks like Patrick can solve it for you >> before i get back. >> >> cheers, >> jamal >> > From hno@marasystems.com Thu Mar 10 02:10:16 2005 Received: with ECARTIS (v1.0.0; list netdev); Thu, 10 Mar 2005 02:10:23 -0800 (PST) Received: from filer.marasystems.com (marasystems.com [83.241.133.2]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j2AAAFZt018247 for ; Thu, 10 Mar 2005 02:10:16 -0800 Received: from localhost (henrik@localhost) by filer.marasystems.com (8.11.6/8.11.6) with ESMTP id j2AAA7p26284; Thu, 10 Mar 2005 11:10:07 +0100 Date: Thu, 10 Mar 2005 11:10:07 +0100 (CET) From: Henrik Nordstrom To: Jason Lunz cc: linux-net@vger.kernel.org, netdev@oss.sgi.com Subject: Re: Do you know the TCP stack? (127.x.x.x routing) In-Reply-To: Message-ID: References: <20050306173145.GQ31837@postel.suug.ch> <3sp35g$7hpm0@smtp04.mrf.mail.rcn.net> <422C0B50.20500@mrv.com> <3sp35g$7rsc1@smtp04.mrf.mail.rcn.net> <1110288879.1050.167.camel@jzny.localdomain> <20050308135134.GA20607@atrey.karlin.mff.cuni.cz> <1110290300.1050.190.camel@jzny.localdomain> <20050308140301.GC20607@atrey.karlin.mff.cuni.cz> <1110291470.1043.211.camel@jzny.localdomain> <1110316631.1084.57.camel@jzny.localdomain> <1110377889.1090.124.camel@jzny.localdomain> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Virus-Scanned: ClamAV 0.83/757/Tue Mar 8 15:14:36 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 2819 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: hno@marasystems.com Precedence: bulk X-list: netdev Content-Length: 479 Lines: 14 On Wed, 9 Mar 2005, Jason Lunz wrote: > interfaces. I don't know whether policy routing gives enough control to > do this in a general fashion; Not easily. The problem is to determine which path packets you send should take if the destination is on both sides. You can do some magics with connection tracking and CONNMARK and magic routing tables infront of the local table and disabling the martian checks, but not everything can be solved in this manner. Regards Henrik From romieu@fr.zoreil.com Thu Mar 10 03:21:06 2005 Received: with ECARTIS (v1.0.0; list netdev); Thu, 10 Mar 2005 03:21:16 -0800 (PST) Received: from fr.zoreil.com (electric-eye.fr.zoreil.com [213.41.134.224]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j2ABL50V024354 for ; Thu, 10 Mar 2005 03:21:05 -0800 Received: from electric-eye.fr.zoreil.com (localhost.localdomain [127.0.0.1]) by fr.zoreil.com (8.13.1/8.12.1) with ESMTP id j2ABH9A9029157; Thu, 10 Mar 2005 12:17:09 +0100 Received: (from romieu@localhost) by electric-eye.fr.zoreil.com (8.13.1/8.13.1/Submit) id j2ABH3O0029156; Thu, 10 Mar 2005 12:17:03 +0100 Date: Thu, 10 Mar 2005 12:17:03 +0100 From: Francois Romieu To: Jon Mason Cc: Andi Kleen , Stephen Hemminger , netdev@oss.sgi.com Subject: Re: [PATCH 1/5] r8169: auto detect 32-bit slot Message-ID: <20050310111703.GA29018@electric-eye.fr.zoreil.com> References: <20050309112925.7f7900ab@dxpl.pdx.osdl.net> <200503091608.59122.jdmason@us.ibm.com> <20050309223943.GB9502@electric-eye.fr.zoreil.com> <200503092214.10348.jdmason@us.ibm.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200503092214.10348.jdmason@us.ibm.com> User-Agent: Mutt/1.4.1i X-Organisation: Land of Sunshine Inc. X-Virus-Scanned: ClamAV 0.83/757/Tue Mar 8 15:14:36 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 2820 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: romieu@fr.zoreil.com Precedence: bulk X-list: netdev Content-Length: 531 Lines: 20 Jon Mason : [...] > + if ((sizeof(dma_addr_t) > 4) && > + (RTL_R32(Config2) & (1<<3)) && > + !pci_set_dma_mask(pdev, DMA_64BIT_MASK)) { > > For the above, I get 8 0 1 respectively. So, my adapters fail because of the > 64bit slot test. Config2 can not be a replacement for "use_dac" then. > If you like, I can try my stand-alone adapter in a 64bit slot of a ppc64 > system. It is not strictly necessary. Config2 ought to identify the 64bit slot at best. Thanks. -- Ueimor From hadi@cyberus.ca Thu Mar 10 03:22:51 2005 Received: with ECARTIS (v1.0.0; list netdev); Thu, 10 Mar 2005 03:22:56 -0800 (PST) Received: from mx01.cybersurf.com (mx01.cybersurf.com [209.197.145.104]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j2ABMoR0024816 for ; Thu, 10 Mar 2005 03:22:51 -0800 Received: from mail.cyberus.ca ([209.197.145.21]) by mx01.cybersurf.com with esmtp (Exim 4.30) id 1D9Lka-0002SD-M9 for netdev@oss.sgi.com; Thu, 10 Mar 2005 04:22:44 -0700 Received: from [24.103.99.32] (helo=[10.0.0.9]) by mail.cyberus.ca with esmtp (Exim 4.20) id 1D9LkW-0003ZJ-3I; Thu, 10 Mar 2005 06:22:40 -0500 Subject: Re: dummy as IMQ replacement From: jamal Reply-To: hadi@cyberus.ca To: Remus Cc: netdev@oss.sgi.com, Nguyen Dinh Nam , Andre Tomt , syrius.ml@no-log.org, Andy Furniss , Damion de Soto In-Reply-To: <025501c52552$2dbf87c0$6e69690a@RIMAS> References: <1107123123.8021.80.camel@jzny.localdomain> <0fcf01c5077f$579e4b80$6e69690a@RIMAS> <1107174142.8021.121.camel@jzny.localdomain> <00c301c524b4$938cd240$6e69690a@RIMAS> <1110379135.1091.143.camel@jzny.localdomain> <1110416767.1111.76.camel@jzny.localdomain> <025501c52552$2dbf87c0$6e69690a@RIMAS> Content-Type: text/plain Organization: jamalopolous Message-Id: <1110453757.1108.87.camel@jzny.localdomain> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.2.2 Date: 10 Mar 2005 06:22:38 -0500 Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV 0.83/757/Tue Mar 8 15:14:36 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 2821 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: hadi@cyberus.ca Precedence: bulk X-list: netdev Content-Length: 1677 Lines: 63 Hi Remus, I could not reproduce this one - it is also a bit odd for calloc to fail. I dont have iptables 1.3.1 but i will get and retry. Does this happen all the time? cheers, jamal On Thu, 2005-03-10 at 04:18, Remus wrote: > Hi Jamal, > > Thanks for the patch. > That error is gone but I got a new error: > > ifconfig dummy0 up > tc qdisc add dev eth2 ingress > tc filter add dev eth2 parent ffff: protocol ip prio 10 u32 match u32 0 0 > flowid 1:1 action ipt -j MARK --set-mark 1 action mirred egress redirect dev > dummy0 > iptables: calloc failed: Cannot allocate memory > > I use 2.6.11.2 kernel patched with your dummy patch, iptables 1.3.1 and the > latest iproute2 patched with the pacth you sent yesterday. > > > Regards > > Remus > > > ----- Original Message ----- > From: "Jamal Hadi Salim" > To: "Remus" > Cc: ; "Nguyen Dinh Nam" ; > "Andre Tomt" ; ; "Andy Furniss" > ; "Damion de Soto" > Sent: Thursday, March 10, 2005 1:06 AM > Subject: Re: dummy as IMQ replacement > > > > Hi Remus, > > > > Please try this patch on top of latest iproute2. Credit to Patrick for > > spoting it. I dont know when or who made this change - in any case it > > doesnt matter if it works for you. > > > > cheers, > > > > On Wed, 2005-03-09 at 09:38, jamal wrote: > > > >> I have to go to work - so wont have time to look at this for sometime. > >> Maybe some of the netfilter folks like Patrick can solve it for you > >> before i get back. > >> > >> cheers, > >> jamal > >> > > > > > > From nhorman@redhat.com Thu Mar 10 04:08:29 2005 Received: with ECARTIS (v1.0.0; list netdev); Thu, 10 Mar 2005 04:08:45 -0800 (PST) Received: from mx1.redhat.com (mx1.redhat.com [66.187.233.31]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j2AC8RW2027126 for ; Thu, 10 Mar 2005 04:08:28 -0800 Received: from int-mx1.corp.redhat.com (int-mx1.corp.redhat.com [172.16.52.254]) by mx1.redhat.com (8.12.11/8.12.11) with ESMTP id j2AC8Ecg013133; Thu, 10 Mar 2005 07:08:14 -0500 Received: from localhost.localdomain (hmsendeavour.rdu.redhat.com [172.16.57.156]) by int-mx1.corp.redhat.com (8.11.6/8.11.6) with ESMTP id j2AC8En11853; Thu, 10 Mar 2005 07:08:14 -0500 Received: from localhost.localdomain (hmsendeavour [127.0.0.1]) by localhost.localdomain (8.12.8/8.12.8) with ESMTP id j2AC8E0H006353; Thu, 10 Mar 2005 07:08:14 -0500 Received: (from nhorman@localhost) by localhost.localdomain (8.12.8/8.12.8/Submit) id j2AC84ju006351; Thu, 10 Mar 2005 07:08:04 -0500 Date: Thu, 10 Mar 2005 07:08:03 -0500 From: nhorman@redhat.com To: "David S. Miller" Cc: Sridhar Samudrala , nhorman@redhat.com, netdev@oss.sgi.com, lksctp-developers@lists.sourceforge.net Subject: Re: [Patch] sctp: add receive buffer accounting to sctp (fwd) Message-ID: <20050310120803.GA6341@hmsendeavour.rdu.redhat.com> References: <20050309211632.6f70fe41.davem@davemloft.net> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="W/nzBZO5zC0uMSeA" Content-Disposition: inline In-Reply-To: <20050309211632.6f70fe41.davem@davemloft.net> User-Agent: Mutt/1.4i X-Virus-Scanned: ClamAV 0.83/757/Tue Mar 8 15:14:36 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 2822 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: nhorman@redhat.com Precedence: bulk X-list: netdev Content-Length: 1309 Lines: 51 --W/nzBZO5zC0uMSeA Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Wed, Mar 09, 2005 at 09:16:32PM -0800, David S. Miller wrote: > On Thu, 3 Mar 2005 00:32:12 +0530 (IST) > Sridhar Samudrala wrote: >=20 > > Please apply the following SCTP patch submitted by Neil. > >=20 > > Signed-off-by: Sridhar Samudrala >=20 > This patch doesn't apply cleanly right now. Could you > please cook up a fresh version, and also supply a 2.4.x > version of the patch as well? >=20 > Thanks a lot Sridhar. I'm sorry Dave, I must have built the patch against the latest RHEL4 kernel= and not checked it against the bitkeeper head. I'll rework the patch and repos= t. Thanks Neil --=20 /*************************************************** *Neil Horman *Software Engineer *Red Hat, Inc. *nhorman@redhat.com *gpg keyid: 1024D / 0x92A74FA1 *http://pgp.mit.edu ***************************************************/ --W/nzBZO5zC0uMSeA Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.1 (GNU/Linux) iD8DBQFCMDijM+bEoZKnT6ERAkixAKCSb4NkIPVzDagYGSg/GTHsSiXlFgCcCLga v8by9pZr1SDgmazAfDzVvs4= =QMGC -----END PGP SIGNATURE----- --W/nzBZO5zC0uMSeA-- From steve@services.navaho.net Thu Mar 10 04:45:33 2005 Received: with ECARTIS (v1.0.0; list netdev); Thu, 10 Mar 2005 04:45:41 -0800 (PST) Received: from services.navaho.net (fairchild-194.adsl.newnet.co.uk [213.131.187.194]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j2ACjUJc032133 for ; Thu, 10 Mar 2005 04:45:32 -0800 Received: from [10.101.0.42] (helo=[10.101.0.42] ident=[U2FsdGVkX19aKg0nyJ1aDRUs1cF8X0pjRSA8FaPIXFA=]) by services.navaho.net with esmtp (Exim 4.43) id 1D9N2f-0001eg-Fb for netdev@oss.sgi.com; Thu, 10 Mar 2005 12:45:29 +0000 Date: Thu, 10 Mar 2005 12:45:29 +0000 (GMT) From: Steve Hill X-X-Sender: steve@sorbus2.navaho To: netdev@oss.sgi.com Subject: More IPSEC trouble Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Virus-Scanned: ClamAV 0.83/760/Wed Mar 9 09:12:01 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 2823 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: steve@services.navaho.net Precedence: bulk X-list: netdev Content-Length: 1916 Lines: 42 Unfortunately I've found another IPSEC kernel bug (2.6.10): Running IPSEC in IPv4 tunnel mode - obviously the packets grow in size when encrypted and when I send a packet that grows to > MTU size when encrypted the machine locks up solid (the packet is generated by a different machine that is routing it via the Linux IPSEC router whcih is having problems). When it locks up I get no errors from the kernel - it just freezes up solid. All interfaces have an MTU of 1500 bytes. The IP address of the machine generating the packet is 10.101.0.42 and the public address of it's ipsec gateway (which is the one locking up) is "a.b.c.d" in the below logging. The VPN server at the other end, also running the 2.6.10 kernel, is w.x.y.z. The below logging shows a large ICMP packet that produces an MTU-sized encrypted packet and works ok: $ ping -n 10.254.3.19 -c 1 -s 1372 PING 10.254.3.19 (10.254.3.19) 1372(1400) bytes of data. 1380 bytes from 10.254.3.19: icmp_seq=0 ttl=62 time=94.8 ms # tcpdump -n -i eth0 proto ICMP -v 12:35:50.064417 IP (tos 0x0, ttl 64, id 0, offset 0, flags [DF], proto 1, length: 1400) 10.101.0.42 > 10.254.3.19: icmp 1380: echo request seq 0 # tcpdump -n -i eth1 proto 50 or proto 51 or proto ICMP -v 12:28:53.427655 IP (tos 0x0, ttl 64, id 8224, offset 0, flags [DF], proto 51, length: 1500) a.b.c.d > w.x.y.z: AH(spi=0x07260bb2,sumlen=16,seq=0x2d): IP (tos 0x0, ttl 64, id 55247, offset 0, flags [DF], proto 50, length: 1456) a.b.c.d > w.x.y.z: ESP(spi=0x041b1078,seq=0x2d) Increasing the packet size by 1 byte would obviously require fragmentation of the encrypted packet and causes the machine to lock up. I will continue to do some debugging but any insight would be appreciated. Thanks. - Steve Hill (BSc) Senior Software Developer Email: steve@navaho.co.uk Navaho Technologies Ltd. Tel: +44-870-7034015 From oray@lucent.com Thu Mar 10 05:45:31 2005 Received: with ECARTIS (v1.0.0; list netdev); Thu, 10 Mar 2005 05:45:37 -0800 (PST) Received: from hoemail2.lucent.com (hoemail2.lucent.com [192.11.226.163]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j2ADjVD5002436 for ; Thu, 10 Mar 2005 05:45:31 -0800 Received: from nj7460exch001h.wins.lucent.com (h135-17-42-36.lucent.com [135.17.42.36]) by hoemail2.lucent.com (8.12.11/8.12.11) with ESMTP id j2ADjTI7020559 for ; Thu, 10 Mar 2005 07:45:29 -0600 (CST) Received: by nj7460exch001h.ho.lucent.com with Internet Mail Service (5.5.2657.72) id ; Thu, 10 Mar 2005 08:45:28 -0500 Message-ID: From: "Balasaygun, Oray (Oray)" To: "'Andrew Morton'" , "Balasaygun, Oray (Oray)" Cc: "Balasaygun, Oray (Oray)" , linuxppc-dev@ozlabs.org, netdev@oss.sgi.com, "Nikoonezhad, Danesh (Danesh)" Subject: RE: [Bugme-new] [Bug 4310] New: ppc 8260 fcc ethernet driver cann ot read LXT971 PHY id Date: Thu, 10 Mar 2005 08:45:26 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: text/plain X-Virus-Scanned: ClamAV 0.83/760/Wed Mar 9 09:12:01 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 2824 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: oray@lucent.com Precedence: bulk X-list: netdev Content-Length: 8396 Lines: 255 Andrew, I retested the patch. It works fine. Oray -----Original Message----- From: Andrew Morton [mailto:akpm@osdl.org] Sent: Wednesday, March 09, 2005 6:49 PM To: Balasaygun, Oray (Oray) Cc: oray@lucent.com; linuxppc-dev@ozlabs.org; netdev@oss.sgi.com; dnikoonezhad@lucent.com Subject: Re: [Bugme-new] [Bug 4310] New: ppc 8260 fcc ethernet driver cann ot read LXT971 PHY id "Balasaygun, Oray (Oray)" wrote: > > Attached please find the diff output of the fcc_enet.c that I am running with and the original 2.6.10 version of it. Patch looks reasonable, if unconvnetionally presented ;) Thanks. I fixed a bit of whitespace and converted mii_display_config() and mii_relink() to take an unsigned long arguments as they're now a tasklet callback. Perhaps you could retest this sometime, please? From: "Balasaygun, Oray (Oray)" - fix for Bug 4310 - The fcc_enet.c, as distributed in 2.6.10, does not compile. Evidently the 2.6 kernel no longer supports the schedule_task() and "struct tq_struct" to go with it. Lines 73 through and including 96 of the diffout file show the changes I made to port schedule_task() into tasklet_schedule(). I should have reported this as a bug too but I forgot about it. - customize fcc_enet.c to work with my custom board. These changes are conditional on CONFIG_EON8260 being defined. Signed-off-by: Andrew Morton --- 25-akpm/arch/ppc/8260_io/fcc_enet.c | 91 ++++++++++++++++++++++++++++++------ 1 files changed, 78 insertions(+), 13 deletions(-) diff -puN arch/ppc/8260_io/fcc_enet.c~ppc-8260-fcc-ethernet-driver-cannot-read-lxt971-phy-id arch/ppc/8260_io/fcc_enet.c --- 25/arch/ppc/8260_io/fcc_enet.c~ppc-8260-fcc-ethernet-driver-cannot-read-lxt971-phy-id 2005-03-09 15:40:26.000000000 -0800 +++ 25-akpm/arch/ppc/8260_io/fcc_enet.c 2005-03-09 15:47:23.000000000 -0800 @@ -177,6 +177,54 @@ static int fcc_enet_set_mac_address(stru #define CMX1_CLK_MASK ((uint)0xff000000) #endif +#ifdef CONFIG_EON8260 + +#define MAKE_BITMASK(n) (1 << (31-n)) + +#define PA8 MAKE_BITMASK(8) +#define PA9 MAKE_BITMASK(9) + +#define PB18 MAKE_BITMASK(18) +#define PB19 MAKE_BITMASK(19) +#define PB20 MAKE_BITMASK(20) +#define PB21 MAKE_BITMASK(21) +#define PB22 MAKE_BITMASK(22) +#define PB23 MAKE_BITMASK(23) +#define PB24 MAKE_BITMASK(24) +#define PB25 MAKE_BITMASK(25) +#define PB26 MAKE_BITMASK(26) +#define PB27 MAKE_BITMASK(27) +#define PB28 MAKE_BITMASK(28) +#define PB29 MAKE_BITMASK(29) +#define PB30 MAKE_BITMASK(30) +#define PB31 MAKE_BITMASK(31) + +#define PB2_TXER PB31 +#define PB2_RXDV PB30 +#define PB2_TXEN PB29 +#define PB2_RXER PB28 +#define PB2_COL PB27 +#define PB2_CRS PB26 +#define PB2_TXDAT (PB22 | PB23 | PB24 | PB25) +#define PB2_RXDAT (PB18 | PB19 | PB20 | PB21) +#define PB2_PSORB0 (PB2_RXDAT | PB2_TXDAT | PB2_CRS | PB2_COL | \ + PB2_RXER | PB2_RXDV | PB2_TXER) +#define PB2_PSORB1 (PB2_TXEN) +#define PB2_DIRB0 (PB2_RXDAT | PB2_CRS | PB2_COL | PB2_RXER | PB2_RXDV) +#define PB2_DIRB1 (PB2_TXDAT | PB2_TXEN | PB2_TXER) + +/* CLK16 (PC16) is receive, CLK15 (PC17) is transmit */ + +#define PC_F2RXCLK ((uint)0x00008000) +#define PC_F2TXCLK ((uint)0x00004000) + +#define CMXFCR_TF2CS_CLK15 0x00060000 /* Transmit FCC2 Clock Source is CLK15 */ +#define CMXFCR_RF2CS_CLK16 0x00380000 /* Receive FCC2 Clock Source is CLK16 */ +#define CMX2_CLK_ROUTE (CMXFCR_RF2CS_CLK16 | CMXFCR_TF2CS_CLK15) +#define CMX2_CLK_MASK ((uint)0x00ff0000) + +#else /* #ifdef CONFIG_EON8260 */ + /* I/O Pin assignment for FCC2. I don't yet know the best way to do this, * but there is little variation among the choices. */ @@ -208,6 +256,8 @@ static int fcc_enet_set_mac_address(stru #define CMX2_CLK_MASK ((uint)0x00ff0000) #endif +#endif /* #ifdef CONFIG_EON8260 */ + /* I/O Pin assignment for FCC3. I don't yet know the best way to do this, * but there is little variation among the choices. */ @@ -234,7 +284,11 @@ static int fcc_enet_set_mac_address(stru /* MII status/control serial interface. */ -#ifdef CONFIG_TQM8260 +#if defined (CONFIG_EON8260) +/* EON8260 has MDIO and MDCK on PC31 and PC30 respectively */ +#define PC_MDIO ((uint)0x00000001) +#define PC_MDCK ((uint)0x00000002) +#elif defined (CONFIG_TQM8260) /* TQM8260 has MDIO and MDCK on PC30 and PC31 respectively */ #define PC_MDIO ((uint)0x00000002) #define PC_MDCK ((uint)0x00000001) @@ -268,7 +322,7 @@ static fcc_info_t fcc_ports[] = { #ifdef CONFIG_FCC1_ENET { 0, CPM_CR_FCC1_SBLOCK, CPM_CR_FCC1_PAGE, PROFF_FCC1, SIU_INT_FCC1, (PC_F1RXCLK | PC_F1TXCLK), CMX1_CLK_ROUTE, CMX1_CLK_MASK, -# if defined(CONFIG_TQM8260) || defined(CONFIG_ADS8272) +# if defined(CONFIG_TQM8260) || defined(CONFIG_ADS8272) || defined(CONFIG_EON8260) PC_MDIO, PC_MDCK }, # else 0x00000004, 0x00000100 }, @@ -277,7 +331,7 @@ static fcc_info_t fcc_ports[] = { #ifdef CONFIG_FCC2_ENET { 1, CPM_CR_FCC2_SBLOCK, CPM_CR_FCC2_PAGE, PROFF_FCC2, SIU_INT_FCC2, (PC_F2RXCLK | PC_F2TXCLK), CMX2_CLK_ROUTE, CMX2_CLK_MASK, -# if defined(CONFIG_TQM8260) || defined(CONFIG_ADS8272) +# if defined(CONFIG_TQM8260) || defined(CONFIG_ADS8272) || defined(CONFIG_EON8260) PC_MDIO, PC_MDCK }, # elif defined(CONFIG_EST8260) || defined(CONFIG_ADS8260) 0x00400000, 0x00200000 }, @@ -288,7 +342,7 @@ static fcc_info_t fcc_ports[] = { #ifdef CONFIG_FCC3_ENET { 2, CPM_CR_FCC3_SBLOCK, CPM_CR_FCC3_PAGE, PROFF_FCC3, SIU_INT_FCC3, (PC_F3RXCLK | PC_F3TXCLK), CMX3_CLK_ROUTE, CMX3_CLK_MASK, -# if defined(CONFIG_TQM8260) || defined(CONFIG_ADS8272) +# if defined(CONFIG_TQM8260) || defined(CONFIG_ADS8272) || defined(CONFIG_EON8260) PC_MDIO, PC_MDCK }, # else 0x00000001, 0x00000040 }, @@ -329,7 +383,7 @@ struct fcc_enet_private { uint phy_id_done; uint phy_status; phy_info_t *phy; - struct tq_struct phy_task; + struct tasklet_struct phy_task; uint sequence_done; @@ -1191,8 +1245,9 @@ static void mii_display_status(struct ne printk(".\n"); } -static void mii_display_config(struct net_device *dev) +static void mii_display_config(unsigned long arg) { + struct net_device *dev = (struct net_device *)arg; volatile struct fcc_enet_private *fep = dev->priv; uint s = fep->phy_status; @@ -1222,8 +1277,9 @@ static void mii_display_config(struct ne fep->sequence_done = 1; } -static void mii_relink(struct net_device *dev) +static void mii_relink(unsigned long arg) { + struct net_device *dev = (struct net_device *)arg; struct fcc_enet_private *fep = dev->priv; int duplex; @@ -1246,18 +1302,18 @@ static void mii_queue_relink(uint mii_re { struct fcc_enet_private *fep = dev->priv; - fep->phy_task.routine = (void *)mii_relink; + fep->phy_task.func = mii_relink; fep->phy_task.data = dev; - schedule_task(&fep->phy_task); + tasklet_schedule(&fep->phy_task); } static void mii_queue_config(uint mii_reg, struct net_device *dev) { struct fcc_enet_private *fep = dev->priv; - fep->phy_task.routine = (void *)mii_display_config; + fep->phy_task.func = mii_display_config; fep->phy_task.data = dev; - schedule_task(&fep->phy_task); + tasklet_schedule(&fep->phy_task); } @@ -1464,6 +1520,9 @@ static int __init fec_enet_init(void) return -ENOMEM; cep = dev->priv; + cep->phy_task.next = NULL; + cep->phy_task.state = 0; + cep->phy_task.count.counter = 0; spin_lock_init(&cep->lock); cep->fip = fip; @@ -1698,6 +1757,11 @@ init_fcc_param(fcc_info_t *fip, struct n * non-static part of the address. */ eap = (unsigned char *)&(ep->fen_paddrh); +#if defined(CONFIG_EON8260) + for (i = 5; i >=0 ; i--) { + *eap++ = dev->dev_addr[i] = bd->bi_enetaddr[i]; + } +#else /* if defined(CONFIG_EON8260) */ for (i=5; i>=0; i--) { #ifdef CONFIG_SBC82xx if (i == 5) { @@ -1718,6 +1782,7 @@ init_fcc_param(fcc_info_t *fip, struct n *eap++ = dev->dev_addr[i] = bd->bi_enetaddr[i]; } } +#endif /* if defined(CONFIG_EON8260) */ ep->fen_taddrh = 0; ep->fen_taddrm = 0; @@ -1940,10 +2005,10 @@ mii_send_receive(fcc_info_t *fip, uint c { FCC_PDATC_MDC(1); retval <<= 1; - if (io->iop_pdatc & fip->fc_mdio) - retval++; udelay(1); FCC_PDATC_MDC(0); + if (io->iop_pdatc & fip->fc_mdio) + retval++; udelay(1); } } _ From tgraf@suug.ch Thu Mar 10 06:08:26 2005 Received: with ECARTIS (v1.0.0; list netdev); Thu, 10 Mar 2005 06:08:32 -0800 (PST) Received: from b.mx.projectdream.org (eth0-0.arisu.projectdream.org [194.158.4.191]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j2AE8PHt003868 for ; Thu, 10 Mar 2005 06:08:26 -0800 Received: from postel.suug.ch (postel.suug.ch [195.134.158.23]) (using TLSv1 with cipher EDH-RSA-DES-CBC3-SHA (168/168 bits)) (No client certificate requested) by b.mx.projectdream.org (Postfix) with ESMTP id BF4DC88; Thu, 10 Mar 2005 15:08:00 +0100 (CET) Received: by postel.suug.ch (Postfix, from userid 10001) id 35E301C0EA; Thu, 10 Mar 2005 15:08:43 +0100 (CET) Date: Thu, 10 Mar 2005 15:08:43 +0100 From: Thomas Graf To: Andi Kleen Cc: Ben Greear , "David S. Miller" , baruch@ev-en.org, shemminger@osdl.org, netdev@oss.sgi.com Subject: Re: netif_rx packet dumping Message-ID: <20050310140843.GX31837@postel.suug.ch> References: <42278122.6000000@ev-en.org> <20050303133659.0d224e61.davem@davemloft.net> <42278554.2090902@ev-en.org> <20050303135718.2e1a0170.davem@davemloft.net> <422DC7CE.2040800@ev-en.org> <20050308100902.24b67b2f.davem@davemloft.net> <422DEE85.5010302@candelatech.com> <20050309235728.GV31837@postel.suug.ch> <20050310083309.GA510@muc.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20050310083309.GA510@muc.de> X-Virus-Scanned: ClamAV 0.83/760/Wed Mar 9 09:12:01 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 2825 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: tgraf@suug.ch Precedence: bulk X-list: netdev Content-Length: 4645 Lines: 133 * Andi Kleen <20050310083309.GA510@muc.de> 2005-03-10 09:33 > > I attached a small patch below saving 4 bytes and leaving some room for > > additional flags. The removal of security has indeed potential to break > > external modules. > > And? The Linux kernel never had a stable ABI. Sure but why break it if not really necessary? Anyways, here's a revised version saving 4 bytes and leaving 19 bits for additional flags or a new field. A trivial reordering saves another 4 bytes on 64bit archs when both netfilter debugging and bridging ist enabled. Signed-off-by: Thomas Graf diff -Nru linux-2.6.11-bk5.orig/include/linux/skbuff.h linux-2.6.11-bk5/include/linux/skbuff.h --- linux-2.6.11-bk5.orig/include/linux/skbuff.h 2005-03-10 13:34:00.000000000 +0100 +++ linux-2.6.11-bk5/include/linux/skbuff.h 2005-03-10 13:49:17.000000000 +0100 @@ -250,16 +250,16 @@ unsigned int len, data_len, - mac_len, csum; - unsigned char local_df, + unsigned short mac_len, + protocol; + unsigned char pkt_type, + local_df:1, cloned:1, - nohdr:1, - pkt_type, - ip_summed; + ip_summed:2, + nohdr:1; + __u16 __pad; __u32 priority; - unsigned short protocol, - security; void (*destructor)(struct sk_buff *skb); #ifdef CONFIG_NETFILTER @@ -267,12 +267,12 @@ __u32 nfcache; __u32 nfctinfo; struct nf_conntrack *nfct; -#ifdef CONFIG_NETFILTER_DEBUG - unsigned int nf_debug; -#endif #ifdef CONFIG_BRIDGE_NETFILTER struct nf_bridge_info *nf_bridge; #endif +#ifdef CONFIG_NETFILTER_DEBUG + unsigned int nf_debug; +#endif #endif /* CONFIG_NETFILTER */ #if defined(CONFIG_HIPPI) union { diff -Nru linux-2.6.11-bk5.orig/include/linux/tc_ematch/tc_em_meta.h linux-2.6.11-bk5/include/linux/tc_ematch/tc_em_meta.h --- linux-2.6.11-bk5.orig/include/linux/tc_ematch/tc_em_meta.h 2005-03-10 13:34:00.000000000 +0100 +++ linux-2.6.11-bk5/include/linux/tc_ematch/tc_em_meta.h 2005-03-09 23:34:28.000000000 +0100 @@ -45,7 +45,7 @@ TCF_META_ID_REALDEV, TCF_META_ID_PRIORITY, TCF_META_ID_PROTOCOL, - TCF_META_ID_SECURITY, + TCF_META_ID_SECURITY, /* obsolete */ TCF_META_ID_PKTTYPE, TCF_META_ID_PKTLEN, TCF_META_ID_DATALEN, diff -Nru linux-2.6.11-bk5.orig/net/core/skbuff.c linux-2.6.11-bk5/net/core/skbuff.c --- linux-2.6.11-bk5.orig/net/core/skbuff.c 2005-03-10 13:34:00.000000000 +0100 +++ linux-2.6.11-bk5/net/core/skbuff.c 2005-03-09 23:33:54.000000000 +0100 @@ -359,7 +359,6 @@ C(ip_summed); C(priority); C(protocol); - C(security); n->destructor = NULL; #ifdef CONFIG_NETFILTER C(nfmark); @@ -427,7 +426,6 @@ new->pkt_type = old->pkt_type; new->stamp = old->stamp; new->destructor = NULL; - new->security = old->security; #ifdef CONFIG_NETFILTER new->nfmark = old->nfmark; new->nfcache = old->nfcache; diff -Nru linux-2.6.11-bk5.orig/net/ipv4/ip_output.c linux-2.6.11-bk5/net/ipv4/ip_output.c --- linux-2.6.11-bk5.orig/net/ipv4/ip_output.c 2005-03-10 13:34:00.000000000 +0100 +++ linux-2.6.11-bk5/net/ipv4/ip_output.c 2005-03-09 23:41:40.000000000 +0100 @@ -388,7 +388,6 @@ to->pkt_type = from->pkt_type; to->priority = from->priority; to->protocol = from->protocol; - to->security = from->security; dst_release(to->dst); to->dst = dst_clone(from->dst); to->dev = from->dev; diff -Nru linux-2.6.11-bk5.orig/net/ipv6/ip6_output.c linux-2.6.11-bk5/net/ipv6/ip6_output.c --- linux-2.6.11-bk5.orig/net/ipv6/ip6_output.c 2005-03-10 13:34:00.000000000 +0100 +++ linux-2.6.11-bk5/net/ipv6/ip6_output.c 2005-03-09 23:46:01.000000000 +0100 @@ -462,7 +462,6 @@ to->pkt_type = from->pkt_type; to->priority = from->priority; to->protocol = from->protocol; - to->security = from->security; dst_release(to->dst); to->dst = dst_clone(from->dst); to->dev = from->dev; diff -Nru linux-2.6.11-bk5.orig/net/sched/em_meta.c linux-2.6.11-bk5/net/sched/em_meta.c --- linux-2.6.11-bk5.orig/net/sched/em_meta.c 2005-03-10 13:34:00.000000000 +0100 +++ linux-2.6.11-bk5/net/sched/em_meta.c 2005-03-09 23:34:16.000000000 +0100 @@ -204,11 +204,6 @@ dst->value = skb->protocol; } -META_COLLECTOR(int_security) -{ - dst->value = skb->security; -} - META_COLLECTOR(int_pkttype) { dst->value = skb->pkt_type; @@ -311,7 +306,6 @@ [TCF_META_ID_REALDEV] = { .get = meta_int_realdev }, [TCF_META_ID_PRIORITY] = { .get = meta_int_priority }, [TCF_META_ID_PROTOCOL] = { .get = meta_int_protocol }, - [TCF_META_ID_SECURITY] = { .get = meta_int_security }, [TCF_META_ID_PKTTYPE] = { .get = meta_int_pkttype }, [TCF_META_ID_PKTLEN] = { .get = meta_int_pktlen }, [TCF_META_ID_DATALEN] = { .get = meta_int_datalen }, From steve.iribarne@dilithiumnetworks.com Thu Mar 10 06:35:45 2005 Received: with ECARTIS (v1.0.0; list netdev); Thu, 10 Mar 2005 06:35:48 -0800 (PST) Received: from DHOST001-17.DEX001.intermedia.net (dhost001-17.intermedia.net [64.78.61.64]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j2AEZiwB011708 for ; Thu, 10 Mar 2005 06:35:45 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Subject: RE: Do you know the TCP stack? (127.x.x.x routing) Date: Thu, 10 Mar 2005 06:35:43 -0800 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Do you know the TCP stack? (127.x.x.x routing) Thread-Index: AcUlPU9way76hMQGQ9ydMG3kXOS5TwAQPNcw From: "Steve Iribarne" To: "Catalin\(ux aka Dino\) BOIE" Cc: , "Henrik Nordstrom" , "Martin Mares" , "Zdenek Radouch" , "Eran Mann" , "Thomas Graf" , "Andi Kleen" , , X-Virus-Scanned: ClamAV 0.83/760/Wed Mar 9 09:12:01 2005 on oss.sgi.com X-Virus-Status: Clean Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by oss.sgi.com id j2AEZiwB011708 X-archive-position: 2826 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: steve.iribarne@dilithiumnetworks.com Precedence: bulk X-list: netdev Content-Length: 542 Lines: 16 -> You say that a client will not allow you to use net 10. -> OK, but, the same client would not allow you to use 127/8 because they -> use -> it! -> What I'm saying is that 10.0.0.0/8 and 127.0.0.0/8 are the same. The -> customer can use them. -> You assume that the client will not use 127/8. Why? This is wrong. -> You can use it, the client can use it. -> No. If the client uses 127/8 on a linux box, it is just a loopback and will never go out on the wire and the applications (i.e. telnet, ftp, ping, whatever) will just loopback. From hadi@cyberus.ca Thu Mar 10 06:42:36 2005 Received: with ECARTIS (v1.0.0; list netdev); Thu, 10 Mar 2005 06:42:42 -0800 (PST) Received: from mx02.cybersurf.com (mx02.cybersurf.com [209.197.145.105]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j2AEgZI6012339 for ; Thu, 10 Mar 2005 06:42:36 -0800 Received: from mail.cyberus.ca ([209.197.145.21]) by mx02.cybersurf.com with esmtp (Exim 4.30) id 1D9Orw-0008BN-UW for netdev@oss.sgi.com; Thu, 10 Mar 2005 09:42:32 -0500 Received: from [216.209.86.2] (helo=[10.0.0.9]) by mail.cyberus.ca with esmtp (Exim 4.20) id 1D9Ort-0005VO-Ij; Thu, 10 Mar 2005 09:42:29 -0500 Subject: Re: Re[2]: [leo@yuriev.ru: [PATCH] ethernet-bridge: update skb->priority in case forwarded frame has VLAN-header] From: jamal Reply-To: hadi@cyberus.ca To: "leo.yuriev.ru" Cc: linux-net@vger.kernel.org, Ben Greear , Patrick McHardy , Lennert Buytenhek , shemminger@osdl.org, netdev@oss.sgi.com In-Reply-To: <1391080646.20050310162628@yuriev.ru> References: <20050305141225.GA5180@xi.wantstofly.org> <4229D98F.9010008@trash.net> <422A0C21.3050709@candelatech.com> <1110199696.1094.1299.camel@jzny.localdomain> <1391080646.20050310162628@yuriev.ru> Content-Type: text/plain Organization: jamalopolous Message-Id: <1110465746.1076.29.camel@jzny.localdomain> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.2.2 Date: 10 Mar 2005 09:42:27 -0500 Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV 0.83/760/Wed Mar 9 09:12:01 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 2827 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: hadi@cyberus.ca Precedence: bulk X-list: netdev Content-Length: 1664 Lines: 46 On Thu, 2005-03-10 at 08:26, Leo Yuriev wrote: > >>From looking at the patch: > j> ------ > j> + /* > j> + * We map VLAN_TCI priority (0..7) to skb->priority (0..15) > j> + * most similarly e.g. 0->0, 1->1, .., 7->7 > j> + */ > j> + skb->priority = (vlan_TCI >> 13) & 7; > j> ------ > > j> This is wrong. IEEE priorities are opposite of IETF priorities (as used by > skb->>prio). > j> Unless you install a prio qdisc and rewrite the priomap, you are screwed. > j> So you should do opposite mapping, i.e something along the lines of > j> VLAN_TCI priority (0..7) to skb->priority (15..8) i,e skb->priority = 15 - vlan_TCI; > j> cheers, > j> jamal > > > Jamal, you are wrong! But i am not, Leo ;-> > 802.1p defines priority as "linear" from 0 to 7, > the 0 is lowest priority and 7 is highest. > Yes of course this is true for IEEE (I never said this wasnt the case). The issue is this: _which_ queue gets processed first? In strict priority (default for Linux), queue 0 is always high priority and will always be processed first even if queue 1 has work (to use other terms queue 1 will be "starved" by queue 0). So you need to make sure that "highest" priority(7 in your case) always goes to queue 0. As was pointed out in the thread discussion - priority map in Linux actually doesnt quiet map to a true reverse as i had put it. So you need to change your equation to map to the default map in Linux in which the result is always to make sure 802.1p priority 7 is processed first. If you have any problems figuring it out email me privately and i can help. cheers, jamal From dmitry.torokhov@gmail.com Thu Mar 10 06:49:41 2005 Received: with ECARTIS (v1.0.0; list netdev); Thu, 10 Mar 2005 06:49:46 -0800 (PST) Received: from rproxy.gmail.com (rproxy.gmail.com [64.233.170.193]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j2AEnfDR013094 for ; Thu, 10 Mar 2005 06:49:41 -0800 Received: by rproxy.gmail.com with SMTP id r35so568129rna for ; Thu, 10 Mar 2005 06:49:40 -0800 (PST) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:reply-to:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:references; b=IkeiiV/dq8cE2FKElSekCwB95s5yjly+t99S3zIfORtUqc3u2JiRoln6CR7A1OV16J0WxdugCvlrVpK0Gg/ZmqmUMzt8U4bhSM4iUdfda3yVqXxHXOx8JRVDX2zbjUX/zxadtEVHHfKabqQQVTZrCPbGBesIpN0MclrQ8NEmCkg= Received: by 10.38.73.45 with SMTP id v45mr1805297rna; Thu, 10 Mar 2005 06:49:40 -0800 (PST) Received: by 10.38.24.62 with HTTP; Thu, 10 Mar 2005 06:49:40 -0800 (PST) Message-ID: Date: Thu, 10 Mar 2005 09:49:40 -0500 From: Dmitry Torokhov Reply-To: dtor_core@ameritech.net To: Steve Iribarne Subject: Re: Do you know the TCP stack? (127.x.x.x routing) Cc: "Catalin(ux aka Dino) BOIE" , hadi@cyberus.ca, Henrik Nordstrom , Martin Mares , Zdenek Radouch , Eran Mann , Thomas Graf , Andi Kleen , netdev@oss.sgi.com, linux-net@vger.kernel.org In-Reply-To: Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit References: X-Virus-Scanned: ClamAV 0.83/760/Wed Mar 9 09:12:01 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 2828 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: dmitry.torokhov@gmail.com Precedence: bulk X-list: netdev Content-Length: 746 Lines: 22 On Thu, 10 Mar 2005 06:35:43 -0800, Steve Iribarne wrote: > -> You say that a client will not allow you to use net 10. > -> OK, but, the same client would not allow you to use 127/8 because > they > -> use > -> it! > -> What I'm saying is that 10.0.0.0/8 and 127.0.0.0/8 are the same. The > -> customer can use them. > -> You assume that the client will not use 127/8. Why? This is wrong. > -> You can use it, the client can use it. > -> > > No. If the client uses 127/8 on a linux box, it is just a loopback and > will never go out on the wire and the applications (i.e. telnet, ftp, > ping, whatever) will just loopback. > This assumes that the client did not apply the same hack you did. -- Dmitry From nicolas.dichtel@6wind.com Thu Mar 10 07:02:04 2005 Received: with ECARTIS (v1.0.0; list netdev); Thu, 10 Mar 2005 07:02:10 -0800 (PST) Received: from eagle.6wind.com (46.106-14-84.ripe.coltfrance.com [84.14.106.46]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j2AF2243014736 for ; Thu, 10 Mar 2005 07:02:03 -0800 Received: from [10.16.0.135] (unknown [10.16.0.135]) by eagle.6wind.com (Postfix) with ESMTP id 9468F21F; Thu, 10 Mar 2005 16:02:01 +0100 (CET) Message-ID: <42306145.3050603@6wind.com> Date: Thu, 10 Mar 2005 16:01:25 +0100 From: Nicolas DICHTEL Reply-To: nicolas.dichtel@6wind.com User-Agent: Mozilla Thunderbird 1.0 (Windows/20041206) X-Accept-Language: en-us, en MIME-Version: 1.0 To: steve@services.navaho.net Cc: netdev@oss.sgi.com Subject: Re: More IPSEC trouble References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV 0.83/760/Wed Mar 9 09:12:01 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 2829 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: nicolas.dichtel@6wind.com Precedence: bulk X-list: netdev Content-Length: 2751 Lines: 70 When the stack check the mtu for this packet, it doesn't know the size of the overhead. So the total length of the packet don't include the size of the esp or ah header. The same bug appears when you run IPSEC in IPv4 transport mode over a 4in4 tunnel. A fix for this bug is to allow locally the fragmentation of the packet. Nicolas Dichtel Here is a patch: --- a/linux26/net/ipv4/xfrm4_output.c Thu Mar 10 15:50:30 2005 +++ b/linux26/net/ipv4/xfrm4_output.c Thu Mar 10 15:51:49 2005 @@ -116,6 +116,9 @@ int xfrm4_output(struct sk_buff *skb) xfrm4_encap(skb); + /* We still allow to fragment this packet locally */ + skb->local_df = 1; + err = x->type->output(skb); if (err) goto error; Steve Hill wrote: > > Unfortunately I've found another IPSEC kernel bug (2.6.10): > > Running IPSEC in IPv4 tunnel mode - obviously the packets grow in size > when encrypted and when I send a packet that grows to > MTU size when > encrypted the machine locks up solid (the packet is generated by a > different machine that is routing it via the Linux IPSEC router whcih > is having problems). When it locks up I get no errors from the kernel > - it just freezes up solid. > > All interfaces have an MTU of 1500 bytes. The IP address of the > machine generating the packet is 10.101.0.42 and the public address of > it's ipsec gateway (which is the one locking up) is "a.b.c.d" in the > below logging. The VPN server at the other end, also running the > 2.6.10 kernel, is w.x.y.z. The below logging shows a large ICMP > packet that produces an MTU-sized encrypted packet and works ok: > > $ ping -n 10.254.3.19 -c 1 -s 1372 > PING 10.254.3.19 (10.254.3.19) 1372(1400) bytes of data. > 1380 bytes from 10.254.3.19: icmp_seq=0 ttl=62 time=94.8 ms > > # tcpdump -n -i eth0 proto ICMP -v > 12:35:50.064417 IP (tos 0x0, ttl 64, id 0, offset 0, flags [DF], > proto 1, length: 1400) 10.101.0.42 > 10.254.3.19: icmp 1380: echo > request seq 0 > > # tcpdump -n -i eth1 proto 50 or proto 51 or proto ICMP -v > 12:28:53.427655 IP (tos 0x0, ttl 64, id 8224, offset 0, flags [DF], > proto 51, length: 1500) a.b.c.d > w.x.y.z: > AH(spi=0x07260bb2,sumlen=16,seq=0x2d): IP (tos 0x0, ttl 64, id 55247, > offset 0, flags [DF], proto 50, length: 1456) a.b.c.d > w.x.y.z: > ESP(spi=0x041b1078,seq=0x2d) > > Increasing the packet size by 1 byte would obviously require > fragmentation of the encrypted packet and causes the machine to lock up. > > I will continue to do some debugging but any insight would be > appreciated. Thanks. > > - Steve Hill (BSc) > Senior Software Developer Email: > steve@navaho.co.uk > Navaho Technologies Ltd. Tel: +44-870-7034015 > > From steve.iribarne@dilithiumnetworks.com Thu Mar 10 07:04:03 2005 Received: with ECARTIS (v1.0.0; list netdev); Thu, 10 Mar 2005 07:04:07 -0800 (PST) Received: from DHOST001-17.DEX001.intermedia.net (dhost001-17.intermedia.net [64.78.61.64]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j2AF43hw015316 for ; Thu, 10 Mar 2005 07:04:03 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Subject: RE: Do you know the TCP stack? (127.x.x.x routing) Date: Thu, 10 Mar 2005 07:04:02 -0800 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Do you know the TCP stack? (127.x.x.x routing) Thread-Index: AcUlgGSO02N6ZKmLSaSD9JNB4kmuuwAAUcOw From: "Steve Iribarne" To: Cc: "Catalin\(ux aka Dino\) BOIE" , , "Henrik Nordstrom" , "Martin Mares" , "Zdenek Radouch" , "Eran Mann" , "Thomas Graf" , "Andi Kleen" , , X-Virus-Scanned: ClamAV 0.83/760/Wed Mar 9 09:12:01 2005 on oss.sgi.com X-Virus-Status: Clean Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by oss.sgi.com id j2AF43hw015316 X-archive-position: 2830 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: steve.iribarne@dilithiumnetworks.com Precedence: bulk X-list: netdev Content-Length: 678 Lines: 17 -> This assumes that the client did not apply the same hack you did. -> They wouldn't do it on the same machine or system. I control my internal system. It's an embedded system which means I have complete control. If they applied it somewhere else on the network, I wouldn't receive any of those packets because the router would drop it and my patch drops the 127.xxx rcv'd packets if not received on the proper VLAN and my system doesn't accept tagged packets from the outside world. I don't think I'm the only one who has done this. As a matter of fact, I KNOW I'm not. When I worked on BSD years ago (10+), I worked for a company who did the same sort of hack. -stv From util@deuroconsult.ro Thu Mar 10 07:25:39 2005 Received: with ECARTIS (v1.0.0; list netdev); Thu, 10 Mar 2005 07:25:45 -0800 (PST) Received: from webhosting.rdsbv.ro (webhosting.rdsbv.ro [213.157.185.164]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j2AFPcH4017139 for ; Thu, 10 Mar 2005 07:25:39 -0800 Received: from webhosting.rdsbv.ro (localhost [127.0.0.1]) by webhosting.rdsbv.ro (8.13.3/8.13.3) with ESMTP id j2AFP1LK007278 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 10 Mar 2005 17:25:01 +0200 Received: from localhost (util@localhost) by webhosting.rdsbv.ro (8.13.3/8.13.3/Submit) with ESMTP id j2AFP0bq007270; Thu, 10 Mar 2005 17:25:00 +0200 X-Authentication-Warning: webhosting.rdsbv.ro: util owned process doing -bs Date: Thu, 10 Mar 2005 17:25:00 +0200 (EET) From: "Catalin(ux aka Dino) BOIE" X-X-Sender: util@webhosting.rdsbv.ro To: Steve Iribarne cc: dtor_core@ameritech.net, hadi@cyberus.ca, Henrik Nordstrom , Martin Mares , Zdenek Radouch , Eran Mann , Thomas Graf , Andi Kleen , netdev@oss.sgi.com, linux-net@vger.kernel.org Subject: RE: Do you know the TCP stack? (127.x.x.x routing) In-Reply-To: Message-ID: References: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Virus-Scanned: ClamAV 0.83/760/Wed Mar 9 09:12:01 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 2831 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: util@deuroconsult.ro Precedence: bulk X-list: netdev Content-Length: 1107 Lines: 27 > -> This assumes that the client did not apply the same hack you did. :) Exactly! > They wouldn't do it on the same machine or system. I control my internal > system. It's an embedded system which means I have complete control. > If they applied it somewhere else on the network, I wouldn't receive any > of those packets because the router would drop it and my patch drops the > 127.xxx rcv'd packets if not received on the proper VLAN and my system > doesn't accept tagged packets from the outside world. > > I don't think I'm the only one who has done this. As a matter of fact, > I KNOW I'm not. When I worked on BSD years ago (10+), I worked for a > company who did the same sort of hack. I think that the best way is to choose a 10.0.0.0/24|16|8 net and let the client to configure other net if it has the same net somewhere. I agree that 127 is a lot less used that 10, but you never know. Probably you will choose anyway 127, but I suggest to have a possibility the user choose another class if he wants. --- Catalin(ux aka Dino) BOIE catab at deuroconsult.ro http://kernel.umbrella.ro/ From nhorman@redhat.com Thu Mar 10 07:43:50 2005 Received: with ECARTIS (v1.0.0; list netdev); Thu, 10 Mar 2005 07:44:02 -0800 (PST) Received: from mx1.redhat.com (mx1.redhat.com [66.187.233.31]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j2AFhnGg018114 for ; Thu, 10 Mar 2005 07:43:49 -0800 Received: from int-mx1.corp.redhat.com (int-mx1.corp.redhat.com [172.16.52.254]) by mx1.redhat.com (8.12.11/8.12.11) with ESMTP id j2AFhgTC010424; Thu, 10 Mar 2005 10:43:42 -0500 Received: from localhost.localdomain (hmsendeavour.rdu.redhat.com [172.16.57.156]) by int-mx1.corp.redhat.com (8.11.6/8.11.6) with ESMTP id j2AFhgn14196; Thu, 10 Mar 2005 10:43:42 -0500 Received: from localhost.localdomain (hmsendeavour [127.0.0.1]) by localhost.localdomain (8.12.8/8.12.8) with ESMTP id j2AFhg0H008379; Thu, 10 Mar 2005 10:43:42 -0500 Received: (from nhorman@localhost) by localhost.localdomain (8.12.8/8.12.8/Submit) id j2AFhgAL008377; Thu, 10 Mar 2005 10:43:42 -0500 Date: Thu, 10 Mar 2005 10:43:42 -0500 From: nhorman@redhat.com To: nhorman@redhat.com Cc: "David S. Miller" , Sridhar Samudrala , netdev@oss.sgi.com, lksctp-developers@lists.sourceforge.net Subject: Re: [Patch] sctp: add receive buffer accounting to sctp (fwd) Message-ID: <20050310154342.GG6341@hmsendeavour.rdu.redhat.com> References: <20050309211632.6f70fe41.davem@davemloft.net> <20050310120803.GA6341@hmsendeavour.rdu.redhat.com> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="ytoMbUMiTKPMT3hY" Content-Disposition: inline In-Reply-To: <20050310120803.GA6341@hmsendeavour.rdu.redhat.com> User-Agent: Mutt/1.4i X-Virus-Scanned: ClamAV 0.83/760/Wed Mar 9 09:12:01 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 2832 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: nhorman@redhat.com Precedence: bulk X-list: netdev Content-Length: 2174 Lines: 84 --ytoMbUMiTKPMT3hY Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Repost of my ealier rcvbuf patch. No changes, but rediffed to apply cleanl= y to the head of the bitkeeper tree. Passes all lksctp regression tests Signed-off-by: Neil Horman input.c | 22 ++++++++++++++++++++++ 1 files changed, 22 insertions(+) --- linux-2.6-sctp/net/sctp/input.c.orig 2005-03-10 07:11:46.000000000 -0500 +++ linux-2.6-sctp/net/sctp/input.c 2005-03-10 07:18:25.000000000 -0500 @@ -100,6 +100,21 @@ return 0; } =20 +/* The free routine for skbuffs that sctp receives */ +static void sctp_rfree(struct sk_buff *skb) +{ + atomic_sub(sizeof(struct sctp_chunk),&skb->sk->sk_rmem_alloc); + sock_rfree(skb); +} + +/* The ownership wrapper routine to do receive buffer accounting */ +static void sctp_rcv_set_owner_r(struct sk_buff *skb, struct sock *sk) +{ + skb_set_owner_r(skb,sk); + skb->destructor =3D sctp_rfree; + atomic_add(sizeof(struct sctp_chunk),&sk->sk_rmem_alloc); +} + /* * This is the routine which IP calls when receiving an SCTP packet. */ @@ -183,6 +198,11 @@ rcvr =3D asoc ? &asoc->base : &ep->base; sk =3D rcvr->sk; =20 + if ((sk) && (atomic_read(&sk->sk_rmem_alloc) >=3D sk->sk_rcvbuf)) { + goto discard_release; + } + + /* SCTP seems to always need a timestamp right now (FIXME) */ if (skb->stamp.tv_sec =3D=3D 0) { do_gettimeofday(&skb->stamp); @@ -203,6 +223,8 @@ goto discard_release; } =20 + sctp_rcv_set_owner_r(skb,sk); + /* Remember what endpoint is to handle this packet. */ chunk->rcvr =3D rcvr; =20 --=20 /*************************************************** *Neil Horman *Software Engineer *Red Hat, Inc. *nhorman@redhat.com *gpg keyid: 1024D / 0x92A74FA1 *http://pgp.mit.edu ***************************************************/ --ytoMbUMiTKPMT3hY Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.1 (GNU/Linux) iD8DBQFCMGstM+bEoZKnT6ERAg+5AJ9ff0925s3t6tAfyjmH/A3/+Wo6NgCeLdNI cIt64C2uCN2DN+LgUDdix9w= =7M4K -----END PGP SIGNATURE----- --ytoMbUMiTKPMT3hY-- From mcgrof@ruslug.rutgers.edu Thu Mar 10 08:30:09 2005 Received: with ECARTIS (v1.0.0; list netdev); Thu, 10 Mar 2005 08:30:13 -0800 (PST) Received: from ruslug.rutgers.edu (ruslug.rutgers.edu [128.6.24.131]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j2AGU8tx027723 for ; Thu, 10 Mar 2005 08:30:08 -0800 Received: by ruslug.rutgers.edu (Postfix, from userid 503) id EB779F9928; Thu, 10 Mar 2005 11:30:07 -0500 (EST) Date: Thu, 10 Mar 2005 11:30:07 -0500 To: Chris Wedgwood , Jeff Garzik , Netdev Cc: Adam K Kirchhoff , prism54-devel@prism54.org, Feyd Subject: Re: [Prism54-devel] Re: Problems with a PCI SMC2802W Message-ID: <20050310163007.GK17854@ruslug.rutgers.edu> Mail-Followup-To: Chris Wedgwood , Jeff Garzik , Netdev , Adam K Kirchhoff , prism54-devel@prism54.org, Feyd References: <422F118D.8070704@voicenet.com> <20050309160744.GN4017@Redstar.dorchain.net> <20050309202718.4f94b871@veagle.suse.cz> <20050310021724.GD17854@ruslug.rutgers.edu> <42302133.2060103@voicenet.com> <20050310103608.GB1416@taniwha.stupidest.org> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="e5bfZ/T2xnjpUIbw" Content-Disposition: inline In-Reply-To: <20050310103608.GB1416@taniwha.stupidest.org> User-Agent: Mutt/1.3.28i X-Operating-System: 2.4.18-1-686 Organization: Rutgers University Student Linux Users Group From: mcgrof@ruslug.rutgers.edu (Luis R. Rodriguez) X-Virus-Scanned: ClamAV 0.83/760/Wed Mar 9 09:12:01 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 2833 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: mcgrof@ruslug.rutgers.edu Precedence: bulk X-list: netdev Content-Length: 4129 Lines: 126 --e5bfZ/T2xnjpUIbw Content-Type: text/plain; charset=us-ascii Content-Disposition: attachment Content-Transfer-Encoding: quoted-printable On Thu, Mar 10, 2005 at 02:36:08AM -0800, Chris Wedgwood wrote: > On Thu, Mar 10, 2005 at 05:28:03AM -0500, Adam K Kirchhoff wrote: >=20 > > Unfortunately, the latest svn checkout doesn't want to compile for > > me on 2.6.11: >=20 > I have these diffs. Forward to the list if you like since it never > accepts email from me (grr) >=20 >=20 > Index: ksrc/islpci_eth.c > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > --- ksrc/islpci_eth.c (revision 528) > +++ ksrc/islpci_eth.c (working copy) > @@ -90,7 +90,9 @@ > struct sk_buff *newskb; > int newskb_offset; > unsigned long flags; > +#ifdef CONFIG_PRISM54_WDS > unsigned char wds_mac[6]; > +#endif > u32 curr_frag; > int err =3D 0; > =20 > @@ -362,9 +364,9 @@ > struct sk_buff *skb; > u16 size; > u32 index, offset; > - unsigned char *src; > int discard =3D 0; > #ifdef CONFIG_PRISM54_WDS > + unsigned char *src; > struct wds_priv *wdsp =3D priv->wdsp; > struct net_device *wds_dev =3D NULL; > struct wds_net_local *wds_lp; > Index: ksrc/islpci_hotplug.c > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > --- ksrc/islpci_hotplug.c (revision 528) > +++ ksrc/islpci_hotplug.c (working copy) > @@ -277,7 +277,7 @@ > printk(KERN_NOTICE "%s: got suspend request (state %d)\n", > ndev->name, state); > =20 > - pci_save_state(pdev, priv->pci_state); > + pci_save_state(pdev); > =20 > /* tell the device not to trigger interrupts for now... */ > isl38xx_disable_interrupts(priv->device_base); > @@ -303,7 +303,7 @@ > =20 > printk(KERN_NOTICE "%s: got resume request\n", ndev->name); > =20 > - pci_restore_state(pdev, priv->pci_state); > + pci_restore_state(pdev); > =20 > /* alright let's go into the PREBOOT state */ > islpci_reset(priv, 1); > Index: ksrc/islpci_dev.h > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > --- ksrc/islpci_dev.h (revision 528) > +++ ksrc/islpci_dev.h (working copy) > @@ -112,7 +112,6 @@ > =20 > /* PCI bus allocation & configuration members */ > struct pci_dev *pdev; /* PCI structure information */ > - u32 pci_state[16]; /* used for suspend/resume */ > char firmware[33]; > =20 > void __iomem *device_base; /* ioremapped device base address */ > Index: ksrc/islpci_mgt.c > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > --- ksrc/islpci_mgt.c (revision 528) > +++ ksrc/islpci_mgt.c (working copy) > @@ -345,7 +345,7 @@ > } > =20 > /* Ensure the results of device DMA are visible to the CPU. */ > - pci_dma_sync_single(priv->pdev, buf->pci_addr, > + pci_dma_sync_single_for_cpu(priv->pdev, buf->pci_addr, > frag_len, PCI_DMA_FROMDEVICE); > =20 > /* Perform endianess conversion for PIMFOR header in-place. */ Thanks, but the pci_[restore|save]_state changes requires testing/backporti= ng to 2.4.=20 Same goes for pci_dma_sync_single_for_cpu(). We can macro this but ugh, it'= s just so=20 horrible. Margit, where are you? Jeff, what's better a prismcompat24.h edit or a check for LINUX_VERSION_CODE here? Luis --=20 GnuPG Key fingerprint =3D 113F B290 C6D2 0251 4D84 A34A 6ADD 4937 E20A 525E --e5bfZ/T2xnjpUIbw Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.4 (GNU/Linux) iD8DBQFCMHYPat1JN+IKUl4RAkmpAJ9l42Hx+rOgOdrcMInC2xeiEJGsSACgjB2p Q+qntGGYlnHLfbv3IK0WgEc= =aCFv -----END PGP SIGNATURE----- --e5bfZ/T2xnjpUIbw-- From steve@services.navaho.net Thu Mar 10 08:32:03 2005 Received: with ECARTIS (v1.0.0; list netdev); Thu, 10 Mar 2005 08:32:08 -0800 (PST) Received: from services.navaho.net (fairchild-194.adsl.newnet.co.uk [213.131.187.194]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j2AGW3vi028120 for ; Thu, 10 Mar 2005 08:32:03 -0800 Received: from [10.101.0.42] (helo=[10.101.0.42] ident=[U2FsdGVkX1/Gi4MRtfDLIfvi372FkyLz2lELk4Agf1s=]) by services.navaho.net with esmtp (Exim 4.43) id 1D9QZu-00014x-3O; Thu, 10 Mar 2005 16:32:02 +0000 Date: Thu, 10 Mar 2005 16:32:01 +0000 (GMT) From: Steve Hill X-X-Sender: steve@sorbus2.navaho To: Nicolas DICHTEL cc: netdev@oss.sgi.com Subject: Re: More IPSEC trouble In-Reply-To: <42306145.3050603@6wind.com> Message-ID: References: <42306145.3050603@6wind.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Virus-Scanned: ClamAV 0.83/760/Wed Mar 9 09:12:01 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 2834 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: steve@services.navaho.net Precedence: bulk X-list: netdev Content-Length: 624 Lines: 14 On Thu, 10 Mar 2005, Nicolas DICHTEL wrote: > When the stack check the mtu for this packet, it doesn't know the size of > the overhead. So the total length of the packet don't include the size > of the esp or ah header. The same bug appears when you run > IPSEC in IPv4 transport mode over a 4in4 tunnel. A fix for this bug > is to allow locally the fragmentation of the packet. I've just tried the patch and unfortunately it doesn't fix the problem. :( - Steve Hill (BSc) Senior Software Developer Email: steve@navaho.co.uk Navaho Technologies Ltd. Tel: +44-870-7034015 From kaber@trash.net Thu Mar 10 09:16:01 2005 Received: with ECARTIS (v1.0.0; list netdev); Thu, 10 Mar 2005 09:16:06 -0800 (PST) Received: from kaber.coreworks.de ([62.206.217.67]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j2AHG0Qf030210 for ; Thu, 10 Mar 2005 09:16:01 -0800 Received: from localhost ([127.0.0.1]) by kaber.coreworks.de with esmtp (Exim 4.50) id 1D9RGN-00014r-0b; Thu, 10 Mar 2005 18:15:55 +0100 Message-ID: <423080CA.3060604@trash.net> Date: Thu, 10 Mar 2005 18:15:54 +0100 From: Patrick McHardy User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.7.5) Gecko/20050106 Debian/1.7.5-1 X-Accept-Language: en MIME-Version: 1.0 To: Steve Hill CC: netdev@oss.sgi.com Subject: Re: More IPSEC trouble References: In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV 0.83/760/Wed Mar 9 09:12:01 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 2835 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: kaber@trash.net Precedence: bulk X-list: netdev Content-Length: 318 Lines: 13 Steve Hill wrote: > > Unfortunately I've found another IPSEC kernel bug (2.6.10): > > Increasing the packet size by 1 byte would obviously require > fragmentation of the encrypted packet and causes the machine to lock up. Doesn't sound familiar to me, but I would recommend trying 2.6.11 anyway. Regards Patrick From shemminger@osdl.org Thu Mar 10 10:41:59 2005 Received: with ECARTIS (v1.0.0; list netdev); Thu, 10 Mar 2005 10:42:04 -0800 (PST) Received: from smtp.osdl.org (fire.osdl.org [65.172.181.4]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j2AIfxEN000393 for ; Thu, 10 Mar 2005 10:41:59 -0800 Received: from shell0.pdx.osdl.net (fw.osdl.org [65.172.181.6]) by smtp.osdl.org (8.12.8/8.12.8) with ESMTP id j2AIfnqi008140 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO); Thu, 10 Mar 2005 10:41:50 -0800 Received: from dxpl.pdx.osdl.net (dxpl.pdx.osdl.net [172.20.1.103]) by shell0.pdx.osdl.net (8.13.1/8.11.6) with ESMTP id j2AIfn4W007551; Thu, 10 Mar 2005 10:41:49 -0800 Date: Thu, 10 Mar 2005 10:42:07 -0800 From: Stephen Hemminger To: Jamal Hadi Salim , "David S. Miller" Cc: netdev@oss.sgi.com Subject: [PATCH] move tc_u32_mark into pkt_cls.h Message-ID: <20050310104207.1d74ac00@dxpl.pdx.osdl.net> Organization: Open Source Development Lab X-Mailer: Sylpheed-Claws 1.0.1 (GTK+ 1.2.10; x86_64-unknown-linux-gnu) X-Face: &@E+xe?c%:&e4D{>f1O<&U>2qwRREG5!}7R4;D<"NO^UI2mJ[eEOA2*3>(`Th.yP,VDPo9$ /`~cw![cmj~~jWe?AHY7D1S+\}5brN0k*NE?pPh_'_d>6;XGG[\KDRViCfumZT3@[ Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Received-SPF: pass (domain of shemminger@osdl.org designates 65.172.181.6 as permitted sender) X-MIMEDefang-Filter: osdl$Revision: 1.104 $ X-Scanned-By: MIMEDefang 2.36 X-Virus-Scanned: ClamAV 0.83/760/Wed Mar 9 09:12:01 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 2836 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: shemminger@osdl.org Precedence: bulk X-list: netdev Content-Length: 1218 Lines: 54 The tc_u32_mark structure is used as part of the netlink message from the user API to the kernel, so it needs to be moved to include/linux/pkt_cls.h and have types changed from u32 to __u32. Also, the definition of u32 performance counters doesn't need to depend on the config option. The definition can exist even if the code isn't enabled. Signed-off-by: Stephen Hemminger diff -Nru a/include/linux/pkt_cls.h b/include/linux/pkt_cls.h --- a/include/linux/pkt_cls.h 2005-03-10 10:36:39 -08:00 +++ b/include/linux/pkt_cls.h 2005-03-10 10:36:39 -08:00 @@ -221,14 +221,20 @@ struct tc_u32_key keys[0]; }; -#ifdef CONFIG_CLS_U32_PERF +struct tc_u32_mark +{ + __u32 val; + __u32 mask; + __u32 success; +}; + struct tc_u32_pcnt { __u64 rcnt; __u64 rhit; __u64 kcnts[0]; }; -#endif + /* Flags */ #define TC_U32_TERMINAL 1 diff -Nru a/net/sched/cls_u32.c b/net/sched/cls_u32.c --- a/net/sched/cls_u32.c 2005-03-10 10:36:39 -08:00 +++ b/net/sched/cls_u32.c 2005-03-10 10:36:39 -08:00 @@ -58,14 +58,6 @@ #include #include - -struct tc_u32_mark -{ - u32 val; - u32 mask; - u32 success; -}; - struct tc_u_knode { struct tc_u_knode *next; From cliffw@osdl.org Thu Mar 10 10:48:51 2005 Received: with ECARTIS (v1.0.0; list netdev); Thu, 10 Mar 2005 10:48:58 -0800 (PST) Received: from smtp.osdl.org (fire.osdl.org [65.172.181.4]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j2AImogO001150 for ; Thu, 10 Mar 2005 10:48:50 -0800 Received: from es175 (fw.osdl.org [65.172.181.6]) (authenticated bits=0) by smtp.osdl.org (8.12.8/8.12.8) with ESMTP id j2AImUqi008728 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO); Thu, 10 Mar 2005 10:48:31 -0800 Date: Thu, 10 Mar 2005 10:48:30 -0800 From: cliff white To: Robert Olsson Cc: Stephen Hemminger , Robert Olsson , netdev@oss.sgi.com Subject: Re: pktgen: causing lots of errors in console log Message-ID: <20050310104830.58c467c0@es175> In-Reply-To: <16942.55689.924299.906304@robur.slu.se> References: <20050308140826.451435e5@dxpl.pdx.osdl.net> <16942.55689.924299.906304@robur.slu.se> Organization: OSDL X-Mailer: Sylpheed-Claws 1.0.1 (GTK+ 1.2.10; i386-pc-linux-gnu) Mime-Version: 1.0 Content-Type: multipart/mixed; boundary=Multipart_Thu__10_Mar_2005_10_48_30_-0800_BLa3zW+zhWEPwmhp X-MIMEDefang-Filter: osdl$Revision: 1.104 $ X-Scanned-By: MIMEDefang 2.36 X-Virus-Scanned: ClamAV 0.83/760/Wed Mar 9 09:12:01 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 2837 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: cliffw@osdl.org Precedence: bulk X-list: netdev Content-Length: 43666 Lines: 626 --Multipart_Thu__10_Mar_2005_10_48_30_-0800_BLa3zW+zhWEPwmhp Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Disposition: inline On Wed, 9 Mar 2005 12:10:01 +0100 Robert Olsson wrote: > > Hello! > > > Stephen Hemminger writes: > > 1. Errors from IPV4 > > Freeing alive in_device ffff81007e96a400 > > Try: > > --- net/core/pktgen.c.orig 2005-03-09 10:15:01.000000000 +0100 > +++ net/core/pktgen.c 2005-03-09 10:24:19.000000000 +0100 > @@ -151,7 +151,7 @@ > #include > > > -#define VERSION "pktgen v2.58: Packet Generator for packet performance testing.\n" > +#define VERSION "pktgen v2.59: Packet Generator for packet performance testing.\n" > > /* #define PG_DEBUG(a) a */ > #define PG_DEBUG(a) > @@ -1682,7 +1682,7 @@ > pkt_dev->saddr_min = in_dev->ifa_list->ifa_address; > pkt_dev->saddr_max = pkt_dev->saddr_min; > } > - in_dev_put(in_dev); > + __in_dev_put(in_dev); > } > rcu_read_unlock(); > } > > > > > > 2. Cliff is getting this with e1000 and pktgen-conf-1-2 > > looks like calling schedule_timeout with lock held. > > > > Need to reproduce this one... Okay, I can reproduce it on two machines, no problem. Please let me know what information you need. I'm using 2.6.11 from bk, problem also happens on 2.6.10. .config file is attached. I'm using the basic 'send 10 million packets to a second machine' example file. lspci for the cards: 0000:04:04.0 Ethernet controller: Intel Corp. 82557/8/9 [Ethernet Pro 100] (rev 0c) 0000:04:0a.0 Ethernet controller: Intel Corp. 82557/8/9 [Ethernet Pro 100] (rev 08) -------------------dmesg ( again ) scheduling while atomic: test-local/0x00000001/3648 [] schedule+0x672/0x680 [] dnotify_parent+0x3a/0xb0 [] _spin_lock+0x16/0x90 [] _spin_unlock_irqrestore+0xf/0x30 [] __mod_timer+0xe9/0x130 [] schedule_timeout+0x72/0xd0 [] process_timeout+0x0/0x10 [] _spin_lock+0x16/0x90 [] proc_thread_write+0x20a/0x2f0 [pktgen] [] _spin_lock+0x16/0x90 [] proc_file_write+0x37/0x50 [] vfs_write+0xae/0x130 [] sys_write+0x51/0x80 [] syscall_call+0x7/0xb ----------------------- cliffw > > > --ro > -- "Ive always gone through periods where I bolt upright at four in the morning; now at least theres a reason." -Michael Feldman --Multipart_Thu__10_Mar_2005_10_48_30_-0800_BLa3zW+zhWEPwmhp Content-Type: text/plain; name=.config Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename=.config Iw0KIyBBdXRvbWF0aWNhbGx5IGdlbmVyYXRlZCBtYWtlIGNvbmZpZzogZG9uJ3QgZWRpdA0KIyBM aW51eCBrZXJuZWwgdmVyc2lvbjogMi42LjExDQojIFR1ZSBNYXIgIDggMTA6MzY6MzkgMjAwNQ0K Iw0KQ09ORklHX1g4Nj15DQpDT05GSUdfTU1VPXkNCkNPTkZJR19VSUQxNj15DQpDT05GSUdfR0VO RVJJQ19JU0FfRE1BPXkNCkNPTkZJR19HRU5FUklDX0lPTUFQPXkNCg0KIw0KIyBDb2RlIG1hdHVy aXR5IGxldmVsIG9wdGlvbnMNCiMNCkNPTkZJR19FWFBFUklNRU5UQUw9eQ0KQ09ORklHX0NMRUFO X0NPTVBJTEU9eQ0KQ09ORklHX0xPQ0tfS0VSTkVMPXkNCg0KIw0KIyBHZW5lcmFsIHNldHVwDQoj DQpDT05GSUdfTE9DQUxWRVJTSU9OPSIiDQpDT05GSUdfU1dBUD15DQpDT05GSUdfU1lTVklQQz15 DQojIENPTkZJR19QT1NJWF9NUVVFVUUgaXMgbm90IHNldA0KQ09ORklHX0JTRF9QUk9DRVNTX0FD Q1Q9eQ0KIyBDT05GSUdfQlNEX1BST0NFU1NfQUNDVF9WMyBpcyBub3Qgc2V0DQpDT05GSUdfU1lT Q1RMPXkNCiMgQ09ORklHX0FVRElUIGlzIG5vdCBzZXQNCkNPTkZJR19MT0dfQlVGX1NISUZUPTE1 DQpDT05GSUdfSE9UUExVRz15DQpDT05GSUdfS09CSkVDVF9VRVZFTlQ9eQ0KIyBDT05GSUdfSUtD T05GSUcgaXMgbm90IHNldA0KIyBDT05GSUdfRU1CRURERUQgaXMgbm90IHNldA0KQ09ORklHX0tB TExTWU1TPXkNCiMgQ09ORklHX0tBTExTWU1TX0FMTCBpcyBub3Qgc2V0DQojIENPTkZJR19LQUxM U1lNU19FWFRSQV9QQVNTIGlzIG5vdCBzZXQNCkNPTkZJR19GVVRFWD15DQpDT05GSUdfRVBPTEw9 eQ0KIyBDT05GSUdfQ0NfT1BUSU1JWkVfRk9SX1NJWkUgaXMgbm90IHNldA0KQ09ORklHX1NITUVN PXkNCkNPTkZJR19DQ19BTElHTl9GVU5DVElPTlM9MA0KQ09ORklHX0NDX0FMSUdOX0xBQkVMUz0w DQpDT05GSUdfQ0NfQUxJR05fTE9PUFM9MA0KQ09ORklHX0NDX0FMSUdOX0pVTVBTPTANCiMgQ09O RklHX1RJTllfU0hNRU0gaXMgbm90IHNldA0KDQojDQojIExvYWRhYmxlIG1vZHVsZSBzdXBwb3J0 DQojDQpDT05GSUdfTU9EVUxFUz15DQojIENPTkZJR19NT0RVTEVfVU5MT0FEIGlzIG5vdCBzZXQN CkNPTkZJR19PQlNPTEVURV9NT0RQQVJNPXkNCkNPTkZJR19NT0RWRVJTSU9OUz15DQojIENPTkZJ R19NT0RVTEVfU1JDVkVSU0lPTl9BTEwgaXMgbm90IHNldA0KQ09ORklHX0tNT0Q9eQ0KDQojDQoj IFByb2Nlc3NvciB0eXBlIGFuZCBmZWF0dXJlcw0KIw0KQ09ORklHX1g4Nl9QQz15DQojIENPTkZJ R19YODZfRUxBTiBpcyBub3Qgc2V0DQojIENPTkZJR19YODZfVk9ZQUdFUiBpcyBub3Qgc2V0DQoj IENPTkZJR19YODZfTlVNQVEgaXMgbm90IHNldA0KIyBDT05GSUdfWDg2X1NVTU1JVCBpcyBub3Qg c2V0DQojIENPTkZJR19YODZfQklHU01QIGlzIG5vdCBzZXQNCiMgQ09ORklHX1g4Nl9WSVNXUyBp cyBub3Qgc2V0DQojIENPTkZJR19YODZfR0VORVJJQ0FSQ0ggaXMgbm90IHNldA0KIyBDT05GSUdf WDg2X0VTNzAwMCBpcyBub3Qgc2V0DQojIENPTkZJR19NMzg2IGlzIG5vdCBzZXQNCiMgQ09ORklH X000ODYgaXMgbm90IHNldA0KIyBDT05GSUdfTTU4NiBpcyBub3Qgc2V0DQojIENPTkZJR19NNTg2 VFNDIGlzIG5vdCBzZXQNCiMgQ09ORklHX001ODZNTVggaXMgbm90IHNldA0KIyBDT05GSUdfTTY4 NiBpcyBub3Qgc2V0DQojIENPTkZJR19NUEVOVElVTUlJIGlzIG5vdCBzZXQNCkNPTkZJR19NUEVO VElVTUlJST15DQojIENPTkZJR19NUEVOVElVTU0gaXMgbm90IHNldA0KIyBDT05GSUdfTVBFTlRJ VU00IGlzIG5vdCBzZXQNCiMgQ09ORklHX01LNiBpcyBub3Qgc2V0DQojIENPTkZJR19NSzcgaXMg bm90IHNldA0KIyBDT05GSUdfTUs4IGlzIG5vdCBzZXQNCiMgQ09ORklHX01DUlVTT0UgaXMgbm90 IHNldA0KIyBDT05GSUdfTUVGRklDRU9OIGlzIG5vdCBzZXQNCiMgQ09ORklHX01XSU5DSElQQzYg aXMgbm90IHNldA0KIyBDT05GSUdfTVdJTkNISVAyIGlzIG5vdCBzZXQNCiMgQ09ORklHX01XSU5D SElQM0QgaXMgbm90IHNldA0KIyBDT05GSUdfTUNZUklYSUlJIGlzIG5vdCBzZXQNCiMgQ09ORklH X01WSUFDM18yIGlzIG5vdCBzZXQNCkNPTkZJR19YODZfR0VORVJJQz15DQpDT05GSUdfWDg2X0NN UFhDSEc9eQ0KQ09ORklHX1g4Nl9YQUREPXkNCkNPTkZJR19YODZfTDFfQ0FDSEVfU0hJRlQ9Nw0K Q09ORklHX1JXU0VNX1hDSEdBRERfQUxHT1JJVEhNPXkNCkNPTkZJR19HRU5FUklDX0NBTElCUkFU RV9ERUxBWT15DQpDT05GSUdfWDg2X1dQX1dPUktTX09LPXkNCkNPTkZJR19YODZfSU5WTFBHPXkN CkNPTkZJR19YODZfQlNXQVA9eQ0KQ09ORklHX1g4Nl9QT1BBRF9PSz15DQpDT05GSUdfWDg2X0dP T0RfQVBJQz15DQpDT05GSUdfWDg2X0lOVEVMX1VTRVJDT1BZPXkNCkNPTkZJR19YODZfVVNFX1BQ Uk9fQ0hFQ0tTVU09eQ0KIyBDT05GSUdfSFBFVF9USU1FUiBpcyBub3Qgc2V0DQpDT05GSUdfU01Q PXkNCkNPTkZJR19OUl9DUFVTPTgNCiMgQ09ORklHX1NDSEVEX1NNVCBpcyBub3Qgc2V0DQpDT05G SUdfUFJFRU1QVD15DQpDT05GSUdfUFJFRU1QVF9CS0w9eQ0KQ09ORklHX1g4Nl9MT0NBTF9BUElD PXkNCkNPTkZJR19YODZfSU9fQVBJQz15DQpDT05GSUdfWDg2X1RTQz15DQpDT05GSUdfWDg2X01D RT15DQojIENPTkZJR19YODZfTUNFX05PTkZBVEFMIGlzIG5vdCBzZXQNCiMgQ09ORklHX1g4Nl9N Q0VfUDRUSEVSTUFMIGlzIG5vdCBzZXQNCiMgQ09ORklHX1RPU0hJQkEgaXMgbm90IHNldA0KIyBD T05GSUdfSThLIGlzIG5vdCBzZXQNCkNPTkZJR19NSUNST0NPREU9eQ0KQ09ORklHX1g4Nl9NU1I9 eQ0KQ09ORklHX1g4Nl9DUFVJRD15DQoNCiMNCiMgRmlybXdhcmUgRHJpdmVycw0KIw0KIyBDT05G SUdfRUREIGlzIG5vdCBzZXQNCiMgQ09ORklHX05PSElHSE1FTSBpcyBub3Qgc2V0DQpDT05GSUdf SElHSE1FTTRHPXkNCiMgQ09ORklHX0hJR0hNRU02NEcgaXMgbm90IHNldA0KQ09ORklHX0hJR0hN RU09eQ0KIyBDT05GSUdfSElHSFBURSBpcyBub3Qgc2V0DQojIENPTkZJR19NQVRIX0VNVUxBVElP TiBpcyBub3Qgc2V0DQpDT05GSUdfTVRSUj15DQojIENPTkZJR19FRkkgaXMgbm90IHNldA0KQ09O RklHX0lSUUJBTEFOQ0U9eQ0KQ09ORklHX0hBVkVfREVDX0xPQ0s9eQ0KIyBDT05GSUdfUkVHUEFS TSBpcyBub3Qgc2V0DQoNCiMNCiMgUG93ZXIgbWFuYWdlbWVudCBvcHRpb25zIChBQ1BJLCBBUE0p DQojDQpDT05GSUdfUE09eQ0KIyBDT05GSUdfUE1fREVCVUcgaXMgbm90IHNldA0KIyBDT05GSUdf U09GVFdBUkVfU1VTUEVORCBpcyBub3Qgc2V0DQoNCiMNCiMgQUNQSSAoQWR2YW5jZWQgQ29uZmln dXJhdGlvbiBhbmQgUG93ZXIgSW50ZXJmYWNlKSBTdXBwb3J0DQojDQpDT05GSUdfQUNQST15DQpD T05GSUdfQUNQSV9CT09UPXkNCkNPTkZJR19BQ1BJX0lOVEVSUFJFVEVSPXkNCiMgQ09ORklHX0FD UElfU0xFRVAgaXMgbm90IHNldA0KIyBDT05GSUdfQUNQSV9BQyBpcyBub3Qgc2V0DQojIENPTkZJ R19BQ1BJX0JBVFRFUlkgaXMgbm90IHNldA0KIyBDT05GSUdfQUNQSV9CVVRUT04gaXMgbm90IHNl dA0KQ09ORklHX0FDUElfVklERU89bQ0KIyBDT05GSUdfQUNQSV9GQU4gaXMgbm90IHNldA0KQ09O RklHX0FDUElfUFJPQ0VTU09SPXkNCiMgQ09ORklHX0FDUElfVEhFUk1BTCBpcyBub3Qgc2V0DQoj IENPTkZJR19BQ1BJX0FTVVMgaXMgbm90IHNldA0KQ09ORklHX0FDUElfSUJNPW0NCiMgQ09ORklH X0FDUElfVE9TSElCQSBpcyBub3Qgc2V0DQpDT05GSUdfQUNQSV9CTEFDS0xJU1RfWUVBUj0wDQoj IENPTkZJR19BQ1BJX0RFQlVHIGlzIG5vdCBzZXQNCkNPTkZJR19BQ1BJX0JVUz15DQpDT05GSUdf QUNQSV9FQz15DQpDT05GSUdfQUNQSV9QT1dFUj15DQpDT05GSUdfQUNQSV9QQ0k9eQ0KQ09ORklH X0FDUElfU1lTVEVNPXkNCiMgQ09ORklHX1g4Nl9QTV9USU1FUiBpcyBub3Qgc2V0DQojIENPTkZJ R19BQ1BJX0NPTlRBSU5FUiBpcyBub3Qgc2V0DQoNCiMNCiMgQVBNIChBZHZhbmNlZCBQb3dlciBN YW5hZ2VtZW50KSBCSU9TIFN1cHBvcnQNCiMNCkNPTkZJR19BUE09eQ0KIyBDT05GSUdfQVBNX0lH Tk9SRV9VU0VSX1NVU1BFTkQgaXMgbm90IHNldA0KIyBDT05GSUdfQVBNX0RPX0VOQUJMRSBpcyBu b3Qgc2V0DQpDT05GSUdfQVBNX0NQVV9JRExFPXkNCiMgQ09ORklHX0FQTV9ESVNQTEFZX0JMQU5L IGlzIG5vdCBzZXQNCiMgQ09ORklHX0FQTV9SVENfSVNfR01UIGlzIG5vdCBzZXQNCiMgQ09ORklH X0FQTV9BTExPV19JTlRTIGlzIG5vdCBzZXQNCkNPTkZJR19BUE1fUkVBTF9NT0RFX1BPV0VSX09G Rj15DQoNCiMNCiMgQ1BVIEZyZXF1ZW5jeSBzY2FsaW5nDQojDQojIENPTkZJR19DUFVfRlJFUSBp cyBub3Qgc2V0DQoNCiMNCiMgQnVzIG9wdGlvbnMgKFBDSSwgUENNQ0lBLCBFSVNBLCBNQ0EsIElT QSkNCiMNCkNPTkZJR19QQ0k9eQ0KIyBDT05GSUdfUENJX0dPQklPUyBpcyBub3Qgc2V0DQojIENP TkZJR19QQ0lfR09NTUNPTkZJRyBpcyBub3Qgc2V0DQojIENPTkZJR19QQ0lfR09ESVJFQ1QgaXMg bm90IHNldA0KQ09ORklHX1BDSV9HT0FOWT15DQpDT05GSUdfUENJX0JJT1M9eQ0KQ09ORklHX1BD SV9ESVJFQ1Q9eQ0KQ09ORklHX1BDSV9NTUNPTkZJRz15DQojIENPTkZJR19QQ0lFUE9SVEJVUyBp cyBub3Qgc2V0DQojIENPTkZJR19QQ0lfTVNJIGlzIG5vdCBzZXQNCiMgQ09ORklHX1BDSV9MRUdB Q1lfUFJPQyBpcyBub3Qgc2V0DQpDT05GSUdfUENJX05BTUVTPXkNCkNPTkZJR19JU0E9eQ0KQ09O RklHX0VJU0E9eQ0KIyBDT05GSUdfRUlTQV9WTEJfUFJJTUlORyBpcyBub3Qgc2V0DQpDT05GSUdf RUlTQV9QQ0lfRUlTQT15DQojIENPTkZJR19FSVNBX1ZJUlRVQUxfUk9PVCBpcyBub3Qgc2V0DQoj IENPTkZJR19FSVNBX05BTUVTIGlzIG5vdCBzZXQNCiMgQ09ORklHX01DQSBpcyBub3Qgc2V0DQoj IENPTkZJR19TQ3gyMDAgaXMgbm90IHNldA0KDQojDQojIFBDQ0FSRCAoUENNQ0lBL0NhcmRCdXMp IHN1cHBvcnQNCiMNCiMgQ09ORklHX1BDQ0FSRCBpcyBub3Qgc2V0DQoNCiMNCiMgUEMtY2FyZCBi cmlkZ2VzDQojDQpDT05GSUdfUENNQ0lBX1BST0JFPXkNCg0KIw0KIyBQQ0kgSG90cGx1ZyBTdXBw b3J0DQojDQojIENPTkZJR19IT1RQTFVHX1BDSSBpcyBub3Qgc2V0DQoNCiMNCiMgRXhlY3V0YWJs ZSBmaWxlIGZvcm1hdHMNCiMNCkNPTkZJR19CSU5GTVRfRUxGPXkNCkNPTkZJR19CSU5GTVRfQU9V VD1tDQpDT05GSUdfQklORk1UX01JU0M9bQ0KDQojDQojIERldmljZSBEcml2ZXJzDQojDQoNCiMN CiMgR2VuZXJpYyBEcml2ZXIgT3B0aW9ucw0KIw0KQ09ORklHX1NUQU5EQUxPTkU9eQ0KQ09ORklH X1BSRVZFTlRfRklSTVdBUkVfQlVJTEQ9eQ0KQ09ORklHX0ZXX0xPQURFUj15DQojIENPTkZJR19E RUJVR19EUklWRVIgaXMgbm90IHNldA0KDQojDQojIE1lbW9yeSBUZWNobm9sb2d5IERldmljZXMg KE1URCkNCiMNCiMgQ09ORklHX01URCBpcyBub3Qgc2V0DQoNCiMNCiMgUGFyYWxsZWwgcG9ydCBz dXBwb3J0DQojDQojIENPTkZJR19QQVJQT1JUIGlzIG5vdCBzZXQNCg0KIw0KIyBQbHVnIGFuZCBQ bGF5IHN1cHBvcnQNCiMNCkNPTkZJR19QTlA9eQ0KIyBDT05GSUdfUE5QX0RFQlVHIGlzIG5vdCBz ZXQNCg0KIw0KIyBQcm90b2NvbHMNCiMNCiMgQ09ORklHX0lTQVBOUCBpcyBub3Qgc2V0DQojIENP TkZJR19QTlBCSU9TIGlzIG5vdCBzZXQNCkNPTkZJR19QTlBBQ1BJPXkNCg0KIw0KIyBCbG9jayBk ZXZpY2VzDQojDQpDT05GSUdfQkxLX0RFVl9GRD15DQojIENPTkZJR19CTEtfREVWX1hEIGlzIG5v dCBzZXQNCiMgQ09ORklHX0JMS19DUFFfREEgaXMgbm90IHNldA0KIyBDT05GSUdfQkxLX0NQUV9D SVNTX0RBIGlzIG5vdCBzZXQNCiMgQ09ORklHX0JMS19ERVZfREFDOTYwIGlzIG5vdCBzZXQNCiMg Q09ORklHX0JMS19ERVZfVU1FTSBpcyBub3Qgc2V0DQojIENPTkZJR19CTEtfREVWX0NPV19DT01N T04gaXMgbm90IHNldA0KQ09ORklHX0JMS19ERVZfTE9PUD15DQojIENPTkZJR19CTEtfREVWX0NS WVBUT0xPT1AgaXMgbm90IHNldA0KIyBDT05GSUdfQkxLX0RFVl9OQkQgaXMgbm90IHNldA0KIyBD T05GSUdfQkxLX0RFVl9TWDggaXMgbm90IHNldA0KIyBDT05GSUdfQkxLX0RFVl9VQiBpcyBub3Qg c2V0DQojIENPTkZJR19CTEtfREVWX1JBTSBpcyBub3Qgc2V0DQpDT05GSUdfQkxLX0RFVl9SQU1f Q09VTlQ9MTYNCkNPTkZJR19JTklUUkFNRlNfU09VUkNFPSIiDQojIENPTkZJR19MQkQgaXMgbm90 IHNldA0KIyBDT05GSUdfQ0RST01fUEtUQ0RWRCBpcyBub3Qgc2V0DQoNCiMNCiMgSU8gU2NoZWR1 bGVycw0KIw0KQ09ORklHX0lPU0NIRURfTk9PUD15DQpDT05GSUdfSU9TQ0hFRF9BUz15DQpDT05G SUdfSU9TQ0hFRF9ERUFETElORT15DQpDT05GSUdfSU9TQ0hFRF9DRlE9eQ0KIyBDT05GSUdfQVRB X09WRVJfRVRIIGlzIG5vdCBzZXQNCg0KIw0KIyBBVEEvQVRBUEkvTUZNL1JMTCBzdXBwb3J0DQoj DQpDT05GSUdfSURFPXkNCkNPTkZJR19CTEtfREVWX0lERT15DQoNCiMNCiMgUGxlYXNlIHNlZSBE b2N1bWVudGF0aW9uL2lkZS50eHQgZm9yIGhlbHAvaW5mbyBvbiBJREUgZHJpdmVzDQojDQojIENP TkZJR19CTEtfREVWX0lERV9TQVRBIGlzIG5vdCBzZXQNCiMgQ09ORklHX0JMS19ERVZfSERfSURF IGlzIG5vdCBzZXQNCkNPTkZJR19CTEtfREVWX0lERURJU0s9eQ0KQ09ORklHX0lERURJU0tfTVVM VElfTU9ERT15DQpDT05GSUdfQkxLX0RFVl9JREVDRD15DQojIENPTkZJR19CTEtfREVWX0lERVRB UEUgaXMgbm90IHNldA0KQ09ORklHX0JMS19ERVZfSURFRkxPUFBZPXkNCiMgQ09ORklHX0JMS19E RVZfSURFU0NTSSBpcyBub3Qgc2V0DQpDT05GSUdfSURFX1RBU0tfSU9DVEw9eQ0KDQojDQojIElE RSBjaGlwc2V0IHN1cHBvcnQvYnVnZml4ZXMNCiMNCkNPTkZJR19JREVfR0VORVJJQz15DQpDT05G SUdfQkxLX0RFVl9DTUQ2NDA9eQ0KIyBDT05GSUdfQkxLX0RFVl9DTUQ2NDBfRU5IQU5DRUQgaXMg bm90IHNldA0KIyBDT05GSUdfQkxLX0RFVl9JREVQTlAgaXMgbm90IHNldA0KQ09ORklHX0JMS19E RVZfSURFUENJPXkNCkNPTkZJR19JREVQQ0lfU0hBUkVfSVJRPXkNCiMgQ09ORklHX0JMS19ERVZf T0ZGQk9BUkQgaXMgbm90IHNldA0KQ09ORklHX0JMS19ERVZfR0VORVJJQz15DQojIENPTkZJR19C TEtfREVWX09QVEk2MjEgaXMgbm90IHNldA0KIyBDT05GSUdfQkxLX0RFVl9SWjEwMDAgaXMgbm90 IHNldA0KQ09ORklHX0JMS19ERVZfSURFRE1BX1BDST15DQojIENPTkZJR19CTEtfREVWX0lERURN QV9GT1JDRUQgaXMgbm90IHNldA0KQ09ORklHX0lERURNQV9QQ0lfQVVUTz15DQojIENPTkZJR19J REVETUFfT05MWURJU0sgaXMgbm90IHNldA0KIyBDT05GSUdfQkxLX0RFVl9BRUM2MlhYIGlzIG5v dCBzZXQNCiMgQ09ORklHX0JMS19ERVZfQUxJMTVYMyBpcyBub3Qgc2V0DQojIENPTkZJR19CTEtf REVWX0FNRDc0WFggaXMgbm90IHNldA0KIyBDT05GSUdfQkxLX0RFVl9BVElJWFAgaXMgbm90IHNl dA0KIyBDT05GSUdfQkxLX0RFVl9DTUQ2NFggaXMgbm90IHNldA0KIyBDT05GSUdfQkxLX0RFVl9U UklGTEVYIGlzIG5vdCBzZXQNCiMgQ09ORklHX0JMS19ERVZfQ1k4MkM2OTMgaXMgbm90IHNldA0K IyBDT05GSUdfQkxLX0RFVl9DUzU1MjAgaXMgbm90IHNldA0KIyBDT05GSUdfQkxLX0RFVl9DUzU1 MzAgaXMgbm90IHNldA0KIyBDT05GSUdfQkxLX0RFVl9IUFQzNFggaXMgbm90IHNldA0KIyBDT05G SUdfQkxLX0RFVl9IUFQzNjYgaXMgbm90IHNldA0KIyBDT05GSUdfQkxLX0RFVl9TQzEyMDAgaXMg bm90IHNldA0KQ09ORklHX0JMS19ERVZfUElJWD15DQojIENPTkZJR19CTEtfREVWX05TODc0MTUg aXMgbm90IHNldA0KIyBDT05GSUdfQkxLX0RFVl9QREMyMDJYWF9PTEQgaXMgbm90IHNldA0KIyBD T05GSUdfQkxLX0RFVl9QREMyMDJYWF9ORVcgaXMgbm90IHNldA0KQ09ORklHX0JMS19ERVZfU1ZX S1M9eQ0KIyBDT05GSUdfQkxLX0RFVl9TSUlNQUdFIGlzIG5vdCBzZXQNCiMgQ09ORklHX0JMS19E RVZfU0lTNTUxMyBpcyBub3Qgc2V0DQojIENPTkZJR19CTEtfREVWX1NMQzkwRTY2IGlzIG5vdCBz ZXQNCiMgQ09ORklHX0JMS19ERVZfVFJNMjkwIGlzIG5vdCBzZXQNCiMgQ09ORklHX0JMS19ERVZf VklBODJDWFhYIGlzIG5vdCBzZXQNCiMgQ09ORklHX0lERV9BUk0gaXMgbm90IHNldA0KIyBDT05G SUdfSURFX0NISVBTRVRTIGlzIG5vdCBzZXQNCkNPTkZJR19CTEtfREVWX0lERURNQT15DQojIENP TkZJR19JREVETUFfSVZCIGlzIG5vdCBzZXQNCkNPTkZJR19JREVETUFfQVVUTz15DQojIENPTkZJ R19CTEtfREVWX0hEIGlzIG5vdCBzZXQNCg0KIw0KIyBTQ1NJIGRldmljZSBzdXBwb3J0DQojDQpD T05GSUdfU0NTST1tDQpDT05GSUdfU0NTSV9QUk9DX0ZTPXkNCg0KIw0KIyBTQ1NJIHN1cHBvcnQg dHlwZSAoZGlzaywgdGFwZSwgQ0QtUk9NKQ0KIw0KIyBDT05GSUdfQkxLX0RFVl9TRCBpcyBub3Qg c2V0DQojIENPTkZJR19DSFJfREVWX1NUIGlzIG5vdCBzZXQNCiMgQ09ORklHX0NIUl9ERVZfT1NT VCBpcyBub3Qgc2V0DQojIENPTkZJR19CTEtfREVWX1NSIGlzIG5vdCBzZXQNCiMgQ09ORklHX0NI Ul9ERVZfU0cgaXMgbm90IHNldA0KDQojDQojIFNvbWUgU0NTSSBkZXZpY2VzIChlLmcuIENEIGp1 a2Vib3gpIHN1cHBvcnQgbXVsdGlwbGUgTFVOcw0KIw0KIyBDT05GSUdfU0NTSV9NVUxUSV9MVU4g aXMgbm90IHNldA0KIyBDT05GSUdfU0NTSV9DT05TVEFOVFMgaXMgbm90IHNldA0KIyBDT05GSUdf U0NTSV9MT0dHSU5HIGlzIG5vdCBzZXQNCg0KIw0KIyBTQ1NJIFRyYW5zcG9ydCBBdHRyaWJ1dGVz DQojDQojIENPTkZJR19TQ1NJX1NQSV9BVFRSUyBpcyBub3Qgc2V0DQojIENPTkZJR19TQ1NJX0ZD X0FUVFJTIGlzIG5vdCBzZXQNCiMgQ09ORklHX1NDU0lfSVNDU0lfQVRUUlMgaXMgbm90IHNldA0K DQojDQojIFNDU0kgbG93LWxldmVsIGRyaXZlcnMNCiMNCiMgQ09ORklHX0JMS19ERVZfM1dfWFhY WF9SQUlEIGlzIG5vdCBzZXQNCiMgQ09ORklHX1NDU0lfM1dfOVhYWCBpcyBub3Qgc2V0DQojIENP TkZJR19TQ1NJXzcwMDBGQVNTVCBpcyBub3Qgc2V0DQojIENPTkZJR19TQ1NJX0FDQVJEIGlzIG5v dCBzZXQNCiMgQ09ORklHX1NDU0lfQUhBMTUyWCBpcyBub3Qgc2V0DQojIENPTkZJR19TQ1NJX0FI QTE1NDIgaXMgbm90IHNldA0KIyBDT05GSUdfU0NTSV9BSEExNzQwIGlzIG5vdCBzZXQNCiMgQ09O RklHX1NDU0lfQUFDUkFJRCBpcyBub3Qgc2V0DQojIENPTkZJR19TQ1NJX0FJQzdYWFggaXMgbm90 IHNldA0KIyBDT05GSUdfU0NTSV9BSUM3WFhYX09MRCBpcyBub3Qgc2V0DQojIENPTkZJR19TQ1NJ X0FJQzc5WFggaXMgbm90IHNldA0KIyBDT05GSUdfU0NTSV9EUFRfSTJPIGlzIG5vdCBzZXQNCiMg Q09ORklHX1NDU0lfSU4yMDAwIGlzIG5vdCBzZXQNCiMgQ09ORklHX01FR0FSQUlEX05FV0dFTiBp cyBub3Qgc2V0DQojIENPTkZJR19NRUdBUkFJRF9MRUdBQ1kgaXMgbm90IHNldA0KIyBDT05GSUdf U0NTSV9TQVRBIGlzIG5vdCBzZXQNCiMgQ09ORklHX1NDU0lfQlVTTE9HSUMgaXMgbm90IHNldA0K IyBDT05GSUdfU0NTSV9ETVgzMTkxRCBpcyBub3Qgc2V0DQojIENPTkZJR19TQ1NJX0RUQzMyODAg aXMgbm90IHNldA0KIyBDT05GSUdfU0NTSV9FQVRBIGlzIG5vdCBzZXQNCiMgQ09ORklHX1NDU0lf RUFUQV9QSU8gaXMgbm90IHNldA0KIyBDT05GSUdfU0NTSV9GVVRVUkVfRE9NQUlOIGlzIG5vdCBz ZXQNCiMgQ09ORklHX1NDU0lfR0RUSCBpcyBub3Qgc2V0DQojIENPTkZJR19TQ1NJX0dFTkVSSUNf TkNSNTM4MCBpcyBub3Qgc2V0DQojIENPTkZJR19TQ1NJX0dFTkVSSUNfTkNSNTM4MF9NTUlPIGlz IG5vdCBzZXQNCiMgQ09ORklHX1NDU0lfSVBTIGlzIG5vdCBzZXQNCiMgQ09ORklHX1NDU0lfSU5J VElPIGlzIG5vdCBzZXQNCiMgQ09ORklHX1NDU0lfSU5JQTEwMCBpcyBub3Qgc2V0DQojIENPTkZJ R19TQ1NJX05DUjUzQzQwNkEgaXMgbm90IHNldA0KIyBDT05GSUdfU0NTSV9TWU01M0M4WFhfMiBp cyBub3Qgc2V0DQojIENPTkZJR19TQ1NJX0lQUiBpcyBub3Qgc2V0DQojIENPTkZJR19TQ1NJX1BB UzE2IGlzIG5vdCBzZXQNCiMgQ09ORklHX1NDU0lfUFNJMjQwSSBpcyBub3Qgc2V0DQojIENPTkZJ R19TQ1NJX1FMT0dJQ19GQVMgaXMgbm90IHNldA0KIyBDT05GSUdfU0NTSV9RTE9HSUNfSVNQIGlz IG5vdCBzZXQNCiMgQ09ORklHX1NDU0lfUUxPR0lDX0ZDIGlzIG5vdCBzZXQNCiMgQ09ORklHX1ND U0lfUUxPR0lDXzEyODAgaXMgbm90IHNldA0KQ09ORklHX1NDU0lfUUxBMlhYWD1tDQojIENPTkZJ R19TQ1NJX1FMQTIxWFggaXMgbm90IHNldA0KIyBDT05GSUdfU0NTSV9RTEEyMlhYIGlzIG5vdCBz ZXQNCiMgQ09ORklHX1NDU0lfUUxBMjMwMCBpcyBub3Qgc2V0DQojIENPTkZJR19TQ1NJX1FMQTIz MjIgaXMgbm90IHNldA0KIyBDT05GSUdfU0NTSV9RTEE2MzEyIGlzIG5vdCBzZXQNCiMgQ09ORklH X1NDU0lfU0lNNzEwIGlzIG5vdCBzZXQNCiMgQ09ORklHX1NDU0lfU1lNNTNDNDE2IGlzIG5vdCBz ZXQNCiMgQ09ORklHX1NDU0lfREMzOTV4IGlzIG5vdCBzZXQNCiMgQ09ORklHX1NDU0lfREMzOTBU IGlzIG5vdCBzZXQNCiMgQ09ORklHX1NDU0lfVDEyOCBpcyBub3Qgc2V0DQojIENPTkZJR19TQ1NJ X1UxNF8zNEYgaXMgbm90IHNldA0KIyBDT05GSUdfU0NTSV9VTFRSQVNUT1IgaXMgbm90IHNldA0K IyBDT05GSUdfU0NTSV9OU1AzMiBpcyBub3Qgc2V0DQojIENPTkZJR19TQ1NJX0RFQlVHIGlzIG5v dCBzZXQNCg0KIw0KIyBPbGQgQ0QtUk9NIGRyaXZlcnMgKG5vdCBTQ1NJLCBub3QgSURFKQ0KIw0K IyBDT05GSUdfQ0RfTk9fSURFU0NTSSBpcyBub3Qgc2V0DQoNCiMNCiMgTXVsdGktZGV2aWNlIHN1 cHBvcnQgKFJBSUQgYW5kIExWTSkNCiMNCiMgQ09ORklHX01EIGlzIG5vdCBzZXQNCg0KIw0KIyBG dXNpb24gTVBUIGRldmljZSBzdXBwb3J0DQojDQojIENPTkZJR19GVVNJT04gaXMgbm90IHNldA0K DQojDQojIElFRUUgMTM5NCAoRmlyZVdpcmUpIHN1cHBvcnQNCiMNCiMgQ09ORklHX0lFRUUxMzk0 IGlzIG5vdCBzZXQNCg0KIw0KIyBJMk8gZGV2aWNlIHN1cHBvcnQNCiMNCiMgQ09ORklHX0kyTyBp cyBub3Qgc2V0DQoNCiMNCiMgTmV0d29ya2luZyBzdXBwb3J0DQojDQpDT05GSUdfTkVUPXkNCg0K Iw0KIyBOZXR3b3JraW5nIG9wdGlvbnMNCiMNCkNPTkZJR19QQUNLRVQ9eQ0KQ09ORklHX1BBQ0tF VF9NTUFQPXkNCkNPTkZJR19ORVRMSU5LX0RFVj15DQpDT05GSUdfVU5JWD15DQojIENPTkZJR19O RVRfS0VZIGlzIG5vdCBzZXQNCkNPTkZJR19JTkVUPXkNCiMgQ09ORklHX0lQX01VTFRJQ0FTVCBp cyBub3Qgc2V0DQojIENPTkZJR19JUF9BRFZBTkNFRF9ST1VURVIgaXMgbm90IHNldA0KIyBDT05G SUdfSVBfUE5QIGlzIG5vdCBzZXQNCiMgQ09ORklHX05FVF9JUElQIGlzIG5vdCBzZXQNCiMgQ09O RklHX05FVF9JUEdSRSBpcyBub3Qgc2V0DQojIENPTkZJR19BUlBEIGlzIG5vdCBzZXQNCkNPTkZJ R19TWU5fQ09PS0lFUz15DQojIENPTkZJR19JTkVUX0FIIGlzIG5vdCBzZXQNCiMgQ09ORklHX0lO RVRfRVNQIGlzIG5vdCBzZXQNCiMgQ09ORklHX0lORVRfSVBDT01QIGlzIG5vdCBzZXQNCiMgQ09O RklHX0lORVRfVFVOTkVMIGlzIG5vdCBzZXQNCkNPTkZJR19JUF9UQ1BESUFHPXkNCiMgQ09ORklH X0lQX1RDUERJQUdfSVBWNiBpcyBub3Qgc2V0DQoNCiMNCiMgSVA6IFZpcnR1YWwgU2VydmVyIENv bmZpZ3VyYXRpb24NCiMNCiMgQ09ORklHX0lQX1ZTIGlzIG5vdCBzZXQNCiMgQ09ORklHX0lQVjYg aXMgbm90IHNldA0KQ09ORklHX05FVEZJTFRFUj15DQojIENPTkZJR19ORVRGSUxURVJfREVCVUcg aXMgbm90IHNldA0KDQojDQojIElQOiBOZXRmaWx0ZXIgQ29uZmlndXJhdGlvbg0KIw0KQ09ORklH X0lQX05GX0NPTk5UUkFDSz1tDQojIENPTkZJR19JUF9ORl9DVF9BQ0NUIGlzIG5vdCBzZXQNCiMg Q09ORklHX0lQX05GX0NPTk5UUkFDS19NQVJLIGlzIG5vdCBzZXQNCiMgQ09ORklHX0lQX05GX0NU X1BST1RPX1NDVFAgaXMgbm90IHNldA0KQ09ORklHX0lQX05GX0ZUUD1tDQpDT05GSUdfSVBfTkZf SVJDPW0NCkNPTkZJR19JUF9ORl9URlRQPW0NCkNPTkZJR19JUF9ORl9BTUFOREE9bQ0KQ09ORklH X0lQX05GX1FVRVVFPW0NCkNPTkZJR19JUF9ORl9JUFRBQkxFUz1tDQpDT05GSUdfSVBfTkZfTUFU Q0hfTElNSVQ9bQ0KIyBDT05GSUdfSVBfTkZfTUFUQ0hfSVBSQU5HRSBpcyBub3Qgc2V0DQpDT05G SUdfSVBfTkZfTUFUQ0hfTUFDPW0NCkNPTkZJR19JUF9ORl9NQVRDSF9QS1RUWVBFPW0NCkNPTkZJ R19JUF9ORl9NQVRDSF9NQVJLPW0NCkNPTkZJR19JUF9ORl9NQVRDSF9NVUxUSVBPUlQ9bQ0KQ09O RklHX0lQX05GX01BVENIX1RPUz1tDQojIENPTkZJR19JUF9ORl9NQVRDSF9SRUNFTlQgaXMgbm90 IHNldA0KQ09ORklHX0lQX05GX01BVENIX0VDTj1tDQpDT05GSUdfSVBfTkZfTUFUQ0hfRFNDUD1t DQpDT05GSUdfSVBfTkZfTUFUQ0hfQUhfRVNQPW0NCkNPTkZJR19JUF9ORl9NQVRDSF9MRU5HVEg9 bQ0KQ09ORklHX0lQX05GX01BVENIX1RUTD1tDQpDT05GSUdfSVBfTkZfTUFUQ0hfVENQTVNTPW0N CkNPTkZJR19JUF9ORl9NQVRDSF9IRUxQRVI9bQ0KQ09ORklHX0lQX05GX01BVENIX1NUQVRFPW0N CkNPTkZJR19JUF9ORl9NQVRDSF9DT05OVFJBQ0s9bQ0KQ09ORklHX0lQX05GX01BVENIX09XTkVS PW0NCiMgQ09ORklHX0lQX05GX01BVENIX0FERFJUWVBFIGlzIG5vdCBzZXQNCiMgQ09ORklHX0lQ X05GX01BVENIX1JFQUxNIGlzIG5vdCBzZXQNCiMgQ09ORklHX0lQX05GX01BVENIX1NDVFAgaXMg bm90IHNldA0KIyBDT05GSUdfSVBfTkZfTUFUQ0hfQ09NTUVOVCBpcyBub3Qgc2V0DQojIENPTkZJ R19JUF9ORl9NQVRDSF9IQVNITElNSVQgaXMgbm90IHNldA0KQ09ORklHX0lQX05GX0ZJTFRFUj1t DQpDT05GSUdfSVBfTkZfVEFSR0VUX1JFSkVDVD1tDQpDT05GSUdfSVBfTkZfVEFSR0VUX0xPRz1t DQpDT05GSUdfSVBfTkZfVEFSR0VUX1VMT0c9bQ0KQ09ORklHX0lQX05GX1RBUkdFVF9UQ1BNU1M9 bQ0KQ09ORklHX0lQX05GX05BVD1tDQpDT05GSUdfSVBfTkZfTkFUX05FRURFRD15DQpDT05GSUdf SVBfTkZfVEFSR0VUX01BU1FVRVJBREU9bQ0KQ09ORklHX0lQX05GX1RBUkdFVF9SRURJUkVDVD1t DQojIENPTkZJR19JUF9ORl9UQVJHRVRfTkVUTUFQIGlzIG5vdCBzZXQNCiMgQ09ORklHX0lQX05G X1RBUkdFVF9TQU1FIGlzIG5vdCBzZXQNCkNPTkZJR19JUF9ORl9OQVRfU05NUF9CQVNJQz1tDQpD T05GSUdfSVBfTkZfTkFUX0lSQz1tDQpDT05GSUdfSVBfTkZfTkFUX0ZUUD1tDQpDT05GSUdfSVBf TkZfTkFUX1RGVFA9bQ0KQ09ORklHX0lQX05GX05BVF9BTUFOREE9bQ0KQ09ORklHX0lQX05GX01B TkdMRT1tDQpDT05GSUdfSVBfTkZfVEFSR0VUX1RPUz1tDQpDT05GSUdfSVBfTkZfVEFSR0VUX0VD Tj1tDQpDT05GSUdfSVBfTkZfVEFSR0VUX0RTQ1A9bQ0KQ09ORklHX0lQX05GX1RBUkdFVF9NQVJL PW0NCiMgQ09ORklHX0lQX05GX1RBUkdFVF9DTEFTU0lGWSBpcyBub3Qgc2V0DQojIENPTkZJR19J UF9ORl9SQVcgaXMgbm90IHNldA0KQ09ORklHX0lQX05GX0FSUFRBQkxFUz1tDQpDT05GSUdfSVBf TkZfQVJQRklMVEVSPW0NCiMgQ09ORklHX0lQX05GX0FSUF9NQU5HTEUgaXMgbm90IHNldA0KDQoj DQojIFNDVFAgQ29uZmlndXJhdGlvbiAoRVhQRVJJTUVOVEFMKQ0KIw0KIyBDT05GSUdfSVBfU0NU UCBpcyBub3Qgc2V0DQojIENPTkZJR19BVE0gaXMgbm90IHNldA0KIyBDT05GSUdfQlJJREdFIGlz IG5vdCBzZXQNCiMgQ09ORklHX1ZMQU5fODAyMVEgaXMgbm90IHNldA0KIyBDT05GSUdfREVDTkVU IGlzIG5vdCBzZXQNCiMgQ09ORklHX0xMQzIgaXMgbm90IHNldA0KIyBDT05GSUdfSVBYIGlzIG5v dCBzZXQNCiMgQ09ORklHX0FUQUxLIGlzIG5vdCBzZXQNCiMgQ09ORklHX1gyNSBpcyBub3Qgc2V0 DQojIENPTkZJR19MQVBCIGlzIG5vdCBzZXQNCiMgQ09ORklHX05FVF9ESVZFUlQgaXMgbm90IHNl dA0KIyBDT05GSUdfRUNPTkVUIGlzIG5vdCBzZXQNCiMgQ09ORklHX1dBTl9ST1VURVIgaXMgbm90 IHNldA0KDQojDQojIFFvUyBhbmQvb3IgZmFpciBxdWV1ZWluZw0KIw0KIyBDT05GSUdfTkVUX1ND SEVEIGlzIG5vdCBzZXQNCiMgQ09ORklHX05FVF9DTFNfUk9VVEUgaXMgbm90IHNldA0KDQojDQoj IE5ldHdvcmsgdGVzdGluZw0KIw0KQ09ORklHX05FVF9QS1RHRU49bQ0KIyBDT05GSUdfTkVUUE9M TCBpcyBub3Qgc2V0DQojIENPTkZJR19ORVRfUE9MTF9DT05UUk9MTEVSIGlzIG5vdCBzZXQNCiMg Q09ORklHX0hBTVJBRElPIGlzIG5vdCBzZXQNCiMgQ09ORklHX0lSREEgaXMgbm90IHNldA0KIyBD T05GSUdfQlQgaXMgbm90IHNldA0KQ09ORklHX05FVERFVklDRVM9eQ0KIyBDT05GSUdfRFVNTVkg aXMgbm90IHNldA0KIyBDT05GSUdfQk9ORElORyBpcyBub3Qgc2V0DQojIENPTkZJR19FUVVBTEla RVIgaXMgbm90IHNldA0KIyBDT05GSUdfVFVOIGlzIG5vdCBzZXQNCiMgQ09ORklHX0VUSEVSVEFQ IGlzIG5vdCBzZXQNCiMgQ09ORklHX05FVF9TQjEwMDAgaXMgbm90IHNldA0KDQojDQojIEFSQ25l dCBkZXZpY2VzDQojDQojIENPTkZJR19BUkNORVQgaXMgbm90IHNldA0KDQojDQojIEV0aGVybmV0 ICgxMCBvciAxMDBNYml0KQ0KIw0KQ09ORklHX05FVF9FVEhFUk5FVD15DQpDT05GSUdfTUlJPW0N CiMgQ09ORklHX0hBUFBZTUVBTCBpcyBub3Qgc2V0DQojIENPTkZJR19TVU5HRU0gaXMgbm90IHNl dA0KIyBDT05GSUdfTkVUX1ZFTkRPUl8zQ09NIGlzIG5vdCBzZXQNCiMgQ09ORklHX0xBTkNFIGlz IG5vdCBzZXQNCiMgQ09ORklHX05FVF9WRU5ET1JfU01DIGlzIG5vdCBzZXQNCiMgQ09ORklHX05F VF9WRU5ET1JfUkFDQUwgaXMgbm90IHNldA0KDQojDQojIFR1bGlwIGZhbWlseSBuZXR3b3JrIGRl dmljZSBzdXBwb3J0DQojDQojIENPTkZJR19ORVRfVFVMSVAgaXMgbm90IHNldA0KIyBDT05GSUdf QVQxNzAwIGlzIG5vdCBzZXQNCiMgQ09ORklHX0RFUENBIGlzIG5vdCBzZXQNCiMgQ09ORklHX0hQ MTAwIGlzIG5vdCBzZXQNCiMgQ09ORklHX05FVF9JU0EgaXMgbm90IHNldA0KQ09ORklHX05FVF9Q Q0k9eQ0KIyBDT05GSUdfUENORVQzMiBpcyBub3Qgc2V0DQojIENPTkZJR19BTUQ4MTExX0VUSCBp cyBub3Qgc2V0DQojIENPTkZJR19BREFQVEVDX1NUQVJGSVJFIGlzIG5vdCBzZXQNCiMgQ09ORklH X0FDMzIwMCBpcyBub3Qgc2V0DQojIENPTkZJR19BUFJJQ09UIGlzIG5vdCBzZXQNCiMgQ09ORklH X0I0NCBpcyBub3Qgc2V0DQojIENPTkZJR19GT1JDRURFVEggaXMgbm90IHNldA0KIyBDT05GSUdf Q1M4OXgwIGlzIG5vdCBzZXQNCiMgQ09ORklHX0RHUlMgaXMgbm90IHNldA0KQ09ORklHX0VFUFJP MTAwPW0NCkNPTkZJR19FMTAwPW0NCiMgQ09ORklHX0UxMDBfTkFQSSBpcyBub3Qgc2V0DQojIENP TkZJR19MTkUzOTAgaXMgbm90IHNldA0KIyBDT05GSUdfRkVBTE5YIGlzIG5vdCBzZXQNCiMgQ09O RklHX05BVFNFTUkgaXMgbm90IHNldA0KIyBDT05GSUdfTkUyS19QQ0kgaXMgbm90IHNldA0KIyBD T05GSUdfTkUzMjEwIGlzIG5vdCBzZXQNCiMgQ09ORklHX0VTMzIxMCBpcyBub3Qgc2V0DQojIENP TkZJR184MTM5Q1AgaXMgbm90IHNldA0KIyBDT05GSUdfODEzOVRPTyBpcyBub3Qgc2V0DQojIENP TkZJR19TSVM5MDAgaXMgbm90IHNldA0KIyBDT05GSUdfRVBJQzEwMCBpcyBub3Qgc2V0DQojIENP TkZJR19TVU5EQU5DRSBpcyBub3Qgc2V0DQojIENPTkZJR19UTEFOIGlzIG5vdCBzZXQNCiMgQ09O RklHX1ZJQV9SSElORSBpcyBub3Qgc2V0DQojIENPTkZJR19ORVRfUE9DS0VUIGlzIG5vdCBzZXQN Cg0KIw0KIyBFdGhlcm5ldCAoMTAwMCBNYml0KQ0KIw0KIyBDT05GSUdfQUNFTklDIGlzIG5vdCBz ZXQNCiMgQ09ORklHX0RMMksgaXMgbm90IHNldA0KIyBDT05GSUdfRTEwMDAgaXMgbm90IHNldA0K IyBDT05GSUdfTlM4MzgyMCBpcyBub3Qgc2V0DQojIENPTkZJR19IQU1BQ0hJIGlzIG5vdCBzZXQN CiMgQ09ORklHX1lFTExPV0ZJTiBpcyBub3Qgc2V0DQojIENPTkZJR19SODE2OSBpcyBub3Qgc2V0 DQojIENPTkZJR19TSzk4TElOIGlzIG5vdCBzZXQNCiMgQ09ORklHX1ZJQV9WRUxPQ0lUWSBpcyBu b3Qgc2V0DQojIENPTkZJR19USUdPTjMgaXMgbm90IHNldA0KDQojDQojIEV0aGVybmV0ICgxMDAw MCBNYml0KQ0KIw0KIyBDT05GSUdfSVhHQiBpcyBub3Qgc2V0DQojIENPTkZJR19TMklPIGlzIG5v dCBzZXQNCg0KIw0KIyBUb2tlbiBSaW5nIGRldmljZXMNCiMNCiMgQ09ORklHX1RSIGlzIG5vdCBz ZXQNCg0KIw0KIyBXaXJlbGVzcyBMQU4gKG5vbi1oYW1yYWRpbykNCiMNCiMgQ09ORklHX05FVF9S QURJTyBpcyBub3Qgc2V0DQoNCiMNCiMgV2FuIGludGVyZmFjZXMNCiMNCiMgQ09ORklHX1dBTiBp cyBub3Qgc2V0DQojIENPTkZJR19GRERJIGlzIG5vdCBzZXQNCiMgQ09ORklHX0hJUFBJIGlzIG5v dCBzZXQNCiMgQ09ORklHX1BQUCBpcyBub3Qgc2V0DQojIENPTkZJR19TTElQIGlzIG5vdCBzZXQN CiMgQ09ORklHX05FVF9GQyBpcyBub3Qgc2V0DQojIENPTkZJR19TSEFQRVIgaXMgbm90IHNldA0K IyBDT05GSUdfTkVUQ09OU09MRSBpcyBub3Qgc2V0DQoNCiMNCiMgSVNETiBzdWJzeXN0ZW0NCiMN CiMgQ09ORklHX0lTRE4gaXMgbm90IHNldA0KDQojDQojIFRlbGVwaG9ueSBTdXBwb3J0DQojDQoj IENPTkZJR19QSE9ORSBpcyBub3Qgc2V0DQoNCiMNCiMgSW5wdXQgZGV2aWNlIHN1cHBvcnQNCiMN CkNPTkZJR19JTlBVVD15DQoNCiMNCiMgVXNlcmxhbmQgaW50ZXJmYWNlcw0KIw0KQ09ORklHX0lO UFVUX01PVVNFREVWPXkNCkNPTkZJR19JTlBVVF9NT1VTRURFVl9QU0FVWD15DQpDT05GSUdfSU5Q VVRfTU9VU0VERVZfU0NSRUVOX1g9MTAyNA0KQ09ORklHX0lOUFVUX01PVVNFREVWX1NDUkVFTl9Z PTc2OA0KIyBDT05GSUdfSU5QVVRfSk9ZREVWIGlzIG5vdCBzZXQNCiMgQ09ORklHX0lOUFVUX1RT REVWIGlzIG5vdCBzZXQNCkNPTkZJR19JTlBVVF9FVkRFVj15DQojIENPTkZJR19JTlBVVF9FVkJV RyBpcyBub3Qgc2V0DQoNCiMNCiMgSW5wdXQgSS9PIGRyaXZlcnMNCiMNCiMgQ09ORklHX0dBTUVQ T1JUIGlzIG5vdCBzZXQNCkNPTkZJR19TT1VORF9HQU1FUE9SVD15DQpDT05GSUdfU0VSSU89eQ0K Q09ORklHX1NFUklPX0k4MDQyPXkNCkNPTkZJR19TRVJJT19TRVJQT1JUPXkNCiMgQ09ORklHX1NF UklPX0NUODJDNzEwIGlzIG5vdCBzZXQNCkNPTkZJR19TRVJJT19QQ0lQUzI9eQ0KQ09ORklHX1NF UklPX0xJQlBTMj15DQojIENPTkZJR19TRVJJT19SQVcgaXMgbm90IHNldA0KDQojDQojIElucHV0 IERldmljZSBEcml2ZXJzDQojDQpDT05GSUdfSU5QVVRfS0VZQk9BUkQ9eQ0KQ09ORklHX0tFWUJP QVJEX0FUS0JEPXkNCiMgQ09ORklHX0tFWUJPQVJEX1NVTktCRCBpcyBub3Qgc2V0DQojIENPTkZJ R19LRVlCT0FSRF9MS0tCRCBpcyBub3Qgc2V0DQojIENPTkZJR19LRVlCT0FSRF9YVEtCRCBpcyBu b3Qgc2V0DQojIENPTkZJR19LRVlCT0FSRF9ORVdUT04gaXMgbm90IHNldA0KQ09ORklHX0lOUFVU X01PVVNFPXkNCkNPTkZJR19NT1VTRV9QUzI9eQ0KIyBDT05GSUdfTU9VU0VfU0VSSUFMIGlzIG5v dCBzZXQNCiMgQ09ORklHX01PVVNFX0lOUE9SVCBpcyBub3Qgc2V0DQojIENPTkZJR19NT1VTRV9M T0dJQk0gaXMgbm90IHNldA0KIyBDT05GSUdfTU9VU0VfUEMxMTBQQUQgaXMgbm90IHNldA0KIyBD T05GSUdfTU9VU0VfVlNYWFhBQSBpcyBub3Qgc2V0DQojIENPTkZJR19JTlBVVF9KT1lTVElDSyBp cyBub3Qgc2V0DQojIENPTkZJR19JTlBVVF9UT1VDSFNDUkVFTiBpcyBub3Qgc2V0DQojIENPTkZJ R19JTlBVVF9NSVNDIGlzIG5vdCBzZXQNCg0KIw0KIyBDaGFyYWN0ZXIgZGV2aWNlcw0KIw0KQ09O RklHX1ZUPXkNCkNPTkZJR19WVF9DT05TT0xFPXkNCkNPTkZJR19IV19DT05TT0xFPXkNCiMgQ09O RklHX1NFUklBTF9OT05TVEFOREFSRCBpcyBub3Qgc2V0DQoNCiMNCiMgU2VyaWFsIGRyaXZlcnMN CiMNCiMgQ09ORklHX1NFUklBTF84MjUwIGlzIG5vdCBzZXQNCg0KIw0KIyBOb24tODI1MCBzZXJp YWwgcG9ydCBzdXBwb3J0DQojDQpDT05GSUdfVU5JWDk4X1BUWVM9eQ0KQ09ORklHX0xFR0FDWV9Q VFlTPXkNCkNPTkZJR19MRUdBQ1lfUFRZX0NPVU5UPTI1Ng0KDQojDQojIElQTUkNCiMNCiMgQ09O RklHX0lQTUlfSEFORExFUiBpcyBub3Qgc2V0DQoNCiMNCiMgV2F0Y2hkb2cgQ2FyZHMNCiMNCiMg Q09ORklHX1dBVENIRE9HIGlzIG5vdCBzZXQNCkNPTkZJR19IV19SQU5ET009eQ0KQ09ORklHX05W UkFNPW0NCkNPTkZJR19SVEM9eQ0KIyBDT05GSUdfRFRMSyBpcyBub3Qgc2V0DQojIENPTkZJR19S Mzk2NCBpcyBub3Qgc2V0DQojIENPTkZJR19BUFBMSUNPTSBpcyBub3Qgc2V0DQojIENPTkZJR19T T05ZUEkgaXMgbm90IHNldA0KDQojDQojIEZ0YXBlLCB0aGUgZmxvcHB5IHRhcGUgZGV2aWNlIGRy aXZlcg0KIw0KQ09ORklHX0FHUD15DQojIENPTkZJR19BR1BfQUxJIGlzIG5vdCBzZXQNCiMgQ09O RklHX0FHUF9BVEkgaXMgbm90IHNldA0KIyBDT05GSUdfQUdQX0FNRCBpcyBub3Qgc2V0DQojIENP TkZJR19BR1BfQU1ENjQgaXMgbm90IHNldA0KQ09ORklHX0FHUF9JTlRFTD15DQojIENPTkZJR19B R1BfSU5URUxfTUNIIGlzIG5vdCBzZXQNCiMgQ09ORklHX0FHUF9OVklESUEgaXMgbm90IHNldA0K IyBDT05GSUdfQUdQX1NJUyBpcyBub3Qgc2V0DQpDT05GSUdfQUdQX1NXT1JLUz15DQojIENPTkZJ R19BR1BfVklBIGlzIG5vdCBzZXQNCiMgQ09ORklHX0FHUF9FRkZJQ0VPTiBpcyBub3Qgc2V0DQpD T05GSUdfRFJNPXkNCiMgQ09ORklHX0RSTV9UREZYIGlzIG5vdCBzZXQNCiMgQ09ORklHX0RSTV9S MTI4IGlzIG5vdCBzZXQNCiMgQ09ORklHX0RSTV9SQURFT04gaXMgbm90IHNldA0KIyBDT05GSUdf RFJNX0k4MTAgaXMgbm90IHNldA0KIyBDT05GSUdfRFJNX0k4MzAgaXMgbm90IHNldA0KIyBDT05G SUdfRFJNX0k5MTUgaXMgbm90IHNldA0KQ09ORklHX0RSTV9NR0E9eQ0KIyBDT05GSUdfRFJNX1NJ UyBpcyBub3Qgc2V0DQojIENPTkZJR19NV0FWRSBpcyBub3Qgc2V0DQpDT05GSUdfUkFXX0RSSVZF Uj1tDQojIENPTkZJR19IUEVUIGlzIG5vdCBzZXQNCkNPTkZJR19NQVhfUkFXX0RFVlM9MjU2DQoj IENPTkZJR19IQU5HQ0hFQ0tfVElNRVIgaXMgbm90IHNldA0KDQojDQojIEkyQyBzdXBwb3J0DQoj DQojIENPTkZJR19JMkMgaXMgbm90IHNldA0KDQojDQojIERhbGxhcydzIDEtd2lyZSBidXMNCiMN CiMgQ09ORklHX1cxIGlzIG5vdCBzZXQNCg0KIw0KIyBNaXNjIGRldmljZXMNCiMNCiMgQ09ORklH X0lCTV9BU00gaXMgbm90IHNldA0KDQojDQojIE11bHRpbWVkaWEgZGV2aWNlcw0KIw0KIyBDT05G SUdfVklERU9fREVWIGlzIG5vdCBzZXQNCg0KIw0KIyBEaWdpdGFsIFZpZGVvIEJyb2FkY2FzdGlu ZyBEZXZpY2VzDQojDQojIENPTkZJR19EVkIgaXMgbm90IHNldA0KDQojDQojIEdyYXBoaWNzIHN1 cHBvcnQNCiMNCiMgQ09ORklHX0ZCIGlzIG5vdCBzZXQNCiMgQ09ORklHX1ZJREVPX1NFTEVDVCBp cyBub3Qgc2V0DQoNCiMNCiMgQ29uc29sZSBkaXNwbGF5IGRyaXZlciBzdXBwb3J0DQojDQpDT05G SUdfVkdBX0NPTlNPTEU9eQ0KIyBDT05GSUdfTURBX0NPTlNPTEUgaXMgbm90IHNldA0KQ09ORklH X0RVTU1ZX0NPTlNPTEU9eQ0KDQojDQojIFNvdW5kDQojDQpDT05GSUdfU09VTkQ9bQ0KDQojDQoj IEFkdmFuY2VkIExpbnV4IFNvdW5kIEFyY2hpdGVjdHVyZQ0KIw0KQ09ORklHX1NORD1tDQpDT05G SUdfU05EX1RJTUVSPW0NCkNPTkZJR19TTkRfUENNPW0NCkNPTkZJR19TTkRfUkFXTUlEST1tDQpD T05GSUdfU05EX1NFUVVFTkNFUj1tDQojIENPTkZJR19TTkRfU0VRX0RVTU1ZIGlzIG5vdCBzZXQN CkNPTkZJR19TTkRfT1NTRU1VTD15DQpDT05GSUdfU05EX01JWEVSX09TUz1tDQpDT05GSUdfU05E X1BDTV9PU1M9bQ0KQ09ORklHX1NORF9TRVFVRU5DRVJfT1NTPXkNCkNPTkZJR19TTkRfUlRDVElN RVI9bQ0KIyBDT05GSUdfU05EX1ZFUkJPU0VfUFJJTlRLIGlzIG5vdCBzZXQNCiMgQ09ORklHX1NO RF9ERUJVRyBpcyBub3Qgc2V0DQoNCiMNCiMgR2VuZXJpYyBkZXZpY2VzDQojDQojIENPTkZJR19T TkRfRFVNTVkgaXMgbm90IHNldA0KIyBDT05GSUdfU05EX1ZJUk1JREkgaXMgbm90IHNldA0KIyBD T05GSUdfU05EX01UUEFWIGlzIG5vdCBzZXQNCiMgQ09ORklHX1NORF9TRVJJQUxfVTE2NTUwIGlz IG5vdCBzZXQNCiMgQ09ORklHX1NORF9NUFU0MDEgaXMgbm90IHNldA0KDQojDQojIElTQSBkZXZp Y2VzDQojDQojIENPTkZJR19TTkRfQUQxODQ4IGlzIG5vdCBzZXQNCiMgQ09ORklHX1NORF9DUzQy MzEgaXMgbm90IHNldA0KIyBDT05GSUdfU05EX0NTNDIzMiBpcyBub3Qgc2V0DQojIENPTkZJR19T TkRfQ1M0MjM2IGlzIG5vdCBzZXQNCiMgQ09ORklHX1NORF9FUzE2ODggaXMgbm90IHNldA0KIyBD T05GSUdfU05EX0VTMThYWCBpcyBub3Qgc2V0DQojIENPTkZJR19TTkRfR1VTQ0xBU1NJQyBpcyBu b3Qgc2V0DQojIENPTkZJR19TTkRfR1VTRVhUUkVNRSBpcyBub3Qgc2V0DQojIENPTkZJR19TTkRf R1VTTUFYIGlzIG5vdCBzZXQNCiMgQ09ORklHX1NORF9JTlRFUldBVkUgaXMgbm90IHNldA0KIyBD T05GSUdfU05EX0lOVEVSV0FWRV9TVEIgaXMgbm90IHNldA0KIyBDT05GSUdfU05EX09QVEk5Mlhf QUQxODQ4IGlzIG5vdCBzZXQNCiMgQ09ORklHX1NORF9PUFRJOTJYX0NTNDIzMSBpcyBub3Qgc2V0 DQojIENPTkZJR19TTkRfT1BUSTkzWCBpcyBub3Qgc2V0DQojIENPTkZJR19TTkRfU0I4IGlzIG5v dCBzZXQNCiMgQ09ORklHX1NORF9TQjE2IGlzIG5vdCBzZXQNCiMgQ09ORklHX1NORF9TQkFXRSBp cyBub3Qgc2V0DQojIENPTkZJR19TTkRfV0FWRUZST05UIGlzIG5vdCBzZXQNCiMgQ09ORklHX1NO RF9DTUk4MzMwIGlzIG5vdCBzZXQNCiMgQ09ORklHX1NORF9PUEwzU0EyIGlzIG5vdCBzZXQNCiMg Q09ORklHX1NORF9TR0FMQVhZIGlzIG5vdCBzZXQNCiMgQ09ORklHX1NORF9TU0NBUEUgaXMgbm90 IHNldA0KDQojDQojIFBDSSBkZXZpY2VzDQojDQpDT05GSUdfU05EX0FDOTdfQ09ERUM9bQ0KIyBD T05GSUdfU05EX0FMSTU0NTEgaXMgbm90IHNldA0KIyBDT05GSUdfU05EX0FUSUlYUCBpcyBub3Qg c2V0DQojIENPTkZJR19TTkRfQVRJSVhQX01PREVNIGlzIG5vdCBzZXQNCiMgQ09ORklHX1NORF9B VTg4MTAgaXMgbm90IHNldA0KIyBDT05GSUdfU05EX0FVODgyMCBpcyBub3Qgc2V0DQojIENPTkZJ R19TTkRfQVU4ODMwIGlzIG5vdCBzZXQNCiMgQ09ORklHX1NORF9BWlQzMzI4IGlzIG5vdCBzZXQN CiMgQ09ORklHX1NORF9CVDg3WCBpcyBub3Qgc2V0DQojIENPTkZJR19TTkRfQ1M0NlhYIGlzIG5v dCBzZXQNCiMgQ09ORklHX1NORF9DUzQyODEgaXMgbm90IHNldA0KIyBDT05GSUdfU05EX0VNVTEw SzEgaXMgbm90IHNldA0KIyBDT05GSUdfU05EX0VNVTEwSzFYIGlzIG5vdCBzZXQNCiMgQ09ORklH X1NORF9DQTAxMDYgaXMgbm90IHNldA0KIyBDT05GSUdfU05EX0tPUkcxMjEyIGlzIG5vdCBzZXQN CiMgQ09ORklHX1NORF9NSVhBUlQgaXMgbm90IHNldA0KIyBDT05GSUdfU05EX05NMjU2IGlzIG5v dCBzZXQNCiMgQ09ORklHX1NORF9STUUzMiBpcyBub3Qgc2V0DQojIENPTkZJR19TTkRfUk1FOTYg aXMgbm90IHNldA0KIyBDT05GSUdfU05EX1JNRTk2NTIgaXMgbm90IHNldA0KIyBDT05GSUdfU05E X0hEU1AgaXMgbm90IHNldA0KIyBDT05GSUdfU05EX1RSSURFTlQgaXMgbm90IHNldA0KIyBDT05G SUdfU05EX1lNRlBDSSBpcyBub3Qgc2V0DQojIENPTkZJR19TTkRfQUxTNDAwMCBpcyBub3Qgc2V0 DQojIENPTkZJR19TTkRfQ01JUENJIGlzIG5vdCBzZXQNCiMgQ09ORklHX1NORF9FTlMxMzcwIGlz IG5vdCBzZXQNCiMgQ09ORklHX1NORF9FTlMxMzcxIGlzIG5vdCBzZXQNCiMgQ09ORklHX1NORF9F UzE5MzggaXMgbm90IHNldA0KIyBDT05GSUdfU05EX0VTMTk2OCBpcyBub3Qgc2V0DQojIENPTkZJ R19TTkRfTUFFU1RSTzMgaXMgbm90IHNldA0KIyBDT05GSUdfU05EX0ZNODAxIGlzIG5vdCBzZXQN CiMgQ09ORklHX1NORF9JQ0UxNzEyIGlzIG5vdCBzZXQNCiMgQ09ORklHX1NORF9JQ0UxNzI0IGlz IG5vdCBzZXQNCkNPTkZJR19TTkRfSU5URUw4WDA9bQ0KIyBDT05GSUdfU05EX0lOVEVMOFgwTSBp cyBub3Qgc2V0DQojIENPTkZJR19TTkRfU09OSUNWSUJFUyBpcyBub3Qgc2V0DQojIENPTkZJR19T TkRfVklBODJYWCBpcyBub3Qgc2V0DQojIENPTkZJR19TTkRfVklBODJYWF9NT0RFTSBpcyBub3Qg c2V0DQojIENPTkZJR19TTkRfVlgyMjIgaXMgbm90IHNldA0KDQojDQojIFVTQiBkZXZpY2VzDQoj DQpDT05GSUdfU05EX1VTQl9BVURJTz1tDQojIENPTkZJR19TTkRfVVNCX1VTWDJZIGlzIG5vdCBz ZXQNCg0KIw0KIyBPcGVuIFNvdW5kIFN5c3RlbQ0KIw0KIyBDT05GSUdfU09VTkRfUFJJTUUgaXMg bm90IHNldA0KDQojDQojIFVTQiBzdXBwb3J0DQojDQpDT05GSUdfVVNCPW0NCiMgQ09ORklHX1VT Ql9ERUJVRyBpcyBub3Qgc2V0DQoNCiMNCiMgTWlzY2VsbGFuZW91cyBVU0Igb3B0aW9ucw0KIw0K Q09ORklHX1VTQl9ERVZJQ0VGUz15DQojIENPTkZJR19VU0JfQkFORFdJRFRIIGlzIG5vdCBzZXQN CiMgQ09ORklHX1VTQl9EWU5BTUlDX01JTk9SUyBpcyBub3Qgc2V0DQojIENPTkZJR19VU0JfU1VT UEVORCBpcyBub3Qgc2V0DQojIENPTkZJR19VU0JfT1RHIGlzIG5vdCBzZXQNCkNPTkZJR19VU0Jf QVJDSF9IQVNfSENEPXkNCkNPTkZJR19VU0JfQVJDSF9IQVNfT0hDST15DQoNCiMNCiMgVVNCIEhv c3QgQ29udHJvbGxlciBEcml2ZXJzDQojDQpDT05GSUdfVVNCX0VIQ0lfSENEPW0NCiMgQ09ORklH X1VTQl9FSENJX1NQTElUX0lTTyBpcyBub3Qgc2V0DQojIENPTkZJR19VU0JfRUhDSV9ST09UX0hV Ql9UVCBpcyBub3Qgc2V0DQojIENPTkZJR19VU0JfT0hDSV9IQ0QgaXMgbm90IHNldA0KQ09ORklH X1VTQl9VSENJX0hDRD1tDQojIENPTkZJR19VU0JfU0w4MTFfSENEIGlzIG5vdCBzZXQNCg0KIw0K IyBVU0IgRGV2aWNlIENsYXNzIGRyaXZlcnMNCiMNCiMgQ09ORklHX1VTQl9BVURJTyBpcyBub3Qg c2V0DQojIENPTkZJR19VU0JfQkxVRVRPT1RIX1RUWSBpcyBub3Qgc2V0DQojIENPTkZJR19VU0Jf TUlESSBpcyBub3Qgc2V0DQojIENPTkZJR19VU0JfQUNNIGlzIG5vdCBzZXQNCiMgQ09ORklHX1VT Ql9QUklOVEVSIGlzIG5vdCBzZXQNCg0KIw0KIyBOT1RFOiBVU0JfU1RPUkFHRSBlbmFibGVzIFND U0ksIGFuZCAnU0NTSSBkaXNrIHN1cHBvcnQnIG1heSBhbHNvIGJlIG5lZWRlZDsgc2VlIFVTQl9T VE9SQUdFIEhlbHAgZm9yIG1vcmUgaW5mb3JtYXRpb24NCiMNCkNPTkZJR19VU0JfU1RPUkFHRT1t DQojIENPTkZJR19VU0JfU1RPUkFHRV9ERUJVRyBpcyBub3Qgc2V0DQojIENPTkZJR19VU0JfU1RP UkFHRV9SV19ERVRFQ1QgaXMgbm90IHNldA0KIyBDT05GSUdfVVNCX1NUT1JBR0VfREFUQUZBQiBp cyBub3Qgc2V0DQojIENPTkZJR19VU0JfU1RPUkFHRV9GUkVFQ09NIGlzIG5vdCBzZXQNCiMgQ09O RklHX1VTQl9TVE9SQUdFX0lTRDIwMCBpcyBub3Qgc2V0DQojIENPTkZJR19VU0JfU1RPUkFHRV9E UENNIGlzIG5vdCBzZXQNCiMgQ09ORklHX1VTQl9TVE9SQUdFX0hQODIwMGUgaXMgbm90IHNldA0K IyBDT05GSUdfVVNCX1NUT1JBR0VfU0REUjA5IGlzIG5vdCBzZXQNCiMgQ09ORklHX1VTQl9TVE9S QUdFX1NERFI1NSBpcyBub3Qgc2V0DQojIENPTkZJR19VU0JfU1RPUkFHRV9KVU1QU0hPVCBpcyBu b3Qgc2V0DQoNCiMNCiMgVVNCIElucHV0IERldmljZXMNCiMNCkNPTkZJR19VU0JfSElEPW0NCiMg Q09ORklHX1VTQl9ISURJTlBVVCBpcyBub3Qgc2V0DQojIENPTkZJR19VU0JfSElEREVWIGlzIG5v dCBzZXQNCg0KIw0KIyBVU0IgSElEIEJvb3QgUHJvdG9jb2wgZHJpdmVycw0KIw0KIyBDT05GSUdf VVNCX0tCRCBpcyBub3Qgc2V0DQojIENPTkZJR19VU0JfTU9VU0UgaXMgbm90IHNldA0KIyBDT05G SUdfVVNCX0FJUFRFSyBpcyBub3Qgc2V0DQpDT05GSUdfVVNCX1dBQ09NPW0NCiMgQ09ORklHX1VT Ql9LQlRBQiBpcyBub3Qgc2V0DQojIENPTkZJR19VU0JfUE9XRVJNQVRFIGlzIG5vdCBzZXQNCiMg Q09ORklHX1VTQl9NVE9VQ0ggaXMgbm90IHNldA0KIyBDT05GSUdfVVNCX0VHQUxBWCBpcyBub3Qg c2V0DQojIENPTkZJR19VU0JfWFBBRCBpcyBub3Qgc2V0DQojIENPTkZJR19VU0JfQVRJX1JFTU9U RSBpcyBub3Qgc2V0DQoNCiMNCiMgVVNCIEltYWdpbmcgZGV2aWNlcw0KIw0KIyBDT05GSUdfVVNC X01EQzgwMCBpcyBub3Qgc2V0DQojIENPTkZJR19VU0JfTUlDUk9URUsgaXMgbm90IHNldA0KDQoj DQojIFVTQiBNdWx0aW1lZGlhIGRldmljZXMNCiMNCiMgQ09ORklHX1VTQl9EQUJVU0IgaXMgbm90 IHNldA0KDQojDQojIFZpZGVvNExpbnV4IHN1cHBvcnQgaXMgbmVlZGVkIGZvciBVU0IgTXVsdGlt ZWRpYSBkZXZpY2Ugc3VwcG9ydA0KIw0KDQojDQojIFVTQiBOZXR3b3JrIEFkYXB0ZXJzDQojDQoj IENPTkZJR19VU0JfQ0FUQyBpcyBub3Qgc2V0DQojIENPTkZJR19VU0JfS0FXRVRIIGlzIG5vdCBz ZXQNCiMgQ09ORklHX1VTQl9QRUdBU1VTIGlzIG5vdCBzZXQNCiMgQ09ORklHX1VTQl9SVEw4MTUw IGlzIG5vdCBzZXQNCiMgQ09ORklHX1VTQl9VU0JORVQgaXMgbm90IHNldA0KDQojDQojIFVTQiBw b3J0IGRyaXZlcnMNCiMNCg0KIw0KIyBVU0IgU2VyaWFsIENvbnZlcnRlciBzdXBwb3J0DQojDQoj IENPTkZJR19VU0JfU0VSSUFMIGlzIG5vdCBzZXQNCg0KIw0KIyBVU0IgTWlzY2VsbGFuZW91cyBk cml2ZXJzDQojDQojIENPTkZJR19VU0JfRU1JNjIgaXMgbm90IHNldA0KIyBDT05GSUdfVVNCX0VN STI2IGlzIG5vdCBzZXQNCiMgQ09ORklHX1VTQl9BVUVSU1dBTEQgaXMgbm90IHNldA0KIyBDT05G SUdfVVNCX1JJTzUwMCBpcyBub3Qgc2V0DQojIENPTkZJR19VU0JfTEVHT1RPV0VSIGlzIG5vdCBz ZXQNCiMgQ09ORklHX1VTQl9MQ0QgaXMgbm90IHNldA0KIyBDT05GSUdfVVNCX0xFRCBpcyBub3Qg c2V0DQojIENPTkZJR19VU0JfQ1lUSEVSTSBpcyBub3Qgc2V0DQojIENPTkZJR19VU0JfUEhJREdF VEtJVCBpcyBub3Qgc2V0DQojIENPTkZJR19VU0JfUEhJREdFVFNFUlZPIGlzIG5vdCBzZXQNCiMg Q09ORklHX1VTQl9JRE1PVVNFIGlzIG5vdCBzZXQNCiMgQ09ORklHX1VTQl9URVNUIGlzIG5vdCBz ZXQNCg0KIw0KIyBVU0IgQVRNL0RTTCBkcml2ZXJzDQojDQoNCiMNCiMgVVNCIEdhZGdldCBTdXBw b3J0DQojDQojIENPTkZJR19VU0JfR0FER0VUIGlzIG5vdCBzZXQNCg0KIw0KIyBNTUMvU0QgQ2Fy ZCBzdXBwb3J0DQojDQojIENPTkZJR19NTUMgaXMgbm90IHNldA0KDQojDQojIEluZmluaUJhbmQg c3VwcG9ydA0KIw0KIyBDT05GSUdfSU5GSU5JQkFORCBpcyBub3Qgc2V0DQoNCiMNCiMgRmlsZSBz eXN0ZW1zDQojDQpDT05GSUdfRVhUMl9GUz15DQojIENPTkZJR19FWFQyX0ZTX1hBVFRSIGlzIG5v dCBzZXQNCkNPTkZJR19FWFQzX0ZTPXkNCkNPTkZJR19FWFQzX0ZTX1hBVFRSPXkNCkNPTkZJR19F WFQzX0ZTX1BPU0lYX0FDTD15DQojIENPTkZJR19FWFQzX0ZTX1NFQ1VSSVRZIGlzIG5vdCBzZXQN CkNPTkZJR19KQkQ9eQ0KIyBDT05GSUdfSkJEX0RFQlVHIGlzIG5vdCBzZXQNCkNPTkZJR19GU19N QkNBQ0hFPXkNCkNPTkZJR19SRUlTRVJGU19GUz15DQojIENPTkZJR19SRUlTRVJGU19DSEVDSyBp cyBub3Qgc2V0DQpDT05GSUdfUkVJU0VSRlNfUFJPQ19JTkZPPXkNCiMgQ09ORklHX1JFSVNFUkZT X0ZTX1hBVFRSIGlzIG5vdCBzZXQNCiMgQ09ORklHX0pGU19GUyBpcyBub3Qgc2V0DQpDT05GSUdf RlNfUE9TSVhfQUNMPXkNCg0KIw0KIyBYRlMgc3VwcG9ydA0KIw0KIyBDT05GSUdfWEZTX0ZTIGlz IG5vdCBzZXQNCiMgQ09ORklHX01JTklYX0ZTIGlzIG5vdCBzZXQNCiMgQ09ORklHX1JPTUZTX0ZT IGlzIG5vdCBzZXQNCiMgQ09ORklHX1FVT1RBIGlzIG5vdCBzZXQNCkNPTkZJR19ETk9USUZZPXkN CkNPTkZJR19BVVRPRlNfRlM9eQ0KQ09ORklHX0FVVE9GUzRfRlM9eQ0KDQojDQojIENELVJPTS9E VkQgRmlsZXN5c3RlbXMNCiMNCkNPTkZJR19JU085NjYwX0ZTPXkNCkNPTkZJR19KT0xJRVQ9eQ0K Q09ORklHX1pJU09GUz15DQpDT05GSUdfWklTT0ZTX0ZTPXkNCkNPTkZJR19VREZfRlM9bQ0KQ09O RklHX1VERl9OTFM9eQ0KDQojDQojIERPUy9GQVQvTlQgRmlsZXN5c3RlbXMNCiMNCkNPTkZJR19G QVRfRlM9eQ0KQ09ORklHX01TRE9TX0ZTPXkNCkNPTkZJR19WRkFUX0ZTPXkNCkNPTkZJR19GQVRf REVGQVVMVF9DT0RFUEFHRT00MzcNCkNPTkZJR19GQVRfREVGQVVMVF9JT0NIQVJTRVQ9Imlzbzg4 NTktMSINCiMgQ09ORklHX05URlNfRlMgaXMgbm90IHNldA0KDQojDQojIFBzZXVkbyBmaWxlc3lz dGVtcw0KIw0KQ09ORklHX1BST0NfRlM9eQ0KQ09ORklHX1BST0NfS0NPUkU9eQ0KQ09ORklHX1NZ U0ZTPXkNCiMgQ09ORklHX0RFVkZTX0ZTIGlzIG5vdCBzZXQNCiMgQ09ORklHX0RFVlBUU19GU19Y QVRUUiBpcyBub3Qgc2V0DQpDT05GSUdfVE1QRlM9eQ0KIyBDT05GSUdfVE1QRlNfWEFUVFIgaXMg bm90IHNldA0KIyBDT05GSUdfSFVHRVRMQkZTIGlzIG5vdCBzZXQNCiMgQ09ORklHX0hVR0VUTEJf UEFHRSBpcyBub3Qgc2V0DQpDT05GSUdfUkFNRlM9eQ0KDQojDQojIE1pc2NlbGxhbmVvdXMgZmls ZXN5c3RlbXMNCiMNCiMgQ09ORklHX0FERlNfRlMgaXMgbm90IHNldA0KIyBDT05GSUdfQUZGU19G UyBpcyBub3Qgc2V0DQojIENPTkZJR19IRlNfRlMgaXMgbm90IHNldA0KIyBDT05GSUdfSEZTUExV U19GUyBpcyBub3Qgc2V0DQojIENPTkZJR19CRUZTX0ZTIGlzIG5vdCBzZXQNCiMgQ09ORklHX0JG U19GUyBpcyBub3Qgc2V0DQojIENPTkZJR19FRlNfRlMgaXMgbm90IHNldA0KIyBDT05GSUdfQ1JB TUZTIGlzIG5vdCBzZXQNCiMgQ09ORklHX1ZYRlNfRlMgaXMgbm90IHNldA0KIyBDT05GSUdfSFBG U19GUyBpcyBub3Qgc2V0DQojIENPTkZJR19RTlg0RlNfRlMgaXMgbm90IHNldA0KIyBDT05GSUdf U1lTVl9GUyBpcyBub3Qgc2V0DQojIENPTkZJR19VRlNfRlMgaXMgbm90IHNldA0KDQojDQojIE5l dHdvcmsgRmlsZSBTeXN0ZW1zDQojDQpDT05GSUdfTkZTX0ZTPXkNCkNPTkZJR19ORlNfVjM9eQ0K IyBDT05GSUdfTkZTX1Y0IGlzIG5vdCBzZXQNCiMgQ09ORklHX05GU19ESVJFQ1RJTyBpcyBub3Qg c2V0DQpDT05GSUdfTkZTRD15DQpDT05GSUdfTkZTRF9WMz15DQojIENPTkZJR19ORlNEX1Y0IGlz IG5vdCBzZXQNCiMgQ09ORklHX05GU0RfVENQIGlzIG5vdCBzZXQNCkNPTkZJR19MT0NLRD15DQpD T05GSUdfTE9DS0RfVjQ9eQ0KQ09ORklHX0VYUE9SVEZTPXkNCkNPTkZJR19TVU5SUEM9eQ0KIyBD T05GSUdfUlBDU0VDX0dTU19LUkI1IGlzIG5vdCBzZXQNCiMgQ09ORklHX1JQQ1NFQ19HU1NfU1BL TTMgaXMgbm90IHNldA0KQ09ORklHX1NNQl9GUz15DQojIENPTkZJR19TTUJfTkxTX0RFRkFVTFQg aXMgbm90IHNldA0KIyBDT05GSUdfQ0lGUyBpcyBub3Qgc2V0DQojIENPTkZJR19OQ1BfRlMgaXMg bm90IHNldA0KIyBDT05GSUdfQ09EQV9GUyBpcyBub3Qgc2V0DQojIENPTkZJR19BRlNfRlMgaXMg bm90IHNldA0KDQojDQojIFBhcnRpdGlvbiBUeXBlcw0KIw0KIyBDT05GSUdfUEFSVElUSU9OX0FE VkFOQ0VEIGlzIG5vdCBzZXQNCkNPTkZJR19NU0RPU19QQVJUSVRJT049eQ0KDQojDQojIE5hdGl2 ZSBMYW5ndWFnZSBTdXBwb3J0DQojDQpDT05GSUdfTkxTPXkNCkNPTkZJR19OTFNfREVGQVVMVD0i aXNvODg1OS0xIg0KQ09ORklHX05MU19DT0RFUEFHRV80Mzc9eQ0KIyBDT05GSUdfTkxTX0NPREVQ QUdFXzczNyBpcyBub3Qgc2V0DQojIENPTkZJR19OTFNfQ09ERVBBR0VfNzc1IGlzIG5vdCBzZXQN CiMgQ09ORklHX05MU19DT0RFUEFHRV84NTAgaXMgbm90IHNldA0KIyBDT05GSUdfTkxTX0NPREVQ QUdFXzg1MiBpcyBub3Qgc2V0DQojIENPTkZJR19OTFNfQ09ERVBBR0VfODU1IGlzIG5vdCBzZXQN CiMgQ09ORklHX05MU19DT0RFUEFHRV84NTcgaXMgbm90IHNldA0KIyBDT05GSUdfTkxTX0NPREVQ QUdFXzg2MCBpcyBub3Qgc2V0DQojIENPTkZJR19OTFNfQ09ERVBBR0VfODYxIGlzIG5vdCBzZXQN CiMgQ09ORklHX05MU19DT0RFUEFHRV84NjIgaXMgbm90IHNldA0KIyBDT05GSUdfTkxTX0NPREVQ QUdFXzg2MyBpcyBub3Qgc2V0DQojIENPTkZJR19OTFNfQ09ERVBBR0VfODY0IGlzIG5vdCBzZXQN CiMgQ09ORklHX05MU19DT0RFUEFHRV84NjUgaXMgbm90IHNldA0KIyBDT05GSUdfTkxTX0NPREVQ QUdFXzg2NiBpcyBub3Qgc2V0DQojIENPTkZJR19OTFNfQ09ERVBBR0VfODY5IGlzIG5vdCBzZXQN CiMgQ09ORklHX05MU19DT0RFUEFHRV85MzYgaXMgbm90IHNldA0KIyBDT05GSUdfTkxTX0NPREVQ QUdFXzk1MCBpcyBub3Qgc2V0DQojIENPTkZJR19OTFNfQ09ERVBBR0VfOTMyIGlzIG5vdCBzZXQN CiMgQ09ORklHX05MU19DT0RFUEFHRV85NDkgaXMgbm90IHNldA0KIyBDT05GSUdfTkxTX0NPREVQ QUdFXzg3NCBpcyBub3Qgc2V0DQojIENPTkZJR19OTFNfSVNPODg1OV84IGlzIG5vdCBzZXQNCiMg Q09ORklHX05MU19DT0RFUEFHRV8xMjUwIGlzIG5vdCBzZXQNCiMgQ09ORklHX05MU19DT0RFUEFH RV8xMjUxIGlzIG5vdCBzZXQNCiMgQ09ORklHX05MU19BU0NJSSBpcyBub3Qgc2V0DQojIENPTkZJ R19OTFNfSVNPODg1OV8xIGlzIG5vdCBzZXQNCiMgQ09ORklHX05MU19JU084ODU5XzIgaXMgbm90 IHNldA0KIyBDT05GSUdfTkxTX0lTTzg4NTlfMyBpcyBub3Qgc2V0DQojIENPTkZJR19OTFNfSVNP ODg1OV80IGlzIG5vdCBzZXQNCiMgQ09ORklHX05MU19JU084ODU5XzUgaXMgbm90IHNldA0KIyBD T05GSUdfTkxTX0lTTzg4NTlfNiBpcyBub3Qgc2V0DQojIENPTkZJR19OTFNfSVNPODg1OV83IGlz IG5vdCBzZXQNCiMgQ09ORklHX05MU19JU084ODU5XzkgaXMgbm90IHNldA0KIyBDT05GSUdfTkxT X0lTTzg4NTlfMTMgaXMgbm90IHNldA0KIyBDT05GSUdfTkxTX0lTTzg4NTlfMTQgaXMgbm90IHNl dA0KIyBDT05GSUdfTkxTX0lTTzg4NTlfMTUgaXMgbm90IHNldA0KIyBDT05GSUdfTkxTX0tPSThf UiBpcyBub3Qgc2V0DQojIENPTkZJR19OTFNfS09JOF9VIGlzIG5vdCBzZXQNCiMgQ09ORklHX05M U19VVEY4IGlzIG5vdCBzZXQNCg0KIw0KIyBQcm9maWxpbmcgc3VwcG9ydA0KIw0KQ09ORklHX1BS T0ZJTElORz15DQpDT05GSUdfT1BST0ZJTEU9bQ0KDQojDQojIEtlcm5lbCBoYWNraW5nDQojDQpD T05GSUdfREVCVUdfS0VSTkVMPXkNCkNPTkZJR19NQUdJQ19TWVNSUT15DQojIENPTkZJR19TQ0hF RFNUQVRTIGlzIG5vdCBzZXQNCiMgQ09ORklHX0RFQlVHX1NMQUIgaXMgbm90IHNldA0KQ09ORklH X0RFQlVHX1BSRUVNUFQ9eQ0KIyBDT05GSUdfREVCVUdfU1BJTkxPQ0sgaXMgbm90IHNldA0KIyBD T05GSUdfREVCVUdfU1BJTkxPQ0tfU0xFRVAgaXMgbm90IHNldA0KIyBDT05GSUdfREVCVUdfS09C SkVDVCBpcyBub3Qgc2V0DQojIENPTkZJR19ERUJVR19ISUdITUVNIGlzIG5vdCBzZXQNCkNPTkZJ R19ERUJVR19CVUdWRVJCT1NFPXkNCiMgQ09ORklHX0RFQlVHX0lORk8gaXMgbm90IHNldA0KIyBD T05GSUdfREVCVUdfRlMgaXMgbm90IHNldA0KIyBDT05GSUdfRlJBTUVfUE9JTlRFUiBpcyBub3Qg c2V0DQpDT05GSUdfRUFSTFlfUFJJTlRLPXkNCkNPTkZJR19ERUJVR19TVEFDS09WRVJGTE9XPXkN CiMgQ09ORklHX0tQUk9CRVMgaXMgbm90IHNldA0KIyBDT05GSUdfREVCVUdfU1RBQ0tfVVNBR0Ug aXMgbm90IHNldA0KIyBDT05GSUdfREVCVUdfUEFHRUFMTE9DIGlzIG5vdCBzZXQNCiMgQ09ORklH XzRLU1RBQ0tTIGlzIG5vdCBzZXQNCkNPTkZJR19YODZfRklORF9TTVBfQ09ORklHPXkNCkNPTkZJ R19YODZfTVBQQVJTRT15DQoNCiMNCiMgU2VjdXJpdHkgb3B0aW9ucw0KIw0KIyBDT05GSUdfS0VZ UyBpcyBub3Qgc2V0DQojIENPTkZJR19TRUNVUklUWSBpcyBub3Qgc2V0DQoNCiMNCiMgQ3J5cHRv Z3JhcGhpYyBvcHRpb25zDQojDQojIENPTkZJR19DUllQVE8gaXMgbm90IHNldA0KDQojDQojIEhh cmR3YXJlIGNyeXB0byBkZXZpY2VzDQojDQoNCiMNCiMgTGlicmFyeSByb3V0aW5lcw0KIw0KIyBD T05GSUdfQ1JDX0NDSVRUIGlzIG5vdCBzZXQNCiMgQ09ORklHX0NSQzMyIGlzIG5vdCBzZXQNCiMg Q09ORklHX0xJQkNSQzMyQyBpcyBub3Qgc2V0DQpDT05GSUdfWkxJQl9JTkZMQVRFPXkNCkNPTkZJ R19HRU5FUklDX0hBUkRJUlFTPXkNCkNPTkZJR19HRU5FUklDX0lSUV9QUk9CRT15DQpDT05GSUdf WDg2X1NNUD15DQpDT05GSUdfWDg2X0hUPXkNCkNPTkZJR19YODZfQklPU19SRUJPT1Q9eQ0KQ09O RklHX1g4Nl9UUkFNUE9MSU5FPXkNCkNPTkZJR19QQz15DQo= --Multipart_Thu__10_Mar_2005_10_48_30_-0800_BLa3zW+zhWEPwmhp-- From cel@citi.umich.edu Thu Mar 10 10:54:17 2005 Received: with ECARTIS (v1.0.0; list netdev); Thu, 10 Mar 2005 10:54:23 -0800 (PST) Received: from citi.umich.edu (citi.umich.edu [141.211.133.111]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j2AIsH61001814 for ; Thu, 10 Mar 2005 10:54:17 -0800 Received: from [10.58.53.132] (nat-198-95-226-230.netapp.com [198.95.226.230]) by citi.umich.edu (Postfix) with ESMTP id D659F1BB0E; Thu, 10 Mar 2005 13:54:13 -0500 (EST) Message-ID: <423097D5.30605@citi.umich.edu> Date: Thu, 10 Mar 2005 13:54:13 -0500 From: Chuck Lever Reply-To: cel@citi.umich.edu Organization: Network Appliance, Inc. User-Agent: Mozilla Thunderbird 1.0 (Windows/20041206) X-Accept-Language: en-us, en MIME-Version: 1.0 To: netdev@oss.sgi.com Cc: linux-kernel@vger.kernel.org Subject: 2.6.11 oops in skb_drop_fraglist Content-Type: multipart/mixed; boundary="------------060206010409030806030001" X-Virus-Scanned: ClamAV 0.83/760/Wed Mar 9 09:12:01 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 2838 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: cel@citi.umich.edu Precedence: bulk X-list: netdev Content-Length: 4654 Lines: 123 This is a multi-part message in MIME format. --------------060206010409030806030001 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit testing NFS client workloads on a dual Pentium-III system running 2.6.11 with some NFS patches. i hit this oops while doing simple-minded ftps and tars. the system locks up once or twice a day under this workload. this is the first time i had the console and captured the oops output. Unable to handle kernel NULL pointer dereference at virtual address 00000001 printing eip: c02fc752 *pde = 00000000 Oops: 0000 [#1] SMP CPU: 0 EIP: 0060:[] Not tainted VLI EFLAGS: 00010202 (2.6.11-CITI_NFS4_ALL-1) EIP is at skb_drop_fraglist+0x22/0x50 eax: f6fe26e0 ebx: 00000001 ecx: f6fe26e0 edx: 00000001 esi: f6f29240 edi: 00000004 ebp: f697ed24 esp: c04cadd8 ds: 007b es: 007b ss: 0068 Process swapper (pid: 0, threadinfo=c04ca000 task=c03efb60) Stack: 00000001 c02fc7fa f6f29240 f697ecc0 c02fc838 00000000 c02fc8ba ccbf2ab0 00000b50 c0326a16 f6f87740 f6f29240 f6f29240 c0321c4a 00000020 f6f87778 f6f87740 f697ecc0 f69d1560 00625a79 c04cae6c 00000000 00000012 f697ecc0 Call Trace: [] skb_release_data+0x5a/0x90 [] kfree_skbmem+0x8/0x20 [] __kfree_skb+0x6a/0xf0 [] tcp_transmit_skb+0x406/0x720 [] tcp_clean_rtx_queue+0x17a/0x410 [] tcp_ack+0xf6/0x580 [] tcp_rcv_established+0x409/0x7f0 [] apic_timer_interrupt+0x1c/0x24 [] tcp_v4_do_rcv+0x110/0x120 [] tcp_v4_rcv+0x6bf/0x940 [] ip_local_deliver+0xc2/0x1f0 [] ip_rcv+0x336/0x450 [] alloc_skb+0x41/0xf0 [] netif_receive_skb+0x136/0x1a0 [] e1000_clean_rx_irq+0x15e/0x4a0 [] __kfree_skb+0x6a/0xf0 [] e1000_clean+0xba/0xf0 [] net_rx_action+0x6f/0x100 [] __do_softirq+0xb9/0xd0 [] do_softirq+0x4a/0x60 c02fc730: 53 push %ebx c02fc731: 8b 80 94 00 00 00 mov 0x94(%eax),%eax c02fc737: 8b 58 0c mov 0xc(%eax),%ebx c02fc73a: c7 40 0c 00 00 00 00 movl $0x0,0xc(%eax) c02fc741: eb 0d jmp c02fc750 c02fc743: 90 nop c02fc744: 90 nop c02fc745: 90 nop c02fc746: 90 nop c02fc747: 90 nop c02fc748: 90 nop c02fc749: 90 nop c02fc74a: 90 nop c02fc74b: 90 nop c02fc74c: 90 nop c02fc74d: 90 nop c02fc74e: 90 nop c02fc74f: 90 nop c02fc750: 89 da mov %ebx,%edx c02fc752: 8b 1b mov (%ebx),%ebx c02fc754: 8b 82 84 00 00 00 mov 0x84(%edx),%eax c02fc75a: 48 dec %eax c02fc75b: 75 13 jne c02fc770 c02fc75d: f0 83 44 24 00 00 lock addl $0x0,0x0(%esp,1) c02fc763: 89 d0 mov %edx,%eax c02fc765: e8 e6 00 00 00 call c02fc850 <__kfree_skb> c02fc76a: 85 db test %ebx,%ebx c02fc76c: 75 e2 jne c02fc750 c02fc76e: 5b pop %ebx c02fc76f: c3 ret c02fc770: f0 ff 8a 84 00 00 00 lock decl 0x84(%edx) c02fc777: 0f 94 c0 sete %al c02fc77a: 84 c0 test %al,%al c02fc77c: 74 ec je c02fc76a c02fc77e: eb e3 jmp c02fc763 --------------060206010409030806030001 Content-Type: text/x-vcard; charset=utf-8; name="cel.vcf" Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="cel.vcf" begin:vcard fn:Chuck Lever n:Lever;Charles org:Network Appliance, Incorporated;Linux NFS Client Development adr:535 West William Street, Suite 3100;;Center for Information Technology Integration;Ann Arbor;MI;48103-4943;USA email;internet:cel@citi.umich.edu title:Member of Technical Staff tel;work:+1 734 763-4415 tel;fax:+1 734 763 4434 tel;home:+1 734 668-1089 x-mozilla-html:FALSE url:http://www.monkey.org/~cel/ version:2.1 end:vcard --------------060206010409030806030001-- From hadi@znyx.com Thu Mar 10 11:00:52 2005 Received: with ECARTIS (v1.0.0; list netdev); Thu, 10 Mar 2005 11:00:57 -0800 (PST) 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 j2AJ0qw2003027 for ; Thu, 10 Mar 2005 11:00:52 -0800 Received: from [10.0.0.9] ([208.2.156.2]) by lotus.znyx.com (Lotus Domino Release 5.0.11) with ESMTP id 2005031011020415:7262 ; Thu, 10 Mar 2005 11:02:04 -0800 Subject: Re: [PATCH] move tc_u32_mark into pkt_cls.h From: Jamal Hadi Salim Reply-To: hadi@znyx.com To: Stephen Hemminger Cc: "David S. Miller" , netdev@oss.sgi.com In-Reply-To: <20050310104207.1d74ac00@dxpl.pdx.osdl.net> References: <20050310104207.1d74ac00@dxpl.pdx.osdl.net> Organization: Znyx Networks Message-Id: <1110481248.1074.306.camel@jzny.localdomain> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.2.2 Date: 10 Mar 2005 14:00:48 -0500 X-MIMETrack: Itemize by SMTP Server on Lotus/Znyx(Release 5.0.11 |July 24, 2002) at 03/10/2005 11:02:04 AM, Serialize by Router on Lotus/Znyx(Release 5.0.11 |July 24, 2002) at 03/10/2005 11:02:07 AM, Serialize complete at 03/10/2005 11:02:07 AM Content-Transfer-Encoding: 7bit Content-Type: text/plain X-Virus-Scanned: ClamAV 0.83/760/Wed Mar 9 09:12:01 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 2839 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: hadi@znyx.com Precedence: bulk X-list: netdev Content-Length: 1533 Lines: 66 Agreed on both counts. Note, however, the tc_u32_mark should die Real Soon Now given the meta match patches that are in from Thomas. cheers, jamal On Thu, 2005-03-10 at 13:42, Stephen Hemminger wrote: > The tc_u32_mark structure is used as part of the netlink message > from the user API to the kernel, so it needs to be moved to include/linux/pkt_cls.h > and have types changed from u32 to __u32. > > Also, the definition of u32 performance counters doesn't need to depend > on the config option. The definition can exist even if the code isn't > enabled. > > Signed-off-by: Stephen Hemminger > > diff -Nru a/include/linux/pkt_cls.h b/include/linux/pkt_cls.h > --- a/include/linux/pkt_cls.h 2005-03-10 10:36:39 -08:00 > +++ b/include/linux/pkt_cls.h 2005-03-10 10:36:39 -08:00 > @@ -221,14 +221,20 @@ > struct tc_u32_key keys[0]; > }; > > -#ifdef CONFIG_CLS_U32_PERF > +struct tc_u32_mark > +{ > + __u32 val; > + __u32 mask; > + __u32 success; > +}; > + > struct tc_u32_pcnt > { > __u64 rcnt; > __u64 rhit; > __u64 kcnts[0]; > }; > -#endif > + > /* Flags */ > > #define TC_U32_TERMINAL 1 > diff -Nru a/net/sched/cls_u32.c b/net/sched/cls_u32.c > --- a/net/sched/cls_u32.c 2005-03-10 10:36:39 -08:00 > +++ b/net/sched/cls_u32.c 2005-03-10 10:36:39 -08:00 > @@ -58,14 +58,6 @@ > #include > #include > > - > -struct tc_u32_mark > -{ > - u32 val; > - u32 mask; > - u32 success; > -}; > - > struct tc_u_knode > { > struct tc_u_knode *next; From shemminger@osdl.org Thu Mar 10 11:24:29 2005 Received: with ECARTIS (v1.0.0; list netdev); Thu, 10 Mar 2005 11:24:34 -0800 (PST) Received: from smtp.osdl.org (fire.osdl.org [65.172.181.4]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j2AJOTAH006810 for ; Thu, 10 Mar 2005 11:24:29 -0800 Received: from shell0.pdx.osdl.net (fw.osdl.org [65.172.181.6]) by smtp.osdl.org (8.12.8/8.12.8) with ESMTP id j2AJO6qi011824 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO); Thu, 10 Mar 2005 11:24:07 -0800 Received: from dxpl.pdx.osdl.net (dxpl.pdx.osdl.net [172.20.1.103]) by shell0.pdx.osdl.net (8.13.1/8.11.6) with ESMTP id j2AJO53S009786; Thu, 10 Mar 2005 11:24:05 -0800 Date: Thu, 10 Mar 2005 11:24:23 -0800 From: Stephen Hemminger To: linux-net@vger.kernel.org Cc: netdev@oss.sgi.com, lartc@mailman.ds9a.nl Subject: [ANNOUNCE] iproute2 release Message-ID: <20050310112423.7afdd095@dxpl.pdx.osdl.net> Organization: Open Source Development Lab X-Mailer: Sylpheed-Claws 1.0.1 (GTK+ 1.2.10; x86_64-unknown-linux-gnu) X-Face: &@E+xe?c%:&e4D{>f1O<&U>2qwRREG5!}7R4;D<"NO^UI2mJ[eEOA2*3>(`Th.yP,VDPo9$ /`~cw![cmj~~jWe?AHY7D1S+\}5brN0k*NE?pPh_'_d>6;XGG[\KDRViCfumZT3@[ Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Received-SPF: pass (domain of shemminger@osdl.org designates 65.172.181.6 as permitted sender) X-MIMEDefang-Filter: osdl$Revision: 1.104 $ X-Scanned-By: MIMEDefang 2.36 X-Virus-Scanned: ClamAV 0.83/760/Wed Mar 9 09:12:01 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 2840 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: shemminger@osdl.org Precedence: bulk X-list: netdev Content-Length: 672 Lines: 27 Minor update release for iproute2 is available. http://developer.osdl.org/dev/iproute2/download/iproute2-2.6.11-050310.tar.gz Also, this time it unpacks to the right name. Stephen Hemminger * fix pkt_cls.h to have tc_u32_mark * update include files to be stripped versions of 2.6.11 * add documentation about netem distributions [from nistnet] * turn off nup in document make [from FC3] * don't build with extra debug info (-g) [from FC3] Nix * make man3 directory Pasi * add ESP-in-UDP encapsulation Thomas Graf * [NETEM] Fix off by one * [NEIGH] print number of probes done so far (statistics mode only) Herbert Xu * Trivial typo in ip help From marcel@holtmann.org Thu Mar 10 11:51:47 2005 Received: with ECARTIS (v1.0.0; list netdev); Thu, 10 Mar 2005 11:51:50 -0800 (PST) Received: from mail.holtmann.net (root@coyote.holtmann.net [217.160.111.169]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j2AJpjOU008398 for ; Thu, 10 Mar 2005 11:51:46 -0800 Received: from pegasus (p3EE2C7D7.dip.t-dialin.net [62.226.199.215]) by mail.holtmann.net (8.12.3/8.12.3/Debian-7.1) with ESMTP id j2AJpqhH025348 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NO); Thu, 10 Mar 2005 20:51:53 +0100 Subject: Re: [PATCH][BLUETOOTH] kill bt_sock_alloc From: Marcel Holtmann To: Arnaldo Carvalho de Melo Cc: Max Krasnyansky , "David S. Miller" , Network Development Mailing List In-Reply-To: <20050309184314.GA29053@conectiva.com.br> References: <20050308094937.GA9468@conectiva.com.br> <20050308095209.GB9468@conectiva.com.br> <422F33E9.4030401@qualcomm.com> <1110392653.5462.40.camel@notepaq> <20050309184314.GA29053@conectiva.com.br> Content-Type: text/plain Date: Thu, 10 Mar 2005 20:51:03 +0100 Message-Id: <1110484263.8395.6.camel@pegasus> Mime-Version: 1.0 X-Mailer: Evolution 2.0.4 Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV 0.83/760/Wed Mar 9 09:12:01 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 2841 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: marcel@holtmann.org Precedence: bulk X-list: netdev Content-Length: 1058 Lines: 30 Hi Arnaldo, > > > Looks good to me. Marcel I'd suggest for you to apply this patch. > > > It helps in reducing overall size of the socket structures. > > > > I didn't got the time to review and test it. Will do that next week. > > OK, take your time, but the changes are rather small, I left renaming > all the _pinfo (l2cap_pinfo, for instance) to _sock (for consistency > with all the other net families) to keep the patch small. the patch is fine so far, but you forgot to change cmtp/sock.c. Please do this and resend it. Send a second patch on top this one which is doing the renaming from *_pinfo to *_sock. I am fine with the renaming, but I like to have this in two separate patches. > For now I'll work on doing this same change to the HAM radio protocols, > coordinating with Ralf Baechle and then wait for your comments to finally > kill sk_protinfo and move on to introduce struct connection_sock. When doing this, please split these changes into patches for net/bluetooth/, net/bluetooth/rfcomm/ and net/bluetooth/*/. Regards Marcel From shemminger@osdl.org Thu Mar 10 12:00:51 2005 Received: with ECARTIS (v1.0.0; list netdev); Thu, 10 Mar 2005 12:00:55 -0800 (PST) Received: from smtp.osdl.org (fire.osdl.org [65.172.181.4]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j2AK0pww009413 for ; Thu, 10 Mar 2005 12:00:51 -0800 Received: from shell0.pdx.osdl.net (fw.osdl.org [65.172.181.6]) by smtp.osdl.org (8.12.8/8.12.8) with ESMTP id j2AK0cqi014732 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO); Thu, 10 Mar 2005 12:00:38 -0800 Received: from dxpl.pdx.osdl.net (dxpl.pdx.osdl.net [172.20.1.103]) by shell0.pdx.osdl.net (8.13.1/8.11.6) with ESMTP id j2AK0cjf011527; Thu, 10 Mar 2005 12:00:38 -0800 Date: Thu, 10 Mar 2005 12:00:55 -0800 From: Stephen Hemminger To: Jon Mason Cc: Francois Romieu , netdev@oss.sgi.com Subject: Re: [PATCH 5/5] r8169: ethtool hardware statistics support Message-ID: <20050310120055.5991e354@dxpl.pdx.osdl.net> In-Reply-To: <200503092221.48487.jdmason@us.ibm.com> References: <20050309113626.6708c93e@dxpl.pdx.osdl.net> <200503091537.30899.jdmason@us.ibm.com> <20050309135345.5efae9b6@dxpl.pdx.osdl.net> <200503092221.48487.jdmason@us.ibm.com> Organization: Open Source Development Lab X-Mailer: Sylpheed-Claws 1.0.1 (GTK+ 1.2.10; x86_64-unknown-linux-gnu) X-Face: &@E+xe?c%:&e4D{>f1O<&U>2qwRREG5!}7R4;D<"NO^UI2mJ[eEOA2*3>(`Th.yP,VDPo9$ /`~cw![cmj~~jWe?AHY7D1S+\}5brN0k*NE?pPh_'_d>6;XGG[\KDRViCfumZT3@[ Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Received-SPF: pass (domain of shemminger@osdl.org designates 65.172.181.6 as permitted sender) X-MIMEDefang-Filter: osdl$Revision: 1.104 $ X-Scanned-By: MIMEDefang 2.36 X-Virus-Scanned: ClamAV 0.83/760/Wed Mar 9 09:12:01 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 2842 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: shemminger@osdl.org Precedence: bulk X-list: netdev Content-Length: 1313 Lines: 33 On Wed, 9 Mar 2005 22:21:48 -0600 Jon Mason wrote: > On Wednesday 09 March 2005 03:53 pm, Stephen Hemminger wrote: > > On Wed, 9 Mar 2005 15:37:30 -0600 > > > > Jon Mason wrote: > > > Does this patch fix the problem of bogus statistics if the interface is > > > down > > > > I see no problem when interface is down. It returns all zero's because > > the device is reset on probe (and on shutdown). > > I can confirm that I see no statistic errors either. > > I believe the faulty code in Richard's patch was: > + if (RTL_R32(StatsAddrLow) & DumpStats) > + return; /* no stats - took too long */ > > Which returned before the stats were populated (leaving garbage). Since your > patch lacks this, we see no problem. If this is true, there is probably a > problem on 8139cp, which has a similar error path in its cp_get_ethtool_stats > function. The problem with the 8139cp is that it allocates the area to hold the statistics as part of the ring structure. The ring structure doesn't exist until device is up. I figured that there was no point in holding the extra space unless needed. One more brief pci allocation was easier. Also, my code waits longer (up to 10ms) and is CPU speed independent. Should I go back and fix the 8139cp? From davem@davemloft.net Thu Mar 10 12:01:30 2005 Received: with ECARTIS (v1.0.0; list netdev); Thu, 10 Mar 2005 12:01:36 -0800 (PST) Received: from cheetah.davemloft.net (mail@dsl027-180-174.sfo1.dsl.speakeasy.net [216.27.180.174]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j2AK1UWW009661 for ; Thu, 10 Mar 2005 12:01:30 -0800 Received: from localhost ([127.0.0.1] helo=cheetah.davemloft.net ident=davem) by cheetah.davemloft.net with smtp (Exim 3.36 #1 (Debian)) id 1D9TpV-0000Wc-00; Thu, 10 Mar 2005 12:00:21 -0800 Date: Thu, 10 Mar 2005 12:00:21 -0800 From: "David S. Miller" To: yoshfuji@linux-ipv6.org Cc: netdev@oss.sgi.com Subject: Re: [BK PATCH] IPV6 Update Message-Id: <20050310120021.76f1d63a.davem@davemloft.net> In-Reply-To: <20050304.121010.06175310.yoshfuji@linux-ipv6.org> References: <20050304.121010.06175310.yoshfuji@linux-ipv6.org> X-Mailer: Sylpheed version 1.0.1 (GTK+ 1.2.10; sparc-unknown-linux-gnu) X-Face: "_;p5u5aPsO,_Vsx"^v-pEq09'CU4&Dc1$fQExov$62l60cgCc%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 X-Virus-Scanned: ClamAV 0.83/760/Wed Mar 9 09:12:01 2005 on oss.sgi.com X-Virus-Status: Clean Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by oss.sgi.com id j2AK1UWW009661 X-archive-position: 2843 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: davem@davemloft.net Precedence: bulk X-list: netdev Content-Length: 358 Lines: 13 On Fri, 04 Mar 2005 12:10:10 +0900 (JST) YOSHIFUJI Hideaki / $B5HF#1QL@(B wrote: > Hello. > > Please pull the following changesets available at: > bk://bk.skbuff.net:20612/linux-2.6-inet6-01a_v6ready2/ > > After all, we can pass IPv6 Ready Logo Phase 1,2 Self Test2 > without FAILs. Pulled, arigato gozaimasu Yoshifuji-san. From jgarzik@pobox.com Thu Mar 10 12:10:06 2005 Received: with ECARTIS (v1.0.0; list netdev); Thu, 10 Mar 2005 12:10:11 -0800 (PST) Received: from parcelfarce.linux.theplanet.co.uk (IDENT:93@parcelfarce.linux.theplanet.co.uk [195.92.249.252]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j2AKA5hg010649 for ; Thu, 10 Mar 2005 12:10:06 -0800 Received: from [69.134.152.124] (helo=[10.10.10.88]) by parcelfarce.linux.theplanet.co.uk with asmtp (TLSv1:AES256-SHA:256) (Exim 4.33) id 1D9Typ-0005BT-K1; Thu, 10 Mar 2005 20:09:59 +0000 Message-ID: <4230A989.7080004@pobox.com> Date: Thu, 10 Mar 2005 15:09:45 -0500 From: Jeff Garzik User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.3) Gecko/20040922 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Stephen Hemminger CC: Jon Mason , Francois Romieu , netdev@oss.sgi.com Subject: Re: [PATCH 5/5] r8169: ethtool hardware statistics support References: <20050309113626.6708c93e@dxpl.pdx.osdl.net> <200503091537.30899.jdmason@us.ibm.com> <20050309135345.5efae9b6@dxpl.pdx.osdl.net> <200503092221.48487.jdmason@us.ibm.com> <20050310120055.5991e354@dxpl.pdx.osdl.net> In-Reply-To: <20050310120055.5991e354@dxpl.pdx.osdl.net> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV 0.83/760/Wed Mar 9 09:12:01 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 2844 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: jgarzik@pobox.com Precedence: bulk X-list: netdev Content-Length: 1408 Lines: 45 Stephen Hemminger wrote: > On Wed, 9 Mar 2005 22:21:48 -0600 > Jon Mason wrote: > > >>On Wednesday 09 March 2005 03:53 pm, Stephen Hemminger wrote: >> >>>On Wed, 9 Mar 2005 15:37:30 -0600 >>> >>>Jon Mason wrote: >>> >>>>Does this patch fix the problem of bogus statistics if the interface is >>>>down >>> >>>I see no problem when interface is down. It returns all zero's because >>>the device is reset on probe (and on shutdown). >> >>I can confirm that I see no statistic errors either. >> >>I believe the faulty code in Richard's patch was: >>+ if (RTL_R32(StatsAddrLow) & DumpStats) >>+ return; /* no stats - took too long */ >> >>Which returned before the stats were populated (leaving garbage). Since your >>patch lacks this, we see no problem. If this is true, there is probably a >>problem on 8139cp, which has a similar error path in its cp_get_ethtool_stats >>function. > > > The problem with the 8139cp is that it allocates the area to hold > the statistics as part of the ring structure. The ring structure doesn't > exist until device is up. > > I figured that there was no point in holding the extra space unless needed. > One more brief pci allocation was easier. Also, my code waits longer > (up to 10ms) and is CPU speed independent. > > Should I go back and fix the 8139cp? 8139cp fixes are welcome :) Jeff From chrisw@osdl.org Thu Mar 10 12:25:57 2005 Received: with ECARTIS (v1.0.0; list netdev); Thu, 10 Mar 2005 12:26:03 -0800 (PST) Received: from smtp.osdl.org (fire.osdl.org [65.172.181.4]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j2AKPvxi015079 for ; Thu, 10 Mar 2005 12:25:57 -0800 Received: from shell0.pdx.osdl.net (fw.osdl.org [65.172.181.6]) by smtp.osdl.org (8.12.8/8.12.8) with ESMTP id j2AKPmqi016679 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO); Thu, 10 Mar 2005 12:25:48 -0800 Received: from shell0.pdx.osdl.net (localhost [127.0.0.1]) by shell0.pdx.osdl.net (8.13.1/8.11.6) with ESMTP id j2AKPmYh012726; Thu, 10 Mar 2005 12:25:48 -0800 Received: (from chrisw@localhost) by shell0.pdx.osdl.net (8.13.1/8.13.1/Submit) id j2AKPmQW012725; Thu, 10 Mar 2005 12:25:48 -0800 Date: Thu, 10 Mar 2005 12:25:48 -0800 From: Chris Wright To: Jeff Garzik Cc: Andrew Morton , Linus Torvalds , Netdev , stable@kernel.org, Linux Kernel Subject: Re: [stable] [BK PATCHES] 2.6.x net driver oops fixes Message-ID: <20050310202548.GV5389@shell0.pdx.osdl.net> References: <422F59E8.2090707@pobox.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <422F59E8.2090707@pobox.com> User-Agent: Mutt/1.5.6i Received-SPF: pass (domain of chrisw@osdl.org designates 65.172.181.6 as permitted sender) X-MIMEDefang-Filter: osdl$Revision: 1.104 $ X-Scanned-By: MIMEDefang 2.36 X-Virus-Scanned: ClamAV 0.83/760/Wed Mar 9 09:12:01 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 2845 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: chrisw@osdl.org Precedence: bulk X-list: netdev Content-Length: 4595 Lines: 137 * Jeff Garzik (jgarzik@pobox.com) wrote: > This will update the following files: > > drivers/net/sis900.c | 41 +++++++++++++++++++++-------------------- > drivers/net/via-rhine.c | 3 +++ The via-rhine fix is already in the stable queue. But the sis900 oops fix does not apply to the stable tree. It relies on a few intermediate patches. Appears to still be an issue for the older version which is in 2.6.11. Here's a stab at a backport. Would you like to review/validate or drop this one? thanks, -chris ===== drivers/net/sis900.c 1.62 vs edited ===== --- 1.62/drivers/net/sis900.c 2005-01-10 08:52:27 -08:00 +++ edited/drivers/net/sis900.c 2005-03-10 12:23:49 -08:00 @@ -236,7 +236,7 @@ static int __devinit sis900_get_mac_addr signature = (u16) read_eeprom(ioaddr, EEPROMSignature); if (signature == 0xffff || signature == 0x0000) { printk (KERN_INFO "%s: Error EERPOM read %x\n", - net_dev->name, signature); + pci_name(pci_dev), signature); return 0; } @@ -268,7 +268,7 @@ static int __devinit sis630e_get_mac_add if (!isa_bridge) isa_bridge = pci_get_device(PCI_VENDOR_ID_SI, 0x0018, isa_bridge); if (!isa_bridge) { - printk("%s: Can not find ISA bridge\n", net_dev->name); + printk("%s: Can not find ISA bridge\n", pci_name(pci_dev)); return 0; } pci_read_config_byte(isa_bridge, 0x48, ®); @@ -456,10 +456,6 @@ static int __devinit sis900_probe(struct net_dev->tx_timeout = sis900_tx_timeout; net_dev->watchdog_timeo = TX_TIMEOUT; net_dev->ethtool_ops = &sis900_ethtool_ops; - - ret = register_netdev(net_dev); - if (ret) - goto err_unmap_rx; /* Get Mac address according to the chip revision */ pci_read_config_byte(pci_dev, PCI_CLASS_REVISION, &revision); @@ -476,7 +472,7 @@ static int __devinit sis900_probe(struct if (ret == 0) { ret = -ENODEV; - goto err_out_unregister; + goto err_unmap_rx; } /* 630ET : set the mii access mode as software-mode */ @@ -486,7 +482,7 @@ static int __devinit sis900_probe(struct /* probe for mii transceiver */ if (sis900_mii_probe(net_dev) == 0) { ret = -ENODEV; - goto err_out_unregister; + goto err_unmap_rx; } /* save our host bridge revision */ @@ -496,6 +492,10 @@ static int __devinit sis900_probe(struct pci_dev_put(dev); } + ret = register_netdev(net_dev); + if (ret) + goto err_unmap_rx; + /* print some information about our NIC */ printk(KERN_INFO "%s: %s at %#lx, IRQ %d, ", net_dev->name, card_name, ioaddr, net_dev->irq); @@ -505,8 +505,6 @@ static int __devinit sis900_probe(struct return 0; - err_out_unregister: - unregister_netdev(net_dev); err_unmap_rx: pci_free_consistent(pci_dev, RX_TOTAL_SIZE, sis_priv->rx_ring, sis_priv->rx_ring_dma); @@ -533,6 +531,7 @@ static int __devinit sis900_probe(struct static int __init sis900_mii_probe(struct net_device * net_dev) { struct sis900_private * sis_priv = net_dev->priv; + const char *dev_name = pci_name(sis_priv->pci_dev); u16 poll_bit = MII_STAT_LINK, status = 0; unsigned long timeout = jiffies + 5 * HZ; int phy_addr; @@ -582,21 +581,20 @@ static int __init sis900_mii_probe(struc mii_phy->phy_types = (mii_status & (MII_STAT_CAN_TX_FDX | MII_STAT_CAN_TX)) ? LAN : HOME; printk(KERN_INFO "%s: %s transceiver found at address %d.\n", - net_dev->name, mii_chip_table[i].name, + dev_name, mii_chip_table[i].name, phy_addr); break; } if( !mii_chip_table[i].phy_id1 ) { printk(KERN_INFO "%s: Unknown PHY transceiver found at address %d.\n", - net_dev->name, phy_addr); + dev_name, phy_addr); mii_phy->phy_types = UNKNOWN; } } if (sis_priv->mii == NULL) { - printk(KERN_INFO "%s: No MII transceivers found!\n", - net_dev->name); + printk(KERN_INFO "%s: No MII transceivers found!\n", dev_name); return 0; } @@ -621,7 +619,7 @@ static int __init sis900_mii_probe(struc poll_bit ^= (mdio_read(net_dev, sis_priv->cur_phy, MII_STATUS) & poll_bit); if (time_after_eq(jiffies, timeout)) { printk(KERN_WARNING "%s: reset phy and link down now\n", - net_dev->name); + dev_name); return -ETIME; } } @@ -691,7 +689,7 @@ static u16 sis900_default_phy(struct net sis_priv->mii = default_phy; sis_priv->cur_phy = default_phy->phy_addr; printk(KERN_INFO "%s: Using transceiver found at address %d as default\n", - net_dev->name,sis_priv->cur_phy); + pci_name(sis_priv->pci_dev), sis_priv->cur_phy); } status = mdio_read(net_dev, sis_priv->cur_phy, MII_CONTROL); From jgarzik@pobox.com Thu Mar 10 12:29:42 2005 Received: with ECARTIS (v1.0.0; list netdev); Thu, 10 Mar 2005 12:29:46 -0800 (PST) Received: from parcelfarce.linux.theplanet.co.uk (IDENT:93@parcelfarce.linux.theplanet.co.uk [195.92.249.252]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j2AKTf7e015614 for ; Thu, 10 Mar 2005 12:29:41 -0800 Received: from [69.134.152.124] (helo=[10.10.10.88]) by parcelfarce.linux.theplanet.co.uk with asmtp (TLSv1:AES256-SHA:256) (Exim 4.33) id 1D9UHr-0005bY-Jf; Thu, 10 Mar 2005 20:29:39 +0000 Message-ID: <4230AE24.602@pobox.com> Date: Thu, 10 Mar 2005 15:29:24 -0500 From: Jeff Garzik User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.3) Gecko/20040922 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Chris Wright CC: Andrew Morton , Linus Torvalds , Netdev , stable@kernel.org, Linux Kernel , Roger Luethi Subject: Re: [stable] [BK PATCHES] 2.6.x net driver oops fixes References: <422F59E8.2090707@pobox.com> <20050310202548.GV5389@shell0.pdx.osdl.net> In-Reply-To: <20050310202548.GV5389@shell0.pdx.osdl.net> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV 0.83/760/Wed Mar 9 09:12:01 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 2846 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: jgarzik@pobox.com Precedence: bulk X-list: netdev Content-Length: 681 Lines: 22 Chris Wright wrote: > * Jeff Garzik (jgarzik@pobox.com) wrote: > > >>This will update the following files: >> >> drivers/net/sis900.c | 41 +++++++++++++++++++++-------------------- >> drivers/net/via-rhine.c | 3 +++ > > > The via-rhine fix is already in the stable queue. But the sis900 oops > fix does not apply to the stable tree. It relies on a few intermediate > patches. Appears to still be an issue for the older version which is in > 2.6.11. Here's a stab at a backport. Would you like to review/validate > or drop this one? The backport looks correct to me, though it would be nice to get a via-rhine owner to ACK the patch before it goes in... Jeff From greg@kroah.com Thu Mar 10 12:31:24 2005 Received: with ECARTIS (v1.0.0; list netdev); Thu, 10 Mar 2005 12:31:27 -0800 (PST) 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 j2AKVNts016193 for ; Thu, 10 Mar 2005 12:31:23 -0800 Received: from [192.168.0.10] (c-24-22-118-199.client.comcast.net [24.22.118.199]) (authenticated) by perch.kroah.org (8.11.6/8.11.6) with ESMTP id j2AKVIi31073; Thu, 10 Mar 2005 12:31:18 -0800 Received: from greg by echidna.kroah.org with local (masqmail 0.2.19) id 1D9UJM-5IE-00; Thu, 10 Mar 2005 12:31:12 -0800 Date: Thu, 10 Mar 2005 12:31:12 -0800 From: Greg KH To: Chris Wright Cc: Jeff Garzik , Andrew Morton , Netdev , Linus Torvalds , stable@kernel.org, Linux Kernel Subject: Re: [BK PATCHES] 2.6.x net driver oops fixes Message-ID: <20050310203112.GA20337@kroah.com> References: <422F59E8.2090707@pobox.com> <20050310202548.GV5389@shell0.pdx.osdl.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20050310202548.GV5389@shell0.pdx.osdl.net> User-Agent: Mutt/1.5.8i X-Virus-Scanned: ClamAV 0.83/760/Wed Mar 9 09:12:01 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 2847 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 Content-Length: 709 Lines: 20 On Thu, Mar 10, 2005 at 12:25:48PM -0800, Chris Wright wrote: > * Jeff Garzik (jgarzik@pobox.com) wrote: > > > This will update the following files: > > > > drivers/net/sis900.c | 41 +++++++++++++++++++++-------------------- > > drivers/net/via-rhine.c | 3 +++ > > The via-rhine fix is already in the stable queue. But the sis900 oops > fix does not apply to the stable tree. It relies on a few intermediate > patches. Appears to still be an issue for the older version which is in > 2.6.11. Here's a stab at a backport. Would you like to review/validate > or drop this one? The pci_name() portion of this patch is not necessary for the -stable tree. Care to remove it? thanks, greg k-h From greg@kroah.com Thu Mar 10 13:36:04 2005 Received: with ECARTIS (v1.0.0; list netdev); Thu, 10 Mar 2005 13:36:10 -0800 (PST) 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 j2ALa3P5018355 for ; Thu, 10 Mar 2005 13:36:04 -0800 Received: from [192.168.0.10] (c-24-22-118-199.client.comcast.net [24.22.118.199]) (authenticated) by perch.kroah.org (8.11.6/8.11.6) with ESMTP id j2ALa0i21473; Thu, 10 Mar 2005 13:36:00 -0800 Received: from greg by echidna.kroah.org with local (masqmail 0.2.19) id 1D9VJy-5Tu-00; Thu, 10 Mar 2005 13:35:54 -0800 Date: Thu, 10 Mar 2005 13:35:54 -0800 From: Greg KH To: Chris Wright Cc: Andrew Morton , Netdev , Linus Torvalds , Jeff Garzik , stable@kernel.org, Linux Kernel Subject: Re: [BK PATCHES] 2.6.x net driver oops fixes Message-ID: <20050310213554.GA21061@kroah.com> References: <422F59E8.2090707@pobox.com> <20050310202548.GV5389@shell0.pdx.osdl.net> <20050310203112.GA20337@kroah.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20050310203112.GA20337@kroah.com> User-Agent: Mutt/1.5.8i X-Virus-Scanned: ClamAV 0.83/760/Wed Mar 9 09:12:01 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 2848 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 Content-Length: 838 Lines: 21 On Thu, Mar 10, 2005 at 12:31:12PM -0800, Greg KH wrote: > On Thu, Mar 10, 2005 at 12:25:48PM -0800, Chris Wright wrote: > > * Jeff Garzik (jgarzik@pobox.com) wrote: > > > > > This will update the following files: > > > > > > drivers/net/sis900.c | 41 +++++++++++++++++++++-------------------- > > > drivers/net/via-rhine.c | 3 +++ > > > > The via-rhine fix is already in the stable queue. But the sis900 oops > > fix does not apply to the stable tree. It relies on a few intermediate > > patches. Appears to still be an issue for the older version which is in > > 2.6.11. Here's a stab at a backport. Would you like to review/validate > > or drop this one? > > The pci_name() portion of this patch is not necessary for the -stable > tree. Care to remove it? Oh nevermind, I was completly wrong, it's fine. greg k-h From chrisw@osdl.org Thu Mar 10 13:39:33 2005 Received: with ECARTIS (v1.0.0; list netdev); Thu, 10 Mar 2005 13:39:38 -0800 (PST) Received: from smtp.osdl.org (fire.osdl.org [65.172.181.4]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j2ALdWWr018920 for ; Thu, 10 Mar 2005 13:39:33 -0800 Received: from shell0.pdx.osdl.net (fw.osdl.org [65.172.181.6]) by smtp.osdl.org (8.12.8/8.12.8) with ESMTP id j2ALdIqi023703 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO); Thu, 10 Mar 2005 13:39:19 -0800 Received: from shell0.pdx.osdl.net (localhost [127.0.0.1]) by shell0.pdx.osdl.net (8.13.1/8.11.6) with ESMTP id j2ALdHT4016418; Thu, 10 Mar 2005 13:39:17 -0800 Received: (from chrisw@localhost) by shell0.pdx.osdl.net (8.13.1/8.13.1/Submit) id j2ALdHtS016417; Thu, 10 Mar 2005 13:39:17 -0800 Date: Thu, 10 Mar 2005 13:39:17 -0800 From: Chris Wright To: Jeff Garzik Cc: Chris Wright , Andrew Morton , Linus Torvalds , Netdev , stable@kernel.org, Linux Kernel , Roger Luethi Subject: Re: [stable] [BK PATCHES] 2.6.x net driver oops fixes Message-ID: <20050310213917.GW5389@shell0.pdx.osdl.net> References: <422F59E8.2090707@pobox.com> <20050310202548.GV5389@shell0.pdx.osdl.net> <4230AE24.602@pobox.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4230AE24.602@pobox.com> User-Agent: Mutt/1.5.6i Received-SPF: pass (domain of chrisw@osdl.org designates 65.172.181.6 as permitted sender) X-MIMEDefang-Filter: osdl$Revision: 1.104 $ X-Scanned-By: MIMEDefang 2.36 X-Virus-Scanned: ClamAV 0.83/760/Wed Mar 9 09:12:01 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 2849 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: chrisw@osdl.org Precedence: bulk X-list: netdev Content-Length: 862 Lines: 25 * Jeff Garzik (jgarzik@pobox.com) wrote: > Chris Wright wrote: > >* Jeff Garzik (jgarzik@pobox.com) wrote: > > > > > >>This will update the following files: > >> > >>drivers/net/sis900.c | 41 +++++++++++++++++++++-------------------- > >>drivers/net/via-rhine.c | 3 +++ > > > > > >The via-rhine fix is already in the stable queue. But the sis900 oops > >fix does not apply to the stable tree. It relies on a few intermediate > >patches. Appears to still be an issue for the older version which is in > >2.6.11. Here's a stab at a backport. Would you like to review/validate > >or drop this one? > > The backport looks correct to me, though it would be nice to get a > via-rhine owner to ACK the patch before it goes in... OK, thanks. ITYM sis900 maintainer, is that still Ollie Lho as listed in MAINTAINERS (that's looking old)? thanks, -chris From cliffw@osdl.org Thu Mar 10 13:54:42 2005 Received: with ECARTIS (v1.0.0; list netdev); Thu, 10 Mar 2005 13:54:46 -0800 (PST) Received: from smtp.osdl.org (fire.osdl.org [65.172.181.4]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j2ALsfsi019682 for ; Thu, 10 Mar 2005 13:54:42 -0800 Received: from es175 (fw.osdl.org [65.172.181.6]) (authenticated bits=0) by smtp.osdl.org (8.12.8/8.12.8) with ESMTP id j2ALsaqi024917 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO) for ; Thu, 10 Mar 2005 13:54:36 -0800 Date: Thu, 10 Mar 2005 13:54:35 -0800 From: cliff white To: netdev@oss.sgi.com Subject: Ethtool doesn't work on Debian unstable? Message-ID: <20050310135435.23af10b8@es175> Organization: OSDL X-Mailer: Sylpheed-Claws 1.0.1 (GTK+ 1.2.10; i386-pc-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-MIMEDefang-Filter: osdl$Revision: 1.104 $ X-Scanned-By: MIMEDefang 2.36 X-Virus-Scanned: ClamAV 0.83/760/Wed Mar 9 09:12:01 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 2850 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: cliffw@osdl.org Precedence: bulk X-list: netdev Content-Length: 1361 Lines: 39 This is wierd. I know I am doing something Real Stupid, but i can't figure it out. Two systems. 2.6.11 kernel on both systems. One runs RedHat 9.0, and ethtool Just Works: ethtool -g eth0 Ring parameters for eth0: Pre-set maximums: RX: 256 RX Mini: 0 RX Jumbo: 0 TX: 256 Current hardware settings: RX: 64 RX Mini: 0 RX Jumbo: 0 TX: 64 -------------------- The other is Debian unstable, and nothing works: ethtool -g eth0 Ring parameters for eth0: Cannot get device ring settings: Operation not supported ------------------------ If i strace, i see the ioctl failing on the Debian side: 7657 munmap(0xb7fd6000, 75321) = 0 7657 socket(PF_INET, SOCK_DGRAM, IPPROTO_IP) = 3 7657 fstat64(1, {st_mode=S_IFCHR|0600, st_rdev=makedev(136, 5), ...}) = 0 7657 mmap2(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0xb7fe8000 7657 write(1, "Ring parameters for eth1:\n", 26) = 26 7657 ioctl(3, SIOCETHTOOL, 0xbffffd30) = -1 EOPNOTSUPP (Operation not supported) 7657 dup(2) = 4 ------------------------ Can anyone help me here? I'd like to use Debian for this testing, but so far, no love. cliffw -- "Ive always gone through periods where I bolt upright at four in the morning; now at least theres a reason." -Michael Feldman From andre@tomt.net Thu Mar 10 14:15:33 2005 Received: with ECARTIS (v1.0.0; list netdev); Thu, 10 Mar 2005 14:15:37 -0800 (PST) Received: from mx1.skjellin.no (mail1.skjellin.no [80.239.42.67]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j2AMFWaj020882 for ; Thu, 10 Mar 2005 14:15:33 -0800 Received: from localhost (localhost [127.0.0.1]) by mx1.skjellin.no (Postfix) with ESMTP id 4C5BE885DC; Thu, 10 Mar 2005 23:15:36 +0100 (CET) Received: from puppen.pasop.tomt.net (gw-fe-1.pasop.tomt.net [10.255.1.1]) by mail1.skjellin.no (Postfix) with ESMTP id D2BEF885D5; Thu, 10 Mar 2005 23:15:35 +0100 (CET) Received: from [10.255.1.10] (slurv.pasop.tomt.net [10.255.1.10]) by puppen.pasop.tomt.net (Postfix) with ESMTP id 445D322AD2; Thu, 10 Mar 2005 23:15:32 +0100 (CET) Message-ID: <4230C703.6060706@tomt.net> Date: Thu, 10 Mar 2005 23:15:31 +0100 From: Andre Tomt User-Agent: Mozilla Thunderbird 1.0 (Windows/20041206) X-Accept-Language: en-us, en MIME-Version: 1.0 To: cliff white Cc: netdev@oss.sgi.com Subject: Re: Ethtool doesn't work on Debian unstable? References: <20050310135435.23af10b8@es175> In-Reply-To: <20050310135435.23af10b8@es175> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV 0.83/760/Wed Mar 9 09:12:01 2005 on oss.sgi.com X-Virus-Scanned: by amavisd-new-20030616-p10 (Debian) at skjellin.no X-Virus-Status: Clean X-archive-position: 2851 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: andre@tomt.net Precedence: bulk X-list: netdev Content-Length: 1548 Lines: 41 cliff white wrote: > This is wierd. I know I am doing something Real Stupid, but i can't figure it out. > > Two systems. 2.6.11 kernel on both systems. > One runs RedHat 9.0, and ethtool Just Works: > ethtool -g eth0 > Ring parameters for eth0: > Pre-set maximums: > RX: 256 > RX Mini: 0 > RX Jumbo: 0 > TX: 256 > Current hardware settings: > RX: 64 > RX Mini: 0 > RX Jumbo: 0 > TX: 64 > -------------------- > The other is Debian unstable, and nothing works: > ethtool -g eth0 > Ring parameters for eth0: > Cannot get device ring settings: Operation not supported > ------------------------ > If i strace, i see the ioctl failing on the Debian side: > 7657 munmap(0xb7fd6000, 75321) = 0 > 7657 socket(PF_INET, SOCK_DGRAM, IPPROTO_IP) = 3 > 7657 fstat64(1, {st_mode=S_IFCHR|0600, st_rdev=makedev(136, 5), ...}) = 0 > 7657 mmap2(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0xb7fe8000 > 7657 write(1, "Ring parameters for eth1:\n", 26) = 26 > 7657 ioctl(3, SIOCETHTOOL, 0xbffffd30) = -1 EOPNOTSUPP (Operation not supported) > 7657 dup(2) = 4 > ------------------------ > Can anyone help me here? I'd like to use Debian for this testing, but so far, no love. > cliffw > > Most likely the other debian system just is using a network driver that do not support ethtool, or even just that ethtool command. ethtool support differs a lot between drivers, with quite a few not supporting ethtool at all. From cliffw@osdl.org Thu Mar 10 14:39:26 2005 Received: with ECARTIS (v1.0.0; list netdev); Thu, 10 Mar 2005 14:39:30 -0800 (PST) Received: from smtp.osdl.org (fire.osdl.org [65.172.181.4]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j2AMdPUR021849 for ; Thu, 10 Mar 2005 14:39:25 -0800 Received: from es175 (fw.osdl.org [65.172.181.6]) (authenticated bits=0) by smtp.osdl.org (8.12.8/8.12.8) with ESMTP id j2AMdJqi028268 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO) for ; Thu, 10 Mar 2005 14:39:20 -0800 Date: Thu, 10 Mar 2005 14:39:19 -0800 From: cliff white To: netdev@oss.sgi.com Subject: Re: Ethtool doesn't work on Debian unstable? Message-ID: <20050310143919.27c7b9f2@es175> In-Reply-To: <4230C703.6060706@tomt.net> References: <20050310135435.23af10b8@es175> <4230C703.6060706@tomt.net> Organization: OSDL X-Mailer: Sylpheed-Claws 1.0.1 (GTK+ 1.2.10; i386-pc-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-MIMEDefang-Filter: osdl$Revision: 1.104 $ X-Scanned-By: MIMEDefang 2.36 X-Virus-Scanned: ClamAV 0.83/760/Wed Mar 9 09:12:01 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 2852 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: cliffw@osdl.org Precedence: bulk X-list: netdev Content-Length: 908 Lines: 30 On Thu, 10 Mar 2005 23:15:31 +0100 Andre Tomt wrote: > cliff white wrote: > > This is wierd. I know I am doing something Real Stupid, but i can't figure it out. > > > > Two systems. 2.6.11 kernel on both systems. [snip] eration not supported) > > 7657 dup(2) = 4 > > ------------------------ > > Can anyone help me here? I'd like to use Debian for this testing, but so far, no love. > > cliffw > > > > > > Most likely the other debian system just is using a network driver that > do not support ethtool, or even just that ethtool command. ethtool > support differs a lot between drivers, with quite a few not supporting > ethtool at all. > Okay, my stupid. Had the wrong driver. Nothing to see here,move along cliffw -- "Ive always gone through periods where I bolt upright at four in the morning; now at least theres a reason." -Michael Feldman From olel@ans.pl Thu Mar 10 14:43:00 2005 Received: with ECARTIS (v1.0.0; list netdev); Thu, 10 Mar 2005 14:43:05 -0800 (PST) Received: from bizon.gios.gov.pl (bizon.gios.gov.pl [212.244.124.8]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j2AMgvOu022397 for ; Thu, 10 Mar 2005 14:42:59 -0800 Received: from bizon.gios.gov.pl (olel@localhost6 [IPv6:::1]) by bizon.gios.gov.pl (8.13.3/8.13.3) with ESMTP id j2AMglEV026160 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Thu, 10 Mar 2005 23:42:49 +0100 Received: from localhost (olel@localhost) by bizon.gios.gov.pl (8.13.3/8.13.3/Submit) with ESMTP id j2AMgjXQ026157 for ; Thu, 10 Mar 2005 23:42:47 +0100 X-Authentication-Warning: bizon.gios.gov.pl: olel owned process doing -bs Date: Thu, 10 Mar 2005 23:42:45 +0100 (CET) From: Krzysztof Oledzki X-X-Sender: olel@bizon.gios.gov.pl To: netdev@oss.sgi.com Subject: Problem with Linux-2.6.x+ipsec-tools & Linksys BEFSX41 Message-ID: MIME-Version: 1.0 Content-Type: MULTIPART/Mixed; BOUNDARY="-187430788-1267226255-1108125500=:11121" Content-ID: X-Virus-Scanned: ClamAV 0.83/760/Wed Mar 9 09:12:01 2005 on oss.sgi.com X-Virus-Scanned: by amavis-milter (http://www.amavis.org/) X-Virus-Status: Clean X-archive-position: 2853 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: olel@ans.pl Precedence: bulk X-list: netdev Content-Length: 9078 Lines: 179 This message is in MIME format. The first part should be readable text, while the remaining parts are likely unreadable without MIME-aware tools. ---187430788-1267226255-1108125500=:11121 Content-Type: TEXT/PLAIN; CHARSET=ISO-8859-2; FORMAT=flowed Content-Transfer-Encoding: QUOTED-PRINTABLE Content-ID: Hello, I have problem with IPSec between 2.6.x Linux native IPsec and Linksys BEFS= X41=20 router. Everything works fine until key renegotiation. Routers are able to= =20 exchange keys & setup IPSec connection: Feb 11 12:29:16 gw1 racoon: INFO: @(#)ipsec-tools 0.4 (http://ipsec-tools.s= ourceforge.net) Feb 11 12:29:16 gw1 racoon: INFO: @(#)This product linked OpenSSL 0.9.7e 25= Oct 2004 (http://www.openssl.org/) Feb 11 12:29:16 gw1 racoon: INFO: BBB.BB.BB.BB[500] used as isakmp port (fd= =3D7) Feb 11 12:29:16 gw1 racoon: INFO: IPsec-SA request for AA.AA.AAA.AAA queued= due to no phase1 found. Feb 11 12:29:16 gw1 racoon: INFO: initiate new phase 1 negotiation: BBB.BB.= BB.BB[500]<=3D>AA.AA.AAA.AAA[500] Feb 11 12:29:16 gw1 racoon: INFO: begin Identity Protection mode. Feb 11 12:29:19 gw1 racoon: INFO: ISAKMP-SA established BBB.BB.BB.BB[500]-A= A.AA.AAA.AAA[500] spi:5e657591032b23ce:3f6df2be5d610c99 Feb 11 12:29:20 gw1 racoon: INFO: initiate new phase 2 negotiation: BBB.BB.= BB.BB[0]<=3D>AA.AA.AAA.AAA[0] Feb 11 12:29:22 gw1 racoon: WARNING: attribute has been modified. Feb 11 12:29:22 gw1 racoon: INFO: IPsec-SA established: ESP/Tunnel AA.AA.AA= A.AAA->BBB.BB.BB.BB spi=3D151969078(0x90edd36) Feb 11 12:29:22 gw1 racoon: INFO: IPsec-SA established: ESP/Tunnel BBB.BB.B= B.BB->AA.AA.AAA.AAA spi=3D1042970307(0x3e2a76c3) After 48 minutes (hard limit is 3600s and soft 2880s) racoon starts negotia= ting=20 new keys and then tunnel stops working. Feb 11 13:17:22 gw1 racoon: INFO: IPsec-SA expired: ESP/Tunnel AA.AA.AAA.AA= A->BB.BB.BB.BB spi=3D151969078(0x90edd36) Feb 11 13:17:22 gw1 racoon: INFO: IPsec-SA request for AA.AA.AAA.AAA queued= due to no phase1 found. Feb 11 13:17:22 gw1 racoon: INFO: initiate new phase 1 negotiation: BB.BB.B= B.BB[500]<=3D>AA.AA.AAA.AAA[500] Feb 11 13:17:22 gw1 racoon: INFO: begin Identity Protection mode. Feb 11 13:17:22 gw1 racoon: INFO: IPsec-SA expired: ESP/Tunnel BB.BB.BB.BB-= >AA.AA.AAA.AAA spi=3D1042970307(0x3e2a76c3) Feb 11 13:17:31 gw1 racoon: INFO: ISAKMP-SA established BB.BB.BB.BB[500]-AA= =2EAA.AAA.AAA[500] spi:14cb86caec437624:0c11453a860aa178 Feb 11 13:17:32 gw1 racoon: INFO: initiate new phase 2 negotiation: BB.BB.B= B.BB[0]<=3D>AA.AA.AAA.AAA[0] Feb 11 13:17:35 gw1 racoon: WARNING: attribute has been modified. Feb 11 13:17:35 gw1 racoon: INFO: IPsec-SA established: ESP/Tunnel AA.AA.AA= A.AAA->BB.BB.BB.BB spi=3D151969078(0x90edd36) Feb 11 13:17:35 gw1 racoon: INFO: IPsec-SA established: ESP/Tunnel BB.BB.BB= =2EBB->AA.AA.AAA.AAA spi=3D456046736(0x1b2eb890) Feb 11 13:17:36 gw1 racoon: INFO: IPsec-SA expired: ESP/Tunnel AA.AA.AAA.AA= A->BB.BB.BB.BB spi=3D151969078(0x90edd36) Feb 11 13:17:36 gw1 racoon: INFO: initiate new phase 2 negotiation: BB.BB.B= B.BB[0]<=3D>AA.AA.AAA.AAA[0] Feb 11 13:17:48 gw1 racoon: WARNING: attribute has been modified. Feb 11 13:17:48 gw1 racoon: INFO: IPsec-SA established: ESP/Tunnel AA.AA.AA= A.AAA->BB.BB.BB.BB spi=3D151969078(0x90edd36) Feb 11 13:17:48 gw1 racoon: INFO: IPsec-SA established: ESP/Tunnel BB.BB.BB= =2EBB->AA.AA.AAA.AAA spi=3D984883126(0x3ab41fb6) Feb 11 13:17:49 gw1 racoon: INFO: IPsec-SA expired: ESP/Tunnel AA.AA.AAA.AA= A->BB.BB.BB.BB spi=3D151969078(0x90edd36) Feb 11 13:17:49 gw1 racoon: INFO: initiate new phase 2 negotiation: BB.BB.B= B.BB[0]<=3D>AA.AA.AAA.AAA[0] Feb 11 13:17:50 gw1 racoon: WARNING: attribute has been modified. Feb 11 13:17:50 gw1 racoon: INFO: IPsec-SA established: ESP/Tunnel AA.AA.AA= A.AAA->BB.BB.BB.BB spi=3D151969078(0x90edd36) Feb 11 13:17:50 gw1 racoon: INFO: IPsec-SA established: ESP/Tunnel BB.BB.BB= =2EBB->AA.AA.AAA.AAA spi=3D2443714535(0x91a81fe7) Feb 11 13:17:51 gw1 racoon: INFO: IPsec-SA expired: ESP/Tunnel AA.AA.AAA.AA= A->BB.BB.BB.BB spi=3D151969078(0x90edd36) Feb 11 13:17:51 gw1 racoon: INFO: initiate new phase 2 negotiation: BB.BB.B= B.BB[0]<=3D>AA.AA.AAA.AAA[0] Feb 11 13:17:52 gw1 racoon: WARNING: attribute has been modified. Feb 11 13:17:52 gw1 racoon: INFO: IPsec-SA established: ESP/Tunnel AA.AA.AA= A.AAA->BB.BB.BB.BB spi=3D151969078(0x90edd36) Feb 11 13:17:52 gw1 racoon: INFO: IPsec-SA established: ESP/Tunnel BB.BB.BB= =2EBB->AA.AA.AAA.AAA spi=3D891474119(0x3522d0c7) Feb 11 13:17:53 gw1 racoon: INFO: IPsec-SA expired: ESP/Tunnel AA.AA.AAA.AA= A->BB.BB.BB.BB spi=3D151969078(0x90edd36) Feb 11 13:17:53 gw1 racoon: INFO: initiate new phase 2 negotiation: BB.BB.B= B.BB[0]<=3D>AA.AA.AAA.AAA[0] Feb 11 13:17:56 gw1 racoon: WARNING: attribute has been modified. Feb 11 13:17:56 gw1 racoon: INFO: IPsec-SA established: ESP/Tunnel AA.AA.AA= A.AAA->BB.BB.BB.BB spi=3D151969078(0x90edd36) Feb 11 13:17:56 gw1 racoon: INFO: IPsec-SA established: ESP/Tunnel BB.BB.BB= =2EBB->AA.AA.AAA.AAA spi=3D3294034757(0xc456fb45) Feb 11 13:17:57 gw1 racoon: INFO: IPsec-SA expired: ESP/Tunnel AA.AA.AAA.AA= A->BB.BB.BB.BB spi=3D151969078(0x90edd36) Feb 11 13:17:57 gw1 racoon: INFO: initiate new phase 2 negotiation: BB.BB.B= B.BB[0]<=3D>AA.AA.AAA.AAA[0] Feb 11 13:17:59 gw1 racoon: WARNING: attribute has been modified. Feb 11 13:17:59 gw1 racoon: INFO: IPsec-SA established: ESP/Tunnel AA.AA.AA= A.AAA->BB.BB.BB.BB spi=3D151969078(0x90edd36) Feb 11 13:17:59 gw1 racoon: INFO: IPsec-SA established: ESP/Tunnel BB.BB.BB= =2EBB->AA.AA.AAA.AAA spi=3D1251852702(0x4a9dc19e) Feb 11 13:18:00 gw1 racoon: INFO: IPsec-SA expired: ESP/Tunnel AA.AA.AAA.AA= A->BB.BB.BB.BB spi=3D151969078(0x90edd36) Feb 11 13:18:00 gw1 racoon: INFO: initiate new phase 2 negotiation: BB.BB.B= B.BB[0]<=3D>AA.AA.AAA.AAA[0] Feb 11 13:18:02 gw1 racoon: WARNING: attribute has been modified. Feb 11 13:18:02 gw1 racoon: INFO: IPsec-SA established: ESP/Tunnel AA.AA.AA= A.AAA->BB.BB.BB.BB spi=3D151969078(0x90edd36) Feb 11 13:18:02 gw1 racoon: INFO: IPsec-SA established: ESP/Tunnel BB.BB.BB= =2EBB->AA.AA.AAA.AAA spi=3D522496593(0x1f24aa51) Feb 11 13:18:03 gw1 racoon: INFO: IPsec-SA expired: ESP/Tunnel AA.AA.AAA.AA= A->BB.BB.BB.BB spi=3D151969078(0x90edd36) Feb 11 13:18:03 gw1 racoon: INFO: initiate new phase 2 negotiation: BB.BB.B= B.BB[0]<=3D>AA.AA.AAA.AAA[0] Feb 11 13:18:06 gw1 racoon: WARNING: attribute has been modified. Feb 11 13:18:06 gw1 racoon: INFO: IPsec-SA established: ESP/Tunnel AA.AA.AA= A.AAA->BB.BB.BB.BB spi=3D151969078(0x90edd36) Feb 11 13:18:06 gw1 racoon: INFO: IPsec-SA established: ESP/Tunnel BB.BB.BB= =2EBB->AA.AA.AAA.AAA spi=3D1163930963(0x45602d53) Feb 11 13:18:07 gw1 racoon: INFO: IPsec-SA expired: ESP/Tunnel AA.AA.AAA.AA= A->BB.BB.BB.BB spi=3D151969078(0x90edd36) Feb 11 13:18:07 gw1 racoon: INFO: initiate new phase 2 negotiation: BB.BB.B= B.BB[0]<=3D>AA.AA.AAA.AAA[0] Feb 11 13:18:08 gw1 racoon: WARNING: attribute has been modified. Feb 11 13:18:08 gw1 racoon: INFO: IPsec-SA established: ESP/Tunnel AA.AA.AA= A.AAA->BB.BB.BB.BB spi=3D151969078(0x90edd36) Feb 11 13:18:08 gw1 racoon: INFO: IPsec-SA established: ESP/Tunnel BB.BB.BB= =2EBB->AA.AA.AAA.AAA spi=3D3167100563(0xbcc61e93) Feb 11 13:18:09 gw1 racoon: INFO: IPsec-SA expired: ESP/Tunnel AA.AA.AAA.AA= A->BB.BB.BB.BB spi=3D151969078(0x90edd36) Feb 11 13:18:09 gw1 racoon: INFO: initiate new phase 2 negotiation: BB.BB.B= B.BB[0]<=3D>AA.AA.AAA.AAA[0] (...) (...) Feb 11 13:23:46 gw1 racoon: ERROR: AA.AA.AAA.AAA give up to get IPsec-SA du= e to time up to wait. and finally... Feb 11 13:29:22 gw1 racoon: INFO: IPsec-SA expired: ESP/Tunnel AA.AA.AAA.AA= A->BB.BB.BB.BB spi=3D151969078(0x90edd36) Feb 11 13:29:22 gw1 racoon: INFO: IPsec-SA expired: ESP/Tunnel BB.BB.BB.BB-= >AA.AA.AAA.AAA spi=3D1042970307(0x3e2a76c3) And then I need to restart reacoon. I have already asked this question Ipsec-tools-devel ML but after some=20 additional test it seems that this it may be a bug in IPsec implementatnio= =20 on Linux - this tunnel works just fine on FreeBSD 4.10 & both racoons from= =20 KAME & ipsec-tools package. I tested Linux 2.4.10, 2.4.11-rc (1,2,3 & 4)=20 and finally 2.4.11 kernel, but this problem still exists. As far as I understand linux IPSec code, when a SA's soft limit is reached= =20 kernel sends notification to userspace daemon (racoon for example) and=20 asks it to get a new SA. I have changed expiration time to much smaller=20 values (hard: 120s, soft: 96s) and found that "renegotiation loop" only=20 exists in 96s-120s window. After 120s both SAs=20 (AA.AA.AAA.AAA->BBB.BB.BB.BB & BBB.BB.BB.BB->AA.AA.AAA.AAA) are removed=20 and then renegotiation loop stops. It is not clear to my why kernel tels=20 racoon about SA expiration more than once and why racoon can't simply=20 ignores additional messages? Anyway, such behavior can also be sometimes observerd between my two Linux= =20 routers but it happend very, very rarely. Best regards, =09=09=09Krzysztof Ol=EAdzki ---187430788-1267226255-1108125500=:11121-- From oxymoron@waste.org Thu Mar 10 15:01:23 2005 Received: with ECARTIS (v1.0.0; list netdev); Thu, 10 Mar 2005 15:01:27 -0800 (PST) Received: from waste.org (waste.org [216.27.176.166]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j2AN1Nuq023447 for ; Thu, 10 Mar 2005 15:01:23 -0800 Received: from waste.org (localhost [127.0.0.1]) by waste.org (8.13.2/8.13.2/Debian-1) with ESMTP id j2AN1HYp028380 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Thu, 10 Mar 2005 17:01:17 -0600 Received: (from oxymoron@localhost) by waste.org (8.13.2/8.13.2/Submit) id j2AN1HDH028376; Thu, 10 Mar 2005 17:01:17 -0600 Date: Thu, 10 Mar 2005 15:01:17 -0800 From: Matt Mackall To: Patrick McHardy Cc: Jeff Garzik , netdev@oss.sgi.com, Jeff Moyer Subject: Re: [PATCH 1/7] netpoll: shorten carrier detect timeout Message-ID: <20050310230117.GP3120@waste.org> References: <2.454130102@selenic.com> <422A4A38.4040303@trash.net> <20050306002015.GD3120@waste.org> <422A564D.4080809@trash.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <422A564D.4080809@trash.net> User-Agent: Mutt/1.5.6+20040907i X-Virus-Scanned: ClamAV 0.83/760/Wed Mar 9 09:12:01 2005 on oss.sgi.com X-Virus-Scanned: by amavisd-new X-Virus-Status: Clean X-archive-position: 2855 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: mpm@selenic.com Precedence: bulk X-list: netdev Content-Length: 1228 Lines: 32 On Sun, Mar 06, 2005 at 02:01:01AM +0100, Patrick McHardy wrote: > Matt Mackall wrote: > >On Sun, Mar 06, 2005 at 01:09:28AM +0100, Patrick McHardy wrote: > >> > >>The carrier detection looks partially broken to me. The current logic > >>detects an instantly available carrier as flaky because > >>netif_carrier_ok() takes less than 1/10s. This patch does what > >>I assume is intended, make sure the carrier is stable for 1/10s. Ok, on closer inspection, the current logic is: the NIC reports carrier detect nearly instaneously and thus its carrier detect reporting is considered unreliable. Rather than immediately sending packets, we wait for some interval for it to really be up so that the backlog of console messages doesn't get pumped into the bit bucket. So I'm going to change it from "flaky" to "untrustworthy" and add a comment. > How about this one ? I also removed oflags, reading it outside of > the locked section was racy. I'll do this as a separate patch. > >Did you try this with a card that otherwise goes into the wait? > > Yes, I tried with sk98lin. I don't have a card here that actually > supports netpoll. Huh? sk98lin appears to support it? -- Mathematics is the supreme nostalgia of our time. From jchapman@katalix.com Thu Mar 10 15:01:14 2005 Received: with ECARTIS (v1.0.0; list netdev); Thu, 10 Mar 2005 15:01:19 -0800 (PST) Received: from ptb-relay01.plus.net (ptb-relay01.plus.net [212.159.14.212]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j2AN1DLq023439 for ; Thu, 10 Mar 2005 15:01:14 -0800 Received: from [84.92.108.75] (helo=[192.168.1.10]) by ptb-relay01.plus.net with esmtp (Exim) id 1D9WeL-0003eL-Sy; Thu, 10 Mar 2005 23:01:01 +0000 Message-ID: <4230D1AC.5070506@katalix.com> Date: Thu, 10 Mar 2005 23:01:00 +0000 From: James Chapman User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.3) Gecko/20040910 X-Accept-Language: en, en-us MIME-Version: 1.0 To: Andy Fleming CC: Benjamin Herrenschmidt , netdev@oss.sgi.com, "David S. Miller" , linuxppc-embedded@ozlabs.org Subject: Re: RFC: PHY Abstraction Layer II References: <1107b64b01fb8e9a6c84359bb56881a6@freescale.com> <1110334456.32556.21.camel@gaston> <20050308194229.41c23707.davem@davemloft.net> <1110340214.32524.32.camel@gaston> <57a429f8eb807987d88b06129861d507@freescale.com> In-Reply-To: <57a429f8eb807987d88b06129861d507@freescale.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV 0.83/760/Wed Mar 9 09:12:01 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 2854 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: jchapman@katalix.com Precedence: bulk X-list: netdev Content-Length: 2207 Lines: 61 Hi Andy, Can you elaborate on why this phy abstraction is needed? In your original post, you mentioned that you were going to post a patch to show how your code would be hooked up in an existing net driver. Did I miss it? It would help in understanding the pros and cons of using genphy over using plain old mii.c. btw, I recently posted a patch to add GigE support to mii.c which is in Jeff's netdev-2.6 queue. Some register definitions were added in mii.h that will collide with yours. /james Andy Fleming wrote: > > On Mar 8, 2005, at 21:50, Benjamin Herrenschmidt wrote: > >> On Tue, 2005-03-08 at 19:42 -0800, David S. Miller wrote: >> >>> On Wed, 09 Mar 2005 13:14:16 +1100 >>> Benjamin Herrenschmidt wrote: >>> >>>> I'll have a closer look when I find some time, see if it makes sense to >>>> adapt sungem or not. >>> >>> >>> Especially because of the Broadcom PHYs I bet it doesn't. >>> >>> Too many chips have to reset the MAC, or do other fancy stuff >>> when programming the PHY to make this genphy thing very useful. >> >> >> Oh, I think genphy is just a generic driver, but his layer has hooks for >> other PHY drivers (wasn't it based on sungem_phy in the first place ?) > > > Definitely. Much of this code was culled from the sungem and ibm_emac > drivers, with some input from mii.c. The genphy driver is just one of > the 6 PHY drivers in the patch I sent (the others are Marvell, Davicom, > Cicada, QS, LXT). Actually, several of those files have multiple > drivers in them. The genphy driver is the fallback driver. It exists > for those PHYs which never get a driver, but don't need special attention. > >> >> I discussed several steps of the design with Andy, the idea was to have >> something a bit like sungem_phy.c with addditional common library for >> doing the link polling & fallback stuff etc... that could be easily >> shared by drivers. > > > Yup. I look forward to your input on how well the code meshes with what > people need for their drivers. > > _______________________________________________ > Linuxppc-embedded mailing list > Linuxppc-embedded@ozlabs.org > https://ozlabs.org/mailman/listinfo/linuxppc-embedded > From greg@kroah.com Thu Mar 10 15:10:03 2005 Received: with ECARTIS (v1.0.0; list netdev); Thu, 10 Mar 2005 15:10:10 -0800 (PST) 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 j2ANA3v4024591 for ; Thu, 10 Mar 2005 15:10:03 -0800 Received: from [192.168.0.10] (c-24-22-118-199.client.comcast.net [24.22.118.199]) (authenticated) by perch.kroah.org (8.11.6/8.11.6) with ESMTP id j2ANA0i07746; Thu, 10 Mar 2005 15:10:00 -0800 Received: from greg by echidna.kroah.org with local (masqmail 0.2.19) id 1D9Wmk-5nL-00; Thu, 10 Mar 2005 15:09:42 -0800 Date: Thu, 10 Mar 2005 15:09:42 -0800 From: Greg KH To: jgarzik@pobox.com, netdev@oss.sgi.com, herbert@gondor.apana.org.au, ollie@sis.com.tw, linux-net@vger.kernel.org Cc: linux-kernel@vger.kernel.org, stable@kernel.org Subject: [10/11] sis900 kernel oops fix Message-ID: <20050310230942.GK22112@kroah.com> References: <20050310230519.GA22112@kroah.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20050310230519.GA22112@kroah.com> User-Agent: Mutt/1.5.8i X-Virus-Scanned: ClamAV 0.83/760/Wed Mar 9 09:12:01 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 2856 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 Content-Length: 4926 Lines: 148 -stable review patch. If anyone has any objections, please let us know. ------------------ Backport of fix described below. From: Herbert Xu Fix bug #4223. OK, this happened because we got preempted before sis900_mii_probe finished setting the sis_priv->mii. Theoretically this can happen with SMP as well but I suppose the number of SMP machines with sis900 is fairly small. Anyway, the fix is to make sure that sis900_mii_probe is done before the device can be opened. This patch does it by moving the setup before register_netdevice. Since the netdev name is not available before register_netdev, I've changed the relevant printk's to use pci_name instead. Note that one of those printk's may be called after register_netdev as well. Signed-off-by: Chris Wright Signed-off-by: Greg Kroah-Hartman --- 1.62/drivers/net/sis900.c 2005-01-10 08:52:27 -08:00 +++ edited/drivers/net/sis900.c 2005-03-10 12:23:49 -08:00 @@ -236,7 +236,7 @@ static int __devinit sis900_get_mac_addr signature = (u16) read_eeprom(ioaddr, EEPROMSignature); if (signature == 0xffff || signature == 0x0000) { printk (KERN_INFO "%s: Error EERPOM read %x\n", - net_dev->name, signature); + pci_name(pci_dev), signature); return 0; } @@ -268,7 +268,7 @@ static int __devinit sis630e_get_mac_add if (!isa_bridge) isa_bridge = pci_get_device(PCI_VENDOR_ID_SI, 0x0018, isa_bridge); if (!isa_bridge) { - printk("%s: Can not find ISA bridge\n", net_dev->name); + printk("%s: Can not find ISA bridge\n", pci_name(pci_dev)); return 0; } pci_read_config_byte(isa_bridge, 0x48, ®); @@ -456,10 +456,6 @@ static int __devinit sis900_probe(struct net_dev->tx_timeout = sis900_tx_timeout; net_dev->watchdog_timeo = TX_TIMEOUT; net_dev->ethtool_ops = &sis900_ethtool_ops; - - ret = register_netdev(net_dev); - if (ret) - goto err_unmap_rx; /* Get Mac address according to the chip revision */ pci_read_config_byte(pci_dev, PCI_CLASS_REVISION, &revision); @@ -476,7 +472,7 @@ static int __devinit sis900_probe(struct if (ret == 0) { ret = -ENODEV; - goto err_out_unregister; + goto err_unmap_rx; } /* 630ET : set the mii access mode as software-mode */ @@ -486,7 +482,7 @@ static int __devinit sis900_probe(struct /* probe for mii transceiver */ if (sis900_mii_probe(net_dev) == 0) { ret = -ENODEV; - goto err_out_unregister; + goto err_unmap_rx; } /* save our host bridge revision */ @@ -496,6 +492,10 @@ static int __devinit sis900_probe(struct pci_dev_put(dev); } + ret = register_netdev(net_dev); + if (ret) + goto err_unmap_rx; + /* print some information about our NIC */ printk(KERN_INFO "%s: %s at %#lx, IRQ %d, ", net_dev->name, card_name, ioaddr, net_dev->irq); @@ -505,8 +505,6 @@ static int __devinit sis900_probe(struct return 0; - err_out_unregister: - unregister_netdev(net_dev); err_unmap_rx: pci_free_consistent(pci_dev, RX_TOTAL_SIZE, sis_priv->rx_ring, sis_priv->rx_ring_dma); @@ -533,6 +531,7 @@ static int __devinit sis900_probe(struct static int __init sis900_mii_probe(struct net_device * net_dev) { struct sis900_private * sis_priv = net_dev->priv; + const char *dev_name = pci_name(sis_priv->pci_dev); u16 poll_bit = MII_STAT_LINK, status = 0; unsigned long timeout = jiffies + 5 * HZ; int phy_addr; @@ -582,21 +581,20 @@ static int __init sis900_mii_probe(struc mii_phy->phy_types = (mii_status & (MII_STAT_CAN_TX_FDX | MII_STAT_CAN_TX)) ? LAN : HOME; printk(KERN_INFO "%s: %s transceiver found at address %d.\n", - net_dev->name, mii_chip_table[i].name, + dev_name, mii_chip_table[i].name, phy_addr); break; } if( !mii_chip_table[i].phy_id1 ) { printk(KERN_INFO "%s: Unknown PHY transceiver found at address %d.\n", - net_dev->name, phy_addr); + dev_name, phy_addr); mii_phy->phy_types = UNKNOWN; } } if (sis_priv->mii == NULL) { - printk(KERN_INFO "%s: No MII transceivers found!\n", - net_dev->name); + printk(KERN_INFO "%s: No MII transceivers found!\n", dev_name); return 0; } @@ -621,7 +619,7 @@ static int __init sis900_mii_probe(struc poll_bit ^= (mdio_read(net_dev, sis_priv->cur_phy, MII_STATUS) & poll_bit); if (time_after_eq(jiffies, timeout)) { printk(KERN_WARNING "%s: reset phy and link down now\n", - net_dev->name); + dev_name); return -ETIME; } } @@ -691,7 +689,7 @@ static u16 sis900_default_phy(struct net sis_priv->mii = default_phy; sis_priv->cur_phy = default_phy->phy_addr; printk(KERN_INFO "%s: Using transceiver found at address %d as default\n", - net_dev->name,sis_priv->cur_phy); + pci_name(sis_priv->pci_dev), sis_priv->cur_phy); } status = mdio_read(net_dev, sis_priv->cur_phy, MII_CONTROL); From greg@kroah.com Thu Mar 10 15:10:19 2005 Received: with ECARTIS (v1.0.0; list netdev); Thu, 10 Mar 2005 15:10:24 -0800 (PST) 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 j2ANAJeZ024690 for ; Thu, 10 Mar 2005 15:10:19 -0800 Received: from [192.168.0.10] (c-24-22-118-199.client.comcast.net [24.22.118.199]) (authenticated) by perch.kroah.org (8.11.6/8.11.6) with ESMTP id j2ANA9i08210; Thu, 10 Mar 2005 15:10:09 -0800 Received: from greg by echidna.kroah.org with local (masqmail 0.2.19) id 1D9WmY-5n9-00; Thu, 10 Mar 2005 15:09:30 -0800 Date: Thu, 10 Mar 2005 15:09:30 -0800 From: Greg KH To: shemminger@osdl.org, romieu@fr.zoreil.com, netdev@oss.sgi.com, jgarzik@pobox.com Cc: linux-kernel@vger.kernel.org, stable@kernel.org Subject: [09/11] r8169: receive descriptor length fix Message-ID: <20050310230930.GJ22112@kroah.com> References: <20050310230519.GA22112@kroah.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20050310230519.GA22112@kroah.com> User-Agent: Mutt/1.5.8i X-Virus-Scanned: ClamAV 0.83/760/Wed Mar 9 09:12:01 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 2857 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 Content-Length: 2007 Lines: 65 -stable review patch. If anyone has any objections, please let us know. ------------------ The status and received packets indication in the Rx descriptor ring are not correctly reset when a descriptor is recycled. Signed-off-by: Francois Romieu Signed-off-by: Chris Wright Signed-off-by: Greg Kroah-Hartman diff -puN drivers/net/r8169.c~r8169-490 drivers/net/r8169.c --- a/drivers/net/r8169.c~r8169-490 2005-03-08 00:01:26.000000000 +0100 +++ b/drivers/net/r8169.c 2005-03-09 00:38:34.235464833 +0100 @@ -1683,16 +1683,19 @@ static void rtl8169_free_rx_skb(struct r rtl8169_make_unusable_by_asic(desc); } -static inline void rtl8169_return_to_asic(struct RxDesc *desc, int rx_buf_sz) +static inline void rtl8169_mark_to_asic(struct RxDesc *desc, u32 rx_buf_sz) { - desc->opts1 |= cpu_to_le32(DescOwn + rx_buf_sz); + u32 eor = le32_to_cpu(desc->opts1) & RingEnd; + + desc->opts1 = cpu_to_le32(DescOwn | eor | rx_buf_sz); } -static inline void rtl8169_give_to_asic(struct RxDesc *desc, dma_addr_t mapping, - int rx_buf_sz) +static inline void rtl8169_map_to_asic(struct RxDesc *desc, dma_addr_t mapping, + u32 rx_buf_sz) { desc->addr = cpu_to_le64(mapping); - desc->opts1 |= cpu_to_le32(DescOwn + rx_buf_sz); + wmb(); + rtl8169_mark_to_asic(desc, rx_buf_sz); } static int rtl8169_alloc_rx_skb(struct pci_dev *pdev, struct sk_buff **sk_buff, @@ -1712,7 +1715,7 @@ static int rtl8169_alloc_rx_skb(struct p mapping = pci_map_single(pdev, skb->tail, rx_buf_sz, PCI_DMA_FROMDEVICE); - rtl8169_give_to_asic(desc, mapping, rx_buf_sz); + rtl8169_map_to_asic(desc, mapping, rx_buf_sz); out: return ret; @@ -2150,7 +2153,7 @@ static inline int rtl8169_try_rx_copy(st skb_reserve(skb, NET_IP_ALIGN); eth_copy_and_sum(skb, sk_buff[0]->tail, pkt_size, 0); *sk_buff = skb; - rtl8169_return_to_asic(desc, rx_buf_sz); + rtl8169_mark_to_asic(desc, rx_buf_sz); ret = 0; } } _ -- Ueimor From greg@kroah.com Thu Mar 10 15:10:25 2005 Received: with ECARTIS (v1.0.0; list netdev); Thu, 10 Mar 2005 15:10:35 -0800 (PST) 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 j2ANANRa024726 for ; Thu, 10 Mar 2005 15:10:25 -0800 Received: from [192.168.0.10] (c-24-22-118-199.client.comcast.net [24.22.118.199]) (authenticated) by perch.kroah.org (8.11.6/8.11.6) with ESMTP id j2ANAAi08214; Thu, 10 Mar 2005 15:10:10 -0800 Received: from greg by echidna.kroah.org with local (masqmail 0.2.19) id 1D9Wmr-5nX-00; Thu, 10 Mar 2005 15:09:49 -0800 Date: Thu, 10 Mar 2005 15:09:49 -0800 From: Greg KH To: rl@hellgate.ch, olof@austin.ibm.com, jgarzik@pobox.com, netdev@oss.sgi.com Cc: linux-kernel@vger.kernel.org, stable@kernel.org Subject: [11/11] [VIA RHINE] older chips oops on shutdown Message-ID: <20050310230949.GL22112@kroah.com> References: <20050310230519.GA22112@kroah.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20050310230519.GA22112@kroah.com> User-Agent: Mutt/1.5.8i X-Virus-Scanned: ClamAV 0.83/760/Wed Mar 9 09:12:01 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 2858 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 Content-Length: 3055 Lines: 89 -stable review patch. If anyone has any objections, please let us know. ------------------ Kernel 2.6.11, hardware is a MSI KT333-based board with an XP1800. I'm oopsing on shutdown on a machine that has a Via Rhine adapter in it: Unable to handle kernel paging request at virtual address e0803003 printing eip: c01f262c *pde = 014dc067 *pte = 00000000 Oops: 0000 [#1] Modules linked in: cpufreq_userspace cpufreq_powersave cpufreq_ondemand CPU: 0 EIP: 0060:[] Not tainted VLI EFLAGS: 00010292 (2.6.11) EIP is at ioread8+0x2c/0x40 eax: e0803003 ebx: e0803003 ecx: c026b430 edx: e0803003 esi: dff90260 edi: e0802f80 ebp: dd117e74 esp: dd117e74 ds: 007b es: 007b ss: 0068 Process reboot (pid: 5769, threadinfo=dd117000 task=dfafa080) Stack: dd117e8c c026b490 dff90040 c151ccd4 c044a1a8 b7fdc078 dd117ea4 c0253ad9 c151ccd4 00000042 fee1dead 00000001 dd117fbc c012461c c04d72a8 00000001 00000000 00010800 00000000 dd117ed8 c013b40b dffe7380 00030800 00000000 Call Trace: [] show_stack+0x7f/0xa0 [] show_registers+0x15a/0x1c0 [] die+0xce/0x150 [] do_page_fault+0x356/0x692 [] error_code+0x2b/0x30 [] rhine_shutdown+0x60/0x140 [] device_shutdown+0x89/0x8b [] sys_reboot+0xac/0x200 [] sysenter_past_esp+0x52/0x75 Code: 3d ff ff 03 00 89 c2 89 e5 77 20 66 31 c0 3d 00 00 01 00 75 0c 81 e2 ff ff 00 00 ec 0f b6 c0 c9 c3 0f 0b 37 00 7b 65 3b c0 eb ea <0f> b6 00 eb ec eb 0d 90 90 90 90 90 90 90 90 90 90 90 90 90 55 Seems like it is the ioread8 in: /* Hit power state D3 (sleep) */ iowrite8(ioread8(ioaddr + StickyHW) | 0x03, ioaddr + StickyHW); that fails. StickyHW is 0x83. lspci says: 0000:00:07.0 Ethernet controller: VIA Technologies, Inc. VT86C100A [Rhine] (rev 06) Flags: bus master, medium devsel, latency 32, IRQ 18 I/O ports at ec00 [size=128] Memory at dfffff80 (32-bit, non-prefetchable) [size=128] In other words, it's trying to read outside of the I/O range (0x80), which matches the fauling address. I'm guessing my chip revision doesn't support WOL, it's a crappy noname card. It does seem as if rhine_power_init checks quirks for rqWOL before touching any registers. Should rhine_shutdown do the same? Proposed patch below, which resolves the problem on my system. Check to make sure WOL is supported before setting it up in rhine_shutdown. Signed-off-by: Olof Johansson Signed-off-by: Chris Wright Signed-off-by: Greg Kroah-Hartman --- linux-2.6.11.orig/drivers/net/via-rhine.c 2005-03-02 01:38:32.000000000 -0600 +++ linux-2.6.11/drivers/net/via-rhine.c 2005-03-05 12:25:34.000000000 -0600 @@ -1899,6 +1899,9 @@ struct rhine_private *rp = netdev_priv(dev); void __iomem *ioaddr = rp->base; + if (!(rp->quirks & rqWOL)) + return; /* Nothing to do for non-WOL adapters */ + rhine_power_init(dev); /* Make sure we use pattern 0, 1 and not 4, 5 */ From greg@kroah.com Thu Mar 10 15:11:22 2005 Received: with ECARTIS (v1.0.0; list netdev); Thu, 10 Mar 2005 15:11:27 -0800 (PST) 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 j2ANBLgI025693 for ; Thu, 10 Mar 2005 15:11:22 -0800 Received: from [192.168.0.10] (c-24-22-118-199.client.comcast.net [24.22.118.199]) (authenticated) by perch.kroah.org (8.11.6/8.11.6) with ESMTP id j2ANA3i07872; Thu, 10 Mar 2005 15:10:03 -0800 Received: from greg by echidna.kroah.org with local (masqmail 0.2.19) id 1D9Wln-5mZ-00; Thu, 10 Mar 2005 15:08:43 -0800 Date: Thu, 10 Mar 2005 15:08:43 -0800 From: Greg KH To: davem@davemloft.net, kuznet@ms2.inr.ac.ru, pekkas@netcore.fi, jmorris@redhat.com, yoshfuji@linux-ipv6.org, kaber@coreworks.de, netdev@oss.sgi.com Cc: linux-kernel@vger.kernel.org, stable@kernel.org Subject: [06/11] [TCP]: Put back tcp_timer_bug_msg[] symbol export. Message-ID: <20050310230843.GG22112@kroah.com> References: <20050310230519.GA22112@kroah.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20050310230519.GA22112@kroah.com> User-Agent: Mutt/1.5.8i X-Virus-Scanned: ClamAV 0.83/760/Wed Mar 9 09:12:01 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 2859 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 Content-Length: 1081 Lines: 36 -stable review patch. If anyone has any objections, please let us know. ------------------ This wrecks the ipv6 modular build for a lot of people. In fact, since I always build ipv6 modular I am surprised I never hit this. My best guess is that my compiler is optimizing the reference away, but that can never be depended upon and the symbol export really is needed. [TCP]: Put back tcp_timer_bug_msg[] symbol export. It is needed for tcp_reset_xmit_timer(), which is invoked by tcp_prequeue() which is invoked from tcp_ipv6.c Signed-off-by: Hideaki YOSHIFUJI Signed-off-by: David S. Miller Signed-off-by: Chris Wright Signed-off-by: Greg Kroah-Hartman diff -Nru a/net/ipv4/tcp_timer.c b/net/ipv4/tcp_timer.c --- a/net/ipv4/tcp_timer.c 2005-03-09 17:20:38 -08:00 +++ b/net/ipv4/tcp_timer.c 2005-03-09 17:20:38 -08:00 @@ -38,6 +38,7 @@ #ifdef TCP_DEBUG const char tcp_timer_bug_msg[] = KERN_DEBUG "tcpbug: unknown timer value\n"; +EXPORT_SYMBOL(tcp_timer_bug_msg); #endif /* From benh@kernel.crashing.org Thu Mar 10 15:11:50 2005 Received: with ECARTIS (v1.0.0; list netdev); Thu, 10 Mar 2005 15:11:56 -0800 (PST) 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 j2ANBngM025970 for ; Thu, 10 Mar 2005 15:11:50 -0800 Received: from gaston (localhost [127.0.0.1]) by gate.crashing.org (8.12.8/8.12.8) with ESMTP id j2AN9agJ015916; Thu, 10 Mar 2005 17:09:37 -0600 Subject: Re: RFC: PHY Abstraction Layer II From: Benjamin Herrenschmidt To: James Chapman Cc: Andy Fleming , netdev@oss.sgi.com, "David S. Miller" , linuxppc-embedded@ozlabs.org In-Reply-To: <4230D1AC.5070506@katalix.com> References: <1107b64b01fb8e9a6c84359bb56881a6@freescale.com> <1110334456.32556.21.camel@gaston> <20050308194229.41c23707.davem@davemloft.net> <1110340214.32524.32.camel@gaston> <57a429f8eb807987d88b06129861d507@freescale.com> <4230D1AC.5070506@katalix.com> Content-Type: text/plain Date: Fri, 11 Mar 2005 10:06:32 +1100 Message-Id: <1110495992.32525.290.camel@gaston> Mime-Version: 1.0 X-Mailer: Evolution 2.0.3 Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV 0.83/760/Wed Mar 9 09:12:01 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 2860 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 Content-Length: 965 Lines: 25 On Thu, 2005-03-10 at 23:01 +0000, James Chapman wrote: > Hi Andy, > > Can you elaborate on why this phy abstraction is needed? > > In your original post, you mentioned that you were going to post a > patch to show how your code would be hooked up in an existing net > driver. Did I miss it? It would help in understanding the pros and cons > of using genphy over using plain old mii.c. > > btw, I recently posted a patch to add GigE support to mii.c which is > in Jeff's netdev-2.6 queue. Some register definitions were added in > mii.h that will collide with yours. A variety of PHY chips require special cases that aren't handled by the generic mii code. The PHY driver layer allows to plug PHY specific drivers, with genphy just being the "default" for sane chips. Also, I think Andy added more to the PHY layer than what mii does, like support for the interrupt or timer based link management etc... which tend to be the same in a lot of drivers. Ben. From SRS0+3dc48974f7cf3ae35923+564+infradead.org+hch@pentafluge.srs.infradead.org Thu Mar 10 15:20:31 2005 Received: with ECARTIS (v1.0.0; list netdev); Thu, 10 Mar 2005 15:20:34 -0800 (PST) Received: from pentafluge.infradead.org (pentafluge.infradead.org [213.146.154.40]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j2ANKUKR027273 for ; Thu, 10 Mar 2005 15:20:31 -0800 Received: from hch by pentafluge.infradead.org with local (Exim 4.43 #1 (Red Hat Linux)) id 1D9Wwx-000054-9i; Thu, 10 Mar 2005 23:20:15 +0000 Date: Thu, 10 Mar 2005 23:20:14 +0000 From: Christoph Hellwig To: Greg KH Cc: davem@davemloft.net, kuznet@ms2.inr.ac.ru, pekkas@netcore.fi, jmorris@redhat.com, yoshfuji@linux-ipv6.org, kaber@coreworks.de, netdev@oss.sgi.com, linux-kernel@vger.kernel.org, stable@kernel.org Subject: Re: [06/11] [TCP]: Put back tcp_timer_bug_msg[] symbol export. Message-ID: <20050310232014.GA32228@infradead.org> Mail-Followup-To: Christoph Hellwig , Greg KH , davem@davemloft.net, kuznet@ms2.inr.ac.ru, pekkas@netcore.fi, jmorris@redhat.com, yoshfuji@linux-ipv6.org, kaber@coreworks.de, netdev@oss.sgi.com, linux-kernel@vger.kernel.org, stable@kernel.org References: <20050310230519.GA22112@kroah.com> <20050310230843.GG22112@kroah.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20050310230843.GG22112@kroah.com> User-Agent: Mutt/1.4.1i X-SRS-Rewrite: SMTP reverse-path rewritten from by pentafluge.infradead.org See http://www.infradead.org/rpr.html X-Virus-Scanned: ClamAV 0.83/760/Wed Mar 9 09:12:01 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 2861 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: hch@infradead.org Precedence: bulk X-list: netdev Content-Length: 396 Lines: 12 > --- a/net/ipv4/tcp_timer.c 2005-03-09 17:20:38 -08:00 > +++ b/net/ipv4/tcp_timer.c 2005-03-09 17:20:38 -08:00 > @@ -38,6 +38,7 @@ > > #ifdef TCP_DEBUG > const char tcp_timer_bug_msg[] = KERN_DEBUG "tcpbug: unknown timer value\n"; > +EXPORT_SYMBOL(tcp_timer_bug_msg); > #endif not complaining about putting this into -stable, but why do people have TCP_DEBUG turned on for normal builds? From oxymoron@waste.org Thu Mar 10 15:21:45 2005 Received: with ECARTIS (v1.0.0; list netdev); Thu, 10 Mar 2005 15:21:50 -0800 (PST) Received: from waste.org (waste.org [216.27.176.166]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j2ANLjq5027969 for ; Thu, 10 Mar 2005 15:21:45 -0800 Received: from waste.org (localhost [127.0.0.1]) by waste.org (8.13.2/8.13.2/Debian-1) with ESMTP id j2ANLcJM031653 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Thu, 10 Mar 2005 17:21:38 -0600 Received: (from oxymoron@localhost) by waste.org (8.13.2/8.13.2/Submit) id j2ANLcOD031650; Thu, 10 Mar 2005 17:21:38 -0600 Date: Thu, 10 Mar 2005 15:21:38 -0800 From: Matt Mackall To: Dave Miller , netdev@oss.sgi.com, Patrick McHardy Subject: [PATCH] netpoll carrier clarification Message-ID: <20050310232138.GQ3120@waste.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.5.6+20040907i X-Virus-Scanned: ClamAV 0.83/760/Wed Mar 9 09:12:01 2005 on oss.sgi.com X-Virus-Scanned: by amavisd-new X-Virus-Status: Clean X-archive-position: 2862 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: mpm@selenic.com Precedence: bulk X-list: netdev Content-Length: 1200 Lines: 40 Clarify the flaky carrier detect code and use msleep(). Signed-off-by: Matt Mackall Index: np/net/core/netpoll.c =================================================================== --- np.orig/net/core/netpoll.c 2005-03-10 16:47:54.000000000 -0600 +++ np/net/core/netpoll.c 2005-03-10 17:15:34.000000000 -0600 @@ -18,6 +18,7 @@ #include #include #include +#include #include #include #include @@ -660,12 +661,16 @@ int netpoll_setup(struct netpoll *np) cond_resched(); } + /* If carrier appears to come up instantly, we don't + * trust it and pause so that we don't pump all our + * queued console messages into the bitbucket. + */ + if (time_before(jiffies, atleast)) { - printk(KERN_NOTICE "%s: carrier detect appears flaky," - " waiting 4 seconds\n", + printk(KERN_NOTICE "%s: carrier detect appears" + " untrustworthy, waiting 4 seconds\n", np->name); - while (time_before(jiffies, atmost)) - cond_resched(); + msleep(4000); } } -- Mathematics is the supreme nostalgia of our time. From oxymoron@waste.org Thu Mar 10 15:22:52 2005 Received: with ECARTIS (v1.0.0; list netdev); Thu, 10 Mar 2005 15:22:56 -0800 (PST) Received: from waste.org (waste.org [216.27.176.166]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j2ANMqMF028509 for ; Thu, 10 Mar 2005 15:22:52 -0800 Received: from waste.org (localhost [127.0.0.1]) by waste.org (8.13.2/8.13.2/Debian-1) with ESMTP id j2ANMkMQ031801 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Thu, 10 Mar 2005 17:22:46 -0600 Received: (from oxymoron@localhost) by waste.org (8.13.2/8.13.2/Submit) id j2ANMkkl031793; Thu, 10 Mar 2005 17:22:46 -0600 Date: Thu, 10 Mar 2005 15:22:46 -0800 From: Matt Mackall To: Dave Miller , netdev@oss.sgi.com, Patrick McHardy Subject: [PATCH] netpoll fix racy dev->flags usage Message-ID: <20050310232245.GR3120@waste.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.5.6+20040907i X-Virus-Scanned: ClamAV 0.83/760/Wed Mar 9 09:12:01 2005 on oss.sgi.com X-Virus-Scanned: by amavisd-new X-Virus-Status: Clean X-archive-position: 2863 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: mpm@selenic.com Precedence: bulk X-list: netdev Content-Length: 914 Lines: 29 Put ndev->flags usage under the lock. Spotted by Patrick McHardy. Signed-off-by: Matt Mackall Index: np/net/core/netpoll.c =================================================================== --- np.orig/net/core/netpoll.c 2005-03-10 17:02:03.000000000 -0600 +++ np/net/core/netpoll.c 2005-03-10 17:12:46.000000000 -0600 @@ -632,16 +632,13 @@ int netpoll_setup(struct netpoll *np) } if (!netif_running(ndev)) { - unsigned short oflags; unsigned long atmost, atleast; printk(KERN_INFO "%s: device %s not up yet, forcing it\n", np->name, np->dev_name); - oflags = ndev->flags; - rtnl_shlock(); - if (dev_change_flags(ndev, oflags | IFF_UP) < 0) { + if (dev_change_flags(ndev, ndev->flags | IFF_UP) < 0) { printk(KERN_ERR "%s: failed to open %s\n", np->name, np->dev_name); rtnl_shunlock(); -- Mathematics is the supreme nostalgia of our time. From jgarzik@pobox.com Thu Mar 10 15:28:07 2005 Received: with ECARTIS (v1.0.0; list netdev); Thu, 10 Mar 2005 15:28:11 -0800 (PST) Received: from parcelfarce.linux.theplanet.co.uk (IDENT:93@parcelfarce.linux.theplanet.co.uk [195.92.249.252]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j2ANS6Y8029295 for ; Thu, 10 Mar 2005 15:28:07 -0800 Received: from [69.134.152.124] (helo=[10.10.10.88]) by parcelfarce.linux.theplanet.co.uk with asmtp (TLSv1:AES256-SHA:256) (Exim 4.33) id 1D9X4W-0000Gd-3F; Thu, 10 Mar 2005 23:28:04 +0000 Message-ID: <4230D7F4.8060900@pobox.com> Date: Thu, 10 Mar 2005 18:27:48 -0500 From: Jeff Garzik User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.3) Gecko/20040922 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Benjamin Herrenschmidt CC: James Chapman , Andy Fleming , netdev@oss.sgi.com, "David S. Miller" , linuxppc-embedded@ozlabs.org Subject: Re: RFC: PHY Abstraction Layer II References: <1107b64b01fb8e9a6c84359bb56881a6@freescale.com> <1110334456.32556.21.camel@gaston> <20050308194229.41c23707.davem@davemloft.net> <1110340214.32524.32.camel@gaston> <57a429f8eb807987d88b06129861d507@freescale.com> <4230D1AC.5070506@katalix.com> <1110495992.32525.290.camel@gaston> In-Reply-To: <1110495992.32525.290.camel@gaston> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV 0.83/760/Wed Mar 9 09:12:01 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 2864 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: jgarzik@pobox.com Precedence: bulk X-list: netdev Content-Length: 1379 Lines: 38 Benjamin Herrenschmidt wrote: > On Thu, 2005-03-10 at 23:01 +0000, James Chapman wrote: > >>Hi Andy, >> >>Can you elaborate on why this phy abstraction is needed? >> >>In your original post, you mentioned that you were going to post a >>patch to show how your code would be hooked up in an existing net >>driver. Did I miss it? It would help in understanding the pros and cons >>of using genphy over using plain old mii.c. >> >>btw, I recently posted a patch to add GigE support to mii.c which is >>in Jeff's netdev-2.6 queue. Some register definitions were added in >>mii.h that will collide with yours. > > > A variety of PHY chips require special cases that aren't handled by the > generic mii code. The PHY driver layer allows to plug PHY specific > drivers, with genphy just being the "default" for sane chips. > > Also, I think Andy added more to the PHY layer than what mii does, like > support for the interrupt or timer based link management etc... which > tend to be the same in a lot of drivers. Nod. I haven't had time to review the phy abstraction layer, but my gut feeling is that there are several common code patterns which could be abstracted out, to save code. Typically there will be one or more phy-specific functions in each 10/100 or GigE driver, falling back to a default 'genphy' driver when things are completely MII/GMII-compatible. Jeff From benh@kernel.crashing.org Thu Mar 10 15:33:32 2005 Received: with ECARTIS (v1.0.0; list netdev); Thu, 10 Mar 2005 15:33:35 -0800 (PST) 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 j2ANXTnX029898 for ; Thu, 10 Mar 2005 15:33:31 -0800 Received: from gaston (localhost [127.0.0.1]) by gate.crashing.org (8.12.8/8.12.8) with ESMTP id j2ANUpgJ016386; Thu, 10 Mar 2005 17:31:17 -0600 Subject: Re: RFC: PHY Abstraction Layer II From: Benjamin Herrenschmidt To: Jeff Garzik Cc: James Chapman , Andy Fleming , netdev@oss.sgi.com, "David S. Miller" , linuxppc-embedded@ozlabs.org In-Reply-To: <4230D7F4.8060900@pobox.com> References: <1107b64b01fb8e9a6c84359bb56881a6@freescale.com> <1110334456.32556.21.camel@gaston> <20050308194229.41c23707.davem@davemloft.net> <1110340214.32524.32.camel@gaston> <57a429f8eb807987d88b06129861d507@freescale.com> <4230D1AC.5070506@katalix.com> <1110495992.32525.290.camel@gaston> <4230D7F4.8060900@pobox.com> Content-Type: text/plain Date: Fri, 11 Mar 2005 10:27:47 +1100 Message-Id: <1110497267.32524.295.camel@gaston> Mime-Version: 1.0 X-Mailer: Evolution 2.0.3 Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV 0.83/760/Wed Mar 9 09:12:01 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 2865 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 Content-Length: 567 Lines: 16 On Thu, 2005-03-10 at 18:27 -0500, Jeff Garzik wrote: > I haven't had time to review the phy abstraction layer, but my gut > feeling is that there are several common code patterns which could be > abstracted out, to save code. > > Typically there will be one or more phy-specific functions in each > 10/100 or GigE driver, falling back to a default 'genphy' driver when > things are completely MII/GMII-compatible. Exactly. One thing for which i usually need PHY specific functions (pretty much all the time) is PHY init (thanks Broadcom) and suspend. Ben. From shemminger@osdl.org Thu Mar 10 15:44:28 2005 Received: with ECARTIS (v1.0.0; list netdev); Thu, 10 Mar 2005 15:44:34 -0800 (PST) Received: from smtp.osdl.org (fire.osdl.org [65.172.181.4]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j2ANiSV7030662 for ; Thu, 10 Mar 2005 15:44:28 -0800 Received: from shell0.pdx.osdl.net (fw.osdl.org [65.172.181.6]) by smtp.osdl.org (8.12.8/8.12.8) with ESMTP id j2ANiLqi001474 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO); Thu, 10 Mar 2005 15:44:21 -0800 Received: from dxpl.pdx.osdl.net (dxpl.pdx.osdl.net [172.20.1.103]) by shell0.pdx.osdl.net (8.13.1/8.11.6) with ESMTP id j2ANiLJe023255; Thu, 10 Mar 2005 15:44:21 -0800 Date: Thu, 10 Mar 2005 15:44:39 -0800 From: Stephen Hemminger To: "David S. Miller" Cc: netdev@oss.sgi.com Subject: [PATCH] optimize is_valid_ether_addr Message-ID: <20050310154439.75f62f22@dxpl.pdx.osdl.net> Organization: Open Source Development Lab X-Mailer: Sylpheed-Claws 1.0.1 (GTK+ 1.2.10; x86_64-unknown-linux-gnu) X-Face: &@E+xe?c%:&e4D{>f1O<&U>2qwRREG5!}7R4;D<"NO^UI2mJ[eEOA2*3>(`Th.yP,VDPo9$ /`~cw![cmj~~jWe?AHY7D1S+\}5brN0k*NE?pPh_'_d>6;XGG[\KDRViCfumZT3@[ Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Received-SPF: pass (domain of shemminger@osdl.org designates 65.172.181.6 as permitted sender) X-MIMEDefang-Filter: osdl$Revision: 1.104 $ X-Scanned-By: MIMEDefang 2.36 X-Virus-Scanned: ClamAV 0.83/760/Wed Mar 9 09:12:01 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 2870 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: shemminger@osdl.org Precedence: bulk X-list: netdev Content-Length: 1154 Lines: 39 Low level optimization of the comparison with zero address. On most cpu's faster to use unrolled or rather than a loop and memcmp. This is in the fastpath of bridge forwarding. Signed-off-by: Stephen Hemminger diff -Nru a/include/linux/etherdevice.h b/include/linux/etherdevice.h --- a/include/linux/etherdevice.h 2005-03-10 15:02:04 -08:00 +++ b/include/linux/etherdevice.h 2005-03-10 15:02:04 -08:00 @@ -47,6 +47,15 @@ } /** + * is_zero_ether_addr - Determine if give Ethernet address is all + * zeros. + */ +static inline int is_zero_ether_addr(const u8 *addr) +{ + return !(addr[0] | addr[1] | addr[2] | addr[3] | addr[4] | addr[5]); +} + +/** * is_valid_ether_addr - Determine if the given Ethernet address is valid * @addr: Pointer to a six-byte array containing the Ethernet address * @@ -56,11 +65,9 @@ * * Return true if the address is valid. */ -static inline int is_valid_ether_addr( const u8 *addr ) +static inline int is_valid_ether_addr(const u8 *addr) { - const char zaddr[6] = {0,}; - - return !(addr[0]&1) && memcmp( addr, zaddr, 6); + return !(addr[0]&1) && !is_zero_ether_addr(addr); } /** From shemminger@osdl.org Thu Mar 10 15:44:19 2005 Received: with ECARTIS (v1.0.0; list netdev); Thu, 10 Mar 2005 15:44:24 -0800 (PST) Received: from smtp.osdl.org (fire.osdl.org [65.172.181.4]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j2ANiJW9030637 for ; Thu, 10 Mar 2005 15:44:19 -0800 Received: from shell0.pdx.osdl.net (fw.osdl.org [65.172.181.6]) by smtp.osdl.org (8.12.8/8.12.8) with ESMTP id j2ANiCqi001454 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO); Thu, 10 Mar 2005 15:44:12 -0800 Received: from dxpl.pdx.osdl.net (dxpl.pdx.osdl.net [172.20.1.103]) by shell0.pdx.osdl.net (8.13.1/8.11.6) with ESMTP id j2ANiCtK023243; Thu, 10 Mar 2005 15:44:12 -0800 Date: Thu, 10 Mar 2005 15:44:29 -0800 From: Stephen Hemminger To: "David S. Miller" Cc: netdev@oss.sgi.com, bridge@osdl.org Subject: [PATCH] (1/4) bridge: use jenkins hash Message-ID: <20050310154429.0f879894@dxpl.pdx.osdl.net> Organization: Open Source Development Lab X-Mailer: Sylpheed-Claws 1.0.1 (GTK+ 1.2.10; x86_64-unknown-linux-gnu) X-Face: &@E+xe?c%:&e4D{>f1O<&U>2qwRREG5!}7R4;D<"NO^UI2mJ[eEOA2*3>(`Th.yP,VDPo9$ /`~cw![cmj~~jWe?AHY7D1S+\}5brN0k*NE?pPh_'_d>6;XGG[\KDRViCfumZT3@[ Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Received-SPF: pass (domain of shemminger@osdl.org designates 65.172.181.6 as permitted sender) X-MIMEDefang-Filter: osdl$Revision: 1.104 $ X-Scanned-By: MIMEDefang 2.36 X-Virus-Scanned: ClamAV 0.83/760/Wed Mar 9 09:12:01 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 2866 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: shemminger@osdl.org Precedence: bulk X-list: netdev Content-Length: 1021 Lines: 37 Replace the existing mac hash in the bridge code with the nice inline jenkins hash. This should provide better distribution across hash buckets and compiles to code that is similar in complexity. Signed-off-by: Stephen Hemminger diff -Nru a/net/bridge/br_fdb.c b/net/bridge/br_fdb.c --- a/net/bridge/br_fdb.c 2005-03-10 15:05:11 -08:00 +++ b/net/bridge/br_fdb.c 2005-03-10 15:05:11 -08:00 @@ -19,6 +19,7 @@ #include #include #include +#include #include #include "br_private.h" @@ -57,18 +58,7 @@ static __inline__ int br_mac_hash(const unsigned char *mac) { - unsigned long x; - - x = mac[0]; - x = (x << 2) ^ mac[1]; - x = (x << 2) ^ mac[2]; - x = (x << 2) ^ mac[3]; - x = (x << 2) ^ mac[4]; - x = (x << 2) ^ mac[5]; - - x ^= x >> 8; - - return x & (BR_HASH_SIZE - 1); + return jhash(mac, ETH_ALEN, 0) & (BR_HASH_SIZE - 1); } static __inline__ void fdb_delete(struct net_bridge_fdb_entry *f) From shemminger@osdl.org Thu Mar 10 15:44:23 2005 Received: with ECARTIS (v1.0.0; list netdev); Thu, 10 Mar 2005 15:44:27 -0800 (PST) Received: from smtp.osdl.org (fire.osdl.org [65.172.181.4]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j2ANiMwo030640 for ; Thu, 10 Mar 2005 15:44:23 -0800 Received: from shell0.pdx.osdl.net (fw.osdl.org [65.172.181.6]) by smtp.osdl.org (8.12.8/8.12.8) with ESMTP id j2ANiFqi001460 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO); Thu, 10 Mar 2005 15:44:15 -0800 Received: from dxpl.pdx.osdl.net (dxpl.pdx.osdl.net [172.20.1.103]) by shell0.pdx.osdl.net (8.13.1/8.11.6) with ESMTP id j2ANiEIx023245; Thu, 10 Mar 2005 15:44:14 -0800 Date: Thu, 10 Mar 2005 15:44:32 -0800 From: Stephen Hemminger To: "David S. Miller" Cc: netdev@oss.sgi.com, bridge@lists.osdl.org Subject: [PATCH] (2/4) bridge: get rid of unneeded include Message-ID: <20050310154432.1163ad2d@dxpl.pdx.osdl.net> Organization: Open Source Development Lab X-Mailer: Sylpheed-Claws 1.0.1 (GTK+ 1.2.10; x86_64-unknown-linux-gnu) X-Face: &@E+xe?c%:&e4D{>f1O<&U>2qwRREG5!}7R4;D<"NO^UI2mJ[eEOA2*3>(`Th.yP,VDPo9$ /`~cw![cmj~~jWe?AHY7D1S+\}5brN0k*NE?pPh_'_d>6;XGG[\KDRViCfumZT3@[ Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Received-SPF: pass (domain of shemminger@osdl.org designates 65.172.181.6 as permitted sender) X-MIMEDefang-Filter: osdl$Revision: 1.104 $ X-Scanned-By: MIMEDefang 2.36 X-Virus-Scanned: ClamAV 0.83/760/Wed Mar 9 09:12:01 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 2867 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: shemminger@osdl.org Precedence: bulk X-list: netdev Content-Length: 448 Lines: 16 Get rid of unneeded include. Signed-off-by: Stephen Hemminger diff -Nru a/net/bridge/br.c b/net/bridge/br.c --- a/net/bridge/br.c 2005-03-10 15:06:38 -08:00 +++ b/net/bridge/br.c 2005-03-10 15:06:38 -08:00 @@ -16,7 +16,6 @@ #include #include #include -#include #include #include #include From shemminger@osdl.org Thu Mar 10 15:44:24 2005 Received: with ECARTIS (v1.0.0; list netdev); Thu, 10 Mar 2005 15:44:30 -0800 (PST) Received: from smtp.osdl.org (fire.osdl.org [65.172.181.4]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j2ANiO1f030642 for ; Thu, 10 Mar 2005 15:44:24 -0800 Received: from shell0.pdx.osdl.net (fw.osdl.org [65.172.181.6]) by smtp.osdl.org (8.12.8/8.12.8) with ESMTP id j2ANiHqi001465 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO); Thu, 10 Mar 2005 15:44:17 -0800 Received: from dxpl.pdx.osdl.net (dxpl.pdx.osdl.net [172.20.1.103]) by shell0.pdx.osdl.net (8.13.1/8.11.6) with ESMTP id j2ANiHWv023248; Thu, 10 Mar 2005 15:44:17 -0800 Date: Thu, 10 Mar 2005 15:44:34 -0800 From: Stephen Hemminger To: "David S. Miller" Cc: netdev@oss.sgi.com, bridge@osdl.org Subject: [PATCH] (3/4) bridge: get rid of threaded link for forwarding timeout Message-ID: <20050310154434.52f8f561@dxpl.pdx.osdl.net> Organization: Open Source Development Lab X-Mailer: Sylpheed-Claws 1.0.1 (GTK+ 1.2.10; x86_64-unknown-linux-gnu) X-Face: &@E+xe?c%:&e4D{>f1O<&U>2qwRREG5!}7R4;D<"NO^UI2mJ[eEOA2*3>(`Th.yP,VDPo9$ /`~cw![cmj~~jWe?AHY7D1S+\}5brN0k*NE?pPh_'_d>6;XGG[\KDRViCfumZT3@[ Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Received-SPF: pass (domain of shemminger@osdl.org designates 65.172.181.6 as permitted sender) X-MIMEDefang-Filter: osdl$Revision: 1.104 $ X-Scanned-By: MIMEDefang 2.36 X-Virus-Scanned: ClamAV 0.83/760/Wed Mar 9 09:12:01 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 2868 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: shemminger@osdl.org Precedence: bulk X-list: netdev Content-Length: 4133 Lines: 149 For 2.6, I changed the bridge forwarding table timeout code to keep a threaded list of in order entries. Well, it turns out that this is a performance hit because we end up constantly moving entries around in the list. Later patch changes this to be in place update with RCU. This version just uses a 100ms garbage collection timer. Signed-off-by: Stephen Hemminger --- a/net/bridge/br_fdb.c 2005-03-10 15:06:38 -08:00 +++ b/net/bridge/br_fdb.c 2005-03-10 15:06:38 -08:00 @@ -64,9 +64,6 @@ static __inline__ void fdb_delete(struct net_bridge_fdb_entry *f) { hlist_del_rcu(&f->hlist); - if (!f->is_static) - list_del(&f->u.age_list); - br_fdb_put(f); } @@ -113,30 +110,23 @@ void br_fdb_cleanup(unsigned long _data) { struct net_bridge *br = (struct net_bridge *)_data; - struct list_head *l, *n; - unsigned long delay; + unsigned long delay = hold_time(br); + int i; spin_lock_bh(&br->hash_lock); - delay = hold_time(br); - - list_for_each_safe(l, n, &br->age_list) { + for (i = 0; i < BR_HASH_SIZE; i++) { struct net_bridge_fdb_entry *f; - unsigned long expires; + struct hlist_node *h, *n; - f = list_entry(l, struct net_bridge_fdb_entry, u.age_list); - expires = f->ageing_timer + delay; - - if (time_before_eq(expires, jiffies)) { - WARN_ON(f->is_static); - pr_debug("expire age %lu jiffies %lu\n", - f->ageing_timer, jiffies); - fdb_delete(f); - } else { - mod_timer(&br->gc_timer, expires); - break; + hlist_for_each_entry_safe(f, h, n, &br->hash[i], hlist) { + if (!f->is_static && + time_before_eq(f->ageing_timer + delay, jiffies)) + fdb_delete(f); } } spin_unlock_bh(&br->hash_lock); + + mod_timer(&br->gc_timer, jiffies + HZ/10); } void br_fdb_delete_by_port(struct net_bridge *br, struct net_bridge_port *p) @@ -212,7 +202,7 @@ static void fdb_rcu_free(struct rcu_head *head) { struct net_bridge_fdb_entry *ent - = container_of(head, struct net_bridge_fdb_entry, u.rcu); + = container_of(head, struct net_bridge_fdb_entry, rcu); kmem_cache_free(br_fdb_cache, ent); } @@ -220,7 +210,7 @@ void br_fdb_put(struct net_bridge_fdb_entry *ent) { if (atomic_dec_and_test(&ent->use_count)) - call_rcu(&ent->u.rcu, fdb_rcu_free); + call_rcu(&ent->rcu, fdb_rcu_free); } /* @@ -305,8 +295,6 @@ if (fdb->is_static) return 0; - /* move to end of age list */ - list_del(&fdb->u.age_list); goto update; } } @@ -329,8 +317,6 @@ fdb->is_local = is_local; fdb->is_static = is_local; fdb->ageing_timer = jiffies; - if (!is_local) - list_add_tail(&fdb->u.age_list, &br->age_list); return 0; } diff -Nru a/net/bridge/br_private.h b/net/bridge/br_private.h --- a/net/bridge/br_private.h 2005-03-10 15:06:38 -08:00 +++ b/net/bridge/br_private.h 2005-03-10 15:06:38 -08:00 @@ -46,10 +46,8 @@ { struct hlist_node hlist; struct net_bridge_port *dst; - union { - struct list_head age_list; - struct rcu_head rcu; - } u; + + struct rcu_head rcu; atomic_t use_count; unsigned long ageing_timer; mac_addr addr; diff -Nru a/net/bridge/br_stp_if.c b/net/bridge/br_stp_if.c --- a/net/bridge/br_stp_if.c 2005-03-10 15:06:38 -08:00 +++ b/net/bridge/br_stp_if.c 2005-03-10 15:06:38 -08:00 @@ -49,6 +49,8 @@ spin_lock_bh(&br->lock); mod_timer(&br->hello_timer, jiffies + br->hello_time); + mod_timer(&br->gc_timer, jiffies + HZ/10); + br_config_bpdu_generation(br); list_for_each_entry(p, &br->port_list, list) { @@ -78,6 +80,7 @@ del_timer_sync(&br->hello_timer); del_timer_sync(&br->topology_change_timer); del_timer_sync(&br->tcn_timer); + del_timer_sync(&br->gc_timer); } /* called under bridge lock */ diff -Nru a/net/bridge/br_fdb.c b/net/bridge/br_fdb.c --- a/net/bridge/br_fdb.c 2005-03-10 15:07:12 -08:00 +++ b/net/bridge/br_fdb.c 2005-03-10 15:07:12 -08:00 @@ -307,11 +307,6 @@ atomic_set(&fdb->use_count, 1); hlist_add_head_rcu(&fdb->hlist, &br->hash[hash]); - if (!timer_pending(&br->gc_timer)) { - br->gc_timer.expires = jiffies + hold_time(br); - add_timer(&br->gc_timer); - } - update: fdb->dst = source; fdb->is_local = is_local; From shemminger@osdl.org Thu Mar 10 15:44:27 2005 Received: with ECARTIS (v1.0.0; list netdev); Thu, 10 Mar 2005 15:44:33 -0800 (PST) Received: from smtp.osdl.org (fire.osdl.org [65.172.181.4]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j2ANiRGe030656 for ; Thu, 10 Mar 2005 15:44:27 -0800 Received: from shell0.pdx.osdl.net (fw.osdl.org [65.172.181.6]) by smtp.osdl.org (8.12.8/8.12.8) with ESMTP id j2ANiJqi001469 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO); Thu, 10 Mar 2005 15:44:20 -0800 Received: from dxpl.pdx.osdl.net (dxpl.pdx.osdl.net [172.20.1.103]) by shell0.pdx.osdl.net (8.13.1/8.11.6) with ESMTP id j2ANiJDL023252; Thu, 10 Mar 2005 15:44:19 -0800 Date: Thu, 10 Mar 2005 15:44:37 -0800 From: Stephen Hemminger To: "David S. Miller" Cc: netdev@oss.sgi.com, bridge@lists.osdl.org Subject: [PATCH] (4/4) bridge: forwarding table lockless update Message-ID: <20050310154437.1223b6e9@dxpl.pdx.osdl.net> Organization: Open Source Development Lab X-Mailer: Sylpheed-Claws 1.0.1 (GTK+ 1.2.10; x86_64-unknown-linux-gnu) X-Face: &@E+xe?c%:&e4D{>f1O<&U>2qwRREG5!}7R4;D<"NO^UI2mJ[eEOA2*3>(`Th.yP,VDPo9$ /`~cw![cmj~~jWe?AHY7D1S+\}5brN0k*NE?pPh_'_d>6;XGG[\KDRViCfumZT3@[ Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Received-SPF: pass (domain of shemminger@osdl.org designates 65.172.181.6 as permitted sender) X-MIMEDefang-Filter: osdl$Revision: 1.104 $ X-Scanned-By: MIMEDefang 2.36 X-Virus-Scanned: ClamAV 0.83/760/Wed Mar 9 09:12:01 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 2869 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: shemminger@osdl.org Precedence: bulk X-list: netdev Content-Length: 6737 Lines: 230 Optimize bridge forwarding table for the fastpath of updating an existing entry. Use RCU to find the entry and change it's time. Fallback to normal locking for insert. This gives about a 1/3 improvement in packets forwarding per second on SMP. Signed-off-by: Stephen Hemminger diff -Nru a/net/bridge/br_fdb.c b/net/bridge/br_fdb.c --- a/net/bridge/br_fdb.c 2005-03-10 15:25:50 -08:00 +++ b/net/bridge/br_fdb.c 2005-03-10 15:25:50 -08:00 @@ -25,7 +25,7 @@ static kmem_cache_t *br_fdb_cache; static int fdb_insert(struct net_bridge *br, struct net_bridge_port *source, - const unsigned char *addr, int is_local); + const unsigned char *addr); void __init br_fdb_init(void) { @@ -101,8 +101,7 @@ } insert: /* insert new address, may fail if invalid address or dup. */ - fdb_insert(br, p, newaddr, 1); - + fdb_insert(br, p, newaddr); spin_unlock_bh(&br->hash_lock); } @@ -258,71 +257,108 @@ return num; } -static int fdb_insert(struct net_bridge *br, struct net_bridge_port *source, - const unsigned char *addr, int is_local) +static inline struct net_bridge_fdb_entry *fdb_find(struct hlist_head *head, + const unsigned char *addr) { struct hlist_node *h; struct net_bridge_fdb_entry *fdb; - int hash = br_mac_hash(addr); - if (!is_valid_ether_addr(addr)) - return -EADDRNOTAVAIL; + hlist_for_each_entry_rcu(fdb, h, head, hlist) { + if (!memcmp(fdb->addr.addr, addr, ETH_ALEN)) + return fdb; + } + return NULL; +} - hlist_for_each_entry(fdb, h, &br->hash[hash], hlist) { - if (!memcmp(fdb->addr.addr, addr, ETH_ALEN)) { - /* attempt to update an entry for a local interface */ - if (fdb->is_local) { - /* it is okay to have multiple ports with same - * address, just don't allow to be spoofed. - */ - if (is_local) - return 0; - - if (net_ratelimit()) - printk(KERN_WARNING "%s: received packet with " - " own address as source address\n", - source->dev->name); - return -EEXIST; - } +static struct net_bridge_fdb_entry *fdb_create(struct hlist_head *head, + struct net_bridge_port *source, + const unsigned char *addr, + int is_local) +{ + struct net_bridge_fdb_entry *fdb; - if (is_local) { - printk(KERN_WARNING "%s adding interface with same address " - "as a received packet\n", - source->dev->name); - goto update; - } + fdb = kmem_cache_alloc(br_fdb_cache, GFP_ATOMIC); + if (fdb) { + memcpy(fdb->addr.addr, addr, ETH_ALEN); + atomic_set(&fdb->use_count, 1); + hlist_add_head_rcu(&fdb->hlist, head); + + fdb->dst = source; + fdb->is_local = is_local; + fdb->is_static = is_local; + fdb->ageing_timer = jiffies; + } + return fdb; +} - if (fdb->is_static) - return 0; +static int fdb_insert(struct net_bridge *br, struct net_bridge_port *source, + const unsigned char *addr) +{ + struct hlist_head *head = &br->hash[br_mac_hash(addr)]; + struct net_bridge_fdb_entry *fdb; - goto update; - } - } + if (!is_valid_ether_addr(addr)) + return -EINVAL; - fdb = kmem_cache_alloc(br_fdb_cache, GFP_ATOMIC); - if (!fdb) - return ENOMEM; + fdb = fdb_find(head, addr); + if (fdb) { + /* it is okay to have multiple ports with same + * address, just use the first one. + */ + if (fdb->is_local) + return 0; + + printk(KERN_WARNING "%s adding interface with same address " + "as a received packet\n", + source->dev->name); + fdb_delete(fdb); + } - memcpy(fdb->addr.addr, addr, ETH_ALEN); - atomic_set(&fdb->use_count, 1); - hlist_add_head_rcu(&fdb->hlist, &br->hash[hash]); - - update: - fdb->dst = source; - fdb->is_local = is_local; - fdb->is_static = is_local; - fdb->ageing_timer = jiffies; + if (!fdb_create(head, source, addr, 1)) + return -ENOMEM; return 0; } int br_fdb_insert(struct net_bridge *br, struct net_bridge_port *source, - const unsigned char *addr, int is_local) + const unsigned char *addr) { int ret; spin_lock_bh(&br->hash_lock); - ret = fdb_insert(br, source, addr, is_local); + ret = fdb_insert(br, source, addr); spin_unlock_bh(&br->hash_lock); return ret; +} + +void br_fdb_update(struct net_bridge *br, struct net_bridge_port *source, + const unsigned char *addr) +{ + struct hlist_head *head = &br->hash[br_mac_hash(addr)]; + struct net_bridge_fdb_entry *fdb; + + rcu_read_lock(); + fdb = fdb_find(head, addr); + if (likely(fdb)) { + /* attempt to update an entry for a local interface */ + if (unlikely(fdb->is_local)) { + if (net_ratelimit()) + printk(KERN_WARNING "%s: received packet with " + " own address as source address\n", + source->dev->name); + } else { + /* fastpath: update of existing entry */ + fdb->dst = source; + fdb->ageing_timer = jiffies; + } + } else { + spin_lock_bh(&br->hash_lock); + if (!fdb_find(head, addr)) + fdb_create(head, source, addr, 0); + /* else we lose race and someone else inserts + * it first, don't bother updating + */ + spin_unlock_bh(&br->hash_lock); + } + rcu_read_unlock(); } diff -Nru a/net/bridge/br_if.c b/net/bridge/br_if.c --- a/net/bridge/br_if.c 2005-03-10 15:25:50 -08:00 +++ b/net/bridge/br_if.c 2005-03-10 15:25:50 -08:00 @@ -332,7 +332,7 @@ if (IS_ERR(p = new_nbp(br, dev, br_initial_port_cost(dev)))) return PTR_ERR(p); - if ((err = br_fdb_insert(br, p, dev->dev_addr, 1))) + if ((err = br_fdb_insert(br, p, dev->dev_addr))) destroy_nbp(p); else if ((err = br_sysfs_addif(p))) diff -Nru a/net/bridge/br_input.c b/net/bridge/br_input.c --- a/net/bridge/br_input.c 2005-03-10 15:25:50 -08:00 +++ b/net/bridge/br_input.c 2005-03-10 15:25:50 -08:00 @@ -105,12 +105,12 @@ if (p->state == BR_STATE_DISABLED) goto err; - if (eth_hdr(skb)->h_source[0] & 1) + if (!is_valid_ether_addr(eth_hdr(skb)->h_source)) goto err; if (p->state == BR_STATE_LEARNING || p->state == BR_STATE_FORWARDING) - br_fdb_insert(p->br, p, eth_hdr(skb)->h_source, 0); + br_fdb_update(p->br, p, eth_hdr(skb)->h_source); if (p->br->stp_enabled && !memcmp(dest, bridge_ula, 5) && diff -Nru a/net/bridge/br_private.h b/net/bridge/br_private.h --- a/net/bridge/br_private.h 2005-03-10 15:25:50 -08:00 +++ b/net/bridge/br_private.h 2005-03-10 15:25:50 -08:00 @@ -146,8 +146,10 @@ unsigned long count, unsigned long off); extern int br_fdb_insert(struct net_bridge *br, struct net_bridge_port *source, - const unsigned char *addr, - int is_local); + const unsigned char *addr); +extern void br_fdb_update(struct net_bridge *br, + struct net_bridge_port *source, + const unsigned char *addr); /* br_forward.c */ extern void br_deliver(const struct net_bridge_port *to, From davem@davemloft.net Thu Mar 10 15:49:06 2005 Received: with ECARTIS (v1.0.0; list netdev); Thu, 10 Mar 2005 15:49:12 -0800 (PST) Received: from cheetah.davemloft.net (mail@dsl027-180-174.sfo1.dsl.speakeasy.net [216.27.180.174]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j2ANn6VL000774 for ; Thu, 10 Mar 2005 15:49:06 -0800 Received: from localhost ([127.0.0.1] helo=cheetah.davemloft.net ident=davem) by cheetah.davemloft.net with smtp (Exim 3.36 #1 (Debian)) id 1D9XN6-0001mx-00; Thu, 10 Mar 2005 15:47:16 -0800 Date: Thu, 10 Mar 2005 15:47:16 -0800 From: "David S. Miller" To: Christoph Hellwig Cc: greg@kroah.com, kuznet@ms2.inr.ac.ru, pekkas@netcore.fi, jmorris@redhat.com, yoshfuji@linux-ipv6.org, kaber@coreworks.de, netdev@oss.sgi.com, linux-kernel@vger.kernel.org, stable@kernel.org Subject: Re: [06/11] [TCP]: Put back tcp_timer_bug_msg[] symbol export. Message-Id: <20050310154716.5694bf69.davem@davemloft.net> In-Reply-To: <20050310232014.GA32228@infradead.org> References: <20050310230519.GA22112@kroah.com> <20050310230843.GG22112@kroah.com> <20050310232014.GA32228@infradead.org> X-Mailer: Sylpheed version 1.0.1 (GTK+ 1.2.10; sparc-unknown-linux-gnu) X-Face: "_;p5u5aPsO,_Vsx"^v-pEq09'CU4&Dc1$fQExov$62l60cgCc%FnIwD=.UF^a>?5'9Kn[;433QFVV9M..2eN.@4ZWPGbdi<=?[:T>y?SD(R*-3It"Vj:)"dP Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV 0.83/760/Wed Mar 9 09:12:01 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 2871 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: davem@davemloft.net Precedence: bulk X-list: netdev Content-Length: 563 Lines: 16 On Thu, 10 Mar 2005 23:20:14 +0000 Christoph Hellwig wrote: > > --- a/net/ipv4/tcp_timer.c 2005-03-09 17:20:38 -08:00 > > +++ b/net/ipv4/tcp_timer.c 2005-03-09 17:20:38 -08:00 > > @@ -38,6 +38,7 @@ > > > > #ifdef TCP_DEBUG > > const char tcp_timer_bug_msg[] = KERN_DEBUG "tcpbug: unknown timer value\n"; > > +EXPORT_SYMBOL(tcp_timer_bug_msg); > > #endif > > not complaining about putting this into -stable, but why do people have > TCP_DEBUG turned on for normal builds? It is on in everyone's build unless they edit include/net/tcp.h From davem@davemloft.net Thu Mar 10 16:20:59 2005 Received: with ECARTIS (v1.0.0; list netdev); Thu, 10 Mar 2005 16:21:02 -0800 (PST) Received: from cheetah.davemloft.net (mail@dsl027-180-174.sfo1.dsl.speakeasy.net [216.27.180.174]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j2B0Kw6T005449 for ; Thu, 10 Mar 2005 16:20:58 -0800 Received: from localhost ([127.0.0.1] helo=cheetah.davemloft.net ident=davem) by cheetah.davemloft.net with smtp (Exim 3.36 #1 (Debian)) id 1D9XsY-000200-00; Thu, 10 Mar 2005 16:19:46 -0800 Date: Thu, 10 Mar 2005 16:19:46 -0800 From: "David S. Miller" To: Patrick McHardy Cc: netdev@oss.sgi.com Subject: Re: [PATCH 2/3 XFRM]: Always reroute in tunnel mode Message-Id: <20050310161946.68d9dd25.davem@davemloft.net> In-Reply-To: <4229BB27.30009@trash.net> References: <4229BB27.30009@trash.net> X-Mailer: Sylpheed version 1.0.1 (GTK+ 1.2.10; sparc-unknown-linux-gnu) X-Face: "_;p5u5aPsO,_Vsx"^v-pEq09'CU4&Dc1$fQExov$62l60cgCc%FnIwD=.UF^a>?5'9Kn[;433QFVV9M..2eN.@4ZWPGbdi<=?[:T>y?SD(R*-3It"Vj:)"dP Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV 0.83/760/Wed Mar 9 09:12:01 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 2872 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: davem@davemloft.net Precedence: bulk X-list: netdev Content-Length: 85 Lines: 3 Applied, but I had to modify it a bit to work on top of Herbert's xfrm_dst changes. From herbert@gondor.apana.org.au Thu Mar 10 17:19:31 2005 Received: with ECARTIS (v1.0.0; list netdev); Thu, 10 Mar 2005 17:19:38 -0800 (PST) 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 j2B1JTRs007462 for ; Thu, 10 Mar 2005 17:19:30 -0800 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 1D9YoE-0006Vy-00 for ; Fri, 11 Mar 2005 12:19:22 +1100 Received: from herbert by gondolin.me.apana.org.au with local (Exim 3.36 #1 (Debian)) id 1D9Ymg-0001x0-00; Fri, 11 Mar 2005 12:17:46 +1100 From: Herbert Xu To: steve@services.navaho.net (Steve Hill) Subject: Re: More IPSEC trouble Cc: netdev@oss.sgi.com Organization: Core In-Reply-To: X-Newsgroups: apana.lists.os.linux.netdev User-Agent: tin/1.7.4-20040225 ("Benbecula") (UNIX) (Linux/2.4.27-hx-1-686-smp (i686)) Message-Id: Date: Fri, 11 Mar 2005 12:17:46 +1100 X-Virus-Scanned: ClamAV 0.83/760/Wed Mar 9 09:12:01 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 2873 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: herbert@gondor.apana.org.au Precedence: bulk X-list: netdev Content-Length: 698 Lines: 15 Steve Hill wrote: > > Running IPSEC in IPv4 tunnel mode - obviously the packets grow in size > when encrypted and when I send a packet that grows to > MTU size when > encrypted the machine locks up solid (the packet is generated by a > different machine that is routing it via the Linux IPSEC router whcih is > having problems). When it locks up I get no errors from the kernel - it > just freezes up solid. What does CTRL-SCROLLLOCK or SysRq tell us? -- 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 nobody@misty.ori-g.net Thu Mar 10 17:45:39 2005 Received: with ECARTIS (v1.0.0; list netdev); Thu, 10 Mar 2005 17:45:47 -0800 (PST) Received: from misty.ori-g.net ([222.122.15.89]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j2B1jbnY008629 for ; Thu, 10 Mar 2005 17:45:38 -0800 Received: by misty.ori-g.net (Postfix, from userid 99) id 5ECB05212B; Fri, 11 Mar 2005 10:48:24 +0900 (KST) To: netdev@oss.sgi.com Subject: =?ISO-2022-JP?B?GyRCJSslYSVpO0UzXSQxJEEkYyRDJD8hJiEmISYheRsoQg==?= To: netdev@oss.sgi.com From: =?ISO-2022-JP?B?GyRCJGIkQyRIR0EkJCRGISobKEI=?= Message-Id: <20050311014824.5ECB05212B@misty.ori-g.net> Date: Fri, 11 Mar 2005 10:48:24 +0900 (KST) X-Virus-Scanned: ClamAV 0.83/760/Wed Mar 9 09:12:01 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 2874 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: chan@mag.vig-seet.to Precedence: bulk X-list: netdev Content-Length: 3094 Lines: 71 ™KEBBEK™™KEBˆÅƒ‹[ƒg“ÁWƒƒ‹ƒ}ƒKBEK™™KEBBEK™ @@@@@@@@@@@@@@@ Eddc„ª„ª„ª„ª„ª„ª„ª„ª„ª„ª„ª„ª„ª„ª„ª„ª„ª„ª„ª„ª„ª„ª„ª„ª„ª„ª„ª„ª @@@œœœw‹†‹É‚̈êlƒGƒbƒ`‚ð‚·‚é‚É‚ÍEEEx @@@@@@@@º‚ª•·‚±‚¦‚éI’†‚ªŒ©‚¦‚éIœœœ @ ƒXƒg[ƒJ[‚ª•”‰®‚Ì’†‚ɃJƒƒ‰‚ðŽdŠ|‚¯‚½II @ @@@Š®‘S“®‰æ‚Å›››››–º‚Ì—‚ꂽŽ„¶Šˆ›Œ©‚¦ô @@ @@@@@ http://hanamitu.polty.cc/?g374tojofp Eddc„ª„ª„ª„ª„ª„ª„ª„ª„ª„ª„ª„ª„ª„ª„ª„ª„ª„ª„ª„ª„ª„ª„ª„ª„ª„ª„ª„ª @ ’j‚ÌŽq‚ׂ̈̃`ƒJƒ““ÁWI @@@—‚ÌŽq‚ׂ̈̃Iƒiƒj[“ÁWI @@   ¡  ™  ¡  ™  ¡  ™  ¡  ™  ¡  ™  ¡  ¡ ¡   ¡ ¡   ¡ ¡   ¡ ¡   ¡ ¡   ¡  @@@ „¡„Ÿ„Ÿ„Ÿ„Ÿ„Ÿ„Ÿ„Ÿ„Ÿ„Ÿ„Ÿ„Ÿ„Ÿ„Ÿ„Ÿ„Ÿ„Ÿ„Ÿ„Ÿ„Ÿ„Ÿ„Ÿ„Ÿ„¢ @@@ šššš@@@@@@‚PDƒŒƒYƒrƒAƒ“‚ÌŠé‰æ@@@@@@@šššš @@@ „¤„Ÿ„Ÿ„Ÿ„Ÿ„Ÿ„Ÿ„Ÿ„Ÿ„Ÿ„Ÿ„Ÿ„Ÿ„Ÿ„Ÿ„Ÿ„Ÿ„Ÿ„Ÿ„Ÿ„Ÿ„Ÿ„Ÿ„£ @@@ œœœœœœœ‚³‚炯o‚³‚ꂽ“÷—~œœœœœœœ @ @Ž‹‚ç‚ê‚邱‚Æ‚ª‰õŠ´‚Ì—‚ÌŽq‚½‚¿‚ª‚¢‚ë‚ñ‚Èꊂőåƒnƒvƒjƒ“ƒOô @@ ʼn‚Í’p‚¸‚©‚µ‚ª‚Á‚Ä‚¢‚½”Þ—‚½‚¿‚àŽŸ‘æ‚ɃR[ƒtƒ“‚µ‚Ä‚«‚Ä @@ ‚Ç‚ñ‚Ç‚ñˆú‚ç‚Éc @@@@œœœœœœœƒtƒFƒ`‚È–Ï‘z‚©‚È‚¦‚Ü‚·œœœœœœœ @ Žñ‹ØA”w’†Aƒ€ƒlA‚¨Kc‚ ‚È‚½‚Í‚Ç‚ñ‚ȃp[ƒc‚ªD‚«H @@@ —‚ÌŽq‚Ì‚¢‚ë‚ñ‚È•”•ª‚É‚±‚¾‚í‚Á‚½‰æ‘œ‚ª·‚肾‚­‚³‚ñô @@@ ¡‰ñ‚wƒ}ƒXŠé‰æ‚Æ‚µ‚ÄA—‚ÌŽq‚ªg‘̂𒣂Á‚Ä‚Ìo’£ƒŒƒ|ô @@@ “ú ‚Ì—­‚Ü‚Á‚½–Ï‘z‚ðŽv‚¤‘¶•ª“f‚«o‚µ‚¿‚á‚Á‚Ä‚­‚¾‚³‚¢™ @ http://hanamitu.polty.cc/?g374tojofp ------------------------------------------------------------------- @@@„¡„Ÿ„Ÿ„Ÿ„Ÿ„Ÿ„Ÿ„Ÿ„Ÿ„Ÿ„Ÿ„Ÿ„Ÿ„Ÿ„Ÿ„Ÿ„Ÿ„Ÿ„Ÿ„Ÿ„Ÿ„Ÿ„Ÿ„Ÿ„Ÿ„Ÿ„Ÿ„¢ @@@šššš@@@@@‚QD‚Ü‚·‚Ü‚·[ŽÀI‘ål‹CƒR[ƒi[ @@@@šššš @@@„¤„Ÿ„Ÿ„Ÿ„Ÿ„Ÿ„Ÿ„Ÿ„Ÿ„Ÿ„Ÿ„Ÿ„Ÿ„Ÿ„Ÿ„Ÿ„Ÿ„Ÿ„Ÿ„Ÿ„Ÿ„Ÿ„Ÿ„Ÿ„Ÿ„Ÿ„Ÿ„£ @@¡—Žq›¶‚̃iƒ}Žp @@@@c‰Âˆ¤‚¢—Žq›¶‚½‚¿‚ª‘å’_‚ɧ•ž‚̉º‚Ì‚ ‚è‚Ì‚Ü‚Ü‚ÌŽp‚ð‚³‚ç‚¯‚¾‚µ‚Ü‚· @@@@@ @@ ¡M‚ÈŠè–] @@@@cƒhƒƒhƒ‚ɉ˜‚ê‚é‚Ü‚Å•òŽd‚³‚¹‚ç‚ê‚é—‚½‚¿‚̈ꕔŽnI‚ðŒµ‘IŒöŠJII @@ ¡ƒRƒXƒ`ƒ…[ƒ€‚Ì— ‚Ì—  @@@@cƒi[ƒX‚âƒXƒbƒ`[A˜a•ž‚Ƀ`ƒƒƒCƒiƒhƒŒƒX‚È‚ÇA“²‚ê‚̃RƒXƒvƒŒ–Ú”’‰Ÿ‚µ™ http://hanamitu.polty.cc/?g374tojofp @@@@@                                   ------------------------------------------------------------------- @@@ššššššššƒƒƒ‹ƒT‚¿‚á‚ñ‚æ‚è„šššššššš ------------------------------------------------------------------- @@ ¡‚±‚̃}ƒKƒWƒ“ƒ[ƒ‹‚ÌŒfÚî•ñ‚Ì—˜—p‚ÉŠÖ‚µ‚Ä‚ÍA @@@@Šel‚ªŽ©•ª‚ÌÓ”C‚Ås‚È‚Á‚Ä‚¢‚½‚¾‚­‚±‚ð‘O’ñ‚Æ‚µ‚Ä‚¢‚Ü‚·B @@@@ŒfÚî•ñ‚ÉŠÖ‚µ‚Ä‚Ì‚¨–⇂¹‚⑹ŠQ‚ɑ΂µ‚Ä‚Í‚¢‚©‚È‚éÓ”C‚à @@@@•‰‚¢‚©‚Ë‚Ü‚·‚Ì‚ÅA—\‚ß‚²—¹³‰º‚³‚¢B @@@@ŒfÚ‚³‚ꂽ‹LŽ–‚̈ꕔ‚Ü‚½‚Í‘S•”‚ð‹–‰Â‚È‚­“]Ú‚·‚邱‚Æ‚ð‹ÖŽ~’v‚µ‚Ü‚·B ------------------------------------------------------------------- @||||||||||||||||||||||||||||||||| @@ ¦w“ljðœ•û–@ @@@@w“ljðœ‚Í‚¨Žè”‚Å‚·‚ªA‰º‹L‚̃AƒhƒŒƒX‚æ‚胃OƒCƒ“‚µA‚²Ž©g‚Å‚¨Žè‘±‚«‰º‚³‚¢B http://mag.vig-seet.to/melsa/ @|||||||||||||||||||||||||||||||||@@@ From akpm@osdl.org Thu Mar 10 17:49:54 2005 Received: with ECARTIS (v1.0.0; list netdev); Thu, 10 Mar 2005 17:50:02 -0800 (PST) Received: from smtp.osdl.org (fire.osdl.org [65.172.181.4]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j2B1nr3a009257 for ; Thu, 10 Mar 2005 17:49:54 -0800 Received: from shell0.pdx.osdl.net (fw.osdl.org [65.172.181.6]) by smtp.osdl.org (8.12.8/8.12.8) with ESMTP id j2B1nhqi013349 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO); Thu, 10 Mar 2005 17:49:46 -0800 Received: from bix (shell0.pdx.osdl.net [10.9.0.31]) by shell0.pdx.osdl.net (8.13.1/8.11.6) with SMTP id j2B1ngea029332; Thu, 10 Mar 2005 17:49:42 -0800 Date: Thu, 10 Mar 2005 17:49:15 -0800 From: Andrew Morton To: netdev@oss.sgi.com Cc: Kimmo Sundqvist Subject: Fw: Log full of "ing_filter: fixed ippp2 out ippp2" Message-Id: <20050310174915.3148c9a8.akpm@osdl.org> X-Mailer: Sylpheed version 0.9.7 (GTK+ 1.2.10; i386-redhat-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Received-SPF: pass (domain of akpm@osdl.org designates 65.172.181.6 as permitted sender) X-MIMEDefang-Filter: osdl$Revision: 1.104 $ X-Scanned-By: MIMEDefang 2.36 X-Virus-Scanned: ClamAV 0.83/760/Wed Mar 9 09:12:01 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 2875 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: akpm@osdl.org Precedence: bulk X-list: netdev Content-Length: 3661 Lines: 107 Can you check to see if 2.6.11 is still doing this? Begin forwarded message: Date: Wed, 9 Mar 2005 22:07:41 +0200 From: Kimmo Sundqvist To: linux-kernel@vger.kernel.org Subject: Log full of "ing_filter: fixed ippp2 out ippp2" Hello Please cc all replies to me. After upgrading my little NATting firewall/router from 2.6.7-ck4 to 2.6.10-gentoo-r6 my /var/log/messages is 15MB in size and most of it looks like the text below. All traffic to the Internet seems to cause this. "cat /var/log/messages | uniq | uniqmessages" results in a 3MB file. I use syslog-ng. Iptables setup script further down. Mar 9 21:58:15 shadowgate ing_filter: fixed ippp2 out ippp2 Mar 9 21:58:15 shadowgate ing_filter: fixed ippp2 out ippp2 Mar 9 21:58:15 shadowgate ing_filter: fixed ippp2 out ippp2 Mar 9 21:58:15 shadowgate ing_filter: fixed ippp2 out ippp2 Mar 9 21:58:15 shadowgate ing_filter: fixed ippp2 out ippp2 Mar 9 21:58:16 shadowgate ing_filter: fixed ippp2 out ippp2 Mar 9 21:58:16 shadowgate ing_filter: fixed ippp2 out ippp2 Mar 9 21:58:16 shadowgate ing_filter: fixed ippp2 out ippp2 Mar 9 21:58:16 shadowgate ing_filter: fixed ippp2 out ippp2 Mar 9 21:58:16 shadowgate ing_filter: fixed ippp2 out ippp2 Mar 9 21:58:16 shadowgate ing_filter: fixed ippp2 out ippp2 Mar 9 21:58:16 shadowgate ing_filter: fixed ippp2 out ippp2 Mar 9 21:58:17 shadowgate ing_filter: fixed ippp2 out ippp2 Mar 9 21:58:17 shadowgate ing_filter: fixed ippp2 out ippp2 Mar 9 21:58:17 shadowgate ing_filter: fixed ippp2 out ippp2 Mar 9 21:58:17 shadowgate ing_filter: fixed ippp2 out ippp2 Mar 9 21:58:17 shadowgate ing_filter: fixed ippp2 out ippp2 Mar 9 21:58:17 shadowgate ing_filter: fixed ippp2 out ippp2 Mar 9 21:58:17 shadowgate ing_filter: fixed ippp2 out ippp2 Mar 9 21:58:17 shadowgate ing_filter: fixed ippp2 out ippp2 Mar 9 21:58:17 shadowgate ing_filter: fixed ippp2 out ippp2 Mar 9 21:58:17 shadowgate ing_filter: fixed ippp2 out ippp2 Mar 9 21:58:17 shadowgate ing_filter: fixed ippp2 out ippp2 Mar 9 21:58:17 shadowgate ing_filter: fixed ippp2 out ippp2 Mar 9 21:58:17 shadowgate ing_filter: fixed ippp2 out ippp2 Mar 9 21:58:17 shadowgate ing_filter: fixed ippp2 out ippp2 My firewall setup looks like: IPTABLES=/sbin/iptables MODPROBE=/sbin/modprobe DEPMOD=/sbin/depmod EXTIF="ippp2" INTIF="eth0" KAKKOSIF="eth1" $DEPMOD -a $MODPROBE ip_tables #$MODPROBE ip_conntrack #In the kernel $MODPROBE ip_conntrack_ftp $MODPROBE iptable_nat $MODPROBE ip_nat_ftp echo "1" > /proc/sys/net/ipv4/ip_forward echo "1" > /proc/sys/net/ipv4/ip_dynaddr #echo "1" > /proc/sys/net/ipv4/conf/all/proxy_arp $IPTABLES -P INPUT ACCEPT $IPTABLES -F INPUT $IPTABLES -P OUTPUT ACCEPT $IPTABLES -F OUTPUT $IPTABLES -P FORWARD DROP $IPTABLES -F FORWARD $IPTABLES -t nat -F /sbin/iptables -A FORWARD -i eth1 -o eth0 -j ACCEPT /sbin/iptables -A FORWARD -i eth0 -o eth1 -j ACCEPT $IPTABLES -A FORWARD -i $EXTIF -o $KAKKOSIF -m state --state \ ESTABLISHED,RELATED -j ACCEPT # RJ-45 $IPTABLES -A FORWARD -i $EXTIF -o $INTIF -m state --state \ ESTABLISHED,RELATED -j ACCEPT # BNC segment $IPTABLES -A FORWARD -i $KAKKOSIF -o $EXTIF -j ACCEPT # RJ-45 $IPTABLES -A FORWARD -i $INTIF -o $EXTIF -j ACCEPT # BNC segment $IPTABLES -t nat -A POSTROUTING -o $EXTIF -j MASQUERADE $IPTABLES -A FORWARD -j LOG exit 0 -Kimmo S. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/ From davem@davemloft.net Thu Mar 10 18:20:54 2005 Received: with ECARTIS (v1.0.0; list netdev); Thu, 10 Mar 2005 18:20:58 -0800 (PST) Received: from cheetah.davemloft.net (mail@dsl027-180-174.sfo1.dsl.speakeasy.net [216.27.180.174]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j2B2Kpoq010882 for ; Thu, 10 Mar 2005 18:20:53 -0800 Received: from localhost ([127.0.0.1] helo=cheetah.davemloft.net ident=davem) by cheetah.davemloft.net with smtp (Exim 3.36 #1 (Debian)) id 1D9ZkZ-0002f1-00; Thu, 10 Mar 2005 18:19:39 -0800 Date: Thu, 10 Mar 2005 18:19:39 -0800 From: "David S. Miller" To: Jeff Garzik Cc: netdev@oss.sgi.com, shemminger@osdl.org Subject: Re: [PATCH] kill ->accept_fastpath hook Message-Id: <20050310181939.4283ff02.davem@davemloft.net> In-Reply-To: <422F44D8.3010009@pobox.com> References: <20050309092628.3c9014db@dxpl.pdx.osdl.net> <422F44D8.3010009@pobox.com> X-Mailer: Sylpheed version 1.0.1 (GTK+ 1.2.10; sparc-unknown-linux-gnu) X-Face: "_;p5u5aPsO,_Vsx"^v-pEq09'CU4&Dc1$fQExov$62l60cgCc%FnIwD=.UF^a>?5'9Kn[;433QFVV9M..2eN.@4ZWPGbdi<=?[:T>y?SD(R*-3It"Vj:)"dP Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV 0.83/760/Wed Mar 9 09:12:01 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 2877 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: davem@davemloft.net Precedence: bulk X-list: netdev Content-Length: 460 Lines: 14 On Wed, 09 Mar 2005 13:47:52 -0500 Jeff Garzik wrote: > Stephen Hemminger wrote: > > Trivial reordering of netdevice structure to save four bytes. > > > > Signed-off-by: Stephen Hemminger > > If we are twiddling struct net_device, might as well kill this hook. > Never called AFAICS, and only assigned -- to a no-op stub -- in one driver. > > Signed-off-by: Jeff Garzik Applied, thanks Jeff. From davem@davemloft.net Thu Mar 10 18:20:01 2005 Received: with ECARTIS (v1.0.0; list netdev); Thu, 10 Mar 2005 18:20:07 -0800 (PST) Received: from cheetah.davemloft.net (mail@dsl027-180-174.sfo1.dsl.speakeasy.net [216.27.180.174]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j2B2K11h010660 for ; Thu, 10 Mar 2005 18:20:01 -0800 Received: from localhost ([127.0.0.1] helo=cheetah.davemloft.net ident=davem) by cheetah.davemloft.net with smtp (Exim 3.36 #1 (Debian)) id 1D9Zio-0002dm-00; Thu, 10 Mar 2005 18:17:50 -0800 Date: Thu, 10 Mar 2005 18:17:50 -0800 From: "David S. Miller" To: Herbert Xu Cc: kuznet@ms2.inr.ac.ru, jmorris@redhat.com, yoshfuji@linux-ipv6.org, netdev@oss.sgi.com Subject: Re: [11/*] [NET] Move dst_release out of dst->ops->check Message-Id: <20050310181750.420c073d.davem@davemloft.net> In-Reply-To: <20050308102741.GA23468@gondor.apana.org.au> References: <20050214221006.GA18415@gondor.apana.org.au> <20050214221200.GA18465@gondor.apana.org.au> <20050214221433.GB18465@gondor.apana.org.au> <20050214221607.GC18465@gondor.apana.org.au> <20050306213214.7d8a143d.davem@davemloft.net> <20050307103536.GB7137@gondor.apana.org.au> <20050308102741.GA23468@gondor.apana.org.au> X-Mailer: Sylpheed version 1.0.1 (GTK+ 1.2.10; sparc-unknown-linux-gnu) X-Face: "_;p5u5aPsO,_Vsx"^v-pEq09'CU4&Dc1$fQExov$62l60cgCc%FnIwD=.UF^a>?5'9Kn[;433QFVV9M..2eN.@4ZWPGbdi<=?[:T>y?SD(R*-3It"Vj:)"dP Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV 0.83/760/Wed Mar 9 09:12:01 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 2876 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: davem@davemloft.net Precedence: bulk X-list: netdev Content-Length: 697 Lines: 17 On Tue, 8 Mar 2005 21:27:41 +1100 Herbert Xu wrote: > On Mon, Mar 07, 2005 at 09:35:36PM +1100, herbert wrote: > > > > Here's the patch to fix those two problems. Yes I know > > my dst_check implementation is lame. I'll come back and > > fix up all the dst_check functions by moving their dst_release > > calls out. It proves that you were right in that IPv6 dst > > leak thread :) > > As promised here is the patch that moves dst_release out of > dst->ops->check. It bloats sk_dst_check/__sk_dst_check slightly > but they're only used in a handful of places so it isn't too bad. > I actually counted, it's about a few hundred bytes. Applied, thanks Herbert. From hadi@cyberus.ca Thu Mar 10 18:21:50 2005 Received: with ECARTIS (v1.0.0; list netdev); Thu, 10 Mar 2005 18:21:56 -0800 (PST) Received: from mx02.cybersurf.com (mx02.cybersurf.com [209.197.145.105]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j2B2Lnq5011328 for ; Thu, 10 Mar 2005 18:21:50 -0800 Received: from mail.cyberus.ca ([209.197.145.21]) by mx02.cybersurf.com with esmtp (Exim 4.30) id 1D9Zme-00077o-R6 for netdev@oss.sgi.com; Thu, 10 Mar 2005 21:21:48 -0500 Received: from [24.103.99.32] (helo=[10.0.0.9]) by mail.cyberus.ca with esmtp (Exim 4.20) id 1D9ZmZ-0007qS-Qy; Thu, 10 Mar 2005 21:21:44 -0500 Subject: Re: Fw: Log full of "ing_filter: fixed ippp2 out ippp2" From: jamal Reply-To: hadi@cyberus.ca To: Andrew Morton Cc: netdev@oss.sgi.com, Kimmo Sundqvist In-Reply-To: <20050310174915.3148c9a8.akpm@osdl.org> References: <20050310174915.3148c9a8.akpm@osdl.org> Content-Type: multipart/mixed; boundary="=-LruYe0NJ6hHmL9sT3hgS" Organization: jamalopolous Message-Id: <1110507647.1088.82.camel@jzny.localdomain> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.2.2 Date: 10 Mar 2005 21:20:47 -0500 X-Virus-Scanned: ClamAV 0.83/760/Wed Mar 9 09:12:01 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 2878 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: hadi@cyberus.ca Precedence: bulk X-list: netdev Content-Length: 1694 Lines: 59 --=-LruYe0NJ6hHmL9sT3hgS Content-Type: text/plain Content-Transfer-Encoding: 7bit Does this fix it? On Thu, 2005-03-10 at 20:49, Andrew Morton wrote: > Can you check to see if 2.6.11 is still doing this? > > > Begin forwarded message: > > Date: Wed, 9 Mar 2005 22:07:41 +0200 > From: Kimmo Sundqvist > To: linux-kernel@vger.kernel.org > Subject: Log full of "ing_filter: fixed ippp2 out ippp2" > > > Hello > > Please cc all replies to me. > > After upgrading my little NATting firewall/router from 2.6.7-ck4 to > 2.6.10-gentoo-r6 my /var/log/messages is 15MB in size and most of it looks > like the text below. All traffic to the Internet seems to cause this. > > "cat /var/log/messages | uniq | uniqmessages" results in a 3MB file. I use > syslog-ng. --=-LruYe0NJ6hHmL9sT3hgS Content-Disposition: attachment; filename=isdn_p Content-Type: text/plain; name=isdn_p; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit --- a/drivers/isdn/i4l/isdn_net.c 2005-03-02 02:38:33.000000000 -0500 +++ b/drivers/isdn/i4l/isdn_net.c 2005-03-10 21:15:59.451485136 -0500 @@ -1786,6 +1786,7 @@ lp->stats.rx_bytes += skb->len; } skb->dev = ndev; + skb->input_dev = ndev; skb->pkt_type = PACKET_HOST; skb->mac.raw = skb->data; #ifdef ISDN_DEBUG_NET_DUMP --- a/drivers/isdn/i4l/isdn_ppp.c 2005-03-02 02:38:13.000000000 -0500 +++ b/drivers/isdn/i4l/isdn_ppp.c 2005-03-10 21:12:47.069731608 -0500 @@ -1178,6 +1178,7 @@ mlp->huptimer = 0; #endif /* CONFIG_IPPP_FILTER */ skb->dev = dev; + skb->input_dev = dev; skb->mac.raw = skb->data; netif_rx(skb); /* net_dev->local->stats.rx_packets++; done in isdn_net.c */ --=-LruYe0NJ6hHmL9sT3hgS-- From davem@davemloft.net Thu Mar 10 18:22:10 2005 Received: with ECARTIS (v1.0.0; list netdev); Thu, 10 Mar 2005 18:22:15 -0800 (PST) Received: from cheetah.davemloft.net (mail@dsl027-180-174.sfo1.dsl.speakeasy.net [216.27.180.174]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j2B2MA81011504 for ; Thu, 10 Mar 2005 18:22:10 -0800 Received: from localhost ([127.0.0.1] helo=cheetah.davemloft.net ident=davem) by cheetah.davemloft.net with smtp (Exim 3.36 #1 (Debian)) id 1D9Zlc-0002fN-00; Thu, 10 Mar 2005 18:20:44 -0800 Date: Thu, 10 Mar 2005 18:20:44 -0800 From: "David S. Miller" To: Patrick McHardy Cc: andre@tomt.net, vanco@satro.sk, linux-kernel@vger.kernel.org, netdev@oss.sgi.com Subject: Re: 2.6.11 on AMD64 traps Message-Id: <20050310182044.1d740738.davem@davemloft.net> In-Reply-To: <422F525F.90404@trash.net> References: <200503081900.18686.vanco@satro.sk> <422DF07D.7010908@tomt.net> <422F525F.90404@trash.net> X-Mailer: Sylpheed version 1.0.1 (GTK+ 1.2.10; sparc-unknown-linux-gnu) X-Face: "_;p5u5aPsO,_Vsx"^v-pEq09'CU4&Dc1$fQExov$62l60cgCc%FnIwD=.UF^a>?5'9Kn[;433QFVV9M..2eN.@4ZWPGbdi<=?[:T>y?SD(R*-3It"Vj:)"dP Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV 0.83/760/Wed Mar 9 09:12:01 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 2879 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: davem@davemloft.net Precedence: bulk X-list: netdev Content-Length: 561 Lines: 17 On Wed, 09 Mar 2005 20:45:35 +0100 Patrick McHardy wrote: > > Michal Vanco wrote: > >> > >> I see this problem running 2.6.11 on dual AMD64: > >> > >> Running quagga routing daemon (ospf+bgp) and issuing "netstat -rn |wc > >> -l" command > >> while quagga tries to load more than 154000 routes from its bgp > >> neighbours causes this trap: > > This patch should fix it. The crash is caused by stale pointers, > the pointers in fib_iter_state are not reloaded after seq->stop() > followed by seq->start(pos > 0). Applied, thanks Patrick. From davem@davemloft.net Thu Mar 10 18:24:35 2005 Received: with ECARTIS (v1.0.0; list netdev); Thu, 10 Mar 2005 18:24:42 -0800 (PST) Received: from cheetah.davemloft.net (mail@dsl027-180-174.sfo1.dsl.speakeasy.net [216.27.180.174]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j2B2OZ2x012738 for ; Thu, 10 Mar 2005 18:24:35 -0800 Received: from localhost ([127.0.0.1] helo=cheetah.davemloft.net ident=davem) by cheetah.davemloft.net with smtp (Exim 3.36 #1 (Debian)) id 1D9Zo4-0002gD-00; Thu, 10 Mar 2005 18:23:16 -0800 Date: Thu, 10 Mar 2005 18:23:16 -0800 From: "David S. Miller" To: Jeff Garzik Cc: domen@coderock.org, netdev@oss.sgi.com, sfeldma@pobox.com, janitor@sternwelten.at Subject: Re: [patch 11/26] janitor: net/tg3: pci_find_device to pci_dev_present Message-Id: <20050310182316.4c2c49ec.davem@davemloft.net> In-Reply-To: <422F5BC6.9020802@pobox.com> References: <20050306103312.3155B1E46E@trashy.coderock.org> <422F5BC6.9020802@pobox.com> X-Mailer: Sylpheed version 1.0.1 (GTK+ 1.2.10; sparc-unknown-linux-gnu) X-Face: "_;p5u5aPsO,_Vsx"^v-pEq09'CU4&Dc1$fQExov$62l60cgCc%FnIwD=.UF^a>?5'9Kn[;433QFVV9M..2eN.@4ZWPGbdi<=?[:T>y?SD(R*-3It"Vj:)"dP Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV 0.83/760/Wed Mar 9 09:12:01 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 2880 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: davem@davemloft.net Precedence: bulk X-list: netdev Content-Length: 251 Lines: 9 On Wed, 09 Mar 2005 15:25:42 -0500 Jeff Garzik wrote: > domen@coderock.org wrote: > > Replace pci_find_device with pci_dev_present. Compile tested. ... > seems OK to me. DaveM should be applying this, though. Applied, thanks. From davem@davemloft.net Thu Mar 10 18:40:10 2005 Received: with ECARTIS (v1.0.0; list netdev); Thu, 10 Mar 2005 18:40:13 -0800 (PST) Received: from cheetah.davemloft.net (mail@dsl027-180-174.sfo1.dsl.speakeasy.net [216.27.180.174]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j2B2eAt5013854 for ; Thu, 10 Mar 2005 18:40:10 -0800 Received: from localhost ([127.0.0.1] helo=cheetah.davemloft.net ident=davem) by cheetah.davemloft.net with smtp (Exim 3.36 #1 (Debian)) id 1D9a3E-0002pI-00; Thu, 10 Mar 2005 18:38:56 -0800 Date: Thu, 10 Mar 2005 18:38:56 -0800 From: "David S. Miller" To: nhorman@redhat.com Cc: sri@us.ibm.com, netdev@oss.sgi.com, lksctp-developers@lists.sourceforge.net Subject: Re: [Patch] sctp: add receive buffer accounting to sctp (fwd) Message-Id: <20050310183856.08cb5f7b.davem@davemloft.net> In-Reply-To: <20050310154342.GG6341@hmsendeavour.rdu.redhat.com> References: <20050309211632.6f70fe41.davem@davemloft.net> <20050310120803.GA6341@hmsendeavour.rdu.redhat.com> <20050310154342.GG6341@hmsendeavour.rdu.redhat.com> X-Mailer: Sylpheed version 1.0.1 (GTK+ 1.2.10; sparc-unknown-linux-gnu) X-Face: "_;p5u5aPsO,_Vsx"^v-pEq09'CU4&Dc1$fQExov$62l60cgCc%FnIwD=.UF^a>?5'9Kn[;433QFVV9M..2eN.@4ZWPGbdi<=?[:T>y?SD(R*-3It"Vj:)"dP Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV 0.83/760/Wed Mar 9 09:12:01 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 2881 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: davem@davemloft.net Precedence: bulk X-list: netdev Content-Length: 237 Lines: 7 On Thu, 10 Mar 2005 10:43:42 -0500 nhorman@redhat.com wrote: > Repost of my ealier rcvbuf patch. No changes, but rediffed to apply cleanly to > the head of the bitkeeper tree. Passes all lksctp regression tests Applied, thanks Neil. From davem@davemloft.net Thu Mar 10 18:41:39 2005 Received: with ECARTIS (v1.0.0; list netdev); Thu, 10 Mar 2005 18:41:44 -0800 (PST) Received: from cheetah.davemloft.net (mail@dsl027-180-174.sfo1.dsl.speakeasy.net [216.27.180.174]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j2B2fdYQ014251 for ; Thu, 10 Mar 2005 18:41:39 -0800 Received: from localhost ([127.0.0.1] helo=cheetah.davemloft.net ident=davem) by cheetah.davemloft.net with smtp (Exim 3.36 #1 (Debian)) id 1D9a4N-0002pl-00; Thu, 10 Mar 2005 18:40:07 -0800 Date: Thu, 10 Mar 2005 18:40:07 -0800 From: "David S. Miller" To: Patrick McHardy Cc: steve@services.navaho.net, netdev@oss.sgi.com Subject: Re: IPSEC Message-Id: <20050310184007.28eaabd0.davem@davemloft.net> In-Reply-To: <422DE487.5020800@trash.net> References: <422DE487.5020800@trash.net> X-Mailer: Sylpheed version 1.0.1 (GTK+ 1.2.10; sparc-unknown-linux-gnu) X-Face: "_;p5u5aPsO,_Vsx"^v-pEq09'CU4&Dc1$fQExov$62l60cgCc%FnIwD=.UF^a>?5'9Kn[;433QFVV9M..2eN.@4ZWPGbdi<=?[:T>y?SD(R*-3It"Vj:)"dP Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV 0.83/760/Wed Mar 9 09:12:01 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 2882 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: davem@davemloft.net Precedence: bulk X-list: netdev Content-Length: 663 Lines: 22 On Tue, 08 Mar 2005 18:44:39 +0100 Patrick McHardy wrote: > Steve Hill wrote: > > > then the ESP SA is added and it has the same sequence number (1) as the > > AH SA so the AH SA gets deleted. > > > > The xfrm_state_add() function does: > > x1 = __xfrm_find_acq_byseq(x->km.seq); > > ... > > xfrm_state_delete(x1); > > And this is responsible for deleting the AH SA due to it's matching > > sequence number. > > This is a bug in the kernel, __xfrm_find_acq_byseq should only return > XFRM_STATE_ACQ states. This patch should fix it. > > Signed-off-by: Patrick McHardy Applied, thanks Patrick. From davem@davemloft.net Thu Mar 10 18:42:39 2005 Received: with ECARTIS (v1.0.0; list netdev); Thu, 10 Mar 2005 18:42:44 -0800 (PST) Received: from cheetah.davemloft.net (mail@dsl027-180-174.sfo1.dsl.speakeasy.net [216.27.180.174]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j2B2gdGT014687 for ; Thu, 10 Mar 2005 18:42:39 -0800 Received: from localhost ([127.0.0.1] helo=cheetah.davemloft.net ident=davem) by cheetah.davemloft.net with smtp (Exim 3.36 #1 (Debian)) id 1D9a5g-0002qG-00; Thu, 10 Mar 2005 18:41:28 -0800 Date: Thu, 10 Mar 2005 18:41:28 -0800 From: "David S. Miller" To: Stephen Hemminger Cc: netdev@oss.sgi.com Subject: Re: [PATCH] rearrange netdevice structure to save space Message-Id: <20050310184128.141c7583.davem@davemloft.net> In-Reply-To: <20050309092628.3c9014db@dxpl.pdx.osdl.net> References: <20050309092628.3c9014db@dxpl.pdx.osdl.net> X-Mailer: Sylpheed version 1.0.1 (GTK+ 1.2.10; sparc-unknown-linux-gnu) X-Face: "_;p5u5aPsO,_Vsx"^v-pEq09'CU4&Dc1$fQExov$62l60cgCc%FnIwD=.UF^a>?5'9Kn[;433QFVV9M..2eN.@4ZWPGbdi<=?[:T>y?SD(R*-3It"Vj:)"dP Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV 0.83/760/Wed Mar 9 09:12:01 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 2883 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: davem@davemloft.net Precedence: bulk X-list: netdev Content-Length: 232 Lines: 8 On Wed, 9 Mar 2005 09:26:28 -0800 Stephen Hemminger wrote: > Trivial reordering of netdevice structure to save four bytes. > > Signed-off-by: Stephen Hemminger Applied, thanks Stephen. From davem@davemloft.net Thu Mar 10 18:44:12 2005 Received: with ECARTIS (v1.0.0; list netdev); Thu, 10 Mar 2005 18:44:17 -0800 (PST) Received: from cheetah.davemloft.net (mail@dsl027-180-174.sfo1.dsl.speakeasy.net [216.27.180.174]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j2B2iC4x015370 for ; Thu, 10 Mar 2005 18:44:12 -0800 Received: from localhost ([127.0.0.1] helo=cheetah.davemloft.net ident=davem) by cheetah.davemloft.net with smtp (Exim 3.36 #1 (Debian)) id 1D9a79-0002qV-00; Thu, 10 Mar 2005 18:42:59 -0800 Date: Thu, 10 Mar 2005 18:42:59 -0800 From: "David S. Miller" To: Stephen Hemminger Cc: hadi@znyx.com, netdev@oss.sgi.com Subject: Re: [PATCH] move tc_u32_mark into pkt_cls.h Message-Id: <20050310184259.51f1e474.davem@davemloft.net> In-Reply-To: <20050310104207.1d74ac00@dxpl.pdx.osdl.net> References: <20050310104207.1d74ac00@dxpl.pdx.osdl.net> X-Mailer: Sylpheed version 1.0.1 (GTK+ 1.2.10; sparc-unknown-linux-gnu) X-Face: "_;p5u5aPsO,_Vsx"^v-pEq09'CU4&Dc1$fQExov$62l60cgCc%FnIwD=.UF^a>?5'9Kn[;433QFVV9M..2eN.@4ZWPGbdi<=?[:T>y?SD(R*-3It"Vj:)"dP Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV 0.83/760/Wed Mar 9 09:12:01 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 2884 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: davem@davemloft.net Precedence: bulk X-list: netdev Content-Length: 527 Lines: 14 On Thu, 10 Mar 2005 10:42:07 -0800 Stephen Hemminger wrote: > The tc_u32_mark structure is used as part of the netlink message > from the user API to the kernel, so it needs to be moved to include/linux/pkt_cls.h > and have types changed from u32 to __u32. > > Also, the definition of u32 performance counters doesn't need to depend > on the config option. The definition can exist even if the code isn't > enabled. > > Signed-off-by: Stephen Hemminger Applied, thanks Stephen. From davem@davemloft.net Thu Mar 10 18:50:59 2005 Received: with ECARTIS (v1.0.0; list netdev); Thu, 10 Mar 2005 18:51:02 -0800 (PST) Received: from cheetah.davemloft.net (mail@dsl027-180-174.sfo1.dsl.speakeasy.net [216.27.180.174]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j2B2oqF6016084 for ; Thu, 10 Mar 2005 18:50:59 -0800 Received: from localhost ([127.0.0.1] helo=cheetah.davemloft.net ident=davem) by cheetah.davemloft.net with smtp (Exim 3.36 #1 (Debian)) id 1D9aDd-0002vO-00; Thu, 10 Mar 2005 18:49:41 -0800 Date: Thu, 10 Mar 2005 18:49:41 -0800 From: "David S. Miller" To: Stephen Hemminger Cc: netdev@oss.sgi.com, bridge@osdl.org Subject: Re: [PATCH] (1/4) bridge: use jenkins hash Message-Id: <20050310184941.21a033bb.davem@davemloft.net> In-Reply-To: <20050310154429.0f879894@dxpl.pdx.osdl.net> References: <20050310154429.0f879894@dxpl.pdx.osdl.net> X-Mailer: Sylpheed version 1.0.1 (GTK+ 1.2.10; sparc-unknown-linux-gnu) X-Face: "_;p5u5aPsO,_Vsx"^v-pEq09'CU4&Dc1$fQExov$62l60cgCc%FnIwD=.UF^a>?5'9Kn[;433QFVV9M..2eN.@4ZWPGbdi<=?[:T>y?SD(R*-3It"Vj:)"dP Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV 0.83/760/Wed Mar 9 09:12:01 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 2885 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: davem@davemloft.net Precedence: bulk X-list: netdev Content-Length: 371 Lines: 10 On Thu, 10 Mar 2005 15:44:29 -0800 Stephen Hemminger wrote: > Replace the existing mac hash in the bridge code with the nice > inline jenkins hash. This should provide better distribution across > hash buckets and compiles to code that is similar in complexity. > > Signed-off-by: Stephen Hemminger Applied, thanks Stephen. From davem@davemloft.net Thu Mar 10 18:51:29 2005 Received: with ECARTIS (v1.0.0; list netdev); Thu, 10 Mar 2005 18:51:32 -0800 (PST) Received: from cheetah.davemloft.net (mail@dsl027-180-174.sfo1.dsl.speakeasy.net [216.27.180.174]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j2B2pTLa016247 for ; Thu, 10 Mar 2005 18:51:29 -0800 Received: from localhost ([127.0.0.1] helo=cheetah.davemloft.net ident=davem) by cheetah.davemloft.net with smtp (Exim 3.36 #1 (Debian)) id 1D9aEE-0002vh-00; Thu, 10 Mar 2005 18:50:18 -0800 Date: Thu, 10 Mar 2005 18:50:18 -0800 From: "David S. Miller" To: Stephen Hemminger Cc: netdev@oss.sgi.com, bridge@lists.osdl.org Subject: Re: [PATCH] (2/4) bridge: get rid of unneeded include Message-Id: <20050310185018.5ee03918.davem@davemloft.net> In-Reply-To: <20050310154432.1163ad2d@dxpl.pdx.osdl.net> References: <20050310154432.1163ad2d@dxpl.pdx.osdl.net> X-Mailer: Sylpheed version 1.0.1 (GTK+ 1.2.10; sparc-unknown-linux-gnu) X-Face: "_;p5u5aPsO,_Vsx"^v-pEq09'CU4&Dc1$fQExov$62l60cgCc%FnIwD=.UF^a>?5'9Kn[;433QFVV9M..2eN.@4ZWPGbdi<=?[:T>y?SD(R*-3It"Vj:)"dP Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV 0.83/760/Wed Mar 9 09:12:01 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 2886 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: davem@davemloft.net Precedence: bulk X-list: netdev Content-Length: 184 Lines: 8 On Thu, 10 Mar 2005 15:44:32 -0800 Stephen Hemminger wrote: > Get rid of unneeded include. > > Signed-off-by: Stephen Hemminger Applied. From davem@davemloft.net Thu Mar 10 18:52:08 2005 Received: with ECARTIS (v1.0.0; list netdev); Thu, 10 Mar 2005 18:52:12 -0800 (PST) Received: from cheetah.davemloft.net (mail@dsl027-180-174.sfo1.dsl.speakeasy.net [216.27.180.174]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j2B2q8wZ016726 for ; Thu, 10 Mar 2005 18:52:08 -0800 Received: from localhost ([127.0.0.1] helo=cheetah.davemloft.net ident=davem) by cheetah.davemloft.net with smtp (Exim 3.36 #1 (Debian)) id 1D9aEr-0002vz-00; Thu, 10 Mar 2005 18:50:57 -0800 Date: Thu, 10 Mar 2005 18:50:57 -0800 From: "David S. Miller" To: Stephen Hemminger Cc: netdev@oss.sgi.com, bridge@osdl.org Subject: Re: [PATCH] (3/4) bridge: get rid of threaded link for forwarding timeout Message-Id: <20050310185057.05336cd1.davem@davemloft.net> In-Reply-To: <20050310154434.52f8f561@dxpl.pdx.osdl.net> References: <20050310154434.52f8f561@dxpl.pdx.osdl.net> X-Mailer: Sylpheed version 1.0.1 (GTK+ 1.2.10; sparc-unknown-linux-gnu) X-Face: "_;p5u5aPsO,_Vsx"^v-pEq09'CU4&Dc1$fQExov$62l60cgCc%FnIwD=.UF^a>?5'9Kn[;433QFVV9M..2eN.@4ZWPGbdi<=?[:T>y?SD(R*-3It"Vj:)"dP Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV 0.83/760/Wed Mar 9 09:12:01 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 2887 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: davem@davemloft.net Precedence: bulk X-list: netdev Content-Length: 508 Lines: 13 On Thu, 10 Mar 2005 15:44:34 -0800 Stephen Hemminger wrote: > For 2.6, I changed the bridge forwarding table timeout code to keep > a threaded list of in order entries. Well, it turns out that this is > a performance hit because we end up constantly moving entries around > in the list. Later patch changes this to be in place update with RCU. > > This version just uses a 100ms garbage collection timer. > > Signed-off-by: Stephen Hemminger Applied, thanks. From davem@davemloft.net Thu Mar 10 18:53:03 2005 Received: with ECARTIS (v1.0.0; list netdev); Thu, 10 Mar 2005 18:53:07 -0800 (PST) Received: from cheetah.davemloft.net (mail@dsl027-180-174.sfo1.dsl.speakeasy.net [216.27.180.174]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j2B2r3b4017362 for ; Thu, 10 Mar 2005 18:53:03 -0800 Received: from localhost ([127.0.0.1] helo=cheetah.davemloft.net ident=davem) by cheetah.davemloft.net with smtp (Exim 3.36 #1 (Debian)) id 1D9aFk-0002wJ-00; Thu, 10 Mar 2005 18:51:52 -0800 Date: Thu, 10 Mar 2005 18:51:52 -0800 From: "David S. Miller" To: Stephen Hemminger Cc: netdev@oss.sgi.com, bridge@lists.osdl.org Subject: Re: [PATCH] (4/4) bridge: forwarding table lockless update Message-Id: <20050310185152.12ed9819.davem@davemloft.net> In-Reply-To: <20050310154437.1223b6e9@dxpl.pdx.osdl.net> References: <20050310154437.1223b6e9@dxpl.pdx.osdl.net> X-Mailer: Sylpheed version 1.0.1 (GTK+ 1.2.10; sparc-unknown-linux-gnu) X-Face: "_;p5u5aPsO,_Vsx"^v-pEq09'CU4&Dc1$fQExov$62l60cgCc%FnIwD=.UF^a>?5'9Kn[;433QFVV9M..2eN.@4ZWPGbdi<=?[:T>y?SD(R*-3It"Vj:)"dP Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV 0.83/760/Wed Mar 9 09:12:01 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 2888 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: davem@davemloft.net Precedence: bulk X-list: netdev Content-Length: 413 Lines: 11 On Thu, 10 Mar 2005 15:44:37 -0800 Stephen Hemminger wrote: > Optimize bridge forwarding table for the fastpath of updating > an existing entry. Use RCU to find the entry and change it's time. > Fallback to normal locking for insert. This gives about a 1/3 > improvement in packets forwarding per second on SMP. > > Signed-off-by: Stephen Hemminger Applied, thanks. From davem@davemloft.net Thu Mar 10 18:53:57 2005 Received: with ECARTIS (v1.0.0; list netdev); Thu, 10 Mar 2005 18:54:01 -0800 (PST) Received: from cheetah.davemloft.net (mail@dsl027-180-174.sfo1.dsl.speakeasy.net [216.27.180.174]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j2B2rvo6018024 for ; Thu, 10 Mar 2005 18:53:57 -0800 Received: from localhost ([127.0.0.1] helo=cheetah.davemloft.net ident=davem) by cheetah.davemloft.net with smtp (Exim 3.36 #1 (Debian)) id 1D9aGc-0002wY-00; Thu, 10 Mar 2005 18:52:46 -0800 Date: Thu, 10 Mar 2005 18:52:46 -0800 From: "David S. Miller" To: Stephen Hemminger Cc: netdev@oss.sgi.com Subject: Re: [PATCH] optimize is_valid_ether_addr Message-Id: <20050310185246.6b626480.davem@davemloft.net> In-Reply-To: <20050310154439.75f62f22@dxpl.pdx.osdl.net> References: <20050310154439.75f62f22@dxpl.pdx.osdl.net> X-Mailer: Sylpheed version 1.0.1 (GTK+ 1.2.10; sparc-unknown-linux-gnu) X-Face: "_;p5u5aPsO,_Vsx"^v-pEq09'CU4&Dc1$fQExov$62l60cgCc%FnIwD=.UF^a>?5'9Kn[;433QFVV9M..2eN.@4ZWPGbdi<=?[:T>y?SD(R*-3It"Vj:)"dP Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV 0.83/760/Wed Mar 9 09:12:01 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 2889 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: davem@davemloft.net Precedence: bulk X-list: netdev Content-Length: 352 Lines: 10 On Thu, 10 Mar 2005 15:44:39 -0800 Stephen Hemminger wrote: > Low level optimization of the comparison with zero address. > On most cpu's faster to use unrolled or rather than a loop > and memcmp. This is in the fastpath of bridge forwarding. > > Signed-off-by: Stephen Hemminger Applied, thanks Stephen. From davem@davemloft.net Thu Mar 10 18:59:40 2005 Received: with ECARTIS (v1.0.0; list netdev); Thu, 10 Mar 2005 18:59:47 -0800 (PST) Received: from cheetah.davemloft.net (mail@dsl027-180-174.sfo1.dsl.speakeasy.net [216.27.180.174]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j2B2xeUo018880 for ; Thu, 10 Mar 2005 18:59:40 -0800 Received: from localhost ([127.0.0.1] helo=cheetah.davemloft.net ident=davem) by cheetah.davemloft.net with smtp (Exim 3.36 #1 (Debian)) id 1D9aM5-0002yC-00; Thu, 10 Mar 2005 18:58:25 -0800 Date: Thu, 10 Mar 2005 18:58:24 -0800 From: "David S. Miller" To: Robert Olsson Cc: shemminger@osdl.org, Robert.Olsson@data.slu.se, netdev@oss.sgi.com Subject: Re: pktgen: causing lots of errors in console log Message-Id: <20050310185824.30499218.davem@davemloft.net> In-Reply-To: <16942.55689.924299.906304@robur.slu.se> References: <20050308140826.451435e5@dxpl.pdx.osdl.net> <16942.55689.924299.906304@robur.slu.se> X-Mailer: Sylpheed version 1.0.1 (GTK+ 1.2.10; sparc-unknown-linux-gnu) X-Face: "_;p5u5aPsO,_Vsx"^v-pEq09'CU4&Dc1$fQExov$62l60cgCc%FnIwD=.UF^a>?5'9Kn[;433QFVV9M..2eN.@4ZWPGbdi<=?[:T>y?SD(R*-3It"Vj:)"dP Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV 0.83/760/Wed Mar 9 09:12:01 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 2890 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: davem@davemloft.net Precedence: bulk X-list: netdev Content-Length: 218 Lines: 10 On Wed, 9 Mar 2005 12:10:01 +0100 Robert Olsson wrote: > Stephen Hemminger writes: > > 1. Errors from IPV4 > > Freeing alive in_device ffff81007e96a400 > > Try: Applied, thanks Robert. From davem@davemloft.net Thu Mar 10 19:21:52 2005 Received: with ECARTIS (v1.0.0; list netdev); Thu, 10 Mar 2005 19:21:57 -0800 (PST) Received: from cheetah.davemloft.net (mail@dsl027-180-174.sfo1.dsl.speakeasy.net [216.27.180.174]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j2B3LpvN020332 for ; Thu, 10 Mar 2005 19:21:51 -0800 Received: from localhost ([127.0.0.1] helo=cheetah.davemloft.net ident=davem) by cheetah.davemloft.net with smtp (Exim 3.36 #1 (Debian)) id 1D9ahL-000393-00; Thu, 10 Mar 2005 19:20:23 -0800 Date: Thu, 10 Mar 2005 19:20:23 -0800 From: "David S. Miller" To: Patrick McHardy Cc: maxk@qualcomm.com, shemminger@osdl.org, netdev@oss.sgi.com Subject: Re: Fw: [Bug 4279] New: When I try to start vpnc the net/core/skbuff.c:91 crash Message-Id: <20050310192023.1270fef6.davem@davemloft.net> In-Reply-To: <4228AD8F.4020000@trash.net> References: <20050303095832.6a084856@dxpl.pdx.osdl.net> <4228A354.8020904@qualcomm.com> <4228AD8F.4020000@trash.net> X-Mailer: Sylpheed version 1.0.1 (GTK+ 1.2.10; sparc-unknown-linux-gnu) X-Face: "_;p5u5aPsO,_Vsx"^v-pEq09'CU4&Dc1$fQExov$62l60cgCc%FnIwD=.UF^a>?5'9Kn[;433QFVV9M..2eN.@4ZWPGbdi<=?[:T>y?SD(R*-3It"Vj:)"dP Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV 0.83/760/Wed Mar 9 09:12:01 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 2891 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: davem@davemloft.net Precedence: bulk X-list: netdev Content-Length: 751 Lines: 25 On Fri, 04 Mar 2005 19:48:47 +0100 Patrick McHardy wrote: > Max Krasnyansky wrote: > > Hi Stephen, > > > >> Looks like a something wrong with tun driver on 2.6.11 > > > > Thanks for forwarding this. I'll take a look at it. > > As far as I remember nothing really changed in the TUN write logic. > > Must be some other changes broke it. > > This check is wrong, gcc optimizes it away: > > if ((len -= sizeof(pi)) > len) > return -EINVAL; > > This could be responsible for the BUG. If len is 2 or 3 and TUN_NO_PI > isn't set it underflows. alloc_skb() allocates len + 2, which is 0 or > 1 byte. skb_reserve tries to reserve 2 bytes and things explode in > skb_put. Good catch Patrick. Patch applied, thanks. From davem@davemloft.net Thu Mar 10 19:42:12 2005 Received: with ECARTIS (v1.0.0; list netdev); Thu, 10 Mar 2005 19:42:18 -0800 (PST) Received: from cheetah.davemloft.net (mail@dsl027-180-174.sfo1.dsl.speakeasy.net [216.27.180.174]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j2B3gC0r021713 for ; Thu, 10 Mar 2005 19:42:12 -0800 Received: from localhost ([127.0.0.1] helo=cheetah.davemloft.net ident=davem) by cheetah.davemloft.net with smtp (Exim 3.36 #1 (Debian)) id 1D9b1D-0003Gu-00; Thu, 10 Mar 2005 19:40:55 -0800 Date: Thu, 10 Mar 2005 19:40:55 -0800 From: "David S. Miller" To: "chas williams - CONTRACTOR" Cc: netdev@oss.sgi.com Subject: Re: [PATCH] [ATM]: [fore200e] rewrite to eliminate pci_find_device() but preserve sbus support Message-Id: <20050310194055.3b5baac6.davem@davemloft.net> In-Reply-To: <200502231417.j1NEHIZ2012625@ginger.cmf.nrl.navy.mil> References: <200502231417.j1NEHIZ2012625@ginger.cmf.nrl.navy.mil> X-Mailer: Sylpheed version 1.0.1 (GTK+ 1.2.10; sparc-unknown-linux-gnu) X-Face: "_;p5u5aPsO,_Vsx"^v-pEq09'CU4&Dc1$fQExov$62l60cgCc%FnIwD=.UF^a>?5'9Kn[;433QFVV9M..2eN.@4ZWPGbdi<=?[:T>y?SD(R*-3It"Vj:)"dP Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV 0.83/760/Wed Mar 9 09:12:01 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 2892 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: davem@davemloft.net Precedence: bulk X-list: netdev Content-Length: 311 Lines: 10 On Wed, 23 Feb 2005 09:17:18 -0500 "chas williams - CONTRACTOR" wrote: > this patch correctly removes the pci_find_device() used by the fore200e > driver. the __init/__exit remains a bit clunky since we need to preserve > sbus support. > > please apply to 2.6. Applied, thanks Chas. From davem@davemloft.net Thu Mar 10 19:46:37 2005 Received: with ECARTIS (v1.0.0; list netdev); Thu, 10 Mar 2005 19:46:42 -0800 (PST) Received: from cheetah.davemloft.net (mail@dsl027-180-174.sfo1.dsl.speakeasy.net [216.27.180.174]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j2B3kbrC022291 for ; Thu, 10 Mar 2005 19:46:37 -0800 Received: from localhost ([127.0.0.1] helo=cheetah.davemloft.net ident=davem) by cheetah.davemloft.net with smtp (Exim 3.36 #1 (Debian)) id 1D9b5V-0003Hy-00; Thu, 10 Mar 2005 19:45:21 -0800 Date: Thu, 10 Mar 2005 19:45:21 -0800 From: "David S. Miller" To: "Michael Chan" Cc: d.willmann@tu-bs.de, netdev@oss.sgi.com, jluebbe@lasnet.de, davem@redhat.com Subject: Re: tg3 kernel oops when setting flow control while interface is down (2.6.10) Message-Id: <20050310194521.317474c7.davem@davemloft.net> In-Reply-To: References: X-Mailer: Sylpheed version 1.0.1 (GTK+ 1.2.10; sparc-unknown-linux-gnu) X-Face: "_;p5u5aPsO,_Vsx"^v-pEq09'CU4&Dc1$fQExov$62l60cgCc%FnIwD=.UF^a>?5'9Kn[;433QFVV9M..2eN.@4ZWPGbdi<=?[:T>y?SD(R*-3It"Vj:)"dP Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV 0.83/760/Wed Mar 9 09:12:01 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 2893 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: davem@davemloft.net Precedence: bulk X-list: netdev Content-Length: 557 Lines: 14 On Mon, 28 Feb 2005 09:26:25 -0800 "Michael Chan" wrote: > I think it is better to just set the PAUSE flags and return 0 if > !netif_running(). This way, the settings will take effect when the device is > subsequently brought up. Then arguably we should do the same for link settings too. His patch exactly makes pause parameter setting behave the same as we currently do for link settings, if the device is down or in low power PHY mode, we -EAGAIN error out. We have to decide driver-wide how we're going to handle this situation. From davem@davemloft.net Thu Mar 10 19:47:37 2005 Received: with ECARTIS (v1.0.0; list netdev); Thu, 10 Mar 2005 19:47:41 -0800 (PST) Received: from cheetah.davemloft.net (mail@dsl027-180-174.sfo1.dsl.speakeasy.net [216.27.180.174]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j2B3lXZY022663 for ; Thu, 10 Mar 2005 19:47:37 -0800 Received: from localhost ([127.0.0.1] helo=cheetah.davemloft.net ident=davem) by cheetah.davemloft.net with smtp (Exim 3.36 #1 (Debian)) id 1D9b6Q-0003IN-00; Thu, 10 Mar 2005 19:46:18 -0800 Date: Thu, 10 Mar 2005 19:46:18 -0800 From: "David S. Miller" To: Ralf Baechle Cc: netdev@oss.sgi.com Subject: Re: [PATCH] NET/ROM locking Message-Id: <20050310194618.3f37be03.davem@davemloft.net> In-Reply-To: <20050302090246.GA6844@linux-mips.org> References: <20050302090246.GA6844@linux-mips.org> X-Mailer: Sylpheed version 1.0.1 (GTK+ 1.2.10; sparc-unknown-linux-gnu) X-Face: "_;p5u5aPsO,_Vsx"^v-pEq09'CU4&Dc1$fQExov$62l60cgCc%FnIwD=.UF^a>?5'9Kn[;433QFVV9M..2eN.@4ZWPGbdi<=?[:T>y?SD(R*-3It"Vj:)"dP Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV 0.83/760/Wed Mar 9 09:12:01 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 2894 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: davem@davemloft.net Precedence: bulk X-list: netdev Content-Length: 149 Lines: 6 On Wed, 2 Mar 2005 09:02:46 +0000 Ralf Baechle wrote: > Fix deadlock in NET/ROM due to double locking. Applied, thanks Ralf. From davem@davemloft.net Thu Mar 10 19:48:19 2005 Received: with ECARTIS (v1.0.0; list netdev); Thu, 10 Mar 2005 19:48:23 -0800 (PST) Received: from cheetah.davemloft.net (mail@dsl027-180-174.sfo1.dsl.speakeasy.net [216.27.180.174]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j2B3mIs2023138 for ; Thu, 10 Mar 2005 19:48:18 -0800 Received: from localhost ([127.0.0.1] helo=cheetah.davemloft.net ident=davem) by cheetah.davemloft.net with smtp (Exim 3.36 #1 (Debian)) id 1D9b7C-0003Ic-00; Thu, 10 Mar 2005 19:47:06 -0800 Date: Thu, 10 Mar 2005 19:47:02 -0800 From: "David S. Miller" To: Ralf Baechle Cc: netdev@oss.sgi.com Subject: Re: [PATCH] Fix ROSE security hole Message-Id: <20050310194702.1b812b51.davem@davemloft.net> In-Reply-To: <20050302090658.GA6873@linux-mips.org> References: <20050302090658.GA6873@linux-mips.org> X-Mailer: Sylpheed version 1.0.1 (GTK+ 1.2.10; sparc-unknown-linux-gnu) X-Face: "_;p5u5aPsO,_Vsx"^v-pEq09'CU4&Dc1$fQExov$62l60cgCc%FnIwD=.UF^a>?5'9Kn[;433QFVV9M..2eN.@4ZWPGbdi<=?[:T>y?SD(R*-3It"Vj:)"dP Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV 0.83/760/Wed Mar 9 09:12:01 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 2895 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: davem@davemloft.net Precedence: bulk X-list: netdev Content-Length: 202 Lines: 7 On Wed, 2 Mar 2005 09:06:58 +0000 Ralf Baechle wrote: > ROSE wasn't verifying the ndigis argument of a new route resulting in a > minor security hole. Also applied, thanks Ralf. From davem@davemloft.net Thu Mar 10 19:49:03 2005 Received: with ECARTIS (v1.0.0; list netdev); Thu, 10 Mar 2005 19:49:07 -0800 (PST) Received: from cheetah.davemloft.net (mail@dsl027-180-174.sfo1.dsl.speakeasy.net [216.27.180.174]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j2B3n3sL023589 for ; Thu, 10 Mar 2005 19:49:03 -0800 Received: from localhost ([127.0.0.1] helo=cheetah.davemloft.net ident=davem) by cheetah.davemloft.net with smtp (Exim 3.36 #1 (Debian)) id 1D9b7v-0003Is-00; Thu, 10 Mar 2005 19:47:51 -0800 Date: Thu, 10 Mar 2005 19:47:50 -0800 From: "David S. Miller" To: Ralf Baechle Cc: netdev@oss.sgi.com Subject: Re: [PATCH] Sparse fixes for NETROM Message-Id: <20050310194750.1e17f71b.davem@davemloft.net> In-Reply-To: <20050302204753.GA5985@linux-mips.org> References: <20050302204753.GA5985@linux-mips.org> X-Mailer: Sylpheed version 1.0.1 (GTK+ 1.2.10; sparc-unknown-linux-gnu) X-Face: "_;p5u5aPsO,_Vsx"^v-pEq09'CU4&Dc1$fQExov$62l60cgCc%FnIwD=.UF^a>?5'9Kn[;433QFVV9M..2eN.@4ZWPGbdi<=?[:T>y?SD(R*-3It"Vj:)"dP Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV 0.83/760/Wed Mar 9 09:12:01 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 2896 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: davem@davemloft.net Precedence: bulk X-list: netdev Content-Length: 170 Lines: 7 On Wed, 2 Mar 2005 21:47:53 +0100 Ralf Baechle wrote: > Moving nr_init_timers prototype to where all the other prototypes > already are. Applied. From kaber@trash.net Thu Mar 10 20:35:19 2005 Received: with ECARTIS (v1.0.0; list netdev); Thu, 10 Mar 2005 20:35:23 -0800 (PST) Received: from kaber.coreworks.de ([62.206.217.67]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j2B4ZJ1G000846 for ; Thu, 10 Mar 2005 20:35:19 -0800 Received: from localhost ([127.0.0.1]) by kaber.coreworks.de with esmtp (Exim 4.50) id 1D9bre-0002Vo-11; Fri, 11 Mar 2005 05:35:06 +0100 Message-ID: <42311FF9.5010007@trash.net> Date: Fri, 11 Mar 2005 05:35:05 +0100 From: Patrick McHardy User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.7.5) Gecko/20050106 Debian/1.7.5-1 X-Accept-Language: en MIME-Version: 1.0 To: Matt Mackall CC: Jeff Garzik , netdev@oss.sgi.com, Jeff Moyer Subject: Re: [PATCH 1/7] netpoll: shorten carrier detect timeout References: <2.454130102@selenic.com> <422A4A38.4040303@trash.net> <20050306002015.GD3120@waste.org> <422A564D.4080809@trash.net> <20050310230117.GP3120@waste.org> In-Reply-To: <20050310230117.GP3120@waste.org> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV 0.83/760/Wed Mar 9 09:12:01 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 2897 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: kaber@trash.net Precedence: bulk X-list: netdev Content-Length: 572 Lines: 15 Matt Mackall wrote: > Ok, on closer inspection, the current logic is: the NIC reports > carrier detect nearly instaneously and thus its carrier detect > reporting is considered unreliable. Rather than immediately sending > packets, we wait for some interval for it to really be up so that the > backlog of console messages doesn't get pumped into the bit bucket. > > So I'm going to change it from "flaky" to "untrustworthy" and add a > comment. Why don't you trust an instaneously available carrier? Any reason to assume there will be false positives? Regards Patrick From oxymoron@waste.org Thu Mar 10 20:42:57 2005 Received: with ECARTIS (v1.0.0; list netdev); Thu, 10 Mar 2005 20:43:00 -0800 (PST) Received: from waste.org (waste.org [216.27.176.166]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j2B4gqIO001535 for ; Thu, 10 Mar 2005 20:42:57 -0800 Received: from waste.org (localhost [127.0.0.1]) by waste.org (8.13.2/8.13.2/Debian-1) with ESMTP id j2B4glVh031783 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Thu, 10 Mar 2005 22:42:47 -0600 Received: (from oxymoron@localhost) by waste.org (8.13.2/8.13.2/Submit) id j2B4glUB031780; Thu, 10 Mar 2005 22:42:47 -0600 Date: Thu, 10 Mar 2005 20:42:46 -0800 From: Matt Mackall To: Patrick McHardy Cc: Jeff Garzik , netdev@oss.sgi.com, Jeff Moyer Subject: Re: [PATCH 1/7] netpoll: shorten carrier detect timeout Message-ID: <20050311044246.GT3120@waste.org> References: <2.454130102@selenic.com> <422A4A38.4040303@trash.net> <20050306002015.GD3120@waste.org> <422A564D.4080809@trash.net> <20050310230117.GP3120@waste.org> <42311FF9.5010007@trash.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <42311FF9.5010007@trash.net> User-Agent: Mutt/1.5.6+20040907i X-Virus-Scanned: ClamAV 0.83/760/Wed Mar 9 09:12:01 2005 on oss.sgi.com X-Virus-Scanned: by amavisd-new X-Virus-Status: Clean X-archive-position: 2898 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: mpm@selenic.com Precedence: bulk X-list: netdev Content-Length: 908 Lines: 21 On Fri, Mar 11, 2005 at 05:35:05AM +0100, Patrick McHardy wrote: > Matt Mackall wrote: > >Ok, on closer inspection, the current logic is: the NIC reports > >carrier detect nearly instaneously and thus its carrier detect > >reporting is considered unreliable. Rather than immediately sending > >packets, we wait for some interval for it to really be up so that the > >backlog of console messages doesn't get pumped into the bit bucket. > > > >So I'm going to change it from "flaky" to "untrustworthy" and add a > >comment. > > Why don't you trust an instaneously available carrier? Any > reason to assume there will be false positives? Because I had reports of people losing all their boot messages until this logic was added (about a year ago now?). I don't remember which NICs were implicated, but some apparently report carrier is always available. -- Mathematics is the supreme nostalgia of our time. From kaber@trash.net Thu Mar 10 20:53:30 2005 Received: with ECARTIS (v1.0.0; list netdev); Thu, 10 Mar 2005 20:53:33 -0800 (PST) Received: from kaber.coreworks.de ([62.206.217.67]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j2B4rTub004150 for ; Thu, 10 Mar 2005 20:53:30 -0800 Received: from localhost ([127.0.0.1]) by kaber.coreworks.de with esmtp (Exim 4.50) id 1D9c9H-0002ac-Bb; Fri, 11 Mar 2005 05:53:19 +0100 Message-ID: <4231243C.1040001@trash.net> Date: Fri, 11 Mar 2005 05:53:16 +0100 From: Patrick McHardy User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.7.5) Gecko/20050106 Debian/1.7.5-1 X-Accept-Language: en MIME-Version: 1.0 To: Matt Mackall CC: Jeff Garzik , netdev@oss.sgi.com, Jeff Moyer Subject: Re: [PATCH 1/7] netpoll: shorten carrier detect timeout References: <2.454130102@selenic.com> <422A4A38.4040303@trash.net> <20050306002015.GD3120@waste.org> <422A564D.4080809@trash.net> <20050310230117.GP3120@waste.org> <42311FF9.5010007@trash.net> <20050311044246.GT3120@waste.org> In-Reply-To: <20050311044246.GT3120@waste.org> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV 0.83/760/Wed Mar 9 09:12:01 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 2899 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: kaber@trash.net Precedence: bulk X-list: netdev Content-Length: 745 Lines: 22 Matt Mackall wrote: > On Fri, Mar 11, 2005 at 05:35:05AM +0100, Patrick McHardy wrote: > >>>So I'm going to change it from "flaky" to "untrustworthy" and add a >>>comment. >> >>Why don't you trust an instaneously available carrier? Any >>reason to assume there will be false positives? > > > Because I had reports of people losing all their boot messages until > this logic was added (about a year ago now?). I don't remember which > NICs were implicated, but some apparently report carrier is always > available. If this problem is not common, I think it would be better to make this behaviour dependant on a boot parameter instead of forcing everyone to wait for 4s. Additionally you could have a blacklist of flaky NICs. Regards Patrick From kaber@trash.net Thu Mar 10 21:03:38 2005 Received: with ECARTIS (v1.0.0; list netdev); Thu, 10 Mar 2005 21:03:41 -0800 (PST) Received: from kaber.coreworks.de ([62.206.217.67]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j2B53bsn005120 for ; Thu, 10 Mar 2005 21:03:37 -0800 Received: from localhost ([127.0.0.1]) by kaber.coreworks.de with esmtp (Exim 4.50) id 1D9cIs-0002bh-Tq; Fri, 11 Mar 2005 06:03:14 +0100 Message-ID: <42312692.7040806@trash.net> Date: Fri, 11 Mar 2005 06:03:14 +0100 From: Patrick McHardy User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.7.5) Gecko/20050106 Debian/1.7.5-1 X-Accept-Language: en MIME-Version: 1.0 To: "David S. Miller" CC: maxk@qualcomm.com, shemminger@osdl.org, netdev@oss.sgi.com Subject: Re: Fw: [Bug 4279] New: When I try to start vpnc the net/core/skbuff.c:91 crash References: <20050303095832.6a084856@dxpl.pdx.osdl.net> <4228A354.8020904@qualcomm.com> <4228AD8F.4020000@trash.net> <20050310192023.1270fef6.davem@davemloft.net> In-Reply-To: <20050310192023.1270fef6.davem@davemloft.net> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV 0.83/760/Wed Mar 9 09:12:01 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 2900 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: kaber@trash.net Precedence: bulk X-list: netdev Content-Length: 500 Lines: 21 David S. Miller wrote: >>This check is wrong, gcc optimizes it away: >> >> if ((len -= sizeof(pi)) > len) >> return -EINVAL; >> >>This could be responsible for the BUG. If len is 2 or 3 and TUN_NO_PI >>isn't set it underflows. alloc_skb() allocates len + 2, which is 0 or >>1 byte. skb_reserve tries to reserve 2 bytes and things explode in >>skb_put. > > Good catch Patrick. > > Patch applied, thanks. The patch is also needed (and applies with fuzz) for 2.4. Regards Patrick From kostodo@gmail.com Thu Mar 10 21:51:33 2005 Received: with ECARTIS (v1.0.0; list netdev); Thu, 10 Mar 2005 21:51:39 -0800 (PST) Received: from rproxy.gmail.com (rproxy.gmail.com [64.233.170.206]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j2B5pW98011551 for ; Thu, 10 Mar 2005 21:51:32 -0800 Received: by rproxy.gmail.com with SMTP id c51so609632rne for ; Thu, 10 Mar 2005 21:51:31 -0800 (PST) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:reply-to:to:subject:cc:mime-version:content-type:content-transfer-encoding; b=LFKuXjuz53nX/Blkcrkt0s5dsugf/8i8q4MIe+U4X/1jf9PwxGVaSWuGsArKHDwvFFsZBgmM22SpkXwHq9tEc5fowqu6UVFCgHD9Y8TnKCY3Qxxl5+IfNyT76iQFYsDZ63xCDMKDmU444Ke8WngmqMUqTfAwYCid6f0l8cr8TIk= Received: by 10.38.82.51 with SMTP id f51mr2621481rnb; Thu, 10 Mar 2005 21:51:31 -0800 (PST) Received: by 10.38.208.49 with HTTP; Thu, 10 Mar 2005 21:51:31 -0800 (PST) Message-ID: Date: Fri, 11 Mar 2005 05:51:31 +0000 From: Kosta Todorovic Reply-To: Kosta Todorovic To: jgarzik@pobox.com Subject: Network card driver problem (znb.o/tulip) Cc: tulip-users@lists.sourceforge.net, netdev@oss.sgi.com Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV 0.83/760/Wed Mar 9 09:12:01 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 2901 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: kostodo@gmail.com Precedence: bulk X-list: netdev Content-Length: 1771 Lines: 46 My company has recently purchased several ZNYX ZX274 network cards. These cards are Four Channel, 10/100 PCI Adapters. They use Intel chipsets. Unfortunately there exists no drivers for linux amd64 architecture. There are 32bit drivers found at: http://www.znyx.com/support/drivers/ZX374_drivers.htm but naturally they wont compile under my amd64 system. The driver itself is called znb.o and can be downloaded from ZNYX's website. I spoke to support staff there but they told me they have discontinued support and development for this series of cards. The system I am running gentoo and have tried both 2.4.x and 2.6.x kernels but no luck. Unfortunately there is NO 64bit drivers available for ANY platform. not even MS. Does anyone know of a customised znb.o driver built for amd64? Is there any chance of anyone modifying the source code of the driver to compile under a amd64 system? I've noticed that "tulip" drivers get loaded as a module at boot time. but they dont function correctly. (lets you start the device and attach ips but cant talk through it) Is there any variants of the tulip driver that will work for this? Help much appreciated. /proc/pci extract for network cards: Bus 5, device 5, function 0: Ethernet controller: Digital Equipment Corporation DECchip 21142/43 (#30) (rev 65). IRQ 30. Master Capable. Latency=128. Min Gnt=20.Max Lat=40. I/O at 0x0 [0x7f]. Non-prefetchable 32 bit memory at 0xfa1ff400 [0xfa1ff7ff]. Bus 5, device 4, function 0: Ethernet controller: Digital Equipment Corporation DECchip 21142/43 (#29) (rev 65). IRQ 29. Master Capable. No bursts. Min Gnt=20.Max Lat=40. I/O at 0x0 [0x7f]. Non-prefetchable 32 bit memory at 0xf9f00000 [0xf9f003ff]. From greearb@candelatech.com Thu Mar 10 22:00:30 2005 Received: with ECARTIS (v1.0.0; list netdev); Thu, 10 Mar 2005 22:00:36 -0800 (PST) Received: from www.lanforge.com (ns1.lanforge.com [66.165.47.210]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j2B60UO9012562 for ; Thu, 10 Mar 2005 22:00:30 -0800 Received: from [4.33.45.22] (evrtwa1-ar2-4-33-045-022.evrtwa1.dsl-verizon.net [4.33.45.22]) (authenticated bits=0) by www.lanforge.com (8.12.8/8.12.8) with ESMTP id j2B6NnLH028472; Thu, 10 Mar 2005 22:23:49 -0800 Message-ID: <423133F7.7040400@candelatech.com> Date: Thu, 10 Mar 2005 22:00:23 -0800 From: Ben Greear Organization: Candela Technologies User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.7.3) Gecko/20041020 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Kosta Todorovic CC: jgarzik@pobox.com, tulip-users@lists.sourceforge.net, netdev@oss.sgi.com Subject: Re: Network card driver problem (znb.o/tulip) References: In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV 0.83/760/Wed Mar 9 09:12:01 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 2902 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: greearb@candelatech.com Precedence: bulk X-list: netdev Content-Length: 1566 Lines: 41 Kosta Todorovic wrote: > My company has recently purchased several ZNYX ZX274 network cards. > These cards are Four Channel, 10/100 PCI Adapters. They use Intel chipsets. > > Unfortunately there exists no drivers for linux amd64 architecture. > There are 32bit drivers found at: > http://www.znyx.com/support/drivers/ZX374_drivers.htm but naturally > they wont compile under my amd64 system. > > The driver itself is called znb.o and can be downloaded from ZNYX's > website. I spoke to support staff there but they told me they have > discontinued support and development for this series of cards. > > The system I am running gentoo and have tried both 2.4.x and 2.6.x > kernels but no luck. > > Unfortunately there is NO 64bit drivers available for ANY platform. not even MS. > > Does anyone know of a customised znb.o driver built for amd64? > Is there any chance of anyone modifying the source code of the driver > to compile under a amd64 system? > > I've noticed that "tulip" drivers get loaded as a module at boot time. > but they dont function correctly. (lets you start the device and > attach ips but cant talk through it) > > Is there any variants of the tulip driver that will work for this? > > Help much appreciated. My personal opinion is that those NICs suck. I never did get mine to work. I'd suggest getting a DFE-570tx if you can find it, or perhaps a p430tx. You can also get 4-port GigE NICs from Intel for around $400 these days... Ben -- Ben Greear Candela Technologies Inc http://www.candelatech.com From kostodo@gmail.com Thu Mar 10 22:08:44 2005 Received: with ECARTIS (v1.0.0; list netdev); Thu, 10 Mar 2005 22:08:49 -0800 (PST) Received: from rproxy.gmail.com (rproxy.gmail.com [64.233.170.193]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j2B68hi7013201 for ; Thu, 10 Mar 2005 22:08:44 -0800 Received: by rproxy.gmail.com with SMTP id c51so611399rne for ; Thu, 10 Mar 2005 22:08:43 -0800 (PST) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:reply-to:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:references; b=nZFY4K+Vz3FeukCOn8F4elA8Rx4x0xh4rquWDz/m3Zy42Uf9NaqrCSG3fCzM8EaE/rD9ufd3jVoMrBYNobIR832GiwxVuKsws8wmE+HpeW6OOnuQbzzV5U+H8oLBDzfnZCunBqv6doKdcmOKLf87cP2daSI4HQnrhHHmVQPdjHI= Received: by 10.38.208.65 with SMTP id f65mr2636956rng; Thu, 10 Mar 2005 22:08:43 -0800 (PST) Received: by 10.38.208.49 with HTTP; Thu, 10 Mar 2005 22:08:43 -0800 (PST) Message-ID: Date: Fri, 11 Mar 2005 06:08:43 +0000 From: Kosta Todorovic Reply-To: Kosta Todorovic To: Ben Greear Subject: Re: Network card driver problem (znb.o/tulip) Cc: jgarzik@pobox.com, tulip-users@lists.sourceforge.net, netdev@oss.sgi.com In-Reply-To: <423133F7.7040400@candelatech.com> Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit References: <423133F7.7040400@candelatech.com> X-Virus-Scanned: ClamAV 0.83/760/Wed Mar 9 09:12:01 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 2903 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: kostodo@gmail.com Precedence: bulk X-list: netdev Content-Length: 1802 Lines: 50 Its not really an option to exchange network cards. Any other suggestions? On Thu, 10 Mar 2005 22:00:23 -0800, Ben Greear wrote: > Kosta Todorovic wrote: > > My company has recently purchased several ZNYX ZX274 network cards. > > These cards are Four Channel, 10/100 PCI Adapters. They use Intel chipsets. > > > > Unfortunately there exists no drivers for linux amd64 architecture. > > There are 32bit drivers found at: > > http://www.znyx.com/support/drivers/ZX374_drivers.htm but naturally > > they wont compile under my amd64 system. > > > > The driver itself is called znb.o and can be downloaded from ZNYX's > > website. I spoke to support staff there but they told me they have > > discontinued support and development for this series of cards. > > > > The system I am running gentoo and have tried both 2.4.x and 2.6.x > > kernels but no luck. > > > > Unfortunately there is NO 64bit drivers available for ANY platform. not even MS. > > > > Does anyone know of a customised znb.o driver built for amd64? > > Is there any chance of anyone modifying the source code of the driver > > to compile under a amd64 system? > > > > I've noticed that "tulip" drivers get loaded as a module at boot time. > > but they dont function correctly. (lets you start the device and > > attach ips but cant talk through it) > > > > Is there any variants of the tulip driver that will work for this? > > > > Help much appreciated. > > My personal opinion is that those NICs suck. I never did get mine > to work. I'd suggest getting a DFE-570tx if you can find it, or > perhaps a p430tx. You can also get 4-port GigE NICs from Intel for > around $400 these days... > > Ben > > -- > Ben Greear > Candela Technologies Inc http://www.candelatech.com > > From util@deuroconsult.ro Thu Mar 10 23:01:52 2005 Received: with ECARTIS (v1.0.0; list netdev); Thu, 10 Mar 2005 23:01:58 -0800 (PST) Received: from webhosting.rdsbv.ro (webhosting.rdsbv.ro [213.157.185.164]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j2B71mjr018203 for ; Thu, 10 Mar 2005 23:01:51 -0800 Received: from webhosting.rdsbv.ro (localhost [127.0.0.1]) by webhosting.rdsbv.ro (8.13.3/8.13.3) with ESMTP id j2B71VIa024846 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 11 Mar 2005 09:01:31 +0200 Received: from localhost (util@localhost) by webhosting.rdsbv.ro (8.13.3/8.13.3/Submit) with ESMTP id j2B71V2D024843; Fri, 11 Mar 2005 09:01:31 +0200 X-Authentication-Warning: webhosting.rdsbv.ro: util owned process doing -bs Date: Fri, 11 Mar 2005 09:01:31 +0200 (EET) From: "Catalin(ux aka Dino) BOIE" X-X-Sender: util@webhosting.rdsbv.ro To: Jamal Hadi Salim cc: Stephen Hemminger , "David S. Miller" , netdev@oss.sgi.com Subject: Re: [PATCH] move tc_u32_mark into pkt_cls.h In-Reply-To: <1110481248.1074.306.camel@jzny.localdomain> Message-ID: References: <20050310104207.1d74ac00@dxpl.pdx.osdl.net> <1110481248.1074.306.camel@jzny.localdomain> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Virus-Scanned: ClamAV 0.83/760/Wed Mar 9 09:12:01 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 2904 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: util@deuroconsult.ro Precedence: bulk X-list: netdev Content-Length: 1917 Lines: 80 On Thu, 10 Mar 2005, Jamal Hadi Salim wrote: > > Agreed on both counts. > > Note, however, the tc_u32_mark should die Real Soon Now given the > meta match patches that are in from Thomas. It can die, but there are users that use it. So, I think that as long as u32 will stay in kernel, we can let mark_in_u32 live. It's a small modification and I think it may stay. Thank you. > cheers, > jamal > > > On Thu, 2005-03-10 at 13:42, Stephen Hemminger wrote: >> The tc_u32_mark structure is used as part of the netlink message >> from the user API to the kernel, so it needs to be moved to include/linux/pkt_cls.h >> and have types changed from u32 to __u32. >> >> Also, the definition of u32 performance counters doesn't need to depend >> on the config option. The definition can exist even if the code isn't >> enabled. >> >> Signed-off-by: Stephen Hemminger >> >> diff -Nru a/include/linux/pkt_cls.h b/include/linux/pkt_cls.h >> --- a/include/linux/pkt_cls.h 2005-03-10 10:36:39 -08:00 >> +++ b/include/linux/pkt_cls.h 2005-03-10 10:36:39 -08:00 >> @@ -221,14 +221,20 @@ >> struct tc_u32_key keys[0]; >> }; >> >> -#ifdef CONFIG_CLS_U32_PERF >> +struct tc_u32_mark >> +{ >> + __u32 val; >> + __u32 mask; >> + __u32 success; >> +}; >> + >> struct tc_u32_pcnt >> { >> __u64 rcnt; >> __u64 rhit; >> __u64 kcnts[0]; >> }; >> -#endif >> + >> /* Flags */ >> >> #define TC_U32_TERMINAL 1 >> diff -Nru a/net/sched/cls_u32.c b/net/sched/cls_u32.c >> --- a/net/sched/cls_u32.c 2005-03-10 10:36:39 -08:00 >> +++ b/net/sched/cls_u32.c 2005-03-10 10:36:39 -08:00 >> @@ -58,14 +58,6 @@ >> #include >> #include >> >> - >> -struct tc_u32_mark >> -{ >> - u32 val; >> - u32 mask; >> - u32 success; >> -}; >> - >> struct tc_u_knode >> { >> struct tc_u_knode *next; > > --- Catalin(ux aka Dino) BOIE catab at deuroconsult.ro http://kernel.umbrella.ro/ From dtor_core@ameritech.net Thu Mar 10 23:23:35 2005 Received: with ECARTIS (v1.0.0; list netdev); Thu, 10 Mar 2005 23:23:39 -0800 (PST) Received: from smtp806.mail.sc5.yahoo.com (smtp806.mail.sc5.yahoo.com [66.163.168.185]) by oss.sgi.com (8.13.0/8.13.0) with SMTP id j2B7NZ7C019580 for ; Thu, 10 Mar 2005 23:23:35 -0800 Received: from unknown (HELO core.corenet.prv) (dtor?core@ameritech.net@68.253.44.57 with plain) by smtp806.mail.sc5.yahoo.com with SMTP; 11 Mar 2005 07:23:34 -0000 From: Dmitry Torokhov To: netdev@oss.sgi.com Subject: Last night Linus bk - netfilter busted? Date: Fri, 11 Mar 2005 02:23:34 -0500 User-Agent: KMail/1.7.2 Cc: LKML MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200503110223.34461.dtor_core@ameritech.net> X-Virus-Scanned: ClamAV 0.83/760/Wed Mar 9 09:12:01 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 2905 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: dtor_core@ameritech.net Precedence: bulk X-list: netdev Content-Length: 226 Lines: 10 Hi, My box gets stuck while booting (actually starting ntpd) whith tonight pull from Linus. It looks like it is spinning in ipt_do_table when I do SysRq-P. No call trace though. Anyone else seeing it? Any ideas? -- Dmitry From buytenh@wantstofly.org Fri Mar 11 00:55:40 2005 Received: with ECARTIS (v1.0.0; list netdev); Fri, 11 Mar 2005 00:55:44 -0800 (PST) Received: from xi.wantstofly.org (alephnull.demon.nl [212.238.201.82]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j2B8teWO010715 for ; Fri, 11 Mar 2005 00:55:40 -0800 Received: by xi.wantstofly.org (Postfix, from userid 500) id B63C62B0EC; Fri, 11 Mar 2005 09:55:39 +0100 (MET) Date: Fri, 11 Mar 2005 09:55:39 +0100 From: Lennert Buytenhek To: Jon Mason Cc: Ben Greear , Ganesh Venkatesan , "netdev@oss.sgi.com" Subject: Re: ethtool -d no longer works for e1000 Message-ID: <20050311085539.GB3253@xi.wantstofly.org> References: <422F6C37.8090202@candelatech.com> <5fc59ff3050309140910f3e492@mail.gmail.com> <422F822D.9010707@candelatech.com> <200503091713.55454.jdmason@us.ibm.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200503091713.55454.jdmason@us.ibm.com> User-Agent: Mutt/1.4.1i X-Virus-Scanned: ClamAV 0.83/760/Wed Mar 9 09:12:01 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 2907 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: buytenh@wantstofly.org Precedence: bulk X-list: netdev Content-Length: 151 Lines: 8 On Wed, Mar 09, 2005 at 05:13:55PM -0600, Jon Mason wrote: > Cononical form indicator: disabled Shouldn't this be 'Canonical' ? --L From buytenh@wantstofly.org Fri Mar 11 00:54:59 2005 Received: with ECARTIS (v1.0.0; list netdev); Fri, 11 Mar 2005 00:55:08 -0800 (PST) Received: from xi.wantstofly.org (alephnull.demon.nl [212.238.201.82]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j2B8svnX010632 for ; Fri, 11 Mar 2005 00:54:59 -0800 Received: by xi.wantstofly.org (Postfix, from userid 500) id 9D3A22B0EC; Fri, 11 Mar 2005 09:54:56 +0100 (MET) Date: Fri, 11 Mar 2005 09:54:56 +0100 From: Lennert Buytenhek To: Ben Greear Cc: Jon Mason , Ganesh Venkatesan , "netdev@oss.sgi.com" Subject: Re: ethtool -d no longer works for e1000 Message-ID: <20050311085456.GA3253@xi.wantstofly.org> References: <422F6C37.8090202@candelatech.com> <5fc59ff3050309140910f3e492@mail.gmail.com> <422F822D.9010707@candelatech.com> <200503091713.55454.jdmason@us.ibm.com> <422F8737.7050002@candelatech.com> <422F89CB.2070705@candelatech.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <422F89CB.2070705@candelatech.com> User-Agent: Mutt/1.4.1i X-Virus-Scanned: ClamAV 0.83/760/Wed Mar 9 09:12:01 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 2906 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: buytenh@wantstofly.org Precedence: bulk X-list: netdev Content-Length: 1108 Lines: 38 On Wed, Mar 09, 2005 at 03:42:03PM -0800, Ben Greear wrote: > >>I don't see this problem at all on my 2.6.11-rc4-mm1 kernel (Athlon64 > >>proc). > > > >I think I see the problem. ethtool -d eth0 works for me, > >but ethtool -d eth1 does not, even with both are e1000 > >NICs. It appears it cannot handle reading the second NIC for > >some reason? > > Errr, my bad. The problem is more that the dual-port pro/1000 NICs > don't seem to work, but the built-in e1000s do. > > The chipset that does not work correctly is: 82546GB > > The NICs with chipset: 82541EI seem to work just fine. "Me too." Works fine: 82540EM (SE7505VB2 on-board e1000) Doesn't work: 82546GB (dual port e1000 server NIC) [root@phi ~]# uname -a Linux phi.wantstofly.org 2.6.10-1.766_FC3smp #1 SMP Wed Feb 9 23:21:37 EST 2005 i686 i686 i386 GNU/Linux [root@phi ~]# ethtool -d eth1 Cannot dump registers: Success [root@phi ~]# ethtool -d eth2 Cannot dump registers: Success [root@phi ~]# ethtool -d eth3 | head -3 MAC Registers ------------- 0x00000: CTRL (Device control register) 0x003C0249 Nothing appears in syslog. --L From itkes@fat.imec.msu.ru Fri Mar 11 03:27:54 2005 Received: with ECARTIS (v1.0.0; list netdev); Fri, 11 Mar 2005 03:27:58 -0800 (PST) Received: from fat.imec.msu.ru (postfix@fat.imec.msu.ru [193.232.114.64]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j2BBRq8x024683 for ; Fri, 11 Mar 2005 03:27:53 -0800 Received: from mx.imec.msu.ru (localhost.localdomain [127.0.0.1]) by fat.imec.msu.ru (Postfix) with ESMTP id A58002CF for ; Fri, 11 Mar 2005 14:27:50 +0300 (MSK) Received: from 80.249.146.228 (SquirrelMail authenticated user itkes) by mx.imec.msu.ru with HTTP; Fri, 11 Mar 2005 14:27:50 +0300 (MSK) Message-ID: <1047.80.249.146.228.1110540470.squirrel@mx.imec.msu.ru> Date: Fri, 11 Mar 2005 14:27:50 +0300 (MSK) Subject: A bug in the Kernel? From: itkes@fat.imec.msu.ru To: netdev@oss.sgi.com User-Agent: SquirrelMail/1.4.4 MIME-Version: 1.0 Content-Type: multipart/mixed;boundary="----=_20050311142750_20323" X-Priority: 3 (Normal) Importance: Normal X-Virus-Scanned: ClamAV 0.83/760/Wed Mar 9 09:12:01 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 2908 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: itkes@fat.imec.msu.ru Precedence: bulk X-list: netdev Content-Length: 11226 Lines: 417 ------=_20050311142750_20323 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit Hello. I think, I have found a bug in the Linux Kernel. It is caused by working with lists by indexes in such operstions as routing tables dump and routing rules dump (functions fib_rules_dump in fib_rules.c and a few dump functions in fib_hash.c). If some elements are removed form the list, the index may identify not the element it identified earlier. As a result, there may happen that an application that requested the routes or rules dump, will not receive the entire table. There is how to make an application to lose some rules. 1. Add 150 rules to kernel table. 2. Application A sends an RTM_GETRULE message with flag NLM_F_DUMP. The kernel puts first 107 rules to the buffer. 3. Application B deletes first 20 rules. 4. Application A receives the first couple of data from kernel. The kernel puts next couple of rules to the buffer, begining from 108-th rule, that was 128-th earlier. As a result, 20 rules had not been sent to the application, without being deleted or modified during the dump operation. Routes can be lost, too, if you add certain 5000 routes, request their dump and remove 1000 from them during the dump. In the patch (against kernel 2.6.11) attached, I have corrected these bugs. In the modified kernel, both dumps of routes and routing rules seems to work properly. But, I think, there can be other bugs similar to this in other dump operations. Alex Itkes. ------=_20050311142750_20323 Content-Type: text/plain; name="patch-2.6.11-nl01" Content-Transfer-Encoding: 8bit Content-Disposition: attachment; filename="patch-2.6.11-nl01" diff -urN linux-2.6.11/include/linux/netlink.h linux-2.6.11-nl01/include/linux/netlink.h --- linux-2.6.11/include/linux/netlink.h 2005-03-02 23:04:19.000000000 +0300 +++ linux-2.6.11-nl01/include/linux/netlink.h 2005-03-08 15:03:11.000000000 +0300 @@ -145,9 +145,11 @@ int (*dump)(struct sk_buff * skb, struct netlink_callback *cb); int (*done)(struct netlink_callback *cb); int family; - long args[4]; + long args[5]; }; +#define NLCB_ZERO(cb_,k_) memset((cb_)->args+(k_),0,sizeof((cb_)->args)-(k_)*sizeof((cb_)->args[0])) + struct netlink_notify { int pid; diff -urN linux-2.6.11/net/core/rtnetlink.c linux-2.6.11-nl01/net/core/rtnetlink.c --- linux-2.6.11/net/core/rtnetlink.c 2005-03-02 23:04:21.000000000 +0300 +++ linux-2.6.11-nl01/net/core/rtnetlink.c 2005-03-08 17:27:28.000000000 +0300 @@ -425,7 +425,7 @@ rtnetlink_links[idx][type].dumpit == NULL) continue; if (idx > s_idx) - memset(&cb->args[0], 0, sizeof(cb->args)); + NLCB_ZERO(cb,0); if (rtnetlink_links[idx][type].dumpit(skb, cb)) break; } diff -urN linux-2.6.11/net/ipv4/fib_frontend.c linux-2.6.11-nl01/net/ipv4/fib_frontend.c --- linux-2.6.11/net/ipv4/fib_frontend.c 2005-03-02 23:04:21.000000000 +0300 +++ linux-2.6.11-nl01/net/ipv4/fib_frontend.c 2005-03-08 17:33:40.000000000 +0300 @@ -347,7 +347,7 @@ for (t=s_t; t<=RT_TABLE_MAX; t++) { if (t < s_t) continue; if (t > s_t) - memset(&cb->args[1], 0, sizeof(cb->args)-sizeof(cb->args[0])); + NLCB_ZERO(cb,1); if ((tb = fib_get_table(t))==NULL) continue; if (tb->tb_dump(tb, skb, cb) < 0) diff -urN linux-2.6.11/net/ipv4/fib_hash.c linux-2.6.11-nl01/net/ipv4/fib_hash.c --- linux-2.6.11/net/ipv4/fib_hash.c 2005-03-02 23:04:21.000000000 +0300 +++ linux-2.6.11-nl01/net/ipv4/fib_hash.c 2005-03-08 17:37:28.000000000 +0300 @@ -52,6 +52,9 @@ struct hlist_node fn_hash; struct list_head fn_alias; u32 fn_key; + + u32 fn_nl_links; + u8 fn_nl_dead; }; struct fn_zone { @@ -256,7 +259,7 @@ head = &fz->fz_hash[fn_hash(k, fz)]; hlist_for_each_entry(f, node, head, fn_hash) { - if (f->fn_key != k) + if (f->fn_key != k || f->fn_nl_dead) continue; err = fib_semantic_match(&f->fn_alias, @@ -296,8 +299,14 @@ hlist_for_each_entry(f, node, &fz->fz_hash[0], fn_hash) { struct fib_alias *fa; + if(f->fn_nl_dead){ + continue; + }; list_for_each_entry(fa, &f->fn_alias, fa_list) { struct fib_info *next_fi = fa->fa_info; + if (fa->fa_nl_dead){ + continue; + }; if (fa->fa_scope != res->scope || fa->fa_type != RTN_UNICAST) @@ -497,6 +506,8 @@ INIT_HLIST_NODE(&new_f->fn_hash); INIT_LIST_HEAD(&new_f->fn_alias); new_f->fn_key = key; + new_f->fn_nl_links=0; + new_f->fn_nl_dead=0; f = new_f; } @@ -506,6 +517,8 @@ new_fa->fa_scope = r->rtm_scope; new_fa->fa_state = 0; + new_fa->fa_nl_links=0; + new_fa->fa_nl_dead=0; /* * Insert new entry to the list. */ @@ -591,8 +604,17 @@ int kill_fn; fa = fa_to_delete; + if(fa->fa_nl_dead){ + tb->tb_flush(tb); + return -ESRCH; + }; rtmsg_fib(RTM_DELROUTE, key, fa, z, tb->tb_id, n, req); - + + if(fa->fa_nl_links){ + fa->fa_nl_dead=1; + tb->tb_flush(tb); + return 0; + }; kill_fn = 0; write_lock_bh(&fib_hash_lock); list_del(&fa->fa_list); @@ -630,7 +652,7 @@ list_for_each_entry_safe(fa, fa_node, &f->fn_alias, fa_list) { struct fib_info *fi = fa->fa_info; - if (fi && (fi->fib_flags&RTNH_F_DEAD)) { + if ((fi && (fi->fib_flags&RTNH_F_DEAD))||(fa->fa_nl_dead&&(fa->fa_nl_links==0))) { write_lock_bh(&fib_hash_lock); list_del(&fa->fa_list); if (list_empty(&f->fn_alias)) { @@ -675,17 +697,42 @@ { struct hlist_node *node; struct fib_node *f; - int i, s_i; - - s_i = cb->args[3]; - i = 0; + int flag1=0; + int flag2=0; + + if(cb->args[3]==0){ + flag1=1; + }; hlist_for_each_entry(f, node, head, fn_hash) { struct fib_alias *fa; + if(flag1==0){ + if((long)(f)==cb->args[3]){ + --(f->fn_nl_links); + flag1=1; + }else{ + continue; + }; + }; + if(cb->args[4]==0){ + flag2=1; + }; + if(f->fn_nl_dead){ + continue; + }; list_for_each_entry(fa, &f->fn_alias, fa_list) { - if (i < s_i) - goto next; + if(flag2==0){ + if((long)(fa)==cb->args[4]){ + --(fa->fa_nl_links); + flag2=1; + }else{ + continue; + }; + }; + if(fa->fa_nl_dead){ + continue; + }; if (fib_dump_info(skb, NETLINK_CB(cb->skb).pid, cb->nlh->nlmsg_seq, RTM_NEWROUTE, @@ -696,14 +743,16 @@ fz->fz_order, fa->fa_tos, fa->fa_info) < 0) { - cb->args[3] = i; + ++(fa->fa_nl_links); + ++(f->fn_nl_links); + cb->args[4]=(long)(fa); + cb->args[3]=(long)(f); return -1; } - next: - i++; } } - cb->args[3] = i; + cb->args[4]=0; + cb->args[3]=0; return skb->len; } @@ -718,8 +767,7 @@ for (h=0; h < fz->fz_divisor; h++) { if (h < s_h) continue; if (h > s_h) - memset(&cb->args[3], 0, - sizeof(cb->args) - 3*sizeof(cb->args[0])); + NLCB_ZERO(cb,3); if (fz->fz_hash == NULL || hlist_empty(&fz->fz_hash[h])) continue; @@ -734,25 +782,27 @@ static int fn_hash_dump(struct fib_table *tb, struct sk_buff *skb, struct netlink_callback *cb) { - int m, s_m; struct fn_zone *fz; struct fn_hash *table = (struct fn_hash*)tb->tb_data; - s_m = cb->args[1]; read_lock(&fib_hash_lock); - for (fz = table->fn_zone_list, m=0; fz; fz = fz->fz_next, m++) { - if (m < s_m) continue; - if (m > s_m) - memset(&cb->args[2], 0, - sizeof(cb->args) - 2*sizeof(cb->args[0])); + if(cb->args[1]){ + fz=(struct fn_zone*)(cb->args[1]); + }else{ + fz=table->fn_zone_list; + }; + for (; fz; fz = fz->fz_next) { + if((long)(fz)!=cb->args[1]){ + NLCB_ZERO(cb,2); + }; if (fn_hash_dump_zone(skb, cb, tb, fz) < 0) { - cb->args[1] = m; + cb->args[1] = (long)(fz); read_unlock(&fib_hash_lock); return -1; } } read_unlock(&fib_hash_lock); - cb->args[1] = m; + cb->args[1] = 0; return skb->len; } diff -urN linux-2.6.11/net/ipv4/fib_lookup.h linux-2.6.11-nl01/net/ipv4/fib_lookup.h --- linux-2.6.11/net/ipv4/fib_lookup.h 2005-03-02 23:04:21.000000000 +0300 +++ linux-2.6.11-nl01/net/ipv4/fib_lookup.h 2005-03-08 12:51:36.000000000 +0300 @@ -12,6 +12,9 @@ u8 fa_type; u8 fa_scope; u8 fa_state; + + u32 fa_nl_links; + u8 fa_nl_dead; }; #define FA_S_ACCESSED 0x01 diff -urN linux-2.6.11/net/ipv4/fib_rules.c linux-2.6.11-nl01/net/ipv4/fib_rules.c --- linux-2.6.11/net/ipv4/fib_rules.c 2005-03-02 23:04:21.000000000 +0300 +++ linux-2.6.11-nl01/net/ipv4/fib_rules.c 2005-03-08 17:33:25.000000000 +0300 @@ -74,6 +74,9 @@ #endif char r_ifname[IFNAMSIZ]; int r_dead; + + u32 r_nl_links; + u8 r_nl_dead; }; static struct fib_rule default_rule = { @@ -101,6 +104,28 @@ static struct fib_rule *fib_rules = &local_rule; static DEFINE_RWLOCK(fib_rules_lock); +static void nl_rules_flush(void) +{ + struct fib_rule *r, **rp; + + for(rp=&fib_rules;(r=*rp)!=NULL;rp=&r->r_next){ + next:; + if(r->r_nl_dead&&(r->r_nl_links==0)){ + write_lock_bh(&fib_rules_lock); + *rp = r->r_next; + r->r_dead = 1; + write_unlock_bh(&fib_rules_lock); + fib_rule_put(r); + r=*rp; + if(r==0){ + return; + }else{ + goto next; + }; + }; + }; +} + int inet_rtm_delrule(struct sk_buff *skb, struct nlmsghdr* nlh, void *arg) { struct rtattr **rta = arg; @@ -121,10 +146,18 @@ (!rta[RTA_PRIORITY-1] || memcmp(RTA_DATA(rta[RTA_PRIORITY-1]), &r->r_preference, 4) == 0) && (!rta[RTA_IIF-1] || rtattr_strcmp(rta[RTA_IIF-1], r->r_ifname) == 0) && (!rtm->rtm_table || (r && rtm->rtm_table == r->r_table))) { + if(r->r_nl_dead==1){ + nl_rules_flush(); + break; + }; err = -EPERM; if (r == &local_rule) break; - + if(r->r_nl_links!=0){ + r->r_nl_dead=1; + nl_rules_flush(); + return 0; + }; write_lock_bh(&fib_rules_lock); *rp = r->r_next; r->r_dead = 1; @@ -198,6 +231,8 @@ new_r->r_srcmask = inet_make_mask(rtm->rtm_src_len); new_r->r_dstmask = inet_make_mask(rtm->rtm_dst_len); new_r->r_tos = rtm->rtm_tos; + new_r->r_nl_links=0; + new_r->r_nl_dead=0; #ifdef CONFIG_IP_ROUTE_FWMARK if (rta[RTA_PROTOINFO-1]) memcpy(&new_r->r_fwmark, RTA_DATA(rta[RTA_PROTOINFO-1]), 4); @@ -293,6 +328,9 @@ NIPQUAD(flp->fl4_dst), NIPQUAD(flp->fl4_src)); read_lock(&fib_rules_lock); for (r = fib_rules; r; r=r->r_next) { + if(r->r_nl_dead){ + continue; + }; if (((saddr^r->r_src) & r->r_srcmask) || ((daddr^r->r_dst) & r->r_dstmask) || (r->r_tos && r->r_tos != flp->fl4_tos) || @@ -414,19 +452,30 @@ int inet_dump_rules(struct sk_buff *skb, struct netlink_callback *cb) { - int idx; - int s_idx = cb->args[0]; struct fib_rule *r; - + + if(cb->args[0]==(-1)){ + return 0; + }; read_lock(&fib_rules_lock); - for (r=fib_rules, idx=0; r; r = r->r_next, idx++) { - if (idx < s_idx) - continue; - if (inet_fill_rule(skb, r, cb) < 0) - break; + if(cb->args[0]){ + r=(struct fib_rule*)(cb->args[0]); + --(r->r_nl_links); + }else{ + r=fib_rules; + }; + for (; r; r = r->r_next) { + if(r->r_nl_dead){ + continue; + }; + if (inet_fill_rule(skb, r, cb) < 0){ + ++(r->r_nl_links); + cb->args[0]=(long)(r); + return skb->len; + }; } + cb->args[0]=(-1); read_unlock(&fib_rules_lock); - cb->args[0] = idx; return skb->len; } ------=_20050311142750_20323-- From Petri.Passila@vtt.fi Fri Mar 11 03:35:26 2005 Received: with ECARTIS (v1.0.0; list netdev); Fri, 11 Mar 2005 03:35:31 -0800 (PST) Received: from mailgw5.vtt.fi (mailgw5.vtt.fi [130.188.1.19]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j2BBZOaw025365 for ; Fri, 11 Mar 2005 03:35:26 -0800 Received: from elemail.ele.vtt.fi (localhost [127.0.0.1]) by mailgw5.vtt.fi (8.12.11/8.12.11) with ESMTP id j2BBZCwK003439 for ; Fri, 11 Mar 2005 13:35:13 +0200 (EET) Received: from OULKV1K176.elemail.ele.vtt.fi (ele3128.ele.vtt.fi [130.188.93.128]) by elemail.ele.vtt.fi (8.9.1a/8.9.1) with ESMTP id NAA12128 for ; Fri, 11 Mar 2005 13:35:08 +0200 (EET) Message-Id: <5.1.0.14.2.20050311133309.00ab5f10@elemail.ele.vtt.fi> X-Sender: elepjp@elemail.ele.vtt.fi X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Fri, 11 Mar 2005 13:34:39 +0200 To: netdev@oss.sgi.com From: Petri Passila Subject: UDP Lite Implementation Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Virus-Scanned: ClamAV 0.83/760/Wed Mar 9 09:12:01 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 2909 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: Petri.Passila@vtt.fi Precedence: bulk X-list: netdev Content-Length: 1058 Lines: 35 Hello ! I am doing my bachelors thesis here in Recearch center of Finland (VTT Electronics) in Oulu. The meaning of the thesis is to compare UDP and UDP Lite using multimedia streaming. The part of my job is to implement UDP Lite into the Linux protocol stack (or FreeBSDs). And I have encountered some difficulties during my way. I am investigating the operation of the Linux protocol stack and the udp.c file tells that you are the athors for the UDP. And I am courious to know if you might know something about implementing the UDP Lite. So I wonder if you could possibly help me in my thesis. If you had some information about porting, which could help me, or the whole implementation I would be grateful to hear about it. Or, do you know someone who might know about the issue? Our platform is constructed of a FreeBSD 5.1 and Linux RH9 (kernel 2.4.20) machine(s). Sincerely yours Petri Passila VTT Electronics Telecommunication Systems Wireless Services group Work Tel. 040-5425526 GSM +35840-731 0109 mail: petri.passila@vtt.fi From cat@zip.com.au Fri Mar 11 04:17:54 2005 Received: with ECARTIS (v1.0.0; list netdev); Fri, 11 Mar 2005 04:18:03 -0800 (PST) Received: from theirongiant.lochness.weebeastie.net (nessie.weebeastie.net [220.233.7.36]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j2BCHraC027767 for ; Fri, 11 Mar 2005 04:17:54 -0800 Received: from theirongiant.lochness.weebeastie.net (localhost.localdomain [127.0.0.1]) by theirongiant.lochness.weebeastie.net (8.13.3/8.13.3/Debian-6) with ESMTP id j2BCH83K032633; Fri, 11 Mar 2005 23:17:08 +1100 Received: (from hogarth@localhost) by theirongiant.lochness.weebeastie.net (8.13.3/8.13.3/Submit) id j2BCGtmi032624; Fri, 11 Mar 2005 23:16:55 +1100 X-Authentication-Warning: theirongiant.lochness.weebeastie.net: hogarth set sender to cat@zip.com.au using -f Date: Fri, 11 Mar 2005 23:16:55 +1100 From: CaT To: linux-kernel@vger.kernel.org Cc: netdev@oss.sgi.com, pekkas@netcore.fi, yoshfuji@linux-ipv6.org Subject: ipv6 and ipv4 interaction weirdness Message-ID: <20050311121655.GE14146@zip.com.au> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Organisation: Furball Inc. User-Agent: Mutt/1.5.6+20040907i X-Virus-Scanned: ClamAV 0.83/760/Wed Mar 9 09:12:01 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 2910 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: cat@zip.com.au Precedence: bulk X-list: netdev Content-Length: 1041 Lines: 22 I just had some issues with ssh and trying to get it to bind to all ipv6 and ipv4 addresses to it via :: and 0.0.0.0. The problem was that it'd only let one succeed. If 0.0.0.0:22 was successful then :: port 22 could not happen and neither could my ipv6 addy port 22 as it would get the 'address already in use' error from bind(). The reverse was also true. If it bound to :: port 22 then 0.0.0.0:22 would fail. On the other hand if I got it to bind to each address individually then both ipv4 (2 addresses) and ipv6 (1 address) binds would succeed. Maybe I'm just looking at it wrong but shouldn't ipv4 and ipv6 interfere with each other? I'm using kernel 2.6.11-ac2 with OpenSSH_3.8.1p1 Debian-8.sarge.4, OpenSSL 0.9.7e 25 Oct 2004 and glibc 2.3.2 (debian version 2.3.2.ds1-20). -- "It goes against the grain of modern education to teach children to program. What fun is there in making plans, acquiring discipline in organising thoughts, devoting attention to detail and learning to be self-critical?" -- Alan Perlis From hadi@cyberus.ca Fri Mar 11 04:31:46 2005 Received: with ECARTIS (v1.0.0; list netdev); Fri, 11 Mar 2005 04:31:53 -0800 (PST) Received: from mx03.cybersurf.com (mx03.cybersurf.com [209.197.145.106]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j2BCVjRM032180 for ; Fri, 11 Mar 2005 04:31:46 -0800 Received: from mail.cyberus.ca ([209.197.145.21]) by mx03.cybersurf.com with esmtp (Exim 4.30) id 1D9jIs-0002xY-16 for netdev@oss.sgi.com; Fri, 11 Mar 2005 07:31:42 -0500 Received: from [24.103.99.32] (helo=[10.0.0.9]) by mail.cyberus.ca with esmtp (Exim 4.20) id 1D9jIp-0005GD-ES; Fri, 11 Mar 2005 07:31:39 -0500 Subject: Re: A bug in the Kernel? From: jamal Reply-To: hadi@cyberus.ca To: itkes@fat.imec.msu.ru Cc: netdev@oss.sgi.com In-Reply-To: <1047.80.249.146.228.1110540470.squirrel@mx.imec.msu.ru> References: <1047.80.249.146.228.1110540470.squirrel@mx.imec.msu.ru> Content-Type: text/plain Organization: jamalopolous Message-Id: <1110544296.1091.155.camel@jzny.localdomain> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.2.2 Date: 11 Mar 2005 07:31:37 -0500 Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV 0.83/760/Wed Mar 9 09:12:01 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 2911 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: hadi@cyberus.ca Precedence: bulk X-list: netdev Content-Length: 2300 Lines: 52 Hello Alex, I didnt pay close attention to your patch, but i dont see how a problem such as you describe can be solved by a patch in the kernel that is not coordinated to user space. The best way to do it is to have read/write locking of tables issued from user (you can use ideas like the NLM_F_ATOMIC flag to signal this). Unfortunately this means during the lock period (especially if it is a write lock), incoming/outgoing traffic cannot be processed. My belief is this is a design/tradeoff decision made by Alexey to allow this "hole" so that we dont have moments where we have freezes". One way to do it is to have your app A also register to listen to events that are happening in the kernel. This way when app B deletes those routes it is informed about it. cheers, jamal On Fri, 2005-03-11 at 06:27, itkes@fat.imec.msu.ru wrote: > Hello. > > I think, I have found a bug in the Linux Kernel. It is caused by working > with lists by indexes in such operstions as routing tables dump and > routing rules dump (functions fib_rules_dump in fib_rules.c and a few dump > functions in fib_hash.c). If some elements are removed form the list, the > index may identify not the element it identified earlier. As a result, > there may happen that an application that requested the routes or rules > dump, will not receive the entire table. There is how > to make an application to lose some rules. > > 1. Add 150 rules to kernel table. > 2. Application A sends an RTM_GETRULE message with flag NLM_F_DUMP. The > kernel puts first 107 rules to the buffer. > 3. Application B deletes first 20 rules. > 4. Application A receives the first couple of data from kernel. The kernel > puts next couple of rules to the buffer, begining from 108-th rule, that > was 128-th earlier. > As a result, 20 rules had not been sent to the application, without being > deleted or modified during the dump operation. > > Routes can be lost, too, if you add certain 5000 routes, request their > dump and remove 1000 from them during the dump. > > In the patch (against kernel 2.6.11) attached, I have corrected these > bugs. In the modified kernel, both dumps of routes and routing rules seems > to work properly. But, I think, there can be other bugs similar to this in > other dump operations. > > Alex Itkes. From hadi@cyberus.ca Fri Mar 11 04:36:37 2005 Received: with ECARTIS (v1.0.0; list netdev); Fri, 11 Mar 2005 04:36:43 -0800 (PST) Received: from mx02.cybersurf.com (mx02.cybersurf.com [209.197.145.105]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j2BCaaiF000333 for ; Fri, 11 Mar 2005 04:36:36 -0800 Received: from mail.cyberus.ca ([209.197.145.21]) by mx02.cybersurf.com with esmtp (Exim 4.30) id 1D9jNY-0003tS-VB for netdev@oss.sgi.com; Fri, 11 Mar 2005 07:36:32 -0500 Received: from [24.103.99.32] (helo=[10.0.0.9]) by mail.cyberus.ca with esmtp (Exim 4.20) id 1D9jNX-0005zu-8f; Fri, 11 Mar 2005 07:36:31 -0500 Subject: Re: UDP Lite Implementation From: jamal Reply-To: hadi@cyberus.ca To: Petri Passila Cc: netdev@oss.sgi.com In-Reply-To: <5.1.0.14.2.20050311133309.00ab5f10@elemail.ele.vtt.fi> References: <5.1.0.14.2.20050311133309.00ab5f10@elemail.ele.vtt.fi> Content-Type: text/plain Organization: jamalopolous Message-Id: <1110544588.1089.159.camel@jzny.localdomain> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.2.2 Date: 11 Mar 2005 07:36:28 -0500 Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV 0.83/760/Wed Mar 9 09:12:01 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 2912 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: hadi@cyberus.ca Precedence: bulk X-list: netdev Content-Length: 1422 Lines: 46 Start looking at udp code and go from there. What do you see as an issue that will slow you down? You should probably be able to cutnpaste a lot of the code from UDP. Of course forget about other OSes - implement on Linux. cheers, jamal On Fri, 2005-03-11 at 06:34, Petri Passila wrote: > Hello ! > > I am doing my bachelors thesis here in Recearch center of Finland (VTT > Electronics) in Oulu. The meaning of the thesis is to compare UDP and UDP > Lite using multimedia streaming. The part of my job is to implement UDP > Lite into the Linux protocol stack (or FreeBSDs). And I have encountered > some difficulties during my way. > > I am investigating the operation of the Linux protocol stack and the udp.c > file tells that you are the athors for the UDP. And I am courious to know > if you might know something about implementing the UDP Lite. So I wonder if > you could possibly help me in my thesis. If you had some information about > porting, which could help me, or the whole implementation I would be > grateful to hear about it. Or, do you know someone who might know about the > issue? > > Our platform is constructed of a FreeBSD 5.1 and Linux RH9 (kernel 2.4.20) > machine(s). > > > Sincerely yours > > > > Petri Passila > VTT Electronics > Telecommunication Systems > Wireless Services group > > Work Tel. 040-5425526 > GSM +35840-731 0109 > mail: petri.passila@vtt.fi > > > > From nhorman@redhat.com Fri Mar 11 04:57:51 2005 Received: with ECARTIS (v1.0.0; list netdev); Fri, 11 Mar 2005 04:58:02 -0800 (PST) Received: from mx1.redhat.com (mx1.redhat.com [66.187.233.31]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j2BCvo92001440 for ; Fri, 11 Mar 2005 04:57:51 -0800 Received: from int-mx1.corp.redhat.com (int-mx1.corp.redhat.com [172.16.52.254]) by mx1.redhat.com (8.12.11/8.12.11) with ESMTP id j2BCvYCj004255; Fri, 11 Mar 2005 07:57:34 -0500 Received: from localhost.localdomain (hmsendeavour.rdu.redhat.com [172.16.57.156]) by int-mx1.corp.redhat.com (8.11.6/8.11.6) with ESMTP id j2BCvYn06873; Fri, 11 Mar 2005 07:57:34 -0500 Received: from localhost.localdomain (hmsendeavour [127.0.0.1]) by localhost.localdomain (8.12.8/8.12.8) with ESMTP id j2BCvY0H018460; Fri, 11 Mar 2005 07:57:34 -0500 Received: (from nhorman@localhost) by localhost.localdomain (8.12.8/8.12.8/Submit) id j2BCvOAP018458; Fri, 11 Mar 2005 07:57:24 -0500 Date: Fri, 11 Mar 2005 07:57:24 -0500 From: nhorman@redhat.com To: "David S. Miller" Cc: nhorman@redhat.com, sri@us.ibm.com, netdev@oss.sgi.com, lksctp-developers@lists.sourceforge.net Subject: Re: [Patch] sctp: add receive buffer accounting to sctp (fwd) Message-ID: <20050311125724.GB18122@hmsendeavour.rdu.redhat.com> References: <20050309211632.6f70fe41.davem@davemloft.net> <20050310120803.GA6341@hmsendeavour.rdu.redhat.com> <20050310154342.GG6341@hmsendeavour.rdu.redhat.com> <20050310183856.08cb5f7b.davem@davemloft.net> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="uZ3hkaAS1mZxFaxD" Content-Disposition: inline In-Reply-To: <20050310183856.08cb5f7b.davem@davemloft.net> User-Agent: Mutt/1.4i X-Virus-Scanned: ClamAV 0.83/760/Wed Mar 9 09:12:01 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 2913 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: nhorman@redhat.com Precedence: bulk X-list: netdev Content-Length: 2472 Lines: 93 --uZ3hkaAS1mZxFaxD Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Thu, Mar 10, 2005 at 06:38:56PM -0800, David S. Miller wrote: > On Thu, 10 Mar 2005 10:43:42 -0500 > nhorman@redhat.com wrote: >=20 > > Repost of my ealier rcvbuf patch. No changes, but rediffed to apply cl= eanly to > > the head of the bitkeeper tree. Passes all lksctp regression tests >=20 > Applied, thanks Neil. You're quite welcome. Heres the 2.4 version of the same patch that you requested. Applies clean against the bitkeeper head. Signed-off-by: Neil Horman [nhorman@hmsendeavour kernel]$ diffstat linux-2.4-sctp.rcvbuf.patch=20 input.c | 21 +++++++++++++++++++++ 1 files changed, 21 insertions(+) --- linux-2.4-sctp/net/sctp/input.c.orig 2005-03-10 13:36:49.000000000 -0500 +++ linux-2.4-sctp/net/sctp/input.c 2005-03-10 13:51:25.000000000 -0500 @@ -100,6 +100,21 @@ return 0; } =20 +/* The free routine for skbuffs that sctp receives */ +static void sctp_rfree(struct sk_buff *skb) +{ + atomic_sub(sizeof(struct sctp_chunk),&skb->sk->sk_rmem_alloc); + sock_rfree(skb); +} + +/* The ownership wrapper routine to do receive buffer accounting */ +static void sctp_rcv_set_owner_r(struct sk_buff *skb, struct sock *sk) +{ + skb_set_owner_r(skb,sk); + skb->destructor =3D sctp_rfree; + atomic_add(sizeof(struct sctp_chunk),&sk->sk_rmem_alloc); +} + /* * This is the routine which IP calls when receiving an SCTP packet. */ @@ -183,6 +198,10 @@ rcvr =3D asoc ? &asoc->base : &ep->base; sk =3D rcvr->sk; =20 + if ((sk) && (atomic_read(&sk->sk_rmem_alloc) >=3D sk->sk_rcvbuf))=20 + goto discard_release; +=20 + if (!ipsec_sk_policy(sk, skb)) goto discard_release; =20 @@ -197,6 +216,8 @@ goto discard_release; } =20 + sctp_rcv_set_owner_r(skb,sk); + /* Remember what endpoint is to handle this packet. */ chunk->rcvr =3D rcvr; =20 --=20 /*************************************************** *Neil Horman *Software Engineer *Red Hat, Inc. *nhorman@redhat.com *gpg keyid: 1024D / 0x92A74FA1 *http://pgp.mit.edu ***************************************************/ --uZ3hkaAS1mZxFaxD Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.1 (GNU/Linux) iD8DBQFCMZWzM+bEoZKnT6ERAru2AJ9N1Fle7qQoSZtcSXaXZJ0c9UOFnACghdoe BPoGpQWVuAI/Rimoo6zd/vo= =WO73 -----END PGP SIGNATURE----- --uZ3hkaAS1mZxFaxD-- From tgraf@suug.ch Fri Mar 11 05:28:32 2005 Received: with ECARTIS (v1.0.0; list netdev); Fri, 11 Mar 2005 05:28:39 -0800 (PST) Received: from b.mx.projectdream.org (eth0-0.arisu.projectdream.org [194.158.4.191]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j2BDSVrq003118 for ; Fri, 11 Mar 2005 05:28:32 -0800 Received: from postel.suug.ch (postel.suug.ch [195.134.158.23]) (using TLSv1 with cipher EDH-RSA-DES-CBC3-SHA (168/168 bits)) (No client certificate requested) by b.mx.projectdream.org (Postfix) with ESMTP id 9D8DD88; Fri, 11 Mar 2005 14:28:06 +0100 (CET) Received: by postel.suug.ch (Postfix, from userid 10001) id C20871C0EA; Fri, 11 Mar 2005 14:28:48 +0100 (CET) Date: Fri, 11 Mar 2005 14:28:48 +0100 From: Thomas Graf To: "Catalin(ux aka Dino) BOIE" Cc: Jamal Hadi Salim , Stephen Hemminger , "David S. Miller" , netdev@oss.sgi.com Subject: Re: [PATCH] move tc_u32_mark into pkt_cls.h Message-ID: <20050311132848.GF31837@postel.suug.ch> References: <20050310104207.1d74ac00@dxpl.pdx.osdl.net> <1110481248.1074.306.camel@jzny.localdomain> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-Virus-Scanned: ClamAV 0.83/760/Wed Mar 9 09:12:01 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 2914 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: tgraf@suug.ch Precedence: bulk X-list: netdev Content-Length: 778 Lines: 18 * Catalin(ux aka Dino) BOIE 2005-03-11 09:01 > On Thu, 10 Mar 2005, Jamal Hadi Salim wrote: > > > > >Agreed on both counts. > > > >Note, however, the tc_u32_mark should die Real Soon Now given the > >meta match patches that are in from Thomas. > > It can die, but there are users that use it. > So, I think that as long as u32 will stay in kernel, we can let > mark_in_u32 live. > It's a small modification and I think it may stay. Everyone told you that it would only be a temporary solution and once the meta ematch works flawlessly there is no reason to keep it in the tree. In order to give everyone enough time to switch the removal should be announced on LARTC mailinglist and commited 2-3 release cycles later. From Robert.Olsson@data.slu.se Fri Mar 11 05:58:39 2005 Received: with ECARTIS (v1.0.0; list netdev); Fri, 11 Mar 2005 05:58:42 -0800 (PST) Received: from mx1.slu.se (mx1.slu.se [130.238.96.70]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j2BDwcvw004764 for ; Fri, 11 Mar 2005 05:58:38 -0800 Received: from robur.slu.se (robur.slu.se [130.238.98.12]) by mx1.slu.se (8.13.1/8.13.1) with ESMTP id j2BDwWZ6012311; Fri, 11 Mar 2005 14:58:33 +0100 Received: by robur.slu.se (Postfix, from userid 1000) id CCD3CEE1E9; Fri, 11 Mar 2005 14:58:32 +0100 (CET) From: Robert Olsson MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <16945.41992.799695.358632@robur.slu.se> Date: Fri, 11 Mar 2005 14:58:32 +0100 To: cliff white Cc: Robert Olsson , Stephen Hemminger , netdev@oss.sgi.com Subject: Re: pktgen: causing lots of errors in console log In-Reply-To: <20050310104830.58c467c0@es175> References: <20050308140826.451435e5@dxpl.pdx.osdl.net> <16942.55689.924299.906304@robur.slu.se> <20050310104830.58c467c0@es175> X-Mailer: VM 7.18 under Emacs 21.3.1 X-Scanned-By: MIMEDefang 2.48 on 130.238.96.70 X-Virus-Scanned: ClamAV 0.83/760/Wed Mar 9 09:12:01 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 2915 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: Robert.Olsson@data.slu.se Precedence: bulk X-list: netdev Content-Length: 1689 Lines: 73 cliff white writes: > Okay, I can reproduce it on two machines, no problem. I too with CONFIG_PREEMPT=y. Thanks. Please try: --- net/core/pktgen.c.050310 2005-03-10 22:12:43.000000000 +0100 +++ net/core/pktgen.c 2005-03-11 10:48:43.000000000 +0100 @@ -151,7 +151,7 @@ #include -#define VERSION "pktgen v2.59: Packet Generator for packet performance testing.\n" +#define VERSION "pktgen v2.60: Packet Generator for packet performance testing.\n" /* #define PG_DEBUG(a) a */ #define PG_DEBUG(a) @@ -1419,7 +1419,6 @@ if (debug) printk("pktgen: t=%s, count=%lu\n", name, count); - thread_lock(); t = (struct pktgen_thread*)(data); if(!t) { @@ -1441,14 +1440,18 @@ if( copy_from_user(f, &user_buffer[i], len) ) return -EFAULT; i += len; + thread_lock(); pktgen_add_device(t, f); + thread_unlock(); ret = count; sprintf(pg_result, "OK: add_device=%s", f); goto out; } if (!strcmp(name, "rem_device_all")) { + thread_lock(); t->control |= T_REMDEV; + thread_unlock(); current->state = TASK_INTERRUPTIBLE; schedule_timeout(HZ/8); /* Propagate thread->control */ ret = count; @@ -1456,10 +1459,11 @@ goto out; } - if (!strcmp(name, "max_before_softirq")) { len = num_arg(&user_buffer[i], 10, &value); + thread_lock(); t->max_before_softirq = value; + thread_unlock(); ret = count; sprintf(pg_result, "OK: max_before_softirq=%lu", value); goto out; @@ -1467,7 +1471,6 @@ ret = -EINVAL; out: - thread_unlock(); return ret; } --ro From hadi@cyberus.ca Fri Mar 11 05:59:31 2005 Received: with ECARTIS (v1.0.0; list netdev); Fri, 11 Mar 2005 05:59:36 -0800 (PST) Received: from mx02.cybersurf.com (mx02.cybersurf.com [209.197.145.105]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j2BDxURZ004962 for ; Fri, 11 Mar 2005 05:59:30 -0800 Received: from mail.cyberus.ca ([209.197.145.21]) by mx02.cybersurf.com with esmtp (Exim 4.30) id 1D9kfm-0001KB-RE for netdev@oss.sgi.com; Fri, 11 Mar 2005 08:59:26 -0500 Received: from [24.103.99.32] (helo=[10.0.0.9]) by mail.cyberus.ca with esmtp (Exim 4.20) id 1D9kfk-0000gH-5o; Fri, 11 Mar 2005 08:59:24 -0500 Subject: Re: [PATCH] move tc_u32_mark into pkt_cls.h From: jamal Reply-To: hadi@cyberus.ca To: Thomas Graf Cc: "Catalin(ux aka Dino) "BOIE , Stephen Hemminger , "David S. Miller" , netdev@oss.sgi.com In-Reply-To: <20050311132848.GF31837@postel.suug.ch> References: <20050310104207.1d74ac00@dxpl.pdx.osdl.net> <1110481248.1074.306.camel@jzny.localdomain> <20050311132848.GF31837@postel.suug.ch> Content-Type: text/plain Organization: jamalopolous Message-Id: <1110549556.2127.14.camel@jzny.localdomain> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.2.2 Date: 11 Mar 2005 08:59:16 -0500 Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV 0.83/760/Wed Mar 9 09:12:01 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 2916 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: hadi@cyberus.ca Precedence: bulk X-list: netdev Content-Length: 900 Lines: 23 On Fri, 2005-03-11 at 08:28, Thomas Graf wrote: > * Catalin(ux aka Dino) BOIE 2005-03-11 09:01 > > > > It can die, but there are users that use it. > > So, I think that as long as u32 will stay in kernel, we can let > > mark_in_u32 live. > > It's a small modification and I think it may stay. > > Everyone told you that it would only be a temporary solution and once > the meta ematch works flawlessly there is no reason to keep it in the > tree. In order to give everyone enough time to switch the removal should > be announced on LARTC mailinglist and commited 2-3 release cycles later. > As an alternative: we can probably still keep the user space interface the way he has it and just underneath hide it as meta ematch? This will mean no script changes - but if it is too much work to hide it, it may not be worth it. cheers, jamal From AUpton@island.com Fri Mar 11 06:00:52 2005 Received: with ECARTIS (v1.0.0; list netdev); Fri, 11 Mar 2005 06:00:58 -0800 (PST) Received: from hfcmsw02.instinet.com (hfcmsw02.instinet.com [198.178.39.151]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j2BE0pNO005594 for ; Fri, 11 Mar 2005 06:00:52 -0800 Received: from nmailr01.prod.instinet.com (unverified) by hfcmsw02.instinet.com (Content Technologies SMTPRS 4.3.17) with ESMTP id for ; Fri, 11 Mar 2005 09:00:50 -0500 Received: from hfccinfexch101.AMERICAS.CORP.LOCAL by Instinet.com with ESMTP id JAA24365 for ; Fri, 11 Mar 2005 09:00:50 -0500 (EST) Received: from HFCCINFEXCH501.AMERICAS.CORP.LOCAL ([172.27.195.19]) by hfccinfexch101.AMERICAS.CORP.LOCAL with Microsoft SMTPSVC (5.0.2195.5329) ; Fri, 11 Mar 2005 09:00:50 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Subject: 2.6.10 - "netdev=" kernel boot commands and the Intel e1000 nic Date: Fri, 11 Mar 2005 09:00:50 -0500 Message-ID: <13A26154A563124B876A26F0EF0CE1ED032C9299@HFCCINFEXCH501.AMERICAS.CORP.LOCAL> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: 2.6.10 - "netdev=" kernel boot commands and the Intel e1000 nic Thread-Index: AcUmQrtWveAlBbgbSZCW95ed9F3AIA== From: "Alex Upton" To: X-OriginalArrivalTime: 11 Mar 2005 14:00:50.0482 (UTC) FILETIME=[BB77E120:01C52642] X-Virus-Scanned: ClamAV 0.83/760/Wed Mar 9 09:12:01 2005 on oss.sgi.com X-Virus-Status: Clean Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by oss.sgi.com id j2BE0pNO005594 X-archive-position: 2917 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: AUpton@island.com Precedence: bulk X-list: netdev Content-Length: 2869 Lines: 74 Hello All, For about 3.5 days now I've been trying to swap eth0 and eth1 devices through use of the netdev kernel boot switch. The scenario: We have a system with onboard NICS and a PCI Intel e1000 Fiber NIC installed. This particular system by default forces the NIC inside the PCI slot to always default to eth0. We want to have ultimate control as to which NIC is deemed worthy enough to become eth0. We are using an entirely monolithic kernel via a PXE driven build and prefer not to support use of modules. Reading through the kernel-parameters.txt I found the "netdev=" command which suggests the following usage: netdev= [NET] Network devices parameters Format: ,,,, Note that mem_start is often overloaded to mean something different and driver-specific. We have tried the following methods based on this info and other peoples examples found in google land without success. netdev=21,0x2800,0xf6fa,0xf6fd,eth1 netdev=21,0x2800,0xf6fa0000,0xf6fd0000,eth1 netdev=21,0x2800,1,32,eth1 netdev=irq=21,io=0x2800,name=eth1 We have also tried to use "nameif" as a second approach, unfortunately nameif seems to be limited to only having the capability to change any logical Ethernet device name other than eth0. We've even attempted use of the "pci=" commands with hopes of reversing the PCI search order, and forced bios values, again without success. If anyone has any suggestions or insight on how to work with netdev and the e1000 properly it would be greatly appreciated! Thanks very much -Alex Alex.upton@inetats.com ***************************************************************** <<>> In compliance with applicable rules and regulations, Instinet reviews and archives incoming and outgoing email communications, copies of which may be produced at the request of regulators. This message is intended only for the personal and confidential use of the recipients named above. If the reader of this email is not the intended recipient, you have received this email in error and any review, dissemination, distribution or copying is strictly prohibited. If you have received this email in error, please notify the sender immediately by return email and permanently delete the copy you received. Instinet accepts no liability for any content contained in the email, or any errors or omissions arising as a result of email transmission. Any opinions contained in this email constitute the sender's best judgment at this time and are subject to change without notice. Instinet does not make recommendations of a particular security and the information contained in this email should not be considered as a recommendation, an offer or a solicitation of an offer to buy and sell securities. ***************************************************************** From kaber@trash.net Fri Mar 11 06:01:06 2005 Received: with ECARTIS (v1.0.0; list netdev); Fri, 11 Mar 2005 06:01:13 -0800 (PST) Received: from kaber.coreworks.de ([62.206.217.67]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j2BE15nD005626 for ; Fri, 11 Mar 2005 06:01:06 -0800 Received: from localhost ([127.0.0.1]) by kaber.coreworks.de with esmtp (Exim 4.50) id 1D9khE-0000th-6d; Fri, 11 Mar 2005 15:00:56 +0100 Message-ID: <4231A498.4020101@trash.net> Date: Fri, 11 Mar 2005 15:00:56 +0100 From: Patrick McHardy User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.7.5) Gecko/20050106 Debian/1.7.5-1 X-Accept-Language: en MIME-Version: 1.0 To: Dmitry Torokhov CC: netdev@oss.sgi.com, LKML , Netfilter Development Mailinglist Subject: Re: Last night Linus bk - netfilter busted? References: <200503110223.34461.dtor_core@ameritech.net> In-Reply-To: <200503110223.34461.dtor_core@ameritech.net> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV 0.83/760/Wed Mar 9 09:12:01 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 2918 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: kaber@trash.net Precedence: bulk X-list: netdev Content-Length: 693 Lines: 21 Dmitry Torokhov wrote: > My box gets stuck while booting (actually starting ntpd) whith tonight > pull from Linus. It looks like it is spinning in ipt_do_table when I do > SysRq-P. No call trace though. Please post your ruleset and .config. A backtrace would also be useful. > Anyone else seeing it? Any ideas? Works fine here. You could try if reverting one of these two patches helps (second one only if its a SMP box). ChangeSet@1.2010, 2005-03-09 20:28:17-08:00, bdschuym@pandora.be [NETFILTER]: Reduce call chain length in netfilter (take 2) ChangeSet@1.1982.114.20, 2005-03-03 23:15:48+01:00, ak@suse.de [NETFILTER]: Reduce netfilter memory use on MP systems Regards Patrick From util@deuroconsult.ro Fri Mar 11 06:06:00 2005 Received: with ECARTIS (v1.0.0; list netdev); Fri, 11 Mar 2005 06:06:07 -0800 (PST) Received: from webhosting.rdsbv.ro (webhosting.rdsbv.ro [213.157.185.164]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j2BE5xag007248 for ; Fri, 11 Mar 2005 06:06:00 -0800 Received: from webhosting.rdsbv.ro (localhost [127.0.0.1]) by webhosting.rdsbv.ro (8.13.3/8.13.3) with ESMTP id j2BE5mLm014503 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 11 Mar 2005 16:05:48 +0200 Received: from localhost (util@localhost) by webhosting.rdsbv.ro (8.13.3/8.13.3/Submit) with ESMTP id j2BE5l3V014500; Fri, 11 Mar 2005 16:05:47 +0200 X-Authentication-Warning: webhosting.rdsbv.ro: util owned process doing -bs Date: Fri, 11 Mar 2005 16:05:47 +0200 (EET) From: "Catalin(ux aka Dino) BOIE" X-X-Sender: util@webhosting.rdsbv.ro To: Thomas Graf cc: Jamal Hadi Salim , Stephen Hemminger , "David S. Miller" , netdev@oss.sgi.com Subject: Re: [PATCH] move tc_u32_mark into pkt_cls.h In-Reply-To: <20050311132848.GF31837@postel.suug.ch> Message-ID: References: <20050310104207.1d74ac00@dxpl.pdx.osdl.net> <1110481248.1074.306.camel@jzny.localdomain> <20050311132848.GF31837@postel.suug.ch> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Virus-Scanned: ClamAV 0.83/760/Wed Mar 9 09:12:01 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 2919 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: util@deuroconsult.ro Precedence: bulk X-list: netdev Content-Length: 1056 Lines: 27 >> It can die, but there are users that use it. >> So, I think that as long as u32 will stay in kernel, we can let >> mark_in_u32 live. >> It's a small modification and I think it may stay. > > Everyone told you that it would only be a temporary solution and once > the meta ematch works flawlessly there is no reason to keep it in the > tree. In order to give everyone enough time to switch the removal should > be announced on LARTC mailinglist and commited 2-3 release cycles later. Yes, you are right, everybody told me. I don't deny. And I will respect the decision that will be taken. But I'm wonder what are the gains removing nfmark from u32? ~64 bytes of code and 128 bytes of sources?! I thing that the gain being in is bigger than the gains resulting from removing it. I will not ask another set of questions. If I'm wrong, let me know and I will send, as soon as I can, patches to remove it from kernel (with 3 releases warning). Thank you for your time! --- Catalin(ux aka Dino) BOIE catab at deuroconsult.ro http://kernel.umbrella.ro/ From hadi@cyberus.ca Fri Mar 11 06:12:56 2005 Received: with ECARTIS (v1.0.0; list netdev); Fri, 11 Mar 2005 06:13:01 -0800 (PST) Received: from mx04.cybersurf.com (mx04.cybersurf.com [209.197.145.108]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j2BECt0N007978 for ; Fri, 11 Mar 2005 06:12:56 -0800 Received: from mail.cyberus.ca ([209.197.145.21]) by mx01.cybersurf.com with esmtp (Exim 4.30) id 1D9ksl-0006TJ-Lo for netdev@oss.sgi.com; Fri, 11 Mar 2005 09:12:51 -0500 Received: from [24.103.99.32] (helo=[10.0.0.9]) by mail.cyberus.ca with esmtp (Exim 4.20) id 1D9ksj-0002Yn-Rr; Fri, 11 Mar 2005 09:12:50 -0500 Subject: Re: 2.6.10 - "netdev=" kernel boot commands and the Intel e1000 nic From: jamal Reply-To: hadi@cyberus.ca To: Alex Upton Cc: netdev@oss.sgi.com In-Reply-To: <13A26154A563124B876A26F0EF0CE1ED032C9299@HFCCINFEXCH501.AMERICAS.CORP.LOCAL> References: <13A26154A563124B876A26F0EF0CE1ED032C9299@HFCCINFEXCH501.AMERICAS.CORP.LOCAL> Content-Type: text/plain Organization: jamalopolous Message-Id: <1110550365.2130.28.camel@jzny.localdomain> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.2.2 Date: 11 Mar 2005 09:12:46 -0500 Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV 0.83/760/Wed Mar 9 09:12:01 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 2920 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: hadi@cyberus.ca Precedence: bulk X-list: netdev Content-Length: 1845 Lines: 55 you may need to open a bug report against nameif. btw, too long a disclaimer. cheers, jamal On Fri, 2005-03-11 at 09:00, Alex Upton wrote: > Hello All, > > For about 3.5 days now I've been trying to swap eth0 and eth1 devices > through use of the netdev kernel boot switch. > > The scenario: > > We have a system with onboard NICS and a PCI Intel e1000 Fiber NIC > installed. This particular system by default forces the NIC inside the > PCI slot to always default to eth0. We want to have ultimate control as > to which NIC is deemed worthy enough to become eth0. We are using an > entirely monolithic kernel via a PXE driven build and prefer not to > support use of modules. > > Reading through the kernel-parameters.txt I found the "netdev=" command > which suggests the following usage: > > netdev= [NET] Network devices parameters > Format: ,,,, > Note that mem_start is often overloaded to mean > something different and driver-specific. > > We have tried the following methods based on this info and other peoples > examples found in google land without success. > > netdev=21,0x2800,0xf6fa,0xf6fd,eth1 > netdev=21,0x2800,0xf6fa0000,0xf6fd0000,eth1 > netdev=21,0x2800,1,32,eth1 > netdev=irq=21,io=0x2800,name=eth1 > > We have also tried to use "nameif" as a second approach, unfortunately > nameif seems to be limited to only having the capability to change any > logical Ethernet device name other than eth0. > > We've even attempted use of the "pci=" commands with hopes of reversing > the PCI search order, and forced bios values, again without success. > > If anyone has any suggestions or insight on how to work with netdev and > the e1000 properly it would be greatly appreciated! > > Thanks very much > -Alex > > Alex.upton@inetats.com > From shemminger@osdl.org Thu Mar 10 14:14:41 2005 Received: with ECARTIS (v1.0.0; list netdev); Thu, 10 Mar 2005 14:14:55 -0800 (PST) Received: from smtp.osdl.org (fire.osdl.org [65.172.181.4]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j2AMEbqi001453 for ; Thu, 10 Mar 2005 14:14:39 -0800 Received: from shell0.pdx.osdl.net (fw.osdl.org [65.172.181.6]) by smtp.osdl.org (8.12.8/8.12.8) with ESMTP id j2BHgMqi025119 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO); Fri, 11 Mar 2005 09:42:22 -0800 Received: from dxpl.pdx.osdl.net (dxpl.pdx.osdl.net [172.20.1.103]) by shell0.pdx.osdl.net (8.13.1/8.11.6) with ESMTP id j2BHgMKZ031750; Fri, 11 Mar 2005 09:42:22 -0800 Date: Fri, 11 Mar 2005 09:42:39 -0800 From: Stephen Hemminger To: Baruch Even Cc: "David S.Miller" , linux-net@vger.kernel.org, netdev@oss.sgi.com, Baruch Even , Douglas Leith Subject: Re: [RFC INTRO 0/5] H-TCP congestion control Message-ID: <20050311094239.4c59c29d@dxpl.pdx.osdl.net> In-Reply-To: <20050311160734.30424.67955.65942@galon.ev-en.org> References: <20050311160734.30424.67955.65942@galon.ev-en.org> Organization: Open Source Development Lab X-Mailer: Sylpheed-Claws 1.0.1 (GTK+ 1.2.10; x86_64-unknown-linux-gnu) X-Face: &@E+xe?c%:&e4D{>f1O<&U>2qwRREG5!}7R4;D<"NO^UI2mJ[eEOA2*3>(`Th.yP,VDPo9$ /`~cw![cmj~~jWe?AHY7D1S+\}5brN0k*NE?pPh_'_d>6;XGG[\KDRViCfumZT3@[ Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Received-SPF: pass (domain of shemminger@osdl.org designates 65.172.181.6 as permitted sender) X-MIMEDefang-Filter: osdl$Revision: 1.104 $ X-Scanned-By: MIMEDefang 2.36 X-Virus-Scanned: ClamAV version 0.83, clamav-milter version 0.83 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 8 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: shemminger@osdl.org Precedence: bulk X-list: netdev Content-Length: 1157 Lines: 28 On Fri, 11 Mar 2005 18:07:34 +0200 (IST) Baruch Even wrote: > The following patches are the result of the work of Douglas Leith to implement > the H-TCP congestion control proposal. They have since been modified by me > (Baruch Even) to port them to kernel 2.6.x, test them and tune them. > > All patches are against Linux kernel version 2.6.11-bk6. This is currently > a preliminary work and is presented for review in order to receive comments to > improve this work so it can be accepted to mainline Linux Kernel. > > The initial development was to add H-TCP to the Linux kernel for testing > purposes, it became evident that on 1 Gbit/s links Linux is unable to process > the received ack stream fast enough to handle the load. We have patches for > that but they proved too hard to be ported to 2.6.11+, we are currently working > on them. > > Baruch Are there any IPR encumberance to this like FAST TCP. Earlier versions of this patch said: > This patch is covered by a pending patent, a license is being worked on to > enable the inclusion in Linux. Comments and suggestions on this are also > solicited. Has this changed? From shemminger@osdl.org Thu Mar 10 14:14:42 2005 Received: with ECARTIS (v1.0.0; list netdev); Thu, 10 Mar 2005 14:14:54 -0800 (PST) Received: from smtp.osdl.org (fire.osdl.org [65.172.181.4]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j2AMEbqk001453 for ; Thu, 10 Mar 2005 14:14:41 -0800 Received: from shell0.pdx.osdl.net (fw.osdl.org [65.172.181.6]) by smtp.osdl.org (8.12.8/8.12.8) with ESMTP id j2BHb7qi024635 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO); Fri, 11 Mar 2005 09:37:07 -0800 Received: from dxpl.pdx.osdl.net (dxpl.pdx.osdl.net [172.20.1.103]) by shell0.pdx.osdl.net (8.13.1/8.11.6) with ESMTP id j2BHb6JY031500; Fri, 11 Mar 2005 09:37:06 -0800 Date: Fri, 11 Mar 2005 09:37:24 -0800 From: Stephen Hemminger To: "leo.yuriev.ru" Cc: Lennert Buytenhek , Patrick McHardy , jamal , Ben Greear , , Subject: Re: [PATCH] updated, ethernet-bridge: update skb->priority in case forwarded frame has VLAN-header Message-ID: <20050311093724.6c8b6a6d@dxpl.pdx.osdl.net> In-Reply-To: <914610115.20050311172022@yuriev.ru> References: <914610115.20050311172022@yuriev.ru> Organization: Open Source Development Lab X-Mailer: Sylpheed-Claws 1.0.1 (GTK+ 1.2.10; x86_64-unknown-linux-gnu) X-Face: &@E+xe?c%:&e4D{>f1O<&U>2qwRREG5!}7R4;D<"NO^UI2mJ[eEOA2*3>(`Th.yP,VDPo9$ /`~cw![cmj~~jWe?AHY7D1S+\}5brN0k*NE?pPh_'_d>6;XGG[\KDRViCfumZT3@[ Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Received-SPF: pass (domain of shemminger@osdl.org designates 65.172.181.6 as permitted sender) X-MIMEDefang-Filter: osdl$Revision: 1.104 $ X-Scanned-By: MIMEDefang 2.36 X-Virus-Scanned: ClamAV version 0.83, clamav-milter version 0.83 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 7 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: shemminger@osdl.org Precedence: bulk X-list: netdev Content-Length: 490 Lines: 15 On Fri, 11 Mar 2005 17:20:22 +0300 Leo Yuriev wrote: > Kernel 2.6 (2.6.11) > > When ethernet-bridge forward a packet and such ethernet-frame has > VLAN-tag, bridge should update skb->prioriry for properly QoS > handling. This small patch does this. > > Based upon discussion during last week I added pskb_may_pull() > checking and simple mapping from 802.1p/user_priority to skb->priority. > > Patch-by: Leo Yuriev Do this as an ebtables module please. From christoph@graphe.net Thu Mar 10 14:13:42 2005 Received: with ECARTIS (v1.0.0; list netdev); Thu, 10 Mar 2005 14:13:47 -0800 (PST) Received: from graphe.net (209-204-138-32.dsl.static.sonic.net [209.204.138.32]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j2AMDgWe001203 for ; Thu, 10 Mar 2005 14:13:42 -0800 Received: from christoph (helo=localhost) by graphe.net with local-esmtp (Exim 4.44) id 1D9qAu-0006SI-Ff; Fri, 11 Mar 2005 11:52:03 -0800 Date: Fri, 11 Mar 2005 11:51:56 -0800 (PST) From: Christoph Lameter X-X-Sender: christoph@server.graphe.net To: Andrew Morton cc: linux-kernel@vger.kernel.org, mark@chelsio.com, netdev@oss.sgi.com, Jeff Garzik Subject: Re: A new 10GB Ethernet Driver by Chelsio Communications In-Reply-To: <20050311112132.6a3a3b49.akpm@osdl.org> Message-ID: References: <20050311112132.6a3a3b49.akpm@osdl.org> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Virus-Scanned: ClamAV version 0.83, clamav-milter version 0.83 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 2 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: christoph@lameter.com Precedence: bulk X-list: netdev Content-Length: 205 Lines: 7 On Fri, 11 Mar 2005, Andrew Morton wrote: > > It supports AMD64, EM64T and x86 systems. > > Is it only supported on those systems? If so, why is that? The driver was only tested on those architectures. From akpm@osdl.org Thu Mar 10 14:14:38 2005 Received: with ECARTIS (v1.0.0; list netdev); Thu, 10 Mar 2005 14:14:52 -0800 (PST) Received: from smtp.osdl.org (fire.osdl.org [65.172.181.4]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j2AMEbqc001453 for ; Thu, 10 Mar 2005 14:14:38 -0800 Received: from shell0.pdx.osdl.net (fw.osdl.org [65.172.181.6]) by smtp.osdl.org (8.12.8/8.12.8) with ESMTP id j2BJM1qi002331 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO); Fri, 11 Mar 2005 11:22:01 -0800 Received: from bix (shell0.pdx.osdl.net [10.9.0.31]) by shell0.pdx.osdl.net (8.13.1/8.11.6) with SMTP id j2BJLxxw004359; Fri, 11 Mar 2005 11:22:00 -0800 Date: Fri, 11 Mar 2005 11:21:32 -0800 From: Andrew Morton To: Christoph Lameter Cc: linux-kernel@vger.kernel.org, mark@chelsio.com, netdev@oss.sgi.com, Jeff Garzik Subject: Re: A new 10GB Ethernet Driver by Chelsio Communications Message-Id: <20050311112132.6a3a3b49.akpm@osdl.org> In-Reply-To: References: X-Mailer: Sylpheed version 0.9.7 (GTK+ 1.2.10; i386-redhat-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Received-SPF: pass (domain of akpm@osdl.org designates 65.172.181.6 as permitted sender) X-MIMEDefang-Filter: osdl$Revision: 1.104 $ X-Scanned-By: MIMEDefang 2.36 X-Virus-Scanned: ClamAV version 0.83, clamav-milter version 0.83 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 6 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: akpm@osdl.org Precedence: bulk X-list: netdev Content-Length: 600 Lines: 18 Christoph Lameter wrote: > > A Linux driver for the Chelsio 10Gb Ethernet Network Controller by > Chelsio (http://www.chelsio.com). This driver supports the Chelsio N210 > NIC and is backward compatible with the Chelsio N110 model 10Gb NICs. Thanks, Christoph. The 400k patch was too large for the vger email server so I have uploaded it to http://www.zip.com.au/~akpm/linux/patches/stuff/a-new-10gb-ethernet-driver-by-chelsio-communications.patch for reviewers. > It supports AMD64, EM64T and x86 systems. Is it only supported on those systems? If so, why is that? From chrisw@osdl.org Thu Mar 10 14:14:37 2005 Received: with ECARTIS (v1.0.0; list netdev); Thu, 10 Mar 2005 14:14:50 -0800 (PST) Received: from smtp.osdl.org (fire.osdl.org [65.172.181.4]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j2AMEbqa001453 for ; Thu, 10 Mar 2005 14:14:37 -0800 Received: from shell0.pdx.osdl.net (fw.osdl.org [65.172.181.6]) by smtp.osdl.org (8.12.8/8.12.8) with ESMTP id j2BJa6qi003599 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO); Fri, 11 Mar 2005 11:36:07 -0800 Received: from shell0.pdx.osdl.net (localhost [127.0.0.1]) by shell0.pdx.osdl.net (8.13.1/8.11.6) with ESMTP id j2BJa6AB005214; Fri, 11 Mar 2005 11:36:06 -0800 Received: (from chrisw@localhost) by shell0.pdx.osdl.net (8.13.1/8.13.1/Submit) id j2BJa6Xi005213; Fri, 11 Mar 2005 11:36:06 -0800 Date: Fri, 11 Mar 2005 11:36:06 -0800 From: Chris Wright To: Daniele Venzano Cc: Chris Wright , stable@kernel.org, Linux Kernel , Jeff Garzik , Netdev Subject: Re: [stable] [BK PATCHES] 2.6.x net driver oops fixes Message-ID: <20050311193606.GL5389@shell0.pdx.osdl.net> References: <422F59E8.2090707@pobox.com> <20050310202548.GV5389@shell0.pdx.osdl.net> <4230AE24.602@pobox.com> <20050310213917.GW5389@shell0.pdx.osdl.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.6i Received-SPF: pass (domain of chrisw@osdl.org designates 65.172.181.6 as permitted sender) X-MIMEDefang-Filter: osdl$Revision: 1.104 $ X-Scanned-By: MIMEDefang 2.36 X-Virus-Scanned: ClamAV version 0.83, clamav-milter version 0.83 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 4 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: chrisw@osdl.org Precedence: bulk X-list: netdev Content-Length: 166 Lines: 7 * Daniele Venzano (webvenza@libero.it) wrote: > > I have been acting maintainer for more than a year now, and I'm > completely fine with the patch. Thanks. -chris From shemminger@osdl.org Thu Mar 10 14:14:38 2005 Received: with ECARTIS (v1.0.0; list netdev); Thu, 10 Mar 2005 14:14:49 -0800 (PST) Received: from smtp.osdl.org (fire.osdl.org [65.172.181.4]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j2AMEbqe001453 for ; Thu, 10 Mar 2005 14:14:38 -0800 Received: from shell0.pdx.osdl.net (fw.osdl.org [65.172.181.6]) by smtp.osdl.org (8.12.8/8.12.8) with ESMTP id j2BIQJqi029910 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO); Fri, 11 Mar 2005 10:26:19 -0800 Received: from dxpl.pdx.osdl.net (dxpl.pdx.osdl.net [172.20.1.103]) by shell0.pdx.osdl.net (8.13.1/8.11.6) with ESMTP id j2BIQJ1e001552; Fri, 11 Mar 2005 10:26:19 -0800 Date: Fri, 11 Mar 2005 10:26:36 -0800 From: Stephen Hemminger To: "David S. Miller" Cc: netdev@oss.sgi.com, bridge@lists.osdl.org Subject: [PATCH] bridge: no update when hold time is zero Message-ID: <20050311102636.30934f12@dxpl.pdx.osdl.net> In-Reply-To: <20050310185152.12ed9819.davem@davemloft.net> References: <20050310154437.1223b6e9@dxpl.pdx.osdl.net> <20050310185152.12ed9819.davem@davemloft.net> Organization: Open Source Development Lab X-Mailer: Sylpheed-Claws 1.0.1 (GTK+ 1.2.10; x86_64-unknown-linux-gnu) X-Face: &@E+xe?c%:&e4D{>f1O<&U>2qwRREG5!}7R4;D<"NO^UI2mJ[eEOA2*3>(`Th.yP,VDPo9$ /`~cw![cmj~~jWe?AHY7D1S+\}5brN0k*NE?pPh_'_d>6;XGG[\KDRViCfumZT3@[ Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Received-SPF: pass (domain of shemminger@osdl.org designates 65.172.181.6 as permitted sender) X-MIMEDefang-Filter: osdl$Revision: 1.104 $ X-Scanned-By: MIMEDefang 2.36 X-Virus-Scanned: ClamAV version 0.83, clamav-milter version 0.83 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 3 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: shemminger@osdl.org Precedence: bulk X-list: netdev Content-Length: 686 Lines: 19 Some users, set hold time to zero on bridge so it always does flooding. This is usually when using it with wireless. The new RCU based code changed the behaviour so the bridge would not flood for one GC interval. This patch restores the original behaviour. diff -Nru a/net/bridge/br_fdb.c b/net/bridge/br_fdb.c --- a/net/bridge/br_fdb.c 2005-03-11 10:23:44 -08:00 +++ b/net/bridge/br_fdb.c 2005-03-11 10:23:44 -08:00 @@ -337,6 +337,10 @@ struct hlist_head *head = &br->hash[br_mac_hash(addr)]; struct net_bridge_fdb_entry *fdb; + /* some users want to always flood. */ + if (hold_time(br) == 0) + return; + rcu_read_lock(); fdb = fdb_find(head, addr); if (likely(fdb)) { From tgraf@suug.ch Thu Mar 10 14:13:24 2005 Received: with ECARTIS (v1.0.0; list netdev); Thu, 10 Mar 2005 14:13:39 -0800 (PST) Received: from b.mx.projectdream.org (eth0-0.arisu.projectdream.org [194.158.4.191]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j2BEFev3008597 for ; Fri, 11 Mar 2005 06:15:40 -0800 Received: from postel.suug.ch (postel.suug.ch [195.134.158.23]) (using TLSv1 with cipher EDH-RSA-DES-CBC3-SHA (168/168 bits)) (No client certificate requested) by b.mx.projectdream.org (Postfix) with ESMTP id 02A7288; Fri, 11 Mar 2005 15:15:16 +0100 (CET) Received: by postel.suug.ch (Postfix, from userid 10001) id 8AA311C0EA; Fri, 11 Mar 2005 15:15:58 +0100 (CET) Date: Fri, 11 Mar 2005 15:15:58 +0100 From: Thomas Graf To: jamal Cc: "Catalin(ux aka Dino) BOIE" , Stephen Hemminger , "David S. Miller" , netdev@oss.sgi.com Subject: Re: [PATCH] move tc_u32_mark into pkt_cls.h Message-ID: <20050311141558.GG31837@postel.suug.ch> References: <20050310104207.1d74ac00@dxpl.pdx.osdl.net> <1110481248.1074.306.camel@jzny.localdomain> <20050311132848.GF31837@postel.suug.ch> <1110549556.2127.14.camel@jzny.localdomain> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1110549556.2127.14.camel@jzny.localdomain> X-Virus-Scanned: ClamAV 0.83/760/Wed Mar 9 09:12:01 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 1 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: tgraf@suug.ch Precedence: bulk X-list: netdev Content-Length: 562 Lines: 10 * jamal <1110549556.2127.14.camel@jzny.localdomain> 2005-03-11 08:59 > As an alternative: > we can probably still keep the user space interface the way he has it > and just underneath hide it as meta ematch? This will mean no script > changes - but if it is too much work to hide it, it may not be worth it. The only problem is what to do when both the existing u32 mark and a ematch tree is given. We can probably push it at the beginning of the tree with a AND relation so it should work out correctly. Sounds like a good idea and shouldn't be too much work. From cliffw@osdl.org Thu Mar 10 14:14:39 2005 Received: with ECARTIS (v1.0.0; list netdev); Thu, 10 Mar 2005 14:14:50 -0800 (PST) Received: from smtp.osdl.org (fire.osdl.org [65.172.181.4]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j2AMEbqg001453 for ; Thu, 10 Mar 2005 14:14:38 -0800 Received: from shell0.pdx.osdl.net (fw.osdl.org [65.172.181.6]) by smtp.osdl.org (8.12.8/8.12.8) with ESMTP id j2BID9qi028206 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO); Fri, 11 Mar 2005 10:13:10 -0800 Received: from es175 (Debian-exim@es175.pdx.osdl.net [172.20.1.68]) by shell0.pdx.osdl.net (8.13.1/8.11.6) with ESMTP id j2BID9mQ000740; Fri, 11 Mar 2005 10:13:09 -0800 Received: from cliffw (helo=es175) by es175 with local-esmtp (Exim 4.50) id 1D9odJ-0002FK-CJ; Fri, 11 Mar 2005 10:13:09 -0800 To: Robert Olsson cc: Stephen Hemminger , netdev@oss.sgi.com Subject: Re: pktgen: causing lots of errors in console log In-reply-to: <16945.41992.799695.358632@robur.slu.se> References: <20050308140826.451435e5@dxpl.pdx.osdl.net> <16942.55689.924299.906304@robur.slu.se> <20050310104830.58c467c0@es175> <16945.41992.799695.358632@robur.slu.se> Comments: In-reply-to Robert Olsson message dated "Fri, 11 Mar 2005 14:58:32 +0100." Date: Fri, 11 Mar 2005 10:13:09 -0800 From: Cliff White Message-Id: Received-SPF: pass (domain of cliffw@osdl.org designates 65.172.181.6 as permitted sender) X-MIMEDefang-Filter: osdl$Revision: 1.104 $ X-Scanned-By: MIMEDefang 2.36 X-Virus-Scanned: ClamAV version 0.83, clamav-milter version 0.83 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 5 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: cliffw@osdl.org Precedence: bulk X-list: netdev Content-Length: 1885 Lines: 80 > > cliff white writes: > > > Okay, I can reproduce it on two machines, no problem. > > I too with CONFIG_PREEMPT=y. Thanks. > > Please try: > > > --- net/core/pktgen.c.050310 2005-03-10 22:12:43.000000000 +0100 > +++ net/core/pktgen.c 2005-03-11 10:48:43.000000000 +0100 > @@ -151,7 +151,7 @@ > #include > > > -#define VERSION "pktgen v2.59: Packet Generator for packet performance test > ing.\n" > +#define VERSION "pktgen v2.60: Packet Generator for packet performance test > ing.\n" > > /* #define PG_DEBUG(a) a */ > #define PG_DEBUG(a) > @@ -1419,7 +1419,6 @@ > if (debug) > printk("pktgen: t=%s, count=%lu\n", name, count); > > - thread_lock(); > > t = (struct pktgen_thread*)(data); > if(!t) { > @@ -1441,14 +1440,18 @@ > if( copy_from_user(f, &user_buffer[i], len) ) > return -EFAULT; > i += len; > + thread_lock(); > pktgen_add_device(t, f); > + thread_unlock(); > ret = count; > sprintf(pg_result, "OK: add_device=%s", f); > goto out; > } > > if (!strcmp(name, "rem_device_all")) { > + thread_lock(); > t->control |= T_REMDEV; > + thread_unlock(); > current->state = TASK_INTERRUPTIBLE; > schedule_timeout(HZ/8); /* Propagate thread->control */ > ret = count; > @@ -1456,10 +1459,11 @@ > goto out; > } > > - > if (!strcmp(name, "max_before_softirq")) { > len = num_arg(&user_buffer[i], 10, &value); > + thread_lock(); > t->max_before_softirq = value; > + thread_unlock(); > ret = count; > sprintf(pg_result, "OK: max_before_softirq=%lu", value); > goto out; > @@ -1467,7 +1471,6 @@ > > ret = -EINVAL; > out: > - thread_unlock(); > > return ret; > } > > This stops the errors, thanks. cliffw > > --ro > From davem@davemloft.net Fri Mar 11 13:23:15 2005 Received: with ECARTIS (v1.0.0; list netdev); Fri, 11 Mar 2005 13:23:23 -0800 (PST) Received: from cheetah.davemloft.net (mail@dsl027-180-174.sfo1.dsl.speakeasy.net [216.27.180.174]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j2BLNFUE003203 for ; Fri, 11 Mar 2005 13:23:15 -0800 Received: from localhost ([127.0.0.1] helo=cheetah.davemloft.net ident=davem) by cheetah.davemloft.net with smtp (Exim 3.36 #1 (Debian)) id 1D9pEW-0004KQ-00; Fri, 11 Mar 2005 10:51:36 -0800 Date: Fri, 11 Mar 2005 10:51:36 -0800 From: "David S. Miller" To: Patrick McHardy Cc: dtor_core@ameritech.net, netdev@oss.sgi.com, linux-kernel@vger.kernel.org, netfilter-devel@lists.netfilter.org Subject: Re: Last night Linus bk - netfilter busted? Message-Id: <20050311105136.2a5e4ddc.davem@davemloft.net> In-Reply-To: <4231A498.4020101@trash.net> References: <200503110223.34461.dtor_core@ameritech.net> <4231A498.4020101@trash.net> X-Mailer: Sylpheed version 1.0.1 (GTK+ 1.2.10; sparc-unknown-linux-gnu) X-Face: "_;p5u5aPsO,_Vsx"^v-pEq09'CU4&Dc1$fQExov$62l60cgCc%FnIwD=.UF^a>?5'9Kn[;433QFVV9M..2eN.@4ZWPGbdi<=?[:T>y?SD(R*-3It"Vj:)"dP Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV version 0.83, clamav-milter version 0.83 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 9 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: davem@davemloft.net Precedence: bulk X-list: netdev Content-Length: 918 Lines: 21 On Fri, 11 Mar 2005 15:00:56 +0100 Patrick McHardy wrote: > Works fine here. You could try if reverting one of these two patches > helps (second one only if its a SMP box). > > ChangeSet@1.2010, 2005-03-09 20:28:17-08:00, bdschuym@pandora.be > [NETFILTER]: Reduce call chain length in netfilter (take 2) It's this change, I know it is, because Linus sees the same problem on his workstation. You wouldn't happen to be seeing this problem on a PPC box would you? Since Linus's machine is a PPC machine too, that would support my theory that this could be a compiler issue on that platform. Damn, wait, Patrick, I think I know what's happening. The iptables IPT_* verdicts are dependant upon the NF_* values, and they don't cope with Bart's changes I bet. Can you figure out what the exact error would be? This kind of issue would explain the looping inside of ipt_do_table(), wouldn't it? From herbert@gondor.apana.org.au Fri Mar 11 13:23:54 2005 Received: with ECARTIS (v1.0.0; list netdev); Fri, 11 Mar 2005 13:24:04 -0800 (PST) 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 j2BLNp5o003479 for ; Fri, 11 Mar 2005 13:23:52 -0800 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 1D9rbO-000693-00; Sat, 12 Mar 2005 08:23:22 +1100 Received: from herbert by gondolin.me.apana.org.au with local (Exim 3.36 #1 (Debian)) id 1D9rZX-0004KE-00; Sat, 12 Mar 2005 08:21:28 +1100 From: Herbert Xu To: kaber@trash.net (Patrick McHardy) Subject: Re: Last night Linus bk - netfilter busted? Cc: davem@davemloft.net, dtor_core@ameritech.net, netdev@oss.sgi.com, linux-kernel@vger.kernel.org, netfilter-devel@lists.netfilter.org Organization: Core In-Reply-To: <4232044E.8030001@trash.net> X-Newsgroups: apana.lists.os.linux.kernel,apana.lists.os.linux.netdev User-Agent: tin/1.7.4-20040225 ("Benbecula") (UNIX) (Linux/2.4.27-hx-1-686-smp (i686)) Message-Id: Date: Sat, 12 Mar 2005 08:21:28 +1100 X-Virus-Scanned: ClamAV version 0.83, clamav-milter version 0.83 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 10 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: herbert@gondor.apana.org.au Precedence: bulk X-list: netdev Content-Length: 578 Lines: 16 Patrick McHardy wrote: > > You're right, good catch. IPT_RETURN is interpreted internally by > ip_tables, but since the value changed it isn't recognized by ip_tables > anymore and returned to nf_iterate() as NF_REPEAT. This patch restores > the old value. Please fix netfilter_arp while you're at it since it does exactly the same thing. Cheers, -- Visit Openswan at http://www.openswan.org/ Email: Herbert Xu ~{PmV>HI~} Home Page: http://gondor.apana.org.au/~herbert/ PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt From garzik@havoc.gtf.org Fri Mar 11 13:30:49 2005 Received: with ECARTIS (v1.0.0; list netdev); Fri, 11 Mar 2005 13:30:57 -0800 (PST) Received: from bastet.signetmail.com (atlmail.prod.rxgsys.com [64.74.124.160]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j2BLUkm2006745 for ; Fri, 11 Mar 2005 13:30:48 -0800 Received: from localhost (localhost.localdomain [127.0.0.1]) by bastet.signetmail.com (RXG Elite Mail Server) with ESMTP id 3CA68A8830; Fri, 11 Mar 2005 14:25:53 -0500 (EST) Received: from bastet.signetmail.com ([127.0.0.1]) by localhost (atlmail.prod.rxgsys.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 14452-10; Fri, 11 Mar 2005 14:25:51 -0500 (EST) Received: from havoc.gtf.org (havoc.gtf.org [63.115.148.101]) by bastet.signetmail.com (RXG Elite Mail Server) with ESMTP id 12FCEA87A1; Fri, 11 Mar 2005 14:25:47 -0500 (EST) Received: from havoc.gtf.org (havoc.gtf.org [127.0.0.1]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by havoc.gtf.org (Postfix) with ESMTP id 97B8D1C0C465; Fri, 11 Mar 2005 14:32:11 -0500 (EST) Received: (from garzik@localhost) by havoc.gtf.org (8.13.1/8.13.1/Submit) id j2BJW5CG023159; Fri, 11 Mar 2005 14:32:05 -0500 Date: Fri, 11 Mar 2005 14:32:05 -0500 From: Jeff Garzik To: Daniele Venzano Cc: Chris Wright , stable@kernel.org, Linux Kernel , Netdev Subject: Re: [stable] [BK PATCHES] 2.6.x net driver oops fixes Message-ID: <20050311193205.GA23140@havoc.gtf.org> References: <422F59E8.2090707@pobox.com> <20050310202548.GV5389@shell0.pdx.osdl.net> <4230AE24.602@pobox.com> <20050310213917.GW5389@shell0.pdx.osdl.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.1i X-Virus-Scanned: ClamAV version 0.83, clamav-milter version 0.83 on oss.sgi.com X-Virus-Scanned: by EMS at localhost.localdomain X-Virus-Status: Clean X-archive-position: 11 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: jgarzik@pobox.com Precedence: bulk X-list: netdev Content-Length: 431 Lines: 15 On Fri, Mar 11, 2005 at 08:29:50PM +0100, Daniele Venzano wrote: > I have been acting maintainer for more than a year now, and I'm > completely fine with the patch. > > A lot of time ago (2.6.6) I proposed a patch to update MAINTAINERS, but > Jeff said he wanted to wait some time. I don't know if such change is > now possible/wanted. > AFAIK Ollie's email address bounces. Feel free to send a patch to MAINTAINERS Jeff From kaber@trash.net Fri Mar 11 13:33:21 2005 Received: with ECARTIS (v1.0.0; list netdev); Fri, 11 Mar 2005 13:33:30 -0800 (PST) Received: from kaber.coreworks.de ([62.206.217.67]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j2BLXHUx007606 for ; Fri, 11 Mar 2005 13:33:19 -0800 Received: from localhost ([127.0.0.1]) by kaber.coreworks.de with esmtp (Exim 4.50) id 1D9r4Q-0000uo-NC; Fri, 11 Mar 2005 21:49:18 +0100 Message-ID: <4232044E.8030001@trash.net> Date: Fri, 11 Mar 2005 21:49:18 +0100 From: Patrick McHardy User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.7.5) Gecko/20050106 Debian/1.7.5-1 X-Accept-Language: en MIME-Version: 1.0 To: "David S. Miller" CC: dtor_core@ameritech.net, netdev@oss.sgi.com, linux-kernel@vger.kernel.org, netfilter-devel@lists.netfilter.org Subject: Re: Last night Linus bk - netfilter busted? References: <200503110223.34461.dtor_core@ameritech.net> <4231A498.4020101@trash.net> <20050311105136.2a5e4ddc.davem@davemloft.net> In-Reply-To: <20050311105136.2a5e4ddc.davem@davemloft.net> Content-Type: multipart/mixed; boundary="------------000409040102040404030604" X-Virus-Scanned: ClamAV version 0.83, clamav-milter version 0.83 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 12 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: kaber@trash.net Precedence: bulk X-list: netdev Content-Length: 2524 Lines: 71 This is a multi-part message in MIME format. --------------000409040102040404030604 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit David S. Miller wrote: > Damn, wait, Patrick, I think I know what's happening. The iptables > IPT_* verdicts are dependant upon the NF_* values, and they don't > cope with Bart's changes I bet. Can you figure out what the exact > error would be? This kind of issue would explain the looping inside > of ipt_do_table(), wouldn't it? You're right, good catch. IPT_RETURN is interpreted internally by ip_tables, but since the value changed it isn't recognized by ip_tables anymore and returned to nf_iterate() as NF_REPEAT. This patch restores the old value. --------------000409040102040404030604 Content-Type: text/plain; name="x" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="x" # This is a BitKeeper generated diff -Nru style patch. # # ChangeSet # 2005/03/11 21:41:01+01:00 kaber@coreworks.de # [NETFILTER]: Fix iptables userspace compatibility breakage # # Signed-off-by: Patrick McHardy # # include/linux/netfilter_ipv6/ip6_tables.h # 2005/03/11 21:40:52+01:00 kaber@coreworks.de +1 -1 # [NETFILTER]: Fix iptables userspace compatibility breakage # # Signed-off-by: Patrick McHardy # # include/linux/netfilter_ipv4/ip_tables.h # 2005/03/11 21:40:52+01:00 kaber@coreworks.de +1 -1 # [NETFILTER]: Fix iptables userspace compatibility breakage # # Signed-off-by: Patrick McHardy # diff -Nru a/include/linux/netfilter_ipv4/ip_tables.h b/include/linux/netfilter_ipv4/ip_tables.h --- a/include/linux/netfilter_ipv4/ip_tables.h 2005-03-11 21:41:32 +01:00 +++ b/include/linux/netfilter_ipv4/ip_tables.h 2005-03-11 21:41:32 +01:00 @@ -166,7 +166,7 @@ #define IPT_CONTINUE 0xFFFFFFFF /* For standard target */ -#define IPT_RETURN (-NF_MAX_VERDICT - 1) +#define IPT_RETURN (-NF_REPEAT - 1) /* TCP matching stuff */ struct ipt_tcp diff -Nru a/include/linux/netfilter_ipv6/ip6_tables.h b/include/linux/netfilter_ipv6/ip6_tables.h --- a/include/linux/netfilter_ipv6/ip6_tables.h 2005-03-11 21:41:32 +01:00 +++ b/include/linux/netfilter_ipv6/ip6_tables.h 2005-03-11 21:41:32 +01:00 @@ -166,7 +166,7 @@ #define IP6T_CONTINUE 0xFFFFFFFF /* For standard target */ -#define IP6T_RETURN (-NF_MAX_VERDICT - 1) +#define IP6T_RETURN (-NF_REPEAT - 1) /* TCP matching stuff */ struct ip6t_tcp --------------000409040102040404030604-- From baruch@ev-en.org Fri Mar 11 13:37:56 2005 Received: with ECARTIS (v1.0.0; list netdev); Fri, 11 Mar 2005 13:38:12 -0800 (PST) Received: from galon.ev-en.org ([24.123.59.149]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j2BLbtbu008972 for ; Fri, 11 Mar 2005 13:37:56 -0800 Received: by galon.ev-en.org (Postfix, from userid 105) id 27CCB11AA2D; Fri, 11 Mar 2005 18:07:51 +0200 (IST) Received: from galon.ev-en.org (galon.ev-en.org [127.0.0.1]) by galon.ev-en.org (Postfix) with ESMTP id 99FB511A6C8; Fri, 11 Mar 2005 18:07:34 +0200 (IST) From: Baruch Even To: "David S.Miller" Cc: linux-net@vger.kernel.org, netdev@oss.sgi.com, Baruch Even , Douglas Leith , Stephen Hemminger Message-Id: <20050311160734.30424.67955.65942@galon.ev-en.org> Subject: [RFC INTRO 0/5] H-TCP congestion control Date: Fri, 11 Mar 2005 18:07:34 +0200 (IST) X-Virus-Scanned: ClamAV version 0.83, clamav-milter version 0.83 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 13 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: baruch@ev-en.org Precedence: bulk X-list: netdev Content-Length: 769 Lines: 15 The following patches are the result of the work of Douglas Leith to implement the H-TCP congestion control proposal. They have since been modified by me (Baruch Even) to port them to kernel 2.6.x, test them and tune them. All patches are against Linux kernel version 2.6.11-bk6. This is currently a preliminary work and is presented for review in order to receive comments to improve this work so it can be accepted to mainline Linux Kernel. The initial development was to add H-TCP to the Linux kernel for testing purposes, it became evident that on 1 Gbit/s links Linux is unable to process the received ack stream fast enough to handle the load. We have patches for that but they proved too hard to be ported to 2.6.11+, we are currently working on them. Baruch From baruch@ev-en.org Fri Mar 11 13:37:56 2005 Received: with ECARTIS (v1.0.0; list netdev); Fri, 11 Mar 2005 13:38:16 -0800 (PST) Received: from galon.ev-en.org ([24.123.59.149]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j2BLbtDH008963 for ; Fri, 11 Mar 2005 13:37:56 -0800 Received: by galon.ev-en.org (Postfix, from userid 105) id 6940911AA2F; Fri, 11 Mar 2005 18:10:53 +0200 (IST) Received: from galon.ev-en.org (galon.ev-en.org [127.0.0.1]) by galon.ev-en.org (Postfix) with ESMTP id F01A611A6C8; Fri, 11 Mar 2005 18:10:39 +0200 (IST) From: Baruch Even To: "David S.Miller" Cc: linux-net@vger.kernel.org, netdev@oss.sgi.com, Baruch Even , Douglas Leith , Stephen Hemminger Message-Id: <20050311161039.30424.15240.63353@galon.ev-en.org> In-Reply-To: <20050311160734.30424.67955.65942@galon.ev-en.org> References: <20050311160734.30424.67955.65942@galon.ev-en.org> Subject: [RFC PATCH 3/5] Adjust alpha to 2*(1-beta) Date: Fri, 11 Mar 2005 18:10:39 +0200 (IST) X-Virus-Scanned: ClamAV version 0.83, clamav-milter version 0.83 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 15 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: baruch@ev-en.org Precedence: bulk X-list: netdev Content-Length: 2461 Lines: 78 Update alpha to be related to beta so that fairness between flows will be preserved. See article for details. Signed-Off-By: Douglas Leith Signed-Off-By: Baruch Even Index: 2.6.12-rc/net/ipv4/tcp_input.c =================================================================== --- 2.6.12-rc.orig/net/ipv4/tcp_input.c +++ 2.6.12-rc/net/ipv4/tcp_input.c @@ -106,6 +106,7 @@ int sysctl_tcp_bic_beta = 819; /* = 819 int sysctl_tcp_htcp = 1; int sysctl_tcp_htcp_modeswitch = 1; int sysctl_tcp_htcp_alpha_func = 1; +int sysctl_tcp_htcp_alpha_adjust = 1; #define FLAG_DATA 0x01 /* Incoming frame contained data. */ #define FLAG_WIN_UPDATE 0x02 /* Incoming ACK was a window update. */ @@ -2131,7 +2132,15 @@ static inline void reno_cong_avoid(struc } } - tp->htcp.snd_alpha = alpha; + if (sysctl_tcp_htcp_alpha_adjust) { + alpha = alpha*2*((1<<7)-tp->htcp.snd_beta); + if (!alpha) + alpha = 1<<7; + } + else + alpha <<= 7; + + tp->htcp.snd_alpha = alpha>>7; tp->snd_cwnd_cnt++; if ((tp->snd_cwnd_cnt*alpha)>>7 > tp->snd_cwnd) { Index: 2.6.12-rc/include/net/tcp.h =================================================================== --- 2.6.12-rc.orig/include/net/tcp.h +++ 2.6.12-rc/include/net/tcp.h @@ -615,6 +615,7 @@ extern int sysctl_tcp_tso_win_divisor; extern int sysctl_tcp_htcp; extern int sysctl_tcp_htcp_modeswitch; extern int sysctl_tcp_htcp_alpha_func; +extern int sysctl_tcp_htcp_alpha_adjust; extern atomic_t tcp_memory_allocated; extern atomic_t tcp_sockets_allocated; Index: 2.6.12-rc/net/ipv4/sysctl_net_ipv4.c =================================================================== --- 2.6.12-rc.orig/net/ipv4/sysctl_net_ipv4.c +++ 2.6.12-rc/net/ipv4/sysctl_net_ipv4.c @@ -714,6 +714,14 @@ ctl_table ipv4_table[] = { .mode = 0644, .proc_handler = &proc_dointvec, }, + { + .ctl_name = NET_TCP_HTCP_ALPHA_ADJUST, + .procname = "tcp_htcp_alpha_adjust", + .data = &sysctl_tcp_htcp_alpha_adjust, + .maxlen = sizeof(int), + .mode = 0644, + .proc_handler = &proc_dointvec, + }, { .ctl_name = 0 } }; Index: 2.6.12-rc/include/linux/sysctl.h =================================================================== --- 2.6.12-rc.orig/include/linux/sysctl.h +++ 2.6.12-rc/include/linux/sysctl.h @@ -349,6 +349,7 @@ enum NET_TCP_HTCP=109, NET_TCP_HTCP_MODESWITCH=110, NET_TCP_HTCP_ALPHA_FUNC=111, + NET_TCP_HTCP_ALPHA_ADJUST=112, }; enum { From baruch@ev-en.org Fri Mar 11 13:37:57 2005 Received: with ECARTIS (v1.0.0; list netdev); Fri, 11 Mar 2005 13:38:17 -0800 (PST) Received: from galon.ev-en.org ([24.123.59.149]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j2BLbuUc008974 for ; Fri, 11 Mar 2005 13:37:56 -0800 Received: by galon.ev-en.org (Postfix, from userid 105) id 9ED7D11AA31; Fri, 11 Mar 2005 18:13:46 +0200 (IST) Received: from galon.ev-en.org (galon.ev-en.org [127.0.0.1]) by galon.ev-en.org (Postfix) with ESMTP id 476AB11AA33; Fri, 11 Mar 2005 18:12:47 +0200 (IST) From: Baruch Even To: "David S.Miller" Cc: linux-net@vger.kernel.org, netdev@oss.sgi.com, Baruch Even , Douglas Leith , Stephen Hemminger Message-Id: <20050311161242.30424.92575.64606@galon.ev-en.org> In-Reply-To: <20050311160734.30424.67955.65942@galon.ev-en.org> References: <20050311160734.30424.67955.65942@galon.ev-en.org> Subject: [RFC PATCH 5/5] Switch in/out of beta=minrtt/maxrtt by bandwidth Date: Fri, 11 Mar 2005 18:12:47 +0200 (IST) X-Virus-Scanned: ClamAV version 0.83, clamav-milter version 0.83 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 17 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: baruch@ev-en.org Precedence: bulk X-list: netdev Content-Length: 2870 Lines: 80 Reset beta when bandwidth usage changes drastically, we have completely new network conditions. Signed-Off-By: Douglas Leith Signed-Off-By: Baruch Even Index: 2.6.12-rc/include/net/tcp.h =================================================================== --- 2.6.12-rc.orig/include/net/tcp.h +++ 2.6.12-rc/include/net/tcp.h @@ -613,6 +613,7 @@ extern int sysctl_tcp_bic_beta; extern int sysctl_tcp_moderate_rcvbuf; extern int sysctl_tcp_tso_win_divisor; extern int sysctl_tcp_htcp; +extern int sysctl_tcp_htcp_bandwidth_switch; extern int sysctl_tcp_htcp_modeswitch; extern int sysctl_tcp_htcp_alpha_func; extern int sysctl_tcp_htcp_alpha_adjust; @@ -978,12 +979,17 @@ static inline void htcp_beta_check(struc static inline void htcp_beta_update(struct tcp_sock *tp) { + __u32 snd_maxB; + __u32 snd_oldmaxB; + if (!tcp_is_htcp(tp)) return; + snd_maxB = tp->htcp.snd_maxB; + snd_oldmaxB = tp->htcp.snd_oldmaxB; tp->htcp.snd_oldmaxB = tp->htcp.snd_maxB; - if (sysctl_tcp_htcp_modeswitch) { + if ((!sysctl_tcp_htcp_bandwidth_switch || between(5*snd_maxB, 4*snd_oldmaxB, 6*snd_oldmaxB)) && sysctl_tcp_htcp_modeswitch) { if (tp->htcp.snd_modecount && tp->htcp.snd_minRTT>HZ/100 && tp->htcp.snd_maxRTT>0) tp->htcp.snd_beta = (tp->htcp.snd_minRTT<<7)/tp->htcp.snd_maxRTT; else Index: 2.6.12-rc/net/ipv4/tcp_input.c =================================================================== --- 2.6.12-rc.orig/net/ipv4/tcp_input.c +++ 2.6.12-rc/net/ipv4/tcp_input.c @@ -104,6 +104,7 @@ int sysctl_tcp_bic_fast_convergence = 1; int sysctl_tcp_bic_low_window = 14; int sysctl_tcp_bic_beta = 819; /* = 819/1024 (BICTCP_BETA_SCALE) */ int sysctl_tcp_htcp = 1; +int sysctl_tcp_htcp_bandwidth_switch = 1; int sysctl_tcp_htcp_modeswitch = 1; int sysctl_tcp_htcp_alpha_func = 1; int sysctl_tcp_htcp_alpha_adjust = 1; Index: 2.6.12-rc/net/ipv4/sysctl_net_ipv4.c =================================================================== --- 2.6.12-rc.orig/net/ipv4/sysctl_net_ipv4.c +++ 2.6.12-rc/net/ipv4/sysctl_net_ipv4.c @@ -699,6 +699,14 @@ ctl_table ipv4_table[] = { .proc_handler = &proc_dointvec, }, { + .ctl_name = NET_TCP_HTCP_BANDWIDTH_SWITCH, + .procname = "tcp_htcp_bandwidth_switch", + .data = &sysctl_tcp_htcp_bandwidth_switch, + .maxlen = sizeof(int), + .mode = 0644, + .proc_handler = &proc_dointvec, + }, + { .ctl_name = NET_TCP_HTCP_MODESWITCH, .procname = "tcp_htcp_modeswitch", .data = &sysctl_tcp_htcp_modeswitch, Index: 2.6.12-rc/include/linux/sysctl.h =================================================================== --- 2.6.12-rc.orig/include/linux/sysctl.h +++ 2.6.12-rc/include/linux/sysctl.h @@ -351,6 +351,7 @@ enum NET_TCP_HTCP_ALPHA_FUNC=111, NET_TCP_HTCP_ALPHA_ADJUST=112, NET_TCP_HTCP_RTT_SCALING=113, + NET_TCP_HTCP_BANDWIDTH_SWITCH=114, }; enum { From baruch@ev-en.org Fri Mar 11 13:37:57 2005 Received: with ECARTIS (v1.0.0; list netdev); Fri, 11 Mar 2005 13:38:16 -0800 (PST) Received: from galon.ev-en.org ([24.123.59.149]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j2BLbubl008976 for ; Fri, 11 Mar 2005 13:37:56 -0800 Received: by galon.ev-en.org (Postfix, from userid 105) id 7A84711AA2B; Fri, 11 Mar 2005 18:12:37 +0200 (IST) Received: from galon.ev-en.org (galon.ev-en.org [127.0.0.1]) by galon.ev-en.org (Postfix) with ESMTP id 190BD11A6C8; Fri, 11 Mar 2005 18:11:41 +0200 (IST) From: Baruch Even To: "David S.Miller" Cc: linux-net@vger.kernel.org, netdev@oss.sgi.com, Baruch Even , Douglas Leith , Stephen Hemminger Message-Id: <20050311161141.30424.47574.20943@galon.ev-en.org> In-Reply-To: <20050311160734.30424.67955.65942@galon.ev-en.org> References: <20050311160734.30424.67955.65942@galon.ev-en.org> Subject: [RFC PATCH 4/5] Adjust alpha according to RTT timing Date: Fri, 11 Mar 2005 18:11:41 +0200 (IST) X-Virus-Scanned: ClamAV version 0.83, clamav-milter version 0.83 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 14 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: baruch@ev-en.org Precedence: bulk X-list: netdev Content-Length: 2525 Lines: 77 Do RTT scaling on alpha. Signed-Off-By: Douglas Leith Signed-Off-By: Baruch Even Index: 2.6.12-rc/net/ipv4/tcp_input.c =================================================================== --- 2.6.12-rc.orig/net/ipv4/tcp_input.c +++ 2.6.12-rc/net/ipv4/tcp_input.c @@ -107,6 +107,7 @@ int sysctl_tcp_htcp = 1; int sysctl_tcp_htcp_modeswitch = 1; int sysctl_tcp_htcp_alpha_func = 1; int sysctl_tcp_htcp_alpha_adjust = 1; +int sysctl_tcp_htcp_rtt_scaling = 1; #define FLAG_DATA 0x01 /* Incoming frame contained data. */ #define FLAG_WIN_UPDATE 0x02 /* Incoming ACK was a window update. */ @@ -2132,6 +2133,16 @@ static inline void reno_cong_avoid(struc } } + if (sysctl_tcp_htcp_rtt_scaling) { + __u32 RTT_Scaling; + /* refer current RTT to design point, clamping ratio to interval [0.5,10] */ + RTT_Scaling = max((HZ<<3)/(10*tp->htcp.snd_minRTT), (__u32)1<<2); + RTT_Scaling = min(RTT_Scaling,(__u32)10<<3); + alpha = (alpha<<3)/RTT_Scaling; + if (!alpha) + alpha = 1; + } + if (sysctl_tcp_htcp_alpha_adjust) { alpha = alpha*2*((1<<7)-tp->htcp.snd_beta); if (!alpha) Index: 2.6.12-rc/net/ipv4/sysctl_net_ipv4.c =================================================================== --- 2.6.12-rc.orig/net/ipv4/sysctl_net_ipv4.c +++ 2.6.12-rc/net/ipv4/sysctl_net_ipv4.c @@ -722,6 +722,14 @@ ctl_table ipv4_table[] = { .mode = 0644, .proc_handler = &proc_dointvec, }, + { + .ctl_name = NET_TCP_HTCP_RTT_SCALING, + .procname = "tcp_htcp_rtt_scaling", + .data = &sysctl_tcp_htcp_rtt_scaling, + .maxlen = sizeof(int), + .mode = 0644, + .proc_handler = &proc_dointvec, + }, { .ctl_name = 0 } }; Index: 2.6.12-rc/include/linux/sysctl.h =================================================================== --- 2.6.12-rc.orig/include/linux/sysctl.h +++ 2.6.12-rc/include/linux/sysctl.h @@ -350,6 +350,7 @@ enum NET_TCP_HTCP_MODESWITCH=110, NET_TCP_HTCP_ALPHA_FUNC=111, NET_TCP_HTCP_ALPHA_ADJUST=112, + NET_TCP_HTCP_RTT_SCALING=113, }; enum { Index: 2.6.12-rc/include/net/tcp.h =================================================================== --- 2.6.12-rc.orig/include/net/tcp.h +++ 2.6.12-rc/include/net/tcp.h @@ -616,6 +616,7 @@ extern int sysctl_tcp_htcp; extern int sysctl_tcp_htcp_modeswitch; extern int sysctl_tcp_htcp_alpha_func; extern int sysctl_tcp_htcp_alpha_adjust; +extern int sysctl_tcp_htcp_rtt_scaling; extern atomic_t tcp_memory_allocated; extern atomic_t tcp_sockets_allocated; From baruch@ev-en.org Fri Mar 11 13:37:57 2005 Received: with ECARTIS (v1.0.0; list netdev); Fri, 11 Mar 2005 13:38:17 -0800 (PST) Received: from galon.ev-en.org ([24.123.59.149]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j2BLbupd008973 for ; Fri, 11 Mar 2005 13:37:56 -0800 Received: by galon.ev-en.org (Postfix, from userid 105) id 280D611AA2C; Fri, 11 Mar 2005 18:09:06 +0200 (IST) Received: from galon.ev-en.org (galon.ev-en.org [127.0.0.1]) by galon.ev-en.org (Postfix) with ESMTP id F239111A6C8; Fri, 11 Mar 2005 18:08:35 +0200 (IST) From: Baruch Even To: "David S.Miller" Cc: linux-net@vger.kernel.org, netdev@oss.sgi.com, Baruch Even , Douglas Leith , Stephen Hemminger Message-Id: <20050311160835.30424.23960.13323@galon.ev-en.org> In-Reply-To: <20050311160734.30424.67955.65942@galon.ev-en.org> References: <20050311160734.30424.67955.65942@galon.ev-en.org> Subject: [RFC PATCH 1/5] Implement H-TCP congestion control algorithm Date: Fri, 11 Mar 2005 18:08:35 +0200 (IST) X-Virus-Scanned: ClamAV version 0.83, clamav-milter version 0.83 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 16 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: baruch@ev-en.org Precedence: bulk X-list: netdev Content-Length: 15281 Lines: 476 H-TCP implementation. H-TCP is an improved congestion control algorithm for TCP which aims to work on the regular networks and high-speed networks, and provide maximum bandwidth utilization while maintaining relative fairness between TCP and H-TCP streams. You can find more information on H-TCP at http://hamilton.ie/net/ Signed-Off-By: Douglas Leith Signed-Off-By: Baruch Even Index: 2.6.12-rc/include/linux/sysctl.h =================================================================== --- 2.6.12-rc.orig/include/linux/sysctl.h +++ 2.6.12-rc/include/linux/sysctl.h @@ -346,6 +346,8 @@ enum NET_TCP_MODERATE_RCVBUF=106, NET_TCP_TSO_WIN_DIVISOR=107, NET_TCP_BIC_BETA=108, + NET_TCP_HTCP=109, + NET_TCP_HTCP_MODESWITCH=110, }; enum { Index: 2.6.12-rc/include/linux/tcp.h =================================================================== --- 2.6.12-rc.orig/include/linux/tcp.h +++ 2.6.12-rc/include/linux/tcp.h @@ -208,6 +208,7 @@ enum tcp_congestion_algo { TCP_VEGAS, TCP_WESTWOOD, TCP_BIC, + TCP_HTCP, }; struct tcp_options_received { @@ -437,6 +438,27 @@ struct tcp_sock { __u32 last_cwnd; /* the last snd_cwnd */ __u32 last_stamp; /* time when updated last_cwnd */ } bictcp; + + /* HTCP variables */ + struct { + __u16 snd_ccount; /* number of RTT's since last back-off */ + __u16 snd_cwnd_cnt2; /* counter used as part of snd_ccount calculation */ + __u32 snd_minRTT; /* minimum RTT */ + __u32 snd_maxRTT; /* max RTT */ + __u32 snd_packetcount;/* number of packets acked since snd_lasttime */ + __u32 snd_lasttime; + __u32 snd_minB; /* throughput just after a backoff event */ + __u32 snd_maxB; /* max throughput achieved in current congestion epoch */ + __u32 snd_oldmaxB; /* max throughput achieved in previous congestion epoch */ + __u32 snd_Bi; /* current achieved throughput */ + __u32 snd_modecount; + __u32 snd_alpha; /* current cwnd increase rate */ + __u32 undo_modecount; + __u32 undo_oldmaxB; + __u32 undo_maxRTT; + __u16 undo_ccount; + __u8 snd_beta; /* current backoff factor <<7 */ + } htcp; }; static inline struct tcp_sock *tcp_sk(const struct sock *sk) Index: 2.6.12-rc/include/net/tcp.h =================================================================== --- 2.6.12-rc.orig/include/net/tcp.h +++ 2.6.12-rc/include/net/tcp.h @@ -562,6 +562,10 @@ static __inline__ int tcp_sk_listen_hash #define TCP_NAGLE_CORK 2 /* Socket is corked */ #define TCP_NAGLE_PUSH 4 /* Cork is overriden for already queued data */ +/* HTCP constants */ +#define HTCP_BETA_MIN (1<<6) /* 0.5 with shift << 7 */ +#define HTCP_BETA_MAX 102 /* 0.8 with shift << 7 */ + /* sysctl variables for tcp */ extern int sysctl_max_syn_backlog; extern int sysctl_tcp_timestamps; @@ -608,6 +612,8 @@ extern int sysctl_tcp_bic_low_window; extern int sysctl_tcp_bic_beta; extern int sysctl_tcp_moderate_rcvbuf; extern int sysctl_tcp_tso_win_divisor; +extern int sysctl_tcp_htcp; +extern int sysctl_tcp_htcp_modeswitch; extern atomic_t tcp_memory_allocated; extern atomic_t tcp_sockets_allocated; @@ -930,6 +936,124 @@ extern void tcp_unhash(struct sock *sk extern int tcp_v4_hash_connecting(struct sock *sk); +/* TCP timestamps are only 32-bits, this causes a slight + * complication on 64-bit systems since we store a snapshot + * of jiffies in the buffer control blocks below. We decidely + * only use of the low 32-bits of jiffies and hide the ugly + * casts with the following macro. + */ +#define tcp_time_stamp ((__u32)(jiffies)) + +/* + * 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) +#define tcp_is_htcp(__tp) ((__tp)->adv_cong == TCP_HTCP) + +static inline void htcp_reset(struct tcp_sock *tp) +{ + BUG_TRAP(tp!=NULL); + + tp->htcp.undo_ccount = tp->htcp.snd_ccount; + tp->htcp.undo_oldmaxB = tp->htcp.snd_oldmaxB; + tp->htcp.undo_modecount = tp->htcp.snd_modecount; + tp->htcp.undo_maxRTT = tp->htcp.snd_maxRTT; + + tp->htcp.snd_ccount = 0; + tp->htcp.snd_cwnd_cnt2 = 0; +} + +static inline void htcp_beta_check(struct tcp_sock *tp) +{ + if (tp->htcp.snd_beta < HTCP_BETA_MIN) + tp->htcp.snd_beta = HTCP_BETA_MIN; + if (tp->htcp.snd_beta > HTCP_BETA_MAX) + tp->htcp.snd_beta = HTCP_BETA_MAX; +} + +static inline void htcp_beta_update(struct tcp_sock *tp) +{ + if (!tcp_is_htcp(tp)) + return; + + tp->htcp.snd_oldmaxB = tp->htcp.snd_maxB; + + if (sysctl_tcp_htcp_modeswitch) { + if (tp->htcp.snd_modecount && tp->htcp.snd_minRTT>HZ/100 && tp->htcp.snd_maxRTT>0) + tp->htcp.snd_beta = (tp->htcp.snd_minRTT<<7)/tp->htcp.snd_maxRTT; + else + tp->htcp.snd_beta = HTCP_BETA_MIN; + tp->htcp.snd_modecount++; + } else { + tp->htcp.snd_modecount = 0; + tp->htcp.snd_beta = HTCP_BETA_MIN; + } + htcp_beta_check(tp); + + /* add slowly fading memory for maxRTT to accommodate routing changes etc */ + if (tp->htcp.snd_minRTT > 0 && tp->htcp.snd_maxRTT > tp->htcp.snd_minRTT) + tp->htcp.snd_maxRTT = tp->htcp.snd_minRTT + ((tp->htcp.snd_maxRTT-tp->htcp.snd_minRTT)*95)/100; +} + +static inline void undo_htcp_reset(struct tcp_sock *tp) +{ + BUG_TRAP(tp!=NULL); + + tp->htcp.snd_modecount = tp->htcp.undo_modecount; + tp->htcp.snd_oldmaxB = tp->htcp.undo_oldmaxB; + tp->htcp.snd_ccount = tp->htcp.undo_ccount; + tp->htcp.snd_maxRTT = tp->htcp.undo_maxRTT; +} + +static inline void measure_minRTT(struct tcp_sock *tp) +{ + /* keep track of minimum RTT seen so far, minRTT is zero at first */ + if (tp->htcp.snd_minRTT > tp->srtt>>3 || tp->htcp.snd_minRTT == 0) + tp->htcp.snd_minRTT = tp->srtt>>3; + if (tp->htcp.snd_minRTT == 0) + tp->htcp.snd_minRTT = 1; /* Avoid divide by zero */ + + /* max RTT */ + if (tp->ca_state == TCP_CA_Open && tp->snd_ssthresh < 0xFFFF && tp->htcp.snd_ccount > 3) { + if (tp->htcp.snd_maxRTT < tp->htcp.snd_minRTT) + tp->htcp.snd_maxRTT = tp->htcp.snd_minRTT; + if (tp->srtt>>3 > tp->htcp.snd_maxRTT && tp->srtt>>3 <= tp->htcp.snd_maxRTT+HZ/50) + tp->htcp.snd_maxRTT = tp->srtt>>3; + } +} + +static inline void measure_achieved_throughput(struct tcp_sock *tp) +{ + __u32 now = tcp_time_stamp; + + /* achieved throughput calculations */ + if (tp->ca_state != TCP_CA_Open && tp->ca_state != TCP_CA_Disorder) { + tp->htcp.snd_packetcount = 0; + tp->htcp.snd_lasttime = now; + return; + } + + if (tp->htcp.snd_packetcount >= tp->snd_cwnd-tp->htcp.snd_alpha + && now - tp->htcp.snd_lasttime >= tp->htcp.snd_minRTT + && tp->htcp.snd_minRTT>0) { + __u32 cur_Bi = tp->htcp.snd_packetcount*HZ/(now - tp->htcp.snd_lasttime); + if (tp->htcp.snd_ccount <=3) { + // just after backoff + tp->htcp.snd_minB = tp->htcp.snd_maxB = tp->htcp.snd_Bi = cur_Bi; + } else { + tp->htcp.snd_Bi = (3*tp->htcp.snd_Bi + cur_Bi)/4; + if (tp->htcp.snd_Bi > tp->htcp.snd_maxB) + tp->htcp.snd_maxB = tp->htcp.snd_Bi; + if (tp->htcp.snd_minB > tp->htcp.snd_maxB) + tp->htcp.snd_minB = tp->htcp.snd_maxB; //sanity check + } + tp->htcp.snd_packetcount = 0; + tp->htcp.snd_lasttime = now; + } +} + /* From syncookies.c */ extern struct sock *cookie_v4_check(struct sock *sk, struct sk_buff *skb, @@ -1102,14 +1226,6 @@ static __inline__ u32 tcp_receive_window */ extern u32 __tcp_select_window(struct sock *sk); -/* TCP timestamps are only 32-bits, this causes a slight - * complication on 64-bit systems since we store a snapshot - * of jiffies in the buffer control blocks below. We decidely - * only use of the low 32-bits of jiffies and hide the ugly - * casts with the following macro. - */ -#define tcp_time_stamp ((__u32)(jiffies)) - /* This is what the send packet queueing engine uses to pass * TCP per-packet control information to the transmission * code. We also store the host-order sequence numbers in @@ -1222,13 +1338,6 @@ static __inline__ unsigned int tcp_packe 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: @@ -1238,9 +1347,15 @@ static __inline__ unsigned int tcp_packe * BIC: * behave like Reno until low_window is reached, * then increase congestion window slowly + * + * HTCP: + * work as tcp but use a variable alpha. */ static inline __u32 tcp_recalc_ssthresh(struct tcp_sock *tp) { + if (tcp_is_htcp(tp) && sysctl_tcp_htcp_modeswitch) + return max((tp->snd_cwnd*tp->htcp.snd_beta)>>7, 2U); + if (tcp_is_bic(tp)) { if (sysctl_tcp_bic_fast_convergence && tp->snd_cwnd < tp->bictcp.last_max_cwnd) @@ -1354,11 +1469,14 @@ static inline void tcp_cwnd_validate(str /* Set slow start threshould and cwnd not falling to slow start */ static inline void __tcp_enter_cwr(struct tcp_sock *tp) { + htcp_beta_update(tp); + tp->undo_marker = 0; tp->snd_ssthresh = tcp_recalc_ssthresh(tp); tp->snd_cwnd = min(tp->snd_cwnd, tcp_packets_in_flight(tp) + 1U); tp->snd_cwnd_cnt = 0; + htcp_reset(tp); tp->high_seq = tp->snd_nxt; tp->snd_cwnd_stamp = tcp_time_stamp; TCP_ECN_queue_cwr(tp); Index: 2.6.12-rc/net/ipv4/sysctl_net_ipv4.c =================================================================== --- 2.6.12-rc.orig/net/ipv4/sysctl_net_ipv4.c +++ 2.6.12-rc/net/ipv4/sysctl_net_ipv4.c @@ -690,6 +690,22 @@ ctl_table ipv4_table[] = { .mode = 0644, .proc_handler = &proc_dointvec, }, + { + .ctl_name = NET_TCP_HTCP, + .procname = "tcp_htcp", + .data = &sysctl_tcp_htcp, + .maxlen = sizeof(int), + .mode = 0644, + .proc_handler = &proc_dointvec, + }, + { + .ctl_name = NET_TCP_HTCP_MODESWITCH, + .procname = "tcp_htcp_modeswitch", + .data = &sysctl_tcp_htcp_modeswitch, + .maxlen = sizeof(int), + .mode = 0644, + .proc_handler = &proc_dointvec, + }, { .ctl_name = 0 } }; Index: 2.6.12-rc/net/ipv4/tcp_input.c =================================================================== --- 2.6.12-rc.orig/net/ipv4/tcp_input.c +++ 2.6.12-rc/net/ipv4/tcp_input.c @@ -103,6 +103,8 @@ int sysctl_tcp_bic = 1; int sysctl_tcp_bic_fast_convergence = 1; int sysctl_tcp_bic_low_window = 14; int sysctl_tcp_bic_beta = 819; /* = 819/1024 (BICTCP_BETA_SCALE) */ +int sysctl_tcp_htcp = 1; +int sysctl_tcp_htcp_modeswitch = 1; #define FLAG_DATA 0x01 /* Incoming frame contained data. */ #define FLAG_WIN_UPDATE 0x02 /* Incoming ACK was a window update. */ @@ -570,7 +572,9 @@ void tcp_ca_init(struct tcp_sock *tp) tp->adv_cong = TCP_VEGAS; tp->vegas.baseRTT = 0x7fffffff; tcp_vegas_enable(tp); - } + } else if (sysctl_tcp_htcp) { + tp->adv_cong = TCP_HTCP; + } } /* Do RTT sampling needed for Vegas. @@ -1241,7 +1245,8 @@ static void tcp_enter_frto_loss(struct s tcp_sync_left_out(tp); tp->snd_cwnd = tp->frto_counter + tcp_packets_in_flight(tp)+1; - tp->snd_cwnd_cnt = 0; + tp->snd_cwnd_cnt = 0; // BEVEN major change above (used to be: tp->snd_cwnd=1) + htcp_reset(tp); tp->snd_cwnd_stamp = tcp_time_stamp; tp->undo_marker = 0; tp->frto_counter = 0; @@ -1286,6 +1291,7 @@ void tcp_enter_loss(struct sock *sk, int } tp->snd_cwnd = 1; tp->snd_cwnd_cnt = 0; + htcp_reset(tp); tp->snd_cwnd_stamp = tcp_time_stamp; tcp_clear_retrans(tp); @@ -1653,7 +1659,11 @@ static void DBGUNDO(struct sock *sk, str static void tcp_undo_cwr(struct tcp_sock *tp, int undo) { if (tp->prior_ssthresh) { - tp->snd_cwnd = max(tp->snd_cwnd, tp->snd_ssthresh<<1); + if (tcp_is_htcp(tp)) { + tp->snd_cwnd = max(tp->snd_cwnd, (tp->snd_ssthresh<<7)/tp->htcp.snd_beta); + undo_htcp_reset(tp); + } else + tp->snd_cwnd = max(tp->snd_cwnd, tp->snd_ssthresh<<1); if (undo && tp->prior_ssthresh > tp->snd_ssthresh) { tp->snd_ssthresh = tp->prior_ssthresh; @@ -1939,6 +1949,8 @@ tcp_fastretrans_alert(struct sock *sk, u tp->undo_marker = tp->snd_una; tp->undo_retrans = tp->retrans_out; + htcp_beta_update(tp); + if (tp->ca_state < TCP_CA_CWR) { if (!(flag&FLAG_ECE)) tp->prior_ssthresh = tcp_current_ssthresh(tp); @@ -1946,6 +1958,10 @@ tcp_fastretrans_alert(struct sock *sk, u TCP_ECN_queue_cwr(tp); } + htcp_reset(tp); + if (tp->snd_cwnd > tp->htcp.snd_alpha+2) /* account for expected packet loss up front */ + tp->snd_cwnd = tp->snd_cwnd - tp->htcp.snd_alpha; + tp->snd_cwnd_cnt = 0; tcp_set_ca_state(tp, TCP_CA_Recovery); } @@ -2087,18 +2103,43 @@ static inline void reno_cong_avoid(struc /* In "safe" area, increase. */ if (tp->snd_cwnd < tp->snd_cwnd_clamp) tp->snd_cwnd++; + htcp_beta_check(tp); } else { - /* In dangerous area, increase slowly. - * In theory this is tp->snd_cwnd += 1 / tp->snd_cwnd - */ - if (tp->snd_cwnd_cnt >= bictcp_cwnd(tp)) { - if (tp->snd_cwnd < tp->snd_cwnd_clamp) - tp->snd_cwnd++; - tp->snd_cwnd_cnt=0; - } else + /* In dangerous area, increase slowly. */ + + if (tcp_is_htcp(tp)) { + __u32 alpha = 1; + + /* keep track of number of round-trip times since last backoff event */ + if (tp->htcp.snd_cwnd_cnt2 > tp->snd_cwnd) { + tp->htcp.snd_ccount++; + tp->htcp.snd_cwnd_cnt2 = 0; + } else + tp->htcp.snd_cwnd_cnt2++; + + measure_minRTT(tp); + + /* calculate increase rate - alpha is number of packets added to cwnd per RTT */ + tp->htcp.snd_alpha = alpha; + tp->snd_cwnd_cnt++; - } - tp->snd_cwnd_stamp = tcp_time_stamp; + if ((tp->snd_cwnd_cnt*alpha)>>7 > tp->snd_cwnd) { + tp->snd_cwnd++; + tp->snd_cwnd_cnt = 0; + } + } else { + tp->htcp.snd_alpha = 1; + + /* In theory this is tp->snd_cwnd += 1 / tp->snd_cwnd */ + if (tp->snd_cwnd_cnt >= bictcp_cwnd(tp)) { + if (tp->snd_cwnd < tp->snd_cwnd_clamp) + tp->snd_cwnd++; + tp->snd_cwnd_cnt = 0; + } else + tp->snd_cwnd_cnt++; + } + tp->snd_cwnd_stamp = tcp_time_stamp; + } } /* This is based on the congestion detection/avoidance scheme described in @@ -2444,6 +2485,7 @@ static int tcp_clean_rtx_queue(struct so */ if (!(scb->flags & TCPCB_FLAG_SYN)) { acked |= FLAG_DATA_ACKED; + tp->htcp.snd_packetcount++; } else { acked |= FLAG_SYN_ACKED; tp->retrans_stamp = 0; @@ -2479,6 +2521,8 @@ static int tcp_clean_rtx_queue(struct so tcp_ack_packets_out(sk, tp); } + measure_achieved_throughput(tp); + #if FASTRETRANS_DEBUG > 0 BUG_TRAP((int)tp->sacked_out >= 0); BUG_TRAP((int)tp->lost_out >= 0); @@ -2620,6 +2664,13 @@ static void tcp_process_frto(struct sock tp->frto_counter = (tp->frto_counter + 1) % 3; } +static void init_htcp(struct sock *sk) +{ + struct tcp_sock *tp = tcp_sk(sk); + + tp->htcp.snd_beta = HTCP_BETA_MIN; +} + /* * TCP Westwood+ */ @@ -4714,6 +4765,7 @@ int tcp_rcv_state_process(struct sock *s return 1; init_westwood(sk); + init_htcp(sk); init_bictcp(tp); /* Now we have several options: In theory there is @@ -4738,6 +4790,7 @@ int tcp_rcv_state_process(struct sock *s case TCP_SYN_SENT: init_westwood(sk); + init_htcp(sk); init_bictcp(tp); queued = tcp_rcv_synsent_state_process(sk, skb, th, len); From baruch@ev-en.org Fri Mar 11 13:38:23 2005 Received: with ECARTIS (v1.0.0; list netdev); Fri, 11 Mar 2005 13:38:33 -0800 (PST) Received: from galon.ev-en.org ([24.123.59.149]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j2BLcLbE009131 for ; Fri, 11 Mar 2005 13:38:22 -0800 Received: by galon.ev-en.org (Postfix, from userid 105) id D1EFC11AA30; Fri, 11 Mar 2005 20:39:22 +0200 (IST) Received: from [10.220.3.66] (hamilton.nuim.ie [149.157.192.252]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by galon.ev-en.org (Postfix) with ESMTP id 7F94711AA33; Fri, 11 Mar 2005 20:38:50 +0200 (IST) Message-ID: <4231E5B7.2010306@ev-en.org> Date: Fri, 11 Mar 2005 18:38:47 +0000 From: Baruch Even User-Agent: Debian Thunderbird 1.0 (X11/20050116) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Stephen Hemminger Cc: "David S.Miller" , linux-net@vger.kernel.org, netdev@oss.sgi.com, Douglas Leith Subject: Re: [RFC INTRO 0/5] H-TCP congestion control References: <20050311160734.30424.67955.65942@galon.ev-en.org> <20050311094239.4c59c29d@dxpl.pdx.osdl.net> In-Reply-To: <20050311094239.4c59c29d@dxpl.pdx.osdl.net> X-Enigmail-Version: 0.90.0.0 X-Enigmail-Supports: pgp-inline, pgp-mime Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV version 0.83, clamav-milter version 0.83 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 18 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: baruch@ev-en.org Precedence: bulk X-list: netdev Content-Length: 655 Lines: 19 Stephen Hemminger wrote: > On Fri, 11 Mar 2005 18:07:34 +0200 (IST) > Baruch Even wrote: > > Are there any IPR encumberance to this like FAST TCP. Earlier versions of > this patch said: > >>This patch is covered by a pending patent, a license is being worked on to >>enable the inclusion in Linux. Comments and suggestions on this are also >>solicited. > > Has this changed? No. That's why it's an RFC and not a request to add it. The license will be worked out before the actual request for inclusion. Unfortunately, the decision on these matters is not in my hands and is in the channels of the university bureaucracy. Baruch From baruch@ev-en.org Fri Mar 11 13:38:23 2005 Received: with ECARTIS (v1.0.0; list netdev); Fri, 11 Mar 2005 13:38:34 -0800 (PST) Received: from galon.ev-en.org ([24.123.59.149]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j2BLcLfK009132 for ; Fri, 11 Mar 2005 13:38:22 -0800 Received: by galon.ev-en.org (Postfix, from userid 105) id 0AC1E11AA2E; Fri, 11 Mar 2005 18:09:58 +0200 (IST) Received: from galon.ev-en.org (galon.ev-en.org [127.0.0.1]) by galon.ev-en.org (Postfix) with ESMTP id C6E9D11A6C8; Fri, 11 Mar 2005 18:09:38 +0200 (IST) From: Baruch Even To: "David S.Miller" Cc: linux-net@vger.kernel.org, netdev@oss.sgi.com, Baruch Even , Douglas Leith , Stephen Hemminger Message-Id: <20050311160938.30424.87084.26112@galon.ev-en.org> In-Reply-To: <20050311160734.30424.67955.65942@galon.ev-en.org> References: <20050311160734.30424.67955.65942@galon.ev-en.org> Subject: [RFC PATCH 2/5] Adjust alpha according to a function defined in HTCP Date: Fri, 11 Mar 2005 18:09:38 +0200 (IST) X-Virus-Scanned: ClamAV version 0.83, clamav-milter version 0.83 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 19 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: baruch@ev-en.org Precedence: bulk X-list: netdev Content-Length: 2512 Lines: 77 Modify alpha as a function of the time since last backoff. Signed-Off-By: Douglas Leith Signed-Off-By: Baruch Even Index: 2.6.12-rc/net/ipv4/tcp_input.c =================================================================== --- 2.6.12-rc.orig/net/ipv4/tcp_input.c +++ 2.6.12-rc/net/ipv4/tcp_input.c @@ -105,6 +105,7 @@ int sysctl_tcp_bic_low_window = 14; int sysctl_tcp_bic_beta = 819; /* = 819/1024 (BICTCP_BETA_SCALE) */ int sysctl_tcp_htcp = 1; int sysctl_tcp_htcp_modeswitch = 1; +int sysctl_tcp_htcp_alpha_func = 1; #define FLAG_DATA 0x01 /* Incoming frame contained data. */ #define FLAG_WIN_UPDATE 0x02 /* Incoming ACK was a window update. */ @@ -2120,6 +2121,16 @@ static inline void reno_cong_avoid(struc measure_minRTT(tp); /* calculate increase rate - alpha is number of packets added to cwnd per RTT */ + if (sysctl_tcp_htcp_alpha_func) { + /* time since last backoff */ + __u32 diff = tp->htcp.snd_ccount * tp->htcp.snd_minRTT; + + if (diff > HZ) { + diff -= HZ; + alpha += ( 10*diff+((diff>>1)*(diff>>1)/HZ) )/HZ; + } + } + tp->htcp.snd_alpha = alpha; tp->snd_cwnd_cnt++; Index: 2.6.12-rc/include/net/tcp.h =================================================================== --- 2.6.12-rc.orig/include/net/tcp.h +++ 2.6.12-rc/include/net/tcp.h @@ -614,6 +614,7 @@ extern int sysctl_tcp_moderate_rcvbuf; extern int sysctl_tcp_tso_win_divisor; extern int sysctl_tcp_htcp; extern int sysctl_tcp_htcp_modeswitch; +extern int sysctl_tcp_htcp_alpha_func; extern atomic_t tcp_memory_allocated; extern atomic_t tcp_sockets_allocated; Index: 2.6.12-rc/net/ipv4/sysctl_net_ipv4.c =================================================================== --- 2.6.12-rc.orig/net/ipv4/sysctl_net_ipv4.c +++ 2.6.12-rc/net/ipv4/sysctl_net_ipv4.c @@ -706,6 +706,14 @@ ctl_table ipv4_table[] = { .mode = 0644, .proc_handler = &proc_dointvec, }, + { + .ctl_name = NET_TCP_HTCP_ALPHA_FUNC, + .procname = "tcp_htcp_alpha_func", + .data = &sysctl_tcp_htcp_alpha_func, + .maxlen = sizeof(int), + .mode = 0644, + .proc_handler = &proc_dointvec, + }, { .ctl_name = 0 } }; Index: 2.6.12-rc/include/linux/sysctl.h =================================================================== --- 2.6.12-rc.orig/include/linux/sysctl.h +++ 2.6.12-rc/include/linux/sysctl.h @@ -348,6 +348,7 @@ enum NET_TCP_BIC_BETA=108, NET_TCP_HTCP=109, NET_TCP_HTCP_MODESWITCH=110, + NET_TCP_HTCP_ALPHA_FUNC=111, }; enum { From nhorman@redhat.com Fri Mar 11 13:41:24 2005 Received: with ECARTIS (v1.0.0; list netdev); Fri, 11 Mar 2005 13:41:34 -0800 (PST) Received: from mx1.redhat.com (mx1.redhat.com [66.187.233.31]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j2BLfNWG011592 for ; Fri, 11 Mar 2005 13:41:24 -0800 Received: from int-mx1.corp.redhat.com (int-mx1.corp.redhat.com [172.16.52.254]) by mx1.redhat.com (8.12.11/8.12.11) with ESMTP id j2BFmank016849; Fri, 11 Mar 2005 10:48:36 -0500 Received: from localhost.localdomain (hmsendeavour.rdu.redhat.com [172.16.57.156]) by int-mx1.corp.redhat.com (8.11.6/8.11.6) with ESMTP id j2BFman23544; Fri, 11 Mar 2005 10:48:36 -0500 Received: from localhost.localdomain (hmsendeavour [127.0.0.1]) by localhost.localdomain (8.12.8/8.12.8) with ESMTP id j2BFma0H020346; Fri, 11 Mar 2005 10:48:36 -0500 Received: (from nhorman@localhost) by localhost.localdomain (8.12.8/8.12.8/Submit) id j2BFmaxd020344; Fri, 11 Mar 2005 10:48:36 -0500 Date: Fri, 11 Mar 2005 10:48:36 -0500 From: nhorman@redhat.com To: Sridhar Samudrala Cc: nhorman@redhat.com, "David S. Miller" , netdev@oss.sgi.com, lksctp-developers@lists.sourceforge.net Subject: Re: [Patch] sctp: add receive buffer accounting to sctp (fwd) Message-ID: <20050311154836.GC19052@hmsendeavour.rdu.redhat.com> References: <20050309211632.6f70fe41.davem@davemloft.net> <20050310120803.GA6341@hmsendeavour.rdu.redhat.com> <20050310154342.GG6341@hmsendeavour.rdu.redhat.com> <20050310183856.08cb5f7b.davem@davemloft.net> <20050311125724.GB18122@hmsendeavour.rdu.redhat.com> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="UugvWAfsgieZRqgk" Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4i X-Virus-Scanned: ClamAV version 0.83, clamav-milter version 0.83 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 20 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: nhorman@redhat.com Precedence: bulk X-list: netdev Content-Length: 3286 Lines: 124 --UugvWAfsgieZRqgk Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Fri, Mar 11, 2005 at 07:58:50PM +0530, Sridhar Samudrala wrote: > Neil, >=20 > I guess you may not have tried to compile SCTP with this patch.=20 > 2.4 struct sock members do not have sk_ prefix. > So you need to replace sk_rmem_alloc and sk_rcvbuf with rmem_alloc and > rcvbuf. >=20 No, I compiled the kernel, I just forgot to enable CONFIG_IP_SCTP. I must = have booted to a 2.6 kernel on my dev box by accident when I ran the tests. I'm= a dummy, sorry :). I'll repost the patch (after I veryify that I build and t= est the actual code). Regards,=20 Neil > Thanks > Sridhar >=20 > On Fri, 11 Mar 2005 nhorman@redhat.com wrote: >=20 > >On Thu, Mar 10, 2005 at 06:38:56PM -0800, David S. Miller wrote: > >>On Thu, 10 Mar 2005 10:43:42 -0500 > >>nhorman@redhat.com wrote: > >> > >>>Repost of my ealier rcvbuf patch. No changes, but rediffed to apply= =20 > >>>cleanly to > >>>the head of the bitkeeper tree. Passes all lksctp regression tests > >> > >>Applied, thanks Neil. > > > >You're quite welcome. Heres the 2.4 version of the same patch that you > >requested. Applies clean against the bitkeeper head. > > > >Signed-off-by: Neil Horman > > > >[nhorman@hmsendeavour kernel]$ diffstat linux-2.4-sctp.rcvbuf.patch > >input.c | 21 +++++++++++++++++++++ > >1 files changed, 21 insertions(+) > > > > > >--- linux-2.4-sctp/net/sctp/input.c.orig 2005-03-10=20 > >13:36:49.000000000 -0500 > >+++ linux-2.4-sctp/net/sctp/input.c 2005-03-10 13:51:25.000000000 -0500 > >@@ -100,6 +100,21 @@ > > return 0; > >} > > > >+/* The free routine for skbuffs that sctp receives */ > >+static void sctp_rfree(struct sk_buff *skb) > >+{ > >+ atomic_sub(sizeof(struct sctp_chunk),&skb->sk->sk_rmem_alloc); > >+ sock_rfree(skb); > >+} > >+ > >+/* The ownership wrapper routine to do receive buffer accounting */ > >+static void sctp_rcv_set_owner_r(struct sk_buff *skb, struct sock *sk) > >+{ > >+ skb_set_owner_r(skb,sk); > >+ skb->destructor =3D sctp_rfree; > >+ atomic_add(sizeof(struct sctp_chunk),&sk->sk_rmem_alloc); > >+} > >+ > >/* > > * This is the routine which IP calls when receiving an SCTP packet. > > */ > >@@ -183,6 +198,10 @@ > > rcvr =3D asoc ? &asoc->base : &ep->base; > > sk =3D rcvr->sk; > > > >+ if ((sk) && (atomic_read(&sk->sk_rmem_alloc) >=3D sk->sk_rcvbuf)) > >+ goto discard_release; > >+ > >+ > > if (!ipsec_sk_policy(sk, skb)) > > goto discard_release; > > > >@@ -197,6 +216,8 @@ > > goto discard_release; > > } > > > >+ sctp_rcv_set_owner_r(skb,sk); > >+ > > /* Remember what endpoint is to handle this packet. */ > > chunk->rcvr =3D rcvr; > > > > >=20 > --=20 --=20 /*************************************************** *Neil Horman *Software Engineer *Red Hat, Inc. *nhorman@redhat.com *gpg keyid: 1024D / 0x92A74FA1 *http://pgp.mit.edu ***************************************************/ --UugvWAfsgieZRqgk Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.1 (GNU/Linux) iD8DBQFCMb3TM+bEoZKnT6ERApscAJ0Qzbdd7+CDOM5Bcc8MgyEBDL8gRQCcCqfE /wBHfr9ZB1UgFhThIuoIwQs= =lL2g -----END PGP SIGNATURE----- --UugvWAfsgieZRqgk-- From P@draigBrady.com Fri Mar 11 13:42:50 2005 Received: with ECARTIS (v1.0.0; list netdev); Fri, 11 Mar 2005 13:42:59 -0800 (PST) Received: from corvil.com (gate.corvil.net [213.94.219.177]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j2BLgnEw012422 for ; Fri, 11 Mar 2005 13:42:49 -0800 Received: from draigBrady.com (pixelbeat.local.corvil.com [172.18.1.170]) by corvil.com (8.12.9/8.12.5) with ESMTP id j2BER8wS023420; Fri, 11 Mar 2005 14:27:09 GMT (envelope-from P@draigBrady.com) Message-ID: <4231AABC.8040101@draigBrady.com> Date: Fri, 11 Mar 2005 14:27:08 +0000 From: P@draigBrady.com User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.6) Gecko/20040124 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Alex Upton CC: netdev@oss.sgi.com Subject: Re: 2.6.10 - "netdev=" kernel boot commands and the Intel e1000 nic References: <13A26154A563124B876A26F0EF0CE1ED032C9299@HFCCINFEXCH501.AMERICAS.CORP.LOCAL> In-Reply-To: <13A26154A563124B876A26F0EF0CE1ED032C9299@HFCCINFEXCH501.AMERICAS.CORP.LOCAL> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit X-Virus-Scanned: ClamAV version 0.83, clamav-milter version 0.83 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 21 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: P@draigBrady.com Precedence: bulk X-list: netdev Content-Length: 965 Lines: 29 Alex Upton wrote: > Hello All, > > For about 3.5 days now I've been trying to swap eth0 and eth1 devices > through use of the netdev kernel boot switch. > > The scenario: > > We have a system with onboard NICS and a PCI Intel e1000 Fiber NIC > installed. This particular system by default forces the NIC inside the > PCI slot to always default to eth0. We want to have ultimate control as > to which NIC is deemed worthy enough to become eth0. We are using an > entirely monolithic kernel via a PXE driven build and prefer not to > support use of modules. > > If anyone has any suggestions or insight on how to work with netdev and > the e1000 properly it would be greatly appreciated! I've found using a higher level script with heuristics is the only way to order nics generically as I want. for e.g. if ethtool eth0 | grep -q "Port: FIBRE"; then ip link set dev eth0 name not_eth0 ip link set dev eth1 name eth0 fi you get the idea... Pádraig. From yoshfuji@linux-ipv6.org Fri Mar 11 13:43:46 2005 Received: with ECARTIS (v1.0.0; list netdev); Fri, 11 Mar 2005 13:43:56 -0800 (PST) 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 j2BLhigB013134 for ; Fri, 11 Mar 2005 13:43:45 -0800 Received: from localhost (localhost [127.0.0.1]) by yue.st-paulia.net (Postfix) with ESMTP id 5842833CC2; Fri, 11 Mar 2005 23:58:17 +0900 (JST) Date: Fri, 11 Mar 2005 08:58:15 -0600 (CST) Message-Id: <20050311.085815.100748583.yoshfuji@linux-ipv6.org> To: cat@zip.com.au Cc: linux-kernel@vger.kernel.org, netdev@oss.sgi.com, pekkas@netcore.fi, yoshfuji@linux-ipv6.org Subject: Re: ipv6 and ipv4 interaction weirdness From: YOSHIFUJI Hideaki / =?iso-2022-jp?B?GyRCNUhGIzFRTEAbKEI=?= In-Reply-To: <20050311121655.GE14146@zip.com.au> References: <20050311121655.GE14146@zip.com.au> Organization: USAGI Project X-URL: http://www.yoshifuji.org/%7Ehideaki/ X-Fingerprint: 9022 65EB 1ECF 3AD1 0BDF 80D8 4807 F894 E062 0EEA X-PGP-Key-URL: http://www.yoshifuji.org/%7Ehideaki/hideaki@yoshifuji.org.asc X-Face: "5$Al-.M>NJ%a'@hhZdQm:."qn~PA^gq4o*>iCFToq*bAi#4FRtx}enhuQKz7fNqQz\BYU] $~O_5m-9'}MIs`XGwIEscw;e5b>n"B_?j/AkL~i/MEaZBLP X-Mailer: Mew version 2.2 on Emacs 20.7 / Mule 4.1 (AOI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV version 0.83, clamav-milter version 0.83 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 22 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: yoshfuji@linux-ipv6.org Precedence: bulk X-list: netdev Content-Length: 631 Lines: 17 In article <20050311121655.GE14146@zip.com.au> (at Fri, 11 Mar 2005 23:16:55 +1100), CaT says: > If it bound to :: port 22 then 0.0.0.0:22 would fail. > > On the other hand if I got it to bind to each address individually then > both ipv4 (2 addresses) and ipv6 (1 address) binds would succeed. > > Maybe I'm just looking at it wrong but shouldn't ipv4 and ipv6 interfere > with each other? It is 100% intended, even it is not similar to BSD variants do. IPv4 and IPv6 share address/port space. :: and 0.0.0.0 is special "any" address, thus they confict. ::ffff:a.b.c.d and a.b.c.d also conflict. --yoshfuji From cat@zip.com.au Fri Mar 11 13:48:41 2005 Received: with ECARTIS (v1.0.0; list netdev); Fri, 11 Mar 2005 13:48:46 -0800 (PST) Received: from theirongiant.lochness.weebeastie.net (nessie.weebeastie.net [220.233.7.36]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j2BLmbcm015017 for ; Fri, 11 Mar 2005 13:48:37 -0800 Received: from theirongiant.lochness.weebeastie.net (localhost.localdomain [127.0.0.1]) by theirongiant.lochness.weebeastie.net (8.13.3/8.13.3/Debian-6) with ESMTP id j2BFBMM3002697; Sat, 12 Mar 2005 02:11:22 +1100 Received: (from hogarth@localhost) by theirongiant.lochness.weebeastie.net (8.13.3/8.13.3/Submit) id j2BFBH20002696; Sat, 12 Mar 2005 02:11:17 +1100 X-Authentication-Warning: theirongiant.lochness.weebeastie.net: hogarth set sender to cat@zip.com.au using -f Date: Sat, 12 Mar 2005 02:11:17 +1100 From: CaT To: "YOSHIFUJI Hideaki / ?$B5HF#1QL@" Cc: linux-kernel@vger.kernel.org, netdev@oss.sgi.com, pekkas@netcore.fi Subject: Re: ipv6 and ipv4 interaction weirdness Message-ID: <20050311151116.GF14146@zip.com.au> References: <20050311121655.GE14146@zip.com.au> <20050311.085815.100748583.yoshfuji@linux-ipv6.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20050311.085815.100748583.yoshfuji@linux-ipv6.org> Organisation: Furball Inc. User-Agent: Mutt/1.5.6+20040907i X-Virus-Scanned: ClamAV version 0.83, clamav-milter version 0.83 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 23 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: cat@zip.com.au Precedence: bulk X-list: netdev Content-Length: 1311 Lines: 29 On Fri, Mar 11, 2005 at 08:58:15AM -0600, YOSHIFUJI Hideaki / ?$B5HF#1QL@ wrote: > > If it bound to :: port 22 then 0.0.0.0:22 would fail. > > > > On the other hand if I got it to bind to each address individually then > > both ipv4 (2 addresses) and ipv6 (1 address) binds would succeed. > > > > Maybe I'm just looking at it wrong but shouldn't ipv4 and ipv6 interfere > > with each other? > > It is 100% intended, even it is not similar to BSD variants do. > > IPv4 and IPv6 share address/port space. > :: and 0.0.0.0 is special "any" address, thus they confict. > ::ffff:a.b.c.d and a.b.c.d also conflict. Argh! Ofcourse. That makes sense. In the IPv6 ip space, IPv4 was made a subset so anything that decides to bind 0.0.0.0:22 (for eg) would prevent another bind to :: much like binding to 10.1.1.1:22 would prevent a 0.0.0.0:22 bind. Having changed ListenAddress to :: it works as it should and I get responses in the IPv4 ip space. Joy. Thanks for the clue. I've so rarely come across the ::ffff: ip space that I completely forgot about it. -- "It goes against the grain of modern education to teach children to program. What fun is there in making plans, acquiring discipline in organising thoughts, devoting attention to detail and learning to be self-critical?" -- Alan Perlis From webvenza@libero.it Fri Mar 11 13:52:41 2005 Received: with ECARTIS (v1.0.0; list netdev); Fri, 11 Mar 2005 13:52:45 -0800 (PST) Received: from gateway.milesteg.arr (foobar@adsl-166-231.38-151.net24.it [151.38.231.166]) by oss.sgi.com (8.13.0/8.13.0) with SMTP id j2BLqdbp015695 for ; Fri, 11 Mar 2005 13:52:40 -0800 Received: (qmail 28660 invoked from network); 11 Mar 2005 19:31:02 -0000 Received: from unknown (HELO ?192.168.0.205?) (192.168.0.205) by gateway.milesteg.arr with SMTP; 11 Mar 2005 19:31:02 -0000 In-Reply-To: <20050310213917.GW5389@shell0.pdx.osdl.net> References: <422F59E8.2090707@pobox.com> <20050310202548.GV5389@shell0.pdx.osdl.net> <4230AE24.602@pobox.com> <20050310213917.GW5389@shell0.pdx.osdl.net> Mime-Version: 1.0 (Apple Message framework v619.2) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: Content-Transfer-Encoding: 7bit Cc: stable@kernel.org, Linux Kernel , Jeff Garzik , Netdev From: Daniele Venzano Subject: Re: [stable] [BK PATCHES] 2.6.x net driver oops fixes Date: Fri, 11 Mar 2005 20:29:50 +0100 To: Chris Wright X-Mailer: Apple Mail (2.619.2) X-Virus-Scanned: ClamAV version 0.83, clamav-milter version 0.83 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 24 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: webvenza@libero.it Precedence: bulk X-list: netdev Content-Length: 1285 Lines: 44 On 10/mar/05, at 22:39, Chris Wright wrote: > * Jeff Garzik (jgarzik@pobox.com) wrote: >> Chris Wright wrote: >>> * Jeff Garzik (jgarzik@pobox.com) wrote: >>> >>> >>>> This will update the following files: >>>> >>>> drivers/net/sis900.c | 41 >>>> +++++++++++++++++++++-------------------- >>>> drivers/net/via-rhine.c | 3 +++ >>> >>> >>> The via-rhine fix is already in the stable queue. But the sis900 >>> oops >>> fix does not apply to the stable tree. It relies on a few >>> intermediate >>> patches. Appears to still be an issue for the older version which >>> is in >>> 2.6.11. Here's a stab at a backport. Would you like to >>> review/validate >>> or drop this one? >> >> The backport looks correct to me, though it would be nice to get a >> via-rhine owner to ACK the patch before it goes in... > > OK, thanks. ITYM sis900 maintainer, is that still Ollie Lho as listed > in > MAINTAINERS (that's looking old)? I have been acting maintainer for more than a year now, and I'm completely fine with the patch. A lot of time ago (2.6.6) I proposed a patch to update MAINTAINERS, but Jeff said he wanted to wait some time. I don't know if such change is now possible/wanted. AFAIK Ollie's email address bounces. -- Daniele Venzano http://www.brownhat.org From simon@thekelleys.org.uk Fri Mar 11 13:53:03 2005 Received: with ECARTIS (v1.0.0; list netdev); Fri, 11 Mar 2005 13:53:08 -0800 (PST) Received: from thekelleys.org.uk (cpc4-cmbg4-4-0-cust135.cmbg.cable.ntl.com [81.108.205.135]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j2BLr2Ts015873 for ; Fri, 11 Mar 2005 13:53:03 -0800 Received: from central ([192.168.0.4] helo=[127.0.0.1]) by thekelleys.org.uk with esmtp (Exim 3.35 #1 (Debian)) id 1D9l1m-0002sz-00; Fri, 11 Mar 2005 14:22:10 +0000 Message-ID: <4231A94E.9020904@thekelleys.org.uk> Date: Fri, 11 Mar 2005 14:21:02 +0000 From: Simon Kelley User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.3) Gecko/20041007 Debian/1.7.3-5 X-Accept-Language: en MIME-Version: 1.0 To: CaT CC: linux-kernel@vger.kernel.org, netdev@oss.sgi.com, pekkas@netcore.fi, yoshfuji@linux-ipv6.org Subject: Re: ipv6 and ipv4 interaction weirdness References: <20050311121655.GE14146@zip.com.au> In-Reply-To: <20050311121655.GE14146@zip.com.au> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV version 0.83, clamav-milter version 0.83 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 25 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: simon@thekelleys.org.uk Precedence: bulk X-list: netdev Content-Length: 1115 Lines: 31 CaT wrote: > I just had some issues with ssh and trying to get it to bind to all ipv6 > and ipv4 addresses to it via :: and 0.0.0.0. The problem was that it'd > only let one succeed. If 0.0.0.0:22 was successful then :: port 22 could > not happen and neither could my ipv6 addy port 22 as it would get the > 'address already in use' error from bind(). The reverse was also true. > If it bound to :: port 22 then 0.0.0.0:22 would fail. > > On the other hand if I got it to bind to each address individually then > both ipv4 (2 addresses) and ipv6 (1 address) binds would succeed. > > Maybe I'm just looking at it wrong but shouldn't ipv4 and ipv6 interfere > with each other? > > I'm using kernel 2.6.11-ac2 with OpenSSH_3.8.1p1 Debian-8.sarge.4, > OpenSSL 0.9.7e 25 Oct 2004 and glibc 2.3.2 (debian version > 2.3.2.ds1-20). > A solution is to set the IPV6_V6ONLY sockopt on the IPv6 socket (or just use IPv6 sockets and their ability to accept IPv4 connections in a corner of the IPv6 address space). It seems unlikely that a released ssh would have that problem, but I haven't checked. Cheers, Simon. From steve@services.navaho.net Fri Mar 11 14:04:23 2005 Received: with ECARTIS (v1.0.0; list netdev); Fri, 11 Mar 2005 14:04:32 -0800 (PST) Received: from services.navaho.net (fairchild-194.adsl.newnet.co.uk [213.131.187.194]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j2BM4MCM017974 for ; Fri, 11 Mar 2005 14:04:22 -0800 Received: from [10.101.0.42] (helo=[10.101.0.42] ident=[U2FsdGVkX1+JiUTt0ldffH7UFgLECENlwOx/QT92H8I=]) by services.navaho.net with esmtp (Exim 4.43) id 1D9lhg-0002kt-Ir; Fri, 11 Mar 2005 15:05:28 +0000 Date: Fri, 11 Mar 2005 15:05:28 +0000 (GMT) From: Steve Hill X-X-Sender: steve@sorbus2.navaho To: Herbert Xu cc: netdev@oss.sgi.com Subject: Re: More IPSEC trouble In-Reply-To: Message-ID: References: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Virus-Scanned: ClamAV version 0.83, clamav-milter version 0.83 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 26 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: steve@services.navaho.net Precedence: bulk X-list: netdev Content-Length: 1906 Lines: 43 On Fri, 11 Mar 2005, Herbert Xu wrote: > What does CTRL-SCROLLLOCK or SysRq tell us? The kernel locks up solid - no SysRq, capslock/numlock lights don't toggle when hitting the keys - completely dead. I've managed to work out what causes it though: I have overlapping subnets on the IPSEC tunnel - on the local side there is 10.101.0.0/16 and on the remote side there is 10.0.0.0/8. The IPSEC server is 10.101.0.254. The problem is that the policies I had required: 10.101.0.0/16 -> 10.0.0.0/8 Requires AH and ESP 10.0.0.0/8 -> 10.101.0.0/16 Requires AH and ESP This obviously also matches traffic sent from 10.101.0.254 (the IPSEC server) to any machine on the local 10.101.0.0/16 network. And since there is no SA for that traffic it gets dropped. This was a configuration mistake on my part and admittedly it shouldn't work properly - however, it triggered a kernel bug: sending a packet with the DF flag set which will grow to be > the MTU when encrypted causes the kernel to generate an ICMP Frag Needed packet, which got caught by the policy and this triggered the kernel to lock up hard. So whilest the error in the configuration legitimately causes parts of the network to not work, it certainly shouldn't have caused the kernel to lock up. It seems the problem is occurring when the kernel generates a packet which the policy drops. I have fixed my configuration now so that I have policies like: 10.101.0.0/16 -> 10.101.0.0/16 None 10.101.0.0/16 -> 10.0.0.0/8 Requires AH and ESP 10.0.0.0/8 -> 10.101.0.0/16 Requires AH and ESP Since the policy nolonger catches the kernel-generated packets the problem nolonger occurs for me, but obviously there is a bug there that should really be fixed. - Steve Hill (BSc) Senior Software Developer Email: steve@navaho.co.uk Navaho Technologies Ltd. Tel: +44-870-7034015 From dtor_core@ameritech.net Fri Mar 11 14:22:16 2005 Received: with ECARTIS (v1.0.0; list netdev); Fri, 11 Mar 2005 14:22:20 -0800 (PST) Received: from smtp811.mail.sc5.yahoo.com (smtp811.mail.sc5.yahoo.com [66.163.170.81]) by oss.sgi.com (8.13.0/8.13.0) with SMTP id j2BMMGLn020330 for ; Fri, 11 Mar 2005 14:22:16 -0800 Received: from unknown (HELO core.corenet.prv) (dtor?core@ameritech.net@68.253.44.57 with plain) by smtp811.mail.sc5.yahoo.com with SMTP; 11 Mar 2005 18:56:55 -0000 From: Dmitry Torokhov To: "David S. Miller" Subject: Re: Last night Linus bk - netfilter busted? Date: Fri, 11 Mar 2005 13:56:53 -0500 User-Agent: KMail/1.7.2 Cc: Patrick McHardy , netdev@oss.sgi.com, linux-kernel@vger.kernel.org, netfilter-devel@lists.netfilter.org References: <200503110223.34461.dtor_core@ameritech.net> <4231A498.4020101@trash.net> <20050311105136.2a5e4ddc.davem@davemloft.net> In-Reply-To: <20050311105136.2a5e4ddc.davem@davemloft.net> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200503111356.53620.dtor_core@ameritech.net> X-Virus-Scanned: ClamAV version 0.83, clamav-milter version 0.83 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 27 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: dtor_core@ameritech.net Precedence: bulk X-list: netdev Content-Length: 1076 Lines: 29 On Friday 11 March 2005 13:51, David S. Miller wrote: > On Fri, 11 Mar 2005 15:00:56 +0100 > Patrick McHardy wrote: > > > Works fine here. You could try if reverting one of these two patches > > helps (second one only if its a SMP box). > > > > ChangeSet@1.2010, 2005-03-09 20:28:17-08:00, bdschuym@pandora.be > > [NETFILTER]: Reduce call chain length in netfilter (take 2) > > It's this change, I know it is, because Linus sees the same problem > on his workstation. > > You wouldn't happen to be seeing this problem on a PPC box would > you? Since Linus's machine is a PPC machine too, that would support > my theory that this could be a compiler issue on that platform. > No, it is regular PIII laptop (preempt, UP). > Damn, wait, Patrick, I think I know what's happening. The iptables > IPT_* verdicts are dependant upon the NF_* values, and they don't > cope with Bart's changes I bet. Can you figure out what the exact > error would be? This kind of issue would explain the looping inside > of ipt_do_table(), wouldn't it? > -- Dmitry From sri@us.ibm.com Fri Mar 11 14:32:51 2005 Received: with ECARTIS (v1.0.0; list netdev); Fri, 11 Mar 2005 14:32:56 -0800 (PST) Received: from over.ny.us.ibm.com (over.ny.us.ibm.com [32.97.182.150]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j2BMWo3P021348 for ; Fri, 11 Mar 2005 14:32:51 -0800 Received: from e4.ny.us.ibm.com ([192.168.1.104]) by pokfb.esmtp.ibm.com (8.12.11/8.12.11) with ESMTP id j2BEXuGt022574 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for ; Fri, 11 Mar 2005 09:33:56 -0500 Received: from d01relay04.pok.ibm.com (d01relay04.pok.ibm.com [9.56.227.236]) by e4.ny.us.ibm.com (8.12.11/8.12.11) with ESMTP id j2BESuNS001845 for ; Fri, 11 Mar 2005 09:28:56 -0500 Received: from d01av02.pok.ibm.com (d01av02.pok.ibm.com [9.56.224.216]) by d01relay04.pok.ibm.com (8.12.10/NCO/VER6.6) with ESMTP id j2BESugf225728 for ; Fri, 11 Mar 2005 09:28:56 -0500 Received: from d01av02.pok.ibm.com (loopback [127.0.0.1]) by d01av02.pok.ibm.com (8.12.11/8.12.11) with ESMTP id j2BEStrw011618 for ; Fri, 11 Mar 2005 09:28:55 -0500 Received: from sig-9-65-33-216.mts.ibm.com (sig-9-65-33-216.mts.ibm.com [9.65.33.216]) by d01av02.pok.ibm.com (8.12.11/8.12.11) with ESMTP id j2BESpDm011500; Fri, 11 Mar 2005 09:28:53 -0500 Date: Fri, 11 Mar 2005 19:58:50 +0530 (IST) From: Sridhar Samudrala X-X-Sender: sridhar@localhost.localdomain To: nhorman@redhat.com cc: "David S. Miller" , netdev@oss.sgi.com, lksctp-developers@lists.sourceforge.net Subject: Re: [Patch] sctp: add receive buffer accounting to sctp (fwd) In-Reply-To: <20050311125724.GB18122@hmsendeavour.rdu.redhat.com> Message-ID: References: <20050309211632.6f70fe41.davem@davemloft.net> <20050310120803.GA6341@hmsendeavour.rdu.redhat.com> <20050310154342.GG6341@hmsendeavour.rdu.redhat.com> <20050310183856.08cb5f7b.davem@davemloft.net> <20050311125724.GB18122@hmsendeavour.rdu.redhat.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Virus-Scanned: ClamAV version 0.83, clamav-milter version 0.83 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 28 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: sri@us.ibm.com Precedence: bulk X-list: netdev Content-Length: 2119 Lines: 78 Neil, I guess you may not have tried to compile SCTP with this patch. 2.4 struct sock members do not have sk_ prefix. So you need to replace sk_rmem_alloc and sk_rcvbuf with rmem_alloc and rcvbuf. Thanks Sridhar On Fri, 11 Mar 2005 nhorman@redhat.com wrote: > On Thu, Mar 10, 2005 at 06:38:56PM -0800, David S. Miller wrote: >> On Thu, 10 Mar 2005 10:43:42 -0500 >> nhorman@redhat.com wrote: >> >>> Repost of my ealier rcvbuf patch. No changes, but rediffed to apply cleanly to >>> the head of the bitkeeper tree. Passes all lksctp regression tests >> >> Applied, thanks Neil. > > You're quite welcome. Heres the 2.4 version of the same patch that you > requested. Applies clean against the bitkeeper head. > > Signed-off-by: Neil Horman > > [nhorman@hmsendeavour kernel]$ diffstat linux-2.4-sctp.rcvbuf.patch > input.c | 21 +++++++++++++++++++++ > 1 files changed, 21 insertions(+) > > > --- linux-2.4-sctp/net/sctp/input.c.orig 2005-03-10 13:36:49.000000000 -0500 > +++ linux-2.4-sctp/net/sctp/input.c 2005-03-10 13:51:25.000000000 -0500 > @@ -100,6 +100,21 @@ > return 0; > } > > +/* The free routine for skbuffs that sctp receives */ > +static void sctp_rfree(struct sk_buff *skb) > +{ > + atomic_sub(sizeof(struct sctp_chunk),&skb->sk->sk_rmem_alloc); > + sock_rfree(skb); > +} > + > +/* The ownership wrapper routine to do receive buffer accounting */ > +static void sctp_rcv_set_owner_r(struct sk_buff *skb, struct sock *sk) > +{ > + skb_set_owner_r(skb,sk); > + skb->destructor = sctp_rfree; > + atomic_add(sizeof(struct sctp_chunk),&sk->sk_rmem_alloc); > +} > + > /* > * This is the routine which IP calls when receiving an SCTP packet. > */ > @@ -183,6 +198,10 @@ > rcvr = asoc ? &asoc->base : &ep->base; > sk = rcvr->sk; > > + if ((sk) && (atomic_read(&sk->sk_rmem_alloc) >= sk->sk_rcvbuf)) > + goto discard_release; > + > + > if (!ipsec_sk_policy(sk, skb)) > goto discard_release; > > @@ -197,6 +216,8 @@ > goto discard_release; > } > > + sctp_rcv_set_owner_r(skb,sk); > + > /* Remember what endpoint is to handle this packet. */ > chunk->rcvr = rcvr; > > -- From shemminger@osdl.org Fri Mar 11 14:35:48 2005 Received: with ECARTIS (v1.0.0; list netdev); Fri, 11 Mar 2005 14:35:53 -0800 (PST) Received: from smtp.osdl.org (fire.osdl.org [65.172.181.4]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j2BMZlAU021990 for ; Fri, 11 Mar 2005 14:35:48 -0800 Received: from shell0.pdx.osdl.net (fw.osdl.org [65.172.181.6]) by smtp.osdl.org (8.12.8/8.12.8) with ESMTP id j2BMZ7qi019638 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO); Fri, 11 Mar 2005 14:35:07 -0800 Received: from dxpl.pdx.osdl.net (dxpl.pdx.osdl.net [172.20.1.103]) by shell0.pdx.osdl.net (8.13.1/8.11.6) with ESMTP id j2BMZ6Xm014189; Fri, 11 Mar 2005 14:35:07 -0800 Date: Fri, 11 Mar 2005 14:35:24 -0800 From: Stephen Hemminger To: Andrew Morton Cc: Christoph Lameter , linux-kernel@vger.kernel.org, mark@chelsio.com, netdev@oss.sgi.com, Jeff Garzik Subject: Re: A new 10GB Ethernet Driver by Chelsio Communications Message-ID: <20050311143524.7495f22b@dxpl.pdx.osdl.net> In-Reply-To: <20050311112132.6a3a3b49.akpm@osdl.org> References: <20050311112132.6a3a3b49.akpm@osdl.org> Organization: Open Source Development Lab X-Mailer: Sylpheed-Claws 1.0.1 (GTK+ 1.2.10; x86_64-unknown-linux-gnu) X-Face: &@E+xe?c%:&e4D{>f1O<&U>2qwRREG5!}7R4;D<"NO^UI2mJ[eEOA2*3>(`Th.yP,VDPo9$ /`~cw![cmj~~jWe?AHY7D1S+\}5brN0k*NE?pPh_'_d>6;XGG[\KDRViCfumZT3@[ Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Received-SPF: pass (domain of shemminger@osdl.org designates 65.172.181.6 as permitted sender) X-MIMEDefang-Filter: osdl$Revision: 1.104 $ X-Scanned-By: MIMEDefang 2.36 X-Virus-Scanned: ClamAV version 0.83, clamav-milter version 0.83 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 29 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: shemminger@osdl.org Precedence: bulk X-list: netdev Content-Length: 3063 Lines: 115 On Fri, 11 Mar 2005 11:21:32 -0800 Andrew Morton wrote: > Christoph Lameter wrote: > > > > A Linux driver for the Chelsio 10Gb Ethernet Network Controller by > > Chelsio (http://www.chelsio.com). This driver supports the Chelsio N210 > > NIC and is backward compatible with the Chelsio N110 model 10Gb NICs. > > Thanks, Christoph. > > The 400k patch was too large for the vger email server so I have uploaded it to > > http://www.zip.com.au/~akpm/linux/patches/stuff/a-new-10gb-ethernet-driver-by-chelsio-communications.patch > > for reviewers. The performance recommendations in cxgb.txt are common to all fast devices, and should be in one file rather than just for this device. I would rather see ip-sysctl.txt updated or a new file on tuning recommendations started. Some of them have consequences that aren't documented well. For example, turning off TCP timestamps risks data corruption from sequence wrap. A new driver shouldn't need so may #ifdef's unless you want to putit on older vendor versions of 2.4 Some accessor and wrapper functions like: t1_pci_read_config_4 adapter_name t1_malloc are just annoying noise. Why have useless dead code like: /* Interrupt handler */ +static int pm3393_interrupt_handler(struct cmac *cmac) +{ + u32 master_intr_status; +/* + 1. Read master interrupt register. + 2. Read BLOCK's interrupt status registers. + 3. Handle BLOCK interrupts. +*/ + /* Read the master interrupt status register. */ + pmread(cmac, SUNI1x10GEXP_REG_MASTER_INTERRUPT_STATUS, + &master_intr_status); + CH_DBG(cmac->adapter, INTR, "PM3393 intr cause 0x%x\n", + master_intr_status); + + /* Handle BLOCK's interrupts. */ + + if (SUNI1x10GEXP_BITMSK_TOP_PL4IO_INT & master_intr_status) { + } + + if (SUNI1x10GEXP_BITMSK_TOP_IRAM_INT & master_intr_status) { + } + + if (SUNI1x10GEXP_BITMSK_TOP_ERAM_INT & master_intr_status) { + } + + /* SERDES */ + if (SUNI1x10GEXP_BITMSK_TOP_XAUI_INT & master_intr_status) { + } + + /* MSTAT */ + if (SUNI1x10GEXP_BITMSK_TOP_MSTAT_INT & master_intr_status) { + } + + /* RXXG */ + if (SUNI1x10GEXP_BITMSK_TOP_RXXG_INT & master_intr_status) { + } + + /* TXXG */ + if (SUNI1x10GEXP_BITMSK_TOP_TXXG_INT & master_intr_status) { + } + + /* XRF */ + if (SUNI1x10GEXP_BITMSK_TOP_XRF_INT & master_intr_status) { + } + + /* XTEF */ + if (SUNI1x10GEXP_BITMSK_TOP_XTEF_INT & master_intr_status) { + } + + /* MDIO */ + if (SUNI1x10GEXP_BITMSK_TOP_MDIO_BUSY_INT & master_intr_status) { + /* Not used. 8000 uses MDIO through Elmer. */ + } + + /* RXOAM */ + if (SUNI1x10GEXP_BITMSK_TOP_RXOAM_INT & master_intr_status) { + } + + /* TXOAM */ + if (SUNI1x10GEXP_BITMSK_TOP_TXOAM_INT & master_intr_status) { + } + + /* IFLX */ + if (SUNI1x10GEXP_BITMSK_TOP_IFLX_INT & master_intr_status) { + } + + /* EFLX */ + if (SUNI1x10GEXP_BITMSK_TOP_EFLX_INT & master_intr_status) { + } + + /* PL4ODP */ + if (SUNI1x10GEXP_BITMSK_TOP_PL4ODP_INT & master_intr_status) { + } + + /* PL4IDU */ + if (SUNI1x10GEXP_BITMSK_TOP_PL4IDU_INT & master_intr_status) { + } From jt@hpl.hp.com Fri Mar 11 14:36:11 2005 Received: with ECARTIS (v1.0.0; list netdev); Fri, 11 Mar 2005 14:36:16 -0800 (PST) Received: from palrel10.hp.com (palrel10.hp.com [156.153.255.245]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j2BMaA0A022164 for ; Fri, 11 Mar 2005 14:36:11 -0800 Received: from tomil.hpl.hp.com (tomil.hpl.hp.com [15.0.152.100]) by palrel10.hp.com (Postfix) with ESMTP id 0DD2CCAB for ; Fri, 11 Mar 2005 10:23:55 -0800 (PST) Received: from bougret.hpl.hp.com (Debian-exim@bougret.hpl.hp.com [15.9.72.130]) by tomil.hpl.hp.com (8.9.3 (PHNE_29774)/8.9.3 HPLabs Timeshare Server) with ESMTP id KAA12201 for ; Fri, 11 Mar 2005 10:23:58 -0800 (PST) Received: from jt by bougret.hpl.hp.com with local (Exim 4.44) id 1D9oni-00011a-Pp for netdev@oss.sgi.com; Fri, 11 Mar 2005 10:23:54 -0800 Date: Fri, 11 Mar 2005 10:23:54 -0800 To: netdev@oss.sgi.com Subject: Re: 2.6.10 - "netdev=" kernel boot commands and the Intel e1000 nic Message-ID: <20050311182354.GA3931@bougret.hpl.hp.com> Reply-To: jt@hpl.hp.com Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Organisation: HP Labs Palo Alto Address: HP Labs, 1U-17, 1501 Page Mill road, Palo Alto, CA 94304, USA. E-mail: jt@hpl.hp.com User-Agent: Mutt/1.5.6+20040907i From: Jean Tourrilhes X-Virus-Scanned: ClamAV version 0.83, clamav-milter version 0.83 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 30 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: jt@hpl.hp.com Precedence: bulk X-list: netdev Content-Length: 340 Lines: 11 Alex Upton wrote : > > We have also tried to use "nameif" as a second approach, unfortunately > nameif seems to be limited to only having the capability to change any > logical Ethernet device name other than eth0. ifrename has takeover support, however I would still discourage you to force an interface to use the "eth0" name. Jean From kaber@trash.net Fri Mar 11 14:56:42 2005 Received: with ECARTIS (v1.0.0; list netdev); Fri, 11 Mar 2005 14:56:46 -0800 (PST) Received: from kaber.coreworks.de ([62.206.217.67]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j2BMufbM025089 for ; Fri, 11 Mar 2005 14:56:41 -0800 Received: from localhost ([127.0.0.1]) by kaber.coreworks.de with esmtp (Exim 4.50) id 1D9t31-0001JN-4W; Fri, 11 Mar 2005 23:55:59 +0100 Message-ID: <423221FF.8020103@trash.net> Date: Fri, 11 Mar 2005 23:55:59 +0100 From: Patrick McHardy User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.7.5) Gecko/20050106 Debian/1.7.5-1 X-Accept-Language: en MIME-Version: 1.0 To: Herbert Xu CC: davem@davemloft.net, dtor_core@ameritech.net, netdev@oss.sgi.com, linux-kernel@vger.kernel.org, netfilter-devel@lists.netfilter.org Subject: Re: Last night Linus bk - netfilter busted? References: In-Reply-To: Content-Type: multipart/mixed; boundary="------------010502040408080807090105" X-Virus-Scanned: ClamAV version 0.83, clamav-milter version 0.83 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 31 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: kaber@trash.net Precedence: bulk X-list: netdev Content-Length: 3074 Lines: 91 This is a multi-part message in MIME format. --------------010502040408080807090105 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Herbert Xu wrote: > Patrick McHardy wrote: > >>You're right, good catch. IPT_RETURN is interpreted internally by >>ip_tables, but since the value changed it isn't recognized by ip_tables >>anymore and returned to nf_iterate() as NF_REPEAT. This patch restores >>the old value. > > > Please fix netfilter_arp while you're at it since it does exactly > the same thing. New patch attached, thanks. --------------010502040408080807090105 Content-Type: text/plain; name="x" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="x" # This is a BitKeeper generated diff -Nru style patch. # # ChangeSet # 2005/03/11 23:54:54+01:00 kaber@coreworks.de # [NETFILTER]: Fix iptables userspace compatibility breakage # # Signed-off-by: Patrick McHardy # # include/linux/netfilter_ipv6/ip6_tables.h # 2005/03/11 23:54:44+01:00 kaber@coreworks.de +1 -1 # [NETFILTER]: Fix iptables userspace compatibility breakage # # Signed-off-by: Patrick McHardy # # include/linux/netfilter_ipv4/ip_tables.h # 2005/03/11 23:54:44+01:00 kaber@coreworks.de +1 -1 # [NETFILTER]: Fix iptables userspace compatibility breakage # # Signed-off-by: Patrick McHardy # # include/linux/netfilter_arp/arp_tables.h # 2005/03/11 23:54:44+01:00 kaber@coreworks.de +1 -1 # [NETFILTER]: Fix iptables userspace compatibility breakage # # Signed-off-by: Patrick McHardy # diff -Nru a/include/linux/netfilter_arp/arp_tables.h b/include/linux/netfilter_arp/arp_tables.h --- a/include/linux/netfilter_arp/arp_tables.h 2005-03-11 23:55:09 +01:00 +++ b/include/linux/netfilter_arp/arp_tables.h 2005-03-11 23:55:09 +01:00 @@ -154,7 +154,7 @@ #define ARPT_CONTINUE 0xFFFFFFFF /* For standard target */ -#define ARPT_RETURN (-NF_MAX_VERDICT - 1) +#define ARPT_RETURN (-NF_REPEAT - 1) /* The argument to ARPT_SO_GET_INFO */ struct arpt_getinfo diff -Nru a/include/linux/netfilter_ipv4/ip_tables.h b/include/linux/netfilter_ipv4/ip_tables.h --- a/include/linux/netfilter_ipv4/ip_tables.h 2005-03-11 23:55:09 +01:00 +++ b/include/linux/netfilter_ipv4/ip_tables.h 2005-03-11 23:55:09 +01:00 @@ -166,7 +166,7 @@ #define IPT_CONTINUE 0xFFFFFFFF /* For standard target */ -#define IPT_RETURN (-NF_MAX_VERDICT - 1) +#define IPT_RETURN (-NF_REPEAT - 1) /* TCP matching stuff */ struct ipt_tcp diff -Nru a/include/linux/netfilter_ipv6/ip6_tables.h b/include/linux/netfilter_ipv6/ip6_tables.h --- a/include/linux/netfilter_ipv6/ip6_tables.h 2005-03-11 23:55:09 +01:00 +++ b/include/linux/netfilter_ipv6/ip6_tables.h 2005-03-11 23:55:09 +01:00 @@ -166,7 +166,7 @@ #define IP6T_CONTINUE 0xFFFFFFFF /* For standard target */ -#define IP6T_RETURN (-NF_MAX_VERDICT - 1) +#define IP6T_RETURN (-NF_REPEAT - 1) /* TCP matching stuff */ struct ip6t_tcp --------------010502040408080807090105-- From bunk@stusta.de Fri Mar 11 14:58:41 2005 Received: with ECARTIS (v1.0.0; list netdev); Fri, 11 Mar 2005 14:58:48 -0800 (PST) Received: from mailout.stusta.mhn.de (emailhub.stusta.mhn.de [141.84.69.5]) by oss.sgi.com (8.13.0/8.13.0) with SMTP id j2BMwdmo026004 for ; Fri, 11 Mar 2005 14:58:40 -0800 Received: (qmail 17689 invoked from network); 11 Mar 2005 22:58:32 -0000 Received: from r063144.stusta.swh.mhn.de (10.150.63.144) by mailhub.stusta.mhn.de with SMTP; 11 Mar 2005 22:58:32 -0000 Received: by r063144.stusta.swh.mhn.de (Postfix, from userid 1000) id C086FB7B23; Fri, 11 Mar 2005 23:58:31 +0100 (CET) Date: Fri, 11 Mar 2005 23:58:31 +0100 From: Adrian Bunk To: Andrew Morton Cc: Christoph Lameter , linux-kernel@vger.kernel.org, mark@chelsio.com, netdev@oss.sgi.com, Jeff Garzik Subject: Re: A new 10GB Ethernet Driver by Chelsio Communications Message-ID: <20050311225831.GQ3723@stusta.de> References: <20050311112132.6a3a3b49.akpm@osdl.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20050311112132.6a3a3b49.akpm@osdl.org> User-Agent: Mutt/1.5.6+20040907i X-Virus-Scanned: ClamAV version 0.83, clamav-milter version 0.83 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 32 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: bunk@stusta.de Precedence: bulk X-list: netdev Content-Length: 1328 Lines: 40 On Fri, Mar 11, 2005 at 11:21:32AM -0800, Andrew Morton wrote: > Christoph Lameter wrote: > > > > A Linux driver for the Chelsio 10Gb Ethernet Network Controller by > > Chelsio (http://www.chelsio.com). This driver supports the Chelsio N210 > > NIC and is backward compatible with the Chelsio N110 model 10Gb NICs. > > Thanks, Christoph. > > The 400k patch was too large for the vger email server so I have uploaded it to > > http://www.zip.com.au/~akpm/linux/patches/stuff/a-new-10gb-ethernet-driver-by-chelsio-communications.patch > > for reviewers. >... - my3126.c is unused (because t1_my3126_ops isn't used anywhere) - what are the EXTRA_CFLAGS in drivers/net/chelsio/Makefile for? - $(cxgb-y) in drivers/net/chelsio/Makefile seems to be unneeded - completely unused global functions: - espi.c: t1_espi_get_intr_counts - sge.c: t1_sge_get_intr_counts - the following functions can be made static: - sge.c: t1_espi_workaround - sge.c: t1_sge_tx - subr.c: __t1_tpi_read - subr.c: __t1_tpi_write - subr.c: t1_wait_op_done cu Adrian -- "Is there not promise of rain?" Ling Tan asked suddenly out of the darkness. There had been need of rain for many days. "Only a promise," Lao Er said. Pearl S. Buck - Dragon Seed From hadi@cyberus.ca Fri Mar 11 15:16:20 2005 Received: with ECARTIS (v1.0.0; list netdev); Fri, 11 Mar 2005 15:16:27 -0800 (PST) Received: from mx04.cybersurf.com (mx04.cybersurf.com [209.197.145.108]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j2BNGJJD027806 for ; Fri, 11 Mar 2005 15:16:20 -0800 Received: from mail.cyberus.ca ([209.197.145.21]) by mx01.cybersurf.com with esmtp (Exim 4.30) id 1D9oyE-0003y2-3u for netdev@oss.sgi.com; Fri, 11 Mar 2005 13:34:46 -0500 Received: from [216.209.86.2] (helo=[10.0.0.9]) by mail.cyberus.ca with esmtp (Exim 4.20) id 1D9oy9-0003RT-9k; Fri, 11 Mar 2005 13:34:41 -0500 Subject: Re: [PATCH] updated, ethernet-bridge: update skb->priority in case forwarded frame has VLAN-header From: jamal Reply-To: hadi@cyberus.ca To: Stephen Hemminger Cc: "leo.yuriev.ru" , Lennert Buytenhek , Patrick McHardy , Ben Greear , netdev@oss.sgi.com, linux-kernel@vger.kernel.org In-Reply-To: <20050311093724.6c8b6a6d@dxpl.pdx.osdl.net> References: <914610115.20050311172022@yuriev.ru> <20050311093724.6c8b6a6d@dxpl.pdx.osdl.net> Content-Type: text/plain Organization: jamalopolous Message-Id: <1110566077.1071.16.camel@jzny.localdomain> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.2.2 Date: 11 Mar 2005 13:34:37 -0500 Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV version 0.83, clamav-milter version 0.83 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 33 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: hadi@cyberus.ca Precedence: bulk X-list: netdev Content-Length: 858 Lines: 28 Actually there is a case to be made for this to be part of the bridge code. A VLAN is a single collision domain which is mappable to a collission domain that is a bridge. infact the old VLAN code written by Lennert (and somebody else) had those two intermingled. cheers, jamal On Fri, 2005-03-11 at 12:37, Stephen Hemminger wrote: > On Fri, 11 Mar 2005 17:20:22 +0300 > Leo Yuriev wrote: > > > Kernel 2.6 (2.6.11) > > > > When ethernet-bridge forward a packet and such ethernet-frame has > > VLAN-tag, bridge should update skb->prioriry for properly QoS > > handling. This small patch does this. > > > > Based upon discussion during last week I added pskb_may_pull() > > checking and simple mapping from 802.1p/user_priority to skb->priority. > > > > Patch-by: Leo Yuriev > > Do this as an ebtables module please. > From kaber@trash.net Fri Mar 11 16:00:51 2005 Received: with ECARTIS (v1.0.0; list netdev); Fri, 11 Mar 2005 16:00:55 -0800 (PST) Received: from kaber.coreworks.de ([62.206.217.67]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j2C00oCC030280 for ; Fri, 11 Mar 2005 16:00:50 -0800 Received: from localhost ([127.0.0.1]) by kaber.coreworks.de with esmtp (Exim 4.50) id 1D9u3Z-0001zU-VL; Sat, 12 Mar 2005 01:00:37 +0100 Message-ID: <42323125.20706@trash.net> Date: Sat, 12 Mar 2005 01:00:37 +0100 From: Patrick McHardy User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.7.5) Gecko/20050106 Debian/1.7.5-1 X-Accept-Language: en MIME-Version: 1.0 To: Steve Hill CC: Herbert Xu , netdev@oss.sgi.com, "David S. Miller" Subject: Re: More IPSEC trouble References: In-Reply-To: Content-Type: multipart/mixed; boundary="------------050106080400040708060905" X-Virus-Scanned: ClamAV version 0.83, clamav-milter version 0.83 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 34 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: kaber@trash.net Precedence: bulk X-list: netdev Content-Length: 2782 Lines: 88 This is a multi-part message in MIME format. --------------050106080400040708060905 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Steve Hill wrote: > This was a configuration mistake on my part and admittedly it shouldn't > work properly - however, it triggered a kernel bug: sending a packet > with the DF flag set which will grow to be > the MTU when encrypted > causes the kernel to generate an ICMP Frag Needed packet, which got > caught by the policy and this triggered the kernel to lock up hard. Thanks for tracking this down, we need to unlock the state before calling icmp_send(). This patch fixes it, it should apply to 2.6.10 if you replace dst_mtu() by dst_pmtu() in the context. --------------050106080400040708060905 Content-Type: text/plain; name="x" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="x" # This is a BitKeeper generated diff -Nru style patch. # # ChangeSet # 2005/03/12 00:59:07+01:00 kaber@coreworks.de # [XFRM]: Avoid possible deadlock for locally generated ICMP errors # # Signed-off-by: Patrick McHardy # # net/ipv6/xfrm6_output.c # 2005/03/12 00:58:59+01:00 kaber@coreworks.de +3 -1 # [XFRM]: Avoid possible deadlock for locally generated ICMP errors # # Signed-off-by: Patrick McHardy # # net/ipv4/xfrm4_output.c # 2005/03/12 00:58:59+01:00 kaber@coreworks.de +3 -1 # [XFRM]: Avoid possible deadlock for locally generated ICMP errors # # Signed-off-by: Patrick McHardy # diff -Nru a/net/ipv4/xfrm4_output.c b/net/ipv4/xfrm4_output.c --- a/net/ipv4/xfrm4_output.c 2005-03-12 00:59:22 +01:00 +++ b/net/ipv4/xfrm4_output.c 2005-03-12 00:59:22 +01:00 @@ -84,6 +84,7 @@ dst = skb->dst; mtu = dst_mtu(dst); if (skb->len > mtu) { + spin_unlock_bh(&x->lock); icmp_send(skb, ICMP_DEST_UNREACH, ICMP_FRAG_NEEDED, htonl(mtu)); ret = -EMSGSIZE; } @@ -111,7 +112,8 @@ if (x->props.mode) { err = xfrm4_tunnel_check_size(skb); if (err) - goto error; + /* xfrm4_tunnel_check_size() drops the lock on error */ + goto error_nolock; } xfrm4_encap(skb); diff -Nru a/net/ipv6/xfrm6_output.c b/net/ipv6/xfrm6_output.c --- a/net/ipv6/xfrm6_output.c 2005-03-12 00:59:22 +01:00 +++ b/net/ipv6/xfrm6_output.c 2005-03-12 00:59:22 +01:00 @@ -84,6 +84,7 @@ mtu = IPV6_MIN_MTU; if (skb->len > mtu) { + spin_unlock_bh(&x->lock); icmpv6_send(skb, ICMPV6_PKT_TOOBIG, 0, mtu, skb->dev); ret = -EMSGSIZE; } @@ -111,7 +112,8 @@ if (x->props.mode) { err = xfrm6_tunnel_check_size(skb); if (err) - goto error; + /* xfrm6_tunnel_check_size() drops the lock on error */ + goto error_nolock; } xfrm6_encap(skb); --------------050106080400040708060905-- From kaber@trash.net Fri Mar 11 16:11:51 2005 Received: with ECARTIS (v1.0.0; list netdev); Fri, 11 Mar 2005 16:11:56 -0800 (PST) Received: from kaber.coreworks.de ([62.206.217.67]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j2C0Bka9031166 for ; Fri, 11 Mar 2005 16:11:51 -0800 Received: from localhost ([127.0.0.1]) by kaber.coreworks.de with esmtp (Exim 4.50) id 1D9uED-0002eW-TB; Sat, 12 Mar 2005 01:11:37 +0100 Message-ID: <423233B9.50204@trash.net> Date: Sat, 12 Mar 2005 01:11:37 +0100 From: Patrick McHardy User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.7.5) Gecko/20050106 Debian/1.7.5-1 X-Accept-Language: en MIME-Version: 1.0 To: Steve Hill CC: Herbert Xu , netdev@oss.sgi.com, "David S. Miller" Subject: Re: More IPSEC trouble References: <42323125.20706@trash.net> In-Reply-To: <42323125.20706@trash.net> Content-Type: multipart/mixed; boundary="------------050100050708000203090002" X-Virus-Scanned: ClamAV version 0.83, clamav-milter version 0.83 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 35 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: kaber@trash.net Precedence: bulk X-list: netdev Content-Length: 2862 Lines: 94 This is a multi-part message in MIME format. --------------050100050708000203090002 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Patrick McHardy wrote: > Steve Hill wrote: > >> This was a configuration mistake on my part and admittedly it >> shouldn't work properly - however, it triggered a kernel bug: sending >> a packet with the DF flag set which will grow to be > the MTU when >> encrypted causes the kernel to generate an ICMP Frag Needed packet, >> which got caught by the policy and this triggered the kernel to lock >> up hard. > > > Thanks for tracking this down, we need to unlock the state before > calling icmp_send(). This patch fixes it, it should apply to 2.6.10 > if you replace dst_mtu() by dst_pmtu() in the context. Second try .. this one compiles. --------------050100050708000203090002 Content-Type: text/plain; name="x" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="x" # This is a BitKeeper generated diff -Nru style patch. # # ChangeSet # 2005/03/12 00:59:07+01:00 kaber@coreworks.de # [XFRM]: Avoid possible deadlock for locally generated ICMP errors # # Signed-off-by: Patrick McHardy # # net/ipv6/xfrm6_output.c # 2005/03/12 00:58:59+01:00 kaber@coreworks.de +3 -1 # [XFRM]: Avoid possible deadlock for locally generated ICMP errors # # Signed-off-by: Patrick McHardy # # net/ipv4/xfrm4_output.c # 2005/03/12 00:58:59+01:00 kaber@coreworks.de +3 -1 # [XFRM]: Avoid possible deadlock for locally generated ICMP errors # # Signed-off-by: Patrick McHardy # diff -Nru a/net/ipv4/xfrm4_output.c b/net/ipv4/xfrm4_output.c --- a/net/ipv4/xfrm4_output.c 2005-03-12 01:03:18 +01:00 +++ b/net/ipv4/xfrm4_output.c 2005-03-12 01:03:18 +01:00 @@ -84,6 +84,7 @@ dst = skb->dst; mtu = dst_mtu(dst); if (skb->len > mtu) { + spin_unlock_bh(&x->lock); icmp_send(skb, ICMP_DEST_UNREACH, ICMP_FRAG_NEEDED, htonl(mtu)); ret = -EMSGSIZE; } @@ -111,7 +112,8 @@ if (x->props.mode) { err = xfrm4_tunnel_check_size(skb); if (err) - goto error; + /* xfrm4_tunnel_check_size() drops the lock on error */ + goto error_nolock; } xfrm4_encap(skb); diff -Nru a/net/ipv6/xfrm6_output.c b/net/ipv6/xfrm6_output.c --- a/net/ipv6/xfrm6_output.c 2005-03-12 01:03:18 +01:00 +++ b/net/ipv6/xfrm6_output.c 2005-03-12 01:03:18 +01:00 @@ -84,6 +84,7 @@ mtu = IPV6_MIN_MTU; if (skb->len > mtu) { + spin_unlock_bh(&x->lock); icmpv6_send(skb, ICMPV6_PKT_TOOBIG, 0, mtu, skb->dev); ret = -EMSGSIZE; } @@ -111,7 +112,8 @@ if (x->props.mode) { err = xfrm6_tunnel_check_size(skb); if (err) - goto error; + /* xfrm6_tunnel_check_size drops the lock on error */ + goto error_nolock; } xfrm6_encap(skb); --------------050100050708000203090002-- From kaber@trash.net Fri Mar 11 16:13:32 2005 Received: with ECARTIS (v1.0.0; list netdev); Fri, 11 Mar 2005 16:13:36 -0800 (PST) Received: from kaber.coreworks.de ([62.206.217.67]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j2C0DVpl031732 for ; Fri, 11 Mar 2005 16:13:31 -0800 Received: from localhost ([127.0.0.1]) by kaber.coreworks.de with esmtp (Exim 4.50) id 1D9uFv-0002fK-83; Sat, 12 Mar 2005 01:13:23 +0100 Message-ID: <42323423.3000001@trash.net> Date: Sat, 12 Mar 2005 01:13:23 +0100 From: Patrick McHardy User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.7.5) Gecko/20050106 Debian/1.7.5-1 X-Accept-Language: en MIME-Version: 1.0 To: Steve Hill CC: Herbert Xu , netdev@oss.sgi.com, "David S. Miller" Subject: Re: More IPSEC trouble References: <42323125.20706@trash.net> <423233B9.50204@trash.net> In-Reply-To: <423233B9.50204@trash.net> Content-Type: multipart/mixed; boundary="------------090809090208090007040601" X-Virus-Scanned: ClamAV version 0.83, clamav-milter version 0.83 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 36 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: kaber@trash.net Precedence: bulk X-list: netdev Content-Length: 3692 Lines: 125 This is a multi-part message in MIME format. --------------090809090208090007040601 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Patrick McHardy wrote: > Patrick McHardy wrote: > >> Steve Hill wrote: >> >>> This was a configuration mistake on my part and admittedly it >>> shouldn't work properly - however, it triggered a kernel bug: sending >>> a packet with the DF flag set which will grow to be > the MTU when >>> encrypted causes the kernel to generate an ICMP Frag Needed packet, >>> which got caught by the policy and this triggered the kernel to lock >>> up hard. >> >> >> >> Thanks for tracking this down, we need to unlock the state before >> calling icmp_send(). This patch fixes it, it should apply to 2.6.10 >> if you replace dst_mtu() by dst_pmtu() in the context. > > > Second try .. this one compiles. Embarrasing .. had I actually attached the new patch it would have compiled :) Time to go to bed it seems .. --------------090809090208090007040601 Content-Type: text/plain; name="x" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="x" # This is a BitKeeper generated diff -Nru style patch. # # ChangeSet # 2005/03/12 01:10:40+01:00 kaber@coreworks.de # [XFRM]: Avoid possible deadlock for locally generated ICMP errors # # Signed-off-by: Patrick McHardy # # net/ipv6/xfrm6_output.c # 2005/03/12 01:10:31+01:00 kaber@coreworks.de +5 -3 # [XFRM]: Avoid possible deadlock for locally generated ICMP errors # # Signed-off-by: Patrick McHardy # # net/ipv4/xfrm4_output.c # 2005/03/12 01:10:31+01:00 kaber@coreworks.de +5 -3 # [XFRM]: Avoid possible deadlock for locally generated ICMP errors # # Signed-off-by: Patrick McHardy # diff -Nru a/net/ipv4/xfrm4_output.c b/net/ipv4/xfrm4_output.c --- a/net/ipv4/xfrm4_output.c 2005-03-12 01:12:12 +01:00 +++ b/net/ipv4/xfrm4_output.c 2005-03-12 01:12:12 +01:00 @@ -67,7 +67,7 @@ memset(&(IPCB(skb)->opt), 0, sizeof(struct ip_options)); } -static int xfrm4_tunnel_check_size(struct sk_buff *skb) +static int xfrm4_tunnel_check_size(struct xfrm_state *x, struct sk_buff *skb) { int mtu, ret = 0; struct dst_entry *dst; @@ -84,6 +84,7 @@ dst = skb->dst; mtu = dst_mtu(dst); if (skb->len > mtu) { + spin_unlock_bh(&x->lock); icmp_send(skb, ICMP_DEST_UNREACH, ICMP_FRAG_NEEDED, htonl(mtu)); ret = -EMSGSIZE; } @@ -109,9 +110,10 @@ goto error; if (x->props.mode) { - err = xfrm4_tunnel_check_size(skb); + err = xfrm4_tunnel_check_size(x, skb); if (err) - goto error; + /* xfrm4_tunnel_check_size() drops the lock on error */ + goto error_nolock; } xfrm4_encap(skb); diff -Nru a/net/ipv6/xfrm6_output.c b/net/ipv6/xfrm6_output.c --- a/net/ipv6/xfrm6_output.c 2005-03-12 01:12:12 +01:00 +++ b/net/ipv6/xfrm6_output.c 2005-03-12 01:12:12 +01:00 @@ -74,7 +74,7 @@ ipv6_addr_copy(&top_iph->daddr, (struct in6_addr *)&x->id.daddr); } -static int xfrm6_tunnel_check_size(struct sk_buff *skb) +static int xfrm6_tunnel_check_size(struct xfrm_state *x, struct sk_buff *skb) { int mtu, ret = 0; struct dst_entry *dst = skb->dst; @@ -84,6 +84,7 @@ mtu = IPV6_MIN_MTU; if (skb->len > mtu) { + spin_unlock_bh(&x->lock); icmpv6_send(skb, ICMPV6_PKT_TOOBIG, 0, mtu, skb->dev); ret = -EMSGSIZE; } @@ -109,9 +110,10 @@ goto error; if (x->props.mode) { - err = xfrm6_tunnel_check_size(skb); + err = xfrm6_tunnel_check_size(x, skb); if (err) - goto error; + /* xfrm6_tunnel_check_size drops the lock on error */ + goto error_nolock; } xfrm6_encap(skb); --------------090809090208090007040601-- From bunk@stusta.de Fri Mar 11 16:24:22 2005 Received: with ECARTIS (v1.0.0; list netdev); Fri, 11 Mar 2005 16:24:30 -0800 (PST) Received: from mailout.stusta.mhn.de (mailout.stusta.mhn.de [141.84.69.5]) by oss.sgi.com (8.13.0/8.13.0) with SMTP id j2C0OLFi003610 for ; Fri, 11 Mar 2005 16:24:21 -0800 Received: (qmail 16350 invoked from network); 11 Mar 2005 22:24:14 -0000 Received: from r063144.stusta.swh.mhn.de (10.150.63.144) by mailhub.stusta.mhn.de with SMTP; 11 Mar 2005 22:24:14 -0000 Received: by r063144.stusta.swh.mhn.de (Postfix, from userid 1000) id 9E809BB5FB; Fri, 11 Mar 2005 23:24:12 +0100 (CET) Date: Fri, 11 Mar 2005 23:24:11 +0100 From: Adrian Bunk To: Andrew Morton Cc: Christoph Lameter , linux-kernel@vger.kernel.org, mark@chelsio.com, netdev@oss.sgi.com, Jeff Garzik Subject: Re: A new 10GB Ethernet Driver by Chelsio Communications Message-ID: <20050311222411.GN3723@stusta.de> References: <20050311112132.6a3a3b49.akpm@osdl.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20050311112132.6a3a3b49.akpm@osdl.org> User-Agent: Mutt/1.5.6+20040907i X-Virus-Scanned: ClamAV version 0.83, clamav-milter version 0.83 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 37 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: bunk@stusta.de Precedence: bulk X-list: netdev Content-Length: 927 Lines: 34 On Fri, Mar 11, 2005 at 11:21:32AM -0800, Andrew Morton wrote: > Christoph Lameter wrote: > > > > A Linux driver for the Chelsio 10Gb Ethernet Network Controller by > > Chelsio (http://www.chelsio.com). This driver supports the Chelsio N210 > > NIC and is backward compatible with the Chelsio N110 model 10Gb NICs. > > Thanks, Christoph. > > The 400k patch was too large for the vger email server so I have uploaded it to > > http://www.zip.com.au/~akpm/linux/patches/stuff/a-new-10gb-ethernet-driver-by-chelsio-communications.patch > > for reviewers. >... #if defined(MODULE) && ! defined(MODVERSIONS) #define MODVERSIONS #endif Why? cu Adrian -- "Is there not promise of rain?" Ling Tan asked suddenly out of the darkness. There had been need of rain for many days. "Only a promise," Lao Er said. Pearl S. Buck - Dragon Seed From jesse.brandeburg@intel.com Fri Mar 11 16:48:40 2005 Received: with ECARTIS (v1.0.0; list netdev); Fri, 11 Mar 2005 16:48:45 -0800 (PST) Received: from orsfmr002.jf.intel.com (fmr17.intel.com [134.134.136.16]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j2C0mdYk006363 for ; Fri, 11 Mar 2005 16:48:39 -0800 Received: from orsfmr101.jf.intel.com (orsfmr101.jf.intel.com [10.7.209.17]) by orsfmr002.jf.intel.com (8.12.10/8.12.10/d: major-outer.mc,v 1.1 2004/09/17 17:50:56 root Exp $) with ESMTP id j2C0mYf8008605; Sat, 12 Mar 2005 00:48:34 GMT Received: from nwlxmail01.jf.intel.com (nwlxmail01.jf.intel.com [10.7.171.40]) by orsfmr101.jf.intel.com (8.12.10/8.12.10/d: major-inner.mc,v 1.2 2004/09/17 18:05:01 root Exp $) with ESMTP id j2C0mYCS005194; Sat, 12 Mar 2005 00:48:34 GMT Received: from rickshaw.jf.intel.com (rickshaw.jf.intel.com [10.23.35.56]) by nwlxmail01.jf.intel.com (8.12.10/8.12.9/MailSET/Hub) with ESMTP id j2C0mV3t007091; Fri, 11 Mar 2005 16:48:33 -0800 Date: Fri, 11 Mar 2005 16:48:31 -0800 (PST) From: Jesse Brandeburg X-X-Sender: jbrandeb@localhost.localdomain To: jgarzik@pobox.com cc: netdev@oss.sgi.com Subject: [PATCH ethtool-3] add ixgb dump register support Message-ID: ReplyTo: "Jesse Brandeburg" MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Scanned-By: MIMEDefang 2.44 X-Virus-Scanned: ClamAV version 0.83, clamav-milter version 0.83 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 38 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: jesse.brandeburg@intel.com Precedence: bulk X-list: netdev Content-Length: 4668 Lines: 136 I didn't to a push to gkernel bitkeeper because I've never done that before, Jeff if you want that, I can try it. This is off a bitkeeper clone from yesterday. Apologies if I screwed up something with bitkeeper, as I'm just figuring it all out but want to learn! Thank you for your support, Jesse # This is a BitKeeper generated diff -Nru style patch. # # ChangeSet # 2005/03/11 09:26:41-08:00 jbrandeb@isotope.jf.intel.com # Addition of ixgb dump register (-d command) support for the Intel PRO/10Gb Server Adapter family. # # Signed-off-by: Jesse Brandeburg # diff -Nru a/Makefile.am b/Makefile.am --- a/Makefile.am 2005-03-11 09:27:23 -08:00 +++ b/Makefile.am 2005-03-11 09:27:23 -08:00 @@ -6,7 +6,7 @@ sbin_PROGRAMS = ethtool ethtool_SOURCES = de2104x.c ethtool.c ethtool-copy.h ethtool-util.h natsemi.c \ e1000.c realtek.c e100.c tg3.c amd8111e.c pcnet32.c \ - fec_8xx.c + fec_8xx.c ixgb.c dist-hook: cp $(top_srcdir)/ethtool.spec $(distdir) diff -Nru a/ethtool-util.h b/ethtool-util.h --- a/ethtool-util.h 2005-03-11 09:27:23 -08:00 +++ b/ethtool-util.h 2005-03-11 09:27:23 -08:00 @@ -39,4 +39,7 @@ /* Motorola 8xx FEC Ethernet controller */ int fec_8xx_dump_regs(struct ethtool_drvinfo *info, struct ethtool_regs *regs); +/* Intel PRO/10GbE Server Adapters */ +int ixgb_dump_regs(struct ethtool_drvinfo *info, struct ethtool_regs *regs); + #endif diff -Nru a/ethtool.c b/ethtool.c --- a/ethtool.c 2005-03-11 09:27:23 -08:00 +++ b/ethtool.c 2005-03-11 09:27:23 -08:00 @@ -11,6 +11,7 @@ * e1000 support by Scott Feldman * e100 support by Wen Tao * amd8111e support by Reeja John + * ixgb support by Jesse Brandeburg * * TODO: * * no-args => summary of each device (mii-tool style) @@ -1012,6 +1013,7 @@ { "amd8111e", amd8111e_dump_regs }, { "pcnet32", pcnet32_dump_regs }, { "fec_8xx", fec_8xx_dump_regs }, + { "ixgb", ixgb_dump_regs }, }; static int dump_regs(struct ethtool_drvinfo *info, struct ethtool_regs *regs) diff -Nru a/ixgb.c b/ixgb.c --- /dev/null Wed Dec 31 16:00:00 196900 +++ b/ixgb.c 2005-03-11 09:27:23 -08:00 @@ -0,0 +1,70 @@ +/* Copyright (c) 2004 Intel Corporation */ +/* support added by Jesse Brandeburg */ +#include +#include "ethtool-util.h" + +#define PCI_VENDOR_INTEL 0x8086 +#define PCI_DEVICE_82597EX 0x1048 +#define PCI_DEVICE_82597EX_SR 0x1A48 +#define PCI_DEVICE_82597EX_LR 0x1B48 + +char *reg_name[] = { +"CTRL0", "CTRL1", "STAT", "EECD", "MFS", "ICR", +"ICS", "IMS", "IMC", "RCTL", "FRCTL", "FRCTH", +"RDBAL", "RDBAH", "RDLEN", "RDH", "RDT", "RDTR", +"RXDCTL", "RAIDC", "RXCSUM", "RAL_0", "RAH_0", +"RAL_1", "RAH_1", "RAL_2", "RAH_2", "RAL_3", "RAH_3", +"RAL_4", "RAH_4", "RAL_5", "RAH_5", "RAL_6", "RAH_6", +"RAL_7", "RAH_7", "RAL_8", "RAH_8", "RAL_9", "RAH_9", +"RAL_A", "RAH_A", "RAL_B", "RAH_B", "RAL_C", "RAH_C", +"RAL_D", "RAH_D", "RAL_E", "RAH_E", "RAL_F", "RAH_F", +"TCTL", "TDBAL", "TDBAH", "TDLEN", "TDH", "TDT", +"TIDV", "TXDCTL", "TSPMT", "PAP", "PCSC", "PCSC2", +"PCSS", "PCSS2", "XPCSS", "UCCR", "XPCSTC", "MACA", "APAE", +"ARD", "AIS", "MSCA", "MSRWD", "TPRL", "TPRH", +"GPRCL", "GPRCH", "BPRCL", "BPRCH", "MPRCL", "MPRCH", +"UPRCL", "UPRCH", "VPRCL", "VPRCH", "JPRCL", "JPRCH", +"GORCL", "GORCH", "TORL", "TORH", "RNBC", "RUC", "ROC", +"RLEC", "CRCERRS", "ICBC", "ECBC", "MPC", "TPTL", "TPTH", +"GPTCL", "GPTCH", "BPTCL", "BPTCH", "MPTCL", "MPTCH", +"UPTCL", "UPTCH", "VPTCL", "VPTCH", "JPTCL", "JPTCH", +"GOTCL", "GOTCH", "TOTL", "TOTH", "DC", "PLT64C", "TSCTC", +"TSCTFC", "IBIC", "RFC", "LFC", "PFRC", "PFTC", "MCFRC", +"MCFTC", "XONRXC", "XONTXC", "XOFFRXC", "XOFFTXC", "RJC" +}; + +int +ixgb_dump_regs(struct ethtool_drvinfo *info, struct ethtool_regs *regs) +{ + u32 *data = (u32 *)regs->data; + u16 hw_device_id; + u32 i; + u32 num_of_regs = regs->len/sizeof(u32); + + /* two different driver setups */ + if(!(regs->version & 0xF0000000)) { + hw_device_id = (u16)regs->version; + switch (hw_device_id) { + case PCI_DEVICE_82597EX: + case PCI_DEVICE_82597EX_SR: + case PCI_DEVICE_82597EX_LR: + break; + default: + fprintf(stdout, "Unknown device ID %04x\n", + hw_device_id); + break; + } + } else { + /* avoid the device check for older drivers */ + } + + fprintf(stdout, "82597EX Registers %d\n", num_of_regs); + fprintf(stdout, "-----------------\n\n"); + + for (i = 0; i < num_of_regs; i++) { + fprintf(stdout, "%-15s %08x\n", + reg_name[i], data[i]); + } + return 0; +} + From akpm@osdl.org Fri Mar 11 17:33:16 2005 Received: with ECARTIS (v1.0.0; list netdev); Fri, 11 Mar 2005 17:33:22 -0800 (PST) Received: from smtp.osdl.org (fire.osdl.org [65.172.181.4]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j2C1XEOR009038 for ; Fri, 11 Mar 2005 17:33:16 -0800 Received: from shell0.pdx.osdl.net (fw.osdl.org [65.172.181.6]) by smtp.osdl.org (8.12.8/8.12.8) with ESMTP id j2C1X4qi001871 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO); Fri, 11 Mar 2005 17:33:05 -0800 Received: from akpm.pao.digeo.com (shell0.pdx.osdl.net [10.9.0.31]) by shell0.pdx.osdl.net (8.13.1/8.11.6) with SMTP id j2C1X4Zf022004; Fri, 11 Mar 2005 17:33:04 -0800 Date: Fri, 11 Mar 2005 17:33:08 -0800 From: Andrew Morton To: Felix von Leitner Cc: linux-kernel@vger.kernel.org, netdev@oss.sgi.com Subject: Re: 2.6.11: USB broken on nforce4, ipv6 still broken, centrino speedstep even more broken than in 2.6.10 Message-Id: <20050311173308.7a076e8f.akpm@osdl.org> In-Reply-To: <20050311202122.GA13205@fefe.de> References: <20050311202122.GA13205@fefe.de> X-Mailer: Sylpheed version 1.0.0 (GTK+ 1.2.10; i386-vine-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Received-SPF: pass (domain of akpm@osdl.org designates 65.172.181.6 as permitted sender) X-MIMEDefang-Filter: osdl$Revision: 1.104 $ X-Scanned-By: MIMEDefang 2.36 X-Virus-Scanned: ClamAV version 0.83, clamav-milter version 0.83 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 39 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: akpm@osdl.org Precedence: bulk X-list: netdev Content-Length: 813 Lines: 17 (Added netdev cc) Felix von Leitner wrote: > > Now about IPv6: npush and npoll are two applications I wrote. npush > sends multicast announcements and opens a TCP socket. npoll receives > the multicast announcement and connects to the source IP/port/scope_id > of the announcement. If both are run on the same machine, npoll sees > the link local address of eth0 as source IP, and the interface number of > eth0 as scope_id. So far so good. Trying to connect() however hangs. > Since this has been broken in different ways for as long as I can > remember in Linux, and I keep complaining about it every half a year or > so. Can't someone fix this once and for all? IPv4 checks whether we > are connecting to our own address and reroutes through loopback, why > can't IPv6? > From herbert@gondor.apana.org.au Fri Mar 11 17:36:17 2005 Received: with ECARTIS (v1.0.0; list netdev); Fri, 11 Mar 2005 17:36:29 -0800 (PST) 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 j2C1aFA5009625 for ; Fri, 11 Mar 2005 17:36:16 -0800 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 1D9vXW-0008Gb-00; Sat, 12 Mar 2005 12:35:38 +1100 Received: from herbert by gondolin.me.apana.org.au with local (Exim 3.36 #1 (Debian)) id 1D9vX9-0004i4-00; Sat, 12 Mar 2005 12:35:15 +1100 Date: Sat, 12 Mar 2005 12:35:15 +1100 To: Patrick McHardy Cc: Steve Hill , netdev@oss.sgi.com, "David S. Miller" Subject: Re: More IPSEC trouble Message-ID: <20050312013515.GA17539@gondor.apana.org.au> References: <42323125.20706@trash.net> Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="Q68bSM7Ycu6FN28Q" Content-Disposition: inline In-Reply-To: <42323125.20706@trash.net> User-Agent: Mutt/1.5.6+20040907i From: Herbert Xu X-Virus-Scanned: ClamAV version 0.83, clamav-milter version 0.83 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 40 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: herbert@gondor.apana.org.au Precedence: bulk X-list: netdev Content-Length: 2057 Lines: 84 --Q68bSM7Ycu6FN28Q Content-Type: text/plain; charset=us-ascii Content-Disposition: inline On Sat, Mar 12, 2005 at 01:00:37AM +0100, Patrick McHardy wrote: > > Thanks for tracking this down, we need to unlock the state before > calling icmp_send(). This patch fixes it, it should apply to 2.6.10 > if you replace dst_mtu() by dst_pmtu() in the context. Good catch. However let's try to avoid spreading lock/unlock calls around if possible. Since tunnel_check_size only looks at the state to determine whether it's tunnel mode, it doesn't need to hold the lock at all. 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 --Q68bSM7Ycu6FN28Q Content-Type: text/plain; charset=us-ascii Content-Disposition: attachment; filename=p ===== net/ipv4/xfrm4_output.c 1.7 vs edited ===== --- 1.7/net/ipv4/xfrm4_output.c 2005-03-07 16:33:59 +11:00 +++ edited/net/ipv4/xfrm4_output.c 2005-03-12 12:26:20 +11:00 @@ -103,16 +103,16 @@ goto error_nolock; } - spin_lock_bh(&x->lock); - err = xfrm_state_check(x, skb); - if (err) - goto error; - if (x->props.mode) { err = xfrm4_tunnel_check_size(skb); if (err) - goto error; + goto error_nolock; } + + spin_lock_bh(&x->lock); + err = xfrm_state_check(x, skb); + if (err) + goto error; xfrm4_encap(skb); ===== net/ipv6/xfrm6_output.c 1.9 vs edited ===== --- 1.9/net/ipv6/xfrm6_output.c 2005-03-07 16:33:59 +11:00 +++ edited/net/ipv6/xfrm6_output.c 2005-03-12 12:29:00 +11:00 @@ -103,16 +103,16 @@ goto error_nolock; } - spin_lock_bh(&x->lock); - err = xfrm_state_check(x, skb); - if (err) - goto error; - if (x->props.mode) { err = xfrm6_tunnel_check_size(skb); if (err) - goto error; + goto error_nolock; } + + spin_lock_bh(&x->lock); + err = xfrm_state_check(x, skb); + if (err) + goto error; xfrm6_encap(skb); --Q68bSM7Ycu6FN28Q-- From kaber@trash.net Fri Mar 11 18:35:55 2005 Received: with ECARTIS (v1.0.0; list netdev); Fri, 11 Mar 2005 18:36:01 -0800 (PST) Received: from kaber.coreworks.de ([62.206.217.67]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j2C2ZtS6012227 for ; Fri, 11 Mar 2005 18:35:55 -0800 Received: from localhost ([127.0.0.1]) by kaber.coreworks.de with esmtp (Exim 4.50) id 1D9wTi-0004sM-Ue; Sat, 12 Mar 2005 03:35:46 +0100 Message-ID: <42325582.1090003@trash.net> Date: Sat, 12 Mar 2005 03:35:46 +0100 From: Patrick McHardy User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.7.5) Gecko/20050106 Debian/1.7.5-1 X-Accept-Language: en MIME-Version: 1.0 To: Herbert Xu CC: Steve Hill , netdev@oss.sgi.com, "David S. Miller" Subject: Re: More IPSEC trouble References: <42323125.20706@trash.net> <20050312013515.GA17539@gondor.apana.org.au> In-Reply-To: <20050312013515.GA17539@gondor.apana.org.au> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV version 0.83, clamav-milter version 0.83 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 41 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: kaber@trash.net Precedence: bulk X-list: netdev Content-Length: 293 Lines: 11 Herbert Xu wrote: > Good catch. However let's try to avoid spreading lock/unlock calls > around if possible. > > Since tunnel_check_size only looks at the state to determine whether > it's tunnel mode, it doesn't need to hold the lock at all. Agreed, your patch is better. Regards Patrick From davem@davemloft.net Fri Mar 11 20:13:46 2005 Received: with ECARTIS (v1.0.0; list netdev); Fri, 11 Mar 2005 20:13:52 -0800 (PST) Received: from cheetah.davemloft.net (mail@dsl027-180-174.sfo1.dsl.speakeasy.net [216.27.180.174]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j2C4DjhQ015872 for ; Fri, 11 Mar 2005 20:13:46 -0800 Received: from localhost ([127.0.0.1] helo=cheetah.davemloft.net ident=davem) by cheetah.davemloft.net with smtp (Exim 3.36 #1 (Debian)) id 1D9y0A-0007OL-00; Fri, 11 Mar 2005 20:13:22 -0800 Date: Fri, 11 Mar 2005 20:13:22 -0800 From: "David S. Miller" To: Baruch Even Cc: shemminger@osdl.org, linux-net@vger.kernel.org, netdev@oss.sgi.com, doug.leith@nuim.ie Subject: Re: [RFC INTRO 0/5] H-TCP congestion control Message-Id: <20050311201322.7f730e51.davem@davemloft.net> In-Reply-To: <4231E5B7.2010306@ev-en.org> References: <20050311160734.30424.67955.65942@galon.ev-en.org> <20050311094239.4c59c29d@dxpl.pdx.osdl.net> <4231E5B7.2010306@ev-en.org> X-Mailer: Sylpheed version 1.0.1 (GTK+ 1.2.10; sparc-unknown-linux-gnu) X-Face: "_;p5u5aPsO,_Vsx"^v-pEq09'CU4&Dc1$fQExov$62l60cgCc%FnIwD=.UF^a>?5'9Kn[;433QFVV9M..2eN.@4ZWPGbdi<=?[:T>y?SD(R*-3It"Vj:)"dP Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV version 0.83, clamav-milter version 0.83 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 42 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: davem@davemloft.net Precedence: bulk X-list: netdev Content-Length: 298 Lines: 10 On Fri, 11 Mar 2005 18:38:47 +0000 Baruch Even wrote: > That's why it's an RFC and not a request to add it. That's fine. Please in the future still state that there are legal hurdles to pass over before inclusion. I'll often apply RFC patches that I think are very good. :-) From jgarzik@pobox.com Fri Mar 11 20:34:20 2005 Received: with ECARTIS (v1.0.0; list netdev); Fri, 11 Mar 2005 20:34:26 -0800 (PST) Received: from parcelfarce.linux.theplanet.co.uk (IDENT:93@parcelfarce.linux.theplanet.co.uk [195.92.249.252]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j2C4YJDe020415 for ; Fri, 11 Mar 2005 20:34:19 -0800 Received: from [69.134.152.124] (helo=[10.10.10.88]) by parcelfarce.linux.theplanet.co.uk with asmtp (TLSv1:AES256-SHA:256) (Exim 4.33) id 1D9yKP-0001pd-FC; Sat, 12 Mar 2005 04:34:17 +0000 Message-ID: <4232712D.3070705@pobox.com> Date: Fri, 11 Mar 2005 23:33:49 -0500 From: Jeff Garzik User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.3) Gecko/20040922 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Andrew Morton , Linus Torvalds CC: Netdev , Linux Kernel Subject: [BK PATCHES] 2.6.x net driver fixes Content-Type: multipart/mixed; boundary="------------060701010700080001070204" X-Virus-Scanned: ClamAV version 0.83, clamav-milter version 0.83 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 43 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: jgarzik@pobox.com Precedence: bulk X-list: netdev Content-Length: 6261 Lines: 187 This is a multi-part message in MIME format. --------------060701010700080001070204 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit --------------060701010700080001070204 Content-Type: text/plain; name="net-drivers.txt" Content-Transfer-Encoding: 8bit Content-Disposition: inline; filename="net-drivers.txt" Please do a bk pull bk://gkernel.bkbits.net/net-drivers-2.6 This will update the following files: drivers/net/lance.c | 1 + drivers/net/r8169.c | 17 ++++++++++------- drivers/net/sk98lin/skge.c | 2 +- drivers/net/tulip/media.c | 4 ++-- drivers/net/tulip/tulip_core.c | 21 ++++++++++++--------- drivers/net/typhoon-firmware.h | 2 +- 6 files changed, 27 insertions(+), 20 deletions(-) through these ChangeSets: : o sk98lin driver: fix driver name string Adrian Bunk: o drivers/net/typhoon: make a firmware image static Alan Cox: o ac bits for ULI ethernet missing from 2.6.11 François Romieu: o Fix r8169: panic on 2.6.11 Matthew Wilcox: o Lance needs delay.h --------------060701010700080001070204 Content-Type: text/x-patch; name="net-drivers.patch" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="net-drivers.patch" diff -Nru a/drivers/net/lance.c b/drivers/net/lance.c --- a/drivers/net/lance.c 2005-03-11 23:31:46 -05:00 +++ b/drivers/net/lance.c 2005-03-11 23:31:46 -05:00 @@ -47,6 +47,7 @@ #include #include #include +#include #include #include #include diff -Nru a/drivers/net/r8169.c b/drivers/net/r8169.c --- a/drivers/net/r8169.c 2005-03-11 23:31:46 -05:00 +++ b/drivers/net/r8169.c 2005-03-11 23:31:46 -05:00 @@ -1683,16 +1683,19 @@ rtl8169_make_unusable_by_asic(desc); } -static inline void rtl8169_return_to_asic(struct RxDesc *desc, int rx_buf_sz) +static inline void rtl8169_mark_to_asic(struct RxDesc *desc, u32 rx_buf_sz) { - desc->opts1 |= cpu_to_le32(DescOwn + rx_buf_sz); + u32 eor = le32_to_cpu(desc->opts1) & RingEnd; + + desc->opts1 = cpu_to_le32(DescOwn | eor | rx_buf_sz); } -static inline void rtl8169_give_to_asic(struct RxDesc *desc, dma_addr_t mapping, - int rx_buf_sz) +static inline void rtl8169_map_to_asic(struct RxDesc *desc, dma_addr_t mapping, + u32 rx_buf_sz) { desc->addr = cpu_to_le64(mapping); - desc->opts1 |= cpu_to_le32(DescOwn + rx_buf_sz); + wmb(); + rtl8169_mark_to_asic(desc, rx_buf_sz); } static int rtl8169_alloc_rx_skb(struct pci_dev *pdev, struct sk_buff **sk_buff, @@ -1712,7 +1715,7 @@ mapping = pci_map_single(pdev, skb->tail, rx_buf_sz, PCI_DMA_FROMDEVICE); - rtl8169_give_to_asic(desc, mapping, rx_buf_sz); + rtl8169_map_to_asic(desc, mapping, rx_buf_sz); out: return ret; @@ -2150,7 +2153,7 @@ skb_reserve(skb, NET_IP_ALIGN); eth_copy_and_sum(skb, sk_buff[0]->tail, pkt_size, 0); *sk_buff = skb; - rtl8169_return_to_asic(desc, rx_buf_sz); + rtl8169_mark_to_asic(desc, rx_buf_sz); ret = 0; } } diff -Nru a/drivers/net/sk98lin/skge.c b/drivers/net/sk98lin/skge.c --- a/drivers/net/sk98lin/skge.c 2005-03-11 23:31:46 -05:00 +++ b/drivers/net/sk98lin/skge.c 2005-03-11 23:31:46 -05:00 @@ -5155,7 +5155,7 @@ MODULE_DEVICE_TABLE(pci, skge_pci_tbl); static struct pci_driver skge_driver = { - .name = "skge", + .name = "sk98lin", .id_table = skge_pci_tbl, .probe = skge_probe_one, .remove = __devexit_p(skge_remove_one), diff -Nru a/drivers/net/tulip/media.c b/drivers/net/tulip/media.c --- a/drivers/net/tulip/media.c 2005-03-11 23:31:46 -05:00 +++ b/drivers/net/tulip/media.c 2005-03-11 23:31:46 -05:00 @@ -88,7 +88,7 @@ value = ioread32(ioaddr + CSR9); iowrite32(value & 0xFFEFFFFF, ioaddr + CSR9); - value = (phy_id << 21) | (location << 16) | 0x80000000; + value = (phy_id << 21) | (location << 16) | 0x08000000; iowrite32(value, ioaddr + CSR10); while(--i > 0) { @@ -166,7 +166,7 @@ value = ioread32(ioaddr + CSR9); iowrite32(value & 0xFFEFFFFF, ioaddr + CSR9); - value = (phy_id << 21) | (location << 16) | 0x40000000 | (val & 0xFFFF); + value = (phy_id << 21) | (location << 16) | 0x04000000 | (val & 0xFFFF); iowrite32(value, ioaddr + CSR10); while(--i > 0) { diff -Nru a/drivers/net/tulip/tulip_core.c b/drivers/net/tulip/tulip_core.c --- a/drivers/net/tulip/tulip_core.c 2005-03-11 23:31:46 -05:00 +++ b/drivers/net/tulip/tulip_core.c 2005-03-11 23:31:46 -05:00 @@ -1102,15 +1102,18 @@ entry = tp->cur_tx++ % TX_RING_SIZE; if (entry != 0) { - /* Avoid a chip errata by prefixing a dummy entry. */ - tp->tx_buffers[entry].skb = NULL; - tp->tx_buffers[entry].mapping = 0; - tp->tx_ring[entry].length = - (entry == TX_RING_SIZE-1) ? cpu_to_le32(DESC_RING_WRAP) : 0; - tp->tx_ring[entry].buffer1 = 0; - /* Must set DescOwned later to avoid race with chip */ - dummy = entry; - entry = tp->cur_tx++ % TX_RING_SIZE; + /* Avoid a chip errata by prefixing a dummy entry. Don't do + this on the ULI526X as it triggers a different problem */ + if (!(tp->chip_id == ULI526X && (tp->revision = 0x40 || tp->revision == 0x50))) { + tp->tx_buffers[entry].skb = NULL; + tp->tx_buffers[entry].mapping = 0; + tp->tx_ring[entry].length = + (entry == TX_RING_SIZE-1) ? cpu_to_le32(DESC_RING_WRAP) : 0; + tp->tx_ring[entry].buffer1 = 0; + /* Must set DescOwned later to avoid race with chip */ + dummy = entry; + entry = tp->cur_tx++ % TX_RING_SIZE; + } } tp->tx_buffers[entry].skb = NULL; diff -Nru a/drivers/net/typhoon-firmware.h b/drivers/net/typhoon-firmware.h --- a/drivers/net/typhoon-firmware.h 2005-03-11 23:31:46 -05:00 +++ b/drivers/net/typhoon-firmware.h 2005-03-11 23:31:46 -05:00 @@ -32,7 +32,7 @@ */ /* ver 03.001.008 */ -const u8 typhoon_firmware_image[] = { +static const u8 typhoon_firmware_image[] = { 0x54, 0x59, 0x50, 0x48, 0x4f, 0x4f, 0x4e, 0x00, 0x02, 0x00, 0x00, 0x00, 0x09, 0x00, 0x00, 0x00, 0x00, 0x00, 0xff, 0xff, 0xcb, 0x99, 0xb1, 0xd4, 0x4c, 0xb8, 0xd0, 0x4b, 0x32, 0x02, 0xd4, 0xee, 0x73, 0x7e, 0x0b, 0x13, --------------060701010700080001070204-- From jgarzik@pobox.com Fri Mar 11 20:50:06 2005 Received: with ECARTIS (v1.0.0; list netdev); Fri, 11 Mar 2005 20:50:12 -0800 (PST) Received: from parcelfarce.linux.theplanet.co.uk (IDENT:93@parcelfarce.linux.theplanet.co.uk [195.92.249.252]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j2C4o3aE021401 for ; Fri, 11 Mar 2005 20:50:05 -0800 Received: from [69.134.152.124] (helo=[10.10.10.88]) by parcelfarce.linux.theplanet.co.uk with asmtp (TLSv1:AES256-SHA:256) (Exim 4.33) id 1D9yZb-0002MC-Mn; Sat, 12 Mar 2005 04:49:59 +0000 Message-ID: <423274E5.4060804@pobox.com> Date: Fri, 11 Mar 2005 23:49:41 -0500 From: Jeff Garzik User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.3) Gecko/20040922 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Andrew Morton , Christoph Lameter CC: linux-kernel@vger.kernel.org, mark@chelsio.com, netdev@oss.sgi.com Subject: Re: A new 10GB Ethernet Driver by Chelsio Communications References: <20050311112132.6a3a3b49.akpm@osdl.org> In-Reply-To: <20050311112132.6a3a3b49.akpm@osdl.org> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV version 0.83, clamav-milter version 0.83 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 44 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: jgarzik@pobox.com Precedence: bulk X-list: netdev Content-Length: 725 Lines: 23 Andrew Morton wrote: > Christoph Lameter wrote: > >>A Linux driver for the Chelsio 10Gb Ethernet Network Controller by >> Chelsio (http://www.chelsio.com). This driver supports the Chelsio N210 >> NIC and is backward compatible with the Chelsio N110 model 10Gb NICs. > > > Thanks, Christoph. > > The 400k patch was too large for the vger email server so I have uploaded it to > > http://www.zip.com.au/~akpm/linux/patches/stuff/a-new-10gb-ethernet-driver-by-chelsio-communications.patch step 1: kill all the OS wrappers. And do you really need hooks for multiple MACs, when only one MAC is really supported? Typically these hooks are at a higher level anyway -- struct net_device. Jeff From andre@tomt.net Fri Mar 11 22:10:15 2005 Received: with ECARTIS (v1.0.0; list netdev); Fri, 11 Mar 2005 22:10:21 -0800 (PST) Received: from mx1.skjellin.no (mail1.skjellin.no [80.239.42.67]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j2C6AD5s024851 for ; Fri, 11 Mar 2005 22:10:14 -0800 Received: from localhost (localhost [127.0.0.1]) by mx1.skjellin.no (Postfix) with ESMTP id A72E8885E0; Sat, 12 Mar 2005 07:10:13 +0100 (CET) Received: from puppen.pasop.tomt.net (gw-fe-1.pasop.tomt.net [10.255.1.1]) by mail1.skjellin.no (Postfix) with ESMTP id 23606885DC; Sat, 12 Mar 2005 07:10:13 +0100 (CET) Received: from [10.255.1.10] (slurv.pasop.tomt.net [10.255.1.10]) by puppen.pasop.tomt.net (Postfix) with ESMTP id 53F2722B82; Sat, 12 Mar 2005 07:10:13 +0100 (CET) Message-ID: <423287C4.60701@tomt.net> Date: Sat, 12 Mar 2005 07:10:12 +0100 From: Andre Tomt User-Agent: Mozilla Thunderbird 1.0 (Windows/20041206) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Netdev , davem@davemloft.net Subject: [PATCH] Fix a gcc-3.4 build failure and gcc-3.3 build warnings with TCP_DEBUG disabled in tcp.h Content-Type: multipart/mixed; boundary="------------040309010906010804090708" X-Virus-Scanned: ClamAV version 0.83, clamav-milter version 0.83 on oss.sgi.com X-Virus-Scanned: by amavisd-new-20030616-p10 (Debian) at skjellin.no X-Virus-Status: Clean X-archive-position: 45 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: andre@tomt.net Precedence: bulk X-list: netdev Content-Length: 1745 Lines: 54 This is a multi-part message in MIME format. --------------040309010906010804090708 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Fix a gcc-3.4 build failure and gcc-3.3 build warnings with TCP_DEBUG disabled in tcp.h Patch (with description and signed-off-by) attached due to braindamaged MUA. --------------040309010906010804090708 Content-Type: text/x-patch; name="fix-tcp-non-debug-build.patch" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="fix-tcp-non-debug-build.patch" Fix a gcc-3.4 build failure and gcc-3.3 build warnings with TCP_DEBUG disabled in tcp.h TCP_DEBUG is default on, but it should work with it off anyway. With gcc-3.4: CC net/core/sock.o In file included from net/core/sock.c:127: include/net/tcp.h: In function `tcp_reset_xmit_timer': include/net/tcp.h:1042: error: label at end of compound statement make[3]: *** [net/core/sock.o] Error 1 make[2]: *** [net/core] Error 2 make[1]: *** [net] Error 2 make[1]: Leaving directory `/build/kernel/linux-2.6.11-s3' make: *** [stamp-build] Error 2 With gcc-3.3: In file included from net/ipv4/icmp.c:84: include/net/tcp.h: In function `tcp_reset_xmit_timer': include/net/tcp.h:1042: warning: deprecated use of label at end of compound statement (times everywhere tcp.h is included) Signed-off-by: Andre Tomt diff -Naur linux-2.6.11/include/net/tcp.h linux-2.6.11-1.1/include/net/tcp.h --- linux-2.6.11/include/net/tcp.h 2005-03-02 08:37:48.000000000 +0100 +++ linux-2.6.11-1.1/include/net/tcp.h 2005-03-12 07:00:52.000000000 +0100 @@ -1039,6 +1039,7 @@ #ifdef TCP_DEBUG printk(tcp_timer_bug_msg); #endif + return; }; } --------------040309010906010804090708-- From oe@port.de Sat Mar 12 02:10:42 2005 Received: with ECARTIS (v1.0.0; list netdev); Sat, 12 Mar 2005 02:10:49 -0800 (PST) Received: from hermes.professional-internet.de (mail.professional-internet.de [213.69.77.2]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j2CAAeUp005771 for ; Sat, 12 Mar 2005 02:10:42 -0800 Received: from mailer.port.de ([195.4.0.127]) by hermes.professional-internet.de (8.12.10/8.12.10) with ESMTP id j2CAAa6Z030720 for ; Sat, 12 Mar 2005 11:10:37 +0100 Received: from mailer.port.de (localhost [127.0.0.1]) by mailer.port.de (8.12.10/8.12.7/SuSE Linux 0.6) with ESMTP id j2CAAaOu029978 for ; Sat, 12 Mar 2005 11:10:37 +0100 Received: (from oe@localhost) by mailer.port.de (8.12.10/8.12.10/Submit) id j2CAAaGx029977; Sat, 12 Mar 2005 11:10:36 +0100 Date: Sat, 12 Mar 2005 11:10:36 +0100 From: Heinz-Juergen Oertel Message-Id: <200503121010.j2CAAaGx029977@mailer.port.de> To: netdev@oss.sgi.com Subject: Re: Error References: <200503120959.j2C9xr6Z030450@hermes.professional-internet.de> In-Reply-To: <200503120959.j2C9xr6Z030450@hermes.professional-internet.de> Precedence: junk X-Loop: loescher@port.de X-Virus-Scanned: ClamAV version 0.83, clamav-milter version 0.83 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 46 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: oe@port.de Precedence: bulk X-list: netdev Content-Length: 431 Lines: 14 Hallo, ich bin vom 2. zum 14. März nicht erreichbar. Treffen Sie mich in Rom zur internationalen CAN Konferenz. Senden Sie Ihre Email in dringenden Fällen zu mailto:service@port.de Hello, I received your mail, but I'm not at the office from March 2nd to 14th. Meet me at the 10th international CAN Conference in Rome. Otherwise I will read your Email when I'm back at office. For important things mail to mailto:service@port.de From webvenza@libero.it Sat Mar 12 02:36:36 2005 Received: with ECARTIS (v1.0.0; list netdev); Sat, 12 Mar 2005 02:36:42 -0800 (PST) Received: from localhost.localdomain (foobar@adsl-166-231.38-151.net24.it [151.38.231.166]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j2CAaYC3007537 for ; Sat, 12 Mar 2005 02:36:35 -0800 Received: from localhost.localdomain (localhost.localdomain [127.0.0.1]) by localhost.localdomain (Postfix) with ESMTP id 0736621695; Sat, 12 Mar 2005 11:39:40 +0100 (CET) MIME-Version: 1.0 Content-Type: multipart/mixed; charset="us-ascii"; boundary="===============1842727395==" Content-Transfer-Encoding: 7bit User-Agent: Python patchbomber v. 0.0.0.0.1 Message-ID: <20050312103939.27851.24067@localhost.localdomain> Subject: [PATCH 1/2] More ethtool support for sis900 and warning fix From: Daniele Venzano To: netdev@oss.sgi.com, jgarzik@pobox.com Date: Sat, 12 Mar 2005 11:39:40 +0100 (CET) X-Virus-Scanned: ClamAV version 0.83, clamav-milter version 0.83 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 48 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: webvenza@libero.it Precedence: bulk X-list: netdev Content-Length: 4203 Lines: 129 This is a MIME message, see the first attachment for the text and the second for the patch --===============1842727395== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Add support to sis900 for the following ethtool ops: - get_link - get_settings - set_settings - nway_reset Rediff against Linus' 2.6.11-bk7 of the patches sent some days ago. Signed-off-by: Daniele Venzano --===============1842727395== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Index: sis900.c =================================================================== --- a/drivers/net/sis900.c (revision 101) +++ b/drivers/net/sis900.c (revision 102) @@ -162,6 +162,7 @@ struct sis900_private { struct mii_phy * mii; struct mii_phy * first_mii; /* record the first mii structure */ unsigned int cur_phy; + struct mii_if_info mii_info; struct timer_list timer; /* Link status detection timer. */ u8 autong_complete; /* 1: auto-negotiate complete */ @@ -201,7 +202,7 @@ static int sis900_open(struct net_device static int sis900_mii_probe (struct net_device * net_dev); static void sis900_init_rxfilter (struct net_device * net_dev); static u16 read_eeprom(long ioaddr, int location); -static u16 mdio_read(struct net_device *net_dev, int phy_id, int location); +static int mdio_read(struct net_device *net_dev, int phy_id, int location); static void mdio_write(struct net_device *net_dev, int phy_id, int location, int val); static void sis900_timer(unsigned long data); static void sis900_check_mode (struct net_device *net_dev, struct mii_phy *mii_phy); @@ -476,7 +477,13 @@ static int __devinit sis900_probe(struct sis_priv->msg_enable = sis900_debug; else sis_priv->msg_enable = SIS900_DEF_MSG; - + + sis_priv->mii_info.dev = net_dev; + sis_priv->mii_info.mdio_read = mdio_read; + sis_priv->mii_info.mdio_write = mdio_write; + sis_priv->mii_info.phy_id_mask = 0x1f; + sis_priv->mii_info.reg_num_mask = 0x1f; + /* Get Mac address according to the chip revision */ pci_read_config_byte(pci_dev, PCI_CLASS_REVISION, &(sis_priv->chipset_rev)); if(netif_msg_probe(sis_priv)) @@ -723,6 +730,8 @@ static u16 sis900_default_phy(struct net pci_name(sis_priv->pci_dev), sis_priv->cur_phy); } + sis_priv->mii_info.phy_id = sis_priv->cur_phy; + status = mdio_read(net_dev, sis_priv->cur_phy, MII_CONTROL); status &= (~MII_CNTL_ISOLATE); @@ -850,7 +859,7 @@ static void mdio_reset(long mdio_addr) * Please see SiS7014 or ICS spec */ -static u16 mdio_read(struct net_device *net_dev, int phy_id, int location) +static int mdio_read(struct net_device *net_dev, int phy_id, int location) { long mdio_addr = net_dev->base_addr + mear; int mii_cmd = MIIread|(phy_id<msg_enable = value; } +static u32 sis900_get_link(struct net_device *net_dev) +{ + struct sis900_private *sis_priv = net_dev->priv; + return mii_link_ok(&sis_priv->mii_info); +} + +static int sis900_get_settings(struct net_device *net_dev, + struct ethtool_cmd *cmd) +{ + struct sis900_private *sis_priv = net_dev->priv; + spin_lock_irq(&sis_priv->lock); + mii_ethtool_gset(&sis_priv->mii_info, cmd); + spin_unlock_irq(&sis_priv->lock); + return 0; +} + +static int sis900_set_settings(struct net_device *net_dev, + struct ethtool_cmd *cmd) +{ + struct sis900_private *sis_priv = net_dev->priv; + int rt; + spin_lock_irq(&sis_priv->lock); + rt = mii_ethtool_sset(&sis_priv->mii_info, cmd); + spin_unlock_irq(&sis_priv->lock); + return rt; +} + +static int sis900_nway_reset(struct net_device *net_dev) +{ + struct sis900_private *sis_priv = net_dev->priv; + return mii_nway_restart(&sis_priv->mii_info); +} + static struct ethtool_ops sis900_ethtool_ops = { .get_drvinfo = sis900_get_drvinfo, .get_msglevel = sis900_get_msglevel, .set_msglevel = sis900_set_msglevel, + .get_link = sis900_get_link, + .get_settings = sis900_get_settings, + .set_settings = sis900_set_settings, + .nway_reset = sis900_nway_reset, }; /** --===============1842727395==-- From webvenza@libero.it Sat Mar 12 02:36:36 2005 Received: with ECARTIS (v1.0.0; list netdev); Sat, 12 Mar 2005 02:36:42 -0800 (PST) Received: from localhost.localdomain (foobar@adsl-166-231.38-151.net24.it [151.38.231.166]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j2CAaZMi007538 for ; Sat, 12 Mar 2005 02:36:35 -0800 Received: from localhost.localdomain (localhost.localdomain [127.0.0.1]) by localhost.localdomain (Postfix) with ESMTP id 108CB2EE69; Sat, 12 Mar 2005 11:39:41 +0100 (CET) MIME-Version: 1.0 Content-Type: multipart/mixed; charset="us-ascii"; boundary="===============0603660046==" Content-Transfer-Encoding: 7bit User-Agent: Python patchbomber v. 0.0.0.0.1 Message-ID: <20050312103941.27851.65526@localhost.localdomain> In-Reply-To: <20050312103939.27851.24067@localhost.localdomain> Subject: [PATCH 2/2] More ethtool support for sis900 and warning fix From: Daniele Venzano To: netdev@oss.sgi.com, jgarzik@pobox.com Date: Sat, 12 Mar 2005 11:39:41 +0100 (CET) X-Virus-Scanned: ClamAV version 0.83, clamav-milter version 0.83 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 47 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: webvenza@libero.it Precedence: bulk X-list: netdev Content-Length: 1181 Lines: 36 This is a MIME message, see the first attachment for the text and the second for the patch --===============0603660046== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Fix for a warning introduced with the patch for netconsole support. Signed-off-by: Daniele Venzano --===============0603660046== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Index: sis900.c =================================================================== --- a/drivers/net/sis900.c (revision 102) +++ b/drivers/net/sis900.c (revision 103) @@ -197,7 +197,10 @@ MODULE_PARM_DESC(multicast_filter_limit, MODULE_PARM_DESC(max_interrupt_work, "SiS 900/7016 maximum events handled per interrupt"); MODULE_PARM_DESC(sis900_debug, "SiS 900/7016 bitmapped debugging message level"); +#ifdef CONFIG_NET_POLL_CONTROLLER static void sis900_poll(struct net_device *dev); +#endif + static int sis900_open(struct net_device *net_dev); static int sis900_mii_probe (struct net_device * net_dev); static void sis900_init_rxfilter (struct net_device * net_dev); --===============0603660046==-- From rich@phekda.gotadsl.co.uk Sat Mar 12 04:02:25 2005 Received: with ECARTIS (v1.0.0; list netdev); Sat, 12 Mar 2005 04:02:34 -0800 (PST) Received: from smtp.nildram.co.uk (smtp.nildram.co.uk [195.112.4.54]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j2CC2OmA013413 for ; Sat, 12 Mar 2005 04:02:24 -0800 Received: from katrina.int.phekda.gotadsl.co.uk (82-133-65-125.dyn.gotadsl.co.uk [82.133.65.125]) by smtp.nildram.co.uk (Postfix) with ESMTP id 845D42BDA0E; Sat, 12 Mar 2005 11:59:55 +0000 (GMT) Received: from [192.168.1.4] (katrina.int.phekda.gotadsl.co.uk [192.168.1.4]) by katrina.int.phekda.gotadsl.co.uk (Postfix) with ESMTP id D7BD1381DD; Sat, 12 Mar 2005 12:02:23 +0000 (GMT) Message-ID: <4232DA4F.5050804@phekda.gotadsl.co.uk> Date: Sat, 12 Mar 2005 12:02:23 +0000 From: Richard Dawe User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.3) Gecko/20041020 X-Accept-Language: en, de, fr MIME-Version: 1.0 To: Stephen Hemminger Cc: Francois Romieu , netdev@oss.sgi.com Subject: Re: [PATCH 4/5] r8169: ethtool message level control References: <20050309113402.05d25e49@dxpl.pdx.osdl.net> In-Reply-To: <20050309113402.05d25e49@dxpl.pdx.osdl.net> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV version 0.83, clamav-milter version 0.83 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 49 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: rich@phekda.gotadsl.co.uk Precedence: bulk X-list: netdev Content-Length: 1314 Lines: 44 Hello. Stephen Hemminger wrote: > Add ethtool message level control support. This is the standard way > to enable/disable console log messages. Also, ratelimit the too much > work at interrupt message, so if under massive packet load the console > doesn't get flooded. > > Signed-off-by: Stephen Hemminger > > diff -Nru a/drivers/net/r8169.c b/drivers/net/r8169.c > --- a/drivers/net/r8169.c 2005-03-09 11:25:04 -08:00 > +++ b/drivers/net/r8169.c 2005-03-09 11:25:04 -08:00 [snip] > @@ -875,12 +885,26 @@ > spin_unlock_irqrestore(&tp->lock, flags); > } > > +static u32 rtl8169_get_msglevel(struct net_device *dev) > +{ > + struct rtl8169_private *tp = netdev_priv(dev); > + return tp->msg_enable; > +} > + > +static void rtl8169_set_msglevel(struct net_device *dev, u32 value) > +{ > + struct rtl8169_private *tp = netdev_priv(dev); > + tp->msg_enable = value; > +} > + [snip] When I posted a patch for message level support a couple of weeks ago (and got a ton of corrective feedback), Francois asked that there be whitespace separating the definitions from executable code in these functions. Bye, Rich =] -- Richard Dawe [ http://homepages.nildram.co.uk/~phekda/richdawe/ ] "You can't evaluate a man by logic alone." -- McCoy, "I, Mudd", Star Trek From rich@phekda.gotadsl.co.uk Sat Mar 12 04:28:20 2005 Received: with ECARTIS (v1.0.0; list netdev); Sat, 12 Mar 2005 04:28:25 -0800 (PST) Received: from smtp.nildram.co.uk (smtp.nildram.co.uk [195.112.4.54]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j2CCSJwo018605 for ; Sat, 12 Mar 2005 04:28:20 -0800 Received: from katrina.int.phekda.gotadsl.co.uk (82-133-65-125.dyn.gotadsl.co.uk [82.133.65.125]) by smtp.nildram.co.uk (Postfix) with ESMTP id AF4C52BCCFA; Sat, 12 Mar 2005 12:28:16 +0000 (GMT) Received: from [192.168.1.4] (katrina.int.phekda.gotadsl.co.uk [192.168.1.4]) by katrina.int.phekda.gotadsl.co.uk (Postfix) with ESMTP id A6A8F381DD; Sat, 12 Mar 2005 12:30:44 +0000 (GMT) Message-ID: <4232E0F4.8020103@phekda.gotadsl.co.uk> Date: Sat, 12 Mar 2005 12:30:44 +0000 From: Richard Dawe User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.3) Gecko/20041020 X-Accept-Language: en, de, fr MIME-Version: 1.0 To: Stephen Hemminger Cc: Francois Romieu , netdev@oss.sgi.com Subject: Re: [PATCH 4/5] r8169: ethtool message level control References: <20050309113402.05d25e49@dxpl.pdx.osdl.net> In-Reply-To: <20050309113402.05d25e49@dxpl.pdx.osdl.net> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV version 0.83, clamav-milter version 0.83 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 50 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: rich@phekda.gotadsl.co.uk Precedence: bulk X-list: netdev Content-Length: 920 Lines: 33 Hello. Stephen Hemminger wrote: > Add ethtool message level control support. This is the standard way > to enable/disable console log messages. Also, ratelimit the too much > work at interrupt message, so if under massive packet load the console > doesn't get flooded. [snip] Works fine for me on my Athlon64 laptop with a 8169 with built-in PHY. Testing: * Remove Ethernet cable, insert module (no params), then "/etc/init.d/network start". Check I get the "PHY reset until link up" message. * "ethtool -s eth0 msglvl 0". Restart networking. Check I get no PHY reset message. * Remove module. Reinsert module with "debug=16" param. Restart networking. Check I get PHY reset message plus chip info in dmesg. * Insert cable, restart networking. Bye, Rich =] -- Richard Dawe [ http://homepages.nildram.co.uk/~phekda/richdawe/ ] "You can't evaluate a man by logic alone." -- McCoy, "I, Mudd", Star Trek From rich@phekda.gotadsl.co.uk Sat Mar 12 04:29:40 2005 Received: with ECARTIS (v1.0.0; list netdev); Sat, 12 Mar 2005 04:29:47 -0800 (PST) Received: from smtp.nildram.co.uk (smtp.nildram.co.uk [195.112.4.54]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j2CCTdi2018858 for ; Sat, 12 Mar 2005 04:29:40 -0800 Received: from katrina.int.phekda.gotadsl.co.uk (82-133-65-125.dyn.gotadsl.co.uk [82.133.65.125]) by smtp.nildram.co.uk (Postfix) with ESMTP id 16E242BD43E; Sat, 12 Mar 2005 12:29:37 +0000 (GMT) Received: from [192.168.1.4] (katrina.int.phekda.gotadsl.co.uk [192.168.1.4]) by katrina.int.phekda.gotadsl.co.uk (Postfix) with ESMTP id 9E43E381DD; Sat, 12 Mar 2005 12:32:05 +0000 (GMT) Message-ID: <4232E145.5030005@phekda.gotadsl.co.uk> Date: Sat, 12 Mar 2005 12:32:05 +0000 From: Richard Dawe User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.3) Gecko/20041020 X-Accept-Language: en, de, fr MIME-Version: 1.0 To: Stephen Hemminger Cc: Francois Romieu , netdev@oss.sgi.com Subject: Re: [PATCH 5/5] r8169: ethtool hardware statistics support References: <20050309113626.6708c93e@dxpl.pdx.osdl.net> In-Reply-To: <20050309113626.6708c93e@dxpl.pdx.osdl.net> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV version 0.83, clamav-milter version 0.83 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 51 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: rich@phekda.gotadsl.co.uk Precedence: bulk X-list: netdev Content-Length: 642 Lines: 21 Hello. Stephen Hemminger wrote: > Add ethtool support for dumping the chip statistics. There aren't lots > of statistics available, but this is what is available according to the RealTek > documentation. [snip] Works fine for me on my Athlon64 laptop with a 8169 with built-in PHY. Did some rsync'ing and some broadcast pings. Statistics looked sane. Also tried stopping networking ("/etc/init.d/network stop") and checked that all the stats had been reset to zero. Thanks, bye, Rich =] -- Richard Dawe [ http://homepages.nildram.co.uk/~phekda/richdawe/ ] "You can't evaluate a man by logic alone." -- McCoy, "I, Mudd", Star Trek From venza@brownhat.org Sat Mar 12 04:42:24 2005 Received: with ECARTIS (v1.0.0; list netdev); Sat, 12 Mar 2005 04:42:31 -0800 (PST) Received: from gateway.milesteg.arr (foobar@adsl-166-231.38-151.net24.it [151.38.231.166]) by oss.sgi.com (8.13.0/8.13.0) with SMTP id j2CCgM6I020183 for ; Sat, 12 Mar 2005 04:42:23 -0800 Received: (qmail 2414 invoked by uid 1000); 12 Mar 2005 12:42:21 -0000 Date: Sat, 12 Mar 2005 13:42:21 +0100 From: Daniele Venzano To: Jeff Garzik , Linux Kernel Mailing List , NetDev Subject: Maintainer change for the sis900 driver Message-ID: <20050312124221.GA2368@gateway.milesteg.arr> Mail-Followup-To: Jeff Garzik , Linux Kernel Mailing List , NetDev Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="Pd0ReVV5GZGQvF3a" Content-Disposition: inline User-Agent: Mutt/1.5.6+20040907i X-Virus-Scanned: ClamAV version 0.83, clamav-milter version 0.83 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 52 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: venza@brownhat.org Precedence: bulk X-list: netdev Content-Length: 1325 Lines: 58 --Pd0ReVV5GZGQvF3a Content-Type: multipart/mixed; boundary="6c2NcOVqGQ03X4Wi" Content-Disposition: inline --6c2NcOVqGQ03X4Wi Content-Type: text/plain; charset=us-ascii Content-Disposition: inline The attached patch updates the sis900 record of MAINTAINERS file. Signed-off-by: Daniele Venzano -- ----------------------------- Daniele Venzano Web: http://www.brownhat.org --6c2NcOVqGQ03X4Wi Content-Type: text/plain; charset=us-ascii Content-Disposition: attachment; filename="sis900_maintainer.diff" --- a/MAINTAINERS 2005-03-12 11:40:46.000000000 +0100 +++ b/MAINTAINERS 2005-03-12 11:44:39.000000000 +0100 @@ -2017,10 +2017,11 @@ S: Maintained SIS 900/7016 FAST ETHERNET DRIVER -P: Ollie Lho -M: ollie@sis.com.tw +P: Daniele Venzano +M: venza@brownhat.org +W: http://www.brownhat.org/sis900.html L: linux-net@vger.kernel.org -S: Supported +S: Maintained SIS FRAMEBUFFER DRIVER P: Thomas Winischhofer --6c2NcOVqGQ03X4Wi-- --Pd0ReVV5GZGQvF3a 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) iD8DBQFCMuOt2rmHZCWzV+0RAtK3AJ9ksAjE51pz+JxA3hyZAhlbU+DcPACfSWeF Tj+GrgfJj/hVHHy84hTKAFQ= =+yWa -----END PGP SIGNATURE----- --Pd0ReVV5GZGQvF3a-- From romieu@fr.zoreil.com Sat Mar 12 06:35:54 2005 Received: with ECARTIS (v1.0.0; list netdev); Sat, 12 Mar 2005 06:36:01 -0800 (PST) Received: from fr.zoreil.com (electric-eye.fr.zoreil.com [213.41.134.224]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j2CEZrAp025555 for ; Sat, 12 Mar 2005 06:35:53 -0800 Received: from electric-eye.fr.zoreil.com (localhost.localdomain [127.0.0.1]) by fr.zoreil.com (8.13.1/8.12.1) with ESMTP id j2CEXUta015198; Sat, 12 Mar 2005 15:33:30 +0100 Received: (from romieu@localhost) by electric-eye.fr.zoreil.com (8.13.1/8.13.1/Submit) id j2CEXPIr015197; Sat, 12 Mar 2005 15:33:25 +0100 Date: Sat, 12 Mar 2005 15:33:24 +0100 From: Francois Romieu To: Richard Dawe Cc: Stephen Hemminger , netdev@oss.sgi.com Subject: Re: [PATCH 4/5] r8169: ethtool message level control Message-ID: <20050312143324.GA15154@electric-eye.fr.zoreil.com> References: <20050309113402.05d25e49@dxpl.pdx.osdl.net> <4232DA4F.5050804@phekda.gotadsl.co.uk> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4232DA4F.5050804@phekda.gotadsl.co.uk> User-Agent: Mutt/1.4.1i X-Organisation: Land of Sunshine Inc. X-Virus-Scanned: ClamAV version 0.83, clamav-milter version 0.83 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 53 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: romieu@fr.zoreil.com Precedence: bulk X-list: netdev Content-Length: 436 Lines: 16 Richard Dawe : [...] > When I posted a patch for message level support a couple of weeks ago > (and got a ton of corrective feedback), Francois asked that there be A ton ? Naahhh, just a few details :o) > whitespace separating the definitions from executable code in these > functions. > I'll fix it and convert the remaining printk as well during the merge of your version with this one. -- Ueimor From kaber@trash.net Sat Mar 12 07:07:32 2005 Received: with ECARTIS (v1.0.0; list netdev); Sat, 12 Mar 2005 07:07:39 -0800 (PST) Received: from kaber.coreworks.de ([62.206.217.67]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j2CF7VQV027122 for ; Sat, 12 Mar 2005 07:07:31 -0800 Received: from localhost ([127.0.0.1]) by kaber.coreworks.de with esmtp (Exim 4.50) id 1DA8D5-0001Js-Fm; Sat, 12 Mar 2005 16:07:23 +0100 Message-ID: <423305AB.7050701@trash.net> Date: Sat, 12 Mar 2005 16:07:23 +0100 From: Patrick McHardy User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.7.5) Gecko/20050106 Debian/1.7.5-1 X-Accept-Language: en MIME-Version: 1.0 To: Stephen Hemminger CC: linux-net@vger.kernel.org, netdev@oss.sgi.com, lartc@mailman.ds9a.nl Subject: Re: [ANNOUNCE] iproute2 release References: <20050310112423.7afdd095@dxpl.pdx.osdl.net> In-Reply-To: <20050310112423.7afdd095@dxpl.pdx.osdl.net> Content-Type: multipart/mixed; boundary="------------080803030603010607050504" X-Virus-Scanned: ClamAV version 0.83, clamav-milter version 0.83 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 54 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: kaber@trash.net Precedence: bulk X-list: netdev Content-Length: 5316 Lines: 174 This is a multi-part message in MIME format. --------------080803030603010607050504 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Stephen Hemminger wrote: > Minor update release for iproute2 is available. It's missing this patch to use correct values for HZ. If you have doubts, please say so, I'm not going to resend a fourth time. To demonstrate the problem: $ while true; do date; ip -s route get 172.16.195.200; sleep 1; done Sat Mar 12 15:55:13 CET 2005 172.16.195.200 dev eth0 src 172.16.1.123 cache expires 2133437sec users 2 used 18 mtu 1500 advmss 1460 hoplimit 64 Sat Mar 12 15:55:14 CET 2005 172.16.195.200 dev eth0 src 172.16.1.123 cache expires 2133436sec users 1 used 19 mtu 1500 advmss 1460 hoplimit 64 Sat Mar 12 15:55:15 CET 2005 172.16.195.200 dev eth0 src 172.16.1.123 cache expires 2133436sec users 1 used 20 mtu 1500 advmss 1460 hoplimit 64 Sat Mar 12 15:55:16 CET 2005 172.16.195.200 dev eth0 src 172.16.1.123 cache expires 2133436sec users 1 used 21 mtu 1500 advmss 1460 hoplimit 64 Sat Mar 12 15:55:17 CET 2005 172.16.195.200 dev eth0 src 172.16.1.123 cache expires 2133436sec users 1 used 22 mtu 1500 advmss 1460 hoplimit 64 Sat Mar 12 15:55:18 CET 2005 172.16.195.200 dev eth0 src 172.16.1.123 cache expires 2133436sec users 1 used 23 mtu 1500 advmss 1460 hoplimit 64 Sat Mar 12 15:55:19 CET 2005 172.16.195.200 dev eth0 src 172.16.1.123 cache expires 2133436sec users 1 used 24 mtu 1500 advmss 1460 hoplimit 64 Sat Mar 12 15:55:20 CET 2005 172.16.195.200 dev eth0 src 172.16.1.123 cache expires 2133436sec users 1 used 25 mtu 1500 advmss 1460 hoplimit 64 Sat Mar 12 15:55:21 CET 2005 172.16.195.200 dev eth0 src 172.16.1.123 cache expires 2133436sec users 1 used 26 mtu 1500 advmss 1460 hoplimit 64 Sat Mar 12 15:55:22 CET 2005 172.16.195.200 dev eth0 src 172.16.1.123 cache expires 2133436sec users 1 used 27 mtu 1500 advmss 1460 hoplimit 64 Sat Mar 12 15:55:23 CET 2005 172.16.195.200 dev eth0 src 172.16.1.123 cache expires 2133436sec users 1 used 28 mtu 1500 advmss 1460 hoplimit 64 Sat Mar 12 15:55:24 CET 2005 172.16.195.200 dev eth0 src 172.16.1.123 cache expires 2133435sec users 1 used 29 mtu 1500 advmss 1460 hoplimit 64 --------------080803030603010607050504 Content-Type: text/plain; name="x" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="x" # This is a BitKeeper generated diff -Nru style patch. # # ChangeSet # 2005/01/29 10:59:53+01:00 kaber@coreworks.de # Use USER_HZ where necessary # # BitKeeper/etc/logging_ok # 2005/01/29 10:59:51+01:00 kaber@coreworks.de +1 -0 # Logging to logging@openlogging.org accepted # # tc/tc_util.c # 2005/01/29 10:59:48+01:00 kaber@coreworks.de +1 -1 # Use USER_HZ where necessary # # lib/utils.c # 2005/01/29 10:59:48+01:00 kaber@coreworks.de +7 -0 # Use USER_HZ where necessary # # ip/iproute.c # 2005/01/29 10:59:48+01:00 kaber@coreworks.de +3 -3 # Use USER_HZ where necessary # # include/utils.h # 2005/01/29 10:59:48+01:00 kaber@coreworks.de +10 -0 # Use USER_HZ where necessary # diff -Nru a/include/utils.h b/include/utils.h --- a/include/utils.h 2005-03-12 15:49:04 +01:00 +++ b/include/utils.h 2005-03-12 15:49:04 +01:00 @@ -113,4 +113,14 @@ return __iproute2_hz_internal; } +extern int __iproute2_user_hz_internal; +extern int __get_user_hz(void); + +static __inline__ int get_user_hz(void) +{ + if (__iproute2_user_hz_internal == 0) + __iproute2_user_hz_internal = __get_user_hz(); + return __iproute2_user_hz_internal; +} + #endif /* __UTILS_H__ */ diff -Nru a/ip/iproute.c b/ip/iproute.c --- a/ip/iproute.c 2005-03-12 15:49:04 +01:00 +++ b/ip/iproute.c 2005-03-12 15:49:04 +01:00 @@ -412,7 +412,7 @@ struct rta_cacheinfo *ci = RTA_DATA(tb[RTA_CACHEINFO]); static int hz; if (!hz) - hz = get_hz(); + hz = get_user_hz(); if (ci->rta_expires != 0) fprintf(fp, " expires %dsec", ci->rta_expires/hz); if (ci->rta_error != 0) @@ -439,7 +439,7 @@ if ((r->rtm_flags & RTM_F_CLONED) || (ci && ci->rta_expires)) { static int hz; if (!hz) - hz = get_hz(); + hz = get_user_hz(); if (r->rtm_flags & RTM_F_CLONED) fprintf(fp, "%s cache ", _SL_); if (ci->rta_expires) @@ -491,7 +491,7 @@ if (i-2 < sizeof(mx_names)/sizeof(char*)) fprintf(fp, " %s", mx_names[i-2]); else - fprintf(fp, " metric%d", i); + fprintf(fp, " metric %d", i); if (mxlock & (1<install != 0) fprintf(f, " installed %d sec", tm->install/hz); if (tm->lastuse != 0) --------------080803030603010607050504-- From rich@phekda.gotadsl.co.uk Sat Mar 12 07:10:10 2005 Received: with ECARTIS (v1.0.0; list netdev); Sat, 12 Mar 2005 07:10:14 -0800 (PST) Received: from smtp.nildram.co.uk (smtp.nildram.co.uk [195.112.4.54]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j2CFA9nv027744 for ; Sat, 12 Mar 2005 07:10:09 -0800 Received: from katrina.int.phekda.gotadsl.co.uk (unknown [82.133.113.201]) by smtp.nildram.co.uk (Postfix) with ESMTP id 21DBB2BDB58; Sat, 12 Mar 2005 15:10:06 +0000 (GMT) Received: from [192.168.1.4] (katrina.int.phekda.gotadsl.co.uk [192.168.1.4]) by katrina.int.phekda.gotadsl.co.uk (Postfix) with ESMTP id EA3C6381DD; Sat, 12 Mar 2005 15:12:34 +0000 (GMT) Message-ID: <423306DC.40105@phekda.gotadsl.co.uk> Date: Sat, 12 Mar 2005 15:12:28 +0000 From: Richard Dawe User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.3) Gecko/20041020 X-Accept-Language: en, de, fr MIME-Version: 1.0 To: Francois Romieu Cc: Stephen Hemminger , netdev@oss.sgi.com Subject: Re: [PATCH 4/5] r8169: ethtool message level control References: <20050309113402.05d25e49@dxpl.pdx.osdl.net> <4232DA4F.5050804@phekda.gotadsl.co.uk> <20050312143324.GA15154@electric-eye.fr.zoreil.com> In-Reply-To: <20050312143324.GA15154@electric-eye.fr.zoreil.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV version 0.83, clamav-milter version 0.83 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 55 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: rich@phekda.gotadsl.co.uk Precedence: bulk X-list: netdev Content-Length: 591 Lines: 20 Hello. Francois Romieu wrote: [snip] > I'll fix it and convert the remaining printk as well during the merge > of your version with this one. I think you should disregard my patch and just use Stephen's. His patch is what I was hoping to end up with, after fixing my patch. ;) Likewise for my statistics patch - please use Stephen's, if you're happy with setting up the DMA mappings on each get_ethtool_stats call. Thanks, bye, Rich =] -- Richard Dawe [ http://homepages.nildram.co.uk/~phekda/richdawe/ ] "You can't evaluate a man by logic alone." -- McCoy, "I, Mudd", Star Trek From jm@jm.kir.nu Sat Mar 12 16:10:17 2005 Received: with ECARTIS (v1.0.0; list netdev); Sat, 12 Mar 2005 16:10:21 -0800 (PST) Received: from jm.kir.nu (dsl017-049-110.sfo4.dsl.speakeasy.net [69.17.49.110]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j2D0AGpL024226 for ; Sat, 12 Mar 2005 16:10:17 -0800 Received: from jm by jm.kir.nu with local (Exim 4.43) id 1DAGn5-0003SY-0H; Sat, 12 Mar 2005 16:17:07 -0800 Date: Sat, 12 Mar 2005 16:17:06 -0800 From: Jouni Malinen To: Jeff Garzik Cc: netdev@oss.sgi.com, jkmaline@cc.hut.fi Subject: [PATCH wireless-2.6 0/10] hostap: Updates from Host AP repository Message-ID: <20050313001706.GA8253@jm.kir.nu> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.5.6i X-Virus-Scanned: ClamAV version 0.83, clamav-milter version 0.83 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 56 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: jkmaline@cc.hut.fi Precedence: bulk X-list: netdev Content-Length: 501 Lines: 10 Following patches bring wireless-2.6 tree up to date with the Host AP repository. First nine patches in the series do not have other dependencies. The last patch requires an update for the Linux wireless extensions which is not yet in the wireless-2.6, so this patch may remain pending for now. I updated the proposal for WE-18 earlier today and sent it to Jean. Hopefully, it will get to wireless-2.6 tree some time soon. -- Jouni Malinen PGP id EFC895FA From jm@jm.kir.nu Sat Mar 12 16:22:07 2005 Received: with ECARTIS (v1.0.0; list netdev); Sat, 12 Mar 2005 16:22:14 -0800 (PST) Received: from jm.kir.nu (dsl017-049-110.sfo4.dsl.speakeasy.net [69.17.49.110]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j2D0M7Me028526 for ; Sat, 12 Mar 2005 16:22:07 -0800 Received: from jm by jm.kir.nu with local (Exim 4.43) id 1DAGyZ-0003TD-3T; Sat, 12 Mar 2005 16:28:59 -0800 Date: Sat, 12 Mar 2005 16:28:58 -0800 From: Jouni Malinen To: Jeff Garzik Cc: netdev@oss.sgi.com Subject: [PATCH wireless-2.6 1/10] hostap: Clear station statistic on accounting start Message-ID: <20050313002858.GB8253@jm.kir.nu> References: <20050313001706.GA8253@jm.kir.nu> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20050313001706.GA8253@jm.kir.nu> User-Agent: Mutt/1.5.6i X-Virus-Scanned: ClamAV version 0.83, clamav-milter version 0.83 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 57 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: jkmaline@cc.hut.fi Precedence: bulk X-list: netdev Content-Length: 9153 Lines: 282 Added support for larger number of BSSes in scan results by using local BSS list to fill in APs that are missing from firmware scan results (firmware limit seemed to be 32 APs at least in some versions); this requires STA firmware version 1.7.x or newer and WPA enabled. Signed-off-by: Jouni Malinen Index: jm-wireless-2.6/drivers/net/wireless/hostap/hostap_80211_rx.c =================================================================== --- jm-wireless-2.6.orig/drivers/net/wireless/hostap/hostap_80211_rx.c 2005-03-12 16:10:40.000000000 -0800 +++ jm-wireless-2.6/drivers/net/wireless/hostap/hostap_80211_rx.c 2005-03-12 16:10:42.000000000 -0800 @@ -361,14 +361,13 @@ int stype) { struct hostap_ieee80211_mgmt *mgmt; - int left; + int left, chan = 0; u8 *pos; u8 *ssid = NULL, *wpa = NULL, *rsn = NULL; size_t ssid_len = 0, wpa_len = 0, rsn_len = 0; struct hostap_bss_info *bss; - if (!local->wpa || - skb->len < IEEE80211_MGMT_HDR_LEN + sizeof(mgmt->u.beacon)) + if (skb->len < IEEE80211_MGMT_HDR_LEN + sizeof(mgmt->u.beacon)) return; mgmt = (struct hostap_ieee80211_mgmt *) skb->data; @@ -395,6 +394,10 @@ rsn = pos; rsn_len = pos[1] + 2; break; + case WLAN_EID_DS_PARAMS: + if (pos[1] >= 1) + chan = pos[2]; + break; } left -= 2 + pos[1]; pos += 2 + pos[1]; @@ -425,6 +428,7 @@ bss->rsn_ie_len = rsn_len; } else bss->rsn_ie_len = 0; + bss->chan = chan; } __hostap_expire_bss(local); spin_unlock(&local->lock); Index: jm-wireless-2.6/drivers/net/wireless/hostap/hostap_ioctl.c =================================================================== --- jm-wireless-2.6.orig/drivers/net/wireless/hostap/hostap_ioctl.c 2005-03-12 16:10:40.000000000 -0800 +++ jm-wireless-2.6/drivers/net/wireless/hostap/hostap_ioctl.c 2005-03-12 16:10:42.000000000 -0800 @@ -1768,7 +1768,7 @@ struct hostap_bss_info *bss, u8 *bssid, char *current_ev, char *end_buf) { - int i; + int i, chan; struct iw_event iwe; char *current_val; u16 capabilities; @@ -1814,8 +1814,12 @@ memset(&iwe, 0, sizeof(iwe)); iwe.cmd = SIOCGIWMODE; - capabilities = le16_to_cpu(hostscan ? hscan->capability : - scan->capability); + if (bss) { + capabilities = bss->capab_info; + } else { + capabilities = le16_to_cpu(hostscan ? hscan->capability : + scan->capability); + } if (capabilities & (WLAN_CAPABILITY_ESS | WLAN_CAPABILITY_IBSS)) { if (capabilities & WLAN_CAPABILITY_ESS) @@ -1829,26 +1833,38 @@ memset(&iwe, 0, sizeof(iwe)); iwe.cmd = SIOCGIWFREQ; - iwe.u.freq.m = freq_list[le16_to_cpu(hostscan ? hscan->chid : - scan->chid) - 1] * 100000; - iwe.u.freq.e = 1; - iwe.len = IW_EV_FREQ_LEN; - current_ev = iwe_stream_add_event(current_ev, end_buf, &iwe, - IW_EV_FREQ_LEN); - - memset(&iwe, 0, sizeof(iwe)); - iwe.cmd = IWEVQUAL; - if (hostscan) { - iwe.u.qual.level = le16_to_cpu(hscan->sl); - iwe.u.qual.noise = le16_to_cpu(hscan->anl); + if (hscan || scan) { + chan = hostscan ? hscan->chid : scan->chid; + } else if (bss) { + chan = bss->chan; } else { - iwe.u.qual.level = HFA384X_LEVEL_TO_dBm(le16_to_cpu(scan->sl)); - iwe.u.qual.noise = HFA384X_LEVEL_TO_dBm( - le16_to_cpu(scan->anl)); + chan = 0; + } + + if (chan > 0) { + iwe.u.freq.m = freq_list[le16_to_cpu(chan - 1)] * 100000; + iwe.u.freq.e = 1; + iwe.len = IW_EV_FREQ_LEN; + current_ev = iwe_stream_add_event(current_ev, end_buf, &iwe, + IW_EV_FREQ_LEN); + } + + if (scan || hscan) { + memset(&iwe, 0, sizeof(iwe)); + iwe.cmd = IWEVQUAL; + if (hostscan) { + iwe.u.qual.level = le16_to_cpu(hscan->sl); + iwe.u.qual.noise = le16_to_cpu(hscan->anl); + } else { + iwe.u.qual.level = + HFA384X_LEVEL_TO_dBm(le16_to_cpu(scan->sl)); + iwe.u.qual.noise = + HFA384X_LEVEL_TO_dBm(le16_to_cpu(scan->anl)); + } + iwe.len = IW_EV_QUAL_LEN; + current_ev = iwe_stream_add_event(current_ev, end_buf, &iwe, + IW_EV_QUAL_LEN); } - iwe.len = IW_EV_QUAL_LEN; - current_ev = iwe_stream_add_event(current_ev, end_buf, &iwe, - IW_EV_QUAL_LEN); memset(&iwe, 0, sizeof(iwe)); iwe.cmd = SIOCGIWENCODE; @@ -1860,45 +1876,54 @@ iwe.len = IW_EV_POINT_LEN + iwe.u.data.length; current_ev = iwe_stream_add_point(current_ev, end_buf, &iwe, ""); - memset(&iwe, 0, sizeof(iwe)); - iwe.cmd = SIOCGIWRATE; - current_val = current_ev + IW_EV_LCP_LEN; - pos = hostscan ? hscan->sup_rates : scan->sup_rates; - for (i = 0; i < sizeof(scan->sup_rates); i++) { - if (pos[i] == 0) - break; - /* Bit rate given in 500 kb/s units (+ 0x80) */ - iwe.u.bitrate.value = ((pos[i] & 0x7f) * 500000); - current_val = iwe_stream_add_value( - current_ev, current_val, end_buf, &iwe, - IW_EV_PARAM_LEN); - } - /* Check if we added any event */ - if ((current_val - current_ev) > IW_EV_LCP_LEN) - current_ev = current_val; - - memset(&iwe, 0, sizeof(iwe)); - iwe.cmd = IWEVCUSTOM; - sprintf(buf, "bcn_int=%d", - le16_to_cpu(hostscan ? hscan->beacon_interval : - scan->beacon_interval)); - iwe.u.data.length = strlen(buf); - current_ev = iwe_stream_add_point(current_ev, end_buf, &iwe, buf); + /* TODO: add SuppRates into BSS table */ + if (scan || hscan) { + memset(&iwe, 0, sizeof(iwe)); + iwe.cmd = SIOCGIWRATE; + current_val = current_ev + IW_EV_LCP_LEN; + pos = hostscan ? hscan->sup_rates : scan->sup_rates; + for (i = 0; i < sizeof(scan->sup_rates); i++) { + if (pos[i] == 0) + break; + /* Bit rate given in 500 kb/s units (+ 0x80) */ + iwe.u.bitrate.value = ((pos[i] & 0x7f) * 500000); + current_val = iwe_stream_add_value( + current_ev, current_val, end_buf, &iwe, + IW_EV_PARAM_LEN); + } + /* Check if we added any event */ + if ((current_val - current_ev) > IW_EV_LCP_LEN) + current_ev = current_val; + } - memset(&iwe, 0, sizeof(iwe)); - iwe.cmd = IWEVCUSTOM; - sprintf(buf, "resp_rate=%d", le16_to_cpu(hostscan ? hscan->rate : - scan->rate)); - iwe.u.data.length = strlen(buf); - current_ev = iwe_stream_add_point(current_ev, end_buf, &iwe, buf); + /* TODO: add BeaconInt,resp_rate,atim into BSS table */ + if (scan || hscan) { + memset(&iwe, 0, sizeof(iwe)); + iwe.cmd = IWEVCUSTOM; + sprintf(buf, "bcn_int=%d", + le16_to_cpu(hostscan ? hscan->beacon_interval : + scan->beacon_interval)); + iwe.u.data.length = strlen(buf); + current_ev = iwe_stream_add_point(current_ev, end_buf, &iwe, + buf); - if (hostscan && (capabilities & WLAN_CAPABILITY_IBSS)) { memset(&iwe, 0, sizeof(iwe)); iwe.cmd = IWEVCUSTOM; - sprintf(buf, "atim=%d", le16_to_cpu(hscan->atim)); + sprintf(buf, "resp_rate=%d", le16_to_cpu(hostscan ? + hscan->rate : + scan->rate)); iwe.u.data.length = strlen(buf); current_ev = iwe_stream_add_point(current_ev, end_buf, &iwe, buf); + + if (hostscan && (capabilities & WLAN_CAPABILITY_IBSS)) { + memset(&iwe, 0, sizeof(iwe)); + iwe.cmd = IWEVCUSTOM; + sprintf(buf, "atim=%d", le16_to_cpu(hscan->atim)); + iwe.u.data.length = strlen(buf); + current_ev = iwe_stream_add_point(current_ev, end_buf, + &iwe, buf); + } } if (bss && bss->wpa_ie_len > 0 && bss->wpa_ie_len <= MAX_WPA_IE_LEN ) { @@ -1948,6 +1973,12 @@ spin_lock_bh(&local->lock); + list_for_each(ptr, &local->bss_list) { + struct hostap_bss_info *bss; + bss = list_entry(ptr, struct hostap_bss_info, list); + bss->included = 0; + } + hostscan = local->last_scan_type == PRISM2_HOSTSCAN; entries = hostscan ? local->last_hostscan_results_count : local->last_scan_results_count; @@ -1965,6 +1996,7 @@ struct hostap_bss_info *bss; bss = list_entry(ptr, struct hostap_bss_info, list); if (memcmp(bss->bssid, bssid, ETH_ALEN) == 0) { + bss->included = 1; current_ev = __prism2_translate_scan( local, scan, hscan, hostscan, bss, bssid, current_ev, end_buf); @@ -1984,6 +2016,25 @@ } } + /* Prism2 firmware has limits (32 at least in some versions) for number + * of BSSes in scan results. Extend this limit by using local BSS list. + */ + list_for_each(ptr, &local->bss_list) { + struct hostap_bss_info *bss; + bss = list_entry(ptr, struct hostap_bss_info, list); + if (bss->included) + continue; + current_ev = __prism2_translate_scan(local, NULL, NULL, 0, bss, + bss->bssid, current_ev, + end_buf); + /* Check if there is space for one more entry */ + if ((end_buf - current_ev) <= IW_EV_ADDR_LEN) { + /* Ask user space to try again with a bigger buffer */ + spin_unlock_bh(&local->lock); + return -E2BIG; + } + } + spin_unlock_bh(&local->lock); return current_ev - buffer; Index: jm-wireless-2.6/drivers/net/wireless/hostap/hostap_wlan.h =================================================================== --- jm-wireless-2.6.orig/drivers/net/wireless/hostap/hostap_wlan.h 2005-03-12 16:10:40.000000000 -0800 +++ jm-wireless-2.6/drivers/net/wireless/hostap/hostap_wlan.h 2005-03-12 16:10:42.000000000 -0800 @@ -630,6 +630,8 @@ size_t wpa_ie_len; u8 rsn_ie[MAX_WPA_IE_LEN]; size_t rsn_ie_len; + int chan; + int included; }; -- Jouni Malinen PGP id EFC895FA From jm@jm.kir.nu Sat Mar 12 16:22:48 2005 Received: with ECARTIS (v1.0.0; list netdev); Sat, 12 Mar 2005 16:22:52 -0800 (PST) Received: from jm.kir.nu (dsl017-049-110.sfo4.dsl.speakeasy.net [69.17.49.110]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j2D0Mm9I028724 for ; Sat, 12 Mar 2005 16:22:48 -0800 Received: from jm by jm.kir.nu with local (Exim 4.43) id 1DAGzE-0003TN-Cq; Sat, 12 Mar 2005 16:29:40 -0800 Date: Sat, 12 Mar 2005 16:29:40 -0800 From: Jouni Malinen To: Jeff Garzik Cc: netdev@oss.sgi.com Subject: [PATCH wireless-2.6 2/10] hostap: Include asm/io.h Message-ID: <20050313002940.GC8253@jm.kir.nu> References: <20050313001706.GA8253@jm.kir.nu> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20050313001706.GA8253@jm.kir.nu> User-Agent: Mutt/1.5.6i X-Virus-Scanned: ClamAV version 0.83, clamav-milter version 0.83 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 58 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: jkmaline@cc.hut.fi Precedence: bulk X-list: netdev Content-Length: 1189 Lines: 33 Include asm/io.h into hostap_{pci,plx}.c since this seems to be needed for ARM on Linux 2.6.x and this file is already included into hostap_cs.c anyway. Signed-off-by: Jouni Malinen Index: jm-wireless-2.6/drivers/net/wireless/hostap/hostap_pci.c =================================================================== --- jm-wireless-2.6.orig/drivers/net/wireless/hostap/hostap_pci.c 2005-03-12 16:10:40.000000000 -0800 +++ jm-wireless-2.6/drivers/net/wireless/hostap/hostap_pci.c 2005-03-12 16:10:50.000000000 -0800 @@ -17,6 +17,7 @@ #include #include +#include #include "hostap_wlan.h" Index: jm-wireless-2.6/drivers/net/wireless/hostap/hostap_plx.c =================================================================== --- jm-wireless-2.6.orig/drivers/net/wireless/hostap/hostap_plx.c 2005-03-12 16:10:40.000000000 -0800 +++ jm-wireless-2.6/drivers/net/wireless/hostap/hostap_plx.c 2005-03-12 16:10:50.000000000 -0800 @@ -20,6 +20,7 @@ #include #include +#include #include "hostap_wlan.h" -- Jouni Malinen PGP id EFC895FA From jm@jm.kir.nu Sat Mar 12 16:23:59 2005 Received: with ECARTIS (v1.0.0; list netdev); Sat, 12 Mar 2005 16:24:03 -0800 (PST) Received: from jm.kir.nu (dsl017-049-110.sfo4.dsl.speakeasy.net [69.17.49.110]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j2D0Nx59029593 for ; Sat, 12 Mar 2005 16:23:59 -0800 Received: from jm by jm.kir.nu with local (Exim 4.43) id 1DAH0N-0003Td-9n; Sat, 12 Mar 2005 16:30:51 -0800 Date: Sat, 12 Mar 2005 16:30:51 -0800 From: Jouni Malinen To: Jeff Garzik Cc: netdev@oss.sgi.com Subject: [PATCH wireless-2.6 3/10] hostap: Disable interrupts before Genesis mode Message-ID: <20050313003051.GD8253@jm.kir.nu> References: <20050313001706.GA8253@jm.kir.nu> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20050313001706.GA8253@jm.kir.nu> User-Agent: Mutt/1.5.6i X-Virus-Scanned: ClamAV version 0.83, clamav-milter version 0.83 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 59 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: jkmaline@cc.hut.fi Precedence: bulk X-list: netdev Content-Length: 1086 Lines: 26 Disable interrupts before trying to initialize card after Genesis mode download. This seems to be required at least with SanDisk ConnectPlus, but seems to be a good idea in generic, so just do it with all cards. Signed-off-by: Jouni Malinen Index: jm-wireless-2.6/drivers/net/wireless/hostap/hostap_download.c =================================================================== --- jm-wireless-2.6.orig/drivers/net/wireless/hostap/hostap_download.c 2005-03-12 16:10:40.000000000 -0800 +++ jm-wireless-2.6/drivers/net/wireless/hostap/hostap_download.c 2005-03-12 16:10:52.000000000 -0800 @@ -464,6 +464,11 @@ local->hw_downloading = 0; PDEBUG(DEBUG_EXTRA2, "Trying to initialize card\n"); + /* + * Make sure the INIT command does not generate a command completion + * event by disabling interrupts. + */ + hfa384x_disable_interrupts(dev); if (prism2_hw_init(dev, 1)) { printk(KERN_DEBUG "%s: Initialization after genesis mode " "download failed\n", dev->name); -- Jouni Malinen PGP id EFC895FA From jm@jm.kir.nu Sat Mar 12 16:24:40 2005 Received: with ECARTIS (v1.0.0; list netdev); Sat, 12 Mar 2005 16:24:46 -0800 (PST) Received: from jm.kir.nu (dsl017-049-110.sfo4.dsl.speakeasy.net [69.17.49.110]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j2D0OekY029947 for ; Sat, 12 Mar 2005 16:24:40 -0800 Received: from jm by jm.kir.nu with local (Exim 4.43) id 1DAH12-0003Tn-4h; Sat, 12 Mar 2005 16:31:32 -0800 Date: Sat, 12 Mar 2005 16:31:32 -0800 From: Jouni Malinen To: Jeff Garzik Cc: netdev@oss.sgi.com Subject: [PATCH wireless-2.6 4/10] hostap: Add support for multi-func SanDisk ConnectPlus Message-ID: <20050313003132.GE8253@jm.kir.nu> References: <20050313001706.GA8253@jm.kir.nu> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20050313001706.GA8253@jm.kir.nu> User-Agent: Mutt/1.5.6i X-Virus-Scanned: ClamAV version 0.83, clamav-milter version 0.83 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 60 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: jkmaline@cc.hut.fi Precedence: bulk X-list: netdev Content-Length: 5817 Lines: 210 Added support for the special initialization needed for the wireless part of multi-function SanDisk ConnectPlus CF cards (manfid 0xd601, 0x0101). Signed-off-by: Jouni Malinen Index: jm-wireless-2.6/drivers/net/wireless/hostap/hostap_cs.c =================================================================== --- jm-wireless-2.6.orig/drivers/net/wireless/hostap/hostap_cs.c 2005-03-12 16:10:40.000000000 -0800 +++ jm-wireless-2.6/drivers/net/wireless/hostap/hostap_cs.c 2005-03-12 16:10:53.000000000 -0800 @@ -217,6 +217,137 @@ return 0; } + +/* + * SanDisk CompactFlash WLAN Flashcard - Product Manual v1.0 + * Document No. 20-10-00058, January 2004 + * http://www.sandisk.com/pdf/industrial/ProdManualCFWLANv1.0.pdf + */ +#define SANDISK_WLAN_ACTIVATION_OFF 0x40 +#define SANDISK_HCR_OFF 0x42 + + +static void sandisk_set_iobase(local_info_t *local) +{ + int res; + conf_reg_t reg; + + reg.Function = 0; + reg.Action = CS_WRITE; + reg.Offset = 0x10; /* 0x3f0 IO base 1 */ + reg.Value = local->link->io.BasePort1 & 0x00ff; + res = pcmcia_access_configuration_register(local->link->handle, ®); + if (res != CS_SUCCESS) { + printk(KERN_DEBUG "Prism3 SanDisk - failed to set I/O base 0 -" + " res=%d\n", res); + } + udelay(10); + + reg.Function = 0; + reg.Action = CS_WRITE; + reg.Offset = 0x12; /* 0x3f2 IO base 2 */ + reg.Value = (local->link->io.BasePort1 & 0xff00) >> 8; + res = pcmcia_access_configuration_register(local->link->handle, ®); + if (res != CS_SUCCESS) { + printk(KERN_DEBUG "Prism3 SanDisk - failed to set I/O base 1 -" + " res=%d\n", res); + } +} + + +static void sandisk_write_hcr(local_info_t *local, int hcr) +{ + struct net_device *dev = local->dev; + int i; + + HFA384X_OUTB(0x80, SANDISK_WLAN_ACTIVATION_OFF); + udelay(50); + for (i = 0; i < 10; i++) { + HFA384X_OUTB(hcr, SANDISK_HCR_OFF); + } + udelay(55); + HFA384X_OUTB(0x45, SANDISK_WLAN_ACTIVATION_OFF); +} + + +static void sandisk_enable_wireless(struct net_device *dev) +{ + int res; + conf_reg_t reg; + struct hostap_interface *iface = dev->priv; + local_info_t *local = iface->local; + tuple_t tuple; + cisparse_t parse; + u_char buf[64]; + + if (local->link->io.NumPorts1 < 0x42) { + /* Not enough ports to be SanDisk multi-function card */ + return; + } + + tuple.DesiredTuple = CISTPL_MANFID; + tuple.Attributes = TUPLE_RETURN_COMMON; + tuple.TupleData = buf; + tuple.TupleDataMax = sizeof(buf); + tuple.TupleOffset = 0; + if (pcmcia_get_first_tuple(local->link->handle, &tuple) || + pcmcia_get_tuple_data(local->link->handle, &tuple) || + pcmcia_parse_tuple(local->link->handle, &tuple, &parse) || + parse.manfid.manf != 0xd601 || parse.manfid.card != 0x0101) { + /* No SanDisk manfid found */ + return; + } + + tuple.DesiredTuple = CISTPL_LONGLINK_MFC; + if (pcmcia_get_first_tuple(local->link->handle, &tuple) || + pcmcia_get_tuple_data(local->link->handle, &tuple) || + pcmcia_parse_tuple(local->link->handle, &tuple, &parse) || + parse.longlink_mfc.nfn < 2) { + /* No multi-function links found */ + return; + } + + printk(KERN_DEBUG "%s: Multi-function SanDisk ConnectPlus detected" + " - using vendor-specific initialization\n", dev->name); + local->sandisk_connectplus = 1; + + reg.Function = 0; + reg.Action = CS_WRITE; + reg.Offset = CISREG_COR; + reg.Value = COR_SOFT_RESET; + res = pcmcia_access_configuration_register(local->link->handle, ®); + if (res != CS_SUCCESS) { + printk(KERN_DEBUG "%s: SanDisk - COR sreset failed (%d)\n", + dev->name, res); + return; + } + mdelay(5); + + reg.Function = 0; + reg.Action = CS_WRITE; + reg.Offset = CISREG_COR; + /* + * Do not enable interrupts here to avoid some bogus events. Interrupts + * will be enabled during the first cor_sreset call. + */ + reg.Value = COR_LEVEL_REQ | 0x8 | COR_ADDR_DECODE | COR_FUNC_ENA; + res = pcmcia_access_configuration_register(local->link->handle, ®); + if (res != CS_SUCCESS) { + printk(KERN_DEBUG "%s: SanDisk - COR sreset failed (%d)\n", + dev->name, res); + return; + } + mdelay(5); + + sandisk_set_iobase(local); + + HFA384X_OUTB(0xc5, SANDISK_WLAN_ACTIVATION_OFF); + udelay(10); + HFA384X_OUTB(0x4b, SANDISK_WLAN_ACTIVATION_OFF); + udelay(10); +} + + static void prism2_pccard_cor_sreset(local_info_t *local) { int res; @@ -247,9 +378,11 @@ return; } - mdelay(2); + mdelay(local->sandisk_connectplus ? 5 : 2); reg.Value &= ~COR_SOFT_RESET; + if (local->sandisk_connectplus) + reg.Value |= COR_IREQ_ENA; res = pcmcia_access_configuration_register(local->link->handle, ®); if (res != CS_SUCCESS) { printk(KERN_DEBUG "prism2_pccard_cor_sreset failed 3 (%d)\n", @@ -257,7 +390,10 @@ return; } - mdelay(2); + mdelay(local->sandisk_connectplus ? 5 : 2); + + if (local->sandisk_connectplus) + sandisk_set_iobase(local); } @@ -270,6 +406,11 @@ if (!prism2_pccard_card_present(local)) return; + if (local->sandisk_connectplus) { + sandisk_write_hcr(local, hcr); + return; + } + reg.Function = 0; reg.Action = CS_READ; reg.Offset = CISREG_COR; @@ -643,6 +784,8 @@ local->shutdown = 0; + sandisk_enable_wireless(dev); + ret = prism2_hw_config(dev, 1); if (!ret) { ret = hostap_hw_ready(dev); Index: jm-wireless-2.6/drivers/net/wireless/hostap/hostap_wlan.h =================================================================== --- jm-wireless-2.6.orig/drivers/net/wireless/hostap/hostap_wlan.h 2005-03-12 16:10:42.000000000 -0800 +++ jm-wireless-2.6/drivers/net/wireless/hostap/hostap_wlan.h 2005-03-12 16:10:53.000000000 -0800 @@ -895,6 +895,7 @@ #ifdef PRISM2_PCCARD dev_node_t node; dev_link_t *link; + int sandisk_connectplus; #endif /* PRISM2_PCCARD */ #ifdef PRISM2_PLX -- Jouni Malinen PGP id EFC895FA From jm@jm.kir.nu Sat Mar 12 16:25:20 2005 Received: with ECARTIS (v1.0.0; list netdev); Sat, 12 Mar 2005 16:25:26 -0800 (PST) Received: from jm.kir.nu (dsl017-049-110.sfo4.dsl.speakeasy.net [69.17.49.110]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j2D0PKMZ030443 for ; Sat, 12 Mar 2005 16:25:20 -0800 Received: from jm by jm.kir.nu with local (Exim 4.43) id 1DAH1g-0003U2-6t; Sat, 12 Mar 2005 16:32:12 -0800 Date: Sat, 12 Mar 2005 16:32:12 -0800 From: Jouni Malinen To: Jeff Garzik Cc: netdev@oss.sgi.com Subject: [PATCH wireless-2.6 5/10] hostap: Fix procfs rmdir after ifname change Message-ID: <20050313003212.GF8253@jm.kir.nu> References: <20050313001706.GA8253@jm.kir.nu> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20050313001706.GA8253@jm.kir.nu> User-Agent: Mutt/1.5.6i X-Virus-Scanned: ClamAV version 0.83, clamav-milter version 0.83 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 61 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: jkmaline@cc.hut.fi Precedence: bulk X-list: netdev Content-Length: 987 Lines: 24 Fixed /proc/net/hostap/wlan# removing to use name from the procfs instead of from the netdevice. This allows the procfs entry be removed nicely even if the network interface has been renamed. Signed-off-by: Jouni Malinen Index: jm-wireless-2.6/drivers/net/wireless/hostap/hostap_proc.c =================================================================== --- jm-wireless-2.6.orig/drivers/net/wireless/hostap/hostap_proc.c 2005-03-12 16:10:40.000000000 -0800 +++ jm-wireless-2.6/drivers/net/wireless/hostap/hostap_proc.c 2005-03-12 16:10:55.000000000 -0800 @@ -456,8 +456,8 @@ #ifndef PRISM2_NO_PROCFS_DEBUG remove_proc_entry("debug", local->proc); #endif /* PRISM2_NO_PROCFS_DEBUG */ - if (local->ddev != NULL && hostap_proc != NULL) - remove_proc_entry(local->ddev->name, hostap_proc); + if (hostap_proc != NULL) + remove_proc_entry(local->proc->name, hostap_proc); } } -- Jouni Malinen PGP id EFC895FA From jm@jm.kir.nu Sat Mar 12 16:26:05 2005 Received: with ECARTIS (v1.0.0; list netdev); Sat, 12 Mar 2005 16:26:12 -0800 (PST) Received: from jm.kir.nu (dsl017-049-110.sfo4.dsl.speakeasy.net [69.17.49.110]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j2D0Q5OO030989 for ; Sat, 12 Mar 2005 16:26:05 -0800 Received: from jm by jm.kir.nu with local (Exim 4.43) id 1DAH2P-0003UT-8i; Sat, 12 Mar 2005 16:32:57 -0800 Date: Sat, 12 Mar 2005 16:32:57 -0800 From: Jouni Malinen To: Jeff Garzik Cc: netdev@oss.sgi.com Subject: [PATCH wireless-2.6 6/10] hostap: Clear station statistic on accounting start Message-ID: <20050313003257.GG8253@jm.kir.nu> References: <20050313001706.GA8253@jm.kir.nu> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20050313001706.GA8253@jm.kir.nu> User-Agent: Mutt/1.5.6i X-Virus-Scanned: ClamAV version 0.83, clamav-milter version 0.83 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 62 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: jkmaline@cc.hut.fi Precedence: bulk X-list: netdev Content-Length: 2182 Lines: 69 From Gunter Burchardt Added new ioctl command for hostapd to clear station specific accounting data when starting a new accounting session. Signed-off-by: Jouni Malinen Index: jm-wireless-2.6/drivers/net/wireless/hostap/hostap_ap.c =================================================================== --- jm-wireless-2.6.orig/drivers/net/wireless/hostap/hostap_ap.c 2005-03-12 16:10:40.000000000 -0800 +++ jm-wireless-2.6/drivers/net/wireless/hostap/hostap_ap.c 2005-03-12 16:10:56.000000000 -0800 @@ -2582,6 +2582,31 @@ } +static int prism2_hostapd_sta_clear_stats(struct ap_data *ap, + struct prism2_hostapd_param *param) +{ + struct sta_info *sta; + int rate; + + spin_lock_bh(&ap->sta_table_lock); + sta = ap_get_sta(ap, param->sta_addr); + if (sta) { + sta->rx_packets = sta->tx_packets = 0; + sta->rx_bytes = sta->tx_bytes = 0; + for (rate = 0; rate < WLAN_RATE_COUNT; rate++) { + sta->tx_count[rate] = 0; + sta->rx_count[rate] = 0; + } + } + spin_unlock_bh(&ap->sta_table_lock); + + if (!sta) + return -ENOENT; + + return 0; +} + + static int prism2_hostapd(struct ap_data *ap, struct prism2_hostapd_param *param) { @@ -2597,6 +2622,8 @@ return prism2_hostapd_get_info_sta(ap, param); case PRISM2_HOSTAPD_SET_FLAGS_STA: return prism2_hostapd_set_flags_sta(ap, param); + case PRISM2_HOSTAPD_STA_CLEAR_STATS: + return prism2_hostapd_sta_clear_stats(ap, param); default: printk(KERN_WARNING "prism2_hostapd: unknown cmd=%d\n", param->cmd); Index: jm-wireless-2.6/drivers/net/wireless/hostap/hostap_common.h =================================================================== --- jm-wireless-2.6.orig/drivers/net/wireless/hostap/hostap_common.h 2005-03-12 16:10:40.000000000 -0800 +++ jm-wireless-2.6/drivers/net/wireless/hostap/hostap_common.h 2005-03-12 16:10:56.000000000 -0800 @@ -482,6 +482,7 @@ PRISM2_HOSTAPD_SET_GENERIC_ELEMENT = 12, PRISM2_HOSTAPD_MLME = 13, PRISM2_HOSTAPD_SCAN_REQ = 14, + PRISM2_HOSTAPD_STA_CLEAR_STATS = 15, }; #define PRISM2_HOSTAPD_MAX_BUF_SIZE 1024 -- Jouni Malinen PGP id EFC895FA From jm@jm.kir.nu Sat Mar 12 16:27:21 2005 Received: with ECARTIS (v1.0.0; list netdev); Sat, 12 Mar 2005 16:27:25 -0800 (PST) Received: from jm.kir.nu (dsl017-049-110.sfo4.dsl.speakeasy.net [69.17.49.110]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j2D0RLR0031689 for ; Sat, 12 Mar 2005 16:27:21 -0800 Received: from jm by jm.kir.nu with local (Exim 4.43) id 1DAH3c-0003Ud-U8; Sat, 12 Mar 2005 16:34:12 -0800 Date: Sat, 12 Mar 2005 16:34:12 -0800 From: Jouni Malinen To: Jeff Garzik Cc: netdev@oss.sgi.com Subject: [PATCH wireless-2.6 7/10] hostap: Rate limiting for debug messages Message-ID: <20050313003412.GH8253@jm.kir.nu> References: <20050313001706.GA8253@jm.kir.nu> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20050313001706.GA8253@jm.kir.nu> User-Agent: Mutt/1.5.6i X-Virus-Scanned: ClamAV version 0.83, clamav-milter version 0.83 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 63 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: jkmaline@cc.hut.fi Precedence: bulk X-list: netdev Content-Length: 976 Lines: 25 Limit rate of debug messages for interrupts before card is ready. This could happen when multiple devices are sharing the same interrupt. Signed-off-by: Jouni Malinen Index: jm-wireless-2.6/drivers/net/wireless/hostap/hostap_hw.c =================================================================== --- jm-wireless-2.6.orig/drivers/net/wireless/hostap/hostap_hw.c 2005-03-12 16:10:40.000000000 -0800 +++ jm-wireless-2.6/drivers/net/wireless/hostap/hostap_hw.c 2005-03-12 16:10:58.000000000 -0800 @@ -2790,8 +2790,10 @@ prism2_io_debug_add(dev, PRISM2_IO_DEBUG_CMD_INTERRUPT, 0, 0); if (local->func->card_present && !local->func->card_present(local)) { - printk(KERN_DEBUG "%s: Interrupt, but dev not OK\n", - dev->name); + if (net_ratelimit()) { + printk(KERN_DEBUG "%s: Interrupt, but dev not OK\n", + dev->name); + } return IRQ_HANDLED; } -- Jouni Malinen PGP id EFC895FA From jm@jm.kir.nu Sat Mar 12 16:27:57 2005 Received: with ECARTIS (v1.0.0; list netdev); Sat, 12 Mar 2005 16:28:01 -0800 (PST) Received: from jm.kir.nu (dsl017-049-110.sfo4.dsl.speakeasy.net [69.17.49.110]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j2D0Rug4031976 for ; Sat, 12 Mar 2005 16:27:57 -0800 Received: from jm by jm.kir.nu with local (Exim 4.43) id 1DAH4C-0003Un-Rk; Sat, 12 Mar 2005 16:34:48 -0800 Date: Sat, 12 Mar 2005 16:34:48 -0800 From: Jouni Malinen To: Jeff Garzik Cc: netdev@oss.sgi.com Subject: [PATCH wireless-2.6 8/10] hostap: Improved suspend Message-ID: <20050313003448.GI8253@jm.kir.nu> References: <20050313001706.GA8253@jm.kir.nu> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20050313001706.GA8253@jm.kir.nu> User-Agent: Mutt/1.5.6i X-Virus-Scanned: ClamAV version 0.83, clamav-milter version 0.83 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 64 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: jkmaline@cc.hut.fi Precedence: bulk X-list: netdev Content-Length: 2392 Lines: 68 Improved suspend operation: disable firmware (hostap_cs) and generate disconnect event to trigger wpa_supplicant to reassociate immediately after resume. Signed-off-by: Jouni Malinen Index: jm-wireless-2.6/drivers/net/wireless/hostap/hostap_cs.c =================================================================== --- jm-wireless-2.6.orig/drivers/net/wireless/hostap/hostap_cs.c 2005-03-12 16:10:53.000000000 -0800 +++ jm-wireless-2.6/drivers/net/wireless/hostap/hostap_cs.c 2005-03-12 16:10:59.000000000 -0800 @@ -870,6 +870,7 @@ netif_stop_queue(dev); netif_device_detach(dev); } + prism2_suspend(dev); pcmcia_release_configuration(link->handle); } break; Index: jm-wireless-2.6/drivers/net/wireless/hostap/hostap_hw.c =================================================================== --- jm-wireless-2.6.orig/drivers/net/wireless/hostap/hostap_hw.c 2005-03-12 16:10:58.000000000 -0800 +++ jm-wireless-2.6/drivers/net/wireless/hostap/hostap_hw.c 2005-03-12 16:10:59.000000000 -0800 @@ -3594,6 +3594,28 @@ } +#ifndef PRISM2_PLX +static void prism2_suspend(struct net_device *dev) +{ + struct hostap_interface *iface; + struct local_info *local; + union iwreq_data wrqu; + + iface = dev->priv; + local = iface->local; + + /* Send disconnect event, e.g., to trigger reassociation after resume + * if wpa_supplicant is used. */ + memset(&wrqu, 0, sizeof(wrqu)); + wrqu.ap_addr.sa_family = ARPHRD_ETHER; + wireless_send_event(local->dev, SIOCGIWAP, &wrqu, NULL); + + /* Disable hardware and firmware */ + prism2_hw_shutdown(dev, 0); +} +#endif /* PRISM2_PLX */ + + /* These might at some point be compiled separately and used as separate * kernel modules or linked into one */ #ifdef PRISM2_DOWNLOAD_SUPPORT Index: jm-wireless-2.6/drivers/net/wireless/hostap/hostap_pci.c =================================================================== --- jm-wireless-2.6.orig/drivers/net/wireless/hostap/hostap_pci.c 2005-03-12 16:10:50.000000000 -0800 +++ jm-wireless-2.6/drivers/net/wireless/hostap/hostap_pci.c 2005-03-12 16:10:59.000000000 -0800 @@ -393,7 +393,7 @@ netif_stop_queue(dev); netif_device_detach(dev); } - prism2_hw_shutdown(dev, 0); + prism2_suspend(dev); pci_save_state(pdev); pci_disable_device(pdev); pci_set_power_state(pdev, 3); -- Jouni Malinen PGP id EFC895FA From jm@jm.kir.nu Sat Mar 12 16:28:38 2005 Received: with ECARTIS (v1.0.0; list netdev); Sat, 12 Mar 2005 16:28:47 -0800 (PST) Received: from jm.kir.nu (dsl017-049-110.sfo4.dsl.speakeasy.net [69.17.49.110]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j2D0ScnR032520 for ; Sat, 12 Mar 2005 16:28:38 -0800 Received: from jm by jm.kir.nu with local (Exim 4.43) id 1DAH4s-0003Ux-B0; Sat, 12 Mar 2005 16:35:30 -0800 Date: Sat, 12 Mar 2005 16:35:30 -0800 From: Jouni Malinen To: Jeff Garzik Cc: netdev@oss.sgi.com Subject: [PATCH wireless-2.6 9/10] hostap: Filter disconnect events Message-ID: <20050313003530.GJ8253@jm.kir.nu> References: <20050313001706.GA8253@jm.kir.nu> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20050313001706.GA8253@jm.kir.nu> User-Agent: Mutt/1.5.6i X-Virus-Scanned: ClamAV version 0.83, clamav-milter version 0.83 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 65 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: jkmaline@cc.hut.fi Precedence: bulk X-list: netdev Content-Length: 1897 Lines: 45 Filter out sequential disconnect events to make race condition with received EAPOL frames less likely to happen (this improves authentication success rate with some APs that send EAPOL frames very quickly after the (re)association response). Signed-off-by: Jouni Malinen Index: jm-wireless-2.6/drivers/net/wireless/hostap/hostap_info.c =================================================================== --- jm-wireless-2.6.orig/drivers/net/wireless/hostap/hostap_info.c 2005-03-12 16:10:39.000000000 -0800 +++ jm-wireless-2.6/drivers/net/wireless/hostap/hostap_info.c 2005-03-12 16:11:01.000000000 -0800 @@ -428,7 +428,16 @@ memset(wrqu.ap_addr.sa_data, 0, ETH_ALEN); } wrqu.ap_addr.sa_family = ARPHRD_ETHER; - wireless_send_event(local->dev, SIOCGIWAP, &wrqu, NULL); + + /* + * Filter out sequential disconnect events in order not to cause a + * flood of SIOCGIWAP events that have a race condition with EAPOL + * frames and can confuse wpa_supplicant about the current association + * status. + */ + if (connected || local->prev_linkstatus_connected) + wireless_send_event(local->dev, SIOCGIWAP, &wrqu, NULL); + local->prev_linkstatus_connected = connected; } Index: jm-wireless-2.6/drivers/net/wireless/hostap/hostap_wlan.h =================================================================== --- jm-wireless-2.6.orig/drivers/net/wireless/hostap/hostap_wlan.h 2005-03-12 16:10:53.000000000 -0800 +++ jm-wireless-2.6/drivers/net/wireless/hostap/hostap_wlan.h 2005-03-12 16:11:01.000000000 -0800 @@ -833,6 +833,7 @@ #define PRISM2_INFO_PENDING_LINKSTATUS 0 #define PRISM2_INFO_PENDING_SCANRESULTS 1 int prev_link_status; /* previous received LinkStatus info */ + int prev_linkstatus_connected; u8 preferred_ap[6]; /* use this AP if possible */ #ifdef PRISM2_CALLBACK -- Jouni Malinen PGP id EFC895FA From jm@jm.kir.nu Sat Mar 12 16:34:40 2005 Received: with ECARTIS (v1.0.0; list netdev); Sat, 12 Mar 2005 16:34:46 -0800 (PST) Received: from jm.kir.nu (dsl017-049-110.sfo4.dsl.speakeasy.net [69.17.49.110]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j2D0YdpU000939 for ; Sat, 12 Mar 2005 16:34:39 -0800 Received: from jm by jm.kir.nu with local (Exim 4.43) id 1DAHAg-0003g7-ND; Sat, 12 Mar 2005 16:41:30 -0800 Date: Sat, 12 Mar 2005 16:41:30 -0800 From: Jouni Malinen To: Jeff Garzik Cc: netdev@oss.sgi.com Subject: [PATCH wireless-2.6 10/10] hostap: Update to use the new WE18 proposal Message-ID: <20050313004130.GK8253@jm.kir.nu> References: <20050313001706.GA8253@jm.kir.nu> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20050313001706.GA8253@jm.kir.nu> User-Agent: Mutt/1.5.6i X-Virus-Scanned: ClamAV version 0.83, clamav-milter version 0.83 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 66 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: jkmaline@cc.hut.fi Precedence: bulk X-list: netdev Content-Length: 16719 Lines: 613 Note: This depends on WE18 patch being applied first. Signed-off-by: Jouni Malinen Index: jm-wireless-2.6/drivers/net/wireless/hostap/hostap_ioctl.c =================================================================== --- jm-wireless-2.6.orig/drivers/net/wireless/hostap/hostap_ioctl.c 2005-03-12 16:10:42.000000000 -0800 +++ jm-wireless-2.6/drivers/net/wireless/hostap/hostap_ioctl.c 2005-03-12 16:39:05.000000000 -0800 @@ -1000,7 +1000,7 @@ } range->we_version_compiled = WIRELESS_EXT; - range->we_version_source = 16; + range->we_version_source = 18; range->retry_capa = IW_RETRY_LIMIT; range->retry_flags = IW_RETRY_LIMIT; @@ -1076,6 +1076,9 @@ IW_EVENT_CAPA_MASK(IWEVREGISTERED) | IW_EVENT_CAPA_MASK(IWEVEXPIRED)); + range->enc_capa = IW_ENC_CAPA_WPA | IW_ENC_CAPA_WPA2 | + IW_ENC_CAPA_CIPHER_TKIP | IW_ENC_CAPA_CIPHER_CCMP; + return 0; } @@ -1731,10 +1734,15 @@ struct hostap_interface *iface; local_info_t *local; int ret; + u8 *ssid = NULL, ssid_len = 0; + struct iw_scan_req *req = (struct iw_scan_req *) extra; iface = netdev_priv(dev); local = iface->local; + if (data->length < sizeof(struct iw_scan_req)) + req = NULL; + if (local->iw_mode == IW_MODE_MASTER) { /* In master mode, we just return the results of our local * tables, so we don't need to start anything... @@ -1746,8 +1754,19 @@ if (!local->dev_enabled) return -ENETDOWN; + if (req && data->flags & IW_SCAN_THIS_ESSID) { + ssid = req->essid; + ssid_len = req->essid_len; + + if (ssid_len && + ((local->iw_mode != IW_MODE_INFRA && + local->iw_mode != IW_MODE_ADHOC) || + (local->sta_fw_ver < PRISM2_FW_VER(1,3,1)))) + return -EOPNOTSUPP; + } + if (local->sta_fw_ver >= PRISM2_FW_VER(1,3,1)) - ret = prism2_request_hostscan(dev, NULL, 0); + ret = prism2_request_hostscan(dev, ssid, ssid_len); else ret = prism2_request_scan(dev); @@ -1926,32 +1945,20 @@ } } - if (bss && bss->wpa_ie_len > 0 && bss->wpa_ie_len <= MAX_WPA_IE_LEN ) { - u8 *p = buf; - p += sprintf(p, "wpa_ie="); - for (i = 0; i < bss->wpa_ie_len; i++) { - p += sprintf(p, "%02x", bss->wpa_ie[i]); - } - + if (bss && bss->wpa_ie_len > 0 && bss->wpa_ie_len <= MAX_WPA_IE_LEN) { memset(&iwe, 0, sizeof(iwe)); - iwe.cmd = IWEVCUSTOM; - iwe.u.data.length = strlen(buf); + iwe.cmd = IWEVGENIE; + iwe.u.data.length = bss->wpa_ie_len; current_ev = iwe_stream_add_point( - current_ev, end_buf, &iwe, buf); + current_ev, end_buf, &iwe, bss->wpa_ie); } - if (bss && bss->rsn_ie_len > 0 && bss->rsn_ie_len <= MAX_WPA_IE_LEN ) { - u8 *p = buf; - p += sprintf(p, "rsn_ie="); - for (i = 0; i < bss->rsn_ie_len; i++) { - p += sprintf(p, "%02x", bss->rsn_ie[i]); - } - + if (bss && bss->rsn_ie_len > 0 && bss->rsn_ie_len <= MAX_WPA_IE_LEN) { memset(&iwe, 0, sizeof(iwe)); - iwe.cmd = IWEVCUSTOM; - iwe.u.data.length = strlen(buf); + iwe.cmd = IWEVGENIE; + iwe.u.data.length = bss->rsn_ie_len; current_ev = iwe_stream_add_point( - current_ev, end_buf, &iwe, buf); + current_ev, end_buf, &iwe, bss->rsn_ie); } return current_ev; @@ -3098,6 +3105,387 @@ #endif /* PRISM2_DOWNLOAD_SUPPORT */ +static int prism2_set_genericelement(struct net_device *dev, u8 *elem, + size_t len) +{ + struct hostap_interface *iface = dev->priv; + local_info_t *local = iface->local; + u8 *buf; + + /* + * Add 16-bit length in the beginning of the buffer because Prism2 RID + * includes it. + */ + buf = kmalloc(len + 2, GFP_KERNEL); + if (buf == NULL) + return -ENOMEM; + + *((u16 *) buf) = cpu_to_le16(len); + memcpy(buf + 2, elem, len); + + kfree(local->generic_elem); + local->generic_elem = buf; + local->generic_elem_len = len + 2; + + return local->func->set_rid(local->dev, HFA384X_RID_GENERICELEMENT, + buf, len + 2); +} + + +static int prism2_ioctl_siwauth(struct net_device *dev, + struct iw_request_info *info, + struct iw_param *data, char *extra) +{ + struct hostap_interface *iface = dev->priv; + local_info_t *local = iface->local; + + switch (data->flags & IW_AUTH_INDEX) { + case IW_AUTH_WPA_VERSION: + case IW_AUTH_CIPHER_PAIRWISE: + case IW_AUTH_CIPHER_GROUP: + case IW_AUTH_KEY_MGMT: + /* + * Host AP driver does not use these parameters and allows + * wpa_supplicant to control them internally. + */ + break; + case IW_AUTH_TKIP_COUNTERMEASURES: + local->tkip_countermeasures = data->value; + break; + case IW_AUTH_DROP_UNENCRYPTED: + local->drop_unencrypted = data->value; + break; + case IW_AUTH_80211_AUTH_ALG: + local->auth_algs = data->value; + break; + case IW_AUTH_WPA_ENABLED: + if (data->value == 0) { + local->wpa = 0; + if (local->sta_fw_ver < PRISM2_FW_VER(1,7,0)) + break; + prism2_set_genericelement(dev, "", 0); + local->host_roaming = 0; + local->privacy_invoked = 0; + if (hostap_set_word(dev, HFA384X_RID_SSNHANDLINGMODE, + 0) || + hostap_set_roaming(local) || + hostap_set_encryption(local) || + local->func->reset_port(dev)) + return -EINVAL; + break; + } + if (local->sta_fw_ver < PRISM2_FW_VER(1,7,0)) + return -EOPNOTSUPP; + local->host_roaming = 2; + local->privacy_invoked = 1; + local->wpa = 1; + if (hostap_set_word(dev, HFA384X_RID_SSNHANDLINGMODE, 1) || + hostap_set_roaming(local) || + hostap_set_encryption(local) || + local->func->reset_port(dev)) + return -EINVAL; + break; + case IW_AUTH_RX_UNENCRYPTED_EAPOL: + local->ieee_802_1x = data->value; + break; + case IW_AUTH_PRIVACY_INVOKED: + local->privacy_invoked = data->value; + break; + default: + return -EOPNOTSUPP; + } + return 0; +} + + +static int prism2_ioctl_giwauth(struct net_device *dev, + struct iw_request_info *info, + struct iw_param *data, char *extra) +{ + struct hostap_interface *iface = dev->priv; + local_info_t *local = iface->local; + + switch (data->flags & IW_AUTH_INDEX) { + case IW_AUTH_WPA_VERSION: + case IW_AUTH_CIPHER_PAIRWISE: + case IW_AUTH_CIPHER_GROUP: + case IW_AUTH_KEY_MGMT: + /* + * Host AP driver does not use these parameters and allows + * wpa_supplicant to control them internally. + */ + return -EOPNOTSUPP; + case IW_AUTH_TKIP_COUNTERMEASURES: + data->value = local->tkip_countermeasures; + break; + case IW_AUTH_DROP_UNENCRYPTED: + data->value = local->drop_unencrypted; + break; + case IW_AUTH_80211_AUTH_ALG: + data->value = local->auth_algs; + break; + case IW_AUTH_WPA_ENABLED: + data->value = local->wpa; + break; + case IW_AUTH_RX_UNENCRYPTED_EAPOL: + data->value = local->ieee_802_1x; + break; + default: + return -EOPNOTSUPP; + } + return 0; +} + + +static int prism2_ioctl_siwencodeext(struct net_device *dev, + struct iw_request_info *info, + struct iw_point *erq, char *extra) +{ + struct hostap_interface *iface = dev->priv; + local_info_t *local = iface->local; + struct iw_encode_ext *ext = (struct iw_encode_ext *) extra; + int i, ret = 0; + struct hostap_crypto_ops *ops; + struct prism2_crypt_data **crypt; + void *sta_ptr; + u8 *addr; + const char *alg, *module; + + i = erq->flags & IW_ENCODE_INDEX; + if (i > WEP_KEYS) + return -EINVAL; + if (i < 1 || i > WEP_KEYS) + i = local->tx_keyidx; + else + i--; + if (i < 0 || i >= WEP_KEYS) + return -EINVAL; + + addr = ext->addr.sa_data; + if (addr[0] == 0xff && addr[1] == 0xff && addr[2] == 0xff && + addr[3] == 0xff && addr[4] == 0xff && addr[5] == 0xff) { + sta_ptr = NULL; + crypt = &local->crypt[i]; + } else { + if (i != 0) + return -EINVAL; + sta_ptr = ap_crypt_get_ptrs(local->ap, addr, 0, &crypt); + if (sta_ptr == NULL) { + if (local->iw_mode == IW_MODE_INFRA) { + /* + * TODO: add STA entry for the current AP so + * that unicast key can be used. For now, this + * is emulated by using default key idx 0. + */ + i = 0; + crypt = &local->crypt[i]; + } else + return -EINVAL; + } + } + + if ((erq->flags & IW_ENCODE_DISABLED) || + ext->alg == IW_ENCODE_ALG_NONE) { + if (*crypt) + prism2_crypt_delayed_deinit(local, crypt); + goto done; + } + + switch (ext->alg) { + case IW_ENCODE_ALG_WEP: + alg = "WEP"; + module = "hostap_crypt_wep"; + break; + case IW_ENCODE_ALG_TKIP: + alg = "TKIP"; + module = "hostap_crypt_tkip"; + break; + case IW_ENCODE_ALG_CCMP: + alg = "CCMP"; + module = "hostap_crypt_ccmp"; + break; + default: + printk(KERN_DEBUG "%s: unsupported algorithm %d\n", + local->dev->name, ext->alg); + ret = -EOPNOTSUPP; + goto done; + } + + ops = hostap_get_crypto_ops(alg); + if (ops == NULL) { + request_module(module); + ops = hostap_get_crypto_ops(alg); + } + if (ops == NULL) { + printk(KERN_DEBUG "%s: unknown crypto alg '%s'\n", + local->dev->name, alg); + ret = -EOPNOTSUPP; + goto done; + } + + if (sta_ptr || ext->alg != IW_ENCODE_ALG_WEP) { + /* + * Per station encryption and other than WEP algorithms + * require host-based encryption, so force them on + * automatically. + */ + local->host_decrypt = local->host_encrypt = 1; + } + + if (*crypt == NULL || (*crypt)->ops != ops) { + struct prism2_crypt_data *new_crypt; + + prism2_crypt_delayed_deinit(local, crypt); + + new_crypt = (struct prism2_crypt_data *) + kmalloc(sizeof(struct prism2_crypt_data), GFP_KERNEL); + if (new_crypt == NULL) { + ret = -ENOMEM; + goto done; + } + memset(new_crypt, 0, sizeof(struct prism2_crypt_data)); + new_crypt->ops = ops; + new_crypt->priv = new_crypt->ops->init(i); + if (new_crypt->priv == NULL) { + kfree(new_crypt); + ret = -EINVAL; + goto done; + } + + *crypt = new_crypt; + } + + /* + * TODO: if ext_flags does not have IW_ENCODE_EXT_RX_SEQ_VALID, the + * existing seq# should not be changed. + * TODO: if ext_flags has IW_ENCODE_EXT_TX_SEQ_VALID, next TX seq# + * should be changed to something else than zero. + */ + if ((!(ext->ext_flags & IW_ENCODE_EXT_SET_TX_KEY) || ext->key_len > 0) + && (*crypt)->ops->set_key && + (*crypt)->ops->set_key(ext->key, ext->key_len, ext->rx_seq, + (*crypt)->priv) < 0) { + printk(KERN_DEBUG "%s: key setting failed\n", + local->dev->name); + ret = -EINVAL; + goto done; + } + + if (ext->ext_flags & IW_ENCODE_EXT_SET_TX_KEY) { + if (!sta_ptr) + local->tx_keyidx = i; + else if (i) { + ret = -EINVAL; + goto done; + } + } + + + if (sta_ptr == NULL && ext->key_len > 0) { + int first = 1, j; + for (j = 0; j < WEP_KEYS; j++) { + if (j != i && local->crypt[j]) { + first = 0; + break; + } + } + if (first) + local->tx_keyidx = i; + } + + done: + if (sta_ptr) + hostap_handle_sta_release(sta_ptr); + + local->open_wep = erq->flags & IW_ENCODE_OPEN; + + /* + * Do not reset port0 if card is in Managed mode since resetting will + * generate new IEEE 802.11 authentication which may end up in looping + * with IEEE 802.1X. Prism2 documentation seem to require port reset + * after WEP configuration. However, keys are apparently changed at + * least in Managed mode. + */ + if (ret == 0 && + (hostap_set_encryption(local) || + (local->iw_mode != IW_MODE_INFRA && + local->func->reset_port(local->dev)))) + ret = -EINVAL; + + return ret; +} + + +static int prism2_ioctl_giwencodeext(struct net_device *dev, + struct iw_request_info *info, + struct iw_point *erq, char *extra) +{ + struct hostap_interface *iface = dev->priv; + local_info_t *local = iface->local; + struct prism2_crypt_data **crypt; + void *sta_ptr; + int max_key_len, i; + struct iw_encode_ext *ext = (struct iw_encode_ext *) extra; + u8 *addr; + + max_key_len = erq->length - sizeof(*ext); + if (max_key_len < 0) + return -EINVAL; + + i = erq->flags & IW_ENCODE_INDEX; + if (i < 1 || i > WEP_KEYS) + i = local->tx_keyidx; + else + i--; + + addr = ext->addr.sa_data; + if (addr[0] == 0xff && addr[1] == 0xff && addr[2] == 0xff && + addr[3] == 0xff && addr[4] == 0xff && addr[5] == 0xff) { + sta_ptr = NULL; + crypt = &local->crypt[i]; + } else { + i = 0; + sta_ptr = ap_crypt_get_ptrs(local->ap, addr, 0, &crypt); + if (sta_ptr == NULL) + return -EINVAL; + } + erq->flags = i + 1; + memset(ext, 0, sizeof(*ext)); + + if (*crypt == NULL || (*crypt)->ops == NULL) { + ext->alg = IW_ENCODE_ALG_NONE; + ext->key_len = 0; + erq->flags |= IW_ENCODE_DISABLED; + } else { + if (strcmp((*crypt)->ops->name, "WEP") == 0) + ext->alg = IW_ENCODE_ALG_WEP; + else if (strcmp((*crypt)->ops->name, "TKIP") == 0) + ext->alg = IW_ENCODE_ALG_TKIP; + else if (strcmp((*crypt)->ops->name, "CCMP") == 0) + ext->alg = IW_ENCODE_ALG_CCMP; + else + return -EINVAL; + + if ((*crypt)->ops->get_key) { + ext->key_len = + (*crypt)->ops->get_key(ext->key, + max_key_len, + ext->tx_seq, + (*crypt)->priv); + if (ext->key_len && + (ext->alg == IW_ENCODE_ALG_TKIP || + ext->alg == IW_ENCODE_ALG_CCMP)) + ext->ext_flags |= IW_ENCODE_EXT_TX_SEQ_VALID; + } + } + + if (sta_ptr) + hostap_handle_sta_release(sta_ptr); + + return 0; +} + + static int prism2_ioctl_set_encryption(local_info_t *local, struct prism2_hostapd_param *param, int param_len) @@ -3342,33 +3730,76 @@ } +static int prism2_ioctl_siwgenie(struct net_device *dev, + struct iw_request_info *info, + struct iw_point *data, char *extra) +{ + return prism2_set_genericelement(dev, extra, data->length); +} + + +static int prism2_ioctl_giwgenie(struct net_device *dev, + struct iw_request_info *info, + struct iw_point *data, char *extra) +{ + struct hostap_interface *iface = dev->priv; + local_info_t *local = iface->local; + int len = local->generic_elem_len - 2; + + if (len <= 0 || local->generic_elem == NULL) { + data->length = 0; + return 0; + } + + if (data->length < len) + return -E2BIG; + + data->length = len; + memcpy(extra, local->generic_elem + 2, len); + + return 0; +} + + static int prism2_ioctl_set_generic_element(local_info_t *local, struct prism2_hostapd_param *param, int param_len) { int max_len, len; - u8 *buf; len = param->u.generic_elem.len; max_len = param_len - PRISM2_HOSTAPD_GENERIC_ELEMENT_HDR_LEN; if (max_len < 0 || max_len < len) return -EINVAL; - /* Add 16-bit length in the beginning of the buffer because Prism2 RID - * includes it. */ - buf = kmalloc(len + 2, GFP_KERNEL); - if (buf == NULL) - return -ENOMEM; + return prism2_set_genericelement(local->dev, + param->u.generic_elem.data, len); +} - *((u16 *) buf) = cpu_to_le16(len); - memcpy(buf + 2, param->u.generic_elem.data, len); - kfree(local->generic_elem); - local->generic_elem = buf; - local->generic_elem_len = len + 2; +static int prism2_ioctl_siwmlme(struct net_device *dev, + struct iw_request_info *info, + struct iw_point *data, char *extra) +{ + struct hostap_interface *iface = dev->priv; + local_info_t *local = iface->local; + struct iw_mlme *mlme = (struct iw_mlme *) extra; + u16 reason; - return local->func->set_rid(local->dev, HFA384X_RID_GENERICELEMENT, - buf, len + 2); + reason = cpu_to_le16(mlme->reason_code); + + switch (mlme->cmd) { + case IW_MLME_DEAUTH: + return prism2_sta_send_mgmt(local, mlme->addr.sa_data, + WLAN_FC_STYPE_DEAUTH, + (u8 *) &reason, 2); + case IW_MLME_DISASSOC: + return prism2_sta_send_mgmt(local, mlme->addr.sa_data, + WLAN_FC_STYPE_DISASSOC, + (u8 *) &reason, 2); + default: + return -EOPNOTSUPP; + } } @@ -3532,7 +3963,7 @@ iw_handler_get_thrspy, /* SIOCGIWTHRSPY */ (iw_handler) prism2_ioctl_siwap, /* SIOCSIWAP */ (iw_handler) prism2_ioctl_giwap, /* SIOCGIWAP */ - (iw_handler) NULL, /* -- hole -- */ + (iw_handler) prism2_ioctl_siwmlme, /* SIOCSIWMLME */ (iw_handler) prism2_ioctl_giwaplist, /* SIOCGIWAPLIST */ (iw_handler) prism2_ioctl_siwscan, /* SIOCSIWSCAN */ (iw_handler) prism2_ioctl_giwscan, /* SIOCGIWSCAN */ @@ -3556,6 +3987,16 @@ (iw_handler) prism2_ioctl_giwencode, /* SIOCGIWENCODE */ (iw_handler) prism2_ioctl_siwpower, /* SIOCSIWPOWER */ (iw_handler) prism2_ioctl_giwpower, /* SIOCGIWPOWER */ + (iw_handler) NULL, /* -- hole -- */ + (iw_handler) NULL, /* -- hole -- */ + (iw_handler) prism2_ioctl_siwgenie, /* SIOCSIWGENIE */ + (iw_handler) prism2_ioctl_giwgenie, /* SIOCGIWGENIE */ + (iw_handler) prism2_ioctl_siwauth, /* SIOCSIWAUTH */ + (iw_handler) prism2_ioctl_giwauth, /* SIOCGIWAUTH */ + (iw_handler) prism2_ioctl_siwencodeext, /* SIOCSIWENCODEEXT */ + (iw_handler) prism2_ioctl_giwencodeext, /* SIOCGIWENCODEEXT */ + (iw_handler) NULL, /* SIOCSIWPMKSA */ + (iw_handler) NULL, /* -- hole -- */ }; static const iw_handler prism2_private_handler[] = -- Jouni Malinen PGP id EFC895FA From boian@bonev.com Sat Mar 12 18:14:28 2005 Received: with ECARTIS (v1.0.0; list netdev); Sat, 12 Mar 2005 18:14:35 -0800 (PST) Received: from mx.cisbg.com (ns.cisbg.com [195.69.109.188]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j2D2ER0H005070 for ; Sat, 12 Mar 2005 18:14:28 -0800 Received: from orange.bonev.com (orange.bonev.com [195.69.108.254]) by mx.cisbg.com (8.13.1/8.13.1) with SMTP id j2D2ERZ6016721 for ; Sun, 13 Mar 2005 04:14:27 +0200 Received: (qmail 26192 invoked by uid 99); 13 Mar 2005 02:14:27 -0000 Message-ID: <20050313021427.26190.qmail@orange.bonev.com> Mime-Version: 1.0 Received: from firewall.cisbg.com (195.69.108.252) by mail.bonev.com with HTTP; Sun, 13 Mar 2005 04:14:27 +0200 From: Boian Bonev Cc: netdev@oss.sgi.com To: Lennert Buytenhek , Pekka Savola , jamal , shemminger@osdl.org Subject: tunneling in linux (was: Re: [PATCH][RFC] etherip: Ethernet-in-IPv4 tunneling), GRE Ethernet tunneling Date: Sun, 13 Mar 2005 04:14:27 +0200 Content-Type: multipart/mixed; boundary="=_1_1110680067_26188" Content-Transfer-Encoding: 8bit X-BIS.BG-Antispam-Check: Yes X-Scanned-By: MIMEDefang 2.48 on 195.69.109.187 X-Virus-Scanned: ClamAV version 0.83, clamav-milter version 0.83 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 67 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: boian@bonev.com Precedence: bulk X-list: netdev Content-Length: 1111 Lines: 27 This is a MIME-formatted message. If you see this text it means that your E-mail software does not support MIME-formatted messages. --=_1_1110680067_26188 Content-Type: text/plain; charset=windows-1251 Content-Transfer-Encoding: quoted-printable it really looks stoopid but i found your discussion on linux tunneling wh= ile looking for replies to my post on GRE Ethernet tunneling - it was an = ask for help :) and all we have walked the same path alone seems you have concept proof on etherip encap and i did a gre like one here is my dirty code: http://purple.bonev.com/ (it is made on 2.4.28, bu= t i still use 2.4/e1000/bcm5700/no napi on my high load routers) in rethinking tunnel creation and management - if i summarize all etherne= t like devices shall be ARPHDR_ETHER, best user-kernel proto will be netl= ink and also why not support ethtool for virtual ethernets? it will make = it easier for userland to know what the heck kind of device it is at leas= t about interoperability - look here: http://www.mikrotik.com/Documentation= /manual_2.7/Interface/EoIP.html b. --=_1_1110680067_26188-- From dtor_core@ameritech.net Sat Mar 12 22:54:05 2005 Received: with ECARTIS (v1.0.0; list netdev); Sat, 12 Mar 2005 22:54:11 -0800 (PST) Received: from smtp804.mail.sc5.yahoo.com (smtp804.mail.sc5.yahoo.com [66.163.168.183]) by oss.sgi.com (8.13.0/8.13.0) with SMTP id j2D6s5r4017605 for ; Sat, 12 Mar 2005 22:54:05 -0800 Received: from unknown (HELO core.corenet.prv) (dtor?core@ameritech.net@68.253.44.57 with plain) by smtp804.mail.sc5.yahoo.com with SMTP; 13 Mar 2005 06:54:05 -0000 From: Dmitry Torokhov To: Patrick McHardy Subject: Re: Last night Linus bk - netfilter busted? Date: Sun, 13 Mar 2005 01:54:02 -0500 User-Agent: KMail/1.7.2 Cc: Herbert Xu , davem@davemloft.net, netdev@oss.sgi.com, linux-kernel@vger.kernel.org, netfilter-devel@lists.netfilter.org References: <423221FF.8020103@trash.net> In-Reply-To: <423221FF.8020103@trash.net> MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200503130154.03777.dtor_core@ameritech.net> X-Virus-Scanned: ClamAV version 0.83, clamav-milter version 0.83 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 68 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: dtor_core@ameritech.net Precedence: bulk X-list: netdev Content-Length: 627 Lines: 23 On Friday 11 March 2005 17:55, Patrick McHardy wrote: > Herbert Xu wrote: > > Patrick McHardy wrote: > > > >>You're right, good catch. IPT_RETURN is interpreted internally by > >>ip_tables, but since the value changed it isn't recognized by ip_tables > >>anymore and returned to nf_iterate() as NF_REPEAT. This patch restores > >>the old value. > > > > > > Please fix netfilter_arp while you're at it since it does exactly > > the same thing. > > New patch attached, thanks. > If this is of any interest, yesterday's pull from Linux plus this patch seem to be working fine here. Thank you. -- Dmitry From hasso@estpak.ee Sun Mar 13 09:49:39 2005 Received: with ECARTIS (v1.0.0; list netdev); Sun, 13 Mar 2005 09:49:45 -0800 (PST) Received: from arena.estpak.ee (test.estpak.ee [194.126.115.47]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j2DHncQm021565 for ; Sun, 13 Mar 2005 09:49:39 -0800 Received: from localhost ([127.0.0.1] helo=arena) by arena.estpak.ee with esmtp (Exim 4.44) id 1DAXDG-0001eT-DR; Sun, 13 Mar 2005 19:49:14 +0200 From: Hasso Tepper To: Tommy Christensen Subject: Re: [patch 4/10] s390: network driver. Date: Sun, 13 Mar 2005 19:49:13 +0200 User-Agent: KMail/1.7.2 Cc: hadi@cyberus.ca, Jeff Garzik , Thomas Spatzier , "David S. Miller" , Herbert Xu , netdev@oss.sgi.com, Paul Jakma References: <1107142012.8021.109.camel@jzny.localdomain> <1107173804.5812.133.camel@tsc-6.cph.tpack.net> In-Reply-To: <1107173804.5812.133.camel@tsc-6.cph.tpack.net> Organization: Elion Enterprises Ltd. MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200503131949.13962.hasso@estpak.ee> X-Virus-Scanned: ClamAV version 0.83, clamav-milter version 0.83 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 69 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: hasso@estpak.ee Precedence: bulk X-list: netdev Content-Length: 856 Lines: 27 Tommy Christensen wrote: > On Mon, 2005-01-31 at 04:26, jamal wrote: > > It does look pretty sane.. Tested? > > Nope, I don't have access to any relevant HW. Hopefully someone > else can give it some beating. Please. Sorry for long delay. I lost track in this discussion, was busy with other things, but found finally time to test this. > Hopefully someone can verify that with e.g. an e1000, and then check > whether the patch I send makes any difference. Yes, confirmed that patch makes difference and solves Quagga ospfd problem (from what it all started :). Thank you very much! PS. Patch is tested with 2.4.29 as well, but it requires link watch stuff to work. Complete (link-watch + vlan carrier detection + this fix) is here - http://hasso.linux.ee/quagga/2.4.29-link-watch.patch -- Hasso Tepper Elion Enterprises Ltd. WAN administrator From ak@muc.de Sun Mar 13 16:05:46 2005 Received: with ECARTIS (v1.0.0; list netdev); Sun, 13 Mar 2005 16:05:53 -0800 (PST) Received: from colin2.muc.de (qmailr@colin2.muc.de [193.149.48.15]) by oss.sgi.com (8.13.0/8.13.0) with SMTP id j2E05j4o001262 for ; Sun, 13 Mar 2005 16:05:45 -0800 Received: (qmail 87708 invoked by uid 3709); 14 Mar 2005 00:05:43 -0000 Date: 14 Mar 2005 01:05:43 +0100 Date: Mon, 14 Mar 2005 01:05:43 +0100 From: Andi Kleen To: jgarzik@pobox.com, netdev@oss.sgi.com, bcrl@kvack.org Subject: [PATCH] Fix ns82830 driver for x86-64 Message-ID: <20050314000543.GA85950@muc.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.4.1i X-Virus-Scanned: ClamAV version 0.83, clamav-milter version 0.83 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 70 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: ak@muc.de Precedence: bulk X-list: netdev Content-Length: 2686 Lines: 90 Fix up some dodgy ifdefs in the ns82820 driver and support DAC mode on x86-64. Do proper sizeof(dma_addr_t) checks instead. Only compile tested due to lack of hardware. Originally pointed out by Al Viro Signed-off-by: Andi Kleen Index: linux/drivers/net/ns83820.c =================================================================== --- linux.orig/drivers/net/ns83820.c 2005-03-12 15:06:34.000000000 +0100 +++ linux/drivers/net/ns83820.c 2005-03-14 00:50:07.547865056 +0100 @@ -1,4 +1,4 @@ -#define _VERSION "0.20" +#define VERSION "0.20" /* ns83820.c by Benjamin LaHaise with contributions. * * Questions/comments/discussion to linux-ns83820@kvack.org. @@ -129,18 +129,6 @@ #undef Dprintk #define Dprintk dprintk -#if defined(CONFIG_HIGHMEM64G) || defined(__ia64__) -#define USE_64BIT_ADDR "+" -#endif - -#if defined(USE_64BIT_ADDR) -#define VERSION _VERSION USE_64BIT_ADDR -#define TRY_DAC 1 -#else -#define VERSION _VERSION -#define TRY_DAC 0 -#endif - /* tunables */ #define RX_BUF_SIZE 1500 /* 8192 */ #if defined(CONFIG_VLAN_8021Q) || defined(CONFIG_VLAN_8021Q_MODULE) @@ -386,22 +374,16 @@ #define LINK_DOWN 0x02 #define LINK_UP 0x04 -#ifdef USE_64BIT_ADDR -#define HW_ADDR_LEN 8 +#define HW_ADDR_LEN sizeof(dma_addr_t) #define desc_addr_set(desc, addr) \ do { \ - u64 __addr = (addr); \ - (desc)[0] = cpu_to_le32(__addr); \ - (desc)[1] = cpu_to_le32(__addr >> 32); \ + ((desc)[0] = cpu_to_le32(addr)); \ + if (HW_ADDR_LEN == 8) \ + (desc)[1] = cpu_to_le32(((u64)addr) >> 32); \ } while(0) #define desc_addr_get(desc) \ - (((u64)le32_to_cpu((desc)[1]) << 32) \ - | le32_to_cpu((desc)[0])) -#else -#define HW_ADDR_LEN 4 -#define desc_addr_set(desc, addr) ((desc)[0] = cpu_to_le32(addr)) -#define desc_addr_get(desc) (le32_to_cpu((desc)[0])) -#endif + (le32_to_cpu((desc)[0]) | \ + (HW_ADDR_LEN == 8 ? ((dma_addr_t)le32_to_cpu((desc)[1]))<<32 : 0)) #define DESC_LINK 0 #define DESC_BUFPTR (DESC_LINK + HW_ADDR_LEN/4) @@ -1841,7 +1823,8 @@ int using_dac = 0; /* See if we can set the dma mask early on; failure is fatal. */ - if (TRY_DAC && !pci_set_dma_mask(pci_dev, 0xffffffffffffffffULL)) { + if (sizeof(dma_addr_t) == 8 && + !pci_set_dma_mask(pci_dev, 0xffffffffffffffffULL)) { using_dac = 1; } else if (!pci_set_dma_mask(pci_dev, 0xffffffff)) { using_dac = 0; @@ -1972,9 +1955,8 @@ /* When compiled with 64 bit addressing, we must always enable * the 64 bit descriptor format. */ -#ifdef USE_64BIT_ADDR - dev->CFG_cache |= CFG_M64ADDR; -#endif + if (sizeof(dma_addr_t) == 8) + dev->CFG_cache |= CFG_M64ADDR; if (using_dac) dev->CFG_cache |= CFG_T64ADDR; From herbert@gondor.apana.org.au Mon Mar 14 01:45:07 2005 Received: with ECARTIS (v1.0.0; list netdev); Mon, 14 Mar 2005 01:45:15 -0800 (PST) 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 j2E9j5Wk029475 for ; Mon, 14 Mar 2005 01:45:06 -0800 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 1DAm81-00051s-00; Mon, 14 Mar 2005 20:44:49 +1100 Received: from herbert by gondolin.me.apana.org.au with local (Exim 3.36 #1 (Debian)) id 1DAm7Y-0005nL-00; Mon, 14 Mar 2005 20:44:20 +1100 Date: Mon, 14 Mar 2005 20:44:20 +1100 To: "David S. Miller" , netdev@oss.sgi.com Subject: [NETLINK] Fix multicast bind/autobind race Message-ID: <20050314094420.GA15349@gondor.apana.org.au> Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="oyUTqETQ0mS9luUI" Content-Disposition: inline User-Agent: Mutt/1.5.6+20040907i From: Herbert Xu X-Virus-Scanned: ClamAV version 0.83, clamav-milter version 0.83 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 71 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: herbert@gondor.apana.org.au Precedence: bulk X-list: netdev Content-Length: 1397 Lines: 46 --oyUTqETQ0mS9luUI Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Hi Dave: netlink_autobind has always set nlk_sk(sk)->groups to zero. This is unnecessary because sk_alloc already zeroes the entire structure. Since a socket can only be bound once netlink_autobind doesn't need to zero groups at all. This had been safe until I added mc_list. Now it is possible for netlink_bind to race against netlink_autobind running on the same socket on another CPU. The result would be a socket that's on mc_list with groups set to zero. This socket will be left on the list even after it is destroyed. The fix is to remove the zeroing in netlink_autobind. 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 --oyUTqETQ0mS9luUI Content-Type: text/plain; charset=us-ascii Content-Disposition: attachment; filename=p ===== net/netlink/af_netlink.c 1.70 vs edited ===== --- 1.70/net/netlink/af_netlink.c 2005-02-09 15:09:15 +11:00 +++ edited/net/netlink/af_netlink.c 2005-03-14 20:28:59 +11:00 @@ -430,7 +430,6 @@ err = netlink_insert(sk, pid); if (err == -EADDRINUSE) goto retry; - nlk_sk(sk)->groups = 0; return 0; } --oyUTqETQ0mS9luUI-- From ralf@linux-mips.org Mon Mar 14 02:28:57 2005 Received: with ECARTIS (v1.0.0; list netdev); Mon, 14 Mar 2005 02:29:02 -0800 (PST) Received: from mail.linux-mips.net (extgw-uk.mips.com [62.254.210.129]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j2EASuDR031808 for ; Mon, 14 Mar 2005 02:28:57 -0800 Received: from dea.linux-mips.net (localhost.localdomain [127.0.0.1]) by mail.linux-mips.net (8.13.1/8.13.1) with ESMTP id j2EARePS009628; Mon, 14 Mar 2005 10:27:40 GMT Received: (from ralf@localhost) by dea.linux-mips.net (8.13.1/8.13.1/Submit) id j2E8binm012772; Mon, 14 Mar 2005 08:37:44 GMT Date: Mon, 14 Mar 2005 08:37:44 +0000 From: Ralf Baechle DL5RB To: netdev@oss.sgi.com, linux-hams@vger.kernel.org Cc: "David S. Miller" Subject: [PATCH] Fix ax25_get_socket locking Message-ID: <20050314083744.GA12765@linux-mips.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.4.1i X-Virus-Scanned: ClamAV version 0.83, clamav-milter version 0.83 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 73 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: ralf@linux-mips.org Precedence: bulk X-list: netdev Content-Length: 1454 Lines: 41 In an attempt to return a locked socket ax25_get_socket() was calling lock_sock() with a spinlock held, bad idea. Making matters worse it's only user is running in bottom half context resulting in a potencial attempt to sleep in bottom half context, so fix the locking there as well. Index: bk-afu/net/ax25/ax25_in.c =================================================================== --- bk-afu.orig/net/ax25/ax25_in.c 2005-03-14 00:20:42.153164936 +0000 +++ bk-afu/net/ax25/ax25_in.c 2005-03-14 00:21:07.469316296 +0000 @@ -275,6 +275,7 @@ /* Now find a suitable dgram socket */ sk = ax25_get_socket(&dest, &src, SOCK_DGRAM); if (sk != NULL) { + bh_lock_sock(sk); if (atomic_read(&sk->sk_rmem_alloc) >= sk->sk_rcvbuf) { kfree_skb(skb); @@ -286,7 +287,8 @@ if (sock_queue_rcv_skb(sk, skb) != 0) kfree_skb(skb); } - release_sock(sk); + bh_unlock_sock(sk); + sock_put(sk); } else { kfree_skb(skb); } Index: bk-afu/net/ax25/af_ax25.c =================================================================== --- bk-afu.orig/net/ax25/af_ax25.c 2005-03-14 00:21:03.757880520 +0000 +++ bk-afu/net/ax25/af_ax25.c 2005-03-14 00:21:07.471315992 +0000 @@ -180,8 +180,7 @@ !ax25cmp(&s->dest_addr, dest_addr) && s->sk->sk_type == type) { sk = s->sk; - /* XXX Sleeps with spinlock held, use refcounts instead. XXX */ - lock_sock(sk); + sock_hold(sk); break; } } From herbert@gondor.apana.org.au Mon Mar 14 02:28:41 2005 Received: with ECARTIS (v1.0.0; list netdev); Mon, 14 Mar 2005 02:28:50 -0800 (PST) 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 j2EASd37031784 for ; Mon, 14 Mar 2005 02:28:40 -0800 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 1DAmmr-0005U2-00; Mon, 14 Mar 2005 21:27:01 +1100 Received: from herbert by gondolin.me.apana.org.au with local (Exim 3.36 #1 (Debian)) id 1DAmm6-0003SS-00; Mon, 14 Mar 2005 21:26:14 +1100 Date: Mon, 14 Mar 2005 21:26:14 +1100 To: "David S. Miller" Cc: Alexey Kuznetsov , YOSHIFUJI Hideaki , Patrick McHardy , netdev@oss.sgi.com Subject: [12/*] [IPSEC] Handle local_df in IPv4 Message-ID: <20050314102614.GA9610@gondor.apana.org.au> References: <20050214221006.GA18415@gondor.apana.org.au> <20050214221200.GA18465@gondor.apana.org.au> <20050214221433.GB18465@gondor.apana.org.au> <20050214221607.GC18465@gondor.apana.org.au> <20050306213214.7d8a143d.davem@davemloft.net> <20050307103536.GB7137@gondor.apana.org.au> <20050308102741.GA23468@gondor.apana.org.au> Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="5vNYLRcllDrimb99" Content-Disposition: inline In-Reply-To: <20050308102741.GA23468@gondor.apana.org.au> User-Agent: Mutt/1.5.6+20040907i From: Herbert Xu X-Virus-Scanned: ClamAV version 0.83, clamav-milter version 0.83 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 72 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: herbert@gondor.apana.org.au Precedence: bulk X-list: netdev Content-Length: 1297 Lines: 44 --5vNYLRcllDrimb99 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Hi Dave: When cleaning up the remaining users of dst_pmtu I noticed that local_df wasn't being treated correctly in IPsec. In fact, if you socket's dst went over IPsec, local_df is essentailly ignored. This patch fixes that. Signed-off-by: Herbert Xu I was going to do the same thing to IPv6. Unfortunately it seems that we don't have any local_df support over there. That is, we always fragment outbound UDP/raw packets. Did I miss something? 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 --5vNYLRcllDrimb99 Content-Type: text/plain; charset=us-ascii Content-Disposition: attachment; filename=xfrm-12 ===== net/ipv4/xfrm4_output.c 1.7 vs edited ===== --- 1.7/net/ipv4/xfrm4_output.c 2005-03-07 16:33:59 +11:00 +++ edited/net/ipv4/xfrm4_output.c 2005-03-14 13:55:35 +11:00 @@ -78,7 +78,7 @@ IPCB(skb)->flags |= IPSKB_XFRM_TUNNEL_SIZE; - if (!(iph->frag_off & htons(IP_DF))) + if (!(iph->frag_off & htons(IP_DF)) || skb->local_df) goto out; dst = skb->dst; --5vNYLRcllDrimb99-- From weber@faps.uni-erlangen.de Mon Mar 14 02:38:55 2005 Received: with ECARTIS (v1.0.0; list netdev); Mon, 14 Mar 2005 02:38:59 -0800 (PST) Received: from moritz.faps.uni-erlangen.de (moritz.faps.uni-erlangen.de [131.188.113.15]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j2EAcrYa000397 for ; Mon, 14 Mar 2005 02:38:54 -0800 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="Windows-1252" Subject: Resending ethernet packets to direct neighbours X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 Date: Mon, 14 Mar 2005 11:38:48 +0100 Message-ID: <09766A6E64A068419B362367800D50C0B58A65@moritz.faps.uni-erlangen.de> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Resending ethernet packets to direct neighbours thread-index: AcUoggE72zZ+1SELSK2JGDFMGX4dlw== From: "Weber Matthias" To: , X-Virus-Scanned: ClamAV version 0.83, clamav-milter version 0.83 on oss.sgi.com X-Virus-Status: Clean Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by oss.sgi.com id j2EAcrYa000397 X-archive-position: 74 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: weber@faps.uni-erlangen.de Precedence: bulk X-list: netdev Content-Length: 601 Lines: 15 Hi, i have a pc with five ethernet devices onto and want to resend ethernet packets coming in from one device to four direct neighbours (distance 1). Therefore i have installed a packet handler receiving skbs. Now i have the following questions: 1) is it enough to change the skb->dev to the output device, rebuild the ethernet header and call dev_queue_xmit()? 2) how to i get the destination ethernet address of the physically direct neighbour within the packet handler? I believe, that i have to use the neighour caches but have not idea how... Any help would be appreciated! Bye Matthias From herbert@gondor.apana.org.au Mon Mar 14 02:54:47 2005 Received: with ECARTIS (v1.0.0; list netdev); Mon, 14 Mar 2005 02:54:55 -0800 (PST) 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 j2EAsjes003224 for ; Mon, 14 Mar 2005 02:54:46 -0800 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 1DAnCk-0005gY-00; Mon, 14 Mar 2005 21:53:46 +1100 Received: from herbert by gondolin.me.apana.org.au with local (Exim 3.36 #1 (Debian)) id 1DAnCD-00067d-00; Mon, 14 Mar 2005 21:53:13 +1100 Date: Mon, 14 Mar 2005 21:53:13 +1100 To: "David S. Miller" Cc: Alexey Kuznetsov , YOSHIFUJI Hideaki , Patrick McHardy , netdev@oss.sgi.com Subject: [13/*] [IPV4] Fix room calculation in icmp_send Message-ID: <20050314105313.GA21001@gondor.apana.org.au> References: <20050214221006.GA18415@gondor.apana.org.au> <20050214221200.GA18465@gondor.apana.org.au> <20050214221433.GB18465@gondor.apana.org.au> <20050214221607.GC18465@gondor.apana.org.au> <20050306213214.7d8a143d.davem@davemloft.net> <20050307103536.GB7137@gondor.apana.org.au> <20050308102741.GA23468@gondor.apana.org.au> <20050314102614.GA9610@gondor.apana.org.au> Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="+QahgC5+KEYLbs62" Content-Disposition: inline In-Reply-To: <20050314102614.GA9610@gondor.apana.org.au> User-Agent: Mutt/1.5.6+20040907i From: Herbert Xu X-Virus-Scanned: ClamAV version 0.83, clamav-milter version 0.83 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 75 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: herbert@gondor.apana.org.au Precedence: bulk X-list: netdev Content-Length: 1330 Lines: 45 --+QahgC5+KEYLbs62 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Hi Dave: I'm now cleaning up all users of dst_pmtu with the aim of replacing dst_pmtu with dst_mtu. I'm going to start with the ones that actually fix bugs. This patch fixes the length calculation in icmp_send. As it is we're overestimating the space available by including the space that would be used up by IPsec encapsulation. IPv6 doesn't have this problem since its calculation is based on 1280 instead of the PMTU. 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 --+QahgC5+KEYLbs62 Content-Type: text/plain; charset=us-ascii Content-Disposition: attachment; filename=xfrm-13 ===== net/ipv4/icmp.c 1.49 vs edited ===== --- 1.49/net/ipv4/icmp.c 2004-12-28 16:30:43 +11:00 +++ edited/net/ipv4/icmp.c 2005-03-14 21:34:20 +11:00 @@ -560,7 +560,7 @@ /* RFC says return as much as we can without exceeding 576 bytes. */ - room = dst_pmtu(&rt->u.dst); + room = dst_mtu(&rt->u.dst); if (room > 576) room = 576; room -= sizeof(struct iphdr) + icmp_param.replyopts.optlen; --+QahgC5+KEYLbs62-- From penberg@gmail.com Mon Mar 14 03:10:58 2005 Received: with ECARTIS (v1.0.0; list netdev); Mon, 14 Mar 2005 03:11:03 -0800 (PST) Received: from wproxy.gmail.com (wproxy.gmail.com [64.233.184.198]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j2EBAv9N004202 for ; Mon, 14 Mar 2005 03:10:57 -0800 Received: by wproxy.gmail.com with SMTP id 68so1827312wra for ; Mon, 14 Mar 2005 03:10:52 -0800 (PST) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:reply-to:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:references; b=p2rGNCBvptR/bx/JYr9EM3dWJQVI36W3jxOw8txSrdOJ3hL9DwQnzU7BtTiwwQdJLcO2chUCQWLTWOasP01UDSBQkctksGSIB/5OnIlXcugE9sfL+0GFIeOreW/vDGgjjXey6JrMNjVt4MAjgDfQi1HKqXapHNVdk7A0iRX2Zrc= Received: by 10.54.29.35 with SMTP id c35mr3493960wrc; Mon, 14 Mar 2005 03:10:46 -0800 (PST) Received: by 10.54.8.11 with HTTP; Mon, 14 Mar 2005 03:10:46 -0800 (PST) Message-ID: <84144f0205031403105351abf5@mail.gmail.com> Date: Mon, 14 Mar 2005 13:10:46 +0200 From: Pekka Enberg Reply-To: Pekka Enberg To: Andrew Morton Subject: Re: A new 10GB Ethernet Driver by Chelsio Communications Cc: Christoph Lameter , linux-kernel@vger.kernel.org, mark@chelsio.com, netdev@oss.sgi.com, Jeff Garzik , penberg@cs.helsinki.fi In-Reply-To: <20050311112132.6a3a3b49.akpm@osdl.org> Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit References: <20050311112132.6a3a3b49.akpm@osdl.org> X-Virus-Scanned: ClamAV version 0.83, clamav-milter version 0.83 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 76 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: penberg@gmail.com Precedence: bulk X-list: netdev Content-Length: 1665 Lines: 55 Some of my usual coding style comments... On Fri, 11 Mar 2005 11:21:32 -0800, Andrew Morton wrote: > diff -puN /dev/null drivers/net/chelsio/osdep.h > --- /dev/null 2003-09-15 06:40:47.000000000 -0700 > +++ 25-akpm/drivers/net/chelsio/osdep.h 2005-03-11 11:13:06.000000000 -0800 > +static inline void *t1_malloc(size_t len) > +{ > + void *m = kmalloc(len, GFP_KERNEL); > + if (m) > + memset(m, 0, len); > + return m; > +} > + > +static inline void t1_free(void *v, size_t len) > +{ > + kfree(v); > +} Please do not introduce subsystem specific wrappers to kmalloc and kfree. > +/* > + * Allocates basic RX resources, consisting of memory mapped freelist Qs and a > + * response Q. > + */ > +static int alloc_rx_resources(struct sge *sge, struct sge_params *p) > +{ > + struct pci_dev *pdev = sge->adapter->pdev; > + unsigned int size, i; > + > + for (i = 0; i < SGE_FREELQ_N; i++) { > + struct freelQ *Q = &sge->freelQ[i]; > + > + Q->genbit = 1; > + Q->entries_n = p->freelQ_size[i]; > + Q->dma_offset = SGE_RX_OFFSET - sge->rx_pkt_pad; > + size = sizeof(struct freelQ_e) * Q->entries_n; > + Q->entries = (struct freelQ_e *) > + pci_alloc_consistent(pdev, size, &Q->dma_addr); > + if (!Q->entries) > + goto err_no_mem; > + memset(Q->entries, 0, size); > + size = sizeof(struct freelQ_ce) * Q->entries_n; > + Q->centries = (struct freelQ_ce *) kmalloc(size, GFP_KERNEL); > + if (!Q->centries) > + goto err_no_mem; > + memset(Q->centries, 0, size); Please drop the redundant casts and use kcalloc() here and in various other places as well. Also, the patch has some whitespace damage (spaces instead of tabs). Pekka From herbert@gondor.apana.org.au Mon Mar 14 03:11:13 2005 Received: with ECARTIS (v1.0.0; list netdev); Mon, 14 Mar 2005 03:11:21 -0800 (PST) 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 j2EBBBDK004272 for ; Mon, 14 Mar 2005 03:11:12 -0800 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 1DAnSw-0005si-00; Mon, 14 Mar 2005 22:10:30 +1100 Received: from herbert by gondolin.me.apana.org.au with local (Exim 3.36 #1 (Debian)) id 1DAnSU-00008f-00; Mon, 14 Mar 2005 22:10:02 +1100 Date: Mon, 14 Mar 2005 22:10:02 +1100 To: "David S. Miller" Cc: Alexey Kuznetsov , YOSHIFUJI Hideaki , Patrick McHardy , netdev@oss.sgi.com Subject: [14/*] [IPV6] Reload skb->dst after xfrm6_route_forward Message-ID: <20050314111002.GA29156@gondor.apana.org.au> References: <20050214221006.GA18415@gondor.apana.org.au> <20050214221200.GA18465@gondor.apana.org.au> <20050214221433.GB18465@gondor.apana.org.au> <20050214221607.GC18465@gondor.apana.org.au> <20050306213214.7d8a143d.davem@davemloft.net> <20050307103536.GB7137@gondor.apana.org.au> <20050308102741.GA23468@gondor.apana.org.au> <20050314102614.GA9610@gondor.apana.org.au> <20050314105313.GA21001@gondor.apana.org.au> Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="fdj2RfSjLxBAspz7" Content-Disposition: inline In-Reply-To: <20050314105313.GA21001@gondor.apana.org.au> User-Agent: Mutt/1.5.6+20040907i From: Herbert Xu X-Virus-Scanned: ClamAV version 0.83, clamav-milter version 0.83 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 77 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: herbert@gondor.apana.org.au Precedence: bulk X-list: netdev Content-Length: 1170 Lines: 40 --fdj2RfSjLxBAspz7 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Hi Dave: While replacing dst_pmtu in ip6_output I found this little gem. In ip6_forward we're not reloading the dst pointer after calling xfrm6_route_forward. So all subsequent dereferences of dst will refer to its pre-IPsec value. The solution is of course to refresh its value. Signed-off-by: Herbert Xu Cheers, -- Visit Openswan at http://www.openswan.org/ Email: Herbert Xu ~{PmV>HI~} Home Page: http://gondor.apana.org.au/~herbert/ PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt --fdj2RfSjLxBAspz7 Content-Type: text/plain; charset=us-ascii Content-Disposition: attachment; filename=xfrm-14 ===== net/ipv6/ip6_output.c 1.85 vs edited ===== --- 1.85/net/ipv6/ip6_output.c 2005-03-03 16:12:38 +11:00 +++ edited/net/ipv6/ip6_output.c 2005-03-14 22:05:31 +11:00 @@ -397,6 +397,7 @@ IP6_INC_STATS(IPSTATS_MIB_INDISCARDS); goto drop; } + dst = skb->dst; /* IPv6 specs say nothing about it, but it is clear that we cannot send redirects to source routed frames. --fdj2RfSjLxBAspz7-- From penberg@gmail.com Mon Mar 14 03:40:24 2005 Received: with ECARTIS (v1.0.0; list netdev); Mon, 14 Mar 2005 03:40:31 -0800 (PST) Received: from wproxy.gmail.com (wproxy.gmail.com [64.233.184.205]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j2EBeOGr005648 for ; Mon, 14 Mar 2005 03:40:24 -0800 Received: by wproxy.gmail.com with SMTP id 69so1387228wri for ; Mon, 14 Mar 2005 03:40:18 -0800 (PST) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:reply-to:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:references; b=kVkHhTSfhOnFQJgJu58w9C10IIWRPQ384sY5Tv1mtkxGQCXFAFi3Hj3jjKULD/MMmY2Ok2YLWs+KxHUzfX48k/SdKjucbryNHSdNGt6F0pUAYCqULj7otqbems/1Lr7UCWTT+J9tnVGZDD/hl1Jif1LkX0FIfS26tCVxXi9hqRE= Received: by 10.54.4.8 with SMTP id 8mr4702818wrd; Mon, 14 Mar 2005 03:40:18 -0800 (PST) Received: by 10.54.8.11 with HTTP; Mon, 14 Mar 2005 03:40:18 -0800 (PST) Message-ID: <84144f0205031403404eda561c@mail.gmail.com> Date: Mon, 14 Mar 2005 13:40:18 +0200 From: Pekka Enberg Reply-To: Pekka Enberg To: Andrew Morton Subject: Re: A new 10GB Ethernet Driver by Chelsio Communications Cc: Christoph Lameter , linux-kernel@vger.kernel.org, mark@chelsio.com, netdev@oss.sgi.com, Jeff Garzik , penberg@cs.helsinki.fi In-Reply-To: <84144f0205031403105351abf5@mail.gmail.com> Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit References: <20050311112132.6a3a3b49.akpm@osdl.org> <84144f0205031403105351abf5@mail.gmail.com> X-Virus-Scanned: ClamAV version 0.83, clamav-milter version 0.83 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 78 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: penberg@gmail.com Precedence: bulk X-list: netdev Content-Length: 3891 Lines: 127 Hi, Few more coding style comments. On Fri, 11 Mar 2005 11:21:32 -0800, Andrew Morton wrote: > diff -puN /dev/null drivers/net/chelsio/cxgb2.c > --- /dev/null 2003-09-15 06:40:47.000000000 -0700 > +++ 25-akpm/drivers/net/chelsio/cxgb2.c 2005-03-11 11:13:06.000000000 -0800 > @@ -0,0 +1,1284 @@ > +#ifndef HAVE_FREE_NETDEV > +#define free_netdev(dev) kfree(dev) > +#endif Please drop this wrapper. > + printk(KERN_INFO "%s: %s (rev %d), %s %dMHz/%d-bit\n", adapter->name, > + bi->desc, adapter->params.chip_revision, > + adapter->params.pci.is_pcix ? "PCIX" : "PCI", > + adapter->params.pci.speed, adapter->params.pci.width); > + return 0; > + > + out_release_adapter_res: > + t1_free_sw_modules(adapter); > + out_free_dev: > + if (adapter) { > + if (adapter->tdev) > + kfree(adapter->tdev); kfree() handles null pointers so please drop the redundant check. > diff -puN /dev/null drivers/net/chelsio/gmac.h > --- /dev/null 2003-09-15 06:40:47.000000000 -0700 > +++ 25-akpm/drivers/net/chelsio/gmac.h 2005-03-11 11:13:06.000000000 -0800 > @@ -0,0 +1,126 @@ > + > +typedef struct _cmac_instance cmac_instance; Please drop the typedef. > diff -puN /dev/null drivers/net/chelsio/osdep.h > --- /dev/null 2003-09-15 06:40:47.000000000 -0700 > +++ 25-akpm/drivers/net/chelsio/osdep.h 2005-03-11 11:13:06.000000000 -0800 > @@ -0,0 +1,222 @@ > +#define DRV_NAME "cxgb" > +#define PFX DRV_NAME ": " > + > +#define CH_ERR(fmt, ...) printk(KERN_ERR PFX fmt, ## __VA_ARGS__) > +#define CH_WARN(fmt, ...) printk(KERN_WARNING PFX fmt, ## __VA_ARGS__) > +#define CH_ALERT(fmt, ...) printk(KERN_ALERT PFX fmt, ## __VA_ARGS__) > + > +/* > + * More powerful macro that selectively prints messages based on msg_enable. > + * For info and debugging messages. > + */ > +#define CH_MSG(adapter, level, category, fmt, ...) do { \ > + if ((adapter)->msg_enable & NETIF_MSG_##category) \ > + printk(KERN_##level PFX "%s: " fmt, (adapter)->name, \ > + ## __VA_ARGS__); \ > +} while (0) > + > +#ifdef DEBUG > +# define CH_DBG(adapter, category, fmt, ...) \ > + CH_MSG(adapter, DEBUG, category, fmt, ## __VA_ARGS__) > +#else > +# define CH_DBG(fmt, ...) > +#endif Please consider using dev_* helpers from instead. > + > +/* Additional NETIF_MSG_* categories */ > +#define NETIF_MSG_MMIO 0x8000000 > + > +#define CH_DEVICE(devid, ssid, idx) \ > + { PCI_VENDOR_ID_CHELSIO, devid, PCI_ANY_ID, ssid, 0, 0, idx } > + > +#define SUPPORTED_PAUSE (1 << 13) > +#define SUPPORTED_LOOPBACK (1 << 15) > + > +#define ADVERTISED_PAUSE (1 << 13) > +#define ADVERTISED_ASYM_PAUSE (1 << 14) > + > +/* > + * Now that we have included the driver's main data structure, > + * we typedef it to something the rest of the system understands. > + */ > +typedef struct adapter adapter_t; Please drop the typedef. > + > +#define DELAY_US(x) udelay(x) > + > +#define TPI_LOCK(adapter) spin_lock(&(adapter)->tpi_lock) > +#define TPI_UNLOCK(adapter) spin_unlock(&(adapter)->tpi_lock) Please drop the obfuscating wrappers. > +void t1_elmer0_ext_intr(adapter_t *adapter); > +void t1_link_changed(adapter_t *adapter, int port_id, int link_status, > + int speed, int duplex, int fc); > + > +static inline void DELAY_MS(unsigned long ms) > +{ > + unsigned long ticks = (ms * HZ + 999) / 1000 + 1; > + > + while (ticks) { > + set_current_state(TASK_UNINTERRUPTIBLE); > + ticks = schedule_timeout(ticks); > + } > +} Use msleep here. > diff -puN /dev/null drivers/net/chelsio/subr.c > --- /dev/null 2003-09-15 06:40:47.000000000 -0700 > +++ 25-akpm/drivers/net/chelsio/subr.c 2005-03-11 11:13:06.000000000 -0800 > +typedef struct { > + u32 format_version; > + u8 serial_number[16]; > + u8 mac_base_address[6]; > + u8 pad[2]; /* make multiple-of-4 size requirement explicit */ > +} chelsio_vpd_t; Please drop the typedef. Pekka From kaber@trash.net Mon Mar 14 03:53:26 2005 Received: with ECARTIS (v1.0.0; list netdev); Mon, 14 Mar 2005 03:53:30 -0800 (PST) Received: from kaber.coreworks.de ([62.206.217.67]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j2EBrP9B006413 for ; Mon, 14 Mar 2005 03:53:26 -0800 Received: from localhost ([127.0.0.1]) by kaber.coreworks.de with esmtp (Exim 4.50) id 1DAo7M-0002XT-FI; Mon, 14 Mar 2005 12:52:16 +0100 Message-ID: <42357AF0.4080205@trash.net> Date: Mon, 14 Mar 2005 12:52:16 +0100 From: Patrick McHardy User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.7.5) Gecko/20050106 Debian/1.7.5-1 X-Accept-Language: en MIME-Version: 1.0 To: Herbert Xu CC: "David S. Miller" , Alexey Kuznetsov , James Morris , YOSHIFUJI Hideaki , netdev@oss.sgi.com Subject: Re: [3/4] [IPSEC] Add route element to xfrm_dst References: <20050214221006.GA18415@gondor.apana.org.au> <20050214221200.GA18465@gondor.apana.org.au> <20050214221433.GB18465@gondor.apana.org.au> In-Reply-To: <20050214221433.GB18465@gondor.apana.org.au> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV version 0.83, clamav-milter version 0.83 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 79 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: kaber@trash.net Precedence: bulk X-list: netdev Content-Length: 1138 Lines: 38 Herbert Xu wrote: > This patch adds a pointer to the route corresponding to the specific > flow over the SA of an xfrm_dst that's being used. > > It also sets the next pointer of each xfrm_dst to the one above it. > This allows to traverse the list upwards from the bottom. Looking at this again, I noticed a problem: > + if (remote != fl_tunnel.fl4_dst) { > + fl_tunnel.fl4_src = local; > + fl_tunnel.fl4_dst = remote; > + err = xfrm_dst_lookup((struct xfrm_dst **)&rt, > + &fl_tunnel, AF_INET); > + if (err) > + goto error; > + } else > + dst_hold(&rt->u.dst); > } > + > dst_prev->child = &rt->u.dst; > + dst->path = &rt->u.dst; > + > + *dst_p = dst; > + dst = dst_prev; > + > + dst_prev = *dst_p; > i = 0; > - for (dst_prev = dst; dst_prev != &rt->u.dst; dst_prev = dst_prev->child) { > + for (; dst_prev != &rt->u.dst; dst_prev = dst_prev->child) { Since the tunnel dst is not necessarily the last in the bundle anymore, we might miss to initialize some dsts, for example with ipcomp/tunnel + esp/transport. If we have nested tunnels we'll fiddle with entries in the routing cache. Regards Patrick From steve@services.navaho.net Mon Mar 14 04:12:41 2005 Received: with ECARTIS (v1.0.0; list netdev); Mon, 14 Mar 2005 04:12:55 -0800 (PST) Received: from services.navaho.net (fairchild-194.adsl.newnet.co.uk [213.131.187.194]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j2ECCeZZ007941 for ; Mon, 14 Mar 2005 04:12:40 -0800 Received: from [10.101.0.42] (helo=[10.101.0.42] ident=[U2FsdGVkX18Ssidkn/L5xefEXDi8UhlpRgDm7p3Vo3E=]) by services.navaho.net with esmtp (Exim 4.43) id 1DAoQu-0001md-3V; Mon, 14 Mar 2005 12:12:28 +0000 Date: Mon, 14 Mar 2005 12:12:27 +0000 (GMT) From: Steve Hill X-X-Sender: steve@sorbus2.navaho To: Herbert Xu cc: Patrick McHardy , netdev@oss.sgi.com, "David S. Miller" Subject: Re: More IPSEC trouble In-Reply-To: <20050312013515.GA17539@gondor.apana.org.au> Message-ID: References: <42323125.20706@trash.net> <20050312013515.GA17539@gondor.apana.org.au> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Virus-Scanned: ClamAV version 0.83, clamav-milter version 0.83 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 80 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: steve@services.navaho.net Precedence: bulk X-list: netdev Content-Length: 462 Lines: 14 On Sat, 12 Mar 2005, Herbert Xu wrote: > Since tunnel_check_size only looks at the state to determine whether > it's tunnel mode, it doesn't need to hold the lock at all. > > Signed-off-by: Herbert Xu I can confirm this fixes the problem - tested under 2.6.10. - Steve Hill (BSc) Senior Software Developer Email: steve@navaho.co.uk Navaho Technologies Ltd. Tel: +44-870-7034015 From hasso@estpak.ee Mon Mar 14 04:35:41 2005 Received: with ECARTIS (v1.0.0; list netdev); Mon, 14 Mar 2005 04:35:46 -0800 (PST) Received: from arena.estpak.ee (test.estpak.ee [194.126.115.47]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j2ECZecq012396 for ; Mon, 14 Mar 2005 04:35:40 -0800 Received: from localhost ([127.0.0.1] helo=arena) by arena.estpak.ee with esmtp (Exim 4.44) id 1DAonK-00014x-Ef for netdev@oss.sgi.com; Mon, 14 Mar 2005 14:35:38 +0200 From: Hasso Tepper To: netdev@oss.sgi.com Subject: Link detection Date: Mon, 14 Mar 2005 14:35:38 +0200 User-Agent: KMail/1.7.2 Organization: Elion Enterprises Ltd. MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-15" Content-Disposition: inline Message-Id: <200503141435.38227.hasso@estpak.ee> X-Virus-Scanned: ClamAV version 0.83, clamav-milter version 0.83 on oss.sgi.com X-Virus-Status: Clean Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by oss.sgi.com id j2ECZecq012396 X-archive-position: 81 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: hasso@estpak.ee Precedence: bulk X-list: netdev Content-Length: 3434 Lines: 71 We (the Quagga project) are planning to rework link detection in Quagga to support more platforms (only Linux and Solaris are supported at the moment) and to have proper abstraction of link detection in zebra daemon. During discussions several questions were raised. 1) What's the proper way to detect carrier in Linux for user space application like Quagga? Till now I thought that IFF_RUNNING flag should be used for that. But some time ago I tried to bug Stephen Hemminger about missing IFF_RUNNING flag in ip output and got answer that IFF_RUNNING is BSD'ism and shouldn't be used any more and /sys/class/net/eth0/carrier should be looked at. True, IFF_RUNNING is from BSD, but as long as the code in net/core/dev.c:dev_get_flags() is there, it gives nice clean way to get carrier status from user space (AFAIK it's used in same way in Solaris). Especially for applications using rtnetlink - ie. without it there is no all info in the netlink message any more. If these applications will receive RTM_NEWLINK, they have to poll kernel "look, maybe carrier status is changed" every time? 2) There is no difference between "we know that carrier is really on" and "interface doesn't support carrier detection" in Linux. From users' point of view it might make huge difference - can I rely on info I get from OS, or have to run to the equipment to see whether links are really up or not? It's not critical, but would be still nice to have. 3) Connected routes in carrier down situations. If address are added to the interface, "connected" route is added to the interface as well. Problem is that this route is still there if carrier is down, but there is no difference for user if just carrier is down or interface is administratively down - network behind this interface is still actually unreachable. It's not only the issue related with routing protocols, but the general one. I'm using laptop with two interfaces - ethernet and wireless. If I plug off ethernet cable and walk away from my desk, the network on this ethernet segment should be still reachable for me via wireless (default route), but no ... I have to shut down ethernet interface manually. There are several scenarios which are affected - building redundant firewalls/gateways, computers/equipment with backup links etc. And of course routers. We take care of this in Quagga not to take nexthops in down network into account, but it doesn't matter if destination of actual traffic is this particular network on interface which is actually down. Before someone proposes that - yes, managing these routes can be done from user space in theory (like zebra daemon), but there are several problems regarding this. * Managing connected routes from user space might leave network in inconsistent state. You can't create routes with protocol kernel with ip utility, so kernel will not remove these routes if address is really deleted from interface. * There are several applications which would be interested in this, but it would be dangerous imho if several applications at once will manage connected routes in kernel. And I don't see any actual reason not to manage removal/adding connected routes in kernel level if link goes down/up. Or is there any? Why would anyone need route to the interface if it's actually known to be unusable? with my best wishes, -- Hasso Tepper Elion Enterprises Ltd. WAN administrator From yoshfuji@wide.ad.jp Mon Mar 14 05:31:49 2005 Received: with ECARTIS (v1.0.0; list netdev); Mon, 14 Mar 2005 05:31:58 -0800 (PST) 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 j2EDVnvO015289 for ; Mon, 14 Mar 2005 05:31:49 -0800 Received: from localhost (localhost [127.0.0.1]) by yue.st-paulia.net (Postfix) with ESMTP id 8826933CC2 for ; Mon, 14 Mar 2005 22:33:33 +0900 (JST) Resent-Date: Mon, 14 Mar 2005 22:33:32 +0900 (JST) Resent-Message-Id: <20050314.223332.28902097.yoshfuji@wide.ad.jp> Resent-To: netdev@oss.sgi.com Resent-From: YOSHIFUJI Hideaki / =?iso-2022-jp?B?GyRCNUhGIzFRTEAbKEI=?= X-Authentication-Warning: localhost.localdomain: alan set sender to alan@lxorguk.ukuu.org.uk using -f Subject: Re: select() doesn't respect SO_RCVLOWAT ? From: Alan Cox To: Felix Matathias Cc: Linux Kernel Mailing List In-Reply-To: References: <1110568180.17740.69.camel@localhost.localdomain> Content-Type: text/plain Content-Transfer-Encoding: 7bit Message-Id: <1110806662.15927.108.camel@localhost.localdomain> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.6 (1.4.6-2) Date: Mon, 14 Mar 2005 13:24:24 +0000 Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org X-Virus-Scanned: ClamAV version 0.83, clamav-milter version 0.83 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 86 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: yoshfuji@wide.ad.jp Precedence: bulk X-list: netdev Content-Length: 1002 Lines: 25 On Gwe, 2005-03-11 at 20:26, Felix Matathias wrote: > Dear Alan, > > I am positive. I can setsockopt, and then, getsockopt returns the value > that I requested. Ok I misremembered - its SNDLOWAT that is locked to one in Linux. > Stevens very clearly states that SO_RCVLOWAT has a direct impact on > select() and I assumed that this would be the case for Linux. > What is the rationale for not complying with that ? Is it the micromanagement > of select() that you dislike ? Isn't a significant reduction in the > amount of read operations a real gain in high speed networking ? I believe since we implement SO_SNDLOWAT that its a bug. Stevens and 1003.1g both agree with your expectations. The right list is probably netdev@oss.sgi.com however. Alan - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/ From yoshfuji@wide.ad.jp Mon Mar 14 05:31:12 2005 Received: with ECARTIS (v1.0.0; list netdev); Mon, 14 Mar 2005 05:31:18 -0800 (PST) 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 j2EDVBwq014645 for ; Mon, 14 Mar 2005 05:31:11 -0800 Received: from localhost (localhost [127.0.0.1]) by yue.st-paulia.net (Postfix) with ESMTP id D197C33CC2 for ; Mon, 14 Mar 2005 22:32:55 +0900 (JST) Resent-Date: Mon, 14 Mar 2005 22:32:55 +0900 (JST) Resent-Message-Id: <20050314.223255.52292727.yoshfuji@wide.ad.jp> Resent-To: netdev@oss.sgi.com Resent-From: YOSHIFUJI Hideaki / =?iso-2022-jp?B?GyRCNUhGIzFRTEAbKEI=?= X-Authentication-Warning: localhost.localdomain: alan set sender to alan@lxorguk.ukuu.org.uk using -f Subject: Re: select() doesn't respect SO_RCVLOWAT ? From: Alan Cox To: Felix Matathias Cc: Linux Kernel Mailing List In-Reply-To: References: Content-Type: text/plain Content-Transfer-Encoding: 7bit Message-Id: <1110568180.17740.69.camel@localhost.localdomain> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.6 (1.4.6-2) Date: Fri, 11 Mar 2005 19:09:41 +0000 Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org X-Virus-Scanned: ClamAV version 0.83, clamav-milter version 0.83 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 84 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: yoshfuji@wide.ad.jp Precedence: bulk X-list: netdev Content-Length: 553 Lines: 14 On Iau, 2005-03-10 at 21:58, Felix Matathias wrote: > Dear all, > > I am running a 2.4.21-9.0.3.ELsmp #1 kernel and I can setsockopt and > getsockopt correctly the SO_RCVLOWAT option The only value the code at least used to support was setting it to 1. Are you sure you are actually setting/checking ok ? - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/ From yoshfuji@wide.ad.jp Mon Mar 14 05:31:00 2005 Received: with ECARTIS (v1.0.0; list netdev); Mon, 14 Mar 2005 05:31:05 -0800 (PST) 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 j2EDUxTu014517 for ; Mon, 14 Mar 2005 05:31:00 -0800 Received: from localhost (localhost [127.0.0.1]) by yue.st-paulia.net (Postfix) with ESMTP id 53A6A33CC2 for ; Mon, 14 Mar 2005 22:32:44 +0900 (JST) Resent-Date: Mon, 14 Mar 2005 22:32:43 +0900 (JST) Resent-Message-Id: <20050314.223243.51754658.yoshfuji@wide.ad.jp> Resent-To: netdev@oss.sgi.com Resent-From: YOSHIFUJI Hideaki / =?iso-2022-jp?B?GyRCNUhGIzFRTEAbKEI=?= Date: Fri, 11 Mar 2005 06:43:08 +0100 From: Willy Tarreau To: Felix Matathias Cc: linux-kernel@vger.kernel.org Subject: Re: select() doesn't respect SO_RCVLOWAT ? Message-ID: <20050311054307.GF30052@alpha.home.local> References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4i Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org X-Virus-Scanned: ClamAV version 0.83, clamav-milter version 0.83 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 83 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: yoshfuji@wide.ad.jp Precedence: bulk X-list: netdev Content-Length: 1973 Lines: 46 On Thu, Mar 10, 2005 at 04:58:51PM -0500, Felix Matathias wrote: > > I am running a 2.4.21-9.0.3.ELsmp #1 kernel and I can setsockopt and > getsockopt correctly the SO_RCVLOWAT option, but select() seems to mark a > socket readable even if a single byte is ready to be read. Then, a read() > blocks until the specified number of bytes in SO_RCVLOWAT makes it to the > socket buffer. as discussed in a previous thread, if you use select(), you should also use non-blocking sockets. There are cases where select() can wake you up without anything to read, eg if there is a packet waiting with a wrong checksum. > This is the exact opposite behaviour of what I yould have > expected/desired. Our application receives data at many Khz rate and we > want to avoid reading the socket until a predetermined amount of data is > sent, to avoid partial reads. SO_RCVLOWAT seemed to be a nice way to > implement that. I too came across this problem a long time ago and concluded that LOWAT was not really usable on Linux. But in the end, this is not really a big deal, because as long as your application doesn't eat all CPU, it does not change anything performance-wise, and when it becomes to eat a lot of CPU, the latency will increase, letting more data come in when you do one read. > An earlier message by Alan Cox was a bit cryptic: > > "But is the cost of all those special case checks and all the handling > for it such as select computing if enough tcp packets together accumulated > worth the cost on every app not using LOWAT for the microscopic gain given > that essentially nobody uses it." > > Does this mean that select() in Linux will wake up no matter what > SO_RCVLOWAT is set to ? Yes. Regards, Willy - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/ From yoshfuji@wide.ad.jp Mon Mar 14 05:30:45 2005 Received: with ECARTIS (v1.0.0; list netdev); Mon, 14 Mar 2005 05:30:50 -0800 (PST) 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 j2EDUiDB014458 for ; Mon, 14 Mar 2005 05:30:45 -0800 Received: from localhost (localhost [127.0.0.1]) by yue.st-paulia.net (Postfix) with ESMTP id A150033CC2 for ; Mon, 14 Mar 2005 22:32:28 +0900 (JST) Resent-Date: Mon, 14 Mar 2005 22:32:28 +0900 (JST) Resent-Message-Id: <20050314.223228.01498740.yoshfuji@wide.ad.jp> Resent-To: netdev@oss.sgi.com Resent-From: YOSHIFUJI Hideaki / =?iso-2022-jp?B?GyRCNUhGIzFRTEAbKEI=?= Date: Thu, 10 Mar 2005 16:58:51 -0500 (EST) From: Felix Matathias To: linux-kernel@vger.kernel.org Subject: select() doesn't respect SO_RCVLOWAT ? Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Scanned-By: MIMEDefang 2.51 on 129.236.252.8 Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org X-Virus-Scanned: ClamAV version 0.83, clamav-milter version 0.83 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 82 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: yoshfuji@wide.ad.jp Precedence: bulk X-list: netdev Content-Length: 1816 Lines: 46 Dear all, I am running a 2.4.21-9.0.3.ELsmp #1 kernel and I can setsockopt and getsockopt correctly the SO_RCVLOWAT option, but select() seems to mark a socket readable even if a single byte is ready to be read. Then, a read() blocks until the specified number of bytes in SO_RCVLOWAT makes it to the socket buffer. This is the exact opposite behaviour of what I yould have expected/desired. Our application receives data at many Khz rate and we want to avoid reading the socket until a predetermined amount of data is sent, to avoid partial reads. SO_RCVLOWAT seemed to be a nice way to implement that. An earlier message by Alan Cox was a bit cryptic: "But is the cost of all those special case checks and all the handling for it such as select computing if enough tcp packets together accumulated worth the cost on every app not using LOWAT for the microscopic gain given that essentially nobody uses it." Does this mean that select() in Linux will wake up no matter what SO_RCVLOWAT is set to ? Best Regards, Felix Matathias P.S. I would appreciate if you could also cc your response to me. -- ______________________________________________________________________ Felix Matathias of Columbia University, Nevis Labs Brookhaven National Lab cell : 631-988-3694 Bldg 1005, 3-304 web : http://www.matathias.com Upton, NY, 11973 photo: http://www.pbase.com/matathias tel/fax :631-344-7622/3253 email: felix@nevis.columbia.edu _______________________________________________________________________ - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/ From tgraf@suug.ch Mon Mar 14 05:31:59 2005 Received: with ECARTIS (v1.0.0; list netdev); Mon, 14 Mar 2005 05:32:08 -0800 (PST) Received: from b.mx.projectdream.org (eth0-0.arisu.projectdream.org [194.158.4.191]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j2EDVwe1015439 for ; Mon, 14 Mar 2005 05:31:59 -0800 Received: from postel.suug.ch (postel.suug.ch [195.134.158.23]) (using TLSv1 with cipher EDH-RSA-DES-CBC3-SHA (168/168 bits)) (No client certificate requested) by b.mx.projectdream.org (Postfix) with ESMTP id 1D7DE82; Mon, 14 Mar 2005 14:31:34 +0100 (CET) Received: by postel.suug.ch (Postfix, from userid 10001) id E7ED41C0EA; Mon, 14 Mar 2005 14:32:16 +0100 (CET) Date: Mon, 14 Mar 2005 14:32:16 +0100 From: Thomas Graf To: Hasso Tepper Cc: netdev@oss.sgi.com Subject: Re: Link detection Message-ID: <20050314133216.GM31837@postel.suug.ch> References: <200503141435.38227.hasso@estpak.ee> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200503141435.38227.hasso@estpak.ee> X-Virus-Scanned: ClamAV version 0.83, clamav-milter version 0.83 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 87 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: tgraf@suug.ch Precedence: bulk X-list: netdev Content-Length: 4342 Lines: 83 * Hasso Tepper <200503141435.38227.hasso@estpak.ee> 2005-03-14 14:35 > 1) What's the proper way to detect carrier in Linux for user space > application like Quagga? > > True, IFF_RUNNING is from BSD, but as long as the code in > net/core/dev.c:dev_get_flags() is there, it gives nice clean way to get > carrier status from user space (AFAIK it's used in same way in Solaris). > Especially for applications using rtnetlink - ie. without it there is no > all info in the netlink message any more. If these applications will > receive RTM_NEWLINK, they have to poll kernel "look, maybe carrier status > is changed" every time? You should open a rtnetlink socket and register to the RTMGRP_LINK multicast group and filter for RTM_NEWLINK with ifi_change & IFF_UP and then look at ifi_flags & IFF_UP to see whether the interface is now up or down. You'll receive such a rtnetlink message everytime the carrier status changes. > 2) There is no difference between "we know that carrier is really on" and > "interface doesn't support carrier detection" in Linux. > > >From users' point of view it might make huge difference - can I rely on info > I get from OS, or have to run to the equipment to see whether links are > really up or not? It's not critical, but would be still nice to have. Yes, this is a known weakness. You can use ethtool to work around this a bit. > 3) Connected routes in carrier down situations. If address are added to the > interface, "connected" route is added to the interface as well. Problem is > that this route is still there if carrier is down, but there is no > difference for user if just carrier is down or interface is > administratively down - network behind this interface is still actually > unreachable. The routes must stay if the interface isn't shut down completely. A loss of the carrier can be temporarly for just a very short period of time. What we can do is, like in the neighbour tables, differ between a adimistrative shutdown and a loss of the carrier with a new flag, would that help you? > It's not only the issue related with routing protocols, but the general one. > I'm using laptop with two interfaces - ethernet and wireless. If I plug off > ethernet cable and walk away from my desk, the network on this ethernet > segment should be still reachable for me via wireless (default route), but > no ... I have to shut down ethernet interface manually. I think the reaction upon a loss of the carrier should remain in userspace to some kind of daemon. The only way that would be half working would be some kind of timeout representing a watermark which makes a temporary carrier loss a permanent one (i.e. react on it as it would be a permanent shutdown). This timer must be disabled by default but can be activated by the user. My question is, what should happen once the carrier is found again? Restore the routes from somd kind of backup tables created while disabling the interface? Leave it to userspace? > Before someone proposes that - yes, managing these routes can be done from > user space in theory (like zebra daemon), but there are several problems > regarding this. > > * There are several applications which would be interested in this, but it > would be dangerous imho if several applications at once will manage > connected routes in kernel. This is subject to be solved via the use of a netlink daemon taking care of proper locking. Just needs some more time. > And I don't see any actual reason not to manage removal/adding connected > routes in kernel level if link goes down/up. Or is there any? Why would > anyone need route to the interface if it's actually known to be unusable? Problem #1: Differ between a temporary loss of carrier and a permanent failure. Relatively easy from userspace because userspace knows about the strategy. Problem #2: Strategy upon resume of carrier signal, userspace can simply reread its configuration and add the routes again. Kernel must backup them and somehow ensure that they stay consistent. Imagine you delete a route to a certain host but one of your links is down at the moment, the route will be restored once the interface comes back up which is probably unexpected behaviour. Both issues can be solved with quite some effort though. From yoshfuji@wide.ad.jp Mon Mar 14 05:31:33 2005 Received: with ECARTIS (v1.0.0; list netdev); Mon, 14 Mar 2005 05:31:38 -0800 (PST) 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 j2EDVWR6015020 for ; Mon, 14 Mar 2005 05:31:32 -0800 Received: from localhost (localhost [127.0.0.1]) by yue.st-paulia.net (Postfix) with ESMTP id 01A8233CC2 for ; Mon, 14 Mar 2005 22:33:16 +0900 (JST) Resent-Date: Mon, 14 Mar 2005 22:33:16 +0900 (JST) Resent-Message-Id: <20050314.223316.117280596.yoshfuji@wide.ad.jp> Resent-To: netdev@oss.sgi.com Resent-From: YOSHIFUJI Hideaki / =?iso-2022-jp?B?GyRCNUhGIzFRTEAbKEI=?= Date: Fri, 11 Mar 2005 15:26:38 -0500 (EST) From: Felix Matathias To: Alan Cox Cc: Linux Kernel Mailing List Subject: Re: select() doesn't respect SO_RCVLOWAT ? In-Reply-To: <1110568180.17740.69.camel@localhost.localdomain> Message-ID: References: <1110568180.17740.69.camel@localhost.localdomain> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Scanned-By: MIMEDefang 2.51 on 129.236.252.8 Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org X-Virus-Scanned: ClamAV version 0.83, clamav-milter version 0.83 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 85 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: yoshfuji@wide.ad.jp Precedence: bulk X-list: netdev Content-Length: 1531 Lines: 44 Dear Alan, I am positive. I can setsockopt, and then, getsockopt returns the value that I requested. Stevens very clearly states that SO_RCVLOWAT has a direct impact on select() and I assumed that this would be the case for Linux. What is the rationale for not complying with that ? Is it the micromanagement of select() that you dislike ? Isn't a significant reduction in the amount of read operations a real gain in high speed networking ? Best Regards, Felix On Fri, 11 Mar 2005, Alan Cox wrote: > On Iau, 2005-03-10 at 21:58, Felix Matathias wrote: >> Dear all, >> >> I am running a 2.4.21-9.0.3.ELsmp #1 kernel and I can setsockopt and >> getsockopt correctly the SO_RCVLOWAT option > > The only value the code at least used to support was setting it to 1. > Are you sure you are actually setting/checking ok ? > -- ______________________________________________________________________ Felix Matathias of Columbia University, Nevis Labs Brookhaven National Lab cell : 631-988-3694 Bldg 1005, 3-304 web : http://www.matathias.com Upton, NY, 11973 photo: http://www.pbase.com/matathias tel/fax :631-344-7622/3253 email: felix@nevis.columbia.edu _______________________________________________________________________ - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/ From yoshfuji@linux-ipv6.org Mon Mar 14 05:32:39 2005 Received: with ECARTIS (v1.0.0; list netdev); Mon, 14 Mar 2005 05:32:46 -0800 (PST) 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 j2EDWcjk016268 for ; Mon, 14 Mar 2005 05:32:38 -0800 Received: from localhost (localhost [127.0.0.1]) by yue.st-paulia.net (Postfix) with ESMTP id E667B33CC2; Mon, 14 Mar 2005 22:34:22 +0900 (JST) Date: Mon, 14 Mar 2005 22:34:22 +0900 (JST) Message-Id: <20050314.223422.120167824.yoshfuji@linux-ipv6.org> To: alan@lxorguk.ukuu.org.uk, felix@nevis.columbia.edu Cc: linux-kernel@vger.kernel.org, netdev@oss.sgi.com Subject: Re: select() doesn't respect SO_RCVLOWAT ? From: YOSHIFUJI Hideaki / =?iso-2022-jp?B?GyRCNUhGIzFRTEAbKEI=?= In-Reply-To: <1110806662.15927.108.camel@localhost.localdomain> References: <1110568180.17740.69.camel@localhost.localdomain> <1110806662.15927.108.camel@localhost.localdomain> 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-Virus-Scanned: ClamAV version 0.83, clamav-milter version 0.83 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 88 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: yoshfuji@linux-ipv6.org Precedence: bulk X-list: netdev Content-Length: 301 Lines: 8 In article <1110806662.15927.108.camel@localhost.localdomain> (at Mon, 14 Mar 2005 13:24:24 +0000), Alan Cox says: > 1003.1g both agree with your expectations. The right list is probably > netdev@oss.sgi.com however. I've just forwarded this thread to netdev. --yoshfuji From hasso@estpak.ee Mon Mar 14 06:05:08 2005 Received: with ECARTIS (v1.0.0; list netdev); Mon, 14 Mar 2005 06:05:12 -0800 (PST) Received: from arena.estpak.ee (test.estpak.ee [194.126.115.47]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j2EE56uU018844 for ; Mon, 14 Mar 2005 06:05:07 -0800 Received: from localhost ([127.0.0.1] helo=arena) by arena.estpak.ee with esmtp (Exim 4.44) id 1DAqBr-00019z-2a; Mon, 14 Mar 2005 16:05:03 +0200 From: Hasso Tepper To: Thomas Graf Subject: Re: Link detection Date: Mon, 14 Mar 2005 16:05:02 +0200 User-Agent: KMail/1.7.2 Cc: netdev@oss.sgi.com References: <200503141435.38227.hasso@estpak.ee> <20050314133216.GM31837@postel.suug.ch> In-Reply-To: <20050314133216.GM31837@postel.suug.ch> Organization: Elion Enterprises Ltd. MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200503141605.02959.hasso@estpak.ee> X-Virus-Scanned: ClamAV version 0.83, clamav-milter version 0.83 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 89 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: hasso@estpak.ee Precedence: bulk X-list: netdev Content-Length: 1926 Lines: 46 Thomas Graf wrote: > The routes must stay if the interface isn't shut down completely. A loss > of the carrier can be temporarly for just a very short period of time. > What we can do is, like in the neighbour tables, differ between a > adimistrative shutdown and a loss of the carrier with a new flag, would > that help you? In theory yes, if this info is carried over netlink. > Problem #1: Differ between a temporary loss of carrier and a permanent > failure. Relatively easy from userspace because userspace > knows about the strategy. Is there need for that? There should be knob of course to tune behaviour IMHO. Sure there are applications which expect current behaviour. > Problem #2: Strategy upon resume of carrier signal, userspace can simply > reread its configuration and add the routes again. Kernel > must backup them and somehow ensure that they stay > consistent. Imagine you delete a route to a certain host but > one of your links is down at the moment, the route will be > restored once the interface comes back up which is probably > unexpected behaviour. I think that you misunderstood. I don't talk about any routes created by any user space applications or by user. These _must_ be untouched of course. I'm talking about routes _kernel_ creates if address is added to the interface. All other routes are not problem anyway. Even if their next hop points to network behind down interface, their next hop is unreachable and route shouldn't be used, no? arena:/home/hasso# ip route | grep 192.168 arena:/home/hasso# ip addr add 192.168.1.1/24 dev eth0 arena:/home/hasso# ip route | grep 192.168 192.168.1.0/24 dev eth0 proto kernel scope link src 192.168.1.1 arena:/home/hasso# I'm talking only about these routes - created by kernel with link scope. with my best wishes, -- Hasso Tepper Elion Enterprises Ltd. WAN administrator From hasso@estpak.ee Mon Mar 14 06:41:37 2005 Received: with ECARTIS (v1.0.0; list netdev); Mon, 14 Mar 2005 06:41:42 -0800 (PST) Received: from arena.estpak.ee (test.estpak.ee [194.126.115.47]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j2EEfaB3020152 for ; Mon, 14 Mar 2005 06:41:36 -0800 Received: from localhost ([127.0.0.1] helo=arena) by arena.estpak.ee with esmtp (Exim 4.44) id 1DAqlB-0001CW-NP; Mon, 14 Mar 2005 16:41:33 +0200 From: Hasso Tepper To: Thomas Graf Subject: Re: Link detection Date: Mon, 14 Mar 2005 16:41:33 +0200 User-Agent: KMail/1.7.2 Cc: netdev@oss.sgi.com References: <200503141435.38227.hasso@estpak.ee> <20050314133216.GM31837@postel.suug.ch> In-Reply-To: <20050314133216.GM31837@postel.suug.ch> Organization: Elion Enterprises Ltd. MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200503141641.33510.hasso@estpak.ee> X-Virus-Scanned: ClamAV version 0.83, clamav-milter version 0.83 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 90 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: hasso@estpak.ee Precedence: bulk X-list: netdev Content-Length: 1210 Lines: 31 Thomas Graf wrote: > * Hasso Tepper <200503141435.38227.hasso@estpak.ee> 2005-03-14 14:35 > > > 1) What's the proper way to detect carrier in Linux for user space > > application like Quagga? > > > > True, IFF_RUNNING is from BSD, but as long as the code in > > net/core/dev.c:dev_get_flags() is there, it gives nice clean way to get > > carrier status from user space (AFAIK it's used in same way in > > Solaris). Especially for applications using rtnetlink - ie. without it > > there is no all info in the netlink message any more. If these > > applications will receive RTM_NEWLINK, they have to poll kernel "look, > > maybe carrier status is changed" every time? > > You should open a rtnetlink socket and register to the RTMGRP_LINK > multicast group and filter for RTM_NEWLINK with ifi_change & IFF_UP and > then look at ifi_flags & IFF_UP to see whether the interface is now > up or down. You'll receive such a rtnetlink message everytime the > carrier status changes. Forgot to answer this part. We already do all this. IFF_UP doesn't show carrier status, but administrative status. IFF_RUNNING shows carrier status. with my best wishes, -- Hasso Tepper Elion Enterprises Ltd. WAN administrator From tgraf@suug.ch Mon Mar 14 06:56:54 2005 Received: with ECARTIS (v1.0.0; list netdev); Mon, 14 Mar 2005 06:56:59 -0800 (PST) Received: from b.mx.projectdream.org (eth0-0.arisu.projectdream.org [194.158.4.191]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j2EEuri2021078 for ; Mon, 14 Mar 2005 06:56:53 -0800 Received: from postel.suug.ch (postel.suug.ch [195.134.158.23]) (using TLSv1 with cipher EDH-RSA-DES-CBC3-SHA (168/168 bits)) (No client certificate requested) by b.mx.projectdream.org (Postfix) with ESMTP id 301C182; Mon, 14 Mar 2005 15:56:28 +0100 (CET) Received: by postel.suug.ch (Postfix, from userid 10001) id C637D1C0EA; Mon, 14 Mar 2005 15:57:10 +0100 (CET) Date: Mon, 14 Mar 2005 15:57:10 +0100 From: Thomas Graf To: Hasso Tepper Cc: netdev@oss.sgi.com Subject: Re: Link detection Message-ID: <20050314145710.GO31837@postel.suug.ch> References: <200503141435.38227.hasso@estpak.ee> <20050314133216.GM31837@postel.suug.ch> <200503141605.02959.hasso@estpak.ee> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200503141605.02959.hasso@estpak.ee> X-Virus-Scanned: ClamAV version 0.83, clamav-milter version 0.83 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 91 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: tgraf@suug.ch Precedence: bulk X-list: netdev Content-Length: 1999 Lines: 38 * Hasso Tepper <200503141605.02959.hasso@estpak.ee> 2005-03-14 16:05 > > The routes must stay if the interface isn't shut down completely. A loss > > of the carrier can be temporarly for just a very short period of time. > > What we can do is, like in the neighbour tables, differ between a > > adimistrative shutdown and a loss of the carrier with a new flag, would > > that help you? > > In theory yes, if this info is carried over netlink. It is carried but not in the way I mentioned. I was wrong with IFF_UP, it isn't modified. An event is sent upon carrier off and again when the carrier is found again so you must toggle. Alternatively we can alter a flag in netif_carrier_(on|off) which is probably a good idea anyway. I'll prepare a patch for this. Polling sysfs is definitely not the way to go. > > Problem #1: Differ between a temporary loss of carrier and a permanent > > failure. Relatively easy from userspace because userspace > > knows about the strategy. > > Is there need for that? There should be knob of course to tune behaviour > IMHO. Sure there are applications which expect current behaviour. Now that I know you're only taking about implicite routes the problem is less serious, still a timeout value would be a good thing, one can always set it to 0 to remove routes immediately or disable it completely. > I think that you misunderstood. I don't talk about any routes created by any > user space applications or by user. These _must_ be untouched of course. > I'm talking about routes _kernel_ creates if address is added to the > interface. All other routes are not problem anyway. Even if their next hop > points to network behind down interface, their next hop is unreachable and > route shouldn't be used, no? Makes a lot more sense now. Yes, the nexthops should be marked unreachable since the routing cache flushed upon a NETDEV_CHANGE. What about setting RFT_REJECT/RTN_UNREACHABLE on those routes for the time the carrier is gone? From tgraf@suug.ch Mon Mar 14 07:02:43 2005 Received: with ECARTIS (v1.0.0; list netdev); Mon, 14 Mar 2005 07:02:47 -0800 (PST) Received: from b.mx.projectdream.org (eth0-0.arisu.projectdream.org [194.158.4.191]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j2EF2g6E021831 for ; Mon, 14 Mar 2005 07:02:42 -0800 Received: from postel.suug.ch (postel.suug.ch [195.134.158.23]) (using TLSv1 with cipher EDH-RSA-DES-CBC3-SHA (168/168 bits)) (No client certificate requested) by b.mx.projectdream.org (Postfix) with ESMTP id 8066282; Mon, 14 Mar 2005 16:02:19 +0100 (CET) Received: by postel.suug.ch (Postfix, from userid 10001) id 506371C0EA; Mon, 14 Mar 2005 16:03:02 +0100 (CET) Date: Mon, 14 Mar 2005 16:03:02 +0100 From: Thomas Graf To: Hasso Tepper Cc: netdev@oss.sgi.com Subject: Re: Link detection Message-ID: <20050314150302.GP31837@postel.suug.ch> References: <200503141435.38227.hasso@estpak.ee> <20050314133216.GM31837@postel.suug.ch> <200503141641.33510.hasso@estpak.ee> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200503141641.33510.hasso@estpak.ee> X-Virus-Scanned: ClamAV version 0.83, clamav-milter version 0.83 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 92 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: tgraf@suug.ch Precedence: bulk X-list: netdev Content-Length: 264 Lines: 6 * Hasso Tepper <200503141641.33510.hasso@estpak.ee> 2005-03-14 16:41 > Forgot to answer this part. We already do all this. IFF_UP doesn't show > carrier status, but administrative status. IFF_RUNNING shows carrier > status. You're right, forget what I've said. From tgraf@suug.ch Mon Mar 14 08:16:05 2005 Received: with ECARTIS (v1.0.0; list netdev); Mon, 14 Mar 2005 08:16:11 -0800 (PST) Received: from b.mx.projectdream.org (eth0-0.arisu.projectdream.org [194.158.4.191]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j2EGG4wS024069 for ; Mon, 14 Mar 2005 08:16:04 -0800 Received: from postel.suug.ch (postel.suug.ch [195.134.158.23]) (using TLSv1 with cipher EDH-RSA-DES-CBC3-SHA (168/168 bits)) (No client certificate requested) by b.mx.projectdream.org (Postfix) with ESMTP id E9AE18A; Mon, 14 Mar 2005 17:15:38 +0100 (CET) Received: by postel.suug.ch (Postfix, from userid 10001) id D65D51C0EA; Mon, 14 Mar 2005 17:16:21 +0100 (CET) Date: Mon, 14 Mar 2005 17:16:21 +0100 From: Thomas Graf To: Stephen Hemminger Cc: Hasso Tepper , netdev@oss.sgi.com Subject: [PATCH] ip link should print NO-CARRIER for !IFF_RUNNING && IFF_UP Message-ID: <20050314161621.GQ31837@postel.suug.ch> References: <200503141435.38227.hasso@estpak.ee> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200503141435.38227.hasso@estpak.ee> X-Virus-Scanned: ClamAV 0.83/762/Sun Mar 13 15:35:33 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 93 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: tgraf@suug.ch Precedence: bulk X-list: netdev Content-Length: 1119 Lines: 30 > Till now I thought that IFF_RUNNING flag should be used for that. But some > time ago I tried to bug Stephen Hemminger about missing IFF_RUNNING flag in > ip output and got answer that IFF_RUNNING is BSD'ism and shouldn't be used > any more and /sys/class/net/eth0/carrier should be looked at. The patch below changes ip link to print NO-CARRIER flag if there is no carrier and the link is up. # This is a BitKeeper generated diff -Nru style patch. # # ChangeSet # 2005/03/14 17:12:43+01:00 tgraf@suug.ch # [LINK] Report if link has no carrier # # ip/ipaddress.c # 2005/03/14 17:12:43+01:00 tgraf@suug.ch +2 -0 # [LINK] Report if link has no carrier # diff -Nru a/ip/ipaddress.c b/ip/ipaddress.c --- a/ip/ipaddress.c 2005-03-14 17:13:59 +01:00 +++ b/ip/ipaddress.c 2005-03-14 17:13:59 +01:00 @@ -77,6 +77,8 @@ void print_link_flags(FILE *fp, unsigned flags, unsigned mdown) { fprintf(fp, "<"); + if (flags & IFF_UP && !(flags & IFF_RUNNING)) + fprintf(fp, "NO-CARRIER%s", flags ? "," : ""); flags &= ~IFF_RUNNING; #define _PF(f) if (flags&IFF_##f) { \ flags &= ~IFF_##f ; \ From bernd.schubert@pci.uni-heidelberg.de Mon Mar 14 08:45:12 2005 Received: with ECARTIS (v1.0.0; list netdev); Mon, 14 Mar 2005 08:45:23 -0800 (PST) Received: from relay.uni-heidelberg.de (relay.uni-heidelberg.de [129.206.100.212]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j2EGjBNC029220 for ; Mon, 14 Mar 2005 08:45:12 -0800 Received: from hamilton1.pci.uni-heidelberg.de (hamilton1.pci.uni-heidelberg.de [129.206.21.201]) by relay.uni-heidelberg.de (8.12.10/8.12.10) with ESMTP id j2EGjlfK013187 for ; Mon, 14 Mar 2005 17:45:47 +0100 (MET) Received: from euklid.pci.uni-heidelberg.de ([129.206.21.104] helo=euklid ident=foobar) by hamilton1.pci.uni-heidelberg.de with smtp (Exim 3.35 #1 (Debian)) id 1DAsgm-0006Y0-00 for ; Mon, 14 Mar 2005 17:45:08 +0100 Received: by euklid (sSMTP sendmail emulation); Mon, 14 Mar 2005 17:45:08 +0100 From: Bernd Schubert To: netdev@oss.sgi.com Subject: network speed extremly slowed down Date: Mon, 14 Mar 2005 17:45:06 +0100 User-Agent: KMail/1.6.2 MIME-Version: 1.0 Content-Disposition: inline Content-Type: text/plain; charset="iso-8859-1" Message-Id: <200503141745.08032.bernd.schubert@pci.uni-heidelberg.de> X-Virus-Scanned: ClamAV 0.83/762/Sun Mar 13 15:35:33 2005 on oss.sgi.com X-Virus-Status: Clean Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by oss.sgi.com id j2EGjBNC029220 X-archive-position: 94 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: bernd.schubert@pci.uni-heidelberg.de Precedence: bulk X-list: netdev Content-Length: 1972 Lines: 65 Hi, until one hour ago I thought this bug affects only 3com 3c509B cards. Now we go on switching more and more systems from 2.4.X to 2.6.X and it seems that many cards work much slower with 2.6.X with 2.4.27: ========= bernd@pc-brenn bernd>nttcp -T hamilton2 Bytes Real s CPU s Real-MBit/s CPU-MBit/s Calls Real-C/s CPU-C/s l 8388608 0.72 0.02 92.7710 3355.4432 2048 2831.15 102400.0 1 8388608 0.73 0.04 92.0581 1864.3941 5783 7932.96 160661.2 with 2.6.11.3: ========== bernd@pc-brenn bernd>nttcp -T hamilton2 Bytes Real s CPU s Real-MBit/s CPU-MBit/s Calls Real-C/s CPU-C/s l 8388608 3.29 3.28 20.3957 20.4569 2048 622.43 624.3 1 8388608 3.29 0.04 20.3923 1637.0411 6143 1866.67 149851.2 Cards that show this behaviour: ======================= Yukon Gigabit Ethernet 10/100/1000Base-T Adapter (sk98lin) 3Com PCI 3c905B Cyclone 100baseTx a eth0: VIA VT6102 Rhine-II Cards that work fine with 2.4.X and 2.6.X: ============================== 3Com PCI 3c905C Tornado The drivers always claim they are using full duplex, here e.g.: eth0: network connection up using port A speed: 100 autonegotiation: yes duplex mode: full flowctrl: none irq moderation: disabled scatter-gather: enabled I already reported this issue about the 3C509B on LKML several month ago, but nobody could help. Ever since that mail I got several reports from other people having the same trouble with their cards. Initially I wanted to write a bug report following the instructions in /usr/src/linux/Documentation/networking/vortex.txt, but since this seems to be more or less a general problem I don't know how to proceed now. Thanks in advance, Bernd -- Bernd Schubert Physikalisch Chemisches Institut / Theoretische Chemie Universität Heidelberg INF 229 69120 Heidelberg e-mail: bernd.schubert@pci.uni-heidelberg.de From tgraf@suug.ch Mon Mar 14 08:54:10 2005 Received: with ECARTIS (v1.0.0; list netdev); Mon, 14 Mar 2005 08:54:15 -0800 (PST) Received: from b.mx.projectdream.org (eth0-0.arisu.projectdream.org [194.158.4.191]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j2EGs9Qc029916 for ; Mon, 14 Mar 2005 08:54:09 -0800 Received: from postel.suug.ch (postel.suug.ch [195.134.158.23]) (using TLSv1 with cipher EDH-RSA-DES-CBC3-SHA (168/168 bits)) (No client certificate requested) by b.mx.projectdream.org (Postfix) with ESMTP id 6C6428A; Mon, 14 Mar 2005 17:53:45 +0100 (CET) Received: by postel.suug.ch (Postfix, from userid 10001) id 655601C0EA; Mon, 14 Mar 2005 17:54:28 +0100 (CET) Date: Mon, 14 Mar 2005 17:54:28 +0100 From: Thomas Graf To: Hasso Tepper Cc: netdev@oss.sgi.com Subject: Re: Link detection Message-ID: <20050314165428.GR31837@postel.suug.ch> References: <200503141435.38227.hasso@estpak.ee> <20050314133216.GM31837@postel.suug.ch> <200503141641.33510.hasso@estpak.ee> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200503141641.33510.hasso@estpak.ee> X-Virus-Scanned: ClamAV 0.83/762/Sun Mar 13 15:35:33 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 95 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: tgraf@suug.ch Precedence: bulk X-list: netdev Content-Length: 1063 Lines: 17 * Hasso Tepper <200503141641.33510.hasso@estpak.ee> 2005-03-14 16:41 > > > 1) What's the proper way to detect carrier in Linux for user space > > > application like Quagga? > > > > > > True, IFF_RUNNING is from BSD, but as long as the code in > > > net/core/dev.c:dev_get_flags() is there, it gives nice clean way to get > > > carrier status from user space (AFAIK it's used in same way in > > > Solaris). Especially for applications using rtnetlink - ie. without it > > > there is no all info in the netlink message any more. If these > > > applications will receive RTM_NEWLINK, they have to poll kernel "look, > > > maybe carrier status is changed" every time? I've been looking into it more deeply. Sorry for the wrong information at first, I thought IFF_RUNNING was unused after the link state was introduced, especially after seeing IFF_RUNNING being ignored in iproue2 source. I'm fixing up the drivers still doing it wrong, after that IFF_RUNNING should be accurate and with no races. The way you're checking carrier at the moment is absolutely correct. From shemminger@osdl.org Mon Mar 14 09:21:42 2005 Received: with ECARTIS (v1.0.0; list netdev); Mon, 14 Mar 2005 09:21:47 -0800 (PST) Received: from smtp.osdl.org (fire.osdl.org [65.172.181.4]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j2EHLfQP031860 for ; Mon, 14 Mar 2005 09:21:42 -0800 Received: from shell0.pdx.osdl.net (fw.osdl.org [65.172.181.6]) by smtp.osdl.org (8.12.8/8.12.8) with ESMTP id j2EHLZqi021058 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO); Mon, 14 Mar 2005 09:21:36 -0800 Received: from dxpl.pdx.osdl.net (dxpl.pdx.osdl.net [172.20.1.103]) by shell0.pdx.osdl.net (8.13.1/8.11.6) with ESMTP id j2EHLZxw003963; Mon, 14 Mar 2005 09:21:35 -0800 Date: Mon, 14 Mar 2005 09:21:53 -0800 From: Stephen Hemminger To: Bernd Schubert Cc: netdev@oss.sgi.com Subject: Re: network speed extremly slowed down Message-ID: <20050314092153.79ae93f1@dxpl.pdx.osdl.net> In-Reply-To: <200503141745.08032.bernd.schubert@pci.uni-heidelberg.de> References: <200503141745.08032.bernd.schubert@pci.uni-heidelberg.de> Organization: Open Source Development Lab X-Mailer: Sylpheed-Claws 1.0.1 (GTK+ 1.2.10; x86_64-unknown-linux-gnu) X-Face: &@E+xe?c%:&e4D{>f1O<&U>2qwRREG5!}7R4;D<"NO^UI2mJ[eEOA2*3>(`Th.yP,VDPo9$ /`~cw![cmj~~jWe?AHY7D1S+\}5brN0k*NE?pPh_'_d>6;XGG[\KDRViCfumZT3@[ Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Received-SPF: pass (domain of shemminger@osdl.org designates 65.172.181.6 as permitted sender) X-MIMEDefang-Filter: osdl$Revision: 1.104 $ X-Scanned-By: MIMEDefang 2.36 X-Virus-Scanned: ClamAV 0.83/762/Sun Mar 13 15:35:33 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 96 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: shemminger@osdl.org Precedence: bulk X-list: netdev Content-Length: 1053 Lines: 27 On Mon, 14 Mar 2005 17:45:06 +0100 Bernd Schubert wrote: > Hi, > > until one hour ago I thought this bug affects only 3com 3c509B cards. Now we > go on switching more and more systems from 2.4.X to 2.6.X and it seems that > many cards work much slower with 2.6.X > > with 2.4.27: > ========= > bernd@pc-brenn bernd>nttcp -T hamilton2 > Bytes Real s CPU s Real-MBit/s CPU-MBit/s Calls Real-C/s CPU-C/s > l 8388608 0.72 0.02 92.7710 3355.4432 2048 2831.15 102400.0 > 1 8388608 0.73 0.04 92.0581 1864.3941 5783 7932.96 160661.2 > > with 2.6.11.3: > ========== > > bernd@pc-brenn bernd>nttcp -T hamilton2 > Bytes Real s CPU s Real-MBit/s CPU-MBit/s Calls Real-C/s CPU-C/s > l 8388608 3.29 3.28 20.3957 20.4569 2048 622.43 624.3 > 1 8388608 3.29 0.04 20.3923 1637.0411 6143 1866.67 149851.2 > What type is the other host (hamilton2) and what is the round trip delay? Is it on the same local network? From bernd.schubert@pci.uni-heidelberg.de Mon Mar 14 10:07:01 2005 Received: with ECARTIS (v1.0.0; list netdev); Mon, 14 Mar 2005 10:07:06 -0800 (PST) Received: from relay.uni-heidelberg.de (relay.uni-heidelberg.de [129.206.100.212]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j2EI70pt002190 for ; Mon, 14 Mar 2005 10:07:00 -0800 Received: from hamilton1.pci.uni-heidelberg.de (hamilton1.pci.uni-heidelberg.de [129.206.21.201]) by relay.uni-heidelberg.de (8.12.10/8.12.10) with ESMTP id j2EI7VfL009344; Mon, 14 Mar 2005 19:07:32 +0100 (MET) Received: from euklid.pci.uni-heidelberg.de ([129.206.21.104] helo=euklid ident=foobar) by hamilton1.pci.uni-heidelberg.de with smtp (Exim 3.35 #1 (Debian)) id 1DAtj8-0002lp-00; Mon, 14 Mar 2005 18:51:38 +0100 Received: by euklid (sSMTP sendmail emulation); Mon, 14 Mar 2005 18:51:38 +0100 From: Bernd Schubert To: Stephen Hemminger Subject: Re: network speed extremly slowed down Date: Mon, 14 Mar 2005 18:51:36 +0100 User-Agent: KMail/1.6.2 Cc: netdev@oss.sgi.com References: <200503141745.08032.bernd.schubert@pci.uni-heidelberg.de> <20050314092153.79ae93f1@dxpl.pdx.osdl.net> In-Reply-To: <20050314092153.79ae93f1@dxpl.pdx.osdl.net> MIME-Version: 1.0 Content-Disposition: inline Content-Type: text/plain; charset="iso-8859-1" Message-Id: <200503141851.38468.bernd.schubert@pci.uni-heidelberg.de> X-Virus-Scanned: ClamAV 0.83/762/Sun Mar 13 15:35:33 2005 on oss.sgi.com X-Virus-Status: Clean Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by oss.sgi.com id j2EI70pt002190 X-archive-position: 97 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: bernd.schubert@pci.uni-heidelberg.de Precedence: bulk X-list: netdev Content-Length: 2583 Lines: 76 On Monday 14 March 2005 18:21, Stephen Hemminger wrote: > On Mon, 14 Mar 2005 17:45:06 +0100 > > Bernd Schubert wrote: > > Hi, > > > > until one hour ago I thought this bug affects only 3com 3c509B cards. Now > > we go on switching more and more systems from 2.4.X to 2.6.X and it seems > > that many cards work much slower with 2.6.X > > > > with 2.4.27: > > ========= > > bernd@pc-brenn bernd>nttcp -T hamilton2 > > Bytes Real s CPU s Real-MBit/s CPU-MBit/s Calls Real-C/s > > CPU-C/s l 8388608 0.72 0.02 92.7710 3355.4432 2048 > > 2831.15 102400.0 1 8388608 0.73 0.04 92.0581 1864.3941 > > 5783 7932.96 160661.2 > > > > with 2.6.11.3: > > ========== > > > > bernd@pc-brenn bernd>nttcp -T hamilton2 > > Bytes Real s CPU s Real-MBit/s CPU-MBit/s Calls Real-C/s > > CPU-C/s l 8388608 3.29 3.28 20.3957 20.4569 2048 > > 622.43 624.3 1 8388608 3.29 0.04 20.3923 1637.0411 > > 6143 1866.67 149851.2 > > What type is the other host (hamilton2) and what is the round trip delay? > Is it on the same local network? Yes of course, hamilton2 is on our local network. And of course, this is completely independet of hamilton2, it can be reproduced with any local system (as long as this system has full network speed, of course ;) ). Round trip delay, e.g. the ping time? Hmm, interesting! 2.4.27: ===== bernd@wigner bernd>ping hamilton2 PING hamilton2.pci.uni-heidelberg.de (129.206.21.202): 56 data bytes 64 bytes from 129.206.21.202: icmp_seq=0 ttl=64 time=0.1 ms 64 bytes from 129.206.21.202: icmp_seq=1 ttl=64 time=0.1 ms 64 bytes from 129.206.21.202: icmp_seq=2 ttl=64 time=0.1 ms 64 bytes from 129.206.21.202: icmp_seq=3 ttl=64 time=0.1 ms 64 bytes from 129.206.21.202: icmp_seq=4 ttl=64 time=0.1 ms 64 bytes from 129.206.21.202: icmp_seq=5 ttl=64 time=0.1 ms 2.6.11.3 ====== bernd@wigner bernd>ping hamilton2 PING hamilton2.pci.uni-heidelberg.de (129.206.21.202): 56 data bytes 64 bytes from 129.206.21.202: icmp_seq=0 ttl=64 time=0.9 ms 64 bytes from 129.206.21.202: icmp_seq=1 ttl=64 time=0.4 ms 64 bytes from 129.206.21.202: icmp_seq=2 ttl=64 time=0.5 ms 64 bytes from 129.206.21.202: icmp_seq=3 ttl=64 time=0.4 ms 64 bytes from 129.206.21.202: icmp_seq=4 ttl=64 time=0.4 ms 64 bytes from 129.206.21.202: icmp_seq=5 ttl=64 time=0.4 ms Thanks, Bernd -- Bernd Schubert Physikalisch Chemisches Institut / Theoretische Chemie Universität Heidelberg INF 229 69120 Heidelberg e-mail: bernd.schubert@pci.uni-heidelberg.de From hasso@estpak.ee Mon Mar 14 10:41:36 2005 Received: with ECARTIS (v1.0.0; list netdev); Mon, 14 Mar 2005 10:41:41 -0800 (PST) Received: from arena.estpak.ee (dream.estpak.ee [194.126.115.147]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j2EIfZX7004348 for ; Mon, 14 Mar 2005 10:41:35 -0800 Received: from localhost ([127.0.0.1] helo=arena) by arena.estpak.ee with esmtp (Exim 4.44) id 1DAuVG-0000jS-2E; Mon, 14 Mar 2005 20:41:22 +0200 From: Hasso Tepper To: Thomas Graf Subject: Re: Link detection Date: Mon, 14 Mar 2005 20:41:21 +0200 User-Agent: KMail/1.7.2 Cc: netdev@oss.sgi.com References: <200503141435.38227.hasso@estpak.ee> <200503141605.02959.hasso@estpak.ee> <20050314145710.GO31837@postel.suug.ch> In-Reply-To: <20050314145710.GO31837@postel.suug.ch> Organization: Elion Enterprises Ltd. MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Disposition: inline Message-Id: <200503142041.21451.hasso@estpak.ee> X-Virus-Scanned: ClamAV 0.83/762/Sun Mar 13 15:35:33 2005 on oss.sgi.com X-Virus-Status: Clean Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by oss.sgi.com id j2EIfZX7004348 X-archive-position: 98 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: hasso@estpak.ee Precedence: bulk X-list: netdev Content-Length: 1026 Lines: 27 Thomas Graf wrote: > * Hasso Tepper <200503141605.02959.hasso@estpak.ee> 2005-03-14 16:05 > > I think that you misunderstood. I don't talk about any routes created > > by any user space applications or by user. These _must_ be untouched of > > course. I'm talking about routes _kernel_ creates if address is added > > to the interface. All other routes are not problem anyway. Even if > > their next hop points to network behind down interface, their next hop > > is unreachable and route shouldn't be used, no? > > Makes a lot more sense now. Yes, the nexthops should be marked > unreachable since the routing cache flushed upon a NETDEV_CHANGE. > > What about setting RFT_REJECT/RTN_UNREACHABLE on those routes for the > time the carrier is gone? From users' point of view I think that any solution is acceptable which prevents kernel to actually use these routers if carrier is down. And setting flags might be less expensive of course. with my best wishes, -- Hasso Tepper Elion Enterprises Ltd. WAN administrator From uucp@ganesha.gnumonks.org Mon Mar 14 11:41:46 2005 Received: with ECARTIS (v1.0.0; list netdev); Mon, 14 Mar 2005 11:41:53 -0800 (PST) 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 j2EJfjsb008364 for ; Mon, 14 Mar 2005 11:41:46 -0800 Received: from uucp by ganesha.gnumonks.org with local-bsmtp (Exim 4.34) id 1DAvRf-0007iq-IF for netdev@oss.sgi.com; Mon, 14 Mar 2005 20:41:43 +0100 Received: from laforge by obroa-skai.gnumonks.org with local (Exim 3.36 #1) id 1DAkaq-00052m-00; Mon, 14 Mar 2005 09:06:28 +0100 Date: Mon, 14 Mar 2005 09:06:28 +0100 From: Harald Welte To: Peter Bieringer Cc: Maillist netdev , David Miller Subject: Re: ip6t_LOG.c: patch killing spaces on ouput of IPv4 address on TUNNEL= Message-ID: <20050314080628.GE19298@obroa-skai.de.gnumonks.org> References: Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="hcut4fGOf7Kh6EdG" Content-Disposition: inline In-Reply-To: X-Operating-System: Linux obroa-skai.de.gnumonks.org 2.6.11-rc2-bk4gm1 X-Date: Today is Pungenday, the 73rd day of Chaos in the YOLD 3171 User-Agent: Mutt/1.5.6+20040907i X-Virus-Scanned: ClamAV 0.83/762/Sun Mar 13 15:35:33 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 99 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: laforge@gnumonks.org Precedence: bulk X-list: netdev Content-Length: 1358 Lines: 43 --hcut4fGOf7Kh6EdG Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Sat, Mar 05, 2005 at 05:01:53PM +0100, Peter Bieringer wrote: > Hi, >=20 > I'm still wondering that this was never fixed since 3 years: Because it presumably breaks existing scripts that expect it to be in the broken (speced) format. I'm not particularly for or against that change... but whatever I do, somebody will always be complaining. To make you happy and have someone else complain next time ;) Signed-off-by: Harald Welte --=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 --hcut4fGOf7Kh6EdG Content-Type: application/pgp-signature; name="signature.asc" Content-Description: Digital signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.4 (GNU/Linux) iD8DBQFCNUYEXaXGVTD0i/8RAnl8AJwN3JUwaAPT8gQzzAYMxY2gm7lGIACgq5tN 3SV5q4TW3C4v+44aVcXmNzc= =lBrC -----END PGP SIGNATURE----- --hcut4fGOf7Kh6EdG-- From pb@bieringer.de Mon Mar 14 11:52:37 2005 Received: with ECARTIS (v1.0.0; list netdev); Mon, 14 Mar 2005 11:52:45 -0800 (PST) Received: from smtp1.aerasec.de (pib.aerasec.de [195.226.187.146]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j2EJqahs009474 for ; Mon, 14 Mar 2005 11:52:36 -0800 Received: from [192.168.1.2] (ppp-82-135-3-112.mnet-online.de [82.135.3.112]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by smtp1.aerasec.de (Postfix) with ESMTP id D990F27820; Mon, 14 Mar 2005 20:52:28 +0100 (CET) Date: Mon, 14 Mar 2005 20:52:27 +0100 From: Peter Bieringer To: Harald Welte cc: Maillist netdev , David Miller Subject: Re: ip6t_LOG.c: patch killing spaces on ouput of IPv4 address on TUNNEL= Message-ID: <6D408DE92D49A118EA5D4FB6@worker.muc.bieringer.de> In-Reply-To: <20050314080628.GE19298@obroa-skai.de.gnumonks.org> References: <20050314080628.GE19298@obroa-skai.de.gnumonks.org> X-Mailer: Mulberry/3.1.6 (Linux/x86) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Disposition: inline X-Virus-Scanned: ClamAV 0.83/762/Sun Mar 13 15:35:33 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 100 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: pb@bieringer.de Precedence: bulk X-list: netdev Content-Length: 1330 Lines: 39 --On Monday, March 14, 2005 09:06:28 AM +0100 Harald Welte wrote: > On Sat, Mar 05, 2005 at 05:01:53PM +0100, Peter Bieringer wrote: >> Hi, >> >> I'm still wondering that this was never fixed since 3 years: > > Because it presumably breaks existing scripts that expect it to be in > the broken (speced) format. How many scripts are already parsing IPv6 log lines? Show me one, please. I believe I'm the only one who really looked into the logs because I saw nobody else ever claiming about the broken printout. > I'm not particularly for or against that change... but whatever I do, > somebody will always be complaining. To make you happy and have someone > else complain next time ;) I don't believe that it is a good idea to let broken log output long time in the kernel, especially in IPv6 world, where changes still ongoing in current Linux kernel. How longer you wait the more will ran (perhaps) into temporary trouble. For all the script writers, add a module option like "broken_log_lines=yes" ;-) Regards, Peter -- Dr. Peter Bieringer http://www.bieringer.de/pb/ GPG/PGP Key 0x958F422D mailto: pb at bieringer dot de Deep Space 6 Co-Founder and Core Member http://www.deepspace6.net/ > > Signed-off-by: Harald Welte From shemminger@osdl.org Mon Mar 14 11:57:46 2005 Received: with ECARTIS (v1.0.0; list netdev); Mon, 14 Mar 2005 11:57:53 -0800 (PST) Received: from smtp.osdl.org (fire.osdl.org [65.172.181.4]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j2EJvjkQ010229 for ; Mon, 14 Mar 2005 11:57:46 -0800 Received: from shell0.pdx.osdl.net (fw.osdl.org [65.172.181.6]) by smtp.osdl.org (8.12.8/8.12.8) with ESMTP id j2EJvdqi002869 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO); Mon, 14 Mar 2005 11:57:39 -0800 Received: from dxpl.pdx.osdl.net (dxpl.pdx.osdl.net [172.20.1.103]) by shell0.pdx.osdl.net (8.13.1/8.11.6) with ESMTP id j2EJvdUt012499; Mon, 14 Mar 2005 11:57:39 -0800 Date: Mon, 14 Mar 2005 11:57:57 -0800 From: Stephen Hemminger To: Bernd Schubert Cc: netdev@oss.sgi.com Subject: Re: network speed extremly slowed down Message-ID: <20050314115757.789a82d4@dxpl.pdx.osdl.net> In-Reply-To: <200503141745.08032.bernd.schubert@pci.uni-heidelberg.de> References: <200503141745.08032.bernd.schubert@pci.uni-heidelberg.de> Organization: Open Source Development Lab X-Mailer: Sylpheed-Claws 1.0.1 (GTK+ 1.2.10; x86_64-unknown-linux-gnu) X-Face: &@E+xe?c%:&e4D{>f1O<&U>2qwRREG5!}7R4;D<"NO^UI2mJ[eEOA2*3>(`Th.yP,VDPo9$ /`~cw![cmj~~jWe?AHY7D1S+\}5brN0k*NE?pPh_'_d>6;XGG[\KDRViCfumZT3@[ Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Received-SPF: pass (domain of shemminger@osdl.org designates 65.172.181.6 as permitted sender) X-MIMEDefang-Filter: osdl$Revision: 1.104 $ X-Scanned-By: MIMEDefang 2.36 X-Virus-Scanned: ClamAV 0.83/762/Sun Mar 13 15:35:33 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 101 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: shemminger@osdl.org Precedence: bulk X-list: netdev Content-Length: 1649 Lines: 48 On Mon, 14 Mar 2005 17:45:06 +0100 Bernd Schubert wrote: > Hi, > > until one hour ago I thought this bug affects only 3com 3c509B cards. Now we > go on switching more and more systems from 2.4.X to 2.6.X and it seems that > many cards work much slower with 2.6.X > > with 2.4.27: > ========= > bernd@pc-brenn bernd>nttcp -T hamilton2 > Bytes Real s CPU s Real-MBit/s CPU-MBit/s Calls Real-C/s CPU-C/s > l 8388608 0.72 0.02 92.7710 3355.4432 2048 2831.15 102400.0 > 1 8388608 0.73 0.04 92.0581 1864.3941 5783 7932.96 160661.2 > > with 2.6.11.3: > ========== > > bernd@pc-brenn bernd>nttcp -T hamilton2 > Bytes Real s CPU s Real-MBit/s CPU-MBit/s Calls Real-C/s CPU-C/s > l 8388608 3.29 3.28 20.3957 20.4569 2048 622.43 624.3 > 1 8388608 3.29 0.04 20.3923 1637.0411 6143 1866.67 149851.2 > > > Cards that show this behaviour: > ======================= > Yukon Gigabit Ethernet 10/100/1000Base-T Adapter (sk98lin) > 3Com PCI 3c905B Cyclone 100baseTx a > eth0: VIA VT6102 Rhine-II > > Cards that work fine with 2.4.X and 2.6.X: > ============================== > 3Com PCI 3c905C Tornado > > > The drivers always claim they are using full duplex, here e.g.: > > eth0: network connection up using port A > speed: 100 > autonegotiation: yes > duplex mode: full > flowctrl: none > irq moderation: disabled > scatter-gather: enabled > Are there any errors reported? Cpu time sees high perhaps the console log is filling with messages or something. From davem@davemloft.net Mon Mar 14 12:16:31 2005 Received: with ECARTIS (v1.0.0; list netdev); Mon, 14 Mar 2005 12:16:36 -0800 (PST) Received: from cheetah.davemloft.net (mail@dsl027-180-174.sfo1.dsl.speakeasy.net [216.27.180.174]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j2EKGV0d011966 for ; Mon, 14 Mar 2005 12:16:31 -0800 Received: from localhost ([127.0.0.1] helo=cheetah.davemloft.net ident=davem) by cheetah.davemloft.net with smtp (Exim 3.36 #1 (Debian)) id 1DAvy1-0002gZ-00; Mon, 14 Mar 2005 12:15:09 -0800 Date: Mon, 14 Mar 2005 12:15:09 -0800 From: "David S. Miller" To: Stephen Hemminger Cc: bernd.schubert@pci.uni-heidelberg.de, netdev@oss.sgi.com Subject: Re: network speed extremly slowed down Message-Id: <20050314121509.70dcd129.davem@davemloft.net> In-Reply-To: <20050314115757.789a82d4@dxpl.pdx.osdl.net> References: <200503141745.08032.bernd.schubert@pci.uni-heidelberg.de> <20050314115757.789a82d4@dxpl.pdx.osdl.net> X-Mailer: Sylpheed version 1.0.1 (GTK+ 1.2.10; sparc-unknown-linux-gnu) X-Face: "_;p5u5aPsO,_Vsx"^v-pEq09'CU4&Dc1$fQExov$62l60cgCc%FnIwD=.UF^a>?5'9Kn[;433QFVV9M..2eN.@4ZWPGbdi<=?[:T>y?SD(R*-3It"Vj:)"dP Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV 0.83/762/Sun Mar 13 15:35:33 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 102 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: davem@davemloft.net Precedence: bulk X-list: netdev Content-Length: 296 Lines: 9 On Mon, 14 Mar 2005 11:57:57 -0800 Stephen Hemminger wrote: > Are there any errors reported? Cpu time sees high perhaps the console log > is filling with messages or something. Or he has CONFIG_DEBUG_SLAB enabled in his kernel config. So many people do this unknowingly. From jt@hpl.hp.com Mon Mar 14 12:19:37 2005 Received: with ECARTIS (v1.0.0; list netdev); Mon, 14 Mar 2005 12:19:45 -0800 (PST) Received: from palrel13.hp.com (palrel13.hp.com [156.153.255.238]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j2EKJaMb015909 for ; Mon, 14 Mar 2005 12:19:36 -0800 Received: from tomil.hpl.hp.com (tomil.hpl.hp.com [15.0.152.100]) by palrel13.hp.com (Postfix) with ESMTP id 34F8F1C02B4A; Mon, 14 Mar 2005 12:19:36 -0800 (PST) Received: from bougret.hpl.hp.com (Debian-exim@bougret.hpl.hp.com [15.9.72.130]) by tomil.hpl.hp.com (8.9.3 (PHNE_29774)/8.9.3 HPLabs Timeshare Server) with ESMTP id MAA01398; Mon, 14 Mar 2005 12:19:41 -0800 (PST) Received: from jt by bougret.hpl.hp.com with local (Exim 4.44) id 1DAw2G-0000Nw-BG; Mon, 14 Mar 2005 12:19:32 -0800 Date: Mon, 14 Mar 2005 12:19:32 -0800 To: Jeff Garzik , Jouni Malinen , netdev@oss.sgi.com, Linux kernel mailing list Subject: [PATCH 2.6.11] WE-18 (aka WPA) Message-ID: <20050314201932.GA1467@bougret.hpl.hp.com> Reply-To: jt@hpl.hp.com Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Organisation: HP Labs Palo Alto Address: HP Labs, 1U-17, 1501 Page Mill road, Palo Alto, CA 94304, USA. E-mail: jt@hpl.hp.com User-Agent: Mutt/1.5.6+20040907i From: Jean Tourrilhes X-Virus-Scanned: ClamAV 0.83/762/Sun Mar 13 15:35:33 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 103 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: jt@hpl.hp.com Precedence: bulk X-list: netdev Content-Length: 17812 Lines: 484 Hi Jeff, This is version 18 of the Wireless Extensions. The main change is that it adds all the necessary APIs for WPA and WPA2 support. This work was entirely done by Jouni Malinen, so let's thank him for both his hard work and deep expertise on the subject ;-) This APIs obviously doesn't do much by itself and works in concert with driver support (Jouni already sent you the HostAP changes) and userspace (Jouni is updating wpa_supplicant). This is also orthogonal with the ongoing work on in-kernel IEEE support (but potentially useful). The patch is attached, tested with 2.6.11. Normally, I would ask you to push that directly in the kernel (99% of the patch has been on my web page for ages and it does not affect non-WPA stuff), but Jouni convinced me that it should bake a few weeks in wireless-2.6 first, so that other driver maintainers can get up to speed with it. So, would you mind pushing that in wireless-2.6 ? Thanks in advance... Jean diff -upr linux-2.6.11/include/linux/wireless.h linux-2.6.11-WE18/include/linux/wireless.h --- linux-2.6.11/include/linux/wireless.h 2004-12-24 13:35:01.000000000 -0800 +++ linux-2.6.11-WE18/include/linux/wireless.h 2005-03-12 09:53:02.000000000 -0800 @@ -1,10 +1,10 @@ /* * This file define a set of standard wireless extensions * - * Version : 17 21.6.04 + * Version : 18 12.3.05 * * Authors : Jean Tourrilhes - HPL - - * Copyright (c) 1997-2004 Jean Tourrilhes, All Rights Reserved. + * Copyright (c) 1997-2005 Jean Tourrilhes, All Rights Reserved. */ #ifndef _LINUX_WIRELESS_H @@ -82,7 +82,7 @@ * (there is some stuff that will be added in the future...) * I just plan to increment with each new version. */ -#define WIRELESS_EXT 17 +#define WIRELESS_EXT 18 /* * Changes : @@ -182,6 +182,21 @@ * - Document (struct iw_quality *)->updated, add new flags (INVALID) * - Wireless Event capability in struct iw_range * - Add support for relative TxPower (yick !) + * + * V17 to V18 (From Jouni Malinen ) + * ---------- + * - Add support for WPA/WPA2 + * - Add extended encoding configuration (SIOCSIWENCODEEXT and + * SIOCGIWENCODEEXT) + * - Add SIOCSIWGENIE/SIOCGIWGENIE + * - Add SIOCSIWMLME + * - Add SIOCSIWPMKSA + * - Add struct iw_range bit field for supported encoding capabilities + * - Add optional scan request parameters for SIOCSIWSCAN + * - Add SIOCSIWAUTH/SIOCGIWAUTH for setting authentication and WPA + * related parameters (extensible up to 4096 parameter values) + * - Add wireless events: IWEVGENIE, IWEVMICHAELMICFAILURE, + * IWEVASSOCREQIE, IWEVASSOCRESPIE, IWEVPMKIDCAND */ /**************************** CONSTANTS ****************************/ @@ -256,6 +271,30 @@ #define SIOCSIWPOWER 0x8B2C /* set Power Management settings */ #define SIOCGIWPOWER 0x8B2D /* get Power Management settings */ +/* WPA : Generic IEEE 802.11 informatiom element (e.g., for WPA/RSN/WMM). + * This ioctl uses struct iw_point and data buffer that includes IE id and len + * fields. More than one IE may be included in the request. Setting the generic + * IE to empty buffer (len=0) removes the generic IE from the driver. Drivers + * are allowed to generate their own WPA/RSN IEs, but in these cases, drivers + * are required to report the used IE as a wireless event, e.g., when + * associating with an AP. */ +#define SIOCSIWGENIE 0x8B30 /* set generic IE */ +#define SIOCGIWGENIE 0x8B31 /* get generic IE */ + +/* WPA : IEEE 802.11 MLME requests */ +#define SIOCSIWMLME 0x8B16 /* request MLME operation; uses + * struct iw_mlme */ +/* WPA : Authentication mode parameters */ +#define SIOCSIWAUTH 0x8B32 /* set authentication mode params */ +#define SIOCGIWAUTH 0x8B33 /* get authentication mode params */ + +/* WPA : Extended version of encoding configuration */ +#define SIOCSIWENCODEEXT 0x8B34 /* set encoding token & mode */ +#define SIOCGIWENCODEEXT 0x8B35 /* get encoding token & mode */ + +/* WPA2 : PMKSA cache management */ +#define SIOCSIWPMKSA 0x8B36 /* PMKSA cache operation */ + /* -------------------- DEV PRIVATE IOCTL LIST -------------------- */ /* These 32 ioctl are wireless device private, for 16 commands. @@ -297,6 +336,34 @@ #define IWEVCUSTOM 0x8C02 /* Driver specific ascii string */ #define IWEVREGISTERED 0x8C03 /* Discovered a new node (AP mode) */ #define IWEVEXPIRED 0x8C04 /* Expired a node (AP mode) */ +#define IWEVGENIE 0x8C05 /* Generic IE (WPA, RSN, WMM, ..) + * (scan results); This includes id and + * length fields. One IWEVGENIE may + * contain more than one IE. Scan + * results may contain one or more + * IWEVGENIE events. */ +#define IWEVMICHAELMICFAILURE 0x8C06 /* Michael MIC failure + * (struct iw_michaelmicfailure) + */ +#define IWEVASSOCREQIE 0x8C07 /* IEs used in (Re)Association Request. + * The data includes id and length + * fields and may contain more than one + * IE. This event is required in + * Managed mode if the driver + * generates its own WPA/RSN IE. This + * should be sent just before + * IWEVREGISTERED event for the + * association. */ +#define IWEVASSOCRESPIE 0x8C08 /* IEs used in (Re)Association + * Response. The data includes id and + * length fields and may contain more + * than one IE. This may be sent + * between IWEVASSOCREQIE and + * IWEVREGISTERED events for the + * association. */ +#define IWEVPMKIDCAND 0x8C09 /* PMKID candidate for RSN + * pre-authentication + * (struct iw_pmkid_cand) */ #define IWEVFIRST 0x8C00 @@ -432,12 +499,94 @@ #define IW_SCAN_THIS_MODE 0x0020 /* Scan only this Mode */ #define IW_SCAN_ALL_RATE 0x0040 /* Scan all Bit-Rates */ #define IW_SCAN_THIS_RATE 0x0080 /* Scan only this Bit-Rate */ +/* struct iw_scan_req scan_type */ +#define IW_SCAN_TYPE_ACTIVE 0 +#define IW_SCAN_TYPE_PASSIVE 1 /* Maximum size of returned data */ #define IW_SCAN_MAX_DATA 4096 /* In bytes */ /* Max number of char in custom event - use multiple of them if needed */ #define IW_CUSTOM_MAX 256 /* In bytes */ +/* Generic information element */ +#define IW_GENERIC_IE_MAX 1024 + +/* MLME requests (SIOCSIWMLME / struct iw_mlme) */ +#define IW_MLME_DEAUTH 0 +#define IW_MLME_DISASSOC 1 + +/* SIOCSIWAUTH/SIOCGIWAUTH struct iw_param flags */ +#define IW_AUTH_INDEX 0x0FFF +#define IW_AUTH_FLAGS 0xF000 +/* SIOCSIWAUTH/SIOCGIWAUTH parameters (0 .. 4095) + * (IW_AUTH_INDEX mask in struct iw_param flags; this is the index of the + * parameter that is being set/get to; value will be read/written to + * struct iw_param value field) */ +#define IW_AUTH_WPA_VERSION 0 +#define IW_AUTH_CIPHER_PAIRWISE 1 +#define IW_AUTH_CIPHER_GROUP 2 +#define IW_AUTH_KEY_MGMT 3 +#define IW_AUTH_TKIP_COUNTERMEASURES 4 +#define IW_AUTH_DROP_UNENCRYPTED 5 +#define IW_AUTH_80211_AUTH_ALG 6 +#define IW_AUTH_WPA_ENABLED 7 +#define IW_AUTH_RX_UNENCRYPTED_EAPOL 8 +#define IW_AUTH_ROAMING_CONTROL 9 +#define IW_AUTH_PRIVACY_INVOKED 10 + +/* IW_AUTH_WPA_VERSION values (bit field) */ +#define IW_AUTH_WPA_VERSION_DISABLED 0x00000001 +#define IW_AUTH_WPA_VERSION_WPA 0x00000002 +#define IW_AUTH_WPA_VERSION_WPA2 0x00000004 + +/* IW_AUTH_PAIRWISE_CIPHER and IW_AUTH_GROUP_CIPHER values (bit field) */ +#define IW_AUTH_CIPHER_NONE 0x00000001 +#define IW_AUTH_CIPHER_WEP40 0x00000002 +#define IW_AUTH_CIPHER_TKIP 0x00000004 +#define IW_AUTH_CIPHER_CCMP 0x00000008 +#define IW_AUTH_CIPHER_WEP104 0x00000010 + +/* IW_AUTH_KEY_MGMT values (bit field) */ +#define IW_AUTH_KEY_MGMT_802_1X 1 +#define IW_AUTH_KEY_MGMT_PSK 2 + +/* IW_AUTH_80211_AUTH_ALG values (bit field) */ +#define IW_AUTH_ALG_OPEN_SYSTEM 0x00000001 +#define IW_AUTH_ALG_SHARED_KEY 0x00000002 +#define IW_AUTH_ALG_LEAP 0x00000004 + +/* IW_AUTH_ROAMING_CONTROL values */ +#define IW_AUTH_ROAMING_ENABLE 0 /* driver/firmware based roaming */ +#define IW_AUTH_ROAMING_DISABLE 1 /* user space program used for roaming + * control */ + +/* SIOCSIWENCODEEXT definitions */ +#define IW_ENCODE_SEQ_MAX_SIZE 8 +/* struct iw_encode_ext ->alg */ +#define IW_ENCODE_ALG_NONE 0 +#define IW_ENCODE_ALG_WEP 1 +#define IW_ENCODE_ALG_TKIP 2 +#define IW_ENCODE_ALG_CCMP 3 +/* struct iw_encode_ext ->ext_flags */ +#define IW_ENCODE_EXT_TX_SEQ_VALID 0x00000001 +#define IW_ENCODE_EXT_RX_SEQ_VALID 0x00000002 +#define IW_ENCODE_EXT_GROUP_KEY 0x00000004 +#define IW_ENCODE_EXT_SET_TX_KEY 0x00000008 + +/* IWEVMICHAELMICFAILURE : struct iw_michaelmicfailure ->flags */ +#define IW_MICFAILURE_KEY_ID 0x00000003 /* Key ID 0..3 */ +#define IW_MICFAILURE_GROUP 0x00000004 +#define IW_MICFAILURE_PAIRWISE 0x00000008 +#define IW_MICFAILURE_STAKEY 0x00000010 +#define IW_MICFAILURE_COUNT 0x00000060 /* 1 or 2 (0 = count not supported) + */ + +/* Bit field values for enc_capa in struct iw_range */ +#define IW_ENC_CAPA_WPA 0x00000001 +#define IW_ENC_CAPA_WPA2 0x00000002 +#define IW_ENC_CAPA_CIPHER_TKIP 0x00000004 +#define IW_ENC_CAPA_CIPHER_CCMP 0x00000008 + /* Event capability macros - in (struct iw_range *)->event_capa * Because we have more than 32 possible events, we use an array of * 32 bit bitmasks. Note : 32 bits = 0x20 = 2^5. */ @@ -546,6 +695,132 @@ struct iw_thrspy struct iw_quality high; /* High threshold */ }; +/* + * Optional data for scan request + * + * Note: these optional parameters are controlling parameters for the + * scanning behavior, these do not apply to getting scan results + * (SIOCGIWSCAN). Drivers are expected to keep a local BSS table and + * provide a merged results with all BSSes even if the previous scan + * request limited scanning to a subset, e.g., by specifying an SSID. + * Especially, scan results are required to include an entry for the + * current BSS if the driver is in Managed mode and associated with an AP. + */ +struct iw_scan_req +{ + __u8 scan_type; /* IW_SCAN_TYPE_{ACTIVE,PASSIVE} */ + __u8 essid_len; + __u8 num_channels; /* num entries in channel_list; + * 0 = scan all allowed channels */ + __u8 flags; /* reserved as padding; use zero, this may + * be used in the future for adding flags + * to request different scan behavior */ + struct sockaddr bssid; /* ff:ff:ff:ff:ff:ff for broadcast BSSID or + * individual address of a specific BSS */ + + /* + * Use this ESSID if IW_SCAN_THIS_ESSID flag is used instead of using + * the current ESSID. This allows scan requests for specific ESSID + * without having to change the current ESSID and potentially breaking + * the current association. + */ + __u8 essid[IW_ESSID_MAX_SIZE]; + + /* + * Optional parameters for changing the default scanning behavior. + * These are based on the MLME-SCAN.request from IEEE Std 802.11. + * TU is 1.024 ms. If these are set to 0, driver is expected to use + * reasonable default values. min_channel_time defines the time that + * will be used to wait for the first reply on each channel. If no + * replies are received, next channel will be scanned after this. If + * replies are received, total time waited on the channel is defined by + * max_channel_time. + */ + __u32 min_channel_time; /* in TU */ + __u32 max_channel_time; /* in TU */ + + struct iw_freq channel_list[IW_MAX_FREQUENCIES]; +}; + +/* ------------------------- WPA SUPPORT ------------------------- */ + +/* + * Extended data structure for get/set encoding (this is used with + * SIOCSIWENCODEEXT/SIOCGIWENCODEEXT. struct iw_point and IW_ENCODE_* + * flags are used in the same way as with SIOCSIWENCODE/SIOCGIWENCODE and + * only the data contents changes (key data -> this structure, including + * key data). + * + * If the new key is the first group key, it will be set as the default + * TX key. Otherwise, default TX key index is only changed if + * IW_ENCODE_EXT_SET_TX_KEY flag is set. + * + * Key will be changed with SIOCSIWENCODEEXT in all cases except for + * special "change TX key index" operation which is indicated by setting + * key_len = 0 and ext_flags |= IW_ENCODE_EXT_SET_TX_KEY. + * + * tx_seq/rx_seq are only used when respective + * IW_ENCODE_EXT_{TX,RX}_SEQ_VALID flag is set in ext_flags. Normal + * TKIP/CCMP operation is to set RX seq with SIOCSIWENCODEEXT and start + * TX seq from zero whenever key is changed. SIOCGIWENCODEEXT is normally + * used only by an Authenticator (AP or an IBSS station) to get the + * current TX sequence number. Using TX_SEQ_VALID for SIOCSIWENCODEEXT and + * RX_SEQ_VALID for SIOCGIWENCODEEXT are optional, but can be useful for + * debugging/testing. + */ +struct iw_encode_ext +{ + __u32 ext_flags; /* IW_ENCODE_EXT_* */ + __u8 tx_seq[IW_ENCODE_SEQ_MAX_SIZE]; /* LSB first */ + __u8 rx_seq[IW_ENCODE_SEQ_MAX_SIZE]; /* LSB first */ + struct sockaddr addr; /* ff:ff:ff:ff:ff:ff for broadcast/multicast + * (group) keys or unicast address for + * individual keys */ + __u16 alg; /* IW_ENCODE_ALG_* */ + __u16 key_len; + __u8 key[0]; +}; + +/* SIOCSIWMLME data */ +struct iw_mlme +{ + __u16 cmd; /* IW_MLME_* */ + __u16 reason_code; + struct sockaddr addr; +}; + +/* SIOCSIWPMKSA data */ +#define IW_PMKSA_ADD 1 +#define IW_PMKSA_REMOVE 2 +#define IW_PMKSA_FLUSH 3 + +#define IW_PMKID_LEN 16 + +struct iw_pmksa +{ + __u32 cmd; /* IW_PMKSA_* */ + struct sockaddr bssid; + __u8 pmkid[IW_PMKID_LEN]; +}; + +/* IWEVMICHAELMICFAILURE data */ +struct iw_michaelmicfailure +{ + __u32 flags; + struct sockaddr src_addr; + __u8 tsc[IW_ENCODE_SEQ_MAX_SIZE]; /* LSB first */ +}; + +/* IWEVPMKIDCAND data */ +#define IW_PMKID_CAND_PREAUTH 0x00000001 /* RNS pre-authentication enabled */ +struct iw_pmkid_cand +{ + __u32 flags; /* IW_PMKID_CAND_* */ + __u32 index; /* the smaller the index, the higher the + * priority */ + struct sockaddr bssid; +}; + /* ------------------------ WIRELESS STATS ------------------------ */ /* * Wireless statistics (used for /proc/net/wireless) @@ -725,6 +1000,8 @@ struct iw_range struct iw_freq freq[IW_MAX_FREQUENCIES]; /* list */ /* Note : this frequency list doesn't need to fit channel numbers, * because each entry contain its channel index */ + + __u32 enc_capa; /* IW_ENC_CAPA_* bit field */ }; /* diff -upr linux-2.6.11/net/core/wireless.c linux-2.6.11-WE18/net/core/wireless.c --- linux-2.6.11/net/core/wireless.c 2005-03-04 15:55:29.000000000 -0800 +++ linux-2.6.11-WE18/net/core/wireless.c 2005-03-12 09:11:24.000000000 -0800 @@ -2,7 +2,7 @@ * This file implement the Wireless Extensions APIs. * * Authors : Jean Tourrilhes - HPL - - * Copyright (c) 1997-2004 Jean Tourrilhes, All Rights Reserved. + * Copyright (c) 1997-2005 Jean Tourrilhes, All Rights Reserved. * * (As all part of the Linux kernel, this file is GPL) */ @@ -187,6 +187,12 @@ static const struct iw_ioctl_description .header_type = IW_HEADER_TYPE_ADDR, .flags = IW_DESCR_FLAG_DUMP, }, + [SIOCSIWMLME - SIOCIWFIRST] = { + .header_type = IW_HEADER_TYPE_POINT, + .token_size = 1, + .min_tokens = sizeof(struct iw_mlme), + .max_tokens = sizeof(struct iw_mlme), + }, [SIOCGIWAPLIST - SIOCIWFIRST] = { .header_type = IW_HEADER_TYPE_POINT, .token_size = sizeof(struct sockaddr) + @@ -195,7 +201,10 @@ static const struct iw_ioctl_description .flags = IW_DESCR_FLAG_NOMAX, }, [SIOCSIWSCAN - SIOCIWFIRST] = { - .header_type = IW_HEADER_TYPE_PARAM, + .header_type = IW_HEADER_TYPE_POINT, + .token_size = 1, + .min_tokens = 0, + .max_tokens = sizeof(struct iw_scan_req), }, [SIOCGIWSCAN - SIOCIWFIRST] = { .header_type = IW_HEADER_TYPE_POINT, @@ -273,6 +282,42 @@ static const struct iw_ioctl_description [SIOCGIWPOWER - SIOCIWFIRST] = { .header_type = IW_HEADER_TYPE_PARAM, }, + [SIOCSIWGENIE - SIOCIWFIRST] = { + .header_type = IW_HEADER_TYPE_POINT, + .token_size = 1, + .max_tokens = IW_GENERIC_IE_MAX, + }, + [SIOCGIWGENIE - SIOCIWFIRST] = { + .header_type = IW_HEADER_TYPE_POINT, + .token_size = 1, + .max_tokens = IW_GENERIC_IE_MAX, + }, + [SIOCSIWAUTH - SIOCIWFIRST] = { + .header_type = IW_HEADER_TYPE_PARAM, + }, + [SIOCGIWAUTH - SIOCIWFIRST] = { + .header_type = IW_HEADER_TYPE_PARAM, + }, + [SIOCSIWENCODEEXT - SIOCIWFIRST] = { + .header_type = IW_HEADER_TYPE_POINT, + .token_size = 1, + .min_tokens = sizeof(struct iw_encode_ext), + .max_tokens = sizeof(struct iw_encode_ext) + + IW_ENCODING_TOKEN_MAX, + }, + [SIOCGIWENCODEEXT - SIOCIWFIRST] = { + .header_type = IW_HEADER_TYPE_POINT, + .token_size = 1, + .min_tokens = sizeof(struct iw_encode_ext), + .max_tokens = sizeof(struct iw_encode_ext) + + IW_ENCODING_TOKEN_MAX, + }, + [SIOCSIWPMKSA - SIOCIWFIRST] = { + .header_type = IW_HEADER_TYPE_POINT, + .token_size = 1, + .min_tokens = sizeof(struct iw_pmksa), + .max_tokens = sizeof(struct iw_pmksa), + }, }; static const int standard_ioctl_num = (sizeof(standard_ioctl) / sizeof(struct iw_ioctl_description)); @@ -299,6 +344,31 @@ static const struct iw_ioctl_description [IWEVEXPIRED - IWEVFIRST] = { .header_type = IW_HEADER_TYPE_ADDR, }, + [IWEVGENIE - IWEVFIRST] = { + .header_type = IW_HEADER_TYPE_POINT, + .token_size = 1, + .max_tokens = IW_GENERIC_IE_MAX, + }, + [IWEVMICHAELMICFAILURE - IWEVFIRST] = { + .header_type = IW_HEADER_TYPE_POINT, + .token_size = 1, + .max_tokens = sizeof(struct iw_michaelmicfailure), + }, + [IWEVASSOCREQIE - IWEVFIRST] = { + .header_type = IW_HEADER_TYPE_POINT, + .token_size = 1, + .max_tokens = IW_GENERIC_IE_MAX, + }, + [IWEVASSOCRESPIE - IWEVFIRST] = { + .header_type = IW_HEADER_TYPE_POINT, + .token_size = 1, + .max_tokens = IW_GENERIC_IE_MAX, + }, + [IWEVPMKIDCAND - IWEVFIRST] = { + .header_type = IW_HEADER_TYPE_POINT, + .token_size = 1, + .max_tokens = sizeof(struct iw_pmkid_cand), + }, }; static const int standard_event_num = (sizeof(standard_event) / sizeof(struct iw_ioctl_description)); From alex@neterion.com Mon Mar 14 12:23:32 2005 Received: with ECARTIS (v1.0.0; list netdev); Mon, 14 Mar 2005 12:23:40 -0800 (PST) Received: from ns1.s2io.com (ns1.s2io.com [142.46.200.198]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j2EKNW7G016569 for ; Mon, 14 Mar 2005 12:23:32 -0800 Received: from guinness.s2io.com (sentry.s2io.com [142.46.200.199]) by ns1.s2io.com (8.12.10/8.12.10) with ESMTP id j2EKNOuN011110; Mon, 14 Mar 2005 15:23:24 -0500 (EST) Received: from aaizmanlt ([10.16.16.166]) by guinness.s2io.com (8.12.6/8.12.6) with ESMTP id j2EKNMDD027705; Mon, 14 Mar 2005 15:23:23 -0500 (EST) Message-Id: <200503142023.j2EKNMDD027705@guinness.s2io.com> Reply-To: From: "Alex Aizman" To: Cc: , "'Jeff Garzik'" Subject: [ANNOUNCE] Experimental Driver for Neterion/S2io 10GbE Adapters Date: Mon, 14 Mar 2005 12:22:51 -0800 Organization: neterion MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook, Build 11.0.5510 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 In-Reply-To: <1109005880.1076.77.camel@jzny.localdomain> Thread-Index: AcUYOF5YcNsGmgBPTJiQJO18SqqLIQQkWekg X-Scanned-By: MIMEDefang 2.34 X-Virus-Scanned: ClamAV 0.83/762/Sun Mar 13 15:35:33 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 104 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: alex@neterion.com Precedence: bulk X-list: netdev Content-Length: 5935 Lines: 161 This is to announce "xge", an experimental 10GbE driver for Neterion, Inc (formerly S2io, Inc) family of adapters. Motivation ========== The production ("s2io") driver for Xframe-I adapter was accepted in the kernel starting 2.6.5, and is currently a part of the 2.6 kernel. Why to re-write an accepted and well-performing production quality driver? As Neterion 10GbE ASICs evolve and add more stateless and state-aware TCP assists, we felt that a forward-looking re-design is warranted. Going forward this experimental driver will hopefully serve as a vehicle to support ASIC features like Large Receive Offload and UDP LSO (based upon header splitting, multiple logical Tx/Rx paths, MSI/MSI-X usage, etc.) - both in the driver and in the kernel. Hopefully, some of these TCP assists will eventually get supported in a de-facto standard way, like checksum offload and TSO are supported today. At present, the experimental driver is running on the shipping hardware as well. Over the last five months it was tested to the same extend as the "s2io" driver in the kernel, and in some scenarios offers performance advantage. When reviewed by the community, we would advocate that "xge" driver is included in the kernel as an addition, and going forward as a replacement for the "s2io" driver. HAL-based ========= Most Neterion drivers are HAL (Hardware Abstraction Layer) based. This is always a curse and blessing; in our experience this was the latter by a big margin. While the current "s2io" driver in the kernel doesn't share HAL code with other driver, the "xge" driver is HAL-based. For these reviewers who consider this a minus, we hope you will find the HAL code in full compliance with Linux guidelines (in fact, it was written by our Linux team). Performance-wise, there was no negative impact discovered either. Testing-wise, this HAL has undergone numerous stress, functional, and performance tests "under" different drivers on a variety of platforms. Since the HAL is a "common code", you will find a GPL license on Linux-only files and a GPL license plus exception on the HAL code. Going forward, we don't expect community developers to do extensive modifications to the HAL files - but if it happens, we would appreciate the changes to be released under the same "GPL plus exception" terms. You are not required to do so of course, but keeping the default terms on the hw-specific part of the code will help us to maintain consistency of the code - for the common benefit. What about maintenance, support and documentation? ================================================== Neterion Linux team is committed to maintain the driver going forward; please post any requests/suggestions on the list and to alex@neterion.com For developers who intend to work with the hw-dependent code, we will make available both HAL API guide and ASIC programming manual; please send requests to leonid@neterion.com If there is enough interest in modifying the hw-dependent code, please send the request and we will consider making ASIC programming manual available as well; please send request to leonid@neterion.com What about 10GbE setup? ====================== If there will be enough interest in working with the driver; we will put in place a back-to-back 10GbE setup for remote access, available 24 hrs a day on a "first come, first served" self-scheduled basis; we realize that 10GbE gear is still fairly expensive. Driver Status ============= The xge driver was done (code complete) by October 2004. Since then it has accumulated enough mileage in terms of stress, performance, and functional testing. The driver, although carrying the experimental status, is estimated to be very close to production. Kernels: the driver supports both 2.6 and 2.4 kernels. Platforms: AMD Opteron (TM) (64bit and 32bit), Itanium(TM) based (including SGI Altix), Xeon 32bit, and PPC(TM) based (in particular, pSeries) systems. Features: - Neterion Xframe-I and Xframe-II adapters (the latter adapters were just recently announced by Neterion, end-user availability is still TBD); - full checksum offload; - jumbo frames (up to 9600 bytes); - there is no limit on a number, size, and alignment of Tx fragments; - broadcast, multicast, and promiscuous mode; - TCP Send Offload (TSO); - ethtool (fully); - multiple Xframe I and/or Xframe II adapters present in the host; - multiple receive and transmit rings; - MSI and MSI-X (the latter Xframe-II only); - L2, L3, and L4 header splitting; - Receive Traffic Hashing (Xframe-II only); - NAPI. The driver also contains a number of optimization features. Performance numbers for Xframe-I 10GbE adapter: 7.6 Gbps transmit and 7.6 Gbps receive (jumbo, 2.4GHz dual Opteron), limited by PCI-X 133 bus. Note that Xframe-II adapter removes the PCI-X bottleneck. For more information see the readme file: xge.txt. TODO ===== (1) Testing so far is 100% successful, but production-grade testing still remains tbd. (2) MSI. The driver was tested with a single MSI (see Documentation/MSI-HOWTO.txt). Multiple MSIs remain tbd. (3) Large Receive Offload. Unlike most of other features, the LRO retains its experimental status. It needs to be debugged and fully tested. Note that to a certain extent the "experimental" status applies also to MSI and Receive Traffic Hashing. (4) NAPI performance. 1500 MTU receive performance is marginally better with NAPI enabled. We expect to get more than "margin" out of NAPI. Download ========= Here's the FTP site to download a single gzipped patch (filename xge-v.1.1.2816-2.6.11.patch.gz, cksum 3463616385). This patch will replace the "s2io" driver with the new "xge" driver. ftp: ns1.s2io.com user: linuxsrc password: opensource Signed-off-by: Dmitry Yusupov Signed-off-by: Raghavendra Koushik Signed-off-by: Alex Aizman Regards, Neterion's team. From linville@bilbo.tuxdriver.com Mon Mar 14 12:24:12 2005 Received: with ECARTIS (v1.0.0; list netdev); Mon, 14 Mar 2005 12:24:18 -0800 (PST) Received: from ra.tuxdriver.com (ra.tuxdriver.com [24.172.12.4]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j2EKOB5C016696 for ; Mon, 14 Mar 2005 12:24:12 -0800 Received: from bilbo.tuxdriver.com (bilbo.tuxdriver.com [24.172.12.5]) by ra.tuxdriver.com (8.11.6/8.11.6) with ESMTP id j2EKHjg18151; Mon, 14 Mar 2005 15:17:45 -0500 Received: from bilbo.tuxdriver.com (localhost.localdomain [127.0.0.1]) by bilbo.tuxdriver.com (8.13.1/8.13.1) with ESMTP id j2EKO2ja012415; Mon, 14 Mar 2005 15:24:03 -0500 Received: (from linville@localhost) by bilbo.tuxdriver.com (8.13.1/8.13.1/Submit) id j2EKO1ZZ012414; Mon, 14 Mar 2005 15:24:01 -0500 Date: Mon, 14 Mar 2005 15:24:01 -0500 From: "John W. Linville" To: linux-kernel@vger.kernel.org Cc: netdev@oss.sgi.com, pp@netppl.fi, jgarzik@pobox.com, davem@davemloft.net Subject: [patch 2.6.11] b44: allocate tx bounce bufs as needed Message-ID: <20050314202355.GA12298@tuxdriver.com> Mail-Followup-To: linux-kernel@vger.kernel.org, netdev@oss.sgi.com, pp@netppl.fi, jgarzik@pobox.com, davem@davemloft.net Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit User-Agent: Mutt/1.4.1i X-Virus-Scanned: ClamAV 0.83/762/Sun Mar 13 15:35:33 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 105 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: linville@tuxdriver.com Precedence: bulk X-list: netdev Content-Length: 4019 Lines: 119 Allocate tx bounce buffers one at a time as needed, rather than in a single allocation. This limits usage of the GFP_DMA memory pool. Acked-by: Pekka Pietikäinen Signed-off-by: John W. Linville --- The b44 hardware has a DMA mask that only covers 1GB. On x86, a DMA mask <4GB results in allocations using GFP_DMA. The GFP_DMA pool (16MB) gets exhausted very quickly in some configurations. The b44 driver has been pre-allocating bounce buffers in a single large (~750k) contiguous block. On boxes w/ limited GFP_DMA memory, this allocation can fail. Such failure results in the driver being unable to load and function. The solution here is to check each tx skb against the DMA mask. If it is outside the allowable range, a single buffer is allocated from the GFP_DMA range and discarded after the tx completes. This behaviour mimics what is done for bounce buffers on the rx side. The pre-allocation of tx bounce buffers is, of course, removed. drivers/net/b44.c | 36 +++++++++++++++++++++--------------- drivers/net/b44.h | 3 +-- 2 files changed, 22 insertions(+), 17 deletions(-) --- linux-2.6.11/drivers/net/b44.h.orig 2005-03-14 14:22:55.640858983 -0500 +++ linux-2.6.11/drivers/net/b44.h 2005-03-14 14:25:00.972718022 -0500 @@ -383,7 +383,6 @@ struct b44 { struct ring_info *rx_buffers; struct ring_info *tx_buffers; - unsigned char *tx_bufs; u32 dma_offset; u32 flags; @@ -415,7 +414,7 @@ struct b44 { struct pci_dev *pdev; struct net_device *dev; - dma_addr_t rx_ring_dma, tx_ring_dma,tx_bufs_dma; + dma_addr_t rx_ring_dma, tx_ring_dma; u32 rx_pending; u32 tx_pending; --- linux-2.6.11/drivers/net/b44.c.orig 2005-03-14 14:22:17.000000000 -0500 +++ linux-2.6.11/drivers/net/b44.c 2005-03-14 14:25:00.991715423 -0500 @@ -907,6 +907,7 @@ static void b44_tx_timeout(struct net_de static int b44_start_xmit(struct sk_buff *skb, struct net_device *dev) { struct b44 *bp = netdev_priv(dev); + struct sk_buff *bounce_skb; dma_addr_t mapping; u32 len, entry, ctrl; @@ -922,15 +923,31 @@ static int b44_start_xmit(struct sk_buff return 1; } - entry = bp->tx_prod; mapping = pci_map_single(bp->pdev, skb->data, len, PCI_DMA_TODEVICE); if(mapping+len > B44_DMA_MASK) { /* Chip can't handle DMA to/from >1GB, use bounce buffer */ - pci_unmap_single(bp->pdev, mapping, len,PCI_DMA_TODEVICE); - memcpy(bp->tx_bufs+entry*TX_PKT_BUF_SZ,skb->data,skb->len); - mapping = pci_map_single(bp->pdev, bp->tx_bufs+entry*TX_PKT_BUF_SZ, len, PCI_DMA_TODEVICE); + pci_unmap_single(bp->pdev, mapping, len, PCI_DMA_TODEVICE); + + bounce_skb = __dev_alloc_skb(TX_PKT_BUF_SZ, + GFP_ATOMIC|GFP_DMA); + if (!bounce_skb) + return NETDEV_TX_BUSY; + + mapping = pci_map_single(bp->pdev, bounce_skb->data, + len, PCI_DMA_TODEVICE); + if(mapping+len > B44_DMA_MASK) { + pci_unmap_single(bp->pdev, mapping, + len, PCI_DMA_TODEVICE); + dev_kfree_skb_any(bounce_skb); + return NETDEV_TX_BUSY; + } + + memcpy(skb_put(bounce_skb, len), skb->data, skb->len); + dev_kfree_skb_any(skb); + skb = bounce_skb; } + entry = bp->tx_prod; bp->tx_buffers[entry].skb = skb; pci_unmap_addr_set(&bp->tx_buffers[entry], mapping, mapping); @@ -1077,11 +1094,6 @@ static void b44_free_consistent(struct b bp->tx_ring, bp->tx_ring_dma); bp->tx_ring = NULL; } - if (bp->tx_bufs) { - pci_free_consistent(bp->pdev, B44_TX_RING_SIZE * TX_PKT_BUF_SZ, - bp->tx_bufs, bp->tx_bufs_dma); - bp->tx_bufs = NULL; - } } /* @@ -1104,12 +1116,6 @@ static int b44_alloc_consistent(struct b goto out_err; memset(bp->tx_buffers, 0, size); - size = B44_TX_RING_SIZE * TX_PKT_BUF_SZ; - bp->tx_bufs = pci_alloc_consistent(bp->pdev, size, &bp->tx_bufs_dma); - if (!bp->tx_bufs) - goto out_err; - memset(bp->tx_bufs, 0, size); - size = DMA_TABLE_BYTES; bp->rx_ring = pci_alloc_consistent(bp->pdev, size, &bp->rx_ring_dma); if (!bp->rx_ring) -- John W. Linville linville@tuxdriver.com From herbert@gondor.apana.org.au Mon Mar 14 12:33:47 2005 Received: with ECARTIS (v1.0.0; list netdev); Mon, 14 Mar 2005 12:33:54 -0800 (PST) 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 j2EKXj5q017743 for ; Mon, 14 Mar 2005 12:33:46 -0800 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 1DAwF5-00044c-00; Tue, 15 Mar 2005 07:32:47 +1100 Received: from herbert by gondolin.me.apana.org.au with local (Exim 3.36 #1 (Debian)) id 1DAwES-0003wf-00; Tue, 15 Mar 2005 07:32:08 +1100 Date: Tue, 15 Mar 2005 07:32:08 +1100 To: Patrick McHardy Cc: "David S. Miller" , Alexey Kuznetsov , James Morris , YOSHIFUJI Hideaki , netdev@oss.sgi.com Subject: Re: [3/4] [IPSEC] Add route element to xfrm_dst Message-ID: <20050314203208.GA15146@gondor.apana.org.au> References: <20050214221006.GA18415@gondor.apana.org.au> <20050214221200.GA18465@gondor.apana.org.au> <20050214221433.GB18465@gondor.apana.org.au> <42357AF0.4080205@trash.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <42357AF0.4080205@trash.net> User-Agent: Mutt/1.5.6+20040907i From: Herbert Xu X-Virus-Scanned: ClamAV 0.83/762/Sun Mar 13 15:35:33 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 106 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: herbert@gondor.apana.org.au Precedence: bulk X-list: netdev Content-Length: 1389 Lines: 43 On Mon, Mar 14, 2005 at 12:52:16PM +0100, Patrick McHardy wrote: > > >+ if (remote != fl_tunnel.fl4_dst) { > >+ fl_tunnel.fl4_src = local; > >+ fl_tunnel.fl4_dst = remote; > >+ err = xfrm_dst_lookup((struct xfrm_dst **)&rt, > >+ &fl_tunnel, AF_INET); > >+ if (err) > >+ goto error; > >+ } else > >+ dst_hold(&rt->u.dst); > > } > >+ > > dst_prev->child = &rt->u.dst; > >+ dst->path = &rt->u.dst; > >+ > >+ *dst_p = dst; > >+ dst = dst_prev; > >+ > >+ dst_prev = *dst_p; > > i = 0; > >- for (dst_prev = dst; dst_prev != &rt->u.dst; dst_prev = > >dst_prev->child) { > >+ for (; dst_prev != &rt->u.dst; dst_prev = dst_prev->child) { > > Since the tunnel dst is not necessarily the last in the bundle anymore, > we might miss to initialize some dsts, for example with ipcomp/tunnel + > esp/transport. If we have nested tunnels we'll fiddle with entries in > the routing cache. Sorry, but I don't get it :) First of all what do you mean by the tunnel dst? If you mean &rt->u.dst then as far as I can see it's still the last child in the bundle. It may also appear in ->route elements earlier on but that does not come into play in this loop. Cheers, -- Visit Openswan at http://www.openswan.org/ Email: Herbert Xu ~{PmV>HI~} Home Page: http://gondor.apana.org.au/~herbert/ PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt From davem@davemloft.net Mon Mar 14 12:39:36 2005 Received: with ECARTIS (v1.0.0; list netdev); Mon, 14 Mar 2005 12:39:41 -0800 (PST) Received: from cheetah.davemloft.net (mail@dsl027-180-174.sfo1.dsl.speakeasy.net [216.27.180.174]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j2EKdaL6018330 for ; Mon, 14 Mar 2005 12:39:36 -0800 Received: from localhost ([127.0.0.1] helo=cheetah.davemloft.net ident=davem) by cheetah.davemloft.net with smtp (Exim 3.36 #1 (Debian)) id 1DAwKN-0002nW-00; Mon, 14 Mar 2005 12:38:15 -0800 Date: Mon, 14 Mar 2005 12:38:15 -0800 From: "David S. Miller" To: Cc: netdev@oss.sgi.com, leonid@neterion.com, jgarzik@pobox.com Subject: Re: [ANNOUNCE] Experimental Driver for Neterion/S2io 10GbE Adapters Message-Id: <20050314123815.73e7ee78.davem@davemloft.net> In-Reply-To: <200503142023.j2EKNMDD027705@guinness.s2io.com> References: <1109005880.1076.77.camel@jzny.localdomain> <200503142023.j2EKNMDD027705@guinness.s2io.com> X-Mailer: Sylpheed version 1.0.1 (GTK+ 1.2.10; sparc-unknown-linux-gnu) X-Face: "_;p5u5aPsO,_Vsx"^v-pEq09'CU4&Dc1$fQExov$62l60cgCc%FnIwD=.UF^a>?5'9Kn[;433QFVV9M..2eN.@4ZWPGbdi<=?[:T>y?SD(R*-3It"Vj:)"dP Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV 0.83/762/Sun Mar 13 15:35:33 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 107 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: davem@davemloft.net Precedence: bulk X-list: netdev Content-Length: 863 Lines: 19 On Mon, 14 Mar 2005 12:22:51 -0800 "Alex Aizman" wrote: > For these reviewers who consider this a minus, we hope you will find the HAL > code in full compliance with Linux guidelines (in fact, it was written by > our Linux team). Performance-wise, there was no negative impact discovered > either. Testing-wise, this HAL has undergone numerous stress, functional, > and performance tests "under" different drivers on a variety of platforms. So you wrote a non-HAL version of this driver and compared the results? Simply comparing against the existins s2io driver does not count. If you're simply comparing against s2io, and your driver is faster than s2io is already, imagine how much faster it might be without that HAL layer. I totally reject this driver, HAL is unacceptable for in-tree drivers. We've been over this a thousand times. From leonid.grossman@neterion.com Mon Mar 14 12:54:43 2005 Received: with ECARTIS (v1.0.0; list netdev); Mon, 14 Mar 2005 12:54:48 -0800 (PST) Received: from ns1.s2io.com (ns1.s2io.com [142.46.200.198]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j2EKsgFn019862 for ; Mon, 14 Mar 2005 12:54:42 -0800 Received: from guinness.s2io.com (sentry.s2io.com [142.46.200.199]) by ns1.s2io.com (8.12.10/8.12.10) with ESMTP id j2EKs4uN011468; Mon, 14 Mar 2005 15:54:04 -0500 (EST) Received: from lgt40 ([10.16.16.75]) by guinness.s2io.com (8.12.6/8.12.6) with ESMTP id j2EKs2DD003697; Mon, 14 Mar 2005 15:54:02 -0500 (EST) Message-Id: <200503142054.j2EKs2DD003697@guinness.s2io.com> From: "Leonid Grossman" To: "'David S. Miller'" , Cc: , , Subject: RE: [ANNOUNCE] Experimental Driver for Neterion/S2io 10GbE Adapters Date: Mon, 14 Mar 2005 12:53:57 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook, Build 11.0.5510 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1409 In-Reply-To: <20050314123815.73e7ee78.davem@davemloft.net> Thread-Index: AcUo1e7UY4kCK9cPSrGnlypMdJyV+wAADPvA X-Scanned-By: MIMEDefang 2.34 X-Virus-Scanned: ClamAV 0.83/762/Sun Mar 13 15:35:33 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 108 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: leonid.grossman@neterion.com Precedence: bulk X-list: netdev Content-Length: 2184 Lines: 51 Hi David, S2io and Neterion is the same company, we just got our Company name changed recently. So, the non-HAL version of this driver is in fact "s2io" driver in the kernel - sorry we did not make it clear in the readme file. I've seen in the past layered architectures for MAC drivers that resulted in a performance hit, so this was a significant concern for me as well - for 10GbE product performance is an overwriting objective. We compared performance results of the HAL-based driver vs. monolithic approach on multiple platforms, and did not see any performance delta that could be attributed to the approach itself. In fact, in some cases this experimental driver faster - but I assume this is due to the lessons we learned not the layered approach itself; performance-wise I see it as a draw. Do you have other objections to the submission? We'd like to see if these could be addressed; going forward we see significant benefits both for S2io/Neterion (and our customers) and for community to use this driver. Regards, Leonid -----Original Message----- From: David S. Miller [mailto:davem@davemloft.net] Sent: Monday, March 14, 2005 12:38 PM To: alex@neterion.com Cc: netdev@oss.sgi.com; leonid@neterion.com; jgarzik@pobox.com Subject: Re: [ANNOUNCE] Experimental Driver for Neterion/S2io 10GbE Adapters On Mon, 14 Mar 2005 12:22:51 -0800 "Alex Aizman" wrote: > For these reviewers who consider this a minus, we hope you will find the HAL > code in full compliance with Linux guidelines (in fact, it was written by > our Linux team). Performance-wise, there was no negative impact discovered > either. Testing-wise, this HAL has undergone numerous stress, functional, > and performance tests "under" different drivers on a variety of platforms. So you wrote a non-HAL version of this driver and compared the results? Simply comparing against the existins s2io driver does not count. If you're simply comparing against s2io, and your driver is faster than s2io is already, imagine how much faster it might be without that HAL layer. I totally reject this driver, HAL is unacceptable for in-tree drivers. We've been over this a thousand times. From Bernd.Schubert@tc.pci.uni-heidelberg.de Mon Mar 14 13:16:39 2005 Received: with ECARTIS (v1.0.0; list netdev); Mon, 14 Mar 2005 13:16:45 -0800 (PST) Received: from relay.uni-heidelberg.de (relay.uni-heidelberg.de [129.206.100.212]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j2ELGcN3020854 for ; Mon, 14 Mar 2005 13:16:39 -0800 Received: from fubini.pci.uni-heidelberg.de (fubini.pci.uni-heidelberg.de [129.206.21.240]) by relay.uni-heidelberg.de (8.12.10/8.12.10) with ESMTP id j2ELH9fK014622; Mon, 14 Mar 2005 22:17:09 +0100 (MET) Received: from bernd by fubini.pci.uni-heidelberg.de with local (Exim 3.35 #1 (Debian)) id 1DAwvO-0005Ex-00; Mon, 14 Mar 2005 22:16:30 +0100 Date: Mon, 14 Mar 2005 22:16:30 +0100 To: "David S. Miller" , Stephen Hemminger , netdev@oss.sgi.com Subject: Re: network speed extremly slowed down Message-ID: <20050314211630.GA20122@fubini.pci.uni-heidelberg.de> References: <200503141745.08032.bernd.schubert@pci.uni-heidelberg.de> <20050314115757.789a82d4@dxpl.pdx.osdl.net> <20050314121509.70dcd129.davem@davemloft.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20050314121509.70dcd129.davem@davemloft.net> User-Agent: Mutt/1.3.28i From: Bernd Schubert X-Virus-Scanned: ClamAV 0.83/762/Sun Mar 13 15:35:33 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 109 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: Bernd.Schubert@tc.pci.uni-heidelberg.de Precedence: bulk X-list: netdev Content-Length: 539 Lines: 17 On Mon, Mar 14, 2005 at 12:15:09PM -0800, David S. Miller wrote: > On Mon, 14 Mar 2005 11:57:57 -0800 > Stephen Hemminger wrote: > > > Are there any errors reported? Cpu time sees high perhaps the console log > > is filling with messages or something. > > Or he has CONFIG_DEBUG_SLAB enabled in his kernel config. > So many people do this unknowingly. > No, no unusual error reports, but full debugging is enabled, so also CONFIG_DEBUG_SLAB. Recompiling now with only CONFIG_MAGIC_SYSRQ support. Thanks, Bernd From linville@bilbo.tuxdriver.com Mon Mar 14 13:25:24 2005 Received: with ECARTIS (v1.0.0; list netdev); Mon, 14 Mar 2005 13:25:29 -0800 (PST) Received: from ra.tuxdriver.com (ra.tuxdriver.com [24.172.12.4]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j2ELPN24021508 for ; Mon, 14 Mar 2005 13:25:23 -0800 Received: from bilbo.tuxdriver.com (bilbo.tuxdriver.com [24.172.12.5]) by ra.tuxdriver.com (8.11.6/8.11.6) with ESMTP id j2ELIwg18987; Mon, 14 Mar 2005 16:18:58 -0500 Received: from bilbo.tuxdriver.com (localhost.localdomain [127.0.0.1]) by bilbo.tuxdriver.com (8.13.1/8.13.1) with ESMTP id j2ELPGBd013681; Mon, 14 Mar 2005 16:25:16 -0500 Received: (from linville@localhost) by bilbo.tuxdriver.com (8.13.1/8.13.1/Submit) id j2ELPGGx013680; Mon, 14 Mar 2005 16:25:16 -0500 Date: Mon, 14 Mar 2005 16:25:15 -0500 From: "John W. Linville" To: linux-kernel@vger.kernel.org Cc: netdev@oss.sgi.com, jgarzik@pobox.com, cramerj@intel.com, john.ronciak@intel.com, ganesh.venkatesan@intel.com Subject: [patch 2.6.11] e1000: avoid sleeping in watchdog timer context Message-ID: <20050314212510.GA12573@tuxdriver.com> Mail-Followup-To: linux-kernel@vger.kernel.org, netdev@oss.sgi.com, jgarzik@pobox.com, cramerj@intel.com, john.ronciak@intel.com, ganesh.venkatesan@intel.com Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.4.1i X-Virus-Scanned: ClamAV 0.83/762/Sun Mar 13 15:35:33 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 110 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: linville@tuxdriver.com Precedence: bulk X-list: netdev Content-Length: 2997 Lines: 78 Move bulk of e1000_watchdog to a workqueue to make it safe to call functions which can sleep. Signed-off-by: John W. Linville --- The e1000 driver uses a timer to invoke e1000_watchdog(). e1000_watchdog() calls e1000_check_for_link() which can call e1000_config_dsp_after_link_change(). This in turn can call msec_delay(). msec_delay() is, of course, simply a wrapper for msleep(). Since a timer does not have a process context, sleeping is impossible. Attempting to do so causes a crash. The fix is to move the body of e1000_watchdog() to the newly defined e1000_watchdog_task(). This is invoked via the workqueue interface from the new version of e1000_watchdog(). drivers/net/e1000/e1000.h | 1 + drivers/net/e1000/e1000_main.c | 15 +++++++++++++-- 2 files changed, 14 insertions(+), 2 deletions(-) --- linux-2.6.11/drivers/net/e1000/e1000.h.orig 2005-03-14 16:06:53.000000000 -0500 +++ linux-2.6.11/drivers/net/e1000/e1000.h 2005-03-14 16:16:37.436364543 -0500 @@ -203,6 +203,7 @@ struct e1000_adapter { spinlock_t stats_lock; atomic_t irq_sem; struct work_struct tx_timeout_task; + struct work_struct watchdog_task; uint8_t fc_autoneg; struct timer_list blink_timer; --- linux-2.6.11/drivers/net/e1000/e1000_main.c.orig 2005-03-14 16:09:42.991007873 -0500 +++ linux-2.6.11/drivers/net/e1000/e1000_main.c 2005-03-14 16:16:37.438364260 -0500 @@ -142,6 +142,7 @@ static void e1000_clean_rx_ring(struct e static void e1000_set_multi(struct net_device *netdev); static void e1000_update_phy_info(unsigned long data); static void e1000_watchdog(unsigned long data); +static void e1000_watchdog_task(struct e1000_adapter *adapter); static void e1000_82547_tx_fifo_stall(unsigned long data); static int e1000_xmit_frame(struct sk_buff *skb, struct net_device *netdev); static struct net_device_stats * e1000_get_stats(struct net_device *netdev); @@ -574,6 +575,9 @@ e1000_probe(struct pci_dev *pdev, adapter->watchdog_timer.function = &e1000_watchdog; adapter->watchdog_timer.data = (unsigned long) adapter; + INIT_WORK(&adapter->watchdog_task, + (void (*)(void *))e1000_watchdog_task, adapter); + init_timer(&adapter->phy_info_timer); adapter->phy_info_timer.function = &e1000_update_phy_info; adapter->phy_info_timer.data = (unsigned long) adapter; @@ -1529,13 +1533,20 @@ e1000_82547_tx_fifo_stall(unsigned long /** * e1000_watchdog - Timer Call-back - * @data: pointer to netdev cast into an unsigned long + * @data: pointer to adapter cast into an unsigned long **/ - static void e1000_watchdog(unsigned long data) { struct e1000_adapter *adapter = (struct e1000_adapter *) data; + + /* Do the rest outside of interrupt context */ + schedule_work(&adapter->watchdog_task); +} + +static void +e1000_watchdog_task(struct e1000_adapter *adapter) +{ struct net_device *netdev = adapter->netdev; struct e1000_desc_ring *txdr = &adapter->tx_ring; uint32_t link; -- John W. Linville linville@tuxdriver.com From cliffw@osdl.org Mon Mar 14 13:34:15 2005 Received: with ECARTIS (v1.0.0; list netdev); Mon, 14 Mar 2005 13:34:19 -0800 (PST) Received: from smtp.osdl.org (fire.osdl.org [65.172.181.4]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j2ELYEr8022216 for ; Mon, 14 Mar 2005 13:34:14 -0800 Received: from es175 (fw.osdl.org [65.172.181.6]) (authenticated bits=0) by smtp.osdl.org (8.12.8/8.12.8) with ESMTP id j2ELY5qi011760 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO); Mon, 14 Mar 2005 13:34:05 -0800 Date: Mon, 14 Mar 2005 13:34:04 -0800 From: cliff white To: Robert.Olsson@data.slu.se, netdev@oss.sgi.com Subject: Constant errors with pktgen Message-ID: <20050314133404.2528647f@es175> Organization: OSDL X-Mailer: Sylpheed-Claws 1.0.1 (GTK+ 1.2.10; i386-pc-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-MIMEDefang-Filter: osdl$Revision: 1.104 $ X-Scanned-By: MIMEDefang 2.36 X-Virus-Scanned: ClamAV 0.83/762/Sun Mar 13 15:35:33 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 111 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: cliffw@osdl.org Precedence: bulk X-list: netdev Content-Length: 833 Lines: 26 Robert. I am doing some wrapper scripts for pktgen for some testing purposes. My test rig is two machines with an e100 card, connected by crossover cable. When i run pktgen, the error counter == packet count, always. Adding printk's, i see the error is coming from this bit past line 2688: ---------- now = getCurUs(); if (now > pkt_dev->next_tx_us) { /* TODO: this code is slightly wonky. */ pkt_dev->errors++; pkt_dev->next_tx_us = now - pkt_dev->delay_us; pkt_dev->next_tx_ns = 0; } ---------------- Any suggestions? More info if needed.. cliffw -- "Ive always gone through periods where I bolt upright at four in the morning; now at least theres a reason." -Michael Feldman From jgarzik@pobox.com Mon Mar 14 14:51:00 2005 Received: with ECARTIS (v1.0.0; list netdev); Mon, 14 Mar 2005 14:51:06 -0800 (PST) Received: from parcelfarce.linux.theplanet.co.uk (IDENT:93@parcelfarce.linux.theplanet.co.uk [195.92.249.252]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j2EMowc2024785 for ; Mon, 14 Mar 2005 14:50:59 -0800 Received: from [69.134.152.124] (helo=[10.10.10.88]) by parcelfarce.linux.theplanet.co.uk with asmtp (TLSv1:AES256-SHA:256) (Exim 4.33) id 1DAyOl-0000uV-QG for netdev@oss.sgi.com; Mon, 14 Mar 2005 22:50:56 +0000 Message-ID: <42361510.2080902@pobox.com> Date: Mon, 14 Mar 2005 17:49:52 -0500 From: Jeff Garzik User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.3) Gecko/20040922 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Netdev Subject: IPv6 went away? Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV 0.83/762/Sun Mar 13 15:35:33 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 112 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: jgarzik@pobox.com Precedence: bulk X-list: netdev Content-Length: 288 Lines: 12 Has anything major been done to ipv6 recently? I'm running BK-latest (-bk10), and my workstation cannot seem to ping6 the router, much less the outside world. My router can ping6 various Internet sites just fine, and it's running -bk9. I'll dig deeper today or tomorrow... Jeff From maxk@qualcomm.com Mon Mar 14 14:53:48 2005 Received: with ECARTIS (v1.0.0; list netdev); Mon, 14 Mar 2005 14:53:53 -0800 (PST) Received: from ithilien.qualcomm.com (ithilien.qualcomm.com [129.46.51.59]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j2EMrmg7025586 for ; Mon, 14 Mar 2005 14:53:48 -0800 Received: from crowley.qualcomm.com (crowley.qualcomm.com [129.46.61.151]) by ithilien.qualcomm.com (8.12.10/8.12.5/1.0) with ESMTP id j2EMr8XO029641; Mon, 14 Mar 2005 14:53:08 -0800 (PST) Received: from [129.46.90.158] (workie.qualcomm.com [129.46.90.158]) by crowley.qualcomm.com (8.12.10/8.12.5/1.0) with ESMTP id j2EMr5IT022822; Mon, 14 Mar 2005 14:53:05 -0800 (PST) Message-ID: <423615D1.9030901@qualcomm.com> Date: Mon, 14 Mar 2005 14:53:05 -0800 From: Max Krasnyansky User-Agent: Mozilla Thunderbird 0.9 (X11/20041127) X-Accept-Language: en-us, en MIME-Version: 1.0 To: hadi@cyberus.ca CC: Thomas Graf , Ben Greear , "'netdev@oss.sgi.com'" Subject: Re: Interconnect virtual device? References: <4222A8F2.6080004@candelatech.com> <1109592365.2188.914.camel@jzny.localdomain> <422353C9.6050001@candelatech.com> <1109800554.1091.213.camel@jzny.localdomain> <20050302225558.GS31837@postel.suug.ch> <1109810103.1090.247.camel@jzny.localdomain> In-Reply-To: <1109810103.1090.247.camel@jzny.localdomain> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-PMX-Version: 4.7.0.111621 X-Virus-Scanned: ClamAV 0.83/762/Sun Mar 13 15:35:33 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 113 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: maxk@qualcomm.com Precedence: bulk X-list: netdev Content-Length: 1903 Lines: 44 jamal wrote: > On Wed, 2005-03-02 at 17:55, Thomas Graf wrote: > >>I think we talked about this once already and I do like the idea >>but the reinjection is at least of the same importance to me. What >>I'm thinking of basically gets down to two ring buffers both holding >>mmaped buffers. > > > The ring device already has the recv side direction ring, > Whats needed is tx side. > > >> The action enqueues skbs to the first ring buffer >>and userspace dequeues it from there. The skb gets completely lost >>at this point by having it shot or just cloned if mirroring is requested. > > > This will happen by default i.e the mirred action will take care of > buffer management and hopefully the ring device will worry about reusing > those skbs. > >>Userspace may reinject the skb again by putting it onto the second >>ring buffer for a kernel thread to pick up and reinject it at >>netif_receive_skb. Userspace may do whathever it likes as long as >>the checksum gets corrected, it may also fragment packets and reinject >>more than it originally received. Obviously for the redirect to >>userspace the skb must fullfil quite a lot of requirements only >>achievable on ingress but it would open up possibilities quite a lot. > > > One thing the PF_RING device needs is some form of metadata that can be > passed to user space. PF_PACKET with MMAP has a few, but we need to do a > lot more such as exposing most if not all of the skb metadata. > Similarly, the direction from user space will contain details of where > this packet is going to go (ingress vs egress) - PF_PACKET assumes > egress only at the moment. btw I'm going to add mmap() interface for the TUN driver (I need it for other stuff myself). In which case it seems that it should do pretty much the same thing that you guys are talking about. i.e. mmap(/dev/net/tun), setup mirroring to tunX, copy frames in/out of tunX. Max From yoshfuji@wide.ad.jp Mon Mar 14 15:01:42 2005 Received: with ECARTIS (v1.0.0; list netdev); Mon, 14 Mar 2005 15:01:47 -0800 (PST) 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 j2EN1fh7026447 for ; Mon, 14 Mar 2005 15:01:42 -0800 Received: from localhost (localhost [127.0.0.1]) by yue.st-paulia.net (Postfix) with ESMTP id D642833CC2; Tue, 15 Mar 2005 08:03:25 +0900 (JST) Date: Tue, 15 Mar 2005 08:03:25 +0900 (JST) Message-Id: <20050315.080325.14561230.yoshfuji@wide.ad.jp> To: jgarzik@pobox.com Cc: netdev@oss.sgi.com Subject: Re: IPv6 went away? From: YOSHIFUJI Hideaki / =?iso-2022-jp?B?GyRCNUhGIzFRTEAbKEI=?= In-Reply-To: <42361510.2080902@pobox.com> References: <42361510.2080902@pobox.com> X-URL: http://www.yoshifuji.org/%7Ehideaki/ X-Fingerprint: 90 22 65 EB 1E CF 3A D1 0B DF 80 D8 48 07 F8 94 E0 62 0E EA X-PGP-Key-URL: http://www.yoshifuji.org/%7Ehideaki/hideaki@yoshifuji.org.asc X-Mailer: Mew version 2.2 on Emacs 20.7 / Mule 4.1 (AOI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV 0.83/762/Sun Mar 13 15:35:33 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 114 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: yoshfuji@wide.ad.jp Precedence: bulk X-list: netdev Content-Length: 457 Lines: 14 In article <42361510.2080902@pobox.com> (at Mon, 14 Mar 2005 17:49:52 -0500), Jeff Garzik says: > Has anything major been done to ipv6 recently? I don't think so. > I'm running BK-latest (-bk10), and my workstation cannot seem to ping6 > the router, much less the outside world. My router can ping6 various > Internet sites just fine, and it's running -bk9. Our daily tests report nothing strange. Maybe driver issue? --yoshfuji From davem@davemloft.net Mon Mar 14 15:03:26 2005 Received: with ECARTIS (v1.0.0; list netdev); Mon, 14 Mar 2005 15:03:30 -0800 (PST) Received: from cheetah.davemloft.net (mail@dsl027-180-174.sfo1.dsl.speakeasy.net [216.27.180.174]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j2EN3QoK026852 for ; Mon, 14 Mar 2005 15:03:26 -0800 Received: from localhost ([127.0.0.1] helo=cheetah.davemloft.net ident=davem) by cheetah.davemloft.net with smtp (Exim 3.36 #1 (Debian)) id 1DAyZL-0003Yw-00; Mon, 14 Mar 2005 15:01:51 -0800 Date: Mon, 14 Mar 2005 15:01:51 -0800 From: "David S. Miller" To: Jeff Garzik Cc: netdev@oss.sgi.com Subject: Re: IPv6 went away? Message-Id: <20050314150151.0a2abda6.davem@davemloft.net> In-Reply-To: <42361510.2080902@pobox.com> References: <42361510.2080902@pobox.com> X-Mailer: Sylpheed version 1.0.1 (GTK+ 1.2.10; sparc-unknown-linux-gnu) X-Face: "_;p5u5aPsO,_Vsx"^v-pEq09'CU4&Dc1$fQExov$62l60cgCc%FnIwD=.UF^a>?5'9Kn[;433QFVV9M..2eN.@4ZWPGbdi<=?[:T>y?SD(R*-3It"Vj:)"dP Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV 0.83/762/Sun Mar 13 15:35:33 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 115 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: davem@davemloft.net Precedence: bulk X-list: netdev Content-Length: 331 Lines: 9 On Mon, 14 Mar 2005 17:49:52 -0500 Jeff Garzik wrote: > Has anything major been done to ipv6 recently? Yes, it was changed with several updates from USAGI to make it pass the "ipv6 ready" requirements. The experimental Kconfig tag was also removed, perhaps for this reason it was not included in your build? From yoshfuji@wide.ad.jp Mon Mar 14 15:08:50 2005 Received: with ECARTIS (v1.0.0; list netdev); Mon, 14 Mar 2005 15:08:57 -0800 (PST) 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 j2EN8nDs027614 for ; Mon, 14 Mar 2005 15:08:49 -0800 Received: from localhost (localhost [127.0.0.1]) by yue.st-paulia.net (Postfix) with ESMTP id 34DAB33CC2; Tue, 15 Mar 2005 08:10:34 +0900 (JST) Date: Tue, 15 Mar 2005 08:10:33 +0900 (JST) Message-Id: <20050315.081033.106923337.yoshfuji@wide.ad.jp> To: jgarzik@pobox.com Cc: netdev@oss.sgi.com Subject: Re: IPv6 went away? From: YOSHIFUJI Hideaki / =?iso-2022-jp?B?GyRCNUhGIzFRTEAbKEI=?= In-Reply-To: <20050315.080325.14561230.yoshfuji@wide.ad.jp> References: <42361510.2080902@pobox.com> <20050315.080325.14561230.yoshfuji@wide.ad.jp> X-URL: http://www.yoshifuji.org/%7Ehideaki/ X-Fingerprint: 90 22 65 EB 1E CF 3A D1 0B DF 80 D8 48 07 F8 94 E0 62 0E EA X-PGP-Key-URL: http://www.yoshifuji.org/%7Ehideaki/hideaki@yoshifuji.org.asc X-Mailer: Mew version 2.2 on Emacs 20.7 / Mule 4.1 (AOI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=iso-2022-jp Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV 0.83/762/Sun Mar 13 15:35:33 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 116 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: yoshfuji@wide.ad.jp Precedence: bulk X-list: netdev Content-Length: 491 Lines: 12 In article <20050315.080325.14561230.yoshfuji@wide.ad.jp> (at Tue, 15 Mar 2005 08:03:25 +0900 (JST)), YOSHIFUJI Hideaki / $B5HF#1QL@(B says: > In article <42361510.2080902@pobox.com> (at Mon, 14 Mar 2005 17:49:52 -0500), Jeff Garzik says: > > > Has anything major been done to ipv6 recently? > > I don't think so. To clarify: I interpreted "recently" as "between bk9 and bk10." In that means, I don't think there're major changes. --yoshfuji From jgarzik@pobox.com Mon Mar 14 15:18:53 2005 Received: with ECARTIS (v1.0.0; list netdev); Mon, 14 Mar 2005 15:18:59 -0800 (PST) Received: from parcelfarce.linux.theplanet.co.uk (IDENT:93@parcelfarce.linux.theplanet.co.uk [195.92.249.252]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j2ENIq0s028542 for ; Mon, 14 Mar 2005 15:18:53 -0800 Received: from [69.134.152.124] (helo=[10.10.10.88]) by parcelfarce.linux.theplanet.co.uk with asmtp (TLSv1:AES256-SHA:256) (Exim 4.33) id 1DAypn-0001gW-31; Mon, 14 Mar 2005 23:18:51 +0000 Message-ID: <42361BBA.5050409@pobox.com> Date: Mon, 14 Mar 2005 18:18:18 -0500 From: Jeff Garzik User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.3) Gecko/20040922 X-Accept-Language: en-us, en MIME-Version: 1.0 To: "David S. Miller" , yoshfuji@wide.ad.jp CC: netdev@oss.sgi.com Subject: Re: IPv6 went away? References: <42361510.2080902@pobox.com> <20050314150151.0a2abda6.davem@davemloft.net> In-Reply-To: <20050314150151.0a2abda6.davem@davemloft.net> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV 0.83/762/Sun Mar 13 15:35:33 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 118 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: jgarzik@pobox.com Precedence: bulk X-list: netdev Content-Length: 546 Lines: 21 David S. Miller wrote: > On Mon, 14 Mar 2005 17:49:52 -0500 > Jeff Garzik wrote: > > >>Has anything major been done to ipv6 recently? > > > Yes, it was changed with several updates from USAGI to > make it pass the "ipv6 ready" requirements. The > experimental Kconfig tag was also removed, perhaps for this > reason it was not included in your build? Nevermind, a route didn't come up on my side. My apologies for wasting everybody's time. 6to4 and IPv6 appear to be working just fine, good work everyone :) Jeff From shemminger@osdl.org Mon Mar 14 15:17:24 2005 Received: with ECARTIS (v1.0.0; list netdev); Mon, 14 Mar 2005 15:17:40 -0800 (PST) Received: from smtp.osdl.org (fire.osdl.org [65.172.181.4]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j2ENHNGH028246 for ; Mon, 14 Mar 2005 15:17:23 -0800 Received: from shell0.pdx.osdl.net (fw.osdl.org [65.172.181.6]) by smtp.osdl.org (8.12.8/8.12.8) with ESMTP id j2ENH8qi020399 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO); Mon, 14 Mar 2005 15:17:08 -0800 Received: from dxpl.pdx.osdl.net (dxpl.pdx.osdl.net [172.20.1.103]) by shell0.pdx.osdl.net (8.13.1/8.11.6) with ESMTP id j2ENH8Z5023142; Mon, 14 Mar 2005 15:17:08 -0800 Date: Mon, 14 Mar 2005 15:17:26 -0800 From: Stephen Hemminger To: "David S. Miller" Cc: baruch@ev-en.org, netdev@oss.sgi.com Subject: [RFC] TCP congestion schedulers Message-ID: <20050314151726.532af90d@dxpl.pdx.osdl.net> In-Reply-To: <20050311201011.360c00da.davem@davemloft.net> References: <421CF5E5.1060606@ev-en.org> <20050223135732.39e62c6c.davem@davemloft.net> <421D1E66.5090301@osdl.org> <421D30FA.1060900@ev-en.org> <20050225120814.5fa77b13@dxpl.pdx.osdl.net> <20050309210442.3e9786a6.davem@davemloft.net> <4230288F.1030202@ev-en.org> <20050310182629.1eab09ec.davem@davemloft.net> <20050311120054.4bbf675a@dxpl.pdx.osdl.net> <20050311201011.360c00da.davem@davemloft.net> Organization: Open Source Development Lab X-Mailer: Sylpheed-Claws 1.0.1 (GTK+ 1.2.10; x86_64-unknown-linux-gnu) X-Face: &@E+xe?c%:&e4D{>f1O<&U>2qwRREG5!}7R4;D<"NO^UI2mJ[eEOA2*3>(`Th.yP,VDPo9$ /`~cw![cmj~~jWe?AHY7D1S+\}5brN0k*NE?pPh_'_d>6;XGG[\KDRViCfumZT3@[ Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Received-SPF: pass (domain of shemminger@osdl.org designates 65.172.181.6 as permitted sender) X-MIMEDefang-Filter: osdl$Revision: 1.104 $ X-Scanned-By: MIMEDefang 2.36 X-Virus-Scanned: ClamAV 0.83/762/Sun Mar 13 15:35:33 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 117 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: shemminger@osdl.org Precedence: bulk X-list: netdev Content-Length: 79685 Lines: 2593 Since developers want to experiment with different congestion control mechanisms, and the kernel is getting bloated with overlapping data structure and code for multiple algorithms; here is a patch to split out the Reno, Vegas, Westwood, BIC congestion control stuff into an infrastructure similar to the I/O schedulers. Congestion control protocol is controlled by sysctl net.ipv4.tcp_congestion_control and the boot parameter tcp_congestion_control. The parameter is a lower case string. The congestion control is set when the socket is connected. If you give a bogus value to the parameter, then it warns and falls back to using TCP Reno. TCP Reno is still required, both as a fallback protocol and to allow other code to use it. No attempt was made to do backward compatibility with the old sysctl's (net.ipv4.tcp_bic, ...) Individual protocols can have parameters but instead of being sysctl's they are done as module parameters. Sysctl hooks are not ref counted so they can't be safely used by modules. Parmeters can be changed via sysfs. This is not complete and bugs were probably inserted when extracting out the algorithms so more testing is needed. --- diff -urNp -X dontdiff linux-2.6/include/linux/sysctl.h tcp-2.6/include/linux/sysctl.h --- linux-2.6/include/linux/sysctl.h 2005-03-14 14:30:49.000000000 -0800 +++ tcp-2.6/include/linux/sysctl.h 2005-03-11 15:45:27.000000000 -0800 @@ -346,6 +346,7 @@ enum NET_TCP_MODERATE_RCVBUF=106, NET_TCP_TSO_WIN_DIVISOR=107, NET_TCP_BIC_BETA=108, + NET_TCP_CONG_CONTROL=109, }; enum { diff -urNp -X dontdiff linux-2.6/include/linux/tcp.h tcp-2.6/include/linux/tcp.h --- linux-2.6/include/linux/tcp.h 2005-03-14 14:30:49.000000000 -0800 +++ tcp-2.6/include/linux/tcp.h 2005-03-11 16:30:28.000000000 -0800 @@ -203,13 +203,6 @@ struct tcp_sack_block { __u32 end_seq; }; -enum tcp_congestion_algo { - TCP_RENO=0, - TCP_VEGAS, - TCP_WESTWOOD, - TCP_BIC, -}; - struct tcp_options_received { /* PAWS/RTTM data */ long ts_recent_stamp;/* Time we stored ts_recent (for aging) */ @@ -295,7 +288,7 @@ struct tcp_sock { __u8 reordering; /* Packet reordering metric. */ __u8 frto_counter; /* Number of new acks after RTO */ - __u8 adv_cong; /* Using Vegas, Westwood, or BIC */ + __u8 unused; __u8 defer_accept; /* User waits for some data after accept() */ /* RTT measurement */ @@ -406,37 +399,10 @@ struct tcp_sock { __u32 time; } rcvq_space; -/* TCP Westwood structure */ - struct { - __u32 bw_ns_est; /* first bandwidth estimation..not too smoothed 8) */ - __u32 bw_est; /* bandwidth estimate */ - __u32 rtt_win_sx; /* here starts a new evaluation... */ - __u32 bk; - __u32 snd_una; /* used for evaluating the number of acked bytes */ - __u32 cumul_ack; - __u32 accounted; - __u32 rtt; - __u32 rtt_min; /* minimum observed RTT */ - } westwood; - -/* Vegas variables */ - struct { - __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 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) */ - __u32 baseRTT; /* the min of all Vegas RTT measurements seen (in usec) */ - } vegas; - - /* BI TCP Parameters */ - struct { - __u32 cnt; /* increase cwnd by 1 after this number of ACKs */ - __u32 last_max_cwnd; /* last maximium snd_cwnd */ - __u32 last_cwnd; /* the last snd_cwnd */ - __u32 last_stamp; /* time when updated last_cwnd */ - } bictcp; +/* Hook for advanced congestion control */ + struct tcp_ca_type *ca_proto; +#define TCP_CA_PRIV_SIZE 48 + u8 *ca_priv[TCP_CA_PRIV_SIZE]; }; static inline struct tcp_sock *tcp_sk(const struct sock *sk) @@ -444,6 +410,11 @@ static inline struct tcp_sock *tcp_sk(co return (struct tcp_sock *)sk; } +static inline void *tcp_ca(const struct tcp_sock *tp) +{ + return (void *) tp->ca_priv; +} + #endif #endif /* _LINUX_TCP_H */ diff -urNp -X dontdiff linux-2.6/include/net/tcp.h tcp-2.6/include/net/tcp.h --- linux-2.6/include/net/tcp.h 2005-03-14 14:30:50.000000000 -0800 +++ tcp-2.6/include/net/tcp.h 2005-03-11 16:26:17.000000000 -0800 @@ -504,25 +504,6 @@ static __inline__ int tcp_sk_listen_hash #else # define TCP_TW_RECYCLE_TICK (12+2-TCP_TW_RECYCLE_SLOTS_LOG) #endif - -#define BICTCP_BETA_SCALE 1024 /* Scale factor beta calculation - * max_cwnd = snd_cwnd * beta - */ -#define BICTCP_MAX_INCREMENT 32 /* - * Limit on the amount of - * increment allowed during - * binary search. - */ -#define BICTCP_FUNC_OF_MIN_INCR 11 /* - * log(B/Smin)/log(B/(B-1))+1, - * Smin:min increment - * B:log factor - */ -#define BICTCP_B 4 /* - * In binary search, - * go to point (max+min)/N - */ - /* * TCP option */ @@ -596,16 +577,7 @@ extern int sysctl_tcp_adv_win_scale; extern int sysctl_tcp_tw_reuse; extern int sysctl_tcp_frto; extern int sysctl_tcp_low_latency; -extern int sysctl_tcp_westwood; -extern int sysctl_tcp_vegas_cong_avoid; -extern int sysctl_tcp_vegas_alpha; -extern int sysctl_tcp_vegas_beta; -extern int sysctl_tcp_vegas_gamma; extern int sysctl_tcp_nometrics_save; -extern int sysctl_tcp_bic; -extern int sysctl_tcp_bic_fast_convergence; -extern int sysctl_tcp_bic_low_window; -extern int sysctl_tcp_bic_beta; extern int sysctl_tcp_moderate_rcvbuf; extern int sysctl_tcp_tso_win_divisor; @@ -1203,6 +1175,61 @@ static inline void tcp_packets_out_dec(s tp->packets_out -= tcp_skb_pcount(skb); } +/* + * Hooks for TCP congestion control algorithms + */ +enum tcp_ca_event { + CA_EVENT_CWND_RESTART, + CA_EVENT_COMPLETE_CWR, + CA_EVENT_FRTO, + CA_EVENT_FAST_ACK, + CA_EVENT_SLOW_ACK, +}; + +struct tcp_ca_type { + void (*start)(struct tcp_sock *tp); + u32 (*ssthresh)(struct tcp_sock *tp); + u32 (*min_cwnd)(struct tcp_sock *tp); + void (*cong_avoid)(struct tcp_sock *tp, u32 ack, + u32 rtt, u32 in_flight); + void (*rtt_sample)(struct tcp_sock *tp, u32 rtt); + void (*set_state)(struct tcp_sock *tp, u8 new_state); + + void (*cwnd_event)(struct tcp_sock *tp, enum tcp_ca_event ev); + + struct list_head list; + struct module *owner; + const char *name; +}; + + +#define TCP_CA_NAME_MAX 32 +extern char sysctl_tcp_ca_protocol[TCP_CA_NAME_MAX]; +extern void tcp_ca_register(struct tcp_ca_type *type); +extern void tcp_ca_unregister(struct tcp_ca_type *type); +extern void tcp_ca_init(struct tcp_sock *tp); +extern void tcp_ca_destroy(struct tcp_sock *tp); + +extern struct tcp_ca_type tcp_reno; +extern void tcp_reno_cong_avoid(struct tcp_sock *tp, u32 ack, + u32 rtt, u32 in_flight); +extern u32 tcp_reno_cwnd_min(struct tcp_sock *tp); +extern u32 tcp_reno_ssthresh(struct tcp_sock *tp); + +static inline void tcp_set_ca_state(struct tcp_sock *tp, u8 ca_state) +{ + if (tp->ca_proto->set_state) + tp->ca_proto->set_state(tp, ca_state); + tp->ca_state = ca_state; +} + +static inline void tcp_ca_event(struct tcp_sock *tp, enum tcp_ca_event event) +{ + if (tp->ca_proto->cwnd_event) + tp->ca_proto->cwnd_event(tp, event); +} + + /* This determines how many packets are "in the network" to the best * of our knowledge. In many cases it is conservative, but where * detailed information is available from the receiver (via SACK @@ -1222,91 +1249,6 @@ static __inline__ unsigned int tcp_packe 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: - * one half the current congestion window, but no - * less than two segments - * - * BIC: - * behave like Reno until low_window is reached, - * then increase congestion window slowly - */ -static inline __u32 tcp_recalc_ssthresh(struct tcp_sock *tp) -{ - if (tcp_is_bic(tp)) { - if (sysctl_tcp_bic_fast_convergence && - tp->snd_cwnd < tp->bictcp.last_max_cwnd) - tp->bictcp.last_max_cwnd = (tp->snd_cwnd * - (BICTCP_BETA_SCALE - + sysctl_tcp_bic_beta)) - / (2 * BICTCP_BETA_SCALE); - else - tp->bictcp.last_max_cwnd = tp->snd_cwnd; - - if (tp->snd_cwnd > sysctl_tcp_bic_low_window) - return max((tp->snd_cwnd * sysctl_tcp_bic_beta) - / BICTCP_BETA_SCALE, 2U); - } - - return max(tp->snd_cwnd >> 1U, 2U); -} - -/* Stop taking Vegas samples for now. */ -#define tcp_vegas_disable(__tp) ((__tp)->vegas.doing_vegas_now = 0) - -static inline void tcp_vegas_enable(struct tcp_sock *tp) -{ - /* There are several situations when we must "re-start" Vegas: - * - * o when a connection is established - * o after an RTO - * o after fast recovery - * o when we send a packet and there is no outstanding - * unacknowledged data (restarting an idle connection) - * - * In these circumstances we cannot do a Vegas calculation at the - * end of the first RTT, because any calculation we do is using - * stale info -- both the saved cwnd and congestion feedback are - * stale. - * - * Instead we must wait until the completion of an RTT during - * which we actually receive ACKs. - */ - - /* Begin taking Vegas samples next time we send something. */ - tp->vegas.doing_vegas_now = 1; - - /* Set the beginning of the next send window. */ - tp->vegas.beg_snd_nxt = tp->snd_nxt; - - tp->vegas.cntRTT = 0; - tp->vegas.minRTT = 0x7fffffff; -} - -/* Should we be taking Vegas samples right now? */ -#define tcp_vegas_enabled(__tp) ((__tp)->vegas.doing_vegas_now) - -extern void tcp_ca_init(struct tcp_sock *tp); - -static inline void tcp_set_ca_state(struct tcp_sock *tp, u8 ca_state) -{ - if (tcp_is_vegas(tp)) { - if (ca_state == TCP_CA_Open) - tcp_vegas_enable(tp); - else - tcp_vegas_disable(tp); - } - tp->ca_state = ca_state; -} - /* If cwnd > ssthresh, we may raise ssthresh to be half-way to cwnd. * The exception is rate halving phase, when cwnd is decreasing towards * ssthresh. @@ -1355,7 +1297,7 @@ static inline void tcp_cwnd_validate(str static inline void __tcp_enter_cwr(struct tcp_sock *tp) { tp->undo_marker = 0; - tp->snd_ssthresh = tcp_recalc_ssthresh(tp); + tp->snd_ssthresh = tp->ca_proto->ssthresh(tp); tp->snd_cwnd = min(tp->snd_cwnd, tcp_packets_in_flight(tp) + 1U); tp->snd_cwnd_cnt = 0; @@ -1970,52 +1912,4 @@ struct tcp_iter_state { extern int tcp_proc_register(struct tcp_seq_afinfo *afinfo); extern void tcp_proc_unregister(struct tcp_seq_afinfo *afinfo); -/* TCP Westwood functions and constants */ - -#define TCP_WESTWOOD_INIT_RTT (20*HZ) /* maybe too conservative?! */ -#define TCP_WESTWOOD_RTT_MIN (HZ/20) /* 50ms */ - -static inline void tcp_westwood_update_rtt(struct tcp_sock *tp, __u32 rtt_seq) -{ - if (tcp_is_westwood(tp)) - tp->westwood.rtt = rtt_seq; -} - -static inline __u32 __tcp_westwood_bw_rttmin(const struct tcp_sock *tp) -{ - return max((tp->westwood.bw_est) * (tp->westwood.rtt_min) / - (__u32) (tp->mss_cache_std), - 2U); -} - -static inline __u32 tcp_westwood_bw_rttmin(const struct tcp_sock *tp) -{ - return tcp_is_westwood(tp) ? __tcp_westwood_bw_rttmin(tp) : 0; -} - -static inline int tcp_westwood_ssthresh(struct tcp_sock *tp) -{ - __u32 ssthresh = 0; - - if (tcp_is_westwood(tp)) { - ssthresh = __tcp_westwood_bw_rttmin(tp); - if (ssthresh) - tp->snd_ssthresh = ssthresh; - } - - return (ssthresh != 0); -} - -static inline int tcp_westwood_cwnd(struct tcp_sock *tp) -{ - __u32 cwnd = 0; - - if (tcp_is_westwood(tp)) { - cwnd = __tcp_westwood_bw_rttmin(tp); - if (cwnd) - tp->snd_cwnd = cwnd; - } - - return (cwnd != 0); -} #endif /* _TCP_H */ diff -urNp -X dontdiff linux-2.6/net/ipv4/Kconfig tcp-2.6/net/ipv4/Kconfig --- linux-2.6/net/ipv4/Kconfig 2005-03-14 14:30:52.000000000 -0800 +++ tcp-2.6/net/ipv4/Kconfig 2005-03-11 15:45:32.000000000 -0800 @@ -365,5 +365,48 @@ config IP_TCPDIAG config IP_TCPDIAG_IPV6 def_bool (IP_TCPDIAG=y && IPV6=y) || (IP_TCPDIAG=m && IPV6) +menu "TCP congestion control" + +# Reno is required as fallback +config TCP_CONG_VEGAS + tristate "TCP Vegas" + default n + ---help--- + TCP Vegas is a sender-side only change to TCP that anticipates + the onset of congestion by estimating the bandwidth. TCP Vegas + adjusts the sending rate by modifying the congestion + window. TCP Vegas should provide less packet loss, but it is + not as aggressive as TCP Reno. + +config TCP_CONG_BIC + tristate "Binary Increase Congestion (BIC) control" + default y + ---help--- + BIC-TCP is a sender-side only change that ensures a linear RTT + fairness under large windows while offering both scalability and + bounded TCP-friendliness. The protocol combines two schemes + called additive increase and binary search increase. When the + congestion window is large, additive increase with a large + increment ensures linear RTT fairness as well as good + scalability. Under small congestion windows, binary search + increase provides TCP friendliness. + +config TCP_CONG_WESTWOOD + tristate "TCP Westwood+" + default y + ---help--- + TCP Westwood+ is a sender-side only modification of the TCP Reno + protocol stack that optimizes the performance of TCP congestion + control. It is based on end-to-end bandwidth estimation to set + congestion window and slow start threshold after a congestion + episode. Using this estimation, TCP Westwood+ adaptively sets a + slow start threshold and a congestion window which takes into + account the bandwidth used at the time congestion is experienced. + TCP Westwood+ significantly increases fairness wrt TCP Reno in + wired networks and throughput over wireless links. + +endmenu + + source "net/ipv4/ipvs/Kconfig" diff -urNp -X dontdiff linux-2.6/net/ipv4/Makefile tcp-2.6/net/ipv4/Makefile --- linux-2.6/net/ipv4/Makefile 2005-03-14 14:30:52.000000000 -0800 +++ tcp-2.6/net/ipv4/Makefile 2005-03-11 15:45:33.000000000 -0800 @@ -5,7 +5,8 @@ obj-y := utils.o route.o inetpeer.o protocol.o \ ip_input.o ip_fragment.o ip_forward.o ip_options.o \ ip_output.o ip_sockglue.o \ - tcp.o tcp_input.o tcp_output.o tcp_timer.o tcp_ipv4.o tcp_minisocks.o \ + tcp.o tcp_input.o tcp_output.o tcp_timer.o tcp_ipv4.o \ + tcp_minisocks.o tcp_cong.o tcp_reno.o \ datagram.o raw.o udp.o arp.o icmp.o devinet.o af_inet.o igmp.o \ sysctl_net_ipv4.o fib_frontend.o fib_semantics.o fib_hash.o @@ -23,6 +24,9 @@ obj-$(CONFIG_IP_PNP) += ipconfig.o obj-$(CONFIG_NETFILTER) += netfilter/ obj-$(CONFIG_IP_VS) += ipvs/ obj-$(CONFIG_IP_TCPDIAG) += tcp_diag.o +obj-$(CONFIG_TCP_CONG_VEGAS) += tcp_vegas.o +obj-$(CONFIG_TCP_CONG_BIC) += tcp_bic.o +obj-$(CONFIG_TCP_CONG_WESTWOOD) += tcp_westwood.o obj-$(CONFIG_XFRM) += xfrm4_policy.o xfrm4_state.o xfrm4_input.o \ xfrm4_output.o diff -urNp -X dontdiff linux-2.6/net/ipv4/sysctl_net_ipv4.c tcp-2.6/net/ipv4/sysctl_net_ipv4.c --- linux-2.6/net/ipv4/sysctl_net_ipv4.c 2005-03-14 14:30:52.000000000 -0800 +++ tcp-2.6/net/ipv4/sysctl_net_ipv4.c 2005-03-11 16:13:46.000000000 -0800 @@ -603,70 +603,6 @@ ctl_table ipv4_table[] = { .proc_handler = &proc_dointvec, }, { - .ctl_name = NET_TCP_WESTWOOD, - .procname = "tcp_westwood", - .data = &sysctl_tcp_westwood, - .maxlen = sizeof(int), - .mode = 0644, - .proc_handler = &proc_dointvec, - }, - { - .ctl_name = NET_TCP_VEGAS, - .procname = "tcp_vegas_cong_avoid", - .data = &sysctl_tcp_vegas_cong_avoid, - .maxlen = sizeof(int), - .mode = 0644, - .proc_handler = &proc_dointvec, - }, - { - .ctl_name = NET_TCP_VEGAS_ALPHA, - .procname = "tcp_vegas_alpha", - .data = &sysctl_tcp_vegas_alpha, - .maxlen = sizeof(int), - .mode = 0644, - .proc_handler = &proc_dointvec, - }, - { - .ctl_name = NET_TCP_VEGAS_BETA, - .procname = "tcp_vegas_beta", - .data = &sysctl_tcp_vegas_beta, - .maxlen = sizeof(int), - .mode = 0644, - .proc_handler = &proc_dointvec, - }, - { - .ctl_name = NET_TCP_VEGAS_GAMMA, - .procname = "tcp_vegas_gamma", - .data = &sysctl_tcp_vegas_gamma, - .maxlen = sizeof(int), - .mode = 0644, - .proc_handler = &proc_dointvec, - }, - { - .ctl_name = NET_TCP_BIC, - .procname = "tcp_bic", - .data = &sysctl_tcp_bic, - .maxlen = sizeof(int), - .mode = 0644, - .proc_handler = &proc_dointvec, - }, - { - .ctl_name = NET_TCP_BIC_FAST_CONVERGENCE, - .procname = "tcp_bic_fast_convergence", - .data = &sysctl_tcp_bic_fast_convergence, - .maxlen = sizeof(int), - .mode = 0644, - .proc_handler = &proc_dointvec, - }, - { - .ctl_name = NET_TCP_BIC_LOW_WINDOW, - .procname = "tcp_bic_low_window", - .data = &sysctl_tcp_bic_low_window, - .maxlen = sizeof(int), - .mode = 0644, - .proc_handler = &proc_dointvec, - }, - { .ctl_name = NET_TCP_MODERATE_RCVBUF, .procname = "tcp_moderate_rcvbuf", .data = &sysctl_tcp_moderate_rcvbuf, @@ -683,12 +619,13 @@ ctl_table ipv4_table[] = { .proc_handler = &proc_dointvec, }, { - .ctl_name = NET_TCP_BIC_BETA, - .procname = "tcp_bic_beta", - .data = &sysctl_tcp_bic_beta, - .maxlen = sizeof(int), + .ctl_name = NET_TCP_CONG_CONTROL, + .procname = "tcp_congestion_control", + .data = &sysctl_tcp_ca_protocol, + .maxlen = TCP_CA_NAME_MAX, .mode = 0644, - .proc_handler = &proc_dointvec, + .proc_handler = &proc_dostring, + .strategy = &sysctl_string, }, { .ctl_name = 0 } }; diff -urNp -X dontdiff linux-2.6/net/ipv4/tcp_bic.c tcp-2.6/net/ipv4/tcp_bic.c --- linux-2.6/net/ipv4/tcp_bic.c 1969-12-31 16:00:00.000000000 -0800 +++ tcp-2.6/net/ipv4/tcp_bic.c 2005-03-11 16:32:37.000000000 -0800 @@ -0,0 +1,194 @@ +/* + * Binary Increase Congestion control for TCP + * + * This is from the implementation of BICTCP in + * Lison-Xu, Kahaled Harfoush, and Injog Rhee. + * "Binary Increase Congestion Control for Fast, Long Distance + * Networks" in InfoComm 2004 + * Available from: + * http://www.csc.ncsu.edu/faculty/rhee/export/bitcp.pdf + * + * Unless BIC is enabled and congestion window is large + * this behaves the same as the original Reno. + */ + +#include +#include +#include +#include + + +#define BICTCP_BETA_SCALE 1024 /* Scale factor beta calculation + * max_cwnd = snd_cwnd * beta + */ +#define BICTCP_MAX_INCREMENT 32 /* + * Limit on the amount of + * increment allowed during + * binary search. + */ +#define BICTCP_FUNC_OF_MIN_INCR 11 /* + * log(B/Smin)/log(B/(B-1))+1, + * Smin:min increment + * B:log factor + */ +#define BICTCP_B 4 /* + * In binary search, + * go to point (max+min)/N + */ + +static int fast_convergence = 1; +static int low_window = 14; +static int beta = 819; /* = 819/1024 (BICTCP_BETA_SCALE) */ + +module_param(fast_convergence, int, 0644); +MODULE_PARM_DESC(fast_convergence, "turn on/off fast convergence"); +module_param(low_window, int, 0644); +MODULE_PARM_DESC(low_window, "lower bound on cwind (for TCP friendliness)"); +module_param(beta, int, 0644); +MODULE_PARM_DESC(beta, "beta for multiplictative increase"); + +/* BIC TCP Parameters */ +struct bictcp_ca { + u32 cnt; /* increase cwnd by 1 after ACKs */ + u32 last_max_cwnd; /* last maximium snd_cwnd */ + u32 last_cwnd; /* the last snd_cwnd */ + u32 last_stamp; /* time when updated last_cwnd */ +}; + +static void bictcp_start(struct tcp_sock *tp) +{ + struct bictcp_ca *ca = tcp_ca(tp); + ca->cnt = 0; + ca->last_max_cwnd = 0; + ca->last_cwnd = 0; + ca->last_stamp = 0; +} + +/* + * Compute congestion window to use. + */ +static inline u32 bictcp_cwnd(struct tcp_sock *tp) +{ + struct bictcp_ca *ca = tcp_ca(tp); + + if (ca->last_cwnd == tp->snd_cwnd && + (s32)(tcp_time_stamp - ca->last_stamp) <= (HZ>>5)) + return ca->cnt; + + ca->last_cwnd = tp->snd_cwnd; + ca->last_stamp = tcp_time_stamp; + + /* start off normal */ + if (tp->snd_cwnd <= low_window) + ca->cnt = tp->snd_cwnd; + + /* binary increase */ + else if (tp->snd_cwnd < ca->last_max_cwnd) { + __u32 dist = (ca->last_max_cwnd - tp->snd_cwnd) + / BICTCP_B; + + if (dist > BICTCP_MAX_INCREMENT) + /* linear increase */ + ca->cnt = tp->snd_cwnd / BICTCP_MAX_INCREMENT; + else if (dist <= 1U) + /* binary search increase */ + ca->cnt = tp->snd_cwnd * BICTCP_FUNC_OF_MIN_INCR + / BICTCP_B; + else + /* binary search increase */ + ca->cnt = tp->snd_cwnd / dist; + } else { + /* slow start amd linear increase */ + if (tp->snd_cwnd < ca->last_max_cwnd + BICTCP_B) + /* slow start */ + ca->cnt = tp->snd_cwnd * BICTCP_FUNC_OF_MIN_INCR + / BICTCP_B; + else if (tp->snd_cwnd < ca->last_max_cwnd + + BICTCP_MAX_INCREMENT*(BICTCP_B-1)) + /* slow start */ + ca->cnt = tp->snd_cwnd * (BICTCP_B-1) + / (tp->snd_cwnd-ca->last_max_cwnd); + else + /* linear increase */ + ca->cnt = tp->snd_cwnd / BICTCP_MAX_INCREMENT; + } + + return ca->cnt; +} + +static void bictcp_cong_avoid(struct tcp_sock *tp, u32 ack, + u32 seq_rtt, u32 in_flight) +{ + if (in_flight < tp->snd_cwnd) + return; + + if (tp->snd_cwnd <= tp->snd_ssthresh) { + /* In "safe" area, increase. */ + if (tp->snd_cwnd < tp->snd_cwnd_clamp) + tp->snd_cwnd++; + } else { + if (tp->snd_cwnd_cnt > (bictcp_cwnd(tp) << 3)) { + tp->snd_cwnd_cnt = 0; + tp->snd_cwnd++; + } + } +} + + +/* + * behave like Reno until low_window is reached, + * then increase congestion window slowly + */ +static u32 bictcp_recalc_ssthresh(struct tcp_sock *tp) +{ + struct bictcp_ca *ca = tcp_ca(tp); + + if (fast_convergence && tp->snd_cwnd < ca->last_max_cwnd) + ca->last_max_cwnd = (tp->snd_cwnd * (BICTCP_BETA_SCALE + beta)) + / (2 * BICTCP_BETA_SCALE); + else + ca->last_max_cwnd = tp->snd_cwnd; + + if (tp->snd_cwnd <= low_window) + return max(tp->snd_cwnd >> 1U, 2U); + else + return max((tp->snd_cwnd * beta) / BICTCP_BETA_SCALE, 2U); +} + +static void bictcp_ca_state(struct tcp_sock *tp, u8 new_state) +{ + if (new_state == TCP_CA_Loss) + bictcp_start(tp); +} + +static struct tcp_ca_type bictcp = { + .start = bictcp_start, + .ssthresh = bictcp_recalc_ssthresh, + .cong_avoid = bictcp_cong_avoid, + .min_cwnd = tcp_reno_cwnd_min, + .set_state = bictcp_ca_state, + + .owner = THIS_MODULE, + .name = "bic", +}; + +static int __init bictcp_init(void) +{ + BUILD_BUG_ON(sizeof(struct bictcp_ca) > TCP_CA_PRIV_SIZE); + tcp_ca_register(&bictcp); + return 0; +} + +static void __exit bictcp_exit(void) +{ + tcp_ca_unregister(&bictcp); +} + +module_init(bictcp_init); +module_exit(bictcp_exit); + +MODULE_AUTHOR("Stephen Hemminger"); +MODULE_LICENSE("GPL"); +MODULE_DESCRIPTION("BIC TCP"); + + diff -urNp -X dontdiff linux-2.6/net/ipv4/tcp.c tcp-2.6/net/ipv4/tcp.c --- linux-2.6/net/ipv4/tcp.c 2005-03-14 14:30:52.000000000 -0800 +++ tcp-2.6/net/ipv4/tcp.c 2005-03-11 16:13:46.000000000 -0800 @@ -2366,6 +2366,8 @@ void __init tcp_init(void) printk(KERN_INFO "TCP: Hash tables configured " "(established %d bind %d)\n", tcp_ehash_size << 1, tcp_bhash_size); + + tcp_ca_register(&tcp_reno); } EXPORT_SYMBOL(tcp_accept); diff -urNp -X dontdiff linux-2.6/net/ipv4/tcp_cong.c tcp-2.6/net/ipv4/tcp_cong.c --- linux-2.6/net/ipv4/tcp_cong.c 1969-12-31 16:00:00.000000000 -0800 +++ tcp-2.6/net/ipv4/tcp_cong.c 2005-03-14 12:00:25.000000000 -0800 @@ -0,0 +1,112 @@ +/* + * Plugable TCP congestion control support. + * + * Based on ideas from I/O scheduler suport and Web100. + * + * Copyright (C) 2005 Stephen Hemminger + */ + +#include +#include +#include +#include +#include + +static DEFINE_SPINLOCK(tcp_ca_list_lock); +static LIST_HEAD(tcp_ca_list); + +char sysctl_tcp_ca_protocol[TCP_CA_NAME_MAX] = +#if defined(CONFIG_TCP_CONG_BIC) + "bic"; +#elif defined(CONFIG_TCP_CONG_WESTWOOD) + "westwood"; +#elif defined(CONFIG_TCP_CONG_VEGAS) + "vegas"; +#else + "reno"; +#endif + +static struct tcp_ca_type *tcp_ca_find(const char *name) +{ + struct tcp_ca_type *match = NULL; + struct list_head *entry; + + rcu_read_lock(); + list_for_each_rcu(entry, &tcp_ca_list) { + struct tcp_ca_type *ca + = list_entry(entry, struct tcp_ca_type, list); + + if (strcmp(ca->name, name) == 0) { + match = ca; + break; + } + } + rcu_read_unlock(); + return match; +} + +void tcp_ca_register(struct tcp_ca_type *ca) +{ + BUG_ON(tcp_ca_find(ca->name)); + + spin_lock_irq(&tcp_ca_list_lock); + list_add_tail_rcu(&ca->list, &tcp_ca_list); + spin_unlock_irq(&tcp_ca_list_lock); + + printk(KERN_INFO "TCP %s registered\n", ca->name); +} + +void tcp_ca_unregister(struct tcp_ca_type *ca) +{ + spin_lock(&tcp_ca_list_lock); + list_del_rcu(&ca->list); + spin_unlock(&tcp_ca_list_lock); +} + +/* allow setting on boot cmdline */ +static int __init tcp_congestion_setup(char *str) +{ + strncpy(sysctl_tcp_ca_protocol, str, TCP_CA_NAME_MAX-1); + return 0; +} +__setup("tcp_congestion=", tcp_congestion_setup); + +/* When starting a new connection, pin down the current choice of + * congestion algorithm. + * NB: this depends on tcp_reno being always available. + */ +void tcp_ca_init(struct tcp_sock *tp) +{ + struct tcp_ca_type *ca; + + if (tp->ca_proto) + return; + + ca = tcp_ca_find(sysctl_tcp_ca_protocol); + + if (!ca && capable(CAP_SYS_MODULE)) { + request_module("tcp_%s", sysctl_tcp_ca_protocol); + ca = tcp_ca_find(sysctl_tcp_ca_protocol); + } + + if (!ca || !try_module_get(ca->owner)) { + if (net_ratelimit()) + printk(KERN_WARNING "%s unavailable using TCP reno\n", + sysctl_tcp_ca_protocol); + tp->ca_proto = &tcp_reno; + } else { + tp->ca_proto = ca; + ca->start(tp); + } +} + +void tcp_ca_destroy(struct tcp_sock *tp) +{ + if (tp->ca_proto) { + module_put(tp->ca_proto->owner); + tp->ca_proto = NULL; + } +} + +EXPORT_SYMBOL_GPL(tcp_ca_register); +EXPORT_SYMBOL_GPL(tcp_ca_unregister); diff -urNp -X dontdiff linux-2.6/net/ipv4/tcp_diag.c tcp-2.6/net/ipv4/tcp_diag.c --- linux-2.6/net/ipv4/tcp_diag.c 2005-03-14 14:30:52.000000000 -0800 +++ tcp-2.6/net/ipv4/tcp_diag.c 2005-03-11 16:13:46.000000000 -0800 @@ -61,7 +61,6 @@ static int tcpdiag_fill(struct sk_buff * 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)); @@ -73,9 +72,6 @@ static int tcpdiag_fill(struct sk_buff * 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->sk_family; r->tcpdiag_state = sk->sk_state; @@ -166,20 +162,6 @@ static int tcpdiag_fill(struct sk_buff * if (info) tcp_get_info(sk, info); - if (vinfo) { - if (tcp_is_vegas(tp)) { - vinfo->tcpv_enabled = tp->vegas.doing_vegas_now; - vinfo->tcpv_rttcnt = tp->vegas.cntRTT; - vinfo->tcpv_rtt = jiffies_to_usecs(tp->vegas.baseRTT); - vinfo->tcpv_minrtt = jiffies_to_usecs(tp->vegas.minRTT); - } else { - vinfo->tcpv_enabled = 0; - vinfo->tcpv_rttcnt = 0; - vinfo->tcpv_rtt = jiffies_to_usecs(tp->westwood.rtt); - vinfo->tcpv_minrtt = jiffies_to_usecs(tp->westwood.rtt_min); - } - } - nlh->nlmsg_len = skb->tail - b; return skb->len; diff -urNp -X dontdiff linux-2.6/net/ipv4/tcp_input.c tcp-2.6/net/ipv4/tcp_input.c --- linux-2.6/net/ipv4/tcp_input.c 2005-03-14 14:30:52.000000000 -0800 +++ tcp-2.6/net/ipv4/tcp_input.c 2005-03-11 16:13:46.000000000 -0800 @@ -61,7 +61,6 @@ * Panu Kuhlberg: Experimental audit of TCP (re)transmission * engine. Lots of bugs are found. * Pasi Sarolahti: F-RTO for dealing with spurious RTOs - * Angelo Dell'Aera: TCP Westwood+ support */ #include @@ -87,23 +86,9 @@ int sysctl_tcp_rfc1337; int sysctl_tcp_max_orphans = NR_FILE; int sysctl_tcp_frto; int sysctl_tcp_nometrics_save; -int sysctl_tcp_westwood; -int sysctl_tcp_vegas_cong_avoid; int sysctl_tcp_moderate_rcvbuf = 1; -/* Default values of the Vegas variables, in fixed-point representation - * with V_PARAM_SHIFT bits to the right of the binary point. - */ -#define V_PARAM_SHIFT 1 -int sysctl_tcp_vegas_alpha = 1<snd_cwnd_stamp = tcp_time_stamp; } -static void init_bictcp(struct tcp_sock *tp) -{ - tp->bictcp.cnt = 0; - - tp->bictcp.last_max_cwnd = 0; - tp->bictcp.last_cwnd = 0; - tp->bictcp.last_stamp = 0; -} - /* 5. Recalculate window clamp after socket hit its memory bounds. */ static void tcp_clamp_window(struct sock *sk, struct tcp_sock *tp) { @@ -557,45 +533,6 @@ static void tcp_event_data_recv(struct s tcp_grow_window(sk, tp, skb); } -/* When starting a new connection, pin down the current choice of - * congestion algorithm. - */ -void tcp_ca_init(struct tcp_sock *tp) -{ - 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); - } -} - -/* Do RTT sampling needed for Vegas. - * Basically we: - * o min-filter RTT samples from within an RTT to get the current - * propagation delay + queuing delay (we are min-filtering to try to - * avoid the effects of delayed ACKs) - * o min-filter RTT samples from a much longer window (forever for now) - * to find the propagation delay (baseRTT) - */ -static inline void vegas_rtt_calc(struct tcp_sock *tp, __u32 rtt) -{ - __u32 vrtt = rtt + 1; /* Never allow zero rtt or baseRTT */ - - /* Filter to find propagation delay: */ - if (vrtt < tp->vegas.baseRTT) - tp->vegas.baseRTT = vrtt; - - /* Find the min RTT during the last RTT to find - * the current prop. delay + queuing delay: - */ - tp->vegas.minRTT = min(tp->vegas.minRTT, vrtt); - tp->vegas.cntRTT++; -} - /* Called to compute a smoothed rtt estimate. The data fed to this * routine either comes from timestamps, or from segments that were * known _not_ to have been retransmitted [see Karn/Partridge @@ -609,9 +546,6 @@ static void tcp_rtt_estimator(struct tcp { long m = mrtt; /* RTT */ - if (tcp_vegas_enabled(tp)) - vegas_rtt_calc(tp, mrtt); - /* The following amusing code comes from Jacobson's * article in SIGCOMM '88. Note that rtt and mdev * are scaled versions of rtt and mean deviation. @@ -669,7 +603,8 @@ static void tcp_rtt_estimator(struct tcp tp->rtt_seq = tp->snd_nxt; } - tcp_westwood_update_rtt(tp, tp->srtt >> 3); + if (tp->ca_proto->rtt_sample) + tp->ca_proto->rtt_sample(tp, mrtt); } /* Calculate rto without backoff. This is the second half of Van Jacobson's @@ -1184,8 +1119,7 @@ void tcp_enter_frto(struct sock *sk) tp->snd_una == tp->high_seq || (tp->ca_state == TCP_CA_Loss && !tp->retransmits)) { tp->prior_ssthresh = tcp_current_ssthresh(tp); - if (!tcp_westwood_ssthresh(tp)) - tp->snd_ssthresh = tcp_recalc_ssthresh(tp); + tcp_ca_event(tp, CA_EVENT_FRTO); } /* Have to clear retransmission markers here to keep the bookkeeping @@ -1251,8 +1185,6 @@ static void tcp_enter_frto_loss(struct s tcp_set_ca_state(tp, TCP_CA_Loss); tp->high_seq = tp->frto_highmark; TCP_ECN_queue_cwr(tp); - - init_bictcp(tp); } void tcp_clear_retrans(struct tcp_sock *tp) @@ -1282,7 +1214,7 @@ void tcp_enter_loss(struct sock *sk, int if (tp->ca_state <= TCP_CA_Disorder || tp->snd_una == tp->high_seq || (tp->ca_state == TCP_CA_Loss && !tp->retransmits)) { tp->prior_ssthresh = tcp_current_ssthresh(tp); - tp->snd_ssthresh = tcp_recalc_ssthresh(tp); + tp->snd_ssthresh = tp->ca_proto->ssthresh(tp); } tp->snd_cwnd = 1; tp->snd_cwnd_cnt = 0; @@ -1313,6 +1245,7 @@ void tcp_enter_loss(struct sock *sk, int tp->reordering = min_t(unsigned int, tp->reordering, sysctl_tcp_reordering); + tcp_set_ca_state(tp, TCP_CA_Loss); tp->high_seq = tp->snd_nxt; TCP_ECN_queue_cwr(tp); @@ -1599,24 +1532,11 @@ static inline void tcp_moderate_cwnd(str static void tcp_cwnd_down(struct tcp_sock *tp) { int decr = tp->snd_cwnd_cnt + 1; - __u32 limit; - - /* - * TCP Westwood - * Here limit is evaluated as BWestimation*RTTmin (for obtaining it - * in packets we use mss_cache). If sysctl_tcp_westwood is off - * tcp_westwood_bw_rttmin() returns 0. In such case snd_ssthresh is - * still used as usual. It prevents other strange cases in which - * BWE*RTTmin could assume value 0. It should not happen but... - */ - - if (!(limit = tcp_westwood_bw_rttmin(tp))) - limit = tp->snd_ssthresh/2; tp->snd_cwnd_cnt = decr&1; decr >>= 1; - if (decr && tp->snd_cwnd > limit) + if (decr && tp->snd_cwnd > tp->ca_proto->min_cwnd(tp)) tp->snd_cwnd -= decr; tp->snd_cwnd = min(tp->snd_cwnd, tcp_packets_in_flight(tp)+1); @@ -1763,10 +1683,8 @@ static int tcp_try_undo_loss(struct sock static inline void tcp_complete_cwr(struct tcp_sock *tp) { - if (tcp_westwood_cwnd(tp)) - tp->snd_ssthresh = tp->snd_cwnd; - else - tp->snd_cwnd = min(tp->snd_cwnd, tp->snd_ssthresh); + tcp_ca_event(tp, CA_EVENT_COMPLETE_CWR); + tp->snd_cwnd = min(tp->snd_cwnd, tp->snd_ssthresh); tp->snd_cwnd_stamp = tcp_time_stamp; } @@ -1942,7 +1860,7 @@ tcp_fastretrans_alert(struct sock *sk, u if (tp->ca_state < TCP_CA_CWR) { if (!(flag&FLAG_ECE)) tp->prior_ssthresh = tcp_current_ssthresh(tp); - tp->snd_ssthresh = tcp_recalc_ssthresh(tp); + tp->snd_ssthresh = tp->ca_proto->ssthresh(tp); TCP_ECN_queue_cwr(tp); } @@ -2015,322 +1933,13 @@ static inline void tcp_ack_update_rtt(st tcp_ack_no_tstamp(tp, seq_rtt, flag); } -/* - * Compute congestion window to use. - * - * This is from the implementation of BICTCP in - * Lison-Xu, Kahaled Harfoush, and Injog Rhee. - * "Binary Increase Congestion Control for Fast, Long Distance - * Networks" in InfoComm 2004 - * Available from: - * http://www.csc.ncsu.edu/faculty/rhee/export/bitcp.pdf - * - * Unless BIC is enabled and congestion window is large - * this behaves the same as the original Reno. - */ -static inline __u32 bictcp_cwnd(struct tcp_sock *tp) -{ - /* orignal Reno behaviour */ - if (!tcp_is_bic(tp)) - return tp->snd_cwnd; - - if (tp->bictcp.last_cwnd == tp->snd_cwnd && - (s32)(tcp_time_stamp - tp->bictcp.last_stamp) <= (HZ>>5)) - return tp->bictcp.cnt; - - tp->bictcp.last_cwnd = tp->snd_cwnd; - tp->bictcp.last_stamp = tcp_time_stamp; - - /* start off normal */ - if (tp->snd_cwnd <= sysctl_tcp_bic_low_window) - tp->bictcp.cnt = tp->snd_cwnd; - - /* binary increase */ - else if (tp->snd_cwnd < tp->bictcp.last_max_cwnd) { - __u32 dist = (tp->bictcp.last_max_cwnd - tp->snd_cwnd) - / BICTCP_B; - - if (dist > BICTCP_MAX_INCREMENT) - /* linear increase */ - tp->bictcp.cnt = tp->snd_cwnd / BICTCP_MAX_INCREMENT; - else if (dist <= 1U) - /* binary search increase */ - tp->bictcp.cnt = tp->snd_cwnd * BICTCP_FUNC_OF_MIN_INCR - / BICTCP_B; - else - /* binary search increase */ - tp->bictcp.cnt = tp->snd_cwnd / dist; - } else { - /* slow start amd linear increase */ - if (tp->snd_cwnd < tp->bictcp.last_max_cwnd + BICTCP_B) - /* slow start */ - tp->bictcp.cnt = tp->snd_cwnd * BICTCP_FUNC_OF_MIN_INCR - / BICTCP_B; - else if (tp->snd_cwnd < tp->bictcp.last_max_cwnd - + BICTCP_MAX_INCREMENT*(BICTCP_B-1)) - /* slow start */ - tp->bictcp.cnt = tp->snd_cwnd * (BICTCP_B-1) - / (tp->snd_cwnd-tp->bictcp.last_max_cwnd); - else - /* linear increase */ - tp->bictcp.cnt = tp->snd_cwnd / BICTCP_MAX_INCREMENT; - } - return tp->bictcp.cnt; -} - -/* This is Jacobson's slow start and congestion avoidance. - * SIGCOMM '88, p. 328. - */ -static inline void reno_cong_avoid(struct tcp_sock *tp) +static inline void tcp_cong_avoid(struct tcp_sock *tp, u32 ack, u32 seq_rtt, + u32 in_flight) { - if (tp->snd_cwnd <= tp->snd_ssthresh) { - /* In "safe" area, increase. */ - if (tp->snd_cwnd < tp->snd_cwnd_clamp) - tp->snd_cwnd++; - } else { - /* In dangerous area, increase slowly. - * In theory this is tp->snd_cwnd += 1 / tp->snd_cwnd - */ - if (tp->snd_cwnd_cnt >= bictcp_cwnd(tp)) { - if (tp->snd_cwnd < tp->snd_cwnd_clamp) - tp->snd_cwnd++; - tp->snd_cwnd_cnt=0; - } else - tp->snd_cwnd_cnt++; - } + tp->ca_proto->cong_avoid(tp, ack, seq_rtt, in_flight); tp->snd_cwnd_stamp = tcp_time_stamp; } -/* This is based on the congestion detection/avoidance scheme described in - * Lawrence S. Brakmo and Larry L. Peterson. - * "TCP Vegas: End to end congestion avoidance on a global internet." - * IEEE Journal on Selected Areas in Communication, 13(8):1465--1480, - * October 1995. Available from: - * ftp://ftp.cs.arizona.edu/xkernel/Papers/jsac.ps - * - * See http://www.cs.arizona.edu/xkernel/ for their implementation. - * The main aspects that distinguish this implementation from the - * Arizona Vegas implementation are: - * o We do not change the loss detection or recovery mechanisms of - * Linux in any way. Linux already recovers from losses quite well, - * using fine-grained timers, NewReno, and FACK. - * o To avoid the performance penalty imposed by increasing cwnd - * only every-other RTT during slow start, we increase during - * every RTT during slow start, just like Reno. - * o Largely to allow continuous cwnd growth during slow start, - * we use the rate at which ACKs come back as the "actual" - * rate, rather than the rate at which data is sent. - * o To speed convergence to the right rate, we set the cwnd - * to achieve the right ("actual") rate when we exit slow start. - * o To filter out the noise caused by delayed ACKs, we use the - * minimum RTT sample observed during the last RTT to calculate - * the actual rate. - * o When the sender re-starts from idle, it waits until it has - * received ACKs for an entire flight of new data before making - * a cwnd adjustment decision. The original Vegas implementation - * assumed senders never went idle. - */ -static void vegas_cong_avoid(struct tcp_sock *tp, u32 ack, u32 seq_rtt) -{ - /* The key players are v_beg_snd_una and v_beg_snd_nxt. - * - * These are so named because they represent the approximate values - * of snd_una and snd_nxt at the beginning of the current RTT. More - * precisely, they represent the amount of data sent during the RTT. - * At the end of the RTT, when we receive an ACK for v_beg_snd_nxt, - * we will calculate that (v_beg_snd_nxt - v_beg_snd_una) outstanding - * bytes of data have been ACKed during the course of the RTT, giving - * an "actual" rate of: - * - * (v_beg_snd_nxt - v_beg_snd_una) / (rtt duration) - * - * Unfortunately, v_beg_snd_una is not exactly equal to snd_una, - * because delayed ACKs can cover more than one segment, so they - * don't line up nicely with the boundaries of RTTs. - * - * Another unfortunate fact of life is that delayed ACKs delay the - * advance of the left edge of our send window, so that the number - * of bytes we send in an RTT is often less than our cwnd will allow. - * So we keep track of our cwnd separately, in v_beg_snd_cwnd. - */ - - if (after(ack, tp->vegas.beg_snd_nxt)) { - /* Do the Vegas once-per-RTT cwnd adjustment. */ - u32 old_wnd, old_snd_cwnd; - - - /* Here old_wnd is essentially the window of data that was - * sent during the previous RTT, and has all - * been acknowledged in the course of the RTT that ended - * with the ACK we just received. Likewise, old_snd_cwnd - * is the cwnd during the previous RTT. - */ - old_wnd = (tp->vegas.beg_snd_nxt - tp->vegas.beg_snd_una) / - tp->mss_cache_std; - old_snd_cwnd = tp->vegas.beg_snd_cwnd; - - /* Save the extent of the current window so we can use this - * at the end of the next RTT. - */ - tp->vegas.beg_snd_una = tp->vegas.beg_snd_nxt; - tp->vegas.beg_snd_nxt = tp->snd_nxt; - tp->vegas.beg_snd_cwnd = tp->snd_cwnd; - - /* Take into account the current RTT sample too, to - * decrease the impact of delayed acks. This double counts - * this sample since we count it for the next window as well, - * but that's not too awful, since we're taking the min, - * rather than averaging. - */ - vegas_rtt_calc(tp, seq_rtt); - - /* We do the Vegas calculations only if we got enough RTT - * samples that we can be reasonably sure that we got - * at least one RTT sample that wasn't from a delayed ACK. - * If we only had 2 samples total, - * then that means we're getting only 1 ACK per RTT, which - * means they're almost certainly delayed ACKs. - * If we have 3 samples, we should be OK. - */ - - if (tp->vegas.cntRTT <= 2) { - /* We don't have enough RTT samples to do the Vegas - * calculation, so we'll behave like Reno. - */ - if (tp->snd_cwnd > tp->snd_ssthresh) - tp->snd_cwnd++; - } else { - u32 rtt, target_cwnd, diff; - - /* We have enough RTT samples, so, using the Vegas - * algorithm, we determine if we should increase or - * decrease cwnd, and by how much. - */ - - /* Pluck out the RTT we are using for the Vegas - * calculations. This is the min RTT seen during the - * last RTT. Taking the min filters out the effects - * of delayed ACKs, at the cost of noticing congestion - * a bit later. - */ - rtt = tp->vegas.minRTT; - - /* Calculate the cwnd we should have, if we weren't - * going too fast. - * - * This is: - * (actual rate in segments) * baseRTT - * We keep it as a fixed point number with - * V_PARAM_SHIFT bits to the right of the binary point. - */ - target_cwnd = ((old_wnd * tp->vegas.baseRTT) - << V_PARAM_SHIFT) / rtt; - - /* Calculate the difference between the window we had, - * and the window we would like to have. This quantity - * is the "Diff" from the Arizona Vegas papers. - * - * Again, this is a fixed point number with - * V_PARAM_SHIFT bits to the right of the binary - * point. - */ - diff = (old_wnd << V_PARAM_SHIFT) - target_cwnd; - - if (tp->snd_cwnd < tp->snd_ssthresh) { - /* Slow start. */ - if (diff > sysctl_tcp_vegas_gamma) { - /* Going too fast. Time to slow down - * and switch to congestion avoidance. - */ - tp->snd_ssthresh = 2; - - /* Set cwnd to match the actual rate - * exactly: - * cwnd = (actual rate) * baseRTT - * Then we add 1 because the integer - * truncation robs us of full link - * utilization. - */ - tp->snd_cwnd = min(tp->snd_cwnd, - (target_cwnd >> - V_PARAM_SHIFT)+1); - - } - } else { - /* Congestion avoidance. */ - u32 next_snd_cwnd; - - /* Figure out where we would like cwnd - * to be. - */ - if (diff > sysctl_tcp_vegas_beta) { - /* The old window was too fast, so - * we slow down. - */ - next_snd_cwnd = old_snd_cwnd - 1; - } else if (diff < sysctl_tcp_vegas_alpha) { - /* We don't have enough extra packets - * in the network, so speed up. - */ - next_snd_cwnd = old_snd_cwnd + 1; - } else { - /* Sending just as fast as we - * should be. - */ - next_snd_cwnd = old_snd_cwnd; - } - - /* Adjust cwnd upward or downward, toward the - * desired value. - */ - if (next_snd_cwnd > tp->snd_cwnd) - tp->snd_cwnd++; - else if (next_snd_cwnd < tp->snd_cwnd) - tp->snd_cwnd--; - } - } - - /* Wipe the slate clean for the next RTT. */ - tp->vegas.cntRTT = 0; - tp->vegas.minRTT = 0x7fffffff; - } - - /* The following code is executed for every ack we receive, - * except for conditions checked in should_advance_cwnd() - * before the call to tcp_cong_avoid(). Mainly this means that - * we only execute this code if the ack actually acked some - * data. - */ - - /* If we are in slow start, increase our cwnd in response to this ACK. - * (If we are not in slow start then we are in congestion avoidance, - * and adjust our congestion window only once per RTT. See the code - * above.) - */ - if (tp->snd_cwnd <= tp->snd_ssthresh) - tp->snd_cwnd++; - - /* to keep cwnd from growing without bound */ - tp->snd_cwnd = min_t(u32, tp->snd_cwnd, tp->snd_cwnd_clamp); - - /* Make sure that we are never so timid as to reduce our cwnd below - * 2 MSS. - * - * Going below 2 MSS would risk huge delayed ACKs from our receiver. - */ - tp->snd_cwnd = max(tp->snd_cwnd, 2U); - - tp->snd_cwnd_stamp = tcp_time_stamp; -} - -static inline void tcp_cong_avoid(struct tcp_sock *tp, u32 ack, u32 seq_rtt) -{ - if (tcp_vegas_enabled(tp)) - vegas_cong_avoid(tp, ack, seq_rtt); - else - reno_cong_avoid(tp); -} - /* Restart timer after forward progress on connection. * RFC2988 recommends to restart timer to now+rto. */ @@ -2620,256 +2229,6 @@ static void tcp_process_frto(struct sock tp->frto_counter = (tp->frto_counter + 1) % 3; } -/* - * TCP Westwood+ - */ - -/* - * @init_westwood - * This function initializes fields used in TCP Westwood+. We can't - * get no information about RTTmin at this time so we simply set it to - * TCP_WESTWOOD_INIT_RTT. This value was chosen to be too conservative - * since in this way we're sure it will be updated in a consistent - * way as soon as possible. It will reasonably happen within the first - * RTT period of the connection lifetime. - */ - -static void init_westwood(struct sock *sk) -{ - struct tcp_sock *tp = tcp_sk(sk); - - tp->westwood.bw_ns_est = 0; - tp->westwood.bw_est = 0; - tp->westwood.accounted = 0; - tp->westwood.cumul_ack = 0; - tp->westwood.rtt_win_sx = tcp_time_stamp; - tp->westwood.rtt = TCP_WESTWOOD_INIT_RTT; - tp->westwood.rtt_min = TCP_WESTWOOD_INIT_RTT; - tp->westwood.snd_una = tp->snd_una; -} - -/* - * @westwood_do_filter - * Low-pass filter. Implemented using constant coeffients. - */ - -static inline __u32 westwood_do_filter(__u32 a, __u32 b) -{ - return (((7 * a) + b) >> 3); -} - -static void westwood_filter(struct sock *sk, __u32 delta) -{ - struct tcp_sock *tp = tcp_sk(sk); - - tp->westwood.bw_ns_est = - westwood_do_filter(tp->westwood.bw_ns_est, - tp->westwood.bk / delta); - tp->westwood.bw_est = - westwood_do_filter(tp->westwood.bw_est, - tp->westwood.bw_ns_est); -} - -/* - * @westwood_update_rttmin - * It is used to update RTTmin. In this case we MUST NOT use - * WESTWOOD_RTT_MIN minimum bound since we could be on a LAN! - */ - -static inline __u32 westwood_update_rttmin(const struct sock *sk) -{ - const struct tcp_sock *tp = tcp_sk(sk); - __u32 rttmin = tp->westwood.rtt_min; - - if (tp->westwood.rtt != 0 && - (tp->westwood.rtt < tp->westwood.rtt_min || !rttmin)) - rttmin = tp->westwood.rtt; - - return rttmin; -} - -/* - * @westwood_acked - * Evaluate increases for dk. - */ - -static inline __u32 westwood_acked(const struct sock *sk) -{ - const struct tcp_sock *tp = tcp_sk(sk); - - return tp->snd_una - tp->westwood.snd_una; -} - -/* - * @westwood_new_window - * It evaluates if we are receiving data inside the same RTT window as - * when we started. - * Return value: - * It returns 0 if we are still evaluating samples in the same RTT - * window, 1 if the sample has to be considered in the next window. - */ - -static int westwood_new_window(const struct sock *sk) -{ - const struct tcp_sock *tp = tcp_sk(sk); - __u32 left_bound; - __u32 rtt; - int ret = 0; - - left_bound = tp->westwood.rtt_win_sx; - rtt = max(tp->westwood.rtt, (u32) TCP_WESTWOOD_RTT_MIN); - - /* - * A RTT-window has passed. Be careful since if RTT is less than - * 50ms we don't filter but we continue 'building the sample'. - * This minimum limit was choosen since an estimation on small - * time intervals is better to avoid... - * Obvioulsy on a LAN we reasonably will always have - * right_bound = left_bound + WESTWOOD_RTT_MIN - */ - - if ((left_bound + rtt) < tcp_time_stamp) - ret = 1; - - return ret; -} - -/* - * @westwood_update_window - * It updates RTT evaluation window if it is the right moment to do - * it. If so it calls filter for evaluating bandwidth. - */ - -static void __westwood_update_window(struct sock *sk, __u32 now) -{ - struct tcp_sock *tp = tcp_sk(sk); - __u32 delta = now - tp->westwood.rtt_win_sx; - - 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) -{ - if (westwood_new_window(sk)) - __westwood_update_window(sk, now); -} - -/* - * @__tcp_westwood_fast_bw - * It is called when we are in fast path. In particular it is called when - * header prediction is successfull. In such case infact update is - * straight forward and doesn't need any particular care. - */ - -static void __tcp_westwood_fast_bw(struct sock *sk, struct sk_buff *skb) -{ - struct tcp_sock *tp = tcp_sk(sk); - - westwood_update_window(sk, tcp_time_stamp); - - tp->westwood.bk += westwood_acked(sk); - tp->westwood.snd_una = tp->snd_una; - tp->westwood.rtt_min = westwood_update_rttmin(sk); -} - -static inline void tcp_westwood_fast_bw(struct sock *sk, struct sk_buff *skb) -{ - if (tcp_is_westwood(tcp_sk(sk))) - __tcp_westwood_fast_bw(sk, skb); -} - - -/* - * @westwood_dupack_update - * It updates accounted and cumul_ack when receiving a dupack. - */ - -static void westwood_dupack_update(struct sock *sk) -{ - struct tcp_sock *tp = tcp_sk(sk); - - tp->westwood.accounted += tp->mss_cache_std; - tp->westwood.cumul_ack = tp->mss_cache_std; -} - -static inline int westwood_may_change_cumul(struct tcp_sock *tp) -{ - return (tp->westwood.cumul_ack > tp->mss_cache_std); -} - -static inline void westwood_partial_update(struct tcp_sock *tp) -{ - tp->westwood.accounted -= tp->westwood.cumul_ack; - tp->westwood.cumul_ack = tp->mss_cache_std; -} - -static inline void westwood_complete_update(struct tcp_sock *tp) -{ - tp->westwood.cumul_ack -= tp->westwood.accounted; - tp->westwood.accounted = 0; -} - -/* - * @westwood_acked_count - * This function evaluates cumul_ack for evaluating dk in case of - * delayed or partial acks. - */ - -static inline __u32 westwood_acked_count(struct sock *sk) -{ - struct tcp_sock *tp = tcp_sk(sk); - - tp->westwood.cumul_ack = westwood_acked(sk); - - /* If cumul_ack is 0 this is a dupack since it's not moving - * tp->snd_una. - */ - if (!(tp->westwood.cumul_ack)) - westwood_dupack_update(sk); - - if (westwood_may_change_cumul(tp)) { - /* Partial or delayed ack */ - if (tp->westwood.accounted >= tp->westwood.cumul_ack) - westwood_partial_update(tp); - else - westwood_complete_update(tp); - } - - tp->westwood.snd_una = tp->snd_una; - - return tp->westwood.cumul_ack; -} - - -/* - * @__tcp_westwood_slow_bw - * It is called when something is going wrong..even if there could - * be no problems! Infact a simple delayed packet may trigger a - * dupack. But we need to be careful in such case. - */ - -static void __tcp_westwood_slow_bw(struct sock *sk, struct sk_buff *skb) -{ - struct tcp_sock *tp = tcp_sk(sk); - - westwood_update_window(sk, tcp_time_stamp); - - tp->westwood.bk += westwood_acked_count(sk); - tp->westwood.rtt_min = westwood_update_rttmin(sk); -} - -static inline void tcp_westwood_slow_bw(struct sock *sk, struct sk_buff *skb) -{ - if (tcp_is_westwood(tcp_sk(sk))) - __tcp_westwood_slow_bw(sk, skb); -} /* This routine deals with incoming acks, but not outgoing ones. */ static int tcp_ack(struct sock *sk, struct sk_buff *skb, int flag) @@ -2898,9 +2257,10 @@ static int tcp_ack(struct sock *sk, stru */ tcp_update_wl(tp, ack, ack_seq); tp->snd_una = ack; - tcp_westwood_fast_bw(sk, skb); flag |= FLAG_WIN_UPDATE; + tcp_ca_event(tp, CA_EVENT_FAST_ACK); + NET_INC_STATS_BH(LINUX_MIB_TCPHPACKS); } else { if (ack_seq != TCP_SKB_CB(skb)->end_seq) @@ -2916,7 +2276,7 @@ static int tcp_ack(struct sock *sk, stru if (TCP_ECN_rcv_ecn_echo(tp, skb->h.th)) flag |= FLAG_ECE; - tcp_westwood_slow_bw(sk,skb); + tcp_ca_event(tp, CA_EVENT_SLOW_ACK); } /* We passed data and got it acked, remove any soft error @@ -2937,16 +2297,13 @@ static int tcp_ack(struct sock *sk, stru tcp_process_frto(sk, prior_snd_una); if (tcp_ack_is_dubious(tp, flag)) { - /* Advanve CWND, if state allows this. */ - if ((flag & FLAG_DATA_ACKED) && - (tcp_vegas_enabled(tp) || prior_in_flight >= tp->snd_cwnd) && - tcp_may_raise_cwnd(tp, flag)) - tcp_cong_avoid(tp, ack, seq_rtt); + /* Advance CWND, if state allows this. */ + if ((flag & FLAG_DATA_ACKED) && tcp_may_raise_cwnd(tp, flag)) + tcp_cong_avoid(tp, ack, seq_rtt, prior_in_flight); tcp_fastretrans_alert(sk, prior_snd_una, prior_packets, flag); } else { - if ((flag & FLAG_DATA_ACKED) && - (tcp_vegas_enabled(tp) || prior_in_flight >= tp->snd_cwnd)) - tcp_cong_avoid(tp, ack, seq_rtt); + if ((flag & FLAG_DATA_ACKED)) + tcp_cong_avoid(tp, ack, seq_rtt, prior_in_flight); } if ((flag & FLAG_FORWARD_PROGRESS) || !(flag&FLAG_NOT_DUP)) @@ -4713,8 +4070,7 @@ int tcp_rcv_state_process(struct sock *s if(tp->af_specific->conn_request(sk, skb) < 0) return 1; - init_westwood(sk); - init_bictcp(tp); + tcp_ca_init(tp); /* Now we have several options: In theory there is * nothing else in the frame. KA9Q has an option to @@ -4737,8 +4093,7 @@ int tcp_rcv_state_process(struct sock *s goto discard; case TCP_SYN_SENT: - init_westwood(sk); - init_bictcp(tp); + tcp_ca_init(tp); queued = tcp_rcv_synsent_state_process(sk, skb, th, len); if (queued >= 0) diff -urNp -X dontdiff linux-2.6/net/ipv4/tcp_ipv4.c tcp-2.6/net/ipv4/tcp_ipv4.c --- linux-2.6/net/ipv4/tcp_ipv4.c 2005-03-14 12:03:58.000000000 -0800 +++ tcp-2.6/net/ipv4/tcp_ipv4.c 2005-03-14 12:04:25.000000000 -0800 @@ -2058,7 +2058,6 @@ static int tcp_v4_init_sock(struct sock tp->snd_ssthresh = 0x7fffffff; /* Infinity */ tp->snd_cwnd_clamp = ~0; tp->mss_cache_std = tp->mss_cache = 536; - tp->reordering = sysctl_tcp_reordering; sk->sk_state = TCP_CLOSE; @@ -2082,6 +2081,8 @@ int tcp_v4_destroy_sock(struct sock *sk) tcp_clear_xmit_timers(sk); + tcp_ca_destroy(tp); + /* Cleanup up the write buffer. */ sk_stream_writequeue_purge(sk); diff -urNp -X dontdiff linux-2.6/net/ipv4/tcp_output.c tcp-2.6/net/ipv4/tcp_output.c --- linux-2.6/net/ipv4/tcp_output.c 2005-03-14 14:30:52.000000000 -0800 +++ tcp-2.6/net/ipv4/tcp_output.c 2005-03-11 16:13:46.000000000 -0800 @@ -111,8 +111,7 @@ static void tcp_cwnd_restart(struct tcp_ u32 restart_cwnd = tcp_init_cwnd(tp, dst); u32 cwnd = tp->snd_cwnd; - if (tcp_is_vegas(tp)) - tcp_vegas_enable(tp); + tcp_ca_event(tp, CA_EVENT_CWND_RESTART); tp->snd_ssthresh = tcp_current_ssthresh(tp); restart_cwnd = min(restart_cwnd, cwnd); @@ -304,18 +303,6 @@ static int tcp_transmit_skb(struct sock (tp->rx_opt.eff_sacks * TCPOLEN_SACK_PERBLOCK)); } - /* - * If the connection is idle and we are restarting, - * then we don't want to do any Vegas calculations - * until we get fresh RTT samples. So when we - * restart, we reset our Vegas state to a clean - * slate. After we get acks for this flight of - * packets, _then_ we can make Vegas calculations - * again. - */ - if (tcp_is_vegas(tp) && tcp_packets_in_flight(tp) == 0) - tcp_vegas_enable(tp); - th = (struct tcphdr *) skb_push(skb, tcp_header_size); skb->h.th = th; skb_set_owner_w(skb, sk); diff -urNp -X dontdiff linux-2.6/net/ipv4/tcp_reno.c tcp-2.6/net/ipv4/tcp_reno.c --- linux-2.6/net/ipv4/tcp_reno.c 1969-12-31 16:00:00.000000000 -0800 +++ tcp-2.6/net/ipv4/tcp_reno.c 2005-03-14 12:02:02.000000000 -0800 @@ -0,0 +1,63 @@ +/* + * TCP Reno congestion control + * + * This is special case used for fallback as well. + */ + +#include +#include +#include +#include + +/* This is Jacobson's slow start and congestion avoidance. + * SIGCOMM '88, p. 328. + */ +u32 tcp_reno_ssthresh(struct tcp_sock *tp) +{ + return max(tp->snd_cwnd >> 1U, 2U); +} +EXPORT_SYMBOL_GPL(tcp_reno_ssthresh); + +void tcp_reno_cong_avoid(struct tcp_sock *tp, u32 ack, u32 rtt, u32 in_flight) +{ + if (in_flight < tp->snd_cwnd) + return; + + if (tp->snd_cwnd <= tp->snd_ssthresh) { + /* In "safe" area, increase. */ + if (tp->snd_cwnd < tp->snd_cwnd_clamp) + tp->snd_cwnd++; + } else { + /* In dangerous area, increase slowly. + * In theory this is tp->snd_cwnd += 1 / tp->snd_cwnd + */ + if (tp->snd_cwnd_cnt >= tp->snd_cwnd) { + if (tp->snd_cwnd < tp->snd_cwnd_clamp) + tp->snd_cwnd++; + tp->snd_cwnd_cnt = 0; + } else + tp->snd_cwnd_cnt++; + } +} +EXPORT_SYMBOL_GPL(tcp_reno_cong_avoid); + +u32 tcp_reno_cwnd_min(struct tcp_sock *tp) +{ + return tp->snd_ssthresh/2; +} +EXPORT_SYMBOL_GPL(tcp_reno_cwnd_min); + +static void tcp_reno_start(struct tcp_sock *tp) +{ + return; +} + +struct tcp_ca_type tcp_reno = { + .start = tcp_reno_start, + .ssthresh = tcp_reno_ssthresh, + .min_cwnd = tcp_reno_cwnd_min, + .cong_avoid = tcp_reno_cong_avoid, + + .owner = THIS_MODULE, + .name = "reno", +}; diff -urNp -X dontdiff linux-2.6/net/ipv4/tcp_vegas.c tcp-2.6/net/ipv4/tcp_vegas.c --- linux-2.6/net/ipv4/tcp_vegas.c 1969-12-31 16:00:00.000000000 -0800 +++ tcp-2.6/net/ipv4/tcp_vegas.c 2005-03-14 11:46:52.000000000 -0800 @@ -0,0 +1,381 @@ +/* + * TCP Vegas congestion control + * + * This is based on the congestion detection/avoidance scheme described in + * Lawrence S. Brakmo and Larry L. Peterson. + * "TCP Vegas: End to end congestion avoidance on a global internet." + * IEEE Journal on Selected Areas in Communication, 13(8):1465--1480, + * October 1995. Available from: + * ftp://ftp.cs.arizona.edu/xkernel/Papers/jsac.ps + * + * See http://www.cs.arizona.edu/xkernel/ for their implementation. + * The main aspects that distinguish this implementation from the + * Arizona Vegas implementation are: + * o We do not change the loss detection or recovery mechanisms of + * Linux in any way. Linux already recovers from losses quite well, + * using fine-grained timers, NewReno, and FACK. + * o To avoid the performance penalty imposed by increasing cwnd + * only every-other RTT during slow start, we increase during + * every RTT during slow start, just like Reno. + * o Largely to allow continuous cwnd growth during slow start, + * we use the rate at which ACKs come back as the "actual" + * rate, rather than the rate at which data is sent. + * o To speed convergence to the right rate, we set the cwnd + * to achieve the right ("actual") rate when we exit slow start. + * o To filter out the noise caused by delayed ACKs, we use the + * minimum RTT sample observed during the last RTT to calculate + * the actual rate. + * o When the sender re-starts from idle, it waits until it has + * received ACKs for an entire flight of new data before making + * a cwnd adjustment decision. The original Vegas implementation + * assumed senders never went idle. + */ + +#include +#include +#include +#include + +/* Default values of the Vegas variables, in fixed-point representation + * with V_PARAM_SHIFT bits to the right of the binary point. + */ +#define V_PARAM_SHIFT 1 +static int alpha = 1<doing_vegas_now = 1; + + /* Set the beginning of the next send window. */ + vegas->beg_snd_nxt = tp->snd_nxt; + + vegas->cntRTT = 0; + vegas->minRTT = 0x7fffffff; +} + +/* Stop taking Vegas samples for now. */ +static inline void tcp_vegas_disable(struct tcp_sock *tp) +{ + struct tcp_vegas_info *vegas = tcp_ca(tp); + + vegas->doing_vegas_now = 0; +} + +static void tcp_vegas_start(struct tcp_sock *tp) +{ + struct tcp_vegas_info *vegas = tcp_ca(tp); + + vegas->baseRTT = 0x7fffffff; + tcp_vegas_enable(tp); +} + +/* Do RTT sampling needed for Vegas. + * Basically we: + * o min-filter RTT samples from within an RTT to get the current + * propagation delay + queuing delay (we are min-filtering to try to + * avoid the effects of delayed ACKs) + * o min-filter RTT samples from a much longer window (forever for now) + * to find the propagation delay (baseRTT) + */ +static void tcp_vegas_rtt_calc(struct tcp_sock *tp, u32 rtt) +{ + struct tcp_vegas_info *vegas = tcp_ca(tp); + u32 vrtt = rtt + 1; /* Never allow zero rtt or baseRTT */ + + /* Filter to find propagation delay: */ + if (vrtt < vegas->baseRTT) + vegas->baseRTT = vrtt; + + /* Find the min RTT during the last RTT to find + * the current prop. delay + queuing delay: + */ + vegas->minRTT = min(vegas->minRTT, vrtt); + vegas->cntRTT++; +} + +static void tcp_vegas_ca_state(struct tcp_sock *tp, u8 ca_state) +{ + if (ca_state == TCP_CA_Open) + tcp_vegas_enable(tp); + else + tcp_vegas_disable(tp); +} + +static void tcp_vegas_cwnd_event(struct tcp_sock *tp, enum tcp_ca_event event) +{ + if(event == CA_EVENT_CWND_RESTART) + tcp_vegas_enable(tp); +} + +static void tcp_vegas_cong_avoid(struct tcp_sock *tp, u32 ack, + u32 seq_rtt, u32 in_flight) +{ + struct tcp_vegas_info *vegas = tcp_ca(tp); + + if (!vegas->doing_vegas_now) { + tcp_reno_cong_avoid(tp, ack, seq_rtt, in_flight); + return; + } + + /* The key players are v_beg_snd_una and v_beg_snd_nxt. + * + * These are so named because they represent the approximate values + * of snd_una and snd_nxt at the beginning of the current RTT. More + * precisely, they represent the amount of data sent during the RTT. + * At the end of the RTT, when we receive an ACK for v_beg_snd_nxt, + * we will calculate that (v_beg_snd_nxt - v_beg_snd_una) outstanding + * bytes of data have been ACKed during the course of the RTT, giving + * an "actual" rate of: + * + * (v_beg_snd_nxt - v_beg_snd_una) / (rtt duration) + * + * Unfortunately, v_beg_snd_una is not exactly equal to snd_una, + * because delayed ACKs can cover more than one segment, so they + * don't line up nicely with the boundaries of RTTs. + * + * Another unfortunate fact of life is that delayed ACKs delay the + * advance of the left edge of our send window, so that the number + * of bytes we send in an RTT is often less than our cwnd will allow. + * So we keep track of our cwnd separately, in v_beg_snd_cwnd. + */ + + if (after(ack, vegas->beg_snd_nxt)) { + /* Do the Vegas once-per-RTT cwnd adjustment. */ + u32 old_wnd, old_snd_cwnd; + + + /* Here old_wnd is essentially the window of data that was + * sent during the previous RTT, and has all + * been acknowledged in the course of the RTT that ended + * with the ACK we just received. Likewise, old_snd_cwnd + * is the cwnd during the previous RTT. + */ + old_wnd = (vegas->beg_snd_nxt - vegas->beg_snd_una) / + tp->mss_cache_std; + old_snd_cwnd = vegas->beg_snd_cwnd; + + /* Save the extent of the current window so we can use this + * at the end of the next RTT. + */ + vegas->beg_snd_una = vegas->beg_snd_nxt; + vegas->beg_snd_nxt = tp->snd_nxt; + vegas->beg_snd_cwnd = tp->snd_cwnd; + + /* Take into account the current RTT sample too, to + * decrease the impact of delayed acks. This double counts + * this sample since we count it for the next window as well, + * but that's not too awful, since we're taking the min, + * rather than averaging. + */ + tcp_vegas_rtt_calc(tp, seq_rtt); + + /* We do the Vegas calculations only if we got enough RTT + * samples that we can be reasonably sure that we got + * at least one RTT sample that wasn't from a delayed ACK. + * If we only had 2 samples total, + * then that means we're getting only 1 ACK per RTT, which + * means they're almost certainly delayed ACKs. + * If we have 3 samples, we should be OK. + */ + + if (vegas->cntRTT <= 2) { + /* We don't have enough RTT samples to do the Vegas + * calculation, so we'll behave like Reno. + */ + if (tp->snd_cwnd > tp->snd_ssthresh) + tp->snd_cwnd++; + } else { + u32 rtt, target_cwnd, diff; + + /* We have enough RTT samples, so, using the Vegas + * algorithm, we determine if we should increase or + * decrease cwnd, and by how much. + */ + + /* Pluck out the RTT we are using for the Vegas + * calculations. This is the min RTT seen during the + * last RTT. Taking the min filters out the effects + * of delayed ACKs, at the cost of noticing congestion + * a bit later. + */ + rtt = vegas->minRTT; + + /* Calculate the cwnd we should have, if we weren't + * going too fast. + * + * This is: + * (actual rate in segments) * baseRTT + * We keep it as a fixed point number with + * V_PARAM_SHIFT bits to the right of the binary point. + */ + target_cwnd = ((old_wnd * vegas->baseRTT) + << V_PARAM_SHIFT) / rtt; + + /* Calculate the difference between the window we had, + * and the window we would like to have. This quantity + * is the "Diff" from the Arizona Vegas papers. + * + * Again, this is a fixed point number with + * V_PARAM_SHIFT bits to the right of the binary + * point. + */ + diff = (old_wnd << V_PARAM_SHIFT) - target_cwnd; + + if (tp->snd_cwnd < tp->snd_ssthresh) { + /* Slow start. */ + if (diff > gamma) { + /* Going too fast. Time to slow down + * and switch to congestion avoidance. + */ + tp->snd_ssthresh = 2; + + /* Set cwnd to match the actual rate + * exactly: + * cwnd = (actual rate) * baseRTT + * Then we add 1 because the integer + * truncation robs us of full link + * utilization. + */ + tp->snd_cwnd = min(tp->snd_cwnd, + (target_cwnd >> + V_PARAM_SHIFT)+1); + + } + } else { + /* Congestion avoidance. */ + u32 next_snd_cwnd; + + /* Figure out where we would like cwnd + * to be. + */ + if (diff > beta) { + /* The old window was too fast, so + * we slow down. + */ + next_snd_cwnd = old_snd_cwnd - 1; + } else if (diff < alpha) { + /* We don't have enough extra packets + * in the network, so speed up. + */ + next_snd_cwnd = old_snd_cwnd + 1; + } else { + /* Sending just as fast as we + * should be. + */ + next_snd_cwnd = old_snd_cwnd; + } + + /* Adjust cwnd upward or downward, toward the + * desired value. + */ + if (next_snd_cwnd > tp->snd_cwnd) + tp->snd_cwnd++; + else if (next_snd_cwnd < tp->snd_cwnd) + tp->snd_cwnd--; + } + } + + /* Wipe the slate clean for the next RTT. */ + vegas->cntRTT = 0; + vegas->minRTT = 0x7fffffff; + } + + /* The following code is executed for every ack we receive, + * except for conditions checked in should_advance_cwnd() + * before the call to tcp_cong_avoid(). Mainly this means that + * we only execute this code if the ack actually acked some + * data. + */ + + /* If we are in slow start, increase our cwnd in response to this ACK. + * (If we are not in slow start then we are in congestion avoidance, + * and adjust our congestion window only once per RTT. See the code + * above.) + */ + if (tp->snd_cwnd <= tp->snd_ssthresh) + tp->snd_cwnd++; + + /* to keep cwnd from growing without bound */ + tp->snd_cwnd = min_t(u32, tp->snd_cwnd, tp->snd_cwnd_clamp); + + /* Make sure that we are never so timid as to reduce our cwnd below + * 2 MSS. + * + * Going below 2 MSS would risk huge delayed ACKs from our receiver. + */ + tp->snd_cwnd = max(tp->snd_cwnd, 2U); +} + +static struct tcp_ca_type tcp_vegas = { + .start = tcp_vegas_start, + .ssthresh = tcp_reno_ssthresh, + .min_cwnd = tcp_reno_cwnd_min, + .cong_avoid = tcp_vegas_cong_avoid, + .rtt_sample = tcp_vegas_rtt_calc, + .set_state = tcp_vegas_ca_state, + .cwnd_event = tcp_vegas_cwnd_event, + + .owner = THIS_MODULE, + .name = "vegas", +}; + +static int __init tcp_vegas_init(void) +{ + BUILD_BUG_ON(sizeof(struct tcp_vegas_info) > TCP_CA_PRIV_SIZE); + tcp_ca_register(&tcp_vegas); + return 0; +} + +static void __exit tcp_vegas_exit(void) +{ + tcp_ca_unregister(&tcp_vegas); +} + +module_init(tcp_vegas_init); +module_exit(tcp_vegas_exit); + +MODULE_AUTHOR("Stephen Hemminger"); +MODULE_LICENSE("GPL"); +MODULE_DESCRIPTION("TCP Vegas"); + + diff -urNp -X dontdiff linux-2.6/net/ipv4/tcp_westwood.c tcp-2.6/net/ipv4/tcp_westwood.c --- linux-2.6/net/ipv4/tcp_westwood.c 1969-12-31 16:00:00.000000000 -0800 +++ tcp-2.6/net/ipv4/tcp_westwood.c 2005-03-14 11:48:01.000000000 -0800 @@ -0,0 +1,326 @@ +/* + * TCP Westwood+ + * + * Angelo Dell'Aera: TCP Westwood+ support + */ + +#include +#include +#include +#include + +/* TCP Westwood structure */ +struct tcp_westwood_info { + u32 bw_ns_est; /* first bandwidth estimation..not too smoothed 8) */ + u32 bw_est; /* bandwidth estimate */ + u32 rtt_win_sx; /* here starts a new evaluation... */ + u32 bk; + u32 snd_una; /* used for evaluating the number of acked bytes */ + u32 cumul_ack; + u32 accounted; + u32 rtt; + u32 rtt_min; /* minimum observed RTT */ +}; + + +/* TCP Westwood functions and constants */ +#define TCP_WESTWOOD_INIT_RTT (20*HZ) /* maybe too conservative?! */ +#define TCP_WESTWOOD_RTT_MIN (HZ/20) /* 50ms */ + +/* + * @tcp_westwood_create + * This function initializes fields used in TCP Westwood+. We can't + * get no information about RTTmin at this time so we simply set it to + * TCP_WESTWOOD_INIT_RTT. This value was chosen to be too conservative + * since in this way we're sure it will be updated in a consistent + * way as soon as possible. It will reasonably happen within the first + * RTT period of the connection lifetime. + */ +static void tcp_westwood_start(struct tcp_sock *tp) +{ + struct tcp_westwood_info *w = tcp_ca(tp); + + w->bw_ns_est = 0; + w->bw_est = 0; + w->accounted = 0; + w->cumul_ack = 0; + w->rtt_win_sx = tcp_time_stamp; + w->rtt = TCP_WESTWOOD_INIT_RTT; + w->rtt_min = TCP_WESTWOOD_INIT_RTT; + w->snd_una = tp->snd_una; +} + +/* + * @westwood_do_filter + * Low-pass filter. Implemented using constant coefficents. + */ +static inline u32 westwood_do_filter(u32 a, u32 b) +{ + return (((7 * a) + b) >> 3); +} + +static inline void westwood_filter(struct tcp_westwood_info *w, u32 delta) +{ + w->bw_ns_est = westwood_do_filter(w->bw_ns_est, w->bk / delta); + w->bw_est = westwood_do_filter(w->bw_est, w->bw_ns_est); +} + +/* + * @westwood_update_rttmin + * It is used to update RTTmin. In this case we MUST NOT use + * WESTWOOD_RTT_MIN minimum bound since we could be on a LAN! + */ +static inline u32 westwood_update_rttmin(const struct tcp_westwood_info *w) +{ + u32 rttmin = w->rtt_min; + + if (w->rtt != 0 && + (w->rtt < w->rtt_min || !rttmin)) + rttmin = w->rtt; + + return rttmin; +} + +static void tcp_westwood_sample_rtt(struct tcp_sock *tp, u32 rtt) +{ + struct tcp_westwood_info *w = tcp_ca(tp); + w->rtt = tp->srtt >> 3; +} + +/* + * @westwood_acked + * Evaluate increases for dk. + */ +static inline u32 westwood_acked(struct tcp_sock *tp) +{ + struct tcp_westwood_info *w = tcp_ca(tp); + return tp->snd_una - w->snd_una; +} + +/* + * @westwood_new_window + * It evaluates if we are receiving data inside the same RTT window as + * when we started. + * Return value: + * It returns 0 if we are still evaluating samples in the same RTT + * window, 1 if the sample has to be considered in the next window. + */ +static inline int westwood_new_window(const struct tcp_sock *tp) +{ + struct tcp_westwood_info *w = tcp_ca(tp); + u32 left_bound; + u32 rtt; + int ret = 0; + + left_bound = w->rtt_win_sx; + rtt = max(w->rtt, (u32) TCP_WESTWOOD_RTT_MIN); + + /* + * A RTT-window has passed. Be careful since if RTT is less than + * 50ms we don't filter but we continue 'building the sample'. + * This minimum limit was choosen since an estimation on small + * time intervals is better to avoid... + * Obvioulsy on a LAN we reasonably will always have + * right_bound = left_bound + WESTWOOD_RTT_MIN + */ + + if ((left_bound + rtt) < tcp_time_stamp) + ret = 1; + + return ret; +} + +/* + * @westwood_update_window + * It updates RTT evaluation window if it is the right moment to do + * it. If so it calls filter for evaluating bandwidth. + */ +static void westwood_update_window(struct tcp_sock *tp, u32 now) +{ + struct tcp_westwood_info *w = tcp_ca(tp); + if (westwood_new_window(tp)) { + u32 delta = now - w->rtt_win_sx; + + if (delta) { + if (w->rtt) + westwood_filter(w, delta); + + w->bk = 0; + w->rtt_win_sx = tcp_time_stamp; + } + } +} + +/* + * @tcp_westwood_fast_bw + * It is called when we are in fast path. In particular it is called when + * header prediction is successfull. In such case infact update is + * straight forward and doesn't need any particular care. + */ +static void tcp_westwood_fast_bw(struct tcp_sock *tp) +{ + struct tcp_westwood_info *w = tcp_ca(tp); + westwood_update_window(tp, tcp_time_stamp); + + w->bk += westwood_acked(tp); + w->snd_una = tp->snd_una; + w->rtt_min = westwood_update_rttmin(w); +} + +/* + * @westwood_acked_count + * This function evaluates cumul_ack for evaluating dk in case of + * delayed or partial acks. + */ +static u32 westwood_acked_count(struct tcp_sock *tp) +{ + struct tcp_westwood_info *w = tcp_ca(tp); + + w->cumul_ack = westwood_acked(tp); + + /* If cumul_ack is 0 this is a dupack since it's not moving + * tp->snd_una. + */ + if (!w->cumul_ack) { + w->accounted += tp->mss_cache_std; + w->cumul_ack = tp->mss_cache_std; + } + + if (w->cumul_ack > tp->mss_cache_std) { + /* Partial or delayed ack */ + if (w->accounted >= w->cumul_ack) { + w->accounted -= w->cumul_ack; + w->cumul_ack = tp->mss_cache_std; + } else { + w->cumul_ack -= w->accounted; + w->accounted = 0; + } + } + + w->snd_una = tp->snd_una; + + return w->cumul_ack; +} + + +/* + * @tcp_westwood_slow_bw + * It is called when something is going wrong..even if there could + * be no problems! Infact a simple delayed packet may trigger a + * dupack. But we need to be careful in such case. + */ +static void tcp_westwood_slow_bw(struct tcp_sock *tp) +{ + struct tcp_westwood_info *w = tcp_ca(tp); + + westwood_update_window(tp, tcp_time_stamp); + + w->bk += westwood_acked_count(tp); + w->rtt_min = westwood_update_rttmin(w); +} + +static inline u32 tcp_westwood_bw_rttmin(const struct tcp_sock *tp) +{ + struct tcp_westwood_info *w = tcp_ca(tp); + + return max((w->bw_est) * (w->rtt_min) / (u32) (tp->mss_cache_std), + 2U); +} + +static inline u32 tcp_westwood_ssthresh(struct tcp_sock *tp) +{ + u32 ssthresh = tcp_westwood_bw_rttmin(tp); + if (ssthresh) + tp->snd_ssthresh = ssthresh; + + return (ssthresh != 0); +} + +static inline int tcp_westwood_cwnd(struct tcp_sock *tp) +{ + u32 cwnd = 0; + + cwnd = tcp_westwood_bw_rttmin(tp); + if (cwnd) + tp->snd_cwnd = cwnd; + + return (cwnd != 0); +} + +/* + * TCP Westwood + * Here limit is evaluated as BWestimation*RTTmin (for obtaining it + * in packets we use mss_cache). If sysctl_tcp_westwood is off + * tcp_westwood_bw_rttmin() returns 0. In such case snd_ssthresh is + * still used as usual. It prevents other strange cases in which + * BWE*RTTmin could assume value 0. It should not happen but... + */ +static u32 tcp_westwood_cwnd_min(struct tcp_sock *tp) +{ + u32 limit; + + limit = tcp_westwood_bw_rttmin(tp); + if (limit == 0) + limit = tp->snd_ssthresh/2; + return limit; +} + +static void tcp_westwood_event(struct tcp_sock *tp, enum tcp_ca_event event) +{ + switch(event) { + case CA_EVENT_CWND_RESTART: + break; + + case CA_EVENT_COMPLETE_CWR: + if (tcp_westwood_cwnd(tp)) + tp->snd_ssthresh = tp->snd_cwnd; + break; + + case CA_EVENT_FRTO: + if (!tcp_westwood_ssthresh(tp)) + tp->snd_ssthresh = tcp_westwood_ssthresh(tp); + break; + + case CA_EVENT_FAST_ACK: + tcp_westwood_fast_bw(tp); + break; + + case CA_EVENT_SLOW_ACK: + tcp_westwood_slow_bw(tp); + break; + + } +} + +static struct tcp_ca_type tcp_westwood = { + .start = tcp_westwood_start, + .ssthresh = tcp_reno_ssthresh, + .rtt_sample = tcp_westwood_sample_rtt, + .cong_avoid = tcp_reno_cong_avoid, + .min_cwnd = tcp_westwood_cwnd_min, + .cwnd_event = tcp_westwood_event, + + .owner = THIS_MODULE, + .name = "westwood" +}; + +static int __init tcp_westwood_init(void) +{ + BUILD_BUG_ON(sizeof(struct tcp_westwood_info) > TCP_CA_PRIV_SIZE); + tcp_ca_register(&tcp_westwood); + return 0; +} + +static void __exit tcp_westwood_exit(void) +{ + tcp_ca_unregister(&tcp_westwood); +} + +module_init(tcp_westwood_init); +module_exit(tcp_westwood_exit); + +MODULE_AUTHOR("Stephen Hemminger, Angelo Del'Aera"); +MODULE_LICENSE("GPL"); +MODULE_DESCRIPTION("TCP Westwood+"); + + From ak@muc.de Mon Mar 14 15:27:34 2005 Received: with ECARTIS (v1.0.0; list netdev); Mon, 14 Mar 2005 15:27:39 -0800 (PST) Received: from one.firstfloor.org (one.firstfloor.org [213.235.205.2]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j2ENRXjS029566 for ; Mon, 14 Mar 2005 15:27:33 -0800 Received: by one.firstfloor.org (Postfix, from userid 502) id 73564D033E; Tue, 15 Mar 2005 00:27:32 +0100 (CET) To: "Leonid Grossman" Cc: , , , alex@neterion.com Subject: Re: [ANNOUNCE] Experimental Driver for Neterion/S2io 10GbE Adapters References: <20050314123815.73e7ee78.davem@davemloft.net> <200503142054.j2EKs2DD003697@guinness.s2io.com> From: Andi Kleen Date: Tue, 15 Mar 2005 00:27:32 +0100 In-Reply-To: <200503142054.j2EKs2DD003697@guinness.s2io.com> (Leonid Grossman's message of "Mon, 14 Mar 2005 12:53:57 -0800") Message-ID: User-Agent: Gnus/5.110002 (No Gnus v0.2) Emacs/21.3 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Virus-Scanned: ClamAV 0.83/762/Sun Mar 13 15:35:33 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 119 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: ak@muc.de Precedence: bulk X-list: netdev Content-Length: 1457 Lines: 31 "Leonid Grossman" writes: > > Do you have other objections to the submission? We'd like to see if these > could be addressed; going forward we see significant benefits both for > S2io/Neterion (and our customers) and for community to use this driver. I guess the main objection to the HAL comes not from performance issues (Usually the only thing that really counts for performance is data cache misses and the HAL is unlikely to affect this much), but the coding style etc.. Indeed it does not look too Linux like. One thing that's frowned upon in Linux are lots of wrappers for standard functions (like spin_lock etc.). I would recommend to at least replace them with the standard Linux functions. In principle this can be even done with some kind of preprocessor Also less ifdefs would be nice. An possible compromise might be to get rid of all the HAL parts that wraps Linux functionality, and then only use a leaner low level library to access the more difficult parts of the hardware. This would involve moving more code into the Linux specific layers. This should be more low level code, nothing like the high level queue handling functions you currently have etc., with the high level logic all in Linux code -Andi P.S.: The patch would be much easier to read if it created new files instead of changing the old ones. This makes sense since the new driver will probably live next to the old one for some time. From romieu@fr.zoreil.com Mon Mar 14 15:32:13 2005 Received: with ECARTIS (v1.0.0; list netdev); Mon, 14 Mar 2005 15:32:20 -0800 (PST) Received: from fr.zoreil.com (electric-eye.fr.zoreil.com [213.41.134.224]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j2ENWB58030355 for ; Mon, 14 Mar 2005 15:32:12 -0800 Received: from electric-eye.fr.zoreil.com (localhost.localdomain [127.0.0.1]) by fr.zoreil.com (8.13.1/8.12.1) with ESMTP id j2ENVFeL020658; Tue, 15 Mar 2005 00:31:16 +0100 Received: (from romieu@localhost) by electric-eye.fr.zoreil.com (8.13.1/8.13.1/Submit) id j2ENV3h3020657; Tue, 15 Mar 2005 00:31:03 +0100 Date: Tue, 15 Mar 2005 00:31:03 +0100 From: Francois Romieu To: netdev@oss.sgi.com Cc: jgarzik@pobox.com, Jon Mason , Stephen Hemminger , mark@kiora.ath.cx Subject: [patch linux-2.6.11-bk10 1/1] r8169: incoming frame length check Message-ID: <20050314233103.GC16072@electric-eye.fr.zoreil.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.4.1i X-Organisation: Land of Sunshine Inc. X-Virus-Scanned: ClamAV 0.83/762/Sun Mar 13 15:35:33 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 120 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: romieu@fr.zoreil.com Precedence: bulk X-list: netdev Content-Length: 3311 Lines: 102 The size of the incoming frame is not correctly checked. The RxMaxSize register (0xDA) does not work as expected and incoming frames whose size exceeds the MTU actually end spanning multiple descriptors. The first Rx descriptor contains the size of the whole frame (or some garbage in its place). The driver does not expect something above the space allocated to the current skb and crashes loudly when it issues a skb_put. The fix contains two parts: - disable hardware Rx size filtering: so far it only proved to be able to trigger some new fancy errors; - drop multi-descriptors frame: as the driver allocates MTU sized Rx buffers, it provides an adequate filtering. As a bonus, wrong descriptors were not returned to the asic after their processing. Signed-off-by: Francois Romieu diff -puN drivers/net/r8169.c~r8169-570 drivers/net/r8169.c --- linux-2.6.11/drivers/net/r8169.c~r8169-570 2005-03-13 23:35:37.000000000 +0100 +++ linux-2.6.11-fr/drivers/net/r8169.c 2005-03-14 23:47:56.529014957 +0100 @@ -1585,8 +1585,8 @@ rtl8169_hw_start(struct net_device *dev) RTL_W8(ChipCmd, CmdTxEnb | CmdRxEnb); RTL_W8(EarlyTxThres, EarlyTxThld); - /* For gigabit rtl8169, MTU + header + CRC + VLAN */ - RTL_W16(RxMaxSize, tp->rx_buf_sz); + /* Low hurts. Let's disable the filtering. */ + RTL_W16(RxMaxSize, 16383); /* Set Rx Config register */ i = rtl8169_rx_config | @@ -2127,6 +2127,11 @@ rtl8169_tx_interrupt(struct net_device * } } +static inline int rtl8169_fragmented_frame(u32 status) +{ + return (status & (FirstFrag | LastFrag)) != (FirstFrag | LastFrag); +} + static inline void rtl8169_rx_csum(struct sk_buff *skb, struct RxDesc *desc) { u32 opts1 = le32_to_cpu(desc->opts1); @@ -2177,27 +2182,41 @@ rtl8169_rx_interrupt(struct net_device * while (rx_left > 0) { unsigned int entry = cur_rx % NUM_RX_DESC; + struct RxDesc *desc = tp->RxDescArray + entry; u32 status; rmb(); - status = le32_to_cpu(tp->RxDescArray[entry].opts1); + status = le32_to_cpu(desc->opts1); if (status & DescOwn) break; if (status & RxRES) { - printk(KERN_INFO "%s: Rx ERROR!!!\n", dev->name); + printk(KERN_INFO "%s: Rx ERROR. status = %08x\n", + dev->name, status); tp->stats.rx_errors++; if (status & (RxRWT | RxRUNT)) tp->stats.rx_length_errors++; if (status & RxCRC) tp->stats.rx_crc_errors++; + rtl8169_mark_to_asic(desc, tp->rx_buf_sz); } else { - struct RxDesc *desc = tp->RxDescArray + entry; struct sk_buff *skb = tp->Rx_skbuff[entry]; int pkt_size = (status & 0x00001FFF) - 4; void (*pci_action)(struct pci_dev *, dma_addr_t, size_t, int) = pci_dma_sync_single_for_device; + /* + * The driver does not support incoming fragmented + * frames. They are seen as a symptom of over-mtu + * sized frames. + */ + if (unlikely(rtl8169_fragmented_frame(status))) { + tp->stats.rx_dropped++; + tp->stats.rx_length_errors++; + rtl8169_mark_to_asic(desc, tp->rx_buf_sz); + goto move_on; + } + rtl8169_rx_csum(skb, desc); pci_dma_sync_single_for_cpu(tp->pci_dev, @@ -2224,7 +2243,7 @@ rtl8169_rx_interrupt(struct net_device * tp->stats.rx_bytes += pkt_size; tp->stats.rx_packets++; } - +move_on: cur_rx++; rx_left--; } _ From jgarzik@pobox.com Mon Mar 14 15:47:06 2005 Received: with ECARTIS (v1.0.0; list netdev); Mon, 14 Mar 2005 15:47:12 -0800 (PST) Received: from parcelfarce.linux.theplanet.co.uk (IDENT:93@parcelfarce.linux.theplanet.co.uk [195.92.249.252]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j2ENkj0c031127 for ; Mon, 14 Mar 2005 15:47:06 -0800 Received: from [69.134.152.124] (helo=[10.10.10.88]) by parcelfarce.linux.theplanet.co.uk with asmtp (TLSv1:AES256-SHA:256) (Exim 4.33) id 1DAzGg-0002BR-0Q; Mon, 14 Mar 2005 23:46:39 +0000 Message-ID: <42362232.4070202@pobox.com> Date: Mon, 14 Mar 2005 18:45:54 -0500 From: Jeff Garzik User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.3) Gecko/20040922 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Andi Kleen CC: Leonid Grossman , netdev@oss.sgi.com, leonid@neterion.com, alex@neterion.com, "David S. Miller" Subject: Re: [ANNOUNCE] Experimental Driver for Neterion/S2io 10GbE Adapters References: <20050314123815.73e7ee78.davem@davemloft.net> <200503142054.j2EKs2DD003697@guinness.s2io.com> In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV 0.83/762/Sun Mar 13 15:35:33 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 121 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: jgarzik@pobox.com Precedence: bulk X-list: netdev Content-Length: 1449 Lines: 38 Andi Kleen wrote: > "Leonid Grossman" writes: > >>Do you have other objections to the submission? We'd like to see if these >>could be addressed; going forward we see significant benefits both for >>S2io/Neterion (and our customers) and for community to use this driver. > > > I guess the main objection to the HAL comes not from performance > issues (Usually the only thing that really counts for performance > is data cache misses and the HAL is unlikely to affect this much), but > the coding style etc.. Indeed it does not look too Linux like. Well, not coding style, but code analysis and maintenance issues. HALs are generally type-opaque, breaking checker-style tools and sparse checks. "it looks like Linux code" has implications on bug finding and fixing, and long term maintenance of the code. You want to make it easy for someone to make the same change across N net drivers. Because most ->hard_start_xmit() hooks were written in a similar fashion, it was easy and quick to deploy fixes for the skb_padto() security bug across many net drivers. A lot of tiny costs that mostly wind up as noise: additional branching / derefs. My biggest objection is that HALs increase the overall "cost" of maintaining a piece of code, and serve as a barrier against outside (non-primary-author) kernel hacker involvement. Remember, this driver is going to be with us for -10- years or more. Jeff From tgraf@suug.ch Mon Mar 14 16:14:01 2005 Received: with ECARTIS (v1.0.0; list netdev); Mon, 14 Mar 2005 16:14:08 -0800 (PST) Received: from b.mx.projectdream.org (eth0-0.arisu.projectdream.org [194.158.4.191]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j2F0E1Wf032350 for ; Mon, 14 Mar 2005 16:14:01 -0800 Received: from postel.suug.ch (postel.suug.ch [195.134.158.23]) (using TLSv1 with cipher EDH-RSA-DES-CBC3-SHA (168/168 bits)) (No client certificate requested) by b.mx.projectdream.org (Postfix) with ESMTP id 9E0288C; Tue, 15 Mar 2005 01:13:35 +0100 (CET) Received: by postel.suug.ch (Postfix, from userid 10001) id 01E8C1C0EA; Tue, 15 Mar 2005 01:14:18 +0100 (CET) Date: Tue, 15 Mar 2005 01:14:17 +0100 From: Thomas Graf To: "David S. Miller" Cc: YOSHIFUJI Hideaki , netdev@oss.sgi.com Subject: [PATCH] [IPV6] Use dev_get_flags() while building inet6 ifinfo message Message-ID: <20050315001417.GB3086@postel.suug.ch> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline X-Virus-Scanned: ClamAV 0.83/762/Sun Mar 13 15:35:33 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 122 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: tgraf@suug.ch Precedence: bulk X-list: netdev Content-Length: 726 Lines: 21 Use dev_get_flags() in inet6_fill_ifinfo() to fetch interface flags to ensure correctly reporting IFF_PROMISC and IFF_ALLMULTI flags. Signed-off-by: Thomas Graf --- linux-2.6.11-bk10.orig/net/ipv6/addrconf.c 2005-03-14 19:40:28.000000000 +0100 +++ linux-2.6.11-bk10/net/ipv6/addrconf.c 2005-03-14 21:08:28.000000000 +0100 @@ -2923,12 +2923,8 @@ r->ifi_family = AF_INET6; r->ifi_type = dev->type; r->ifi_index = dev->ifindex; - r->ifi_flags = dev->flags; + r->ifi_flags = dev_get_flags(dev); r->ifi_change = 0; - if (!netif_running(dev) || !netif_carrier_ok(dev)) - r->ifi_flags &= ~IFF_RUNNING; - else - r->ifi_flags |= IFF_RUNNING; RTA_PUT(skb, IFLA_IFNAME, strlen(dev->name)+1, dev->name); From yoshfuji@linux-ipv6.org Mon Mar 14 16:24:27 2005 Received: with ECARTIS (v1.0.0; list netdev); Mon, 14 Mar 2005 16:24:32 -0800 (PST) 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 j2F0OR8H004416 for ; Mon, 14 Mar 2005 16:24:27 -0800 Received: from localhost (localhost [127.0.0.1]) by yue.st-paulia.net (Postfix) with ESMTP id E5E9533CC2; Tue, 15 Mar 2005 09:26:11 +0900 (JST) Date: Tue, 15 Mar 2005 09:26:10 +0900 (JST) Message-Id: <20050315.092610.112709648.yoshfuji@linux-ipv6.org> To: tgraf@suug.ch, davem@davemloft.net Cc: netdev@oss.sgi.com Subject: Re: [PATCH] [IPV6] Use dev_get_flags() while building inet6 ifinfo message From: YOSHIFUJI Hideaki / =?iso-2022-jp?B?GyRCNUhGIzFRTEAbKEI=?= In-Reply-To: <20050315001417.GB3086@postel.suug.ch> References: <20050315001417.GB3086@postel.suug.ch> Organization: USAGI Project X-URL: http://www.yoshifuji.org/%7Ehideaki/ X-Fingerprint: 9022 65EB 1ECF 3AD1 0BDF 80D8 4807 F894 E062 0EEA X-PGP-Key-URL: http://www.yoshifuji.org/%7Ehideaki/hideaki@yoshifuji.org.asc X-Face: "5$Al-.M>NJ%a'@hhZdQm:."qn~PA^gq4o*>iCFToq*bAi#4FRtx}enhuQKz7fNqQz\BYU] $~O_5m-9'}MIs`XGwIEscw;e5b>n"B_?j/AkL~i/MEaZBLP X-Mailer: Mew version 2.2 on Emacs 20.7 / Mule 4.1 (AOI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV 0.83/762/Sun Mar 13 15:35:33 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 123 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: yoshfuji@linux-ipv6.org Precedence: bulk X-list: netdev Content-Length: 334 Lines: 10 In article <20050315001417.GB3086@postel.suug.ch> (at Tue, 15 Mar 2005 01:14:17 +0100), Thomas Graf says: > Use dev_get_flags() in inet6_fill_ifinfo() to fetch interface flags > to ensure correctly reporting IFF_PROMISC and IFF_ALLMULTI flags. > > Signed-off-by: Thomas Graf sane to me. --yoshfuji From shemminger@osdl.org Mon Mar 14 16:34:33 2005 Received: with ECARTIS (v1.0.0; list netdev); Mon, 14 Mar 2005 16:34:38 -0800 (PST) Received: from smtp.osdl.org (fire.osdl.org [65.172.181.4]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j2F0YVDJ005077 for ; Mon, 14 Mar 2005 16:34:32 -0800 Received: from shell0.pdx.osdl.net (fw.osdl.org [65.172.181.6]) by smtp.osdl.org (8.12.8/8.12.8) with ESMTP id j2F0YLqi027721 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO); Mon, 14 Mar 2005 16:34:22 -0800 Received: from dxpl.pdx.osdl.net (dxpl.pdx.osdl.net [172.20.1.103]) by shell0.pdx.osdl.net (8.13.1/8.11.6) with ESMTP id j2F0YKjR027157; Mon, 14 Mar 2005 16:34:20 -0800 Date: Mon, 14 Mar 2005 16:34:38 -0800 From: Stephen Hemminger To: linux-net@vger.kernel.org, lartc@mailman.ds9a.nl Cc: netdev@oss.sgi.com Subject: [ANNOUNCE] iproute2-2.6.11-050314 Message-ID: <20050314163438.1f73ec6d@dxpl.pdx.osdl.net> Organization: Open Source Development Lab X-Mailer: Sylpheed-Claws 1.0.1 (GTK+ 1.2.10; x86_64-unknown-linux-gnu) X-Face: &@E+xe?c%:&e4D{>f1O<&U>2qwRREG5!}7R4;D<"NO^UI2mJ[eEOA2*3>(`Th.yP,VDPo9$ /`~cw![cmj~~jWe?AHY7D1S+\}5brN0k*NE?pPh_'_d>6;XGG[\KDRViCfumZT3@[ Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Received-SPF: pass (domain of shemminger@osdl.org designates 65.172.181.6 as permitted sender) X-MIMEDefang-Filter: osdl$Revision: 1.104 $ X-Scanned-By: MIMEDefang 2.36 X-Virus-Scanned: ClamAV 0.83/762/Sun Mar 13 15:35:33 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 125 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: shemminger@osdl.org Precedence: bulk X-list: netdev Content-Length: 356 Lines: 21 New version of Iproute2 is available: http://developer.osdl.org/dev/iproute2/download/iproute2-2.6.11-050314.tar.gz Changes: Boian Bonev TC batch mode to read commands from file. Thomas Graf ip link command displays carrier status Patrick McHardy use user hz Jamal Hadi Salim Fix ipt registration Me Batch mode cleanup. IP tables build fix From leonid.grossman@neterion.com Mon Mar 14 16:34:20 2005 Received: with ECARTIS (v1.0.0; list netdev); Mon, 14 Mar 2005 16:34:25 -0800 (PST) Received: from ns1.s2io.com (ns1.s2io.com [142.46.200.198]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j2F0YJpe005067 for ; Mon, 14 Mar 2005 16:34:20 -0800 Received: from guinness.s2io.com (sentry.s2io.com [142.46.200.199]) by ns1.s2io.com (8.12.10/8.12.10) with ESMTP id j2F0XBuN013667; Mon, 14 Mar 2005 19:33:11 -0500 (EST) Received: from lgt40 ([10.16.16.75]) by guinness.s2io.com (8.12.6/8.12.6) with ESMTP id j2F0WRDD011602; Mon, 14 Mar 2005 19:32:27 -0500 (EST) Message-Id: <200503150032.j2F0WRDD011602@guinness.s2io.com> From: "Leonid Grossman" To: "'Jeff Garzik'" , "'Andi Kleen'" Cc: , , , "'David S. Miller'" Subject: RE: [ANNOUNCE] Experimental Driver for Neterion/S2io 10GbE Adapters Date: Mon, 14 Mar 2005 16:32:22 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook, Build 11.0.5510 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1409 In-Reply-To: <42362232.4070202@pobox.com> Thread-Index: AcUo8BPWt13Uo3P8T16TyDJilm6uLwAAZYhw X-Scanned-By: MIMEDefang 2.34 X-Virus-Scanned: ClamAV 0.83/762/Sun Mar 13 15:35:33 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 124 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: leonid.grossman@neterion.com Precedence: bulk X-list: netdev Content-Length: 3488 Lines: 84 > -----Original Message----- > From: Jeff Garzik [mailto:jgarzik@pobox.com] > Sent: Monday, March 14, 2005 3:46 PM > To: Andi Kleen > Cc: Leonid Grossman; netdev@oss.sgi.com; leonid@neterion.com; > alex@neterion.com; David S. Miller > Subject: Re: [ANNOUNCE] Experimental Driver for Neterion/S2io 10GbE > Adapters > > Andi Kleen wrote: > > "Leonid Grossman" writes: > > > >>Do you have other objections to the submission? We'd like to see if > these > >>could be addressed; going forward we see significant benefits both for > >>S2io/Neterion (and our customers) and for community to use this driver. > > > > > > I guess the main objection to the HAL comes not from performance > > issues (Usually the only thing that really counts for performance > > is data cache misses and the HAL is unlikely to affect this much), but > > the coding style etc.. Indeed it does not look too Linux like. > > Well, not coding style, but code analysis and maintenance issues. > > HALs are generally type-opaque, breaking checker-style tools and sparse > checks. > > "it looks like Linux code" has implications on bug finding and fixing, > and long term maintenance of the code. You want to make it easy for > someone to make the same change across N net drivers. > > Because most ->hard_start_xmit() hooks were written in a similar > fashion, it was easy and quick to deploy fixes for the skb_padto() > security bug across many net drivers. > > A lot of tiny costs that mostly wind up as noise: additional branching > / derefs. > > My biggest objection is that HALs increase the overall "cost" of > maintaining a piece of code, and serve as a barrier against outside > (non-primary-author) kernel hacker involvement. There are several valid arguments against HAL-based MAC drivers, but the maintenance cost is probably one of the main arguments in the "for" column. My assumption is that the vast majority of the maintenance for the hw-dependent code will be done by Neterion team - and for us the HAL-based approach allows to fix a bug or to add a new feature in hw-dependent code once and for all across all drivers. In our experience, third-party contribution tends to come to the OS-specific part of the driver not to the HAL - but if there is a meaningful contribution to the HAL from one of our Unix driver, it will be useful to pick it up in a transparent fashion. Agreed that HAL makes code analysis and changes by the outside hacker somewhat more difficult - but hopefully not by much, and again I expect most of the outside contribution to be done above HAL level. Also, we are trying to ease the pain by releasing HAL API and ASIC Programming Manual documentation. > > Remember, this driver is going to be with us for -10- years or more. Yes, and this was actually a second reason for the submission. Present "s2io" driver is fine for the current and next ASIC, beyond that we will have to probably re-write it anyways. The new submission is 2+ years "younger" and has a much better chance to require an incremental upgrade only. Since 10GbE is just taking off and not a lot of people got familiar with the code, we feel it's easier to take this hit earlier than later. To sum it up, I agree that HAL is a trade-off - but for this hardware it has been working well for us in multi-platform environment; the hope is that you will find a (smaller, perhaps) subset of these benefits useful in Linux environment as well. Leonid > > Jeff > From afleming@freescale.com Mon Mar 14 16:41:23 2005 Received: with ECARTIS (v1.0.0; list netdev); Mon, 14 Mar 2005 16:41:28 -0800 (PST) Received: from az33egw01.freescale.net (az33egw01.freescale.net [192.88.158.102]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j2F0fNat006138 for ; Mon, 14 Mar 2005 16:41:23 -0800 Received: from az33smr02.freescale.net (az33smr02.freescale.net [10.64.34.200]) by az33egw01.freescale.net (8.12.11/az33egw01) with ESMTP id j2F0hKQV028839; Mon, 14 Mar 2005 17:43:25 -0700 (MST) Received: from [10.82.16.201] ([10.82.16.201]) by az33smr02.freescale.net (8.13.1/8.13.0) with ESMTP id j2F0gRdP007608; Mon, 14 Mar 2005 18:42:27 -0600 (CST) In-Reply-To: <4230D1AC.5070506@katalix.com> References: <1107b64b01fb8e9a6c84359bb56881a6@freescale.com> <1110334456.32556.21.camel@gaston> <20050308194229.41c23707.davem@davemloft.net> <1110340214.32524.32.camel@gaston> <57a429f8eb807987d88b06129861d507@freescale.com> <4230D1AC.5070506@katalix.com> Mime-Version: 1.0 (Apple Message framework v619.2) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: Content-Transfer-Encoding: 7bit Cc: netdev@oss.sgi.com, "David S. Miller" , linuxppc-embedded@ozlabs.org, Benjamin Herrenschmidt From: Andy Fleming Subject: Re: RFC: PHY Abstraction Layer II Date: Mon, 14 Mar 2005 18:41:10 -0600 To: James Chapman X-Mailer: Apple Mail (2.619.2) X-Virus-Scanned: ClamAV 0.83/762/Sun Mar 13 15:35:33 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 126 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: afleming@freescale.com Precedence: bulk X-list: netdev Content-Length: 2036 Lines: 50 On Mar 10, 2005, at 17:01, James Chapman wrote: > Hi Andy, > > Can you elaborate on why this phy abstraction is needed? > > In your original post, you mentioned that you were going to post a > patch to show how your code would be hooked up in an existing net > driver. Did I miss it? It would help in understanding the pros and cons > of using genphy over using plain old mii.c. Hi James, I haven't posted it yet, since it's a large patch (it deletes a lot of code from my driver), but I can give a basic overview of how my driver hooks into this code: 1) The driver connects to the PHY when opened, calling phy_connect, and then clears some bits to declare functionality it doesn't support (my driver, for instance, does not support gigabit in half-duplex mode). 2) The driver implements a function which reads the speed/duplex settings, and modifies the controller registers as appropriate (also bringing the carrier up and down depending on link state). My driver needs to note whether it's gigabit or not (for GMII vs MII mode), and the duplex (to set the MAC full or half). Both of those steps are very straightforward. The PHY layer will invoke the callback whenever the link state changes, so the controller will always be up-to-date. 3) The third step is the part that can make things a little messier. My driver implements a second driver for the MDIO bus, which is connected through its registers. This bus needs to be registered, and the driver also needs to register. Then some code needs to be written to deal with initialization, and takedown. I can send out that patch anytime, if there's demand. > > btw, I recently posted a patch to add GigE support to mii.c which is > in Jeff's netdev-2.6 queue. Some register definitions were added in > mii.h that will collide with yours. Yeah, I ran in to some of those. I can't remember whether they're in the patch or not, I suspect not. I will have to submit a new patch to cover those (I just changed my code to use your definitions). Andy From alex@neterion.com Mon Mar 14 17:08:55 2005 Received: with ECARTIS (v1.0.0; list netdev); Mon, 14 Mar 2005 17:08:59 -0800 (PST) Received: from ns1.s2io.com (ns1.s2io.com [142.46.200.198]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j2F18sjq007654 for ; Mon, 14 Mar 2005 17:08:54 -0800 Received: from guinness.s2io.com (sentry.s2io.com [142.46.200.199]) by ns1.s2io.com (8.12.10/8.12.10) with ESMTP id j2F18GuN014001; Mon, 14 Mar 2005 20:08:16 -0500 (EST) Received: from aaizmanlt ([10.16.16.78]) by guinness.s2io.com (8.12.6/8.12.6) with ESMTP id j2F18FDD016965; Mon, 14 Mar 2005 20:08:15 -0500 (EST) Message-Id: <200503150108.j2F18FDD016965@guinness.s2io.com> Reply-To: From: "Alex Aizman" To: "'Andi Kleen'" , "'Leonid Grossman'" Cc: , , Subject: RE: [ANNOUNCE] Experimental Driver for Neterion/S2io 10GbE Adapters Date: Mon, 14 Mar 2005 17:07:44 -0800 Organization: neterion MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook, Build 11.0.5510 In-Reply-To: X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 Thread-Index: AcUo7WqOR9kQG616RWi2m3tBhTo9eAABn6Ow X-Scanned-By: MIMEDefang 2.34 X-Virus-Scanned: ClamAV 0.83/762/Sun Mar 13 15:35:33 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 127 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: alex@neterion.com Precedence: bulk X-list: netdev Content-Length: 3731 Lines: 89 Andi Kleen writes: > I guess the main objection to the HAL comes not from > performance issues But the second or the third objection comes from there, I guess... As far as the data path, HAL as a "layer" completely disappears. There is just a few inline instructions that post descriptors and process completed descriptors. These same instructions are unavoidable; they'd be present HAL or no-HAL. There's no HAL locks on the data path (the locks are compiled out), no HAL (as a "layer") induced overhead. Note that the performance was one persistent "paranoia" from the very start of this project. The numbers also tell the tale. We have 7.6Gbps jumbo throughput, the bottleneck is PCI, not the host. We have 13us 1byte netpipe latency. Here's for example today's netpipe run: [root@localhost root]# ./nptcp -a -t -l 256 -u 98304 -i 256 -p 5100 -P - h 17.1.1.227 Latency: 0.000013 Now starting main loop 0: 256 bytes 7 times --> 131.37 Mbps in 0.000015 sec 1: 512 bytes 65 times --> 239.75 Mbps in 0.000016 sec 2: 768 bytes 7701 times --> 181.37 Mbps in 0.000032 sec 3: 1024 bytes 5168 times --> 212.35 Mbps in 0.000037 sec 4: 1280 bytes 5102 times --> 209.95 Mbps in 0.000047 sec 5: 1536 bytes 4303 times --> 211.65 Mbps in 0.000055 sec 6: 1792 bytes 3765 times --> 238.44 Mbps in 0.000057 sec 7: 2048 bytes 3739 times --> 267.33 Mbps in 0.000058 sec 8: 2304 bytes 3744 times --> 297.43 Mbps in 0.000059 sec 9: 2560 bytes 3761 times --> 319.77 Mbps in 0.000061 sec 10: 2816 bytes 3685 times --> 349.80 Mbps in 0.000061 sec 11: 3072 bytes 3701 times --> 344.98 Mbps in 0.000068 sec 12: 3328 bytes 3374 times --> 372.86 Mbps in 0.000068 sec 13: 3584 bytes 3389 times --> 400.46 Mbps in 0.000068 sec ... > (Usually the only thing that really counts > for performance is data cache misses and the HAL is unlikely > to affect this much), but the coding style etc.. Indeed it > does not look too Linux like. > > One thing that's frowned upon in Linux are lots of wrappers > for standard functions (like spin_lock etc.). I would > recommend to at least replace them with the standard Linux functions. There's always a tradeoff, a balancing act. The wrappers is a price to pay for the reusable and extremely well tested code. Note also that a small company like Neterion does not have the luxury *not* to re-use the code.. Having said that, there's couple ideas that can be worked in relatively easily. > In principle this can be even done with some kind of > preprocessor Also less ifdefs would be nice. Exactly. Simple script that'll remove extra #ifdefs and wrappers. > > An possible compromise might be to get rid of all the HAL > parts that wraps Linux functionality, and then only use a > leaner low level library to access the more difficult parts > of the hardware. This would involve moving more code into > the Linux specific layers. This should be more low level > code, nothing like the high level queue handling functions > you currently have etc., with the high level logic all in Linux code Well, I guess we can do a lot in that direction. Looking forward to get specific review comments, etc. However, the main question remains: will the HAL-based driver (because even after the script-produced "surgery" it'll continue to be HAL based) ever get accepted? > > -Andi > > P.S.: The patch would be much easier to read if it created > new files instead of changing the old ones. Can be done, very easy. Obviously, only one of the driver has to be selected.. > This makes sense > since the new driver will probably live next to the old one > for some time. > > Alex From rick.jones2@hp.com Mon Mar 14 17:29:59 2005 Received: with ECARTIS (v1.0.0; list netdev); Mon, 14 Mar 2005 17:30:05 -0800 (PST) Received: from palrel11.hp.com (palrel11.hp.com [156.153.255.246]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j2F1Tx3l008713 for ; Mon, 14 Mar 2005 17:29:59 -0800 Received: from tardy.cup.hp.com (tardy.cup.hp.com [15.244.44.58]) by palrel11.hp.com (Postfix) with ESMTP id 3C6F5343 for ; Mon, 14 Mar 2005 17:29:59 -0800 (PST) Received: from hp.com (localhost [127.0.0.1]) by tardy.cup.hp.com (8.9.3 (PHNE_28810)/8.9.3 SMKit7.02) with ESMTP id RAA18192 for ; Mon, 14 Mar 2005 17:29:58 -0800 (PST) Message-ID: <42363A96.2090601@hp.com> Date: Mon, 14 Mar 2005 17:29:58 -0800 From: Rick Jones User-Agent: Mozilla/5.0 (X11; U; HP-UX 9000/785; en-US; rv:1.6) Gecko/20040304 X-Accept-Language: en-us, en MIME-Version: 1.0 To: netdev@oss.sgi.com Subject: Re: [ANNOUNCE] Experimental Driver for Neterion/S2io 10GbE Adapters References: <200503150108.j2F18FDD016965@guinness.s2io.com> In-Reply-To: <200503150108.j2F18FDD016965@guinness.s2io.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV 0.83/762/Sun Mar 13 15:35:33 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 128 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: rick.jones2@hp.com Precedence: bulk X-list: netdev Content-Length: 2005 Lines: 49 Alex Aizman wrote: > Andi Kleen writes: > > >>I guess the main objection to the HAL comes not from >>performance issues > > > But the second or the third objection comes from there, I guess... As far as > the data path, HAL as a "layer" completely disappears. There is just a few > inline instructions that post descriptors and process completed descriptors. > These same instructions are unavoidable; they'd be present HAL or no-HAL. > There's no HAL locks on the data path (the locks are compiled out), no HAL > (as a "layer") induced overhead. Note that the performance was one > persistent "paranoia" from the very start of this project. > > The numbers also tell the tale. We have 7.6Gbps jumbo throughput, the > bottleneck is PCI, not the host. That would seem to suggest then comparing (using netperf terminology) service demands between HAL and no HAL. JumboFrame can compensate for a host of ills :) I really do _not_ mean to imply there are any ills for which compensation is required, just suggesting to get folks into the habit of including CPU utilization. And since we cannot count on JumboFrame being there end-to-end, performance with 1500 byte frames, while perhaps a bit unpleasant, is still important. > We have 13us 1byte netpipe latency. So 76,000 transactions per second on something like single-byte netperf TCP_RR?!? Or am I mis-interpreting the netpipe latency figure? I am of course biased, but netperf (compiled with -DUSE_PROCSTAT under Linux, somethign else for other OSes - feel free to contact me about it) tests along the lines of: netperf -c -C -t TCP_STREAM -H -l -i 10,3 -- -s 256K -S 256K -m 32K and netperf -c -C -t TCP_RR -H -l -i 10,3 are generally useful. If you have the same system type at each end, the -C can be dropped from the TCP_RR test since it _should_ be symmetric. If -C dumps core on the TCP_STREAM test, drop it and add a TCP_MAERTS test to get receive service demand. rick jones From leonid.grossman@neterion.com Mon Mar 14 18:28:28 2005 Received: with ECARTIS (v1.0.0; list netdev); Mon, 14 Mar 2005 18:28:33 -0800 (PST) Received: from ns1.s2io.com (ns1.s2io.com [142.46.200.198]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j2F2SR3A011819 for ; Mon, 14 Mar 2005 18:28:27 -0800 Received: from guinness.s2io.com (sentry.s2io.com [142.46.200.199]) by ns1.s2io.com (8.12.10/8.12.10) with ESMTP id j2F2SKuN014570; Mon, 14 Mar 2005 21:28:21 -0500 (EST) Received: from lgt40 ([10.16.16.169]) by guinness.s2io.com (8.12.6/8.12.6) with ESMTP id j2F2SJDD028252; Mon, 14 Mar 2005 21:28:20 -0500 (EST) Message-Id: <200503150228.j2F2SJDD028252@guinness.s2io.com> From: "Leonid Grossman" To: "'Rick Jones'" , Subject: RE: [ANNOUNCE] Experimental Driver for Neterion/S2io 10GbE Adapters Date: Mon, 14 Mar 2005 18:28:19 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook, Build 11.0.5510 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1409 In-Reply-To: <42363A96.2090601@hp.com> Thread-Index: AcUo/pXNNZeU4AsLSVG5z13jCwTjmgABw4oQ X-Scanned-By: MIMEDefang 2.34 X-Virus-Scanned: ClamAV 0.83/762/Sun Mar 13 15:35:33 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 129 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: leonid.grossman@neterion.com Precedence: bulk X-list: netdev Content-Length: 2715 Lines: 86 > -----Original Message----- > From: netdev-bounce@oss.sgi.com [mailto:netdev-bounce@oss.sgi.com] On > Behalf Of Rick Jones > Sent: Monday, March 14, 2005 5:30 PM > To: netdev@oss.sgi.com > Subject: Re: [ANNOUNCE] Experimental Driver for Neterion/S2io 10GbE > Adapters > > Alex Aizman wrote: > > Andi Kleen writes: > > > > > >>I guess the main objection to the HAL comes not from > >>performance issues > > > > > > But the second or the third objection comes from there, I guess... As > far as > > the data path, HAL as a "layer" completely disappears. There is just a > few > > inline instructions that post descriptors and process completed > descriptors. > > These same instructions are unavoidable; they'd be present HAL or no- > HAL. > > There's no HAL locks on the data path (the locks are compiled out), no > HAL > > (as a "layer") induced overhead. Note that the performance was one > > persistent "paranoia" from the very start of this project. > > > > The numbers also tell the tale. We have 7.6Gbps jumbo throughput, the > > bottleneck is PCI, not the host. > > That would seem to suggest then comparing (using netperf terminology) > service > demands between HAL and no HAL. JumboFrame can compensate for a host of > ills :) > I really do _not_ mean to imply there are any ills for which compensation > is > required, just suggesting to get folks into the habit of including CPU > utilization. And since we cannot count on JumboFrame being there end-to- > end, > performance with 1500 byte frames, while perhaps a bit unpleasant, is > still > important. Hi Rick, With Jumbo frames, the performance and %cpu for the two drivers are at par. With 1500, HAL driver actually shows somewhat better throughput and %cpu - though the approach has nothing to do with it, the important point is that there is no performance drop that could be traced to the usage of HAL per say Leonid. > > > We have 13us 1byte netpipe latency. > > So 76,000 transactions per second on something like single-byte netperf > TCP_RR?!? Or am I mis-interpreting the netpipe latency figure? > > I am of course biased, but netperf (compiled with -DUSE_PROCSTAT under > Linux, > somethign else for other OSes - feel free to contact me about it) tests > along > the lines of: > > netperf -c -C -t TCP_STREAM -H -l -i 10,3 -- -s 256K -S > 256K > -m 32K > > and > > netperf -c -C -t TCP_RR -H -l -i 10,3 > > are generally useful. If you have the same system type at each end, the - > C can > be dropped from the TCP_RR test since it _should_ be symmetric. If -C > dumps > core on the TCP_STREAM test, drop it and add a TCP_MAERTS test to get > receive > service demand. > > rick jones From greearb@candelatech.com Mon Mar 14 19:57:16 2005 Received: with ECARTIS (v1.0.0; list netdev); Mon, 14 Mar 2005 19:57:21 -0800 (PST) Received: from www.lanforge.com (ns1.lanforge.com [66.165.47.210]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j2F3vF7G014314 for ; Mon, 14 Mar 2005 19:57:15 -0800 Received: from [4.33.45.22] (evrtwa1-ar2-4-33-045-022.evrtwa1.dsl-verizon.net [4.33.45.22]) (authenticated bits=0) by www.lanforge.com (8.12.8/8.12.8) with ESMTP id j2F4L8LH003045 for ; Mon, 14 Mar 2005 20:21:08 -0800 Message-ID: <42365D1B.2080504@candelatech.com> Date: Mon, 14 Mar 2005 19:57:15 -0800 From: Ben Greear Organization: Candela Technologies User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.7.3) Gecko/20041020 X-Accept-Language: en-us, en MIME-Version: 1.0 To: "'netdev@oss.sgi.com'" Subject: VIA Rhine (VT6105M) v/s Tulip performance. Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV 0.83/762/Sun Mar 13 15:35:33 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 130 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: greearb@candelatech.com Precedence: bulk X-list: netdev Content-Length: 1422 Lines: 37 Hello! I just got a new 4-port VIA VT6105M NIC (router-board 44) and decided to benchmark it against my 4-port tulip NIC (p430tx)... My test is pktgen sending to itself across two interfaces, and my network emulator bridging the other two interfaces. It's wired so that pktgen is sending a packet through the bridge. There is no protocol overhead here since my bridge software doesn't care, and pktgen is receiving before the UDP protocol can get a hold of it. Kernel is 2.4.29, P-IV 2.66Ghz, 512MB RAM, RH9 w/X and some applications running. With the VIA board, I get about 39Mbps tx + rx on each interface with 1514 byte packets. I get a few dropped packets, maybe .1% or so. The tulip board sustains about 58Mbps tx+rx on each interface, and for whatever reason, the CPU usage is lower. I am dropping a larger percentage of packets with tulip, but not too bad. Both NICs are stable under load so far...though I've only cooked them for 10 minutes at a time. Will let the VIA cook over-night to see if it holds up (have cooked the tulip NICs for days and they always do well)... The VIA board is significantly cheaper, so the lower performance may just be the reality of the situation. I'll try the VIA in a 2.6 kernel sometime soon and let you all know if that changes things significantly. Take it easy, Ben -- Ben Greear Candela Technologies Inc http://www.candelatech.com From sfeldma@pobox.com Mon Mar 14 21:16:19 2005 Received: with ECARTIS (v1.0.0; list netdev); Mon, 14 Mar 2005 21:16:25 -0800 (PST) Received: from orb.pobox.com (orb.pobox.com [207.8.226.5]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j2F5GJQh020641 for ; Mon, 14 Mar 2005 21:16:19 -0800 Received: from orb (localhost [127.0.0.1]) by orb.pobox.com (Postfix) with ESMTP id 999CC8C; Tue, 15 Mar 2005 00:16:17 -0500 (EST) Received: from [192.168.0.3] (wbar2.sea1-4-5-053-048.sea1.dsl-verizon.net [4.5.53.48]) by orb.sasl.smtp.pobox.com (Postfix) with ESMTP id B87898C; Tue, 15 Mar 2005 00:16:13 -0500 (EST) In-Reply-To: <200503142023.j2EKNMDD027705@guinness.s2io.com> References: <200503142023.j2EKNMDD027705@guinness.s2io.com> Mime-Version: 1.0 (Apple Message framework v619.2) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: Content-Transfer-Encoding: 7bit Cc: "" , "" , "'Jeff Garzik'" From: Scott Feldman Subject: Re: [ANNOUNCE] Experimental Driver for Neterion/S2io 10GbE Adapters Date: Mon, 14 Mar 2005 21:14:59 -0800 To: "" X-Mailer: Apple Mail (2.619.2) X-Virus-Scanned: ClamAV 0.83/762/Sun Mar 13 15:35:33 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 131 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: sfeldma@pobox.com Precedence: bulk X-list: netdev Content-Length: 1242 Lines: 30 On Mar 14, 2005, at 12:22 PM, Alex Aizman wrote: > HAL-based > ========= > Most Neterion drivers are HAL (Hardware Abstraction Layer) based. This > is > always a curse and blessing; in our experience this was the latter by > a big > margin. While the current "s2io" driver in the kernel doesn't share > HAL code > with other driver, the "xge" driver is HAL-based. e1000 and ixgb are HAL-based, which is why there is always push back when someone in the community modifies *_hw.[ch]. I'd hate to see more of this in the kernel, but I can definitely relate to the "testing across multiple OSes" gain. Here's an (old?) idea: remember the NDIS-wrapper project? I think the reverse is much more interesting. A linux-wrapper takes a plain old Linux driver and wraps it with what ever is needed to make it an NDIS driver. Or FreeBSD, or whatever. Let's pretend this is trivial for a second. What do we gain? 1) one clean Linux driver to maintain, 2) testability on other OSes, and 3) access to other OSes' certification kits. Licensing is clean: the Linux driver is GPL and the linux-wrapper code is GPL. Can't the world revolve around Linux and let everyone else be burdened with the abstraction layer overhead? -scott From davem@davemloft.net Mon Mar 14 21:23:15 2005 Received: with ECARTIS (v1.0.0; list netdev); Mon, 14 Mar 2005 21:23:21 -0800 (PST) Received: from cheetah.davemloft.net (mail@dsl027-180-174.sfo1.dsl.speakeasy.net [216.27.180.174]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j2F5NEuB021256 for ; Mon, 14 Mar 2005 21:23:15 -0800 Received: from localhost ([127.0.0.1] helo=cheetah.davemloft.net ident=davem) by cheetah.davemloft.net with smtp (Exim 3.36 #1 (Debian)) id 1DB4Uy-0005ZU-00; Mon, 14 Mar 2005 21:21:44 -0800 Date: Mon, 14 Mar 2005 21:21:43 -0800 From: "David S. Miller" To: Thomas Graf Cc: yoshfuji@linux-ipv6.org, netdev@oss.sgi.com Subject: Re: [PATCH] [IPV6] Use dev_get_flags() while building inet6 ifinfo message Message-Id: <20050314212143.4fed451e.davem@davemloft.net> In-Reply-To: <20050315001417.GB3086@postel.suug.ch> References: <20050315001417.GB3086@postel.suug.ch> X-Mailer: Sylpheed version 1.0.1 (GTK+ 1.2.10; sparc-unknown-linux-gnu) X-Face: "_;p5u5aPsO,_Vsx"^v-pEq09'CU4&Dc1$fQExov$62l60cgCc%FnIwD=.UF^a>?5'9Kn[;433QFVV9M..2eN.@4ZWPGbdi<=?[:T>y?SD(R*-3It"Vj:)"dP Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV 0.83/762/Sun Mar 13 15:35:33 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 132 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: davem@davemloft.net Precedence: bulk X-list: netdev Content-Length: 282 Lines: 9 On Tue, 15 Mar 2005 01:14:17 +0100 Thomas Graf wrote: > Use dev_get_flags() in inet6_fill_ifinfo() to fetch interface flags > to ensure correctly reporting IFF_PROMISC and IFF_ALLMULTI flags. > > Signed-off-by: Thomas Graf Applied, thanks Thomas. From davem@davemloft.net Mon Mar 14 21:28:23 2005 Received: with ECARTIS (v1.0.0; list netdev); Mon, 14 Mar 2005 21:28:29 -0800 (PST) Received: from cheetah.davemloft.net (mail@dsl027-180-174.sfo1.dsl.speakeasy.net [216.27.180.174]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j2F5SN0O021864 for ; Mon, 14 Mar 2005 21:28:23 -0800 Received: from localhost ([127.0.0.1] helo=cheetah.davemloft.net ident=davem) by cheetah.davemloft.net with smtp (Exim 3.36 #1 (Debian)) id 1DB4Z4-0005d8-00; Mon, 14 Mar 2005 21:25:58 -0800 Date: Mon, 14 Mar 2005 21:25:57 -0800 From: "David S. Miller" To: Herbert Xu Cc: kuznet@ms2.inr.ac.ru, yoshfuji@linux-ipv6.org, kaber@trash.net, netdev@oss.sgi.com Subject: Re: [12/*] [IPSEC] Handle local_df in IPv4 Message-Id: <20050314212557.23f0ab09.davem@davemloft.net> In-Reply-To: <20050314102614.GA9610@gondor.apana.org.au> References: <20050214221006.GA18415@gondor.apana.org.au> <20050214221200.GA18465@gondor.apana.org.au> <20050214221433.GB18465@gondor.apana.org.au> <20050214221607.GC18465@gondor.apana.org.au> <20050306213214.7d8a143d.davem@davemloft.net> <20050307103536.GB7137@gondor.apana.org.au> <20050308102741.GA23468@gondor.apana.org.au> <20050314102614.GA9610@gondor.apana.org.au> X-Mailer: Sylpheed version 1.0.1 (GTK+ 1.2.10; sparc-unknown-linux-gnu) X-Face: "_;p5u5aPsO,_Vsx"^v-pEq09'CU4&Dc1$fQExov$62l60cgCc%FnIwD=.UF^a>?5'9Kn[;433QFVV9M..2eN.@4ZWPGbdi<=?[:T>y?SD(R*-3It"Vj:)"dP Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV 0.83/762/Sun Mar 13 15:35:33 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 133 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: davem@davemloft.net Precedence: bulk X-list: netdev Content-Length: 665 Lines: 18 On Mon, 14 Mar 2005 21:26:14 +1100 Herbert Xu wrote: > When cleaning up the remaining users of dst_pmtu I noticed that > local_df wasn't being treated correctly in IPsec. In fact, if > you socket's dst went over IPsec, local_df is essentailly ignored. > > This patch fixes that. > > Signed-off-by: Herbert Xu Applied, thanks Herbert. > I was going to do the same thing to IPv6. Unfortunately it seems > that we don't have any local_df support over there. That is, we > always fragment outbound UDP/raw packets. Did I miss something? I have no idea offhand. Perhaps Yoshifuji can figure it out? From davem@davemloft.net Mon Mar 14 21:28:37 2005 Received: with ECARTIS (v1.0.0; list netdev); Mon, 14 Mar 2005 21:28:41 -0800 (PST) Received: from cheetah.davemloft.net (mail@dsl027-180-174.sfo1.dsl.speakeasy.net [216.27.180.174]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j2F5Sb70021875 for ; Mon, 14 Mar 2005 21:28:37 -0800 Received: from localhost ([127.0.0.1] helo=cheetah.davemloft.net ident=davem) by cheetah.davemloft.net with smtp (Exim 3.36 #1 (Debian)) id 1DB4Zo-0005du-00; Mon, 14 Mar 2005 21:26:44 -0800 Date: Mon, 14 Mar 2005 21:26:43 -0800 From: "David S. Miller" To: Herbert Xu Cc: kuznet@ms2.inr.ac.ru, yoshfuji@linux-ipv6.org, kaber@trash.net, netdev@oss.sgi.com Subject: Re: [13/*] [IPV4] Fix room calculation in icmp_send Message-Id: <20050314212643.67f63669.davem@davemloft.net> In-Reply-To: <20050314105313.GA21001@gondor.apana.org.au> References: <20050214221006.GA18415@gondor.apana.org.au> <20050214221200.GA18465@gondor.apana.org.au> <20050214221433.GB18465@gondor.apana.org.au> <20050214221607.GC18465@gondor.apana.org.au> <20050306213214.7d8a143d.davem@davemloft.net> <20050307103536.GB7137@gondor.apana.org.au> <20050308102741.GA23468@gondor.apana.org.au> <20050314102614.GA9610@gondor.apana.org.au> <20050314105313.GA21001@gondor.apana.org.au> X-Mailer: Sylpheed version 1.0.1 (GTK+ 1.2.10; sparc-unknown-linux-gnu) X-Face: "_;p5u5aPsO,_Vsx"^v-pEq09'CU4&Dc1$fQExov$62l60cgCc%FnIwD=.UF^a>?5'9Kn[;433QFVV9M..2eN.@4ZWPGbdi<=?[:T>y?SD(R*-3It"Vj:)"dP Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV 0.83/762/Sun Mar 13 15:35:33 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 134 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: davem@davemloft.net Precedence: bulk X-list: netdev Content-Length: 607 Lines: 17 On Mon, 14 Mar 2005 21:53:13 +1100 Herbert Xu wrote: > I'm now cleaning up all users of dst_pmtu with the aim of replacing > dst_pmtu with dst_mtu. I'm going to start with the ones that actually > fix bugs. > > This patch fixes the length calculation in icmp_send. As it is > we're overestimating the space available by including the space > that would be used up by IPsec encapsulation. > > IPv6 doesn't have this problem since its calculation is based > on 1280 instead of the PMTU. > > Signed-off-by: Herbert Xu Applied, thanks Herbert. From davem@davemloft.net Mon Mar 14 21:29:19 2005 Received: with ECARTIS (v1.0.0; list netdev); Mon, 14 Mar 2005 21:29:24 -0800 (PST) Received: from cheetah.davemloft.net (mail@dsl027-180-174.sfo1.dsl.speakeasy.net [216.27.180.174]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j2F5TIsC022266 for ; Mon, 14 Mar 2005 21:29:19 -0800 Received: from localhost ([127.0.0.1] helo=cheetah.davemloft.net ident=davem) by cheetah.davemloft.net with smtp (Exim 3.36 #1 (Debian)) id 1DB4aX-0005eA-00; Mon, 14 Mar 2005 21:27:29 -0800 Date: Mon, 14 Mar 2005 21:27:28 -0800 From: "David S. Miller" To: Herbert Xu Cc: kuznet@ms2.inr.ac.ru, yoshfuji@linux-ipv6.org, kaber@trash.net, netdev@oss.sgi.com Subject: Re: [14/*] [IPV6] Reload skb->dst after xfrm6_route_forward Message-Id: <20050314212728.75ce14e4.davem@davemloft.net> In-Reply-To: <20050314111002.GA29156@gondor.apana.org.au> References: <20050214221006.GA18415@gondor.apana.org.au> <20050214221200.GA18465@gondor.apana.org.au> <20050214221433.GB18465@gondor.apana.org.au> <20050214221607.GC18465@gondor.apana.org.au> <20050306213214.7d8a143d.davem@davemloft.net> <20050307103536.GB7137@gondor.apana.org.au> <20050308102741.GA23468@gondor.apana.org.au> <20050314102614.GA9610@gondor.apana.org.au> <20050314105313.GA21001@gondor.apana.org.au> <20050314111002.GA29156@gondor.apana.org.au> X-Mailer: Sylpheed version 1.0.1 (GTK+ 1.2.10; sparc-unknown-linux-gnu) X-Face: "_;p5u5aPsO,_Vsx"^v-pEq09'CU4&Dc1$fQExov$62l60cgCc%FnIwD=.UF^a>?5'9Kn[;433QFVV9M..2eN.@4ZWPGbdi<=?[:T>y?SD(R*-3It"Vj:)"dP Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV 0.83/762/Sun Mar 13 15:35:33 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 135 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: davem@davemloft.net Precedence: bulk X-list: netdev Content-Length: 471 Lines: 15 On Mon, 14 Mar 2005 22:10:02 +1100 Herbert Xu wrote: > While replacing dst_pmtu in ip6_output I found this little gem. In > ip6_forward we're not reloading the dst pointer after calling > xfrm6_route_forward. So all subsequent dereferences of dst will > refer to its pre-IPsec value. > > The solution is of course to refresh its value. > > Signed-off-by: Herbert Xu Good catch Herbert. Applied, thanks. From davem@davemloft.net Mon Mar 14 21:30:20 2005 Received: with ECARTIS (v1.0.0; list netdev); Mon, 14 Mar 2005 21:30:27 -0800 (PST) Received: from cheetah.davemloft.net (mail@dsl027-180-174.sfo1.dsl.speakeasy.net [216.27.180.174]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j2F5UKFq023132 for ; Mon, 14 Mar 2005 21:30:20 -0800 Received: from localhost ([127.0.0.1] helo=cheetah.davemloft.net ident=davem) by cheetah.davemloft.net with smtp (Exim 3.36 #1 (Debian)) id 1DB4bl-0005eX-00; Mon, 14 Mar 2005 21:28:45 -0800 Date: Mon, 14 Mar 2005 21:28:45 -0800 From: "David S. Miller" To: Herbert Xu Cc: netdev@oss.sgi.com Subject: Re: [NETLINK] Fix multicast bind/autobind race Message-Id: <20050314212845.6a7fd240.davem@davemloft.net> In-Reply-To: <20050314094420.GA15349@gondor.apana.org.au> References: <20050314094420.GA15349@gondor.apana.org.au> X-Mailer: Sylpheed version 1.0.1 (GTK+ 1.2.10; sparc-unknown-linux-gnu) X-Face: "_;p5u5aPsO,_Vsx"^v-pEq09'CU4&Dc1$fQExov$62l60cgCc%FnIwD=.UF^a>?5'9Kn[;433QFVV9M..2eN.@4ZWPGbdi<=?[:T>y?SD(R*-3It"Vj:)"dP Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV 0.83/762/Sun Mar 13 15:35:33 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 136 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: davem@davemloft.net Precedence: bulk X-list: netdev Content-Length: 860 Lines: 22 On Mon, 14 Mar 2005 20:44:20 +1100 Herbert Xu wrote: > netlink_autobind has always set nlk_sk(sk)->groups to zero. This is > unnecessary because sk_alloc already zeroes the entire structure. > Since a socket can only be bound once netlink_autobind doesn't need > to zero groups at all. > > This had been safe until I added mc_list. Now it is possible for > netlink_bind to race against netlink_autobind running on the same > socket on another CPU. The result would be a socket that's on > mc_list with groups set to zero. This socket will be left on the > list even after it is destroyed. > > The fix is to remove the zeroing in netlink_autobind. > > Signed-off-by: Herbert Xu Applied, thanks Herbert. I suspect a 2.4.x version is necessary as well. Could you cook one up for me? Thanks. From davem@davemloft.net Mon Mar 14 21:31:43 2005 Received: with ECARTIS (v1.0.0; list netdev); Mon, 14 Mar 2005 21:31:48 -0800 (PST) Received: from cheetah.davemloft.net (mail@dsl027-180-174.sfo1.dsl.speakeasy.net [216.27.180.174]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j2F5VgnL023911 for ; Mon, 14 Mar 2005 21:31:43 -0800 Received: from localhost ([127.0.0.1] helo=cheetah.davemloft.net ident=davem) by cheetah.davemloft.net with smtp (Exim 3.36 #1 (Debian)) id 1DB4dD-0005f7-00; Mon, 14 Mar 2005 21:30:15 -0800 Date: Mon, 14 Mar 2005 21:30:15 -0800 From: "David S. Miller" To: Ralf Baechle DL5RB Cc: netdev@oss.sgi.com, linux-hams@vger.kernel.org Subject: Re: [PATCH] Fix ax25_get_socket locking Message-Id: <20050314213015.1b113610.davem@davemloft.net> In-Reply-To: <20050314083744.GA12765@linux-mips.org> References: <20050314083744.GA12765@linux-mips.org> X-Mailer: Sylpheed version 1.0.1 (GTK+ 1.2.10; sparc-unknown-linux-gnu) X-Face: "_;p5u5aPsO,_Vsx"^v-pEq09'CU4&Dc1$fQExov$62l60cgCc%FnIwD=.UF^a>?5'9Kn[;433QFVV9M..2eN.@4ZWPGbdi<=?[:T>y?SD(R*-3It"Vj:)"dP Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV 0.83/762/Sun Mar 13 15:35:33 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 137 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: davem@davemloft.net Precedence: bulk X-list: netdev Content-Length: 413 Lines: 9 On Mon, 14 Mar 2005 08:37:44 +0000 Ralf Baechle DL5RB wrote: > In an attempt to return a locked socket ax25_get_socket() was calling > lock_sock() with a spinlock held, bad idea. Making matters worse it's > only user is running in bottom half context resulting in a potencial > attempt to sleep in bottom half context, so fix the locking there as well. Looks fine. Applied, thanks Ralf. From davem@davemloft.net Mon Mar 14 21:38:42 2005 Received: with ECARTIS (v1.0.0; list netdev); Mon, 14 Mar 2005 21:38:47 -0800 (PST) Received: from cheetah.davemloft.net (mail@dsl027-180-174.sfo1.dsl.speakeasy.net [216.27.180.174]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j2F5cfTK024540 for ; Mon, 14 Mar 2005 21:38:41 -0800 Received: from localhost ([127.0.0.1] helo=cheetah.davemloft.net ident=davem) by cheetah.davemloft.net with smtp (Exim 3.36 #1 (Debian)) id 1DB4jx-0005gT-00; Mon, 14 Mar 2005 21:37:13 -0800 Date: Mon, 14 Mar 2005 21:37:13 -0800 From: "David S. Miller" To: Andre Tomt Cc: netdev@oss.sgi.com Subject: Re: [PATCH] Fix a gcc-3.4 build failure and gcc-3.3 build warnings with TCP_DEBUG disabled in tcp.h Message-Id: <20050314213713.7064c93a.davem@davemloft.net> In-Reply-To: <423287C4.60701@tomt.net> References: <423287C4.60701@tomt.net> X-Mailer: Sylpheed version 1.0.1 (GTK+ 1.2.10; sparc-unknown-linux-gnu) X-Face: "_;p5u5aPsO,_Vsx"^v-pEq09'CU4&Dc1$fQExov$62l60cgCc%FnIwD=.UF^a>?5'9Kn[;433QFVV9M..2eN.@4ZWPGbdi<=?[:T>y?SD(R*-3It"Vj:)"dP Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV 0.83/762/Sun Mar 13 15:35:33 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 138 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: davem@davemloft.net Precedence: bulk X-list: netdev Content-Length: 271 Lines: 10 On Sat, 12 Mar 2005 07:10:12 +0100 Andre Tomt wrote: > Fix a gcc-3.4 build failure and gcc-3.3 build warnings with TCP_DEBUG > disabled in tcp.h > > Patch (with description and signed-off-by) attached due to braindamaged MUA. Applied, thanks Andre. From davem@davemloft.net Mon Mar 14 21:41:08 2005 Received: with ECARTIS (v1.0.0; list netdev); Mon, 14 Mar 2005 21:41:16 -0800 (PST) Received: from cheetah.davemloft.net (mail@dsl027-180-174.sfo1.dsl.speakeasy.net [216.27.180.174]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j2F5f8tB025095 for ; Mon, 14 Mar 2005 21:41:08 -0800 Received: from localhost ([127.0.0.1] helo=cheetah.davemloft.net ident=davem) by cheetah.davemloft.net with smtp (Exim 3.36 #1 (Debian)) id 1DB4lv-0005jc-00; Mon, 14 Mar 2005 21:39:15 -0800 Date: Mon, 14 Mar 2005 21:39:15 -0800 From: "David S. Miller" To: Steve Hill Cc: herbert@gondor.apana.org.au, kaber@trash.net, netdev@oss.sgi.com Subject: Re: More IPSEC trouble Message-Id: <20050314213915.1cf98afc.davem@davemloft.net> In-Reply-To: References: <42323125.20706@trash.net> <20050312013515.GA17539@gondor.apana.org.au> X-Mailer: Sylpheed version 1.0.1 (GTK+ 1.2.10; sparc-unknown-linux-gnu) X-Face: "_;p5u5aPsO,_Vsx"^v-pEq09'CU4&Dc1$fQExov$62l60cgCc%FnIwD=.UF^a>?5'9Kn[;433QFVV9M..2eN.@4ZWPGbdi<=?[:T>y?SD(R*-3It"Vj:)"dP Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV 0.83/762/Sun Mar 13 15:35:33 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 139 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: davem@davemloft.net Precedence: bulk X-list: netdev Content-Length: 441 Lines: 13 On Mon, 14 Mar 2005 12:12:27 +0000 (GMT) Steve Hill wrote: > On Sat, 12 Mar 2005, Herbert Xu wrote: > > > Since tunnel_check_size only looks at the state to determine whether > > it's tunnel mode, it doesn't need to hold the lock at all. > > > > Signed-off-by: Herbert Xu > > I can confirm this fixes the problem - tested under 2.6.10. I've applied Herbert's patch, thanks guys. From davem@davemloft.net Mon Mar 14 21:41:47 2005 Received: with ECARTIS (v1.0.0; list netdev); Mon, 14 Mar 2005 21:41:52 -0800 (PST) Received: from cheetah.davemloft.net (mail@dsl027-180-174.sfo1.dsl.speakeasy.net [216.27.180.174]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j2F5fk4v025465 for ; Mon, 14 Mar 2005 21:41:46 -0800 Received: from localhost ([127.0.0.1] helo=cheetah.davemloft.net ident=davem) by cheetah.davemloft.net with smtp (Exim 3.36 #1 (Debian)) id 1DB4n0-0005jq-00; Mon, 14 Mar 2005 21:40:22 -0800 Date: Mon, 14 Mar 2005 21:40:22 -0800 From: "David S. Miller" To: Stephen Hemminger Cc: netdev@oss.sgi.com, bridge@lists.osdl.org Subject: Re: [PATCH] bridge: no update when hold time is zero Message-Id: <20050314214022.623ff3b0.davem@davemloft.net> In-Reply-To: <20050311102636.30934f12@dxpl.pdx.osdl.net> References: <20050310154437.1223b6e9@dxpl.pdx.osdl.net> <20050310185152.12ed9819.davem@davemloft.net> <20050311102636.30934f12@dxpl.pdx.osdl.net> X-Mailer: Sylpheed version 1.0.1 (GTK+ 1.2.10; sparc-unknown-linux-gnu) X-Face: "_;p5u5aPsO,_Vsx"^v-pEq09'CU4&Dc1$fQExov$62l60cgCc%FnIwD=.UF^a>?5'9Kn[;433QFVV9M..2eN.@4ZWPGbdi<=?[:T>y?SD(R*-3It"Vj:)"dP Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV 0.83/762/Sun Mar 13 15:35:33 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 140 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: davem@davemloft.net Precedence: bulk X-list: netdev Content-Length: 433 Lines: 11 On Fri, 11 Mar 2005 10:26:36 -0800 Stephen Hemminger wrote: > Some users, set hold time to zero on bridge so it always does > flooding. This is usually when using it with wireless. The new RCU > based code changed the behaviour so the bridge would not flood for > one GC interval. This patch restores the original behaviour. Applied, thanks Stephen. Please don't forget the signed-off-by line next time :-) From davem@davemloft.net Mon Mar 14 21:44:00 2005 Received: with ECARTIS (v1.0.0; list netdev); Mon, 14 Mar 2005 21:44:05 -0800 (PST) Received: from cheetah.davemloft.net (mail@dsl027-180-174.sfo1.dsl.speakeasy.net [216.27.180.174]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j2F5i0sk026380 for ; Mon, 14 Mar 2005 21:44:00 -0800 Received: from localhost ([127.0.0.1] helo=cheetah.davemloft.net ident=davem) by cheetah.davemloft.net with smtp (Exim 3.36 #1 (Debian)) id 1DB4p5-0005ks-00; Mon, 14 Mar 2005 21:42:31 -0800 Date: Mon, 14 Mar 2005 21:42:31 -0800 From: "David S. Miller" To: "Michael Chan" Cc: d.willmann@tu-bs.de, netdev@oss.sgi.com, jluebbe@lasnet.de, davem@redhat.com Subject: Re: tg3 kernel oops when setting flow control while interface is down (2.6.10) Message-Id: <20050314214231.78d369b0.davem@davemloft.net> In-Reply-To: References: X-Mailer: Sylpheed version 1.0.1 (GTK+ 1.2.10; sparc-unknown-linux-gnu) X-Face: "_;p5u5aPsO,_Vsx"^v-pEq09'CU4&Dc1$fQExov$62l60cgCc%FnIwD=.UF^a>?5'9Kn[;433QFVV9M..2eN.@4ZWPGbdi<=?[:T>y?SD(R*-3It"Vj:)"dP Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV 0.83/762/Sun Mar 13 15:35:33 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 141 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: davem@davemloft.net Precedence: bulk X-list: netdev Content-Length: 388 Lines: 11 On Fri, 11 Mar 2005 09:19:05 -0800 "Michael Chan" wrote: > O.K., so if there is no objection, I will create some patches for all > relevant tg3 ethtool "set" functions to handle the !netif_running() case as > described above. I think this is better as new settings can be accepted at > any time. No objection at all. Let me know when you have a patch for review. From davem@davemloft.net Mon Mar 14 21:45:38 2005 Received: with ECARTIS (v1.0.0; list netdev); Mon, 14 Mar 2005 21:45:44 -0800 (PST) Received: from cheetah.davemloft.net (mail@dsl027-180-174.sfo1.dsl.speakeasy.net [216.27.180.174]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j2F5jc7i026925 for ; Mon, 14 Mar 2005 21:45:38 -0800 Received: from localhost ([127.0.0.1] helo=cheetah.davemloft.net ident=davem) by cheetah.davemloft.net with smtp (Exim 3.36 #1 (Debian)) id 1DB4qg-0005lD-00; Mon, 14 Mar 2005 21:44:10 -0800 Date: Mon, 14 Mar 2005 21:44:10 -0800 From: "David S. Miller" To: Robert Olsson Cc: cliffw@osdl.org, Robert.Olsson@data.slu.se, shemminger@osdl.org, netdev@oss.sgi.com Subject: Re: pktgen: causing lots of errors in console log Message-Id: <20050314214410.7b0f5ded.davem@davemloft.net> In-Reply-To: <16945.41992.799695.358632@robur.slu.se> References: <20050308140826.451435e5@dxpl.pdx.osdl.net> <16942.55689.924299.906304@robur.slu.se> <20050310104830.58c467c0@es175> <16945.41992.799695.358632@robur.slu.se> X-Mailer: Sylpheed version 1.0.1 (GTK+ 1.2.10; sparc-unknown-linux-gnu) X-Face: "_;p5u5aPsO,_Vsx"^v-pEq09'CU4&Dc1$fQExov$62l60cgCc%FnIwD=.UF^a>?5'9Kn[;433QFVV9M..2eN.@4ZWPGbdi<=?[:T>y?SD(R*-3It"Vj:)"dP Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV 0.83/762/Sun Mar 13 15:35:33 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 142 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: davem@davemloft.net Precedence: bulk X-list: netdev Content-Length: 265 Lines: 13 On Fri, 11 Mar 2005 14:58:32 +0100 Robert Olsson wrote: > > cliff white writes: > > > Okay, I can reproduce it on two machines, no problem. > > I too with CONFIG_PREEMPT=y. Thanks. > > Please try: Applied, thanks a lot Robert. From horms@koto.vergenet.net Mon Mar 14 21:48:01 2005 Received: with ECARTIS (v1.0.0; list netdev); Mon, 14 Mar 2005 21:48:06 -0800 (PST) Received: from koto.vergenet.net (koto.vergenet.net [210.128.90.7]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j2F5m1If027483 for ; Mon, 14 Mar 2005 21:48:01 -0800 Received: by koto.vergenet.net (Postfix, from userid 7100) id E7C8D3402C; Tue, 15 Mar 2005 14:25:21 +0900 (JST) Date: Tue, 15 Mar 2005 14:00:35 +0900 From: Horms To: Quantum Scientific Cc: netdev@oss.sgi.com Subject: Re: Kernel 2.6 IPV6 Busted Message-ID: <20050315050030.GA23777@verge.net.au> Mail-Followup-To: Quantum Scientific , netdev@oss.sgi.com References: <200502270928.44402.Info@Quantum-Sci.com> <20050228.011038.129063054.yoshfuji@linux-ipv6.org> <200502271029.02532.Info@Quantum-Sci.com> Mime-Version: 1.0 Content-Type: text/plain; charset=iso-2022-jp Content-Disposition: inline In-Reply-To: <200502271029.02532.Info@Quantum-Sci.com> X-Cluestick: seven User-Agent: Mutt/1.5.6+20040907i X-Virus-Scanned: ClamAV 0.83/762/Sun Mar 13 15:35:33 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 143 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: horms@debian.org Precedence: bulk X-list: netdev Content-Length: 999 Lines: 26 On Sun, Feb 27, 2005 at 10:29:02AM -0600, Quantum Scientific wrote: > On Sunday 27 February 2005 10:10, YOSHIFUJI Hideaki / $B5HF#1QL@(B wrote: > > > usagi.snap.split-tool-s20050214.tar.bz2 > > > ... however this has no kernel patch within. > > > > > > So I DLed > > > usagi.snap.kit-linux26-s20050214.tar.bz2 > > > ... and no kernel patch here either. Only the kernel and tools. I would > have > > > to run a USAGI-specific kernel, in order to have proper IPV6 support. I > must > > > stay with the Debian kernel. > > > > I believe you should cry at debian-ipv6 list. > > > > And, you can find usagi kernel patch in split directory, and > > you can even find (unsupported) daily kernel snapshot (diff). > > I have 'cried' to the Debian list, and no response. (except viruses) If you have feedback on the Debian kernel, debian-kernel@lists.debian.org is the place. Though your problems seem to mostly relate to the Kernel.Org kernel, so this is probably a better fourum. -- Horms From davem@davemloft.net Mon Mar 14 21:53:12 2005 Received: with ECARTIS (v1.0.0; list netdev); Mon, 14 Mar 2005 21:53:19 -0800 (PST) Received: from cheetah.davemloft.net (mail@dsl027-180-174.sfo1.dsl.speakeasy.net [216.27.180.174]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j2F5rCQv028152 for ; Mon, 14 Mar 2005 21:53:12 -0800 Received: from localhost ([127.0.0.1] helo=cheetah.davemloft.net ident=davem) by cheetah.davemloft.net with smtp (Exim 3.36 #1 (Debian)) id 1DB4xe-0005mu-00; Mon, 14 Mar 2005 21:51:22 -0800 Date: Mon, 14 Mar 2005 21:51:22 -0800 From: "David S. Miller" To: Patrick McHardy Cc: herbert@gondor.apana.org.au, netdev@oss.sgi.com Subject: Re: [PATCH 3/3 XFRM]: Fix invalid key for lookup of cached bundles Message-Id: <20050314215122.356ea961.davem@davemloft.net> In-Reply-To: <422BC655.5070907@trash.net> References: <422AF8D0.3010905@trash.net> <20050307012458.GA4335@gondor.apana.org.au> <422BB14A.5030302@trash.net> <20050307014337.GA4451@gondor.apana.org.au> <422BB477.3040607@trash.net> <20050307015943.GA4533@gondor.apana.org.au> <422BBCC2.4010706@trash.net> <20050307025723.GA4818@gondor.apana.org.au> <422BC655.5070907@trash.net> X-Mailer: Sylpheed version 1.0.1 (GTK+ 1.2.10; sparc-unknown-linux-gnu) X-Face: "_;p5u5aPsO,_Vsx"^v-pEq09'CU4&Dc1$fQExov$62l60cgCc%FnIwD=.UF^a>?5'9Kn[;433QFVV9M..2eN.@4ZWPGbdi<=?[:T>y?SD(R*-3It"Vj:)"dP Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV 0.83/762/Sun Mar 13 15:35:33 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 144 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: davem@davemloft.net Precedence: bulk X-list: netdev Content-Length: 526 Lines: 14 On Mon, 07 Mar 2005 04:11:17 +0100 Patrick McHardy wrote: > Herbert Xu wrote: > > The reason I'm asking is because the places where you're most likely > > to use tos/fwmark is in IPsec gateways. In other words, it isn't > > very useful unless it works in tunnel mode. This plus the fact > > that the check for tunnel mode is a bit of a hack makes me think that > > it's not worth it at the moment. > > Ok, let's drop it for now. Can someone send me an updated patch (with changelog msg please)? Thanks. From davem@davemloft.net Mon Mar 14 21:54:18 2005 Received: with ECARTIS (v1.0.0; list netdev); Mon, 14 Mar 2005 21:54:23 -0800 (PST) Received: from cheetah.davemloft.net (mail@dsl027-180-174.sfo1.dsl.speakeasy.net [216.27.180.174]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j2F5sICV028459 for ; Mon, 14 Mar 2005 21:54:18 -0800 Received: from localhost ([127.0.0.1] helo=cheetah.davemloft.net ident=davem) by cheetah.davemloft.net with smtp (Exim 3.36 #1 (Debian)) id 1DB4w1-0005mU-00; Mon, 14 Mar 2005 21:49:41 -0800 Date: Mon, 14 Mar 2005 21:49:40 -0800 From: "David S. Miller" To: Adrian Bunk Cc: netdev@oss.sgi.com, linux-kernel@vger.kernel.org Subject: Re: [2.6 patch] net/802/fc.c: #if 0 fc_type_trans Message-Id: <20050314214940.4947ccd9.davem@davemloft.net> In-Reply-To: <20050306205754.GO5070@stusta.de> References: <20050306205754.GO5070@stusta.de> X-Mailer: Sylpheed version 1.0.1 (GTK+ 1.2.10; sparc-unknown-linux-gnu) X-Face: "_;p5u5aPsO,_Vsx"^v-pEq09'CU4&Dc1$fQExov$62l60cgCc%FnIwD=.UF^a>?5'9Kn[;433QFVV9M..2eN.@4ZWPGbdi<=?[:T>y?SD(R*-3It"Vj:)"dP Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV 0.83/762/Sun Mar 13 15:35:33 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 145 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: davem@davemloft.net Precedence: bulk X-list: netdev Content-Length: 342 Lines: 12 On Sun, 6 Mar 2005 21:57:54 +0100 Adrian Bunk wrote: > The only user of fc_type_trans (drivers/net/fc/iph5526.c) is BROKEN in > 2.6 and removed in -mm. > > Signed-off-by: Adrian Bunk That driver isn't in Linus's tree any longer either. Just delete the thing altogether instead of #if 0'ing it. Thanks. From oxymoron@waste.org Mon Mar 14 21:59:46 2005 Received: with ECARTIS (v1.0.0; list netdev); Mon, 14 Mar 2005 21:59:50 -0800 (PST) Received: from waste.org (waste.org [216.27.176.166]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j2F5xjul029256 for ; Mon, 14 Mar 2005 21:59:46 -0800 Received: from waste.org (localhost [127.0.0.1]) by waste.org (8.13.2/8.13.2/Debian-1) with ESMTP id j2F5xaoJ015855 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Mon, 14 Mar 2005 23:59:36 -0600 Received: (from oxymoron@localhost) by waste.org (8.13.2/8.13.2/Submit) id j2F5xY82015852; Mon, 14 Mar 2005 23:59:34 -0600 Date: Mon, 14 Mar 2005 21:59:34 -0800 From: Matt Mackall To: Scott Feldman Cc: "" , "" , "" , "'Jeff Garzik'" Subject: Re: [ANNOUNCE] Experimental Driver for Neterion/S2io 10GbE Adapters Message-ID: <20050315055934.GJ3163@waste.org> References: <200503142023.j2EKNMDD027705@guinness.s2io.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.6+20040907i X-Virus-Scanned: ClamAV 0.83/762/Sun Mar 13 15:35:33 2005 on oss.sgi.com X-Virus-Scanned: by amavisd-new X-Virus-Status: Clean X-archive-position: 146 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: mpm@selenic.com Precedence: bulk X-list: netdev Content-Length: 1670 Lines: 38 On Mon, Mar 14, 2005 at 09:14:59PM -0800, Scott Feldman wrote: > > On Mar 14, 2005, at 12:22 PM, Alex Aizman wrote: > > >HAL-based > >========= > >Most Neterion drivers are HAL (Hardware Abstraction Layer) based. This > >is > >always a curse and blessing; in our experience this was the latter by > >a big > >margin. While the current "s2io" driver in the kernel doesn't share > >HAL code > >with other driver, the "xge" driver is HAL-based. > > e1000 and ixgb are HAL-based, which is why there is always push back > when someone in the community modifies *_hw.[ch]. I'd hate to see more > of this in the kernel, but I can definitely relate to the "testing > across multiple OSes" gain. > > Here's an (old?) idea: remember the NDIS-wrapper project? I think the > reverse is much more interesting. A linux-wrapper takes a plain old > Linux driver and wraps it with what ever is needed to make it an NDIS > driver. Or FreeBSD, or whatever. Let's pretend this is trivial for a > second. What do we gain? 1) one clean Linux driver to maintain, 2) > testability on other OSes, and 3) access to other OSes' certification > kits. Licensing is clean: the Linux driver is GPL and the > linux-wrapper code is GPL. Can't the world revolve around Linux and > let everyone else be burdened with the abstraction layer overhead? Depends. Vendors of non-GPL OSes can't ship such drivers for risk of their product becoming a derived work to the extent they're relying on such drivers to make their system useful. You can't get around the GPL by putting a GPL wrapper with an exception around something. -- Mathematics is the supreme nostalgia of our time. From herbert@gondor.apana.org.au Mon Mar 14 22:02:25 2005 Received: with ECARTIS (v1.0.0; list netdev); Mon, 14 Mar 2005 22:02:34 -0800 (PST) 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 j2F62NGt029909 for ; Mon, 14 Mar 2005 22:02:24 -0800 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 1DB586-0000X3-00; Tue, 15 Mar 2005 17:02:10 +1100 Received: from herbert by gondolin.me.apana.org.au with local (Exim 3.36 #1 (Debian)) id 1DB57p-0000rn-00; Tue, 15 Mar 2005 17:01:53 +1100 Date: Tue, 15 Mar 2005 17:01:53 +1100 To: "David S. Miller" Cc: Patrick McHardy , netdev@oss.sgi.com Subject: Re: [PATCH 3/3 XFRM]: Fix invalid key for lookup of cached bundles Message-ID: <20050315060153.GA3282@gondor.apana.org.au> References: <422AF8D0.3010905@trash.net> <20050307012458.GA4335@gondor.apana.org.au> <422BB14A.5030302@trash.net> <20050307014337.GA4451@gondor.apana.org.au> <422BB477.3040607@trash.net> <20050307015943.GA4533@gondor.apana.org.au> <422BBCC2.4010706@trash.net> <20050307025723.GA4818@gondor.apana.org.au> <422BC655.5070907@trash.net> <20050314215122.356ea961.davem@davemloft.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20050314215122.356ea961.davem@davemloft.net> User-Agent: Mutt/1.5.6+20040907i From: Herbert Xu X-Virus-Scanned: ClamAV 0.83/762/Sun Mar 13 15:35:33 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 147 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: herbert@gondor.apana.org.au Precedence: bulk X-list: netdev Content-Length: 1240 Lines: 30 On Mon, Mar 14, 2005 at 09:51:22PM -0800, David S. Miller wrote: > On Mon, 07 Mar 2005 04:11:17 +0100 > Patrick McHardy wrote: > > > Herbert Xu wrote: > > > The reason I'm asking is because the places where you're most likely > > > to use tos/fwmark is in IPsec gateways. In other words, it isn't > > > very useful unless it works in tunnel mode. This plus the fact > > > that the check for tunnel mode is a bit of a hack makes me think that > > > it's not worth it at the moment. > > > > Ok, let's drop it for now. > > Can someone send me an updated patch (with changelog msg please)? I think the conclusion is that until we fix the bundle scalability problem there is no point in adding tos/fwmark support here. The reason is that if we do it now then tunnel mode SAs will potentially be targets of DoS attacks that create a large number of bundles off one policy. However, tunnel mode SAs would be the main users of this feature so if we can't do it for them then we might as well not do it. Cheers, -- Visit Openswan at http://www.openswan.org/ Email: Herbert Xu ~{PmV>HI~} Home Page: http://gondor.apana.org.au/~herbert/ PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt From leonid.grossman@neterion.com Mon Mar 14 22:02:34 2005 Received: with ECARTIS (v1.0.0; list netdev); Mon, 14 Mar 2005 22:02:39 -0800 (PST) Received: from ns1.s2io.com (ns1.s2io.com [142.46.200.198]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j2F62XuJ029915 for ; Mon, 14 Mar 2005 22:02:34 -0800 Received: from guinness.s2io.com (sentry.s2io.com [142.46.200.199]) by ns1.s2io.com (8.12.10/8.12.10) with ESMTP id j2F62RuN015697; Tue, 15 Mar 2005 01:02:27 -0500 (EST) Received: from lgt40 ([10.16.16.166]) by guinness.s2io.com (8.12.6/8.12.6) with ESMTP id j2F62ODD027579; Tue, 15 Mar 2005 01:02:25 -0500 (EST) Message-Id: <200503150602.j2F62ODD027579@guinness.s2io.com> From: "Leonid Grossman" To: "'Scott Feldman'" , Cc: , , "'Jeff Garzik'" Subject: RE: [ANNOUNCE] Experimental Driver for Neterion/S2io 10GbE Adapters Date: Mon, 14 Mar 2005 22:02:23 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook, Build 11.0.5510 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1409 In-Reply-To: Thread-Index: AcUpHh9A7aoifWV6QZunucjA2pt2pAAAmmkA X-Scanned-By: MIMEDefang 2.34 X-Virus-Scanned: ClamAV 0.83/762/Sun Mar 13 15:35:33 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 148 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: leonid.grossman@neterion.com Precedence: bulk X-list: netdev Content-Length: 3258 Lines: 80 > -----Original Message----- > From: Scott Feldman [mailto:sfeldma@pobox.com] > Sent: Monday, March 14, 2005 9:15 PM > To: > Cc: ; ; 'Jeff Garzik' > Subject: Re: [ANNOUNCE] Experimental Driver for Neterion/S2io 10GbE > Adapters > > > On Mar 14, 2005, at 12:22 PM, Alex Aizman wrote: > > > HAL-based > > ========= > > Most Neterion drivers are HAL (Hardware Abstraction Layer) based. This > > is > > always a curse and blessing; in our experience this was the latter by > > a big > > margin. While the current "s2io" driver in the kernel doesn't share > > HAL code > > with other driver, the "xge" driver is HAL-based. > > e1000 and ixgb are HAL-based, which is why there is always push back > when someone in the community modifies *_hw.[ch]. I'd hate to see more > of this in the kernel, but I can definitely relate to the "testing > across multiple OSes" gain. I'll be thrilled to see meaningful community changes to xge HAL files :-) > > Here's an (old?) idea: remember the NDIS-wrapper project? I think the > reverse is much more interesting. A linux-wrapper takes a plain old > Linux driver and wraps it with what ever is needed to make it an NDIS > driver. Or FreeBSD, or whatever. Let's pretend this is trivial for a > second. What do we gain? 1) one clean Linux driver to maintain, 2) > testability on other OSes, and 3) access to other OSes' certification > kits. Licensing is clean: the Linux driver is GPL and the > linux-wrapper code is GPL. Can't the world revolve around Linux and > let everyone else be burdened with the abstraction layer overhead? Believe or not, something like this could (and has been) done but did not stick. People did even spookier things, like a wrapper on top of another OS binary driver - some of you guys may remember Novell NLM vs. Unixware driver project :-) These attempts were always short-lived, my guess is because the teams behind the project did not have a long-term motivation and/or the expertise to get it done and (more importantly) to maintain the framework, as OS driver models evolved and diverged. On the other hand, the HAL model is more alive than ever - Intel, Neterion and many/most other modern NICs I'm aware of use HAL approach. This is actually much more common between non-Linux Oses, since there are still significant (warranted or not) GPL-related concerns. HAL discussion is an old one indeed, and the truth is still in the eye of a beholder :-) People who are sorely responsible for supporting multiple OS drivers for the same hardware (that is, NIC vendors) have strong bias in favor of HAL approach, for all the right reasons (mainly, maintainability and support). People who are sorely responsible for supporting drivers for multiple NICs on the same OS have strong bias against HAL approach - also for some pretty valid reasons. Linux is one (but not the only) case when the drivers are maintained by both groups, and the biases/preferences collide... Interestingly enough, as time goes by and everybody is getting thin on resources, HAL approach tends to gain "marketshare" rather fast - at present, Linux "s2io" is one of the very few Neterion drivers that is not using HAL. > > -scott From davem@davemloft.net Mon Mar 14 22:16:46 2005 Received: with ECARTIS (v1.0.0; list netdev); Mon, 14 Mar 2005 22:16:50 -0800 (PST) Received: from cheetah.davemloft.net (mail@dsl027-180-174.sfo1.dsl.speakeasy.net [216.27.180.174]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j2F6Gk61031229 for ; Mon, 14 Mar 2005 22:16:46 -0800 Received: from localhost ([127.0.0.1] helo=cheetah.davemloft.net ident=davem) by cheetah.davemloft.net with smtp (Exim 3.36 #1 (Debian)) id 1DB5KK-0005x4-00; Mon, 14 Mar 2005 22:14:48 -0800 Date: Mon, 14 Mar 2005 22:14:48 -0800 From: "David S. Miller" To: Herbert Xu Cc: kaber@trash.net, netdev@oss.sgi.com Subject: Re: [PATCH 3/3 XFRM]: Fix invalid key for lookup of cached bundles Message-Id: <20050314221448.7858aaa4.davem@davemloft.net> In-Reply-To: <20050315060153.GA3282@gondor.apana.org.au> References: <422AF8D0.3010905@trash.net> <20050307012458.GA4335@gondor.apana.org.au> <422BB14A.5030302@trash.net> <20050307014337.GA4451@gondor.apana.org.au> <422BB477.3040607@trash.net> <20050307015943.GA4533@gondor.apana.org.au> <422BBCC2.4010706@trash.net> <20050307025723.GA4818@gondor.apana.org.au> <422BC655.5070907@trash.net> <20050314215122.356ea961.davem@davemloft.net> <20050315060153.GA3282@gondor.apana.org.au> X-Mailer: Sylpheed version 1.0.1 (GTK+ 1.2.10; sparc-unknown-linux-gnu) X-Face: "_;p5u5aPsO,_Vsx"^v-pEq09'CU4&Dc1$fQExov$62l60cgCc%FnIwD=.UF^a>?5'9Kn[;433QFVV9M..2eN.@4ZWPGbdi<=?[:T>y?SD(R*-3It"Vj:)"dP Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV 0.83/762/Sun Mar 13 15:35:33 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 149 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: davem@davemloft.net Precedence: bulk X-list: netdev Content-Length: 306 Lines: 9 On Tue, 15 Mar 2005 17:01:53 +1100 Herbert Xu wrote: > I think the conclusion is that until we fix the bundle scalability > problem there is no point in adding tos/fwmark support here. Aha, I see. I misinterpreted the end of the discussion. Thanks for clearing things up. From herbert@gondor.apana.org.au Mon Mar 14 23:19:54 2005 Received: with ECARTIS (v1.0.0; list netdev); Mon, 14 Mar 2005 23:20:02 -0800 (PST) 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 j2F7Jr1W000806 for ; Mon, 14 Mar 2005 23:19:53 -0800 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 1DB6L4-00017d-00; Tue, 15 Mar 2005 18:19:38 +1100 Received: from herbert by gondolin.me.apana.org.au with local (Exim 3.36 #1 (Debian)) id 1DB6Kc-0001QG-00; Tue, 15 Mar 2005 18:19:10 +1100 Date: Tue, 15 Mar 2005 18:19:09 +1100 To: "David S. Miller" Cc: netdev@oss.sgi.com Subject: Re: [NETLINK] Fix multicast bind/autobind race Message-ID: <20050315071909.GA5458@gondor.apana.org.au> References: <20050314094420.GA15349@gondor.apana.org.au> <20050314212845.6a7fd240.davem@davemloft.net> Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="C7zPtVaVf+AK4Oqc" Content-Disposition: inline In-Reply-To: <20050314212845.6a7fd240.davem@davemloft.net> User-Agent: Mutt/1.5.6+20040907i From: Herbert Xu X-Virus-Scanned: ClamAV 0.83/762/Sun Mar 13 15:35:33 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 150 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: herbert@gondor.apana.org.au Precedence: bulk X-list: netdev Content-Length: 1581 Lines: 51 --C7zPtVaVf+AK4Oqc Content-Type: text/plain; charset=us-ascii Content-Disposition: inline On Mon, Mar 14, 2005 at 09:28:45PM -0800, David S. Miller wrote: > > I suspect a 2.4.x version is necessary as well. Could you cook > one up for me? Thanks. Sure, here it is. netlink_autobind has always set nlk_sk(sk)->groups to zero. This is unnecessary because sk_alloc already zeroes the entire structure. Since a socket can only be bound once netlink_autobind doesn't need to zero groups at all. This had been safe until I added mc_list. Now it is possible for netlink_bind to race against netlink_autobind running on the same socket on another CPU. The result would be a socket that's on mc_list with groups set to zero. This socket will be left on the list even after it is destroyed. The fix is to remove the zeroing in netlink_autobind. Signed-off-by: Herbert Xu Cheers, -- Visit Openswan at http://www.openswan.org/ Email: Herbert Xu ~{PmV>HI~} Home Page: http://gondor.apana.org.au/~herbert/ PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt --C7zPtVaVf+AK4Oqc Content-Type: text/plain; charset=us-ascii Content-Disposition: attachment; filename=p ===== net/netlink/af_netlink.c 1.21 vs edited ===== --- 1.21/net/netlink/af_netlink.c 2005-02-17 06:21:57 +11:00 +++ edited/net/netlink/af_netlink.c 2005-03-15 18:17:55 +11:00 @@ -450,7 +450,6 @@ err = netlink_insert(sk, pid); if (err == -EADDRINUSE) goto retry; - sk->protinfo.af_netlink->groups = 0; return 0; } --C7zPtVaVf+AK4Oqc-- From gurtov@cs.helsinki.fi Tue Mar 15 00:13:50 2005 Received: with ECARTIS (v1.0.0; list netdev); Tue, 15 Mar 2005 00:13:57 -0800 (PST) Received: from mail.cs.helsinki.fi (courier.cs.helsinki.fi [128.214.9.1]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j2F8DnlS003997 for ; Tue, 15 Mar 2005 00:13:50 -0800 Received: from [128.214.113.216] (guest216.hiit.fi [128.214.113.216]) (AUTH: PLAIN gurtov, SSL: TLSv1/SSLv3,256bits,AES256-SHA) by mail.cs.helsinki.fi with esmtp; Tue, 15 Mar 2005 10:13:46 +0200 id 00070E77.4236993A.0000421B Message-ID: <42369919.9010203@cs.helsinki.fi> Date: Tue, 15 Mar 2005 10:13:13 +0200 From: Andrei Gurtov User-Agent: Mozilla Thunderbird 1.0 (Windows/20041206) X-Accept-Language: en-us, en MIME-Version: 1.0 To: netdev@oss.sgi.com CC: infrahip@hiit.fi Subject: [PATCH] Host Identity Protocol Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV 0.83/762/Sun Mar 13 15:35:33 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 151 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: gurtov@cs.helsinki.fi Precedence: bulk X-list: netdev Content-Length: 285 Lines: 13 Hi, Please have a look at Host Identity Protocol, a better solution for secure mobility and multihoming than Mobile IP. http://hipl.hiit.fi/hipl/release/kernel-patches/linux-2.6.10-hipl-0.1.patch Project info: http://infrahip.hiit.fi/ Specs: http://hip.piuha.net/drafts/ Andrei From pekkas@netcore.fi Tue Mar 15 00:36:55 2005 Received: with ECARTIS (v1.0.0; list netdev); Tue, 15 Mar 2005 00:37:01 -0800 (PST) Received: from netcore.fi (netcore.fi [193.94.160.1]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j2F8arkT008596 for ; Tue, 15 Mar 2005 00:36:54 -0800 Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id j2F8aC325728; Tue, 15 Mar 2005 10:36:12 +0200 Date: Tue, 15 Mar 2005 10:36:12 +0200 (EET) From: Pekka Savola To: Andrei Gurtov cc: netdev@oss.sgi.com, infrahip@hiit.fi Subject: Re: [PATCH] Host Identity Protocol In-Reply-To: <42369919.9010203@cs.helsinki.fi> Message-ID: References: <42369919.9010203@cs.helsinki.fi> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Virus-Scanned: ClamAV 0.83/762/Sun Mar 13 15:35:33 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 152 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: pekkas@netcore.fi Precedence: bulk X-list: netdev Content-Length: 569 Lines: 13 On Tue, 15 Mar 2005, Andrei Gurtov wrote: > Please have a look at Host Identity Protocol, a better solution for secure > mobility and multihoming than Mobile IP. > > http://hipl.hiit.fi/hipl/release/kernel-patches/linux-2.6.10-hipl-0.1.patch Please clean up the patch :). It has tons of changes which have nothing to do with HIP. Maybe it was diffed against the wrong tree? -- Pekka Savola "You each name yourselves king, yet the Netcore Oy kingdom bleeds." Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings From mkomu@twilight.cs.hut.fi Tue Mar 15 01:04:44 2005 Received: with ECARTIS (v1.0.0; list netdev); Tue, 15 Mar 2005 01:04:51 -0800 (PST) Received: from twilight.cs.hut.fi (twilight.cs.hut.fi [130.233.40.5]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j2F94h6M009852 for ; Tue, 15 Mar 2005 01:04:44 -0800 Received: by twilight.cs.hut.fi (Postfix, from userid 60001) id 3A4502DF0; Tue, 15 Mar 2005 11:04:38 +0200 (EET) Received: from kekkonen.cs.hut.fi (kekkonen.cs.hut.fi [130.233.41.50]) by twilight.cs.hut.fi (Postfix) with ESMTP id 8A9672D14; Tue, 15 Mar 2005 11:04:37 +0200 (EET) Received: (from mkomu@localhost) by kekkonen.cs.hut.fi (8.11.7p1+Sun/8.10.2) id j2F94br18766; Tue, 15 Mar 2005 11:04:37 +0200 (EET) Date: Tue, 15 Mar 2005 11:04:37 +0200 (EET) From: Miika Komu X-X-Sender: mkomu@kekkonen.cs.hut.fi To: Pekka Savola Cc: Andrei Gurtov , netdev@oss.sgi.com, infrahip@hiit.fi Subject: Re: [Infrahip] Re: [PATCH] Host Identity Protocol In-Reply-To: Message-ID: References: <42369919.9010203@cs.helsinki.fi> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Virus-Scanned: ClamAV 0.83/762/Sun Mar 13 15:35:33 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 153 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: miika@iki.fi Precedence: bulk X-list: netdev Content-Length: 696 Lines: 17 On Tue, 15 Mar 2005, Pekka Savola wrote: > On Tue, 15 Mar 2005, Andrei Gurtov wrote: > > Please have a look at Host Identity Protocol, a better solution for secure > > mobility and multihoming than Mobile IP. > > > > http://hipl.hiit.fi/hipl/release/kernel-patches/linux-2.6.10-hipl-0.1.patch > > Please clean up the patch :). It has tons of changes which have > nothing to do with HIP. Maybe it was diffed against the wrong tree? My apologies, I'll clean the patch today. It was created against the correct tree, but we have a separate repository that has accumulated some deleted files from older kernel versions. -- Miika Komu miika@iki.fi http://www.iki.fi/miika/ From herbert@gondor.apana.org.au Tue Mar 15 01:20:33 2005 Received: with ECARTIS (v1.0.0; list netdev); Tue, 15 Mar 2005 01:20:41 -0800 (PST) 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 j2F9KSSg010855 for ; Tue, 15 Mar 2005 01:20:31 -0800 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 1DB8DC-0001ss-00; Tue, 15 Mar 2005 20:19:38 +1100 Received: from herbert by gondolin.me.apana.org.au with local (Exim 3.36 #1 (Debian)) id 1DB8Ce-0001gw-00; Tue, 15 Mar 2005 20:19:04 +1100 Date: Tue, 15 Mar 2005 20:19:04 +1100 To: "David S. Miller" Cc: Alexey Kuznetsov , YOSHIFUJI Hideaki , Patrick McHardy , netdev@oss.sgi.com Subject: [15/*] [INET] Fix IPsec calculation in ip_append_data/ip6_append_data Message-ID: <20050315091904.GA6256@gondor.apana.org.au> References: <20050214221006.GA18415@gondor.apana.org.au> <20050214221200.GA18465@gondor.apana.org.au> <20050214221433.GB18465@gondor.apana.org.au> <20050214221607.GC18465@gondor.apana.org.au> <20050306213214.7d8a143d.davem@davemloft.net> <20050307103536.GB7137@gondor.apana.org.au> <20050308102741.GA23468@gondor.apana.org.au> <20050314102614.GA9610@gondor.apana.org.au> <20050314105313.GA21001@gondor.apana.org.au> <20050314111002.GA29156@gondor.apana.org.au> Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="bg08WKrSYDhXBjb5" Content-Disposition: inline In-Reply-To: <20050314111002.GA29156@gondor.apana.org.au> User-Agent: Mutt/1.5.6+20040907i From: Herbert Xu X-Virus-Scanned: ClamAV 0.83/762/Sun Mar 13 15:35:33 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 154 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: herbert@gondor.apana.org.au Precedence: bulk X-list: netdev Content-Length: 3614 Lines: 125 --bg08WKrSYDhXBjb5 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Hi Dave: This patch fixes the IPsec overhead handling in ip_append_data and ip6_append_data. As it is they assume that the IPsec overhead is constant. This is not true as with ESP the IPsec overhead will vary as the MTU varies. The result is that they may produce packets that will exceed the MTU when ESP is used. Had it taken the trailer_len into account, it would have produced packets less than the real MTU. By switching to dst_mtu we get the optimal result. 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 --bg08WKrSYDhXBjb5 Content-Type: text/plain; charset=us-ascii Content-Disposition: attachment; filename=xfrm-15 ===== net/ipv4/ip_output.c 1.76 vs edited ===== --- 1.76/net/ipv4/ip_output.c 2005-02-01 02:43:53 +11:00 +++ edited/net/ipv4/ip_output.c 2005-03-15 20:13:13 +11:00 @@ -719,7 +719,6 @@ struct ip_options *opt = NULL; int hh_len; - int exthdrlen; int mtu; int copy; int err; @@ -746,22 +745,17 @@ inet->cork.addr = ipc->addr; } dst_hold(&rt->u.dst); - inet->cork.fragsize = mtu = dst_pmtu(&rt->u.dst); + inet->cork.fragsize = mtu = dst_mtu(&rt->u.dst); inet->cork.rt = rt; inet->cork.length = 0; sk->sk_sndmsg_page = NULL; sk->sk_sndmsg_off = 0; - if ((exthdrlen = rt->u.dst.header_len) != 0) { - length += exthdrlen; - transhdrlen += exthdrlen; - } } else { rt = inet->cork.rt; if (inet->cork.flags & IPCORK_OPT) opt = inet->cork.opt; transhdrlen = 0; - exthdrlen = 0; mtu = inet->cork.fragsize; } hh_len = LL_RESERVED_SPACE(rt->u.dst.dev); @@ -770,7 +764,7 @@ maxfraglen = ((mtu - fragheaderlen) & ~7) + fragheaderlen; if (inet->cork.length + length > 0xFFFF - fragheaderlen) { - ip_local_error(sk, EMSGSIZE, rt->rt_dst, inet->dport, mtu-exthdrlen); + ip_local_error(sk, EMSGSIZE, rt->rt_dst, inet->dport, mtu); return -EMSGSIZE; } @@ -781,7 +775,7 @@ if (transhdrlen && length + fragheaderlen <= mtu && rt->u.dst.dev->features&(NETIF_F_IP_CSUM|NETIF_F_NO_CSUM|NETIF_F_HW_CSUM) && - !exthdrlen) + !rt->u.dst.header_len) csummode = CHECKSUM_HW; inet->cork.length += length; @@ -866,9 +860,9 @@ * Find where to start putting bytes. */ data = skb_put(skb, fraglen); - skb->nh.raw = data + exthdrlen; + skb->nh.raw = data; data += fragheaderlen; - skb->h.raw = data + exthdrlen; + skb->h.raw = data; if (fraggap) { skb->csum = skb_copy_and_csum_bits( @@ -890,7 +884,6 @@ offset += copy; length -= datalen - fraggap; transhdrlen = 0; - exthdrlen = 0; csummode = CHECKSUM_NONE; /* ===== net/ipv6/ip6_output.c 1.85 vs edited ===== --- 1.85/net/ipv6/ip6_output.c 2005-03-03 16:12:38 +11:00 +++ edited/net/ipv6/ip6_output.c 2005-03-15 20:12:15 +11:00 @@ -849,13 +849,13 @@ np->cork.rt = rt; inet->cork.fl = *fl; np->cork.hop_limit = hlimit; - inet->cork.fragsize = mtu = dst_pmtu(&rt->u.dst); + inet->cork.fragsize = mtu = dst_mtu(&rt->u.dst); if (dst_allfrag(&rt->u.dst)) inet->cork.flags |= IPCORK_ALLFRAG; inet->cork.length = 0; sk->sk_sndmsg_page = NULL; sk->sk_sndmsg_off = 0; - exthdrlen = rt->u.dst.header_len + (opt ? opt->opt_flen : 0); + exthdrlen = opt ? opt->opt_flen : 0; length += exthdrlen; transhdrlen += exthdrlen; } else { --bg08WKrSYDhXBjb5-- From mroos@linux.ee Tue Mar 15 01:36:47 2005 Received: with ECARTIS (v1.0.0; list netdev); Tue, 15 Mar 2005 01:36:54 -0800 (PST) Received: from math.ut.ee (math.ut.ee [193.40.36.2]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j2F9akEw011736 for ; Tue, 15 Mar 2005 01:36:47 -0800 Received: from math.ut.ee (localhost [IPv6:::1]) by math.ut.ee (8.12.8+Sun/8.12.8/math-1.2) with ESMTP id j2F9aiaW014427 for ; Tue, 15 Mar 2005 11:36:44 +0200 (EET) Received: from localhost (mroos@localhost) by math.ut.ee (8.12.8+Sun/8.12.2/Submit) with ESMTP id j2F9ahhl014409 for ; Tue, 15 Mar 2005 11:36:44 +0200 (EET) X-Authentication-Warning: math.ut.ee: mroos owned process doing -bs Date: Tue, 15 Mar 2005 11:36:42 +0200 (EET) From: Meelis Roos To: netdev@oss.sgi.com Subject: ipv6 unresolved symbol Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Virus-Scanned: ClamAV 0.83/762/Sun Mar 13 15:35:33 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 155 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: mroos@linux.ee Precedence: bulk X-list: netdev Content-Length: 174 Lines: 6 This is todays 2.6.11+BK on x86 with modular ipv6: WARNING: /lib/modules/2.6.11/kernel/net/ipv6/ipv6.ko needs unknown symbol dev_get_flags -- Meelis Roos (mroos@linux.ee) From dada1@cosmosbay.com Tue Mar 15 01:41:14 2005 Received: with ECARTIS (v1.0.0; list netdev); Tue, 15 Mar 2005 01:41:19 -0800 (PST) Received: from gw1.cosmosbay.com (gw1.cosmosbay.com [62.23.185.226]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j2F9fDWE012317 for ; Tue, 15 Mar 2005 01:41:14 -0800 Received: from [172.16.0.131] (edumazet-port [172.16.0.131]) by gw1.cosmosbay.com (8.13.3/8.13.3) with ESMTP id j2F9f238027685; Tue, 15 Mar 2005 10:41:02 +0100 Message-ID: <4236ADB4.6000600@cosmosbay.com> Date: Tue, 15 Mar 2005 10:41:08 +0100 From: Eric Dumazet User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.3) Gecko/20040910 X-Accept-Language: fr, en-us, en MIME-Version: 1.0 To: Stephen Hemminger CC: linux-net@vger.kernel.org, netdev@oss.sgi.com Subject: Re: [ANNOUNCE] iproute2-2.6.11-050314 References: <20050314163438.1f73ec6d@dxpl.pdx.osdl.net> In-Reply-To: <20050314163438.1f73ec6d@dxpl.pdx.osdl.net> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-1.6 (gw1.cosmosbay.com [172.16.8.80]); Tue, 15 Mar 2005 10:41:02 +0100 (CET) X-Virus-Scanned: ClamAV 0.83/762/Sun Mar 13 15:35:33 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 156 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: dada1@cosmosbay.com Precedence: bulk X-list: netdev Content-Length: 2598 Lines: 63 Stephen Hemminger wrote: > New version of Iproute2 is available: > > http://developer.osdl.org/dev/iproute2/download/iproute2-2.6.11-050314.tar.gz > Hi It seems rtstat has a problem, at least on my dual cpu (x86) machine : The 'entries' column seems ok, not the following ones (rt_cache in_hit, rt_cache in_slow_tot) It seems only the last line from /proc/net/stat/rt_cache is taken into account, instead of summing all the lines (one line per cpu) (only the first column 'entries' is not to be summed) [root@ns2513 linux-2.6.11]# /usr/src/iproute2-2.6.11/misc/rtstat -c 3 -i 5 rt_cache|rt_cache|rt_cache|rt_cache|rt_cache|rt_cache|rt_cache|rt_cache|rt_cache|rt_cache|rt_cache|rt_cache|rt_cache|rt_cache|rt_cache|rt_cache| entries| in_hit|in_slow_|in_no_ro| in_brd|in_marti|in_marti| out_hit|out_slow|out_slow|gc_total|gc_ignor|gc_goal_|gc_dst_o|in_hlist|out_hlis| | | tot| ute| | an_dst| an_src| | _tot| _mc| | ed| miss| verflow| _search|t_search| 128497| 0| 0| 0| 0| 0| 0| 0| 3704216|15597939| 0|15597874|15595738| 676| 0| 0| 129505| 0| 0| 0| 0| 0| 0| 0| 13| 70| 0| 70| 70| 0| 0| 0| 129147| 0| 0| 0| 0| 0| 0| 0| 2| 19| 0| 19| 19| 0| 0| 0| [root@ns2513 linux-2.6.11]# cat /proc/net/stat/rt_cache ; sleep 3 ; cat /proc/net/stat/rt_cache entries in_hit in_slow_tot in_no_route in_brd in_martian_dst in_martian_src out_hit out_slow_tot out_slow_mc gc_total gc_ignored gc_goal_miss gc_dst_overflow in_hlist_search out_hlist_search 0001d4c1 6928f9bd 87a34938 00000000 00000000 00004c28 00000000 0000103b 0e15593e 2f5295f0 00000000 b6e7adb3 b6d110f6 0004cbe2 00000000 df1dd7b9 40ef942d 0001d4c1 00000000 00000000 00000000 00000000 00000000 00000000 00000000 011a9c85 04a60a1b 00000000 04a608d8 04a5df1f 00000d35 00000000 00000000 1d94490b entries in_hit in_slow_tot in_no_route in_brd in_martian_dst in_martian_src out_hit out_slow_tot out_slow_mc gc_total gc_ignored gc_goal_miss gc_dst_overflow in_hlist_search out_hlist_search 0001ea38 692916a4 87a3723c 00000000 00000000 00004c28 00000000 0000103b 0e155cef 2f52a454 00000000 b6e7e516 b6d14852 0004cbe3 00000000 df1ed7d7 40efef15 0001ea38 00000000 00000000 00000000 00000000 00000000 00000000 00000000 011a9ce9 04a60bd1 00000000 04a60a8e 04a5e0d5 00000d35 00000000 00000000 1d9453b8 Thank you Eric Dumazet From yoshfuji@linux-ipv6.org Tue Mar 15 01:56:32 2005 Received: with ECARTIS (v1.0.0; list netdev); Tue, 15 Mar 2005 01:56:38 -0800 (PST) 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 j2F9uVwM013253 for ; Tue, 15 Mar 2005 01:56:31 -0800 Received: from localhost (localhost [127.0.0.1]) by yue.st-paulia.net (Postfix) with ESMTP id 60C5533CC2; Tue, 15 Mar 2005 18:58:16 +0900 (JST) Date: Tue, 15 Mar 2005 18:58:15 +0900 (JST) Message-Id: <20050315.185815.12690947.yoshfuji@linux-ipv6.org> To: mroos@linux.ee, davem@davemloft.net Cc: netdev@oss.sgi.com Subject: Re: ipv6 unresolved symbol From: YOSHIFUJI Hideaki / =?iso-2022-jp?B?GyRCNUhGIzFRTEAbKEI=?= In-Reply-To: References: 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-Virus-Scanned: ClamAV 0.83/762/Sun Mar 13 15:35:33 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 157 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: yoshfuji@linux-ipv6.org Precedence: bulk X-list: netdev Content-Length: 888 Lines: 25 In article (at Tue, 15 Mar 2005 11:36:42 +0200 (EET)), Meelis Roos says: > This is todays 2.6.11+BK on x86 with modular ipv6: > > WARNING: /lib/modules/2.6.11/kernel/net/ipv6/ipv6.ko needs unknown symbol dev_get_flags Oops, thanks. Signed-off-by: Hideaki YOSHIFUJI ===== net/core/dev.c 1.185 vs edited ===== --- 1.185/net/core/dev.c 2005-02-11 14:54:32 +09:00 +++ edited/net/core/dev.c 2005-03-15 18:47:34 +09:00 @@ -3328,6 +3328,7 @@ EXPORT_SYMBOL(dev_change_flags); EXPORT_SYMBOL(dev_set_mtu); EXPORT_SYMBOL(dev_set_mac_address); +EXPORT_SYMBOL(dev_get_flags); EXPORT_SYMBOL(free_netdev); EXPORT_SYMBOL(netdev_boot_setup_check); EXPORT_SYMBOL(netdev_set_master); -- Hideaki YOSHIFUJI @ USAGI Project GPG FP: 9022 65EB 1ECF 3AD1 0BDF 80D8 4807 F894 E062 0EEA From herbert@gondor.apana.org.au Tue Mar 15 02:00:08 2005 Received: with ECARTIS (v1.0.0; list netdev); Tue, 15 Mar 2005 02:00:17 -0800 (PST) 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 j2FA06fa013968 for ; Tue, 15 Mar 2005 02:00:07 -0800 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 1DB8pN-0002GK-00; Tue, 15 Mar 2005 20:59:05 +1100 Received: from herbert by gondolin.me.apana.org.au with local (Exim 3.36 #1 (Debian)) id 1DB8ov-0001s3-00; Tue, 15 Mar 2005 20:58:37 +1100 Date: Tue, 15 Mar 2005 20:58:37 +1100 To: "David S. Miller" Cc: Alexey Kuznetsov , YOSHIFUJI Hideaki , Patrick McHardy , netdev@oss.sgi.com Subject: [16/*] [INET] Take IPsec overhead into account in tunnels Message-ID: <20050315095837.GA7130@gondor.apana.org.au> References: <20050214221200.GA18465@gondor.apana.org.au> <20050214221433.GB18465@gondor.apana.org.au> <20050214221607.GC18465@gondor.apana.org.au> <20050306213214.7d8a143d.davem@davemloft.net> <20050307103536.GB7137@gondor.apana.org.au> <20050308102741.GA23468@gondor.apana.org.au> <20050314102614.GA9610@gondor.apana.org.au> <20050314105313.GA21001@gondor.apana.org.au> <20050314111002.GA29156@gondor.apana.org.au> <20050315091904.GA6256@gondor.apana.org.au> Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="XsQoSWH+UP9D9v3l" Content-Disposition: inline In-Reply-To: <20050315091904.GA6256@gondor.apana.org.au> User-Agent: Mutt/1.5.6+20040907i From: Herbert Xu X-Virus-Scanned: ClamAV 0.83/762/Sun Mar 13 15:35:33 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 158 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: herbert@gondor.apana.org.au Precedence: bulk X-list: netdev Content-Length: 4064 Lines: 129 --XsQoSWH+UP9D9v3l Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Hi Dave: This patch uses dst_mtu instead of dst_pmtu in the various tunnel implementations. As it is they simply ignore the IPsec overhead. This leads to bogus MTU values inside the tunnels. Signed-off-by: Herbert Xu BTW, we're doing lazy MTU updates in the tunnel xmit functions. When a packet with DF set hits us and exceeds the updated MTU, we will send an ICMP packet back which is good. Unfortunately when a packet with DF clear hits us as we update the MTU downwards, the packet will be silently discarded instead of fragmented (well we will send an ICMP back to ourselves but we already knew that MTU value :). I presume we want to fix this, right? Cheers, -- Visit Openswan at http://www.openswan.org/ Email: Herbert Xu ~{PmV>HI~} Home Page: http://gondor.apana.org.au/~herbert/ PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt --XsQoSWH+UP9D9v3l Content-Type: text/plain; charset=us-ascii Content-Disposition: attachment; filename=xfrm-16 ===== net/ipv4/ip_gre.c 1.47 vs edited ===== --- 1.47/net/ipv4/ip_gre.c 2005-03-10 16:12:11 +11:00 +++ edited/net/ipv4/ip_gre.c 2005-03-15 20:19:26 +11:00 @@ -511,7 +511,7 @@ /* change mtu on this route */ if (type == ICMP_DEST_UNREACH && code == ICMP_FRAG_NEEDED) { - if (rel_info > dst_pmtu(skb2->dst)) { + if (rel_info > dst_mtu(skb2->dst)) { kfree_skb(skb2); return; } @@ -764,9 +764,9 @@ df = tiph->frag_off; if (df) - mtu = dst_pmtu(&rt->u.dst) - tunnel->hlen; + mtu = dst_mtu(&rt->u.dst) - tunnel->hlen; else - mtu = skb->dst ? dst_pmtu(skb->dst) : dev->mtu; + mtu = skb->dst ? dst_mtu(skb->dst) : dev->mtu; if (skb->dst) skb->dst->ops->update_pmtu(skb->dst, mtu); @@ -785,7 +785,7 @@ else if (skb->protocol == htons(ETH_P_IPV6)) { struct rt6_info *rt6 = (struct rt6_info*)skb->dst; - if (rt6 && mtu < dst_pmtu(skb->dst) && mtu >= IPV6_MIN_MTU) { + if (rt6 && mtu < dst_mtu(skb->dst) && mtu >= IPV6_MIN_MTU) { if ((tunnel->parms.iph.daddr && !MULTICAST(tunnel->parms.iph.daddr)) || rt6->rt6i_dst.plen == 128) { rt6->rt6i_flags |= RTF_MODIFIED; ===== net/ipv4/ipip.c 1.46 vs edited ===== --- 1.46/net/ipv4/ipip.c 2005-01-14 15:41:05 +11:00 +++ edited/net/ipv4/ipip.c 2005-03-15 20:19:26 +11:00 @@ -436,7 +436,7 @@ /* change mtu on this route */ if (type == ICMP_DEST_UNREACH && code == ICMP_FRAG_NEEDED) { - if (rel_info > dst_pmtu(skb2->dst)) { + if (rel_info > dst_mtu(skb2->dst)) { kfree_skb(skb2); return; } @@ -569,9 +569,9 @@ } if (tiph->frag_off) - mtu = dst_pmtu(&rt->u.dst) - sizeof(struct iphdr); + mtu = dst_mtu(&rt->u.dst) - sizeof(struct iphdr); else - mtu = skb->dst ? dst_pmtu(skb->dst) : dev->mtu; + mtu = skb->dst ? dst_mtu(skb->dst) : dev->mtu; if (mtu < 68) { tunnel->stat.collisions++; ===== net/ipv6/ip6_tunnel.c 1.29 vs edited ===== --- 1.29/net/ipv6/ip6_tunnel.c 2005-03-11 13:17:32 +11:00 +++ edited/net/ipv6/ip6_tunnel.c 2005-03-15 20:19:26 +11:00 @@ -689,14 +689,14 @@ t->parms.name); goto tx_err_dst_release; } - mtu = dst_pmtu(dst) - sizeof (*ipv6h); + mtu = dst_mtu(dst) - sizeof (*ipv6h); if (opt) { max_headroom += 8; mtu -= 8; } if (mtu < IPV6_MIN_MTU) mtu = IPV6_MIN_MTU; - if (skb->dst && mtu < dst_pmtu(skb->dst)) { + if (skb->dst && mtu < dst_mtu(skb->dst)) { struct rt6_info *rt = (struct rt6_info *) skb->dst; rt->rt6i_flags |= RTF_MODIFIED; rt->u.dst.metrics[RTAX_MTU-1] = mtu; ===== net/ipv6/sit.c 1.45 vs edited ===== --- 1.45/net/ipv6/sit.c 2005-01-14 15:41:06 +11:00 +++ edited/net/ipv6/sit.c 2005-03-15 20:19:27 +11:00 @@ -500,9 +500,9 @@ } if (tiph->frag_off) - mtu = dst_pmtu(&rt->u.dst) - sizeof(struct iphdr); + mtu = dst_mtu(&rt->u.dst) - sizeof(struct iphdr); else - mtu = skb->dst ? dst_pmtu(skb->dst) : dev->mtu; + mtu = skb->dst ? dst_mtu(skb->dst) : dev->mtu; if (mtu < 68) { tunnel->stat.collisions++; --XsQoSWH+UP9D9v3l-- From herbert@gondor.apana.org.au Tue Mar 15 02:06:21 2005 Received: with ECARTIS (v1.0.0; list netdev); Tue, 15 Mar 2005 02:06:30 -0800 (PST) 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 j2FA6I7k014632 for ; Tue, 15 Mar 2005 02:06:19 -0800 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 1DB8vj-0002JG-00; Tue, 15 Mar 2005 21:05:39 +1100 Received: from herbert by gondolin.me.apana.org.au with local (Exim 3.36 #1 (Debian)) id 1DB8vS-00020Q-00; Tue, 15 Mar 2005 21:05:22 +1100 Date: Tue, 15 Mar 2005 21:05:22 +1100 To: "David S. Miller" Cc: Alexey Kuznetsov , YOSHIFUJI Hideaki , Patrick McHardy , netdev@oss.sgi.com Subject: [17/*] [NET] Replace dst_pmtu with dst_mtu Message-ID: <20050315100522.GA7275@gondor.apana.org.au> References: <20050214221433.GB18465@gondor.apana.org.au> <20050214221607.GC18465@gondor.apana.org.au> <20050306213214.7d8a143d.davem@davemloft.net> <20050307103536.GB7137@gondor.apana.org.au> <20050308102741.GA23468@gondor.apana.org.au> <20050314102614.GA9610@gondor.apana.org.au> <20050314105313.GA21001@gondor.apana.org.au> <20050314111002.GA29156@gondor.apana.org.au> <20050315091904.GA6256@gondor.apana.org.au> <20050315095837.GA7130@gondor.apana.org.au> Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="ikeVEW9yuYc//A+q" Content-Disposition: inline In-Reply-To: <20050315095837.GA7130@gondor.apana.org.au> User-Agent: Mutt/1.5.6+20040907i From: Herbert Xu X-Virus-Scanned: ClamAV 0.83/762/Sun Mar 13 15:35:33 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 159 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: herbert@gondor.apana.org.au Precedence: bulk X-list: netdev Content-Length: 9830 Lines: 291 --ikeVEW9yuYc//A+q Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Hi Dave: This patch replaces most of the other uses of dst_pmtu with dst_mtu. As far as I can tell these are either identical because dst->path == dst, or they're a straightforward replacement of (the slightly incorrect) dst_pmtu(dst) - dst->header_Len with dst_mtu(dst). Signed-off-by: Herbert Xu At this point the only remaining user of dst_pmtu is ipt_REJECT which will go away either when we use icmp_send in there or when I replace it with dst_mtu. We can now remove the other users of dst->path as well with the removal of that attribute itself as the goal. 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 --ikeVEW9yuYc//A+q Content-Type: text/plain; charset=us-ascii Content-Disposition: attachment; filename=xfrm-17 ===== net/decnet/af_decnet.c 1.49 vs edited ===== --- 1.49/net/decnet/af_decnet.c 2005-01-21 09:35:54 +11:00 +++ edited/net/decnet/af_decnet.c 2005-03-15 20:59:05 +11:00 @@ -1868,7 +1868,7 @@ /* This works out the maximum size of segment we can send out */ if (dst) { - u32 mtu = dst_pmtu(dst); + u32 mtu = dst_mtu(dst); mss_now = min_t(int, dn_mss_from_pmtu(dst->dev, mtu), mss_now); } ===== net/decnet/dn_route.c 1.32 vs edited ===== --- 1.32/net/decnet/dn_route.c 2005-03-11 13:17:32 +11:00 +++ edited/net/decnet/dn_route.c 2005-03-15 20:59:05 +11:00 @@ -817,7 +817,7 @@ if (rt->u.dst.metrics[RTAX_MTU-1] == 0 || rt->u.dst.metrics[RTAX_MTU-1] > rt->u.dst.dev->mtu) rt->u.dst.metrics[RTAX_MTU-1] = rt->u.dst.dev->mtu; - mss = dn_mss_from_pmtu(dev, dst_pmtu(&rt->u.dst)); + mss = dn_mss_from_pmtu(dev, dst_mtu(&rt->u.dst)); if (rt->u.dst.metrics[RTAX_ADVMSS-1] == 0 || rt->u.dst.metrics[RTAX_ADVMSS-1] > mss) rt->u.dst.metrics[RTAX_ADVMSS-1] = mss; ===== net/ipv4/ip_output.c 1.76 vs edited ===== --- 1.76/net/ipv4/ip_output.c 2005-02-01 02:43:53 +11:00 +++ edited/net/ipv4/ip_output.c 2005-03-15 20:59:05 +11:00 @@ -278,7 +278,7 @@ newskb->dev, ip_dev_loopback_xmit); } - if (skb->len > dst_pmtu(&rt->u.dst)) + if (skb->len > dst_mtu(&rt->u.dst)) return ip_fragment(skb, ip_finish_output); else return ip_finish_output(skb); @@ -288,7 +288,7 @@ { IP_INC_STATS(IPSTATS_MIB_OUTREQUESTS); - if (skb->len > dst_pmtu(skb->dst) && !skb_shinfo(skb)->tso_size) + if (skb->len > dst_mtu(skb->dst) && !skb_shinfo(skb)->tso_size) return ip_fragment(skb, ip_finish_output); else return ip_finish_output(skb); @@ -448,7 +448,7 @@ if (unlikely((iph->frag_off & htons(IP_DF)) && !skb->local_df)) { icmp_send(skb, ICMP_DEST_UNREACH, ICMP_FRAG_NEEDED, - htonl(dst_pmtu(&rt->u.dst))); + htonl(dst_mtu(&rt->u.dst))); kfree_skb(skb); return -EMSGSIZE; } @@ -458,7 +458,7 @@ */ hlen = iph->ihl * 4; - mtu = dst_pmtu(&rt->u.dst) - hlen; /* Size of data space */ + mtu = dst_mtu(&rt->u.dst) - hlen; /* Size of data space */ /* When frag_list is given, use it. First, check its validity: * some transformers could create wrong frag_list or break existing ===== net/ipv4/ip_sockglue.c 1.31 vs edited ===== --- 1.31/net/ipv4/ip_sockglue.c 2005-01-14 15:41:05 +11:00 +++ edited/net/ipv4/ip_sockglue.c 2005-03-15 20:59:05 +11:00 @@ -955,7 +955,7 @@ val = 0; dst = sk_dst_get(sk); if (dst) { - val = dst_pmtu(dst) - dst->header_len; + val = dst_mtu(dst); dst_release(dst); } if (!val) { ===== net/ipv6/ip6_output.c 1.85 vs edited ===== --- 1.85/net/ipv6/ip6_output.c 2005-03-03 16:12:38 +11:00 +++ edited/net/ipv6/ip6_output.c 2005-03-15 20:59:05 +11:00 @@ -147,7 +147,7 @@ int ip6_output(struct sk_buff *skb) { - if (skb->len > dst_pmtu(skb->dst) || dst_allfrag(skb->dst)) + if (skb->len > dst_mtu(skb->dst) || dst_allfrag(skb->dst)) return ip6_fragment(skb, ip6_output2); else return ip6_output2(skb); @@ -263,7 +263,7 @@ ipv6_addr_copy(&hdr->saddr, &fl->fl6_src); ipv6_addr_copy(&hdr->daddr, first_hop); - mtu = dst_pmtu(dst); + mtu = dst_mtu(dst); if ((skb->len <= mtu) || ipfragok) { IP6_INC_STATS(IPSTATS_MIB_OUTREQUESTS); return NF_HOOK(PF_INET6, NF_IP6_LOCAL_OUT, skb, NULL, dst->dev, ip6_maybe_reroute); @@ -428,10 +428,10 @@ goto error; } - if (skb->len > dst_pmtu(dst)) { + if (skb->len > dst_mtu(dst)) { /* Again, force OUTPUT device used as source address */ skb->dev = dst->dev; - icmpv6_send(skb, ICMPV6_PKT_TOOBIG, 0, dst_pmtu(dst), skb->dev); + icmpv6_send(skb, ICMPV6_PKT_TOOBIG, 0, dst_mtu(dst), skb->dev); IP6_INC_STATS_BH(IPSTATS_MIB_INTOOBIGERRORS); IP6_INC_STATS_BH(IPSTATS_MIB_FRAGFAILS); kfree_skb(skb); @@ -534,7 +534,7 @@ hlen = ip6_find_1stfragopt(skb, &prevhdr); nexthdr = *prevhdr; - mtu = dst_pmtu(&rt->u.dst) - hlen - sizeof(struct frag_hdr); + mtu = dst_mtu(&rt->u.dst) - hlen - sizeof(struct frag_hdr); if (skb_shinfo(skb)->frag_list) { int first_len = skb_pagelen(skb); ===== net/ipv6/ipv6_sockglue.c 1.34 vs edited ===== --- 1.34/net/ipv6/ipv6_sockglue.c 2005-01-14 15:41:06 +11:00 +++ edited/net/ipv6/ipv6_sockglue.c 2005-03-15 20:59:05 +11:00 @@ -607,7 +607,7 @@ lock_sock(sk); dst = sk_dst_get(sk); if (dst) { - val = dst_pmtu(dst) - dst->header_len; + val = dst_mtu(dst); dst_release(dst); } release_sock(sk); ===== net/ipv6/route.c 1.111 vs edited ===== --- 1.111/net/ipv6/route.c 2005-03-11 13:17:32 +11:00 +++ edited/net/ipv6/route.c 2005-03-15 20:59:05 +11:00 @@ -625,7 +625,7 @@ { struct rt6_info *rt6 = (struct rt6_info*)dst; - if (mtu < dst_pmtu(dst) && rt6->rt6i_dst.plen == 128) { + if (mtu < dst_mtu(dst) && rt6->rt6i_dst.plen == 128) { rt6->rt6i_flags |= RTF_MODIFIED; if (mtu < IPV6_MIN_MTU) { mtu = IPV6_MIN_MTU; @@ -686,7 +686,7 @@ atomic_set(&rt->u.dst.__refcnt, 1); rt->u.dst.metrics[RTAX_HOPLIMIT-1] = 255; rt->u.dst.metrics[RTAX_MTU-1] = ipv6_get_mtu(rt->rt6i_dev); - rt->u.dst.metrics[RTAX_ADVMSS-1] = ipv6_advmss(dst_pmtu(&rt->u.dst)); + rt->u.dst.metrics[RTAX_ADVMSS-1] = ipv6_advmss(dst_mtu(&rt->u.dst)); rt->u.dst.output = output; #if 0 /* there's no chance to use these for ndisc */ @@ -971,7 +971,7 @@ if (!rt->u.dst.metrics[RTAX_MTU-1]) rt->u.dst.metrics[RTAX_MTU-1] = ipv6_get_mtu(dev); if (!rt->u.dst.metrics[RTAX_ADVMSS-1]) - rt->u.dst.metrics[RTAX_ADVMSS-1] = ipv6_advmss(dst_pmtu(&rt->u.dst)); + rt->u.dst.metrics[RTAX_ADVMSS-1] = ipv6_advmss(dst_mtu(&rt->u.dst)); rt->u.dst.dev = dev; rt->rt6i_idev = idev; return ip6_ins_rt(rt, nlh, _rtattr); @@ -1134,7 +1134,7 @@ nrt->rt6i_nexthop = neigh_clone(neigh); /* Reset pmtu, it may be better */ nrt->u.dst.metrics[RTAX_MTU-1] = ipv6_get_mtu(neigh->dev); - nrt->u.dst.metrics[RTAX_ADVMSS-1] = ipv6_advmss(dst_pmtu(&nrt->u.dst)); + nrt->u.dst.metrics[RTAX_ADVMSS-1] = ipv6_advmss(dst_mtu(&nrt->u.dst)); if (ip6_ins_rt(nrt, NULL, NULL)) goto out; @@ -1164,7 +1164,7 @@ if (rt == NULL) return; - if (pmtu >= dst_pmtu(&rt->u.dst)) + if (pmtu >= dst_mtu(&rt->u.dst)) goto out; if (pmtu < IPV6_MIN_MTU) { @@ -1405,7 +1405,7 @@ rt->rt6i_dev = &loopback_dev; rt->rt6i_idev = idev; rt->u.dst.metrics[RTAX_MTU-1] = ipv6_get_mtu(rt->rt6i_dev); - rt->u.dst.metrics[RTAX_ADVMSS-1] = ipv6_advmss(dst_pmtu(&rt->u.dst)); + rt->u.dst.metrics[RTAX_ADVMSS-1] = ipv6_advmss(dst_mtu(&rt->u.dst)); rt->u.dst.metrics[RTAX_HOPLIMIT-1] = -1; rt->u.dst.obsolete = -1; @@ -1480,9 +1480,9 @@ */ if (rt->rt6i_dev == arg->dev && !dst_metric_locked(&rt->u.dst, RTAX_MTU) && - (dst_pmtu(&rt->u.dst) > arg->mtu || - (dst_pmtu(&rt->u.dst) < arg->mtu && - dst_pmtu(&rt->u.dst) == idev->cnf.mtu6))) + (dst_mtu(&rt->u.dst) > arg->mtu || + (dst_mtu(&rt->u.dst) < arg->mtu && + dst_mtu(&rt->u.dst) == idev->cnf.mtu6))) rt->u.dst.metrics[RTAX_MTU-1] = arg->mtu; rt->u.dst.metrics[RTAX_ADVMSS-1] = ipv6_advmss(arg->mtu); return 0; ===== net/sctp/transport.c 1.31 vs edited ===== --- 1.31/net/sctp/transport.c 2005-01-15 15:32:41 +11:00 +++ edited/net/sctp/transport.c 2005-03-15 20:59:05 +11:00 @@ -227,7 +227,7 @@ dst = transport->af_specific->get_dst(NULL, &transport->ipaddr, NULL); if (dst) { - transport->pmtu = dst_pmtu(dst); + transport->pmtu = dst_mtu(dst); dst_release(dst); } else transport->pmtu = SCTP_DEFAULT_MAXSEGMENT; @@ -253,7 +253,7 @@ transport->dst = dst; if (dst) { - transport->pmtu = dst_pmtu(dst); + transport->pmtu = dst_mtu(dst); /* Initialize sk->sk_rcv_saddr, if the transport is the * association's active path for getsockname(). ===== net/xfrm/xfrm_policy.c 1.72 vs edited ===== --- 1.72/net/xfrm/xfrm_policy.c 2005-03-11 13:17:32 +11:00 +++ edited/net/xfrm/xfrm_policy.c 2005-03-15 20:59:05 +11:00 @@ -1119,12 +1119,12 @@ struct xfrm_dst *xdst = (struct xfrm_dst *)dst; u32 pmtu, route_mtu_cached; - pmtu = dst_pmtu(dst->child); + pmtu = dst_mtu(dst->child); xdst->child_mtu_cached = pmtu; pmtu = xfrm_state_mtu(dst->xfrm, pmtu); - route_mtu_cached = dst_pmtu(xdst->route); + route_mtu_cached = dst_mtu(xdst->route); xdst->route_mtu_cached = route_mtu_cached; if (pmtu > route_mtu_cached) @@ -1160,7 +1160,7 @@ if (dst->xfrm->km.state != XFRM_STATE_VALID) return 0; - mtu = dst_pmtu(dst->child); + mtu = dst_mtu(dst->child); if (xdst->child_mtu_cached != mtu) { last = xdst; xdst->child_mtu_cached = mtu; @@ -1168,7 +1168,7 @@ if (!dst_check(xdst->route, 0)) return 0; - mtu = dst_pmtu(xdst->route); + mtu = dst_mtu(xdst->route); if (xdst->route_mtu_cached != mtu) { last = xdst; xdst->route_mtu_cached = mtu; --ikeVEW9yuYc//A+q-- From buytenh@wantstofly.org Tue Mar 15 02:20:54 2005 Received: with ECARTIS (v1.0.0; list netdev); Tue, 15 Mar 2005 02:20:58 -0800 (PST) Received: from xi.wantstofly.org (alephnull.demon.nl [212.238.201.82]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j2FAKrr6015586 for ; Tue, 15 Mar 2005 02:20:53 -0800 Received: by xi.wantstofly.org (Postfix, from userid 500) id 24EBA2B0EC; Tue, 15 Mar 2005 11:20:52 +0100 (MET) Date: Tue, 15 Mar 2005 11:20:52 +0100 From: Lennert Buytenhek To: Herbert Xu Cc: "David S. Miller" , Alexey Kuznetsov , YOSHIFUJI Hideaki , Patrick McHardy , netdev@oss.sgi.com Subject: Re: [16/*] [INET] Take IPsec overhead into account in tunnels Message-ID: <20050315102052.GC23800@xi.wantstofly.org> References: <20050214221433.GB18465@gondor.apana.org.au> <20050214221607.GC18465@gondor.apana.org.au> <20050306213214.7d8a143d.davem@davemloft.net> <20050307103536.GB7137@gondor.apana.org.au> <20050308102741.GA23468@gondor.apana.org.au> <20050314102614.GA9610@gondor.apana.org.au> <20050314105313.GA21001@gondor.apana.org.au> <20050314111002.GA29156@gondor.apana.org.au> <20050315091904.GA6256@gondor.apana.org.au> <20050315095837.GA7130@gondor.apana.org.au> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20050315095837.GA7130@gondor.apana.org.au> User-Agent: Mutt/1.4.1i X-Virus-Scanned: ClamAV 0.83/762/Sun Mar 13 15:35:33 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 160 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: buytenh@wantstofly.org Precedence: bulk X-list: netdev Content-Length: 467 Lines: 13 On Tue, Mar 15, 2005 at 08:58:37PM +1100, Herbert Xu wrote: > This patch uses dst_mtu instead of dst_pmtu in the various tunnel > implementations. As it is they simply ignore the IPsec overhead. > This leads to bogus MTU values inside the tunnels. I've not been able to get ipsec-encapsulated ipip/gre tunneling to work properly (without MTU issues) so far, and never had the time to properly dig into it. If this is going to be fixed, that would be great. --L From herbert@gondor.apana.org.au Tue Mar 15 02:29:05 2005 Received: with ECARTIS (v1.0.0; list netdev); Tue, 15 Mar 2005 02:29:12 -0800 (PST) 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 j2FAT3bs016406 for ; Tue, 15 Mar 2005 02:29:04 -0800 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 1DB9HV-0002Xc-00; Tue, 15 Mar 2005 21:28:09 +1100 Received: from herbert by gondolin.me.apana.org.au with local (Exim 3.36 #1 (Debian)) id 1DB9Gw-00053F-00; Tue, 15 Mar 2005 21:27:34 +1100 Date: Tue, 15 Mar 2005 21:27:34 +1100 To: Lennert Buytenhek Cc: "David S. Miller" , Alexey Kuznetsov , YOSHIFUJI Hideaki , Patrick McHardy , netdev@oss.sgi.com Subject: Re: [16/*] [INET] Take IPsec overhead into account in tunnels Message-ID: <20050315102734.GB19203@gondor.apana.org.au> References: <20050214221607.GC18465@gondor.apana.org.au> <20050306213214.7d8a143d.davem@davemloft.net> <20050307103536.GB7137@gondor.apana.org.au> <20050308102741.GA23468@gondor.apana.org.au> <20050314102614.GA9610@gondor.apana.org.au> <20050314105313.GA21001@gondor.apana.org.au> <20050314111002.GA29156@gondor.apana.org.au> <20050315091904.GA6256@gondor.apana.org.au> <20050315095837.GA7130@gondor.apana.org.au> <20050315102052.GC23800@xi.wantstofly.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20050315102052.GC23800@xi.wantstofly.org> User-Agent: Mutt/1.5.6+20040907i From: Herbert Xu X-Virus-Scanned: ClamAV 0.83/762/Sun Mar 13 15:35:33 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 161 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: herbert@gondor.apana.org.au Precedence: bulk X-list: netdev Content-Length: 565 Lines: 13 On Tue, Mar 15, 2005 at 11:20:52AM +0100, Lennert Buytenhek wrote: > > I've not been able to get ipsec-encapsulated ipip/gre tunneling to > work properly (without MTU issues) so far, and never had the time to > properly dig into it. If this is going to be fixed, that would be > great. Well please give it a run and let me know if it's still broken :) -- 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 bernd.schubert@pci.uni-heidelberg.de Tue Mar 15 03:34:59 2005 Received: with ECARTIS (v1.0.0; list netdev); Tue, 15 Mar 2005 03:35:04 -0800 (PST) Received: from relay.uni-heidelberg.de (relay.uni-heidelberg.de [129.206.100.212]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j2FBYvRL021386 for ; Tue, 15 Mar 2005 03:34:58 -0800 Received: from hamilton1.pci.uni-heidelberg.de (hamilton1.pci.uni-heidelberg.de [129.206.21.201]) by relay.uni-heidelberg.de (8.12.10/8.12.10) with ESMTP id j2FBZKfK026334; Tue, 15 Mar 2005 12:35:20 +0100 (MET) Received: from euklid.pci.uni-heidelberg.de ([129.206.21.104] helo=euklid ident=foobar) by hamilton1.pci.uni-heidelberg.de with smtp (Exim 3.35 #1 (Debian)) id 1DBAJt-0002zQ-00; Tue, 15 Mar 2005 12:34:41 +0100 Received: by euklid (sSMTP sendmail emulation); Tue, 15 Mar 2005 12:34:41 +0100 From: Bernd Schubert To: "David S. Miller" Subject: Re: network speed extremly slowed down Date: Tue, 15 Mar 2005 12:34:31 +0100 User-Agent: KMail/1.6.2 Cc: Stephen Hemminger , netdev@oss.sgi.com References: <200503141745.08032.bernd.schubert@pci.uni-heidelberg.de> <20050314115757.789a82d4@dxpl.pdx.osdl.net> <20050314121509.70dcd129.davem@davemloft.net> In-Reply-To: <20050314121509.70dcd129.davem@davemloft.net> MIME-Version: 1.0 Content-Disposition: inline Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <200503151234.33166.bernd.schubert@pci.uni-heidelberg.de> X-Virus-Scanned: ClamAV 0.83/762/Sun Mar 13 15:35:33 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 162 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: bernd.schubert@pci.uni-heidelberg.de Precedence: bulk X-list: netdev Content-Length: 463 Lines: 14 On Monday 14 March 2005 21:15, David S. Miller wrote: > On Mon, 14 Mar 2005 11:57:57 -0800 > > Stephen Hemminger wrote: > > Are there any errors reported? Cpu time sees high perhaps the console log > > is filling with messages or something. > > Or he has CONFIG_DEBUG_SLAB enabled in his kernel config. > So many people do this unknowingly. Thanks a lot, disabling debugging support solved our network speed problems. Thanks again, Bernd From bunk@stusta.de Tue Mar 15 04:20:25 2005 Received: with ECARTIS (v1.0.0; list netdev); Tue, 15 Mar 2005 04:20:33 -0800 (PST) Received: from mailout.stusta.mhn.de (emailhub.stusta.mhn.de [141.84.69.5]) by oss.sgi.com (8.13.0/8.13.0) with SMTP id j2FCKOpS026862 for ; Tue, 15 Mar 2005 04:20:25 -0800 Received: (qmail 29517 invoked from network); 15 Mar 2005 12:20:18 -0000 Received: from r063144.stusta.swh.mhn.de (10.150.63.144) by mailout.stusta.mhn.de with SMTP; 15 Mar 2005 12:20:18 -0000 Received: by r063144.stusta.swh.mhn.de (Postfix, from userid 1000) id BDC48BB685; Tue, 15 Mar 2005 13:20:17 +0100 (CET) Date: Tue, 15 Mar 2005 13:20:17 +0100 From: Adrian Bunk To: "David S. Miller" Cc: netdev@oss.sgi.com, linux-kernel@vger.kernel.org Subject: [2.6 patch] net/802/fc.c: remove fc_type_trans Message-ID: <20050315122017.GF3189@stusta.de> References: <20050306205754.GO5070@stusta.de> <20050314214940.4947ccd9.davem@davemloft.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20050314214940.4947ccd9.davem@davemloft.net> User-Agent: Mutt/1.5.6+20040907i X-Virus-Scanned: ClamAV 0.83/762/Sun Mar 13 15:35:33 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 163 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: bunk@stusta.de Precedence: bulk X-list: netdev Content-Length: 2422 Lines: 89 On Mon, Mar 14, 2005 at 09:49:40PM -0800, David S. Miller wrote: > On Sun, 6 Mar 2005 21:57:54 +0100 > Adrian Bunk wrote: > > > The only user of fc_type_trans (drivers/net/fc/iph5526.c) is BROKEN in > > 2.6 and removed in -mm. > > > > Signed-off-by: Adrian Bunk > > That driver isn't in Linus's tree any longer either. Just delete > the thing altogether instead of #if 0'ing it. >... Updated patch: <-- snip --> The only user of fc_type_trans (drivers/net/fc/iph5526.c) is removed in Linus' tree. Signed-off-by: Adrian Bunk --- include/linux/fcdevice.h | 2 -- net/802/fc.c | 34 ---------------------------------- 2 files changed, 36 deletions(-) --- linux-2.6.11-mm1-full/include/linux/fcdevice.h.old 2005-03-06 21:40:36.000000000 +0100 +++ linux-2.6.11-mm1-full/include/linux/fcdevice.h 2005-03-06 21:41:07.000000000 +0100 @@ -24,12 +24,10 @@ #define _LINUX_FCDEVICE_H #include #ifdef __KERNEL__ -extern unsigned short fc_type_trans(struct sk_buff *skb, struct net_device *dev); - extern struct net_device *alloc_fcdev(int sizeof_priv); #endif #endif /* _LINUX_FCDEVICE_H */ --- linux-2.6.11-mm3-full/net/802/fc.c.old 2005-03-15 13:02:13.000000000 +0100 +++ linux-2.6.11-mm3-full/net/802/fc.c 2005-03-15 13:02:34.000000000 +0100 @@ -97,40 +97,6 @@ #endif } -unsigned short -fc_type_trans(struct sk_buff *skb, struct net_device *dev) -{ - struct fch_hdr *fch = (struct fch_hdr *)skb->data; - struct fcllc *fcllc; - - skb->mac.raw = skb->data; - fcllc = (struct fcllc *)(skb->data + sizeof (struct fch_hdr) + 2); - skb_pull(skb, sizeof (struct fch_hdr) + 2); - - if (*fch->daddr & 1) { - if (!memcmp(fch->daddr, dev->broadcast, FC_ALEN)) - skb->pkt_type = PACKET_BROADCAST; - else - skb->pkt_type = PACKET_MULTICAST; - } else if (dev->flags & IFF_PROMISC) { - if (memcmp(fch->daddr, dev->dev_addr, FC_ALEN)) - skb->pkt_type = PACKET_OTHERHOST; - } - - /* - * Strip the SNAP header from ARP packets since we don't pass - * them through to the 802.2/SNAP layers. - */ - if (fcllc->dsap == EXTENDED_SAP && - (fcllc->ethertype == ntohs(ETH_P_IP) || - fcllc->ethertype == ntohs(ETH_P_ARP))) { - skb_pull(skb, sizeof (struct fcllc)); - return fcllc->ethertype; - } - - return ntohs(ETH_P_802_2); -} - static void fc_setup(struct net_device *dev) { dev->hard_header = fc_header; From bunk@stusta.de Tue Mar 15 04:23:09 2005 Received: with ECARTIS (v1.0.0; list netdev); Tue, 15 Mar 2005 04:23:14 -0800 (PST) Received: from mailout.stusta.mhn.de (emailhub.stusta.mhn.de [141.84.69.5]) by oss.sgi.com (8.13.0/8.13.0) with SMTP id j2FCN8Zt027395 for ; Tue, 15 Mar 2005 04:23:08 -0800 Received: (qmail 29640 invoked from network); 15 Mar 2005 12:23:03 -0000 Received: from r063144.stusta.swh.mhn.de (10.150.63.144) by mailhub.stusta.mhn.de with SMTP; 15 Mar 2005 12:23:03 -0000 Received: by r063144.stusta.swh.mhn.de (Postfix, from userid 1000) id AD345BB685; Tue, 15 Mar 2005 13:22:59 +0100 (CET) Resent-From: bunk@stusta.de Resent-Date: Tue, 15 Mar 2005 13:22:59 +0100 Resent-Message-ID: <20050315122259.GG3189@stusta.de> Resent-To: netdev@oss.sgi.com Date: Tue, 15 Mar 2005 13:19:30 +0100 From: Adrian Bunk To: shemminger@osdl.org, bridge@osdl.org, chas@cmf.nrl.navy.mil Cc: linux-atm-general@lists.sourceforge.net, netdev@oss.sgi.co, linux-kernel@vger.kernel.org Subject: [2.6 patch] fix bridge <-> ATM compile error Message-ID: <20050315121930.GE3189@stusta.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.5.6+20040907i X-Virus-Scanned: ClamAV 0.83/762/Sun Mar 13 15:35:33 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 164 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: bunk@stusta.de Precedence: bulk X-list: netdev Content-Length: 1702 Lines: 56 This patch fixes the following compile error with CONFIG_BRIDGE=y and CONFIG_ATM_LANE=m: <-- snip --> ... LD .tmp_vmlinux1 net/built-in.o(.init.text+0x3ad1): In function `br_init': : undefined reference to `br_fdb_get_hook' net/built-in.o(.init.text+0x3adb): In function `br_init': : undefined reference to `br_fdb_put_hook' net/built-in.o(.exit.text+0xa2): In function `br_deinit': : undefined reference to `br_fdb_get_hook' net/built-in.o(.exit.text+0xac): In function `br_deinit': : undefined reference to `br_fdb_put_hook' make: *** [.tmp_vmlinux1] Error 1 <-- snip --> Signed-off-by: Adrian Bunk --- net/bridge/br.c | 6 +++--- 1 files changed, 3 insertions(+), 3 deletions(-) --- linux-2.6.11-mm3-modular/net/bridge/br.c.old 2005-03-15 03:23:10.000000000 +0100 +++ linux-2.6.11-mm3-modular/net/bridge/br.c 2005-03-15 03:24:05.000000000 +0100 @@ -22,7 +22,7 @@ #include "br_private.h" -#if defined(CONFIG_ATM_LANE) || defined(CONFIG_ATM_LANE_MODULE) +#if defined(CONFIG_ATM_LANE) || (defined(CONFIG_ATM_LANE_MODULE) && defined(MODULE)) #include "../atm/lec.h" #endif @@ -39,7 +39,7 @@ brioctl_set(br_ioctl_deviceless_stub); br_handle_frame_hook = br_handle_frame; -#if defined(CONFIG_ATM_LANE) || defined(CONFIG_ATM_LANE_MODULE) +#if defined(CONFIG_ATM_LANE) || (defined(CONFIG_ATM_LANE_MODULE) && defined(MODULE)) br_fdb_get_hook = br_fdb_get; br_fdb_put_hook = br_fdb_put; #endif @@ -60,7 +60,7 @@ synchronize_net(); -#if defined(CONFIG_ATM_LANE) || defined(CONFIG_ATM_LANE_MODULE) +#if defined(CONFIG_ATM_LANE) || (defined(CONFIG_ATM_LANE_MODULE) && defined(MODULE)) br_fdb_get_hook = NULL; br_fdb_put_hook = NULL; #endif From mkomu@twilight.cs.hut.fi Tue Mar 15 04:56:50 2005 Received: with ECARTIS (v1.0.0; list netdev); Tue, 15 Mar 2005 04:56:57 -0800 (PST) Received: from twilight.cs.hut.fi (twilight.cs.hut.fi [130.233.40.5]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j2FCunTt028692 for ; Tue, 15 Mar 2005 04:56:50 -0800 Received: by twilight.cs.hut.fi (Postfix, from userid 60001) id 6506B2E08; Tue, 15 Mar 2005 14:56:44 +0200 (EET) Received: from kekkonen.cs.hut.fi (kekkonen.cs.hut.fi [130.233.41.50]) by twilight.cs.hut.fi (Postfix) with ESMTP id A30DA2DF0; Tue, 15 Mar 2005 14:56:42 +0200 (EET) Received: (from mkomu@localhost) by kekkonen.cs.hut.fi (8.11.7p1+Sun/8.10.2) id j2FCugP05522; Tue, 15 Mar 2005 14:56:42 +0200 (EET) Date: Tue, 15 Mar 2005 14:56:42 +0200 (EET) From: Miika Komu X-X-Sender: mkomu@kekkonen.cs.hut.fi To: Pekka Savola Cc: Andrei Gurtov , netdev@oss.sgi.com, infrahip@hiit.fi Subject: Re: [Infrahip] Re: [PATCH] Host Identity Protocol In-Reply-To: Message-ID: References: <42369919.9010203@cs.helsinki.fi> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Virus-Scanned: ClamAV 0.83/762/Sun Mar 13 15:35:33 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 165 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: miika@iki.fi Precedence: bulk X-list: netdev Content-Length: 561 Lines: 15 On Tue, 15 Mar 2005, Pekka Savola wrote: > On Tue, 15 Mar 2005, Andrei Gurtov wrote: > > Please have a look at Host Identity Protocol, a better solution for secure > > mobility and multihoming than Mobile IP. > > > > http://hipl.hiit.fi/hipl/release/kernel-patches/linux-2.6.10-hipl-0.1.patch > > Please clean up the patch :). It has tons of changes which have > nothing to do with HIP. Maybe it was diffed against the wrong tree? Fixed. I replaced the old patch with a clean one. -- Miika Komu miika@iki.fi http://www.iki.fi/miika/ From tgraf@suug.ch Tue Mar 15 05:39:46 2005 Received: with ECARTIS (v1.0.0; list netdev); Tue, 15 Mar 2005 05:39:51 -0800 (PST) Received: from b.mx.projectdream.org (eth0-0.arisu.projectdream.org [194.158.4.191]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j2FDdjUv030305 for ; Tue, 15 Mar 2005 05:39:45 -0800 Received: from postel.suug.ch (postel.suug.ch [195.134.158.23]) (using TLSv1 with cipher EDH-RSA-DES-CBC3-SHA (168/168 bits)) (No client certificate requested) by b.mx.projectdream.org (Postfix) with ESMTP id 30FB3F; Tue, 15 Mar 2005 14:39:20 +0100 (CET) Received: by postel.suug.ch (Postfix, from userid 10001) id 2AEDE1C0EA; Tue, 15 Mar 2005 14:40:03 +0100 (CET) Date: Tue, 15 Mar 2005 14:40:02 +0100 From: Thomas Graf To: "YOSHIFUJI Hideaki / ?$B5HF#1QL@" Cc: mroos@linux.ee, davem@davemloft.net, netdev@oss.sgi.com Subject: Re: ipv6 unresolved symbol Message-ID: <20050315134002.GE3086@postel.suug.ch> References: <20050315.185815.12690947.yoshfuji@linux-ipv6.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20050315.185815.12690947.yoshfuji@linux-ipv6.org> X-Virus-Scanned: ClamAV 0.83/762/Sun Mar 13 15:35:33 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 166 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: tgraf@suug.ch Precedence: bulk X-list: netdev Content-Length: 471 Lines: 10 * YOSHIFUJI Hideaki / ?$B5HF#1QL@ <20050315.185815.12690947.yoshfuji@linux-ipv6.org> 2005-03-15 18:58 > In article (at Tue, 15 Mar 2005 11:36:42 +0200 (EET)), Meelis Roos says: > > > This is todays 2.6.11+BK on x86 with modular ipv6: > > > > WARNING: /lib/modules/2.6.11/kernel/net/ipv6/ipv6.ko needs unknown symbol dev_get_flags > > Oops, thanks. Stupid me, should have checked that, thanks for the fix. From bunk@stusta.de Tue Mar 15 06:39:11 2005 Received: with ECARTIS (v1.0.0; list netdev); Tue, 15 Mar 2005 06:39:16 -0800 (PST) Received: from mailout.stusta.mhn.de (mailout.stusta.mhn.de [141.84.69.5]) by oss.sgi.com (8.13.0/8.13.0) with SMTP id j2FEd9GB032686 for ; Tue, 15 Mar 2005 06:39:10 -0800 Received: (qmail 1788 invoked from network); 15 Mar 2005 14:39:04 -0000 Received: from r063144.stusta.swh.mhn.de (10.150.63.144) by mailhub.stusta.mhn.de with SMTP; 15 Mar 2005 14:39:04 -0000 Received: by r063144.stusta.swh.mhn.de (Postfix, from userid 1000) id 60813BB685; Tue, 15 Mar 2005 15:39:03 +0100 (CET) Date: Tue, 15 Mar 2005 15:39:03 +0100 From: Adrian Bunk To: marcel@holtmann.org, maxk@qualcomm.com Cc: bluez-devel@lists.sourceforge.net, netdev@oss.sgi.com, linux-kernel@vger.kernel.org Subject: [2.6 patch] net/bluetooth/rfcomm/core.: make a variable static Message-ID: <20050315143903.GK3189@stusta.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.5.6+20040907i X-Virus-Scanned: ClamAV 0.83/762/Sun Mar 13 15:35:33 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 167 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: bunk@stusta.de Precedence: bulk X-list: netdev Content-Length: 526 Lines: 16 This patch makes a needlessly global variable static. Signed-off-by: Adrian Bunk --- linux-2.6.11-mm3-full/net/bluetooth/rfcomm/core.c.old 2005-03-15 13:21:50.000000000 +0100 +++ linux-2.6.11-mm3-full/net/bluetooth/rfcomm/core.c 2005-03-15 13:22:03.000000000 +0100 @@ -68,7 +68,7 @@ #define rfcomm_lock() down(&rfcomm_sem); #define rfcomm_unlock() up(&rfcomm_sem); -unsigned long rfcomm_event; +static unsigned long rfcomm_event; static LIST_HEAD(session_list); static atomic_t terminate, running; From bunk@stusta.de Tue Mar 15 06:44:15 2005 Received: with ECARTIS (v1.0.0; list netdev); Tue, 15 Mar 2005 06:44:19 -0800 (PST) Received: from mailout.stusta.mhn.de (emailhub.stusta.mhn.de [141.84.69.5]) by oss.sgi.com (8.13.0/8.13.0) with SMTP id j2FEiEqg000780 for ; Tue, 15 Mar 2005 06:44:15 -0800 Received: (qmail 1957 invoked from network); 15 Mar 2005 14:44:09 -0000 Received: from r063144.stusta.swh.mhn.de (10.150.63.144) by mailout.stusta.mhn.de with SMTP; 15 Mar 2005 14:44:09 -0000 Received: by r063144.stusta.swh.mhn.de (Postfix, from userid 1000) id 5CC33BB685; Tue, 15 Mar 2005 15:44:08 +0100 (CET) Date: Tue, 15 Mar 2005 15:44:08 +0100 From: Adrian Bunk To: "David S. Miller" Cc: netdev@oss.sgi.com, linux-kernel@vger.kernel.org Subject: [2.6 patch] net/ipv4/inetpeer.c: make a struct static Message-ID: <20050315144408.GL3189@stusta.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.5.6+20040907i X-Virus-Scanned: ClamAV 0.83/762/Sun Mar 13 15:35:33 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 168 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: bunk@stusta.de Precedence: bulk X-list: netdev Content-Length: 769 Lines: 19 This patch makes a needlessly global struct static. Signed-off-by: Adrian Bunk --- linux-2.6.11-mm3-full/net/ipv4/inetpeer.c.old 2005-03-15 13:29:32.000000000 +0100 +++ linux-2.6.11-mm3-full/net/ipv4/inetpeer.c 2005-03-15 13:30:13.000000000 +0100 @@ -92,9 +92,9 @@ int inet_peer_minttl = 120 * HZ; /* TTL under high load: 120 sec */ int inet_peer_maxttl = 10 * 60 * HZ; /* usual time to live: 10 min */ +static struct inet_peer *inet_peer_unused_head; /* Exported for inet_putpeer inline function. */ -struct inet_peer *inet_peer_unused_head, - **inet_peer_unused_tailp = &inet_peer_unused_head; +struct inet_peer **inet_peer_unused_tailp = &inet_peer_unused_head; DEFINE_SPINLOCK(inet_peer_unused_lock); #define PEER_MAX_CLEANUP_WORK 30 From bunk@stusta.de Tue Mar 15 06:47:20 2005 Received: with ECARTIS (v1.0.0; list netdev); Tue, 15 Mar 2005 06:47:24 -0800 (PST) Received: from mailout.stusta.mhn.de (emailhub.stusta.mhn.de [141.84.69.5]) by oss.sgi.com (8.13.0/8.13.0) with SMTP id j2FElIAl001346 for ; Tue, 15 Mar 2005 06:47:19 -0800 Received: (qmail 2120 invoked from network); 15 Mar 2005 14:47:13 -0000 Received: from r063144.stusta.swh.mhn.de (10.150.63.144) by mailhub.stusta.mhn.de with SMTP; 15 Mar 2005 14:47:13 -0000 Received: by r063144.stusta.swh.mhn.de (Postfix, from userid 1000) id 045B8BB685; Tue, 15 Mar 2005 15:47:13 +0100 (CET) Date: Tue, 15 Mar 2005 15:47:13 +0100 From: Adrian Bunk To: "David S. Miller" Cc: netdev@oss.sgi.com, linux-kernel@vger.kernel.org Subject: [2.6 patch] net/ipv6/ndisc.c: make a function static Message-ID: <20050315144712.GM3189@stusta.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.5.6+20040907i X-Virus-Scanned: ClamAV 0.83/762/Sun Mar 13 15:35:33 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 169 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: bunk@stusta.de Precedence: bulk X-list: netdev Content-Length: 774 Lines: 23 This patch makes a needlessly global function static. Signed-off-by: Adrian Bunk --- linux-2.6.11-mm3-full/net/ipv6/ndisc.c.old 2005-03-15 13:33:29.000000000 +0100 +++ linux-2.6.11-mm3-full/net/ipv6/ndisc.c 2005-03-15 13:34:03.000000000 +0100 @@ -1594,10 +1594,11 @@ return ret; } -int ndisc_ifinfo_sysctl_strategy(ctl_table *ctl, int __user *name, int nlen, - void __user *oldval, size_t __user *oldlenp, - void __user *newval, size_t newlen, - void **context) +static int ndisc_ifinfo_sysctl_strategy(ctl_table *ctl, int __user *name, + int nlen, void __user *oldval, + size_t __user *oldlenp, + void __user *newval, size_t newlen, + void **context) { struct net_device *dev = ctl->extra1; struct inet6_dev *idev; From bunk@stusta.de Tue Mar 15 06:49:14 2005 Received: with ECARTIS (v1.0.0; list netdev); Tue, 15 Mar 2005 06:49:18 -0800 (PST) Received: from mailout.stusta.mhn.de (mailout.stusta.mhn.de [141.84.69.5]) by oss.sgi.com (8.13.0/8.13.0) with SMTP id j2FEnDcH001871 for ; Tue, 15 Mar 2005 06:49:14 -0800 Received: (qmail 2188 invoked from network); 15 Mar 2005 14:49:08 -0000 Received: from r063144.stusta.swh.mhn.de (10.150.63.144) by mailhub.stusta.mhn.de with SMTP; 15 Mar 2005 14:49:08 -0000 Received: by r063144.stusta.swh.mhn.de (Postfix, from userid 1000) id 4BFA0BB685; Tue, 15 Mar 2005 15:49:07 +0100 (CET) Date: Tue, 15 Mar 2005 15:49:07 +0100 From: Adrian Bunk To: Robert Olsson Cc: "David S. Miller" , netdev@oss.sgi.com, linux-kernel@vger.kernel.org Subject: [2.6 patch] net/core/pktgen.c: make a function static Message-ID: <20050315144907.GN3189@stusta.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.5.6+20040907i X-Virus-Scanned: ClamAV 0.83/762/Sun Mar 13 15:35:33 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 170 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: bunk@stusta.de Precedence: bulk X-list: netdev Content-Length: 581 Lines: 19 pktgen_xmit is already inline but not static. This doesn't make much sense - especially since there's no external user of this function. Signed-off-by: Adrian Bunk --- linux-2.6.11-mm3-full/net/core/pktgen.c.old 2005-03-15 13:25:04.000000000 +0100 +++ linux-2.6.11-mm3-full/net/core/pktgen.c 2005-03-15 13:25:20.000000000 +0100 @@ -2587,7 +2587,7 @@ thread_unlock(); } -__inline__ void pktgen_xmit(struct pktgen_dev *pkt_dev) +static inline void pktgen_xmit(struct pktgen_dev *pkt_dev) { struct net_device *odev = NULL; __u64 idle_start = 0; From leonid.grossman@neterion.com Tue Mar 15 07:09:06 2005 Received: with ECARTIS (v1.0.0; list netdev); Tue, 15 Mar 2005 07:09:10 -0800 (PST) Received: from ns1.s2io.com (ns1.s2io.com [142.46.200.198]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j2FF95dd002957 for ; Tue, 15 Mar 2005 07:09:06 -0800 Received: from guinness.s2io.com (sentry.s2io.com [142.46.200.199]) by ns1.s2io.com (8.12.10/8.12.10) with ESMTP id j2FF7wuN018095; Tue, 15 Mar 2005 10:07:58 -0500 (EST) Received: from lgt40 ([10.16.16.166]) by guinness.s2io.com (8.12.6/8.12.6) with ESMTP id j2FF7sDD011131; Tue, 15 Mar 2005 10:07:55 -0500 (EST) Message-Id: <200503151507.j2FF7sDD011131@guinness.s2io.com> From: "Leonid Grossman" To: , Cc: , , , "'Andi Kleen'" Subject: RE: [ANNOUNCE] Experimental Driver for Neterion/S2io 10GbE Adapters Date: Tue, 15 Mar 2005 07:07:54 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook, Build 11.0.5510 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1409 In-Reply-To: <200503150108.j2F18FDD016965@guinness.s2io.com> Thread-Index: AcUo7WqOR9kQG616RWi2m3tBhTo9eAABn6OwAAVZ0bA= X-Scanned-By: MIMEDefang 2.34 X-Virus-Scanned: ClamAV 0.83/762/Sun Mar 13 15:35:33 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 171 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: leonid.grossman@neterion.com Precedence: bulk X-list: netdev Content-Length: 1158 Lines: 34 > Alex Aizman writes: > However, the main question remains: will the > HAL-based driver (because even after the script-produced "surgery" it'll > continue to be HAL based) ever get accepted? Hi all, We truly appreciate the time spent on looking at the code and the feedback.. I guess Alex is asking the right question - before we start code changes, it will be great to get a rough consensus on whether this HAL-based driver (after suggested changes) will be acceptable to the community - or yet another HAL driver in tree will be still "one too many"? In particular - after this discussion, does David's statement below still stand (not sure there was an unconditional rejection of the HAL model from someone else)? >David Miller writes: >I totally reject this driver, HAL is unacceptable for in-tree drivers. >We've been over this a thousand times. If this stands, we are prepared to recall the submission and keep the current "Linux and everything else" status-quo for 10GbE Xframe drivers. It's not the best maintenance option (both for us and arguably, even for a non-primary-author kernel hackers) but it's workable. Thanks again, Leonid From Robert.Olsson@data.slu.se Tue Mar 15 07:39:28 2005 Received: with ECARTIS (v1.0.0; list netdev); Tue, 15 Mar 2005 07:39:32 -0800 (PST) Received: from mx1.slu.se (mx1.slu.se [130.238.96.70]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j2FFdQjq003984 for ; Tue, 15 Mar 2005 07:39:27 -0800 Received: from robur.slu.se (robur.slu.se [130.238.98.12]) by mx1.slu.se (8.13.1/8.13.1) with ESMTP id j2FFdINO001103; Tue, 15 Mar 2005 16:39:19 +0100 Received: by robur.slu.se (Postfix, from userid 1000) id D4D66EE1D2; Tue, 15 Mar 2005 16:39:18 +0100 (CET) From: Robert Olsson MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <16951.422.818446.117190@robur.slu.se> Date: Tue, 15 Mar 2005 16:39:18 +0100 To: cliff white Cc: Robert.Olsson@data.slu.se, netdev@oss.sgi.com Subject: Constant errors with pktgen In-Reply-To: <20050314133404.2528647f@es175> References: <20050314133404.2528647f@es175> X-Mailer: VM 7.18 under Emacs 21.3.1 X-Scanned-By: MIMEDefang 2.48 on 130.238.96.70 X-Virus-Scanned: ClamAV 0.83/762/Sun Mar 13 15:35:33 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 172 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: Robert.Olsson@data.slu.se Precedence: bulk X-list: netdev Content-Length: 1805 Lines: 71 cliff white writes: > My test rig is two machines with an e100 card, connected by crossover > cable. > > When i run pktgen, the error counter == packet count, always. I see. Try the patch patch below it cleans up the code a bit and restores the old meaning of error. It also has the minor fix from Adrian Bunk --ro --- net/core/pktgen.c.050315 2005-03-11 10:48:43.000000000 +0100 +++ net/core/pktgen.c 2005-03-15 16:16:01.000000000 +0100 @@ -151,7 +151,7 @@ #include -#define VERSION "pktgen v2.60: Packet Generator for packet performance testing.\n" +#define VERSION "pktgen v2.61: Packet Generator for packet performance testing.\n" /* #define PG_DEBUG(a) a */ #define PG_DEBUG(a) @@ -2590,7 +2590,7 @@ thread_unlock(); } -__inline__ void pktgen_xmit(struct pktgen_dev *pkt_dev) +static __inline__ void pktgen_xmit(struct pktgen_dev *pkt_dev) { struct net_device *odev = NULL; __u64 idle_start = 0; @@ -2654,7 +2654,6 @@ spin_lock_bh(&odev->xmit_lock); if (!netif_queue_stopped(odev)) { - u64 now; atomic_inc(&(pkt_dev->skb->users)); retry_now: @@ -2678,24 +2677,18 @@ pkt_dev->errors++; pkt_dev->last_ok = 0; - pkt_dev->next_tx_us = getCurUs(); /* TODO */ - pkt_dev->next_tx_ns = 0; } + pkt_dev->next_tx_us = getCurUs(); + pkt_dev->next_tx_ns = 0; + pkt_dev->next_tx_us += pkt_dev->delay_us; pkt_dev->next_tx_ns += pkt_dev->delay_ns; + if (pkt_dev->next_tx_ns > 1000) { pkt_dev->next_tx_us++; pkt_dev->next_tx_ns -= 1000; } - - now = getCurUs(); - if (now > pkt_dev->next_tx_us) { - /* TODO: this code is slightly wonky. */ - pkt_dev->errors++; - pkt_dev->next_tx_us = now - pkt_dev->delay_us; - pkt_dev->next_tx_ns = 0; - } } else { /* Retry it next time */ From leonid.grossman@neterion.com Tue Mar 15 07:57:04 2005 Received: with ECARTIS (v1.0.0; list netdev); Tue, 15 Mar 2005 07:57:09 -0800 (PST) Received: from ns1.s2io.com (ns1.s2io.com [142.46.200.198]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j2FFv404005073 for ; Tue, 15 Mar 2005 07:57:04 -0800 Received: from guinness.s2io.com (sentry.s2io.com [142.46.200.199]) by ns1.s2io.com (8.12.10/8.12.10) with ESMTP id j2FFtsuN018371; Tue, 15 Mar 2005 10:55:54 -0500 (EST) Received: from lgt40 ([10.16.16.166]) by guinness.s2io.com (8.12.6/8.12.6) with ESMTP id j2FFtqDD019050; Tue, 15 Mar 2005 10:55:52 -0500 (EST) Message-Id: <200503151555.j2FFtqDD019050@guinness.s2io.com> From: "Leonid Grossman" To: "'Leonid Grossman'" , , Cc: , , , "'Andi Kleen'" Subject: RE: [ANNOUNCE] Experimental Driver for Neterion/S2io 10GbE Adapters Date: Tue, 15 Mar 2005 07:55:51 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook, Build 11.0.5510 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1409 In-Reply-To: <200503151507.j2FF7sDD011131@guinness.s2io.com> Thread-Index: AcUo7WqOR9kQG616RWi2m3tBhTo9eAABn6OwAAVZ0bAAGueVUA== X-Scanned-By: MIMEDefang 2.34 X-Virus-Scanned: ClamAV 0.83/762/Sun Mar 13 15:35:33 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 173 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: leonid.grossman@neterion.com Precedence: bulk X-list: netdev Content-Length: 1444 Lines: 33 > > > Leonid Grossman writes: > It's not the best maintenance option (both for us and arguably, even for a > non-primary-author kernel hackers) but it's workable. The statement about non-primary-author kernel hacker interests needs some clarification, before people started to throw things at me. This is the last argument before I shut up, I promise :-) Arguably, a hacker will be much more interested in changing the non-HAL part of a driver. This part of the code has to look and feel the same as any other Linux net driver. If it doesn't, then we've done a poor job and need to go back. In our experience, the vast majority of code fixes and new features in the HAL code comes from our team (hey, we planted all these bugs to begin with :-)), and to a much lesser extend from other OS developers, and only then from Linux community. This is normal - for example, if Large Receive Offload that was discussed earlier is to be done, I'd expect a hacker to focus on the kernel changes and generic driver changes (to make a feature common to all net driver that want it), and a Neterion developer to focus on the hw-specific changes. There will be nothing wrong if they trade places, but the first scenario seems more likely. So, for a hacker it's harder to understand HAL part of the code - but then he is not doing the bulk of the maintenance of the ASIC -specific code that he's arguably least interested in maintaining... Leonid From dada1@cosmosbay.com Tue Mar 15 08:13:15 2005 Received: with ECARTIS (v1.0.0; list netdev); Tue, 15 Mar 2005 08:13:22 -0800 (PST) Received: from gw1.cosmosbay.com (gw1.cosmosbay.com [62.23.185.226]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j2FGDE8K006325 for ; Tue, 15 Mar 2005 08:13:14 -0800 Received: from [172.16.0.131] (edumazet-port [172.16.0.131]) by gw1.cosmosbay.com (8.13.3/8.13.3) with ESMTP id j2FGD5Rd006100; Tue, 15 Mar 2005 17:13:06 +0100 Message-ID: <42370997.6010302@cosmosbay.com> Date: Tue, 15 Mar 2005 17:13:11 +0100 From: Eric Dumazet User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.3) Gecko/20040910 X-Accept-Language: fr, en-us, en MIME-Version: 1.0 To: "David S. Miller" , netdev@oss.sgi.com Subject: [PATCH] no more rwlock_t inside tcp_ehash_bucket Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-1.6 (gw1.cosmosbay.com [172.16.8.80]); Tue, 15 Mar 2005 17:13:06 +0100 (CET) X-Virus-Scanned: ClamAV 0.83/762/Sun Mar 13 15:35:33 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 174 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: dada1@cosmosbay.com Precedence: bulk X-list: netdev Content-Length: 13329 Lines: 341 A machine with large tcp_ehash uses half the size of the hash to store rwlocks. That seems not really necessary : - Most accesses to tcp_ehash[] are done with read_locks(), so dirtying the memory (because of embedded rwlocks) all over the hash table is not SMP friendly. The cache hit given by the fact that the rwlock and chain were in the same cache line is not really a gain, because of the dirtying of the cache line (and exclusive use because of lock operations) I suggest in this patch using an array of 256 rwlocks. - Less memory used (or 2 x more entries in hash table if size >= (2^MAX_ORDER)*PAGE_SIZE) - less memory touched during read_lock()/read_unlock() - Better sharing of hash entries between cpus tests done on a production machine (1 million slots, size 8MB). No differences found in performance (oprofile). 5 files changed : - net/ipv4/tcp_diag.c - net/ipv4/tcp_minisocks.c - net/ipv4/tcp_ipv4.c - net/ipv4/tcp.c - include/net/tcp.h - include/net/sock.h (i converted also __tcp_bhash_size , __tcp_ehash_size , sk_hashent to 'unsigned int' to let compiler chose a better code) Eric Dumazet # diff -Nru linux-2.6.11 linux-2.6.11-ed diff -Nru linux-2.6.11/include/net/sock.h linux-2.6.11-ed/include/net/sock.h --- linux-2.6.11/include/net/sock.h 2005-03-02 08:38:17.000000000 +0100 +++ linux-2.6.11-ed/include/net/sock.h 2005-03-15 17:02:52.000000000 +0100 @@ -217,7 +217,7 @@ unsigned char sk_no_largesend; int sk_route_caps; unsigned long sk_lingertime; - int sk_hashent; + unsigned int sk_hashent; /* * The backlog queue is special, it is always used with * the per-socket spinlock held and requires low latency diff -Nru linux-2.6.11/include/net/tcp.h linux-2.6.11-ed/include/net/tcp.h --- linux-2.6.11/include/net/tcp.h 2005-03-02 08:37:48.000000000 +0100 +++ linux-2.6.11-ed/include/net/tcp.h 2005-03-15 15:06:31.000000000 +0100 @@ -44,9 +44,14 @@ * for the rest. I'll experiment with dynamic table growth later. */ struct tcp_ehash_bucket { - rwlock_t lock; struct hlist_head chain; -} __attribute__((__aligned__(8))); +} ; + +/* + * instead of using one rwlock_t for each ehash_bucket, use a table of 256 rwlock_t + */ +#define TCP_EHASH_RWLOCK_SZ 256 +extern rwlock_t tcp_ehash_lock[TCP_EHASH_RWLOCK_SZ] ; /* This is for listening sockets, thus all sockets which possess wildcards. */ #define TCP_LHTABLE_SIZE 32 /* Yes, really, this is all you need. */ @@ -106,6 +111,7 @@ return hlist_empty(&head->chain) ? NULL : __tb_head(head); } + extern struct tcp_hashinfo { /* This is for sockets with full identity only. Sockets here will * always be without wildcards and will have the following invariant: @@ -122,8 +128,9 @@ */ struct tcp_bind_hashbucket *__tcp_bhash; - int __tcp_bhash_size; - int __tcp_ehash_size; + unsigned int __tcp_bhash_size; + unsigned int __tcp_ehash_size; + /* All sockets in TCP_LISTEN state will be in here. This is the only * table where wildcard'd TCP sockets can exist. Hash function here diff -Nru linux-2.6.11/net/ipv4/tcp.c linux-2.6.11-ed/net/ipv4/tcp.c --- linux-2.6.11/net/ipv4/tcp.c 2005-03-15 14:50:53.000000000 +0100 +++ linux-2.6.11-ed/net/ipv4/tcp.c 2005-03-15 15:08:28.000000000 +0100 @@ -2309,10 +2309,10 @@ 0); tcp_ehash_size = (1 << tcp_ehash_size) >> 1; for (i = 0; i < (tcp_ehash_size << 1); i++) { - rwlock_init(&tcp_ehash[i].lock); INIT_HLIST_HEAD(&tcp_ehash[i].chain); } - + for (i = 0; i < TCP_EHASH_RWLOCK_SZ; i++) + rwlock_init(&tcp_ehash_lock[i]); tcp_bhash = (struct tcp_bind_hashbucket *) alloc_large_system_hash("TCP bind", sizeof(struct tcp_bind_hashbucket), diff -Nru linux-2.6.11/net/ipv4/tcp_diag.c linux-2.6.11-ed/net/ipv4/tcp_diag.c --- linux-2.6.11/net/ipv4/tcp_diag.c 2005-03-02 08:37:31.000000000 +0100 +++ linux-2.6.11-ed/net/ipv4/tcp_diag.c 2005-03-15 15:22:30.000000000 +0100 @@ -666,7 +666,7 @@ if (i > s_i) s_num = 0; - read_lock_bh(&head->lock); + read_lock_bh(&tcp_ehash_lock[i%TCP_EHASH_RWLOCK_SZ]); num = 0; sk_for_each(sk, node, &head->chain) { @@ -682,7 +682,7 @@ if (r->id.tcpdiag_dport != inet->dport && r->id.tcpdiag_dport) goto next_normal; if (tcpdiag_dump_sock(skb, sk, cb) < 0) { - read_unlock_bh(&head->lock); + read_unlock_bh(&tcp_ehash_lock[i%TCP_EHASH_RWLOCK_SZ]); goto done; } next_normal: @@ -703,14 +703,14 @@ r->id.tcpdiag_dport) goto next_dying; if (tcpdiag_dump_sock(skb, sk, cb) < 0) { - read_unlock_bh(&head->lock); + read_unlock_bh(&tcp_ehash_lock[i%TCP_EHASH_RWLOCK_SZ]); goto done; } next_dying: ++num; } } - read_unlock_bh(&head->lock); + read_unlock_bh(&tcp_ehash_lock[i%TCP_EHASH_RWLOCK_SZ]); } done: diff -Nru linux-2.6.11/net/ipv4/tcp_ipv4.c linux-2.6.11-ed/net/ipv4/tcp_ipv4.c --- linux-2.6.11/net/ipv4/tcp_ipv4.c 2005-03-02 08:37:54.000000000 +0100 +++ linux-2.6.11-ed/net/ipv4/tcp_ipv4.c 2005-03-15 17:02:52.000000000 +0100 @@ -96,6 +96,8 @@ .__tcp_portalloc_lock = SPIN_LOCK_UNLOCKED }; +rwlock_t tcp_ehash_lock[TCP_EHASH_RWLOCK_SZ] ; + /* * This array holds the first and last local port number. * For high-usage systems, use sysctl to change this to @@ -104,16 +106,16 @@ int sysctl_local_port_range[2] = { 1024, 4999 }; int tcp_port_rover = 1024 - 1; -static __inline__ int tcp_hashfn(__u32 laddr, __u16 lport, +static __inline__ unsigned int tcp_hashfn(__u32 laddr, __u16 lport, __u32 faddr, __u16 fport) { - int h = (laddr ^ lport) ^ (faddr ^ fport); + unsigned int h = (laddr ^ lport) ^ (faddr ^ fport); h ^= h >> 16; h ^= h >> 8; return h & (tcp_ehash_size - 1); } -static __inline__ int tcp_sk_hashfn(struct sock *sk) +static __inline__ unsigned int tcp_sk_hashfn(struct sock *sk) { struct inet_sock *inet = inet_sk(sk); __u32 laddr = inet->rcv_saddr; @@ -360,7 +362,7 @@ tcp_listen_wlock(); } else { list = &tcp_ehash[(sk->sk_hashent = tcp_sk_hashfn(sk))].chain; - lock = &tcp_ehash[sk->sk_hashent].lock; + lock = &tcp_ehash_lock[sk->sk_hashent%TCP_EHASH_RWLOCK_SZ]; write_lock(lock); } __sk_add_node(sk, list); @@ -391,9 +393,8 @@ tcp_listen_wlock(); lock = &tcp_lhash_lock; } else { - struct tcp_ehash_bucket *head = &tcp_ehash[sk->sk_hashent]; - lock = &head->lock; - write_lock_bh(&head->lock); + lock = &tcp_ehash_lock[sk->sk_hashent%TCP_EHASH_RWLOCK_SZ]; + write_lock_bh(lock); } if (__sk_del_node_init(sk)) @@ -492,9 +493,9 @@ /* Optimize here for direct hit, only listening connections can * have wildcards anyways. */ - int hash = tcp_hashfn(daddr, hnum, saddr, sport); + unsigned int hash = tcp_hashfn(daddr, hnum, saddr, sport); head = &tcp_ehash[hash]; - read_lock(&head->lock); + read_lock(&tcp_ehash_lock[hash%TCP_EHASH_RWLOCK_SZ]); sk_for_each(sk, node, &head->chain) { if (TCP_IPV4_MATCH(sk, acookie, saddr, daddr, ports, dif)) goto hit; /* You sunk my battleship! */ @@ -507,7 +508,7 @@ } sk = NULL; out: - read_unlock(&head->lock); + read_unlock(&tcp_ehash_lock[hash%TCP_EHASH_RWLOCK_SZ]); return sk; hit: sock_hold(sk); @@ -555,13 +556,13 @@ int dif = sk->sk_bound_dev_if; TCP_V4_ADDR_COOKIE(acookie, saddr, daddr) __u32 ports = TCP_COMBINED_PORTS(inet->dport, lport); - int hash = tcp_hashfn(daddr, lport, saddr, inet->dport); + unsigned int hash = tcp_hashfn(daddr, lport, saddr, inet->dport); struct tcp_ehash_bucket *head = &tcp_ehash[hash]; struct sock *sk2; struct hlist_node *node; struct tcp_tw_bucket *tw; - write_lock(&head->lock); + write_lock(&tcp_ehash_lock[hash%TCP_EHASH_RWLOCK_SZ]); /* Check TIME-WAIT sockets first. */ sk_for_each(sk2, node, &(head + tcp_ehash_size)->chain) { @@ -616,7 +617,7 @@ BUG_TRAP(sk_unhashed(sk)); __sk_add_node(sk, &head->chain); sock_prot_inc_use(sk->sk_prot); - write_unlock(&head->lock); + write_unlock(&tcp_ehash_lock[hash%TCP_EHASH_RWLOCK_SZ]); if (twp) { *twp = tw; @@ -632,7 +633,7 @@ return 0; not_unique: - write_unlock(&head->lock); + write_unlock(&tcp_ehash_lock[hash%TCP_EHASH_RWLOCK_SZ]); return -EADDRNOTAVAIL; } @@ -2224,7 +2225,7 @@ /* We can reschedule _before_ having picked the target: */ cond_resched_softirq(); - read_lock(&tcp_ehash[st->bucket].lock); + read_lock(&tcp_ehash_lock[st->bucket%TCP_EHASH_RWLOCK_SZ]); sk_for_each(sk, node, &tcp_ehash[st->bucket].chain) { if (sk->sk_family != st->family) { continue; @@ -2241,7 +2242,7 @@ rc = tw; goto out; } - read_unlock(&tcp_ehash[st->bucket].lock); + read_unlock(&tcp_ehash_lock[st->bucket%TCP_EHASH_RWLOCK_SZ]); st->state = TCP_SEQ_STATE_ESTABLISHED; } out: @@ -2268,14 +2269,14 @@ cur = tw; goto out; } - read_unlock(&tcp_ehash[st->bucket].lock); + read_unlock(&tcp_ehash_lock[st->bucket%TCP_EHASH_RWLOCK_SZ]); st->state = TCP_SEQ_STATE_ESTABLISHED; /* We can reschedule between buckets: */ cond_resched_softirq(); if (++st->bucket < tcp_ehash_size) { - read_lock(&tcp_ehash[st->bucket].lock); + read_lock(&tcp_ehash_lock[st->bucket%TCP_EHASH_RWLOCK_SZ]); sk = sk_head(&tcp_ehash[st->bucket].chain); } else { cur = NULL; @@ -2385,7 +2386,7 @@ case TCP_SEQ_STATE_TIME_WAIT: case TCP_SEQ_STATE_ESTABLISHED: if (v) - read_unlock(&tcp_ehash[st->bucket].lock); + read_unlock(&tcp_ehash_lock[st->bucket%TCP_EHASH_RWLOCK_SZ]); local_bh_enable(); break; } diff -Nru linux-2.6.11/net/ipv4/tcp_minisocks.c linux-2.6.11-ed/net/ipv4/tcp_minisocks.c --- linux-2.6.11/net/ipv4/tcp_minisocks.c 2005-03-02 08:38:17.000000000 +0100 +++ linux-2.6.11-ed/net/ipv4/tcp_minisocks.c 2005-03-15 15:21:05.000000000 +0100 @@ -66,14 +66,14 @@ /* Unlink from established hashes. */ ehead = &tcp_ehash[tw->tw_hashent]; - write_lock(&ehead->lock); + write_lock(&tcp_ehash_lock[tw->tw_hashent%TCP_EHASH_RWLOCK_SZ]); if (hlist_unhashed(&tw->tw_node)) { - write_unlock(&ehead->lock); + write_unlock(&tcp_ehash_lock[tw->tw_hashent%TCP_EHASH_RWLOCK_SZ]); return; } __hlist_del(&tw->tw_node); sk_node_init(&tw->tw_node); - write_unlock(&ehead->lock); + write_unlock(&tcp_ehash_lock[tw->tw_hashent%TCP_EHASH_RWLOCK_SZ]); /* Disassociate with bind bucket. */ bhead = &tcp_bhash[tcp_bhashfn(tw->tw_num)]; @@ -297,6 +297,7 @@ static void __tcp_tw_hashdance(struct sock *sk, struct tcp_tw_bucket *tw) { struct tcp_ehash_bucket *ehead = &tcp_ehash[sk->sk_hashent]; + rwlock_t *rwp = &tcp_ehash_lock[sk->sk_hashent%TCP_EHASH_RWLOCK_SZ] ; struct tcp_bind_hashbucket *bhead; /* Step 1: Put TW into bind hash. Original socket stays there too. @@ -310,7 +311,7 @@ tw_add_bind_node(tw, &tw->tw_tb->owners); spin_unlock(&bhead->lock); - write_lock(&ehead->lock); + write_lock(rwp); /* Step 2: Remove SK from established hash. */ if (__sk_del_node_init(sk)) @@ -320,7 +321,7 @@ tw_add_node(tw, &(ehead + tcp_ehash_size)->chain); atomic_inc(&tw->tw_refcnt); - write_unlock(&ehead->lock); + write_unlock(rwp); } /* From bunk@stusta.de Tue Mar 15 09:41:13 2005 Received: with ECARTIS (v1.0.0; list netdev); Tue, 15 Mar 2005 09:41:19 -0800 (PST) Received: from mailout.stusta.mhn.de (emailhub.stusta.mhn.de [141.84.69.5]) by oss.sgi.com (8.13.0/8.13.0) with SMTP id j2FHfC58015628 for ; Tue, 15 Mar 2005 09:41:13 -0800 Received: (qmail 8024 invoked from network); 15 Mar 2005 17:41:07 -0000 Received: from r063144.stusta.swh.mhn.de (10.150.63.144) by mailout.stusta.mhn.de with SMTP; 15 Mar 2005 17:41:07 -0000 Received: by r063144.stusta.swh.mhn.de (Postfix, from userid 1000) id 395F2BB685; Tue, 15 Mar 2005 18:41:06 +0100 (CET) Resent-From: bunk@stusta.de Resent-Date: Tue, 15 Mar 2005 18:41:06 +0100 Resent-Message-ID: <20050315174106.GS3189@stusta.de> Resent-To: netdev@oss.sgi.com Date: Tue, 15 Mar 2005 18:25:08 +0100 From: Adrian Bunk To: Stephen Hemminger Cc: bridge@osdl.org, chas@cmf.nrl.navy.mil, linux-atm-general@lists.sourceforge.net, netdev@oss.sgi.co, linux-kernel@vger.kernel.org Subject: Re: [2.6 patch] fix bridge <-> ATM compile error Message-ID: <20050315172508.GQ3189@stusta.de> References: <20050315121930.GE3189@stusta.de> <20050315091305.3fc07561@dxpl.pdx.osdl.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20050315091305.3fc07561@dxpl.pdx.osdl.net> User-Agent: Mutt/1.5.6+20040907i X-Virus-Scanned: ClamAV 0.83/762/Sun Mar 13 15:35:33 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 175 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: bunk@stusta.de Precedence: bulk X-list: netdev Content-Length: 519 Lines: 18 On Tue, Mar 15, 2005 at 09:13:05AM -0800, Stephen Hemminger wrote: > Given the #ifdef mess, perhaps bridge should have the hooks available > independent of the configuration. The problem is the other way round: The bridge code accesses hooks in the ATM code. cu Adrian -- "Is there not promise of rain?" Ling Tan asked suddenly out of the darkness. There had been need of rain for many days. "Only a promise," Lao Er said. Pearl S. Buck - Dragon Seed From davem@davemloft.net Tue Mar 15 10:21:26 2005 Received: with ECARTIS (v1.0.0; list netdev); Tue, 15 Mar 2005 10:21:33 -0800 (PST) Received: from cheetah.davemloft.net (mail@dsl027-180-174.sfo1.dsl.speakeasy.net [216.27.180.174]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j2FILQjV018401 for ; Tue, 15 Mar 2005 10:21:26 -0800 Received: from localhost ([127.0.0.1] helo=cheetah.davemloft.net ident=davem) by cheetah.davemloft.net with smtp (Exim 3.36 #1 (Debian)) id 1DBGcw-00013B-00; Tue, 15 Mar 2005 10:18:46 -0800 Date: Tue, 15 Mar 2005 10:18:46 -0800 From: "David S. Miller" To: Herbert Xu Cc: kuznet@ms2.inr.ac.ru, yoshfuji@linux-ipv6.org, kaber@trash.net, netdev@oss.sgi.com Subject: Re: [15/*] [INET] Fix IPsec calculation in ip_append_data/ip6_append_data Message-Id: <20050315101846.53027d2f.davem@davemloft.net> In-Reply-To: <20050315091904.GA6256@gondor.apana.org.au> References: <20050214221006.GA18415@gondor.apana.org.au> <20050214221200.GA18465@gondor.apana.org.au> <20050214221433.GB18465@gondor.apana.org.au> <20050214221607.GC18465@gondor.apana.org.au> <20050306213214.7d8a143d.davem@davemloft.net> <20050307103536.GB7137@gondor.apana.org.au> <20050308102741.GA23468@gondor.apana.org.au> <20050314102614.GA9610@gondor.apana.org.au> <20050314105313.GA21001@gondor.apana.org.au> <20050314111002.GA29156@gondor.apana.org.au> <20050315091904.GA6256@gondor.apana.org.au> X-Mailer: Sylpheed version 1.0.1 (GTK+ 1.2.10; sparc-unknown-linux-gnu) X-Face: "_;p5u5aPsO,_Vsx"^v-pEq09'CU4&Dc1$fQExov$62l60cgCc%FnIwD=.UF^a>?5'9Kn[;433QFVV9M..2eN.@4ZWPGbdi<=?[:T>y?SD(R*-3It"Vj:)"dP Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV 0.83/762/Sun Mar 13 15:35:33 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 176 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: davem@davemloft.net Precedence: bulk X-list: netdev Content-Length: 664 Lines: 17 On Tue, 15 Mar 2005 20:19:04 +1100 Herbert Xu wrote: > This patch fixes the IPsec overhead handling in ip_append_data and > ip6_append_data. As it is they assume that the IPsec overhead is > constant. This is not true as with ESP the IPsec overhead will vary > as the MTU varies. > > The result is that they may produce packets that will exceed the MTU > when ESP is used. Had it taken the trailer_len into account, it would > have produced packets less than the real MTU. > > By switching to dst_mtu we get the optimal result. > > Signed-off-by: Herbert Xu Looks nice. Applied, thanks Herbert. From davem@davemloft.net Tue Mar 15 10:22:49 2005 Received: with ECARTIS (v1.0.0; list netdev); Tue, 15 Mar 2005 10:22:53 -0800 (PST) Received: from cheetah.davemloft.net (mail@dsl027-180-174.sfo1.dsl.speakeasy.net [216.27.180.174]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j2FIMnsg018709 for ; Tue, 15 Mar 2005 10:22:49 -0800 Received: from localhost ([127.0.0.1] helo=cheetah.davemloft.net ident=davem) by cheetah.davemloft.net with smtp (Exim 3.36 #1 (Debian)) id 1DBGeu-00013V-00; Tue, 15 Mar 2005 10:20:48 -0800 Date: Tue, 15 Mar 2005 10:20:48 -0800 From: "David S. Miller" To: Herbert Xu Cc: kuznet@ms2.inr.ac.ru, yoshfuji@linux-ipv6.org, kaber@trash.net, netdev@oss.sgi.com Subject: Re: [16/*] [INET] Take IPsec overhead into account in tunnels Message-Id: <20050315102048.18261722.davem@davemloft.net> In-Reply-To: <20050315095837.GA7130@gondor.apana.org.au> References: <20050214221200.GA18465@gondor.apana.org.au> <20050214221433.GB18465@gondor.apana.org.au> <20050214221607.GC18465@gondor.apana.org.au> <20050306213214.7d8a143d.davem@davemloft.net> <20050307103536.GB7137@gondor.apana.org.au> <20050308102741.GA23468@gondor.apana.org.au> <20050314102614.GA9610@gondor.apana.org.au> <20050314105313.GA21001@gondor.apana.org.au> <20050314111002.GA29156@gondor.apana.org.au> <20050315091904.GA6256@gondor.apana.org.au> <20050315095837.GA7130@gondor.apana.org.au> X-Mailer: Sylpheed version 1.0.1 (GTK+ 1.2.10; sparc-unknown-linux-gnu) X-Face: "_;p5u5aPsO,_Vsx"^v-pEq09'CU4&Dc1$fQExov$62l60cgCc%FnIwD=.UF^a>?5'9Kn[;433QFVV9M..2eN.@4ZWPGbdi<=?[:T>y?SD(R*-3It"Vj:)"dP Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV 0.83/762/Sun Mar 13 15:35:33 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 177 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: davem@davemloft.net Precedence: bulk X-list: netdev Content-Length: 1018 Lines: 25 On Tue, 15 Mar 2005 20:58:37 +1100 Herbert Xu wrote: > This patch uses dst_mtu instead of dst_pmtu in the various tunnel > implementations. As it is they simply ignore the IPsec overhead. > This leads to bogus MTU values inside the tunnels. > > Signed-off-by: Herbert Xu Applied, thanks Herbert. > BTW, we're doing lazy MTU updates in the tunnel xmit functions. > When a packet with DF set hits us and exceeds the updated MTU, > we will send an ICMP packet back which is good. > > Unfortunately when a packet with DF clear hits us as we update > the MTU downwards, the packet will be silently discarded instead > of fragmented (well we will send an ICMP back to ourselves but > we already knew that MTU value :). > > I presume we want to fix this, right? I think so, although it could be argued that in the end it really doesn't matter. The final argument though is that quality of implementation says we shouldn't drop the frame for such a reason. From yoshfuji@linux-ipv6.org Tue Mar 15 10:23:56 2005 Received: with ECARTIS (v1.0.0; list netdev); Tue, 15 Mar 2005 10:24:02 -0800 (PST) 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 j2FINtdq019325 for ; Tue, 15 Mar 2005 10:23:55 -0800 Received: from localhost (localhost [127.0.0.1]) by yue.st-paulia.net (Postfix) with ESMTP id CA6B633CC2; Wed, 16 Mar 2005 03:25:38 +0900 (JST) Date: Wed, 16 Mar 2005 03:25:37 +0900 (JST) Message-Id: <20050316.032537.72822422.yoshfuji@linux-ipv6.org> To: davem@davemloft.net, herbert@gondor.apana.org.au Cc: kuznet@ms2.inr.ac.ru, kaber@trash.net, netdev@oss.sgi.com, yoshfuji@linux-ipv6.org Subject: Re: [12/*] [IPSEC] Handle local_df in IPv4 From: YOSHIFUJI Hideaki / =?iso-2022-jp?B?GyRCNUhGIzFRTEAbKEI=?= In-Reply-To: <20050314212557.23f0ab09.davem@davemloft.net> References: <20050308102741.GA23468@gondor.apana.org.au> <20050314102614.GA9610@gondor.apana.org.au> <20050314212557.23f0ab09.davem@davemloft.net> Organization: USAGI Project X-URL: http://www.yoshifuji.org/%7Ehideaki/ X-Fingerprint: 9022 65EB 1ECF 3AD1 0BDF 80D8 4807 F894 E062 0EEA X-PGP-Key-URL: http://www.yoshifuji.org/%7Ehideaki/hideaki@yoshifuji.org.asc X-Face: "5$Al-.M>NJ%a'@hhZdQm:."qn~PA^gq4o*>iCFToq*bAi#4FRtx}enhuQKz7fNqQz\BYU] $~O_5m-9'}MIs`XGwIEscw;e5b>n"B_?j/AkL~i/MEaZBLP X-Mailer: Mew version 2.2 on Emacs 20.7 / Mule 4.1 (AOI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV 0.83/762/Sun Mar 13 15:35:33 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 178 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: yoshfuji@linux-ipv6.org Precedence: bulk X-list: netdev Content-Length: 507 Lines: 13 In article <20050314212557.23f0ab09.davem@davemloft.net> (at Mon, 14 Mar 2005 21:25:57 -0800), "David S. Miller" says: > > I was going to do the same thing to IPv6. Unfortunately it seems > > that we don't have any local_df support over there. That is, we > > always fragment outbound UDP/raw packets. Did I miss something? > > I have no idea offhand. Perhaps Yoshifuji can figure it out? Currently, yes. And, I know this is one of places we may need to revisit... --yoshfuji From yoshfuji@linux-ipv6.org Tue Mar 15 10:26:36 2005 Received: with ECARTIS (v1.0.0; list netdev); Tue, 15 Mar 2005 10:26:42 -0800 (PST) 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 j2FIQaHY020114 for ; Tue, 15 Mar 2005 10:26:36 -0800 Received: from localhost (localhost [127.0.0.1]) by yue.st-paulia.net (Postfix) with ESMTP id D940733CC2; Wed, 16 Mar 2005 03:28:21 +0900 (JST) Date: Wed, 16 Mar 2005 03:28:20 +0900 (JST) Message-Id: <20050316.032820.59615306.yoshfuji@linux-ipv6.org> To: davem@davemloft.net, herbert@gondor.apana.org.au Cc: kuznet@ms2.inr.ac.ru, kaber@trash.net, netdev@oss.sgi.com, yoshfuji@linux-ipv6.org Subject: Re: [12/*] [IPSEC] Handle local_df in IPv4 From: YOSHIFUJI Hideaki / =?iso-2022-jp?B?GyRCNUhGIzFRTEAbKEI=?= In-Reply-To: <20050316.032537.72822422.yoshfuji@linux-ipv6.org> References: <20050314102614.GA9610@gondor.apana.org.au> <20050314212557.23f0ab09.davem@davemloft.net> <20050316.032537.72822422.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-Virus-Scanned: ClamAV 0.83/762/Sun Mar 13 15:35:33 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 179 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: yoshfuji@linux-ipv6.org Precedence: bulk X-list: netdev Content-Length: 473 Lines: 11 In article <20050316.032537.72822422.yoshfuji@linux-ipv6.org> (at Wed, 16 Mar 2005 03:25:37 +0900 (JST)), YOSHIFUJI Hideaki / $B5HF#1QL@(B says: > > > that we don't have any local_df support over there. That is, we > > > always fragment outbound UDP/raw packets. Did I miss something? > > > > I have no idea offhand. Perhaps Yoshifuji can figure it out? > > Currently, yes. I mean: we always fragment outbount UDP/raw packets. --yoshfuji From davem@davemloft.net Tue Mar 15 10:27:02 2005 Received: with ECARTIS (v1.0.0; list netdev); Tue, 15 Mar 2005 10:27:08 -0800 (PST) Received: from cheetah.davemloft.net (mail@dsl027-180-174.sfo1.dsl.speakeasy.net [216.27.180.174]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j2FIR1Dv020127 for ; Tue, 15 Mar 2005 10:27:02 -0800 Received: from localhost ([127.0.0.1] helo=cheetah.davemloft.net ident=davem) by cheetah.davemloft.net with smtp (Exim 3.36 #1 (Debian)) id 1DBGio-000154-00; Tue, 15 Mar 2005 10:24:50 -0800 Date: Tue, 15 Mar 2005 10:24:50 -0800 From: "David S. Miller" To: Herbert Xu Cc: kuznet@ms2.inr.ac.ru, yoshfuji@linux-ipv6.org, kaber@trash.net, netdev@oss.sgi.com Subject: Re: [17/*] [NET] Replace dst_pmtu with dst_mtu Message-Id: <20050315102450.0f3f1618.davem@davemloft.net> In-Reply-To: <20050315100522.GA7275@gondor.apana.org.au> References: <20050214221433.GB18465@gondor.apana.org.au> <20050214221607.GC18465@gondor.apana.org.au> <20050306213214.7d8a143d.davem@davemloft.net> <20050307103536.GB7137@gondor.apana.org.au> <20050308102741.GA23468@gondor.apana.org.au> <20050314102614.GA9610@gondor.apana.org.au> <20050314105313.GA21001@gondor.apana.org.au> <20050314111002.GA29156@gondor.apana.org.au> <20050315091904.GA6256@gondor.apana.org.au> <20050315095837.GA7130@gondor.apana.org.au> <20050315100522.GA7275@gondor.apana.org.au> X-Mailer: Sylpheed version 1.0.1 (GTK+ 1.2.10; sparc-unknown-linux-gnu) X-Face: "_;p5u5aPsO,_Vsx"^v-pEq09'CU4&Dc1$fQExov$62l60cgCc%FnIwD=.UF^a>?5'9Kn[;433QFVV9M..2eN.@4ZWPGbdi<=?[:T>y?SD(R*-3It"Vj:)"dP Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV 0.83/762/Sun Mar 13 15:35:33 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 180 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: davem@davemloft.net Precedence: bulk X-list: netdev Content-Length: 1269 Lines: 31 On Tue, 15 Mar 2005 21:05:22 +1100 Herbert Xu wrote: > This patch replaces most of the other uses of dst_pmtu with dst_mtu. > As far as I can tell these are either identical because dst->path == dst, > or they're a straightforward replacement of (the slightly incorrect) > dst_pmtu(dst) - dst->header_Len with dst_mtu(dst). > > Signed-off-by: Herbert Xu Applied, thanks Herbert. > At this point the only remaining user of dst_pmtu is ipt_REJECT which > will go away either when we use icmp_send in there or when I replace > it with dst_mtu. Yes, I saw that posting on netfilter-devel where you asked Rusty why icmp_send() wasn't directly used even though it appears it should be. > We can now remove the other users of dst->path as well with the removal > of that attribute itself as the goal. Ok, sounds great. So, at that point, I guess the next task is to handle PMTU events of already encrypted packets properly? We still have that problem right? When the ICMP payload is encrypted we have to cache some information on IPSEC output so that a proto+SPI key can find us the encrypted inner IP header info, which we'll need in order to process (and/or forward) the ICMP PMTU information correctly. From davem@davemloft.net Tue Mar 15 10:27:28 2005 Received: with ECARTIS (v1.0.0; list netdev); Tue, 15 Mar 2005 10:27:36 -0800 (PST) Received: from cheetah.davemloft.net (mail@dsl027-180-174.sfo1.dsl.speakeasy.net [216.27.180.174]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j2FIRSke020448 for ; Tue, 15 Mar 2005 10:27:28 -0800 Received: from localhost ([127.0.0.1] helo=cheetah.davemloft.net ident=davem) by cheetah.davemloft.net with smtp (Exim 3.36 #1 (Debian)) id 1DBGjg-00015R-00; Tue, 15 Mar 2005 10:25:44 -0800 Date: Tue, 15 Mar 2005 10:25:43 -0800 From: "David S. Miller" To: Thomas Graf Cc: yoshfuji@linux-ipv6.org, mroos@linux.ee, netdev@oss.sgi.com Subject: Re: ipv6 unresolved symbol Message-Id: <20050315102543.6f59dd15.davem@davemloft.net> In-Reply-To: <20050315134002.GE3086@postel.suug.ch> References: <20050315.185815.12690947.yoshfuji@linux-ipv6.org> <20050315134002.GE3086@postel.suug.ch> X-Mailer: Sylpheed version 1.0.1 (GTK+ 1.2.10; sparc-unknown-linux-gnu) X-Face: "_;p5u5aPsO,_Vsx"^v-pEq09'CU4&Dc1$fQExov$62l60cgCc%FnIwD=.UF^a>?5'9Kn[;433QFVV9M..2eN.@4ZWPGbdi<=?[:T>y?SD(R*-3It"Vj:)"dP Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV 0.83/762/Sun Mar 13 15:35:33 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 181 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: davem@davemloft.net Precedence: bulk X-list: netdev Content-Length: 681 Lines: 16 On Tue, 15 Mar 2005 14:40:02 +0100 Thomas Graf wrote: > * YOSHIFUJI Hideaki / ?$B5HF#1QL@ <20050315.185815.12690947.yoshfuji@linux-ipv6.org> 2005-03-15 18:58 > > In article (at Tue, 15 Mar 2005 11:36:42 +0200 (EET)), Meelis Roos says: > > > > > This is todays 2.6.11+BK on x86 with modular ipv6: > > > > > > WARNING: /lib/modules/2.6.11/kernel/net/ipv6/ipv6.ko needs unknown symbol dev_get_flags > > > > Oops, thanks. > > Stupid me, should have checked that, thanks for the fix. No worries. Andrew Morton sent me this fix a few hours ago so it's already in my tree and about to be sent to Linus. From akepner@sgi.com Tue Mar 15 10:29:54 2005 Received: with ECARTIS (v1.0.0; list netdev); Tue, 15 Mar 2005 10:30:00 -0800 (PST) Received: from omx1.americas.sgi.com (omx1-ext.sgi.com [192.48.179.11]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j2FITsUQ021763 for ; Tue, 15 Mar 2005 10:29:54 -0800 Received: from nodin.corp.sgi.com (nodin.corp.sgi.com [192.26.51.193]) by omx1.americas.sgi.com (8.12.10/8.12.9/linux-outbound_gateway-1.1) with ESMTP id j2FITrxT018397 for ; Tue, 15 Mar 2005 12:29:53 -0600 Received: from cthulhu.engr.sgi.com (cthulhu.engr.sgi.com [192.26.80.2]) by nodin.corp.sgi.com (SGI-8.12.5/8.12.10/SGI_generic_relay-1.2) with ESMTP id j2FITrbT47169142 for ; Tue, 15 Mar 2005 10:29:53 -0800 (PST) Received: from [192.168.2.20] (mtv-vpn-sw-corp-0-85.corp.sgi.com [134.15.0.85]) by cthulhu.engr.sgi.com (SGI-8.12.5/8.12.5) with ESMTP id j2FISq7e3177876; Tue, 15 Mar 2005 10:28:52 -0800 (PST) Date: Tue, 15 Mar 2005 10:29:16 -0800 (PST) From: Arthur Kepner X-X-Sender: akepner@linux.site To: "David S. Miller" cc: netdev@oss.sgi.com Subject: [PATCH] use NETIF_F_LLTX in bonding device Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Virus-Scanned: ClamAV 0.83/762/Sun Mar 13 15:35:33 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 182 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: akepner@sgi.com Precedence: bulk X-list: netdev Content-Length: 803 Lines: 24 Lock contention on the bonding device's xmit_lock can become a bottleneck when 3 or more gige links are aggregated. And it looks like it's unnecessary too, so use the NETIF_F_LLTX flag to avoid grabbing this lock. Signed-off-by: --- linux.orig/drivers/net/bonding/bond_main.c 2005-03-14 14:08:29.000000000 -0800 +++ linux/drivers/net/bonding/bond_main.c 2005-03-14 17:08:57.000000000 -0800 @@ -4306,6 +4306,10 @@ static int __init bond_init(struct net_d */ bond_dev->features |= NETIF_F_VLAN_CHALLENGED; + /* don't acquire bond device's xmit_lock when + * transmitting */ + bond_dev->features |= NETIF_F_LLTX; + /* By default, we declare the bond to be fully * VLAN hardware accelerated capable. Special * care is taken in the various xmit functions -- Arthur From davem@davemloft.net Tue Mar 15 10:31:39 2005 Received: with ECARTIS (v1.0.0; list netdev); Tue, 15 Mar 2005 10:31:45 -0800 (PST) Received: from cheetah.davemloft.net (mail@dsl027-180-174.sfo1.dsl.speakeasy.net [216.27.180.174]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j2FIVduZ022333 for ; Tue, 15 Mar 2005 10:31:39 -0800 Received: from localhost ([127.0.0.1] helo=cheetah.davemloft.net ident=davem) by cheetah.davemloft.net with smtp (Exim 3.36 #1 (Debian)) id 1DBGkm-00016N-00; Tue, 15 Mar 2005 10:26:52 -0800 Date: Tue, 15 Mar 2005 10:26:52 -0800 From: "David S. Miller" To: Adrian Bunk Cc: netdev@oss.sgi.com, linux-kernel@vger.kernel.org Subject: Re: [2.6 patch] net/802/fc.c: remove fc_type_trans Message-Id: <20050315102652.2d122c2f.davem@davemloft.net> In-Reply-To: <20050315122017.GF3189@stusta.de> References: <20050306205754.GO5070@stusta.de> <20050314214940.4947ccd9.davem@davemloft.net> <20050315122017.GF3189@stusta.de> X-Mailer: Sylpheed version 1.0.1 (GTK+ 1.2.10; sparc-unknown-linux-gnu) X-Face: "_;p5u5aPsO,_Vsx"^v-pEq09'CU4&Dc1$fQExov$62l60cgCc%FnIwD=.UF^a>?5'9Kn[;433QFVV9M..2eN.@4ZWPGbdi<=?[:T>y?SD(R*-3It"Vj:)"dP Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV 0.83/762/Sun Mar 13 15:35:33 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 183 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: davem@davemloft.net Precedence: bulk X-list: netdev Content-Length: 570 Lines: 19 On Tue, 15 Mar 2005 13:20:17 +0100 Adrian Bunk wrote: > On Mon, Mar 14, 2005 at 09:49:40PM -0800, David S. Miller wrote: > > On Sun, 6 Mar 2005 21:57:54 +0100 > > Adrian Bunk wrote: > > > > > The only user of fc_type_trans (drivers/net/fc/iph5526.c) is BROKEN in > > > 2.6 and removed in -mm. > > > > > > Signed-off-by: Adrian Bunk > > > > That driver isn't in Linus's tree any longer either. Just delete > > the thing altogether instead of #if 0'ing it. > >... > > Updated patch: Applied, thanks a lot Adrian. From davem@davemloft.net Tue Mar 15 10:34:39 2005 Received: with ECARTIS (v1.0.0; list netdev); Tue, 15 Mar 2005 10:34:45 -0800 (PST) Received: from cheetah.davemloft.net (mail@dsl027-180-174.sfo1.dsl.speakeasy.net [216.27.180.174]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j2FIYdBw022909 for ; Tue, 15 Mar 2005 10:34:39 -0800 Received: from localhost ([127.0.0.1] helo=cheetah.davemloft.net ident=davem) by cheetah.davemloft.net with smtp (Exim 3.36 #1 (Debian)) id 1DBGqb-00019G-00; Tue, 15 Mar 2005 10:32:53 -0800 Date: Tue, 15 Mar 2005 10:32:53 -0800 From: "David S. Miller" To: Eric Dumazet Cc: netdev@oss.sgi.com Subject: Re: [PATCH] no more rwlock_t inside tcp_ehash_bucket Message-Id: <20050315103253.590c8bfc.davem@davemloft.net> In-Reply-To: <42370997.6010302@cosmosbay.com> References: <42370997.6010302@cosmosbay.com> X-Mailer: Sylpheed version 1.0.1 (GTK+ 1.2.10; sparc-unknown-linux-gnu) X-Face: "_;p5u5aPsO,_Vsx"^v-pEq09'CU4&Dc1$fQExov$62l60cgCc%FnIwD=.UF^a>?5'9Kn[;433QFVV9M..2eN.@4ZWPGbdi<=?[:T>y?SD(R*-3It"Vj:)"dP Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV 0.83/762/Sun Mar 13 15:35:33 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 184 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: davem@davemloft.net Precedence: bulk X-list: netdev Content-Length: 937 Lines: 23 On Tue, 15 Mar 2005 17:13:11 +0100 Eric Dumazet wrote: > I suggest in this patch using an array of 256 rwlocks. > > - Less memory used (or 2 x more entries in hash table if size >= (2^MAX_ORDER)*PAGE_SIZE) > - less memory touched during read_lock()/read_unlock() > - Better sharing of hash entries between cpus I'm generally in support of this change, however 2 suggestions: 1) Please allocate the rwlock table dynamically. You can put #ifdef CONFIG_SMP around this stuff if you wish so that we don't do silly things like allocate a zero sized table on non-SMP builds. Perhaps you might want to similarly abstract out the rwlock acquisition, "tcp_ehash_lock(unsigned int slot)" and "tcp_ehash_unlock(unsigned int slot)". It's just an idea. 2) With dynamic allocation, you can consider perhaps dynamic sizing based upon a) the ehash size b) NR_CPUS or some combination of those two. From kaber@trash.net Tue Mar 15 11:03:38 2005 Received: with ECARTIS (v1.0.0; list netdev); Tue, 15 Mar 2005 11:03:44 -0800 (PST) Received: from kaber.coreworks.de ([62.206.217.67]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j2FJ3bn5024343 for ; Tue, 15 Mar 2005 11:03:38 -0800 Received: from localhost ([127.0.0.1]) by kaber.coreworks.de with esmtp (Exim 4.50) id 1DBHJD-0001VP-KC; Tue, 15 Mar 2005 20:02:27 +0100 Message-ID: <42373142.6090902@trash.net> Date: Tue, 15 Mar 2005 20:02:26 +0100 From: Patrick McHardy User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.7.5) Gecko/20050106 Debian/1.7.5-1 X-Accept-Language: en MIME-Version: 1.0 To: "David S. Miller" CC: Herbert Xu , kuznet@ms2.inr.ac.ru, yoshfuji@linux-ipv6.org, netdev@oss.sgi.com, Netfilter Development Mailinglist Subject: Re: [17/*] [NET] Replace dst_pmtu with dst_mtu References: <20050214221433.GB18465@gondor.apana.org.au> <20050214221607.GC18465@gondor.apana.org.au> <20050306213214.7d8a143d.davem@davemloft.net> <20050307103536.GB7137@gondor.apana.org.au> <20050308102741.GA23468@gondor.apana.org.au> <20050314102614.GA9610@gondor.apana.org.au> <20050314105313.GA21001@gondor.apana.org.au> <20050314111002.GA29156@gondor.apana.org.au> <20050315091904.GA6256@gondor.apana.org.au> <20050315095837.GA7130@gondor.apana.org.au> <20050315100522.GA7275@gondor.apana.org.au> <20050315102450.0f3f1618.davem@davemloft.net> In-Reply-To: <20050315102450.0f3f1618.davem@davemloft.net> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV 0.83/762/Sun Mar 13 15:35:33 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 185 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: kaber@trash.net Precedence: bulk X-list: netdev Content-Length: 667 Lines: 20 David S. Miller wrote: > On Tue, 15 Mar 2005 21:05:22 +1100 > Herbert Xu wrote: > >>At this point the only remaining user of dst_pmtu is ipt_REJECT which >>will go away either when we use icmp_send in there or when I replace >>it with dst_mtu. > > > Yes, I saw that posting on netfilter-devel where you asked Rusty > why icmp_send() wasn't directly used even though it appears it > should be. I would prefer to keep it seperately. I have planned to remove xrlim from ipt_REJECT so it behaves similar for TCP and ICMP. Limits should then be handled by the limit match. This can't be done if we switch to icmp_send(). Regards Patrick From cliffw@osdl.org Tue Mar 15 11:04:23 2005 Received: with ECARTIS (v1.0.0; list netdev); Tue, 15 Mar 2005 11:04:30 -0800 (PST) Received: from smtp.osdl.org (fire.osdl.org [65.172.181.4]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j2FJ4MTJ024425 for ; Tue, 15 Mar 2005 11:04:23 -0800 Received: from es175 (fw.osdl.org [65.172.181.6]) (authenticated bits=0) by smtp.osdl.org (8.12.8/8.12.8) with ESMTP id j2FJ4Eqi021042 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO); Tue, 15 Mar 2005 11:04:14 -0800 Date: Tue, 15 Mar 2005 11:04:14 -0800 From: cliff white To: Robert Olsson , netdev@oss.sgi.com Subject: Re: Constant errors with pktgen Message-ID: <20050315110414.3310bf96@es175> In-Reply-To: <16951.422.818446.117190@robur.slu.se> References: <20050314133404.2528647f@es175> <16951.422.818446.117190@robur.slu.se> Organization: OSDL X-Mailer: Sylpheed-Claws 1.0.1 (GTK+ 1.2.10; i386-pc-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-MIMEDefang-Filter: osdl$Revision: 1.105 $ X-Scanned-By: MIMEDefang 2.36 X-Virus-Scanned: ClamAV 0.83/762/Sun Mar 13 15:35:33 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 186 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: cliffw@osdl.org Precedence: bulk X-list: netdev Content-Length: 2273 Lines: 86 On Tue, 15 Mar 2005 16:39:18 +0100 Robert Olsson wrote: > > cliff white writes: > > > My test rig is two machines with an e100 card, connected by crossover > > cable. > > > > When i run pktgen, the error counter == packet count, always. > > I see. Try the patch patch below it cleans up the code a bit and > restores the old meaning of error. It also has the minor fix from > Adrian Bunk > Works for me Current: pkts-sofar: 7400227 errors: 0 ( now i have to force some errors... ) cliffw > --ro > > --- net/core/pktgen.c.050315 2005-03-11 10:48:43.000000000 +0100 > +++ net/core/pktgen.c 2005-03-15 16:16:01.000000000 +0100 > @@ -151,7 +151,7 @@ > #include > > > -#define VERSION "pktgen v2.60: Packet Generator for packet performance testing.\n" > +#define VERSION "pktgen v2.61: Packet Generator for packet performance testing.\n" > > /* #define PG_DEBUG(a) a */ > #define PG_DEBUG(a) > @@ -2590,7 +2590,7 @@ > thread_unlock(); > } > > -__inline__ void pktgen_xmit(struct pktgen_dev *pkt_dev) > +static __inline__ void pktgen_xmit(struct pktgen_dev *pkt_dev) > { > struct net_device *odev = NULL; > __u64 idle_start = 0; > @@ -2654,7 +2654,6 @@ > > spin_lock_bh(&odev->xmit_lock); > if (!netif_queue_stopped(odev)) { > - u64 now; > > atomic_inc(&(pkt_dev->skb->users)); > retry_now: > @@ -2678,24 +2677,18 @@ > > pkt_dev->errors++; > pkt_dev->last_ok = 0; > - pkt_dev->next_tx_us = getCurUs(); /* TODO */ > - pkt_dev->next_tx_ns = 0; > } > > + pkt_dev->next_tx_us = getCurUs(); > + pkt_dev->next_tx_ns = 0; > + > pkt_dev->next_tx_us += pkt_dev->delay_us; > pkt_dev->next_tx_ns += pkt_dev->delay_ns; > + > if (pkt_dev->next_tx_ns > 1000) { > pkt_dev->next_tx_us++; > pkt_dev->next_tx_ns -= 1000; > } > - > - now = getCurUs(); > - if (now > pkt_dev->next_tx_us) { > - /* TODO: this code is slightly wonky. */ > - pkt_dev->errors++; > - pkt_dev->next_tx_us = now - pkt_dev->delay_us; > - pkt_dev->next_tx_ns = 0; > - } > } > > else { /* Retry it next time */ > -- "Ive always gone through periods where I bolt upright at four in the morning; now at least theres a reason." -Michael Feldman From kaber@trash.net Tue Mar 15 11:05:49 2005 Received: with ECARTIS (v1.0.0; list netdev); Tue, 15 Mar 2005 11:05:54 -0800 (PST) Received: from kaber.coreworks.de ([62.206.217.67]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j2FJ5nZ2025106 for ; Tue, 15 Mar 2005 11:05:49 -0800 Received: from localhost ([127.0.0.1]) by kaber.coreworks.de with esmtp (Exim 4.50) id 1DBHMN-0001Vx-LX; Tue, 15 Mar 2005 20:05:43 +0100 Message-ID: <42373207.9090308@trash.net> Date: Tue, 15 Mar 2005 20:05:43 +0100 From: Patrick McHardy User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.7.5) Gecko/20050106 Debian/1.7.5-1 X-Accept-Language: en MIME-Version: 1.0 To: Herbert Xu CC: netdev@oss.sgi.com Subject: Re: [3/4] [IPSEC] Add route element to xfrm_dst References: <20050214221006.GA18415@gondor.apana.org.au> <20050214221200.GA18465@gondor.apana.org.au> <20050214221433.GB18465@gondor.apana.org.au> <42357AF0.4080205@trash.net> <20050314203208.GA15146@gondor.apana.org.au> In-Reply-To: <20050314203208.GA15146@gondor.apana.org.au> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV 0.83/762/Sun Mar 13 15:35:33 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 187 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: kaber@trash.net Precedence: bulk X-list: netdev Content-Length: 703 Lines: 20 Herbert Xu wrote: > On Mon, Mar 14, 2005 at 12:52:16PM +0100, Patrick McHardy wrote: > >>Since the tunnel dst is not necessarily the last in the bundle anymore, >>we might miss to initialize some dsts, for example with ipcomp/tunnel + >>esp/transport. If we have nested tunnels we'll fiddle with entries in >>the routing cache. > > > Sorry, but I don't get it :) First of all what do you mean by the > tunnel dst? > > If you mean &rt->u.dst then as far as I can see it's still the last > child in the bundle. It may also appear in ->route elements earlier > on but that does not come into play in this loop. You're right, I must have misread the code somehow. Sorry for the noise. Regards Patrick From jchapman@katalix.com Tue Mar 15 11:18:34 2005 Received: with ECARTIS (v1.0.0; list netdev); Tue, 15 Mar 2005 11:18:39 -0800 (PST) Received: from ptb-relay01.plus.net (ptb-relay01.plus.net [212.159.14.212]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j2FJIXcc026644 for ; Tue, 15 Mar 2005 11:18:33 -0800 Received: from [84.92.108.75] (helo=[192.168.1.10]) by ptb-relay01.plus.net with esmtp (Exim) id 1DBHYc-0007t1-ON; Tue, 15 Mar 2005 19:18:22 +0000 Message-ID: <423734FB.40101@katalix.com> Date: Tue, 15 Mar 2005 19:18:19 +0000 From: James Chapman User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.3) Gecko/20040910 X-Accept-Language: en, en-us MIME-Version: 1.0 To: Andy Fleming CC: netdev@oss.sgi.com, "David S. Miller" , linuxppc-embedded@ozlabs.org, Benjamin Herrenschmidt Subject: Re: RFC: PHY Abstraction Layer II References: <1107b64b01fb8e9a6c84359bb56881a6@freescale.com> <1110334456.32556.21.camel@gaston> <20050308194229.41c23707.davem@davemloft.net> <1110340214.32524.32.camel@gaston> <57a429f8eb807987d88b06129861d507@freescale.com> <4230D1AC.5070506@katalix.com> In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV 0.83/762/Sun Mar 13 15:35:33 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 188 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: jchapman@katalix.com Precedence: bulk X-list: netdev Content-Length: 5814 Lines: 142 Hi Andy, I finally found some time to review your phy abstraction code. I haven't reviewed the low level MII functions; I focused mostly on its API to the net driver and whether it has the necessary hooks to handle the various hardware that I know. General comment: nice, clean code. No serious style or Linux kernel core API issues that I can see. Specific comments follow. - It isn't obvious what has to be done in net drivers to hook up this code. Consider writing a Documentation/networking/phy.txt to describe typical net driver code changes needed. - If a net driver is modified to use your new code, should it use any functions from mii.c at all? I guess I'm unclear about the relationship with mii.c. - netif_carrier_on()/off() calls are done by mii.c on link state changes. Consider doing the same inside your phy code. - Some hardware does not use a separate irq for phy but instead indicates phy events via the ethernet chip's irq. There are registered phy_driver callbacks to handle things like read/clear/ack interrupt status. But if my ethernet device's phy interrupt is effectively one or more bits in the ethernet chip's status register (where there is no separate phy interrupt), how would this hook into your phy code? For example, in the interrupt handler of mv643xx_eth, we check status bits that indicate link state change from the same register that indicates rx/tx packet events. Also, NAPI drivers will disable irqs and poll for tx/rx while there is work to do. If they have a combined tx/rx/phy interrupt then does this pose other issues for hooking up the new phy code? - What determines whether the phy driver uses interrupts or polling? - The callback registered in phy_connect() is called when phy link changes are detected. It is passed a struct device*. How about letting the net driver register its struct net_device* which would be passed back in the callback? It is likely that the callback will need access to net driver data anyway. Some net drivers will need to reconfigure their ethernet chip for duplex/speed setting changes, for example. Passing in the struct net_device* also lets the phy code call netif_xxx() functions such as netif_carrier_on()/off() mentioned earlier as well as the netif_msg_xxx message control macros. - The callback function is only called by the phy timer poll as far as I can tell. Shouldn't it also be called in the phy interrupt handler when link state changes? - Have all phy printk messages controlled by the netif_msg_ macros. - Many drivers use mii.c to implement ethtool functions. I don't see equivalents in your new code. - Does include/linux/phy.h represent a public API for use by net drivers or is it also the internal API used by various C files in your phy code? It seems to contain some data/defs that are private to the implementation. Separate some members of struct phy_device into public and private parts and move the private bits into separate files away from include/linux? - phy_sanitize_settings() / phy_force_reduction() I don't understand why this is done. Are you trying to handle link negotiation in software for phy chips that can't autoneg? Other minor notes:- - Rename register_mdiobus() --> mdiobus_register()? - I personally try to avoid listing parameter names in function header comment blocks; they seldom contain useful info and they're a maintenance overhead. If it would be useful for docbook-generated documentation then ok, but your comment blocks don't follow that format anyway. I hope this was useful. /james Andy Fleming wrote: > > On Mar 10, 2005, at 17:01, James Chapman wrote: > >> Hi Andy, >> >> Can you elaborate on why this phy abstraction is needed? >> >> In your original post, you mentioned that you were going to post a >> patch to show how your code would be hooked up in an existing net >> driver. Did I miss it? It would help in understanding the pros and cons >> of using genphy over using plain old mii.c. > > > Hi James, > > I haven't posted it yet, since it's a large patch (it deletes a lot of > code from my driver), but I can give a basic overview of how my driver > hooks into this code: > > 1) The driver connects to the PHY when opened, calling phy_connect, and > then clears some bits to declare functionality it doesn't support (my > driver, for instance, does not support gigabit in half-duplex mode). > > 2) The driver implements a function which reads the speed/duplex > settings, and modifies the controller registers as appropriate (also > bringing the carrier up and down depending on link state). My driver > needs to note whether it's gigabit or not (for GMII vs MII mode), and > the duplex (to set the MAC full or half). > > Both of those steps are very straightforward. The PHY layer will invoke > the callback whenever the link state changes, so the controller will > always be up-to-date. > > 3) The third step is the part that can make things a little messier. My > driver implements a second driver for the MDIO bus, which is connected > through its registers. This bus needs to be registered, and the driver > also needs to register. Then some code needs to be written to deal with > initialization, and takedown. I can send out that patch anytime, if > there's demand. > >> >> btw, I recently posted a patch to add GigE support to mii.c which is >> in Jeff's netdev-2.6 queue. Some register definitions were added in >> mii.h that will collide with yours. > > > Yeah, I ran in to some of those. I can't remember whether they're in > the patch or not, I suspect not. I will have to submit a new patch to > cover those (I just changed my code to use your definitions). > > Andy From colin.whittaker@heanet.ie Tue Mar 15 11:39:02 2005 Received: with ECARTIS (v1.0.0; list netdev); Tue, 15 Mar 2005 11:39:08 -0800 (PST) Received: from byron.heanet.ie (byron.heanet.ie [193.1.219.90]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j2FJd1GW028192 for ; Tue, 15 Mar 2005 11:39:02 -0800 Received: from aine.heanet.ie ([2001:770:18:10:210:18ff:fe06:9bb0] ident=Debian-exim) by byron.heanet.ie with esmtpsa (TLSv1:RC4-SHA:128) (Exim 4.50) id 1DBHsa-0000U9-4i; Tue, 15 Mar 2005 19:39:00 +0000 Received: from colin by aine.heanet.ie with local (Exim 4.34) id 1DBHsZ-0008W3-U0; Tue, 15 Mar 2005 19:38:59 +0000 Date: Tue, 15 Mar 2005 19:38:59 +0000 From: Colin Whittaker To: davem@redhat.com, netdev@oss.sgi.com Subject: MTU bug 2.6.8 Message-ID: <20050315193858.GA32624@aine.heanet.ie> Reply-To: Colin Whittaker Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.5.6+20040907i X-Virus-Scanned: ClamAV 0.83/762/Sun Mar 13 15:35:33 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 189 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: colin.whittaker@heanet.ie Precedence: bulk X-list: netdev Content-Length: 636 Lines: 21 Hi David and the rest of the list. I have hit a problem with MTUs under linux and the behaviour is identical to that described in In this case I have a number of machines with e1000 and tg3 based gige cards and they all exhibit this behaviour. I am running a stock 2.6.8.1 kernel and am more than happy to test any fixes / patches but do not know the code base so finiding it is beyond me. If any more data is need please just ask. regards, Colin -- Colin Whittaker colin.whittaker@heanet.ie Tel: +353 1 6609040 HEAnet NOC noc@heanet.ie iNOC-DBA: 1213*752 From jheffner@psc.edu Tue Mar 15 11:54:39 2005 Received: with ECARTIS (v1.0.0; list netdev); Tue, 15 Mar 2005 11:54:46 -0800 (PST) Received: from mailer2.psc.edu (mailer2.psc.edu [128.182.66.106]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j2FJsc1o029061 for ; Tue, 15 Mar 2005 11:54:39 -0800 Received: from dexter.psc.edu (dexter.psc.edu [128.182.61.232]) by mailer2.psc.edu (8.13.3/8.13.3) with ESMTP id j2FJuTFg018396 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 15 Mar 2005 14:56:29 -0500 (EST) Received: from dexter.psc.edu (localhost.psc.edu [127.0.0.1]) by dexter.psc.edu (8.12.11/8.12.10) with ESMTP id j2FJsO7S007798; Tue, 15 Mar 2005 14:54:24 -0500 Received: from localhost (jheffner@localhost) by dexter.psc.edu (8.12.11/8.12.11/Submit) with ESMTP id j2FJsOwW007795; Tue, 15 Mar 2005 14:54:24 -0500 X-Authentication-Warning: dexter.psc.edu: jheffner owned process doing -bs Date: Tue, 15 Mar 2005 14:54:24 -0500 (EST) From: John Heffner To: Stephen Hemminger cc: "David S. Miller" , baruch@ev-en.org, netdev@oss.sgi.com Subject: Re: [RFC] TCP congestion schedulers In-Reply-To: <20050314151726.532af90d@dxpl.pdx.osdl.net> Message-ID: References: <421CF5E5.1060606@ev-en.org> <20050223135732.39e62c6c.davem@davemloft.net> <421D1E66.5090301@osdl.org> <421D30FA.1060900@ev-en.org> <20050225120814.5fa77b13@dxpl.pdx.osdl.net> <20050309210442.3e9786a6.davem@davemloft.net> <4230288F.1030202@ev-en.org> <20050310182629.1eab09ec.davem@davemloft.net> <20050311120054.4bbf675a@dxpl.pdx.osdl.net> <20050311201011.360c00da.davem@davemloft.net> <20050314151726.532af90d@dxpl.pdx.osdl.net> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Virus-Scanned: ClamAV 0.83/762/Sun Mar 13 15:35:33 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 190 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: jheffner@psc.edu Precedence: bulk X-list: netdev Content-Length: 4820 Lines: 188 Cool. :) Here's High Speed TCP. -John --- /* * Sally Floyd's High Speed TCP (RFC 3649) congestion control * * See http://www.icir.org/floyd/hstcp.html * * John Heffner */ #include #include #include /* From AIMD tables from RFC 3649 appendix B, * with fixed-point MD scaled <<8. */ static struct hstcp_aimd_val { unsigned int cwnd; unsigned int md; } hstcp_aimd_vals[] = { { 38, 128, /* 0.50 */ }, { 118, 112, /* 0.44 */ }, { 221, 104, /* 0.41 */ }, { 347, 98, /* 0.38 */ }, { 495, 93, /* 0.37 */ }, { 663, 89, /* 0.35 */ }, { 851, 86, /* 0.34 */ }, { 1058, 83, /* 0.33 */ }, { 1284, 81, /* 0.32 */ }, { 1529, 78, /* 0.31 */ }, { 1793, 76, /* 0.30 */ }, { 2076, 74, /* 0.29 */ }, { 2378, 72, /* 0.28 */ }, { 2699, 71, /* 0.28 */ }, { 3039, 69, /* 0.27 */ }, { 3399, 68, /* 0.27 */ }, { 3778, 66, /* 0.26 */ }, { 4177, 65, /* 0.26 */ }, { 4596, 64, /* 0.25 */ }, { 5036, 62, /* 0.25 */ }, { 5497, 61, /* 0.24 */ }, { 5979, 60, /* 0.24 */ }, { 6483, 59, /* 0.23 */ }, { 7009, 58, /* 0.23 */ }, { 7558, 57, /* 0.22 */ }, { 8130, 56, /* 0.22 */ }, { 8726, 55, /* 0.22 */ }, { 9346, 54, /* 0.21 */ }, { 9991, 53, /* 0.21 */ }, { 10661, 52, /* 0.21 */ }, { 11358, 52, /* 0.20 */ }, { 12082, 51, /* 0.20 */ }, { 12834, 50, /* 0.20 */ }, { 13614, 49, /* 0.19 */ }, { 14424, 48, /* 0.19 */ }, { 15265, 48, /* 0.19 */ }, { 16137, 47, /* 0.19 */ }, { 17042, 46, /* 0.18 */ }, { 17981, 45, /* 0.18 */ }, { 18955, 45, /* 0.18 */ }, { 19965, 44, /* 0.17 */ }, { 21013, 43, /* 0.17 */ }, { 22101, 43, /* 0.17 */ }, { 23230, 42, /* 0.17 */ }, { 24402, 41, /* 0.16 */ }, { 25618, 41, /* 0.16 */ }, { 26881, 40, /* 0.16 */ }, { 28193, 39, /* 0.16 */ }, { 29557, 39, /* 0.15 */ }, { 30975, 38, /* 0.15 */ }, { 32450, 38, /* 0.15 */ }, { 33986, 37, /* 0.15 */ }, { 35586, 36, /* 0.14 */ }, { 37253, 36, /* 0.14 */ }, { 38992, 35, /* 0.14 */ }, { 40808, 35, /* 0.14 */ }, { 42707, 34, /* 0.13 */ }, { 44694, 33, /* 0.13 */ }, { 46776, 33, /* 0.13 */ }, { 48961, 32, /* 0.13 */ }, { 51258, 32, /* 0.13 */ }, { 53677, 31, /* 0.12 */ }, { 56230, 30, /* 0.12 */ }, { 58932, 30, /* 0.12 */ }, { 61799, 29, /* 0.12 */ }, { 64851, 28, /* 0.11 */ }, { 68113, 28, /* 0.11 */ }, { 71617, 27, /* 0.11 */ }, { 75401, 26, /* 0.10 */ }, { 79517, 26, /* 0.10 */ }, { 84035, 25, /* 0.10 */ }, { 89053, 24, /* 0.10 */ }, }; #define HSTCP_AIMD_MAX ((sizeof (hstcp_aimd_vals) / sizeof (struct hstcp_aimd_val)) - 1) struct hstcp_ca { u32 ai; }; static void hstcp_start(struct tcp_sock *tp) { struct hstcp_ca *ca = tcp_ca(tp); ca->ai = 0; /* Ensure the MD arithmetic works. This is somewhat pedantic, * since I don't think we will see a cwnd this large. :) */ tp->snd_cwnd_clamp = min_t(u32, tp->snd_cwnd_clamp, 0xffffffff/128); } static void hstcp_cong_avoid(struct tcp_sock *tp, u32 adk, u32 rtt, u32 in_flight) { struct hstcp_ca *ca = tcp_ca(tp); if (in_flight < tp->snd_cwnd) return; if (tp->snd_cwnd <= tp->snd_ssthresh) { if (tp->snd_cwnd < tp->snd_cwnd_clamp) tp->snd_cwnd++; } else { /* Update AIMD parameters */ if (tp->snd_cwnd > hstcp_aimd_vals[ca->ai].cwnd) { while (tp->snd_cwnd > hstcp_aimd_vals[ca->ai].cwnd && ca->ai < HSTCP_AIMD_MAX) ca->ai++; } else if (tp->snd_cwnd < hstcp_aimd_vals[ca->ai].cwnd) { while (tp->snd_cwnd > hstcp_aimd_vals[ca->ai].cwnd && ca->ai > 0) ca->ai--; } /* Do additive increase */ if (tp->snd_cwnd < tp->snd_cwnd_clamp) { tp->snd_cwnd_cnt += ca->ai; if (tp->snd_cwnd_cnt >= tp->snd_cwnd) { tp->snd_cwnd++; tp->snd_cwnd_cnt -= tp->snd_cwnd; } } } } static u32 hstcp_ssthresh(struct tcp_sock *tp) { struct hstcp_ca *ca = tcp_ca(tp); /* Do multiplicative decrease */ return max(tp->snd_cwnd - ((tp->snd_cwnd * hstcp_aimd_vals[ca->ai].md) >> 8), 2U); } static struct tcp_ca_type tcp_highspeed = { .start = hstcp_start, .ssthresh = hstcp_ssthresh, .min_cwnd = tcp_reno_cwnd_min, .cong_avoid = hstcp_cong_avoid, .owner = THIS_MODULE, .name = "highspeed" }; static int __init hstcp_init(void) { BUILD_BUG_ON(sizeof(struct hstcp_ca) > TCP_CA_PRIV_SIZE); tcp_ca_register(&tcp_highspeed); return 0; } static void __exit hstcp_exit(void) { tcp_ca_unregister(&tcp_highspeed); } module_init(hstcp_init); module_exit(hstcp_exit); MODULE_AUTHOR("John Heffner"); MODULE_LICENSE("GPL"); MODULE_DESCRIPTION("High Speed TCP"); From 76306.1226@compuserve.com Tue Mar 15 11:59:38 2005 Received: with ECARTIS (v1.0.0; list netdev); Tue, 15 Mar 2005 11:59:45 -0800 (PST) Received: from siaag1ag.compuserve.com (siaag1ag.compuserve.com [149.174.40.13]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j2FJxcQG029819 for ; Tue, 15 Mar 2005 11:59:38 -0800 Received: (from mailgate@localhost) by siaag1ag.compuserve.com (8.12.11/8.12.7/SUN-2.17) id j2FJxDoW015318; Tue, 15 Mar 2005 14:59:13 -0500 (EST) Date: Tue, 15 Mar 2005 14:56:15 -0500 From: Chuck Ebbert <76306.1226@compuserve.com> Subject: [PATCH] Optimize loopback stats To: linux-netdev Cc: Andrew Morton , Christoph Lameter Message-ID: <200503151459_MC3-1-989A-61A4@compuserve.com> MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii Content-Disposition: inline X-Virus-Scanned: ClamAV 0.83/762/Sun Mar 13 15:35:33 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 191 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: 76306.1226@compuserve.com Precedence: bulk X-list: netdev Content-Length: 3066 Lines: 87 This patch optimizes the loopback driver's statistics by using a single counter for rx and tx stats instead of one for rx and one for tx. It also adds unlikely() to the test for TSO since it's no longer supported by default. (Maybe the TSO code should be bracketed by "#if 0" ?) o saves 84 bytes per CPU on 32bit and 168 bytes on 64 bit (should save 84K data on 512-way ia64) o AFAICT the driver is ~2.5% faster sending PF_PACKET data o applies on top of Christoph's patch in -mm that removes update of the device's last_rx field Signed-off-by: Chuck Ebbert <76306.1226@compuserve.com> --- 2.6.11-mm/drivers/net/loopback.c 2005-03-15 14:23:30.180677000 -0500 +++ 2.6.11-ce/drivers/net/loopback.c 2005-03-15 14:26:23.700677000 -0500 @@ -58,7 +58,12 @@ #include #include -static DEFINE_PER_CPU(struct net_device_stats, loopback_stats); +struct loopback_device_stats { + unsigned long rx_tx_bytes; + unsigned long rx_tx_packets; +}; + +static DEFINE_PER_CPU(struct loopback_device_stats, loopback_stats); #define LOOPBACK_OVERHEAD (128 + MAX_HEADER + 16 + 16) @@ -126,7 +131,7 @@ static void emulate_large_send_offload(s */ static int loopback_xmit(struct sk_buff *skb, struct net_device *dev) { - struct net_device_stats *lb_stats; + struct loopback_device_stats *lb_stats; skb_orphan(skb); @@ -136,7 +141,7 @@ static int loopback_xmit(struct sk_buff skb->ip_summed = CHECKSUM_UNNECESSARY; #endif - if (skb_shinfo(skb)->tso_size) { + if (unlikely(skb_shinfo(skb)->tso_size)) { BUG_ON(skb->protocol != htons(ETH_P_IP)); BUG_ON(skb->nh.iph->protocol != IPPROTO_TCP); @@ -145,10 +150,8 @@ static int loopback_xmit(struct sk_buff } lb_stats = &per_cpu(loopback_stats, get_cpu()); - lb_stats->rx_bytes += skb->len; - lb_stats->tx_bytes += skb->len; - lb_stats->rx_packets++; - lb_stats->tx_packets++; + lb_stats->rx_tx_bytes += skb->len; + lb_stats->rx_tx_packets++; put_cpu(); netif_rx(skb); @@ -168,15 +171,15 @@ static struct net_device_stats *get_stat memset(stats, 0, sizeof(struct net_device_stats)); for (i=0; i < NR_CPUS; i++) { - struct net_device_stats *lb_stats; + struct loopback_device_stats *lb_stats; if (!cpu_possible(i)) continue; lb_stats = &per_cpu(loopback_stats, i); - stats->rx_bytes += lb_stats->rx_bytes; - stats->tx_bytes += lb_stats->tx_bytes; - stats->rx_packets += lb_stats->rx_packets; - stats->tx_packets += lb_stats->tx_packets; + stats->rx_bytes += lb_stats->rx_tx_bytes; + stats->tx_bytes = stats->rx_bytes; + stats->rx_packets += lb_stats->rx_tx_packets; + stats->tx_packets = stats->rx_packets; } return stats; _ -- Chuck From niv@us.ibm.com Tue Mar 15 12:15:07 2005 Received: with ECARTIS (v1.0.0; list netdev); Tue, 15 Mar 2005 12:15:12 -0800 (PST) Received: from e4.ny.us.ibm.com (e4.ny.us.ibm.com [32.97.182.144]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j2FKF0dx030784 for ; Tue, 15 Mar 2005 12:15:07 -0800 Received: from d01relay04.pok.ibm.com (d01relay04.pok.ibm.com [9.56.227.236]) by e4.ny.us.ibm.com (8.12.11/8.12.11) with ESMTP id j2FKEtJO019136 for ; Tue, 15 Mar 2005 15:14:55 -0500 Received: from d01av02.pok.ibm.com (d01av02.pok.ibm.com [9.56.224.216]) by d01relay04.pok.ibm.com (8.12.10/NCO/VER6.6) with ESMTP id j2FKEtRs244108 for ; Tue, 15 Mar 2005 15:14:55 -0500 Received: from d01av02.pok.ibm.com (loopback [127.0.0.1]) by d01av02.pok.ibm.com (8.12.11/8.12.11) with ESMTP id j2FKEsxY004518 for ; Tue, 15 Mar 2005 15:14:54 -0500 Received: from [9.47.22.102] (IBM-UFKG5CEJ4KK.beaverton.ibm.com [9.47.22.102]) by d01av02.pok.ibm.com (8.12.11/8.12.11) with ESMTP id j2FKEr9r004483; Tue, 15 Mar 2005 15:14:54 -0500 Message-ID: <4237423E.2040505@us.ibm.com> Date: Tue, 15 Mar 2005 12:14:54 -0800 From: Nivedita Singhvi User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.5) Gecko/20041217 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Chuck Ebbert <76306.1226@compuserve.com> CC: linux-netdev , Andrew Morton , Christoph Lameter Subject: Re: [PATCH] Optimize loopback stats References: <200503151459_MC3-1-989A-61A4@compuserve.com> In-Reply-To: <200503151459_MC3-1-989A-61A4@compuserve.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV 0.83/762/Sun Mar 13 15:35:33 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 192 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: niv@us.ibm.com Precedence: bulk X-list: netdev Content-Length: 3402 Lines: 99 Chuck Ebbert wrote: > This patch optimizes the loopback driver's statistics by using a single > counter for rx and tx stats instead of one for rx and one for tx. It also > adds unlikely() to the test for TSO since it's no longer supported by default. > (Maybe the TSO code should be bracketed by "#if 0" ?) Hmm, some of us want those counters separate - if this is really needed, could it be a configurable option, please? thanks, Nivedita > o saves 84 bytes per CPU on 32bit and 168 bytes on 64 bit > (should save 84K data on 512-way ia64) > > o AFAICT the driver is ~2.5% faster sending PF_PACKET data > > o applies on top of Christoph's patch in -mm that removes update > of the device's last_rx field > > Signed-off-by: Chuck Ebbert <76306.1226@compuserve.com> > > --- 2.6.11-mm/drivers/net/loopback.c 2005-03-15 14:23:30.180677000 -0500 > +++ 2.6.11-ce/drivers/net/loopback.c 2005-03-15 14:26:23.700677000 -0500 > @@ -58,7 +58,12 @@ > #include > #include > > -static DEFINE_PER_CPU(struct net_device_stats, loopback_stats); > +struct loopback_device_stats { > + unsigned long rx_tx_bytes; > + unsigned long rx_tx_packets; > +}; > + > +static DEFINE_PER_CPU(struct loopback_device_stats, loopback_stats); > > #define LOOPBACK_OVERHEAD (128 + MAX_HEADER + 16 + 16) > > @@ -126,7 +131,7 @@ static void emulate_large_send_offload(s > */ > static int loopback_xmit(struct sk_buff *skb, struct net_device *dev) > { > - struct net_device_stats *lb_stats; > + struct loopback_device_stats *lb_stats; > > skb_orphan(skb); > > @@ -136,7 +141,7 @@ static int loopback_xmit(struct sk_buff > skb->ip_summed = CHECKSUM_UNNECESSARY; > #endif > > - if (skb_shinfo(skb)->tso_size) { > + if (unlikely(skb_shinfo(skb)->tso_size)) { > BUG_ON(skb->protocol != htons(ETH_P_IP)); > BUG_ON(skb->nh.iph->protocol != IPPROTO_TCP); > > @@ -145,10 +150,8 @@ static int loopback_xmit(struct sk_buff > } > > lb_stats = &per_cpu(loopback_stats, get_cpu()); > - lb_stats->rx_bytes += skb->len; > - lb_stats->tx_bytes += skb->len; > - lb_stats->rx_packets++; > - lb_stats->tx_packets++; > + lb_stats->rx_tx_bytes += skb->len; > + lb_stats->rx_tx_packets++; > put_cpu(); > > netif_rx(skb); > @@ -168,15 +171,15 @@ static struct net_device_stats *get_stat > memset(stats, 0, sizeof(struct net_device_stats)); > > for (i=0; i < NR_CPUS; i++) { > - struct net_device_stats *lb_stats; > + struct loopback_device_stats *lb_stats; > > if (!cpu_possible(i)) > continue; > lb_stats = &per_cpu(loopback_stats, i); > - stats->rx_bytes += lb_stats->rx_bytes; > - stats->tx_bytes += lb_stats->tx_bytes; > - stats->rx_packets += lb_stats->rx_packets; > - stats->tx_packets += lb_stats->tx_packets; > + stats->rx_bytes += lb_stats->rx_tx_bytes; > + stats->tx_bytes = stats->rx_bytes; > + stats->rx_packets += lb_stats->rx_tx_packets; > + stats->tx_packets = stats->rx_packets; > } > > return stats; > _ > > -- > Chuck > > From herbert@gondor.apana.org.au Tue Mar 15 12:33:24 2005 Received: with ECARTIS (v1.0.0; list netdev); Tue, 15 Mar 2005 12:33:33 -0800 (PST) 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 j2FKXNu9003183 for ; Tue, 15 Mar 2005 12:33:24 -0800 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 1DBIiH-0001FW-00; Wed, 16 Mar 2005 07:32:25 +1100 Received: from herbert by gondolin.me.apana.org.au with local (Exim 3.36 #1 (Debian)) id 1DBIhk-0005p5-00; Wed, 16 Mar 2005 07:31:52 +1100 Date: Wed, 16 Mar 2005 07:31:52 +1100 To: "David S. Miller" Cc: kuznet@ms2.inr.ac.ru, yoshfuji@linux-ipv6.org, kaber@trash.net, netdev@oss.sgi.com Subject: Re: [17/*] [NET] Replace dst_pmtu with dst_mtu Message-ID: <20050315203152.GA22349@gondor.apana.org.au> References: <20050306213214.7d8a143d.davem@davemloft.net> <20050307103536.GB7137@gondor.apana.org.au> <20050308102741.GA23468@gondor.apana.org.au> <20050314102614.GA9610@gondor.apana.org.au> <20050314105313.GA21001@gondor.apana.org.au> <20050314111002.GA29156@gondor.apana.org.au> <20050315091904.GA6256@gondor.apana.org.au> <20050315095837.GA7130@gondor.apana.org.au> <20050315100522.GA7275@gondor.apana.org.au> <20050315102450.0f3f1618.davem@davemloft.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20050315102450.0f3f1618.davem@davemloft.net> User-Agent: Mutt/1.5.6+20040907i From: Herbert Xu X-Virus-Scanned: ClamAV 0.83/762/Sun Mar 13 15:35:33 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 193 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: herbert@gondor.apana.org.au Precedence: bulk X-list: netdev Content-Length: 746 Lines: 17 On Tue, Mar 15, 2005 at 10:24:50AM -0800, David S. Miller wrote: > > So, at that point, I guess the next task is to handle PMTU events of already > encrypted packets properly? We still have that problem right? When the > ICMP payload is encrypted we have to cache some information on IPSEC output > so that a proto+SPI key can find us the encrypted inner IP header info, which > we'll need in order to process (and/or forward) the ICMP PMTU information > correctly. Yes, that's going to be the second part of the MTU work. Cheers, -- Visit Openswan at http://www.openswan.org/ Email: Herbert Xu ~{PmV>HI~} Home Page: http://gondor.apana.org.au/~herbert/ PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt From herbert@gondor.apana.org.au Tue Mar 15 12:40:59 2005 Received: with ECARTIS (v1.0.0; list netdev); Tue, 15 Mar 2005 12:41:06 -0800 (PST) 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 j2FKevf7003907 for ; Tue, 15 Mar 2005 12:40:58 -0800 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 1DBIpy-0001PA-00; Wed, 16 Mar 2005 07:40:22 +1100 Received: from herbert by gondolin.me.apana.org.au with local (Exim 3.36 #1 (Debian)) id 1DBIpi-0005qD-00; Wed, 16 Mar 2005 07:40:06 +1100 Date: Wed, 16 Mar 2005 07:40:06 +1100 To: Patrick McHardy Cc: "David S. Miller" , kuznet@ms2.inr.ac.ru, yoshfuji@linux-ipv6.org, netdev@oss.sgi.com Subject: Replace send_unreach with icmp_send Message-ID: <20050315204006.GB22349@gondor.apana.org.au> References: <20050307103536.GB7137@gondor.apana.org.au> <20050308102741.GA23468@gondor.apana.org.au> <20050314102614.GA9610@gondor.apana.org.au> <20050314105313.GA21001@gondor.apana.org.au> <20050314111002.GA29156@gondor.apana.org.au> <20050315091904.GA6256@gondor.apana.org.au> <20050315095837.GA7130@gondor.apana.org.au> <20050315100522.GA7275@gondor.apana.org.au> <20050315102450.0f3f1618.davem@davemloft.net> <42373142.6090902@trash.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <42373142.6090902@trash.net> User-Agent: Mutt/1.5.6+20040907i From: Herbert Xu X-Virus-Scanned: ClamAV 0.83/762/Sun Mar 13 15:35:33 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 194 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: herbert@gondor.apana.org.au Precedence: bulk X-list: netdev Content-Length: 888 Lines: 22 On Tue, Mar 15, 2005 at 08:02:26PM +0100, Patrick McHardy wrote: > > I would prefer to keep it seperately. I have planned to remove xrlim > from ipt_REJECT so it behaves similar for TCP and ICMP. Limits should > then be handled by the limit match. This can't be done if we switch to > icmp_send(). Well it isn't terribly difficult to create a new version of icmp_send that does xrlim conditionally. icmp_send/ipt_REJECT can then call that function. The main reason I'm looking at getting rid of send_unreach is because having two implementations of the same code often leads to bugs. In fact, as it is there are multiple IPsec-related bugs in the ipt_REJECT code. Cheers, -- Visit Openswan at http://www.openswan.org/ Email: Herbert Xu ~{PmV>HI~} Home Page: http://gondor.apana.org.au/~herbert/ PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt From kaber@trash.net Tue Mar 15 12:49:50 2005 Received: with ECARTIS (v1.0.0; list netdev); Tue, 15 Mar 2005 12:49:54 -0800 (PST) Received: from kaber.coreworks.de ([62.206.217.67]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j2FKnoTl004570 for ; Tue, 15 Mar 2005 12:49:50 -0800 Received: from localhost ([127.0.0.1]) by kaber.coreworks.de with esmtp (Exim 4.50) id 1DBIyD-0001oC-Eh; Tue, 15 Mar 2005 21:48:53 +0100 Message-ID: <42374A35.6020308@trash.net> Date: Tue, 15 Mar 2005 21:48:53 +0100 From: Patrick McHardy User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.7.5) Gecko/20050106 Debian/1.7.5-1 X-Accept-Language: en MIME-Version: 1.0 To: Herbert Xu CC: "David S. Miller" , kuznet@ms2.inr.ac.ru, yoshfuji@linux-ipv6.org, netdev@oss.sgi.com Subject: Re: Replace send_unreach with icmp_send References: <20050307103536.GB7137@gondor.apana.org.au> <20050308102741.GA23468@gondor.apana.org.au> <20050314102614.GA9610@gondor.apana.org.au> <20050314105313.GA21001@gondor.apana.org.au> <20050314111002.GA29156@gondor.apana.org.au> <20050315091904.GA6256@gondor.apana.org.au> <20050315095837.GA7130@gondor.apana.org.au> <20050315100522.GA7275@gondor.apana.org.au> <20050315102450.0f3f1618.davem@davemloft.net> <42373142.6090902@trash.net> <20050315204006.GB22349@gondor.apana.org.au> In-Reply-To: <20050315204006.GB22349@gondor.apana.org.au> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV 0.83/762/Sun Mar 13 15:35:33 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 195 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: kaber@trash.net Precedence: bulk X-list: netdev Content-Length: 524 Lines: 15 Herbert Xu wrote: > Well it isn't terribly difficult to create a new version of icmp_send > that does xrlim conditionally. icmp_send/ipt_REJECT can then call that > function. > > The main reason I'm looking at getting rid of send_unreach is because > having two implementations of the same code often leads to bugs. In > fact, as it is there are multiple IPsec-related bugs in the ipt_REJECT > code. Ok. I can't see any different reason to keep it, so go ahead. I'll take care of the xrlim stuff later. Regards Patrick From niv@us.ibm.com Tue Mar 15 12:49:59 2005 Received: with ECARTIS (v1.0.0; list netdev); Tue, 15 Mar 2005 12:50:03 -0800 (PST) Received: from e34.co.us.ibm.com (e34.co.us.ibm.com [32.97.110.132]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j2FKnwBR004583 for ; Tue, 15 Mar 2005 12:49:58 -0800 Received: from westrelay02.boulder.ibm.com (westrelay02.boulder.ibm.com [9.17.195.11]) by e34.co.us.ibm.com (8.12.10/8.12.9) with ESMTP id j2FKnqKN500478 for ; Tue, 15 Mar 2005 15:49:52 -0500 Received: from d03av02.boulder.ibm.com (d03av02.boulder.ibm.com [9.17.195.168]) by westrelay02.boulder.ibm.com (8.12.10/NCO/VER6.6) with ESMTP id j2FKnqTl220554 for ; Tue, 15 Mar 2005 13:49:52 -0700 Received: from d03av02.boulder.ibm.com (loopback [127.0.0.1]) by d03av02.boulder.ibm.com (8.12.11/8.12.11) with ESMTP id j2FKnqQX020506 for ; Tue, 15 Mar 2005 13:49:52 -0700 Received: from [9.47.22.102] (IBM-UFKG5CEJ4KK.beaverton.ibm.com [9.47.22.102]) by d03av02.boulder.ibm.com (8.12.11/8.12.11) with ESMTP id j2FKnphb020475; Tue, 15 Mar 2005 13:49:51 -0700 Message-ID: <42374A6F.50300@us.ibm.com> Date: Tue, 15 Mar 2005 12:49:51 -0800 From: Nivedita Singhvi User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.5) Gecko/20041217 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Chuck Ebbert <76306.1226@compuserve.com> CC: linux-netdev , Andrew Morton , Christoph Lameter Subject: Re: [PATCH] Optimize loopback stats References: <200503151459_MC3-1-989A-61A4@compuserve.com> <4237423E.2040505@us.ibm.com> In-Reply-To: <4237423E.2040505@us.ibm.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV 0.83/762/Sun Mar 13 15:35:33 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 196 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: niv@us.ibm.com Precedence: bulk X-list: netdev Content-Length: 623 Lines: 21 Nivedita Singhvi wrote: > Chuck Ebbert wrote: > >> This patch optimizes the loopback driver's statistics by using a single >> counter for rx and tx stats instead of one for rx and one for tx. It >> also >> adds unlikely() to the test for TSO since it's no longer supported by >> default. >> (Maybe the TSO code should be bracketed by "#if 0" ?) > > > Hmm, some of us want those counters separate - if this is really > needed, could it be a configurable option, please? Or we could live with the appropriate patches to ip, ifconfig, reporting them separately (halving them). That would be fine. thanks, Nivedita From linville@bilbo.tuxdriver.com Tue Mar 15 13:52:26 2005 Received: with ECARTIS (v1.0.0; list netdev); Tue, 15 Mar 2005 13:52:38 -0800 (PST) Received: from ra.tuxdriver.com (ra.tuxdriver.com [24.172.12.4]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j2FLqPsO007767 for ; Tue, 15 Mar 2005 13:52:26 -0800 Received: from bilbo.tuxdriver.com (bilbo.tuxdriver.com [24.172.12.5]) by ra.tuxdriver.com (8.11.6/8.11.6) with ESMTP id j2FLj4G04609; Tue, 15 Mar 2005 16:45:04 -0500 Received: from bilbo.tuxdriver.com (localhost.localdomain [127.0.0.1]) by bilbo.tuxdriver.com (8.13.1/8.13.1) with ESMTP id j2FLpYSJ018299; Tue, 15 Mar 2005 16:51:34 -0500 Received: (from linville@localhost) by bilbo.tuxdriver.com (8.13.1/8.13.1/Submit) id j2FLpXnf018298; Tue, 15 Mar 2005 16:51:33 -0500 Date: Tue, 15 Mar 2005 16:51:33 -0500 From: "John W. Linville" To: linux-kernel@vger.kernel.org Cc: ctindel@users.sourceforge.net, fubar@us.ibm.com, bonding-devel@lists.sourceforge.net, netdev@oss.sgi.com, jgarzik@pobox.com Subject: [patch 2.6.11] bonding: avoid tx balance for IGMP (alb/tlb mode) Message-ID: <20050315215128.GA18262@tuxdriver.com> Mail-Followup-To: linux-kernel@vger.kernel.org, ctindel@users.sourceforge.net, fubar@us.ibm.com, bonding-devel@lists.sourceforge.net, netdev@oss.sgi.com, jgarzik@pobox.com Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.4.1i X-Virus-Scanned: ClamAV 0.83/762/Sun Mar 13 15:35:33 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 197 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: linville@tuxdriver.com Precedence: bulk X-list: netdev Content-Length: 2280 Lines: 55 Add special case to bond_alb_xmit() to avoid tx balance for IGMP. Signed-off-by: John W. Linville --- Some switches (e.g. the Cisco Catalyst 3750) use IGMP snooping to determine which hosts belong to which multicast groups. Typically such switches use a timeout to determine when hosts have quietly left a group. In ALB or TLB mode, only one interface is configured to receive packets at a time. (Receive load balancing doesn't seem to be effective for IGMP traffic.) If both Ethernet interfaces are up, the load balancing capability can move the sending of IGMP packets to the non-receiving interface. If the switch ends up timing out the interface configured to receive packets, the multicast packets are then only sent to the non-receiving interface and are subsequently dropped. This behaviour is undesirable. The fix is to add a new special case (alongside some existing special cases) in bond_alb_xmit() in order to ensure that IGMP traffic is always sent out the port which is configured to receive frames. Of course, this patch has the downside of not load balancing IGMP traffic from the host. But, I'm inclined to believe that is "no big deal"... :-) Also, I'm sure other solutions might exist. But, they are likely no where near as simple as this one. And, this is probably the most in keeping with the ALB/TLB philosophy of not requiring any special switch support. drivers/net/bonding/bond_alb.c | 4 +++- 1 files changed, 3 insertions(+), 1 deletion(-) --- linux-2.6.11/drivers/net/bonding/bond_alb.c.orig 2005-03-15 16:25:09.648034108 -0500 +++ linux-2.6.11/drivers/net/bonding/bond_alb.c 2005-03-15 16:25:09.649033971 -0500 @@ -54,6 +54,7 @@ #include #include #include +#include #include #include #include @@ -1300,7 +1301,8 @@ int bond_alb_xmit(struct sk_buff *skb, s switch (ntohs(skb->protocol)) { case ETH_P_IP: if ((memcmp(eth_data->h_dest, mac_bcast, ETH_ALEN) == 0) || - (skb->nh.iph->daddr == ip_bcast)) { + (skb->nh.iph->daddr == ip_bcast) || + (skb->nh.iph->protocol == IPPROTO_IGMP)) { do_tx_balance = 0; break; } -- John W. Linville linville@tuxdriver.com From jheffner@psc.edu Tue Mar 15 14:16:30 2005 Received: with ECARTIS (v1.0.0; list netdev); Tue, 15 Mar 2005 14:16:35 -0800 (PST) Received: from mailer2.psc.edu (mailer2.psc.edu [128.182.66.106]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j2FMGTxF009011 for ; Tue, 15 Mar 2005 14:16:30 -0800 Received: from dexter.psc.edu (dexter.psc.edu [128.182.61.232]) by mailer2.psc.edu (8.13.3/8.13.3) with ESMTP id j2FMIOwV023834 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 15 Mar 2005 17:18:25 -0500 (EST) Received: from dexter.psc.edu (localhost.psc.edu [127.0.0.1]) by dexter.psc.edu (8.12.11/8.12.10) with ESMTP id j2FMGJhm008560; Tue, 15 Mar 2005 17:16:19 -0500 Received: from localhost (jheffner@localhost) by dexter.psc.edu (8.12.11/8.12.11/Submit) with ESMTP id j2FMGJj7008557; Tue, 15 Mar 2005 17:16:19 -0500 X-Authentication-Warning: dexter.psc.edu: jheffner owned process doing -bs Date: Tue, 15 Mar 2005 17:16:19 -0500 (EST) From: John Heffner To: Stephen Hemminger cc: "David S. Miller" , baruch@ev-en.org, netdev@oss.sgi.com Subject: Re: [RFC] TCP congestion schedulers In-Reply-To: <20050314151726.532af90d@dxpl.pdx.osdl.net> Message-ID: References: <421CF5E5.1060606@ev-en.org> <20050223135732.39e62c6c.davem@davemloft.net> <421D1E66.5090301@osdl.org> <421D30FA.1060900@ev-en.org> <20050225120814.5fa77b13@dxpl.pdx.osdl.net> <20050309210442.3e9786a6.davem@davemloft.net> <4230288F.1030202@ev-en.org> <20050310182629.1eab09ec.davem@davemloft.net> <20050311120054.4bbf675a@dxpl.pdx.osdl.net> <20050311201011.360c00da.davem@davemloft.net> <20050314151726.532af90d@dxpl.pdx.osdl.net> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Virus-Scanned: ClamAV 0.83/762/Sun Mar 13 15:35:33 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 198 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: jheffner@psc.edu Precedence: bulk X-list: netdev Content-Length: 477 Lines: 18 This fixes a null pointer dereference when closing listen sockets. -John ===== include/net/tcp.h 1.107 vs 1.108 ===== --- 1.107/include/net/tcp.h Tue Mar 15 15:12:54 2005 +++ 1.108/include/net/tcp.h Tue Mar 15 17:09:48 2005 @@ -1219,7 +1219,7 @@ static inline void tcp_set_ca_state(struct tcp_sock *tp, u8 ca_state) { - if (tp->ca_proto->set_state) + if (tp->ca_proto && tp->ca_proto->set_state) tp->ca_proto->set_state(tp, ca_state); tp->ca_state = ca_state; } From akpm@osdl.org Tue Mar 15 14:21:59 2005 Received: with ECARTIS (v1.0.0; list netdev); Tue, 15 Mar 2005 14:22:04 -0800 (PST) Received: from smtp.osdl.org (fire.osdl.org [65.172.181.4]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j2FMLxCO009620 for ; Tue, 15 Mar 2005 14:21:59 -0800 Received: from shell0.pdx.osdl.net (fw.osdl.org [65.172.181.6]) by smtp.osdl.org (8.12.8/8.12.8) with ESMTP id j2FMLqqi007288 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO); Tue, 15 Mar 2005 14:21:52 -0800 Received: from akpm.pao.digeo.com (shell0.pdx.osdl.net [10.9.0.31]) by shell0.pdx.osdl.net (8.13.1/8.11.6) with SMTP id j2FMLpjN016768; Tue, 15 Mar 2005 14:21:51 -0800 Date: Tue, 15 Mar 2005 14:21:56 -0800 From: Andrew Morton To: "David S. Miller" , Jeff Garzik Cc: netdev@oss.sgi.com Subject: net patches Message-Id: <20050315142156.1659e655.akpm@osdl.org> X-Mailer: Sylpheed version 1.0.0 (GTK+ 1.2.10; i386-vine-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Received-SPF: pass (domain of akpm@osdl.org designates 65.172.181.6 as permitted sender) X-MIMEDefang-Filter: osdl$Revision: 1.105 $ X-Scanned-By: MIMEDefang 2.36 X-Virus-Scanned: ClamAV 0.83/762/Sun Mar 13 15:35:33 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 199 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: akpm@osdl.org Precedence: bulk X-list: netdev Content-Length: 117 Lines: 4 Time for me to unload some accumulated cruft. Please let me know which if any of these patchs I should just drop. From akpm@osdl.org Tue Mar 15 14:22:44 2005 Received: with ECARTIS (v1.0.0; list netdev); Tue, 15 Mar 2005 14:22:55 -0800 (PST) Received: from smtp.osdl.org (fire.osdl.org [65.172.181.4]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j2FMMi2v009785 for ; Tue, 15 Mar 2005 14:22:44 -0800 Received: from shell0.pdx.osdl.net (fw.osdl.org [65.172.181.6]) by smtp.osdl.org (8.12.8/8.12.8) with ESMTP id j2FMMYqi007517 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO); Tue, 15 Mar 2005 14:22:35 -0800 Received: from localhost.localdomain (shell0.pdx.osdl.net [10.9.0.31]) by shell0.pdx.osdl.net (8.13.1/8.11.6) with ESMTP id j2FMMW2x016793; Tue, 15 Mar 2005 14:22:33 -0800 Message-Id: <200503152222.j2FMMW2x016793@shell0.pdx.osdl.net> Subject: [patch 01/13] b44: allocate tx bounce bufs as needed To: davem@davemloft.net Cc: jgarzik@pobox.com, netdev@oss.sgi.com, akpm@osdl.org, linville@tuxdriver.com, pp@netppl.fi From: akpm@osdl.org Date: Tue, 15 Mar 2005 14:22:37 -0800 Received-SPF: pass (domain of akpm@osdl.org designates 65.172.181.6 as permitted sender) X-MIMEDefang-Filter: osdl$Revision: 1.105 $ X-Scanned-By: MIMEDefang 2.36 X-Virus-Scanned: ClamAV 0.83/762/Sun Mar 13 15:35:33 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 200 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: akpm@osdl.org Precedence: bulk X-list: netdev Content-Length: 4117 Lines: 121 From: "John W. Linville" The b44 hardware has a DMA mask that only covers 1GB. On x86, a DMA mask <4GB results in allocations using GFP_DMA. The GFP_DMA pool (16MB) gets exhausted very quickly in some configurations. The b44 driver has been pre-allocating bounce buffers in a single large (~750k) contiguous block. On boxes w/ limited GFP_DMA memory, this allocation can fail. Such failure results in the driver being unable to load and function. The solution here is to check each tx skb against the DMA mask. If it is outside the allowable range, a single buffer is allocated from the GFP_DMA range and discarded after the tx completes. This behaviour mimics what is done for bounce buffers on the rx side. The pre-allocation of tx bounce buffers is, of course, removed. Acked-by: Pekka Pietikäinen Signed-off-by: John W. Linville Signed-off-by: Andrew Morton --- 25-akpm/drivers/net/b44.c | 36 +++++++++++++++++++++--------------- 25-akpm/drivers/net/b44.h | 3 +-- 2 files changed, 22 insertions(+), 17 deletions(-) diff -puN drivers/net/b44.c~b44-allocate-tx-bounce-bufs-as-needed drivers/net/b44.c --- 25/drivers/net/b44.c~b44-allocate-tx-bounce-bufs-as-needed Tue Mar 15 14:19:52 2005 +++ 25-akpm/drivers/net/b44.c Tue Mar 15 14:19:52 2005 @@ -907,6 +907,7 @@ static void b44_tx_timeout(struct net_de static int b44_start_xmit(struct sk_buff *skb, struct net_device *dev) { struct b44 *bp = netdev_priv(dev); + struct sk_buff *bounce_skb; dma_addr_t mapping; u32 len, entry, ctrl; @@ -922,15 +923,31 @@ static int b44_start_xmit(struct sk_buff return 1; } - entry = bp->tx_prod; mapping = pci_map_single(bp->pdev, skb->data, len, PCI_DMA_TODEVICE); if(mapping+len > B44_DMA_MASK) { /* Chip can't handle DMA to/from >1GB, use bounce buffer */ - pci_unmap_single(bp->pdev, mapping, len,PCI_DMA_TODEVICE); - memcpy(bp->tx_bufs+entry*TX_PKT_BUF_SZ,skb->data,skb->len); - mapping = pci_map_single(bp->pdev, bp->tx_bufs+entry*TX_PKT_BUF_SZ, len, PCI_DMA_TODEVICE); + pci_unmap_single(bp->pdev, mapping, len, PCI_DMA_TODEVICE); + + bounce_skb = __dev_alloc_skb(TX_PKT_BUF_SZ, + GFP_ATOMIC|GFP_DMA); + if (!bounce_skb) + return NETDEV_TX_BUSY; + + mapping = pci_map_single(bp->pdev, bounce_skb->data, + len, PCI_DMA_TODEVICE); + if(mapping+len > B44_DMA_MASK) { + pci_unmap_single(bp->pdev, mapping, + len, PCI_DMA_TODEVICE); + dev_kfree_skb_any(bounce_skb); + return NETDEV_TX_BUSY; + } + + memcpy(skb_put(bounce_skb, len), skb->data, skb->len); + dev_kfree_skb_any(skb); + skb = bounce_skb; } + entry = bp->tx_prod; bp->tx_buffers[entry].skb = skb; pci_unmap_addr_set(&bp->tx_buffers[entry], mapping, mapping); @@ -1077,11 +1094,6 @@ static void b44_free_consistent(struct b bp->tx_ring, bp->tx_ring_dma); bp->tx_ring = NULL; } - if (bp->tx_bufs) { - pci_free_consistent(bp->pdev, B44_TX_RING_SIZE * TX_PKT_BUF_SZ, - bp->tx_bufs, bp->tx_bufs_dma); - bp->tx_bufs = NULL; - } } /* @@ -1104,12 +1116,6 @@ static int b44_alloc_consistent(struct b goto out_err; memset(bp->tx_buffers, 0, size); - size = B44_TX_RING_SIZE * TX_PKT_BUF_SZ; - bp->tx_bufs = pci_alloc_consistent(bp->pdev, size, &bp->tx_bufs_dma); - if (!bp->tx_bufs) - goto out_err; - memset(bp->tx_bufs, 0, size); - size = DMA_TABLE_BYTES; bp->rx_ring = pci_alloc_consistent(bp->pdev, size, &bp->rx_ring_dma); if (!bp->rx_ring) diff -puN drivers/net/b44.h~b44-allocate-tx-bounce-bufs-as-needed drivers/net/b44.h --- 25/drivers/net/b44.h~b44-allocate-tx-bounce-bufs-as-needed Tue Mar 15 14:19:52 2005 +++ 25-akpm/drivers/net/b44.h Tue Mar 15 14:19:52 2005 @@ -383,7 +383,6 @@ struct b44 { struct ring_info *rx_buffers; struct ring_info *tx_buffers; - unsigned char *tx_bufs; u32 dma_offset; u32 flags; @@ -415,7 +414,7 @@ struct b44 { struct pci_dev *pdev; struct net_device *dev; - dma_addr_t rx_ring_dma, tx_ring_dma,tx_bufs_dma; + dma_addr_t rx_ring_dma, tx_ring_dma; u32 rx_pending; u32 tx_pending; _ From akpm@osdl.org Tue Mar 15 14:22:46 2005 Received: with ECARTIS (v1.0.0; list netdev); Tue, 15 Mar 2005 14:23:00 -0800 (PST) Received: from smtp.osdl.org (fire.osdl.org [65.172.181.4]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j2FMMjjF009799 for ; Tue, 15 Mar 2005 14:22:45 -0800 Received: from shell0.pdx.osdl.net (fw.osdl.org [65.172.181.6]) by smtp.osdl.org (8.12.8/8.12.8) with ESMTP id j2FMMbqi007530 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO); Tue, 15 Mar 2005 14:22:38 -0800 Received: from localhost.localdomain (shell0.pdx.osdl.net [10.9.0.31]) by shell0.pdx.osdl.net (8.13.1/8.11.6) with ESMTP id j2FMMawn016802; Tue, 15 Mar 2005 14:22:36 -0800 Message-Id: <200503152222.j2FMMawn016802@shell0.pdx.osdl.net> Subject: [patch 04/13] e100: NAPI fixes To: davem@davemloft.net Cc: jgarzik@pobox.com, netdev@oss.sgi.com, akpm@osdl.org, linville@tuxdriver.com From: akpm@osdl.org Date: Tue, 15 Mar 2005 14:22:41 -0800 Received-SPF: pass (domain of akpm@osdl.org designates 65.172.181.6 as permitted sender) X-MIMEDefang-Filter: osdl$Revision: 1.105 $ X-Scanned-By: MIMEDefang 2.36 X-Virus-Scanned: ClamAV 0.83/762/Sun Mar 13 15:35:33 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 201 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: akpm@osdl.org Precedence: bulk X-list: netdev Content-Length: 5910 Lines: 197 From: "John W. Linville" Just curious...wanna try this patch I got from Intel? I think it may help... Signed-off-by: Andrew Morton --- 25-akpm/drivers/net/e100.c | 69 +++++++++++++++++++++++++++++++++++++-------- 1 files changed, 57 insertions(+), 12 deletions(-) diff -puN drivers/net/e100.c~e100-napi-fixes drivers/net/e100.c --- 25/drivers/net/e100.c~e100-napi-fixes Tue Mar 15 14:19:53 2005 +++ 25-akpm/drivers/net/e100.c Tue Mar 15 14:19:53 2005 @@ -269,6 +269,12 @@ enum scb_status { rus_mask = 0x3C, }; +enum ru_state { + RU_SUSPENDED = 0, + RU_RUNNING = 1, + RU_UNINITIALIZED = -1, +}; + enum scb_stat_ack { stat_ack_not_ours = 0x00, stat_ack_sw_gen = 0x04, @@ -510,7 +516,7 @@ struct nic { struct rx *rx_to_use; struct rx *rx_to_clean; struct rfd blank_rfd; - int ru_running; + enum ru_state ru_running; spinlock_t cb_lock ____cacheline_aligned; spinlock_t cmd_lock; @@ -1415,12 +1421,18 @@ static int e100_alloc_cbs(struct nic *ni return 0; } -static inline void e100_start_receiver(struct nic *nic) +static inline void e100_start_receiver(struct nic *nic, struct rx *rx) { + if(!nic->rxs) return; + if(RU_SUSPENDED != nic->ru_running) return; + + /* handle init time starts */ + if(!rx) rx = nic->rxs; + /* (Re)start RU if suspended or idle and RFA is non-NULL */ - if(!nic->ru_running && nic->rx_to_clean->skb) { - e100_exec_cmd(nic, ruc_start, nic->rx_to_clean->dma_addr); - nic->ru_running = 1; + if(rx->skb) { + e100_exec_cmd(nic, ruc_start, rx->dma_addr); + nic->ru_running = RU_RUNNING; } } @@ -1471,7 +1483,7 @@ static inline int e100_rx_indicate(struc /* If data isn't ready, nothing to indicate */ if(unlikely(!(rfd_status & cb_complete))) - return -EAGAIN; + return -ENODATA; /* Get actual data size */ actual_size = le16_to_cpu(rfd->actual_size) & 0x3FFF; @@ -1482,6 +1494,10 @@ static inline int e100_rx_indicate(struc pci_unmap_single(nic->pdev, rx->dma_addr, RFD_BUF_LEN, PCI_DMA_FROMDEVICE); + /* this allows for a fast restart without re-enabling interrupts */ + if(le16_to_cpu(rfd->command) & cb_el) + nic->ru_running = RU_SUSPENDED; + /* Pull off the RFD and put the actual data (minus eth hdr) */ skb_reserve(skb, sizeof(struct rfd)); skb_put(skb, actual_size); @@ -1514,20 +1530,45 @@ static inline void e100_rx_clean(struct unsigned int work_to_do) { struct rx *rx; + int restart_required = 0; + struct rx *rx_to_start = NULL; + + /* are we already rnr? then pay attention!!! this ensures that + * the state machine progression never allows a start with a + * partially cleaned list, avoiding a race between hardware + * and rx_to_clean when in NAPI mode */ + if(RU_SUSPENDED == nic->ru_running) + restart_required = 1; /* Indicate newly arrived packets */ for(rx = nic->rx_to_clean; rx->skb; rx = nic->rx_to_clean = rx->next) { - if(e100_rx_indicate(nic, rx, work_done, work_to_do)) + int err = e100_rx_indicate(nic, rx, work_done, work_to_do); + if(-EAGAIN == err) { + /* hit quota so have more work to do, restart once + * cleanup is complete */ + restart_required = 0; + break; + } else if(-ENODATA == err) break; /* No more to clean */ } + /* save our starting point as the place we'll restart the receiver */ + if(restart_required) + rx_to_start = nic->rx_to_clean; + /* Alloc new skbs to refill list */ for(rx = nic->rx_to_use; !rx->skb; rx = nic->rx_to_use = rx->next) { if(unlikely(e100_rx_alloc_skb(nic, rx))) break; /* Better luck next time (see watchdog) */ } - e100_start_receiver(nic); + if(restart_required) { + // ack the rnr? + writeb(stat_ack_rnr, &nic->csr->scb.stat_ack); + e100_start_receiver(nic, rx_to_start); + if(work_done) + (*work_done)++; + } } static void e100_rx_clean_list(struct nic *nic) @@ -1535,6 +1576,8 @@ static void e100_rx_clean_list(struct ni struct rx *rx; unsigned int i, count = nic->params.rfds.count; + nic->ru_running = RU_UNINITIALIZED; + if(nic->rxs) { for(rx = nic->rxs, i = 0; i < count; rx++, i++) { if(rx->skb) { @@ -1548,7 +1591,6 @@ static void e100_rx_clean_list(struct ni } nic->rx_to_use = nic->rx_to_clean = NULL; - nic->ru_running = 0; } static int e100_rx_alloc_list(struct nic *nic) @@ -1557,6 +1599,7 @@ static int e100_rx_alloc_list(struct nic unsigned int i, count = nic->params.rfds.count; nic->rx_to_use = nic->rx_to_clean = NULL; + nic->ru_running = RU_UNINITIALIZED; if(!(nic->rxs = kmalloc(sizeof(struct rx) * count, GFP_ATOMIC))) return -ENOMEM; @@ -1572,6 +1615,7 @@ static int e100_rx_alloc_list(struct nic } nic->rx_to_use = nic->rx_to_clean = nic->rxs; + nic->ru_running = RU_SUSPENDED; return 0; } @@ -1593,7 +1637,7 @@ static irqreturn_t e100_intr(int irq, vo /* We hit Receive No Resource (RNR); restart RU after cleaning */ if(stat_ack & stat_ack_rnr) - nic->ru_running = 0; + nic->ru_running = RU_SUSPENDED; e100_disable_irq(nic); netif_rx_schedule(netdev); @@ -1609,6 +1653,7 @@ static int e100_poll(struct net_device * int tx_cleaned; e100_rx_clean(nic, &work_done, work_to_do); + // should we be quota on tx? tx_cleaned = e100_tx_clean(nic); /* If no Rx and Tx cleanup work was done, exit polling mode. */ @@ -1683,7 +1728,7 @@ static int e100_up(struct nic *nic) if((err = e100_hw_init(nic))) goto err_clean_cbs; e100_set_multicast_list(nic->netdev); - e100_start_receiver(nic); + e100_start_receiver(nic, 0); mod_timer(&nic->watchdog, jiffies); if((err = request_irq(nic->pdev->irq, e100_intr, SA_SHIRQ, nic->netdev->name, nic->netdev))) @@ -1749,7 +1794,7 @@ static int e100_loopback_test(struct nic mdio_write(nic->netdev, nic->mii.phy_id, MII_BMCR, BMCR_LOOPBACK); - e100_start_receiver(nic); + e100_start_receiver(nic, 0); if(!(skb = dev_alloc_skb(ETH_DATA_LEN))) { err = -ENOMEM; _ From akpm@osdl.org Tue Mar 15 14:22:49 2005 Received: with ECARTIS (v1.0.0; list netdev); Tue, 15 Mar 2005 14:23:07 -0800 (PST) Received: from smtp.osdl.org (fire.osdl.org [65.172.181.4]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j2FMMm55009828 for ; Tue, 15 Mar 2005 14:22:48 -0800 Received: from shell0.pdx.osdl.net (fw.osdl.org [65.172.181.6]) by smtp.osdl.org (8.12.8/8.12.8) with ESMTP id j2FMMeqi007547 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO); Tue, 15 Mar 2005 14:22:40 -0800 Received: from localhost.localdomain (shell0.pdx.osdl.net [10.9.0.31]) by shell0.pdx.osdl.net (8.13.1/8.11.6) with ESMTP id j2FMMdgg016811; Tue, 15 Mar 2005 14:22:39 -0800 Message-Id: <200503152222.j2FMMdgg016811@shell0.pdx.osdl.net> Subject: [patch 07/13] fix pci_disable_device in 8139too To: davem@davemloft.net Cc: jgarzik@pobox.com, netdev@oss.sgi.com, akpm@osdl.org, dilinger@debian.org From: akpm@osdl.org Date: Tue, 15 Mar 2005 14:22:44 -0800 Received-SPF: pass (domain of akpm@osdl.org designates 65.172.181.6 as permitted sender) X-MIMEDefang-Filter: osdl$Revision: 1.105 $ X-Scanned-By: MIMEDefang 2.36 X-Virus-Scanned: ClamAV 0.83/762/Sun Mar 13 15:35:33 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 202 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: akpm@osdl.org Precedence: bulk X-list: netdev Content-Length: 2173 Lines: 76 From: Andres Salomon http://linux.bkbits.net:8080/linux-2.6/cset@418391928THbmFKdJ5UCOhnFPMYbOA added an unconditional pci_disable_device() to __rtl8139_cleanup_dev(). That's fine for rtl8139_remove_one and rtl8139_init_one; however, for rtl8139_init_board, it ends up being called in the error path. That is, if pci_enable_device or pci_request_regions fails, err_out calls __rtl8139_cleanup_dev, which calls pci_disable_device. I've attached a patch that should fix it. Not the cleanest thing, but it should work until we have a higher level pci api in place. Andres Salomon Signed-off-by: Andrew Morton --- 25-akpm/drivers/net/8139too.c | 8 ++++++-- 1 files changed, 6 insertions(+), 2 deletions(-) diff -puN drivers/net/8139too.c~fix-pci_disable_device-in-8139too drivers/net/8139too.c --- 25/drivers/net/8139too.c~fix-pci_disable_device-in-8139too Tue Mar 15 14:19:53 2005 +++ 25-akpm/drivers/net/8139too.c Tue Mar 15 14:19:53 2005 @@ -749,7 +749,6 @@ static void __rtl8139_cleanup_dev (struc pci_release_regions (pdev); free_netdev(dev); - pci_disable_device(pdev); pci_set_drvdata (pdev, NULL); } @@ -778,7 +777,7 @@ static int __devinit rtl8139_init_board struct net_device *dev; struct rtl8139_private *tp; u8 tmp8; - int rc; + int rc, disable_dev_on_err = 0; unsigned int i; unsigned long pio_start, pio_end, pio_flags, pio_len; unsigned long mmio_start, mmio_end, mmio_flags, mmio_len; @@ -850,6 +849,7 @@ static int __devinit rtl8139_init_board rc = pci_request_regions (pdev, "8139too"); if (rc) goto err_out; + disable_dev_on_err = 1; /* enable PCI bus-mastering */ pci_set_master (pdev); @@ -935,6 +935,8 @@ match: err_out: __rtl8139_cleanup_dev (dev); + if (disable_dev_on_err) + pci_disable_device (pdev); return rc; } @@ -1112,6 +1114,7 @@ static int __devinit rtl8139_init_one (s err_out: __rtl8139_cleanup_dev (dev); + pci_disable_device (pdev); return i; } @@ -1125,6 +1128,7 @@ static void __devexit rtl8139_remove_one unregister_netdev (dev); __rtl8139_cleanup_dev (dev); + pci_disable_device (pdev); } _ From akpm@osdl.org Tue Mar 15 14:22:49 2005 Received: with ECARTIS (v1.0.0; list netdev); Tue, 15 Mar 2005 14:23:09 -0800 (PST) Received: from smtp.osdl.org (fire.osdl.org [65.172.181.4]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j2FMMnjl009834 for ; Tue, 15 Mar 2005 14:22:49 -0800 Received: from shell0.pdx.osdl.net (fw.osdl.org [65.172.181.6]) by smtp.osdl.org (8.12.8/8.12.8) with ESMTP id j2FMMdqi007539 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO); Tue, 15 Mar 2005 14:22:40 -0800 Received: from localhost.localdomain (shell0.pdx.osdl.net [10.9.0.31]) by shell0.pdx.osdl.net (8.13.1/8.11.6) with ESMTP id j2FMMccq016808; Tue, 15 Mar 2005 14:22:38 -0800 Message-Id: <200503152222.j2FMMccq016808@shell0.pdx.osdl.net> Subject: [patch 06/13] ppc 8260 fcc ethernet driver cannot read LXT971 PHY id To: davem@davemloft.net Cc: jgarzik@pobox.com, netdev@oss.sgi.com, akpm@osdl.org, oray@lucent.com From: akpm@osdl.org Date: Tue, 15 Mar 2005 14:22:43 -0800 Received-SPF: pass (domain of akpm@osdl.org designates 65.172.181.6 as permitted sender) X-MIMEDefang-Filter: osdl$Revision: 1.105 $ X-Scanned-By: MIMEDefang 2.36 X-Virus-Scanned: ClamAV 0.83/762/Sun Mar 13 15:35:33 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 203 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: akpm@osdl.org Precedence: bulk X-list: netdev Content-Length: 7553 Lines: 226 From: "Balasaygun, Oray (Oray)" - fix for Bug 4310 - The fcc_enet.c, as distributed in 2.6.10, does not compile. Evidently the 2.6 kernel no longer supports the schedule_task() and "struct tq_struct" to go with it. Lines 73 through and including 96 of the diffout file show the changes I made to port schedule_task() into tasklet_schedule(). I should have reported this as a bug too but I forgot about it. - customize fcc_enet.c to work with my custom board. These changes are conditional on CONFIG_EON8260 being defined. Signed-off-by: Andrew Morton --- 25-akpm/arch/ppc/8260_io/fcc_enet.c | 91 ++++++++++++++++++++++++++++++------ 1 files changed, 78 insertions(+), 13 deletions(-) diff -puN arch/ppc/8260_io/fcc_enet.c~ppc-8260-fcc-ethernet-driver-cannot-read-lxt971-phy-id arch/ppc/8260_io/fcc_enet.c --- 25/arch/ppc/8260_io/fcc_enet.c~ppc-8260-fcc-ethernet-driver-cannot-read-lxt971-phy-id Tue Mar 15 14:19:53 2005 +++ 25-akpm/arch/ppc/8260_io/fcc_enet.c Tue Mar 15 14:19:53 2005 @@ -177,6 +177,54 @@ static int fcc_enet_set_mac_address(stru #define CMX1_CLK_MASK ((uint)0xff000000) #endif +#ifdef CONFIG_EON8260 + +#define MAKE_BITMASK(n) (1 << (31-n)) + +#define PA8 MAKE_BITMASK(8) +#define PA9 MAKE_BITMASK(9) + +#define PB18 MAKE_BITMASK(18) +#define PB19 MAKE_BITMASK(19) +#define PB20 MAKE_BITMASK(20) +#define PB21 MAKE_BITMASK(21) +#define PB22 MAKE_BITMASK(22) +#define PB23 MAKE_BITMASK(23) +#define PB24 MAKE_BITMASK(24) +#define PB25 MAKE_BITMASK(25) +#define PB26 MAKE_BITMASK(26) +#define PB27 MAKE_BITMASK(27) +#define PB28 MAKE_BITMASK(28) +#define PB29 MAKE_BITMASK(29) +#define PB30 MAKE_BITMASK(30) +#define PB31 MAKE_BITMASK(31) + +#define PB2_TXER PB31 +#define PB2_RXDV PB30 +#define PB2_TXEN PB29 +#define PB2_RXER PB28 +#define PB2_COL PB27 +#define PB2_CRS PB26 +#define PB2_TXDAT (PB22 | PB23 | PB24 | PB25) +#define PB2_RXDAT (PB18 | PB19 | PB20 | PB21) +#define PB2_PSORB0 (PB2_RXDAT | PB2_TXDAT | PB2_CRS | PB2_COL | \ + PB2_RXER | PB2_RXDV | PB2_TXER) +#define PB2_PSORB1 (PB2_TXEN) +#define PB2_DIRB0 (PB2_RXDAT | PB2_CRS | PB2_COL | PB2_RXER | PB2_RXDV) +#define PB2_DIRB1 (PB2_TXDAT | PB2_TXEN | PB2_TXER) + +/* CLK16 (PC16) is receive, CLK15 (PC17) is transmit */ + +#define PC_F2RXCLK ((uint)0x00008000) +#define PC_F2TXCLK ((uint)0x00004000) + +#define CMXFCR_TF2CS_CLK15 0x00060000 /* Transmit FCC2 Clock Source is CLK15 */ +#define CMXFCR_RF2CS_CLK16 0x00380000 /* Receive FCC2 Clock Source is CLK16 */ +#define CMX2_CLK_ROUTE (CMXFCR_RF2CS_CLK16 | CMXFCR_TF2CS_CLK15) +#define CMX2_CLK_MASK ((uint)0x00ff0000) + +#else /* #ifdef CONFIG_EON8260 */ + /* I/O Pin assignment for FCC2. I don't yet know the best way to do this, * but there is little variation among the choices. */ @@ -208,6 +256,8 @@ static int fcc_enet_set_mac_address(stru #define CMX2_CLK_MASK ((uint)0x00ff0000) #endif +#endif /* #ifdef CONFIG_EON8260 */ + /* I/O Pin assignment for FCC3. I don't yet know the best way to do this, * but there is little variation among the choices. */ @@ -234,7 +284,11 @@ static int fcc_enet_set_mac_address(stru /* MII status/control serial interface. */ -#ifdef CONFIG_TQM8260 +#if defined (CONFIG_EON8260) +/* EON8260 has MDIO and MDCK on PC31 and PC30 respectively */ +#define PC_MDIO ((uint)0x00000001) +#define PC_MDCK ((uint)0x00000002) +#elif defined (CONFIG_TQM8260) /* TQM8260 has MDIO and MDCK on PC30 and PC31 respectively */ #define PC_MDIO ((uint)0x00000002) #define PC_MDCK ((uint)0x00000001) @@ -268,7 +322,7 @@ static fcc_info_t fcc_ports[] = { #ifdef CONFIG_FCC1_ENET { 0, CPM_CR_FCC1_SBLOCK, CPM_CR_FCC1_PAGE, PROFF_FCC1, SIU_INT_FCC1, (PC_F1RXCLK | PC_F1TXCLK), CMX1_CLK_ROUTE, CMX1_CLK_MASK, -# if defined(CONFIG_TQM8260) || defined(CONFIG_ADS8272) +# if defined(CONFIG_TQM8260) || defined(CONFIG_ADS8272) || defined(CONFIG_EON8260) PC_MDIO, PC_MDCK }, # else 0x00000004, 0x00000100 }, @@ -277,7 +331,7 @@ static fcc_info_t fcc_ports[] = { #ifdef CONFIG_FCC2_ENET { 1, CPM_CR_FCC2_SBLOCK, CPM_CR_FCC2_PAGE, PROFF_FCC2, SIU_INT_FCC2, (PC_F2RXCLK | PC_F2TXCLK), CMX2_CLK_ROUTE, CMX2_CLK_MASK, -# if defined(CONFIG_TQM8260) || defined(CONFIG_ADS8272) +# if defined(CONFIG_TQM8260) || defined(CONFIG_ADS8272) || defined(CONFIG_EON8260) PC_MDIO, PC_MDCK }, # elif defined(CONFIG_EST8260) || defined(CONFIG_ADS8260) 0x00400000, 0x00200000 }, @@ -288,7 +342,7 @@ static fcc_info_t fcc_ports[] = { #ifdef CONFIG_FCC3_ENET { 2, CPM_CR_FCC3_SBLOCK, CPM_CR_FCC3_PAGE, PROFF_FCC3, SIU_INT_FCC3, (PC_F3RXCLK | PC_F3TXCLK), CMX3_CLK_ROUTE, CMX3_CLK_MASK, -# if defined(CONFIG_TQM8260) || defined(CONFIG_ADS8272) +# if defined(CONFIG_TQM8260) || defined(CONFIG_ADS8272) || defined(CONFIG_EON8260) PC_MDIO, PC_MDCK }, # else 0x00000001, 0x00000040 }, @@ -329,7 +383,7 @@ struct fcc_enet_private { uint phy_id_done; uint phy_status; phy_info_t *phy; - struct tq_struct phy_task; + struct tasklet_struct phy_task; uint sequence_done; @@ -1191,8 +1245,9 @@ static void mii_display_status(struct ne printk(".\n"); } -static void mii_display_config(struct net_device *dev) +static void mii_display_config(unsigned long arg) { + struct net_device *dev = (struct net_device *)arg; volatile struct fcc_enet_private *fep = dev->priv; uint s = fep->phy_status; @@ -1222,8 +1277,9 @@ static void mii_display_config(struct ne fep->sequence_done = 1; } -static void mii_relink(struct net_device *dev) +static void mii_relink(unsigned long arg) { + struct net_device *dev = (struct net_device *)arg; struct fcc_enet_private *fep = dev->priv; int duplex; @@ -1246,18 +1302,18 @@ static void mii_queue_relink(uint mii_re { struct fcc_enet_private *fep = dev->priv; - fep->phy_task.routine = (void *)mii_relink; + fep->phy_task.func = mii_relink; fep->phy_task.data = dev; - schedule_task(&fep->phy_task); + tasklet_schedule(&fep->phy_task); } static void mii_queue_config(uint mii_reg, struct net_device *dev) { struct fcc_enet_private *fep = dev->priv; - fep->phy_task.routine = (void *)mii_display_config; + fep->phy_task.func = mii_display_config; fep->phy_task.data = dev; - schedule_task(&fep->phy_task); + tasklet_schedule(&fep->phy_task); } @@ -1464,6 +1520,9 @@ static int __init fec_enet_init(void) return -ENOMEM; cep = dev->priv; + cep->phy_task.next = NULL; + cep->phy_task.state = 0; + cep->phy_task.count.counter = 0; spin_lock_init(&cep->lock); cep->fip = fip; @@ -1698,6 +1757,11 @@ init_fcc_param(fcc_info_t *fip, struct n * non-static part of the address. */ eap = (unsigned char *)&(ep->fen_paddrh); +#if defined(CONFIG_EON8260) + for (i = 5; i >=0 ; i--) { + *eap++ = dev->dev_addr[i] = bd->bi_enetaddr[i]; + } +#else /* if defined(CONFIG_EON8260) */ for (i=5; i>=0; i--) { #ifdef CONFIG_SBC82xx if (i == 5) { @@ -1718,6 +1782,7 @@ init_fcc_param(fcc_info_t *fip, struct n *eap++ = dev->dev_addr[i] = bd->bi_enetaddr[i]; } } +#endif /* if defined(CONFIG_EON8260) */ ep->fen_taddrh = 0; ep->fen_taddrm = 0; @@ -1940,10 +2005,10 @@ mii_send_receive(fcc_info_t *fip, uint c { FCC_PDATC_MDC(1); retval <<= 1; - if (io->iop_pdatc & fip->fc_mdio) - retval++; udelay(1); FCC_PDATC_MDC(0); + if (io->iop_pdatc & fip->fc_mdio) + retval++; udelay(1); } } _ From akpm@osdl.org Tue Mar 15 14:22:50 2005 Received: with ECARTIS (v1.0.0; list netdev); Tue, 15 Mar 2005 14:23:12 -0800 (PST) Received: from smtp.osdl.org (fire.osdl.org [65.172.181.4]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j2FMMoDf009847 for ; Tue, 15 Mar 2005 14:22:50 -0800 Received: from shell0.pdx.osdl.net (fw.osdl.org [65.172.181.6]) by smtp.osdl.org (8.12.8/8.12.8) with ESMTP id j2FMMZqi007522 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO); Tue, 15 Mar 2005 14:22:36 -0800 Received: from localhost.localdomain (shell0.pdx.osdl.net [10.9.0.31]) by shell0.pdx.osdl.net (8.13.1/8.11.6) with ESMTP id j2FMMY7e016796; Tue, 15 Mar 2005 14:22:34 -0800 Message-Id: <200503152222.j2FMMY7e016796@shell0.pdx.osdl.net> Subject: [patch 02/13] ENI155P error handling fix To: davem@davemloft.net Cc: jgarzik@pobox.com, netdev@oss.sgi.com, akpm@osdl.org, takis@lumumba.luc.ac.be From: akpm@osdl.org Date: Tue, 15 Mar 2005 14:22:39 -0800 Received-SPF: pass (domain of akpm@osdl.org designates 65.172.181.6 as permitted sender) X-MIMEDefang-Filter: osdl$Revision: 1.105 $ X-Scanned-By: MIMEDefang 2.36 X-Virus-Scanned: ClamAV 0.83/762/Sun Mar 13 15:35:33 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 205 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: akpm@osdl.org Precedence: bulk X-list: netdev Content-Length: 2894 Lines: 94 From: Panagiotis Issaris In the ENI155P device driver in six possible failure cases the requested irq is not being released. In three of the above possible failure cases additionally there seems to be a memory leak. Signed-off-by: Andrew Morton --- 25-akpm/drivers/atm/eni.c | 27 ++++++++++++++++++--------- 1 files changed, 18 insertions(+), 9 deletions(-) diff -puN drivers/atm/eni.c~eni155p-error-handling-fix drivers/atm/eni.c --- 25/drivers/atm/eni.c~eni155p-error-handling-fix Tue Mar 15 14:19:52 2005 +++ 25-akpm/drivers/atm/eni.c Tue Mar 15 14:19:52 2005 @@ -59,7 +59,6 @@ * - doesn't support OAM cells * - eni_put_free may hang if not putting memory fragments that _complete_ * 2^n block (never happens in real life, though) - * - keeps IRQ even if initialization fails */ @@ -1802,22 +1801,22 @@ static int __devinit eni_start(struct at if (request_irq(eni_dev->irq,&eni_int,SA_SHIRQ,DEV_LABEL,dev)) { printk(KERN_ERR DEV_LABEL "(itf %d): IRQ%d is already in use\n", dev->number,eni_dev->irq); - return -EAGAIN; + error = -EAGAIN; + goto out; } - /* @@@ should release IRQ on error */ pci_set_master(eni_dev->pci_dev); if ((error = pci_write_config_word(eni_dev->pci_dev,PCI_COMMAND, PCI_COMMAND_MEMORY | PCI_COMMAND_MASTER | (eni_dev->asic ? PCI_COMMAND_PARITY | PCI_COMMAND_SERR : 0)))) { printk(KERN_ERR DEV_LABEL "(itf %d): can't enable memory+" "master (0x%02x)\n",dev->number,error); - return error; + goto free_irq; } if ((error = pci_write_config_byte(eni_dev->pci_dev,PCI_TONGA_CTRL, END_SWAP_DMA))) { printk(KERN_ERR DEV_LABEL "(itf %d): can't set endian swap " "(0x%02x)\n",dev->number,error); - return error; + goto free_irq; } /* determine addresses of internal tables */ eni_dev->vci = eni_dev->ram; @@ -1839,7 +1838,8 @@ static int __devinit eni_start(struct at if (!eni_dev->free_list) { printk(KERN_ERR DEV_LABEL "(itf %d): couldn't get free page\n", dev->number); - return -ENOMEM; + error = -ENOMEM; + goto free_irq; } eni_dev->free_len = 0; eni_put_free(eni_dev,buf,buffer_mem); @@ -1855,17 +1855,26 @@ static int __devinit eni_start(struct at */ eni_out(0xffffffff,MID_IE); error = start_tx(dev); - if (error) return error; + if (error) goto free_list; error = start_rx(dev); - if (error) return error; + if (error) goto free_list; error = dev->phy->start(dev); - if (error) return error; + if (error) goto free_list; eni_out(eni_in(MID_MC_S) | (1 << MID_INT_SEL_SHIFT) | MID_TX_LOCK_MODE | MID_DMA_ENABLE | MID_TX_ENABLE | MID_RX_ENABLE, MID_MC_S); /* Tonga uses SBus INTReq1 */ (void) eni_in(MID_ISA); /* clear Midway interrupts */ return 0; + +free_list: + kfree(eni_dev->free_list); + +free_irq: + free_irq(eni_dev->irq, eni_dev); + +out: + return error; } _ From akpm@osdl.org Tue Mar 15 14:22:55 2005 Received: with ECARTIS (v1.0.0; list netdev); Tue, 15 Mar 2005 14:23:11 -0800 (PST) Received: from smtp.osdl.org (fire.osdl.org [65.172.181.4]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j2FMMsk8009904 for ; Tue, 15 Mar 2005 14:22:54 -0800 Received: from shell0.pdx.osdl.net (fw.osdl.org [65.172.181.6]) by smtp.osdl.org (8.12.8/8.12.8) with ESMTP id j2FMMiqi007577 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO); Tue, 15 Mar 2005 14:22:45 -0800 Received: from localhost.localdomain (shell0.pdx.osdl.net [10.9.0.31]) by shell0.pdx.osdl.net (8.13.1/8.11.6) with ESMTP id j2FMMiLB016826; Tue, 15 Mar 2005 14:22:44 -0800 Message-Id: <200503152222.j2FMMiLB016826@shell0.pdx.osdl.net> Subject: [patch 12/13] pcnet32 79C975 fiber fix To: davem@davemloft.net Cc: jgarzik@pobox.com, netdev@oss.sgi.com, akpm@osdl.org, steven.hardy@astrium.eads.net From: akpm@osdl.org Date: Tue, 15 Mar 2005 14:22:48 -0800 Received-SPF: pass (domain of akpm@osdl.org designates 65.172.181.6 as permitted sender) X-MIMEDefang-Filter: osdl$Revision: 1.105 $ X-Scanned-By: MIMEDefang 2.36 X-Virus-Scanned: ClamAV 0.83/762/Sun Mar 13 15:35:33 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 204 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: akpm@osdl.org Precedence: bulk X-list: netdev Content-Length: 1246 Lines: 33 From: "HARDY, Steven" I have found a bug in the pcnet32 driver (drivers/net/pcnet32.c) affecting all ethernet cards based on the AMD79C975 chip, using the fiber interface. It's a one line fix, where some config registers get corrupted during initialisation (which stops the Fiber interface working with this chip) This bug was introduced somewhere betweeen 2.4.17 and 2.6.x (noticed whilst upgrading to 2.6), and it may affect other chips too. I have checked all versions up to 2.6.11-bk6 and they are all broken. Signed-off-by: Andrew Morton --- 25-akpm/drivers/net/pcnet32.c | 3 ++- 1 files changed, 2 insertions(+), 1 deletion(-) diff -puN drivers/net/pcnet32.c~pcnet32-bug-79c975-fiber-fix drivers/net/pcnet32.c --- 25/drivers/net/pcnet32.c~pcnet32-bug-79c975-fiber-fix Tue Mar 15 14:19:55 2005 +++ 25-akpm/drivers/net/pcnet32.c Tue Mar 15 14:19:55 2005 @@ -1351,7 +1351,8 @@ pcnet32_probe1(unsigned long ioaddr, int printk(KERN_INFO "%s: registered as %s\n", dev->name, lp->name); cards_found++; - a->write_bcr(ioaddr, 2, 0x1002); /* enable LED writes */ + /* enable LED writes */ + a->write_bcr(ioaddr, 2, a->read_bcr(ioaddr, 2) | 0x1002); return 0; _ From akpm@osdl.org Tue Mar 15 14:22:57 2005 Received: with ECARTIS (v1.0.0; list netdev); Tue, 15 Mar 2005 14:23:13 -0800 (PST) Received: from smtp.osdl.org (fire.osdl.org [65.172.181.4]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j2FMMvpI009937 for ; Tue, 15 Mar 2005 14:22:57 -0800 Received: from shell0.pdx.osdl.net (fw.osdl.org [65.172.181.6]) by smtp.osdl.org (8.12.8/8.12.8) with ESMTP id j2FMMfqi007557 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO); Tue, 15 Mar 2005 14:22:41 -0800 Received: from localhost.localdomain (shell0.pdx.osdl.net [10.9.0.31]) by shell0.pdx.osdl.net (8.13.1/8.11.6) with ESMTP id j2FMMfU6016817; Tue, 15 Mar 2005 14:22:41 -0800 Message-Id: <200503152222.j2FMMfU6016817@shell0.pdx.osdl.net> Subject: [patch 09/13] bonding needs inet To: davem@davemloft.net Cc: jgarzik@pobox.com, netdev@oss.sgi.com, akpm@osdl.org From: akpm@osdl.org Date: Tue, 15 Mar 2005 14:22:46 -0800 Received-SPF: pass (domain of akpm@osdl.org designates 65.172.181.6 as permitted sender) X-MIMEDefang-Filter: osdl$Revision: 1.105 $ X-Scanned-By: MIMEDefang 2.36 X-Virus-Scanned: ClamAV 0.83/762/Sun Mar 13 15:35:33 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 206 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: akpm@osdl.org Precedence: bulk X-list: netdev Content-Length: 675 Lines: 22 The bonding driver needs CONFIG_INET, for arp_create(), arp_send(), arp_xmit(). Signed-off-by: Andrew Morton --- 25-akpm/drivers/net/Kconfig | 1 + 1 files changed, 1 insertion(+) diff -puN drivers/net/Kconfig~bonding-needs-inet drivers/net/Kconfig --- 25/drivers/net/Kconfig~bonding-needs-inet Tue Mar 15 14:19:54 2005 +++ 25-akpm/drivers/net/Kconfig Tue Mar 15 14:19:54 2005 @@ -44,6 +44,7 @@ config DUMMY config BONDING tristate "Bonding driver support" depends on NETDEVICES + depends on INET ---help--- Say 'Y' or 'M' if you wish to be able to 'bond' multiple Ethernet Channels together. This is called 'Etherchannel' by Cisco, _ From akpm@osdl.org Tue Mar 15 14:23:03 2005 Received: with ECARTIS (v1.0.0; list netdev); Tue, 15 Mar 2005 14:23:18 -0800 (PST) Received: from smtp.osdl.org (fire.osdl.org [65.172.181.4]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j2FMN3Gr010003 for ; Tue, 15 Mar 2005 14:23:03 -0800 Received: from shell0.pdx.osdl.net (fw.osdl.org [65.172.181.6]) by smtp.osdl.org (8.12.8/8.12.8) with ESMTP id j2FMMcqi007536 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO); Tue, 15 Mar 2005 14:22:39 -0800 Received: from localhost.localdomain (shell0.pdx.osdl.net [10.9.0.31]) by shell0.pdx.osdl.net (8.13.1/8.11.6) with ESMTP id j2FMMbhG016805; Tue, 15 Mar 2005 14:22:37 -0800 Message-Id: <200503152222.j2FMMbhG016805@shell0.pdx.osdl.net> Subject: [patch 05/13] remove last_rx update from loopback device To: davem@davemloft.net Cc: jgarzik@pobox.com, netdev@oss.sgi.com, akpm@osdl.org, christoph@graphe.net, nirajk@calsoftinc.com, christoph@lameter.com, Shai@Scalex86.org From: akpm@osdl.org Date: Tue, 15 Mar 2005 14:22:42 -0800 Received-SPF: pass (domain of akpm@osdl.org designates 65.172.181.6 as permitted sender) X-MIMEDefang-Filter: osdl$Revision: 1.105 $ X-Scanned-By: MIMEDefang 2.36 X-Virus-Scanned: ClamAV 0.83/762/Sun Mar 13 15:35:33 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 208 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: akpm@osdl.org Precedence: bulk X-list: netdev Content-Length: 1257 Lines: 34 From: Christoph Lameter The last_rx field in the loopback driver is updated on every xmit but is not used otherwise. Accesses to ->last_rx cause unecessary traffic on the interlink for NUMA systems which limits the performance of the loopback device. The comment given at include/linux/netdevice.h says that last_rx may be used for future network-power-down code, which is likely not relevant for the loopback device (please let me know if it is otherwise ..). Signed-off-by: Niraj Kumar Signed-off-by: Christoph Lameter Signed-off-by: Shai Fultheim Signed-off-by: Andrew Morton --- 25-akpm/drivers/net/loopback.c | 2 -- 1 files changed, 2 deletions(-) diff -puN drivers/net/loopback.c~remove-last_rx-update-from-loopback-device drivers/net/loopback.c --- 25/drivers/net/loopback.c~remove-last_rx-update-from-loopback-device Tue Mar 15 14:19:53 2005 +++ 25-akpm/drivers/net/loopback.c Tue Mar 15 14:19:53 2005 @@ -144,8 +144,6 @@ static int loopback_xmit(struct sk_buff return 0; } - dev->last_rx = jiffies; - lb_stats = &per_cpu(loopback_stats, get_cpu()); lb_stats->rx_bytes += skb->len; lb_stats->tx_bytes += skb->len; _ From akpm@osdl.org Tue Mar 15 14:22:59 2005 Received: with ECARTIS (v1.0.0; list netdev); Tue, 15 Mar 2005 14:23:15 -0800 (PST) Received: from smtp.osdl.org (fire.osdl.org [65.172.181.4]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j2FMMxwn009960 for ; Tue, 15 Mar 2005 14:22:59 -0800 Received: from shell0.pdx.osdl.net (fw.osdl.org [65.172.181.6]) by smtp.osdl.org (8.12.8/8.12.8) with ESMTP id j2FMMhqi007567 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO); Tue, 15 Mar 2005 14:22:43 -0800 Received: from localhost.localdomain (shell0.pdx.osdl.net [10.9.0.31]) by shell0.pdx.osdl.net (8.13.1/8.11.6) with ESMTP id j2FMMhMp016823; Tue, 15 Mar 2005 14:22:43 -0800 Message-Id: <200503152222.j2FMMhMp016823@shell0.pdx.osdl.net> Subject: [patch 11/13] Fix suspend/resume on via-velocity To: davem@davemloft.net Cc: jgarzik@pobox.com, netdev@oss.sgi.com, akpm@osdl.org, pavel@ucw.cz, pavel@suse.cz From: akpm@osdl.org Date: Tue, 15 Mar 2005 14:22:48 -0800 Received-SPF: pass (domain of akpm@osdl.org designates 65.172.181.6 as permitted sender) X-MIMEDefang-Filter: osdl$Revision: 1.105 $ X-Scanned-By: MIMEDefang 2.36 X-Virus-Scanned: ClamAV 0.83/762/Sun Mar 13 15:35:33 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 207 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: akpm@osdl.org Precedence: bulk X-list: netdev Content-Length: 1331 Lines: 38 From: Pavel Machek This fixes suspend-resume on via-velocity. It was confused w.r.t. pointers... Now uses netdev_priv(). [Well, someone should run sed over that driver, there are many more dev->priv]. Signed-off-by: Pavel Machek Signed-off-by: Andrew Morton --- 25-akpm/drivers/net/via-velocity.c | 6 ++++-- 1 files changed, 4 insertions(+), 2 deletions(-) diff -puN drivers/net/via-velocity.c~fix-suspend-resume-on-via-velocity drivers/net/via-velocity.c --- 25/drivers/net/via-velocity.c~fix-suspend-resume-on-via-velocity Tue Mar 15 14:19:55 2005 +++ 25-akpm/drivers/net/via-velocity.c Tue Mar 15 14:19:55 2005 @@ -3212,7 +3212,8 @@ static int velocity_set_wol(struct veloc static int velocity_suspend(struct pci_dev *pdev, pm_message_t state) { - struct velocity_info *vptr = pci_get_drvdata(pdev); + struct net_device *dev = pci_get_drvdata(pdev); + struct velocity_info *vptr = netdev_priv(dev); unsigned long flags; if(!netif_running(vptr->dev)) @@ -3245,7 +3246,8 @@ static int velocity_suspend(struct pci_d static int velocity_resume(struct pci_dev *pdev) { - struct velocity_info *vptr = pci_get_drvdata(pdev); + struct net_device *dev = pci_get_drvdata(pdev); + struct velocity_info *vptr = netdev_priv(dev); unsigned long flags; int i; _ From akpm@osdl.org Tue Mar 15 14:23:11 2005 Received: with ECARTIS (v1.0.0; list netdev); Tue, 15 Mar 2005 14:23:21 -0800 (PST) Received: from smtp.osdl.org (fire.osdl.org [65.172.181.4]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j2FMNANW010078 for ; Tue, 15 Mar 2005 14:23:10 -0800 Received: from shell0.pdx.osdl.net (fw.osdl.org [65.172.181.6]) by smtp.osdl.org (8.12.8/8.12.8) with ESMTP id j2FMMgqi007561 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO); Tue, 15 Mar 2005 14:22:43 -0800 Received: from localhost.localdomain (shell0.pdx.osdl.net [10.9.0.31]) by shell0.pdx.osdl.net (8.13.1/8.11.6) with ESMTP id j2FMMfEI016820; Tue, 15 Mar 2005 14:22:42 -0800 Message-Id: <200503152222.j2FMMfEI016820@shell0.pdx.osdl.net> Subject: [patch 10/13] drivers/net/sis900.c: fix a warning To: davem@davemloft.net Cc: jgarzik@pobox.com, netdev@oss.sgi.com, akpm@osdl.org, bunk@stusta.de From: akpm@osdl.org Date: Tue, 15 Mar 2005 14:22:46 -0800 Received-SPF: pass (domain of akpm@osdl.org designates 65.172.181.6 as permitted sender) X-MIMEDefang-Filter: osdl$Revision: 1.105 $ X-Scanned-By: MIMEDefang 2.36 X-Virus-Scanned: ClamAV 0.83/762/Sun Mar 13 15:35:33 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 209 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: akpm@osdl.org Precedence: bulk X-list: netdev Content-Length: 1034 Lines: 26 From: Adrian Bunk drivers/net/sis900.c:199: warning: 'sis900_poll' declared `static' but never defined Signed-off-by: Adrian Bunk Signed-off-by: Andrew Morton --- 25-akpm/drivers/net/sis900.c | 2 ++ 1 files changed, 2 insertions(+) diff -puN drivers/net/sis900.c~drivers-net-sis900c-fix-a-warning drivers/net/sis900.c --- 25/drivers/net/sis900.c~drivers-net-sis900c-fix-a-warning Tue Mar 15 14:19:54 2005 +++ 25-akpm/drivers/net/sis900.c Tue Mar 15 14:19:54 2005 @@ -196,7 +196,9 @@ MODULE_PARM_DESC(multicast_filter_limit, MODULE_PARM_DESC(max_interrupt_work, "SiS 900/7016 maximum events handled per interrupt"); MODULE_PARM_DESC(sis900_debug, "SiS 900/7016 bitmapped debugging message level"); +#ifdef CONFIG_NET_POLL_CONTROLLER static void sis900_poll(struct net_device *dev); +#endif static int sis900_open(struct net_device *net_dev); static int sis900_mii_probe (struct net_device * net_dev); static void sis900_init_rxfilter (struct net_device * net_dev); _ From akpm@osdl.org Tue Mar 15 14:23:31 2005 Received: with ECARTIS (v1.0.0; list netdev); Tue, 15 Mar 2005 14:23:39 -0800 (PST) Received: from smtp.osdl.org (fire.osdl.org [65.172.181.4]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j2FMNUTl010374 for ; Tue, 15 Mar 2005 14:23:30 -0800 Received: from shell0.pdx.osdl.net (fw.osdl.org [65.172.181.6]) by smtp.osdl.org (8.12.8/8.12.8) with ESMTP id j2FMMfqi007552 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO); Tue, 15 Mar 2005 14:22:41 -0800 Received: from localhost.localdomain (shell0.pdx.osdl.net [10.9.0.31]) by shell0.pdx.osdl.net (8.13.1/8.11.6) with ESMTP id j2FMMeT6016814; Tue, 15 Mar 2005 14:22:40 -0800 Message-Id: <200503152222.j2FMMeT6016814@shell0.pdx.osdl.net> Subject: [patch 08/13] Log full of "ing_filter: fixed ippp2 out ippp2" To: davem@davemloft.net Cc: jgarzik@pobox.com, netdev@oss.sgi.com, akpm@osdl.org, hadi@cyberus.ca From: akpm@osdl.org Date: Tue, 15 Mar 2005 14:22:45 -0800 Received-SPF: pass (domain of akpm@osdl.org designates 65.172.181.6 as permitted sender) X-MIMEDefang-Filter: osdl$Revision: 1.105 $ X-Scanned-By: MIMEDefang 2.36 X-Virus-Scanned: ClamAV 0.83/762/Sun Mar 13 15:35:33 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 211 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: akpm@osdl.org Precedence: bulk X-list: netdev Content-Length: 1276 Lines: 35 From: jamal Signed-off-by: Andrew Morton --- 25-akpm/drivers/isdn/i4l/isdn_net.c | 1 + 25-akpm/drivers/isdn/i4l/isdn_ppp.c | 1 + 2 files changed, 2 insertions(+) diff -puN drivers/isdn/i4l/isdn_net.c~log-full-of-ing_filter-fixed-ippp2-out-ippp2 drivers/isdn/i4l/isdn_net.c --- 25/drivers/isdn/i4l/isdn_net.c~log-full-of-ing_filter-fixed-ippp2-out-ippp2 Tue Mar 15 14:19:53 2005 +++ 25-akpm/drivers/isdn/i4l/isdn_net.c Tue Mar 15 14:19:53 2005 @@ -1786,6 +1786,7 @@ isdn_net_receive(struct net_device *ndev lp->stats.rx_bytes += skb->len; } skb->dev = ndev; + skb->input_dev = ndev; skb->pkt_type = PACKET_HOST; skb->mac.raw = skb->data; #ifdef ISDN_DEBUG_NET_DUMP diff -puN drivers/isdn/i4l/isdn_ppp.c~log-full-of-ing_filter-fixed-ippp2-out-ippp2 drivers/isdn/i4l/isdn_ppp.c --- 25/drivers/isdn/i4l/isdn_ppp.c~log-full-of-ing_filter-fixed-ippp2-out-ippp2 Tue Mar 15 14:19:53 2005 +++ 25-akpm/drivers/isdn/i4l/isdn_ppp.c Tue Mar 15 14:19:53 2005 @@ -1177,6 +1177,7 @@ isdn_ppp_push_higher(isdn_net_dev * net_ mlp->huptimer = 0; #endif /* CONFIG_IPPP_FILTER */ skb->dev = dev; + skb->input_dev = dev; skb->mac.raw = skb->data; netif_rx(skb); /* net_dev->local->stats.rx_packets++; done in isdn_net.c */ _ From akpm@osdl.org Tue Mar 15 14:23:12 2005 Received: with ECARTIS (v1.0.0; list netdev); Tue, 15 Mar 2005 14:23:37 -0800 (PST) Received: from smtp.osdl.org (fire.osdl.org [65.172.181.4]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j2FMNAOW010083 for ; Tue, 15 Mar 2005 14:23:11 -0800 Received: from shell0.pdx.osdl.net (fw.osdl.org [65.172.181.6]) by smtp.osdl.org (8.12.8/8.12.8) with ESMTP id j2FMMaqi007526 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO); Tue, 15 Mar 2005 14:22:36 -0800 Received: from localhost.localdomain (shell0.pdx.osdl.net [10.9.0.31]) by shell0.pdx.osdl.net (8.13.1/8.11.6) with ESMTP id j2FMMZ1i016799; Tue, 15 Mar 2005 14:22:36 -0800 Message-Id: <200503152222.j2FMMZ1i016799@shell0.pdx.osdl.net> Subject: [patch 03/13] drivers/net/myri_code.h cleanup To: davem@davemloft.net Cc: jgarzik@pobox.com, netdev@oss.sgi.com, akpm@osdl.org, domen@coderock.org From: akpm@osdl.org Date: Tue, 15 Mar 2005 14:22:40 -0800 Received-SPF: pass (domain of akpm@osdl.org designates 65.172.181.6 as permitted sender) X-MIMEDefang-Filter: osdl$Revision: 1.105 $ X-Scanned-By: MIMEDefang 2.36 X-Virus-Scanned: ClamAV 0.83/762/Sun Mar 13 15:35:33 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 210 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: akpm@osdl.org Precedence: bulk X-list: netdev Content-Length: 116154 Lines: 1314 From: Domen Puncer Replace static unsigned char lanai4_data[20472] __initdata = { } with static unsigned char lanai4_data[20472] __initdata = { }; Signed-off-by: Domen Puncer Signed-off-by: Andrew Morton --- 25-akpm/drivers/net/myri_code.h | 1283 ---------------------------------------- 1 files changed, 1 insertion(+), 1282 deletions(-) diff -puN drivers/net/myri_code.h~drivers-net-myri_codeh-cleanup drivers/net/myri_code.h --- 25/drivers/net/myri_code.h~drivers-net-myri_codeh-cleanup Tue Mar 15 14:19:52 2005 +++ 25-akpm/drivers/net/myri_code.h Tue Mar 15 14:19:52 2005 @@ -4775,1288 +4775,7 @@ static unsigned char lanai4_code[76256] /* This is the LANai data */ static unsigned int lanai4_data_off = 0x94F0; /* half-word offset */ -static unsigned char lanai4_data[20472] __initdata = { -0x00,0x00, -0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, -0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, -0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, -0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, -0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, -0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, -0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, -0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, -0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, -0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, -0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, -0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, -0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, -0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, -0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, -0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, -0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, -0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, -0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, -0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, -0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, -0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, -0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, -0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, -0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, -0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, -0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, -0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, -0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, -0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, -0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, -0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, -0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, -0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, -0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, -0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, -0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, -0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, -0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, -0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, -0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, -0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, -0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, -0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, -0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, -0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, -0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, -0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, -0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, -0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, -0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, -0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, -0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, -0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, -0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, -0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, -0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, -0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, -0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, -0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, -0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, -0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, -0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, -0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, -0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, -0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, -0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, -0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, -0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, -0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, -0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, -0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, -0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, -0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, -0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, -0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, -0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, -0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, -0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, -0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, -0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, -0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, -0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, -0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, -0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, -0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, -0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, -0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, -0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, -0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, -0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, -0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, -0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, -0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, -0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, -0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, -0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, -0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, -0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, -0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, -0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, -0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, -0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, -0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, -0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, -0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, -0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, -0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, -0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, -0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, -0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, -0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, -0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, -0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, -0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, -0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, -0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, -0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, -0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, -0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, -0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, -0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, -0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, -0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, -0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, -0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, -0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, -0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, -0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, -0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, -0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, -0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, -0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, -0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, -0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, -0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, -0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, -0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, -0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, -0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, -0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, -0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, -0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, -0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, -0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, -0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, -0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, -0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, -0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, -0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, -0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, -0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, -0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, -0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, -0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, -0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, -0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, -0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, -0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, -0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, -0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, -0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, -0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, -0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, -0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, -0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, -0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, -0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, -0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, -0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, -0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, -0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, -0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, -0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, -0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, -0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, -0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, -0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, -0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, -0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, -0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, -0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, -0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, -0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, -0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, -0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, -0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, -0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, -0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, -0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, -0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, -0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, -0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, -0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, -0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, -0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, -0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, -0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, -0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, -0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, -0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, -0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, -0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, -0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, -0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, -0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, -0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, -0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, -0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, -0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, -0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, -0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, -0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, -0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, -0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, -0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, -0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, -0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, -0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, -0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, -0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, -0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, -0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, -0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, -0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, -0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, -0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, -0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, -0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, -0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, -0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, -0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, -0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, -0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, -0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, -0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, -0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, -0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, -0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, -0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, -0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, -0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, -0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, -0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, -0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, -0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, -0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, -0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, -0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, -0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, -0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, -0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, -0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, -0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, -0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, -0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, -0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, -0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, -0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, -0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, -0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, -0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, -0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, -0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, -0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, -0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, -0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, -0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, -0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, -0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, -0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, -0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, -0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, -0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, -0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, -0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, -0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, -0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, -0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, -0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, -0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, -0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, -0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, -0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, -0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, -0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, -0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, -0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, -0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, -0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, -0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, -0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, -0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, -0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, -0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, -0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, -0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, -0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, -0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, -0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, -0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, -0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, -0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, -0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, -0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, -0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, -0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, -0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, -0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, -0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, -0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, -0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, -0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, -0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, -0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, -0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, -0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, -0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, -0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, -0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, -0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, -0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, -0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, -0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, -0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, -0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, -0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, -0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, -0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, -0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, -0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, -0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, -0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, -0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, -0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, -0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, -0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, -0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, -0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, -0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, -0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, -0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, -0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, -0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, -0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, -0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, -0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, -0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, -0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, -0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, -0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, -0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, -0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, -0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, -0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, -0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, -0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, -0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, -0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, -0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, -0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, -0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, -0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, -0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, -0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, -0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, -0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, -0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, -0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, -0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, -0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, -0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, -0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, -0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, -0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, -0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, -0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, -0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, -0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, -0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, -0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, -0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, -0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, -0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, -0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, -0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, -0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, -0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, -0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, -0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, -0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, -0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, -0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, -0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, -0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, -0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, -0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, -0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, -0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, -0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, -0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, -0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, -0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, -0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, -0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, -0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, -0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, -0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, -0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, -0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, -0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, -0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, -0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, -0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, -0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, -0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, -0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, -0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, -0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, -0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, -0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, -0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, -0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, -0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, -0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, -0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, -0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, -0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, -0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, -0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, -0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, -0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, -0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, -0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, -0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, -0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, -0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, -0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, -0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, -0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, -0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, -0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, -0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, -0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, -0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, -0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, -0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, -0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, -0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, -0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, -0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, -0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, -0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, -0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, -0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, -0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, -0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, -0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, -0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, -0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, -0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, -0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, -0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, -0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, -0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, -0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, -0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, -0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, -0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, -0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, -0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, -0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, -0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, -0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, -0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, -0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, -0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, -0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, -0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, -0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, -0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, -0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, -0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, -0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, -0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, -0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, -0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, -0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, -0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, -0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, -0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, -0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, -0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, -0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, -0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, -0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, -0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, -0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, -0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, -0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, -0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, -0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, -0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, -0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, -0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, -0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, -0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, -0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, -0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, -0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, -0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, -0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, -0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, -0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, -0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, -0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, -0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, -0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, -0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, -0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, -0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, -0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, -0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, -0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, -0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, -0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, -0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, -0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, -0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, -0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, -0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, -0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, -0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, -0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, -0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, -0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, -0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, -0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, -0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, -0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, -0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, -0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, -0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, -0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, -0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, -0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, -0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, -0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, -0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, -0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, -0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, -0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, -0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, -0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, -0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, -0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, -0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, -0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, -0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, -0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, -0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, -0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, -0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, -0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, -0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, -0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, -0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, -0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, -0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, -0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, -0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, -0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, -0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, -0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, -0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, -0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, -0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, -0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, -0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, -0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, -0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, -0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, -0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, -0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, -0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, -0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, -0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, -0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, -0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, -0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, -0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, -0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, -0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, -0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, -0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, -0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, -0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, -0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, -0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, -0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, -0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, -0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, -0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, -0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, -0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, -0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, -0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, -0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, -0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, -0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, -0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, -0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, -0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, -0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, -0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, -0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, -0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, -0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, -0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, -0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, -0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, -0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, -0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, -0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, -0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, -0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, -0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, -0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, -0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, -0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, -0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, -0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, -0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, -0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, -0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, -0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, -0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, -0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, -0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, -0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, -0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, -0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, -0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, -0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, -0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, -0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, -0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, -0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, -0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, -0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, -0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, -0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, -0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, -0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, -0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, -0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, -0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, -0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, -0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, -0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, -0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, -0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, -0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, -0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, -0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, -0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, -0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, -0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, -0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, -0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, -0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, -0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, -0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, -0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, -0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, -0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, -0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, -0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, -0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, -0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, -0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, -0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, -0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, -0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, -0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, -0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, -0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, -0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, -0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, -0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, -0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, -0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, -0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, -0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, -0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, -0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, -0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, -0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, -0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, -0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, -0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, -0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, -0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, -0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, -0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, -0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, -0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, -0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, -0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, -0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, -0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, -0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, -0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, -0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, -0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, -0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, -0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, -0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, -0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, -0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, -0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, -0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, -0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, -0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, -0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, -0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, -0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, -0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, -0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, -0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, -0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, -0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, -0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, -0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, -0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, -0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, -0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, -0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, -0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, -0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, -0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, -0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, -0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, -0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, -0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, -0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, -0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, -0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, -0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, -0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, -0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, -0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, -0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, -0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, -0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, -0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, -0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, -0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, -0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, -0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, -0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, -0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, -0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, -0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, -0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, -0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, -0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, -0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, -0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, -0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, -0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, -0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, -0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, -0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, -0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, -0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, -0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, -0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, -0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, -0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, -0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, -0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, -0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, -0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, -0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, -0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, -0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, -0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, -0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, -0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, -0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, -0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, -0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, -0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, -0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, -0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, -0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, -0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, -0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, -0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, -0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, -0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, -0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, -0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, -0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, -0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, -0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, -0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, -0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, -0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, -0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, -0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, -0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, -0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, -0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, -0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, -0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, -0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, -0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, -0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, -0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, -0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, -0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, -0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, -0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, -0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, -0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, -0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, -0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, -0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, -0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, -0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, -0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, -0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, -0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, -0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, -0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, -0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, -0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, -0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, -0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, -0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, -0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, -0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, -0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, -0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, -0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, -0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, -0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, -0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, -0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, -0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, -0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, -0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, -0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, -0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, -0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, -0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, -0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, -0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, -0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, -0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, -0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, -0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, -0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, -0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, -0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, -0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, -0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, -0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, -0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, -0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, -0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, -0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, -0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, -0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, -0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, -0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, -0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, -0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, -0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, -0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, -0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, -0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, -0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, -0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, -0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, -0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, -0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, -0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, -0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, -0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, -0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, -0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, -0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, -0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, -0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, -0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, -0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, -0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, -0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, -0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, -0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, -0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, -0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, -0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, -0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, -0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, -0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, -0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, -0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, -0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, -0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, -0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, -0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, -0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, -0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, -0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, -0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, -0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, -0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, -0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, -0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, -0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, -0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, -0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, -0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, -0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, -0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, -0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, -0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, -0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, -0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, -0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, -0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, -0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, -0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, -0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, -0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, -0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, -0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, -0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, -0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, -0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, -0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, -0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, -0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, -0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, -0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, -0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, -0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, -0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, -0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, -0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, -0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, -0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, -0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, -0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, -0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, -0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, -0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, -0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, -0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, -0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, -0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, -0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, -0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, -0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, -0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, -0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, -0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, -0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, -0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, -0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, -0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, -0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, -0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, -0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, -0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, -0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, -0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, -0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, -0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, -0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, -0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, -0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, -0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, -0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, -0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, -0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, -0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, -0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, -0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, -0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, -0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, -0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, -0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, -0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, -0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, -0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, -0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, -0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, -0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, -0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, -0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, -0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, -0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, -0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, -0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, -0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, -0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, -0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, -0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, -0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, -0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, -0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, -0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, -0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, -0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, -0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, -0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, -0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, -0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, -0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, -0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, -0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, -0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, -0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, -0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, -0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, -0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, -0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, -0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, -0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, -0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, -0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, -0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, -0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, -0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, -0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, -0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, -0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, -0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, -0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, -0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, -0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, -0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, -0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, -0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, -0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, -0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, -0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, -0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, -0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, -0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, -0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, -0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, -0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, -0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, -0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, -0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, -0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, -0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, -0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, -0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, -0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, -0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, -0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, -0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, -0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, -0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, -0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, -0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, -0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, -0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, -0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, -0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, -0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, -0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, -0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, -0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, -0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, -0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, -0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, -0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, -0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, -0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, -0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, -0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, -0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, -0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, -0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, -0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, -0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, -0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, -0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, -0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, -0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, -0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, -0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, -0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, -0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, -0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, -0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, -0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, -0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, -0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, -0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, -0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, -0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x01, -0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, -0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, -0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, -0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, -0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, -0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, -0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, -0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, -0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, -0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, -0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, -0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, -0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, -0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, -0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, -0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, -0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, -0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, -0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, -0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, -0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, -0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, -0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, -0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, -0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, -0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, -0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, -0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, -0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, -0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, -0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, -0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, -0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, -0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, -0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, -0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, -0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, -0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, -0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, -0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, -0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, -0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, -0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, -0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, -0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, -0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, -0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, -0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, -0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, -0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, -0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, -0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, -0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, -0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, -0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, -0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, -0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, -0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, -0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, -0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, -0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, -0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, -0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, -0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, -0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, -0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, -0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, -0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, -0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, -0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, -0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, -0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, -0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, -0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, -0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, -0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, -0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, -0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, -0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, -0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, -0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, -0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, -0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, -0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, -0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, -0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, -0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, -0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, -0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, -0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, -0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, -0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, -0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, -0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, -0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, -0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, -0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, -0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, -0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, -0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, -0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, -0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, -0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, -0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, -0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, -0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, -0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, -0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, -0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, -0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, -0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, -0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, -0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, -0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, -0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, -0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, -0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, -0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, -0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, -0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, -0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, -0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, -0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, -0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, -0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, -0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, -0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, -0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, -0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, -0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, -0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, -0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, -0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, -0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, -0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, -0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, -0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, -0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, -0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, -0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, -0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, -0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, -0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, -0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, -0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, -0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, -0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, -0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, -0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, -0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, -0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, -0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, -0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, -0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, -0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, -0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, -0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, -0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, -0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, -0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, -0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, -0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, -0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, -0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, -0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, -0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, -0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, -0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, -0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, 0x00,0x00, -0x00,0x00, 0x00,0x00, 0x00,0x00, } ; +static unsigned char lanai4_data[20472] __initdata = { }; #ifdef SYMBOL_DEFINES_COMPILED _ From akpm@osdl.org Tue Mar 15 14:29:40 2005 Received: with ECARTIS (v1.0.0; list netdev); Tue, 15 Mar 2005 14:29:50 -0800 (PST) Received: from smtp.osdl.org (fire.osdl.org [65.172.181.4]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j2FMTeNP016319 for ; Tue, 15 Mar 2005 14:29:40 -0800 Received: from shell0.pdx.osdl.net (fw.osdl.org [65.172.181.6]) by smtp.osdl.org (8.12.8/8.12.8) with ESMTP id j2FMMkqi007579 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO); Tue, 15 Mar 2005 14:22:46 -0800 Received: from localhost.localdomain (shell0.pdx.osdl.net [10.9.0.31]) by shell0.pdx.osdl.net (8.13.1/8.11.6) with ESMTP id j2FMMjXu016829; Tue, 15 Mar 2005 14:22:45 -0800 Message-Id: <200503152222.j2FMMjXu016829@shell0.pdx.osdl.net> Subject: [patch 13/13] WE-18 (aka WPA) To: davem@davemloft.net Cc: jgarzik@pobox.com, netdev@oss.sgi.com, akpm@osdl.org, jt@hpl.hp.com From: akpm@osdl.org Date: Tue, 15 Mar 2005 14:22:50 -0800 Received-SPF: pass (domain of akpm@osdl.org designates 65.172.181.6 as permitted sender) X-MIMEDefang-Filter: osdl$Revision: 1.105 $ X-Scanned-By: MIMEDefang 2.36 X-Virus-Scanned: ClamAV 0.83/762/Sun Mar 13 15:35:33 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 212 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: akpm@osdl.org Precedence: bulk X-list: netdev Content-Length: 17841 Lines: 488 From: Jean Tourrilhes This is version 18 of the Wireless Extensions. The main change is that it adds all the necessary APIs for WPA and WPA2 support. This work was entirely done by Jouni Malinen, so let's thank him for both his hard work and deep expertise on the subject ;-) This APIs obviously doesn't do much by itself and works in concert with driver support (Jouni already sent you the HostAP changes) and userspace (Jouni is updating wpa_supplicant). This is also orthogonal with the ongoing work on in-kernel IEEE support (but potentially useful). The patch is attached, tested with 2.6.11. Normally, I would ask you to push that directly in the kernel (99% of the patch has been on my web page for ages and it does not affect non-WPA stuff), but Jouni convinced me that it should bake a few weeks in wireless-2.6 Signed-off-by: Andrew Morton --- 25-akpm/include/linux/wireless.h | 283 ++++++++++++++++++++++++++++++++++++++- 25-akpm/net/core/wireless.c | 74 +++++++++- 2 files changed, 352 insertions(+), 5 deletions(-) diff -puN include/linux/wireless.h~we-18-aka-wpa include/linux/wireless.h --- 25/include/linux/wireless.h~we-18-aka-wpa Tue Mar 15 14:19:55 2005 +++ 25-akpm/include/linux/wireless.h Tue Mar 15 14:19:55 2005 @@ -1,10 +1,10 @@ /* * This file define a set of standard wireless extensions * - * Version : 17 21.6.04 + * Version : 18 12.3.05 * * Authors : Jean Tourrilhes - HPL - - * Copyright (c) 1997-2004 Jean Tourrilhes, All Rights Reserved. + * Copyright (c) 1997-2005 Jean Tourrilhes, All Rights Reserved. */ #ifndef _LINUX_WIRELESS_H @@ -82,7 +82,7 @@ * (there is some stuff that will be added in the future...) * I just plan to increment with each new version. */ -#define WIRELESS_EXT 17 +#define WIRELESS_EXT 18 /* * Changes : @@ -182,6 +182,21 @@ * - Document (struct iw_quality *)->updated, add new flags (INVALID) * - Wireless Event capability in struct iw_range * - Add support for relative TxPower (yick !) + * + * V17 to V18 (From Jouni Malinen ) + * ---------- + * - Add support for WPA/WPA2 + * - Add extended encoding configuration (SIOCSIWENCODEEXT and + * SIOCGIWENCODEEXT) + * - Add SIOCSIWGENIE/SIOCGIWGENIE + * - Add SIOCSIWMLME + * - Add SIOCSIWPMKSA + * - Add struct iw_range bit field for supported encoding capabilities + * - Add optional scan request parameters for SIOCSIWSCAN + * - Add SIOCSIWAUTH/SIOCGIWAUTH for setting authentication and WPA + * related parameters (extensible up to 4096 parameter values) + * - Add wireless events: IWEVGENIE, IWEVMICHAELMICFAILURE, + * IWEVASSOCREQIE, IWEVASSOCRESPIE, IWEVPMKIDCAND */ /**************************** CONSTANTS ****************************/ @@ -256,6 +271,30 @@ #define SIOCSIWPOWER 0x8B2C /* set Power Management settings */ #define SIOCGIWPOWER 0x8B2D /* get Power Management settings */ +/* WPA : Generic IEEE 802.11 informatiom element (e.g., for WPA/RSN/WMM). + * This ioctl uses struct iw_point and data buffer that includes IE id and len + * fields. More than one IE may be included in the request. Setting the generic + * IE to empty buffer (len=0) removes the generic IE from the driver. Drivers + * are allowed to generate their own WPA/RSN IEs, but in these cases, drivers + * are required to report the used IE as a wireless event, e.g., when + * associating with an AP. */ +#define SIOCSIWGENIE 0x8B30 /* set generic IE */ +#define SIOCGIWGENIE 0x8B31 /* get generic IE */ + +/* WPA : IEEE 802.11 MLME requests */ +#define SIOCSIWMLME 0x8B16 /* request MLME operation; uses + * struct iw_mlme */ +/* WPA : Authentication mode parameters */ +#define SIOCSIWAUTH 0x8B32 /* set authentication mode params */ +#define SIOCGIWAUTH 0x8B33 /* get authentication mode params */ + +/* WPA : Extended version of encoding configuration */ +#define SIOCSIWENCODEEXT 0x8B34 /* set encoding token & mode */ +#define SIOCGIWENCODEEXT 0x8B35 /* get encoding token & mode */ + +/* WPA2 : PMKSA cache management */ +#define SIOCSIWPMKSA 0x8B36 /* PMKSA cache operation */ + /* -------------------- DEV PRIVATE IOCTL LIST -------------------- */ /* These 32 ioctl are wireless device private, for 16 commands. @@ -297,6 +336,34 @@ #define IWEVCUSTOM 0x8C02 /* Driver specific ascii string */ #define IWEVREGISTERED 0x8C03 /* Discovered a new node (AP mode) */ #define IWEVEXPIRED 0x8C04 /* Expired a node (AP mode) */ +#define IWEVGENIE 0x8C05 /* Generic IE (WPA, RSN, WMM, ..) + * (scan results); This includes id and + * length fields. One IWEVGENIE may + * contain more than one IE. Scan + * results may contain one or more + * IWEVGENIE events. */ +#define IWEVMICHAELMICFAILURE 0x8C06 /* Michael MIC failure + * (struct iw_michaelmicfailure) + */ +#define IWEVASSOCREQIE 0x8C07 /* IEs used in (Re)Association Request. + * The data includes id and length + * fields and may contain more than one + * IE. This event is required in + * Managed mode if the driver + * generates its own WPA/RSN IE. This + * should be sent just before + * IWEVREGISTERED event for the + * association. */ +#define IWEVASSOCRESPIE 0x8C08 /* IEs used in (Re)Association + * Response. The data includes id and + * length fields and may contain more + * than one IE. This may be sent + * between IWEVASSOCREQIE and + * IWEVREGISTERED events for the + * association. */ +#define IWEVPMKIDCAND 0x8C09 /* PMKID candidate for RSN + * pre-authentication + * (struct iw_pmkid_cand) */ #define IWEVFIRST 0x8C00 @@ -432,12 +499,94 @@ #define IW_SCAN_THIS_MODE 0x0020 /* Scan only this Mode */ #define IW_SCAN_ALL_RATE 0x0040 /* Scan all Bit-Rates */ #define IW_SCAN_THIS_RATE 0x0080 /* Scan only this Bit-Rate */ +/* struct iw_scan_req scan_type */ +#define IW_SCAN_TYPE_ACTIVE 0 +#define IW_SCAN_TYPE_PASSIVE 1 /* Maximum size of returned data */ #define IW_SCAN_MAX_DATA 4096 /* In bytes */ /* Max number of char in custom event - use multiple of them if needed */ #define IW_CUSTOM_MAX 256 /* In bytes */ +/* Generic information element */ +#define IW_GENERIC_IE_MAX 1024 + +/* MLME requests (SIOCSIWMLME / struct iw_mlme) */ +#define IW_MLME_DEAUTH 0 +#define IW_MLME_DISASSOC 1 + +/* SIOCSIWAUTH/SIOCGIWAUTH struct iw_param flags */ +#define IW_AUTH_INDEX 0x0FFF +#define IW_AUTH_FLAGS 0xF000 +/* SIOCSIWAUTH/SIOCGIWAUTH parameters (0 .. 4095) + * (IW_AUTH_INDEX mask in struct iw_param flags; this is the index of the + * parameter that is being set/get to; value will be read/written to + * struct iw_param value field) */ +#define IW_AUTH_WPA_VERSION 0 +#define IW_AUTH_CIPHER_PAIRWISE 1 +#define IW_AUTH_CIPHER_GROUP 2 +#define IW_AUTH_KEY_MGMT 3 +#define IW_AUTH_TKIP_COUNTERMEASURES 4 +#define IW_AUTH_DROP_UNENCRYPTED 5 +#define IW_AUTH_80211_AUTH_ALG 6 +#define IW_AUTH_WPA_ENABLED 7 +#define IW_AUTH_RX_UNENCRYPTED_EAPOL 8 +#define IW_AUTH_ROAMING_CONTROL 9 +#define IW_AUTH_PRIVACY_INVOKED 10 + +/* IW_AUTH_WPA_VERSION values (bit field) */ +#define IW_AUTH_WPA_VERSION_DISABLED 0x00000001 +#define IW_AUTH_WPA_VERSION_WPA 0x00000002 +#define IW_AUTH_WPA_VERSION_WPA2 0x00000004 + +/* IW_AUTH_PAIRWISE_CIPHER and IW_AUTH_GROUP_CIPHER values (bit field) */ +#define IW_AUTH_CIPHER_NONE 0x00000001 +#define IW_AUTH_CIPHER_WEP40 0x00000002 +#define IW_AUTH_CIPHER_TKIP 0x00000004 +#define IW_AUTH_CIPHER_CCMP 0x00000008 +#define IW_AUTH_CIPHER_WEP104 0x00000010 + +/* IW_AUTH_KEY_MGMT values (bit field) */ +#define IW_AUTH_KEY_MGMT_802_1X 1 +#define IW_AUTH_KEY_MGMT_PSK 2 + +/* IW_AUTH_80211_AUTH_ALG values (bit field) */ +#define IW_AUTH_ALG_OPEN_SYSTEM 0x00000001 +#define IW_AUTH_ALG_SHARED_KEY 0x00000002 +#define IW_AUTH_ALG_LEAP 0x00000004 + +/* IW_AUTH_ROAMING_CONTROL values */ +#define IW_AUTH_ROAMING_ENABLE 0 /* driver/firmware based roaming */ +#define IW_AUTH_ROAMING_DISABLE 1 /* user space program used for roaming + * control */ + +/* SIOCSIWENCODEEXT definitions */ +#define IW_ENCODE_SEQ_MAX_SIZE 8 +/* struct iw_encode_ext ->alg */ +#define IW_ENCODE_ALG_NONE 0 +#define IW_ENCODE_ALG_WEP 1 +#define IW_ENCODE_ALG_TKIP 2 +#define IW_ENCODE_ALG_CCMP 3 +/* struct iw_encode_ext ->ext_flags */ +#define IW_ENCODE_EXT_TX_SEQ_VALID 0x00000001 +#define IW_ENCODE_EXT_RX_SEQ_VALID 0x00000002 +#define IW_ENCODE_EXT_GROUP_KEY 0x00000004 +#define IW_ENCODE_EXT_SET_TX_KEY 0x00000008 + +/* IWEVMICHAELMICFAILURE : struct iw_michaelmicfailure ->flags */ +#define IW_MICFAILURE_KEY_ID 0x00000003 /* Key ID 0..3 */ +#define IW_MICFAILURE_GROUP 0x00000004 +#define IW_MICFAILURE_PAIRWISE 0x00000008 +#define IW_MICFAILURE_STAKEY 0x00000010 +#define IW_MICFAILURE_COUNT 0x00000060 /* 1 or 2 (0 = count not supported) + */ + +/* Bit field values for enc_capa in struct iw_range */ +#define IW_ENC_CAPA_WPA 0x00000001 +#define IW_ENC_CAPA_WPA2 0x00000002 +#define IW_ENC_CAPA_CIPHER_TKIP 0x00000004 +#define IW_ENC_CAPA_CIPHER_CCMP 0x00000008 + /* Event capability macros - in (struct iw_range *)->event_capa * Because we have more than 32 possible events, we use an array of * 32 bit bitmasks. Note : 32 bits = 0x20 = 2^5. */ @@ -546,6 +695,132 @@ struct iw_thrspy struct iw_quality high; /* High threshold */ }; +/* + * Optional data for scan request + * + * Note: these optional parameters are controlling parameters for the + * scanning behavior, these do not apply to getting scan results + * (SIOCGIWSCAN). Drivers are expected to keep a local BSS table and + * provide a merged results with all BSSes even if the previous scan + * request limited scanning to a subset, e.g., by specifying an SSID. + * Especially, scan results are required to include an entry for the + * current BSS if the driver is in Managed mode and associated with an AP. + */ +struct iw_scan_req +{ + __u8 scan_type; /* IW_SCAN_TYPE_{ACTIVE,PASSIVE} */ + __u8 essid_len; + __u8 num_channels; /* num entries in channel_list; + * 0 = scan all allowed channels */ + __u8 flags; /* reserved as padding; use zero, this may + * be used in the future for adding flags + * to request different scan behavior */ + struct sockaddr bssid; /* ff:ff:ff:ff:ff:ff for broadcast BSSID or + * individual address of a specific BSS */ + + /* + * Use this ESSID if IW_SCAN_THIS_ESSID flag is used instead of using + * the current ESSID. This allows scan requests for specific ESSID + * without having to change the current ESSID and potentially breaking + * the current association. + */ + __u8 essid[IW_ESSID_MAX_SIZE]; + + /* + * Optional parameters for changing the default scanning behavior. + * These are based on the MLME-SCAN.request from IEEE Std 802.11. + * TU is 1.024 ms. If these are set to 0, driver is expected to use + * reasonable default values. min_channel_time defines the time that + * will be used to wait for the first reply on each channel. If no + * replies are received, next channel will be scanned after this. If + * replies are received, total time waited on the channel is defined by + * max_channel_time. + */ + __u32 min_channel_time; /* in TU */ + __u32 max_channel_time; /* in TU */ + + struct iw_freq channel_list[IW_MAX_FREQUENCIES]; +}; + +/* ------------------------- WPA SUPPORT ------------------------- */ + +/* + * Extended data structure for get/set encoding (this is used with + * SIOCSIWENCODEEXT/SIOCGIWENCODEEXT. struct iw_point and IW_ENCODE_* + * flags are used in the same way as with SIOCSIWENCODE/SIOCGIWENCODE and + * only the data contents changes (key data -> this structure, including + * key data). + * + * If the new key is the first group key, it will be set as the default + * TX key. Otherwise, default TX key index is only changed if + * IW_ENCODE_EXT_SET_TX_KEY flag is set. + * + * Key will be changed with SIOCSIWENCODEEXT in all cases except for + * special "change TX key index" operation which is indicated by setting + * key_len = 0 and ext_flags |= IW_ENCODE_EXT_SET_TX_KEY. + * + * tx_seq/rx_seq are only used when respective + * IW_ENCODE_EXT_{TX,RX}_SEQ_VALID flag is set in ext_flags. Normal + * TKIP/CCMP operation is to set RX seq with SIOCSIWENCODEEXT and start + * TX seq from zero whenever key is changed. SIOCGIWENCODEEXT is normally + * used only by an Authenticator (AP or an IBSS station) to get the + * current TX sequence number. Using TX_SEQ_VALID for SIOCSIWENCODEEXT and + * RX_SEQ_VALID for SIOCGIWENCODEEXT are optional, but can be useful for + * debugging/testing. + */ +struct iw_encode_ext +{ + __u32 ext_flags; /* IW_ENCODE_EXT_* */ + __u8 tx_seq[IW_ENCODE_SEQ_MAX_SIZE]; /* LSB first */ + __u8 rx_seq[IW_ENCODE_SEQ_MAX_SIZE]; /* LSB first */ + struct sockaddr addr; /* ff:ff:ff:ff:ff:ff for broadcast/multicast + * (group) keys or unicast address for + * individual keys */ + __u16 alg; /* IW_ENCODE_ALG_* */ + __u16 key_len; + __u8 key[0]; +}; + +/* SIOCSIWMLME data */ +struct iw_mlme +{ + __u16 cmd; /* IW_MLME_* */ + __u16 reason_code; + struct sockaddr addr; +}; + +/* SIOCSIWPMKSA data */ +#define IW_PMKSA_ADD 1 +#define IW_PMKSA_REMOVE 2 +#define IW_PMKSA_FLUSH 3 + +#define IW_PMKID_LEN 16 + +struct iw_pmksa +{ + __u32 cmd; /* IW_PMKSA_* */ + struct sockaddr bssid; + __u8 pmkid[IW_PMKID_LEN]; +}; + +/* IWEVMICHAELMICFAILURE data */ +struct iw_michaelmicfailure +{ + __u32 flags; + struct sockaddr src_addr; + __u8 tsc[IW_ENCODE_SEQ_MAX_SIZE]; /* LSB first */ +}; + +/* IWEVPMKIDCAND data */ +#define IW_PMKID_CAND_PREAUTH 0x00000001 /* RNS pre-authentication enabled */ +struct iw_pmkid_cand +{ + __u32 flags; /* IW_PMKID_CAND_* */ + __u32 index; /* the smaller the index, the higher the + * priority */ + struct sockaddr bssid; +}; + /* ------------------------ WIRELESS STATS ------------------------ */ /* * Wireless statistics (used for /proc/net/wireless) @@ -725,6 +1000,8 @@ struct iw_range struct iw_freq freq[IW_MAX_FREQUENCIES]; /* list */ /* Note : this frequency list doesn't need to fit channel numbers, * because each entry contain its channel index */ + + __u32 enc_capa; /* IW_ENC_CAPA_* bit field */ }; /* diff -puN net/core/wireless.c~we-18-aka-wpa net/core/wireless.c --- 25/net/core/wireless.c~we-18-aka-wpa Tue Mar 15 14:19:55 2005 +++ 25-akpm/net/core/wireless.c Tue Mar 15 14:19:55 2005 @@ -2,7 +2,7 @@ * This file implement the Wireless Extensions APIs. * * Authors : Jean Tourrilhes - HPL - - * Copyright (c) 1997-2004 Jean Tourrilhes, All Rights Reserved. + * Copyright (c) 1997-2005 Jean Tourrilhes, All Rights Reserved. * * (As all part of the Linux kernel, this file is GPL) */ @@ -187,6 +187,12 @@ static const struct iw_ioctl_description .header_type = IW_HEADER_TYPE_ADDR, .flags = IW_DESCR_FLAG_DUMP, }, + [SIOCSIWMLME - SIOCIWFIRST] = { + .header_type = IW_HEADER_TYPE_POINT, + .token_size = 1, + .min_tokens = sizeof(struct iw_mlme), + .max_tokens = sizeof(struct iw_mlme), + }, [SIOCGIWAPLIST - SIOCIWFIRST] = { .header_type = IW_HEADER_TYPE_POINT, .token_size = sizeof(struct sockaddr) + @@ -195,7 +201,10 @@ static const struct iw_ioctl_description .flags = IW_DESCR_FLAG_NOMAX, }, [SIOCSIWSCAN - SIOCIWFIRST] = { - .header_type = IW_HEADER_TYPE_PARAM, + .header_type = IW_HEADER_TYPE_POINT, + .token_size = 1, + .min_tokens = 0, + .max_tokens = sizeof(struct iw_scan_req), }, [SIOCGIWSCAN - SIOCIWFIRST] = { .header_type = IW_HEADER_TYPE_POINT, @@ -273,6 +282,42 @@ static const struct iw_ioctl_description [SIOCGIWPOWER - SIOCIWFIRST] = { .header_type = IW_HEADER_TYPE_PARAM, }, + [SIOCSIWGENIE - SIOCIWFIRST] = { + .header_type = IW_HEADER_TYPE_POINT, + .token_size = 1, + .max_tokens = IW_GENERIC_IE_MAX, + }, + [SIOCGIWGENIE - SIOCIWFIRST] = { + .header_type = IW_HEADER_TYPE_POINT, + .token_size = 1, + .max_tokens = IW_GENERIC_IE_MAX, + }, + [SIOCSIWAUTH - SIOCIWFIRST] = { + .header_type = IW_HEADER_TYPE_PARAM, + }, + [SIOCGIWAUTH - SIOCIWFIRST] = { + .header_type = IW_HEADER_TYPE_PARAM, + }, + [SIOCSIWENCODEEXT - SIOCIWFIRST] = { + .header_type = IW_HEADER_TYPE_POINT, + .token_size = 1, + .min_tokens = sizeof(struct iw_encode_ext), + .max_tokens = sizeof(struct iw_encode_ext) + + IW_ENCODING_TOKEN_MAX, + }, + [SIOCGIWENCODEEXT - SIOCIWFIRST] = { + .header_type = IW_HEADER_TYPE_POINT, + .token_size = 1, + .min_tokens = sizeof(struct iw_encode_ext), + .max_tokens = sizeof(struct iw_encode_ext) + + IW_ENCODING_TOKEN_MAX, + }, + [SIOCSIWPMKSA - SIOCIWFIRST] = { + .header_type = IW_HEADER_TYPE_POINT, + .token_size = 1, + .min_tokens = sizeof(struct iw_pmksa), + .max_tokens = sizeof(struct iw_pmksa), + }, }; static const int standard_ioctl_num = (sizeof(standard_ioctl) / sizeof(struct iw_ioctl_description)); @@ -299,6 +344,31 @@ static const struct iw_ioctl_description [IWEVEXPIRED - IWEVFIRST] = { .header_type = IW_HEADER_TYPE_ADDR, }, + [IWEVGENIE - IWEVFIRST] = { + .header_type = IW_HEADER_TYPE_POINT, + .token_size = 1, + .max_tokens = IW_GENERIC_IE_MAX, + }, + [IWEVMICHAELMICFAILURE - IWEVFIRST] = { + .header_type = IW_HEADER_TYPE_POINT, + .token_size = 1, + .max_tokens = sizeof(struct iw_michaelmicfailure), + }, + [IWEVASSOCREQIE - IWEVFIRST] = { + .header_type = IW_HEADER_TYPE_POINT, + .token_size = 1, + .max_tokens = IW_GENERIC_IE_MAX, + }, + [IWEVASSOCRESPIE - IWEVFIRST] = { + .header_type = IW_HEADER_TYPE_POINT, + .token_size = 1, + .max_tokens = IW_GENERIC_IE_MAX, + }, + [IWEVPMKIDCAND - IWEVFIRST] = { + .header_type = IW_HEADER_TYPE_POINT, + .token_size = 1, + .max_tokens = sizeof(struct iw_pmkid_cand), + }, }; static const int standard_event_num = (sizeof(standard_event) / sizeof(struct iw_ioctl_description)); _ From bunk@stusta.de Tue Mar 15 14:31:22 2005 Received: with ECARTIS (v1.0.0; list netdev); Tue, 15 Mar 2005 14:31:28 -0800 (PST) Received: from mailout.stusta.mhn.de (emailhub.stusta.mhn.de [141.84.69.5]) by oss.sgi.com (8.13.0/8.13.0) with SMTP id j2FMVKxX016884 for ; Tue, 15 Mar 2005 14:31:21 -0800 Received: (qmail 18439 invoked from network); 15 Mar 2005 22:31:15 -0000 Received: from r063144.stusta.swh.mhn.de (10.150.63.144) by mailhub.stusta.mhn.de with SMTP; 15 Mar 2005 22:31:15 -0000 Received: by r063144.stusta.swh.mhn.de (Postfix, from userid 1000) id 9C851BB696; Tue, 15 Mar 2005 23:31:13 +0100 (CET) Date: Tue, 15 Mar 2005 23:31:12 +0100 From: Adrian Bunk To: Pete Clements Cc: linux-kernel , Thomas Graf , davem@davemloft.net, netdev@oss.sgi.com Subject: [2.6 patch] export dev_get_flags Message-ID: <20050315223112.GX3189@stusta.de> References: <200503151852.j2FIqr8t009525@clem.clem-digital.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200503151852.j2FIqr8t009525@clem.clem-digital.net> User-Agent: Mutt/1.5.6+20040907i X-Virus-Scanned: ClamAV 0.83/762/Sun Mar 13 15:35:33 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 213 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: bunk@stusta.de Precedence: bulk X-list: netdev Content-Length: 530 Lines: 21 On Tue, Mar 15, 2005 at 01:52:53PM -0500, Pete Clements wrote: > Fyi: > 2.6.11.3-bk1 net/ipv6/ipv6.ko missing symbol dev_get_flags It seems this patch is required (untested). Signed-off-by: Adrian Bunk --- linux-2.6.11-mm3-full/net/core/dev.c.old 2005-03-15 20:13:52.000000000 +0100 +++ linux-2.6.11-mm3-full/net/core/dev.c 2005-03-15 20:14:32.000000000 +0100 @@ -2214,6 +2214,7 @@ return flags; } +EXPORT_SYMBOL_GPL(dev_get_flags); int dev_change_flags(struct net_device *dev, unsigned flags) { From jgarzik@pobox.com Tue Mar 15 14:40:49 2005 Received: with ECARTIS (v1.0.0; list netdev); Tue, 15 Mar 2005 14:40:56 -0800 (PST) Received: from parcelfarce.linux.theplanet.co.uk (IDENT:93@parcelfarce.linux.theplanet.co.uk [195.92.249.252]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j2FMem4H018599 for ; Tue, 15 Mar 2005 14:40:49 -0800 Received: from [69.134.152.124] (helo=[10.10.10.88]) by parcelfarce.linux.theplanet.co.uk with asmtp (TLSv1:AES256-SHA:256) (Exim 4.33) id 1DBKiV-0003or-2O; Tue, 15 Mar 2005 22:40:47 +0000 Message-ID: <42376448.3040701@pobox.com> Date: Tue, 15 Mar 2005 17:40:08 -0500 From: Jeff Garzik User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.3) Gecko/20040922 X-Accept-Language: en-us, en MIME-Version: 1.0 To: akpm@osdl.org CC: davem@davemloft.net, netdev@oss.sgi.com, jt@hpl.hp.com Subject: Re: [patch 13/13] WE-18 (aka WPA) References: <200503152222.j2FMMjXu016829@shell0.pdx.osdl.net> In-Reply-To: <200503152222.j2FMMjXu016829@shell0.pdx.osdl.net> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV 0.83/762/Sun Mar 13 15:35:33 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 214 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: jgarzik@pobox.com Precedence: bulk X-list: netdev Content-Length: 972 Lines: 24 akpm@osdl.org wrote: > From: Jean Tourrilhes > > This is version 18 of the Wireless Extensions. The main change is that it > adds all the necessary APIs for WPA and WPA2 support. This work was > entirely done by Jouni Malinen, so let's thank him for both his hard work > and deep expertise on the subject ;-) > > This APIs obviously doesn't do much by itself and works in concert with > driver support (Jouni already sent you the HostAP changes) and userspace > (Jouni is updating wpa_supplicant). This is also orthogonal with the > ongoing work on in-kernel IEEE support (but potentially useful). > > The patch is attached, tested with 2.6.11. Normally, I would ask you to > push that directly in the kernel (99% of the patch has been on my web page > for ages and it does not affect non-WPA stuff), but Jouni convinced me that > it should bake a few weeks in wireless-2.6 Yes, this is going into wireless-2.6 later today, as requested. Jeff From jgarzik@pobox.com Tue Mar 15 14:42:13 2005 Received: with ECARTIS (v1.0.0; list netdev); Tue, 15 Mar 2005 14:42:20 -0800 (PST) Received: from parcelfarce.linux.theplanet.co.uk (IDENT:93@parcelfarce.linux.theplanet.co.uk [195.92.249.252]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j2FMgCBS019002 for ; Tue, 15 Mar 2005 14:42:13 -0800 Received: from [69.134.152.124] (helo=[10.10.10.88]) by parcelfarce.linux.theplanet.co.uk with asmtp (TLSv1:AES256-SHA:256) (Exim 4.33) id 1DBKjr-0003pg-P0; Tue, 15 Mar 2005 22:42:11 +0000 Message-ID: <423764A3.8030201@pobox.com> Date: Tue, 15 Mar 2005 17:41:39 -0500 From: Jeff Garzik User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.3) Gecko/20040922 X-Accept-Language: en-us, en MIME-Version: 1.0 To: akpm@osdl.org CC: davem@davemloft.net, netdev@oss.sgi.com, christoph@graphe.net, nirajk@calsoftinc.com, christoph@lameter.com, Shai@Scalex86.org Subject: Re: [patch 05/13] remove last_rx update from loopback device References: <200503152222.j2FMMbhG016805@shell0.pdx.osdl.net> In-Reply-To: <200503152222.j2FMMbhG016805@shell0.pdx.osdl.net> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV 0.83/762/Sun Mar 13 15:35:33 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 215 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: jgarzik@pobox.com Precedence: bulk X-list: netdev Content-Length: 1418 Lines: 40 akpm@osdl.org wrote: > From: Christoph Lameter > > The last_rx field in the loopback driver is updated on every xmit but is > not used otherwise. Accesses to ->last_rx cause unecessary traffic on the > interlink for NUMA systems which limits the performance of the loopback > device. > > The comment given at include/linux/netdevice.h says that last_rx may be > used for future network-power-down code, which is likely not relevant for > the loopback device (please let me know if it is otherwise ..). > > Signed-off-by: Niraj Kumar > Signed-off-by: Christoph Lameter > Signed-off-by: Shai Fultheim > Signed-off-by: Andrew Morton > --- > > 25-akpm/drivers/net/loopback.c | 2 -- > 1 files changed, 2 deletions(-) > > diff -puN drivers/net/loopback.c~remove-last_rx-update-from-loopback-device drivers/net/loopback.c > --- 25/drivers/net/loopback.c~remove-last_rx-update-from-loopback-device Tue Mar 15 14:19:53 2005 > +++ 25-akpm/drivers/net/loopback.c Tue Mar 15 14:19:53 2005 > @@ -144,8 +144,6 @@ static int loopback_xmit(struct sk_buff > return 0; > } > > - dev->last_rx = jiffies; > - > lb_stats = &per_cpu(loopback_stats, get_cpu()); > lb_stats->rx_bytes += skb->len; > lb_stats->tx_bytes += skb->len; I disagree. loopback.c is doing precisely what it should be doing. Jeff From akpm@osdl.org Tue Mar 15 15:09:07 2005 Received: with ECARTIS (v1.0.0; list netdev); Tue, 15 Mar 2005 15:09:13 -0800 (PST) Received: from smtp.osdl.org (fire.osdl.org [65.172.181.4]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j2FN90m3020423 for ; Tue, 15 Mar 2005 15:09:05 -0800 Received: from shell0.pdx.osdl.net (fw.osdl.org [65.172.181.6]) by smtp.osdl.org (8.12.8/8.12.8) with ESMTP id j2FN8Cqi011871 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO); Tue, 15 Mar 2005 15:08:12 -0800 Received: from akpm.pao.digeo.com (shell0.pdx.osdl.net [10.9.0.31]) by shell0.pdx.osdl.net (8.13.1/8.11.6) with SMTP id j2FN85r1019901; Tue, 15 Mar 2005 15:08:07 -0800 Date: Tue, 15 Mar 2005 15:08:09 -0800 From: Andrew Morton To: Jeff Garzik Cc: davem@davemloft.net, netdev@oss.sgi.com, christoph@graphe.net, nirajk@calsoftinc.com, christoph@lameter.com, Shai@Scalex86.org Subject: Re: [patch 05/13] remove last_rx update from loopback device Message-Id: <20050315150809.579c5e85.akpm@osdl.org> In-Reply-To: <423764A3.8030201@pobox.com> References: <200503152222.j2FMMbhG016805@shell0.pdx.osdl.net> <423764A3.8030201@pobox.com> X-Mailer: Sylpheed version 1.0.0 (GTK+ 1.2.10; i386-vine-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Received-SPF: pass (domain of akpm@osdl.org designates 65.172.181.6 as permitted sender) X-MIMEDefang-Filter: osdl$Revision: 1.105 $ X-Scanned-By: MIMEDefang 2.36 X-Virus-Scanned: ClamAV 0.83/762/Sun Mar 13 15:35:33 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 216 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: akpm@osdl.org Precedence: bulk X-list: netdev Content-Length: 320 Lines: 11 Jeff Garzik wrote: > > > - dev->last_rx = jiffies; > > - > > lb_stats = &per_cpu(loopback_stats, get_cpu()); > > lb_stats->rx_bytes += skb->len; > > lb_stats->tx_bytes += skb->len; > > I disagree. loopback.c is doing precisely what it should be doing. Nothing actually seems to use last_rx? From linville@bilbo.tuxdriver.com Tue Mar 15 15:16:54 2005 Received: with ECARTIS (v1.0.0; list netdev); Tue, 15 Mar 2005 15:17:00 -0800 (PST) Received: from ra.tuxdriver.com (ra.tuxdriver.com [24.172.12.4]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j2FNGrQ2021148 for ; Tue, 15 Mar 2005 15:16:54 -0800 Received: from bilbo.tuxdriver.com (bilbo.tuxdriver.com [24.172.12.5]) by ra.tuxdriver.com (8.11.6/8.11.6) with ESMTP id j2FNA4G06126; Tue, 15 Mar 2005 18:10:04 -0500 Received: from bilbo.tuxdriver.com (localhost.localdomain [127.0.0.1]) by bilbo.tuxdriver.com (8.13.1/8.13.1) with ESMTP id j2FNGZF9018429; Tue, 15 Mar 2005 18:16:35 -0500 Received: (from linville@localhost) by bilbo.tuxdriver.com (8.13.1/8.13.1/Submit) id j2FNGYMO018428; Tue, 15 Mar 2005 18:16:34 -0500 Date: Tue, 15 Mar 2005 18:16:34 -0500 From: "John W. Linville" To: akpm@osdl.org Cc: davem@davemloft.net, jgarzik@pobox.com, netdev@oss.sgi.com Subject: Re: [patch 04/13] e100: NAPI fixes Message-ID: <20050315231632.GA18393@tuxdriver.com> Mail-Followup-To: akpm@osdl.org, davem@davemloft.net, jgarzik@pobox.com, netdev@oss.sgi.com References: <200503152222.j2FMMawn016802@shell0.pdx.osdl.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200503152222.j2FMMawn016802@shell0.pdx.osdl.net> User-Agent: Mutt/1.4.1i X-Virus-Scanned: ClamAV 0.83/762/Sun Mar 13 15:35:33 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 217 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: linville@tuxdriver.com Precedence: bulk X-list: netdev Content-Length: 423 Lines: 16 On Tue, Mar 15, 2005 at 02:22:41PM -0800, akpm@osdl.org wrote: > > From: "John W. Linville" > > Just curious...wanna try this patch I got from Intel? I think it > may help... Hmmm...I didn't really mean for that one to be a submission... Hopefully the Intel e100 guys will be covering this in one of their updates (if they haven't already)... John -- John W. Linville linville@tuxdriver.com From 76306.1226@compuserve.com Tue Mar 15 15:19:46 2005 Received: with ECARTIS (v1.0.0; list netdev); Tue, 15 Mar 2005 15:19:51 -0800 (PST) Received: from siaag1ae.compuserve.com (siaag1ae.compuserve.com [149.174.40.7]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j2FNJfYJ021741 for ; Tue, 15 Mar 2005 15:19:46 -0800 Received: (from mailgate@localhost) by siaag1ae.compuserve.com (8.12.11/8.12.7/SUN-2.17) id j2FNITap019592; Tue, 15 Mar 2005 18:18:29 -0500 (EST) Date: Tue, 15 Mar 2005 18:15:59 -0500 From: Chuck Ebbert <76306.1226@compuserve.com> Subject: Re: [PATCH] Optimize loopback stats To: Nivedita Singhvi Cc: Christoph Lameter , Andrew Morton , linux-netdev Message-ID: <200503151819_MC3-1-98A4-43AC@compuserve.com> MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii Content-Disposition: inline X-Virus-Scanned: ClamAV 0.83/762/Sun Mar 13 15:35:33 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 218 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: 76306.1226@compuserve.com Precedence: bulk X-list: netdev Content-Length: 632 Lines: 20 On 15-Mar-05 Nivedita Singhvi wrote: > Chuck Ebbert wrote: > > > This patch optimizes the loopback driver's statistics by using a single > > counter for rx and tx stats instead of one for rx and one for tx. It also > > adds unlikely() to the test for TSO since it's no longer supported by default. > > (Maybe the TSO code should be bracketed by "#if 0" ?) > > Hmm, some of us want those counters separate - if this is really > needed, could it be a configurable option, please? But they _are_ separately reported -- get_stats() takes care of that. Everything looks exactly the same to userspace after this patch. -- Chuck From amir.sarbazi@gmail.com Tue Mar 15 15:23:28 2005 Received: with ECARTIS (v1.0.0; list netdev); Tue, 15 Mar 2005 15:23:32 -0800 (PST) Received: from wproxy.gmail.com (wproxy.gmail.com [64.233.184.193]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j2FNNQ89022312 for ; Tue, 15 Mar 2005 15:23:28 -0800 Received: by wproxy.gmail.com with SMTP id 68so8792wra for ; Tue, 15 Mar 2005 15:23:20 -0800 (PST) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:reply-to:to:subject:mime-version:content-type:content-transfer-encoding; b=OnNcMlQLs1I+Cbroe+BboifkERk3pWVYPzxgrEg+QyTxA2Y1Oq0ezAUOCusXoGyzL/MMj0ctLxEcpHI6NQLbs/FCgYhnCQTp/w7UbQ3kzrHrMrIvobkbLzv6x2qcY+azlt+CeiTx3ajCopDN5wJ5u+p0mLm5wO03QjoBVzweg2s= Received: by 10.38.97.76 with SMTP id u76mr1206751rnb; Tue, 15 Mar 2005 15:23:19 -0800 (PST) Received: by 10.38.101.42 with HTTP; Tue, 15 Mar 2005 15:23:19 -0800 (PST) Message-ID: <43c5e5aa05031515236d1b1527@mail.gmail.com> Date: Wed, 16 Mar 2005 03:53:19 +0430 From: amir_sarbazi Reply-To: backslash46@yahoo.com To: netdev@oss.sgi.com Subject: limit ssh Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV 0.83/762/Sun Mar 13 15:35:33 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 219 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: amir.sarbazi@gmail.com Precedence: bulk X-list: netdev Content-Length: 116 Lines: 8 Hi all How i can limit ssh with a special IP address. (just can ssh with a special IP) with regards amir sarbazi From akpm@osdl.org Tue Mar 15 15:23:48 2005 Received: with ECARTIS (v1.0.0; list netdev); Tue, 15 Mar 2005 15:23:52 -0800 (PST) Received: from smtp.osdl.org (fire.osdl.org [65.172.181.4]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j2FNNkxd022323 for ; Tue, 15 Mar 2005 15:23:47 -0800 Received: from shell0.pdx.osdl.net (fw.osdl.org [65.172.181.6]) by smtp.osdl.org (8.12.8/8.12.8) with ESMTP id j2FNNWqi013697 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO); Tue, 15 Mar 2005 15:23:33 -0800 Received: from akpm.pao.digeo.com (shell0.pdx.osdl.net [10.9.0.31]) by shell0.pdx.osdl.net (8.13.1/8.11.6) with SMTP id j2FNNRJv020801; Tue, 15 Mar 2005 15:23:29 -0800 Date: Tue, 15 Mar 2005 15:23:32 -0800 From: Andrew Morton To: "John W. Linville" Cc: davem@davemloft.net, jgarzik@pobox.com, netdev@oss.sgi.com Subject: Re: [patch 04/13] e100: NAPI fixes Message-Id: <20050315152332.7c938b30.akpm@osdl.org> In-Reply-To: <20050315231632.GA18393@tuxdriver.com> References: <200503152222.j2FMMawn016802@shell0.pdx.osdl.net> <20050315231632.GA18393@tuxdriver.com> X-Mailer: Sylpheed version 1.0.0 (GTK+ 1.2.10; i386-vine-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Received-SPF: pass (domain of akpm@osdl.org designates 65.172.181.6 as permitted sender) X-MIMEDefang-Filter: osdl$Revision: 1.105 $ X-Scanned-By: MIMEDefang 2.36 X-Virus-Scanned: ClamAV 0.83/762/Sun Mar 13 15:35:33 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 220 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: akpm@osdl.org Precedence: bulk X-list: netdev Content-Length: 468 Lines: 15 "John W. Linville" wrote: > > On Tue, Mar 15, 2005 at 02:22:41PM -0800, akpm@osdl.org wrote: > > > > From: "John W. Linville" > > > > Just curious...wanna try this patch I got from Intel? I think it > > may help... > > Hmmm...I didn't really mean for that one to be a submission... Yeah, I know. But the problem it fixes is real. It's one of my "hold onto this patch so I remember we need to fix it" patches. From niv@us.ibm.com Tue Mar 15 16:09:58 2005 Received: with ECARTIS (v1.0.0; list netdev); Tue, 15 Mar 2005 16:10:04 -0800 (PST) Received: from e35.co.us.ibm.com (e35.co.us.ibm.com [32.97.110.133]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j2G09pZj024778 for ; Tue, 15 Mar 2005 16:09:58 -0800 Received: from d03relay04.boulder.ibm.com (d03relay04.boulder.ibm.com [9.17.195.106]) by e35.co.us.ibm.com (8.12.10/8.12.9) with ESMTP id j2G09jLg562038 for ; Tue, 15 Mar 2005 19:09:45 -0500 Received: from d03av02.boulder.ibm.com (d03av02.boulder.ibm.com [9.17.195.168]) by d03relay04.boulder.ibm.com (8.12.10/NCO/VER6.6) with ESMTP id j2G09jKX188530 for ; Tue, 15 Mar 2005 17:09:45 -0700 Received: from d03av02.boulder.ibm.com (loopback [127.0.0.1]) by d03av02.boulder.ibm.com (8.12.11/8.12.11) with ESMTP id j2G09iUZ022932 for ; Tue, 15 Mar 2005 17:09:44 -0700 Received: from [9.47.22.102] (IBM-UFKG5CEJ4KK.beaverton.ibm.com [9.47.22.102]) by d03av02.boulder.ibm.com (8.12.11/8.12.11) with ESMTP id j2G09h8P022908; Tue, 15 Mar 2005 17:09:44 -0700 Message-ID: <42377947.5090207@us.ibm.com> Date: Tue, 15 Mar 2005 16:09:43 -0800 From: Nivedita Singhvi User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.5) Gecko/20041217 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Chuck Ebbert <76306.1226@compuserve.com> CC: Christoph Lameter , Andrew Morton , linux-netdev Subject: Re: [PATCH] Optimize loopback stats References: <200503151819_MC3-1-98A4-43AC@compuserve.com> In-Reply-To: <200503151819_MC3-1-98A4-43AC@compuserve.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV 0.83/762/Sun Mar 13 15:35:33 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 221 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: niv@us.ibm.com Precedence: bulk X-list: netdev Content-Length: 1029 Lines: 39 Chuck Ebbert wrote: > On 15-Mar-05 Nivedita Singhvi wrote: > > >>Chuck Ebbert wrote: >> >> >>> This patch optimizes the loopback driver's statistics by using a single >>>counter for rx and tx stats instead of one for rx and one for tx. It also >>>adds unlikely() to the test for TSO since it's no longer supported by default. >>>(Maybe the TSO code should be bracketed by "#if 0" ?) >> >>Hmm, some of us want those counters separate - if this is really >>needed, could it be a configurable option, please? > > > But they _are_ separately reported -- get_stats() takes care of that. > Everything looks exactly the same to userspace after this patch. > > > > > -- > Chuck > Hmm, I see the following in your patch: + stats->rx_bytes += lb_stats->rx_tx_bytes; + stats->tx_bytes = stats->rx_bytes; Doesn't that mean RX is now twice what it should be and so is TX? They are separately reported, but if so, their real value should be half of rx_tx_bytes each, correct? thanks, Nivedita From niv@us.ibm.com Tue Mar 15 16:18:50 2005 Received: with ECARTIS (v1.0.0; list netdev); Tue, 15 Mar 2005 16:18:54 -0800 (PST) Received: from e31.co.us.ibm.com (e31.co.us.ibm.com [32.97.110.129]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j2G0Inet025487 for ; Tue, 15 Mar 2005 16:18:50 -0800 Received: from westrelay02.boulder.ibm.com (westrelay02.boulder.ibm.com [9.17.195.11]) by e31.co.us.ibm.com (8.12.10/8.12.9) with ESMTP id j2G0Iiua504336 for ; Tue, 15 Mar 2005 19:18:44 -0500 Received: from d03av02.boulder.ibm.com (d03av02.boulder.ibm.com [9.17.195.168]) by westrelay02.boulder.ibm.com (8.12.10/NCO/VER6.6) with ESMTP id j2G0IiTl235124 for ; Tue, 15 Mar 2005 17:18:44 -0700 Received: from d03av02.boulder.ibm.com (loopback [127.0.0.1]) by d03av02.boulder.ibm.com (8.12.11/8.12.11) with ESMTP id j2G0IhDG014696 for ; Tue, 15 Mar 2005 17:18:43 -0700 Received: from [9.47.22.102] (IBM-UFKG5CEJ4KK.beaverton.ibm.com [9.47.22.102]) by d03av02.boulder.ibm.com (8.12.11/8.12.11) with ESMTP id j2G0Igut014670; Tue, 15 Mar 2005 17:18:43 -0700 Message-ID: <42377B62.6070606@us.ibm.com> Date: Tue, 15 Mar 2005 16:18:42 -0800 From: Nivedita Singhvi User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.5) Gecko/20041217 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Nivedita Singhvi CC: Chuck Ebbert <76306.1226@compuserve.com>, Christoph Lameter , Andrew Morton , linux-netdev Subject: Re: [PATCH] Optimize loopback stats References: <200503151819_MC3-1-98A4-43AC@compuserve.com> <42377947.5090207@us.ibm.com> In-Reply-To: <42377947.5090207@us.ibm.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV 0.83/762/Sun Mar 13 15:35:33 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 222 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: niv@us.ibm.com Precedence: bulk X-list: netdev Content-Length: 444 Lines: 16 > Hmm, I see the following in your patch: > > + stats->rx_bytes += lb_stats->rx_tx_bytes; > + stats->tx_bytes = stats->rx_bytes; > > Doesn't that mean RX is now twice what it should be > and so is TX? They are separately reported, but if > so, their real value should be half of rx_tx_bytes > each, correct? Ah, just beat me silly with a cluestick. I see what you're doing now..it's fine. thanks, Nivedita From rick.jones2@hp.com Tue Mar 15 16:52:16 2005 Received: with ECARTIS (v1.0.0; list netdev); Tue, 15 Mar 2005 16:52:26 -0800 (PST) Received: from palrel13.hp.com (palrel13.hp.com [156.153.255.238]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j2G0qG57029984 for ; Tue, 15 Mar 2005 16:52:16 -0800 Received: from tardy.cup.hp.com (tardy.cup.hp.com [15.244.44.58]) by palrel13.hp.com (Postfix) with ESMTP id E06901C00522; Tue, 15 Mar 2005 16:52:15 -0800 (PST) Received: from hp.com (localhost [127.0.0.1]) by tardy.cup.hp.com (8.9.3 (PHNE_28810)/8.9.3 SMKit7.02) with ESMTP id QAA26940; Tue, 15 Mar 2005 16:52:15 -0800 (PST) Message-ID: <4237833E.9080809@hp.com> Date: Tue, 15 Mar 2005 16:52:14 -0800 From: Rick Jones User-Agent: Mozilla/5.0 (X11; U; HP-UX 9000/785; en-US; rv:1.6) Gecko/20040304 X-Accept-Language: en-us, en MIME-Version: 1.0 To: "John W. Linville" Cc: linux-kernel@vger.kernel.org, ctindel@users.sourceforge.net, fubar@us.ibm.com, bonding-devel@lists.sourceforge.net, netdev@oss.sgi.com, jgarzik@pobox.com Subject: Re: [patch 2.6.11] bonding: avoid tx balance for IGMP (alb/tlb mode) References: <20050315215128.GA18262@tuxdriver.com> In-Reply-To: <20050315215128.GA18262@tuxdriver.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV 0.83/762/Sun Mar 13 15:35:33 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 223 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: rick.jones2@hp.com Precedence: bulk X-list: netdev Content-Length: 754 Lines: 22 Is that switch behaviour "normal" or "correct?" I know next to nothing about what stuff like LACP should do, but asked some internal folks and they had this to say: treats IGMP packets the same as all other non-broadcast traffic (i.e. it will attempt to load balance). This switch behavior seems rather odd in an aggregated case, given the fact that most traffic (except broadcast packets) will be load balanced by the partner device. In addition, the switch (in theory) is suppose to treat the aggregated switch ports as 1 logical port and therefore it should allow IGMP packets to be received back on any port in the logical aggregation. IMO, the switch behavior in this case seems questionable. FWIW, rick jones From davem@davemloft.net Tue Mar 15 16:53:35 2005 Received: with ECARTIS (v1.0.0; list netdev); Tue, 15 Mar 2005 16:53:40 -0800 (PST) Received: from cheetah.davemloft.net (mail@dsl027-180-174.sfo1.dsl.speakeasy.net [216.27.180.174]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j2G0rZlg030293 for ; Tue, 15 Mar 2005 16:53:35 -0800 Received: from localhost ([127.0.0.1] helo=cheetah.davemloft.net ident=davem) by cheetah.davemloft.net with smtp (Exim 3.36 #1 (Debian)) id 1DBMlJ-00035D-00; Tue, 15 Mar 2005 16:51:49 -0800 Date: Tue, 15 Mar 2005 16:51:49 -0800 From: "David S. Miller" To: akpm@osdl.org Cc: jgarzik@pobox.com, netdev@oss.sgi.com, akpm@osdl.org, linville@tuxdriver.com, pp@netppl.fi Subject: Re: [patch 01/13] b44: allocate tx bounce bufs as needed Message-Id: <20050315165149.0aa4db6e.davem@davemloft.net> In-Reply-To: <200503152222.j2FMMW2x016793@shell0.pdx.osdl.net> References: <200503152222.j2FMMW2x016793@shell0.pdx.osdl.net> X-Mailer: Sylpheed version 1.0.1 (GTK+ 1.2.10; sparc-unknown-linux-gnu) X-Face: "_;p5u5aPsO,_Vsx"^v-pEq09'CU4&Dc1$fQExov$62l60cgCc%FnIwD=.UF^a>?5'9Kn[;433QFVV9M..2eN.@4ZWPGbdi<=?[:T>y?SD(R*-3It"Vj:)"dP Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV 0.83/762/Sun Mar 13 15:35:33 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 224 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: davem@davemloft.net Precedence: bulk X-list: netdev Content-Length: 914 Lines: 21 On Tue, 15 Mar 2005 14:22:37 -0800 akpm@osdl.org wrote: > From: "John W. Linville" > > The b44 hardware has a DMA mask that only covers 1GB. On x86, a DMA mask > <4GB results in allocations using GFP_DMA. The GFP_DMA pool (16MB) gets > exhausted very quickly in some configurations. > > The b44 driver has been pre-allocating bounce buffers in a single large > (~750k) contiguous block. On boxes w/ limited GFP_DMA memory, this > allocation can fail. Such failure results in the driver being unable to > load and function. > > The solution here is to check each tx skb against the DMA mask. If it is > outside the allowable range, a single buffer is allocated from the GFP_DMA > range and discarded after the tx completes. This behaviour mimics what is > done for bounce buffers on the rx side. I think this one is fine and I was expecting Jeff to pick it up and push upstream. From davem@davemloft.net Tue Mar 15 16:55:34 2005 Received: with ECARTIS (v1.0.0; list netdev); Tue, 15 Mar 2005 16:55:38 -0800 (PST) Received: from cheetah.davemloft.net (mail@dsl027-180-174.sfo1.dsl.speakeasy.net [216.27.180.174]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j2G0tXU3031044 for ; Tue, 15 Mar 2005 16:55:33 -0800 Received: from localhost ([127.0.0.1] helo=cheetah.davemloft.net ident=davem) by cheetah.davemloft.net with smtp (Exim 3.36 #1 (Debian)) id 1DBMnB-00038N-00; Tue, 15 Mar 2005 16:53:45 -0800 Date: Tue, 15 Mar 2005 16:53:45 -0800 From: "David S. Miller" To: Andrew Morton Cc: jgarzik@pobox.com, netdev@oss.sgi.com, christoph@graphe.net, nirajk@calsoftinc.com, christoph@lameter.com, Shai@Scalex86.org Subject: Re: [patch 05/13] remove last_rx update from loopback device Message-Id: <20050315165345.735573de.davem@davemloft.net> In-Reply-To: <20050315150809.579c5e85.akpm@osdl.org> References: <200503152222.j2FMMbhG016805@shell0.pdx.osdl.net> <423764A3.8030201@pobox.com> <20050315150809.579c5e85.akpm@osdl.org> X-Mailer: Sylpheed version 1.0.1 (GTK+ 1.2.10; sparc-unknown-linux-gnu) X-Face: "_;p5u5aPsO,_Vsx"^v-pEq09'CU4&Dc1$fQExov$62l60cgCc%FnIwD=.UF^a>?5'9Kn[;433QFVV9M..2eN.@4ZWPGbdi<=?[:T>y?SD(R*-3It"Vj:)"dP Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV 0.83/762/Sun Mar 13 15:35:33 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 225 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: davem@davemloft.net Precedence: bulk X-list: netdev Content-Length: 779 Lines: 25 On Tue, 15 Mar 2005 15:08:09 -0800 Andrew Morton wrote: > Jeff Garzik wrote: > > > > > - dev->last_rx = jiffies; > > > - > > > lb_stats = &per_cpu(loopback_stats, get_cpu()); > > > lb_stats->rx_bytes += skb->len; > > > lb_stats->tx_bytes += skb->len; > > > > I disagree. loopback.c is doing precisely what it should be doing. > > Nothing actually seems to use last_rx? For one thing bonding load balancing uses it. You can argue that bonding of loopback devices is silly. But there are other things one might be able to do with last_rx and the fact that every driver faithfully sets it means that it's a reliable metric to use without special cases. These loopback driver SMP optimizations are starting to really driver me crazy. From brazilnut@us.ibm.com Tue Mar 15 16:56:41 2005 Received: with ECARTIS (v1.0.0; list netdev); Tue, 15 Mar 2005 16:56:47 -0800 (PST) Received: from e4.ny.us.ibm.com (e4.ny.us.ibm.com [32.97.182.144]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j2G0uff8031424 for ; Tue, 15 Mar 2005 16:56:41 -0800 Received: from d01relay02.pok.ibm.com (d01relay02.pok.ibm.com [9.56.227.234]) by e4.ny.us.ibm.com (8.12.11/8.12.11) with ESMTP id j2G0uZtk026517 for ; Tue, 15 Mar 2005 19:56:35 -0500 Received: from d01av04.pok.ibm.com (d01av04.pok.ibm.com [9.56.224.64]) by d01relay02.pok.ibm.com (8.12.10/NCO/VER6.6) with ESMTP id j2G0uZl8057246 for ; Tue, 15 Mar 2005 19:56:35 -0500 Received: from d01av04.pok.ibm.com (loopback [127.0.0.1]) by d01av04.pok.ibm.com (8.12.11/8.12.11) with ESMTP id j2G0uZYR009577 for ; Tue, 15 Mar 2005 19:56:35 -0500 Received: from DYN319661.beaverton.ibm.com (dyn9047022144.beaverton.ibm.com [9.47.22.144]) by d01av04.pok.ibm.com (8.12.11/8.12.11) with ESMTP id j2G0uY1J009562; Tue, 15 Mar 2005 19:56:34 -0500 Received: by DYN319661.beaverton.ibm.com (Postfix, from userid 1000) id B2866229AB0; Tue, 15 Mar 2005 16:56:30 -0800 (PST) Date: Tue, 15 Mar 2005 16:56:30 -0800 From: Don Fry To: akpm@osdl.org Cc: davem@davemloft.net, jgarzik@pobox.com, netdev@oss.sgi.com, steven.hardy@astrium.eads.net Subject: Re: [patch 12/13] pcnet32 79C975 fiber fix Message-ID: <20050316005630.GA9421@us.ibm.com> References: <200503152222.j2FMMiLB016826@shell0.pdx.osdl.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200503152222.j2FMMiLB016826@shell0.pdx.osdl.net> User-Agent: Mutt/1.5.6i X-Virus-Scanned: ClamAV 0.83/762/Sun Mar 13 15:35:33 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 226 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: brazilnut@us.ibm.com Precedence: bulk X-list: netdev Content-Length: 1962 Lines: 51 I had not seen this problem until now. The patch looks ok and probably should have been written that way initially. I have been able to do a quick touch test with a 970A, 971, 972, 973, 975, 976, and 978 (some on ia32 and others on ppc64) without any adverse effects. The 975 I have is copper not fiber. Since only bit 12 is needed to enable LED writes, the code could really be "a->write_bcr(ioaddr, 2, a->read_bcr(ioaddr, 2) | 0x1000);" During pcnet32_open the ASEL bit is changed anyway. This change should also be applied to 2.4.30 as well. On Tue, Mar 15, 2005 at 02:22:48PM -0800, akpm@osdl.org wrote: > > From: "HARDY, Steven" > > I have found a bug in the pcnet32 driver (drivers/net/pcnet32.c) affecting > all ethernet cards based on the AMD79C975 chip, using the fiber interface. > > It's a one line fix, where some config registers get corrupted during > initialisation (which stops the Fiber interface working with this chip) > > This bug was introduced somewhere betweeen 2.4.17 and 2.6.x (noticed whilst > upgrading to 2.6), and it may affect other chips too. I have checked all > versions up to 2.6.11-bk6 and they are all broken. > > Signed-off-by: Andrew Morton > --- > > 25-akpm/drivers/net/pcnet32.c | 3 ++- > 1 files changed, 2 insertions(+), 1 deletion(-) > > diff -puN drivers/net/pcnet32.c~pcnet32-bug-79c975-fiber-fix drivers/net/pcnet32.c > --- 25/drivers/net/pcnet32.c~pcnet32-bug-79c975-fiber-fix Tue Mar 15 14:19:55 2005 > +++ 25-akpm/drivers/net/pcnet32.c Tue Mar 15 14:19:55 2005 > @@ -1351,7 +1351,8 @@ pcnet32_probe1(unsigned long ioaddr, int > printk(KERN_INFO "%s: registered as %s\n", dev->name, lp->name); > cards_found++; > > - a->write_bcr(ioaddr, 2, 0x1002); /* enable LED writes */ > + /* enable LED writes */ > + a->write_bcr(ioaddr, 2, a->read_bcr(ioaddr, 2) | 0x1002); > > return 0; > > _ > -- Don Fry brazilnut@us.ibm.com From akpm@osdl.org Tue Mar 15 17:03:44 2005 Received: with ECARTIS (v1.0.0; list netdev); Tue, 15 Mar 2005 17:03:48 -0800 (PST) Received: from smtp.osdl.org (fire.osdl.org [65.172.181.4]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j2G13hYO032329 for ; Tue, 15 Mar 2005 17:03:43 -0800 Received: from shell0.pdx.osdl.net (fw.osdl.org [65.172.181.6]) by smtp.osdl.org (8.12.8/8.12.8) with ESMTP id j2G13Zqi024465 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO); Tue, 15 Mar 2005 17:03:35 -0800 Received: from bix (shell0.pdx.osdl.net [10.9.0.31]) by shell0.pdx.osdl.net (8.13.1/8.11.6) with SMTP id j2G13Y4w026558; Tue, 15 Mar 2005 17:03:34 -0800 Date: Tue, 15 Mar 2005 17:03:22 -0800 From: Andrew Morton To: Don Fry Cc: davem@davemloft.net, jgarzik@pobox.com, netdev@oss.sgi.com, steven.hardy@astrium.eads.net Subject: Re: [patch 12/13] pcnet32 79C975 fiber fix Message-Id: <20050315170322.3398bd60.akpm@osdl.org> In-Reply-To: <20050316005630.GA9421@us.ibm.com> References: <200503152222.j2FMMiLB016826@shell0.pdx.osdl.net> <20050316005630.GA9421@us.ibm.com> X-Mailer: Sylpheed version 0.9.7 (GTK+ 1.2.10; i386-redhat-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Received-SPF: pass (domain of akpm@osdl.org designates 65.172.181.6 as permitted sender) X-MIMEDefang-Filter: osdl$Revision: 1.105 $ X-Scanned-By: MIMEDefang 2.36 X-Virus-Scanned: ClamAV 0.83/762/Sun Mar 13 15:35:33 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 228 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: akpm@osdl.org Precedence: bulk X-list: netdev Content-Length: 786 Lines: 20 Don Fry wrote: > > I had not seen this problem until now. The patch looks ok and > probably should have been written that way initially. I have been > able to do a quick touch test with a 970A, 971, 972, 973, 975, 976, and > 978 (some on ia32 and others on ppc64) without any adverse effects. > The 975 I have is copper not fiber. Great, thanks. > Since only bit 12 is needed to enable LED writes, the code could > really be "a->write_bcr(ioaddr, 2, a->read_bcr(ioaddr, 2) | 0x1000);" > During pcnet32_open the ASEL bit is changed anyway. OK, could you please prepare a final patch sometime and get it into Jeff? cc me as well please so I can update the patch I have. > This change should also be applied to 2.4.30 as well. And that too, I guess. From fubar@us.ibm.com Tue Mar 15 17:03:25 2005 Received: with ECARTIS (v1.0.0; list netdev); Tue, 15 Mar 2005 17:03:31 -0800 (PST) Received: from e1.ny.us.ibm.com (e1.ny.us.ibm.com [32.97.182.141]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j2G13JDP032314 for ; Tue, 15 Mar 2005 17:03:25 -0800 Received: from d01relay02.pok.ibm.com (d01relay02.pok.ibm.com [9.56.227.234]) by e1.ny.us.ibm.com (8.12.11/8.12.11) with ESMTP id j2G13A4D017287 for ; Tue, 15 Mar 2005 20:03:10 -0500 Received: from d01av02.pok.ibm.com (d01av02.pok.ibm.com [9.56.224.216]) by d01relay02.pok.ibm.com (8.12.10/NCO/VER6.6) with ESMTP id j2G13Al8089842 for ; Tue, 15 Mar 2005 20:03:10 -0500 Received: from d01av02.pok.ibm.com (loopback [127.0.0.1]) by d01av02.pok.ibm.com (8.12.11/8.12.11) with ESMTP id j2G13Asj008498 for ; Tue, 15 Mar 2005 20:03:10 -0500 Received: from death.nxdomain.ibm.com (sig-9-65-58-81.mts.ibm.com [9.65.58.81]) by d01av02.pok.ibm.com (8.12.11/8.12.11) with ESMTP id j2G139H1008492; Tue, 15 Mar 2005 20:03:09 -0500 Received: from death.nxdomain.ibm.com (localhost [127.0.0.1]) by death.nxdomain.ibm.com (8.12.8/8.12.8) with ESMTP id j2G132Nn017006; Tue, 15 Mar 2005 17:03:04 -0800 Received: from death (fubar@localhost) by death.nxdomain.ibm.com (8.12.8/8.12.8/Submit) with ESMTP id j2G132YO016999; Tue, 15 Mar 2005 17:03:02 -0800 Message-Id: <200503160103.j2G132YO016999@death.nxdomain.ibm.com> To: Rick Jones cc: "John W. Linville" , linux-kernel@vger.kernel.org, ctindel@users.sourceforge.net, bonding-devel@lists.sourceforge.net, netdev@oss.sgi.com, jgarzik@pobox.com Subject: Re: [patch 2.6.11] bonding: avoid tx balance for IGMP (alb/tlb mode) In-Reply-To: Message from Rick Jones of "Tue, 15 Mar 2005 16:52:14 PST." <4237833E.9080809@hp.com> X-Mailer: MH-E 7.82; nmh 1.0.4; GNU Emacs 21.3.1 Date: Tue, 15 Mar 2005 17:03:01 -0800 From: Jay Vosburgh X-Virus-Scanned: ClamAV 0.83/762/Sun Mar 13 15:35:33 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 227 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: fubar@us.ibm.com Precedence: bulk X-list: netdev Content-Length: 1093 Lines: 26 Rick Jones wrote: > treats IGMP packets the same as all other non-broadcast traffic (i.e. it >will attempt to load balance). This switch behavior seems rather odd in an >aggregated case, given the fact that most traffic (except broadcast packets) >will be load balanced by the partner device. In addition, the switch (in >theory) is suppose to treat the aggregated switch ports as 1 logical port >and therefore it should allow IGMP packets to be received back on any port >in the logical aggregation. > >IMO, the switch behavior in this case seems questionable. This patch only applies to the bonding balance-alb/tlb modes, which do not require the switch to be configured for aggregation. Since the switch has no explicit knowledge that the links are being aggregated, it seems reasonable for it to be confused by what it gets in the described case. I haven't tested the patch, but conceptually the problem John described in his original mail sounds plausible, as does the fix for it. -J --- -Jay Vosburgh, IBM Linux Technology Center, fubar@us.ibm.com From rick.jones2@hp.com Tue Mar 15 17:04:29 2005 Received: with ECARTIS (v1.0.0; list netdev); Tue, 15 Mar 2005 17:04:34 -0800 (PST) Received: from palrel11.hp.com (palrel11.hp.com [156.153.255.246]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j2G14SfG032731 for ; Tue, 15 Mar 2005 17:04:28 -0800 Received: from tardy.cup.hp.com (tardy.cup.hp.com [15.244.44.58]) by palrel11.hp.com (Postfix) with ESMTP id 66FF4776A; Tue, 15 Mar 2005 17:04:28 -0800 (PST) Received: from hp.com (localhost [127.0.0.1]) by tardy.cup.hp.com (8.9.3 (PHNE_28810)/8.9.3 SMKit7.02) with ESMTP id RAA27131; Tue, 15 Mar 2005 17:04:24 -0800 (PST) Message-ID: <42378617.3080600@hp.com> Date: Tue, 15 Mar 2005 17:04:23 -0800 From: Rick Jones User-Agent: Mozilla/5.0 (X11; U; HP-UX 9000/785; en-US; rv:1.6) Gecko/20040304 X-Accept-Language: en-us, en MIME-Version: 1.0 To: "David S. Miller" Cc: Andrew Morton , jgarzik@pobox.com, netdev@oss.sgi.com, christoph@graphe.net, nirajk@calsoftinc.com, christoph@lameter.com, Shai@Scalex86.org Subject: Re: [patch 05/13] remove last_rx update from loopback device References: <200503152222.j2FMMbhG016805@shell0.pdx.osdl.net> <423764A3.8030201@pobox.com> <20050315150809.579c5e85.akpm@osdl.org> <20050315165345.735573de.davem@davemloft.net> In-Reply-To: <20050315165345.735573de.davem@davemloft.net> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV 0.83/762/Sun Mar 13 15:35:33 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 229 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: rick.jones2@hp.com Precedence: bulk X-list: netdev Content-Length: 570 Lines: 13 > These loopback driver SMP optimizations are starting to really > driver me crazy. Correct or not, I suspect there are a non-trivial number of folks out there who use loopback performance as an indicator of over the network performance or at least of stack path length (less driver). particularly when they have only one system and want to make quick (and so worth all the time they put into it) comparisons between OSes. Perhaps that is a driver-ing (since punning drive/driver seems to be the order N squared of the day) force behind the changes? rick jones From davem@davemloft.net Tue Mar 15 17:19:38 2005 Received: with ECARTIS (v1.0.0; list netdev); Tue, 15 Mar 2005 17:19:44 -0800 (PST) Received: from cheetah.davemloft.net (mail@dsl027-180-174.sfo1.dsl.speakeasy.net [216.27.180.174]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j2G1JcA8001891 for ; Tue, 15 Mar 2005 17:19:38 -0800 Received: from localhost ([127.0.0.1] helo=cheetah.davemloft.net ident=davem) by cheetah.davemloft.net with smtp (Exim 3.36 #1 (Debian)) id 1DBNAI-0003EV-00; Tue, 15 Mar 2005 17:17:38 -0800 Date: Tue, 15 Mar 2005 17:17:38 -0800 From: "David S. Miller" To: Rick Jones Cc: akpm@osdl.org, jgarzik@pobox.com, netdev@oss.sgi.com, christoph@graphe.net, nirajk@calsoftinc.com, christoph@lameter.com, Shai@Scalex86.org Subject: Re: [patch 05/13] remove last_rx update from loopback device Message-Id: <20050315171738.29ad1eed.davem@davemloft.net> In-Reply-To: <42378617.3080600@hp.com> References: <200503152222.j2FMMbhG016805@shell0.pdx.osdl.net> <423764A3.8030201@pobox.com> <20050315150809.579c5e85.akpm@osdl.org> <20050315165345.735573de.davem@davemloft.net> <42378617.3080600@hp.com> X-Mailer: Sylpheed version 1.0.1 (GTK+ 1.2.10; sparc-unknown-linux-gnu) X-Face: "_;p5u5aPsO,_Vsx"^v-pEq09'CU4&Dc1$fQExov$62l60cgCc%FnIwD=.UF^a>?5'9Kn[;433QFVV9M..2eN.@4ZWPGbdi<=?[:T>y?SD(R*-3It"Vj:)"dP Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV 0.83/762/Sun Mar 13 15:35:33 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 230 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: davem@davemloft.net Precedence: bulk X-list: netdev Content-Length: 351 Lines: 9 On Tue, 15 Mar 2005 17:04:23 -0800 Rick Jones wrote: > Perhaps that is a driver-ing (since punning drive/driver seems to be the order N > squared of the day) force behind the changes? Every time the SGI guys with the 512 cpu machine find some shared memory reference they think they can legitimately remove, they try to do so. From niv@us.ibm.com Tue Mar 15 17:23:38 2005 Received: with ECARTIS (v1.0.0; list netdev); Tue, 15 Mar 2005 17:23:44 -0800 (PST) Received: from e35.co.us.ibm.com (e35.co.us.ibm.com [32.97.110.133]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j2G1NYkd002467 for ; Tue, 15 Mar 2005 17:23:34 -0800 Received: from westrelay02.boulder.ibm.com (westrelay02.boulder.ibm.com [9.17.195.11]) by e35.co.us.ibm.com (8.12.10/8.12.9) with ESMTP id j2G1NSLg294240 for ; Tue, 15 Mar 2005 20:23:28 -0500 Received: from d03av02.boulder.ibm.com (d03av02.boulder.ibm.com [9.17.195.168]) by westrelay02.boulder.ibm.com (8.12.10/NCO/VER6.6) with ESMTP id j2G1NSTl218162 for ; Tue, 15 Mar 2005 18:23:28 -0700 Received: from d03av02.boulder.ibm.com (loopback [127.0.0.1]) by d03av02.boulder.ibm.com (8.12.11/8.12.11) with ESMTP id j2G1NRaM030124 for ; Tue, 15 Mar 2005 18:23:28 -0700 Received: from [9.47.22.102] (IBM-UFKG5CEJ4KK.beaverton.ibm.com [9.47.22.102]) by d03av02.boulder.ibm.com (8.12.11/8.12.11) with ESMTP id j2G1NQb7030097; Tue, 15 Mar 2005 18:23:26 -0700 Message-ID: <42378A8D.7090801@us.ibm.com> Date: Tue, 15 Mar 2005 17:23:25 -0800 From: Nivedita Singhvi User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.5) Gecko/20041217 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Rick Jones CC: "David S. Miller" , Andrew Morton , jgarzik@pobox.com, netdev@oss.sgi.com, christoph@graphe.net, nirajk@calsoftinc.com, christoph@lameter.com, Shai@Scalex86.org Subject: Re: [patch 05/13] remove last_rx update from loopback device References: <200503152222.j2FMMbhG016805@shell0.pdx.osdl.net> <423764A3.8030201@pobox.com> <20050315150809.579c5e85.akpm@osdl.org> <20050315165345.735573de.davem@davemloft.net> <42378617.3080600@hp.com> In-Reply-To: <42378617.3080600@hp.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV 0.83/762/Sun Mar 13 15:35:33 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 231 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: niv@us.ibm.com Precedence: bulk X-list: netdev Content-Length: 676 Lines: 20 Rick Jones wrote: >> These loopback driver SMP optimizations are starting to really >> driver me crazy. > > > Correct or not, I suspect there are a non-trivial number of folks out > there who use loopback performance as an indicator of over the network > performance or at least of stack path length (less driver). I hope not the former. Given that loopback performance is *significantly* faster than network performance, increasing the performance of the loopback driver in these somewhat artificial ways (that differ from the real network device path) simply *increases* the inaccuracy of their testing and the conclusions they can draw from it ;). thanks, Nivedita From rick.jones2@hp.com Tue Mar 15 17:49:32 2005 Received: with ECARTIS (v1.0.0; list netdev); Tue, 15 Mar 2005 17:49:37 -0800 (PST) Received: from palrel12.hp.com (palrel12.hp.com [156.153.255.237]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j2G1nWBG003631 for ; Tue, 15 Mar 2005 17:49:32 -0800 Received: from tardy.cup.hp.com (tardy.cup.hp.com [15.244.44.58]) by palrel12.hp.com (Postfix) with ESMTP id 4FD8F4002C9; Tue, 15 Mar 2005 17:49:27 -0800 (PST) Received: from hp.com (localhost [127.0.0.1]) by tardy.cup.hp.com (8.9.3 (PHNE_28810)/8.9.3 SMKit7.02) with ESMTP id RAA27510; Tue, 15 Mar 2005 17:49:23 -0800 (PST) Message-ID: <423790A2.2000906@hp.com> Date: Tue, 15 Mar 2005 17:49:22 -0800 From: Rick Jones User-Agent: Mozilla/5.0 (X11; U; HP-UX 9000/785; en-US; rv:1.6) Gecko/20040304 X-Accept-Language: en-us, en MIME-Version: 1.0 To: netdev@oss.sgi.com Cc: jgarzik@pobox.com, christoph@graphe.net, nirajk@calsoftinc.com, christoph@lameter.com, Shai@Scalex86.org Subject: Re: [patch 05/13] remove last_rx update from loopback device References: <200503152222.j2FMMbhG016805@shell0.pdx.osdl.net> <423764A3.8030201@pobox.com> <20050315150809.579c5e85.akpm@osdl.org> <20050315165345.735573de.davem@davemloft.net> <42378617.3080600@hp.com> <42378A8D.7090801@us.ibm.com> In-Reply-To: <42378A8D.7090801@us.ibm.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV 0.83/762/Sun Mar 13 15:35:33 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 232 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: rick.jones2@hp.com Precedence: bulk X-list: netdev Content-Length: 1316 Lines: 35 Nivedita Singhvi wrote: > Rick Jones wrote: > >>> These loopback driver SMP optimizations are starting to really >>> driver me crazy. >> >> >> >> Correct or not, I suspect there are a non-trivial number of folks out >> there who use loopback performance as an indicator of over the network >> performance or at least of stack path length (less driver). > > > I hope not the former. Given that loopback performance is > *significantly* faster than network performance, increasing the > performance of the loopback driver in these somewhat artificial > ways (that differ from the real network device path) simply > *increases* the inaccuracy of their testing and the conclusions > they can draw from it ;). I suspect the idea is that if loopback on Platform A is faster than loopback on Platform B, then over the network will be faster (or at least more efficient) on Platform A than it is on Platform B. It is indeed fraught with numerous pitfalls - different MTU's, shorticircuting at different places etc etc. I do not claim to condone (even if I'm sometimes forced into that situation myself :( ) merely to explain. As for the 512 CPU machine mentioned in another message, at the rate cores per die may increase over the next few years, that may not really be all that large a box... :) rick jones From mcgrof@ruslug.rutgers.edu Tue Mar 15 21:48:53 2005 Received: with ECARTIS (v1.0.0; list netdev); Tue, 15 Mar 2005 21:48:57 -0800 (PST) Received: from ruslug.rutgers.edu (ruslug.rutgers.edu [128.6.24.131]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j2G5mrek016824 for ; Tue, 15 Mar 2005 21:48:53 -0800 Received: by ruslug.rutgers.edu (Postfix, from userid 503) id 68825F98AC; Wed, 16 Mar 2005 00:48:52 -0500 (EST) Date: Wed, 16 Mar 2005 00:48:52 -0500 To: linux-kernel@vger.kernel.org, Netdev , prism54-devel@prism54.org Cc: Margit Schubert-While Subject: Where is Margit Schubert-While? Message-ID: <20050316054852.GK17854@ruslug.rutgers.edu> Mail-Followup-To: linux-kernel@vger.kernel.org, Netdev , prism54-devel@prism54.org, Margit Schubert-While Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="2F7AbV2suvT8PGoH" Content-Disposition: inline User-Agent: Mutt/1.3.28i X-Operating-System: 2.4.18-1-686 Organization: Rutgers University Student Linux Users Group From: mcgrof@ruslug.rutgers.edu (Luis R. Rodriguez) X-Virus-Scanned: ClamAV 0.83/762/Sun Mar 13 15:35:33 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 233 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: mcgrof@ruslug.rutgers.edu Precedence: bulk X-list: netdev Content-Length: 718 Lines: 29 --2F7AbV2suvT8PGoH Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Anyone heard of Margit Schubert recently? I have stopped hearing from her. She was actively working on prism54 and all of a sudden disappeared. IIRC her husband last told me she was sick... Luis --=20 GnuPG Key fingerprint =3D 113F B290 C6D2 0251 4D84 A34A 6ADD 4937 E20A 525E --2F7AbV2suvT8PGoH Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.4 (GNU/Linux) iD8DBQFCN8jEat1JN+IKUl4RAvjRAKCreEwFA+VpMY5RMSVarfZtpuK0DQCffPHx uIN4IY0JA8oWgmEIXPm8g+U= =gjaZ -----END PGP SIGNATURE----- --2F7AbV2suvT8PGoH-- From akpm@osdl.org Tue Mar 15 23:27:34 2005 Received: with ECARTIS (v1.0.0; list netdev); Tue, 15 Mar 2005 23:27:40 -0800 (PST) Received: from smtp.osdl.org (fire.osdl.org [65.172.181.4]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j2G7RYY1021028 for ; Tue, 15 Mar 2005 23:27:34 -0800 Received: from shell0.pdx.osdl.net (fw.osdl.org [65.172.181.6]) by smtp.osdl.org (8.12.8/8.12.8) with ESMTP id j2G7R2qi020168 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO); Tue, 15 Mar 2005 23:27:02 -0800 Received: from bix (shell0.pdx.osdl.net [10.9.0.31]) by shell0.pdx.osdl.net (8.13.1/8.11.6) with SMTP id j2G7R18Q006200; Tue, 15 Mar 2005 23:27:01 -0800 Date: Tue, 15 Mar 2005 23:26:51 -0800 From: Andrew Morton To: davem@davemloft.net, jgarzik@pobox.com, netdev@oss.sgi.com, oray@lucent.com Subject: Re: [patch 06/13] ppc 8260 fcc ethernet driver cannot read LXT971 PHY id Message-Id: <20050315232651.3fd10b13.akpm@osdl.org> In-Reply-To: <200503152222.j2FMMccq016808@shell0.pdx.osdl.net> References: <200503152222.j2FMMccq016808@shell0.pdx.osdl.net> X-Mailer: Sylpheed version 0.9.7 (GTK+ 1.2.10; i386-redhat-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Received-SPF: pass (domain of akpm@osdl.org designates 65.172.181.6 as permitted sender) X-MIMEDefang-Filter: osdl$Revision: 1.105 $ X-Scanned-By: MIMEDefang 2.36 X-Virus-Scanned: ClamAV 0.83/762/Sun Mar 13 15:35:33 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 234 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: akpm@osdl.org Precedence: bulk X-list: netdev Content-Length: 794 Lines: 21 akpm@osdl.org wrote: > > From: "Balasaygun, Oray (Oray)" > > - fix for Bug 4310 > > - The fcc_enet.c, as distributed in 2.6.10, does not compile. Evidently > the 2.6 kernel no longer supports the schedule_task() and "struct > tq_struct" to go with it. Lines 73 through and including 96 of the > diffout file show the changes I made to port schedule_task() into > tasklet_schedule(). I should have reported this as a bug too but I > forgot about it. > > - customize fcc_enet.c to work with my custom board. These changes are > conditional on CONFIG_EON8260 being defined. Jeff, don't apply this please - we're getting a bunch of patches for this driver coming from another direction (mvista, freescale.com). Will take some time to sort through. From horms@koto.vergenet.net Wed Mar 16 01:54:00 2005 Received: with ECARTIS (v1.0.0; list netdev); Wed, 16 Mar 2005 01:54:06 -0800 (PST) Received: from koto.vergenet.net (koto.vergenet.net [210.128.90.7]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j2G9s0Vm030313 for ; Wed, 16 Mar 2005 01:54:00 -0800 Received: by koto.vergenet.net (Postfix, from userid 7100) id 10B4D34031; Wed, 16 Mar 2005 18:31:14 +0900 (JST) Date: Wed, 16 Mar 2005 11:37:54 +0900 From: Horms To: bert hubert , netdev@oss.sgi.com Subject: Re: bridge between ppp and ethernet - 1 IP address and assign it to another host Message-ID: <20050316023752.GS23777@verge.net.au> Mail-Followup-To: bert hubert , netdev@oss.sgi.com References: <20050305220429.GA9335@outpost.ds9a.nl> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20050305220429.GA9335@outpost.ds9a.nl> X-Cluestick: seven User-Agent: Mutt/1.5.6+20040907i X-Virus-Scanned: ClamAV 0.83/762/Sun Mar 13 15:35:33 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 235 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: horms@verge.net.au Precedence: bulk X-list: netdev Content-Length: 1155 Lines: 32 On Sat, Mar 05, 2005 at 11:04:30PM +0100, bert hubert wrote: > Hi people, > > I have an application that wants a Real IP Address, but for a variety of > good reasons, I can't connect the machine to the internet directly. > > So, I need this: > > DSL - Linux - Windows PC > > Where I need the Windows PC to think it has the real single IP addres > assigned to me by the DSL provider. I run PPTP on the Linux box, which > should not touch traffic for that IP address. > > Now I know that several DSL routers are capable of this stunt, so we should > be able to do this too. But how? > > Linux is pretty stubborn in routing packets for its own IP address elsewhere > (rightfully so). I previously spent some time on this with a lot of > SNAT/DNAT trickery but it is not very pleasing, nor did it work. > > What we're trying to do is a lot like building a bridge between ethernet and > ppp, but not quite. > > Anybody have ideas? If we find something I'll post it on http://lartc.org. Have you tried using LVS with Direct Routing? It might do the trick as long as the Windows PC can route outgoing packets directly through the DLS router. -- Horms From dlstevens@us.ibm.com Wed Mar 16 01:59:17 2005 Received: with ECARTIS (v1.0.0; list netdev); Wed, 16 Mar 2005 01:59:22 -0800 (PST) Received: from e35.co.us.ibm.com (e35.co.us.ibm.com [32.97.110.133]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j2G9xH3t031090; Wed, 16 Mar 2005 01:59:17 -0800 Received: from d03relay05.boulder.ibm.com (d03relay05.boulder.ibm.com [9.17.195.107]) by e35.co.us.ibm.com (8.12.10/8.12.9) with ESMTP id j2G9xBLg479242; Wed, 16 Mar 2005 04:59:11 -0500 Received: from d03av03.boulder.ibm.com (d03av03.boulder.ibm.com [9.17.195.169]) by d03relay05.boulder.ibm.com (8.12.10/NCO/VER6.6) with ESMTP id j2G9xAw8181766; Wed, 16 Mar 2005 02:59:10 -0700 Received: from d03av03.boulder.ibm.com (loopback [127.0.0.1]) by d03av03.boulder.ibm.com (8.12.11/8.12.11) with ESMTP id j2G9xAvm003576; Wed, 16 Mar 2005 02:59:10 -0700 Received: from d03nm121.boulder.ibm.com (d03nm121.boulder.ibm.com [9.17.195.147]) by d03av03.boulder.ibm.com (8.12.11/8.12.11) with ESMTP id j2G9xAVn003570; Wed, 16 Mar 2005 02:59:10 -0700 In-Reply-To: <200503160103.j2G132YO016999@death.nxdomain.ibm.com> To: fubar@us.ibm.com Cc: bonding-devel@lists.sourceforge.net, ctindel@users.sourceforge.net, jgarzik@pobox.com, linux-kernel@vger.kernel.org, "John W. Linville" , netdev@oss.sgi.com, netdev-bounce@oss.sgi.com, Rick Jones MIME-Version: 1.0 Subject: Re: [patch 2.6.11] bonding: avoid tx balance for IGMP (alb/tlb mode) X-Mailer: Lotus Notes Release 6.0.2CF1 June 9, 2003 Message-ID: From: David Stevens Date: Wed, 16 Mar 2005 01:59:08 -0800 X-MIMETrack: Serialize by Router on D03NM121/03/M/IBM(Release 6.53HF294 | January 28, 2005) at 03/16/2005 02:59:10, Serialize complete at 03/16/2005 02:59:10 Content-Type: text/plain; charset="US-ASCII" X-Virus-Scanned: ClamAV 0.83/762/Sun Mar 13 15:35:33 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 236 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: dlstevens@us.ibm.com Precedence: bulk X-list: netdev Content-Length: 201 Lines: 6 I didn't look to see if there's a case in that switch for IPv6, but MLD will have the same issue with switches, and probably needs a similar exception. +-DLS From ralf@linux-mips.org Wed Mar 16 02:28:21 2005 Received: with ECARTIS (v1.0.0; list netdev); Wed, 16 Mar 2005 02:28:25 -0800 (PST) Received: from mail.linux-mips.net (extgw-uk.mips.com [62.254.210.129]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j2GASJtT032623 for ; Wed, 16 Mar 2005 02:28:20 -0800 Received: from dea.linux-mips.net (localhost.localdomain [127.0.0.1]) by mail.linux-mips.net (8.13.1/8.13.1) with ESMTP id j2GAQklq007607; Wed, 16 Mar 2005 10:26:52 GMT Received: (from ralf@localhost) by dea.linux-mips.net (8.13.1/8.13.1/Submit) id j2G8YkM0020398; Wed, 16 Mar 2005 08:34:46 GMT Date: Wed, 16 Mar 2005 08:34:46 +0000 From: Ralf Baechle DL5RB To: netdev@oss.sgi.com, linux-hams@vger.kernel.org Cc: "David S. Miller" Subject: [PATCH] Use skb_queue_purge Message-ID: <20050316083446.GA20392@linux-mips.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.4.1i X-Virus-Scanned: ClamAV 0.83/762/Sun Mar 13 15:35:33 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 237 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: ralf@linux-mips.org Precedence: bulk X-list: netdev Content-Length: 505 Lines: 17 skb_queue_purge exists so why not using it ;-) Index: bk-afu/net/ax25/af_ax25.c =================================================================== --- bk-afu.orig/net/ax25/af_ax25.c 2005-03-15 23:26:35.678081272 +0000 +++ bk-afu/net/ax25/af_ax25.c 2005-03-15 23:38:31.979186952 +0000 @@ -306,9 +306,7 @@ kfree_skb(skb); } - while ((skb = skb_dequeue(&ax25->sk->sk_write_queue)) != NULL) { - kfree_skb(skb); - } + skb_queue_purge(&ax25->sk->sk_write_queue); } if (ax25->sk != NULL) { From dada1@cosmosbay.com Wed Mar 16 02:47:48 2005 Received: with ECARTIS (v1.0.0; list netdev); Wed, 16 Mar 2005 02:47:53 -0800 (PST) Received: from gw1.cosmosbay.com (gw1.cosmosbay.com [62.23.185.226]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j2GAliD6003367 for ; Wed, 16 Mar 2005 02:47:47 -0800 Received: from [172.16.0.131] (edumazet-port [172.16.0.131]) by gw1.cosmosbay.com (8.13.3/8.13.3) with ESMTP id j2GAlSAj030666; Wed, 16 Mar 2005 11:47:29 +0100 Message-ID: <42380EC6.60100@cosmosbay.com> Date: Wed, 16 Mar 2005 11:47:34 +0100 From: Eric Dumazet User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.3) Gecko/20040910 X-Accept-Language: fr, en-us, en MIME-Version: 1.0 To: "David S. Miller" CC: netdev@oss.sgi.com Subject: [BUG] overflow in net/ipv4/route.c rt_check_expire() References: <42370997.6010302@cosmosbay.com> <20050315103253.590c8bfc.davem@davemloft.net> In-Reply-To: <20050315103253.590c8bfc.davem@davemloft.net> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-1.6 (gw1.cosmosbay.com [172.16.8.80]); Wed, 16 Mar 2005 11:47:30 +0100 (CET) X-Virus-Scanned: ClamAV 0.83/762/Sun Mar 13 15:35:33 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 238 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: dada1@cosmosbay.com Precedence: bulk X-list: netdev Content-Length: 958 Lines: 27 After having hard times tuning /proc/sys/net/ipv4/route/* values, with various crashes of production machines, I did some investigations... The rt_check_expire() has a serious problem on machines with large route caches, and a standard HZ value of 1000. With default values, ie ip_rt_gc_interval = 60*HZ = 60000 ; the loop count : for (t = ip_rt_gc_interval << rt_hash_log; t >= 0; overflows (t is a 31 bit value) as soon rt_hash_log is >= 16 (65536 slots in route cache hash table) Another problem is the fact that this function has close to 0 effect, because even if ip_rt_gc_interval is changed to 1 HZ, only 1/300 of the table is scanned every second. And the loop breaks as soon a jiffie is consumed. We should adapt the loop count based on the actual number of entries in the route cache, and eventually give more 'jiffies' in some pressure cases. I am experimenting some changes that I will share when ready. Thank you Eric Dumazet From herbert@gondor.apana.org.au Wed Mar 16 02:52:56 2005 Received: with ECARTIS (v1.0.0; list netdev); Wed, 16 Mar 2005 02:53:04 -0800 (PST) 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 j2GAqqlu003977 for ; Wed, 16 Mar 2005 02:52:53 -0800 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 1DBW7q-0007uL-00; Wed, 16 Mar 2005 21:51:42 +1100 Received: from herbert by gondolin.me.apana.org.au with local (Exim 3.36 #1 (Debian)) id 1DBW7A-0002C6-00; Wed, 16 Mar 2005 21:51:00 +1100 Date: Wed, 16 Mar 2005 21:51:00 +1100 To: Patrick McHardy Cc: "David S. Miller" , kuznet@ms2.inr.ac.ru, yoshfuji@linux-ipv6.org, netdev@oss.sgi.com Subject: [IPV4] Make ipt_REJECT use icmp_send again Message-ID: <20050316105100.GA8404@gondor.apana.org.au> References: <20050314102614.GA9610@gondor.apana.org.au> <20050314105313.GA21001@gondor.apana.org.au> <20050314111002.GA29156@gondor.apana.org.au> <20050315091904.GA6256@gondor.apana.org.au> <20050315095837.GA7130@gondor.apana.org.au> <20050315100522.GA7275@gondor.apana.org.au> <20050315102450.0f3f1618.davem@davemloft.net> <42373142.6090902@trash.net> <20050315204006.GB22349@gondor.apana.org.au> <42374A35.6020308@trash.net> Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="6TrnltStXW4iwmi0" Content-Disposition: inline In-Reply-To: <42374A35.6020308@trash.net> User-Agent: Mutt/1.5.6+20040907i From: Herbert Xu X-Virus-Scanned: ClamAV 0.83/762/Sun Mar 13 15:35:33 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 239 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: herbert@gondor.apana.org.au Precedence: bulk X-list: netdev Content-Length: 6550 Lines: 246 --6TrnltStXW4iwmi0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline On Tue, Mar 15, 2005 at 09:48:53PM +0100, Patrick McHardy wrote: > > Ok. I can't see any different reason to keep it, so go ahead. I'll take > care of the xrlim stuff later. Great. Here is the patch that makes ipt_REJECT use icmp_send again. We've gone full circle :) As it is ipt_REJECT doesn't work at all with IPsec. Despite my efforts previously in making the policy lookups work there I neglected to change the final call to dst_output so the policy lookup is useless. ipt_REJECT also had a number of deviations from icmp_send which seems to be unjustified. For examples it ignored source routing IP options. There was a bug in icmp_send too :) It didn't set the ICMP type/code values for the policy lookup. Signed-off-by: Herbert Xu I compared the two functions line-by-line to make sure that there weren't any subtle differences. Please double check this in case I overlooked something important. Cheers, -- Visit Openswan at http://www.openswan.org/ Email: Herbert Xu ~{PmV>HI~} Home Page: http://gondor.apana.org.au/~herbert/ PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt --6TrnltStXW4iwmi0 Content-Type: text/plain; charset=us-ascii Content-Disposition: attachment; filename=xfrm-18 ===== net/ipv4/icmp.c 1.50 vs edited ===== --- 1.50/net/ipv4/icmp.c 2005-03-15 16:26:11 +11:00 +++ edited/net/ipv4/icmp.c 2005-03-16 21:20:41 +11:00 @@ -518,14 +518,6 @@ IPTOS_PREC_INTERNETCONTROL) : iph->tos; - { - struct flowi fl = { .nl_u = { .ip4_u = { .daddr = iph->saddr, - .saddr = saddr, - .tos = RT_TOS(tos) } }, - .proto = IPPROTO_ICMP }; - if (ip_route_output_key(&rt, &fl)) - goto out_unlock; - } if (ip_options_echo(&icmp_param.replyopts, skb_in)) goto ende; @@ -544,13 +536,26 @@ inet_sk(icmp_socket->sk)->tos = tos; ipc.addr = iph->saddr; ipc.opt = &icmp_param.replyopts; - if (icmp_param.replyopts.srr) { - struct flowi fl = { .nl_u = { .ip4_u = - { .daddr = icmp_param.replyopts.faddr, - .saddr = saddr, - .tos = RT_TOS(tos) } }, - .proto = IPPROTO_ICMP }; - ip_rt_put(rt); + + { + struct flowi fl = { + .nl_u = { + .ip4_u = { + .daddr = icmp_param.replyopts.srr ? + icmp_param.replyopts.faddr : + iph->saddr, + .saddr = saddr, + .tos = RT_TOS(tos) + } + }, + .proto = IPPROTO_ICMP, + .uli_u = { + .icmpt = { + .type = type, + .code = code + } + } + }; if (ip_route_output_key(&rt, &fl)) goto out_unlock; } ===== net/ipv4/netfilter/ipt_REJECT.c 1.35 vs edited ===== --- 1.35/net/ipv4/netfilter/ipt_REJECT.c 2005-03-04 09:20:32 +11:00 +++ edited/net/ipv4/netfilter/ipt_REJECT.c 2005-03-16 21:19:20 +11:00 @@ -220,146 +220,9 @@ kfree_skb(nskb); } -static void send_unreach(struct sk_buff *skb_in, int code) +static inline void send_unreach(struct sk_buff *skb_in, int code) { - struct iphdr *iph; - struct icmphdr *icmph; - struct sk_buff *nskb; - u32 saddr; - u8 tos; - int hh_len, length; - struct rtable *rt = (struct rtable*)skb_in->dst; - unsigned char *data; - - if (!rt) - return; - - /* FIXME: Use sysctl number. --RR */ - if (!xrlim_allow(&rt->u.dst, 1*HZ)) - return; - - iph = skb_in->nh.iph; - - /* No replies to physical multicast/broadcast */ - if (skb_in->pkt_type!=PACKET_HOST) - return; - - /* Now check at the protocol level */ - if (rt->rt_flags&(RTCF_BROADCAST|RTCF_MULTICAST)) - return; - - /* Only reply to fragment 0. */ - if (iph->frag_off&htons(IP_OFFSET)) - return; - - /* If we send an ICMP error to an ICMP error a mess would result.. */ - if (iph->protocol == IPPROTO_ICMP) { - struct icmphdr ihdr; - - icmph = skb_header_pointer(skb_in, skb_in->nh.iph->ihl*4, - sizeof(ihdr), &ihdr); - if (!icmph) - return; - - /* Between echo-reply (0) and timestamp (13), - everything except echo-request (8) is an error. - Also, anything greater than NR_ICMP_TYPES is - unknown, and hence should be treated as an error... */ - if ((icmph->type < ICMP_TIMESTAMP - && icmph->type != ICMP_ECHOREPLY - && icmph->type != ICMP_ECHO) - || icmph->type > NR_ICMP_TYPES) - return; - } - - saddr = iph->daddr; - if (!(rt->rt_flags & RTCF_LOCAL)) - saddr = 0; - - tos = (iph->tos & IPTOS_TOS_MASK) | IPTOS_PREC_INTERNETCONTROL; - - { - struct flowi fl = { - .nl_u = { - .ip4_u = { - .daddr = skb_in->nh.iph->saddr, - .saddr = saddr, - .tos = RT_TOS(tos) - } - }, - .proto = IPPROTO_ICMP, - .uli_u = { - .icmpt = { - .type = ICMP_DEST_UNREACH, - .code = code - } - } - }; - - if (ip_route_output_key(&rt, &fl)) - return; - } - /* RFC says return as much as we can without exceeding 576 bytes. */ - length = skb_in->len + sizeof(struct iphdr) + sizeof(struct icmphdr); - - if (length > dst_pmtu(&rt->u.dst)) - length = dst_pmtu(&rt->u.dst); - if (length > 576) - length = 576; - - hh_len = LL_RESERVED_SPACE(rt->u.dst.dev); - - nskb = alloc_skb(hh_len + length, GFP_ATOMIC); - if (!nskb) { - ip_rt_put(rt); - return; - } - - nskb->priority = 0; - nskb->dst = &rt->u.dst; - skb_reserve(nskb, hh_len); - - /* Set up IP header */ - iph = nskb->nh.iph - = (struct iphdr *)skb_put(nskb, sizeof(struct iphdr)); - iph->version=4; - iph->ihl=5; - iph->tos=tos; - iph->tot_len = htons(length); - - /* PMTU discovery never applies to ICMP packets. */ - iph->frag_off = 0; - - iph->ttl = MAXTTL; - ip_select_ident(iph, &rt->u.dst, NULL); - iph->protocol=IPPROTO_ICMP; - iph->saddr=rt->rt_src; - iph->daddr=rt->rt_dst; - iph->check=0; - iph->check = ip_fast_csum((unsigned char *)iph, iph->ihl); - - /* Set up ICMP header. */ - icmph = nskb->h.icmph - = (struct icmphdr *)skb_put(nskb, sizeof(struct icmphdr)); - icmph->type = ICMP_DEST_UNREACH; - icmph->code = code; - icmph->un.gateway = 0; - icmph->checksum = 0; - - /* Copy as much of original packet as will fit */ - data = skb_put(nskb, - length - sizeof(struct iphdr) - sizeof(struct icmphdr)); - - skb_copy_bits(skb_in, 0, data, - length - sizeof(struct iphdr) - sizeof(struct icmphdr)); - - icmph->checksum = ip_compute_csum((unsigned char *)icmph, - length - sizeof(struct iphdr)); - - nf_ct_attach(nskb, skb_in); - - NF_HOOK(PF_INET, NF_IP_LOCAL_OUT, nskb, NULL, nskb->dst->dev, - ip_finish_output); + icmp_send(skb_in, ICMP_DEST_UNREACH, code, 0); } static unsigned int reject(struct sk_buff **pskb, --6TrnltStXW4iwmi0-- From herbert@gondor.apana.org.au Wed Mar 16 03:33:00 2005 Received: with ECARTIS (v1.0.0; list netdev); Wed, 16 Mar 2005 03:33:08 -0800 (PST) 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 j2GBWxqD006598 for ; Wed, 16 Mar 2005 03:32:59 -0800 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 1DBWl7-0008Ax-00; Wed, 16 Mar 2005 22:32:17 +1100 Received: from herbert by gondolin.me.apana.org.au with local (Exim 3.36 #1 (Debian)) id 1DBWkf-0002rG-00; Wed, 16 Mar 2005 22:31:49 +1100 Date: Wed, 16 Mar 2005 22:31:49 +1100 To: "David S. Miller" Cc: Alexey Kuznetsov , YOSHIFUJI Hideaki , Patrick McHardy , netdev@oss.sgi.com Subject: Re: [15/*] [INET] Fix IPsec calculation in ip_append_data/ip6_append_data Message-ID: <20050316113149.GA10960@gondor.apana.org.au> References: <20050214221200.GA18465@gondor.apana.org.au> <20050214221433.GB18465@gondor.apana.org.au> <20050214221607.GC18465@gondor.apana.org.au> <20050306213214.7d8a143d.davem@davemloft.net> <20050307103536.GB7137@gondor.apana.org.au> <20050308102741.GA23468@gondor.apana.org.au> <20050314102614.GA9610@gondor.apana.org.au> <20050314105313.GA21001@gondor.apana.org.au> <20050314111002.GA29156@gondor.apana.org.au> <20050315091904.GA6256@gondor.apana.org.au> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20050315091904.GA6256@gondor.apana.org.au> User-Agent: Mutt/1.5.6+20040907i From: Herbert Xu X-Virus-Scanned: ClamAV 0.83/762/Sun Mar 13 15:35:33 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 240 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: herbert@gondor.apana.org.au Precedence: bulk X-list: netdev Content-Length: 972 Lines: 26 Hi Dave: On Tue, Mar 15, 2005 at 08:19:04PM +1100, herbert wrote: > > This patch fixes the IPsec overhead handling in ip_append_data and > ip6_append_data. As it is they assume that the IPsec overhead is > constant. This is not true as with ESP the IPsec overhead will vary > as the MTU varies. This patch is wrong. This is the *one* place where we do need to use the path MTU. The reason is that when the packet is fragmented we only pay for the IPsec overhead once over all and not once for each fragment. Please revert it for now. The trailer_len in ip_append_data is not quite right as the trailer's length depends on the length of the entire packet. However, it should be harmless since ESP knows how to extend the packet when necessary. 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 linville@bilbo.tuxdriver.com Wed Mar 16 06:38:19 2005 Received: with ECARTIS (v1.0.0; list netdev); Wed, 16 Mar 2005 06:38:27 -0800 (PST) Received: from ra.tuxdriver.com (ra.tuxdriver.com [24.172.12.4]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j2GEcI6c018823 for ; Wed, 16 Mar 2005 06:38:19 -0800 Received: from bilbo.tuxdriver.com (bilbo.tuxdriver.com [24.172.12.5]) by ra.tuxdriver.com (8.11.6/8.11.6) with ESMTP id j2GEV9s15845; Wed, 16 Mar 2005 09:31:09 -0500 Received: from bilbo.tuxdriver.com (localhost.localdomain [127.0.0.1]) by bilbo.tuxdriver.com (8.13.1/8.13.1) with ESMTP id j2GEbkJm020132; Wed, 16 Mar 2005 09:37:46 -0500 Received: (from linville@localhost) by bilbo.tuxdriver.com (8.13.1/8.13.1/Submit) id j2GEbjiA020131; Wed, 16 Mar 2005 09:37:45 -0500 Date: Wed, 16 Mar 2005 09:37:45 -0500 From: "John W. Linville" To: Rick Jones Cc: linux-kernel@vger.kernel.org, ctindel@users.sourceforge.net, fubar@us.ibm.com, bonding-devel@lists.sourceforge.net, netdev@oss.sgi.com, jgarzik@pobox.com Subject: Re: [patch 2.6.11] bonding: avoid tx balance for IGMP (alb/tlb mode) Message-ID: <20050316143743.GC18393@tuxdriver.com> Mail-Followup-To: Rick Jones , linux-kernel@vger.kernel.org, ctindel@users.sourceforge.net, fubar@us.ibm.com, bonding-devel@lists.sourceforge.net, netdev@oss.sgi.com, jgarzik@pobox.com References: <20050315215128.GA18262@tuxdriver.com> <4237833E.9080809@hp.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4237833E.9080809@hp.com> User-Agent: Mutt/1.4.1i X-Virus-Scanned: ClamAV 0.83/762/Sun Mar 13 15:35:33 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 241 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: linville@tuxdriver.com Precedence: bulk X-list: netdev Content-Length: 536 Lines: 15 On Tue, Mar 15, 2005 at 04:52:14PM -0800, Rick Jones wrote: > Is that switch behaviour "normal" or "correct?" I know next to nothing As Jay Vosburgh points-out, this patch only effects ALB and TLB modes. These are modes where the link partner is unaware of the bonded configuration. In effect, we are tricking the switch into behaving the way we desire. Since the switch is unaware of our bonded behaviour, I think it makes sense to accomodate this quirk related to IGMP snooping. John -- John W. Linville linville@tuxdriver.com From linville@bilbo.tuxdriver.com Wed Mar 16 07:45:12 2005 Received: with ECARTIS (v1.0.0; list netdev); Wed, 16 Mar 2005 07:45:18 -0800 (PST) Received: from ra.tuxdriver.com (ra.tuxdriver.com [24.172.12.4]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j2GFjBpG022039 for ; Wed, 16 Mar 2005 07:45:12 -0800 Received: from bilbo.tuxdriver.com (bilbo.tuxdriver.com [24.172.12.5]) by ra.tuxdriver.com (8.11.6/8.11.6) with ESMTP id j2GFcMs16647; Wed, 16 Mar 2005 10:38:22 -0500 Received: from bilbo.tuxdriver.com (localhost.localdomain [127.0.0.1]) by bilbo.tuxdriver.com (8.13.1/8.13.1) with ESMTP id j2GFj1H5021021; Wed, 16 Mar 2005 10:45:01 -0500 Received: (from linville@localhost) by bilbo.tuxdriver.com (8.13.1/8.13.1/Submit) id j2GFj0GL021020; Wed, 16 Mar 2005 10:45:00 -0500 Date: Wed, 16 Mar 2005 10:45:00 -0500 From: "John W. Linville" To: Andrew Morton Cc: davem@davemloft.net, jgarzik@pobox.com, netdev@oss.sgi.com, jesse.brandeburg@intel.com, ganesh.venkatesan@intel.com, john.ronciak@intel.com Subject: Re: [patch 04/13] e100: NAPI fixes Message-ID: <20050316154458.GE18393@tuxdriver.com> Mail-Followup-To: Andrew Morton , davem@davemloft.net, jgarzik@pobox.com, netdev@oss.sgi.com, jesse.brandeburg@intel.com, ganesh.venkatesan@intel.com, john.ronciak@intel.com References: <200503152222.j2FMMawn016802@shell0.pdx.osdl.net> <20050315231632.GA18393@tuxdriver.com> <20050315152332.7c938b30.akpm@osdl.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20050315152332.7c938b30.akpm@osdl.org> User-Agent: Mutt/1.4.1i X-Virus-Scanned: ClamAV 0.83/762/Sun Mar 13 15:35:33 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 242 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: linville@tuxdriver.com Precedence: bulk X-list: netdev Content-Length: 714 Lines: 24 On Tue, Mar 15, 2005 at 03:23:32PM -0800, Andrew Morton wrote: > "John W. Linville" wrote: > > > > On Tue, Mar 15, 2005 at 02:22:41PM -0800, akpm@osdl.org wrote: > > > > > > From: "John W. Linville" > > > > > > Just curious...wanna try this patch I got from Intel? I think it > > > may help... > > > > Hmmm...I didn't really mean for that one to be a submission... > > Yeah, I know. But the problem it fixes is real. It's one of my "hold onto > this patch so I remember we need to fix it" patches. Well, I can't argue with you there...at least let me repost it w/ proper changlog info? Patch to follow... John -- John W. Linville linville@tuxdriver.com From linville@bilbo.tuxdriver.com Wed Mar 16 07:52:04 2005 Received: with ECARTIS (v1.0.0; list netdev); Wed, 16 Mar 2005 07:52:09 -0800 (PST) Received: from ra.tuxdriver.com (ra.tuxdriver.com [24.172.12.4]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j2GFq3PL022812 for ; Wed, 16 Mar 2005 07:52:03 -0800 Received: from bilbo.tuxdriver.com (bilbo.tuxdriver.com [24.172.12.5]) by ra.tuxdriver.com (8.11.6/8.11.6) with ESMTP id j2GFjEs16742; Wed, 16 Mar 2005 10:45:14 -0500 Received: from bilbo.tuxdriver.com (localhost.localdomain [127.0.0.1]) by bilbo.tuxdriver.com (8.13.1/8.13.1) with ESMTP id j2GFprlb021070; Wed, 16 Mar 2005 10:51:53 -0500 Received: (from linville@localhost) by bilbo.tuxdriver.com (8.13.1/8.13.1/Submit) id j2GFpqrA021069; Wed, 16 Mar 2005 10:51:52 -0500 Date: Wed, 16 Mar 2005 10:51:52 -0500 From: "John W. Linville" To: Andrew Morton , davem@davemloft.net, jgarzik@pobox.com, netdev@oss.sgi.com, jesse.brandeburg@intel.com, ganesh.venkatesan@intel.com, john.ronciak@intel.com Subject: [patch 2.6.11] e100: NAPI state machine fix Message-ID: <20050316155152.GF18393@tuxdriver.com> Mail-Followup-To: Andrew Morton , davem@davemloft.net, jgarzik@pobox.com, netdev@oss.sgi.com, jesse.brandeburg@intel.com, ganesh.venkatesan@intel.com, john.ronciak@intel.com References: <200503152222.j2FMMawn016802@shell0.pdx.osdl.net> <20050315231632.GA18393@tuxdriver.com> <20050315152332.7c938b30.akpm@osdl.org> <20050316154458.GE18393@tuxdriver.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20050316154458.GE18393@tuxdriver.com> User-Agent: Mutt/1.4.1i X-Virus-Scanned: ClamAV 0.83/762/Sun Mar 13 15:35:33 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 243 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: linville@tuxdriver.com Precedence: bulk X-list: netdev Content-Length: 6083 Lines: 198 Improve state machine to fix NAPI-related data corruption. Signed-off-by: Jesse Brandeburg Signed-off-by: John W. Linville --- This came direct from Intel (i.e. I am not the author). It has been observed to fix data corruption problems when using the e100 driver on both x86 and ppc systems. drivers/net/e100.c | 69 +++++++++++++++++++++++++++++++++++++++++++---------- 1 files changed, 57 insertions(+), 12 deletions(-) --- linux-2.6.11/drivers/net/e100.c.orig 2005-03-16 10:38:09.091741709 -0500 +++ linux-2.6.11/drivers/net/e100.c 2005-03-16 10:38:09.127736740 -0500 @@ -269,6 +269,12 @@ enum scb_status { rus_mask = 0x3C, }; +enum ru_state { + RU_SUSPENDED = 0, + RU_RUNNING = 1, + RU_UNINITIALIZED = -1, +}; + enum scb_stat_ack { stat_ack_not_ours = 0x00, stat_ack_sw_gen = 0x04, @@ -510,7 +516,7 @@ struct nic { struct rx *rx_to_use; struct rx *rx_to_clean; struct rfd blank_rfd; - int ru_running; + enum ru_state ru_running; spinlock_t cb_lock ____cacheline_aligned; spinlock_t cmd_lock; @@ -1415,12 +1421,18 @@ static int e100_alloc_cbs(struct nic *ni return 0; } -static inline void e100_start_receiver(struct nic *nic) +static inline void e100_start_receiver(struct nic *nic, struct rx *rx) { + if(!nic->rxs) return; + if(RU_SUSPENDED != nic->ru_running) return; + + /* handle init time starts */ + if(!rx) rx = nic->rxs; + /* (Re)start RU if suspended or idle and RFA is non-NULL */ - if(!nic->ru_running && nic->rx_to_clean->skb) { - e100_exec_cmd(nic, ruc_start, nic->rx_to_clean->dma_addr); - nic->ru_running = 1; + if(rx->skb) { + e100_exec_cmd(nic, ruc_start, rx->dma_addr); + nic->ru_running = RU_RUNNING; } } @@ -1471,7 +1483,7 @@ static inline int e100_rx_indicate(struc /* If data isn't ready, nothing to indicate */ if(unlikely(!(rfd_status & cb_complete))) - return -EAGAIN; + return -ENODATA; /* Get actual data size */ actual_size = le16_to_cpu(rfd->actual_size) & 0x3FFF; @@ -1482,6 +1494,10 @@ static inline int e100_rx_indicate(struc pci_unmap_single(nic->pdev, rx->dma_addr, RFD_BUF_LEN, PCI_DMA_FROMDEVICE); + /* this allows for a fast restart without re-enabling interrupts */ + if(le16_to_cpu(rfd->command) & cb_el) + nic->ru_running = RU_SUSPENDED; + /* Pull off the RFD and put the actual data (minus eth hdr) */ skb_reserve(skb, sizeof(struct rfd)); skb_put(skb, actual_size); @@ -1514,20 +1530,45 @@ static inline void e100_rx_clean(struct unsigned int work_to_do) { struct rx *rx; + int restart_required = 0; + struct rx *rx_to_start = NULL; + + /* are we already rnr? then pay attention!!! this ensures that + * the state machine progression never allows a start with a + * partially cleaned list, avoiding a race between hardware + * and rx_to_clean when in NAPI mode */ + if(RU_SUSPENDED == nic->ru_running) + restart_required = 1; /* Indicate newly arrived packets */ for(rx = nic->rx_to_clean; rx->skb; rx = nic->rx_to_clean = rx->next) { - if(e100_rx_indicate(nic, rx, work_done, work_to_do)) + int err = e100_rx_indicate(nic, rx, work_done, work_to_do); + if(-EAGAIN == err) { + /* hit quota so have more work to do, restart once + * cleanup is complete */ + restart_required = 0; + break; + } else if(-ENODATA == err) break; /* No more to clean */ } + /* save our starting point as the place we'll restart the receiver */ + if(restart_required) + rx_to_start = nic->rx_to_clean; + /* Alloc new skbs to refill list */ for(rx = nic->rx_to_use; !rx->skb; rx = nic->rx_to_use = rx->next) { if(unlikely(e100_rx_alloc_skb(nic, rx))) break; /* Better luck next time (see watchdog) */ } - e100_start_receiver(nic); + if(restart_required) { + // ack the rnr? + writeb(stat_ack_rnr, &nic->csr->scb.stat_ack); + e100_start_receiver(nic, rx_to_start); + if(work_done) + (*work_done)++; + } } static void e100_rx_clean_list(struct nic *nic) @@ -1535,6 +1576,8 @@ static void e100_rx_clean_list(struct ni struct rx *rx; unsigned int i, count = nic->params.rfds.count; + nic->ru_running = RU_UNINITIALIZED; + if(nic->rxs) { for(rx = nic->rxs, i = 0; i < count; rx++, i++) { if(rx->skb) { @@ -1548,7 +1591,6 @@ static void e100_rx_clean_list(struct ni } nic->rx_to_use = nic->rx_to_clean = NULL; - nic->ru_running = 0; } static int e100_rx_alloc_list(struct nic *nic) @@ -1557,6 +1599,7 @@ static int e100_rx_alloc_list(struct nic unsigned int i, count = nic->params.rfds.count; nic->rx_to_use = nic->rx_to_clean = NULL; + nic->ru_running = RU_UNINITIALIZED; if(!(nic->rxs = kmalloc(sizeof(struct rx) * count, GFP_ATOMIC))) return -ENOMEM; @@ -1572,6 +1615,7 @@ static int e100_rx_alloc_list(struct nic } nic->rx_to_use = nic->rx_to_clean = nic->rxs; + nic->ru_running = RU_SUSPENDED; return 0; } @@ -1593,7 +1637,7 @@ static irqreturn_t e100_intr(int irq, vo /* We hit Receive No Resource (RNR); restart RU after cleaning */ if(stat_ack & stat_ack_rnr) - nic->ru_running = 0; + nic->ru_running = RU_SUSPENDED; e100_disable_irq(nic); netif_rx_schedule(netdev); @@ -1609,6 +1653,7 @@ static int e100_poll(struct net_device * int tx_cleaned; e100_rx_clean(nic, &work_done, work_to_do); + // should we be quota on tx? tx_cleaned = e100_tx_clean(nic); /* If no Rx and Tx cleanup work was done, exit polling mode. */ @@ -1683,7 +1728,7 @@ static int e100_up(struct nic *nic) if((err = e100_hw_init(nic))) goto err_clean_cbs; e100_set_multicast_list(nic->netdev); - e100_start_receiver(nic); + e100_start_receiver(nic, 0); mod_timer(&nic->watchdog, jiffies); if((err = request_irq(nic->pdev->irq, e100_intr, SA_SHIRQ, nic->netdev->name, nic->netdev))) @@ -1749,7 +1794,7 @@ static int e100_loopback_test(struct nic mdio_write(nic->netdev, nic->mii.phy_id, MII_BMCR, BMCR_LOOPBACK); - e100_start_receiver(nic); + e100_start_receiver(nic, 0); if(!(skb = dev_alloc_skb(ETH_DATA_LEN))) { err = -ENOMEM; -- John W. Linville linville@tuxdriver.com From mcgrof@ruslug.rutgers.edu Wed Mar 16 08:24:53 2005 Received: with ECARTIS (v1.0.0; list netdev); Wed, 16 Mar 2005 08:24:57 -0800 (PST) Received: from ruslug.rutgers.edu (ruslug.rutgers.edu [128.6.24.131]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j2GGOqKu027755 for ; Wed, 16 Mar 2005 08:24:52 -0800 Received: by ruslug.rutgers.edu (Postfix, from userid 503) id 5DBA3F98AC; Wed, 16 Mar 2005 11:24:48 -0500 (EST) Date: Wed, 16 Mar 2005 11:24:48 -0500 To: Chris Wedgwood , Jeff Garzik , Netdev , Adam K Kirchhoff , prism54-devel@prism54.org, Feyd Subject: Re: [Prism54-devel] Re: Problems with a PCI SMC2802W Message-ID: <20050316162448.GR17854@ruslug.rutgers.edu> Mail-Followup-To: Chris Wedgwood , Jeff Garzik , Netdev , Adam K Kirchhoff , prism54-devel@prism54.org, Feyd References: <422F118D.8070704@voicenet.com> <20050309160744.GN4017@Redstar.dorchain.net> <20050309202718.4f94b871@veagle.suse.cz> <20050310021724.GD17854@ruslug.rutgers.edu> <42302133.2060103@voicenet.com> <20050310103608.GB1416@taniwha.stupidest.org> <20050310163007.GK17854@ruslug.rutgers.edu> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="hqsgWuDCGoNNiKsj" Content-Disposition: inline In-Reply-To: <20050310163007.GK17854@ruslug.rutgers.edu> User-Agent: Mutt/1.3.28i X-Operating-System: 2.4.18-1-686 Organization: Rutgers University Student Linux Users Group From: mcgrof@ruslug.rutgers.edu (Luis R. Rodriguez) X-Virus-Scanned: ClamAV 0.83/762/Sun Mar 13 15:35:33 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 244 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: mcgrof@ruslug.rutgers.edu Precedence: bulk X-list: netdev Content-Length: 1871 Lines: 67 --hqsgWuDCGoNNiKsj Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Jeff/netdev, If no comment is given on how we should deal with pci_dma_sync_single/pci_dma_sync_single_for_cpu for 2.4 I'm just going to put in a nasty ifdef there. Comemnts? Luis On Thu, Mar 10, 2005 at 11:30:07AM -0500, Luis R. Rodriguez wrote: > > Index: ksrc/islpci_mgt.c > > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > > --- ksrc/islpci_mgt.c (revision 528) > > +++ ksrc/islpci_mgt.c (working copy) > > @@ -345,7 +345,7 @@ > > } > > =20 > > /* Ensure the results of device DMA are visible to the CPU. */ > > - pci_dma_sync_single(priv->pdev, buf->pci_addr, > > + pci_dma_sync_single_for_cpu(priv->pdev, buf->pci_addr, > > frag_len, PCI_DMA_FROMDEVICE); > > =20 > > /* Perform endianess conversion for PIMFOR header in-place. */ >=20 > Thanks, but the pci_[restore|save]_state changes requires testing/backpor= ting to 2.4.=20 > Same goes for pci_dma_sync_single_for_cpu(). We can macro this but ugh, i= t's just so=20 > horrible. >=20 > Margit, where are you? >=20 > Jeff, what's better a prismcompat24.h edit or a check for > LINUX_VERSION_CODE here? >=20 > Luis >=20 > --=20 > GnuPG Key fingerprint =3D 113F B290 C6D2 0251 4D84 A34A 6ADD 4937 E20A 5= 25E --=20 GnuPG Key fingerprint =3D 113F B290 C6D2 0251 4D84 A34A 6ADD 4937 E20A 525E --hqsgWuDCGoNNiKsj Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.4 (GNU/Linux) iD8DBQFCOF3Qat1JN+IKUl4RApPLAJ99O8gqzvH+s1E0S6OI78+trbIVWgCeM4fb hvE0RtuTkCURb5qCtJPCW1g= =hSOy -----END PGP SIGNATURE----- --hqsgWuDCGoNNiKsj-- From mcgrof@ruslug.rutgers.edu Wed Mar 16 08:33:41 2005 Received: with ECARTIS (v1.0.0; list netdev); Wed, 16 Mar 2005 08:33:46 -0800 (PST) Received: from ruslug.rutgers.edu (ruslug.rutgers.edu [128.6.24.131]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j2GGXfj6028642 for ; Wed, 16 Mar 2005 08:33:41 -0800 Received: by ruslug.rutgers.edu (Postfix, from userid 503) id A38B2F98AC; Wed, 16 Mar 2005 11:33:40 -0500 (EST) Date: Wed, 16 Mar 2005 11:33:40 -0500 To: Jeff Garzik Cc: akpm@osdl.org, davem@davemloft.net, netdev@oss.sgi.com, jt@hpl.hp.com Subject: Re: [patch 13/13] WE-18 (aka WPA) Message-ID: <20050316163340.GS17854@ruslug.rutgers.edu> Mail-Followup-To: Jeff Garzik , akpm@osdl.org, davem@davemloft.net, netdev@oss.sgi.com, jt@hpl.hp.com References: <200503152222.j2FMMjXu016829@shell0.pdx.osdl.net> <42376448.3040701@pobox.com> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="wbs6g7essDTrqL3S" Content-Disposition: inline In-Reply-To: <42376448.3040701@pobox.com> User-Agent: Mutt/1.3.28i X-Operating-System: 2.4.18-1-686 Organization: Rutgers University Student Linux Users Group From: mcgrof@ruslug.rutgers.edu (Luis R. Rodriguez) X-Virus-Scanned: ClamAV 0.83/762/Sun Mar 13 15:35:33 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 245 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: mcgrof@ruslug.rutgers.edu Precedence: bulk X-list: netdev Content-Length: 958 Lines: 36 --wbs6g7essDTrqL3S Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Tue, Mar 15, 2005 at 05:40:08PM -0500, Jeff Garzik wrote: > Yes, this is going into wireless-2.6 later today, as requested. >=20 > Jeff FWIW, looks good to me too, can't wait to start using it for prism54. Once in wireles-2.6 I'll throw in prism54 latest changes which adds support for AP WPA, WDS, and STA WPA (although a few things are missing here). Then we just need to patch it up to start using WE18. Great work Jouni, Luis --=20 GnuPG Key fingerprint =3D 113F B290 C6D2 0251 4D84 A34A 6ADD 4937 E20A 525E --wbs6g7essDTrqL3S Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.4 (GNU/Linux) iD8DBQFCOF/kat1JN+IKUl4RAg07AJ9ZkLqNyJ7X3HatsIgvzfGmL2YIoQCfV6Ax fmJR6ILtzX+qFb/W4/9Koog= =/OiI -----END PGP SIGNATURE----- --wbs6g7essDTrqL3S-- From oxymoron@waste.org Wed Mar 16 08:51:22 2005 Received: with ECARTIS (v1.0.0; list netdev); Wed, 16 Mar 2005 08:51:27 -0800 (PST) Received: from waste.org (waste.org [216.27.176.166]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j2GGpLs5029879 for ; Wed, 16 Mar 2005 08:51:21 -0800 Received: from waste.org (localhost [127.0.0.1]) by waste.org (8.13.2/8.13.2/Debian-1) with ESMTP id j2GGpGGB028975 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Wed, 16 Mar 2005 10:51:16 -0600 Received: (from oxymoron@localhost) by waste.org (8.13.2/8.13.2/Submit) id j2GGpFnH028972; Wed, 16 Mar 2005 10:51:15 -0600 Date: Wed, 16 Mar 2005 08:51:15 -0800 From: Matt Mackall To: backslash46@yahoo.com Cc: netdev@oss.sgi.com Subject: Re: limit ssh Message-ID: <20050316165115.GL3163@waste.org> References: <43c5e5aa05031515236d1b1527@mail.gmail.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <43c5e5aa05031515236d1b1527@mail.gmail.com> User-Agent: Mutt/1.5.6+20040907i X-Virus-Scanned: ClamAV 0.83/762/Sun Mar 13 15:35:33 2005 on oss.sgi.com X-Virus-Scanned: by amavisd-new X-Virus-Status: Clean X-archive-position: 246 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: mpm@selenic.com Precedence: bulk X-list: netdev Content-Length: 230 Lines: 10 On Wed, Mar 16, 2005 at 03:53:19AM +0430, amir_sarbazi wrote: > Hi all > > How i can limit ssh with a special IP address. > (just can ssh with a special IP) man sshd_config -- Mathematics is the supreme nostalgia of our time. From dada1@cosmosbay.com Wed Mar 16 10:05:48 2005 Received: with ECARTIS (v1.0.0; list netdev); Wed, 16 Mar 2005 10:05:54 -0800 (PST) Received: from gw1.cosmosbay.com (gw1.cosmosbay.com [62.23.185.226]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j2GI5lV0001548 for ; Wed, 16 Mar 2005 10:05:48 -0800 Received: from [172.16.0.131] (edumazet-port [172.16.0.131]) by gw1.cosmosbay.com (8.13.3/8.13.3) with ESMTP id j2GI5dBl011425; Wed, 16 Mar 2005 19:05:40 +0100 Message-ID: <42387579.6090502@cosmosbay.com> Date: Wed, 16 Mar 2005 19:05:45 +0100 From: Eric Dumazet User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.3) Gecko/20040910 X-Accept-Language: fr, en-us, en MIME-Version: 1.0 To: "David S. Miller" , netdev@oss.sgi.com Subject: [PATCH] reduce sizeof(struct inet_peer) from 128 to 64 bytes on 64bits architectures References: <42370997.6010302@cosmosbay.com> <20050315103253.590c8bfc.davem@davemloft.net> <42380EC6.60100@cosmosbay.com> In-Reply-To: <42380EC6.60100@cosmosbay.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-1.6 (gw1.cosmosbay.com [172.16.8.80]); Wed, 16 Mar 2005 19:05:40 +0100 (CET) X-Virus-Scanned: ClamAV 0.83/762/Sun Mar 13 15:35:33 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 247 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: dada1@cosmosbay.com Precedence: bulk X-list: netdev Content-Length: 1074 Lines: 25 As peer_cachep uses kmem_cache_create("inet_peer_cache", ... SLAB_HWCACHE_ALIGN ...), better try to use exactly 64 bytes instead of 72 for struct inet_peer. This also means that this structure fits in one cache line on x86_64. Thank you Eric Dumazet # diff -Nru linux-2.6.11/include/net/inetpeer.h linux-2.6.11-ed/include/net/inetpeer.h --- linux-2.6.11/include/net/inetpeer.h 2005-03-02 08:37:48.000000000 +0100 +++ linux-2.6.11-ed/include/net/inetpeer.h 2005-03-16 18:52:49.000000000 +0100 @@ -19,9 +19,9 @@ { struct inet_peer *avl_left, *avl_right; struct inet_peer *unused_next, **unused_prevp; - atomic_t refcnt; unsigned long dtime; /* the time of last use of not * referenced entries */ + atomic_t refcnt; __u32 v4daddr; /* peer's address */ __u16 avl_height; __u16 ip_id_count; /* IP ID for the next packet */ From jgarzik@pobox.com Wed Mar 16 10:13:22 2005 Received: with ECARTIS (v1.0.0; list netdev); Wed, 16 Mar 2005 10:13:28 -0800 (PST) Received: from parcelfarce.linux.theplanet.co.uk (IDENT:93@parcelfarce.linux.theplanet.co.uk [195.92.249.252]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j2GIDLH9002288 for ; Wed, 16 Mar 2005 10:13:22 -0800 Received: from cpe-069-134-152-124.nc.rr.com ([69.134.152.124] helo=[10.10.10.88]) by parcelfarce.linux.theplanet.co.uk with asmtp (TLSv1:AES256-SHA:256) (Exim 4.33) id 1DBd1C-0001gS-86; Wed, 16 Mar 2005 18:13:18 +0000 Message-ID: <42387732.5030500@pobox.com> Date: Wed, 16 Mar 2005 13:13:06 -0500 From: Jeff Garzik User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.3) Gecko/20040922 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Andrew Morton CC: davem@davemloft.net, netdev@oss.sgi.com, oray@lucent.com Subject: Re: [patch 06/13] ppc 8260 fcc ethernet driver cannot read LXT971 PHY id References: <200503152222.j2FMMccq016808@shell0.pdx.osdl.net> <20050315232651.3fd10b13.akpm@osdl.org> In-Reply-To: <20050315232651.3fd10b13.akpm@osdl.org> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV 0.83/762/Sun Mar 13 15:35:33 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 248 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: jgarzik@pobox.com Precedence: bulk X-list: netdev Content-Length: 939 Lines: 29 Andrew Morton wrote: > akpm@osdl.org wrote: > >>From: "Balasaygun, Oray (Oray)" >> >> - fix for Bug 4310 >> >> - The fcc_enet.c, as distributed in 2.6.10, does not compile. Evidently >> the 2.6 kernel no longer supports the schedule_task() and "struct >> tq_struct" to go with it. Lines 73 through and including 96 of the >> diffout file show the changes I made to port schedule_task() into >> tasklet_schedule(). I should have reported this as a bug too but I >> forgot about it. >> >> - customize fcc_enet.c to work with my custom board. These changes are >> conditional on CONFIG_EON8260 being defined. > > > Jeff, don't apply this please - we're getting a bunch of patches for this > driver coming from another direction (mvista, freescale.com). Will take > some time to sort through. All they have to do is send them to the net driver maintainer -- me -- and they get sorted through. Jeff From jgarzik@pobox.com Wed Mar 16 10:14:39 2005 Received: with ECARTIS (v1.0.0; list netdev); Wed, 16 Mar 2005 10:14:44 -0800 (PST) Received: from parcelfarce.linux.theplanet.co.uk (IDENT:93@parcelfarce.linux.theplanet.co.uk [195.92.249.252]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j2GIEclN002887 for ; Wed, 16 Mar 2005 10:14:39 -0800 Received: from cpe-069-134-152-124.nc.rr.com ([69.134.152.124] helo=[10.10.10.88]) by parcelfarce.linux.theplanet.co.uk with asmtp (TLSv1:AES256-SHA:256) (Exim 4.33) id 1DBd2T-0001hp-8Y; Wed, 16 Mar 2005 18:14:37 +0000 Message-ID: <4238777D.6030209@pobox.com> Date: Wed, 16 Mar 2005 13:14:21 -0500 From: Jeff Garzik User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.3) Gecko/20040922 X-Accept-Language: en-us, en MIME-Version: 1.0 To: "Luis R. Rodriguez" CC: Chris Wedgwood , Netdev , Adam K Kirchhoff , prism54-devel@prism54.org, Feyd Subject: Re: [Prism54-devel] Re: Problems with a PCI SMC2802W References: <422F118D.8070704@voicenet.com> <20050309160744.GN4017@Redstar.dorchain.net> <20050309202718.4f94b871@veagle.suse.cz> <20050310021724.GD17854@ruslug.rutgers.edu> <42302133.2060103@voicenet.com> <20050310103608.GB1416@taniwha.stupidest.org> <20050310163007.GK17854@ruslug.rutgers.edu> <20050316162448.GR17854@ruslug.rutgers.edu> In-Reply-To: <20050316162448.GR17854@ruslug.rutgers.edu> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV 0.83/762/Sun Mar 13 15:35:33 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 249 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: jgarzik@pobox.com Precedence: bulk X-list: netdev Content-Length: 322 Lines: 14 Luis R. Rodriguez wrote: > Jeff/netdev, > > If no comment is given on how we should deal with > pci_dma_sync_single/pci_dma_sync_single_for_cpu for 2.4 I'm just going > to put in a nasty ifdef there. Comemnts? For 2.4, why not define pci_dma_sync_single_for_{device,cpu} as equivalent to pci_dma_sync_single? Jeff From bunk@stusta.de Wed Mar 16 10:15:40 2005 Received: with ECARTIS (v1.0.0; list netdev); Wed, 16 Mar 2005 10:15:46 -0800 (PST) Received: from mailout.stusta.mhn.de (mailout.stusta.mhn.de [141.84.69.5]) by oss.sgi.com (8.13.0/8.13.0) with SMTP id j2GIFcxt003472 for ; Wed, 16 Mar 2005 10:15:39 -0800 Received: (qmail 16411 invoked from network); 16 Mar 2005 18:15:32 -0000 Received: from r063144.stusta.swh.mhn.de (10.150.63.144) by mailhub.stusta.mhn.de with SMTP; 16 Mar 2005 18:15:32 -0000 Received: by r063144.stusta.swh.mhn.de (Postfix, from userid 1000) id A403FBB4F2; Wed, 16 Mar 2005 19:15:32 +0100 (CET) Date: Wed, 16 Mar 2005 19:15:32 +0100 From: Adrian Bunk To: chas3@users.sourceforge.net Cc: shemminger@osdl.org, bridge@osdl.org, linux-atm-general@lists.sourceforge.net, netdev@oss.sgi.com, linux-kernel@vger.kernel.org Subject: Re: [2.6 patch] fix bridge <-> ATM compile error Message-ID: <20050316181532.GA3251@stusta.de> References: <20050315121930.GE3189@stusta.de> <200503161611.j2GGBT0F004479@ginger.cmf.nrl.navy.mil> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200503161611.j2GGBT0F004479@ginger.cmf.nrl.navy.mil> User-Agent: Mutt/1.5.6+20040907i X-Virus-Scanned: ClamAV 0.83/762/Sun Mar 13 15:35:33 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 250 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: bunk@stusta.de Precedence: bulk X-list: netdev Content-Length: 1059 Lines: 30 On Wed, Mar 16, 2005 at 11:11:29AM -0500, chas williams - CONTRACTOR wrote: > In message <20050315121930.GE3189@stusta.de>,Adrian Bunk writes: > >This patch fixes the following compile error with CONFIG_BRIDGE=y and > >CONFIG_ATM_LANE=m: > > isnt the problem more that CONFIG_ATM=m not CONFIG_ATM_LANE=m? > perhaps CONFIG_BRIDGE should be dependent on CONFIG_ATM. if > atm is a module then bridge cannot be a module (unless the > hooks are moved from atm to bridge)? The problem is currently CONFIG_ATM_LANE due to the #ifdef's in net/atm/common.c . Letting CONFIG_BRIDGE depend on CONFIG_ATM doesn't sound like a good idea, since I doubt all people using the Bridge code require ATM support. Moving the hooks to the bridge code will give you exactly the same problems the other way round. cu Adrian -- "Is there not promise of rain?" Ling Tan asked suddenly out of the darkness. There had been need of rain for many days. "Only a promise," Lao Er said. Pearl S. Buck - Dragon Seed From cw@f00f.org Wed Mar 16 10:15:52 2005 Received: with ECARTIS (v1.0.0; list netdev); Wed, 16 Mar 2005 10:15:59 -0800 (PST) Received: from pimout3-ext.prodigy.net (pimout3-ext.prodigy.net [207.115.63.102]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j2GIFpQX003713 for ; Wed, 16 Mar 2005 10:15:52 -0800 Received: from taniwha.stupidest.org (adsl-67-124-116-142.dsl.snfc21.pacbell.net [67.124.116.142]) by pimout3-ext.prodigy.net (8.12.10 milter /8.12.10) with ESMTP id j2GIFi9N280014; Wed, 16 Mar 2005 13:15:44 -0500 Received: by taniwha.stupidest.org (Postfix, from userid 38689) id 8466C115C85B; Wed, 16 Mar 2005 10:15:44 -0800 (PST) Date: Wed, 16 Mar 2005 10:15:44 -0800 From: Chris Wedgwood To: Jeff Garzik , Netdev , Adam K Kirchhoff , prism54-devel@prism54.org, Feyd Subject: Re: [Prism54-devel] Re: Problems with a PCI SMC2802W Message-ID: <20050316181544.GB24241@taniwha.stupidest.org> References: <422F118D.8070704@voicenet.com> <20050309160744.GN4017@Redstar.dorchain.net> <20050309202718.4f94b871@veagle.suse.cz> <20050310021724.GD17854@ruslug.rutgers.edu> <42302133.2060103@voicenet.com> <20050310103608.GB1416@taniwha.stupidest.org> <20050310163007.GK17854@ruslug.rutgers.edu> <20050316162448.GR17854@ruslug.rutgers.edu> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20050316162448.GR17854@ruslug.rutgers.edu> X-Virus-Scanned: ClamAV 0.83/762/Sun Mar 13 15:35:33 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 251 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: cw@f00f.org Precedence: bulk X-list: netdev Content-Length: 387 Lines: 13 On Wed, Mar 16, 2005 at 11:24:48AM -0500, Luis R. Rodriguez wrote: > If no comment is given on how we should deal with > pci_dma_sync_single/pci_dma_sync_single_for_cpu for 2.4 I'm just > going to put in a nasty ifdef there. Comemnts? How about just put: #ifndef pci_dma_sync_single_for_cpu #define pci_dma_sync_single_for_cpu pci_dma_sync_single #endif In one of the prism headers? From chas@cmf.nrl.navy.mil Wed Mar 16 10:24:25 2005 Received: with ECARTIS (v1.0.0; list netdev); Wed, 16 Mar 2005 10:24:29 -0800 (PST) Received: from ginger.cmf.nrl.navy.mil (ginger.cmf.nrl.navy.mil [134.207.10.161]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j2GIOORJ005265 for ; Wed, 16 Mar 2005 10:24:25 -0800 Received: from cmf.nrl.navy.mil (thirdoffive.cmf.nrl.navy.mil [134.207.10.180]) by ginger.cmf.nrl.navy.mil (8.12.11/8.12.11) with ESMTP id j2GIOArr007631; Wed, 16 Mar 2005 13:24:11 -0500 (EST) Message-Id: <200503161824.j2GIOArr007631@ginger.cmf.nrl.navy.mil> To: Adrian Bunk cc: shemminger@osdl.org, bridge@osdl.org, linux-atm-general@lists.sourceforge.net, netdev@oss.sgi.com, linux-kernel@vger.kernel.org Reply-To: chas3@users.sourceforge.net Reply-To: chas3@users.sourceforge.net Reply-To: chas3@users.sourceforge.net Subject: Re: [2.6 patch] fix bridge <-> ATM compile error In-reply-to: <20050316181532.GA3251@stusta.de> Date: Wed, 16 Mar 2005 13:24:11 -0500 From: "chas williams - CONTRACTOR" X-Virus-Scanned: ClamAV 0.83/762/Sun Mar 13 15:35:33 2005 on oss.sgi.com X-Virus-Scanned: NAI Completed X-Scanned-By: MIMEDefang 2.30 (www . roaringpenguin . com / mimedefang) X-Virus-Status: Clean X-archive-position: 252 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: chas@cmf.nrl.navy.mil Precedence: bulk X-list: netdev Content-Length: 388 Lines: 11 In message <20050316181532.GA3251@stusta.de>,Adrian Bunk writes: >Letting CONFIG_BRIDGE depend on CONFIG_ATM doesn't sound like a good >idea, since I doubt all people using the Bridge code require ATM >support. i agree. >Moving the hooks to the bridge code will give you exactly the same >problems the other way round. how about moving them to a third location like net/core/dev.c? From romieu@fr.zoreil.com Wed Mar 16 10:36:10 2005 Received: with ECARTIS (v1.0.0; list netdev); Wed, 16 Mar 2005 10:36:16 -0800 (PST) Received: from fr.zoreil.com (electric-eye.fr.zoreil.com [213.41.134.224]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j2GIa83l006141 for ; Wed, 16 Mar 2005 10:36:09 -0800 Received: from electric-eye.fr.zoreil.com (localhost.localdomain [127.0.0.1]) by fr.zoreil.com (8.13.1/8.12.1) with ESMTP id j2GIXvWx026080; Wed, 16 Mar 2005 19:33:57 +0100 Received: (from romieu@localhost) by electric-eye.fr.zoreil.com (8.13.1/8.13.1/Submit) id j2GIXl2l026079; Wed, 16 Mar 2005 19:33:47 +0100 Date: Wed, 16 Mar 2005 19:33:47 +0100 From: Francois Romieu To: Chris Wedgwood , Jeff Garzik , Netdev , Adam K Kirchhoff , prism54-devel@prism54.org, Feyd Subject: Re: [Prism54-devel] Re: Problems with a PCI SMC2802W Message-ID: <20050316183347.GA25595@electric-eye.fr.zoreil.com> References: <422F118D.8070704@voicenet.com> <20050309160744.GN4017@Redstar.dorchain.net> <20050309202718.4f94b871@veagle.suse.cz> <20050310021724.GD17854@ruslug.rutgers.edu> <42302133.2060103@voicenet.com> <20050310103608.GB1416@taniwha.stupidest.org> <20050310163007.GK17854@ruslug.rutgers.edu> <20050316162448.GR17854@ruslug.rutgers.edu> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20050316162448.GR17854@ruslug.rutgers.edu> User-Agent: Mutt/1.4.1i X-Organisation: Land of Sunshine Inc. X-Virus-Scanned: ClamAV 0.83/762/Sun Mar 13 15:35:33 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 253 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: romieu@fr.zoreil.com Precedence: bulk X-list: netdev Content-Length: 627 Lines: 16 Luis R. Rodriguez : [...] > If no comment is given on how we should deal with > pci_dma_sync_single/pci_dma_sync_single_for_cpu for 2.4 I'm just going > to put in a nasty ifdef there. Comemnts? My out of tree 2.4.x driver for the 8169 exhibits a few differences with the 2.6.x driver for these kind of things. Over several months, it happened once that a 2.6.x patch hit this part of the code. Let's say an extra 5 minutes to merge in 2.4.x and no side effects as I had to actually look at the code (of course orthogonal patches helped). Imho it is not a heavy maintenance/taste issue. -- Ueimor From willy@www.linux.org.uk Wed Mar 16 10:53:13 2005 Received: with ECARTIS (v1.0.0; list netdev); Wed, 16 Mar 2005 10:53:23 -0800 (PST) Received: from parcelfarce.linux.theplanet.co.uk (IDENT:93@parcelfarce.linux.theplanet.co.uk [195.92.249.252]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j2GIrCod007092 for ; Wed, 16 Mar 2005 10:53:12 -0800 Received: from willy by parcelfarce.linux.theplanet.co.uk with local (Exim 4.33) id 1DBddm-0003mU-SS; Wed, 16 Mar 2005 18:53:10 +0000 Date: Wed, 16 Mar 2005 18:53:10 +0000 From: Matthew Wilcox To: Mike Christie Cc: Jens Axboe , Christoph Hellwig , Matthew Wilcox , James Bottomley , SCSI Mailing List , netdev@oss.sgi.com Subject: iSCSI and scatterlists Message-ID: <20050316185310.GQ21986@parcelfarce.linux.theplanet.co.uk> References: <200503160209.j2G29cAf010870@hera.kernel.org> <20050316075839.GC7842@suse.de> <1110986016.5771.3.camel@mulgrave> <20050316160447.GU7842@suse.de> <20050316164806.GO21986@parcelfarce.linux.theplanet.co.uk> <20050316165338.GX7842@suse.de> <20050316170259.GA25056@infradead.org> <20050316170417.GY7842@suse.de> <42387EA2.5020106@us.ibm.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <42387EA2.5020106@us.ibm.com> User-Agent: Mutt/1.4.1i X-Virus-Scanned: ClamAV 0.83/762/Sun Mar 13 15:35:33 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 254 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: matthew@wil.cx Precedence: bulk X-list: netdev Content-Length: 1110 Lines: 23 On Wed, Mar 16, 2005 at 10:44:50AM -0800, Mike Christie wrote: > I got lost here. If you are talking about the need to kmap a sglist then > software iscsi has it. iscsi-sfnet used to do > > while (...) > kmap() > > but I fixed that (I think I need to use kmap_atomic though, is that > correct or is it just a performance improvement - I am calling kmap from > a thread too so). I just added kmap_atomic to open-iscsi and I believe > pyx does something similar to the loop above. Sounds like networking should grow an interface to accept a sglist as input. I'm really not familiar with Linux's networking stack to know how to do it ... cc'ing netdev to get their thoughts. -- "Next the statesmen will invent cheap lies, putting the blame upon the nation that is attacked, and every man will be glad of those conscience-soothing falsities, and will diligently study them, and refuse to examine any refutations of them; and thus he will by and by convince himself that the war is just, and will thank God for the better sleep he enjoys after this process of grotesque self-deception." -- Mark Twain From kaber@trash.net Wed Mar 16 11:01:58 2005 Received: with ECARTIS (v1.0.0; list netdev); Wed, 16 Mar 2005 11:02:05 -0800 (PST) Received: from kaber.coreworks.de ([62.206.217.67]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j2GJ1uXK008933 for ; Wed, 16 Mar 2005 11:01:58 -0800 Received: from localhost ([127.0.0.1]) by kaber.coreworks.de with esmtp (Exim 4.50) id 1DBdlD-0001os-FA; Wed, 16 Mar 2005 20:00:51 +0100 Message-ID: <42388263.3090602@trash.net> Date: Wed, 16 Mar 2005 20:00:51 +0100 From: Patrick McHardy User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.7.5) Gecko/20050106 Debian/1.7.5-1 X-Accept-Language: en MIME-Version: 1.0 To: Herbert Xu CC: "David S. Miller" , kuznet@ms2.inr.ac.ru, yoshfuji@linux-ipv6.org, netdev@oss.sgi.com Subject: Re: [IPV4] Make ipt_REJECT use icmp_send again References: <20050314102614.GA9610@gondor.apana.org.au> <20050314105313.GA21001@gondor.apana.org.au> <20050314111002.GA29156@gondor.apana.org.au> <20050315091904.GA6256@gondor.apana.org.au> <20050315095837.GA7130@gondor.apana.org.au> <20050315100522.GA7275@gondor.apana.org.au> <20050315102450.0f3f1618.davem@davemloft.net> <42373142.6090902@trash.net> <20050315204006.GB22349@gondor.apana.org.au> <42374A35.6020308@trash.net> <20050316105100.GA8404@gondor.apana.org.au> In-Reply-To: <20050316105100.GA8404@gondor.apana.org.au> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV 0.83/762/Sun Mar 13 15:35:33 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 255 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: kaber@trash.net Precedence: bulk X-list: netdev Content-Length: 298 Lines: 11 Herbert Xu wrote: > I compared the two functions line-by-line to make sure that there > weren't any subtle differences. Please double check this in case > I overlooked something important. I double checked, all looks good to me. Signed-off-by: Patrick McHardy Regards Patrick From dima@neterion.com Wed Mar 16 12:00:05 2005 Received: with ECARTIS (v1.0.0; list netdev); Wed, 16 Mar 2005 12:00:16 -0800 (PST) Received: from ns1.s2io.com (ns1.s2io.com [142.46.200.198]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j2GK04g8013770 for ; Wed, 16 Mar 2005 12:00:05 -0800 Received: from guinness.s2io.com (sentry.s2io.com [142.46.200.199]) by ns1.s2io.com (8.12.10/8.12.10) with ESMTP id j2GJxjuN028993; Wed, 16 Mar 2005 14:59:45 -0500 (EST) Received: from beastie ([10.16.16.220]) by guinness.s2io.com (8.12.6/8.12.6) with ESMTP id j2GJxhDD017821; Wed, 16 Mar 2005 14:59:43 -0500 (EST) Subject: Re: iSCSI and scatterlists From: Dmitry Yusupov To: Matthew Wilcox Cc: Mike Christie , Jens Axboe , Christoph Hellwig , James Bottomley , SCSI Mailing List , netdev@oss.sgi.com, open-iscsi@googlegroups.com In-Reply-To: <20050316185310.GQ21986@parcelfarce.linux.theplanet.co.uk> References: <200503160209.j2G29cAf010870@hera.kernel.org> <20050316075839.GC7842@suse.de> <1110986016.5771.3.camel@mulgrave> <20050316160447.GU7842@suse.de> <20050316164806.GO21986@parcelfarce.linux.theplanet.co.uk> <20050316165338.GX7842@suse.de> <20050316170259.GA25056@infradead.org> <20050316170417.GY7842@suse.de> <42387EA2.5020106@us.ibm.com> <20050316185310.GQ21986@parcelfarce.linux.theplanet.co.uk> Content-Type: text/plain Organization: Neterion, Inc Date: Wed, 16 Mar 2005 11:59:42 -0800 Message-Id: <1111003182.27052.46.camel@beastie> Mime-Version: 1.0 X-Mailer: Evolution 2.0.2 (2.0.2-3) Content-Transfer-Encoding: 7bit X-Scanned-By: MIMEDefang 2.34 X-Virus-Scanned: ClamAV 0.83/762/Sun Mar 13 15:35:33 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 256 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: dima@neterion.com Precedence: bulk X-list: netdev Content-Length: 1205 Lines: 29 On Wed, 2005-03-16 at 18:53 +0000, Matthew Wilcox wrote: > On Wed, Mar 16, 2005 at 10:44:50AM -0800, Mike Christie wrote: > > I got lost here. If you are talking about the need to kmap a sglist then > > software iscsi has it. iscsi-sfnet used to do > > > > while (...) > > kmap() > > > > but I fixed that (I think I need to use kmap_atomic though, is that > > correct or is it just a performance improvement - I am calling kmap from > > a thread too so). I just added kmap_atomic to open-iscsi and I believe > > pyx does something similar to the loop above. > > Sounds like networking should grow an interface to accept a sglist as > input. I'm really not familiar with Linux's networking stack to know > how to do it ... cc'ing netdev to get their thoughts. This is a nice idea, but will not always work with iSCSI protocol simply because iSCSI PDU's data sizes might be negotiated to be lesser/bigger than original WRITE's sglist size. It might help to optimize some data path when PDU's data segment size >= sglist size. i.e. entire sglist needs to be passed down to the stack. i'm cross-posting to open-iscsi mailing list, so open-iscsi folks might participate in the discussion. Dmitry From shemminger@osdl.org Wed Mar 16 12:38:17 2005 Received: with ECARTIS (v1.0.0; list netdev); Wed, 16 Mar 2005 12:38:22 -0800 (PST) Received: from smtp.osdl.org (fire.osdl.org [65.172.181.4]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j2GKcH2p018689 for ; Wed, 16 Mar 2005 12:38:17 -0800 Received: from shell0.pdx.osdl.net (fw.osdl.org [65.172.181.6]) by smtp.osdl.org (8.12.8/8.12.8) with ESMTP id j2GKc9qi020464 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO); Wed, 16 Mar 2005 12:38:10 -0800 Received: from dxpl.pdx.osdl.net (dxpl.pdx.osdl.net [172.20.1.103]) by shell0.pdx.osdl.net (8.13.1/8.11.6) with ESMTP id j2GKc9YW004598; Wed, 16 Mar 2005 12:38:09 -0800 Date: Wed, 16 Mar 2005 12:38:28 -0800 From: Stephen Hemminger To: bridge@osdl.org Cc: linux-net@vger.kernel.org, linux-kernel@vger.kernel.org, netdev@oss.sgi.com Subject: [ANNOUNCE] bridge utilities 1.0.6 Message-ID: <20050316123828.0eb78fd3@dxpl.pdx.osdl.net> Organization: Open Source Development Lab X-Mailer: Sylpheed-Claws 1.0.1 (GTK+ 1.2.10; x86_64-unknown-linux-gnu) X-Face: &@E+xe?c%:&e4D{>f1O<&U>2qwRREG5!}7R4;D<"NO^UI2mJ[eEOA2*3>(`Th.yP,VDPo9$ /`~cw![cmj~~jWe?AHY7D1S+\}5brN0k*NE?pPh_'_d>6;XGG[\KDRViCfumZT3@[ Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Received-SPF: pass (domain of shemminger@osdl.org designates 65.172.181.6 as permitted sender) X-MIMEDefang-Filter: osdl$Revision: 1.105 $ X-Scanned-By: MIMEDefang 2.36 X-Virus-Scanned: ClamAV 0.83/762/Sun Mar 13 15:35:33 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 257 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: shemminger@osdl.org Precedence: bulk X-list: netdev Content-Length: 359 Lines: 7 Minor update to bridge utilities for 2.4/2.6. The changes are: + Better usage of autoconf to manage detecting sysfs library + Support multiple interfaces for add/delete interface commands. Example: brctl addif br0 eth0 eth1 eth2 - Remove code that was dead and no longer used http://prdownloads.sourceforge.net/bridge/bridge-utils-1.0.6.tar.gz?download From jdmason@us.ibm.com Wed Mar 16 12:39:28 2005 Received: with ECARTIS (v1.0.0; list netdev); Wed, 16 Mar 2005 12:39:35 -0800 (PST) Received: from e31.co.us.ibm.com (e31.co.us.ibm.com [32.97.110.129]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j2GKdSZI018927 for ; Wed, 16 Mar 2005 12:39:28 -0800 Received: from westrelay02.boulder.ibm.com (westrelay02.boulder.ibm.com [9.17.195.11]) by e31.co.us.ibm.com (8.12.10/8.12.9) with ESMTP id j2GKdMua432842 for ; Wed, 16 Mar 2005 15:39:22 -0500 Received: from d03av02.boulder.ibm.com (d03av02.boulder.ibm.com [9.17.195.168]) by westrelay02.boulder.ibm.com (8.12.10/NCO/VER6.6) with ESMTP id j2GKdMc3221326 for ; Wed, 16 Mar 2005 13:39:22 -0700 Received: from d03av02.boulder.ibm.com (loopback [127.0.0.1]) by d03av02.boulder.ibm.com (8.12.11/8.12.11) with ESMTP id j2GKdLv8004114 for ; Wed, 16 Mar 2005 13:39:22 -0700 Received: from dreadnought.austin.ibm.com (dreadnought.austin.ibm.com [9.41.94.123]) by d03av02.boulder.ibm.com (8.12.11/8.12.11) with ESMTP id j2GKdLm9004092; Wed, 16 Mar 2005 13:39:21 -0700 From: Jon Mason Organization: IBM To: Francois Romieu Subject: Re: [patch linux-2.6.11-bk10 1/1] r8169: incoming frame length check Date: Wed, 16 Mar 2005 14:30:17 -0600 User-Agent: KMail/1.7.2 Cc: netdev@oss.sgi.com, jgarzik@pobox.com, Stephen Hemminger , mark@kiora.ath.cx References: <20050314233103.GC16072@electric-eye.fr.zoreil.com> In-Reply-To: <20050314233103.GC16072@electric-eye.fr.zoreil.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200503161430.17943.jdmason@us.ibm.com> X-Virus-Scanned: ClamAV 0.83/762/Sun Mar 13 15:35:33 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 258 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: jdmason@us.ibm.com Precedence: bulk X-list: netdev Content-Length: 3850 Lines: 117 On Monday 14 March 2005 05:31 pm, Francois Romieu wrote: > The size of the incoming frame is not correctly checked. > > The RxMaxSize register (0xDA) does not work as expected and incoming > frames whose size exceeds the MTU actually end spanning multiple > descriptors. The first Rx descriptor contains the size of the whole > frame (or some garbage in its place). The driver does not expect > something above the space allocated to the current skb and crashes > loudly when it issues a skb_put. > > The fix contains two parts: > - disable hardware Rx size filtering: so far it only proved to be able > to trigger some new fancy errors; > - drop multi-descriptors frame: as the driver allocates MTU sized Rx > buffers, it provides an adequate filtering. > > As a bonus, wrong descriptors were not returned to the asic after their > processing. > > Signed-off-by: Francois Romieu Applies cleanly and lightly tested on amd64 (kernel version 2.6.11.3). > diff -puN drivers/net/r8169.c~r8169-570 drivers/net/r8169.c > --- linux-2.6.11/drivers/net/r8169.c~r8169-570 2005-03-13 > 23:35:37.000000000 +0100 +++ linux-2.6.11-fr/drivers/net/r8169.c 2005-03-14 > 23:47:56.529014957 +0100 @@ -1585,8 +1585,8 @@ rtl8169_hw_start(struct > net_device *dev) > RTL_W8(ChipCmd, CmdTxEnb | CmdRxEnb); > RTL_W8(EarlyTxThres, EarlyTxThld); > > - /* For gigabit rtl8169, MTU + header + CRC + VLAN */ > - RTL_W16(RxMaxSize, tp->rx_buf_sz); > + /* Low hurts. Let's disable the filtering. */ > + RTL_W16(RxMaxSize, 16383); Wouldn't a #define be better than 16k-1? Perhaps, RxPacketMaxSize could be used. > > /* Set Rx Config register */ > i = rtl8169_rx_config | > @@ -2127,6 +2127,11 @@ rtl8169_tx_interrupt(struct net_device * > } > } > > +static inline int rtl8169_fragmented_frame(u32 status) > +{ > + return (status & (FirstFrag | LastFrag)) != (FirstFrag | LastFrag); > +} > + > static inline void rtl8169_rx_csum(struct sk_buff *skb, struct RxDesc > *desc) { > u32 opts1 = le32_to_cpu(desc->opts1); > @@ -2177,27 +2182,41 @@ rtl8169_rx_interrupt(struct net_device * > > while (rx_left > 0) { > unsigned int entry = cur_rx % NUM_RX_DESC; > + struct RxDesc *desc = tp->RxDescArray + entry; > u32 status; > > rmb(); > - status = le32_to_cpu(tp->RxDescArray[entry].opts1); > + status = le32_to_cpu(desc->opts1); > > if (status & DescOwn) > break; > if (status & RxRES) { > - printk(KERN_INFO "%s: Rx ERROR!!!\n", dev->name); > + printk(KERN_INFO "%s: Rx ERROR. status = %08x\n", > + dev->name, status); > tp->stats.rx_errors++; > if (status & (RxRWT | RxRUNT)) > tp->stats.rx_length_errors++; > if (status & RxCRC) > tp->stats.rx_crc_errors++; > + rtl8169_mark_to_asic(desc, tp->rx_buf_sz); > } else { > - struct RxDesc *desc = tp->RxDescArray + entry; > struct sk_buff *skb = tp->Rx_skbuff[entry]; > int pkt_size = (status & 0x00001FFF) - 4; > void (*pci_action)(struct pci_dev *, dma_addr_t, > size_t, int) = pci_dma_sync_single_for_device; > > + /* > + * The driver does not support incoming fragmented > + * frames. They are seen as a symptom of over-mtu > + * sized frames. > + */ > + if (unlikely(rtl8169_fragmented_frame(status))) { > + tp->stats.rx_dropped++; > + tp->stats.rx_length_errors++; > + rtl8169_mark_to_asic(desc, tp->rx_buf_sz); > + goto move_on; > + } > + > rtl8169_rx_csum(skb, desc); > > pci_dma_sync_single_for_cpu(tp->pci_dev, > @@ -2224,7 +2243,7 @@ rtl8169_rx_interrupt(struct net_device * > tp->stats.rx_bytes += pkt_size; > tp->stats.rx_packets++; > } > - > +move_on: > cur_rx++; > rx_left--; > } > > _ Looks similar to some of the > 8k Jumbo Frames changes. Should make the diff for next patch much cleaner. Thanks. -- Jon Mason jdmason@us.ibm.com From romieu@fr.zoreil.com Wed Mar 16 13:12:27 2005 Received: with ECARTIS (v1.0.0; list netdev); Wed, 16 Mar 2005 13:12:36 -0800 (PST) Received: from fr.zoreil.com (electric-eye.fr.zoreil.com [213.41.134.224]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j2GLCNtx020794 for ; Wed, 16 Mar 2005 13:12:26 -0800 Received: from electric-eye.fr.zoreil.com (localhost.localdomain [127.0.0.1]) by fr.zoreil.com (8.13.1/8.12.1) with ESMTP id j2GL9tcU029223; Wed, 16 Mar 2005 22:09:55 +0100 Received: (from romieu@localhost) by electric-eye.fr.zoreil.com (8.13.1/8.13.1/Submit) id j2GL9n3A029222; Wed, 16 Mar 2005 22:09:49 +0100 Date: Wed, 16 Mar 2005 22:09:49 +0100 From: Francois Romieu To: Jon Mason Cc: netdev@oss.sgi.com, jgarzik@pobox.com, Stephen Hemminger , mark@kiora.ath.cx Subject: Re: [patch linux-2.6.11-bk10 1/1] r8169: incoming frame length check Message-ID: <20050316210949.GA27477@electric-eye.fr.zoreil.com> References: <20050314233103.GC16072@electric-eye.fr.zoreil.com> <200503161430.17943.jdmason@us.ibm.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200503161430.17943.jdmason@us.ibm.com> User-Agent: Mutt/1.4.1i X-Organisation: Land of Sunshine Inc. X-Virus-Scanned: ClamAV 0.83/762/Sun Mar 13 15:35:33 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 259 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: romieu@fr.zoreil.com Precedence: bulk X-list: netdev Content-Length: 1130 Lines: 30 Jon Mason : [...] > > - /* For gigabit rtl8169, MTU + header + CRC + VLAN */ > > - RTL_W16(RxMaxSize, tp->rx_buf_sz); > > + /* Low hurts. Let's disable the filtering. */ > > + RTL_W16(RxMaxSize, 16383); > > Wouldn't a #define be better than 16k-1? Perhaps, RxPacketMaxSize could be > used. RxPacketMaxSize does not tell a lot more. It is (imho) still a bit too neutral as something badly sucks when you try to filter the packet size. I'll welcome suggestions for something which summarizes "The maximal jumbo frame size as it is actually needed to disable the filtering". On a different topic: Mark and I tested the patch as well. Even if it is not exactly trivial, it could make sense to push it for submission on 2.6.11.x. Without it one do not want to be on a public Gb link (sic). Executive summary: - (patch already included in 2.6.11.x): the Rx ring occasionally announced wrong size for the Rx DMA buffers; - (current patch): the packet length indication in a descriptor after Rx DMA can be related to a packet which spans several descriptors. So it is inaccurate for skb_put. -- Ueimor From davem@davemloft.net Wed Mar 16 14:06:06 2005 Received: with ECARTIS (v1.0.0; list netdev); Wed, 16 Mar 2005 14:06:13 -0800 (PST) Received: from cheetah.davemloft.net (mail@dsl027-180-174.sfo1.dsl.speakeasy.net [216.27.180.174]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j2GM65eo023184 for ; Wed, 16 Mar 2005 14:06:05 -0800 Received: from localhost ([127.0.0.1] helo=cheetah.davemloft.net ident=davem) by cheetah.davemloft.net with smtp (Exim 3.36 #1 (Debian)) id 1DBgbO-00011L-00; Wed, 16 Mar 2005 14:02:54 -0800 Date: Wed, 16 Mar 2005 14:02:54 -0800 From: "David S. Miller" To: Herbert Xu Cc: kuznet@ms2.inr.ac.ru, yoshfuji@linux-ipv6.org, kaber@trash.net, netdev@oss.sgi.com Subject: Re: [15/*] [INET] Fix IPsec calculation in ip_append_data/ip6_append_data Message-Id: <20050316140254.76f5e693.davem@davemloft.net> In-Reply-To: <20050316113149.GA10960@gondor.apana.org.au> References: <20050214221200.GA18465@gondor.apana.org.au> <20050214221433.GB18465@gondor.apana.org.au> <20050214221607.GC18465@gondor.apana.org.au> <20050306213214.7d8a143d.davem@davemloft.net> <20050307103536.GB7137@gondor.apana.org.au> <20050308102741.GA23468@gondor.apana.org.au> <20050314102614.GA9610@gondor.apana.org.au> <20050314105313.GA21001@gondor.apana.org.au> <20050314111002.GA29156@gondor.apana.org.au> <20050315091904.GA6256@gondor.apana.org.au> <20050316113149.GA10960@gondor.apana.org.au> X-Mailer: Sylpheed version 1.0.1 (GTK+ 1.2.10; sparc-unknown-linux-gnu) X-Face: "_;p5u5aPsO,_Vsx"^v-pEq09'CU4&Dc1$fQExov$62l60cgCc%FnIwD=.UF^a>?5'9Kn[;433QFVV9M..2eN.@4ZWPGbdi<=?[:T>y?SD(R*-3It"Vj:)"dP Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV 0.83/762/Sun Mar 13 15:35:33 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 260 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: davem@davemloft.net Precedence: bulk X-list: netdev Content-Length: 349 Lines: 11 On Wed, 16 Mar 2005 22:31:49 +1100 Herbert Xu wrote: > This patch is wrong. This is the *one* place where we do need to > use the path MTU. The reason is that when the packet is fragmented > we only pay for the IPsec overhead once over all and not once for > each fragment. > > Please revert it for now. Ok, done. From davem@davemloft.net Wed Mar 16 14:11:41 2005 Received: with ECARTIS (v1.0.0; list netdev); Wed, 16 Mar 2005 14:11:47 -0800 (PST) Received: from cheetah.davemloft.net (mail@dsl027-180-174.sfo1.dsl.speakeasy.net [216.27.180.174]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j2GMBfmE023852 for ; Wed, 16 Mar 2005 14:11:41 -0800 Received: from localhost ([127.0.0.1] helo=cheetah.davemloft.net ident=davem) by cheetah.davemloft.net with smtp (Exim 3.36 #1 (Debian)) id 1DBghX-000131-00; Wed, 16 Mar 2005 14:09:15 -0800 Date: Wed, 16 Mar 2005 14:09:15 -0800 From: "David S. Miller" To: Eric Dumazet Cc: netdev@oss.sgi.com Subject: Re: [BUG] overflow in net/ipv4/route.c rt_check_expire() Message-Id: <20050316140915.0f6b9528.davem@davemloft.net> In-Reply-To: <42380EC6.60100@cosmosbay.com> References: <42370997.6010302@cosmosbay.com> <20050315103253.590c8bfc.davem@davemloft.net> <42380EC6.60100@cosmosbay.com> X-Mailer: Sylpheed version 1.0.1 (GTK+ 1.2.10; sparc-unknown-linux-gnu) X-Face: "_;p5u5aPsO,_Vsx"^v-pEq09'CU4&Dc1$fQExov$62l60cgCc%FnIwD=.UF^a>?5'9Kn[;433QFVV9M..2eN.@4ZWPGbdi<=?[:T>y?SD(R*-3It"Vj:)"dP Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV 0.83/762/Sun Mar 13 15:35:33 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 261 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: davem@davemloft.net Precedence: bulk X-list: netdev Content-Length: 584 Lines: 19 On Wed, 16 Mar 2005 11:47:34 +0100 Eric Dumazet wrote: > The rt_check_expire() has a serious problem on machines with large > route caches, and a standard HZ value of 1000. > > With default values, ie ip_rt_gc_interval = 60*HZ = 60000 ; > > the loop count : > > for (t = ip_rt_gc_interval << rt_hash_log; t >= 0; > > > overflows (t is a 31 bit value) as soon rt_hash_log is >= 16 (65536 > slots in route cache hash table) ... > I am experimenting some changes that I will share when ready. Good catch, let us know when you have a patch for review. From davem@davemloft.net Wed Mar 16 14:13:03 2005 Received: with ECARTIS (v1.0.0; list netdev); Wed, 16 Mar 2005 14:13:10 -0800 (PST) Received: from cheetah.davemloft.net (mail@dsl027-180-174.sfo1.dsl.speakeasy.net [216.27.180.174]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j2GMD3GB024426 for ; Wed, 16 Mar 2005 14:13:03 -0800 Received: from localhost ([127.0.0.1] helo=cheetah.davemloft.net ident=davem) by cheetah.davemloft.net with smtp (Exim 3.36 #1 (Debian)) id 1DBgjB-00013I-00; Wed, 16 Mar 2005 14:10:57 -0800 Date: Wed, 16 Mar 2005 14:10:57 -0800 From: "David S. Miller" To: Eric Dumazet Cc: netdev@oss.sgi.com Subject: Re: [PATCH] reduce sizeof(struct inet_peer) from 128 to 64 bytes on 64bits architectures Message-Id: <20050316141057.12a8e777.davem@davemloft.net> In-Reply-To: <42387579.6090502@cosmosbay.com> References: <42370997.6010302@cosmosbay.com> <20050315103253.590c8bfc.davem@davemloft.net> <42380EC6.60100@cosmosbay.com> <42387579.6090502@cosmosbay.com> X-Mailer: Sylpheed version 1.0.1 (GTK+ 1.2.10; sparc-unknown-linux-gnu) X-Face: "_;p5u5aPsO,_Vsx"^v-pEq09'CU4&Dc1$fQExov$62l60cgCc%FnIwD=.UF^a>?5'9Kn[;433QFVV9M..2eN.@4ZWPGbdi<=?[:T>y?SD(R*-3It"Vj:)"dP Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV 0.83/762/Sun Mar 13 15:35:33 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 262 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: davem@davemloft.net Precedence: bulk X-list: netdev Content-Length: 429 Lines: 10 On Wed, 16 Mar 2005 19:05:45 +0100 Eric Dumazet wrote: > As peer_cachep uses kmem_cache_create("inet_peer_cache", ... SLAB_HWCACHE_ALIGN ...), > better try to use exactly 64 bytes instead of 72 for struct inet_peer. > > This also means that this structure fits in one cache line on x86_64. Please resend the patch, your email client turned all the tab characters into spaces so the patch will not apply. From davem@davemloft.net Wed Mar 16 14:17:20 2005 Received: with ECARTIS (v1.0.0; list netdev); Wed, 16 Mar 2005 14:17:25 -0800 (PST) Received: from cheetah.davemloft.net (mail@dsl027-180-174.sfo1.dsl.speakeasy.net [216.27.180.174]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j2GMHJfp025089 for ; Wed, 16 Mar 2005 14:17:19 -0800 Received: from localhost ([127.0.0.1] helo=cheetah.davemloft.net ident=davem) by cheetah.davemloft.net with smtp (Exim 3.36 #1 (Debian)) id 1DBgnJ-00016s-00; Wed, 16 Mar 2005 14:15:13 -0800 Date: Wed, 16 Mar 2005 14:15:13 -0800 From: "David S. Miller" To: Ralf Baechle DL5RB Cc: netdev@oss.sgi.com, linux-hams@vger.kernel.org Subject: Re: [PATCH] Use skb_queue_purge Message-Id: <20050316141513.15ef0730.davem@davemloft.net> In-Reply-To: <20050316083446.GA20392@linux-mips.org> References: <20050316083446.GA20392@linux-mips.org> X-Mailer: Sylpheed version 1.0.1 (GTK+ 1.2.10; sparc-unknown-linux-gnu) X-Face: "_;p5u5aPsO,_Vsx"^v-pEq09'CU4&Dc1$fQExov$62l60cgCc%FnIwD=.UF^a>?5'9Kn[;433QFVV9M..2eN.@4ZWPGbdi<=?[:T>y?SD(R*-3It"Vj:)"dP Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV 0.83/762/Sun Mar 13 15:35:33 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 263 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: davem@davemloft.net Precedence: bulk X-list: netdev Content-Length: 156 Lines: 6 On Wed, 16 Mar 2005 08:34:46 +0000 Ralf Baechle DL5RB wrote: > skb_queue_purge exists so why not using it ;-) Applied, thanks Ralf. From davem@davemloft.net Wed Mar 16 14:47:12 2005 Received: with ECARTIS (v1.0.0; list netdev); Wed, 16 Mar 2005 14:47:17 -0800 (PST) Received: from cheetah.davemloft.net (mail@dsl027-180-174.sfo1.dsl.speakeasy.net [216.27.180.174]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j2GMlBP0026470 for ; Wed, 16 Mar 2005 14:47:12 -0800 Received: from localhost ([127.0.0.1] helo=cheetah.davemloft.net ident=davem) by cheetah.davemloft.net with smtp (Exim 3.36 #1 (Debian)) id 1DBhFY-0001FB-00; Wed, 16 Mar 2005 14:44:24 -0800 Date: Wed, 16 Mar 2005 14:44:24 -0800 From: "David S. Miller" To: Patrick McHardy Cc: herbert@gondor.apana.org.au, kuznet@ms2.inr.ac.ru, yoshfuji@linux-ipv6.org, netdev@oss.sgi.com Subject: Re: [IPV4] Make ipt_REJECT use icmp_send again Message-Id: <20050316144424.689d5981.davem@davemloft.net> In-Reply-To: <42388263.3090602@trash.net> References: <20050314102614.GA9610@gondor.apana.org.au> <20050314105313.GA21001@gondor.apana.org.au> <20050314111002.GA29156@gondor.apana.org.au> <20050315091904.GA6256@gondor.apana.org.au> <20050315095837.GA7130@gondor.apana.org.au> <20050315100522.GA7275@gondor.apana.org.au> <20050315102450.0f3f1618.davem@davemloft.net> <42373142.6090902@trash.net> <20050315204006.GB22349@gondor.apana.org.au> <42374A35.6020308@trash.net> <20050316105100.GA8404@gondor.apana.org.au> <42388263.3090602@trash.net> X-Mailer: Sylpheed version 1.0.1 (GTK+ 1.2.10; sparc-unknown-linux-gnu) X-Face: "_;p5u5aPsO,_Vsx"^v-pEq09'CU4&Dc1$fQExov$62l60cgCc%FnIwD=.UF^a>?5'9Kn[;433QFVV9M..2eN.@4ZWPGbdi<=?[:T>y?SD(R*-3It"Vj:)"dP Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV 0.83/762/Sun Mar 13 15:35:33 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 264 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: davem@davemloft.net Precedence: bulk X-list: netdev Content-Length: 397 Lines: 13 On Wed, 16 Mar 2005 20:00:51 +0100 Patrick McHardy wrote: > Herbert Xu wrote: > > I compared the two functions line-by-line to make sure that there > > weren't any subtle differences. Please double check this in case > > I overlooked something important. > > I double checked, all looks good to me. > > Signed-off-by: Patrick McHardy Applied, thanks guys. From davem@davemloft.net Wed Mar 16 14:52:29 2005 Received: with ECARTIS (v1.0.0; list netdev); Wed, 16 Mar 2005 14:52:35 -0800 (PST) Received: from cheetah.davemloft.net (mail@dsl027-180-174.sfo1.dsl.speakeasy.net [216.27.180.174]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j2GMqTsJ027068 for ; Wed, 16 Mar 2005 14:52:29 -0800 Received: from localhost ([127.0.0.1] helo=cheetah.davemloft.net ident=davem) by cheetah.davemloft.net with smtp (Exim 3.36 #1 (Debian)) id 1DBhLI-0001H6-00; Wed, 16 Mar 2005 14:50:20 -0800 Date: Wed, 16 Mar 2005 14:50:20 -0800 From: "David S. Miller" To: Robert Olsson Cc: cliffw@osdl.org, Robert.Olsson@data.slu.se, netdev@oss.sgi.com Subject: Re: Constant errors with pktgen Message-Id: <20050316145020.3ee45a69.davem@davemloft.net> In-Reply-To: <16951.422.818446.117190@robur.slu.se> References: <20050314133404.2528647f@es175> <16951.422.818446.117190@robur.slu.se> X-Mailer: Sylpheed version 1.0.1 (GTK+ 1.2.10; sparc-unknown-linux-gnu) X-Face: "_;p5u5aPsO,_Vsx"^v-pEq09'CU4&Dc1$fQExov$62l60cgCc%FnIwD=.UF^a>?5'9Kn[;433QFVV9M..2eN.@4ZWPGbdi<=?[:T>y?SD(R*-3It"Vj:)"dP Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV 0.83/762/Sun Mar 13 15:35:33 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 265 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: davem@davemloft.net Precedence: bulk X-list: netdev Content-Length: 456 Lines: 16 On Tue, 15 Mar 2005 16:39:18 +0100 Robert Olsson wrote: > > cliff white writes: > > > My test rig is two machines with an e100 card, connected by crossover > > cable. > > > > When i run pktgen, the error counter == packet count, always. > > I see. Try the patch patch below it cleans up the code a bit and > restores the old meaning of error. It also has the minor fix from > Adrian Bunk Applied, thanks Robert. From davem@davemloft.net Wed Mar 16 14:58:53 2005 Received: with ECARTIS (v1.0.0; list netdev); Wed, 16 Mar 2005 14:58:59 -0800 (PST) Received: from cheetah.davemloft.net (mail@dsl027-180-174.sfo1.dsl.speakeasy.net [216.27.180.174]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j2GMwrZN028143 for ; Wed, 16 Mar 2005 14:58:53 -0800 Received: from localhost ([127.0.0.1] helo=cheetah.davemloft.net ident=davem) by cheetah.davemloft.net with smtp (Exim 3.36 #1 (Debian)) id 1DBhOZ-0001IO-00; Wed, 16 Mar 2005 14:53:43 -0800 Date: Wed, 16 Mar 2005 14:53:43 -0800 From: "David S. Miller" To: Adrian Bunk Cc: netdev@oss.sgi.com, linux-kernel@vger.kernel.org Subject: Re: [2.6 patch] net/ipv4/inetpeer.c: make a struct static Message-Id: <20050316145343.6e31ba6a.davem@davemloft.net> In-Reply-To: <20050315144408.GL3189@stusta.de> References: <20050315144408.GL3189@stusta.de> X-Mailer: Sylpheed version 1.0.1 (GTK+ 1.2.10; sparc-unknown-linux-gnu) X-Face: "_;p5u5aPsO,_Vsx"^v-pEq09'CU4&Dc1$fQExov$62l60cgCc%FnIwD=.UF^a>?5'9Kn[;433QFVV9M..2eN.@4ZWPGbdi<=?[:T>y?SD(R*-3It"Vj:)"dP Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV 0.83/762/Sun Mar 13 15:35:33 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 267 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: davem@davemloft.net Precedence: bulk X-list: netdev Content-Length: 278 Lines: 12 On Tue, 15 Mar 2005 15:44:08 +0100 Adrian Bunk wrote: > This patch makes a needlessly global struct static. > > Signed-off-by: Adrian Bunk You need to also kill the externs in net/inetpeer.h Please fix this up and resubmit. Thanks Adrian. From davem@davemloft.net Wed Mar 16 14:57:52 2005 Received: with ECARTIS (v1.0.0; list netdev); Wed, 16 Mar 2005 14:57:57 -0800 (PST) Received: from cheetah.davemloft.net (mail@dsl027-180-174.sfo1.dsl.speakeasy.net [216.27.180.174]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j2GMvnHU027837 for ; Wed, 16 Mar 2005 14:57:51 -0800 Received: from localhost ([127.0.0.1] helo=cheetah.davemloft.net ident=davem) by cheetah.davemloft.net with smtp (Exim 3.36 #1 (Debian)) id 1DBhNU-0001Hr-00; Wed, 16 Mar 2005 14:52:36 -0800 Date: Wed, 16 Mar 2005 14:52:36 -0800 From: "David S. Miller" To: Adrian Bunk Cc: netdev@oss.sgi.com, linux-kernel@vger.kernel.org Subject: Re: [2.6 patch] net/ipv6/ndisc.c: make a function static Message-Id: <20050316145236.2d9bb352.davem@davemloft.net> In-Reply-To: <20050315144712.GM3189@stusta.de> References: <20050315144712.GM3189@stusta.de> X-Mailer: Sylpheed version 1.0.1 (GTK+ 1.2.10; sparc-unknown-linux-gnu) X-Face: "_;p5u5aPsO,_Vsx"^v-pEq09'CU4&Dc1$fQExov$62l60cgCc%FnIwD=.UF^a>?5'9Kn[;433QFVV9M..2eN.@4ZWPGbdi<=?[:T>y?SD(R*-3It"Vj:)"dP Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV 0.83/762/Sun Mar 13 15:35:33 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 266 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: davem@davemloft.net Precedence: bulk X-list: netdev Content-Length: 202 Lines: 8 On Tue, 15 Mar 2005 15:47:13 +0100 Adrian Bunk wrote: > This patch makes a needlessly global function static. > > Signed-off-by: Adrian Bunk Applied, thanks Adrian. From davem@davemloft.net Wed Mar 16 14:59:59 2005 Received: with ECARTIS (v1.0.0; list netdev); Wed, 16 Mar 2005 15:00:06 -0800 (PST) Received: from cheetah.davemloft.net (mail@dsl027-180-174.sfo1.dsl.speakeasy.net [216.27.180.174]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j2GMxxcb028988 for ; Wed, 16 Mar 2005 14:59:59 -0800 Received: from localhost ([127.0.0.1] helo=cheetah.davemloft.net ident=davem) by cheetah.davemloft.net with smtp (Exim 3.36 #1 (Debian)) id 1DBhPd-0001IV-00; Wed, 16 Mar 2005 14:54:49 -0800 Date: Wed, 16 Mar 2005 14:54:48 -0800 From: "David S. Miller" To: "David S. Miller" Cc: bunk@stusta.de, netdev@oss.sgi.com, linux-kernel@vger.kernel.org Subject: Re: [2.6 patch] net/ipv4/inetpeer.c: make a struct static Message-Id: <20050316145448.5a45dddc.davem@davemloft.net> In-Reply-To: <20050316145343.6e31ba6a.davem@davemloft.net> References: <20050315144408.GL3189@stusta.de> <20050316145343.6e31ba6a.davem@davemloft.net> X-Mailer: Sylpheed version 1.0.1 (GTK+ 1.2.10; sparc-unknown-linux-gnu) X-Face: "_;p5u5aPsO,_Vsx"^v-pEq09'CU4&Dc1$fQExov$62l60cgCc%FnIwD=.UF^a>?5'9Kn[;433QFVV9M..2eN.@4ZWPGbdi<=?[:T>y?SD(R*-3It"Vj:)"dP Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV 0.83/762/Sun Mar 13 15:35:33 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 268 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: davem@davemloft.net Precedence: bulk X-list: netdev Content-Length: 517 Lines: 19 On Wed, 16 Mar 2005 14:53:43 -0800 "David S. Miller" wrote: > On Tue, 15 Mar 2005 15:44:08 +0100 > Adrian Bunk wrote: > > > This patch makes a needlessly global struct static. > > > > Signed-off-by: Adrian Bunk > > You need to also kill the externs in net/inetpeer.h > > Please fix this up and resubmit. Actually, Adrian, net/inetpeer.h makes use of inet_peer_unused_tailp in inline functions. How did you get a successful build after marking it static? From shemminger@osdl.org Wed Mar 16 15:04:23 2005 Received: with ECARTIS (v1.0.0; list netdev); Wed, 16 Mar 2005 15:04:29 -0800 (PST) Received: from smtp.osdl.org (fire.osdl.org [65.172.181.4]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j2GN4LAa029882 for ; Wed, 16 Mar 2005 15:04:23 -0800 Received: from shell0.pdx.osdl.net (fw.osdl.org [65.172.181.6]) by smtp.osdl.org (8.12.8/8.12.8) with ESMTP id j2GN4Fqi002879 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO); Wed, 16 Mar 2005 15:04:15 -0800 Received: from dxpl.pdx.osdl.net (dxpl.pdx.osdl.net [172.20.1.103]) by shell0.pdx.osdl.net (8.13.1/8.11.6) with ESMTP id j2GN4FBb012017; Wed, 16 Mar 2005 15:04:15 -0800 Date: Wed, 16 Mar 2005 15:04:33 -0800 From: Stephen Hemminger To: Jeff Garzik Cc: netdev@oss.sgi.com Subject: [RFT 3/3] 8139cp: allocate statistics space only when needed Message-ID: <20050316150433.68cd8cf5@dxpl.pdx.osdl.net> Organization: Open Source Development Lab X-Mailer: Sylpheed-Claws 1.0.1 (GTK+ 1.2.10; x86_64-unknown-linux-gnu) X-Face: &@E+xe?c%:&e4D{>f1O<&U>2qwRREG5!}7R4;D<"NO^UI2mJ[eEOA2*3>(`Th.yP,VDPo9$ /`~cw![cmj~~jWe?AHY7D1S+\}5brN0k*NE?pPh_'_d>6;XGG[\KDRViCfumZT3@[ Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Received-SPF: pass (domain of shemminger@osdl.org designates 65.172.181.6 as permitted sender) X-MIMEDefang-Filter: osdl$Revision: 1.105 $ X-Scanned-By: MIMEDefang 2.36 X-Virus-Scanned: ClamAV 0.83/762/Sun Mar 13 15:35:33 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 271 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: shemminger@osdl.org Precedence: bulk X-list: netdev Content-Length: 3339 Lines: 90 Don't crash if ethtool statistics are requested and device is down. Fix is to allocate pci space for statiistics only when needed. No locking necessary because ethtool calls occur under RTNL semaphore. Once again, not tested on real hardware, just making 8169 and 8139cp compatible; needs blessing by someone with a real board. diff -Nru a/drivers/net/8139cp.c b/drivers/net/8139cp.c --- a/drivers/net/8139cp.c 2005-03-16 14:55:31 -08:00 +++ b/drivers/net/8139cp.c 2005-03-16 14:55:31 -08:00 @@ -1101,10 +1101,6 @@ cp->rx_ring = mem; cp->tx_ring = &cp->rx_ring[CP_RX_RING_SIZE]; - mem += (CP_RING_BYTES - CP_STATS_SIZE); - cp->nic_stats = mem; - cp->nic_stats_dma = cp->ring_dma + (CP_RING_BYTES - CP_STATS_SIZE); - return cp_init_rings(cp); } @@ -1143,7 +1139,6 @@ pci_free_consistent(cp->pdev, CP_RING_BYTES, cp->rx_ring, cp->ring_dma); cp->rx_ring = NULL; cp->tx_ring = NULL; - cp->nic_stats = NULL; } static int cp_open (struct net_device *dev) @@ -1472,14 +1467,17 @@ struct ethtool_stats *estats, u64 *tmp_stats) { struct cp_private *cp = netdev_priv(dev); + struct cp_dma_stats *nic_stats; + dma_addr_t dma; int i; - memset(cp->nic_stats, 0, sizeof(struct cp_dma_stats)); + nic_stats = pci_alloc_consistent(cp->pdev, sizeof(*nic_stats), &dma); + if (!nic_stats) + return; /* begin NIC statistics dump */ - cpw32(StatsAddr + 4, (cp->nic_stats_dma >> 16) >> 16); - cpw32(StatsAddr, (cp->nic_stats_dma & 0xffffffff) | DumpStats); - cpr32(StatsAddr); + cpw32(StatsAddr + 4, (u64)dma >> 32); + cpw32(StatsAddr, ((u64)dma & DMA_32BIT_MASK) | DumpStats); for (i = 0; i < 1000; i++) { if ((cpr32(StatsAddr) & DumpStats) == 0) @@ -1490,21 +1488,23 @@ cpw32(StatsAddr + 4, 0); i = 0; - tmp_stats[i++] = le64_to_cpu(cp->nic_stats->tx_ok); - tmp_stats[i++] = le64_to_cpu(cp->nic_stats->rx_ok); - tmp_stats[i++] = le64_to_cpu(cp->nic_stats->tx_err); - tmp_stats[i++] = le32_to_cpu(cp->nic_stats->rx_err); - tmp_stats[i++] = le16_to_cpu(cp->nic_stats->rx_fifo); - tmp_stats[i++] = le16_to_cpu(cp->nic_stats->frame_align); - tmp_stats[i++] = le32_to_cpu(cp->nic_stats->tx_ok_1col); - tmp_stats[i++] = le32_to_cpu(cp->nic_stats->tx_ok_mcol); - tmp_stats[i++] = le64_to_cpu(cp->nic_stats->rx_ok_phys); - tmp_stats[i++] = le64_to_cpu(cp->nic_stats->rx_ok_bcast); - tmp_stats[i++] = le32_to_cpu(cp->nic_stats->rx_ok_mcast); - tmp_stats[i++] = le16_to_cpu(cp->nic_stats->tx_abort); - tmp_stats[i++] = le16_to_cpu(cp->nic_stats->tx_underrun); + tmp_stats[i++] = le64_to_cpu(nic_stats->tx_ok); + tmp_stats[i++] = le64_to_cpu(nic_stats->rx_ok); + tmp_stats[i++] = le64_to_cpu(nic_stats->tx_err); + tmp_stats[i++] = le32_to_cpu(nic_stats->rx_err); + tmp_stats[i++] = le16_to_cpu(nic_stats->rx_fifo); + tmp_stats[i++] = le16_to_cpu(nic_stats->frame_align); + tmp_stats[i++] = le32_to_cpu(nic_stats->tx_ok_1col); + tmp_stats[i++] = le32_to_cpu(nic_stats->tx_ok_mcol); + tmp_stats[i++] = le64_to_cpu(nic_stats->rx_ok_phys); + tmp_stats[i++] = le64_to_cpu(nic_stats->rx_ok_bcast); + tmp_stats[i++] = le32_to_cpu(nic_stats->rx_ok_mcast); + tmp_stats[i++] = le16_to_cpu(nic_stats->tx_abort); + tmp_stats[i++] = le16_to_cpu(nic_stats->tx_underrun); if (i != CP_NUM_STATS) BUG(); + + pci_free_consistent(cp->pdev, sizeof(*nic_stats), nic_stats, dma); } static struct ethtool_ops cp_ethtool_ops = { From shemminger@osdl.org Wed Mar 16 15:04:21 2005 Received: with ECARTIS (v1.0.0; list netdev); Wed, 16 Mar 2005 15:04:27 -0800 (PST) Received: from smtp.osdl.org (fire.osdl.org [65.172.181.4]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j2GN4J9B029880 for ; Wed, 16 Mar 2005 15:04:20 -0800 Received: from shell0.pdx.osdl.net (fw.osdl.org [65.172.181.6]) by smtp.osdl.org (8.12.8/8.12.8) with ESMTP id j2GN4Bqi002869 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO); Wed, 16 Mar 2005 15:04:11 -0800 Received: from dxpl.pdx.osdl.net (dxpl.pdx.osdl.net [172.20.1.103]) by shell0.pdx.osdl.net (8.13.1/8.11.6) with ESMTP id j2GN4AeN012011; Wed, 16 Mar 2005 15:04:11 -0800 Date: Wed, 16 Mar 2005 15:04:29 -0800 From: Stephen Hemminger To: Jeff Garzik Cc: netdev@oss.sgi.com Subject: [RFT 1/3] 8139: safer spin loop for get_statistics Message-ID: <20050316150429.375845f1@dxpl.pdx.osdl.net> Organization: Open Source Development Lab X-Mailer: Sylpheed-Claws 1.0.1 (GTK+ 1.2.10; x86_64-unknown-linux-gnu) X-Face: &@E+xe?c%:&e4D{>f1O<&U>2qwRREG5!}7R4;D<"NO^UI2mJ[eEOA2*3>(`Th.yP,VDPo9$ /`~cw![cmj~~jWe?AHY7D1S+\}5brN0k*NE?pPh_'_d>6;XGG[\KDRViCfumZT3@[ Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Received-SPF: pass (domain of shemminger@osdl.org designates 65.172.181.6 as permitted sender) X-MIMEDefang-Filter: osdl$Revision: 1.105 $ X-Scanned-By: MIMEDefang 2.36 X-Virus-Scanned: ClamAV 0.83/762/Sun Mar 13 15:35:33 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 269 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: shemminger@osdl.org Precedence: bulk X-list: netdev Content-Length: 1348 Lines: 42 The spin loop in 8139cp is limited to 100 iterations when pulling hardware stats. There is no allowance for processor speed so on a fast machine, the stats may not be available that fast. Also, if the board doesn't return soon enough make sure turn the address back off to prevent later updates when memory has gone away. This has not been tested on real 8139 hardware, but is based on the code for 8169, so could someone who has this hardware please check it. diff -Nru a/drivers/net/8139cp.c b/drivers/net/8139cp.c --- a/drivers/net/8139cp.c 2005-03-16 14:54:48 -08:00 +++ b/drivers/net/8139cp.c 2005-03-16 14:54:48 -08:00 @@ -1486,22 +1486,22 @@ struct ethtool_stats *estats, u64 *tmp_stats) { struct cp_private *cp = netdev_priv(dev); - unsigned int work = 100; int i; + memset(cp->nic_stats, 0, sizeof(struct cp_dma_stats)); + /* begin NIC statistics dump */ cpw32(StatsAddr + 4, (cp->nic_stats_dma >> 16) >> 16); cpw32(StatsAddr, (cp->nic_stats_dma & 0xffffffff) | DumpStats); cpr32(StatsAddr); - while (work-- > 0) { + for (i = 0; i < 1000; i++) { if ((cpr32(StatsAddr) & DumpStats) == 0) break; - cpu_relax(); + udelay(10); } - - if (cpr32(StatsAddr) & DumpStats) - return /* -EIO */; + cpw32(StatsAddr, 0); + cpw32(StatsAddr + 4, 0); i = 0; tmp_stats[i++] = le64_to_cpu(cp->nic_stats->tx_ok); From shemminger@osdl.org Wed Mar 16 15:04:22 2005 Received: with ECARTIS (v1.0.0; list netdev); Wed, 16 Mar 2005 15:04:28 -0800 (PST) Received: from smtp.osdl.org (fire.osdl.org [65.172.181.4]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j2GN4Ki6029881 for ; Wed, 16 Mar 2005 15:04:21 -0800 Received: from shell0.pdx.osdl.net (fw.osdl.org [65.172.181.6]) by smtp.osdl.org (8.12.8/8.12.8) with ESMTP id j2GN4Dqi002874 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO); Wed, 16 Mar 2005 15:04:13 -0800 Received: from dxpl.pdx.osdl.net (dxpl.pdx.osdl.net [172.20.1.103]) by shell0.pdx.osdl.net (8.13.1/8.11.6) with ESMTP id j2GN4DFC012014; Wed, 16 Mar 2005 15:04:13 -0800 Date: Wed, 16 Mar 2005 15:04:31 -0800 From: Stephen Hemminger To: Jeff Garzik Cc: netdev@oss.sgi.com Subject: [RFT 2/3] 8139cp: don't mix software and chip stats Message-ID: <20050316150431.6888fe55@dxpl.pdx.osdl.net> Organization: Open Source Development Lab X-Mailer: Sylpheed-Claws 1.0.1 (GTK+ 1.2.10; x86_64-unknown-linux-gnu) X-Face: &@E+xe?c%:&e4D{>f1O<&U>2qwRREG5!}7R4;D<"NO^UI2mJ[eEOA2*3>(`Th.yP,VDPo9$ /`~cw![cmj~~jWe?AHY7D1S+\}5brN0k*NE?pPh_'_d>6;XGG[\KDRViCfumZT3@[ Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Received-SPF: pass (domain of shemminger@osdl.org designates 65.172.181.6 as permitted sender) X-MIMEDefang-Filter: osdl$Revision: 1.105 $ X-Scanned-By: MIMEDefang 2.36 X-Virus-Scanned: ClamAV 0.83/762/Sun Mar 13 15:35:33 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 270 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: shemminger@osdl.org Precedence: bulk X-list: netdev Content-Length: 2713 Lines: 86 The rx_frags statistic is a software statistic and not a hardware statistic and it is pasted on to the end. Since the statistic is really a warning about overlength frames, it shouldn't be in the ethtool stats. Francois, could you make sure 8169 and 8139cp report fragments the same way. Once again, not tested on real hardware, just making 8169 and 8139cp compatible; needs blessing by someone with a real board. diff -Nru a/drivers/net/8139cp.c b/drivers/net/8139cp.c --- a/drivers/net/8139cp.c 2005-03-16 14:55:11 -08:00 +++ b/drivers/net/8139cp.c 2005-03-16 14:55:11 -08:00 @@ -113,7 +113,7 @@ #define CP_DEF_MSG_ENABLE (NETIF_MSG_DRV | \ NETIF_MSG_PROBE | \ NETIF_MSG_LINK) -#define CP_NUM_STATS 14 /* struct cp_dma_stats, plus one */ +#define CP_NUM_STATS 13 /* struct cp_dma_stats */ #define CP_STATS_SIZE 64 /* size in bytes of DMA stats block */ #define CP_REGS_SIZE (0xff + 1) #define CP_REGS_VER 1 /* version 1 */ @@ -331,10 +331,6 @@ u16 tx_underrun; } __attribute__((packed)); -struct cp_extra_stats { - unsigned long rx_frags; -}; - struct cp_private { void __iomem *regs; struct net_device *dev; @@ -346,9 +342,6 @@ u16 cpcmd; struct net_device_stats net_stats; - struct cp_extra_stats cp_stats; - struct cp_dma_stats *nic_stats; - dma_addr_t nic_stats_dma; unsigned rx_tail ____cacheline_aligned; struct cp_desc *rx_ring; @@ -420,7 +413,6 @@ { "rx_ok_mcast" }, { "tx_abort" }, { "tx_underrun" }, - { "rx_frags" }, }; @@ -543,19 +535,13 @@ len = (status & 0x1fff) - 4; mapping = cp->rx_skb[rx_tail].mapping; - if ((status & (FirstFrag | LastFrag)) != (FirstFrag | LastFrag)) { - /* we don't support incoming fragmented frames. - * instead, we attempt to ensure that the - * pre-allocated RX skbs are properly sized such - * that RX fragments are never encountered - */ - cp_rx_err_acct(cp, rx_tail, status, len); - cp->net_stats.rx_dropped++; - cp->cp_stats.rx_frags++; - goto rx_next; - } - - if (status & (RxError | RxErrFIFO)) { + /* we don't support incoming fragmented frames. + * instead, we attempt to ensure that the + * pre-allocated RX skbs are properly sized such + * that RX fragments are never encountered + */ + if ((status & (FirstFrag | LastFrag)) != (FirstFrag | LastFrag) + || (status & (RxError | RxErrFIFO))) { cp_rx_err_acct(cp, rx_tail, status, len); goto rx_next; } @@ -1517,7 +1503,6 @@ tmp_stats[i++] = le32_to_cpu(cp->nic_stats->rx_ok_mcast); tmp_stats[i++] = le16_to_cpu(cp->nic_stats->tx_abort); tmp_stats[i++] = le16_to_cpu(cp->nic_stats->tx_underrun); - tmp_stats[i++] = cp->cp_stats.rx_frags; if (i != CP_NUM_STATS) BUG(); } From romieu@fr.zoreil.com Wed Mar 16 15:24:09 2005 Received: with ECARTIS (v1.0.0; list netdev); Wed, 16 Mar 2005 15:24:15 -0800 (PST) Received: from fr.zoreil.com (electric-eye.fr.zoreil.com [213.41.134.224]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j2GNO8It031836 for ; Wed, 16 Mar 2005 15:24:09 -0800 Received: from electric-eye.fr.zoreil.com (localhost.localdomain [127.0.0.1]) by fr.zoreil.com (8.13.1/8.12.1) with ESMTP id j2GNM2tJ032606; Thu, 17 Mar 2005 00:22:02 +0100 Received: (from romieu@localhost) by electric-eye.fr.zoreil.com (8.13.1/8.13.1/Submit) id j2GNLqg2032604; Thu, 17 Mar 2005 00:21:52 +0100 Date: Thu, 17 Mar 2005 00:21:52 +0100 From: Francois Romieu To: Stephen Hemminger Cc: Jeff Garzik , netdev@oss.sgi.com Subject: Re: [RFT 1/3] 8139: safer spin loop for get_statistics Message-ID: <20050316232152.GA27664@electric-eye.fr.zoreil.com> References: <20050316150429.375845f1@dxpl.pdx.osdl.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20050316150429.375845f1@dxpl.pdx.osdl.net> User-Agent: Mutt/1.4.1i X-Organisation: Land of Sunshine Inc. X-Virus-Scanned: ClamAV 0.83/762/Sun Mar 13 15:35:33 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 272 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: romieu@fr.zoreil.com Precedence: bulk X-list: netdev Content-Length: 619 Lines: 26 Stephen Hemminger : [...] > diff -Nru a/drivers/net/8139cp.c b/drivers/net/8139cp.c > --- a/drivers/net/8139cp.c 2005-03-16 14:54:48 -08:00 > +++ b/drivers/net/8139cp.c 2005-03-16 14:54:48 -08:00 [...] > - while (work-- > 0) { > + for (i = 0; i < 1000; i++) { > if ((cpr32(StatsAddr) & DumpStats) == 0) > break; > - cpu_relax(); > + udelay(10); > } I am tempted to remove some stuff: while (cpr32(StatsAddr) & DumpStats) { if (msleep_interruptible(1)) break; } May be we could remove "cpr32(StatsAddr);" too as any posted write will be commited in the loop anyway. -- Ueimor From juhl-lkml@dif.dk Wed Mar 16 15:35:14 2005 Received: with ECARTIS (v1.0.0; list netdev); Wed, 16 Mar 2005 15:35:20 -0800 (PST) Received: from mail.dif.dk (mail.dif.dk [193.138.115.101]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j2GNZDR9032605 for ; Wed, 16 Mar 2005 15:35:14 -0800 Received: from localhost (localhost [127.0.0.1]) by mail.dif.dk (Postfix) with ESMTP id 80DCCFFD23 for ; Thu, 17 Mar 2005 00:43:46 +0100 (CET) Received: from mail.dif.dk ([127.0.0.1]) by localhost (saerimmer [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 03028-05 for ; Thu, 17 Mar 2005 00:43:43 +0100 (CET) Received: from diftmgw2.backbone.dif.dk (diftmgw2.backbone.dif.dk [10.227.136.246]) by mail.dif.dk (Postfix) with ESMTP id F3ADEFFD74 for ; Thu, 17 Mar 2005 00:43:40 +0100 (CET) Received: from DIFPST1A.backbone.dif.dk ([10.227.136.220]) by diftmgw2.backbone.dif.dk with InterScan Messaging Security Suite; Thu, 17 Mar 2005 00:34:14 +0100 Received: from [172.16.2.11] (10.227.136.29 [10.227.136.29]) by DIFPST1A.backbone.dif.dk with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2657.72) id GTRBNB10; Thu, 17 Mar 2005 00:35:01 +0100 Date: Thu, 17 Mar 2005 00:36:35 +0100 (CET) From: Jesper Juhl To: Alexey Kuznetsov Cc: "David S. Miller" , Pekka Savola , netdev@oss.sgi.com, linux-net@vger.kernel.org, linux-kernel@vger.kernel.org Subject: [PATCH] net, ipv6: remove redundant NULL checks before kfree in ip6_flowlabel.c Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Virus-Scanned: ClamAV 0.83/762/Sun Mar 13 15:35:33 2005 on oss.sgi.com X-Virus-Scanned: amavisd-new at dif.dk X-Virus-Status: Clean X-archive-position: 273 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: juhl-lkml@dif.dk Precedence: bulk X-list: netdev Content-Length: 1172 Lines: 49 kfree() has no problems dealing with NULL pointers, so wrapping checks for null round calls to it is redundant. This patch gets rid of two such checks in net/ipv6/ip6_flowlabel.c I considered also rewriting the if (fl) fl_free(fl); bit as simply fl_free(fl) as well, but that if() potentially saves two calls to kfree() inside fl_free as well as the call to fl_free itself, so I guess that's worth the if(). Please consider applying. Signed-off-by: Jesper Juhl diff -up linux-2.6.11-mm4-orig/net/ipv6/ip6_flowlabel.c linux-2.6.11-mm4/net/ipv6/ip6_flowlabel.c --- linux-2.6.11-mm4-orig/net/ipv6/ip6_flowlabel.c 2005-03-02 08:37:50.000000000 +0100 +++ linux-2.6.11-mm4/net/ipv6/ip6_flowlabel.c 2005-03-17 00:23:30.000000000 +0100 @@ -87,8 +87,7 @@ static struct ip6_flowlabel * fl_lookup( static void fl_free(struct ip6_flowlabel *fl) { - if (fl->opt) - kfree(fl->opt); + kfree(fl->opt); kfree(fl); } @@ -553,8 +552,7 @@ release: done: if (fl) fl_free(fl); - if (sfl1) - kfree(sfl1); + kfree(sfl1); return err; } -- Jesper Juhl PS. Please CC me on replies from lists other than linux-kernel From dada1@cosmosbay.com Wed Mar 16 15:38:54 2005 Received: with ECARTIS (v1.0.0; list netdev); Wed, 16 Mar 2005 15:39:00 -0800 (PST) Received: from gw1.cosmosbay.com (gw1.cosmosbay.com [62.23.185.226]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j2GNcrj9000730 for ; Wed, 16 Mar 2005 15:38:54 -0800 Received: from [192.168.0.3] ([84.5.80.184]) by gw1.cosmosbay.com (8.13.3/8.13.3) with ESMTP id j2GNcgjD023406; Thu, 17 Mar 2005 00:38:48 +0100 Message-ID: <4238C388.5040303@cosmosbay.com> Date: Thu, 17 Mar 2005 00:38:48 +0100 From: Eric Dumazet User-Agent: Mozilla Thunderbird 1.0 (Windows/20041206) X-Accept-Language: fr, en MIME-Version: 1.0 To: "David S. Miller" , netdev@oss.sgi.com Subject: [PATCH,resent] reduce sizeof(struct inet_peer) from 128 to 64 bytes on 64bits architectures Content-Type: multipart/mixed; boundary="------------060101080702030703080106" X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-1.6 (gw1.cosmosbay.com [62.23.185.226]); Thu, 17 Mar 2005 00:38:48 +0100 (CET) X-Virus-Scanned: ClamAV 0.83/762/Sun Mar 13 15:35:33 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 274 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: dada1@cosmosbay.com Precedence: bulk X-list: netdev Content-Length: 1277 Lines: 41 This is a multi-part message in MIME format. --------------060101080702030703080106 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Resent with diff file not tab/space mangled :( As peer_cachep uses kmem_cache_create("inet_peer_cache", ... SLAB_HWCACHE_ALIGN ...), better try to use exactly 64 bytes instead of 72 for struct inet_peer. This also means that this structure fits in one cache line on x86_64. Thank you Eric Dumazet --------------060101080702030703080106 Content-Type: text/plain; name="diff" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="diff" diff -Nru linux-2.6.11/include/net/inetpeer.h linux-2.6.11-ed/include/net/inetpeer.h --- linux-2.6.11/include/net/inetpeer.h 2005-03-02 08:37:48.000000000 +0100 +++ linux-2.6.11-ed/include/net/inetpeer.h 2005-03-16 18:52:49.000000000 +0100 @@ -19,9 +19,9 @@ { struct inet_peer *avl_left, *avl_right; struct inet_peer *unused_next, **unused_prevp; - atomic_t refcnt; unsigned long dtime; /* the time of last use of not * referenced entries */ + atomic_t refcnt; __u32 v4daddr; /* peer's address */ __u16 avl_height; __u16 ip_id_count; /* IP ID for the next packet */ --------------060101080702030703080106-- From romieu@fr.zoreil.com Wed Mar 16 15:44:12 2005 Received: with ECARTIS (v1.0.0; list netdev); Wed, 16 Mar 2005 15:44:17 -0800 (PST) Received: from fr.zoreil.com (electric-eye.fr.zoreil.com [213.41.134.224]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j2GNiAaQ001343 for ; Wed, 16 Mar 2005 15:44:11 -0800 Received: from electric-eye.fr.zoreil.com (localhost.localdomain [127.0.0.1]) by fr.zoreil.com (8.13.1/8.12.1) with ESMTP id j2GNg7QN000862; Thu, 17 Mar 2005 00:42:07 +0100 Received: (from romieu@localhost) by electric-eye.fr.zoreil.com (8.13.1/8.13.1/Submit) id j2GNg2O6000861; Thu, 17 Mar 2005 00:42:02 +0100 Date: Thu, 17 Mar 2005 00:42:02 +0100 From: Francois Romieu To: Stephen Hemminger Cc: Jeff Garzik , netdev@oss.sgi.com Subject: Re: [RFT 2/3] 8139cp: don't mix software and chip stats Message-ID: <20050316234202.GB27664@electric-eye.fr.zoreil.com> References: <20050316150431.6888fe55@dxpl.pdx.osdl.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20050316150431.6888fe55@dxpl.pdx.osdl.net> User-Agent: Mutt/1.4.1i X-Organisation: Land of Sunshine Inc. X-Virus-Scanned: ClamAV 0.83/762/Sun Mar 13 15:35:33 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 275 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: romieu@fr.zoreil.com Precedence: bulk X-list: netdev Content-Length: 1191 Lines: 33 Stephen Hemminger : > The rx_frags statistic is a software statistic and not a hardware statistic > and it is pasted on to the end. Since the statistic is really a warning about > overlength frames, it shouldn't be in the ethtool stats. > > Francois, could you make sure 8169 and 8139cp report fragments the same way. (not sure I understood the question) Do you mean that the r8169 driver should provide something like cp_rx_err_acct() ? [...] > diff -Nru a/drivers/net/8139cp.c b/drivers/net/8139cp.c > --- a/drivers/net/8139cp.c 2005-03-16 14:55:11 -08:00 > +++ b/drivers/net/8139cp.c 2005-03-16 14:55:11 -08:00 [...] > + /* we don't support incoming fragmented frames. > + * instead, we attempt to ensure that the > + * pre-allocated RX skbs are properly sized such > + * that RX fragments are never encountered > + */ > + if ((status & (FirstFrag | LastFrag)) != (FirstFrag | LastFrag) > + || (status & (RxError | RxErrFIFO))) { > cp_rx_err_acct(cp, rx_tail, status, len); > goto rx_next; > } I'll verify how the 8169 behaves wrt the Rx fifo error indication. It can apparently be set a bit too much (i.e. on every packet). -- Ueimor From shemminger@osdl.org Wed Mar 16 15:46:08 2005 Received: with ECARTIS (v1.0.0; list netdev); Wed, 16 Mar 2005 15:46:14 -0800 (PST) Received: from smtp.osdl.org (fire.osdl.org [65.172.181.4]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j2GNk5DN001837 for ; Wed, 16 Mar 2005 15:46:07 -0800 Received: from shell0.pdx.osdl.net (fw.osdl.org [65.172.181.6]) by smtp.osdl.org (8.12.8/8.12.8) with ESMTP id j2GNjuqi007001 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO); Wed, 16 Mar 2005 15:45:57 -0800 Received: from dxpl.pdx.osdl.net (dxpl.pdx.osdl.net [172.20.1.103]) by shell0.pdx.osdl.net (8.13.1/8.11.6) with ESMTP id j2GNjuew014771; Wed, 16 Mar 2005 15:45:56 -0800 Date: Wed, 16 Mar 2005 15:46:15 -0800 From: Stephen Hemminger To: Francois Romieu Cc: Jeff Garzik , netdev@oss.sgi.com Subject: Re: [RFT 2/3] 8139cp: don't mix software and chip stats Message-ID: <20050316154615.4ac080c2@dxpl.pdx.osdl.net> In-Reply-To: <20050316234202.GB27664@electric-eye.fr.zoreil.com> References: <20050316150431.6888fe55@dxpl.pdx.osdl.net> <20050316234202.GB27664@electric-eye.fr.zoreil.com> Organization: Open Source Development Lab X-Mailer: Sylpheed-Claws 1.0.1 (GTK+ 1.2.10; x86_64-unknown-linux-gnu) X-Face: &@E+xe?c%:&e4D{>f1O<&U>2qwRREG5!}7R4;D<"NO^UI2mJ[eEOA2*3>(`Th.yP,VDPo9$ /`~cw![cmj~~jWe?AHY7D1S+\}5brN0k*NE?pPh_'_d>6;XGG[\KDRViCfumZT3@[ Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Received-SPF: pass (domain of shemminger@osdl.org designates 65.172.181.6 as permitted sender) X-MIMEDefang-Filter: osdl$Revision: 1.105 $ X-Scanned-By: MIMEDefang 2.36 X-Virus-Scanned: ClamAV 0.83/762/Sun Mar 13 15:35:33 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 276 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: shemminger@osdl.org Precedence: bulk X-list: netdev Content-Length: 766 Lines: 18 On Thu, 17 Mar 2005 00:42:02 +0100 Francois Romieu wrote: > Stephen Hemminger : > > The rx_frags statistic is a software statistic and not a hardware statistic > > and it is pasted on to the end. Since the statistic is really a warning about > > overlength frames, it shouldn't be in the ethtool stats. > > > > Francois, could you make sure 8169 and 8139cp report fragments the same way. > > (not sure I understood the question) I just want frag handling to be similar in both driver since they both have the same underlying chipset. The stats should be the same, and any error recovery should be similar. Longer term, maybe the "grand unified phy" theory will allow making one driver with different PHY support. From bunk@stusta.de Wed Mar 16 17:08:29 2005 Received: with ECARTIS (v1.0.0; list netdev); Wed, 16 Mar 2005 17:08:35 -0800 (PST) Received: from mailout.stusta.mhn.de (mailout.stusta.mhn.de [141.84.69.5]) by oss.sgi.com (8.13.0/8.13.0) with SMTP id j2H18SaZ007957 for ; Wed, 16 Mar 2005 17:08:28 -0800 Received: (qmail 28373 invoked from network); 17 Mar 2005 01:08:22 -0000 Received: from r063144.stusta.swh.mhn.de (10.150.63.144) by mailhub.stusta.mhn.de with SMTP; 17 Mar 2005 01:08:22 -0000 Received: by r063144.stusta.swh.mhn.de (Postfix, from userid 1000) id E1D3CAF5BE; Thu, 17 Mar 2005 02:08:21 +0100 (CET) Date: Thu, 17 Mar 2005 02:08:21 +0100 From: Adrian Bunk To: "David S. Miller" Cc: netdev@oss.sgi.com, linux-kernel@vger.kernel.org Subject: [2.6 patch] net/ipv4/inetpeer.c: make a struct static Message-ID: <20050317010821.GE3251@stusta.de> References: <20050315144408.GL3189@stusta.de> <20050316145343.6e31ba6a.davem@davemloft.net> <20050316145448.5a45dddc.davem@davemloft.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20050316145448.5a45dddc.davem@davemloft.net> User-Agent: Mutt/1.5.6+20040907i X-Virus-Scanned: ClamAV 0.83/762/Sun Mar 13 15:35:33 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 277 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: bunk@stusta.de Precedence: bulk X-list: netdev Content-Length: 2373 Lines: 72 On Wed, Mar 16, 2005 at 02:54:48PM -0800, David S. Miller wrote: > On Wed, 16 Mar 2005 14:53:43 -0800 > "David S. Miller" wrote: > > > On Tue, 15 Mar 2005 15:44:08 +0100 > > Adrian Bunk wrote: > > > > > This patch makes a needlessly global struct static. > > > > > > Signed-off-by: Adrian Bunk > > > > You need to also kill the externs in net/inetpeer.h > > > > Please fix this up and resubmit. > > Actually, Adrian, net/inetpeer.h makes use of > inet_peer_unused_tailp in inline functions. > > How did you get a successful build after marking > it static? I might be too dumb for reading the output of grep (inetpeer.h...), but I'm testing all my patches with two .config's that are roughly equivalent to allyesconfig and allmodconfig. inet_peer_unused_tailp might be referenced from other files via inetpeer.h, but inet_peer_unused_head isn't referenced directly from other files. cu Adrian <-- snip --> This patch makes a needlessly global struct static. Signed-off-by: Adrian Bunk --- net/ipv4/inetpeer.c | 4 ++-- include/net/inetpeer.h | 1 - 2 files changed, 2 insertions(+), 3 deletions(-) --- linux-2.6.11-mm3-full/net/ipv4/inetpeer.c.old 2005-03-15 13:29:32.000000000 +0100 +++ linux-2.6.11-mm3-full/net/ipv4/inetpeer.c 2005-03-15 13:30:13.000000000 +0100 @@ -92,9 +92,9 @@ int inet_peer_minttl = 120 * HZ; /* TTL under high load: 120 sec */ int inet_peer_maxttl = 10 * 60 * HZ; /* usual time to live: 10 min */ +static struct inet_peer *inet_peer_unused_head; /* Exported for inet_putpeer inline function. */ -struct inet_peer *inet_peer_unused_head, - **inet_peer_unused_tailp = &inet_peer_unused_head; +struct inet_peer **inet_peer_unused_tailp = &inet_peer_unused_head; DEFINE_SPINLOCK(inet_peer_unused_lock); #define PEER_MAX_CLEANUP_WORK 30 --- linux-2.6.11-mm4-full/include/net/inetpeer.h.old 2005-03-17 00:32:16.000000000 +0100 +++ linux-2.6.11-mm4-full/include/net/inetpeer.h 2005-03-17 00:32:26.000000000 +0100 @@ -35,7 +35,6 @@ struct inet_peer *inet_getpeer(__u32 daddr, int create); extern spinlock_t inet_peer_unused_lock; -extern struct inet_peer *inet_peer_unused_head; extern struct inet_peer **inet_peer_unused_tailp; /* can be called from BH context or outside */ static inline void inet_putpeer(struct inet_peer *p) From yoshfuji@linux-ipv6.org Wed Mar 16 18:52:59 2005 Received: with ECARTIS (v1.0.0; list netdev); Wed, 16 Mar 2005 18:53:06 -0800 (PST) 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 j2H2qxQk011097 for ; Wed, 16 Mar 2005 18:52:59 -0800 Received: from localhost (localhost [127.0.0.1]) by yue.st-paulia.net (Postfix) with ESMTP id E081C33CE2; Thu, 17 Mar 2005 11:54:45 +0900 (JST) Date: Thu, 17 Mar 2005 11:54:44 +0900 (JST) Message-Id: <20050317.115444.31670680.yoshfuji@linux-ipv6.org> To: davem@davemloft.net, juhl-lkml@dif.dk Cc: kuznet@ms2.inr.ac.ru, davem@davemloft.net, pekkas@netcore.fi, netdev@oss.sgi.com, linux-net@vger.kernel.org, linux-kernel@vger.kernel.org, yoshfuji@linux-ipv6.org Subject: Re: [PATCH] net, ipv6: remove redundant NULL checks before kfree in ip6_flowlabel.c From: YOSHIFUJI Hideaki / =?iso-2022-jp?B?GyRCNUhGIzFRTEAbKEI=?= In-Reply-To: References: 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-Virus-Scanned: ClamAV 0.83/762/Sun Mar 13 15:35:33 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 278 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: yoshfuji@linux-ipv6.org Precedence: bulk X-list: netdev Content-Length: 1571 Lines: 66 In article (at Thu, 17 Mar 2005 00:36:35 +0100 (CET)), Jesper Juhl says: > I considered also rewriting the > if (fl) > fl_free(fl); > bit as simply fl_free(fl) as well, but that if() potentially saves two > calls to kfree() inside fl_free as well as the call to fl_free itself, so > I guess that's worth the if(). I don't mind calling kfree twice itself (because that function is not so performance critical), but fl_free(NULL) is out because if fl is NULL, kfree(fl->opt) is out. So, what do you think of checking fl inside fl_free like this? We can even make fl_free inline and check as following: if (fl) { kfree(fl->opt); kfree(fl); } Based on patch from Jesper Juhl . David? Signed-off-by: Hideaki YOSHIFUJI ===== net/ipv6/ip6_flowlabel.c 1.18 vs edited ===== --- 1.18/net/ipv6/ip6_flowlabel.c 2005-01-14 13:41:06 +09:00 +++ edited/net/ipv6/ip6_flowlabel.c 2005-03-17 11:23:32 +09:00 @@ -87,7 +87,7 @@ static void fl_free(struct ip6_flowlabel *fl) { - if (fl->opt) + if (fl) kfree(fl->opt); kfree(fl); } @@ -351,8 +351,7 @@ return fl; done: - if (fl) - fl_free(fl); + fl_free(fl); *err_p = err; return NULL; } @@ -551,10 +550,8 @@ } done: - if (fl) - fl_free(fl); - if (sfl1) - kfree(sfl1); + fl_free(fl); + kfree(sfl1); return err; } -- Hideaki YOSHIFUJI @ USAGI Project GPG FP: 9022 65EB 1ECF 3AD1 0BDF 80D8 4807 F894 E062 0EEA From davem@davemloft.net Wed Mar 16 20:39:56 2005 Received: with ECARTIS (v1.0.0; list netdev); Wed, 16 Mar 2005 20:40:06 -0800 (PST) Received: from cheetah.davemloft.net (mail@dsl027-180-174.sfo1.dsl.speakeasy.net [216.27.180.174]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j2H4dtZ9017962 for ; Wed, 16 Mar 2005 20:39:55 -0800 Received: from localhost ([127.0.0.1] helo=cheetah.davemloft.net ident=davem) by cheetah.davemloft.net with smtp (Exim 3.36 #1 (Debian)) id 1DBmlH-00033l-00; Wed, 16 Mar 2005 20:37:31 -0800 Date: Wed, 16 Mar 2005 20:37:31 -0800 From: "David S. Miller" To: Herbert Xu Cc: netdev@oss.sgi.com Subject: Re: [NETLINK] Fix multicast bind/autobind race Message-Id: <20050316203731.286c0ced.davem@davemloft.net> In-Reply-To: <20050315071909.GA5458@gondor.apana.org.au> References: <20050314094420.GA15349@gondor.apana.org.au> <20050314212845.6a7fd240.davem@davemloft.net> <20050315071909.GA5458@gondor.apana.org.au> X-Mailer: Sylpheed version 1.0.1 (GTK+ 1.2.10; sparc-unknown-linux-gnu) X-Face: "_;p5u5aPsO,_Vsx"^v-pEq09'CU4&Dc1$fQExov$62l60cgCc%FnIwD=.UF^a>?5'9Kn[;433QFVV9M..2eN.@4ZWPGbdi<=?[:T>y?SD(R*-3It"Vj:)"dP Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV 0.83/762/Sun Mar 13 15:35:33 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 279 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: davem@davemloft.net Precedence: bulk X-list: netdev Content-Length: 298 Lines: 11 On Tue, 15 Mar 2005 18:19:09 +1100 Herbert Xu wrote: > On Mon, Mar 14, 2005 at 09:28:45PM -0800, David S. Miller wrote: > > > > I suspect a 2.4.x version is necessary as well. Could you cook > > one up for me? Thanks. > > Sure, here it is. Thanks a lot Herbert. From davem@davemloft.net Wed Mar 16 20:45:38 2005 Received: with ECARTIS (v1.0.0; list netdev); Wed, 16 Mar 2005 20:45:43 -0800 (PST) Received: from cheetah.davemloft.net (mail@dsl027-180-174.sfo1.dsl.speakeasy.net [216.27.180.174]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j2H4jcjX018695 for ; Wed, 16 Mar 2005 20:45:38 -0800 Received: from localhost ([127.0.0.1] helo=cheetah.davemloft.net ident=davem) by cheetah.davemloft.net with smtp (Exim 3.36 #1 (Debian)) id 1DBmo1-00034q-00; Wed, 16 Mar 2005 20:40:21 -0800 Date: Wed, 16 Mar 2005 20:40:20 -0800 From: "David S. Miller" To: Adrian Bunk Cc: netdev@oss.sgi.com, linux-kernel@vger.kernel.org Subject: Re: [2.6 patch] net/ipv4/inetpeer.c: make a struct static Message-Id: <20050316204020.152b35cc.davem@davemloft.net> In-Reply-To: <20050317010821.GE3251@stusta.de> References: <20050315144408.GL3189@stusta.de> <20050316145343.6e31ba6a.davem@davemloft.net> <20050316145448.5a45dddc.davem@davemloft.net> <20050317010821.GE3251@stusta.de> X-Mailer: Sylpheed version 1.0.1 (GTK+ 1.2.10; sparc-unknown-linux-gnu) X-Face: "_;p5u5aPsO,_Vsx"^v-pEq09'CU4&Dc1$fQExov$62l60cgCc%FnIwD=.UF^a>?5'9Kn[;433QFVV9M..2eN.@4ZWPGbdi<=?[:T>y?SD(R*-3It"Vj:)"dP Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV 0.83/762/Sun Mar 13 15:35:33 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 280 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: davem@davemloft.net Precedence: bulk X-list: netdev Content-Length: 340 Lines: 11 On Thu, 17 Mar 2005 02:08:21 +0100 Adrian Bunk wrote: > inet_peer_unused_tailp might be referenced from other files via > inetpeer.h, but inet_peer_unused_head isn't referenced directly from > other files. I misread your patch, I thought you were marking both as static. My bad, sorry. I'll apply your patch, thanks. From davem@redhat.com Wed Mar 16 20:56:22 2005 Received: with ECARTIS (v1.0.0; list netdev); Wed, 16 Mar 2005 20:56:28 -0800 (PST) Received: from mx1.redhat.com (mx1.redhat.com [66.187.233.31]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j2H4uLSU019311 for ; Wed, 16 Mar 2005 20:56:22 -0800 Received: from int-mx1.corp.redhat.com (int-mx1.corp.redhat.com [172.16.52.254]) by mx1.redhat.com (8.12.11/8.12.11) with ESMTP id j2H4uD31012017; Wed, 16 Mar 2005 23:56:13 -0500 Received: from devserv.devel.redhat.com (devserv.devel.redhat.com [172.16.58.1]) by int-mx1.corp.redhat.com (8.11.6/8.11.6) with ESMTP id j2H4uDY11546; Wed, 16 Mar 2005 23:56:13 -0500 Received: from cheetah.davemloft.net (localhost.localdomain [127.0.0.1]) by devserv.devel.redhat.com (8.12.11/8.12.11) with SMTP id j2H4uCZw020931; Wed, 16 Mar 2005 23:56:13 -0500 Date: Wed, 16 Mar 2005 20:54:08 -0800 From: "David S. Miller" To: Eric Dumazet Cc: netdev@oss.sgi.com Subject: Re: [PATCH,resent] reduce sizeof(struct inet_peer) from 128 to 64 bytes on 64bits architectures Message-Id: <20050316205408.01d24df2.davem@redhat.com> In-Reply-To: <4238C388.5040303@cosmosbay.com> References: <4238C388.5040303@cosmosbay.com> X-Mailer: Sylpheed version 1.0.1 (GTK+ 1.2.10; sparc-unknown-linux-gnu) X-Face: "_;p5u5aPsO,_Vsx"^v-pEq09'CU4&Dc1$fQExov$62l60cgCc%FnIwD=.UF^a>?5'9Kn[;433QFVV9M..2eN.@4ZWPGbdi<=?[:T>y?SD(R*-3It"Vj:)"dP Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV 0.83/762/Sun Mar 13 15:35:33 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 281 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: davem@redhat.com Precedence: bulk X-list: netdev Content-Length: 156 Lines: 6 On Thu, 17 Mar 2005 00:38:48 +0100 Eric Dumazet wrote: > Resent with diff file not tab/space mangled :( Patch applied, thanks Eric. From davem@davemloft.net Wed Mar 16 21:00:37 2005 Received: with ECARTIS (v1.0.0; list netdev); Wed, 16 Mar 2005 21:00:46 -0800 (PST) Received: from cheetah.davemloft.net (mail@dsl027-180-174.sfo1.dsl.speakeasy.net [216.27.180.174]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j2H50bEM020025 for ; Wed, 16 Mar 2005 21:00:37 -0800 Received: from localhost ([127.0.0.1] helo=cheetah.davemloft.net ident=davem) by cheetah.davemloft.net with smtp (Exim 3.36 #1 (Debian)) id 1DBn5L-0003Bj-00; Wed, 16 Mar 2005 20:58:15 -0800 Date: Wed, 16 Mar 2005 20:58:15 -0800 From: "David S. Miller" To: Cc: juhl-lkml@dif.dk, kuznet@ms2.inr.ac.ru, pekkas@netcore.fi, netdev@oss.sgi.com, linux-net@vger.kernel.org, linux-kernel@vger.kernel.org Subject: Re: [PATCH] net, ipv6: remove redundant NULL checks before kfree in ip6_flowlabel.c Message-Id: <20050316205815.3e30e111.davem@davemloft.net> In-Reply-To: <20050317.115444.31670680.yoshfuji@linux-ipv6.org> References: <20050317.115444.31670680.yoshfuji@linux-ipv6.org> X-Mailer: Sylpheed version 1.0.1 (GTK+ 1.2.10; sparc-unknown-linux-gnu) X-Face: "_;p5u5aPsO,_Vsx"^v-pEq09'CU4&Dc1$fQExov$62l60cgCc%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 X-Virus-Scanned: ClamAV 0.83/762/Sun Mar 13 15:35:33 2005 on oss.sgi.com X-Virus-Status: Clean Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by oss.sgi.com id j2H50bEM020025 X-archive-position: 282 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: davem@davemloft.net Precedence: bulk X-list: netdev Content-Length: 295 Lines: 13 On Thu, 17 Mar 2005 11:54:44 +0900 (JST) YOSHIFUJI Hideaki / $B5HF#1QL@(B wrote: > Based on patch from Jesper Juhl . > > David? > > Signed-off-by: Hideaki YOSHIFUJI This version of the patch is fine, applied. Thanks. From juhl-lkml@dif.dk Wed Mar 16 22:19:41 2005 Received: with ECARTIS (v1.0.0; list netdev); Wed, 16 Mar 2005 22:19:47 -0800 (PST) Received: from mail.dif.dk (mail.dif.dk [193.138.115.101]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j2H6JevE022469 for ; Wed, 16 Mar 2005 22:19:40 -0800 Received: from localhost (localhost [127.0.0.1]) by mail.dif.dk (Postfix) with ESMTP id D6885FFD07 for ; Thu, 17 Mar 2005 07:28:13 +0100 (CET) Received: from mail.dif.dk ([127.0.0.1]) by localhost (saerimmer [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 12714-03 for ; Thu, 17 Mar 2005 07:28:09 +0100 (CET) Received: from diftmgw2.backbone.dif.dk (diftmgw2.backbone.dif.dk [10.227.136.246]) by mail.dif.dk (Postfix) with ESMTP id 8F1A4FFED8 for ; Thu, 17 Mar 2005 07:28:07 +0100 (CET) Received: from DIFPST1A.backbone.dif.dk ([10.227.136.220]) by diftmgw2.backbone.dif.dk with InterScan Messaging Security Suite; Thu, 17 Mar 2005 07:18:39 +0100 Received: from [172.16.2.11] (10.227.136.29 [10.227.136.29]) by DIFPST1A.backbone.dif.dk with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2657.72) id GTRBNBV7; Thu, 17 Mar 2005 07:19:26 +0100 Date: Thu, 17 Mar 2005 07:21:01 +0100 (CET) From: Jesper Juhl To: YOSHIFUJI Hideaki / =?iso-2022-jp?B?GyRCNUhGIzFRTEAbKEI=?= Cc: davem@davemloft.net, kuznet@ms2.inr.ac.ru, pekkas@netcore.fi, netdev@oss.sgi.com, linux-net@vger.kernel.org, linux-kernel@vger.kernel.org Subject: Re: [PATCH] net, ipv6: remove redundant NULL checks before kfree in ip6_flowlabel.c In-Reply-To: <20050317.115444.31670680.yoshfuji@linux-ipv6.org> Message-ID: References: <20050317.115444.31670680.yoshfuji@linux-ipv6.org> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=ISO-8859-1 X-Virus-Scanned: ClamAV 0.83/762/Sun Mar 13 15:35:33 2005 on oss.sgi.com X-Virus-Scanned: amavisd-new at dif.dk X-Virus-Status: Clean Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from QUOTED-PRINTABLE to 8bit by oss.sgi.com id j2H6JevE022469 X-archive-position: 283 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: juhl-lkml@dif.dk Precedence: bulk X-list: netdev Content-Length: 744 Lines: 22 On Thu, 17 Mar 2005, YOSHIFUJI Hideaki / [iso-2022-jp] µÈÆ£±ÑÌÀ wrote: > In article (at Thu, 17 Mar 2005 00:36:35 +0100 (CET)), Jesper Juhl says: > > > I considered also rewriting the > > if (fl) > > fl_free(fl); > > bit as simply fl_free(fl) as well, but that if() potentially saves two > > calls to kfree() inside fl_free as well as the call to fl_free itself, so > > I guess that's worth the if(). > > I don't mind calling kfree twice itself (because that function is not > so performance critical), but fl_free(NULL) is out because > if fl is NULL, kfree(fl->opt) is out. > Yes, you are right ofcourse. Thanks. -- Jesper From herbert@gondor.apana.org.au Thu Mar 17 02:53:48 2005 Received: with ECARTIS (v1.0.0; list netdev); Thu, 17 Mar 2005 02:53:56 -0800 (PST) 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 j2HArkAS006623 for ; Thu, 17 Mar 2005 02:53:47 -0800 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 1DBsc6-0002Tf-00; Thu, 17 Mar 2005 21:52:26 +1100 Received: from herbert by gondolin.me.apana.org.au with local (Exim 3.36 #1 (Debian)) id 1DBsbS-0005ES-00; Thu, 17 Mar 2005 21:51:46 +1100 Date: Thu, 17 Mar 2005 21:51:45 +1100 To: "David S. Miller" Cc: Patrick McHardy , kuznet@ms2.inr.ac.ru, yoshfuji@linux-ipv6.org, netdev@oss.sgi.com Subject: [IPV4] Send TCP reset through dst_output in ipt_REJECT Message-ID: <20050317105145.GA20089@gondor.apana.org.au> References: <20050315091904.GA6256@gondor.apana.org.au> <20050315095837.GA7130@gondor.apana.org.au> <20050315100522.GA7275@gondor.apana.org.au> <20050315102450.0f3f1618.davem@davemloft.net> <42373142.6090902@trash.net> <20050315204006.GB22349@gondor.apana.org.au> <42374A35.6020308@trash.net> <20050316105100.GA8404@gondor.apana.org.au> <42388263.3090602@trash.net> <20050316144424.689d5981.davem@davemloft.net> Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="VS++wcV0S1rZb1Fb" Content-Disposition: inline In-Reply-To: <20050316144424.689d5981.davem@davemloft.net> User-Agent: Mutt/1.5.6+20040907i From: Herbert Xu X-Virus-Scanned: ClamAV 0.83/762/Sun Mar 13 15:35:33 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 284 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: herbert@gondor.apana.org.au Precedence: bulk X-list: netdev Content-Length: 1221 Lines: 45 --VS++wcV0S1rZb1Fb Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Hi Dave: I noticed that the TCP reset code in ipt_REJECT didn't call dst_output either so it also bypasses IPsec processing. Here is a patch to fix that and use the correct MTU value. Signed-off-by: Herbert Xu Cheers, -- Visit Openswan at http://www.openswan.org/ Email: Herbert Xu ~{PmV>HI~} Home Page: http://gondor.apana.org.au/~herbert/ PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt --VS++wcV0S1rZb1Fb Content-Type: text/plain; charset=us-ascii Content-Disposition: attachment; filename=xfrm-20 ===== net/ipv4/netfilter/ipt_REJECT.c 1.36 vs edited ===== --- 1.36/net/ipv4/netfilter/ipt_REJECT.c 2005-03-17 09:44:14 +11:00 +++ edited/net/ipv4/netfilter/ipt_REJECT.c 2005-03-17 14:18:20 +11:00 @@ -207,13 +207,13 @@ nskb->nh.iph->ihl); /* "Never happens" */ - if (nskb->len > dst_pmtu(nskb->dst)) + if (nskb->len > dst_mtu(nskb->dst)) goto free_nskb; nf_ct_attach(nskb, oldskb); NF_HOOK(PF_INET, NF_IP_LOCAL_OUT, nskb, NULL, nskb->dst->dev, - ip_finish_output); + dst_output); return; free_nskb: --VS++wcV0S1rZb1Fb-- From davem@davemloft.net Thu Mar 17 10:10:11 2005 Received: with ECARTIS (v1.0.0; list netdev); Thu, 17 Mar 2005 10:10:18 -0800 (PST) Received: from cheetah.davemloft.net (mail@dsl027-180-174.sfo1.dsl.speakeasy.net [216.27.180.174]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j2HIABDi012661 for ; Thu, 17 Mar 2005 10:10:11 -0800 Received: from localhost ([127.0.0.1] helo=cheetah.davemloft.net ident=davem) by cheetah.davemloft.net with smtp (Exim 3.36 #1 (Debian)) id 1DBzOS-00073o-00; Thu, 17 Mar 2005 10:06:48 -0800 Date: Thu, 17 Mar 2005 10:06:47 -0800 From: "David S. Miller" To: Herbert Xu Cc: kaber@trash.net, kuznet@ms2.inr.ac.ru, yoshfuji@linux-ipv6.org, netdev@oss.sgi.com Subject: Re: [IPV4] Send TCP reset through dst_output in ipt_REJECT Message-Id: <20050317100647.7e518728.davem@davemloft.net> In-Reply-To: <20050317105145.GA20089@gondor.apana.org.au> References: <20050315091904.GA6256@gondor.apana.org.au> <20050315095837.GA7130@gondor.apana.org.au> <20050315100522.GA7275@gondor.apana.org.au> <20050315102450.0f3f1618.davem@davemloft.net> <42373142.6090902@trash.net> <20050315204006.GB22349@gondor.apana.org.au> <42374A35.6020308@trash.net> <20050316105100.GA8404@gondor.apana.org.au> <42388263.3090602@trash.net> <20050316144424.689d5981.davem@davemloft.net> <20050317105145.GA20089@gondor.apana.org.au> X-Mailer: Sylpheed version 1.0.1 (GTK+ 1.2.10; sparc-unknown-linux-gnu) X-Face: "_;p5u5aPsO,_Vsx"^v-pEq09'CU4&Dc1$fQExov$62l60cgCc%FnIwD=.UF^a>?5'9Kn[;433QFVV9M..2eN.@4ZWPGbdi<=?[:T>y?SD(R*-3It"Vj:)"dP Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV 0.83/765/Thu Mar 17 00:42:45 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 285 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: davem@davemloft.net Precedence: bulk X-list: netdev Content-Length: 359 Lines: 10 On Thu, 17 Mar 2005 21:51:45 +1100 Herbert Xu wrote: > I noticed that the TCP reset code in ipt_REJECT didn't call dst_output > either so it also bypasses IPsec processing. Here is a patch to fix > that and use the correct MTU value. > > Signed-off-by: Herbert Xu Applied, thanks a lot Herbert. From yoshfuji@linux-ipv6.org Thu Mar 17 10:29:01 2005 Received: with ECARTIS (v1.0.0; list netdev); Thu, 17 Mar 2005 10:29:06 -0800 (PST) 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 j2HIT0a1014478 for ; Thu, 17 Mar 2005 10:29:01 -0800 Received: from localhost (localhost [127.0.0.1]) by yue.st-paulia.net (Postfix) with ESMTP id 49E5933CFD; Fri, 18 Mar 2005 03:30:48 +0900 (JST) Date: Fri, 18 Mar 2005 03:30:39 +0900 (JST) Message-Id: <20050318.033039.116005935.yoshfuji@linux-ipv6.org> To: davem@davemloft.net Cc: yoshfuji@linux-ipv6.org, netdev@oss.sgi.com Subject: [PATCH] [NET] Save space for sk_alloc_slab() failure message. 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-Virus-Scanned: ClamAV 0.83/765/Thu Mar 17 00:42:45 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 286 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: yoshfuji@linux-ipv6.org Precedence: bulk X-list: netdev Content-Length: 2825 Lines: 110 Hello. (Almost) all callers of sk_alloc_slab() handle its failure like this: if (sk_alloc_slab(&prot, "sock")) { sk_alloc_slab_error(&prot); /* except for sctp */ goto out; } So, why don't we move sk_alloc_slab_error() into sk_alloc_slab() for simplification and save text segment? Signed-off-by: Hideaki YOSHIFUJI ===== include/net/sock.h 1.99 vs edited ===== --- 1.99/include/net/sock.h 2005-03-16 08:24:42 +09:00 +++ edited/include/net/sock.h 2005-03-18 03:00:59 +09:00 @@ -561,11 +561,6 @@ extern int sk_alloc_slab(struct proto *prot, char *name); extern void sk_free_slab(struct proto *prot); -static inline void sk_alloc_slab_error(struct proto *proto) -{ - printk(KERN_CRIT "%s: Can't create sock SLAB cache!\n", proto->name); -} - static __inline__ void sk_set_owner(struct sock *sk, struct module *owner) { /* ===== net/core/sock.c 1.65 vs edited ===== --- 1.65/net/core/sock.c 2005-03-16 08:20:37 +09:00 +++ edited/net/core/sock.c 2005-03-18 03:05:04 +09:00 @@ -1374,7 +1374,13 @@ prot->slab_obj_size, 0, SLAB_HWCACHE_ALIGN, NULL, NULL); - return prot->slab != NULL ? 0 : -ENOBUFS; + if (prot->slab == NULL) { + printk(KERN_CRIT "%s: Can't create sock SLAB cache!\n", + prot->name); + return -ENOBUFS; + } + + return 0; } EXPORT_SYMBOL(sk_alloc_slab); ===== net/ipv4/af_inet.c 1.84 vs edited ===== --- 1.84/net/ipv4/af_inet.c 2005-01-14 13:41:05 +09:00 +++ edited/net/ipv4/af_inet.c 2005-03-18 03:00:06 +09:00 @@ -1027,20 +1027,16 @@ } rc = sk_alloc_slab(&tcp_prot, "tcp_sock"); - if (rc) { - sk_alloc_slab_error(&tcp_prot); + if (rc) goto out; - } + rc = sk_alloc_slab(&udp_prot, "udp_sock"); - if (rc) { - sk_alloc_slab_error(&udp_prot); + if (rc) goto out_tcp_free_slab; - } + rc = sk_alloc_slab(&raw_prot, "raw_sock"); - if (rc) { - sk_alloc_slab_error(&raw_prot); + if (rc) goto out_udp_free_slab; - } /* * Tell SOCKET that we are alive... ===== net/ipv6/af_inet6.c 1.90 vs edited ===== --- 1.90/net/ipv6/af_inet6.c 2005-03-10 13:39:44 +09:00 +++ edited/net/ipv6/af_inet6.c 2005-03-18 03:00:29 +09:00 @@ -711,20 +711,17 @@ } err = sk_alloc_slab(&tcpv6_prot, "tcpv6_sock"); - if (err) { - sk_alloc_slab_error(&tcpv6_prot); + if (err) goto out; - } + err = sk_alloc_slab(&udpv6_prot, "udpv6_sock"); - if (err) { - sk_alloc_slab_error(&udpv6_prot); + if (err) goto out_tcp_free_slab; - } + err = sk_alloc_slab(&rawv6_prot, "rawv6_sock"); - if (err) { - sk_alloc_slab_error(&rawv6_prot); + if (err) goto out_udp_free_slab; - } + /* Register the socket-side information for inet6_create. */ for(r = &inetsw6[0]; r < &inetsw6[SOCK_MAX]; ++r) -- Hideaki YOSHIFUJI @ USAGI Project GPG FP: 9022 65EB 1ECF 3AD1 0BDF 80D8 4807 F894 E062 0EEA From davem@davemloft.net Thu Mar 17 10:33:25 2005 Received: with ECARTIS (v1.0.0; list netdev); Thu, 17 Mar 2005 10:33:29 -0800 (PST) Received: from cheetah.davemloft.net (mail@dsl027-180-174.sfo1.dsl.speakeasy.net [216.27.180.174]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j2HIXO7G015098 for ; Thu, 17 Mar 2005 10:33:25 -0800 Received: from localhost ([127.0.0.1] helo=cheetah.davemloft.net ident=davem) by cheetah.davemloft.net with smtp (Exim 3.36 #1 (Debian)) id 1DBzlz-0007ER-00; Thu, 17 Mar 2005 10:31:07 -0800 Date: Thu, 17 Mar 2005 10:31:06 -0800 From: "David S. Miller" To: yoshfuji@linux-ipv6.org Cc: netdev@oss.sgi.com Subject: Re: [PATCH] [NET] Save space for sk_alloc_slab() failure message. Message-Id: <20050317103106.009e6b2a.davem@davemloft.net> In-Reply-To: <20050318.033039.116005935.yoshfuji@linux-ipv6.org> References: <20050318.033039.116005935.yoshfuji@linux-ipv6.org> X-Mailer: Sylpheed version 1.0.1 (GTK+ 1.2.10; sparc-unknown-linux-gnu) X-Face: "_;p5u5aPsO,_Vsx"^v-pEq09'CU4&Dc1$fQExov$62l60cgCc%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 X-Virus-Scanned: ClamAV 0.83/765/Thu Mar 17 00:42:45 2005 on oss.sgi.com X-Virus-Status: Clean Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by oss.sgi.com id j2HIXO7G015098 X-archive-position: 287 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: davem@davemloft.net Precedence: bulk X-list: netdev Content-Length: 520 Lines: 19 On Fri, 18 Mar 2005 03:30:39 +0900 (JST) YOSHIFUJI Hideaki / $B5HF#1QL@(B wrote: > (Almost) all callers of sk_alloc_slab() handle its failure like this: > > if (sk_alloc_slab(&prot, "sock")) { > sk_alloc_slab_error(&prot); /* except for sctp */ > goto out; > } > > So, why don't we move sk_alloc_slab_error() into sk_alloc_slab() > for simplification and save text segment? > > Signed-off-by: Hideaki YOSHIFUJI Looks great, patch applied. Thanks. From juhl-lkml@dif.dk Thu Mar 17 11:32:42 2005 Received: with ECARTIS (v1.0.0; list netdev); Thu, 17 Mar 2005 11:32:48 -0800 (PST) Received: from mail.dif.dk (mail.dif.dk [193.138.115.101]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j2HJWfd0021994 for ; Thu, 17 Mar 2005 11:32:41 -0800 Received: from localhost (localhost [127.0.0.1]) by mail.dif.dk (Postfix) with ESMTP id 1B056FFD50 for ; Thu, 17 Mar 2005 20:41:15 +0100 (CET) Received: from mail.dif.dk ([127.0.0.1]) by localhost (saerimmer [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 17693-09 for ; Thu, 17 Mar 2005 20:41:10 +0100 (CET) Received: from diftmgw2.backbone.dif.dk (diftmgw2.backbone.dif.dk [10.227.136.246]) by mail.dif.dk (Postfix) with ESMTP id 1704BFFD3E for ; Thu, 17 Mar 2005 20:41:10 +0100 (CET) Received: from DIFPST1A.backbone.dif.dk ([10.227.136.220]) by diftmgw2.backbone.dif.dk with InterScan Messaging Security Suite; Thu, 17 Mar 2005 20:31:39 +0100 Received: from [172.16.2.11] (10.227.136.29 [10.227.136.29]) by DIFPST1A.backbone.dif.dk with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2657.72) id GTRBNJZN; Thu, 17 Mar 2005 20:32:26 +0100 Date: Thu, 17 Mar 2005 20:34:05 +0100 (CET) From: Jesper Juhl To: netdev@oss.sgi.com Cc: Orest Zborowski , Ross Biro , "Fred N. van Kempen" , "David S. Miller" , linux-net@vger.kernel.org, linux-kernel@vger.kernel.org Subject: [PATCH] net/socket.c : remove redundant NULL pointer check before kfree() Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Virus-Scanned: ClamAV 0.83/765/Thu Mar 17 00:42:45 2005 on oss.sgi.com X-Virus-Scanned: amavisd-new at dif.dk X-Virus-Status: Clean X-archive-position: 288 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: juhl-lkml@dif.dk Precedence: bulk X-list: netdev Content-Length: 536 Lines: 25 kfree() handles NULL pointers just fine, checking first is pointless. Signed-off-by: Jesper Juhl --- linux-2.6.11-mm4-orig/net/socket.c 2005-03-16 15:45:42.000000000 +0100 +++ linux-2.6.11-mm4/net/socket.c 2005-03-17 20:25:36.000000000 +0100 @@ -993,8 +993,7 @@ static int sock_fasync(int fd, struct fi sock = SOCKET_I(filp->f_dentry->d_inode); if ((sk=sock->sk) == NULL) { - if (fna) - kfree(fna); + kfree(fna); return -EINVAL; } (Please CC me on replies to lists other than linux-kernel) From dada1@cosmosbay.com Thu Mar 17 11:52:54 2005 Received: with ECARTIS (v1.0.0; list netdev); Thu, 17 Mar 2005 11:53:03 -0800 (PST) Received: from gw1.cosmosbay.com (gw1.cosmosbay.com [62.23.185.226]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j2HJqqBx022996 for ; Thu, 17 Mar 2005 11:52:53 -0800 Received: from [192.168.0.3] ([84.5.80.184]) by gw1.cosmosbay.com (8.13.3/8.13.3) with ESMTP id j2HJqcjw022728; Thu, 17 Mar 2005 20:52:43 +0100 Message-ID: <4239E00C.4080309@cosmosbay.com> Date: Thu, 17 Mar 2005 20:52:44 +0100 From: Eric Dumazet User-Agent: Mozilla Thunderbird 1.0 (Windows/20041206) X-Accept-Language: fr, en MIME-Version: 1.0 To: "David S. Miller" CC: netdev@oss.sgi.com Subject: Re: [BUG] overflow in net/ipv4/route.c rt_check_expire() References: <42370997.6010302@cosmosbay.com> <20050315103253.590c8bfc.davem@davemloft.net> <42380EC6.60100@cosmosbay.com> <20050316140915.0f6b9528.davem@davemloft.net> In-Reply-To: <20050316140915.0f6b9528.davem@davemloft.net> Content-Type: multipart/mixed; boundary="------------040704050108060909010704" X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-1.6 (gw1.cosmosbay.com [62.23.185.226]); Thu, 17 Mar 2005 20:52:44 +0100 (CET) X-Virus-Scanned: ClamAV 0.83/765/Thu Mar 17 00:42:45 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 289 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: dada1@cosmosbay.com Precedence: bulk X-list: netdev Content-Length: 12402 Lines: 405 This is a multi-part message in MIME format. --------------040704050108060909010704 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit David S. Miller a écrit : > On Wed, 16 Mar 2005 11:47:34 +0100 > Eric Dumazet wrote: > > >>The rt_check_expire() has a serious problem on machines with large >>route caches, and a standard HZ value of 1000. >> >>With default values, ie ip_rt_gc_interval = 60*HZ = 60000 ; >> >>the loop count : >> >> for (t = ip_rt_gc_interval << rt_hash_log; t >= 0; >> >> >>overflows (t is a 31 bit value) as soon rt_hash_log is >= 16 (65536 >>slots in route cache hash table) > > ... > >>I am experimenting some changes that I will share when ready. > > > Good catch, let us know when you have a patch for review. > > Hi This is the patch I'm currently running on several machines (with very high pressure on route cache) If you want to comment it before I submit it with a nice looking mail :) Description : - Makes rt_check_expire() do some real work, auto-adapting the timer interval (chosen between gc_interval/8 and gc_interval) - Move the spinlocks out of tr_hash_table[] to a fixed size table : Saves a lot of memory (particulary on UP) Thank you Eric Dumazet --------------040704050108060909010704 Content-Type: text/plain; name="diff" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="diff" diff -Nru linux-2.6.11/net/ipv4/route.c linux-2.6.11-ed/net/ipv4/route.c --- linux-2.6.11/net/ipv4/route.c 2005-03-17 11:19:45.000000000 +0100 +++ linux-2.6.11-ed/net/ipv4/route.c 2005-03-17 18:33:20.000000000 +0100 @@ -54,6 +54,7 @@ * Marc Boucher : routing by fwmark * Robert Olsson : Added rt_cache statistics * Arnaldo C. Melo : Convert proc stuff to seq_file + * Eric Dumazet : hashed spinlocks and rt_check_expire() fixes. * * This program is free software; you can redistribute it and/or * modify it under the terms of the GNU General Public License @@ -107,12 +108,13 @@ #define IP_MAX_MTU 0xFFF0 #define RT_GC_TIMEOUT (300*HZ) +#define RT_GC_INTERVAL (RT_GC_TIMEOUT/10) /* rt_check_expire() scans 1/10 of the table each round */ static int ip_rt_min_delay = 2 * HZ; static int ip_rt_max_delay = 10 * HZ; static int ip_rt_max_size; static int ip_rt_gc_timeout = RT_GC_TIMEOUT; -static int ip_rt_gc_interval = 60 * HZ; +static int ip_rt_gc_interval = RT_GC_INTERVAL; static int ip_rt_gc_min_interval = HZ / 2; static int ip_rt_redirect_number = 9; static int ip_rt_redirect_load = HZ / 50; @@ -124,6 +126,7 @@ static int ip_rt_min_pmtu = 512 + 20 + 20; static int ip_rt_min_advmss = 256; static int ip_rt_secret_interval = 10 * 60 * HZ; +static int ip_rt_debug ; static unsigned long rt_deadline; #define RTprint(a...) printk(KERN_DEBUG a) @@ -197,8 +200,24 @@ struct rt_hash_bucket { struct rtable *chain; - spinlock_t lock; -} __attribute__((__aligned__(8))); +}; + +#if defined(CONFIG_SMP) || defined(CONFIG_DEBUG_SPINLOCK) +/* + * Instead of using one spinlock for each rt_hash_bucket, we use a table of fixed size spinlocks + */ +# define RT_HASH_LOCK_SZ 256 + static spinlock_t rt_hash_lock[RT_HASH_LOCK_SZ]; +# define rt_hash_lock_addr(slot) &rt_hash_lock[slot & (RT_HASH_LOCK_SZ - 1)] +# define rt_hash_lock_init() { \ + int i; \ + for (i = 0; i < RT_HASH_LOCK_SZ; i++) \ + spin_lock_init(&rt_hash_lock[i]); \ + } +#else +# define rt_hash_lock_addr(slot) NULL +# define rt_hash_lock_init() +#endif static struct rt_hash_bucket *rt_hash_table; static unsigned rt_hash_mask; @@ -470,7 +489,7 @@ rth->u.dst.expires; } -static int rt_may_expire(struct rtable *rth, unsigned long tmo1, unsigned long tmo2) +static __inline__ int rt_may_expire(struct rtable *rth, unsigned long tmo1, unsigned long tmo2) { unsigned long age; int ret = 0; @@ -516,45 +535,84 @@ /* This runs via a timer and thus is always in BH context. */ static void rt_check_expire(unsigned long dummy) { - static int rover; - int i = rover, t; + static unsigned int rover; + static unsigned int effective_interval = RT_GC_INTERVAL; + static unsigned int cached_gc_interval = RT_GC_INTERVAL; + unsigned int i = rover, t; struct rtable *rth, **rthp; unsigned long now = jiffies; + unsigned int freed = 0 , t0; + u64 mult; - for (t = ip_rt_gc_interval << rt_hash_log; t >= 0; - t -= ip_rt_gc_timeout) { - unsigned long tmo = ip_rt_gc_timeout; - + if (cached_gc_interval != ip_rt_gc_interval) { /* ip_rt_gc_interval may have changed with sysctl */ + cached_gc_interval = ip_rt_gc_interval; + effective_interval = cached_gc_interval; + } + /* computes the number of slots we should examin in this run */ + mult = ((u64)effective_interval) << rt_hash_log; + do_div(mult, ip_rt_gc_timeout); + t = (unsigned int)mult; + + if (atomic_read(&ipv4_dst_ops.entries) > ip_rt_max_size/8) { + t <<= 1; /* be more aggressive */ + if (atomic_read(&ipv4_dst_ops.entries) > ip_rt_max_size/4) { + t <<= 1; /* be more aggressive */ + if (atomic_read(&ipv4_dst_ops.entries) > ip_rt_max_size/2) { + t <<= 1; /* be more aggressive */ + now++; /* give us one more tick (time) to do our job */ + } + } + } + if (t > rt_hash_mask) t = rt_hash_mask + 1; + t0 = t; + for ( ; t > 0; t -= 1) { i = (i + 1) & rt_hash_mask; rthp = &rt_hash_table[i].chain; - - spin_lock(&rt_hash_table[i].lock); - while ((rth = *rthp) != NULL) { - if (rth->u.dst.expires) { - /* Entry is expired even if it is in use */ - if (time_before_eq(now, rth->u.dst.expires)) { + if (*rthp) { + unsigned long tmo = ip_rt_gc_timeout; + spin_lock(rt_hash_lock_addr(i)); + while ((rth = *rthp) != NULL) { + if (rth->u.dst.expires) { + /* Entry is expired even if it is in use */ + if (time_before_eq(now, rth->u.dst.expires)) { + tmo >>= 1; + rthp = &rth->u.rt_next; + continue; + } + } else if (!rt_may_expire(rth, tmo, ip_rt_gc_timeout)) { tmo >>= 1; rthp = &rth->u.rt_next; continue; } - } else if (!rt_may_expire(rth, tmo, ip_rt_gc_timeout)) { - tmo >>= 1; - rthp = &rth->u.rt_next; - continue; + + /* Cleanup aged off entries. */ + *rthp = rth->u.rt_next; + freed++; + rt_free(rth); } - - /* Cleanup aged off entries. */ - *rthp = rth->u.rt_next; - rt_free(rth); + spin_unlock(rt_hash_lock_addr(i)); } - spin_unlock(&rt_hash_table[i].lock); - /* Fallback loop breaker. */ if (time_after(jiffies, now)) break; } rover = i; - mod_timer(&rt_periodic_timer, now + ip_rt_gc_interval); + if (t) { + /* Not enough time to perform our job, try to adjust the timer. + * Firing the timer sooner means less planned work. + * We allow the timer to be 1/8 of the sysctl value. + */ + effective_interval = (effective_interval + cached_gc_interval/8)/2; + } + else { + /* We finished our job before time limit, try to increase the timer + * The limit is the sysctl value. + */ + effective_interval = (effective_interval + cached_gc_interval)/2; + } + if (ip_rt_debug & 1) + printk(KERN_WARNING "rt_check_expire() : %u freed, t=%u/%u interval=%u ticks\n", freed, t, t0, effective_interval); + mod_timer(&rt_periodic_timer, jiffies + effective_interval); } /* This can run from both BH and non-BH contexts, the latter @@ -570,11 +628,11 @@ get_random_bytes(&rt_hash_rnd, 4); for (i = rt_hash_mask; i >= 0; i--) { - spin_lock_bh(&rt_hash_table[i].lock); + spin_lock_bh(rt_hash_lock_addr(i)); rth = rt_hash_table[i].chain; if (rth) rt_hash_table[i].chain = NULL; - spin_unlock_bh(&rt_hash_table[i].lock); + spin_unlock_bh(rt_hash_lock_addr(i)); for (; rth; rth = next) { next = rth->u.rt_next; @@ -704,7 +762,7 @@ k = (k + 1) & rt_hash_mask; rthp = &rt_hash_table[k].chain; - spin_lock_bh(&rt_hash_table[k].lock); + spin_lock_bh(rt_hash_lock_addr(k)); while ((rth = *rthp) != NULL) { if (!rt_may_expire(rth, tmo, expire)) { tmo >>= 1; @@ -715,7 +773,7 @@ rt_free(rth); goal--; } - spin_unlock_bh(&rt_hash_table[k].lock); + spin_unlock_bh(rt_hash_lock_addr(k)); if (goal <= 0) break; } @@ -792,7 +850,7 @@ rthp = &rt_hash_table[hash].chain; - spin_lock_bh(&rt_hash_table[hash].lock); + spin_lock_bh(rt_hash_lock_addr(hash)); while ((rth = *rthp) != NULL) { if (compare_keys(&rth->fl, &rt->fl)) { /* Put it first */ @@ -813,7 +871,7 @@ rth->u.dst.__use++; dst_hold(&rth->u.dst); rth->u.dst.lastuse = now; - spin_unlock_bh(&rt_hash_table[hash].lock); + spin_unlock_bh(rt_hash_lock_addr(hash)); rt_drop(rt); *rp = rth; @@ -854,7 +912,7 @@ if (rt->rt_type == RTN_UNICAST || rt->fl.iif == 0) { int err = arp_bind_neighbour(&rt->u.dst); if (err) { - spin_unlock_bh(&rt_hash_table[hash].lock); + spin_unlock_bh(rt_hash_lock_addr(hash)); if (err != -ENOBUFS) { rt_drop(rt); @@ -895,7 +953,7 @@ } #endif rt_hash_table[hash].chain = rt; - spin_unlock_bh(&rt_hash_table[hash].lock); + spin_unlock_bh(rt_hash_lock_addr(hash)); *rp = rt; return 0; } @@ -962,7 +1020,7 @@ { struct rtable **rthp; - spin_lock_bh(&rt_hash_table[hash].lock); + spin_lock_bh(rt_hash_lock_addr(hash)); ip_rt_put(rt); for (rthp = &rt_hash_table[hash].chain; *rthp; rthp = &(*rthp)->u.rt_next) @@ -971,7 +1029,7 @@ rt_free(rt); break; } - spin_unlock_bh(&rt_hash_table[hash].lock); + spin_unlock_bh(rt_hash_lock_addr(hash)); } void ip_rt_redirect(u32 old_gw, u32 daddr, u32 new_gw, @@ -2569,6 +2627,23 @@ .strategy = &sysctl_jiffies, }, { + .ctl_name = NET_IPV4_ROUTE_GC_INTERVAL_MS, + .procname = "gc_interval_ms", + .data = &ip_rt_gc_interval, + .maxlen = sizeof(int), + .mode = 0644, + .proc_handler = &proc_dointvec_ms_jiffies, + .strategy = &sysctl_ms_jiffies, + }, + { + .ctl_name = NET_IPV4_ROUTE_GC_DEBUG, + .procname = "gc_debug", + .data = &ip_rt_debug, + .maxlen = sizeof(int), + .mode = 0644, + .proc_handler = &proc_dointvec, + }, + { .ctl_name = NET_IPV4_ROUTE_REDIRECT_LOAD, .procname = "redirect_load", .data = &ip_rt_redirect_load, @@ -2718,7 +2793,7 @@ int __init ip_rt_init(void) { - int i, order, goal, rc = 0; + int order, goal, rc = 0; rt_hash_rnd = (int) ((num_physpages ^ (num_physpages>>8)) ^ (jiffies ^ (jiffies >> 7))); @@ -2766,14 +2841,12 @@ for (rt_hash_log = 0; (1 << rt_hash_log) != rt_hash_mask; rt_hash_log++) /* NOTHING */; - rt_hash_mask--; - for (i = 0; i <= rt_hash_mask; i++) { - spin_lock_init(&rt_hash_table[i].lock); - rt_hash_table[i].chain = NULL; - } + memset(rt_hash_table, 0, rt_hash_mask * sizeof(struct rt_hash_bucket)); + rt_hash_lock_init(); - ipv4_dst_ops.gc_thresh = (rt_hash_mask + 1); - ip_rt_max_size = (rt_hash_mask + 1) * 16; + ipv4_dst_ops.gc_thresh = rt_hash_mask; + ip_rt_max_size = rt_hash_mask * 16; + rt_hash_mask--; rt_cache_stat = alloc_percpu(struct rt_cache_stat); if (!rt_cache_stat) diff -Nru linux-2.6.11/Documentation/filesystems/proc.txt linux-2.6.11-ed/Documentation/filesystems/proc.txt --- linux-2.6.11/Documentation/filesystems/proc.txt 2005-03-17 18:42:54.000000000 +0100 +++ linux-2.6.11-ed/Documentation/filesystems/proc.txt 2005-03-17 18:42:14.000000000 +0100 @@ -1709,12 +1709,13 @@ Writing to this file results in a flush of the routing cache. -gc_elasticity, gc_interval, gc_min_interval_ms, gc_timeout, gc_thresh +gc_elasticity, gc_interval_ms, gc_min_interval_ms, gc_timeout, gc_thresh, gc_debug --------------------------------------------------------------------- Values to control the frequency and behavior of the garbage collection algorithm for the routing cache. gc_min_interval is deprecated and replaced -by gc_min_interval_ms. +by gc_min_interval_ms. gc_interval is deprecated and replaced by +gc_interval_ms. gc_debug enables some printk() max_size diff -Nru linux-2.6.11/include/linux/sysctl.h linux-2.6.11-ed/include/linux/sysctl.h --- linux-2.6.11/include/linux/sysctl.h 2005-03-17 18:37:13.000000000 +0100 +++ linux-2.6.11-ed/include/linux/sysctl.h 2005-03-17 18:36:57.000000000 +0100 @@ -367,6 +367,8 @@ NET_IPV4_ROUTE_MIN_ADVMSS=17, NET_IPV4_ROUTE_SECRET_INTERVAL=18, NET_IPV4_ROUTE_GC_MIN_INTERVAL_MS=19, + NET_IPV4_ROUTE_GC_INTERVAL_MS=20, + NET_IPV4_ROUTE_GC_DEBUG=21, }; enum --------------040704050108060909010704-- From akpm@osdl.org Thu Mar 17 11:53:06 2005 Received: with ECARTIS (v1.0.0; list netdev); Thu, 17 Mar 2005 11:53:25 -0800 (PST) Received: from smtp.osdl.org (fire.osdl.org [65.172.181.4]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j2HJr4DA023011 for ; Thu, 17 Mar 2005 11:53:05 -0800 Received: from shell0.pdx.osdl.net (fw.osdl.org [65.172.181.6]) by smtp.osdl.org (8.12.8/8.12.8) with ESMTP id j2HJqnqi010964 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO); Thu, 17 Mar 2005 11:52:49 -0800 Received: from akpm.pao.digeo.com (shell0.pdx.osdl.net [10.9.0.31]) by shell0.pdx.osdl.net (8.13.1/8.11.6) with SMTP id j2HJqmrD025654; Thu, 17 Mar 2005 11:52:48 -0800 Date: Thu, 17 Mar 2005 11:52:54 -0800 From: Andrew Morton To: Stefan Schmidt Cc: netdev@oss.sgi.com Subject: Fw: 2.6.11-mm2 weird ethernet RTTs Message-Id: <20050317115254.4f8e462a.akpm@osdl.org> X-Mailer: Sylpheed version 1.0.0 (GTK+ 1.2.10; i386-vine-linux-gnu) Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="Multipart=_Thu__17_Mar_2005_11_52_54_-0800_9sR8yt9M+8/Yn=Tn" Received-SPF: pass (domain of akpm@osdl.org designates 65.172.181.6 as permitted sender) X-MIMEDefang-Filter: osdl$Revision: 1.105 $ X-Scanned-By: MIMEDefang 2.36 X-Virus-Scanned: ClamAV 0.83/765/Thu Mar 17 00:42:45 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 290 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: akpm@osdl.org Precedence: bulk X-list: netdev Content-Length: 127184 Lines: 1744 This is a multi-part message in MIME format. --Multipart=_Thu__17_Mar_2005_11_52_54_-0800_9sR8yt9M+8/Yn=Tn Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Thanks, Stefan. I'm not aware of any changes which would cause this. Generally -mm's networking is the same as Linus's. Could you test Linus's latest tree? (-rc1 should be out very soon, so that would be appropriate) Begin forwarded message: Date: Thu, 17 Mar 2005 17:05:41 +0100 From: Stefan Schmidt To: akpm@osdl.org Subject: 2.6.11-mm2 weird ethernet RTTs Hi Andrew, since i upgraded to 2.6.11-mm2 i see the following pattern in the smokeping running on my workstation. The attached pictures show a behaviour that i also see when pinging (ping -i 0.1) another workstation on the same LAN and Switch, namely that RTTs (just from and to my machine, not from any to the other machine) range from 0.7 to 1.8ms, i.e. rising from 0.7 to 1.8ms in 2-3 seconds and then quickly falling off to 0.7 in about 1s. (ping output attached) Trust me: Its not the Switch nor the other workstation. 0.7ms is the minumum RTT when using 1500 byte packets, with 'usual' ping its like 0.3 to 0.4ms but shows the same behaviour in increasing and decresing. Its an Intel Corp. 82547EI Gigabit Ethernet Controller (LOM) Subsystem: Asustek Computer, Inc.: Unknown device 80f7 running at 100 Base-TX FD. Have you got a hint which of the recent networking or scheduler patches in mm2 could be responsible to this? best regards, Stefan PS: have replaced IP and Name in the ping output so that you can forward it to some list if you like. -- "It's just the end-of-MPLS day coming. The second coming of "pure IP" is upon us." - Petri Helenius on nanog-ml --Multipart=_Thu__17_Mar_2005_11_52_54_-0800_9sR8yt9M+8/Yn=Tn Content-Type: image/png; name="frell_last_10800.png" Content-Disposition: attachment; filename="frell_last_10800.png" Content-Transfer-Encoding: base64 iVBORw0KGgoAAAANSUhEUgAAArUAAAEwCAMAAACe63mFAAAAQlBMVEX///+MjIyCHh4AAAD/AADw 8PDAwMCRkZFhYWFAQEBvb2+fn5/Ozs7+/v4gICAm/wAAuP8AWf9eAP9+AP/dAP8AAADzkeciAAAg AElEQVR4Ae29iWLkOA4kWuWe6fvYN2///1s3AhEgeCiTednlqhY9LZFgIHAIguWUXfPlyznODJwZ ODNwZuDMwJmBMwNnBs4MnBk4M3Bm4MzAmYEzAxcz8JXj4u65cWbgc2bg65ezaj/nlTm9upQBNNqz aC8l55SfGTgzcGbgRRk4n2tflMiT5kMzcD4i3J3uny5qTDs/YXTYmPeCbu+c3pGB87n2jmQl9HLh jTtzlc7r5DvPZwbePwNjbZY9ttZ+b67SeV2a5+yuDJzPtXelS+BWmVmlef7Sdoq1E7WqNT7XP31x tTeeUj9nBxngx17nR18HibkmykKsqgM6F4Oiq9EyFiWbcULbmZNOPlCci4MMnK/GDpKyEUW1CVNV GOtuJzk6UUxxODwD30FT+zyfGXhRBlp1ZeNUCwV72ylLnSimOByeqdF4Sv2cXcjA+YRwITGXxFmI WX2BGxbSnEW5PjynsdjMxXk+zMD509hhWq4Ls7B4znY7NlDpZ3UmW677c9MnF4FxSI3zfDEDZ6+9 mJrjDX4jZ7XFj/4+u9hC3LQMy3VgejxZsLZu8LV5Kp3nMwNnBn6IDJyfIfwQl/HfFcT5ee2/63r/ INGevfYHuZBnGGcGzgx86gycvfZTX57TuaMMnM+1R1k5ZZ88A2ev/eQX6HTvzMCZgR8hA2i157+H 8CNcyH9VDOfb3H/V5f5Bgv1sVfv2fF4/BcWncOLL8148z/ACJ15BcUddLffEVrBkaauxALYUi8Yi mCkWwFYwM6x/MDJTzOv1Us2Ieb3amL3Ya8yImWG1MWvM6/eI444SvAcaj8uPHN4eURp1PgXFp3Di 6/NePM/wAic6inuK8G6sb7jlvtsKPue9vXV7aUFnHK1mtqnYZ7dRLNBm5RUTsy9GtoLmX3qx1VgA W4pFYxHMFAtgK5gZlrJeBAvllmLRWAQzxQLYCmaGxe1FsFBuKRaNRdAolp0sk5ec35f9JS6eJN9h BlxX7/RhbbLPiVmqeRa0uyo1Z8DH3tv2YuvE4tUnjeO/GJlZnreBfbI4mr9t0kfz7PxdSJ916tT/ Mlft95aSqqt3aLf8oR73sY+cXfoSrnbfLiITM2vM68TVeUbM60LmbPZirzEjZoZkrvOsMa8LmbMZ Ma8TV+fZi69f/4uv2l9nM+fMsNeYGV6hkV6woN5xvCv5O/r9o1P/OL32Pa6Uq3Yp3q3gkz1HOTdb t9FQxvFJ45irdnb7s8ex+Dtm/cnV+7LTuTn/Tzr8L1H/NFmDI4+k/H3ryuyLka3g5h7V8r9QbikW jUUwUyyArWBmWJrYIlgotxSLxiKYKb62rLlkFo1ZMDMsbi+CmeH4jW5ftYvGImheLDuPlP5Fnfdl p9k5/xddOTe6DHyarPVV2/m3m3Z11U13Wrfum3Jh3graXZWWLmm0/C+ALcWisQhmigWwFcwMS0ta BAvllmLRWAQzxY/Sa/kZ1RJsVszj53egnJxpVTvJz+W1DFzK2oOt75qp63sPGuzqqpteN3X7rikX 5q1g7g5LS0pBy/9CuaVYNBbBTLEAtoKZId2uFM4U8/r4ebD0b3ixtVBc7LWtiGYv3iuOZhABzTZX QfNigfb5eHr+vux0r1Xt077+mwguZa0vog/Jx4MGs67e5wGBrPi6/z1JvgWh9vFXcuZbnlwfoymd EfN61Zy92GvMiJlhtTFrzOtXaMxeXH43lm/MZi9mhld4RRt59cg321xtpBeEcvCYBRyC1xzegXJy 7FLXmGDncsjApaw92PoG7rsWDxrMusryvcvmFmz2NNLwW0F7gkmVSxot/wtgS7FoLIKZYgFsBTPD 2hpminm9PJQuFIvGIpi9uOG5diqnmWFxYhFsnQiN3syisQiaF8tOlslLzu/LThdb1b7E3++DpL/U j3l8KWvFXLPHLNyo9aAZ1xVarZ8VbjR3GyzZZ/RSzbOg3VWpOQPy3m75XwBbikVjEcwUC2ArmBnS 7QxrfS5bKFeK6VIvGotgpvhReq1+5Klcvmi25O9FvEXTqrZEP/xsqtoH4r2UtWKu2QP0t6s8aCbr imX7+mHOhXormLvD6p0pWv4Xyi3ForEIZooFsBXMDBfjaLlfKFeK6VIvGotgpvhRem1L2msnS/5e Sw+2VrUPMk8V8CDLx6o97/OlrBVzzd41tgfNuK54eocS69iH4BdTs2DuDqtz1mj5nxlu/Nm7T9uW YgFsBTfH0dKzUK4Uvc9H121L8aP02vf9aaxdktdPWtU+SD1VwIMsH6v2vM+Xsgb5zz//zGiet3FT Th404/uSp+UWvcnuNVB8MHHTW4/5vUi+BYFTF75SI9+u5PoSfn33Io18G3SkN3txv42ZYbUyc87r I43R573G7MW1d2M/f/05rthoY2Y48mqU7b0iIq8edfca6cW7fN5Vhfz6G6G4NbvUNWbcpfWDN/sl ug+RP+/zpaxB/kG91h48GMr71pXZFyNbwfowN9eDKVr+F8otRWj0adtSLICtYOsEmsw45vXB83nv M5QXjUUwe3HtuVZVS0Tv18ywN7pxAvxE+B4JU4vGImheLDu9r0/P35ed7iH6Ib33uvyk+r3mXoJ/ 3udLWYP8Y3ttX7V35OZ968rsi5GtoN1VGcoljZb/BbClCI2+ArYUC2Ar2DqxNK2FcqXofUZ+Fo1F MFOcvTbL6vC85O8Q9YywVe2DJFMFPMjysWrP+3wpa5B/V732fX4sc9UuxbsVzN3hYkNp+V8otxSh 0VfAlmIBbAVbJ5bAFsqVovcZ98uisQhmih+l1zLQJdjnO8g7UE5Otaqd5Lcupwq4Ve2b4p73+VLW ID97bd4IS/FuBXN3SCZWi/Jqipb/hfIaRRRdaPQVsKVYAFvB1ok+sPIqZj6sFL3PAG2dWD6G+FF6 bZ+mF86XhL6Ce/i5s1Xtg8xTBTzI8rFqz/t8KWuQf0+9lm+x3qHETLkwbwVrg6nCqF7L5GPE1kJ5 jaI0Up2SLcUC2Aq2TixGF8qVovd5dFvZ2FL8KL1Wr03jYr7wELeCqF941DtHXO54H1jvBGvGvVu/ xjeXt2p9W9xln2/NwSXcf/E+l290mdv3jVEe0NolXy7bzw7L23O5RZ+vX1MuzFvB2mDKmQu9Vn2m YNcoAhVO9H1r8WqmWABbwcywJnmmmNfLQykKanyx0ml8X70W3uJaymdckS4OXcVF0LK57NRlf8Hs Xdj95AX3GDCGHK3ZPY439XuUvjH2ss+35uASDnJn97KN1wRPDzD6qr2DuKurbnoHwVWoKRfmraDd VUnfaSivFChyP9dykWier1EELih7pc6GiGaKBbAVzAz7hrJQrhS9z3C001AOOsGFOITTJo+pAbmz O9lYnShlzZIi5fN6uh7g5/eMvmoXjUXQvPAOn0AXUDrw+PkdKPOTLzqFsDnkX83u8bep36P0jbGX fb41B5dwkKtqmdp3jZIeYPRVe4e9rq666R0EV6GmXJi3gnZXJX2n4W6AHUX+qXotXEqXeb4Wh3Bd YCGY1wcUk41OgwmpzikDixfqcoObSQF1Z3ew8d//vjwO8D/fa1uAr51kNl7K6m4AToTOMczuNCX1 O5WuwF/Nd2Tqsg3sDNV4pN1lbdmGurM7EJEWY4E/IRDjk72W5fUOJWbKhXkruHZvL702MrB8BnmN ItIdTvQXY/FqplgAq6Dng5WZYU3yTDGvDygmG50GM3FwIUcvHuq1Yq4y7YxKSEHv2AKYnbih1/Z8 tNIoTP7Ic+1PchfHnzjaqpssrnd7D0+XXsuMaoATk3uY74RfpS4nrsKe2rxug7tb+isU2Hqm195i 3e7ZCVjj7ILPF3eyaqF3Z4l1dXpYsfSkYx8cW0zNgnZXpVoHuNJrlQvpXKMIRFD2ielsHFMsgFEA rvmz1K0TmaKMc1lXgwnIgY3OCcbfst4oF4rl+1JSQN3ZDaJkwHOtmFNwYIMUvVJSNpUuFSS75bkW oKbOSaNYyAfYlcVPX6pW+1aLYs6NNw6YuvqFhFzdX7V/fvvZGtQ9+lp1LkvutX6Jqfy4hHiNXHYu cXH30l7K09Nc9+f/IrfKbs9zTWPUllav2+/nPPlk7ZLPQqVOf466Qm0++YQAhixVFm3Os3Est0Yn 0P3UCeJOaXeV7puf8ZaxjaHXYhHfY/AqMme+PyeKtT1Ex+lv586GjM0UC6ATgAjDnM3XmSEz0gCL oKM8csI2Sn+Iiy4MgmOKd+m1tK3eGKdrcQRy91y7fuNC4Xo08jbJne251WYgc3VUtdeoHOk1SP8R LXCoTqOhW7Vas+JSengsWc28C8ElRGG3M5PptEU/DCifjyhuiuMKBbac3ZrBDmR7ZtHSK8yOnCuZ oDwuzKUrUCn1Mxcr/xb93rrNOhVdrqaqDS8W5k4g5zpB0LW7SuSP9lqR8wie2UbXa4+dqHtbXiwM vcAUOhnfPYmlZHaipwjMAhhTAX76nXQ8dxq0PgiwDdFMcVuvrYr6GY8NWjW7nVHJnE0uDpyAtHOC bl54roVcfGCZAy2Kxbp1bjipTvlDGWfXqvYaWQTQXL2ARMpqpxbQdTaHWUFNjlPJauZdCGpWu3fO ytQFa3fyXYCXmSMAd2e5NUq8CIYtZxcgzAjFLpOMoUWhxxmxsu7TuN2vAhkHsXY+l65AvVrNXbX3 P9fmp13xUUL3wVdfwWgDYXu5NTqBnOsE4dv0M+uTvRa5Aetsw92BKTt2ou7t8Ak3f5y7QydQ/ruO E7CuwUit0zgWLICRAp6m35iCYvCKccyBQsRsyhqPZihBaQDnXGmGI8e21wLTeYVVUTYzXRzklEZf tRE55NYQoKlz0iicJP0y5QB5xcJVm44slOF9HOYtCkumVHpdC2Cw0E9jMdOi9IK6dY2BEqDru8Xi 2aw+AugIhjjHrTtWdumyqQJwBuYBapnEzh9lGOWE1t3usIUYuAaoRXOY2lIS2qwD+YDpFoW1jdrD lhcC1U4/a1V7cHf0uMfmu17b3J87zF29NkKPzxCUBPnKG9P8ErMbVBjVHZy5C/d2cxGT2cu+fYMF Y9Nry2hzZOQsgO12DSZU6EXv0ugVd3QhNaMKvLrSa0uDWKwAx4Q2MOMuRvVaLIibiwXi0asZAI3W KPOydDaKkuZkQ5Sxk4dGMSYtt191lg8Z6cqa+3EetimRAMnjqN1axEYcgPai6VGBLJJzhlEsWvMI QC0K4FltYbbslqDMW6O2MLPulmwAcDGwiGh0eMCUhmc40bEF1ATGmVlw2tSMuxiObSYiTkOwzrHc iDN3F4FUROldswynQa8tXLX3P9c2hmsTO7DcGiloDvK+64m6XquUpQZAEOBIgbYM8KIRZa+VHOLR BtbcgVxHnEYA+JMCoBjhBGbY0kivIJMZcgorUHYHKw0taaTQagCQaOhRwEDU2cBqeOSXBr3SzMXH TwDEz6NtSEAcBCGOqaDugwwK0l9+ic8QtJBeRt4UrREcdHsCDHEI1GkEJ9fDoEDWfMxsFjmfbF89 eC+gWJa/Qaq/SdLuMSb1+LdF+lsmuIivWmlnPKaWsFxpf7aRO7lP1KhLBmnNR3HnUbvlRaJzP3ny fLSf2Nyrc+7kmTvyVBjazT35q1UxyLMRw90+Ou6OfH1efvn6y5DFun6pVbqalbVirpkwPI5ZL3nN RiatUFYqVUb++uFGNlHr3qa1dmvNt1X0Wt1qvN+HhoIVVH2nxmYAPGv3J2/MtsuOMdrAunY1I4CD nsVILyQWwwBgYN40BU4WiEFECSoKgLTV5SYU0wksSDn0KFm7udfKEZBc6rUC4DjGATNjdtFrf8Ho Y0u3i4LetuBFOQQ/f+OK62GNCKyLXKwUmEKn9nye1ofdly1ctaNtXkJbwKyPNMXYld8UMBcY5ZMX 0o29/lDkpYuMF5+JjtSPQJYNp/IFM++UDwtLgbBlHGZHLAaIgtAjEMQC8DhgKJAGZxpkwSii3Dg+ G4rNUIsDSxYDc+vMZAUlQDhjrIETBF4Y3qDdVsEHliKL2YdU7WSkbkS5D099nzXnsstBIExHAQHE 7gbOJppxm/kCdb1WGWePsoGgva3Xyjwvlx58mdbGQq8owLCbOGktUD6JWYZAi08sDswA2CBAK86G XisxEZhxN06RO5ERoEdKzjQQ/NJrrQuAZk4/FSAAl7PLXYxtrwXGgZmiLnGz0fXaII0fIzCjRqQx nNBWARSXj5+k18o7+q1h77DgDk4QCDPUWywEqlqtWUVqXVUtF8sWZLUrJ1RvgbQjAGlmAE5FZBnN YwhKWSEwMwi7NbYAQi+AwMddnUgu3DjTrr0qIomjWhoLFTVsEwsa0IjIIjasCRvICqr4qVMY7+JU Q6yj9971lk6QzZYk6HpYAV42C+N134GXEgl+xZBzOPpmt2G8zRGOPgrT+QkBxO4GviZgaDNf6ey1 SjltSNE2WneoqrUTlSne2zKvYwJaNjuBzHQdJ+xErxULjiAzgHxy5LDXllH1WuoCHgwRqWadVyIT jpScYQABx5hNLITBVjgR+xEeBFrwCChwFEBRBrpeKyIw5fWQIsTkLI265qLEZn77bALaaHz0ilwQ tEGBfVZEH9Rrw4HBNiUSDFVLmcR0035D4BnSUe5DxoV2scMBmU/eFZzqsZ/5N0sxC0AcBsQcBjUb 2uwAhQl8HGTGTlAys1BWTJgVQJYWANECcUsgymBk4KpdzwAlTqNcEpcT52ANoqIGBMRhAcWOolZG tDsD0MJ5BtloDXLx81igQdxtCQGBWeQRASHIe6Z2XzkL43XfgVru0OpQtXGfNR/rXYzguE6dn5BB 3U2L1wQD97pOVFBw13otENX2giAoqIjRMnBTr20ukode2IMg6nqtcPteSxpzBhMp7BVOENlGw0Tu DAqjzFXbZY1vei0oaUADilCngI5gQPDrr/kZgmnVa0sD4sh/87yuOUBSymQ2AW1gyyzQMHk7EQBf PLD4pr0WbsETV63yYt/tYPObk0jdQa8VyLvGScY8iIlrIOpZpDIgqAFkwZSKGAbhhEXhPAtIYgpg R46ICjSQQTxYsin7UtbkB7Emkg0CyppBjbMsma/tJIvJBMTCA2t6hRUVMSBA/jwzLRG6lwSgGLPK M9bCpDUIQElcDQnKbu3UzCy2BmwIuh5WgJfNwnrdd+CVP9lrmYvIi292G0avtRzwgBz3Wmyx9oPi sNdK19nkvWwDka+4t4H4559/iKuOIxAw2R7kNDopJ8qyMF17kKl7eq0ugS+ATCDYLg5Zu9Zry234 E0ExRDvRKI97rbfjxDgUFwsLXF2vhY0rvVZh40ijfdVmYTUzYzIhHnst1g3qCQXKM4/w72N6Ld+N wbl4D5PvOOAcvrj6FV9866IvovKdCxGUCsvZr6EhjtQXhizFI41iEnch0gt8O2rs/3z9x9bkQ3qh VeLKI8nLFyFkKb3uMSiBZq1YjvOSLIWTN+TTW0FaU2aE5Vq7PHKFqjVCLFoJQ685GxGKgPJkoK3K mnL8a7ALq+iTSZ7wKq0Y4ssDaedR1squsLmrc14x+a3Kae/GqqZfOYub5kKvRYuLHhd366bX/oqq 1XcknHQH8kbU7a122/Uodg387I1jcEcPwIwIB4ct39uQwQ9SvGuvhRnmwq1Uq/ASFyUGdzEKYA00 GOwDym+NwnxVSwOAw3EIRMDQa4UZn2uhIUWii4I2MIIhfmqAGamz1ypD1OCo51ojrvZa2eh6LQQg cW+V2e56aNeASE4cgGMcMc9GXruvnMFKfOsxZyzjgCQMVet3V8Qpc4qUWM50nRgfAJARpy1mE4Mg DOL1vU5ElA0AKmLIBrEA/P3bb/aFBjAahguCNMxPYWJcR9z/z3/+Y0ewEMZE9pQg+qMhkCyN7iRC 0ciU+UiBATs4EqcZZRVU479kzbrUEotmtKEZvcKsuopSWJ9TqnTiXipvB3eg7tgwI0bMPg7rsstd YjWENYs8oigE71u14W31WjmCI9vFULVdr43kTc+16LXQYnxyH8ex1wLAWGVAuOy1Sjk2u14buLjX IW9Vayeqanlve5D96nMtqhYR0QY06AGGX2xBIDFO4aZXcQn8TaSZYWp8E0qWvRZ8Iup6bUAjDmRE gM4GzGg4jrjgLMguVwJkdmXR2UU4yh0u1WGvJTpN4PEghhhwzMIyxh8LaRtKRGjBRAUor4cpBbDP wnxQr81L2PIVjsItRIhi+bvFfKnXGgA4NBkfmDAjX0QanVTpbcEmDmjKoAuAd8sRC3By1QJHAxgC cRbuxkFwTilPDJ3wUNXSDgTCkIgzCMqaZ9KyO8JQhF34MVQtgzWfiSocQakoEGeLKQgod5vKxFFW UCzsqXE49VXrZyhIY8hvTouCfnfvjdQUv3wpwICmOKjyUDjPtLFkKAR5S3j3xSd7lkbsIToO4huq 1jc7zccljF4r9yMZB71Wu0gth3stZLDB/NdzLfQBwM7Ya9325MhvuINAQUUMJQGTw14rA8LQbfnh 2nevZaBBxIY/VO21XgsmOMF4xUkW9CjlpIi+KhziMBAHUZk4+kMKe6XTYa/tEUFBmhgwRcHfzEmM C722Z7jYaxuITrQFJ6NRX49CHPVa7Ebis6B0FV59zPvJvEoKfUcyWLU4lZtIFnE4lUxQpg66vHAA VPQQs2Q1rDTgqIgBgCa/liOGhx8o2vCFBjDkBGd2uFn0WhhytR1WLVlAO4DMYmt1Esju2BJ27eaA G9zhDsIZoOQSiDNtEVeDcvVamaodzwTw0T5X1XpWIFkrFruN04AZryW2SoOzwi5bbXfJUAg+pGrT iN2MbsCr7HsZLrIFIVl0CSf/jhFkGMoIb0xmEwCFSA1ssWLBpCdKwhuO97Z0fX+wBYlf3S/aXqta ONP1WliC+qbXqiXRKIaqlpxQ5Ahns9fCNEFqpZwJA3eYG0Apwxh6LQVDr6UAuUIR4aTYcIyeJRay Rna7ZgAov3NhBxiaQhOjLmRtjG0PGAqcNkD//m19ri2fwUIvyNlVbVzzHrTptWCgO6CwV3OvhZhx MIj84CXmrz90V4fkkdNwCpn4HUNlazcRYoGYAck5w4AuAFW13IRYxcIPAcwy4KgYZZ3f62CALIMj 7JEYgJSuMFjnELtX8kMVkP0D8ZAEuAFEa/KUDPRHcQnEeDGw4C6GAAmCAFsAkAUjILxBhqqN/iZQ URhaJxGRCbIy4Jnc8ZGmMO2rNvJXoLImA+X2gLG1cqJm1CisXOKumDjTLixxVPCxzDYYi5cf7Fka gSP0R712qFreZ/CMDgQo7u2AOo4LvdZFi3qJOxUaUGfW8VyLGXPQqnbfa5sus4TFXb02qtZeQLfr tfAKfjAatSTOMIBBuMwNZhIZQLctqF4rEHbQa1m2BMXoei2VWttLirnXqhl3PQECkNdA8IwDZpA7 PFth8sayhcwguA0QrWlg80qvpZfDt08oUaMshiByR6yC/2a9Vu/G+I4DF8dvVvAwgC+k/uvv+OLb lHyzxXckwglBufZ5JIsQnImFb7V+89fflnGXX7JHTWHEpPcwejeUHMnwT+jJBo+yk3xCayUM39ZI yqPi6b2ot1qKgyh5UVyMV57Wbo9BPQVC/iTmN1hLLqIVLzFCMC+Ul13yJFOy8JyIjLLi+yXyKiZm SHyJqzdsxSKbibhmLe0WNv3IqIjQ7pghvNnH1zu/G/P9Gb1Wd5buTf4YfFOv1a2H49prIYw2yu/u GF2vpSV8AKA72t0YvYLdQD1UnS00igKPxqEXHd+9FhRy2xpeYJffFdSSFNEv8cTzu70gLkDxXCtH GAps4GgNYNhrZYoyIsJLnhsoP0MAXJiviDa+YxOGET0LLBhiYXa1xSNk43Ote622hOjanjxHHEwc iPa9lhTwQkbpASjQKJkhnLHmtpzQjBhqBE6ZpcDdOjFDrxXRBz3XRs5g0RHINp1GiKzaihQyJd7P nPR9GAYoFd6BOgs2RlxHgJQK1ozMGOHLDDEB2PIoCsywQydgQ+rEmA8WayFMd038mI6I+MQpJTI1 a+WwiAxiXgSiwCCdKMCwSw2EzSwnJQ8CukhbWbW8m82FmXhIRGs4QeBdn2SGLBpi8u3OykWCcSST EXKbzKLgLgYWlAk0WqNc6JoJp/XokmUAkAX+YGYZBei37zl8qfO+a7az17ZI2aOYLIwAxXNtn1s3 SlYUANihIBPLsv3KulRkAOAq8sZkKqOm2ZyowS0MbGFN9ECBHXogG9gkhUeQZ0sSBo5Ue1Cr/Z1e QIM2yKRPfCGAOsflXqt9A7iwXTzXgoZ8GCJir2VgGKGVvRYAsfDB17s4QanrtcHC9LuuOTt+rs3M AIDnWuGqavO5VhaxC6/yCtBVPM7Jbwd/a68FUwuegbE6G9GNvdb/XiJVHxp5CakcseQdg5Rc6bVK xXJkHkSkLeaVLBiYZc5azSBfzLWqljMMOeHLD8BQtX9jt2xwtyWwmwnkiJqPrlp+KgI9miFT+4nF OH3wSWYMYMgCEGYGyMu6cAQJgIlBNFU4KHKrZ2FeCMAWjjKW1gCFwLsCEEeKYVRmgLVB+UyYrgKZ oYtBvroCIoJHXWDECl0z4bSmS8k0+ywi45iy6702ijb/ic+A33nwJVx7ratW6YU/Y6/F7xgxD0oH Y1GjZB7gAIKVICslqvaw1/L6aYCOHUaJUtXe0Gthx8mKWWiAgo5g3NJrh2sCd9idLQMRLwCIIICY Q14y8gbqem0A/vmquxRx8UZFahhUuBNlHW3PVcv4AXKvlc8ATb1W33bI0gYirdyhNbzZmgFwGzO6 GB4Q6qdtygKUvRYAXUs6QTQRMUsKreA2d4nNqn2w18a/Vf+Cqo2e4jDDZ//swhbZfOyeEOy9ToxF g1lvVcv4cPk8nFSR8wgojpV55gLDWRcfcYXA9cVu2eAucDxh1MwgADETEY55Bx31WmzLOvu+AKSE OpuAPDUR3CEUKyIwZA1Hf3/gLmIGkbiox91yBwDtkgkzajQi+wwzqng+ZHEmAFCIkosAACAASURB VIkwaBdKzQy/odmaAGOvlRnadGwCMZMgAjk9kA0cq2rpN01hCIQjL4fQdskZKigFu1775CMCvYRz 2WvlIo5ffZHlIwX4j2FiwMErvTYB0S9cspHU6B/NAK42720moQ0+eSmhKraLvVY2oM6na1PG7MFe C11eOAw/fosWvvACwBpsQIQBf92zuKLpeq4VCCTVa1V6h72WUYdBHpdey7xE2XrCwJwanLBgNqtq //jjsNfSRwyZ6fwOpui1zWdU7abX/v1bXMG4WuEanFCGfF+DixT7quU/AP5Mq42/DeMtRVOwiKFA szXJR+0MVZs3nZMrLVxfDvA5WVW1mCF5+QwHQoBw5M0RNnxg1dKa+Djr6zp7LWxwCwM4TboZKMKN dIR2q9fKCWAMMgvMEAc34ooErTE4yZIv/4BhHApZoHBXYTMkkQHT9dqKSAZpFwaEqV5L3fJIABJh 0GdsVe7++OMPGxOgs0Z2NXddAmZWICYJROqfdDQWmVDjLMOqMuSwsAUiVo6IsOag4HqvDcQzB/qW vVZGQ/Ir2wUHMx+vJ5dey9wrHboyfOhhHjAQC3Z4b4tEx6NeGx2dJmK419IPkIGBM9hJP37jvS0T 7n5dr4VFfUfIyx+O0Cvs/PO///2vvAArr1sA2B1orZUS3cSal1AYGhVGRdT1LOoOvRa6iMTJY0yR m6nXomlFuN1h6bXco995H3W9lkYRqfLCoABdeq1+UYFxiAIYeoUFZYwerwgwwGTA3xd7LTUwLvRa Xg8RAXNLr41/w777t+sfKN/wB0apGtngFcTIp0BmL6qWm3QQA3AisNGSGjpT1fL6qVJ87JhAFixj 1RKgBKhqozP3VTv2WhuV2/4RlwtQyFF7Ci+rannhhHE/okZXtBEUmYtILpEFQ1XiHkpdWeMMAwAE 4bA5gwBcwNgamdsNQoCGfzuiZTcgNCc+1D7IyYIRhvJuZmpBcb3XAuBLAD56ICKT2QZOYOauDBhn 2ey1WzMo7HPpRhVe/7z2yScEvnrDj7h8AYcvvqXLN3Z8m8svviv8G5iv2OEbSb25/PXrW+xwF487 fj+J38ny/s+QfMVOsvDMdb5PpR3+tZ7esorlt0DIBzy2BQM+wjWHMHyHKBvy9A37pSEvySwviaYN 6v7PPPRC1on6GXGIKX2oaPTG8r/wSu+n6REjIoPen8q2rMkLYb5+/SOsEce3qGSQtfQnM5tW6UXG Roxs6E23rKXP+a6ciMzub7D3hhWvE1l6a7+Gt/KbV5MYoeSVMi1PaUPXUjnJyKlBHnmlmqCk91m6 jIOVhHGlhcYz7TMPtryjeOtVr8U9h/tx7LUE4WbqO1jXMKRBjAGAetu3uE645fViCvtrrxUmAeDU t1c74pbkext2wECLGMFGi77/3f3YSTCCKLTti5zgFlhwpPrUSeLbOsTCGMQoq2kFJEwL1JwIU2h9 sMYplOAiMB5YMDXeDTAPh7227TIyuUOWMiUz7rWgpFO2UxnSlajggUmQyHyp4CmYGSUAmBnnWWVI rtMUtsDAay4i6+577auqNu4MeIEh28NzLbPm51onBU8wlVNrIA5GgAEWpGJ5rvXVCSsMGA+l3c2B bMDoULV8KB2qdn2uVZKJiyKPJ2GlUp7yKdWe6sLx2RkecBee6oMMxqyLAWg+tgoEjJ9rfXHDy3xA ZCh6ruUMQ6CvVbXySr7wKE+Z3cofZuNzrX4m6AD4zWKQmyUMxXNtX7VvoByqlhqyRiLsyigxqtp8 rnVgcAI7upauWkdOjchQPI7LdVVtXg94BmvAkGJftfF/Rn6lF2+36FHeekqH/O7KCTHLR/ZaZy6C 6DIfuZiq1slClB4kkg0ewWQWbCuvmCQgUknWoWrX51p6qyE3zVwXGJt0BKNd46Fqo3UBJCfcBMko F01ER8TiWACAzNZ0o3Jh0FS1XYLJDCJbEyWOdglEzLAwbTM6drlDO7LkiECmGfNlh+XS4rYuZYKA FRODohcRpC82dIkDgDO4ZJ91YhzYAsA+2yWIb6jabVluAPQIzuV9hwUTr48cHUuE0/daOIi7qnYN gC4jwBDLvtcqFSbCid3AZRuX/2KvbdmMN3TMYNSCWlL2pADxR20PXdmx1+oTxq7XwgnAyadrAhLm xnnB1lGvlTt+zmAcU9VGdgUisyjSrTh3vTayG12tEPo4BQwcAGAwV33VxvVAwQmD4z29FlyoWiYT NqtqHTmCX3ot49Dntbzg8gqpJsUNVZv/V3ib4ry4TY98SzEXbimwzUAwlDkHIv+YNgOwKwwBGI4A MxdLcOSBGaGRNgYzRgFBptAn62GvVZaMAwuH8k3uduG6YsOur7GcIAbe2hVYSycjZPIVEWYtoMS1 i2trJBKIRFPVZinBYTLLFDyq4V5Lr0Dk5Gmb6NkdYpoZAhwbEiYGegUQrRULgfrjFNrRKJ+BE9oX m9kFhicMZYhc4BC067UwhUG3QbGv2md+EAv2cEk3Jg376lzotS1SBJG9VkEg0vy8NiJlAOwG/WD/ GKr2TakojHutkkQG0A5Vy5u/7gzguqfrSFk+1zZP116rdm6Ae23viNtc1ZGaFiNSyUZcfdXm31u1 CnCvZWCBy17rwC73WnoVoOy1zg1SgYvTfOaVohd//vknylWj67XcxiUF0VC1uh6sSd1Fkavm82Gv BRHhCRJDa2XqtfSKFuNG4vX4uKq1Xd6cvDoYLV9cMHq45bQpCgKEwzFy0fXausbmydNQtn2xNEDL kmj/xkWRJaz5cW5VLb2qLezKy3QT3jrf1Gy9dqpa5bvF2/iqapkbXTcmRe6oGvO51tcNIAA4DMJM qWmJ6/Iip3zsrNmUNoItWCr94U6Y6qs2aheXwb4oeGYIRGaJU1VtXPPyuflDhGzkSS71QRHc+Qy4 uj8rYl+111/n9p24nwevDlEj1WsVJcIcbyuI485U4UYtdL0W2UCk+17LrPVVe9xrw6O4uuq1SpZy +nWuWnqhLR7tpWskLlzXtESEwIZ084mS39voXIxNr/0DH8ViqBqpq48h6DWyZIr+AjM19AjQyq4B zXU/1xIXJRJOiEzWxl4LY/Sir9o3UP4BW7LkXqs0OjZdUtbk2GttBg+lcocIOEsb8hluMzBHjplx Q69V+fN67KtWb8e6Kuyn8X/7bEH8cli/6TljyEgxa3nNdiEH6TciwFBeW1NxxHpaurHXhsk4IKnM dZLEObKaj8VYLL2WHsAROftPqYencVMIIE953czfoEPVRlTokW23rgmDje32HA8m4/qqtTtVtQkC HOYRxMgCisai/KpxKbu6BPbZJ+0zIgxHjq2qWs9gCgBbA66LPgkjvz3ID8j8PQZg6I8c5hUCEy89 Brbss0GDS8CpamklKuvaS4aDMixRX6jstNltUcw5fePAy+O3rzjiV2bfcL/F1x9v/PodXyn5ClR+ /Qr5W0MQ9Xfo//qGP5oF6lesfwPn7wOG699jl7b4Re6y9HtokOkfe0Kv/h78+Bv6aYP6b29/BiuZ 6au8pA/6oqf5pYjoBffIQhzj/xuyjDcjLkvkpEfi+SO8JIoRiIlHroQhQrmTT3/bq2KpmDO7b8Ek n8lChvKI1tJnsfwTXvyJ6IX709dDV0DZ5TFj51n515Uim3KVPqfH9Ehx/QqEroWiz8jFiT8KBoey mNecVfH7G/4PN3F+41/TXRpstpf2WnGqYhPHos25fucrbpVstLxdohlED8xe0P8cpdsq+wXx2WvZ Cob7ru7PgMV3Z97EMdgJZKlrt7jRfW9DgzMh7AfaZNmgDE3GzDi5ZR11ErEIOvZauOJ2YyKZiq6N WDTUbbq8KOTcbj+tg2KMCGRqXYQiYNpQY+RMpngsczI1s9R+dj8gLvRap7e6H03liF47+I0dWhMg fMknBH/rteqU6um5tqxFOV7ttVF9rQTn8q0NznJ1VLV8KO18xCOM42h59d9bMd5wMJ6jMhW8hqRw RSnxfI5q2cA8nquQ/ZZUPkcxXxgiIgK6HCGI3xITQH58rYsHDGRvUyrj6buqVp+FiMFH2gCLPdVv 6A5V2z3XRqwRmOstOCKOvmr5UEqf4Q/IgcnkYQWZP0UGqFXtV7utqBhHBRYgMnBEGsjiHytA4qdj IsDCEbN8rgVACcb1YFy+izCZ/Q5KpVqm8oeEKGyS+MWinfjzz/BKK8al51q6hCGiG59rWahZjnPR dhu7qmWkSBcHvVJGOJOMR7UMZSSfhYjQUKRD1XIDRAb4hFBFQYMCKGUJ09X35cdi6bVKkrPEvpWa dDYufl+1fiCjDQ/Aq0RAVo6YSCEbY2eRm9TPiBixfdFFq6otS6raxLWqZa3RWpfdRiUQEaIRrnPZ 1wm7BGFoRnR/jRxXVa3Ds99LYNr2lcYuc48BgRVlqXpy55ISYFyU4dO9Nh4huoeCw15rB+0jbiv4 SC9aXnnfwTkGixn+Ton5sp84qdc69QGIN0TIZMPEva7qFgtvTLI0EBHQpU3M0LM449WI33nGfOy1 wBz22lYAKG1SisFHCirf+MQXvvD2adEc9VoWSmPJjqMSgTH22iol4NwpwaqqzUapgoSpJbt9r6Ua AUPVJgW9ZVbwa15j1a69Vlehqjby375HoJPyKoDMgSGZtIyhawR1p0JSuk2oVvAAWUyvkABZoxf7 qr32ewj52kwPvtWQ+76r51p4D6NRLbqzmLNWk5Gk/DCUkQIK5zpEi9T14qvDGDUct3A0pYE1WYAp gK1piwsBLK56axXQ3TrutfKCntY1SU/CVLEQNFWtb1RjDID5YuBMoThenGCJYwAxKMhc3TJDwF9/ /YWguIsRaum4fYHYeZElgNJlIqTSiAjFIDPSCl/ks5pL3rNhKw6syQYiFxUxCgEWYHiJZIk7ANiG cNgxEXMgr4LmpqpdngruFDjCeIJs2YCD2Q3go8REGIwZfneemVIEPA69FrmAyB2nZSTudeYiR/ba RkSErFEfTnChZNmJVgG8dsC8oQJw8qjHP3uKX793Ktup67UBit9kgH45YQ9UJ8DwARGyYnBE9mXb a9Gz5E4+Ef3115Ld+Fe6AkXQUa8dIoc7DEzlD88x4nogs6gh5ZcXrPnMmjzqtQ6MBNVroQhXsNX1 WjDNvbZ7YG8ZurXXXnmsvaWAlc92AyM4RsooWk36KurmIh6JNYYJlgZvvDZUUf7eRD7heFRGeQQt 1rLUtVuJbYAaQIDBTnTXjnu//z5VbdeS6A0coflhQGnoo/QFAJmxp7QGkAMCAEoDCXGtaoHj1ecQ UfQ9RQ0Z1EVUVXvQa20rH/aZF1mEJd7KLfLOVF+1VPgTplrVMsHlM1k05iuVPud+XCPlDgwc3FFg 5BOO8iEBwhCwf0KI7/v1zf+WOh0xTla+rrfto147VW3Xa+mqeq2vjiJlQ+GWhu915JUBx+h6LTAw 7V7LvEAAJzgTizTin1QII2pJ0WubAVzcfNCyI6AMIl5R+3LYawUiUXOiqpZNSx4R4KdWCHz542MI u+OL6wZP7+H3hV5LKgGAGXstbJTDxCGwoWqhd9hrdY3gLwYbJXUjdn5X7Hot0gMAUZAbU71WLLg7 3GvJguFei5ndrg9HGtFtvfZVVZs3MPxRlJk1O6ii0XVyyyACuxgMyZdQFQW0WbilIWg+AIgPO4Uz wCdtURUIHKUQz1J91bLXEoQhxaGNdp6KxbhyVun2hSsWWhOIVxYD5OXpwhLffsK+QbJGifwml1io qxZpliEwm8IWiYjQaO6Ah5eKzNhZem2rN7NSWy5RQ8PB0xQGZMbkPn0mJkuidezyCFAaAErPtF1s IHv/Xss/8MGDG464sfCFG/Irnmn9hR+GsdYOEfqbI/6t15/4OyWiiMdtjy98uBd/I0U2avwJTvzQ 2b7491bEik1H7v6FL+ESkZxioBXipCEPaEN236CdNijhX7fpb56IoafcVTzC0Yti+Sf+3oqotCPr tEYGRpV/oZUs/Ksw5qVnwWcV8SVMRk4Zmb5GboShLiPOmBUX//5N1oj6AxqJkNeZe2KowUgzd7Kp 6yGvxUnr1NY+OeVjWpJXdb21K59lJ6siWRR5/U0cflEBX/Jb1t5gb/93Y9c+QxgfBS6sonHhnvPN ibuI9+ZRNwAi7s6+8ej+5B2N+w67wZYfJJGIWxq+lW1HJ+zAEh/yMDPAJwio3wYVsOVGoeZGYqjz hCFF9lp5QWchw45JAhW4xuImsem1Mr1ngbXmb0akQMfEtZDzWy1ASl75zLzYYZwAsM9AyB2aElHZ /DNw2SQVvKMnlzPkiwQsRvmsXR7DWLIAQ10Z4QwjMM0l8OkBiVvA7XvthVq8XRwh6CEovu9k1eZD qR3UM46TH85Nz7V6TCIbQFCC90nBYBhpPFdFqnzgQxCvDrABEALK0heD0sXrAf/ygwzZgBI/Q8CJ I9TywdeeQsP6sgFYPNdG1Djg0sSHlJAbIDdpTWUCBJ/u0iN6Gk+tELTa58cQYT2r1pFTRqb2b7Zg TXf0GYJ9DoD+RUT1jgB9ZV6I0ADFXLW0odyR0p8hgEx/RcNcgYja2sZkeK51XA5M1vLz2sbSPdcG i5/Xq2q7D0cUG6vihqq98lsIN5VuVBmyzuTBsGxvem1LRfdcKwqmVpdQuWI1eohcV5HGOLDFfAGL mQE+Wb+dCMcWyFlxskHmunBSrIsLjG+f0RfgCiTWriGLhdYClB0HlporEVSxqPipJxAjwsCCMjK1 gTVZsIsjAHn5AaC37SoIM1TtPb2WdjVorYZkvkZ2CjIAOochwJZrXyB6KhbOMIRJl7LVRmzA7as2 Xnk99xlCJMv3IRPPCNQN6KkcxNH3HeMAyPe2IsARn28TEKnPYtn0WvzMCj3aghkRpRcwB1k5gQXt wgkbwEkY9lrsckAAwFCQ1NAmj3Rz6LUReTSYAkEDNLQGpgBEr4Viw2SvxS7vIP1BBY0LxOThPywo I1Mw8GyWBsjLj46PXVkTaOq1FZhuIxBf6rVgoV3F0XzmpOu1YSquaPMZDl/qtY3lsNeCixZFdFuv fU3VRpRxgG1knMOu1hbTrn7s5AOBmRz2z/iMQCCrA+BhoiCJgxRlrGsr5oN+OYEFVbCF42ijQDLg qnWPhMyO4FSOkEJDrB1ILLTWqpZ2oTsSQZYcGXJVLYOCBrlkgHwYZuG2vv8LoM08CpQIrDCAU2AV l+7rvEx2DhzwinY1ymfOJKvIaRHk2LE1a0GMXssFEe3zIODCmXCHcrlEPkBFRDMf0WuZB92YdBO2 GUG1OQpjuNdyHg7Gcy1mWvMTRRAxguBjTt3mgOGwDex6oNcCJGuuWt7L5outrlHSLiigO9i40Gt9 cS/1WlJggEwNv6tIuUkXG4Y9Co7BI91IXa8Vho2S3gnE5OE/haKqde6qag1gsDSlXqvZpV4rU84u yA97LfiAoy+Kgz634V5LojAV6+YzHO56rVjoN5iKgTMFRgZ/5CusiG7rtU9/hpBVFoF2VZs3seU4 RaR5dXBZKgLOFJ8wBLEaKe/vT3IVDgvsEoeBmMehLeprUBfDBnACnDvQHRC8//OyNJAQNgAWADjk C8WmwCmshJkGoGiwRg3IoB40QUQZRgQTByzExSPdxmkGVNUS4AEQ/CAHZh7QLVMiShBwg/dgAYAD urXDmcQkGkDhbrvNAMIuMEQLN7KAVjt1Xzs24/a99qafuK6BfGf6Pqy8Zpuj7zHcLziH33/91fVa eoteix1EyRGAeNmOHSw43GuDy1fxsNcC6uir4UMgvWxasgHxYa/VZZEjGUdzpHMTiOu9NgD5w7gv Lr6HKJwMVh9DUIYhUNdrw+9wG7MBwCgho5ut1xINEGyQqPnM5LHYMIAVxr3WOP+cIT46Ao0gohUP X+OwR5ZYAySfYe1arw13IplBHm6r15Iv3Y7fhthWLX8Oe+5ThPx+ArscCLAFEcFKzKOi5UwgbisC zuS6MK5a9wBgOKjYBnGQQa+sBaqVrLbIrGFVG2jqS6/Vtc1mIhumsAEwFQsWFKeVjGgA0DQwo6dH LAUCFgsqapAPswFAm5DZlGZEFwgALDgK14jG5DkA4ayBk8W1W0SYcQBUgUnUXWlZozpAZpndYQAi MmBXtVG0T/36DF6YxBsTHfUehW+r9PaGb1VwS3YIzdEK/G5M+4XD0y3QfJfyF5gp1zsgvk/JdzPJ OFvj25t8k0MLxTDy9zb4bkxW5Ine9xCh93z9+yN6pTdE2heGb3PybZW8pX89gn5zJ/OS78Z6TL6F EuYrsGTNSPWOKfMijPyWpd/jDZ38IYqRE5W5I9NsTYj0qd5VEifbPGZueM78p5285uVP+itbvGLi yujzjd2cIa6VRb6h270bQ9W6cK89BFzdi/vE95huTt96vrm0hZ2uc+jWIw4zAHiP6W4rIu9ih7oY 3qoTZNglDqNwmHE0sZbk5+CNjYEZ1IXJHhD78fgnANcCmQILDoiDIw7CkKlABuiEI0fziDYvscwg qXZHKNpnG8SenZVjZC4WzCjAEM5uY0HZyAQshnDc1SBGO941EU4ekJtI6hTLjgEgGi1B0DBEjjiw 3NBrX1S18awGf1oQfLDCwtWIHT8V0ccA8YmSCCkBR4ohAj9SQszh5ygjcNKLLWdERN2jWMi7h1Lp +YdaLkAJzPJcW1dWoIxDBqDUPd0FZzyfKxRgEE4XaAAiMOzYUzxtMxwMm6rn2gYan2uLEkpiSa9k AEd+dI0TaYOFAGeXMiSvWfMtGwixQaOea80Co9AzSwDy89pmMwLFlkhgLZ9rgVA1EmGWAE3Ptfrc yHwiuukzBP9xzdVuen0z7xXmBqOCgJsMVn5zS96NIACkZNwQQej37cK75sLJ+ZIpMmPQKIa2NOfR usomF4Ba3SAhfHENx5bIiQn6jIO4gcU4gKxbJ3llazgNRGWJNgaQt4oSswIQPtjAgszFghkFGNga AqNsZCJb8nFXgxjt1O5gc7RWW8oO1yAaLUGw4CCDAVvb9drrBXnTrh3I/mHb+sjRkSoBbkFcBGjq tbq3zSaWpddSV3kg7pZeW1mXRtdrZWPTa/XDOOPAoPnqeyRcnQDo5l4rBhzZo2TCVdv12sEmQKqA sdcCs++1zVqUNtwca0l/ywAm4MLmca8VgFy6YFlsIBt6rawxFc1nQLpeWwDOQCvcTb32psK8Cgrr CpPHSkXEcdxrCwRX5bBPiiUjxa4AxV9JHa0VLnTy6tKSBKawAZwgth/W0JZ76OiIWBYKgCAziy1B YN06QVbWgDsishNFZiJhF3dsTfLi46xMYVZbppCA1soUVxrYBc5KEBGTe3ktB6LOGqDeGk5mkTVy ycaAqaqltai3q3+je7Uib9l0jNlr5RyOXTdQEoiAq1wEaO21cNixYEYKnDCkjmPaaIKgkEXhiAgd X5PoJxJIqeuDEEN16bWVTWr4g08AZQAix2Hc3PDhbWdDIHslR3HMOLBLG3oo7d2O5HErR1BiIZ9J IY+cL+yw13oEKDupZfVDgQTAJMJMB722WXPh0guot8gjjgIhmd5qJ2r0gE/Ua50YnHoHkYwIFn4X wDPuaUBDej4x3oFIgIWBgsFa4TDjSAvZK0xBAxqFCXy7Y3I/3B5A5UXDEDRagqB2PYOsiAA3EXY5 04lOFFOBhCURZgOGGpTPCR5AUu9ckoC6ZY0rDewWH0TG1K4AndECAUt5GzY9AEhUFA3axQbAB/fa 3sGuG8j97DBYRS4Oe+0QqSksW3otnqOGxAPnrsbcxFb0E66yY2cfBBYyYDqKyGEHoN1qSUUBcZ/u jkF2kqKB6FV5Wr2WBjCq1zYQ/damjkGJqXzGZmY31HnNX9prGQcix3/2KNZ6p9eC9/Uo0Nxr4ZWv R8VFIvms7GSuIBPRhz3XwqJHHwE9tY+53c4tCn/rMQ6nhahkTTsn2BqIFl3vkr0xI1mXcNpyrS0g UZjJIGkMTjiCAnAGsgJhZnKfBCDzBZBMEz1gqAGZ1M21gCynFy1yyKhb1rhqw7taG+NNkY1MxYJZ WMmDTUO3MCSCPCFxNq5An6DXyic4y1u3dzB7LQOJMQOyoVgJdy5hWOmIU9fmEDN2lnubqQhym+a9 3TvR99qQdzc/13OvBVfnZgA6J2hJTvByYFdHatQ1WXqtGiV1G2jstbBJXzAa5t5eC68qchGRwiNo 83poF6LObawooAvdiHVy8Dw+1wJJRA/IK9hIOq+EoxfvX7V4aRfv4uBgvP9DqXVfiNy7nOVcb0mF k7yO4imO0kqM3jIeWZt1k0Wa0sh3h70PiZN+IbjOPb0/LR+ElS8jJnf6c77NTWS/l3Ny5z7PKa94 e2+IoEahNJOHxTPvcz1bIlNqiFEshct170sypybPzJ2+creYhSNT7vGc2e5xuze6t3xIsMH4ton7 Dvdju7O6bhA3Ktx9rtfq5t/32uYBJtFPZN5OVMcRruuUEUn0WsVEDVMA21i6OIAbGj4xajDOik5d 0wqjc8+Kh1LqyiUc6bcpKMeFxpgB3DCoPddSJhvmaoA0SkRg9r3WFDhJiRSYmdJeFUi9lrstyUvk JLJ+nDqvRPQxvfZL7wNc6oOIYLFPVzUMLlBu5PkIYFlC2rlYNFt0DWgKnBiE06zuMkHG/QxBeIG4 auMCC/drq2YQFxFmteOZiY9A2iJuZuGO9MfZEYvtiGUm4nWykijJh1FEWtMaZuayrECYtdwRcwSg zPrDCeIiev8nhKxa3lWdYbULytroelQ4mM9RFwHRcbDr8NxrIYA6lYYPACADjrduRX/UaytXwi29 tgCykS2JqxhdHGGtY+D+fb1WGvGrDJg212mUWzkiu1gsAHmLHX+GQIUApdstnK6rCZMImXIysQUN siDdzZp9sRem9PUoUPXa5hU1ekAwNJdgp/NKuA/utYyzd5BzympA4IwUrnY1Y0SYDQDLCmrmAmlG HMYsHr0QZrRhDWzBRgFosMgG8wbhVADMiKmtmg1EwHnHlFh5tpBZ3k4L7T7FCwAAFNJJREFUQExt PyYDqJwYjA4Y+m0BZsCNu1gNBgaiVJTKHb3WlEVWRj+k10akcReV4aNei134SG8Dd7HXJiB7LTVi +F6vRHVtDpTALPc2LVlbFHOWOopwrrv5qeB23VgwYQsyC05Dw5elpBAIssUr4fKIh1JPwaxBG7kd TlwCNBtJAWBQZKO0p0NXEyYRMlW9NhkiULljX5x/UoY/sTYiTvwMwQaFuRR5MnzDXhsRxKGPgPNl x4LCFWKYXQfU7jBbyL0LOWbcxanlSxe3J5C+s65FB5LA+AL1BF28Vre1AYSFd4fTjOlApTGAqC5H BqLOZ8DtgaDGDSxcQG6ZEEcA6y6nAeu8DF4NgEW9/CvcR/Va9ZMMPezP7aLvnAE47LWOShGMFLYB RIuva5SQYWe5twmVBpnRKOcsdRRE9Dc/l0Ovld3Rq6XXQoOK/ei6WlAsADZKkfvY2Rg0GigBLZwr vVaupNGBwosw310PiTu3iwJbWuAYlI0Pk/EFnRE9IJ0oCgfQQPTiA6q2OYBJs91NtG+BwbXda3fz C4ASH80WcoMgL3i7zJ2scIACkI+Zg+K8wJqjmDGzIDb6wwAyTvvcqdmAM4Fkw8IwygZnj0ALYLBR TDUDy4Ixs7ZqwdmAtbXB6AAYdWs1gD6uarsbUx6koAWW7SEF3b1N79XVOMMoCq0lSMoWYtcoIQOU 93LbxSQ0ell3swvXUYSpeCiNWecEoY2liyNkE8MdvVYegPmw13o3TktXG52AH+61TSlz1QooI18Q EFQcLUpIk0IA7Di7mHE40MaHCXutNn3sKAKXTjRQChoLs/n+Vct3Ywine7uCaIev/q3Hipt1Z4T2 e46RvV/NXLnXaydfLytc7XKWcp37deFmDFG1m7MRlYiUCpWr28/JLs+OWQqTsyP+Prbj/Z695pz1 eL7tSjuF6hHjbq16zAe8G3Nzm+8qeKERdyWnKbBcvwGgm04iArhOQGjM67bJSdfmsALU3aCBZpvt mbMhOgraDgaeGyApmizdJIq4iaF6rVwCJimSMxpMLuj3vtcWWrPZid6LQKTNcJKHpaslIqm7OMqG N8ViDS5ko80MG3sthLONdEJ8OKbABMrm+/faL83eQxO5X6pzHmrnRTMYuMSkLXm0ggbFCyCKxV6z S9ZK3pRKdNOMNjSuwAHw7h57maZYgCHRBejwhHCEWXSPuD6uaue7arnNFkHc24wic0CKWmExc87r pcHsNXhvD9nsOkxsLTd/Gm2K6WYKRgawp0azMwumNXptg3oyIY4p4QCHVGaKZGiAJfJEpO2ZoTcq llljXuufE6JPMUA8IyK7aZDnxSt68XFV27ty3xwRlgLDrdW3mEXCD5z45o4tybgpV69x+1YWuqSx eCsBNy9slfjjqna+q5bbbBEc3ttDVDPnvH6k11ZuNJu9WLuBNVq6Zy9mhiXQRTAzvEscO7cXr14R By+fhszPkV7Mrr39Tp5rm7efZsKkfxpnnnfkY6N5jbXvrtcOl2m5U4ddLLbtYWZYGsxCsdeYEVsn FqMzw+LEXmNLsQC2glfEMVftbHReL4FGKp6tWv5zShr5/6mb63aeK+lc/4szMFftY6mI2nr830MY /n/KW52OEzu2v4tmxCvu7Tkrs415fXxv9yx7jRlxxtHy99jnzk2dE2bzuart/+E69tosV8xy/sYB U+fXmYGXZeDL25eoq6y3+85D1UI1S5VFm/N8yzB3oLWrzYizR7Ums03FnLs1uzPFXmNGzAyrjVlj XkejbEFxMiPm9QJ4ca9lvWelHlXt4Oy5ODPwRAaitz78XNv32l3V7u+iGfF57u0+wbOXazeYEWcc LX/bVMy5W7NLiueqNh8E+ETbV/DZa9t1OifvkIEnq9bPBPqnmbufxkCbTwvnc+22wSwNZek4W4pF YxHMFAtgK5gZFrcXwUK5pVg0FgEpnq3a0L9+eId77aT8d2fg46p2uWm2gu2N+WH3dl8jW7cXr844 Wv62qdhn9+y1LZvn5LvKwNlrp8u13Oxze1gAW8HMsDTjRbBQbikWjUUwUyyArWBmWNxeBAvllmLR WASkeP+q5d+NIZzz68zAyzLwAX835ma23DRbwfbG/LB7u+/HW7cXr844Wv62qdhn92N6bX7y1Tw/ J2cGnszA+z8hZNXu76IZsb0xl642M7zqvXef5MXGVnDG0fK3TcU2mS/4PYSo+d2huXxOzgy8JgNn r53yuNzsc3tYAFvBzLB8i1gEC+WWYtFYBDPFAtgKZobF7UWwUG4pFo1FQIqPq9qpOs7lmYGHM/Bx VbvcNFvB9sb8sHu7T+/W7cWrM46Wv20q9tk9e23L5jn5rjJw9trpci03+9weFsBWMDMszXgRLJRb ikVjEcwUC2ArmBkWtxfBQrmlWDQWASnev2rPd2O4mOfXSzNwvhs7e60zsHS1WbBtlD9Qr823DFN1 nMszAw9n4P2fELJq5zt3uTEXwee5t/v0nnG0bGxTsQC2l3TRWAQf81ybVdtiPSdnBp7MwNlrpwQe 3ts9ZgFsBdsGs3yXWSi3FIvGIpgpFsBWMDMsbi+ChXJLsWgsAlJ8XNX2V/6cnxl4JgMfV7XLTbMV bG/MD7u3+wxv3V68OuNo+dumYp/ds9e2bJ6T7yoDZ6+dLtdys8/tYQFsBTPD0owXwUK5pVg0FsFM sQC2gplhcXsRLJRbikVjEZDi46p2qo5zeWbg4Qy8f9XmG9393zzOiLftW8BZY17j5p++ZsS8nvF/ fZ292GvMiJlhtTFrzOtXaMxe3G9jZniFV7MX83q1QS8+7o3uwzfWqXhmYMrA+/fafMuwPKBsBduH INyI45jX59+NVX7mbC652gpmhiX9i2Ch3FIsGouAFB9XtZW/c3Zm4LkMfFzVLjfNVrC9MT/s3u5z vHV78eqMo+Vvm4p9ds9e27J5Tr6rDJy9drpcy80+t4cFsBXMDEszXgQL5ZZi0VgEM8UC2ApmhsXt RbBQbikWjUVAio+r2qk6zuWZgYcz8HFVu9w0W8H2xvywe7tP79btxaszjpa/bSr22T17bcvmOfmu MvD+vfZ8N/Z53inh20D72r+FmhGfJ47z3dh31WROZyMD799rz3dj24e55Ul4ebrbUiwai2CmWABb wcywuL0IFsotxaKxCEjxcVV7tokzA6/KwMdV7XLTbAXbG/PD7u0+21u3F6/OOFr+tqnYZ/fstS2b 5+S7ysDZa6fLtdzsc3tYAFvBzLA040WwUG4pFo1FMFMsgK1gZljcXgQL5ZZi0VgEpPi4qp2q41ye GXg4A61q/xOzpw7t/zkXLN3cvi03zVawvTE/7N7u07t1e/HqjKPlb5uKfXaHXvuf/zxbt/w/Ks/R z8+qbRft1lQs1+5FV7t3ZLGxFWydWO7XhXJLsWgsgrFqv3x5rm5Zslm2bf7TT29vP53jzMB7ZACl FZ32mXbbKtXVmxWc7fdrTvK8FbwlMs9bjQWwpVg0FsFMsQC2gpkB7yOnMQvm9ZctxaKxCGaKBbAV zAyfIA4U7Dv02unq3LdcsnSfOtGfguJTOPGCVHzCOJ5+rt312vtL7tQ4M7DJwDMPB6L2T2A/qXzn B4SN+XP7zMC3yYAKNaq2/Vz2bTw5rZ4ZODNwZuDMwJUM+Lmie7xwA7+iM20tFPjQhZCOc9JYlguF tW+nIDI+7Gnc0r2dIfwdKB6LY6B4KI6I5Lk4Bor742jGP+dE9YXr3dzTw3L/0qJtHU8WiiggXq4i PdZs0oWCScfu7RSGN8bUvZ0hLRbFg3GMUT8Sx5A4RXBvHD3F/XFUDj7lzMnIE+JTiA70Fp9TV3ly /WHxHEXo305hc9lUoCjd2xnS446C0T8QB3ttqDYXbvdiNEeeRhKzGy7ISnF3HDdY+cYQZ5Sn6DZ3 ZykTq6y6asFi4tvCM5in9OJOijQX56ab0pu8SHBS0JfH4lDwUr6TQsar7mP9QDL7W+f+OG7K1zcE KSuRlvDi0Szp8joQkxbrLsADLyBKmp0294nl6M9j29H+lWOvKlg6kDtXlEuBs1TAWf9rkh0FNfO/ ZHogjp6iCCn9IUaEl9/UEJHCHYPeBDpT6Ao9RUGH7rtWNMfRn+9jGFSL6+44Bi8eiqM3qXkvCdeu HRLMc4yYpDSF3/XZoSkwRVbH2yKbKdrakxtYmgqw9ZCBOrqZgsD2nyZ1vMGDXt1OUJ/T250oD6gn /Tu9ENyxlO4zTsiPu+KIwD/tQT0tLk3Ls4J0qHvPV4qUPEHRPNrbD4RN4sSlj9qJ4w2HleLROAYv VPK3pmJ1QvWbx4+J4wYrJ+TMwJmBMwNnBs4MnBk4M3Bm4MzAmYEzA2cGzgycGTgzcGbgzMCZgTMD ZwbODJwZODNwZuDMwJmBMwNnBs4MnBk4M3BmYM1A/PIHD+uWJFvAqvgvV1kTckpenIGf/tG4XLX/ R+MiYHXop/9P4x6V/2nco/L/a9yj8n817lHBv9zCcYfKmpBvJoHXVxznVr89r8vtbGs9et6NXoVf 3sPotmq6zjrc4EeH7CG9eKraBfbTVLUJ4FnzlDTWqWpbGNdUxqq9SWWuWvtxzcpQtcyvdK6pqGiz alMjQi/lFvrjE5EN+v3lHzb6RellPM1HOHn1l3zBP5goqt4A59xZd1OSu1qnNPV47kfb721f9LOh e4ovU69dtaeqbaZAp/mBytBraVe2r6kMVXubylS16dk1K2PVtkRcUxmq9ibHGu1mQrIatTqaFW6a ddm3Xqkz7/1qUo1d7KvKkb6YExQSrJsyJ7lred0bYcMI4cjBIX2zmUGy2GzTxhBKcjr5C8RNj7Fq CZlgY9WKUSizH6gMVUtDwYnDZZWham9TGas2PbtqZazaLjGXHTuu2mtW6P3huHz5gk7Xrkol0xYS +WqPCwPFdsGwKZ7eOAGXBoPOwKk5kMUytXMnzjiklpj73XIHe9yIkfhEptTbAUywfGrIFCdUfMMT QsMWZqza5kmQJXxinp4QUueqylS1vi5XVYaqBVJeXFUZqxZBNnRLnFha/D9drFopEz6pNN2DydHl U63lTk+X5LnX1s1iSmhKc9Vumm7AFPTnUkgDNh4cA3XcEGmC50u7ZpAZWe/Yeq0e2cvJjbUrIAz1 Tsf8zl6bpuwPKHqDZp+rtsAFl6y589NUtQWs2axyWLVli7NZZahaGi9QzmaVoWqRy64jXVBpQc2T C5dPNLpKSSnVXOHsbUr6kYiUjeU0x58on6UsyiSqc84IFqbShbUSEUwymqjEppp57FkWY89avJKa T0QdXRiLw2NVayo71IIy7VS1g/VLKkdVu7EyVq3qaaNyVLUblbFqESHw11UqueOMWqEck7p8kuel KnldTCJsNKbFK91+PUiyngrQzwQVI45h2eqYexYKwvQOpYTbmMdSsmkndgMRh9l+M9vUaLmsN3Gv GM2DF9y7gveI2CxA71/OZ+ZRpTEHa6x2VgjCf73mTkUad6m8l5U+e/2cEUVUcaidXkifanCl//qj aIxyXsRBdOpwnyuuLwxDdfHBgHU3H4mCInYHLYlxLDRnbYS4c0r8sY0pvdbN0rlpJm82pquTweaK lCmBNJfDK7JJHlBR8u6yAnPA36cSiblLJTTutNISwetDa2FRTLEHKUTe6eTKwsEx8EkbbJLYu6gF M9vXBL/ubHfvJHxM604jl+DK1KXdQ/m/XGXOSX/5+tT08lnnc6372+t2zx7Tup3/RL5rBrrL11et O+u7mj7JzwycGTgzcGbgzMCZgTMDZwbODJwZODNwZuDMwJmBMwNnBs4MnBk4M3Bm4MzAmYEzA2cG zgycGTgzcGbgzMCZgTMDZwbODJwZ4G/qDL+5k7/peZQaATu4dONIKX/dstg4T2yeizU3153CBGVw BnuxFfGRuxvKgT8WortH7R7sau+jJZO307LzhhdFv0nbCTGlxrFW7IRWaghHnjYMqnVs9hDPrQsg KTuGpupJMA7Ci2DRDFGldvx6MPZzTcKep5/LWI8s8zOuQ3VbnXQ0Y6IOWtSXZ4IPcV0Ga+dOCzu6 d96fvJ2Wg3Hurfu8squU0JTm2ZK2JDlBFKRQ81UCQNtKLPUPRuLCftS3PXStN78aZ5nvnaHFtCoz NnzAyX3ZVZCDxf4eCwoIcDZbUEvXR+H7Yw9uuqQQT7Ilo85ik+dCrsfmJ72RRSt8jlMXYO88xBGd j5XKHp+R46ww+4TwwmbITkLgQ8oZwTEkyaUs5m4wemvEUTUlgaL7SSLi8ZigTg2ipMCsUxaWuzlS Io3S4r4MC0GWaZeI/K/bTRkZZEiSPoyeecD0Ko0g7SbP4kkkqLdrZLANcyyCDeH0+DD17Q92NZ1U Znjkhh3mKpYlSUAEwL2ji6WAyaLdAJujTpSKQUaMlcE4lpz1QbwH5lxmYjXPzeVcFTCpaWPAJxXP Gilpup0rQtUxHbKmkcnQdvtYpAyFthvK0rFmYOgsJqkbMkIlF7Lm6W2QDcmSRDwr3jzkLVtW+QQn Re0jvVf8inZIhZwlckysoKtckqCIdFWw3LEBC41tOKwDJKRBN9kdNVIzztqqY4ZxpEJZ/ieSWmnG Yw7N65jM2k8kz/4v8uzlCJqCFB7HuDCEUhJDk2kp9X4L86xwW+duU4vphBdJO45wGf/Gx9lhBQRp bNSuZrnLVUpSxnMv17yOFag0dZRUqOLUzd+ZCNjIr93iX1nLotV5KhjosBBp7GirsLVlPQLSiQ48 cnaYoPKuLBdDrQtVu8kuCR3FLP6nHcsbt9jSdGEoqTCsVYLQz6V2p6O1xShPP8GxnMzAIdHVREhy 1pLwtvDao1Ayng+RXdoUcGiW+sAg4xIlxO6IP6yRx7tyUqZLSsA8pJBqIuUR4YZQR2r5pkkTFiUy VPq9xAePdpMzVHmwlWHXdrUdhJJ0ckzDN4XbeWukdRu/cLJuRZpOmNna2l7ZW3PSChE8+ZJ2Ckn1 bc/hqr1Kt51Beu5ETYE7KHueK5wVZsgtDQnnOUBJ0k6UkrBFCg5ChJQklCiaeEwU4m43UZ/yTGdb HLd5eCd8IH1GdyA6F//qDNx5e90JH1L7jO5AdC7ODJwZODNwZuDMwJmBMwNnBs4MnBk4M3Bm4MzA mYEzA2cGzgycGTgzcGbgzMC/KwP/DwpEbHlk0867AAAAAElFTkSuQmCC --Multipart=_Thu__17_Mar_2005_11_52_54_-0800_9sR8yt9M+8/Yn=Tn Content-Type: image/png; name="frell_mini.png" Content-Disposition: attachment; filename="frell_mini.png" Content-Transfer-Encoding: base64 iVBORw0KGgoAAAANSUhEUgAAArUAAACDBAMAAABhMv7rAAAAG1BMVEX////19fXIyMiWlpaMjIyC Hh4AAAD/AAAAAAClYThTAAAOS0lEQVR4Ae1dS27jSBLVQgbXxrhV++kLFFAnMOA5gg/gRbu3akAF XX/eJzKZSvEj06bllpPlIvMTnxcvg0GKsuTNf9u2EgM/NysZbmb/BLf3bVuFgf80blfhlUYbt6tR 27hdi9qnp8eWt2uR+9i4XYvap4dWE9biFnZbTViJ3FZvVyKWZq9fb3evr318RbMfLFq7QoDNonu/ s9zu9YXNl3vaLW0XZj6l+QXqrXhIwQY/qXt2fAFnaaNsKR/tHQbRfEn/k/g1jteut+Qgxx385H7d 6CXNayGf8j9xmo61iU/rf4F6Sw7y+Uuu4lze4fxPc2xrA7dqU4ay/M8t9dGkTvznTLka7H/e9nh/ 9ftb5lvig43U3uH8L9skRbIxTkH990FFVjLBrWtxWZA5+4nbw9PV78F2SC1yiORTIygjrz3PiRLm bYynhqesyzZt8T/sZe4t8/n769dbXHtewc2rSeb5zT45JEu5rX5wS/kgWYwlXXR6bmHvehWBsK5f E8BG0JTO65Sz5tZ8EauyMVOaG+ZTRiCSuI2j1K6y+yLXMtOECotG4oRj9x5KtE1wK0FlKVcqbDj3 r0KsnH6BvMWZy+v868sLr1X5PiG4VY1I/ES9jbqha5umoKv6ig5fO2QbrB1X3K5db68Y+rquv8B9 wroBXtH6F7i/vWL067puebsqv63erkRvy9uViIXZVm/X47bl7XrcwnKrtyvR+wVe864U2fXNPra8 XW0RxrmNJ/1vfzn+xzvA3pruSL31s8+dnkZVbD2c9qtuxU81O929Nd0RbvU8L54uv5LhP56f/9e2 Cxl4flb+jXGrjHX2vvAJ3v3DJrZtavhYde8mZyvhqnszuluf2mPcqtI2bpEpVQJU3cF8mObWhXaQ 29PEbL0BBsjt0+g9GNMWbwq6MrSaUPB3cd4+jr0u8zuvfqPU2ZvrbeGnNYcZUE146N8v4y8KTG2Z 22rhqu5g/ckIKuGqezO6db19GbyZ7dnO3GaiWmOMgTNuZ95yztxWyVZ1byb3Mm9VgFV3MN7F3Gan rTHGQM1tq7eJqSozp7sX5W1fWYdbuSYkCO04yoDzNt8nvGIbJjVGn562bbuQgadHvHYoPrt3cU0Y Xa02kRio8hZ3t36dO5a8uSYsqD/J55LX5v9G3fpadjG3OdjWGGOA3Jbv8+oXAMeSlrLJUMvbxASP o/cJb/n9hMxtaflG2/t3xnWet9P3CZnbD8/bLkUymANpcqVaTednfo/ZKaYn492f6VL1vN5OFISy JmS/H9XoI5m0WCdTXpJJrbnJwvmRHmi122RfXW7ZUO30WA9IjNyW92DTT8FUb22H61hYrJZ1cB2N C/sDW72ydfcJ/4nufp8sa7rrpNvrb3tWKBC65mLPZPO89zRlN3K+7SFw1LpmFH3MJkRUgm7uoo9u r911vzWXBejIeftYfJ53+g5M3PbROATt9/KsNS8wlIHRseF0PBwZTg8PTQo4AaSmXSfj7lO423uP 5t4C2Vsh2tE2PFBBLrS3qtFSt5MFCoUxae0JquOSlNzSSoFNpvaOAAYgmX3JnrGo3hbfnzD3uuzB Ljulk1zY7qFHQwx3DtnhdypWdGoIXnS21d8cFCk7Anl3lLJlN902PEpY+bNxaGJtS9lgEa07aQU/ 9Ks172TxeGSykVtQzf2WHmWlg4/NHYFjmnv8i7zlPFd020lUljCG02fPgb2U4NdSYe8gGHW9na62 zFugJST6VIzChT4dCZemvNMZGeHRO+dDiscwoEhtNmYli51lI1wpyEOYoRSNn5jNWmlUtpIhHwWV zhkIvBBmmEFXs8hc4VZyngAo7IWkNZJpJooVyG15DzZ/fysS9lw4mXZk3Zbr12PAOsKH0hCjSFQt cgrXxQogBR+ZqaZ4QvM3x8Msjpy1Jx2h27vZ7A/qYd6jPl9CQLmHcf9AhsmWbQkV+vQl+3cxZWfH LUWR5sbGNC6VDxRWPNbtZxk3z7VNdzi7lk1XXD2rOWwPW/5oF0cd+qE0WkllAYwnjdwMs+5rNolA tpayc9rLSFJTg5X5ZCCZtTmN2sBJU5bCeRwyAGsmJflKIgYQlrYHPqsp83b2NS8XhLUAy1pkBEso R/GjUV5zQ4B9LnpK4qwbF4yUP1Fnug66SIiUYB11C1tbFaKwfURF1Zmt1IPgbyJICsjbSDp5Z95q lvOsYVkXfczofIGCK1VcFOha9mwK0z75dK75ekFAdx41Nl4UMLav6+0st3SOwBMCO6Z3ObILhktQ 2GcSgjrVCqDHlEuy91KIAah2ujoJaY8fCtmvmp6XVogCB4Oic0KS84BU9DnvmwTrsq+aay1fGjlU YAtTEHVwmgpssmdsKrayBwA1t7P1Voaww3WT3n21Yg6oZXTdHjkQTUlhNnHL/lZADO+o3OOol6zj a5xYHIE8yCNBS4sX9ySKQWQIdTWIuyTWTIoGt0y24IKjTjbNCwbWEKNaRxzglxeNtAGzQzRrDgGT tuf7aruCk5P7IjoioprbufuEH3RdMKFmRMapuB2SFD0bHulQOpmfwoBZMc1mXKrcmSTv7VGjknJL e9lVkLZVNJW8wS1l7cYC1uVe4KJbtmPK/hwXp7UeIa5DOGRbTa8PFGpuL3o2Tm2uIxwJDPbuark4 zHqrTQJ+MZVEs64EMMpVDnEesq7H8gsxr0hyhMmAQd2kD103FeCRugUXTOMkgEZhiuOV3zRrqmrh NEtFbIO6Nbez9da2RvcpyCQgZIZXTyWRmz2S2/L57cXcVgtXdQfXMZNYCVfdm9Elt2+6B8sEtcYc A3Xezt4nJINVslXdm8m9FO5H1Nu5+4SH7Kw15hhg3pbPb/G1JJNb5rZK1Krb8hbEq94Wz2/xlSaT 3Lbf/fDTikv2Z88TZrhteetKcMl5yrzFlj9LMpe3mdu5YtPm43VZ/n0wf0GR+R7cZ26rhau6rd5G vS2vZYOEFoOZ25aXswy4JuS8xTeWTd8oZG6rRK26LW8jb5GWqd7iwzjT9wmZ29lVawK6B+u/jxHM XshtlahVt+Vt5G1Rby/ntqXlLANV3qLatnpr0qozcbo7eJ7W97fFLcFgs9Xb2XTNAtv7HyfPEwYJ dSprn7ldsI6909xSozI1mANZoxKuul9KF9we8QA33ScMUuuPSnrfuPUqX7Kmytvi87xD5MZn/PlZ iL+en/9q24UMPD//fX//z3Te9twWzH+v75zBG19F7GhW3ZHv2Jmvt4Pcnrqqe5Wvenqyf0O6P47l 798ORb2A2yEz33Dsx8l7kUME8CqWvv1jaL6NTTIweZ/AlxP4hMn0i4pJ8993snjN+31JWCvy4v2y d7vAjZo/RYU0f2umZ5XcuBzOO/36CdUiv/wzNdiGdR+KzztcHsywJGqzL31o+NXGsNzQKP/0hWJc pvsev6x5+KsQyzArlnHd6Xo7RMTIGAJkjPzTNmqMiA0OS2G5LlNnqV+u6VJdZu2U7kdyy5ow5WuQ Vw1yVRbyAz0+eV7s9x26+jMqRE7wA9tHcmsX474G3McQNQlvma4jW6brd1sW6s5gvgVuVaoXrov/ 5M4X5xaFCwhxbo7X9qm8dd1bpuu6t0zX9WSZ7ly8H5a34NX1Fg3+vGVj8kDFL1Pertt/weHbdc3t Msxz8X4ct28h83vINm7XW+fGbeN2PQbWs9zytnG7HgPrWW5527hdj4H1LLe8bdyux8B6llveNm7X Y2A9yzlv+eXCb3zUsR6q27Ccuf37eDx+G27nviziY9Z2jFs99Esu8OYFknoir70o2M+vTn4v2Mal gM9p4+/M60/Na9QPu7GPd44Tjpljdj7wsRjP4fmyTk7/aasBc4SRhk8+pYCOvzS8R4WHqhTtkcM0 Z5Nk/7t2Vd5mnFQn0RioxjjjzbHwAfOJSJo+ORp6llODUQhVSAb/J+t7YqTqhDUd+l0pBGzYBI8C 7pYCqS0g7uxejEM9NmUDDbuDMc1n4FTlW2f5Qzl13mLZkCw7COhZt82X3GIW3XgsHIhgERvNqmEb MVcfAIVZCmD88TcLEJUhKvogIjEAMPGbAGe2MhZ4R1vYKSTsjAPRiwBGgGHsRFDsa3vow8QuPvux Aw4g7CHRBMZoAYOgiJgZgqPwJA3o3Og/A3UfeQt6pBZgCF6s8cgmexRAR6BjSOMYk4hteOZsL2SQ IwbspMAGcQozNCjDoWCeQWrozFjGojd6hcoICKWEmZCFbbs9Nyev5Izu6BY7pyEHElae+xhlDGpk eFwU/8h0nbfgBSWJULj2agA3aIRh29ZgYE3o+oA4Ahta7DR7cgQemKNxFPHepnAmQQaCgSLGYh2T EEUKLEAkcz0UYMgwAm8OojBy2iStyS+aufySRklKgL4Zg3XTXK/riQFuBYBg8M+YcECHP9xpXU+D TTMhAvlwa+fl3thCwOYZDBWyjhp9jJyWh9IO2yUWtOnWuGhXLpJJdqXgIy0Obz0/gEOSQxIHtyQA XeZGNUePVEmimdu4v9X5DPqEjpWOmHha4Gh4OB18Khf0YkZv8IYIo5TwAH76ZmkUAhgivnR+oSU1 zsECTzHOjtYEwAwsrgnGRcD85x+XLrpTWtMg5jE5vNElhBmbG1YgEKtIQDi9eFEHJE/DGXZRb8MV 5ngNQFzao4sJ7nGUcfOdLxJS442NkMcdjmyEwfpAUeDT5UmFCwLGS/ziVikh5BDwrBq1KcIEKOcq r2XJL7GnH3NL7LqRDG6DsTOLAUU3YkT1ykXBRkgOn6UMPtEBReSIXeN0JkMh0Oa8PXczNSKupwQ+ cc5YFDnp/UTPM64WcutcmbH9SdORt/L2lXD1rx0+iYjv5GZh3n4nihbH2rhdTN2sYuN2lqLFAo3b xdTNKjZuZylaLABu//zVtnUY+LlZx26z+uvXz/8DI53ZddFfgbkAAAAASUVORK5CYII= --Multipart=_Thu__17_Mar_2005_11_52_54_-0800_9sR8yt9M+8/Yn=Tn Content-Type: text/plain; name="ping.asc" Content-Disposition: attachment; filename="ping.asc" Content-Transfer-Encoding: 7bit PING othermachine (10.0.0.2) 1492(1520) bytes of data. 1500 bytes from othermachine (10.0.0.2): icmp_seq=1 ttl=64 time=0.825 ms 1500 bytes from othermachine (10.0.0.2): icmp_seq=2 ttl=64 time=0.994 ms 1500 bytes from othermachine (10.0.0.2): icmp_seq=3 ttl=64 time=0.998 ms 1500 bytes from othermachine (10.0.0.2): icmp_seq=4 ttl=64 time=1.00 ms 1500 bytes from othermachine (10.0.0.2): icmp_seq=5 ttl=64 time=1.00 ms 1500 bytes from othermachine (10.0.0.2): icmp_seq=6 ttl=64 time=1.00 ms 1500 bytes from othermachine (10.0.0.2): icmp_seq=7 ttl=64 time=1.00 ms 1500 bytes from othermachine (10.0.0.2): icmp_seq=8 ttl=64 time=1.01 ms 1500 bytes from othermachine (10.0.0.2): icmp_seq=9 ttl=64 time=1.07 ms 1500 bytes from othermachine (10.0.0.2): icmp_seq=10 ttl=64 time=1.07 ms 1500 bytes from othermachine (10.0.0.2): icmp_seq=11 ttl=64 time=0.974 ms 1500 bytes from othermachine (10.0.0.2): icmp_seq=12 ttl=64 time=1.08 ms 1500 bytes from othermachine (10.0.0.2): icmp_seq=13 ttl=64 time=1.10 ms 1500 bytes from othermachine (10.0.0.2): icmp_seq=14 ttl=64 time=1.10 ms 1500 bytes from othermachine (10.0.0.2): icmp_seq=15 ttl=64 time=1.11 ms 1500 bytes from othermachine (10.0.0.2): icmp_seq=16 ttl=64 time=1.11 ms 1500 bytes from othermachine (10.0.0.2): icmp_seq=17 ttl=64 time=1.12 ms 1500 bytes from othermachine (10.0.0.2): icmp_seq=18 ttl=64 time=1.13 ms 1500 bytes from othermachine (10.0.0.2): icmp_seq=19 ttl=64 time=1.13 ms 1500 bytes from othermachine (10.0.0.2): icmp_seq=20 ttl=64 time=0.927 ms 1500 bytes from othermachine (10.0.0.2): icmp_seq=21 ttl=64 time=1.15 ms 1500 bytes from othermachine (10.0.0.2): icmp_seq=22 ttl=64 time=1.16 ms 1500 bytes from othermachine (10.0.0.2): icmp_seq=23 ttl=64 time=1.16 ms 1500 bytes from othermachine (10.0.0.2): icmp_seq=24 ttl=64 time=1.17 ms 1500 bytes from othermachine (10.0.0.2): icmp_seq=25 ttl=64 time=1.17 ms 1500 bytes from othermachine (10.0.0.2): icmp_seq=26 ttl=64 time=1.19 ms 1500 bytes from othermachine (10.0.0.2): icmp_seq=27 ttl=64 time=1.19 ms 1500 bytes from othermachine (10.0.0.2): icmp_seq=28 ttl=64 time=1.20 ms 1500 bytes from othermachine (10.0.0.2): icmp_seq=29 ttl=64 time=1.20 ms 1500 bytes from othermachine (10.0.0.2): icmp_seq=30 ttl=64 time=1.21 ms 1500 bytes from othermachine (10.0.0.2): icmp_seq=31 ttl=64 time=1.22 ms 1500 bytes from othermachine (10.0.0.2): icmp_seq=32 ttl=64 time=1.22 ms 1500 bytes from othermachine (10.0.0.2): icmp_seq=33 ttl=64 time=1.23 ms 1500 bytes from othermachine (10.0.0.2): icmp_seq=34 ttl=64 time=1.24 ms 1500 bytes from othermachine (10.0.0.2): icmp_seq=35 ttl=64 time=1.25 ms 1500 bytes from othermachine (10.0.0.2): icmp_seq=36 ttl=64 time=1.25 ms 1500 bytes from othermachine (10.0.0.2): icmp_seq=37 ttl=64 time=1.26 ms 1500 bytes from othermachine (10.0.0.2): icmp_seq=38 ttl=64 time=1.26 ms 1500 bytes from othermachine (10.0.0.2): icmp_seq=39 ttl=64 time=1.27 ms 1500 bytes from othermachine (10.0.0.2): icmp_seq=40 ttl=64 time=1.28 ms 1500 bytes from othermachine (10.0.0.2): icmp_seq=41 ttl=64 time=1.29 ms 1500 bytes from othermachine (10.0.0.2): icmp_seq=42 ttl=64 time=1.29 ms 1500 bytes from othermachine (10.0.0.2): icmp_seq=43 ttl=64 time=1.30 ms 1500 bytes from othermachine (10.0.0.2): icmp_seq=44 ttl=64 time=1.31 ms 1500 bytes from othermachine (10.0.0.2): icmp_seq=45 ttl=64 time=1.31 ms 1500 bytes from othermachine (10.0.0.2): icmp_seq=46 ttl=64 time=1.32 ms 1500 bytes from othermachine (10.0.0.2): icmp_seq=47 ttl=64 time=1.33 ms 1500 bytes from othermachine (10.0.0.2): icmp_seq=48 ttl=64 time=1.34 ms 1500 bytes from othermachine (10.0.0.2): icmp_seq=49 ttl=64 time=1.35 ms 1500 bytes from othermachine (10.0.0.2): icmp_seq=50 ttl=64 time=1.36 ms 1500 bytes from othermachine (10.0.0.2): icmp_seq=51 ttl=64 time=1.35 ms 1500 bytes from othermachine (10.0.0.2): icmp_seq=52 ttl=64 time=1.37 ms 1500 bytes from othermachine (10.0.0.2): icmp_seq=53 ttl=64 time=1.37 ms 1500 bytes from othermachine (10.0.0.2): icmp_seq=54 ttl=64 time=1.39 ms 1500 bytes from othermachine (10.0.0.2): icmp_seq=55 ttl=64 time=1.38 ms 1500 bytes from othermachine (10.0.0.2): icmp_seq=56 ttl=64 time=1.39 ms 1500 bytes from othermachine (10.0.0.2): icmp_seq=57 ttl=64 time=1.39 ms 1500 bytes from othermachine (10.0.0.2): icmp_seq=58 ttl=64 time=1.44 ms 1500 bytes from othermachine (10.0.0.2): icmp_seq=59 ttl=64 time=1.41 ms 1500 bytes from othermachine (10.0.0.2): icmp_seq=60 ttl=64 time=1.42 ms 1500 bytes from othermachine (10.0.0.2): icmp_seq=61 ttl=64 time=1.43 ms 1500 bytes from othermachine (10.0.0.2): icmp_seq=62 ttl=64 time=1.43 ms 1500 bytes from othermachine (10.0.0.2): icmp_seq=63 ttl=64 time=1.44 ms 1500 bytes from othermachine (10.0.0.2): icmp_seq=64 ttl=64 time=1.45 ms 1500 bytes from othermachine (10.0.0.2): icmp_seq=65 ttl=64 time=1.42 ms 1500 bytes from othermachine (10.0.0.2): icmp_seq=66 ttl=64 time=1.46 ms 1500 bytes from othermachine (10.0.0.2): icmp_seq=67 ttl=64 time=1.47 ms 1500 bytes from othermachine (10.0.0.2): icmp_seq=68 ttl=64 time=1.47 ms 1500 bytes from othermachine (10.0.0.2): icmp_seq=69 ttl=64 time=1.48 ms 1500 bytes from othermachine (10.0.0.2): icmp_seq=70 ttl=64 time=1.49 ms 1500 bytes from othermachine (10.0.0.2): icmp_seq=71 ttl=64 time=1.50 ms 1500 bytes from othermachine (10.0.0.2): icmp_seq=72 ttl=64 time=1.41 ms 1500 bytes from othermachine (10.0.0.2): icmp_seq=73 ttl=64 time=1.51 ms 1500 bytes from othermachine (10.0.0.2): icmp_seq=74 ttl=64 time=1.51 ms 1500 bytes from othermachine (10.0.0.2): icmp_seq=75 ttl=64 time=1.52 ms 1500 bytes from othermachine (10.0.0.2): icmp_seq=76 ttl=64 time=1.52 ms 1500 bytes from othermachine (10.0.0.2): icmp_seq=77 ttl=64 time=1.53 ms 1500 bytes from othermachine (10.0.0.2): icmp_seq=78 ttl=64 time=1.54 ms 1500 bytes from othermachine (10.0.0.2): icmp_seq=79 ttl=64 time=1.55 ms 1500 bytes from othermachine (10.0.0.2): icmp_seq=80 ttl=64 time=1.55 ms 1500 bytes from othermachine (10.0.0.2): icmp_seq=81 ttl=64 time=1.57 ms 1500 bytes from othermachine (10.0.0.2): icmp_seq=82 ttl=64 time=1.56 ms 1500 bytes from othermachine (10.0.0.2): icmp_seq=83 ttl=64 time=1.58 ms 1500 bytes from othermachine (10.0.0.2): icmp_seq=84 ttl=64 time=1.58 ms 1500 bytes from othermachine (10.0.0.2): icmp_seq=85 ttl=64 time=1.59 ms 1500 bytes from othermachine (10.0.0.2): icmp_seq=86 ttl=64 time=1.60 ms 1500 bytes from othermachine (10.0.0.2): icmp_seq=87 ttl=64 time=1.61 ms 1500 bytes from othermachine (10.0.0.2): icmp_seq=88 ttl=64 time=1.61 ms 1500 bytes from othermachine (10.0.0.2): icmp_seq=89 ttl=64 time=1.62 ms 1500 bytes from othermachine (10.0.0.2): icmp_seq=90 ttl=64 time=1.63 ms 1500 bytes from othermachine (10.0.0.2): icmp_seq=91 ttl=64 time=1.64 ms 1500 bytes from othermachine (10.0.0.2): icmp_seq=92 ttl=64 time=1.64 ms 1500 bytes from othermachine (10.0.0.2): icmp_seq=93 ttl=64 time=1.65 ms 1500 bytes from othermachine (10.0.0.2): icmp_seq=94 ttl=64 time=1.65 ms 1500 bytes from othermachine (10.0.0.2): icmp_seq=95 ttl=64 time=1.66 ms 1500 bytes from othermachine (10.0.0.2): icmp_seq=96 ttl=64 time=1.67 ms 1500 bytes from othermachine (10.0.0.2): icmp_seq=97 ttl=64 time=1.68 ms 1500 bytes from othermachine (10.0.0.2): icmp_seq=98 ttl=64 time=1.68 ms 1500 bytes from othermachine (10.0.0.2): icmp_seq=99 ttl=64 time=1.69 ms 1500 bytes from othermachine (10.0.0.2): icmp_seq=100 ttl=64 time=1.70 ms 1500 bytes from othermachine (10.0.0.2): icmp_seq=101 ttl=64 time=1.70 ms 1500 bytes from othermachine (10.0.0.2): icmp_seq=102 ttl=64 time=1.71 ms 1500 bytes from othermachine (10.0.0.2): icmp_seq=103 ttl=64 time=1.72 ms 1500 bytes from othermachine (10.0.0.2): icmp_seq=104 ttl=64 time=1.72 ms 1500 bytes from othermachine (10.0.0.2): icmp_seq=105 ttl=64 time=1.73 ms 1500 bytes from othermachine (10.0.0.2): icmp_seq=106 ttl=64 time=0.748 ms 1500 bytes from othermachine (10.0.0.2): icmp_seq=107 ttl=64 time=0.756 ms 1500 bytes from othermachine (10.0.0.2): icmp_seq=108 ttl=64 time=0.768 ms 1500 bytes from othermachine (10.0.0.2): icmp_seq=109 ttl=64 time=0.771 ms 1500 bytes from othermachine (10.0.0.2): icmp_seq=110 ttl=64 time=0.778 ms 1500 bytes from othermachine (10.0.0.2): icmp_seq=111 ttl=64 time=0.782 ms 1500 bytes from othermachine (10.0.0.2): icmp_seq=112 ttl=64 time=0.789 ms 1500 bytes from othermachine (10.0.0.2): icmp_seq=113 ttl=64 time=0.809 ms 1500 bytes from othermachine (10.0.0.2): icmp_seq=114 ttl=64 time=0.805 ms 1500 bytes from othermachine (10.0.0.2): icmp_seq=115 ttl=64 time=0.811 ms 1500 bytes from othermachine (10.0.0.2): icmp_seq=116 ttl=64 time=0.820 ms 1500 bytes from othermachine (10.0.0.2): icmp_seq=117 ttl=64 time=0.823 ms 1500 bytes from othermachine (10.0.0.2): icmp_seq=118 ttl=64 time=0.830 ms 1500 bytes from othermachine (10.0.0.2): icmp_seq=119 ttl=64 time=0.840 ms 1500 bytes from othermachine (10.0.0.2): icmp_seq=120 ttl=64 time=0.848 ms 1500 bytes from othermachine (10.0.0.2): icmp_seq=121 ttl=64 time=0.850 ms 1500 bytes from othermachine (10.0.0.2): icmp_seq=122 ttl=64 time=1.83 ms 1500 bytes from othermachine (10.0.0.2): icmp_seq=123 ttl=64 time=0.871 ms 1500 bytes from othermachine (10.0.0.2): icmp_seq=124 ttl=64 time=0.875 ms 1500 bytes from othermachine (10.0.0.2): icmp_seq=125 ttl=64 time=0.878 ms 1500 bytes from othermachine (10.0.0.2): icmp_seq=126 ttl=64 time=0.891 ms 1500 bytes from othermachine (10.0.0.2): icmp_seq=127 ttl=64 time=0.894 ms 1500 bytes from othermachine (10.0.0.2): icmp_seq=128 ttl=64 time=0.894 ms 1500 bytes from othermachine (10.0.0.2): icmp_seq=129 ttl=64 time=0.911 ms 1500 bytes from othermachine (10.0.0.2): icmp_seq=130 ttl=64 time=0.913 ms 1500 bytes from othermachine (10.0.0.2): icmp_seq=131 ttl=64 time=0.921 ms 1500 bytes from othermachine (10.0.0.2): icmp_seq=132 ttl=64 time=0.929 ms 1500 bytes from othermachine (10.0.0.2): icmp_seq=133 ttl=64 time=0.940 ms 1500 bytes from othermachine (10.0.0.2): icmp_seq=134 ttl=64 time=0.980 ms 1500 bytes from othermachine (10.0.0.2): icmp_seq=135 ttl=64 time=0.958 ms 1500 bytes from othermachine (10.0.0.2): icmp_seq=136 ttl=64 time=0.944 ms 1500 bytes from othermachine (10.0.0.2): icmp_seq=137 ttl=64 time=0.965 ms 1500 bytes from othermachine (10.0.0.2): icmp_seq=138 ttl=64 time=0.969 ms 1500 bytes from othermachine (10.0.0.2): icmp_seq=139 ttl=64 time=1.00 ms 1500 bytes from othermachine (10.0.0.2): icmp_seq=140 ttl=64 time=0.985 ms 1500 bytes from othermachine (10.0.0.2): icmp_seq=141 ttl=64 time=0.994 ms 1500 bytes from othermachine (10.0.0.2): icmp_seq=142 ttl=64 time=1.00 ms 1500 bytes from othermachine (10.0.0.2): icmp_seq=143 ttl=64 time=1.00 ms 1500 bytes from othermachine (10.0.0.2): icmp_seq=144 ttl=64 time=0.998 ms 1500 bytes from othermachine (10.0.0.2): icmp_seq=145 ttl=64 time=1.01 ms 1500 bytes from othermachine (10.0.0.2): icmp_seq=146 ttl=64 time=0.995 ms 1500 bytes from othermachine (10.0.0.2): icmp_seq=147 ttl=64 time=0.993 ms 1500 bytes from othermachine (10.0.0.2): icmp_seq=148 ttl=64 time=1.00 ms 1500 bytes from othermachine (10.0.0.2): icmp_seq=149 ttl=64 time=1.00 ms 1500 bytes from othermachine (10.0.0.2): icmp_seq=150 ttl=64 time=1.00 ms 1500 bytes from othermachine (10.0.0.2): icmp_seq=151 ttl=64 time=1.00 ms 1500 bytes from othermachine (10.0.0.2): icmp_seq=152 ttl=64 time=1.01 ms 1500 bytes from othermachine (10.0.0.2): icmp_seq=153 ttl=64 time=1.07 ms 1500 bytes from othermachine (10.0.0.2): icmp_seq=154 ttl=64 time=1.08 ms 1500 bytes from othermachine (10.0.0.2): icmp_seq=155 ttl=64 time=1.09 ms 1500 bytes from othermachine (10.0.0.2): icmp_seq=156 ttl=64 time=1.09 ms 1500 bytes from othermachine (10.0.0.2): icmp_seq=157 ttl=64 time=1.10 ms 1500 bytes from othermachine (10.0.0.2): icmp_seq=158 ttl=64 time=1.10 ms 1500 bytes from othermachine (10.0.0.2): icmp_seq=159 ttl=64 time=1.10 ms 1500 bytes from othermachine (10.0.0.2): icmp_seq=160 ttl=64 time=1.11 ms 1500 bytes from othermachine (10.0.0.2): icmp_seq=161 ttl=64 time=1.12 ms 1500 bytes from othermachine (10.0.0.2): icmp_seq=162 ttl=64 time=1.14 ms 1500 bytes from othermachine (10.0.0.2): icmp_seq=163 ttl=64 time=1.12 ms 1500 bytes from othermachine (10.0.0.2): icmp_seq=164 ttl=64 time=1.15 ms 1500 bytes from othermachine (10.0.0.2): icmp_seq=165 ttl=64 time=1.14 ms 1500 bytes from othermachine (10.0.0.2): icmp_seq=166 ttl=64 time=1.15 ms 1500 bytes from othermachine (10.0.0.2): icmp_seq=167 ttl=64 time=1.16 ms 1500 bytes from othermachine (10.0.0.2): icmp_seq=168 ttl=64 time=1.17 ms 1500 bytes from othermachine (10.0.0.2): icmp_seq=169 ttl=64 time=1.17 ms 1500 bytes from othermachine (10.0.0.2): icmp_seq=170 ttl=64 time=1.20 ms 1500 bytes from othermachine (10.0.0.2): icmp_seq=171 ttl=64 time=1.19 ms 1500 bytes from othermachine (10.0.0.2): icmp_seq=172 ttl=64 time=1.20 ms 1500 bytes from othermachine (10.0.0.2): icmp_seq=173 ttl=64 time=1.21 ms 1500 bytes from othermachine (10.0.0.2): icmp_seq=174 ttl=64 time=1.21 ms 1500 bytes from othermachine (10.0.0.2): icmp_seq=175 ttl=64 time=1.22 ms 1500 bytes from othermachine (10.0.0.2): icmp_seq=176 ttl=64 time=1.23 ms 1500 bytes from othermachine (10.0.0.2): icmp_seq=177 ttl=64 time=1.25 ms 1500 bytes from othermachine (10.0.0.2): icmp_seq=178 ttl=64 time=1.24 ms 1500 bytes from othermachine (10.0.0.2): icmp_seq=179 ttl=64 time=1.25 ms 1500 bytes from othermachine (10.0.0.2): icmp_seq=180 ttl=64 time=1.25 ms 1500 bytes from othermachine (10.0.0.2): icmp_seq=181 ttl=64 time=1.26 ms 1500 bytes from othermachine (10.0.0.2): icmp_seq=182 ttl=64 time=1.27 ms 1500 bytes from othermachine (10.0.0.2): icmp_seq=183 ttl=64 time=1.28 ms 1500 bytes from othermachine (10.0.0.2): icmp_seq=184 ttl=64 time=1.28 ms 1500 bytes from othermachine (10.0.0.2): icmp_seq=185 ttl=64 time=1.29 ms 1500 bytes from othermachine (10.0.0.2): icmp_seq=186 ttl=64 time=1.29 ms 1500 bytes from othermachine (10.0.0.2): icmp_seq=187 ttl=64 time=1.30 ms 1500 bytes from othermachine (10.0.0.2): icmp_seq=188 ttl=64 time=1.31 ms 1500 bytes from othermachine (10.0.0.2): icmp_seq=189 ttl=64 time=1.32 ms 1500 bytes from othermachine (10.0.0.2): icmp_seq=190 ttl=64 time=1.32 ms 1500 bytes from othermachine (10.0.0.2): icmp_seq=191 ttl=64 time=1.33 ms 1500 bytes from othermachine (10.0.0.2): icmp_seq=192 ttl=64 time=1.33 ms 1500 bytes from othermachine (10.0.0.2): icmp_seq=193 ttl=64 time=1.34 ms 1500 bytes from othermachine (10.0.0.2): icmp_seq=194 ttl=64 time=1.34 ms 1500 bytes from othermachine (10.0.0.2): icmp_seq=195 ttl=64 time=1.35 ms 1500 bytes from othermachine (10.0.0.2): icmp_seq=196 ttl=64 time=1.36 ms 1500 bytes from othermachine (10.0.0.2): icmp_seq=197 ttl=64 time=1.37 ms 1500 bytes from othermachine (10.0.0.2): icmp_seq=198 ttl=64 time=1.38 ms 1500 bytes from othermachine (10.0.0.2): icmp_seq=199 ttl=64 time=1.38 ms 1500 bytes from othermachine (10.0.0.2): icmp_seq=200 ttl=64 time=1.40 ms 1500 bytes from othermachine (10.0.0.2): icmp_seq=201 ttl=64 time=1.39 ms 1500 bytes from othermachine (10.0.0.2): icmp_seq=202 ttl=64 time=1.40 ms 1500 bytes from othermachine (10.0.0.2): icmp_seq=203 ttl=64 time=1.41 ms 1500 bytes from othermachine (10.0.0.2): icmp_seq=204 ttl=64 time=1.42 ms 1500 bytes from othermachine (10.0.0.2): icmp_seq=205 ttl=64 time=1.43 ms 1500 bytes from othermachine (10.0.0.2): icmp_seq=206 ttl=64 time=1.43 ms 1500 bytes from othermachine (10.0.0.2): icmp_seq=207 ttl=64 time=1.44 ms 1500 bytes from othermachine (10.0.0.2): icmp_seq=208 ttl=64 time=1.45 ms 1500 bytes from othermachine (10.0.0.2): icmp_seq=209 ttl=64 time=1.45 ms 1500 bytes from othermachine (10.0.0.2): icmp_seq=210 ttl=64 time=1.46 ms 1500 bytes from othermachine (10.0.0.2): icmp_seq=211 ttl=64 time=1.47 ms 1500 bytes from othermachine (10.0.0.2): icmp_seq=212 ttl=64 time=1.48 ms 1500 bytes from othermachine (10.0.0.2): icmp_seq=213 ttl=64 time=1.48 ms 1500 bytes from othermachine (10.0.0.2): icmp_seq=214 ttl=64 time=1.48 ms 1500 bytes from othermachine (10.0.0.2): icmp_seq=215 ttl=64 time=1.50 ms 1500 bytes from othermachine (10.0.0.2): icmp_seq=216 ttl=64 time=1.50 ms 1500 bytes from othermachine (10.0.0.2): icmp_seq=217 ttl=64 time=1.50 ms 1500 bytes from othermachine (10.0.0.2): icmp_seq=218 ttl=64 time=1.52 ms 1500 bytes from othermachine (10.0.0.2): icmp_seq=219 ttl=64 time=1.53 ms 1500 bytes from othermachine (10.0.0.2): icmp_seq=220 ttl=64 time=1.53 ms 1500 bytes from othermachine (10.0.0.2): icmp_seq=221 ttl=64 time=1.54 ms 1500 bytes from othermachine (10.0.0.2): icmp_seq=222 ttl=64 time=1.54 ms 1500 bytes from othermachine (10.0.0.2): icmp_seq=223 ttl=64 time=1.55 ms 1500 bytes from othermachine (10.0.0.2): icmp_seq=224 ttl=64 time=1.55 ms 1500 bytes from othermachine (10.0.0.2): icmp_seq=225 ttl=64 time=1.57 ms 1500 bytes from othermachine (10.0.0.2): icmp_seq=226 ttl=64 time=1.57 ms 1500 bytes from othermachine (10.0.0.2): icmp_seq=227 ttl=64 time=1.58 ms 1500 bytes from othermachine (10.0.0.2): icmp_seq=228 ttl=64 time=1.59 ms 1500 bytes from othermachine (10.0.0.2): icmp_seq=229 ttl=64 time=1.59 ms 1500 bytes from othermachine (10.0.0.2): icmp_seq=230 ttl=64 time=1.60 ms 1500 bytes from othermachine (10.0.0.2): icmp_seq=231 ttl=64 time=1.67 ms 1500 bytes from othermachine (10.0.0.2): icmp_seq=232 ttl=64 time=1.61 ms 1500 bytes from othermachine (10.0.0.2): icmp_seq=233 ttl=64 time=1.63 ms 1500 bytes from othermachine (10.0.0.2): icmp_seq=234 ttl=64 time=1.63 ms 1500 bytes from othermachine (10.0.0.2): icmp_seq=235 ttl=64 time=1.63 ms 1500 bytes from othermachine (10.0.0.2): icmp_seq=236 ttl=64 time=1.64 ms 1500 bytes from othermachine (10.0.0.2): icmp_seq=237 ttl=64 time=1.65 ms 1500 bytes from othermachine (10.0.0.2): icmp_seq=238 ttl=64 time=1.66 ms 1500 bytes from othermachine (10.0.0.2): icmp_seq=239 ttl=64 time=1.66 ms 1500 bytes from othermachine (10.0.0.2): icmp_seq=240 ttl=64 time=1.67 ms 1500 bytes from othermachine (10.0.0.2): icmp_seq=241 ttl=64 time=1.68 ms 1500 bytes from othermachine (10.0.0.2): icmp_seq=242 ttl=64 time=1.68 ms 1500 bytes from othermachine (10.0.0.2): icmp_seq=243 ttl=64 time=1.69 ms 1500 bytes from othermachine (10.0.0.2): icmp_seq=244 ttl=64 time=1.69 ms 1500 bytes from othermachine (10.0.0.2): icmp_seq=245 ttl=64 time=1.70 ms 1500 bytes from othermachine (10.0.0.2): icmp_seq=246 ttl=64 time=1.71 ms 1500 bytes from othermachine (10.0.0.2): icmp_seq=247 ttl=64 time=0.753 ms 1500 bytes from othermachine (10.0.0.2): icmp_seq=248 ttl=64 time=1.72 ms 1500 bytes from othermachine (10.0.0.2): icmp_seq=249 ttl=64 time=1.73 ms 1500 bytes from othermachine (10.0.0.2): icmp_seq=250 ttl=64 time=1.73 ms 1500 bytes from othermachine (10.0.0.2): icmp_seq=251 ttl=64 time=1.75 ms 1500 bytes from othermachine (10.0.0.2): icmp_seq=252 ttl=64 time=1.75 ms 1500 bytes from othermachine (10.0.0.2): icmp_seq=253 ttl=64 time=0.769 ms 1500 bytes from othermachine (10.0.0.2): icmp_seq=254 ttl=64 time=0.781 ms 1500 bytes from othermachine (10.0.0.2): icmp_seq=255 ttl=64 time=1.76 ms 1500 bytes from othermachine (10.0.0.2): icmp_seq=256 ttl=64 time=1.78 ms 1500 bytes from othermachine (10.0.0.2): icmp_seq=257 ttl=64 time=0.798 ms 1500 bytes from othermachine (10.0.0.2): icmp_seq=258 ttl=64 time=0.811 ms 1500 bytes from othermachine (10.0.0.2): icmp_seq=259 ttl=64 time=0.809 ms 1500 bytes from othermachine (10.0.0.2): icmp_seq=260 ttl=64 time=0.815 ms 1500 bytes from othermachine (10.0.0.2): icmp_seq=261 ttl=64 time=0.825 ms 1500 bytes from othermachine (10.0.0.2): icmp_seq=262 ttl=64 time=0.831 ms 1500 bytes from othermachine (10.0.0.2): icmp_seq=263 ttl=64 time=0.842 ms 1500 bytes from othermachine (10.0.0.2): icmp_seq=264 ttl=64 time=0.841 ms 1500 bytes from othermachine (10.0.0.2): icmp_seq=265 ttl=64 time=0.852 ms 1500 bytes from othermachine (10.0.0.2): icmp_seq=266 ttl=64 time=0.861 ms 1500 bytes from othermachine (10.0.0.2): icmp_seq=267 ttl=64 time=0.865 ms 1500 bytes from othermachine (10.0.0.2): icmp_seq=268 ttl=64 time=0.874 ms 1500 bytes from othermachine (10.0.0.2): icmp_seq=269 ttl=64 time=0.879 ms 1500 bytes from othermachine (10.0.0.2): icmp_seq=270 ttl=64 time=0.880 ms 1500 bytes from othermachine (10.0.0.2): icmp_seq=271 ttl=64 time=0.897 ms 1500 bytes from othermachine (10.0.0.2): icmp_seq=272 ttl=64 time=0.902 ms 1500 bytes from othermachine (10.0.0.2): icmp_seq=273 ttl=64 time=0.909 ms 1500 bytes from othermachine (10.0.0.2): icmp_seq=274 ttl=64 time=0.913 ms 1500 bytes from othermachine (10.0.0.2): icmp_seq=275 ttl=64 time=0.922 ms 1500 bytes from othermachine (10.0.0.2): icmp_seq=276 ttl=64 time=0.931 ms 1500 bytes from othermachine (10.0.0.2): icmp_seq=277 ttl=64 time=0.936 ms 1500 bytes from othermachine (10.0.0.2): icmp_seq=278 ttl=64 time=0.945 ms 1500 bytes from othermachine (10.0.0.2): icmp_seq=279 ttl=64 time=0.956 ms 1500 bytes from othermachine (10.0.0.2): icmp_seq=280 ttl=64 time=0.957 ms 1500 bytes from othermachine (10.0.0.2): icmp_seq=281 ttl=64 time=0.975 ms 1500 bytes from othermachine (10.0.0.2): icmp_seq=282 ttl=64 time=0.964 ms 1500 bytes from othermachine (10.0.0.2): icmp_seq=283 ttl=64 time=0.985 ms 1500 bytes from othermachine (10.0.0.2): icmp_seq=284 ttl=64 time=0.989 ms 1500 bytes from othermachine (10.0.0.2): icmp_seq=285 ttl=64 time=0.991 ms 1500 bytes from othermachine (10.0.0.2): icmp_seq=286 ttl=64 time=1.00 ms 1500 bytes from othermachine (10.0.0.2): icmp_seq=287 ttl=64 time=1.00 ms 1500 bytes from othermachine (10.0.0.2): icmp_seq=288 ttl=64 time=0.989 ms 1500 bytes from othermachine (10.0.0.2): icmp_seq=289 ttl=64 time=1.00 ms 1500 bytes from othermachine (10.0.0.2): icmp_seq=290 ttl=64 time=0.999 ms 1500 bytes from othermachine (10.0.0.2): icmp_seq=291 ttl=64 time=0.996 ms 1500 bytes from othermachine (10.0.0.2): icmp_seq=292 ttl=64 time=1.00 ms 1500 bytes from othermachine (10.0.0.2): icmp_seq=293 ttl=64 time=0.999 ms 1500 bytes from othermachine (10.0.0.2): icmp_seq=294 ttl=64 time=0.991 ms 1500 bytes from othermachine (10.0.0.2): icmp_seq=295 ttl=64 time=0.989 ms 1500 bytes from othermachine (10.0.0.2): icmp_seq=296 ttl=64 time=1.04 ms 1500 bytes from othermachine (10.0.0.2): icmp_seq=297 ttl=64 time=1.07 ms 1500 bytes from othermachine (10.0.0.2): icmp_seq=298 ttl=64 time=1.08 ms 1500 bytes from othermachine (10.0.0.2): icmp_seq=299 ttl=64 time=1.08 ms 1500 bytes from othermachine (10.0.0.2): icmp_seq=300 ttl=64 time=1.09 ms 1500 bytes from othermachine (10.0.0.2): icmp_seq=301 ttl=64 time=1.09 ms 1500 bytes from othermachine (10.0.0.2): icmp_seq=302 ttl=64 time=1.11 ms 1500 bytes from othermachine (10.0.0.2): icmp_seq=303 ttl=64 time=1.11 ms 1500 bytes from othermachine (10.0.0.2): icmp_seq=304 ttl=64 time=1.12 ms 1500 bytes from othermachine (10.0.0.2): icmp_seq=305 ttl=64 time=1.12 ms 1500 bytes from othermachine (10.0.0.2): icmp_seq=306 ttl=64 time=1.13 ms 1500 bytes from othermachine (10.0.0.2): icmp_seq=307 ttl=64 time=1.13 ms 1500 bytes from othermachine (10.0.0.2): icmp_seq=308 ttl=64 time=1.14 ms 1500 bytes from othermachine (10.0.0.2): icmp_seq=309 ttl=64 time=1.14 ms 1500 bytes from othermachine (10.0.0.2): icmp_seq=310 ttl=64 time=1.15 ms 1500 bytes from othermachine (10.0.0.2): icmp_seq=311 ttl=64 time=1.16 ms 1500 bytes from othermachine (10.0.0.2): icmp_seq=312 ttl=64 time=1.15 ms 1500 bytes from othermachine (10.0.0.2): icmp_seq=313 ttl=64 time=1.17 ms 1500 bytes from othermachine (10.0.0.2): icmp_seq=314 ttl=64 time=1.19 ms 1500 bytes from othermachine (10.0.0.2): icmp_seq=315 ttl=64 time=1.19 ms 1500 bytes from othermachine (10.0.0.2): icmp_seq=316 ttl=64 time=1.20 ms 1500 bytes from othermachine (10.0.0.2): icmp_seq=317 ttl=64 time=1.20 ms 1500 bytes from othermachine (10.0.0.2): icmp_seq=318 ttl=64 time=1.21 ms 1500 bytes from othermachine (10.0.0.2): icmp_seq=319 ttl=64 time=1.22 ms 1500 bytes from othermachine (10.0.0.2): icmp_seq=320 ttl=64 time=1.22 ms 1500 bytes from othermachine (10.0.0.2): icmp_seq=321 ttl=64 time=1.23 ms 1500 bytes from othermachine (10.0.0.2): icmp_seq=322 ttl=64 time=1.25 ms 1500 bytes from othermachine (10.0.0.2): icmp_seq=323 ttl=64 time=1.24 ms 1500 bytes from othermachine (10.0.0.2): icmp_seq=324 ttl=64 time=1.25 ms 1500 bytes from othermachine (10.0.0.2): icmp_seq=325 ttl=64 time=1.26 ms 1500 bytes from othermachine (10.0.0.2): icmp_seq=326 ttl=64 time=1.27 ms 1500 bytes from othermachine (10.0.0.2): icmp_seq=327 ttl=64 time=1.27 ms 1500 bytes from othermachine (10.0.0.2): icmp_seq=328 ttl=64 time=1.28 ms 1500 bytes from othermachine (10.0.0.2): icmp_seq=329 ttl=64 time=1.28 ms 1500 bytes from othermachine (10.0.0.2): icmp_seq=330 ttl=64 time=1.29 ms 1500 bytes from othermachine (10.0.0.2): icmp_seq=331 ttl=64 time=1.30 ms 1500 bytes from othermachine (10.0.0.2): icmp_seq=332 ttl=64 time=1.31 ms 1500 bytes from othermachine (10.0.0.2): icmp_seq=333 ttl=64 time=1.33 ms 1500 bytes from othermachine (10.0.0.2): icmp_seq=334 ttl=64 time=1.32 ms 1500 bytes from othermachine (10.0.0.2): icmp_seq=335 ttl=64 time=1.33 ms 1500 bytes from othermachine (10.0.0.2): icmp_seq=336 ttl=64 time=1.33 ms 1500 bytes from othermachine (10.0.0.2): icmp_seq=337 ttl=64 time=1.34 ms 1500 bytes from othermachine (10.0.0.2): icmp_seq=338 ttl=64 time=1.35 ms 1500 bytes from othermachine (10.0.0.2): icmp_seq=339 ttl=64 time=1.34 ms 1500 bytes from othermachine (10.0.0.2): icmp_seq=340 ttl=64 time=1.36 ms 1500 bytes from othermachine (10.0.0.2): icmp_seq=341 ttl=64 time=1.30 ms 1500 bytes from othermachine (10.0.0.2): icmp_seq=342 ttl=64 time=1.35 ms 1500 bytes from othermachine (10.0.0.2): icmp_seq=343 ttl=64 time=1.36 ms 1500 bytes from othermachine (10.0.0.2): icmp_seq=344 ttl=64 time=1.37 ms 1500 bytes from othermachine (10.0.0.2): icmp_seq=345 ttl=64 time=1.39 ms 1500 bytes from othermachine (10.0.0.2): icmp_seq=346 ttl=64 time=1.40 ms 1500 bytes from othermachine (10.0.0.2): icmp_seq=347 ttl=64 time=1.41 ms 1500 bytes from othermachine (10.0.0.2): icmp_seq=348 ttl=64 time=1.39 ms 1500 bytes from othermachine (10.0.0.2): icmp_seq=349 ttl=64 time=1.39 ms 1500 bytes from othermachine (10.0.0.2): icmp_seq=350 ttl=64 time=1.39 ms 1500 bytes from othermachine (10.0.0.2): icmp_seq=351 ttl=64 time=1.37 ms 1500 bytes from othermachine (10.0.0.2): icmp_seq=352 ttl=64 time=1.44 ms 1500 bytes from othermachine (10.0.0.2): icmp_seq=353 ttl=64 time=1.78 ms 1500 bytes from othermachine (10.0.0.2): icmp_seq=354 ttl=64 time=1.46 ms 1500 bytes from othermachine (10.0.0.2): icmp_seq=355 ttl=64 time=1.46 ms 1500 bytes from othermachine (10.0.0.2): icmp_seq=356 ttl=64 time=1.48 ms 1500 bytes from othermachine (10.0.0.2): icmp_seq=357 ttl=64 time=1.48 ms 1500 bytes from othermachine (10.0.0.2): icmp_seq=358 ttl=64 time=1.48 ms 1500 bytes from othermachine (10.0.0.2): icmp_seq=359 ttl=64 time=1.48 ms 1500 bytes from othermachine (10.0.0.2): icmp_seq=360 ttl=64 time=1.49 ms 1500 bytes from othermachine (10.0.0.2): icmp_seq=361 ttl=64 time=1.49 ms 1500 bytes from othermachine (10.0.0.2): icmp_seq=362 ttl=64 time=1.52 ms 1500 bytes from othermachine (10.0.0.2): icmp_seq=363 ttl=64 time=1.50 ms 1500 bytes from othermachine (10.0.0.2): icmp_seq=364 ttl=64 time=1.53 ms 1500 bytes from othermachine (10.0.0.2): icmp_seq=365 ttl=64 time=1.54 ms 1500 bytes from othermachine (10.0.0.2): icmp_seq=366 ttl=64 time=1.55 ms 1500 bytes from othermachine (10.0.0.2): icmp_seq=367 ttl=64 time=1.55 ms 1500 bytes from othermachine (10.0.0.2): icmp_seq=368 ttl=64 time=1.55 ms 1500 bytes from othermachine (10.0.0.2): icmp_seq=369 ttl=64 time=1.55 ms 1500 bytes from othermachine (10.0.0.2): icmp_seq=370 ttl=64 time=1.56 ms 1500 bytes from othermachine (10.0.0.2): icmp_seq=371 ttl=64 time=1.57 ms 1500 bytes from othermachine (10.0.0.2): icmp_seq=372 ttl=64 time=1.59 ms 1500 bytes from othermachine (10.0.0.2): icmp_seq=373 ttl=64 time=1.58 ms 1500 bytes from othermachine (10.0.0.2): icmp_seq=374 ttl=64 time=1.60 ms 1500 bytes from othermachine (10.0.0.2): icmp_seq=375 ttl=64 time=1.62 ms 1500 bytes from othermachine (10.0.0.2): icmp_seq=376 ttl=64 time=1.61 ms 1500 bytes from othermachine (10.0.0.2): icmp_seq=377 ttl=64 time=1.62 ms 1500 bytes from othermachine (10.0.0.2): icmp_seq=378 ttl=64 time=1.62 ms 1500 bytes from othermachine (10.0.0.2): icmp_seq=379 ttl=64 time=1.62 ms 1500 bytes from othermachine (10.0.0.2): icmp_seq=380 ttl=64 time=1.63 ms 1500 bytes from othermachine (10.0.0.2): icmp_seq=381 ttl=64 time=1.64 ms 1500 bytes from othermachine (10.0.0.2): icmp_seq=382 ttl=64 time=1.70 ms 1500 bytes from othermachine (10.0.0.2): icmp_seq=383 ttl=64 time=1.65 ms 1500 bytes from othermachine (10.0.0.2): icmp_seq=384 ttl=64 time=1.67 ms 1500 bytes from othermachine (10.0.0.2): icmp_seq=385 ttl=64 time=1.68 ms 1500 bytes from othermachine (10.0.0.2): icmp_seq=386 ttl=64 time=1.67 ms 1500 bytes from othermachine (10.0.0.2): icmp_seq=387 ttl=64 time=1.69 ms 1500 bytes from othermachine (10.0.0.2): icmp_seq=388 ttl=64 time=1.68 ms 1500 bytes from othermachine (10.0.0.2): icmp_seq=389 ttl=64 time=1.68 ms 1500 bytes from othermachine (10.0.0.2): icmp_seq=390 ttl=64 time=1.70 ms 1500 bytes from othermachine (10.0.0.2): icmp_seq=391 ttl=64 time=1.70 ms 1500 bytes from othermachine (10.0.0.2): icmp_seq=392 ttl=64 time=1.73 ms 1500 bytes from othermachine (10.0.0.2): icmp_seq=393 ttl=64 time=1.69 ms 1500 bytes from othermachine (10.0.0.2): icmp_seq=394 ttl=64 time=1.74 ms 1500 bytes from othermachine (10.0.0.2): icmp_seq=395 ttl=64 time=1.75 ms 1500 bytes from othermachine (10.0.0.2): icmp_seq=396 ttl=64 time=0.749 ms 1500 bytes from othermachine (10.0.0.2): icmp_seq=397 ttl=64 time=0.777 ms 1500 bytes from othermachine (10.0.0.2): icmp_seq=398 ttl=64 time=0.779 ms 1500 bytes from othermachine (10.0.0.2): icmp_seq=399 ttl=64 time=0.782 ms 1500 bytes from othermachine (10.0.0.2): icmp_seq=400 ttl=64 time=0.791 ms 1500 bytes from othermachine (10.0.0.2): icmp_seq=401 ttl=64 time=0.800 ms 1500 bytes from othermachine (10.0.0.2): icmp_seq=402 ttl=64 time=0.806 ms 1500 bytes from othermachine (10.0.0.2): icmp_seq=403 ttl=64 time=0.814 ms 1500 bytes from othermachine (10.0.0.2): icmp_seq=404 ttl=64 time=0.818 ms 1500 bytes from othermachine (10.0.0.2): icmp_seq=405 ttl=64 time=0.824 ms 1500 bytes from othermachine (10.0.0.2): icmp_seq=406 ttl=64 time=0.826 ms 1500 bytes from othermachine (10.0.0.2): icmp_seq=407 ttl=64 time=0.939 ms 1500 bytes from othermachine (10.0.0.2): icmp_seq=408 ttl=64 time=0.850 ms 1500 bytes from othermachine (10.0.0.2): icmp_seq=409 ttl=64 time=0.825 ms 1500 bytes from othermachine (10.0.0.2): icmp_seq=410 ttl=64 time=0.836 ms 1500 bytes from othermachine (10.0.0.2): icmp_seq=411 ttl=64 time=0.863 ms 1500 bytes from othermachine (10.0.0.2): icmp_seq=412 ttl=64 time=0.842 ms 1500 bytes from othermachine (10.0.0.2): icmp_seq=413 ttl=64 time=0.879 ms 1500 bytes from othermachine (10.0.0.2): icmp_seq=414 ttl=64 time=0.888 ms 1500 bytes from othermachine (10.0.0.2): icmp_seq=415 ttl=64 time=0.898 ms 1500 bytes from othermachine (10.0.0.2): icmp_seq=416 ttl=64 time=0.908 ms 1500 bytes from othermachine (10.0.0.2): icmp_seq=417 ttl=64 time=0.763 ms 1500 bytes from othermachine (10.0.0.2): icmp_seq=418 ttl=64 time=0.921 ms 1500 bytes from othermachine (10.0.0.2): icmp_seq=419 ttl=64 time=0.912 ms 1500 bytes from othermachine (10.0.0.2): icmp_seq=420 ttl=64 time=0.935 ms 1500 bytes from othermachine (10.0.0.2): icmp_seq=421 ttl=64 time=0.926 ms 1500 bytes from othermachine (10.0.0.2): icmp_seq=422 ttl=64 time=0.927 ms 1500 bytes from othermachine (10.0.0.2): icmp_seq=423 ttl=64 time=0.902 ms 1500 bytes from othermachine (10.0.0.2): icmp_seq=424 ttl=64 time=0.957 ms 1500 bytes from othermachine (10.0.0.2): icmp_seq=425 ttl=64 time=0.964 ms 1500 bytes from othermachine (10.0.0.2): icmp_seq=426 ttl=64 time=0.947 ms 1500 bytes from othermachine (10.0.0.2): icmp_seq=427 ttl=64 time=0.980 ms 1500 bytes from othermachine (10.0.0.2): icmp_seq=428 ttl=64 time=0.996 ms 1500 bytes from othermachine (10.0.0.2): icmp_seq=429 ttl=64 time=0.995 ms 1500 bytes from othermachine (10.0.0.2): icmp_seq=430 ttl=64 time=0.993 ms 1500 bytes from othermachine (10.0.0.2): icmp_seq=431 ttl=64 time=0.998 ms 1500 bytes from othermachine (10.0.0.2): icmp_seq=432 ttl=64 time=0.991 ms 1500 bytes from othermachine (10.0.0.2): icmp_seq=433 ttl=64 time=0.992 ms 1500 bytes from othermachine (10.0.0.2): icmp_seq=434 ttl=64 time=0.998 ms 1500 bytes from othermachine (10.0.0.2): icmp_seq=435 ttl=64 time=0.999 ms 1500 bytes from othermachine (10.0.0.2): icmp_seq=436 ttl=64 time=1.00 ms 1500 bytes from othermachine (10.0.0.2): icmp_seq=437 ttl=64 time=0.998 ms 1500 bytes from othermachine (10.0.0.2): icmp_seq=438 ttl=64 time=1.01 ms 1500 bytes from othermachine (10.0.0.2): icmp_seq=439 ttl=64 time=0.991 ms 1500 bytes from othermachine (10.0.0.2): icmp_seq=440 ttl=64 time=1.01 ms 1500 bytes from othermachine (10.0.0.2): icmp_seq=441 ttl=64 time=1.07 ms 1500 bytes from othermachine (10.0.0.2): icmp_seq=442 ttl=64 time=1.09 ms 1500 bytes from othermachine (10.0.0.2): icmp_seq=443 ttl=64 time=1.09 ms 1500 bytes from othermachine (10.0.0.2): icmp_seq=444 ttl=64 time=1.09 ms 1500 bytes from othermachine (10.0.0.2): icmp_seq=445 ttl=64 time=1.09 ms 1500 bytes from othermachine (10.0.0.2): icmp_seq=446 ttl=64 time=1.10 ms 1500 bytes from othermachine (10.0.0.2): icmp_seq=447 ttl=64 time=1.11 ms 1500 bytes from othermachine (10.0.0.2): icmp_seq=448 ttl=64 time=1.14 ms 1500 bytes from othermachine (10.0.0.2): icmp_seq=449 ttl=64 time=1.13 ms 1500 bytes from othermachine (10.0.0.2): icmp_seq=450 ttl=64 time=1.71 ms 1500 bytes from othermachine (10.0.0.2): icmp_seq=451 ttl=64 time=1.23 ms 1500 bytes from othermachine (10.0.0.2): icmp_seq=452 ttl=64 time=1.17 ms 1500 bytes from othermachine (10.0.0.2): icmp_seq=453 ttl=64 time=1.15 ms 1500 bytes from othermachine (10.0.0.2): icmp_seq=454 ttl=64 time=1.17 ms 1500 bytes from othermachine (10.0.0.2): icmp_seq=455 ttl=64 time=1.17 ms 1500 bytes from othermachine (10.0.0.2): icmp_seq=456 ttl=64 time=1.19 ms 1500 bytes from othermachine (10.0.0.2): icmp_seq=457 ttl=64 time=1.18 ms 1500 bytes from othermachine (10.0.0.2): icmp_seq=458 ttl=64 time=1.19 ms 1500 bytes from othermachine (10.0.0.2): icmp_seq=459 ttl=64 time=1.19 ms 1500 bytes from othermachine (10.0.0.2): icmp_seq=460 ttl=64 time=1.20 ms 1500 bytes from othermachine (10.0.0.2): icmp_seq=461 ttl=64 time=1.22 ms 1500 bytes from othermachine (10.0.0.2): icmp_seq=462 ttl=64 time=1.22 ms 1500 bytes from othermachine (10.0.0.2): icmp_seq=463 ttl=64 time=1.22 ms 1500 bytes from othermachine (10.0.0.2): icmp_seq=464 ttl=64 time=1.19 ms 1500 bytes from othermachine (10.0.0.2): icmp_seq=465 ttl=64 time=1.23 ms 1500 bytes from othermachine (10.0.0.2): icmp_seq=466 ttl=64 time=1.26 ms 1500 bytes from othermachine (10.0.0.2): icmp_seq=467 ttl=64 time=1.26 ms 1500 bytes from othermachine (10.0.0.2): icmp_seq=468 ttl=64 time=1.26 ms 1500 bytes from othermachine (10.0.0.2): icmp_seq=469 ttl=64 time=1.26 ms 1500 bytes from othermachine (10.0.0.2): icmp_seq=470 ttl=64 time=1.27 ms 1500 bytes from othermachine (10.0.0.2): icmp_seq=471 ttl=64 time=1.30 ms 1500 bytes from othermachine (10.0.0.2): icmp_seq=472 ttl=64 time=1.28 ms 1500 bytes from othermachine (10.0.0.2): icmp_seq=473 ttl=64 time=1.26 ms 1500 bytes from othermachine (10.0.0.2): icmp_seq=474 ttl=64 time=1.30 ms 1500 bytes from othermachine (10.0.0.2): icmp_seq=475 ttl=64 time=1.30 ms 1500 bytes from othermachine (10.0.0.2): icmp_seq=476 ttl=64 time=1.31 ms 1500 bytes from othermachine (10.0.0.2): icmp_seq=477 ttl=64 time=1.32 ms 1500 bytes from othermachine (10.0.0.2): icmp_seq=478 ttl=64 time=1.33 ms 1500 bytes from othermachine (10.0.0.2): icmp_seq=479 ttl=64 time=1.32 ms 1500 bytes from othermachine (10.0.0.2): icmp_seq=480 ttl=64 time=1.34 ms 1500 bytes from othermachine (10.0.0.2): icmp_seq=481 ttl=64 time=1.34 ms 1500 bytes from othermachine (10.0.0.2): icmp_seq=482 ttl=64 time=1.37 ms 1500 bytes from othermachine (10.0.0.2): icmp_seq=483 ttl=64 time=1.36 ms 1500 bytes from othermachine (10.0.0.2): icmp_seq=484 ttl=64 time=1.36 ms 1500 bytes from othermachine (10.0.0.2): icmp_seq=485 ttl=64 time=1.37 ms 1500 bytes from othermachine (10.0.0.2): icmp_seq=486 ttl=64 time=1.38 ms 1500 bytes from othermachine (10.0.0.2): icmp_seq=487 ttl=64 time=1.39 ms 1500 bytes from othermachine (10.0.0.2): icmp_seq=488 ttl=64 time=1.39 ms 1500 bytes from othermachine (10.0.0.2): icmp_seq=489 ttl=64 time=1.40 ms 1500 bytes from othermachine (10.0.0.2): icmp_seq=490 ttl=64 time=1.41 ms 1500 bytes from othermachine (10.0.0.2): icmp_seq=491 ttl=64 time=1.42 ms 1500 bytes from othermachine (10.0.0.2): icmp_seq=492 ttl=64 time=1.42 ms 1500 bytes from othermachine (10.0.0.2): icmp_seq=493 ttl=64 time=1.43 ms 1500 bytes from othermachine (10.0.0.2): icmp_seq=494 ttl=64 time=1.43 ms 1500 bytes from othermachine (10.0.0.2): icmp_seq=495 ttl=64 time=1.44 ms 1500 bytes from othermachine (10.0.0.2): icmp_seq=496 ttl=64 time=1.27 ms 1500 bytes from othermachine (10.0.0.2): icmp_seq=497 ttl=64 time=1.46 ms 1500 bytes from othermachine (10.0.0.2): icmp_seq=498 ttl=64 time=1.46 ms 1500 bytes from othermachine (10.0.0.2): icmp_seq=499 ttl=64 time=1.48 ms 1500 bytes from othermachine (10.0.0.2): icmp_seq=500 ttl=64 time=1.48 ms 1500 bytes from othermachine (10.0.0.2): icmp_seq=501 ttl=64 time=1.46 ms 1500 bytes from othermachine (10.0.0.2): icmp_seq=502 ttl=64 time=1.49 ms 1500 bytes from othermachine (10.0.0.2): icmp_seq=503 ttl=64 time=1.50 ms 1500 bytes from othermachine (10.0.0.2): icmp_seq=504 ttl=64 time=1.50 ms 1500 bytes from othermachine (10.0.0.2): icmp_seq=505 ttl=64 time=1.52 ms 1500 bytes from othermachine (10.0.0.2): icmp_seq=506 ttl=64 time=1.52 ms 1500 bytes from othermachine (10.0.0.2): icmp_seq=507 ttl=64 time=1.53 ms 1500 bytes from othermachine (10.0.0.2): icmp_seq=508 ttl=64 time=1.53 ms 1500 bytes from othermachine (10.0.0.2): icmp_seq=509 ttl=64 time=1.53 ms 1500 bytes from othermachine (10.0.0.2): icmp_seq=510 ttl=64 time=1.57 ms 1500 bytes from othermachine (10.0.0.2): icmp_seq=511 ttl=64 time=1.55 ms 1500 bytes from othermachine (10.0.0.2): icmp_seq=512 ttl=64 time=1.56 ms 1500 bytes from othermachine (10.0.0.2): icmp_seq=513 ttl=64 time=1.57 ms 1500 bytes from othermachine (10.0.0.2): icmp_seq=514 ttl=64 time=1.58 ms 1500 bytes from othermachine (10.0.0.2): icmp_seq=515 ttl=64 time=1.59 ms 1500 bytes from othermachine (10.0.0.2): icmp_seq=516 ttl=64 time=1.59 ms 1500 bytes from othermachine (10.0.0.2): icmp_seq=517 ttl=64 time=1.60 ms 1500 bytes from othermachine (10.0.0.2): icmp_seq=518 ttl=64 time=1.61 ms 1500 bytes from othermachine (10.0.0.2): icmp_seq=519 ttl=64 time=1.61 ms 1500 bytes from othermachine (10.0.0.2): icmp_seq=520 ttl=64 time=1.63 ms 1500 bytes from othermachine (10.0.0.2): icmp_seq=521 ttl=64 time=1.62 ms 1500 bytes from othermachine (10.0.0.2): icmp_seq=522 ttl=64 time=1.63 ms 1500 bytes from othermachine (10.0.0.2): icmp_seq=523 ttl=64 time=1.64 ms 1500 bytes from othermachine (10.0.0.2): icmp_seq=524 ttl=64 time=1.65 ms 1500 bytes from othermachine (10.0.0.2): icmp_seq=525 ttl=64 time=1.67 ms 1500 bytes from othermachine (10.0.0.2): icmp_seq=526 ttl=64 time=1.66 ms 1500 bytes from othermachine (10.0.0.2): icmp_seq=527 ttl=64 time=1.67 ms 1500 bytes from othermachine (10.0.0.2): icmp_seq=528 ttl=64 time=1.68 ms 1500 bytes from othermachine (10.0.0.2): icmp_seq=529 ttl=64 time=1.68 ms 1500 bytes from othermachine (10.0.0.2): icmp_seq=530 ttl=64 time=1.69 ms 1500 bytes from othermachine (10.0.0.2): icmp_seq=531 ttl=64 time=1.74 ms 1500 bytes from othermachine (10.0.0.2): icmp_seq=532 ttl=64 time=1.70 ms 1500 bytes from othermachine (10.0.0.2): icmp_seq=533 ttl=64 time=1.71 ms 1500 bytes from othermachine (10.0.0.2): icmp_seq=534 ttl=64 time=1.72 ms 1500 bytes from othermachine (10.0.0.2): icmp_seq=535 ttl=64 time=0.732 ms 1500 bytes from othermachine (10.0.0.2): icmp_seq=536 ttl=64 time=0.739 ms 1500 bytes from othermachine (10.0.0.2): icmp_seq=537 ttl=64 time=0.749 ms 1500 bytes from othermachine (10.0.0.2): icmp_seq=538 ttl=64 time=0.756 ms 1500 bytes from othermachine (10.0.0.2): icmp_seq=539 ttl=64 time=1.75 ms 1500 bytes from othermachine (10.0.0.2): icmp_seq=540 ttl=64 time=0.788 ms 1500 bytes from othermachine (10.0.0.2): icmp_seq=541 ttl=64 time=0.783 ms 1500 bytes from othermachine (10.0.0.2): icmp_seq=542 ttl=64 time=0.789 ms 1500 bytes from othermachine (10.0.0.2): icmp_seq=543 ttl=64 time=0.793 ms 1500 bytes from othermachine (10.0.0.2): icmp_seq=544 ttl=64 time=0.795 ms 1500 bytes from othermachine (10.0.0.2): icmp_seq=545 ttl=64 time=0.968 ms 1500 bytes from othermachine (10.0.0.2): icmp_seq=546 ttl=64 time=0.810 ms 1500 bytes from othermachine (10.0.0.2): icmp_seq=547 ttl=64 time=0.813 ms 1500 bytes from othermachine (10.0.0.2): icmp_seq=548 ttl=64 time=0.823 ms 1500 bytes from othermachine (10.0.0.2): icmp_seq=549 ttl=64 time=0.827 ms 1500 bytes from othermachine (10.0.0.2): icmp_seq=550 ttl=64 time=0.834 ms 1500 bytes from othermachine (10.0.0.2): icmp_seq=551 ttl=64 time=0.846 ms 1500 bytes from othermachine (10.0.0.2): icmp_seq=552 ttl=64 time=0.852 ms 1500 bytes from othermachine (10.0.0.2): icmp_seq=553 ttl=64 time=0.859 ms 1500 bytes from othermachine (10.0.0.2): icmp_seq=554 ttl=64 time=0.866 ms 1500 bytes from othermachine (10.0.0.2): icmp_seq=555 ttl=64 time=0.867 ms 1500 bytes from othermachine (10.0.0.2): icmp_seq=556 ttl=64 time=0.937 ms 1500 bytes from othermachine (10.0.0.2): icmp_seq=557 ttl=64 time=0.886 ms 1500 bytes from othermachine (10.0.0.2): icmp_seq=558 ttl=64 time=0.892 ms 1500 bytes from othermachine (10.0.0.2): icmp_seq=559 ttl=64 time=0.901 ms 1500 bytes from othermachine (10.0.0.2): icmp_seq=560 ttl=64 time=0.909 ms 1500 bytes from othermachine (10.0.0.2): icmp_seq=561 ttl=64 time=0.916 ms 1500 bytes from othermachine (10.0.0.2): icmp_seq=562 ttl=64 time=0.924 ms 1500 bytes from othermachine (10.0.0.2): icmp_seq=563 ttl=64 time=0.938 ms 1500 bytes from othermachine (10.0.0.2): icmp_seq=564 ttl=64 time=0.934 ms 1500 bytes from othermachine (10.0.0.2): icmp_seq=565 ttl=64 time=0.942 ms 1500 bytes from othermachine (10.0.0.2): icmp_seq=566 ttl=64 time=0.963 ms 1500 bytes from othermachine (10.0.0.2): icmp_seq=567 ttl=64 time=0.956 ms 1500 bytes from othermachine (10.0.0.2): icmp_seq=568 ttl=64 time=0.965 ms 1500 bytes from othermachine (10.0.0.2): icmp_seq=569 ttl=64 time=0.969 ms 1500 bytes from othermachine (10.0.0.2): icmp_seq=570 ttl=64 time=0.979 ms 1500 bytes from othermachine (10.0.0.2): icmp_seq=571 ttl=64 time=0.985 ms 1500 bytes from othermachine (10.0.0.2): icmp_seq=572 ttl=64 time=0.995 ms 1500 bytes from othermachine (10.0.0.2): icmp_seq=573 ttl=64 time=1.03 ms 1500 bytes from othermachine (10.0.0.2): icmp_seq=574 ttl=64 time=0.998 ms 1500 bytes from othermachine (10.0.0.2): icmp_seq=575 ttl=64 time=1.52 ms 1500 bytes from othermachine (10.0.0.2): icmp_seq=576 ttl=64 time=0.972 ms 1500 bytes from othermachine (10.0.0.2): icmp_seq=577 ttl=64 time=1.00 ms 1500 bytes from othermachine (10.0.0.2): icmp_seq=578 ttl=64 time=0.999 ms 1500 bytes from othermachine (10.0.0.2): icmp_seq=579 ttl=64 time=1.00 ms 1500 bytes from othermachine (10.0.0.2): icmp_seq=580 ttl=64 time=0.982 ms 1500 bytes from othermachine (10.0.0.2): icmp_seq=581 ttl=64 time=1.00 ms 1500 bytes from othermachine (10.0.0.2): icmp_seq=582 ttl=64 time=0.997 ms 1500 bytes from othermachine (10.0.0.2): icmp_seq=583 ttl=64 time=1.00 ms 1500 bytes from othermachine (10.0.0.2): icmp_seq=584 ttl=64 time=1.02 ms 1500 bytes from othermachine (10.0.0.2): icmp_seq=585 ttl=64 time=1.08 ms 1500 bytes from othermachine (10.0.0.2): icmp_seq=586 ttl=64 time=1.11 ms 1500 bytes from othermachine (10.0.0.2): icmp_seq=587 ttl=64 time=1.09 ms 1500 bytes from othermachine (10.0.0.2): icmp_seq=588 ttl=64 time=1.10 ms 1500 bytes from othermachine (10.0.0.2): icmp_seq=589 ttl=64 time=1.10 ms 1500 bytes from othermachine (10.0.0.2): icmp_seq=590 ttl=64 time=1.08 ms 1500 bytes from othermachine (10.0.0.2): icmp_seq=591 ttl=64 time=1.11 ms 1500 bytes from othermachine (10.0.0.2): icmp_seq=592 ttl=64 time=1.12 ms 1500 bytes from othermachine (10.0.0.2): icmp_seq=593 ttl=64 time=1.13 ms 1500 bytes from othermachine (10.0.0.2): icmp_seq=594 ttl=64 time=1.14 ms 1500 bytes from othermachine (10.0.0.2): icmp_seq=595 ttl=64 time=1.14 ms 1500 bytes from othermachine (10.0.0.2): icmp_seq=596 ttl=64 time=0.968 ms 1500 bytes from othermachine (10.0.0.2): icmp_seq=597 ttl=64 time=1.15 ms 1500 bytes from othermachine (10.0.0.2): icmp_seq=598 ttl=64 time=1.16 ms 1500 bytes from othermachine (10.0.0.2): icmp_seq=599 ttl=64 time=1.17 ms 1500 bytes from othermachine (10.0.0.2): icmp_seq=600 ttl=64 time=1.21 ms 1500 bytes from othermachine (10.0.0.2): icmp_seq=601 ttl=64 time=1.18 ms 1500 bytes from othermachine (10.0.0.2): icmp_seq=602 ttl=64 time=1.19 ms 1500 bytes from othermachine (10.0.0.2): icmp_seq=603 ttl=64 time=0.963 ms 1500 bytes from othermachine (10.0.0.2): icmp_seq=604 ttl=64 time=1.20 ms 1500 bytes from othermachine (10.0.0.2): icmp_seq=605 ttl=64 time=1.21 ms 1500 bytes from othermachine (10.0.0.2): icmp_seq=606 ttl=64 time=1.22 ms 1500 bytes from othermachine (10.0.0.2): icmp_seq=607 ttl=64 time=1.22 ms 1500 bytes from othermachine (10.0.0.2): icmp_seq=608 ttl=64 time=1.23 ms 1500 bytes from othermachine (10.0.0.2): icmp_seq=609 ttl=64 time=1.24 ms 1500 bytes from othermachine (10.0.0.2): icmp_seq=610 ttl=64 time=1.24 ms 1500 bytes from othermachine (10.0.0.2): icmp_seq=611 ttl=64 time=1.25 ms 1500 bytes from othermachine (10.0.0.2): icmp_seq=612 ttl=64 time=1.26 ms 1500 bytes from othermachine (10.0.0.2): icmp_seq=613 ttl=64 time=1.26 ms 1500 bytes from othermachine (10.0.0.2): icmp_seq=614 ttl=64 time=1.27 ms 1500 bytes from othermachine (10.0.0.2): icmp_seq=615 ttl=64 time=1.28 ms 1500 bytes from othermachine (10.0.0.2): icmp_seq=616 ttl=64 time=1.29 ms 1500 bytes from othermachine (10.0.0.2): icmp_seq=617 ttl=64 time=1.30 ms 1500 bytes from othermachine (10.0.0.2): icmp_seq=618 ttl=64 time=1.30 ms 1500 bytes from othermachine (10.0.0.2): icmp_seq=619 ttl=64 time=1.31 ms 1500 bytes from othermachine (10.0.0.2): icmp_seq=620 ttl=64 time=1.32 ms 1500 bytes from othermachine (10.0.0.2): icmp_seq=621 ttl=64 time=1.32 ms 1500 bytes from othermachine (10.0.0.2): icmp_seq=622 ttl=64 time=1.32 ms 1500 bytes from othermachine (10.0.0.2): icmp_seq=623 ttl=64 time=1.34 ms 1500 bytes from othermachine (10.0.0.2): icmp_seq=624 ttl=64 time=1.34 ms 1500 bytes from othermachine (10.0.0.2): icmp_seq=625 ttl=64 time=1.35 ms 1500 bytes from othermachine (10.0.0.2): icmp_seq=626 ttl=64 time=1.41 ms 1500 bytes from othermachine (10.0.0.2): icmp_seq=627 ttl=64 time=1.36 ms 1500 bytes from othermachine (10.0.0.2): icmp_seq=628 ttl=64 time=1.36 ms 1500 bytes from othermachine (10.0.0.2): icmp_seq=629 ttl=64 time=1.37 ms 1500 bytes from othermachine (10.0.0.2): icmp_seq=630 ttl=64 time=1.35 ms 1500 bytes from othermachine (10.0.0.2): icmp_seq=631 ttl=64 time=1.38 ms 1500 bytes from othermachine (10.0.0.2): icmp_seq=632 ttl=64 time=1.40 ms 1500 bytes from othermachine (10.0.0.2): icmp_seq=633 ttl=64 time=1.40 ms 1500 bytes from othermachine (10.0.0.2): icmp_seq=634 ttl=64 time=1.41 ms 1500 bytes from othermachine (10.0.0.2): icmp_seq=635 ttl=64 time=1.41 ms 1500 bytes from othermachine (10.0.0.2): icmp_seq=636 ttl=64 time=1.42 ms 1500 bytes from othermachine (10.0.0.2): icmp_seq=637 ttl=64 time=1.43 ms 1500 bytes from othermachine (10.0.0.2): icmp_seq=638 ttl=64 time=1.44 ms 1500 bytes from othermachine (10.0.0.2): icmp_seq=639 ttl=64 time=1.45 ms 1500 bytes from othermachine (10.0.0.2): icmp_seq=640 ttl=64 time=1.45 ms 1500 bytes from othermachine (10.0.0.2): icmp_seq=641 ttl=64 time=1.46 ms 1500 bytes from othermachine (10.0.0.2): icmp_seq=642 ttl=64 time=1.46 ms 1500 bytes from othermachine (10.0.0.2): icmp_seq=643 ttl=64 time=1.47 ms 1500 bytes from othermachine (10.0.0.2): icmp_seq=644 ttl=64 time=1.48 ms 1500 bytes from othermachine (10.0.0.2): icmp_seq=645 ttl=64 time=1.49 ms 1500 bytes from othermachine (10.0.0.2): icmp_seq=646 ttl=64 time=1.49 ms 1500 bytes from othermachine (10.0.0.2): icmp_seq=647 ttl=64 time=1.50 ms 1500 bytes from othermachine (10.0.0.2): icmp_seq=648 ttl=64 time=1.51 ms 1500 bytes from othermachine (10.0.0.2): icmp_seq=649 ttl=64 time=1.52 ms 1500 bytes from othermachine (10.0.0.2): icmp_seq=650 ttl=64 time=1.52 ms 1500 bytes from othermachine (10.0.0.2): icmp_seq=651 ttl=64 time=1.53 ms 1500 bytes from othermachine (10.0.0.2): icmp_seq=652 ttl=64 time=1.54 ms 1500 bytes from othermachine (10.0.0.2): icmp_seq=653 ttl=64 time=1.54 ms 1500 bytes from othermachine (10.0.0.2): icmp_seq=654 ttl=64 time=1.55 ms 1500 bytes from othermachine (10.0.0.2): icmp_seq=655 ttl=64 time=1.58 ms 1500 bytes from othermachine (10.0.0.2): icmp_seq=656 ttl=64 time=1.56 ms 1500 bytes from othermachine (10.0.0.2): icmp_seq=657 ttl=64 time=1.56 ms 1500 bytes from othermachine (10.0.0.2): icmp_seq=658 ttl=64 time=1.58 ms 1500 bytes from othermachine (10.0.0.2): icmp_seq=659 ttl=64 time=1.58 ms 1500 bytes from othermachine (10.0.0.2): icmp_seq=660 ttl=64 time=1.59 ms 1500 bytes from othermachine (10.0.0.2): icmp_seq=661 ttl=64 time=1.59 ms 1500 bytes from othermachine (10.0.0.2): icmp_seq=662 ttl=64 time=1.61 ms 1500 bytes from othermachine (10.0.0.2): icmp_seq=663 ttl=64 time=1.61 ms 1500 bytes from othermachine (10.0.0.2): icmp_seq=664 ttl=64 time=1.62 ms 1500 bytes from othermachine (10.0.0.2): icmp_seq=665 ttl=64 time=1.63 ms 1500 bytes from othermachine (10.0.0.2): icmp_seq=666 ttl=64 time=1.63 ms 1500 bytes from othermachine (10.0.0.2): icmp_seq=667 ttl=64 time=1.64 ms 1500 bytes from othermachine (10.0.0.2): icmp_seq=668 ttl=64 time=1.65 ms 1500 bytes from othermachine (10.0.0.2): icmp_seq=669 ttl=64 time=1.65 ms 1500 bytes from othermachine (10.0.0.2): icmp_seq=670 ttl=64 time=1.66 ms 1500 bytes from othermachine (10.0.0.2): icmp_seq=671 ttl=64 time=1.68 ms 1500 bytes from othermachine (10.0.0.2): icmp_seq=672 ttl=64 time=1.67 ms 1500 bytes from othermachine (10.0.0.2): icmp_seq=673 ttl=64 time=1.68 ms 1500 bytes from othermachine (10.0.0.2): icmp_seq=674 ttl=64 time=1.69 ms 1500 bytes from othermachine (10.0.0.2): icmp_seq=675 ttl=64 time=1.70 ms 1500 bytes from othermachine (10.0.0.2): icmp_seq=676 ttl=64 time=0.711 ms 1500 bytes from othermachine (10.0.0.2): icmp_seq=677 ttl=64 time=1.71 ms 1500 bytes from othermachine (10.0.0.2): icmp_seq=678 ttl=64 time=0.729 ms 1500 bytes from othermachine (10.0.0.2): icmp_seq=679 ttl=64 time=0.734 ms 1500 bytes from othermachine (10.0.0.2): icmp_seq=680 ttl=64 time=1.73 ms 1500 bytes from othermachine (10.0.0.2): icmp_seq=681 ttl=64 time=1.74 ms 1500 bytes from othermachine (10.0.0.2): icmp_seq=682 ttl=64 time=0.750 ms 1500 bytes from othermachine (10.0.0.2): icmp_seq=683 ttl=64 time=0.755 ms 1500 bytes from othermachine (10.0.0.2): icmp_seq=684 ttl=64 time=0.770 ms 1500 bytes from othermachine (10.0.0.2): icmp_seq=685 ttl=64 time=0.772 ms 1500 bytes from othermachine (10.0.0.2): icmp_seq=686 ttl=64 time=0.782 ms 1500 bytes from othermachine (10.0.0.2): icmp_seq=687 ttl=64 time=0.791 ms 1500 bytes from othermachine (10.0.0.2): icmp_seq=688 ttl=64 time=0.799 ms 1500 bytes from othermachine (10.0.0.2): icmp_seq=689 ttl=64 time=0.802 ms 1500 bytes from othermachine (10.0.0.2): icmp_seq=690 ttl=64 time=0.808 ms 1500 bytes from othermachine (10.0.0.2): icmp_seq=691 ttl=64 time=0.818 ms 1500 bytes from othermachine (10.0.0.2): icmp_seq=692 ttl=64 time=0.823 ms 1500 bytes from othermachine (10.0.0.2): icmp_seq=693 ttl=64 time=0.832 ms 1500 bytes from othermachine (10.0.0.2): icmp_seq=694 ttl=64 time=0.838 ms 1500 bytes from othermachine (10.0.0.2): icmp_seq=695 ttl=64 time=0.906 ms 1500 bytes from othermachine (10.0.0.2): icmp_seq=696 ttl=64 time=0.854 ms 1500 bytes from othermachine (10.0.0.2): icmp_seq=697 ttl=64 time=0.857 ms 1500 bytes from othermachine (10.0.0.2): icmp_seq=698 ttl=64 time=0.861 ms 1500 bytes from othermachine (10.0.0.2): icmp_seq=699 ttl=64 time=0.871 ms 1500 bytes from othermachine (10.0.0.2): icmp_seq=700 ttl=64 time=0.879 ms 1500 bytes from othermachine (10.0.0.2): icmp_seq=701 ttl=64 time=0.886 ms 1500 bytes from othermachine (10.0.0.2): icmp_seq=702 ttl=64 time=0.894 ms 1500 bytes from othermachine (10.0.0.2): icmp_seq=703 ttl=64 time=0.901 ms 1500 bytes from othermachine (10.0.0.2): icmp_seq=704 ttl=64 time=0.946 ms 1500 bytes from othermachine (10.0.0.2): icmp_seq=705 ttl=64 time=0.912 ms 1500 bytes from othermachine (10.0.0.2): icmp_seq=706 ttl=64 time=0.927 ms 1500 bytes from othermachine (10.0.0.2): icmp_seq=707 ttl=64 time=0.929 ms 1500 bytes from othermachine (10.0.0.2): icmp_seq=708 ttl=64 time=0.880 ms 1500 bytes from othermachine (10.0.0.2): icmp_seq=709 ttl=64 time=0.943 ms 1500 bytes from othermachine (10.0.0.2): icmp_seq=710 ttl=64 time=0.950 ms 1500 bytes from othermachine (10.0.0.2): icmp_seq=711 ttl=64 time=0.955 ms 1500 bytes from othermachine (10.0.0.2): icmp_seq=712 ttl=64 time=0.961 ms 1500 bytes from othermachine (10.0.0.2): icmp_seq=713 ttl=64 time=0.973 ms 1500 bytes from othermachine (10.0.0.2): icmp_seq=714 ttl=64 time=0.977 ms 1500 bytes from othermachine (10.0.0.2): icmp_seq=715 ttl=64 time=0.989 ms 1500 bytes from othermachine (10.0.0.2): icmp_seq=716 ttl=64 time=0.997 ms 1500 bytes from othermachine (10.0.0.2): icmp_seq=717 ttl=64 time=0.998 ms 1500 bytes from othermachine (10.0.0.2): icmp_seq=718 ttl=64 time=0.984 ms 1500 bytes from othermachine (10.0.0.2): icmp_seq=719 ttl=64 time=0.995 ms 1500 bytes from othermachine (10.0.0.2): icmp_seq=720 ttl=64 time=1.00 ms 1500 bytes from othermachine (10.0.0.2): icmp_seq=721 ttl=64 time=0.999 ms 1500 bytes from othermachine (10.0.0.2): icmp_seq=722 ttl=64 time=1.60 ms 1500 bytes from othermachine (10.0.0.2): icmp_seq=723 ttl=64 time=0.998 ms 1500 bytes from othermachine (10.0.0.2): icmp_seq=724 ttl=64 time=1.00 ms 1500 bytes from othermachine (10.0.0.2): icmp_seq=725 ttl=64 time=0.997 ms 1500 bytes from othermachine (10.0.0.2): icmp_seq=726 ttl=64 time=1.00 ms 1500 bytes from othermachine (10.0.0.2): icmp_seq=727 ttl=64 time=1.04 ms 1500 bytes from othermachine (10.0.0.2): icmp_seq=728 ttl=64 time=1.02 ms 1500 bytes from othermachine (10.0.0.2): icmp_seq=729 ttl=64 time=1.08 ms 1500 bytes from othermachine (10.0.0.2): icmp_seq=730 ttl=64 time=0.939 ms 1500 bytes from othermachine (10.0.0.2): icmp_seq=731 ttl=64 time=1.08 ms 1500 bytes from othermachine (10.0.0.2): icmp_seq=732 ttl=64 time=1.09 ms 1500 bytes from othermachine (10.0.0.2): icmp_seq=733 ttl=64 time=1.10 ms 1500 bytes from othermachine (10.0.0.2): icmp_seq=734 ttl=64 time=1.11 ms 1500 bytes from othermachine (10.0.0.2): icmp_seq=735 ttl=64 time=1.14 ms 1500 bytes from othermachine (10.0.0.2): icmp_seq=736 ttl=64 time=1.12 ms 1500 bytes from othermachine (10.0.0.2): icmp_seq=737 ttl=64 time=1.14 ms 1500 bytes from othermachine (10.0.0.2): icmp_seq=738 ttl=64 time=1.13 ms 1500 bytes from othermachine (10.0.0.2): icmp_seq=739 ttl=64 time=1.16 ms 1500 bytes from othermachine (10.0.0.2): icmp_seq=740 ttl=64 time=1.15 ms 1500 bytes from othermachine (10.0.0.2): icmp_seq=741 ttl=64 time=1.16 ms 1500 bytes from othermachine (10.0.0.2): icmp_seq=742 ttl=64 time=1.16 ms 1500 bytes from othermachine (10.0.0.2): icmp_seq=743 ttl=64 time=1.17 ms 1500 bytes from othermachine (10.0.0.2): icmp_seq=744 ttl=64 time=1.17 ms 1500 bytes from othermachine (10.0.0.2): icmp_seq=745 ttl=64 time=1.18 ms 1500 bytes from othermachine (10.0.0.2): icmp_seq=746 ttl=64 time=1.19 ms 1500 bytes from othermachine (10.0.0.2): icmp_seq=747 ttl=64 time=1.20 ms 1500 bytes from othermachine (10.0.0.2): icmp_seq=748 ttl=64 time=1.20 ms 1500 bytes from othermachine (10.0.0.2): icmp_seq=749 ttl=64 time=1.21 ms 1500 bytes from othermachine (10.0.0.2): icmp_seq=750 ttl=64 time=1.22 ms 1500 bytes from othermachine (10.0.0.2): icmp_seq=751 ttl=64 time=1.22 ms 1500 bytes from othermachine (10.0.0.2): icmp_seq=752 ttl=64 time=1.23 ms 1500 bytes from othermachine (10.0.0.2): icmp_seq=753 ttl=64 time=1.24 ms 1500 bytes from othermachine (10.0.0.2): icmp_seq=754 ttl=64 time=1.25 ms 1500 bytes from othermachine (10.0.0.2): icmp_seq=755 ttl=64 time=1.25 ms 1500 bytes from othermachine (10.0.0.2): icmp_seq=756 ttl=64 time=1.26 ms 1500 bytes from othermachine (10.0.0.2): icmp_seq=757 ttl=64 time=1.21 ms 1500 bytes from othermachine (10.0.0.2): icmp_seq=758 ttl=64 time=1.27 ms 1500 bytes from othermachine (10.0.0.2): icmp_seq=759 ttl=64 time=1.09 ms 1500 bytes from othermachine (10.0.0.2): icmp_seq=760 ttl=64 time=1.29 ms 1500 bytes from othermachine (10.0.0.2): icmp_seq=761 ttl=64 time=1.29 ms 1500 bytes from othermachine (10.0.0.2): icmp_seq=762 ttl=64 time=1.30 ms 1500 bytes from othermachine (10.0.0.2): icmp_seq=763 ttl=64 time=1.31 ms 1500 bytes from othermachine (10.0.0.2): icmp_seq=764 ttl=64 time=1.31 ms 1500 bytes from othermachine (10.0.0.2): icmp_seq=765 ttl=64 time=1.33 ms 1500 bytes from othermachine (10.0.0.2): icmp_seq=766 ttl=64 time=1.33 ms 1500 bytes from othermachine (10.0.0.2): icmp_seq=767 ttl=64 time=1.34 ms 1500 bytes from othermachine (10.0.0.2): icmp_seq=768 ttl=64 time=1.34 ms 1500 bytes from othermachine (10.0.0.2): icmp_seq=769 ttl=64 time=1.36 ms 1500 bytes from othermachine (10.0.0.2): icmp_seq=770 ttl=64 time=1.36 ms 1500 bytes from othermachine (10.0.0.2): icmp_seq=771 ttl=64 time=1.36 ms 1500 bytes from othermachine (10.0.0.2): icmp_seq=772 ttl=64 time=1.37 ms 1500 bytes from othermachine (10.0.0.2): icmp_seq=773 ttl=64 time=1.37 ms 1500 bytes from othermachine (10.0.0.2): icmp_seq=774 ttl=64 time=1.38 ms 1500 bytes from othermachine (10.0.0.2): icmp_seq=775 ttl=64 time=1.39 ms 1500 bytes from othermachine (10.0.0.2): icmp_seq=776 ttl=64 time=1.40 ms 1500 bytes from othermachine (10.0.0.2): icmp_seq=777 ttl=64 time=1.41 ms 1500 bytes from othermachine (10.0.0.2): icmp_seq=778 ttl=64 time=1.41 ms 1500 bytes from othermachine (10.0.0.2): icmp_seq=779 ttl=64 time=1.42 ms 1500 bytes from othermachine (10.0.0.2): icmp_seq=780 ttl=64 time=1.42 ms 1500 bytes from othermachine (10.0.0.2): icmp_seq=781 ttl=64 time=1.43 ms 1500 bytes from othermachine (10.0.0.2): icmp_seq=782 ttl=64 time=1.44 ms 1500 bytes from othermachine (10.0.0.2): icmp_seq=783 ttl=64 time=1.45 ms 1500 bytes from othermachine (10.0.0.2): icmp_seq=784 ttl=64 time=1.45 ms 1500 bytes from othermachine (10.0.0.2): icmp_seq=785 ttl=64 time=1.46 ms 1500 bytes from othermachine (10.0.0.2): icmp_seq=786 ttl=64 time=1.51 ms 1500 bytes from othermachine (10.0.0.2): icmp_seq=787 ttl=64 time=1.48 ms 1500 bytes from othermachine (10.0.0.2): icmp_seq=788 ttl=64 time=1.48 ms 1500 bytes from othermachine (10.0.0.2): icmp_seq=789 ttl=64 time=1.49 ms 1500 bytes from othermachine (10.0.0.2): icmp_seq=790 ttl=64 time=1.50 ms 1500 bytes from othermachine (10.0.0.2): icmp_seq=791 ttl=64 time=1.50 ms 1500 bytes from othermachine (10.0.0.2): icmp_seq=792 ttl=64 time=1.52 ms 1500 bytes from othermachine (10.0.0.2): icmp_seq=793 ttl=64 time=1.52 ms 1500 bytes from othermachine (10.0.0.2): icmp_seq=794 ttl=64 time=1.52 ms 1500 bytes from othermachine (10.0.0.2): icmp_seq=795 ttl=64 time=1.53 ms 1500 bytes from othermachine (10.0.0.2): icmp_seq=796 ttl=64 time=1.54 ms 1500 bytes from othermachine (10.0.0.2): icmp_seq=797 ttl=64 time=1.54 ms 1500 bytes from othermachine (10.0.0.2): icmp_seq=798 ttl=64 time=1.55 ms 1500 bytes from othermachine (10.0.0.2): icmp_seq=799 ttl=64 time=1.56 ms 1500 bytes from othermachine (10.0.0.2): icmp_seq=800 ttl=64 time=1.56 ms 1500 bytes from othermachine (10.0.0.2): icmp_seq=801 ttl=64 time=1.59 ms 1500 bytes from othermachine (10.0.0.2): icmp_seq=802 ttl=64 time=1.58 ms 1500 bytes from othermachine (10.0.0.2): icmp_seq=803 ttl=64 time=1.58 ms 1500 bytes from othermachine (10.0.0.2): icmp_seq=804 ttl=64 time=1.59 ms 1500 bytes from othermachine (10.0.0.2): icmp_seq=805 ttl=64 time=1.60 ms 1500 bytes from othermachine (10.0.0.2): icmp_seq=806 ttl=64 time=1.61 ms 1500 bytes from othermachine (10.0.0.2): icmp_seq=807 ttl=64 time=1.61 ms 1500 bytes from othermachine (10.0.0.2): icmp_seq=808 ttl=64 time=1.62 ms 1500 bytes from othermachine (10.0.0.2): icmp_seq=809 ttl=64 time=1.63 ms 1500 bytes from othermachine (10.0.0.2): icmp_seq=810 ttl=64 time=1.63 ms 1500 bytes from othermachine (10.0.0.2): icmp_seq=811 ttl=64 time=1.65 ms 1500 bytes from othermachine (10.0.0.2): icmp_seq=812 ttl=64 time=1.65 ms 1500 bytes from othermachine (10.0.0.2): icmp_seq=813 ttl=64 time=1.66 ms 1500 bytes from othermachine (10.0.0.2): icmp_seq=814 ttl=64 time=1.66 ms 1500 bytes from othermachine (10.0.0.2): icmp_seq=815 ttl=64 time=1.67 ms 1500 bytes from othermachine (10.0.0.2): icmp_seq=816 ttl=64 time=1.68 ms 1500 bytes from othermachine (10.0.0.2): icmp_seq=817 ttl=64 time=1.68 ms 1500 bytes from othermachine (10.0.0.2): icmp_seq=818 ttl=64 time=1.70 ms 1500 bytes from othermachine (10.0.0.2): icmp_seq=819 ttl=64 time=1.70 ms 1500 bytes from othermachine (10.0.0.2): icmp_seq=820 ttl=64 time=1.70 ms 1500 bytes from othermachine (10.0.0.2): icmp_seq=821 ttl=64 time=1.71 ms 1500 bytes from othermachine (10.0.0.2): icmp_seq=822 ttl=64 time=0.728 ms 1500 bytes from othermachine (10.0.0.2): icmp_seq=823 ttl=64 time=0.739 ms 1500 bytes from othermachine (10.0.0.2): icmp_seq=824 ttl=64 time=1.70 ms 1500 bytes from othermachine (10.0.0.2): icmp_seq=825 ttl=64 time=1.74 ms 1500 bytes from othermachine (10.0.0.2): icmp_seq=826 ttl=64 time=0.762 ms 1500 bytes from othermachine (10.0.0.2): icmp_seq=827 ttl=64 time=1.75 ms 1500 bytes from othermachine (10.0.0.2): icmp_seq=828 ttl=64 time=0.771 ms 1500 bytes from othermachine (10.0.0.2): icmp_seq=829 ttl=64 time=0.776 ms 1500 bytes from othermachine (10.0.0.2): icmp_seq=830 ttl=64 time=0.784 ms 1500 bytes from othermachine (10.0.0.2): icmp_seq=831 ttl=64 time=0.794 ms 1500 bytes from othermachine (10.0.0.2): icmp_seq=832 ttl=64 time=0.798 ms 1500 bytes from othermachine (10.0.0.2): icmp_seq=833 ttl=64 time=0.803 ms 1500 bytes from othermachine (10.0.0.2): icmp_seq=834 ttl=64 time=0.812 ms 1500 bytes from othermachine (10.0.0.2): icmp_seq=835 ttl=64 time=0.818 ms 1500 bytes from othermachine (10.0.0.2): icmp_seq=836 ttl=64 time=0.824 ms 1500 bytes from othermachine (10.0.0.2): icmp_seq=837 ttl=64 time=0.835 ms 1500 bytes from othermachine (10.0.0.2): icmp_seq=838 ttl=64 time=0.840 ms 1500 bytes from othermachine (10.0.0.2): icmp_seq=839 ttl=64 time=0.845 ms 1500 bytes from othermachine (10.0.0.2): icmp_seq=840 ttl=64 time=0.854 ms 1500 bytes from othermachine (10.0.0.2): icmp_seq=841 ttl=64 time=0.858 ms 1500 bytes from othermachine (10.0.0.2): icmp_seq=842 ttl=64 time=0.869 ms 1500 bytes from othermachine (10.0.0.2): icmp_seq=843 ttl=64 time=0.874 ms 1500 bytes from othermachine (10.0.0.2): icmp_seq=844 ttl=64 time=0.880 ms 1500 bytes from othermachine (10.0.0.2): icmp_seq=845 ttl=64 time=0.882 ms 1500 bytes from othermachine (10.0.0.2): icmp_seq=846 ttl=64 time=0.895 ms 1500 bytes from othermachine (10.0.0.2): icmp_seq=847 ttl=64 time=0.901 ms 1500 bytes from othermachine (10.0.0.2): icmp_seq=848 ttl=64 time=0.910 ms 1500 bytes from othermachine (10.0.0.2): icmp_seq=849 ttl=64 time=0.918 ms 1500 bytes from othermachine (10.0.0.2): icmp_seq=850 ttl=64 time=0.922 ms 1500 bytes from othermachine (10.0.0.2): icmp_seq=851 ttl=64 time=0.931 ms 1500 bytes from othermachine (10.0.0.2): icmp_seq=852 ttl=64 time=0.932 ms 1500 bytes from othermachine (10.0.0.2): icmp_seq=853 ttl=64 time=0.944 ms 1500 bytes from othermachine (10.0.0.2): icmp_seq=854 ttl=64 time=0.947 ms 1500 bytes from othermachine (10.0.0.2): icmp_seq=855 ttl=64 time=0.956 ms 1500 bytes from othermachine (10.0.0.2): icmp_seq=856 ttl=64 time=0.965 ms 1500 bytes from othermachine (10.0.0.2): icmp_seq=857 ttl=64 time=0.971 ms 1500 bytes from othermachine (10.0.0.2): icmp_seq=858 ttl=64 time=0.977 ms 1500 bytes from othermachine (10.0.0.2): icmp_seq=859 ttl=64 time=0.991 ms 1500 bytes from othermachine (10.0.0.2): icmp_seq=860 ttl=64 time=1.00 ms 1500 bytes from othermachine (10.0.0.2): icmp_seq=861 ttl=64 time=0.997 ms 1500 bytes from othermachine (10.0.0.2): icmp_seq=862 ttl=64 time=1.00 ms 1500 bytes from othermachine (10.0.0.2): icmp_seq=863 ttl=64 time=1.00 ms 1500 bytes from othermachine (10.0.0.2): icmp_seq=864 ttl=64 time=1.00 ms 1500 bytes from othermachine (10.0.0.2): icmp_seq=865 ttl=64 time=1.00 ms 1500 bytes from othermachine (10.0.0.2): icmp_seq=866 ttl=64 time=1.00 ms 1500 bytes from othermachine (10.0.0.2): icmp_seq=867 ttl=64 time=0.994 ms 1500 bytes from othermachine (10.0.0.2): icmp_seq=868 ttl=64 time=0.990 ms 1500 bytes from othermachine (10.0.0.2): icmp_seq=869 ttl=64 time=0.997 ms 1500 bytes from othermachine (10.0.0.2): icmp_seq=870 ttl=64 time=1.00 ms 1500 bytes from othermachine (10.0.0.2): icmp_seq=871 ttl=64 time=1.00 ms 1500 bytes from othermachine (10.0.0.2): icmp_seq=872 ttl=64 time=1.07 ms 1500 bytes from othermachine (10.0.0.2): icmp_seq=873 ttl=64 time=1.00 ms 1500 bytes from othermachine (10.0.0.2): icmp_seq=874 ttl=64 time=1.07 ms 1500 bytes from othermachine (10.0.0.2): icmp_seq=875 ttl=64 time=1.09 ms 1500 bytes from othermachine (10.0.0.2): icmp_seq=876 ttl=64 time=1.10 ms 1500 bytes from othermachine (10.0.0.2): icmp_seq=877 ttl=64 time=1.17 ms 1500 bytes from othermachine (10.0.0.2): icmp_seq=878 ttl=64 time=1.11 ms 1500 bytes from othermachine (10.0.0.2): icmp_seq=879 ttl=64 time=1.11 ms 1500 bytes from othermachine (10.0.0.2): icmp_seq=880 ttl=64 time=1.12 ms 1500 bytes from othermachine (10.0.0.2): icmp_seq=881 ttl=64 time=1.13 ms 1500 bytes from othermachine (10.0.0.2): icmp_seq=882 ttl=64 time=1.13 ms 1500 bytes from othermachine (10.0.0.2): icmp_seq=883 ttl=64 time=1.14 ms 1500 bytes from othermachine (10.0.0.2): icmp_seq=884 ttl=64 time=1.15 ms 1500 bytes from othermachine (10.0.0.2): icmp_seq=885 ttl=64 time=1.15 ms 1500 bytes from othermachine (10.0.0.2): icmp_seq=886 ttl=64 time=1.16 ms 1500 bytes from othermachine (10.0.0.2): icmp_seq=887 ttl=64 time=1.17 ms 1500 bytes from othermachine (10.0.0.2): icmp_seq=888 ttl=64 time=1.17 ms 1500 bytes from othermachine (10.0.0.2): icmp_seq=889 ttl=64 time=1.19 ms 1500 bytes from othermachine (10.0.0.2): icmp_seq=890 ttl=64 time=1.18 ms 1500 bytes from othermachine (10.0.0.2): icmp_seq=891 ttl=64 time=1.20 ms 1500 bytes from othermachine (10.0.0.2): icmp_seq=892 ttl=64 time=1.20 ms 1500 bytes from othermachine (10.0.0.2): icmp_seq=893 ttl=64 time=1.21 ms 1500 bytes from othermachine (10.0.0.2): icmp_seq=894 ttl=64 time=1.22 ms 1500 bytes from othermachine (10.0.0.2): icmp_seq=895 ttl=64 time=1.22 ms 1500 bytes from othermachine (10.0.0.2): icmp_seq=896 ttl=64 time=1.22 ms 1500 bytes from othermachine (10.0.0.2): icmp_seq=897 ttl=64 time=1.24 ms 1500 bytes from othermachine (10.0.0.2): icmp_seq=898 ttl=64 time=1.24 ms 1500 bytes from othermachine (10.0.0.2): icmp_seq=899 ttl=64 time=1.25 ms 1500 bytes from othermachine (10.0.0.2): icmp_seq=900 ttl=64 time=1.26 ms 1500 bytes from othermachine (10.0.0.2): icmp_seq=901 ttl=64 time=1.28 ms 1500 bytes from othermachine (10.0.0.2): icmp_seq=902 ttl=64 time=1.27 ms 1500 bytes from othermachine (10.0.0.2): icmp_seq=903 ttl=64 time=1.28 ms 1500 bytes from othermachine (10.0.0.2): icmp_seq=904 ttl=64 time=1.28 ms 1500 bytes from othermachine (10.0.0.2): icmp_seq=905 ttl=64 time=1.30 ms 1500 bytes from othermachine (10.0.0.2): icmp_seq=906 ttl=64 time=1.30 ms 1500 bytes from othermachine (10.0.0.2): icmp_seq=907 ttl=64 time=1.31 ms 1500 bytes from othermachine (10.0.0.2): icmp_seq=908 ttl=64 time=1.33 ms 1500 bytes from othermachine (10.0.0.2): icmp_seq=909 ttl=64 time=1.32 ms 1500 bytes from othermachine (10.0.0.2): icmp_seq=910 ttl=64 time=1.34 ms 1500 bytes from othermachine (10.0.0.2): icmp_seq=911 ttl=64 time=1.34 ms 1500 bytes from othermachine (10.0.0.2): icmp_seq=912 ttl=64 time=1.34 ms 1500 bytes from othermachine (10.0.0.2): icmp_seq=913 ttl=64 time=1.35 ms 1500 bytes from othermachine (10.0.0.2): icmp_seq=914 ttl=64 time=1.35 ms 1500 bytes from othermachine (10.0.0.2): icmp_seq=915 ttl=64 time=1.36 ms 1500 bytes from othermachine (10.0.0.2): icmp_seq=916 ttl=64 time=1.37 ms 1500 bytes from othermachine (10.0.0.2): icmp_seq=917 ttl=64 time=1.38 ms 1500 bytes from othermachine (10.0.0.2): icmp_seq=918 ttl=64 time=1.38 ms 1500 bytes from othermachine (10.0.0.2): icmp_seq=919 ttl=64 time=1.39 ms 1500 bytes from othermachine (10.0.0.2): icmp_seq=920 ttl=64 time=1.41 ms 1500 bytes from othermachine (10.0.0.2): icmp_seq=921 ttl=64 time=1.40 ms 1500 bytes from othermachine (10.0.0.2): icmp_seq=922 ttl=64 time=1.41 ms 1500 bytes from othermachine (10.0.0.2): icmp_seq=923 ttl=64 time=1.42 ms 1500 bytes from othermachine (10.0.0.2): icmp_seq=924 ttl=64 time=1.43 ms 1500 bytes from othermachine (10.0.0.2): icmp_seq=925 ttl=64 time=1.43 ms 1500 bytes from othermachine (10.0.0.2): icmp_seq=926 ttl=64 time=1.44 ms 1500 bytes from othermachine (10.0.0.2): icmp_seq=927 ttl=64 time=1.45 ms 1500 bytes from othermachine (10.0.0.2): icmp_seq=928 ttl=64 time=1.46 ms 1500 bytes from othermachine (10.0.0.2): icmp_seq=929 ttl=64 time=0.829 ms 1500 bytes from othermachine (10.0.0.2): icmp_seq=930 ttl=64 time=1.46 ms 1500 bytes from othermachine (10.0.0.2): icmp_seq=931 ttl=64 time=1.48 ms 1500 bytes from othermachine (10.0.0.2): icmp_seq=932 ttl=64 time=1.48 ms 1500 bytes from othermachine (10.0.0.2): icmp_seq=933 ttl=64 time=1.47 ms 1500 bytes from othermachine (10.0.0.2): icmp_seq=934 ttl=64 time=1.50 ms 1500 bytes from othermachine (10.0.0.2): icmp_seq=935 ttl=64 time=1.49 ms 1500 bytes from othermachine (10.0.0.2): icmp_seq=936 ttl=64 time=1.50 ms 1500 bytes from othermachine (10.0.0.2): icmp_seq=937 ttl=64 time=1.50 ms 1500 bytes from othermachine (10.0.0.2): icmp_seq=938 ttl=64 time=1.51 ms 1500 bytes from othermachine (10.0.0.2): icmp_seq=939 ttl=64 time=1.54 ms 1500 bytes from othermachine (10.0.0.2): icmp_seq=940 ttl=64 time=1.54 ms 1500 bytes from othermachine (10.0.0.2): icmp_seq=941 ttl=64 time=1.54 ms 1500 bytes from othermachine (10.0.0.2): icmp_seq=942 ttl=64 time=1.55 ms 1500 bytes from othermachine (10.0.0.2): icmp_seq=943 ttl=64 time=1.49 ms 1500 bytes from othermachine (10.0.0.2): icmp_seq=944 ttl=64 time=1.47 ms 1500 bytes from othermachine (10.0.0.2): icmp_seq=945 ttl=64 time=1.55 ms 1500 bytes from othermachine (10.0.0.2): icmp_seq=946 ttl=64 time=1.55 ms 1500 bytes from othermachine (10.0.0.2): icmp_seq=947 ttl=64 time=1.56 ms 1500 bytes from othermachine (10.0.0.2): icmp_seq=948 ttl=64 time=1.57 ms 1500 bytes from othermachine (10.0.0.2): icmp_seq=949 ttl=64 time=1.55 ms 1500 bytes from othermachine (10.0.0.2): icmp_seq=950 ttl=64 time=1.55 ms 1500 bytes from othermachine (10.0.0.2): icmp_seq=951 ttl=64 time=1.61 ms 1500 bytes from othermachine (10.0.0.2): icmp_seq=952 ttl=64 time=1.61 ms 1500 bytes from othermachine (10.0.0.2): icmp_seq=953 ttl=64 time=1.61 ms 1500 bytes from othermachine (10.0.0.2): icmp_seq=954 ttl=64 time=1.60 ms 1500 bytes from othermachine (10.0.0.2): icmp_seq=955 ttl=64 time=1.64 ms 1500 bytes from othermachine (10.0.0.2): icmp_seq=956 ttl=64 time=1.62 ms 1500 bytes from othermachine (10.0.0.2): icmp_seq=957 ttl=64 time=1.63 ms 1500 bytes from othermachine (10.0.0.2): icmp_seq=958 ttl=64 time=1.63 ms 1500 bytes from othermachine (10.0.0.2): icmp_seq=959 ttl=64 time=1.66 ms 1500 bytes from othermachine (10.0.0.2): icmp_seq=960 ttl=64 time=1.67 ms 1500 bytes from othermachine (10.0.0.2): icmp_seq=961 ttl=64 time=0.739 ms 1500 bytes from othermachine (10.0.0.2): icmp_seq=962 ttl=64 time=1.68 ms 1500 bytes from othermachine (10.0.0.2): icmp_seq=963 ttl=64 time=1.67 ms 1500 bytes from othermachine (10.0.0.2): icmp_seq=964 ttl=64 time=1.68 ms 1500 bytes from othermachine (10.0.0.2): icmp_seq=965 ttl=64 time=1.70 ms 1500 bytes from othermachine (10.0.0.2): icmp_seq=966 ttl=64 time=1.69 ms 1500 bytes from othermachine (10.0.0.2): icmp_seq=967 ttl=64 time=1.70 ms 1500 bytes from othermachine (10.0.0.2): icmp_seq=968 ttl=64 time=1.70 ms 1500 bytes from othermachine (10.0.0.2): icmp_seq=969 ttl=64 time=0.741 ms 1500 bytes from othermachine (10.0.0.2): icmp_seq=970 ttl=64 time=0.747 ms 1500 bytes from othermachine (10.0.0.2): icmp_seq=971 ttl=64 time=0.772 ms 1500 bytes from othermachine (10.0.0.2): icmp_seq=972 ttl=64 time=1.75 ms 1500 bytes from othermachine (10.0.0.2): icmp_seq=973 ttl=64 time=1.75 ms 1500 bytes from othermachine (10.0.0.2): icmp_seq=974 ttl=64 time=1.75 ms 1500 bytes from othermachine (10.0.0.2): icmp_seq=975 ttl=64 time=1.76 ms 1500 bytes from othermachine (10.0.0.2): icmp_seq=976 ttl=64 time=0.773 ms 1500 bytes from othermachine (10.0.0.2): icmp_seq=977 ttl=64 time=0.797 ms 1500 bytes from othermachine (10.0.0.2): icmp_seq=978 ttl=64 time=0.805 ms 1500 bytes from othermachine (10.0.0.2): icmp_seq=979 ttl=64 time=0.793 ms 1500 bytes from othermachine (10.0.0.2): icmp_seq=980 ttl=64 time=0.817 ms 1500 bytes from othermachine (10.0.0.2): icmp_seq=981 ttl=64 time=0.775 ms 1500 bytes from othermachine (10.0.0.2): icmp_seq=982 ttl=64 time=0.827 ms 1500 bytes from othermachine (10.0.0.2): icmp_seq=983 ttl=64 time=0.911 ms 1500 bytes from othermachine (10.0.0.2): icmp_seq=984 ttl=64 time=0.841 ms 1500 bytes from othermachine (10.0.0.2): icmp_seq=985 ttl=64 time=0.863 ms 1500 bytes from othermachine (10.0.0.2): icmp_seq=986 ttl=64 time=0.868 ms 1500 bytes from othermachine (10.0.0.2): icmp_seq=987 ttl=64 time=0.873 ms 1500 bytes from othermachine (10.0.0.2): icmp_seq=988 ttl=64 time=0.879 ms 1500 bytes from othermachine (10.0.0.2): icmp_seq=989 ttl=64 time=0.884 ms 1500 bytes from othermachine (10.0.0.2): icmp_seq=990 ttl=64 time=0.889 ms 1500 bytes from othermachine (10.0.0.2): icmp_seq=991 ttl=64 time=0.898 ms 1500 bytes from othermachine (10.0.0.2): icmp_seq=992 ttl=64 time=0.911 ms 1500 bytes from othermachine (10.0.0.2): icmp_seq=993 ttl=64 time=0.915 ms 1500 bytes from othermachine (10.0.0.2): icmp_seq=994 ttl=64 time=0.923 ms 1500 bytes from othermachine (10.0.0.2): icmp_seq=995 ttl=64 time=0.930 ms 1500 bytes from othermachine (10.0.0.2): icmp_seq=996 ttl=64 time=0.919 ms 1500 bytes from othermachine (10.0.0.2): icmp_seq=997 ttl=64 time=0.933 ms 1500 bytes from othermachine (10.0.0.2): icmp_seq=998 ttl=64 time=0.851 ms 1500 bytes from othermachine (10.0.0.2): icmp_seq=999 ttl=64 time=0.954 ms 1500 bytes from othermachine (10.0.0.2): icmp_seq=1000 ttl=64 time=0.847 ms 1500 bytes from othermachine (10.0.0.2): icmp_seq=1001 ttl=64 time=0.971 ms 1500 bytes from othermachine (10.0.0.2): icmp_seq=1002 ttl=64 time=0.977 ms 1500 bytes from othermachine (10.0.0.2): icmp_seq=1003 ttl=64 time=0.975 ms 1500 bytes from othermachine (10.0.0.2): icmp_seq=1004 ttl=64 time=0.981 ms 1500 bytes from othermachine (10.0.0.2): icmp_seq=1005 ttl=64 time=0.985 ms 1500 bytes from othermachine (10.0.0.2): icmp_seq=1006 ttl=64 time=0.985 ms 1500 bytes from othermachine (10.0.0.2): icmp_seq=1007 ttl=64 time=0.988 ms 1500 bytes from othermachine (10.0.0.2): icmp_seq=1008 ttl=64 time=0.988 ms 1500 bytes from othermachine (10.0.0.2): icmp_seq=1009 ttl=64 time=1.47 ms 1500 bytes from othermachine (10.0.0.2): icmp_seq=1010 ttl=64 time=0.976 ms 1500 bytes from othermachine (10.0.0.2): icmp_seq=1011 ttl=64 time=0.982 ms 1500 bytes from othermachine (10.0.0.2): icmp_seq=1012 ttl=64 time=1.00 ms 1500 bytes from othermachine (10.0.0.2): icmp_seq=1013 ttl=64 time=0.990 ms 1500 bytes from othermachine (10.0.0.2): icmp_seq=1014 ttl=64 time=0.881 ms 1500 bytes from othermachine (10.0.0.2): icmp_seq=1015 ttl=64 time=0.894 ms 1500 bytes from othermachine (10.0.0.2): icmp_seq=1016 ttl=64 time=1.07 ms 1500 bytes from othermachine (10.0.0.2): icmp_seq=1017 ttl=64 time=1.01 ms 1500 bytes from othermachine (10.0.0.2): icmp_seq=1018 ttl=64 time=1.09 ms 1500 bytes from othermachine (10.0.0.2): icmp_seq=1019 ttl=64 time=0.916 ms 1500 bytes from othermachine (10.0.0.2): icmp_seq=1020 ttl=64 time=1.09 ms 1500 bytes from othermachine (10.0.0.2): icmp_seq=1021 ttl=64 time=0.992 ms 1500 bytes from othermachine (10.0.0.2): icmp_seq=1022 ttl=64 time=1.11 ms 1500 bytes from othermachine (10.0.0.2): icmp_seq=1023 ttl=64 time=1.10 ms 1500 bytes from othermachine (10.0.0.2): icmp_seq=1024 ttl=64 time=1.12 ms 1500 bytes from othermachine (10.0.0.2): icmp_seq=1025 ttl=64 time=1.09 ms 1500 bytes from othermachine (10.0.0.2): icmp_seq=1026 ttl=64 time=1.16 ms 1500 bytes from othermachine (10.0.0.2): icmp_seq=1027 ttl=64 time=1.14 ms 1500 bytes from othermachine (10.0.0.2): icmp_seq=1028 ttl=64 time=1.15 ms 1500 bytes from othermachine (10.0.0.2): icmp_seq=1029 ttl=64 time=1.16 ms 1500 bytes from othermachine (10.0.0.2): icmp_seq=1030 ttl=64 time=1.13 ms 1500 bytes from othermachine (10.0.0.2): icmp_seq=1031 ttl=64 time=1.18 ms 1500 bytes from othermachine (10.0.0.2): icmp_seq=1032 ttl=64 time=1.19 ms 1500 bytes from othermachine (10.0.0.2): icmp_seq=1033 ttl=64 time=1.18 ms 1500 bytes from othermachine (10.0.0.2): icmp_seq=1034 ttl=64 time=1.19 ms 1500 bytes from othermachine (10.0.0.2): icmp_seq=1035 ttl=64 time=1.20 ms 1500 bytes from othermachine (10.0.0.2): icmp_seq=1036 ttl=64 time=1.21 ms 1500 bytes from othermachine (10.0.0.2): icmp_seq=1037 ttl=64 time=1.22 ms 1500 bytes from othermachine (10.0.0.2): icmp_seq=1038 ttl=64 time=1.22 ms 1500 bytes from othermachine (10.0.0.2): icmp_seq=1039 ttl=64 time=1.13 ms 1500 bytes from othermachine (10.0.0.2): icmp_seq=1040 ttl=64 time=1.23 ms 1500 bytes from othermachine (10.0.0.2): icmp_seq=1041 ttl=64 time=1.24 ms 1500 bytes from othermachine (10.0.0.2): icmp_seq=1042 ttl=64 time=1.24 ms 1500 bytes from othermachine (10.0.0.2): icmp_seq=1043 ttl=64 time=0.895 ms 1500 bytes from othermachine (10.0.0.2): icmp_seq=1044 ttl=64 time=1.36 ms 1500 bytes from othermachine (10.0.0.2): icmp_seq=1045 ttl=64 time=1.28 ms 1500 bytes from othermachine (10.0.0.2): icmp_seq=1046 ttl=64 time=1.22 ms 1500 bytes from othermachine (10.0.0.2): icmp_seq=1047 ttl=64 time=1.28 ms 1500 bytes from othermachine (10.0.0.2): icmp_seq=1048 ttl=64 time=1.29 ms 1500 bytes from othermachine (10.0.0.2): icmp_seq=1049 ttl=64 time=1.32 ms 1500 bytes from othermachine (10.0.0.2): icmp_seq=1050 ttl=64 time=1.31 ms 1500 bytes from othermachine (10.0.0.2): icmp_seq=1051 ttl=64 time=1.31 ms 1500 bytes from othermachine (10.0.0.2): icmp_seq=1052 ttl=64 time=1.32 ms 1500 bytes from othermachine (10.0.0.2): icmp_seq=1053 ttl=64 time=1.33 ms 1500 bytes from othermachine (10.0.0.2): icmp_seq=1054 ttl=64 time=1.33 ms 1500 bytes from othermachine (10.0.0.2): icmp_seq=1055 ttl=64 time=1.34 ms 1500 bytes from othermachine (10.0.0.2): icmp_seq=1056 ttl=64 time=1.35 ms 1500 bytes from othermachine (10.0.0.2): icmp_seq=1057 ttl=64 time=1.36 ms 1500 bytes from othermachine (10.0.0.2): icmp_seq=1058 ttl=64 time=1.36 ms 1500 bytes from othermachine (10.0.0.2): icmp_seq=1059 ttl=64 time=1.63 ms 1500 bytes from othermachine (10.0.0.2): icmp_seq=1060 ttl=64 time=1.37 ms 1500 bytes from othermachine (10.0.0.2): icmp_seq=1061 ttl=64 time=1.38 ms 1500 bytes from othermachine (10.0.0.2): icmp_seq=1062 ttl=64 time=1.41 ms 1500 bytes from othermachine (10.0.0.2): icmp_seq=1063 ttl=64 time=1.38 ms 1500 bytes from othermachine (10.0.0.2): icmp_seq=1064 ttl=64 time=1.40 ms 1500 bytes from othermachine (10.0.0.2): icmp_seq=1065 ttl=64 time=1.40 ms 1500 bytes from othermachine (10.0.0.2): icmp_seq=1066 ttl=64 time=1.41 ms 1500 bytes from othermachine (10.0.0.2): icmp_seq=1067 ttl=64 time=1.42 ms 1500 bytes from othermachine (10.0.0.2): icmp_seq=1068 ttl=64 time=1.42 ms 1500 bytes from othermachine (10.0.0.2): icmp_seq=1069 ttl=64 time=1.43 ms 1500 bytes from othermachine (10.0.0.2): icmp_seq=1070 ttl=64 time=1.44 ms 1500 bytes from othermachine (10.0.0.2): icmp_seq=1071 ttl=64 time=1.44 ms 1500 bytes from othermachine (10.0.0.2): icmp_seq=1072 ttl=64 time=1.46 ms 1500 bytes from othermachine (10.0.0.2): icmp_seq=1073 ttl=64 time=1.46 ms 1500 bytes from othermachine (10.0.0.2): icmp_seq=1074 ttl=64 time=1.47 ms 1500 bytes from othermachine (10.0.0.2): icmp_seq=1075 ttl=64 time=1.49 ms 1500 bytes from othermachine (10.0.0.2): icmp_seq=1076 ttl=64 time=1.48 ms 1500 bytes from othermachine (10.0.0.2): icmp_seq=1077 ttl=64 time=1.49 ms 1500 bytes from othermachine (10.0.0.2): icmp_seq=1078 ttl=64 time=1.49 ms 1500 bytes from othermachine (10.0.0.2): icmp_seq=1079 ttl=64 time=1.50 ms 1500 bytes from othermachine (10.0.0.2): icmp_seq=1080 ttl=64 time=1.51 ms 1500 bytes from othermachine (10.0.0.2): icmp_seq=1081 ttl=64 time=1.51 ms 1500 bytes from othermachine (10.0.0.2): icmp_seq=1082 ttl=64 time=1.52 ms 1500 bytes from othermachine (10.0.0.2): icmp_seq=1083 ttl=64 time=1.53 ms 1500 bytes from othermachine (10.0.0.2): icmp_seq=1084 ttl=64 time=1.53 ms 1500 bytes from othermachine (10.0.0.2): icmp_seq=1085 ttl=64 time=1.54 ms 1500 bytes from othermachine (10.0.0.2): icmp_seq=1086 ttl=64 time=1.54 ms 1500 bytes from othermachine (10.0.0.2): icmp_seq=1087 ttl=64 time=1.55 ms 1500 bytes from othermachine (10.0.0.2): icmp_seq=1088 ttl=64 time=1.56 ms 1500 bytes from othermachine (10.0.0.2): icmp_seq=1089 ttl=64 time=1.57 ms 1500 bytes from othermachine (10.0.0.2): icmp_seq=1090 ttl=64 time=1.57 ms 1500 bytes from othermachine (10.0.0.2): icmp_seq=1091 ttl=64 time=1.58 ms 1500 bytes from othermachine (10.0.0.2): icmp_seq=1092 ttl=64 time=1.59 ms 1500 bytes from othermachine (10.0.0.2): icmp_seq=1093 ttl=64 time=1.60 ms 1500 bytes from othermachine (10.0.0.2): icmp_seq=1094 ttl=64 time=1.61 ms 1500 bytes from othermachine (10.0.0.2): icmp_seq=1095 ttl=64 time=1.60 ms 1500 bytes from othermachine (10.0.0.2): icmp_seq=1096 ttl=64 time=0.888 ms 1500 bytes from othermachine (10.0.0.2): icmp_seq=1097 ttl=64 time=1.63 ms 1500 bytes from othermachine (10.0.0.2): icmp_seq=1098 ttl=64 time=1.63 ms 1500 bytes from othermachine (10.0.0.2): icmp_seq=1099 ttl=64 time=1.63 ms 1500 bytes from othermachine (10.0.0.2): icmp_seq=1100 ttl=64 time=1.64 ms 1500 bytes from othermachine (10.0.0.2): icmp_seq=1101 ttl=64 time=1.65 ms 1500 bytes from othermachine (10.0.0.2): icmp_seq=1102 ttl=64 time=1.66 ms 1500 bytes from othermachine (10.0.0.2): icmp_seq=1103 ttl=64 time=1.67 ms 1500 bytes from othermachine (10.0.0.2): icmp_seq=1104 ttl=64 time=1.67 ms 1500 bytes from othermachine (10.0.0.2): icmp_seq=1105 ttl=64 time=1.68 ms 1500 bytes from othermachine (10.0.0.2): icmp_seq=1106 ttl=64 time=0.839 ms 1500 bytes from othermachine (10.0.0.2): icmp_seq=1107 ttl=64 time=1.69 ms 1500 bytes from othermachine (10.0.0.2): icmp_seq=1108 ttl=64 time=1.69 ms 1500 bytes from othermachine (10.0.0.2): icmp_seq=1109 ttl=64 time=1.66 ms 1500 bytes from othermachine (10.0.0.2): icmp_seq=1110 ttl=64 time=1.71 ms 1500 bytes from othermachine (10.0.0.2): icmp_seq=1111 ttl=64 time=1.71 ms 1500 bytes from othermachine (10.0.0.2): icmp_seq=1112 ttl=64 time=0.738 ms 1500 bytes from othermachine (10.0.0.2): icmp_seq=1113 ttl=64 time=1.73 ms 1500 bytes from othermachine (10.0.0.2): icmp_seq=1114 ttl=64 time=0.747 ms 1500 bytes from othermachine (10.0.0.2): icmp_seq=1115 ttl=64 time=0.754 ms 1500 bytes from othermachine (10.0.0.2): icmp_seq=1116 ttl=64 time=0.756 ms 1500 bytes from othermachine (10.0.0.2): icmp_seq=1117 ttl=64 time=0.759 ms 1500 bytes from othermachine (10.0.0.2): icmp_seq=1118 ttl=64 time=0.770 ms 1500 bytes from othermachine (10.0.0.2): icmp_seq=1119 ttl=64 time=0.794 ms 1500 bytes from othermachine (10.0.0.2): icmp_seq=1120 ttl=64 time=0.800 ms 1500 bytes from othermachine (10.0.0.2): icmp_seq=1121 ttl=64 time=0.794 ms 1500 bytes from othermachine (10.0.0.2): icmp_seq=1122 ttl=64 time=0.816 ms 1500 bytes from othermachine (10.0.0.2): icmp_seq=1123 ttl=64 time=0.822 ms 1500 bytes from othermachine (10.0.0.2): icmp_seq=1124 ttl=64 time=0.835 ms 1500 bytes from othermachine (10.0.0.2): icmp_seq=1125 ttl=64 time=0.840 ms 1500 bytes from othermachine (10.0.0.2): icmp_seq=1126 ttl=64 time=0.846 ms 1500 bytes from othermachine (10.0.0.2): icmp_seq=1127 ttl=64 time=0.849 ms 1500 bytes from othermachine (10.0.0.2): icmp_seq=1128 ttl=64 time=0.859 ms 1500 bytes from othermachine (10.0.0.2): icmp_seq=1129 ttl=64 time=0.865 ms 1500 bytes from othermachine (10.0.0.2): icmp_seq=1130 ttl=64 time=0.871 ms 1500 bytes from othermachine (10.0.0.2): icmp_seq=1131 ttl=64 time=0.880 ms 1500 bytes from othermachine (10.0.0.2): icmp_seq=1132 ttl=64 time=0.885 ms 1500 bytes from othermachine (10.0.0.2): icmp_seq=1133 ttl=64 time=0.892 ms 1500 bytes from othermachine (10.0.0.2): icmp_seq=1134 ttl=64 time=0.897 ms 1500 bytes from othermachine (10.0.0.2): icmp_seq=1135 ttl=64 time=0.900 ms 1500 bytes from othermachine (10.0.0.2): icmp_seq=1136 ttl=64 time=0.913 ms 1500 bytes from othermachine (10.0.0.2): icmp_seq=1137 ttl=64 time=0.917 ms 1500 bytes from othermachine (10.0.0.2): icmp_seq=1138 ttl=64 time=0.924 ms 1500 bytes from othermachine (10.0.0.2): icmp_seq=1139 ttl=64 time=0.939 ms 1500 bytes from othermachine (10.0.0.2): icmp_seq=1140 ttl=64 time=0.939 ms 1500 bytes from othermachine (10.0.0.2): icmp_seq=1141 ttl=64 time=0.949 ms 1500 bytes from othermachine (10.0.0.2): icmp_seq=1142 ttl=64 time=0.926 ms 1500 bytes from othermachine (10.0.0.2): icmp_seq=1143 ttl=64 time=0.948 ms 1500 bytes from othermachine (10.0.0.2): icmp_seq=1144 ttl=64 time=0.971 ms 1500 bytes from othermachine (10.0.0.2): icmp_seq=1145 ttl=64 time=0.978 ms 1500 bytes from othermachine (10.0.0.2): icmp_seq=1146 ttl=64 time=0.987 ms 1500 bytes from othermachine (10.0.0.2): icmp_seq=1147 ttl=64 time=0.986 ms 1500 bytes from othermachine (10.0.0.2): icmp_seq=1148 ttl=64 time=0.995 ms 1500 bytes from othermachine (10.0.0.2): icmp_seq=1149 ttl=64 time=1.00 ms 1500 bytes from othermachine (10.0.0.2): icmp_seq=1150 ttl=64 time=1.00 ms 1500 bytes from othermachine (10.0.0.2): icmp_seq=1151 ttl=64 time=1.00 ms 1500 bytes from othermachine (10.0.0.2): icmp_seq=1152 ttl=64 time=1.00 ms 1500 bytes from othermachine (10.0.0.2): icmp_seq=1153 ttl=64 time=1.00 ms 1500 bytes from othermachine (10.0.0.2): icmp_seq=1154 ttl=64 time=0.998 ms 1500 bytes from othermachine (10.0.0.2): icmp_seq=1155 ttl=64 time=1.00 ms 1500 bytes from othermachine (10.0.0.2): icmp_seq=1156 ttl=64 time=0.995 ms 1500 bytes from othermachine (10.0.0.2): icmp_seq=1157 ttl=64 time=1.69 ms 1500 bytes from othermachine (10.0.0.2): icmp_seq=1158 ttl=64 time=1.00 ms 1500 bytes from othermachine (10.0.0.2): icmp_seq=1159 ttl=64 time=1.06 ms 1500 bytes from othermachine (10.0.0.2): icmp_seq=1160 ttl=64 time=1.07 ms 1500 bytes from othermachine (10.0.0.2): icmp_seq=1161 ttl=64 time=1.09 ms 1500 bytes from othermachine (10.0.0.2): icmp_seq=1162 ttl=64 time=1.09 ms 1500 bytes from othermachine (10.0.0.2): icmp_seq=1163 ttl=64 time=1.09 ms 1500 bytes from othermachine (10.0.0.2): icmp_seq=1164 ttl=64 time=1.09 ms 1500 bytes from othermachine (10.0.0.2): icmp_seq=1165 ttl=64 time=1.11 ms 1500 bytes from othermachine (10.0.0.2): icmp_seq=1166 ttl=64 time=1.11 ms 1500 bytes from othermachine (10.0.0.2): icmp_seq=1167 ttl=64 time=1.12 ms 1500 bytes from othermachine (10.0.0.2): icmp_seq=1168 ttl=64 time=1.12 ms 1500 bytes from othermachine (10.0.0.2): icmp_seq=1169 ttl=64 time=1.13 ms 1500 bytes from othermachine (10.0.0.2): icmp_seq=1170 ttl=64 time=1.14 ms 1500 bytes from othermachine (10.0.0.2): icmp_seq=1171 ttl=64 time=1.14 ms 1500 bytes from othermachine (10.0.0.2): icmp_seq=1172 ttl=64 time=1.15 ms 1500 bytes from othermachine (10.0.0.2): icmp_seq=1173 ttl=64 time=1.16 ms 1500 bytes from othermachine (10.0.0.2): icmp_seq=1174 ttl=64 time=1.17 ms 1500 bytes from othermachine (10.0.0.2): icmp_seq=1175 ttl=64 time=1.49 ms 1500 bytes from othermachine (10.0.0.2): icmp_seq=1176 ttl=64 time=1.18 ms 1500 bytes from othermachine (10.0.0.2): icmp_seq=1177 ttl=64 time=1.19 ms 1500 bytes from othermachine (10.0.0.2): icmp_seq=1178 ttl=64 time=1.19 ms 1500 bytes from othermachine (10.0.0.2): icmp_seq=1179 ttl=64 time=1.20 ms 1500 bytes from othermachine (10.0.0.2): icmp_seq=1180 ttl=64 time=1.20 ms 1500 bytes from othermachine (10.0.0.2): icmp_seq=1181 ttl=64 time=1.22 ms 1500 bytes from othermachine (10.0.0.2): icmp_seq=1182 ttl=64 time=1.22 ms 1500 bytes from othermachine (10.0.0.2): icmp_seq=1183 ttl=64 time=1.23 ms 1500 bytes from othermachine (10.0.0.2): icmp_seq=1184 ttl=64 time=1.24 ms 1500 bytes from othermachine (10.0.0.2): icmp_seq=1185 ttl=64 time=1.24 ms 1500 bytes from othermachine (10.0.0.2): icmp_seq=1186 ttl=64 time=1.25 ms 1500 bytes from othermachine (10.0.0.2): icmp_seq=1187 ttl=64 time=1.25 ms 1500 bytes from othermachine (10.0.0.2): icmp_seq=1188 ttl=64 time=1.27 ms 1500 bytes from othermachine (10.0.0.2): icmp_seq=1189 ttl=64 time=1.29 ms 1500 bytes from othermachine (10.0.0.2): icmp_seq=1190 ttl=64 time=1.28 ms 1500 bytes from othermachine (10.0.0.2): icmp_seq=1191 ttl=64 time=1.28 ms 1500 bytes from othermachine (10.0.0.2): icmp_seq=1192 ttl=64 time=1.29 ms 1500 bytes from othermachine (10.0.0.2): icmp_seq=1193 ttl=64 time=1.30 ms 1500 bytes from othermachine (10.0.0.2): icmp_seq=1194 ttl=64 time=1.30 ms 1500 bytes from othermachine (10.0.0.2): icmp_seq=1195 ttl=64 time=1.32 ms 1500 bytes from othermachine (10.0.0.2): icmp_seq=1196 ttl=64 time=1.31 ms 1500 bytes from othermachine (10.0.0.2): icmp_seq=1197 ttl=64 time=1.33 ms 1500 bytes from othermachine (10.0.0.2): icmp_seq=1198 ttl=64 time=1.33 ms 1500 bytes from othermachine (10.0.0.2): icmp_seq=1199 ttl=64 time=1.34 ms 1500 bytes from othermachine (10.0.0.2): icmp_seq=1200 ttl=64 time=1.34 ms 1500 bytes from othermachine (10.0.0.2): icmp_seq=1201 ttl=64 time=1.35 ms 1500 bytes from othermachine (10.0.0.2): icmp_seq=1202 ttl=64 time=1.37 ms 1500 bytes from othermachine (10.0.0.2): icmp_seq=1203 ttl=64 time=1.38 ms 1500 bytes from othermachine (10.0.0.2): icmp_seq=1204 ttl=64 time=1.38 ms 1500 bytes from othermachine (10.0.0.2): icmp_seq=1205 ttl=64 time=1.42 ms 1500 bytes from othermachine (10.0.0.2): icmp_seq=1206 ttl=64 time=1.39 ms 1500 bytes from othermachine (10.0.0.2): icmp_seq=1207 ttl=64 time=1.40 ms 1500 bytes from othermachine (10.0.0.2): icmp_seq=1208 ttl=64 time=1.40 ms 1500 bytes from othermachine (10.0.0.2): icmp_seq=1209 ttl=64 time=1.41 ms --- othermachine ping statistics --- 1209 packets transmitted, 1209 received, 0% packet loss, time 123187ms rtt min/avg/max/mdev = 0.711/1.241/1.832/0.287 ms --Multipart=_Thu__17_Mar_2005_11_52_54_-0800_9sR8yt9M+8/Yn=Tn-- From chas@cmf.nrl.navy.mil Thu Mar 17 12:36:54 2005 Received: with ECARTIS (v1.0.0; list netdev); Thu, 17 Mar 2005 12:37:00 -0800 (PST) Received: from ginger.cmf.nrl.navy.mil (ginger.cmf.nrl.navy.mil [134.207.10.161]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j2HKasH7029255 for ; Thu, 17 Mar 2005 12:36:54 -0800 Received: from cmf.nrl.navy.mil (thirdoffive.cmf.nrl.navy.mil [134.207.10.180]) by ginger.cmf.nrl.navy.mil (8.12.11/8.12.11) with ESMTP id j2HKadfm000732; Thu, 17 Mar 2005 15:36:40 -0500 (EST) Message-Id: <200503172036.j2HKadfm000732@ginger.cmf.nrl.navy.mil> To: Adrian Bunk cc: shemminger@osdl.org, bridge@osdl.org, linux-atm-general@lists.sourceforge.net, netdev@oss.sgi.com, linux-kernel@vger.kernel.org Reply-To: chas3@users.sourceforge.net Reply-To: chas3@users.sourceforge.net Reply-To: chas3@users.sourceforge.net Subject: Re: [2.6 patch] fix bridge <-> ATM compile error In-reply-to: <20050316181532.GA3251@stusta.de> Date: Thu, 17 Mar 2005 15:36:40 -0500 From: "chas williams - CONTRACTOR" X-Virus-Scanned: ClamAV 0.83/765/Thu Mar 17 00:42:45 2005 on oss.sgi.com X-Virus-Scanned: NAI Completed X-Scanned-By: MIMEDefang 2.30 (www . roaringpenguin . com / mimedefang) X-Virus-Status: Clean X-archive-position: 291 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: chas@cmf.nrl.navy.mil Precedence: bulk X-list: netdev Content-Length: 4914 Lines: 142 In message <20050316181532.GA3251@stusta.de>,Adrian Bunk writes: >Letting CONFIG_BRIDGE depend on CONFIG_ATM doesn't sound like a good >idea, since I doubt all people using the Bridge code require ATM >support. how about the following? ===== net/atm/common.c 1.58 vs edited ===== --- 1.58/net/atm/common.c 2005-01-20 21:17:39 -05:00 +++ edited/net/atm/common.c 2005-03-16 12:44:37 -05:00 @@ -755,21 +755,6 @@ return vcc->dev->ops->getsockopt(vcc, level, optname, optval, len); } - -#if defined(CONFIG_ATM_LANE) || defined(CONFIG_ATM_LANE_MODULE) -#if defined(CONFIG_BRIDGE) || defined(CONFIG_BRIDGE_MODULE) -struct net_bridge; -struct net_bridge_fdb_entry *(*br_fdb_get_hook)(struct net_bridge *br, - unsigned char *addr) = NULL; -void (*br_fdb_put_hook)(struct net_bridge_fdb_entry *ent) = NULL; -#if defined(CONFIG_ATM_LANE_MODULE) || defined(CONFIG_BRIDGE_MODULE) -EXPORT_SYMBOL(br_fdb_get_hook); -EXPORT_SYMBOL(br_fdb_put_hook); -#endif /* defined(CONFIG_ATM_LANE_MODULE) || defined(CONFIG_BRIDGE_MODULE) */ -#endif /* defined(CONFIG_BRIDGE) || defined(CONFIG_BRIDGE_MODULE) */ -#endif /* defined(CONFIG_ATM_LANE) || defined(CONFIG_ATM_LANE_MODULE) */ - - static int __init atm_init(void) { int error; ===== net/atm/lec.c 1.47 vs edited ===== --- 1.47/net/atm/lec.c 2005-02-08 23:09:15 -05:00 +++ edited/net/atm/lec.c 2005-03-16 13:18:28 -05:00 @@ -37,11 +37,8 @@ #if defined(CONFIG_BRIDGE) || defined(CONFIG_BRIDGE_MODULE) #include #include "../bridge/br_private.h" -static unsigned char bridge_ula_lec[] = {0x01, 0x80, 0xc2, 0x00, 0x00}; -extern struct net_bridge_fdb_entry *(*br_fdb_get_hook)(struct net_bridge *br, - unsigned char *addr); -extern void (*br_fdb_put_hook)(struct net_bridge_fdb_entry *ent); +static unsigned char bridge_ula_lec[] = {0x01, 0x80, 0xc2, 0x00, 0x00}; #endif /* Modular too */ ===== net/atm/lec.h 1.13 vs edited ===== --- 1.13/net/atm/lec.h 2005-01-18 15:59:15 -05:00 +++ edited/net/atm/lec.h 2005-03-16 13:22:13 -05:00 @@ -14,14 +14,6 @@ #include #include -#if defined (CONFIG_BRIDGE) || defined(CONFIG_BRIDGE_MODULE) -#include -struct net_bridge; -extern struct net_bridge_fdb_entry *(*br_fdb_get_hook)(struct net_bridge *br, - unsigned char *addr); -extern void (*br_fdb_put_hook)(struct net_bridge_fdb_entry *ent); -#endif /* defined(CONFIG_BRIDGE) || defined(CONFIG_BRIDGE_MODULE) */ - #define LEC_HEADER_LEN 16 struct lecdatahdr_8023 { ===== net/bridge/br.c 1.20 vs edited ===== --- 1.20/net/bridge/br.c 2005-03-10 21:50:08 -05:00 +++ edited/net/bridge/br.c 2005-03-16 13:21:27 -05:00 @@ -22,10 +22,6 @@ #include "br_private.h" -#if defined(CONFIG_ATM_LANE) || defined(CONFIG_ATM_LANE_MODULE) -#include "../atm/lec.h" -#endif - int (*br_should_route_hook) (struct sk_buff **pskb) = NULL; static int __init br_init(void) @@ -39,10 +35,9 @@ brioctl_set(br_ioctl_deviceless_stub); br_handle_frame_hook = br_handle_frame; -#if defined(CONFIG_ATM_LANE) || defined(CONFIG_ATM_LANE_MODULE) br_fdb_get_hook = br_fdb_get; br_fdb_put_hook = br_fdb_put; -#endif + register_netdevice_notifier(&br_device_notifier); return 0; @@ -60,10 +55,8 @@ synchronize_net(); -#if defined(CONFIG_ATM_LANE) || defined(CONFIG_ATM_LANE_MODULE) br_fdb_get_hook = NULL; br_fdb_put_hook = NULL; -#endif br_handle_frame_hook = NULL; br_fdb_fini(); ===== net/bridge/br_private.h 1.37 vs edited ===== --- 1.37/net/bridge/br_private.h 2005-03-10 21:51:37 -05:00 +++ edited/net/bridge/br_private.h 2005-03-16 13:19:34 -05:00 @@ -216,6 +216,12 @@ extern void br_stp_port_timer_init(struct net_bridge_port *p); extern unsigned long br_timer_value(const struct timer_list *timer); +/* br.c */ +extern struct net_bridge_fdb_entry *(*br_fdb_get_hook)(struct net_bridge *br, + unsigned char *addr); +extern void (*br_fdb_put_hook)(struct net_bridge_fdb_entry *ent); + + #ifdef CONFIG_SYSFS /* br_sysfs_if.c */ extern int br_sysfs_addif(struct net_bridge_port *p); ===== net/core/dev.c 1.185 vs edited ===== --- 1.185/net/core/dev.c 2005-02-11 00:54:32 -05:00 +++ edited/net/core/dev.c 2005-03-16 13:29:23 -05:00 @@ -1561,6 +1561,10 @@ #if defined(CONFIG_BRIDGE) || defined (CONFIG_BRIDGE_MODULE) int (*br_handle_frame_hook)(struct net_bridge_port *p, struct sk_buff **pskb); +struct net_bridge; +struct net_bridge_fdb_entry *(*br_fdb_get_hook)(struct net_bridge *br, + unsigned char *addr); +void (*br_fdb_put_hook)(struct net_bridge_fdb_entry *ent); static __inline__ int handle_bridge(struct sk_buff **pskb, struct packet_type **pt_prev, int *ret) @@ -3346,6 +3350,8 @@ #if defined(CONFIG_BRIDGE) || defined(CONFIG_BRIDGE_MODULE) EXPORT_SYMBOL(br_handle_frame_hook); +EXPORT_SYMBOL(br_fdb_get_hook); +EXPORT_SYMBOL(br_fdb_put_hook); #endif #ifdef CONFIG_KMOD From nobody@helo.ori-g.net Thu Mar 17 15:31:50 2005 Received: with ECARTIS (v1.0.0; list netdev); Thu, 17 Mar 2005 15:31:57 -0800 (PST) Received: from helo.ori-g.net ([218.237.66.178]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j2HNVjc0025692 for ; Thu, 17 Mar 2005 15:31:47 -0800 Received: by helo.ori-g.net (Postfix, from userid 99) id 6332E7E0064; Fri, 18 Mar 2005 08:33:03 +0900 (KST) To: netdev@oss.sgi.com Subject: =?ISO-2022-JP?B?GyRCRCw/YSQtJF4kLyRqPjpFNyQ3JF4kLyRqInYbKEI=?= To: netdev@oss.sgi.com From: =?ISO-2022-JP?B?GyRCJTolQyVdJWpSeiQoOX4kXxsoQg==?= Message-Id: <20050317233303.6332E7E0064@helo.ori-g.net> Date: Fri, 18 Mar 2005 08:33:03 +0900 (KST) X-Virus-Scanned: ClamAV 0.83/765/Thu Mar 17 00:42:45 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 292 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: kumi@york.vig-seet.to Precedence: bulk X-list: netdev Content-Length: 3079 Lines: 67 „ª„ª„ª„ª„ª„ª„ª„ªßƒGƒ“ƒ^[ƒeƒCƒƒ“ƒgƒ}ƒKƒWƒ“FFe-MAGAß„ª„ª„ª„ª„ª„ª„ª„ª @@@@@@@@@Š®‘Sƒ}ƒWŽB‚è‘fl“ŽB‰f‘œôˆ–戙ôôôsssssss £¥£¥£¥£¥£¥£¥£¥£¥£¥£¥££¥£¥£¥£¥£¥£¥£¥£¥ „ª„ª„ª„ª„ª„ª„ª„ª„ª„ª„ª„ª„ª„ª„ª„ª„ª„ª„ª„ª„ª„ª„ª„ª„ª„ª„ª„ª„ª„ª„ª„ª„ª„ª @http://sibuya.mycountry.cc/?84fjdhnj2d y—ŽqZö“ü“ŽB“ÁWz--------------------------------------™ FFFFFFFFFFFFFFFFFFFFF ¡“s“à–^—ŽqZ‚ÉŒˆŽ€‚Ìö“ü‚ɬŒ÷II ‰X‚µ‚¢—‚ÌŽq’B‚Ì•’i‚ÍŒ©‚ê‚È‚¢ˆê–Ê‚ªƒoƒbƒ`ƒŠII yI–­‚ÉŽdŠ|‚¯‚ç‚ꂽƒJƒƒ‰‚ª”`‚­”é–§‚Ì’n‘Ñz------------------------™ FFFFFFFFFFFFFFFFFFFFF @¡“¥‚É•´‚ê‚Ä”íŽÊ‘Ì‚ð’ÇÕIŠX‚Å\‰®“à‚Å\ˆÚ“®’†‚É\\\\ @@@@@@@‚ ‚ç‚ä‚éŠp“x‚©‚ç‘_‚¢‚·‚Ü‚µ‚½ƒxƒXƒgƒVƒ‡ƒbƒgII‚à‚¤Œˆ‚µ‚Ä“¦‚ê‚邱‚Æ‚Ío—ˆ‚È‚¢cB ¡–³–h”õ‚ȃIƒ“ƒi’B‚É”—‚éƒJƒƒ‰‚Ìã©‚»‚µ‚¢‚É‹Ö’f‚̗̈æ‚Ü‚Å‚ð‚à”Æ‚µ‚Ä‚µ‚Ü‚¤cB @ @@@@@Œö‰€‚ÌŒöOƒgƒCƒŒ‚ÉŽdŠ|‚¯‚ç‚ꂽˆê‘ä‚̉B‚µƒJƒƒ‰‚ªŒˆ’è“IuŠÔ‚ð•ß‚炦‚½III @http://sibuya.mycountry.cc/?84fjdhnj2d „´„´„´„´„´„´„´„´@@ „´„´„´„´„´„´„´„´@ „´„´„´„´„´„´„´„´@@ „´„´„´„´„´„´„´„´ @@ ¡@@ ŸŸŸ ‘fl·‚è‚Ì–é‚ÌŒö‰€ @@ ¡@@”‘g‚̃Jƒbƒvƒ‹‚É–Ú‚ð‚‚¯A”ösŽB‰eŠJŽnII ŸŸŸ ‚Æ‚±‚ë‚©‚܂킸Œƒ‚µ‚­‚à‚‚ê‚é‘flƒJƒbƒvƒ‹‚ðŒƒŽÊ™ @@ ¡ ŸŸŸ “s“à–^Šƒiƒ}—ŒðŒ»ê @@ ¡@@’m‚él‚¼’m‚é‰\‚̃Xƒ|ƒbƒg‚ÅA‘å’_ŽB‰e‘å‰ïô @ @http://sibuya.mycountry.cc/?84fjdhnj2d yŠXŽB‚èƒtƒFƒ`‚ÁŽqŽÊ^ŠÙz--------------------------------------™@@@@@ @@ ¡@@ ŸŸŸ @ƒsƒbƒ^ƒsƒ^‚̃[ƒ‰ƒCƒY‚Ég‚ð•ï‚ÝÉ‚µ‚°‚à‚È‚­‰º’…‚ðŒ©‚¹‚Ä•à‚­ @@ ¡@@—‚ÌŽq‚½‚¿‚ðƒRƒbƒ\ƒŠŽB‰eô‚»‚Ì‘¼ƒpƒ“ƒ`ƒ‰•ƒ€ƒlƒ`ƒ‰–žÚô@ @@ ¡ y–ìŠO˜Io“Šez--------------------------------------------™ @@ ¡ ŸŸŸ@Œ©‚ç‚ê‚邱‚Æ‚ÉŠì‚Ñ‚ðŠo‚¦‚é‘fl–º‚½‚¿‚ª @@ ¡@@@ ‘å’_‰ßŒƒ‚Ès“®‚ðŒJ‚è•Ô‚·B http://sibuya.mycountry.cc/?84fjdhnj2d £¥£¥£¥£¥£¥£¥£¥£¥£¥£¥££¥£¥£¥£¥£¥£¥£¥£¥ „ª„ª„ª„ª„ª„ª„ª„ªßƒGƒ“ƒ^[ƒeƒCƒƒ“ƒgƒ}ƒKƒWƒ“FFe-MAGAß„ª„ª„ª„ª„ª„ª„ª„ª ¡“–‹Ç‚̃[ƒ‹ƒ}ƒKƒWƒ“‚ÉŒfÚ‚³‚ê‚Ä‚¢‚éî•ñ‚Ì—˜—p‚ÉŠÖ‚µ‚Ä‚ÍA @@@@‚²w“ÇŽÒŒÂl‚ÌÓ”C‚É‚¨‚¢‚Ä‚²—˜—p‚¢‚½‚¾‚­‚±‚Æ‚ð‘O’ñ‚Æ‚µ‚Ä‚¢‚Ü‚·‚Ì‚Å @@@@‚²Ð‰îæ‚̃TƒCƒg‚É‚¨‚¯‚é‚¢‚©‚È‚éƒgƒ‰ƒuƒ‹‚⑹ŠQ‚ɑ΂µ‚Ä‚à @@@@“–‹Ç‚ł͈êØ‚ÌÓ”C‚𕉂¢‚©‚Ë‚Ü‚·B @@@@–”AŒfÚî•ñ‚ÉŠÖ‚µ‚Ä‚Ì‚¢‚©‚Ȃ邨–⇂¹‚ɑ΂µ‚Ä‚à‚¨“š‚¦‚µ‚©‚Ë‚Ü‚·‚Ì‚Å @@@@—\‚ß‚²—¹³‰º‚³‚¢B @@@@ @@@@ŒfÚ‚³‚ꂽ‹LŽ–‚̈ꕔ‚Ü‚½‚Í‘S•”‚ð‹–‰Â‚È‚­“]Ú‚·‚邱‚Æ‚ð‹ÖŽ~’v‚µ‚Ü‚·B EEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEE ¡w“ljðœ•û–@ @@@@w“ljðœ‚ð‚²Šó–]‚Ì•û‚ÍA‚¨Žè”‚Å‚·‚ª‰º‹L‚̃AƒhƒŒƒX‚æ‚胃OƒCƒ“‚µA @@@@‚²Ž©g‚Å‚¨Žè‘±‚«‰º‚³‚¢B http://york.vig-seet.to/e-maga/ „ª„ª„ª„ª„ª„ª„ª„ªßƒGƒ“ƒ^[ƒeƒCƒƒ“ƒgƒ}ƒKƒWƒ“FFe-MAGAß„ª„ª„ª„ª„ª„ª„ª„ª žžžžžžžžžžžžžžžžžžžžžžžžžžžžžžžžžž ‡‡‡‡‡‡‡‡‡‡‡‡‡‡‡‡‡‡‡‡‡‡‡‡‡‡‡‡‡‡‡‡‡‡‡‡ From ladis@linux-mips.org Thu Mar 17 15:35:13 2005 Received: with ECARTIS (v1.0.0; list netdev); Thu, 17 Mar 2005 15:35:19 -0800 (PST) Received: from smtp.seznam.cz (smtp.seznam.cz [212.80.76.43]) by oss.sgi.com (8.13.0/8.13.0) with SMTP id j2HNZCKa026147 for ; Thu, 17 Mar 2005 15:35:13 -0800 Received: (qmail 9623 invoked from network); 17 Mar 2005 23:35:06 -0000 Received: from unknown (HELO orphique) (Ladislav.Michl@62.77.73.201) by smtp.seznam.cz with SMTP; 17 Mar 2005 23:35:06 -0000 Received: from ladis by orphique with local (Exim 3.36 #1 (Debian)) id 1DC4WC-0003YV-00 for ; Fri, 18 Mar 2005 00:35:08 +0100 Date: Fri, 18 Mar 2005 00:35:08 +0100 To: Netdev Subject: [PATCH] smc91x: get/set eeprom Message-ID: <20050317233508.GA13623@orphique> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.5.6+20040907i From: Ladislav Michl X-Virus-Scanned: ClamAV 0.83/765/Thu Mar 17 00:42:45 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 293 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: ladis@linux-mips.org Precedence: bulk X-list: netdev Content-Length: 4897 Lines: 209 This is implementation of get_eeprom and set_eeprom ethtool's methods. Tested on custom OMAP based board. Comment and/or objections welcome as always. Best regards, ladis ===== drivers/net/smc91x.c 1.17 vs edited ===== --- 1.17/drivers/net/smc91x.c 2005-03-14 14:54:37 +01:00 +++ edited/drivers/net/smc91x.c 2005-03-18 00:23:13 +01:00 @@ -1727,6 +1727,160 @@ lp->msg_enable = level; } +/* + * Must be called with lp->lock locked. Caller must select bank 2 again. + */ +static int smc_read_eeprom_reg(unsigned long ioaddr, unsigned int reg) +{ + unsigned int timeout; + + SMC_SELECT_BANK(2); + SMC_SET_PTR(reg); + + SMC_SELECT_BANK(1); + SMC_SET_CTL(SMC_GET_CTL() | CTL_EEPROM_SELECT | CTL_RELOAD); + timeout = 100; + while ((SMC_GET_CTL() & CTL_RELOAD) && --timeout) + udelay(100); + if (timeout == 0) { + printk(KERN_INFO "%s: timeout reading EEPROM register %02x\n", + CARDNAME, reg); + return -EIO; + } + + return SMC_GET_GP(); +} + +/* + * Must be called with lp->lock locked. Caller must select bank 2 again. + */ +static int smc_write_eeprom_reg(unsigned long ioaddr, unsigned int reg, + unsigned int val) +{ + unsigned int timeout; + + SMC_SELECT_BANK(2); + SMC_SET_PTR(reg); + + SMC_SELECT_BANK(1); + SMC_SET_GP(val); + SMC_SET_CTL(SMC_GET_CTL() | CTL_EEPROM_SELECT | CTL_STORE); + timeout = 100; + while ((SMC_GET_CTL() & CTL_STORE) && --timeout) + udelay(100); + if (timeout == 0) { + printk(KERN_INFO "%s: timeout writing EEPROM register %02x\n", + CARDNAME, reg); + return -EIO; + } + + return 0; +} + +static int smc_ethtool_geteepromlen(struct net_device *dev) +{ + return SMC_EEPROM_SIZE; +} + +static int smc_ethtool_geteeprom(struct net_device *dev, + struct ethtool_eeprom *eeprom, u8 *data) +{ + + struct smc_local *lp = netdev_priv(dev); + unsigned long ioaddr = dev->base_addr; + unsigned reg; + int ret, len; + + len = eeprom->len; + reg = eeprom->offset >> 1; + eeprom->len = 0; + eeprom->magic = SMC_EEPROM_MAGIC; + + spin_lock_irq(&lp->lock); + + if (eeprom->offset & 1) { + ret = smc_read_eeprom_reg(ioaddr, reg++); + if (ret < 0) + goto out; + *data++ = ret >> 8; + eeprom->len++; + len--; + } + while (len) { + len -= 2; + ret = smc_read_eeprom_reg(ioaddr, reg++); + if (ret < 0) + goto out; + *data++ = ret & 0xff; + if (len < 0) { + eeprom->len++; + break; + } + *data++ = ret >> 8; + eeprom->len += 2; + } + + ret = 0; +out: + SMC_SELECT_BANK(2); + spin_unlock_irq(&lp->lock); + + return ret; +} + +static int smc_ethtool_seteeprom(struct net_device *dev, + struct ethtool_eeprom *eeprom, u8 *data) +{ + struct smc_local *lp = netdev_priv(dev); + unsigned long ioaddr = dev->base_addr; + unsigned reg; + int ret, len; + + if (eeprom->magic != SMC_EEPROM_MAGIC) + return -EINVAL; + + reg = eeprom->offset >> 1; + len = eeprom->len; + + spin_lock_irq(&lp->lock); + + if (eeprom->offset & 1) { + ret = smc_read_eeprom_reg(ioaddr, reg); + if (ret < 0) + goto out; + ret = (ret & 0xff) | ((int)*data++ << 8); + ret = smc_write_eeprom_reg(ioaddr, reg++, ret); + if (ret < 0) + goto out; + len--; + } + while (len) { + len -= 2; + if (len < 0) { + ret = smc_read_eeprom_reg(ioaddr, reg); + if (ret < 0) + goto out; + ret = (ret & 0xff) | *data; + ret = smc_write_eeprom_reg(ioaddr, reg, ret); + if (ret < 0) + goto out; + break; + } + ret = *data++; + ret |= (int)*data++ << 8; + ret = smc_write_eeprom_reg(ioaddr, reg++, ret); + if (ret < 0) + goto out; + } + + ret = 0; +out: + SMC_SELECT_BANK(2); + spin_unlock_irq(&lp->lock); + + return ret; +} + static struct ethtool_ops smc_ethtool_ops = { .get_settings = smc_ethtool_getsettings, .set_settings = smc_ethtool_setsettings, @@ -1736,8 +1890,9 @@ .set_msglevel = smc_ethtool_setmsglevel, .nway_reset = smc_ethtool_nwayreset, .get_link = ethtool_op_get_link, -// .get_eeprom = smc_ethtool_geteeprom, -// .set_eeprom = smc_ethtool_seteeprom, + .get_eeprom_len = smc_ethtool_geteepromlen, + .get_eeprom = smc_ethtool_geteeprom, + .set_eeprom = smc_ethtool_seteeprom, }; /* ===== drivers/net/smc91x.h 1.14 vs edited ===== --- 1.14/drivers/net/smc91x.h 2005-03-14 14:54:37 +01:00 +++ edited/drivers/net/smc91x.h 2005-03-17 23:33:13 +01:00 @@ -404,6 +404,13 @@ #define SMC_DATA_EXTENT (4) /* + * 128 bytes serial EEPROM + */ +#define SMC_EEPROM_SIZE 128 + +#define SMC_EEPROM_MAGIC 0x3A8EBEEF + +/* . Bank Select Register: . . yyyy yyyy 0000 00xx @@ -834,6 +841,8 @@ #define SMC_GET_CONFIG() SMC_inw( ioaddr, CONFIG_REG ) #define SMC_SET_CONFIG(x) SMC_outw( x, ioaddr, CONFIG_REG ) #define SMC_GET_COUNTER() SMC_inw( ioaddr, COUNTER_REG ) +#define SMC_GET_GP() SMC_inw( ioaddr, GP_REG ) +#define SMC_SET_GP(x) SMC_outw( x, ioaddr, GP_REG ) #define SMC_GET_CTL() SMC_inw( ioaddr, CTL_REG ) #define SMC_SET_CTL(x) SMC_outw( x, ioaddr, CTL_REG ) #define SMC_GET_MII() SMC_inw( ioaddr, MII_REG ) From davem@davemloft.net Thu Mar 17 20:15:10 2005 Received: with ECARTIS (v1.0.0; list netdev); Thu, 17 Mar 2005 20:15:15 -0800 (PST) Received: from cheetah.davemloft.net (mail@dsl027-180-174.sfo1.dsl.speakeasy.net [216.27.180.174]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j2I4F9Hr012270 for ; Thu, 17 Mar 2005 20:15:10 -0800 Received: from localhost ([127.0.0.1] helo=cheetah.davemloft.net ident=davem) by cheetah.davemloft.net with smtp (Exim 3.36 #1 (Debian)) id 1DC8qd-0001pS-00; Thu, 17 Mar 2005 20:12:31 -0800 Date: Thu, 17 Mar 2005 20:12:31 -0800 From: "David S. Miller" To: Stephen Hemminger Cc: baruch@ev-en.org, netdev@oss.sgi.com Subject: Re: [RFC] TCP congestion schedulers Message-Id: <20050317201231.6d575e0b.davem@davemloft.net> In-Reply-To: <20050314151726.532af90d@dxpl.pdx.osdl.net> References: <421CF5E5.1060606@ev-en.org> <20050223135732.39e62c6c.davem@davemloft.net> <421D1E66.5090301@osdl.org> <421D30FA.1060900@ev-en.org> <20050225120814.5fa77b13@dxpl.pdx.osdl.net> <20050309210442.3e9786a6.davem@davemloft.net> <4230288F.1030202@ev-en.org> <20050310182629.1eab09ec.davem@davemloft.net> <20050311120054.4bbf675a@dxpl.pdx.osdl.net> <20050311201011.360c00da.davem@davemloft.net> <20050314151726.532af90d@dxpl.pdx.osdl.net> X-Mailer: Sylpheed version 1.0.1 (GTK+ 1.2.10; sparc-unknown-linux-gnu) X-Face: "_;p5u5aPsO,_Vsx"^v-pEq09'CU4&Dc1$fQExov$62l60cgCc%FnIwD=.UF^a>?5'9Kn[;433QFVV9M..2eN.@4ZWPGbdi<=?[:T>y?SD(R*-3It"Vj:)"dP Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV 0.83/765/Thu Mar 17 00:42:45 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 294 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: davem@davemloft.net Precedence: bulk X-list: netdev Content-Length: 636 Lines: 19 On Mon, 14 Mar 2005 15:17:26 -0800 Stephen Hemminger wrote: > +/* Hook for advanced congestion control */ > + struct tcp_ca_type *ca_proto; > +#define TCP_CA_PRIV_SIZE 48 > + u8 *ca_priv[TCP_CA_PRIV_SIZE]; An array of 48 pointers to "u8" eh? :-) It happens to work, but you're using too much space (specifically: 48 * sizeof(u8 *)) as a side effect. Otherwise, the only comment I have is that we lose the tcp_diag info. Maybe create a "tcpdiag_put" method in there so we can retain that. I'm also not so religious anymore about retaining the existing sysctl functionality to enable/disable ca algs. From davem@davemloft.net Thu Mar 17 20:35:38 2005 Received: with ECARTIS (v1.0.0; list netdev); Thu, 17 Mar 2005 20:35:44 -0800 (PST) Received: from cheetah.davemloft.net (mail@dsl027-180-174.sfo1.dsl.speakeasy.net [216.27.180.174]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j2I4ZbBv016854 for ; Thu, 17 Mar 2005 20:35:38 -0800 Received: from localhost ([127.0.0.1] helo=cheetah.davemloft.net ident=davem) by cheetah.davemloft.net with smtp (Exim 3.36 #1 (Debian)) id 1DC99z-0001vm-00; Thu, 17 Mar 2005 20:32:31 -0800 Date: Thu, 17 Mar 2005 20:32:31 -0800 From: "David S. Miller" To: Herbert Xu Cc: kaber@trash.net, netdev@oss.sgi.com Subject: Re: IPsec xfrm resolution Message-Id: <20050317203231.1b649f60.davem@davemloft.net> In-Reply-To: <20050219092314.GA8153@gondor.apana.org.au> References: <20050209085251.GA9030@gondor.apana.org.au> <420B9DF1.3020704@trash.net> <20050210202810.GA1609@gondor.apana.org.au> <42144C3F.2060501@trash.net> <20050217091137.GA9476@gondor.apana.org.au> <42152841.5000707@trash.net> <20050218100854.GA19427@gondor.apana.org.au> <4216D6B4.5070901@trash.net> <20050219092314.GA8153@gondor.apana.org.au> X-Mailer: Sylpheed version 1.0.1 (GTK+ 1.2.10; sparc-unknown-linux-gnu) X-Face: "_;p5u5aPsO,_Vsx"^v-pEq09'CU4&Dc1$fQExov$62l60cgCc%FnIwD=.UF^a>?5'9Kn[;433QFVV9M..2eN.@4ZWPGbdi<=?[:T>y?SD(R*-3It"Vj:)"dP Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV 0.83/765/Thu Mar 17 00:42:45 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 295 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: davem@davemloft.net Precedence: bulk X-list: netdev Content-Length: 1044 Lines: 25 On Sat, 19 Feb 2005 20:23:14 +1100 Herbert Xu wrote: > 1) The application must be able to react to MTU changes anyway. This would seem to be the case, but keep in mind that if we're going through all this trouble to improve this quality of implementation issue, we should really get this right. On a more practical side, let's use an example to drive home a point. Say you're using DNS-sec or something like that for all outgoing connections, and you're using non-blocking sockets for all of your stuff. Every time I use TCP to talk to a unique host, we're going to mis-estimate the MTU, get an entire send queue full of too-large packets, then have to resegment the entire thing once the SA is resolved. We'll eat a retransmit every such connection as well. And actually, we'll have to resend about 4 frames (depends upon what the initial send cwnd is set to, it's usually 4 for ethernet size MTUs). Anyways, in truth I'm being very picky :-) Is there any prototype or beginnings of these ideas anywhere? From herbert@gondor.apana.org.au Thu Mar 17 22:24:58 2005 Received: with ECARTIS (v1.0.0; list netdev); Thu, 17 Mar 2005 22:25:05 -0800 (PST) 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 j2I6OuZA023048 for ; Thu, 17 Mar 2005 22:24:57 -0800 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 1DCAuL-0002Vb-00; Fri, 18 Mar 2005 17:24:29 +1100 Received: from herbert by gondolin.me.apana.org.au with local (Exim 3.36 #1 (Debian)) id 1DCAtt-00019a-00; Fri, 18 Mar 2005 17:24:01 +1100 Date: Fri, 18 Mar 2005 17:24:01 +1100 To: "David S. Miller" Cc: kaber@trash.net, netdev@oss.sgi.com Subject: Re: IPsec xfrm resolution Message-ID: <20050318062401.GA4417@gondor.apana.org.au> References: <20050209085251.GA9030@gondor.apana.org.au> <420B9DF1.3020704@trash.net> <20050210202810.GA1609@gondor.apana.org.au> <42144C3F.2060501@trash.net> <20050217091137.GA9476@gondor.apana.org.au> <42152841.5000707@trash.net> <20050218100854.GA19427@gondor.apana.org.au> <4216D6B4.5070901@trash.net> <20050219092314.GA8153@gondor.apana.org.au> <20050317203231.1b649f60.davem@davemloft.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20050317203231.1b649f60.davem@davemloft.net> User-Agent: Mutt/1.5.6+20040907i From: Herbert Xu X-Virus-Scanned: ClamAV 0.83/765/Thu Mar 17 00:42:45 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 297 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: herbert@gondor.apana.org.au Precedence: bulk X-list: netdev Content-Length: 997 Lines: 27 On Thu, Mar 17, 2005 at 08:32:31PM -0800, David S. Miller wrote: > On Sat, 19 Feb 2005 20:23:14 +1100 > Herbert Xu wrote: > > > 1) The application must be able to react to MTU changes anyway. > > This would seem to be the case, but keep in mind that if > we're going through all this trouble to improve this > quality of implementation issue, we should really get this > right. Don't worry, further down in that thread we agreed that optional SAs will simply not be added so the MTU estimate will be correct unless it's changed by PMTU later on. > Anyways, in truth I'm being very picky :-) Is there any prototype > or beginnings of these ideas anywhere? Not yet. However, once the MTU stuff is out of the way I would like to work on this. Cheers, -- Visit Openswan at http://www.openswan.org/ Email: Herbert Xu ~{PmV>HI~} Home Page: http://gondor.apana.org.au/~herbert/ PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt From herbert@gondor.apana.org.au Fri Mar 18 01:04:38 2005 Received: with ECARTIS (v1.0.0; list netdev); Fri, 18 Mar 2005 01:04:47 -0800 (PST) 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 j2I94axk002550 for ; Fri, 18 Mar 2005 01:04:37 -0800 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 1DCDOL-0003Wh-00; Fri, 18 Mar 2005 20:03:37 +1100 Received: from herbert by gondolin.me.apana.org.au with local (Exim 3.36 #1 (Debian)) id 1DCDNu-0007PY-00; Fri, 18 Mar 2005 20:03:10 +1100 Date: Fri, 18 Mar 2005 20:03:10 +1100 To: "David S. Miller" Cc: Alexey Kuznetsov , YOSHIFUJI Hideaki , Patrick McHardy , netdev@oss.sgi.com Subject: [21/*] [IPv4] Fix MTU check in ipmr_queue_xmit Message-ID: <20050318090310.GA28443@gondor.apana.org.au> References: <20050214221433.GB18465@gondor.apana.org.au> <20050214221607.GC18465@gondor.apana.org.au> <20050306213214.7d8a143d.davem@davemloft.net> <20050307103536.GB7137@gondor.apana.org.au> <20050308102741.GA23468@gondor.apana.org.au> <20050314102614.GA9610@gondor.apana.org.au> <20050314105313.GA21001@gondor.apana.org.au> <20050314111002.GA29156@gondor.apana.org.au> <20050315091904.GA6256@gondor.apana.org.au> <20050315095837.GA7130@gondor.apana.org.au> Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="Qxx1br4bt0+wmkIi" Content-Disposition: inline In-Reply-To: <20050315095837.GA7130@gondor.apana.org.au> User-Agent: Mutt/1.5.6+20040907i From: Herbert Xu X-Virus-Scanned: ClamAV 0.83/765/Thu Mar 17 00:42:45 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 298 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: herbert@gondor.apana.org.au Precedence: bulk X-list: netdev Content-Length: 1424 Lines: 45 --Qxx1br4bt0+wmkIi Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Hi Dave: Somehow I missed four files with dst_pmtu usages in them. I'm going to split them along the sames lines I did before: bug fixes and then the trivial changes. Here is a patch that replaces dst_pmtu with dst_pmtu in ipmr.c since this is straight IPIP tunneling equivalent to what we have in ipip.c. As it is we may send ICMP packets when IPsec is present which is exactly what the comment says that we shouldn't do. 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 --Qxx1br4bt0+wmkIi Content-Type: text/plain; charset=us-ascii Content-Disposition: attachment; filename=xfrm-21 ===== net/ipv4/ipmr.c 1.46 vs edited ===== --- 1.46/net/ipv4/ipmr.c 2005-01-14 15:41:05 +11:00 +++ edited/net/ipv4/ipmr.c 2005-03-18 19:56:33 +11:00 @@ -1171,7 +1171,7 @@ dev = rt->u.dst.dev; - if (skb->len+encap > dst_pmtu(&rt->u.dst) && (ntohs(iph->frag_off) & IP_DF)) { + if (skb->len+encap > dst_mtu(&rt->u.dst) && (ntohs(iph->frag_off) & IP_DF)) { /* Do not fragment multicasts. Alas, IPv4 does not allow to send ICMP, so that packets will disappear to blackhole. --Qxx1br4bt0+wmkIi-- From s.schmidt@mcbone.net Fri Mar 18 01:11:49 2005 Received: with ECARTIS (v1.0.0; list netdev); Fri, 18 Mar 2005 01:11:54 -0800 (PST) Received: from mout0.freenet.de (mout0.freenet.de [194.97.50.131]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j2I9BmtX003332 for ; Fri, 18 Mar 2005 01:11:49 -0800 Received: from [194.97.50.136] (helo=mx3.freenet.de) by mout0.freenet.de with esmtpa (Exim 4.51) id 1DCDW8-0005WS-MP; Fri, 18 Mar 2005 10:11:40 +0100 Received: from giscard.mcbone.net ([194.97.7.90]) by mx3.freenet.de with esmtps (TLSv1:AES256-SHA:256) (Exim 4.43 #13) id 1DCDW8-0007qx-KX; Fri, 18 Mar 2005 10:11:40 +0100 Received: from schmidt by giscard.mcbone.net with local (Exim 4.50) id 1DCDW8-0008Tq-3W; Fri, 18 Mar 2005 10:11:40 +0100 Date: Fri, 18 Mar 2005 10:11:40 +0100 From: Stefan Schmidt To: Andrew Morton Cc: Stefan Schmidt , netdev@oss.sgi.com Subject: Re: Fw: 2.6.11-mm2 weird ethernet RTTs Message-ID: <20050318091140.GE30259@giscard.mcbone.net> References: <20050317115254.4f8e462a.akpm@osdl.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20050317115254.4f8e462a.akpm@osdl.org> User-Agent: Mutt/1.5.6+20040907i X-Virus-Scanned: ClamAV 0.83/765/Thu Mar 17 00:42:45 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 299 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: s.schmidt@mcbone.net Precedence: bulk X-list: netdev Content-Length: 683 Lines: 15 On Thu, Mar 17, 2005 at 11:52:54AM -0800, Andrew Morton wrote: > Thanks, Stefan. > > I'm not aware of any changes which would cause this. Generally -mm's > networking is the same as Linus's. Could you test Linus's latest tree? > (-rc1 should be out very soon, so that would be appropriate) 2.6.10-mm1 was the kernel i ran before 2.6.11-mm2 on this machine which did not show this behaviour. I will try the latest vanilla as soon as i'm in office. Perhaps this problem is e1000-driver inflicted, i am using it as a module - will try latest vanilla with the same setup. Stefan -- - The truth is usually just an excuse for a lack of imagination. Garak, "Improbable Cause", ST-DS9 From herbert@gondor.apana.org.au Fri Mar 18 01:12:22 2005 Received: with ECARTIS (v1.0.0; list netdev); Fri, 18 Mar 2005 01:12:30 -0800 (PST) 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 j2I9CKL7003414 for ; Fri, 18 Mar 2005 01:12:21 -0800 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 1DCDW8-0003eB-00; Fri, 18 Mar 2005 20:11:40 +1100 Received: from herbert by gondolin.me.apana.org.au with local (Exim 3.36 #1 (Debian)) id 1DCDVx-0007TO-00; Fri, 18 Mar 2005 20:11:29 +1100 Date: Fri, 18 Mar 2005 20:11:29 +1100 To: "David S. Miller" Cc: Alexey Kuznetsov , YOSHIFUJI Hideaki , Patrick McHardy , netdev@oss.sgi.com Subject: [22/*] [NETFILTER] Use correct IPsec MTU in TCPMSS Message-ID: <20050318091129.GA28658@gondor.apana.org.au> References: <20050214221607.GC18465@gondor.apana.org.au> <20050306213214.7d8a143d.davem@davemloft.net> <20050307103536.GB7137@gondor.apana.org.au> <20050308102741.GA23468@gondor.apana.org.au> <20050314102614.GA9610@gondor.apana.org.au> <20050314105313.GA21001@gondor.apana.org.au> <20050314111002.GA29156@gondor.apana.org.au> <20050315091904.GA6256@gondor.apana.org.au> <20050315095837.GA7130@gondor.apana.org.au> <20050318090310.GA28443@gondor.apana.org.au> Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="sdtB3X0nJg68CQEu" Content-Disposition: inline In-Reply-To: <20050318090310.GA28443@gondor.apana.org.au> User-Agent: Mutt/1.5.6+20040907i From: Herbert Xu X-Virus-Scanned: ClamAV 0.83/765/Thu Mar 17 00:42:45 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 300 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: herbert@gondor.apana.org.au Precedence: bulk X-list: netdev Content-Length: 2010 Lines: 57 --sdtB3X0nJg68CQEu Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Hi Dave: This patch makes ipt_TCPMSS use the correct MTU value for clamping. This is a bit tricky actually since TCPMSS can be used in FORWARD, LOCAL_OUT as well as POST_ROUTING. In the first two cases we haven't performed IPsec yet so dst_mtu obviously does the right thing. As it is, POST_ROUTING is performed after xfrm_output so MSS clamping is useless there. With Patrick's IPsec netfilter stuff, there will be a POST_ROUTING processing before IPsec processing, in which case dst_mtu also returns exactly what we want. Signed-off-by: Herbert Xu BTW Patrick, how is the IPsec netfilter stuff going? 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 --sdtB3X0nJg68CQEu Content-Type: text/plain; charset=us-ascii Content-Disposition: attachment; filename=xfrm-22 ===== net/ipv4/netfilter/ipt_TCPMSS.c 1.13 vs edited ===== --- 1.13/net/ipv4/netfilter/ipt_TCPMSS.c 2004-06-04 15:04:05 +10:00 +++ edited/net/ipv4/netfilter/ipt_TCPMSS.c 2005-03-18 19:56:34 +11:00 @@ -87,14 +87,14 @@ return NF_DROP; /* or IPT_CONTINUE ?? */ } - if(dst_pmtu((*pskb)->dst) <= (sizeof(struct iphdr) + sizeof(struct tcphdr))) { + if(dst_mtu((*pskb)->dst) <= (sizeof(struct iphdr) + sizeof(struct tcphdr))) { if (net_ratelimit()) printk(KERN_ERR - "ipt_tcpmss_target: unknown or invalid path-MTU (%d)\n", dst_pmtu((*pskb)->dst)); + "ipt_tcpmss_target: unknown or invalid path-MTU (%d)\n", dst_mtu((*pskb)->dst)); return NF_DROP; /* or IPT_CONTINUE ?? */ } - newmss = dst_pmtu((*pskb)->dst) - sizeof(struct iphdr) - sizeof(struct tcphdr); + newmss = dst_mtu((*pskb)->dst) - sizeof(struct iphdr) - sizeof(struct tcphdr); } else newmss = tcpmssinfo->mss; --sdtB3X0nJg68CQEu-- From herbert@gondor.apana.org.au Fri Mar 18 01:20:28 2005 Received: with ECARTIS (v1.0.0; list netdev); Fri, 18 Mar 2005 01:20:35 -0800 (PST) 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 j2I9KPni004683 for ; Fri, 18 Mar 2005 01:20:26 -0800 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 1DCDds-0003km-00; Fri, 18 Mar 2005 20:19:40 +1100 Received: from herbert by gondolin.me.apana.org.au with local (Exim 3.36 #1 (Debian)) id 1DCDdW-0007XS-00; Fri, 18 Mar 2005 20:19:18 +1100 Date: Fri, 18 Mar 2005 20:19:18 +1100 To: "David S. Miller" Cc: Alexey Kuznetsov , YOSHIFUJI Hideaki , Patrick McHardy , netdev@oss.sgi.com Subject: [23/*] [IPV4] Kill remaining unnecessary uses of dst_pmtu Message-ID: <20050318091918.GA28944@gondor.apana.org.au> References: <20050306213214.7d8a143d.davem@davemloft.net> <20050307103536.GB7137@gondor.apana.org.au> <20050308102741.GA23468@gondor.apana.org.au> <20050314102614.GA9610@gondor.apana.org.au> <20050314105313.GA21001@gondor.apana.org.au> <20050314111002.GA29156@gondor.apana.org.au> <20050315091904.GA6256@gondor.apana.org.au> <20050315095837.GA7130@gondor.apana.org.au> <20050318090310.GA28443@gondor.apana.org.au> <20050318091129.GA28658@gondor.apana.org.au> Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="rwEMma7ioTxnRzrJ" Content-Disposition: inline In-Reply-To: <20050318091129.GA28658@gondor.apana.org.au> User-Agent: Mutt/1.5.6+20040907i From: Herbert Xu X-Virus-Scanned: ClamAV 0.83/765/Thu Mar 17 00:42:45 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 301 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: herbert@gondor.apana.org.au Precedence: bulk X-list: netdev Content-Length: 3397 Lines: 98 --rwEMma7ioTxnRzrJ Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Hi Dave: Once again here is a couple of trivial dst_pmtu/dst_mtu replacements. In both locations, we can only have simple dst entries which means that dst == dst->path. BTW, this is the rule that we should apply in future for uses of dst_mtu/dst_pmtu (or other metrics on dst). If the only dst's that can appear are simple dst's (dst == dst->path), then we should use dst_mtu or dst_metric. If dst != dst->path, then whoever is writing the code will need to think about which of dst or dst->path is the right one. In most instances dst will be the one. However, as we have seen in ip_append_data, dst->path may be needed rarely. In particular, if we're doing fragmentation immediately after IPsec, then you may need it. Signed-off-by: Herbert Xu Cheers, -- Visit Openswan at http://www.openswan.org/ Email: Herbert Xu ~{PmV>HI~} Home Page: http://gondor.apana.org.au/~herbert/ PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt --rwEMma7ioTxnRzrJ Content-Type: text/plain; charset=us-ascii Content-Disposition: attachment; filename=xfrm-23 ===== net/ipv4/ipvs/ip_vs_xmit.c 1.12 vs edited ===== --- 1.12/net/ipv4/ipvs/ip_vs_xmit.c 2005-03-11 13:17:32 +11:00 +++ edited/net/ipv4/ipvs/ip_vs_xmit.c 2005-03-18 19:56:34 +11:00 @@ -178,7 +178,7 @@ } /* MTU checking */ - mtu = dst_pmtu(&rt->u.dst); + mtu = dst_mtu(&rt->u.dst); if ((skb->len > mtu) && (iph->frag_off&__constant_htons(IP_DF))) { ip_rt_put(rt); icmp_send(skb, ICMP_DEST_UNREACH,ICMP_FRAG_NEEDED, htonl(mtu)); @@ -245,7 +245,7 @@ goto tx_error_icmp; /* MTU checking */ - mtu = dst_pmtu(&rt->u.dst); + mtu = dst_mtu(&rt->u.dst); if ((skb->len > mtu) && (iph->frag_off&__constant_htons(IP_DF))) { ip_rt_put(rt); icmp_send(skb, ICMP_DEST_UNREACH,ICMP_FRAG_NEEDED, htonl(mtu)); @@ -342,7 +342,7 @@ tdev = rt->u.dst.dev; - mtu = dst_pmtu(&rt->u.dst) - sizeof(struct iphdr); + mtu = dst_mtu(&rt->u.dst) - sizeof(struct iphdr); if (mtu < 68) { ip_rt_put(rt); IP_VS_DBG_RL("ip_vs_tunnel_xmit(): mtu less than 68\n"); @@ -445,7 +445,7 @@ goto tx_error_icmp; /* MTU checking */ - mtu = dst_pmtu(&rt->u.dst); + mtu = dst_mtu(&rt->u.dst); if ((iph->frag_off&__constant_htons(IP_DF)) && skb->len > mtu) { icmp_send(skb, ICMP_DEST_UNREACH,ICMP_FRAG_NEEDED, htonl(mtu)); ip_rt_put(rt); @@ -520,7 +520,7 @@ goto tx_error_icmp; /* MTU checking */ - mtu = dst_pmtu(&rt->u.dst); + mtu = dst_mtu(&rt->u.dst); if ((skb->len > mtu) && (skb->nh.iph->frag_off&__constant_htons(IP_DF))) { ip_rt_put(rt); icmp_send(skb, ICMP_DEST_UNREACH, ICMP_FRAG_NEEDED, htonl(mtu)); ===== net/ipv4/netfilter/ip_conntrack_standalone.c 1.66 vs edited ===== --- 1.66/net/ipv4/netfilter/ip_conntrack_standalone.c 2005-03-04 09:17:07 +11:00 +++ edited/net/ipv4/netfilter/ip_conntrack_standalone.c 2005-03-18 19:56:34 +11:00 @@ -457,7 +457,7 @@ /* Local packets are never produced too large for their interface. We degfragment them at LOCAL_OUT, however, so we have to refragment them here. */ - if ((*pskb)->len > dst_pmtu(&rt->u.dst) && + if ((*pskb)->len > dst_mtu(&rt->u.dst) && !skb_shinfo(*pskb)->tso_size) { /* No hook can be after us, so this should be OK. */ ip_fragment(*pskb, okfn); --rwEMma7ioTxnRzrJ-- From colin@colino.net Fri Mar 18 01:29:06 2005 Received: with ECARTIS (v1.0.0; list netdev); Fri, 18 Mar 2005 01:29:15 -0800 (PST) Received: from paperstreet.colino.net (colino.net [213.41.131.56]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j2I9T5FM005504 for ; Fri, 18 Mar 2005 01:29:06 -0800 Received: by paperstreet.colino.net (Postfix, from userid 1015) id 26976101A0; Fri, 18 Mar 2005 10:28:58 +0100 (CET) Received: from jack.colino.net (jack.colino.net [192.168.0.11]) by paperstreet.colino.net (Postfix) with ESMTP id 4985C10183 for ; Fri, 18 Mar 2005 10:28:56 +0100 (CET) Date: Fri, 18 Mar 2005 10:28:55 +0100 From: Colin Leroy To: netdev@oss.sgi.com Subject: Missing hunk in drivers/usb/Makefile Message-ID: <20050318102855.5c6e534e@jack.colino.net> X-Mailer: Sylpheed-Claws 1.0.3cvs2.4 (GTK+ 2.6.1; powerpc-unknown-linux-gnu) X-Face: Fy:*XpRna1/tz}cJ@O'0^:qYs:8b[Rg`*8,+o^[fI?<%5LeB,Xz8ZJK[r7V0hBs8G)*&C+XA0qHoR=LoTohe@7X5K$A-@cN6n~~J/]+{[)E4h'lK$13WQf$.R+Pi;E09tk&{t|;~dakRD%CLHrk6m!?gA,5|Sb=fJ=>[9#n1Bu8?VngkVM4{'^'V_qgdA.8yn3) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV 0.83/765/Thu Mar 17 00:42:45 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 302 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: colin@colino.net Precedence: bulk X-list: netdev Content-Length: 608 Lines: 17 Hi, I see there's been a driver for zd1201 added in drivers/usb/net/. There's a hunk missing in drivers/usb/Makefile, the driver doesn't get built in nothing else in drivers/usb/net is configured in : Signed-off-by: Colin Leroy --- a/drivers/usb/Makefile 2005-03-18 10:26:38.000000000 +0100 +++ b/drivers/usb/Makefile 2005-03-18 10:27:22.000000000 +0100 @@ -50,6 +50,7 @@ obj-$(CONFIG_USB_PEGASUS) += net/ obj-$(CONFIG_USB_RTL8150) += net/ obj-$(CONFIG_USB_USBNET) += net/ +obj-$(CONFIG_USB_ZD1201) += net/ obj-$(CONFIG_USB_HPUSBSCSI) += image/ obj-$(CONFIG_USB_MDC800) += image/ From herbert@gondor.apana.org.au Fri Mar 18 02:09:13 2005 Received: with ECARTIS (v1.0.0; list netdev); Fri, 18 Mar 2005 02:09:21 -0800 (PST) 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 j2IA9B29009509 for ; Fri, 18 Mar 2005 02:09:12 -0800 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 1DCEP2-0004BG-00; Fri, 18 Mar 2005 21:08:24 +1100 Received: from herbert by gondolin.me.apana.org.au with local (Exim 3.36 #1 (Debian)) id 1DCEOb-0007f6-00; Fri, 18 Mar 2005 21:07:57 +1100 Date: Fri, 18 Mar 2005 21:07:57 +1100 To: "David S. Miller" Cc: Alexey Kuznetsov , YOSHIFUJI Hideaki , Patrick McHardy , netdev@oss.sgi.com Subject: [24/*] [IPSEC] Get ttl from child instead of path Message-ID: <20050318100757.GA29433@gondor.apana.org.au> References: <20050307103536.GB7137@gondor.apana.org.au> <20050308102741.GA23468@gondor.apana.org.au> <20050314102614.GA9610@gondor.apana.org.au> <20050314105313.GA21001@gondor.apana.org.au> <20050314111002.GA29156@gondor.apana.org.au> <20050315091904.GA6256@gondor.apana.org.au> <20050315095837.GA7130@gondor.apana.org.au> <20050318090310.GA28443@gondor.apana.org.au> <20050318091129.GA28658@gondor.apana.org.au> <20050318091918.GA28944@gondor.apana.org.au> Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="CE+1k2dSO48ffgeK" Content-Disposition: inline In-Reply-To: <20050318091918.GA28944@gondor.apana.org.au> User-Agent: Mutt/1.5.6+20040907i From: Herbert Xu X-Virus-Scanned: ClamAV 0.83/765/Thu Mar 17 00:42:45 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 303 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: herbert@gondor.apana.org.au Precedence: bulk X-list: netdev Content-Length: 1930 Lines: 56 --CE+1k2dSO48ffgeK Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Hi Dave: Now that dst_pmtu is almost gone let's do the same to dst_path_metric. I've only found one legitimate use of it and that's the one that was recently added in dst_allfrag. This patch makes xfrm4_encap/xfrm6_encap use dst->child instead of dst->path so that we choose the correct route to get the hoplimit from when nested tunnels are present. For simple tunnels dst->child == dst->path so there is no change. Signed-off-by: Herbert Xu Cheers, -- Visit Openswan at http://www.openswan.org/ Email: Herbert Xu ~{PmV>HI~} Home Page: http://gondor.apana.org.au/~herbert/ PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt --CE+1k2dSO48ffgeK Content-Type: text/plain; charset=us-ascii Content-Disposition: attachment; filename=xfrm-24 ===== net/ipv4/xfrm4_output.c 1.9 vs edited ===== --- 1.9/net/ipv4/xfrm4_output.c 2005-03-15 16:38:41 +11:00 +++ edited/net/ipv4/xfrm4_output.c 2005-03-18 21:02:33 +11:00 @@ -58,7 +58,7 @@ if (!top_iph->frag_off) __ip_select_ident(top_iph, dst, 0); - top_iph->ttl = dst_path_metric(dst, RTAX_HOPLIMIT); + top_iph->ttl = dst_metric(dst->child, RTAX_HOPLIMIT); top_iph->saddr = x->props.saddr.a4; top_iph->daddr = x->id.daddr.a4; ===== net/ipv6/xfrm6_output.c 1.10 vs edited ===== --- 1.10/net/ipv6/xfrm6_output.c 2005-03-15 16:38:41 +11:00 +++ edited/net/ipv6/xfrm6_output.c 2005-03-18 21:02:46 +11:00 @@ -69,7 +69,7 @@ dsfield &= ~INET_ECN_MASK; ipv6_change_dsfield(top_iph, 0, dsfield); top_iph->nexthdr = IPPROTO_IPV6; - top_iph->hop_limit = dst_path_metric(dst, RTAX_HOPLIMIT); + top_iph->hop_limit = dst_metric(dst->child, RTAX_HOPLIMIT); ipv6_addr_copy(&top_iph->saddr, (struct in6_addr *)&x->props.saddr); ipv6_addr_copy(&top_iph->daddr, (struct in6_addr *)&x->id.daddr); } --CE+1k2dSO48ffgeK-- From herbert@gondor.apana.org.au Fri Mar 18 02:11:55 2005 Received: with ECARTIS (v1.0.0; list netdev); Fri, 18 Mar 2005 02:12:00 -0800 (PST) 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 j2IABsrO010126 for ; Fri, 18 Mar 2005 02:11:54 -0800 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 1DCES4-0004FS-00; Fri, 18 Mar 2005 21:11:32 +1100 Received: from herbert by gondolin.me.apana.org.au with local (Exim 3.36 #1 (Debian)) id 1DCERy-0007hS-00; Fri, 18 Mar 2005 21:11:26 +1100 Date: Fri, 18 Mar 2005 21:11:26 +1100 To: "David S. Miller" Cc: Alexey Kuznetsov , YOSHIFUJI Hideaki , Patrick McHardy , netdev@oss.sgi.com Subject: [25/*] [NET] Kill unnecessary uses of dst_path_metric Message-ID: <20050318101126.GA29583@gondor.apana.org.au> References: <20050308102741.GA23468@gondor.apana.org.au> <20050314102614.GA9610@gondor.apana.org.au> <20050314105313.GA21001@gondor.apana.org.au> <20050314111002.GA29156@gondor.apana.org.au> <20050315091904.GA6256@gondor.apana.org.au> <20050315095837.GA7130@gondor.apana.org.au> <20050318090310.GA28443@gondor.apana.org.au> <20050318091129.GA28658@gondor.apana.org.au> <20050318091918.GA28944@gondor.apana.org.au> <20050318100757.GA29433@gondor.apana.org.au> Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="zhXaljGHf11kAtnf" Content-Disposition: inline In-Reply-To: <20050318100757.GA29433@gondor.apana.org.au> User-Agent: Mutt/1.5.6+20040907i From: Herbert Xu X-Virus-Scanned: ClamAV 0.83/765/Thu Mar 17 00:42:45 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 304 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: herbert@gondor.apana.org.au Precedence: bulk X-list: netdev Content-Length: 1408 Lines: 46 --zhXaljGHf11kAtnf Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Hi Dave: This gets rid of the last unnecessary use of dst_path_metric. In decnet dst->path is always equal to dst. 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 --zhXaljGHf11kAtnf Content-Type: text/plain; charset=us-ascii Content-Disposition: attachment; filename=xfrm-25 ===== net/decnet/af_decnet.c 1.51 vs edited ===== --- 1.51/net/decnet/af_decnet.c 2005-03-16 09:50:25 +11:00 +++ edited/net/decnet/af_decnet.c 2005-03-18 21:01:24 +11:00 @@ -811,7 +811,7 @@ return -EINVAL; scp->state = DN_CC; - scp->segsize_loc = dst_path_metric(__sk_dst_get(sk), RTAX_ADVMSS); + scp->segsize_loc = dst_metric(__sk_dst_get(sk), RTAX_ADVMSS); dn_send_conn_conf(sk, allocation); prepare_to_wait(sk->sk_sleep, &wait, TASK_INTERRUPTIBLE); @@ -940,7 +940,7 @@ sk->sk_route_caps = sk->sk_dst_cache->dev->features; sock->state = SS_CONNECTING; scp->state = DN_CI; - scp->segsize_loc = dst_path_metric(sk->sk_dst_cache, RTAX_ADVMSS); + scp->segsize_loc = dst_metric(sk->sk_dst_cache, RTAX_ADVMSS); dn_nsp_send_conninit(sk, NSP_CI); err = -EINPROGRESS; --zhXaljGHf11kAtnf-- From colin@colino.net Fri Mar 18 02:43:33 2005 Received: with ECARTIS (v1.0.0; list netdev); Fri, 18 Mar 2005 02:43:40 -0800 (PST) Received: from paperstreet.colino.net (colino.net [213.41.131.56]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j2IAhWRE015439 for ; Fri, 18 Mar 2005 02:43:33 -0800 Received: by paperstreet.colino.net (Postfix, from userid 1015) id 37D75101A0; Fri, 18 Mar 2005 11:43:22 +0100 (CET) Received: from jack.colino.net (jack.colino.net [192.168.0.11]) by paperstreet.colino.net (Postfix) with ESMTP id 478D410183; Fri, 18 Mar 2005 11:43:20 +0100 (CET) Date: Fri, 18 Mar 2005 11:43:19 +0100 From: Colin Leroy To: linux-usb-devel@lists.sourceforge.net Cc: netdev@oss.sgi.com Subject: [PATCH] Missing hunk in drivers/usb/Makefile Message-ID: <20050318114319.350a39e9@jack.colino.net> X-Mailer: Sylpheed-Claws 1.0.3cvs2.6 (GTK+ 2.6.1; powerpc-unknown-linux-gnu) X-Face: Fy:*XpRna1/tz}cJ@O'0^:qYs:8b[Rg`*8,+o^[fI?<%5LeB,Xz8ZJK[r7V0hBs8G)*&C+XA0qHoR=LoTohe@7X5K$A-@cN6n~~J/]+{[)E4h'lK$13WQf$.R+Pi;E09tk&{t|;~dakRD%CLHrk6m!?gA,5|Sb=fJ=>[9#n1Bu8?VngkVM4{'^'V_qgdA.8yn3) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV 0.83/765/Thu Mar 17 00:42:45 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 305 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: colin@colino.net Precedence: bulk X-list: netdev Content-Length: 655 Lines: 19 Hi, [re-send so that linux-usb-devel gets it too] I see there's been a driver for zd1201 added in drivers/usb/net/. There's a hunk missing in drivers/usb/Makefile, the driver doesn't get built if nothing else in drivers/usb/net is configured in : Signed-off-by: Colin Leroy --- a/drivers/usb/Makefile 2005-03-18 10:26:38.000000000 +0100 +++ b/drivers/usb/Makefile 2005-03-18 10:27:22.000000000 +0100 @@ -50,6 +50,7 @@ obj-$(CONFIG_USB_PEGASUS) += net/ obj-$(CONFIG_USB_RTL8150) += net/ obj-$(CONFIG_USB_USBNET) += net/ +obj-$(CONFIG_USB_ZD1201) += net/ obj-$(CONFIG_USB_HPUSBSCSI) += image/ obj-$(CONFIG_USB_MDC800) += image/ From herbert@gondor.apana.org.au Fri Mar 18 03:08:14 2005 Received: with ECARTIS (v1.0.0; list netdev); Fri, 18 Mar 2005 03:08:22 -0800 (PST) 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 j2IB8CsR018206 for ; Fri, 18 Mar 2005 03:08:13 -0800 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 1DCFJr-0004dL-00; Fri, 18 Mar 2005 22:07:07 +1100 Received: from herbert by gondolin.me.apana.org.au with local (Exim 3.36 #1 (Debian)) id 1DCFIx-0001bl-00; Fri, 18 Mar 2005 22:06:11 +1100 Date: Fri, 18 Mar 2005 22:06:11 +1100 To: "David S. Miller" Cc: Alexey Kuznetsov , YOSHIFUJI Hideaki , Patrick McHardy , netdev@oss.sgi.com Subject: [26/*] [NET] Kill dst_pmtu/dst_path_metric Message-ID: <20050318110611.GA5843@gondor.apana.org.au> References: <20050314102614.GA9610@gondor.apana.org.au> <20050314105313.GA21001@gondor.apana.org.au> <20050314111002.GA29156@gondor.apana.org.au> <20050315091904.GA6256@gondor.apana.org.au> <20050315095837.GA7130@gondor.apana.org.au> <20050318090310.GA28443@gondor.apana.org.au> <20050318091129.GA28658@gondor.apana.org.au> <20050318091918.GA28944@gondor.apana.org.au> <20050318100757.GA29433@gondor.apana.org.au> <20050318101126.GA29583@gondor.apana.org.au> Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="azLHFNyN32YCQGCU" Content-Disposition: inline In-Reply-To: <20050318101126.GA29583@gondor.apana.org.au> User-Agent: Mutt/1.5.6+20040907i From: Herbert Xu X-Virus-Scanned: ClamAV 0.83/765/Thu Mar 17 00:42:45 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 306 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: herbert@gondor.apana.org.au Precedence: bulk X-list: netdev Content-Length: 2670 Lines: 89 --azLHFNyN32YCQGCU Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Hi Dave: This would have been the patch that removed dst->path. But ip_append_data got in the way :) However, using dst->path is only needed rarely and should always require a bit of deliberation. So let's get rid of dst_pmtu and dst_path_metric and use dst_mtu and dst_metric directly. Signed-off-by: Herbert Xu BTW, shouldn't dst_allfrag be called dst_path_allfrag? Cheers, -- Visit Openswan at http://www.openswan.org/ Email: Herbert Xu ~{PmV>HI~} Home Page: http://gondor.apana.org.au/~herbert/ PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt --azLHFNyN32YCQGCU Content-Type: text/plain; charset=us-ascii Content-Disposition: attachment; filename=xfrm-26 ===== include/net/dst.h 1.29 vs edited ===== --- 1.29/include/net/dst.h 2005-03-11 13:17:32 +11:00 +++ edited/include/net/dst.h 2005-03-18 21:08:56 +11:00 @@ -109,21 +109,6 @@ return dst->metrics[metric-1]; } -static inline u32 -dst_path_metric(const struct dst_entry *dst, int metric) -{ - return dst->path->metrics[metric-1]; -} - -static inline u32 -dst_pmtu(const struct dst_entry *dst) -{ - u32 mtu = dst_path_metric(dst, RTAX_MTU); - /* Yes, _exactly_. This is paranoia. */ - barrier(); - return mtu; -} - static inline u32 dst_mtu(const struct dst_entry *dst) { u32 mtu = dst_metric(dst, RTAX_MTU); @@ -137,7 +122,7 @@ static inline u32 dst_allfrag(const struct dst_entry *dst) { - int ret = dst_path_metric(dst, RTAX_FEATURES) & RTAX_FEATURE_ALLFRAG; + int ret = dst_metric(dst->path, RTAX_FEATURES) & RTAX_FEATURE_ALLFRAG; /* Yes, _exactly_. This is paranoia. */ barrier(); return ret; ===== net/ipv4/ip_output.c 1.79 vs edited ===== --- 1.79/net/ipv4/ip_output.c 2005-03-17 09:02:36 +11:00 +++ edited/net/ipv4/ip_output.c 2005-03-18 21:00:08 +11:00 @@ -746,7 +746,7 @@ inet->cork.addr = ipc->addr; } dst_hold(&rt->u.dst); - inet->cork.fragsize = mtu = dst_pmtu(&rt->u.dst); + inet->cork.fragsize = mtu = dst_mtu(rt->u.dst.path); inet->cork.rt = rt; inet->cork.length = 0; sk->sk_sndmsg_page = NULL; ===== net/ipv6/ip6_output.c 1.89 vs edited ===== --- 1.89/net/ipv6/ip6_output.c 2005-03-17 09:02:36 +11:00 +++ edited/net/ipv6/ip6_output.c 2005-03-18 21:00:08 +11:00 @@ -850,7 +850,7 @@ np->cork.rt = rt; inet->cork.fl = *fl; np->cork.hop_limit = hlimit; - inet->cork.fragsize = mtu = dst_pmtu(&rt->u.dst); + inet->cork.fragsize = mtu = dst_mtu(rt->u.dst.path); if (dst_allfrag(&rt->u.dst)) inet->cork.flags |= IPCORK_ALLFRAG; inet->cork.length = 0; --azLHFNyN32YCQGCU-- From herbert@gondor.apana.org.au Fri Mar 18 03:29:16 2005 Received: with ECARTIS (v1.0.0; list netdev); Fri, 18 Mar 2005 03:29:23 -0800 (PST) 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 j2IBTEiZ020496 for ; Fri, 18 Mar 2005 03:29:15 -0800 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 1DCFea-0004tY-00; Fri, 18 Mar 2005 22:28:32 +1100 Received: from herbert by gondolin.me.apana.org.au with local (Exim 3.36 #1 (Debian)) id 1DCFe8-00020o-00; Fri, 18 Mar 2005 22:28:04 +1100 Date: Fri, 18 Mar 2005 22:28:04 +1100 To: "David S. Miller" Cc: Alexey Kuznetsov , YOSHIFUJI Hideaki , Patrick McHardy , netdev@oss.sgi.com Subject: [27/*] [NET] Make dst_allfrag use dst instead of dst->path Message-ID: <20050318112804.GA6930@gondor.apana.org.au> References: <20050314105313.GA21001@gondor.apana.org.au> <20050314111002.GA29156@gondor.apana.org.au> <20050315091904.GA6256@gondor.apana.org.au> <20050315095837.GA7130@gondor.apana.org.au> <20050318090310.GA28443@gondor.apana.org.au> <20050318091129.GA28658@gondor.apana.org.au> <20050318091918.GA28944@gondor.apana.org.au> <20050318100757.GA29433@gondor.apana.org.au> <20050318101126.GA29583@gondor.apana.org.au> <20050318110611.GA5843@gondor.apana.org.au> Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="DocE+STaALJfprDB" Content-Disposition: inline In-Reply-To: <20050318110611.GA5843@gondor.apana.org.au> User-Agent: Mutt/1.5.6+20040907i From: Herbert Xu X-Virus-Scanned: ClamAV 0.83/765/Thu Mar 17 00:42:45 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 307 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: herbert@gondor.apana.org.au Precedence: bulk X-list: netdev Content-Length: 1724 Lines: 53 --DocE+STaALJfprDB Content-Type: text/plain; charset=us-ascii Content-Disposition: inline On Fri, Mar 18, 2005 at 10:06:11PM +1100, herbert wrote: > > BTW, shouldn't dst_allfrag be called dst_path_allfrag? Rather than doing that, let's make the path usage explicit in the one place that it's needed (the same place where we use dst_mtu(dst->path)). Signed-off-by: Herbert Xu Hmm, it still doesn't feel right to have an IPv6-specific helper in net/dst.h. Cheers, -- Visit Openswan at http://www.openswan.org/ Email: Herbert Xu ~{PmV>HI~} Home Page: http://gondor.apana.org.au/~herbert/ PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt --DocE+STaALJfprDB Content-Type: text/plain; charset=us-ascii Content-Disposition: attachment; filename=xfrm-27 --- linux-2.6/include/net/dst.h.orig 2005-03-18 22:20:39.000000000 +1100 +++ linux-2.6/include/net/dst.h 2005-03-18 22:20:46.000000000 +1100 @@ -122,7 +122,7 @@ static inline u32 dst_allfrag(const struct dst_entry *dst) { - int ret = dst_metric(dst->path, RTAX_FEATURES) & RTAX_FEATURE_ALLFRAG; + int ret = dst_metric(dst, RTAX_FEATURES) & RTAX_FEATURE_ALLFRAG; /* Yes, _exactly_. This is paranoia. */ barrier(); return ret; --- linux-2.6/net/ipv6/ip6_output.c.orig 2005-03-18 22:21:01.000000000 +1100 +++ linux-2.6/net/ipv6/ip6_output.c 2005-03-18 22:23:52.000000000 +1100 @@ -851,7 +851,7 @@ inet->cork.fl = *fl; np->cork.hop_limit = hlimit; inet->cork.fragsize = mtu = dst_mtu(rt->u.dst.path); - if (dst_allfrag(&rt->u.dst)) + if (dst_allfrag(rt->u.dst.path)) inet->cork.flags |= IPCORK_ALLFRAG; inet->cork.length = 0; sk->sk_sndmsg_page = NULL; --DocE+STaALJfprDB-- From dada1@cosmosbay.com Fri Mar 18 04:06:00 2005 Received: with ECARTIS (v1.0.0; list netdev); Fri, 18 Mar 2005 04:06:11 -0800 (PST) Received: from gw1.cosmosbay.com (gw1.cosmosbay.com [62.23.185.226]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j2IC5wFT024217 for ; Fri, 18 Mar 2005 04:05:59 -0800 Received: from [172.16.0.131] (edumazet-port [172.16.0.131]) by gw1.cosmosbay.com (8.13.3/8.13.3) with ESMTP id j2IC5bga010525; Fri, 18 Mar 2005 13:05:40 +0100 Message-ID: <423AC418.6080903@cosmosbay.com> Date: Fri, 18 Mar 2005 13:05:44 +0100 From: Eric Dumazet User-Agent: Mozilla Thunderbird 1.0 (Windows/20041206) X-Accept-Language: fr, en MIME-Version: 1.0 To: acme@conectiva.com.br, "David S. Miller" , netdev@oss.sgi.com Subject: [PATCH] /proc/net/stat/rt_cache has a wrong header References: <4238C388.5040303@cosmosbay.com> In-Reply-To: <4238C388.5040303@cosmosbay.com> Content-Type: multipart/mixed; boundary="------------040405040806040602080706" X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-1.6 (gw1.cosmosbay.com [172.16.8.80]); Fri, 18 Mar 2005 13:05:40 +0100 (CET) X-Virus-Scanned: ClamAV 0.83/765/Thu Mar 17 00:42:45 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 308 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: dada1@cosmosbay.com Precedence: bulk X-list: netdev Content-Length: 1196 Lines: 35 This is a multi-part message in MIME format. --------------040405040806040602080706 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Hello The header of /proc/net/stat/rt_cache misses the 'in_slow_mc' field. This patch adds it. Thank you Eric Dumazet --------------040405040806040602080706 Content-Type: text/plain; name="diff" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="diff" --- linux-2.6.11/net/ipv4/route.c 2005-03-17 11:19:45.000000000 +0100 +++ linux-2.6.11-ed2/net/ipv4/route.c 2005-03-18 13:01:11.000000000 +0100 @@ -393,7 +393,7 @@ struct rt_cache_stat *st = v; if (v == SEQ_START_TOKEN) { - seq_printf(seq, "entries in_hit in_slow_tot in_no_route in_brd in_martian_dst in_martian_src out_hit out_slow_tot out_slow_mc gc_total gc_ignored gc_goal_miss gc_dst_overflow in_hlist_search out_hlist_search\n"); + seq_printf(seq, "entries in_hit in_slow_tot in_slow_mc in_no_route in_brd in_martian_dst in_martian_src out_hit out_slow_tot out_slow_mc gc_total gc_ignored gc_goal_miss gc_dst_overflow in_hlist_search out_hlist_search\n"); return 0; } --------------040405040806040602080706-- From arnaldo.melo@gmail.com Fri Mar 18 04:53:31 2005 Received: with ECARTIS (v1.0.0; list netdev); Fri, 18 Mar 2005 04:53:36 -0800 (PST) Received: from wproxy.gmail.com (wproxy.gmail.com [64.233.184.206]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j2ICrUuo032125 for ; Fri, 18 Mar 2005 04:53:30 -0800 Received: by wproxy.gmail.com with SMTP id 71so167057wri for ; Fri, 18 Mar 2005 04:53:25 -0800 (PST) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:reply-to:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:references; b=UI6FIx2f05wk7KYi+5UFzXOWOtL+FORb68L3+KiflQQzVXnyvF4dTVbnvvM2ihHHvJLdZcOdiE9KISyIY7VrzbGwUKt9sPGauVJdHOfSwaQSBnp5sVsK/nW3G+UU4u3phf5lk/mzQTcIunx5JL54jiuzLqk8VbHRtEF2oHGMho0= Received: by 10.54.77.17 with SMTP id z17mr163512wra; Fri, 18 Mar 2005 04:53:25 -0800 (PST) Received: by 10.54.10.49 with HTTP; Fri, 18 Mar 2005 04:53:25 -0800 (PST) Message-ID: <39e6f6c705031804531c2c557f@mail.gmail.com> Date: Fri, 18 Mar 2005 09:53:25 -0300 From: Arnaldo Carvalho de Melo Reply-To: acme@conectiva.com.br To: "David S. Miller" Subject: Re: [RFC] TCP congestion schedulers Cc: Stephen Hemminger , baruch@ev-en.org, netdev@oss.sgi.com In-Reply-To: <20050317201231.6d575e0b.davem@davemloft.net> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit References: <421CF5E5.1060606@ev-en.org> <421D30FA.1060900@ev-en.org> <20050225120814.5fa77b13@dxpl.pdx.osdl.net> <20050309210442.3e9786a6.davem@davemloft.net> <4230288F.1030202@ev-en.org> <20050310182629.1eab09ec.davem@davemloft.net> <20050311120054.4bbf675a@dxpl.pdx.osdl.net> <20050311201011.360c00da.davem@davemloft.net> <20050314151726.532af90d@dxpl.pdx.osdl.net> <20050317201231.6d575e0b.davem@davemloft.net> X-Virus-Scanned: ClamAV 0.83/765/Thu Mar 17 00:42:45 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 309 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: arnaldo.melo@gmail.com Precedence: bulk X-list: netdev Content-Length: 1107 Lines: 29 On Thu, 17 Mar 2005 20:12:31 -0800, David S. Miller wrote: > On Mon, 14 Mar 2005 15:17:26 -0800 > Stephen Hemminger wrote: > > > +/* Hook for advanced congestion control */ > > + struct tcp_ca_type *ca_proto; > > +#define TCP_CA_PRIV_SIZE 48 > > + u8 *ca_priv[TCP_CA_PRIV_SIZE]; > > An array of 48 pointers to "u8" eh? :-) > > It happens to work, but you're using too much > space (specifically: 48 * sizeof(u8 *)) as a side effect. > > Otherwise, the only comment I have is that we lose the tcp_diag > info. Maybe create a "tcpdiag_put" method in there so we can > retain that. > > I'm also not so religious anymore about retaining the existing > sysctl functionality to enable/disable ca algs. I haven't looked over this patch completely, so I may well be saying something stupid, but if possible, please don't use the tcp/TCP prefix where you think this code can be used by other inet transport protocols, such as DCCP. I'll try to review this patch this weekend to see if this is possible or if I'm on crack now 8) - Arnaldo From hadi@cyberus.ca Fri Mar 18 05:43:10 2005 Received: with ECARTIS (v1.0.0; list netdev); Fri, 18 Mar 2005 05:43:14 -0800 (PST) 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 j2IDh9Zt004844 for ; Fri, 18 Mar 2005 05:43:10 -0800 Received: from [127.0.0.1] ([208.2.156.2]) by lotus.znyx.com (Lotus Domino Release 5.0.11) with ESMTP id 2005031805441492:16095 ; Fri, 18 Mar 2005 05:44:14 -0800 Subject: Re: [RFC] TCP congestion schedulers From: jamal Reply-To: hadi@cyberus.ca To: acme@conectiva.com.br Cc: "David S. Miller" , Stephen Hemminger , baruch@ev-en.org, netdev@oss.sgi.com In-Reply-To: <39e6f6c705031804531c2c557f@mail.gmail.com> References: <421CF5E5.1060606@ev-en.org> <421D30FA.1060900@ev-en.org> <20050225120814.5fa77b13@dxpl.pdx.osdl.net> <20050309210442.3e9786a6.davem@davemloft.net> <4230288F.1030202@ev-en.org> <20050310182629.1eab09ec.davem@davemloft.net> <20050311120054.4bbf675a@dxpl.pdx.osdl.net> <20050311201011.360c00da.davem@davemloft.net> <20050314151726.532af90d@dxpl.pdx.osdl.net> <20050317201231.6d575e0b.davem@davemloft.net> <39e6f6c705031804531c2c557f@mail.gmail.com> Organization: jamalopolis Message-Id: <1111153298.1146.35.camel@jzny.localdomain> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.2.2 Date: 18 Mar 2005 08:43:04 -0500 X-MIMETrack: Itemize by SMTP Server on Lotus/Znyx(Release 5.0.11 |July 24, 2002) at 03/18/2005 05:44:15 AM, Serialize by Router on Lotus/Znyx(Release 5.0.11 |July 24, 2002) at 03/18/2005 05:44:19 AM, Serialize complete at 03/18/2005 05:44:19 AM Content-Transfer-Encoding: 7bit Content-Type: text/plain X-Virus-Scanned: ClamAV 0.83/765/Thu Mar 17 00:42:45 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 310 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: hadi@cyberus.ca Precedence: bulk X-list: netdev Content-Length: 848 Lines: 23 On Fri, 2005-03-18 at 07:53, Arnaldo Carvalho de Melo wrote: > > I'm also not so religious anymore about retaining the existing > > sysctl functionality to enable/disable ca algs. > > I haven't looked over this patch completely, so I may well be saying something > stupid, but if possible, please don't use the tcp/TCP prefix where you > think this > code can be used by other inet transport protocols, such as DCCP. Yes, that would be really nice. Also heres another thought: if we can have multiple sockets, destined to the same receiver, to share the same congestion state. This is motivated from the CM idea the MIT folks were preaching a few years ago - look at RFC 3124 and the MIT website which had some crude linux code back then as well as tons of papers. I think that scheme may need to hook up to tc to work well. cheers, jamal From olel@ans.pl Fri Mar 18 06:44:31 2005 Received: with ECARTIS (v1.0.0; list netdev); Fri, 18 Mar 2005 06:44:39 -0800 (PST) Received: from bizon.gios.gov.pl (root@bizon.gios.gov.pl [212.244.124.8]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j2IEiPUT008059 for ; Fri, 18 Mar 2005 06:44:30 -0800 Received: from bizon.gios.gov.pl (olel@localhost6 [IPv6:::1]) by bizon.gios.gov.pl (8.13.3/8.13.3) with ESMTP id j2IEhnPY006436 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 18 Mar 2005 15:43:51 +0100 Received: from localhost (olel@localhost) by bizon.gios.gov.pl (8.13.3/8.13.3/Submit) with ESMTP id j2IEhlOq006433; Fri, 18 Mar 2005 15:43:48 +0100 X-Authentication-Warning: bizon.gios.gov.pl: olel owned process doing -bs Date: Fri, 18 Mar 2005 15:43:47 +0100 (CET) From: Krzysztof Oledzki X-X-Sender: olel@bizon.gios.gov.pl To: Wilfried Weissmann cc: ipsec-tools-devel@lists.sourceforge.net, netdev@oss.sgi.com Subject: Re: [Ipsec-tools-devel] more phase 2 reinitiation problems In-Reply-To: <42334B29.2080504@gmx.at> Message-ID: References: <42334B29.2080504@gmx.at> MIME-Version: 1.0 Content-Type: MULTIPART/MIXED; BOUNDARY="-187430788-1420858565-1111157027=:4403" X-Virus-Scanned: ClamAV 0.83/765/Thu Mar 17 00:42:45 2005 on oss.sgi.com X-Virus-Scanned: by amavis-milter (http://www.amavis.org/) X-Virus-Status: Clean X-archive-position: 311 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: olel@ans.pl Precedence: bulk X-list: netdev Content-Length: 5555 Lines: 121 This message is in MIME format. The first part should be readable text, while the remaining parts are likely unreadable without MIME-aware tools. ---187430788-1420858565-1111157027=:4403 Content-Type: TEXT/PLAIN; charset=ISO-8859-2; format=flowed Content-Transfer-Encoding: QUOTED-PRINTABLE On Sat, 12 Mar 2005, Wilfried Weissmann wrote: > Hi, Hi, > The rekeying also fails with debian's racoon 0.5 <=3D=3D> WinXP= (see=20 > Problem with Linux-2.6.x+ipsec-tools-0.4/0.5-rc1/0.5rc2 & Linksys BEFSX41= ). I=20 > am running the linux 2.6.11.2 kernel with IPSec connection tracking patch= es.=20 > The configuration file and the log is attached. > I also have problems between 2 linux boxes in the LAN but the other box i= s=20 > still running racoon 0.3.3 which might be the cause of the LAN trouble. Please giva a try try the 2.6.12-rc1 kernel. I have just upgraded my=20 system to this kernel and it seems that IPSec is able to survive first=20 rekeying. Unfortunately only a first one - after a while (just before=20 removing old expired keys) one of newly generated keys get removed and new= =20 traffic racoon generates two news keys. OK, it is _much_ better but=20 still... not perfect. My log with some comments: Mar 18 11:47:36 gw1 racoon: INFO: @(#)ipsec-tools 0.5 (http://ipsec-tools.s= ourceforge.net) Mar 18 11:47:36 gw1 racoon: INFO: @(#)This product linked OpenSSL 0.9.7e 25= Oct 2004 (http://www.openssl.org/) Mar 18 11:47:36 gw1 racoon: INFO: XXX.XX.XX.XX[500] used as isakmp port (fd= =3D7) Mar 18 11:47:36 gw1 racoon: INFO: XXX.XX.XX.XX[500] used for NAT-T Mar 18 11:48:09 gw1 racoon: INFO: IPsec-SA request for YY.YY.YYY.YYY queued= due to no phase1 found. Mar 18 11:48:09 gw1 racoon: INFO: initiate new phase 1 negotiation: XXX.XX.= XX.XX[500]<=3D>YY.YY.YYY.YYY[500] Mar 18 11:48:09 gw1 racoon: INFO: begin Identity Protection mode. Mar 18 11:48:19 gw1 racoon: INFO: ISAKMP-SA established XXX.XX.XX.XX[500]-Y= Y.YY.YYY.YYY[500] spi:a2acc8844df9591b:29621f95bfa3 8d45 Mar 18 11:48:20 gw1 racoon: INFO: initiate new phase 2 negotiation: XXX.XX.= XX.XX[0]<=3D>YY.YY.YYY.YYY[0] Mar 18 11:48:23 gw1 racoon: WARNING: attribute has been modified. Mar 18 11:48:23 gw1 racoon: INFO: IPsec-SA established: ESP/Tunnel YY.YY.YY= Y.YYY->XXX.XX.XX.XX spi=3D172047746(0xa413d82) Mar 18 11:48:23 gw1 racoon: INFO: IPsec-SA established: ESP/Tunnel XXX.XX.X= X.XX->YY.YY.YYY.YYY spi=3D993793125(0x3b3c1465) OK. Kernel noticed some traffic and racooon generates new keys. Mar 18 12:36:23 gw1 racoon: INFO: IPsec-SA expired: ESP/Tunnel YY.YY.YYY.YY= Y->XXX.XX.XX.XX spi=3D172047746(0xa413d82) Mar 18 12:36:23 gw1 racoon: INFO: initiate new phase 2 negotiation: XXX.XX.= XX.XX[0]<=3D>YY.YY.YYY.YYY[0] Mar 18 12:36:23 gw1 racoon: INFO: IPsec-SA expired: ESP/Tunnel XXX.XX.XX.XX= ->YY.YY.YYY.YYY spi=3D993793125(0x3b3c1465) Mar 18 12:36:27 gw1 racoon: WARNING: attribute has been modified. Mar 18 12:36:27 gw1 racoon: INFO: IPsec-SA established: ESP/Tunnel YY.YY.YY= Y.YYY->XXX.XX.XX.XX spi=3D31676947(0x1e35a13) Mar 18 12:36:27 gw1 racoon: INFO: IPsec-SA established: ESP/Tunnel XXX.XX.X= X.XX->YY.YY.YYY.YYY spi=3D677995285(0x28696315) OK! :) Old keys have just expired and racoon generates new ones. No=20 infinite loop! ;-) Yes! Mar 18 12:48:18 gw1 racoon: INFO: purged IPsec-SA proto_id=3DESP spi=3D6779= 95285. But what is this? We have just generated new key with spi=3D677995285. Why= =20 it is now purged? Mar 18 12:48:19 gw1 racoon: INFO: purged ISAKMP-SA proto_id=3DISAKMP spi=3D= a2acc8844df9591b:29621f95bfa38d45. Mar 18 12:48:20 gw1 racoon: INFO: ISAKMP-SA deleted XXX.XX.XX.XX[500]-YY.YY= =2EYYY.YYY[500] spi:a2acc8844df9591b:29621f95bfa38d45 Mar 18 12:48:20 gw1 racoon: ERROR: unknown Informational exchange received. Mar 18 12:48:23 gw1 racoon: INFO: IPsec-SA expired: ESP/Tunnel YY.YY.YYY.YY= Y->XXX.XX.XX.XX spi=3D172047746(0xa413d82) Mar 18 12:48:23 gw1 racoon: INFO: IPsec-SA expired: ESP/Tunnel XXX.XX.XX.XX= ->YY.YY.YYY.YYY spi=3D993793125(0x3b3c1465) OK. Oldest keys now really expired, they are removed. Mar 18 12:51:31 gw1 racoon: INFO: IPsec-SA request for YY.YY.YYY.YYY queued= due to no phase1 found. Mar 18 12:51:31 gw1 racoon: INFO: initiate new phase 1 negotiation: XXX.XX.= XX.XX[500]<=3D>YY.YY.YYY.YYY[500] Mar 18 12:51:31 gw1 racoon: INFO: begin Identity Protection mode. Mar 18 12:51:40 gw1 racoon: INFO: ISAKMP-SA established XXX.XX.XX.XX[500]-Y= Y.YY.YYY.YYY[500] spi:8f29dd5a50fd83dd:ae84b9eee139 89e5 Mar 18 12:51:41 gw1 racoon: INFO: initiate new phase 2 negotiation: XXX.XX.= XX.XX[0]<=3D>YY.YY.YYY.YYY[0] Mar 18 12:51:43 gw1 racoon: WARNING: attribute has been modified. Mar 18 12:51:43 gw1 racoon: INFO: IPsec-SA established: ESP/Tunnel YY.YY.YY= Y.YYY->XXX.XX.XX.XX spi=3D140244397(0x85bf5ad) Mar 18 12:51:43 gw1 racoon: INFO: IPsec-SA established: ESP/Tunnel XXX.XX.X= X.XX->YY.YY.YYY.YYY spi=3D3173924318(0xbd2e3dde) Kernel noticed some traffic (again), there is no known key for encription= =20 (it was pugred @12:48:18), racooon generates new keys. Mar 18 13:24:27 gw1 racoon: INFO: IPsec-SA expired: ESP/Tunnel YY.YY.YYY.YY= Y->XXX.XX.XX.XX spi=3D31676947(0x1e35a13) Mar 18 13:36:27 gw1 racoon: INFO: IPsec-SA expired: ESP/Tunnel YY.YY.YYY.YY= Y->XXX.XX.XX.XX spi=3D31676947(0x1e35a13) Mar 18 13:39:43 gw1 racoon: INFO: IPsec-SA expired: ESP/Tunnel YY.YY.YYY.YY= Y->XXX.XX.XX.XX spi=3D140244397(0x85bf5ad)=20 Old keys get expired. BTW: Why key with spi=3D31676947 is expired twice? (...) Best regards, =09=09=09Krzysztof Ol=EAdzki ---187430788-1420858565-1111157027=:4403-- From arnaldo.melo@gmail.com Fri Mar 18 08:13:51 2005 Received: with ECARTIS (v1.0.0; list netdev); Fri, 18 Mar 2005 08:13:58 -0800 (PST) Received: from wproxy.gmail.com (wproxy.gmail.com [64.233.184.202]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j2IGDo9i012593 for ; Fri, 18 Mar 2005 08:13:51 -0800 Received: by wproxy.gmail.com with SMTP id 71so231134wra for ; Fri, 18 Mar 2005 08:13:45 -0800 (PST) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:reply-to:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:references; b=KULLdOOXO9H9rErC585G4NzA6MgmOXr6sFFxAql75rEB687y8uxHnRbhaebqhILxFZ9UEz6Kj1wlnQrFWAAOMMYI+mg8OupGbF2yoXKl362SvaCB9sZRGJLHeKCK6SPvW8pYTFgvmqB9mF0umvLDiTRVcIeG3P+AUDBf5vRcATs= Received: by 10.54.23.67 with SMTP id 67mr1841849wrw; Fri, 18 Mar 2005 08:13:45 -0800 (PST) Received: by 10.54.10.49 with HTTP; Fri, 18 Mar 2005 08:13:45 -0800 (PST) Message-ID: <39e6f6c7050318081371238254@mail.gmail.com> Date: Fri, 18 Mar 2005 13:13:45 -0300 From: Arnaldo Carvalho de Melo Reply-To: acme@conectiva.com.br To: hadi@cyberus.ca Subject: Re: [RFC] TCP congestion schedulers Cc: "David S. Miller" , Stephen Hemminger , baruch@ev-en.org, netdev@oss.sgi.com In-Reply-To: <1111153298.1146.35.camel@jzny.localdomain> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit References: <421CF5E5.1060606@ev-en.org> <20050309210442.3e9786a6.davem@davemloft.net> <4230288F.1030202@ev-en.org> <20050310182629.1eab09ec.davem@davemloft.net> <20050311120054.4bbf675a@dxpl.pdx.osdl.net> <20050311201011.360c00da.davem@davemloft.net> <20050314151726.532af90d@dxpl.pdx.osdl.net> <20050317201231.6d575e0b.davem@davemloft.net> <39e6f6c705031804531c2c557f@mail.gmail.com> <1111153298.1146.35.camel@jzny.localdomain> X-Virus-Scanned: ClamAV 0.83/772/Fri Mar 18 00:59:17 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 312 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: arnaldo.melo@gmail.com Precedence: bulk X-list: netdev Content-Length: 1459 Lines: 33 On 18 Mar 2005 08:43:04 -0500, jamal wrote: > On Fri, 2005-03-18 at 07:53, Arnaldo Carvalho de Melo wrote: > > > > I'm also not so religious anymore about retaining the existing > > > sysctl functionality to enable/disable ca algs. > > > > I haven't looked over this patch completely, so I may well be saying something > > stupid, but if possible, please don't use the tcp/TCP prefix where you > > think this > > code can be used by other inet transport protocols, such as DCCP. > > Yes, that would be really nice. > > Also heres another thought: if we can have multiple sockets, destined to > the same receiver, to share the same congestion state. This is motivated > from the CM idea the MIT folks were preaching a few years ago - look at > RFC 3124 and the MIT website which had some crude linux code back then > as well as tons of papers. I think > that scheme may need to hook up to tc to work well. The DCCP drafts mention that they choose not to require the CM, but yes, it is something to consider anyway, its interesting stuff. Again without looking at the patch fully, the tcp_sock passing to this infrastructure would have to go away and instead chunk out the needed members out of tcp_sock and into a congestion_info struct that would be a member of both tcp_sock and dccp_sock, and this one would be the one passed to this infrastructure. In the end we may well give Sally et al some new CCIDs for free :-P -- - Arnaldo From shemminger@osdl.org Fri Mar 18 08:46:32 2005 Received: with ECARTIS (v1.0.0; list netdev); Fri, 18 Mar 2005 08:46:38 -0800 (PST) Received: from smtp.osdl.org (fire.osdl.org [65.172.181.4]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j2IGkVbG017835 for ; Fri, 18 Mar 2005 08:46:32 -0800 Received: from shell0.pdx.osdl.net (fw.osdl.org [65.172.181.6]) by smtp.osdl.org (8.12.8/8.12.8) with ESMTP id j2IGjbqi010818 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO); Fri, 18 Mar 2005 08:45:37 -0800 Received: from dxpl.pdx.osdl.net (dxpl.pdx.osdl.net [172.20.1.103]) by shell0.pdx.osdl.net (8.13.1/8.11.6) with ESMTP id j2IGjaOU006894; Fri, 18 Mar 2005 08:45:36 -0800 Date: Fri, 18 Mar 2005 08:45:55 -0800 From: Stephen Hemminger To: acme@conectiva.com.br Cc: arnaldo.melo@gmail.com, hadi@cyberus.ca, "David S. Miller" , baruch@ev-en.org, netdev@oss.sgi.com Subject: Re: [RFC] TCP congestion schedulers Message-ID: <20050318084555.39638ee9@dxpl.pdx.osdl.net> In-Reply-To: <39e6f6c7050318081371238254@mail.gmail.com> References: <421CF5E5.1060606@ev-en.org> <20050309210442.3e9786a6.davem@davemloft.net> <4230288F.1030202@ev-en.org> <20050310182629.1eab09ec.davem@davemloft.net> <20050311120054.4bbf675a@dxpl.pdx.osdl.net> <20050311201011.360c00da.davem@davemloft.net> <20050314151726.532af90d@dxpl.pdx.osdl.net> <20050317201231.6d575e0b.davem@davemloft.net> <39e6f6c705031804531c2c557f@mail.gmail.com> <1111153298.1146.35.camel@jzny.localdomain> <39e6f6c7050318081371238254@mail.gmail.com> Organization: Open Source Development Lab X-Mailer: Sylpheed-Claws 1.0.1 (GTK+ 1.2.10; x86_64-unknown-linux-gnu) X-Face: &@E+xe?c%:&e4D{>f1O<&U>2qwRREG5!}7R4;D<"NO^UI2mJ[eEOA2*3>(`Th.yP,VDPo9$ /`~cw![cmj~~jWe?AHY7D1S+\}5brN0k*NE?pPh_'_d>6;XGG[\KDRViCfumZT3@[ Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Received-SPF: pass (domain of shemminger@osdl.org designates 65.172.181.6 as permitted sender) X-MIMEDefang-Filter: osdl$Revision: 1.105 $ X-Scanned-By: MIMEDefang 2.36 X-Virus-Scanned: ClamAV 0.83/772/Fri Mar 18 00:59:17 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 313 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: shemminger@osdl.org Precedence: bulk X-list: netdev Content-Length: 1689 Lines: 36 On Fri, 18 Mar 2005 13:13:45 -0300 Arnaldo Carvalho de Melo wrote: > On 18 Mar 2005 08:43:04 -0500, jamal wrote: > > On Fri, 2005-03-18 at 07:53, Arnaldo Carvalho de Melo wrote: > > > > > > I'm also not so religious anymore about retaining the existing > > > > sysctl functionality to enable/disable ca algs. > > > > > > I haven't looked over this patch completely, so I may well be saying something > > > stupid, but if possible, please don't use the tcp/TCP prefix where you > > > think this > > > code can be used by other inet transport protocols, such as DCCP. > > > > Yes, that would be really nice. > > > > Also heres another thought: if we can have multiple sockets, destined to > > the same receiver, to share the same congestion state. This is motivated > > from the CM idea the MIT folks were preaching a few years ago - look at > > RFC 3124 and the MIT website which had some crude linux code back then > > as well as tons of papers. I think > > that scheme may need to hook up to tc to work well. > > The DCCP drafts mention that they choose not to require the CM, but yes, it is > something to consider anyway, its interesting stuff. > > Again without looking at the patch fully, the tcp_sock passing to this > infrastructure > would have to go away and instead chunk out the needed members out of tcp_sock > and into a congestion_info struct that would be a member of both tcp_sock and > dccp_sock, and this one would be the one passed to this infrastructure. > > In the end we may well give Sally et al some new CCIDs for free :-P Let's abstract it for TCP first, then as a later patch reduce the scope and generalize it. From shemminger@osdl.org Fri Mar 18 08:51:03 2005 Received: with ECARTIS (v1.0.0; list netdev); Fri, 18 Mar 2005 08:51:09 -0800 (PST) Received: from smtp.osdl.org (fire.osdl.org [65.172.181.4]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j2IGp3gZ018479 for ; Fri, 18 Mar 2005 08:51:03 -0800 Received: from shell0.pdx.osdl.net (fw.osdl.org [65.172.181.6]) by smtp.osdl.org (8.12.8/8.12.8) with ESMTP id j2IGocqi011105 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO); Fri, 18 Mar 2005 08:50:39 -0800 Received: from dxpl.pdx.osdl.net (dxpl.pdx.osdl.net [172.20.1.103]) by shell0.pdx.osdl.net (8.13.1/8.11.6) with ESMTP id j2IGocDR007099; Fri, 18 Mar 2005 08:50:38 -0800 Date: Fri, 18 Mar 2005 08:50:56 -0800 From: Stephen Hemminger To: Eric Dumazet Cc: acme@conectiva.com.br, "David S. Miller" , netdev@oss.sgi.com Subject: Re: [PATCH] /proc/net/stat/rt_cache has a wrong header Message-ID: <20050318085056.0869394b@dxpl.pdx.osdl.net> In-Reply-To: <423AC418.6080903@cosmosbay.com> References: <4238C388.5040303@cosmosbay.com> <423AC418.6080903@cosmosbay.com> Organization: Open Source Development Lab X-Mailer: Sylpheed-Claws 1.0.1 (GTK+ 1.2.10; x86_64-unknown-linux-gnu) X-Face: &@E+xe?c%:&e4D{>f1O<&U>2qwRREG5!}7R4;D<"NO^UI2mJ[eEOA2*3>(`Th.yP,VDPo9$ /`~cw![cmj~~jWe?AHY7D1S+\}5brN0k*NE?pPh_'_d>6;XGG[\KDRViCfumZT3@[ Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Received-SPF: pass (domain of shemminger@osdl.org designates 65.172.181.6 as permitted sender) X-MIMEDefang-Filter: osdl$Revision: 1.105 $ X-Scanned-By: MIMEDefang 2.36 X-Virus-Scanned: ClamAV 0.83/772/Fri Mar 18 00:59:17 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 314 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: shemminger@osdl.org Precedence: bulk X-list: netdev Content-Length: 298 Lines: 10 On Fri, 18 Mar 2005 13:05:44 +0100 Eric Dumazet wrote: > Hello > > The header of /proc/net/stat/rt_cache misses the 'in_slow_mc' field. > This patch adds it. Current iproute2 tools adapt to additional fields, but wouldn't this be breaking the API for other tools? (if any) From arnaldo.melo@gmail.com Fri Mar 18 08:59:09 2005 Received: with ECARTIS (v1.0.0; list netdev); Fri, 18 Mar 2005 08:59:17 -0800 (PST) Received: from wproxy.gmail.com (wproxy.gmail.com [64.233.184.201]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j2IGx8uH019417 for ; Fri, 18 Mar 2005 08:59:08 -0800 Received: by wproxy.gmail.com with SMTP id 50so249207wri for ; Fri, 18 Mar 2005 08:59:02 -0800 (PST) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:reply-to:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:references; b=mBILZWyCBXmTIqBQ7eCBl14iKgxFftKmmNxuYAkHIpNsdBjes6aSWCREiJRUVJMm6jOquvScmlG7Hgwek3Qvm6VFekyhf5783tYkHbyEYoDIiQwVrYfxBJZKAC+I9bp6BQKZHuLqzh4GkA7py2W7VhbXA8NkyqXaf+1iVU0FlPg= Received: by 10.54.33.64 with SMTP id g64mr1153644wrg; Fri, 18 Mar 2005 08:59:02 -0800 (PST) Received: by 10.54.10.49 with HTTP; Fri, 18 Mar 2005 08:59:02 -0800 (PST) Message-ID: <39e6f6c705031808599bc3b2@mail.gmail.com> Date: Fri, 18 Mar 2005 13:59:02 -0300 From: Arnaldo Carvalho de Melo Reply-To: acme@conectiva.com.br To: Stephen Hemminger Subject: Re: [RFC] TCP congestion schedulers Cc: hadi@cyberus.ca, "David S. Miller" , baruch@ev-en.org, netdev@oss.sgi.com In-Reply-To: <20050318084555.39638ee9@dxpl.pdx.osdl.net> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit References: <421CF5E5.1060606@ev-en.org> <20050310182629.1eab09ec.davem@davemloft.net> <20050311120054.4bbf675a@dxpl.pdx.osdl.net> <20050311201011.360c00da.davem@davemloft.net> <20050314151726.532af90d@dxpl.pdx.osdl.net> <20050317201231.6d575e0b.davem@davemloft.net> <39e6f6c705031804531c2c557f@mail.gmail.com> <1111153298.1146.35.camel@jzny.localdomain> <39e6f6c7050318081371238254@mail.gmail.com> <20050318084555.39638ee9@dxpl.pdx.osdl.net> X-Virus-Scanned: ClamAV 0.83/772/Fri Mar 18 00:59:17 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 315 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: arnaldo.melo@gmail.com Precedence: bulk X-list: netdev Content-Length: 1954 Lines: 45 On Fri, 18 Mar 2005 08:45:55 -0800, Stephen Hemminger wrote: > On Fri, 18 Mar 2005 13:13:45 -0300 > Arnaldo Carvalho de Melo wrote: > > > On 18 Mar 2005 08:43:04 -0500, jamal wrote: > > > On Fri, 2005-03-18 at 07:53, Arnaldo Carvalho de Melo wrote: > > > > > > > > I'm also not so religious anymore about retaining the existing > > > > > sysctl functionality to enable/disable ca algs. > > > > > > > > I haven't looked over this patch completely, so I may well be saying something > > > > stupid, but if possible, please don't use the tcp/TCP prefix where you > > > > think this > > > > code can be used by other inet transport protocols, such as DCCP. > > > > > > Yes, that would be really nice. > > > > > > Also heres another thought: if we can have multiple sockets, destined to > > > the same receiver, to share the same congestion state. This is motivated > > > from the CM idea the MIT folks were preaching a few years ago - look at > > > RFC 3124 and the MIT website which had some crude linux code back then > > > as well as tons of papers. I think > > > that scheme may need to hook up to tc to work well. > > > > The DCCP drafts mention that they choose not to require the CM, but yes, it is > > something to consider anyway, its interesting stuff. > > > > Again without looking at the patch fully, the tcp_sock passing to this > > infrastructure > > would have to go away and instead chunk out the needed members out of tcp_sock > > and into a congestion_info struct that would be a member of both tcp_sock and > > dccp_sock, and this one would be the one passed to this infrastructure. > > > > In the end we may well give Sally et al some new CCIDs for free :-P > > Let's abstract it for TCP first, then as a later patch reduce the scope and > generalize it. Fine with me, just wanted to trow these thoughts so that when working on it you think about it :-) -- - Arnaldo From dada1@cosmosbay.com Fri Mar 18 09:14:37 2005 Received: with ECARTIS (v1.0.0; list netdev); Fri, 18 Mar 2005 09:14:44 -0800 (PST) Received: from gw1.cosmosbay.com (gw1.cosmosbay.com [62.23.185.226]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j2IHEZSg020640 for ; Fri, 18 Mar 2005 09:14:36 -0800 Received: from [172.16.0.131] (edumazet-port [172.16.0.131]) by gw1.cosmosbay.com (8.13.3/8.13.3) with ESMTP id j2IHDspY019591; Fri, 18 Mar 2005 18:13:54 +0100 Message-ID: <423B0C58.10709@cosmosbay.com> Date: Fri, 18 Mar 2005 18:14:00 +0100 From: Eric Dumazet User-Agent: Mozilla Thunderbird 1.0 (Windows/20041206) X-Accept-Language: fr, en MIME-Version: 1.0 To: Stephen Hemminger CC: acme@conectiva.com.br, "David S. Miller" , netdev@oss.sgi.com Subject: Re: [PATCH] /proc/net/stat/rt_cache has a wrong header References: <4238C388.5040303@cosmosbay.com> <423AC418.6080903@cosmosbay.com> <20050318085056.0869394b@dxpl.pdx.osdl.net> In-Reply-To: <20050318085056.0869394b@dxpl.pdx.osdl.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-1.6 (gw1.cosmosbay.com [172.16.8.80]); Fri, 18 Mar 2005 18:13:55 +0100 (CET) X-Virus-Scanned: ClamAV 0.83/772/Fri Mar 18 00:59:17 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 316 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: dada1@cosmosbay.com Precedence: bulk X-list: netdev Content-Length: 597 Lines: 23 Stephen Hemminger a écrit : > On Fri, 18 Mar 2005 13:05:44 +0100 > Eric Dumazet wrote: > > >>Hello >> >>The header of /proc/net/stat/rt_cache misses the 'in_slow_mc' field. >>This patch adds it. > > > Current iproute2 tools adapt to additional fields, but wouldn't this be breaking > the API for other tools? (if any) > > AFAIK the old stat file (/proc/net/rt_cache_acct) was OK. During the conversion to /proc/net/stat/rt_cache done in late 2.6.XX version, a bug was introduced, in kernel and also in iproute2. The API if fine, and my patch doesnt change it. Eric From dada1@cosmosbay.com Fri Mar 18 09:26:10 2005 Received: with ECARTIS (v1.0.0; list netdev); Fri, 18 Mar 2005 09:26:14 -0800 (PST) Received: from gw1.cosmosbay.com (gw1.cosmosbay.com [62.23.185.226]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j2IHQ7sl021649 for ; Fri, 18 Mar 2005 09:26:09 -0800 Received: from [172.16.0.131] (edumazet-port [172.16.0.131]) by gw1.cosmosbay.com (8.13.3/8.13.3) with ESMTP id j2IHPsNi021576; Fri, 18 Mar 2005 18:25:54 +0100 Message-ID: <423B0F28.3040508@cosmosbay.com> Date: Fri, 18 Mar 2005 18:26:00 +0100 From: Eric Dumazet User-Agent: Mozilla Thunderbird 1.0 (Windows/20041206) X-Accept-Language: fr, en MIME-Version: 1.0 To: Eric Dumazet CC: Stephen Hemminger , acme@conectiva.com.br, "David S. Miller" , netdev@oss.sgi.com Subject: Re: [PATCH] /proc/net/stat/rt_cache has a wrong header References: <4238C388.5040303@cosmosbay.com> <423AC418.6080903@cosmosbay.com> <20050318085056.0869394b@dxpl.pdx.osdl.net> <423B0C58.10709@cosmosbay.com> In-Reply-To: <423B0C58.10709@cosmosbay.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-1.6 (gw1.cosmosbay.com [172.16.8.80]); Fri, 18 Mar 2005 18:25:55 +0100 (CET) X-Virus-Scanned: ClamAV 0.83/772/Fri Mar 18 00:59:17 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 317 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: dada1@cosmosbay.com Precedence: bulk X-list: netdev Content-Length: 556 Lines: 22 Eric Dumazet a écrit : > AFAIK the old stat file (/proc/net/rt_cache_acct) was OK. > > During the conversion to /proc/net/stat/rt_cache done in late 2.6.XX > version, a bug was introduced, in kernel and also in iproute2. > > The API if fine, and my patch doesnt change it. > > Eric > > I should give more explanations about the bug : Each line contains 17 fields. But the header contains only 16 fields, one column (in_slow_mc, the 4th field) was forgotten. Thus rtstat (from last iproute2) gives wrong information starting at 4th column. Eric From itkes@fat.imec.msu.ru Fri Mar 18 09:44:31 2005 Received: with ECARTIS (v1.0.0; list netdev); Fri, 18 Mar 2005 09:44:39 -0800 (PST) Received: from fat.imec.msu.ru (postfix@fat.imec.msu.ru [193.232.114.64]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j2IHiREh026282 for ; Fri, 18 Mar 2005 09:44:28 -0800 Received: from mx.imec.msu.ru (localhost.localdomain [127.0.0.1]) by fat.imec.msu.ru (Postfix) with ESMTP id 32B87479 for ; Fri, 18 Mar 2005 20:44:22 +0300 (MSK) Received: from 80.249.146.157 (SquirrelMail authenticated user itkes) by mx.imec.msu.ru with HTTP; Fri, 18 Mar 2005 20:44:22 +0300 (MSK) Message-ID: <1033.80.249.146.157.1111167862.squirrel@mx.imec.msu.ru> Date: Fri, 18 Mar 2005 20:44:22 +0300 (MSK) Subject: A bug in the Kernel? From: itkes@fat.imec.msu.ru To: netdev@oss.sgi.com User-Agent: SquirrelMail/1.4.4 MIME-Version: 1.0 Content-Type: multipart/mixed;boundary="----=_20050318204422_25018" X-Priority: 3 (Normal) Importance: Normal X-Virus-Scanned: ClamAV 0.83/772/Fri Mar 18 00:59:17 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 318 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: itkes@fat.imec.msu.ru Precedence: bulk X-list: netdev Content-Length: 11360 Lines: 420 ------=_20050318204422_25018 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit Hello. I think, I have found a bug in the Linux Kernel. It is caused by working with lists by indexes in such operstions as routing tables dump and routing rules dump (functions fib_rules_dump in fib_rules.c and a few dump functions in fib_hash.c). If some elements are removed form the list, the index may identify not the element it identified earlier. As a result, there may happen that an application that requested the routes or rules dump, will not receive the entire table. There is how to make an application to lose some rules. 1. Add 150 rules to kernel table. 2. Application A sends an RTM_GETRULE message with flag NLM_F_DUMP. The kernel puts first 107 rules to the buffer. 3. Application B deletes first 20 rules. 4. Application A receives the first couple of data from kernel. The kernel puts next couple of rules to the buffer, begining from 108-th rule, that was 128-th earlier. As a result, 20 rules had not been sent to the application, without being deleted or modified during the dump operation. Routes can be lost, too, if you add certain 5000 routes, request their dump and remove 1000 from them during the dump. In the patch (against kernel 2.6.11) attached, I have corrected these bugs. In the modified kernel, both dumps of routes and routing rules seems to work properly. But, I think, there can be other bugs similar to this in other dump operations. Alex Itkes (Moscow State University). P.S. Sorry if you get this message twice. I have already sent it, but the first instance seems to be lost. ------=_20050318204422_25018 Content-Type: text/plain; name="patch-2.6.11-nl01" Content-Transfer-Encoding: 8bit Content-Disposition: attachment; filename="patch-2.6.11-nl01" diff -urN linux-2.6.11/include/linux/netlink.h linux-2.6.11-nl01/include/linux/netlink.h --- linux-2.6.11/include/linux/netlink.h 2005-03-02 23:04:19.000000000 +0300 +++ linux-2.6.11-nl01/include/linux/netlink.h 2005-03-08 15:03:11.000000000 +0300 @@ -145,9 +145,11 @@ int (*dump)(struct sk_buff * skb, struct netlink_callback *cb); int (*done)(struct netlink_callback *cb); int family; - long args[4]; + long args[5]; }; +#define NLCB_ZERO(cb_,k_) memset((cb_)->args+(k_),0,sizeof((cb_)->args)-(k_)*sizeof((cb_)->args[0])) + struct netlink_notify { int pid; diff -urN linux-2.6.11/net/core/rtnetlink.c linux-2.6.11-nl01/net/core/rtnetlink.c --- linux-2.6.11/net/core/rtnetlink.c 2005-03-02 23:04:21.000000000 +0300 +++ linux-2.6.11-nl01/net/core/rtnetlink.c 2005-03-08 17:27:28.000000000 +0300 @@ -425,7 +425,7 @@ rtnetlink_links[idx][type].dumpit == NULL) continue; if (idx > s_idx) - memset(&cb->args[0], 0, sizeof(cb->args)); + NLCB_ZERO(cb,0); if (rtnetlink_links[idx][type].dumpit(skb, cb)) break; } diff -urN linux-2.6.11/net/ipv4/fib_frontend.c linux-2.6.11-nl01/net/ipv4/fib_frontend.c --- linux-2.6.11/net/ipv4/fib_frontend.c 2005-03-02 23:04:21.000000000 +0300 +++ linux-2.6.11-nl01/net/ipv4/fib_frontend.c 2005-03-08 17:33:40.000000000 +0300 @@ -347,7 +347,7 @@ for (t=s_t; t<=RT_TABLE_MAX; t++) { if (t < s_t) continue; if (t > s_t) - memset(&cb->args[1], 0, sizeof(cb->args)-sizeof(cb->args[0])); + NLCB_ZERO(cb,1); if ((tb = fib_get_table(t))==NULL) continue; if (tb->tb_dump(tb, skb, cb) < 0) diff -urN linux-2.6.11/net/ipv4/fib_hash.c linux-2.6.11-nl01/net/ipv4/fib_hash.c --- linux-2.6.11/net/ipv4/fib_hash.c 2005-03-02 23:04:21.000000000 +0300 +++ linux-2.6.11-nl01/net/ipv4/fib_hash.c 2005-03-08 17:37:28.000000000 +0300 @@ -52,6 +52,9 @@ struct hlist_node fn_hash; struct list_head fn_alias; u32 fn_key; + + u32 fn_nl_links; + u8 fn_nl_dead; }; struct fn_zone { @@ -256,7 +259,7 @@ head = &fz->fz_hash[fn_hash(k, fz)]; hlist_for_each_entry(f, node, head, fn_hash) { - if (f->fn_key != k) + if (f->fn_key != k || f->fn_nl_dead) continue; err = fib_semantic_match(&f->fn_alias, @@ -296,8 +299,14 @@ hlist_for_each_entry(f, node, &fz->fz_hash[0], fn_hash) { struct fib_alias *fa; + if(f->fn_nl_dead){ + continue; + }; list_for_each_entry(fa, &f->fn_alias, fa_list) { struct fib_info *next_fi = fa->fa_info; + if (fa->fa_nl_dead){ + continue; + }; if (fa->fa_scope != res->scope || fa->fa_type != RTN_UNICAST) @@ -497,6 +506,8 @@ INIT_HLIST_NODE(&new_f->fn_hash); INIT_LIST_HEAD(&new_f->fn_alias); new_f->fn_key = key; + new_f->fn_nl_links=0; + new_f->fn_nl_dead=0; f = new_f; } @@ -506,6 +517,8 @@ new_fa->fa_scope = r->rtm_scope; new_fa->fa_state = 0; + new_fa->fa_nl_links=0; + new_fa->fa_nl_dead=0; /* * Insert new entry to the list. */ @@ -591,8 +604,17 @@ int kill_fn; fa = fa_to_delete; + if(fa->fa_nl_dead){ + tb->tb_flush(tb); + return -ESRCH; + }; rtmsg_fib(RTM_DELROUTE, key, fa, z, tb->tb_id, n, req); - + + if(fa->fa_nl_links){ + fa->fa_nl_dead=1; + tb->tb_flush(tb); + return 0; + }; kill_fn = 0; write_lock_bh(&fib_hash_lock); list_del(&fa->fa_list); @@ -630,7 +652,7 @@ list_for_each_entry_safe(fa, fa_node, &f->fn_alias, fa_list) { struct fib_info *fi = fa->fa_info; - if (fi && (fi->fib_flags&RTNH_F_DEAD)) { + if ((fi && (fi->fib_flags&RTNH_F_DEAD))||(fa->fa_nl_dead&&(fa->fa_nl_links==0))) { write_lock_bh(&fib_hash_lock); list_del(&fa->fa_list); if (list_empty(&f->fn_alias)) { @@ -675,17 +697,42 @@ { struct hlist_node *node; struct fib_node *f; - int i, s_i; - - s_i = cb->args[3]; - i = 0; + int flag1=0; + int flag2=0; + + if(cb->args[3]==0){ + flag1=1; + }; hlist_for_each_entry(f, node, head, fn_hash) { struct fib_alias *fa; + if(flag1==0){ + if((long)(f)==cb->args[3]){ + --(f->fn_nl_links); + flag1=1; + }else{ + continue; + }; + }; + if(cb->args[4]==0){ + flag2=1; + }; + if(f->fn_nl_dead){ + continue; + }; list_for_each_entry(fa, &f->fn_alias, fa_list) { - if (i < s_i) - goto next; + if(flag2==0){ + if((long)(fa)==cb->args[4]){ + --(fa->fa_nl_links); + flag2=1; + }else{ + continue; + }; + }; + if(fa->fa_nl_dead){ + continue; + }; if (fib_dump_info(skb, NETLINK_CB(cb->skb).pid, cb->nlh->nlmsg_seq, RTM_NEWROUTE, @@ -696,14 +743,16 @@ fz->fz_order, fa->fa_tos, fa->fa_info) < 0) { - cb->args[3] = i; + ++(fa->fa_nl_links); + ++(f->fn_nl_links); + cb->args[4]=(long)(fa); + cb->args[3]=(long)(f); return -1; } - next: - i++; } } - cb->args[3] = i; + cb->args[4]=0; + cb->args[3]=0; return skb->len; } @@ -718,8 +767,7 @@ for (h=0; h < fz->fz_divisor; h++) { if (h < s_h) continue; if (h > s_h) - memset(&cb->args[3], 0, - sizeof(cb->args) - 3*sizeof(cb->args[0])); + NLCB_ZERO(cb,3); if (fz->fz_hash == NULL || hlist_empty(&fz->fz_hash[h])) continue; @@ -734,25 +782,27 @@ static int fn_hash_dump(struct fib_table *tb, struct sk_buff *skb, struct netlink_callback *cb) { - int m, s_m; struct fn_zone *fz; struct fn_hash *table = (struct fn_hash*)tb->tb_data; - s_m = cb->args[1]; read_lock(&fib_hash_lock); - for (fz = table->fn_zone_list, m=0; fz; fz = fz->fz_next, m++) { - if (m < s_m) continue; - if (m > s_m) - memset(&cb->args[2], 0, - sizeof(cb->args) - 2*sizeof(cb->args[0])); + if(cb->args[1]){ + fz=(struct fn_zone*)(cb->args[1]); + }else{ + fz=table->fn_zone_list; + }; + for (; fz; fz = fz->fz_next) { + if((long)(fz)!=cb->args[1]){ + NLCB_ZERO(cb,2); + }; if (fn_hash_dump_zone(skb, cb, tb, fz) < 0) { - cb->args[1] = m; + cb->args[1] = (long)(fz); read_unlock(&fib_hash_lock); return -1; } } read_unlock(&fib_hash_lock); - cb->args[1] = m; + cb->args[1] = 0; return skb->len; } diff -urN linux-2.6.11/net/ipv4/fib_lookup.h linux-2.6.11-nl01/net/ipv4/fib_lookup.h --- linux-2.6.11/net/ipv4/fib_lookup.h 2005-03-02 23:04:21.000000000 +0300 +++ linux-2.6.11-nl01/net/ipv4/fib_lookup.h 2005-03-08 12:51:36.000000000 +0300 @@ -12,6 +12,9 @@ u8 fa_type; u8 fa_scope; u8 fa_state; + + u32 fa_nl_links; + u8 fa_nl_dead; }; #define FA_S_ACCESSED 0x01 diff -urN linux-2.6.11/net/ipv4/fib_rules.c linux-2.6.11-nl01/net/ipv4/fib_rules.c --- linux-2.6.11/net/ipv4/fib_rules.c 2005-03-02 23:04:21.000000000 +0300 +++ linux-2.6.11-nl01/net/ipv4/fib_rules.c 2005-03-08 17:33:25.000000000 +0300 @@ -74,6 +74,9 @@ #endif char r_ifname[IFNAMSIZ]; int r_dead; + + u32 r_nl_links; + u8 r_nl_dead; }; static struct fib_rule default_rule = { @@ -101,6 +104,28 @@ static struct fib_rule *fib_rules = &local_rule; static DEFINE_RWLOCK(fib_rules_lock); +static void nl_rules_flush(void) +{ + struct fib_rule *r, **rp; + + for(rp=&fib_rules;(r=*rp)!=NULL;rp=&r->r_next){ + next:; + if(r->r_nl_dead&&(r->r_nl_links==0)){ + write_lock_bh(&fib_rules_lock); + *rp = r->r_next; + r->r_dead = 1; + write_unlock_bh(&fib_rules_lock); + fib_rule_put(r); + r=*rp; + if(r==0){ + return; + }else{ + goto next; + }; + }; + }; +} + int inet_rtm_delrule(struct sk_buff *skb, struct nlmsghdr* nlh, void *arg) { struct rtattr **rta = arg; @@ -121,10 +146,18 @@ (!rta[RTA_PRIORITY-1] || memcmp(RTA_DATA(rta[RTA_PRIORITY-1]), &r->r_preference, 4) == 0) && (!rta[RTA_IIF-1] || rtattr_strcmp(rta[RTA_IIF-1], r->r_ifname) == 0) && (!rtm->rtm_table || (r && rtm->rtm_table == r->r_table))) { + if(r->r_nl_dead==1){ + nl_rules_flush(); + break; + }; err = -EPERM; if (r == &local_rule) break; - + if(r->r_nl_links!=0){ + r->r_nl_dead=1; + nl_rules_flush(); + return 0; + }; write_lock_bh(&fib_rules_lock); *rp = r->r_next; r->r_dead = 1; @@ -198,6 +231,8 @@ new_r->r_srcmask = inet_make_mask(rtm->rtm_src_len); new_r->r_dstmask = inet_make_mask(rtm->rtm_dst_len); new_r->r_tos = rtm->rtm_tos; + new_r->r_nl_links=0; + new_r->r_nl_dead=0; #ifdef CONFIG_IP_ROUTE_FWMARK if (rta[RTA_PROTOINFO-1]) memcpy(&new_r->r_fwmark, RTA_DATA(rta[RTA_PROTOINFO-1]), 4); @@ -293,6 +328,9 @@ NIPQUAD(flp->fl4_dst), NIPQUAD(flp->fl4_src)); read_lock(&fib_rules_lock); for (r = fib_rules; r; r=r->r_next) { + if(r->r_nl_dead){ + continue; + }; if (((saddr^r->r_src) & r->r_srcmask) || ((daddr^r->r_dst) & r->r_dstmask) || (r->r_tos && r->r_tos != flp->fl4_tos) || @@ -414,19 +452,30 @@ int inet_dump_rules(struct sk_buff *skb, struct netlink_callback *cb) { - int idx; - int s_idx = cb->args[0]; struct fib_rule *r; - + + if(cb->args[0]==(-1)){ + return 0; + }; read_lock(&fib_rules_lock); - for (r=fib_rules, idx=0; r; r = r->r_next, idx++) { - if (idx < s_idx) - continue; - if (inet_fill_rule(skb, r, cb) < 0) - break; + if(cb->args[0]){ + r=(struct fib_rule*)(cb->args[0]); + --(r->r_nl_links); + }else{ + r=fib_rules; + }; + for (; r; r = r->r_next) { + if(r->r_nl_dead){ + continue; + }; + if (inet_fill_rule(skb, r, cb) < 0){ + ++(r->r_nl_links); + cb->args[0]=(long)(r); + return skb->len; + }; } + cb->args[0]=(-1); read_unlock(&fib_rules_lock); - cb->args[0] = idx; return skb->len; } ------=_20050318204422_25018-- From shemminger@osdl.org Fri Mar 18 09:59:33 2005 Received: with ECARTIS (v1.0.0; list netdev); Fri, 18 Mar 2005 09:59:40 -0800 (PST) Received: from smtp.osdl.org (fire.osdl.org [65.172.181.4]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j2IHxXtM029323 for ; Fri, 18 Mar 2005 09:59:33 -0800 Received: from shell0.pdx.osdl.net (fw.osdl.org [65.172.181.6]) by smtp.osdl.org (8.12.8/8.12.8) with ESMTP id j2IHxLqi016530 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO); Fri, 18 Mar 2005 09:59:21 -0800 Received: from dxpl.pdx.osdl.net (dxpl.pdx.osdl.net [172.20.1.103]) by shell0.pdx.osdl.net (8.13.1/8.11.6) with ESMTP id j2IHxLd3011009; Fri, 18 Mar 2005 09:59:21 -0800 Date: Fri, 18 Mar 2005 09:59:39 -0800 From: Stephen Hemminger To: itkes@fat.imec.msu.ru Cc: netdev@oss.sgi.com Subject: Re: A bug in the Kernel? Message-ID: <20050318095939.5550d7bb@dxpl.pdx.osdl.net> In-Reply-To: <1033.80.249.146.157.1111167862.squirrel@mx.imec.msu.ru> References: <1033.80.249.146.157.1111167862.squirrel@mx.imec.msu.ru> Organization: Open Source Development Lab X-Mailer: Sylpheed-Claws 1.0.1 (GTK+ 1.2.10; x86_64-unknown-linux-gnu) X-Face: &@E+xe?c%:&e4D{>f1O<&U>2qwRREG5!}7R4;D<"NO^UI2mJ[eEOA2*3>(`Th.yP,VDPo9$ /`~cw![cmj~~jWe?AHY7D1S+\}5brN0k*NE?pPh_'_d>6;XGG[\KDRViCfumZT3@[ Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Received-SPF: pass (domain of shemminger@osdl.org designates 65.172.181.6 as permitted sender) X-MIMEDefang-Filter: osdl$Revision: 1.105 $ X-Scanned-By: MIMEDefang 2.36 X-Virus-Scanned: ClamAV 0.83/772/Fri Mar 18 00:59:17 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 319 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: shemminger@osdl.org Precedence: bulk X-list: netdev Content-Length: 1995 Lines: 47 On Fri, 18 Mar 2005 20:44:22 +0300 (MSK) itkes@fat.imec.msu.ru wrote: > Hello. > > I think, I have found a bug in the Linux Kernel. It is caused by working > with lists by indexes in such operstions as routing tables dump and > routing rules dump (functions fib_rules_dump in fib_rules.c and a few dump > functions in fib_hash.c). If some elements are removed form the list, the > index may identify not the element it identified earlier. As a result, > there may happen that an application that requested the routes or rules > dump, will not receive the entire table. There is how > to make an application to lose some rules. > > 1. Add 150 rules to kernel table. > 2. Application A sends an RTM_GETRULE message with flag NLM_F_DUMP. The > kernel puts first 107 rules to the buffer. > 3. Application B deletes first 20 rules. > 4. Application A receives the first couple of data from kernel. The kernel > puts next couple of rules to the buffer, begining from 108-th rule, that > was 128-th earlier. > As a result, 20 rules had not been sent to the application, without being > deleted or modified during the dump operation. > > Routes can be lost, too, if you add certain 5000 routes, request their > dump and remove 1000 from them during the dump. > > In the patch (against kernel 2.6.11) attached, I have corrected these > bugs. In the modified kernel, both dumps of routes and routing rules seems > to work properly. But, I think, there can be other bugs similar to this in > other dump operations. > > Alex Itkes (Moscow State University). > > P.S. Sorry if you get this message twice. I have already sent it, but the > first instance seems to be lost. Couple of minor nits. Incorrect indentation: if (idx > s_idx) - memset(&cb->args[0], 0, sizeof(cb->args)); + NLCB_ZERO(cb,0); ^^^^-- should be tab Why introduce a macro instead of the memset, it seems to just confuse the issue. Better to make it an inline function with a name like rtnl_cb_zero(...) From davem@davemloft.net Fri Mar 18 10:40:40 2005 Received: with ECARTIS (v1.0.0; list netdev); Fri, 18 Mar 2005 10:40:45 -0800 (PST) Received: from cheetah.davemloft.net (mail@dsl027-180-174.sfo1.dsl.speakeasy.net [216.27.180.174]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j2IIeeTv031830 for ; Fri, 18 Mar 2005 10:40:40 -0800 Received: from localhost ([127.0.0.1] helo=cheetah.davemloft.net ident=davem) by cheetah.davemloft.net with smtp (Exim 3.36 #1 (Debian)) id 1DCMOL-0007Cu-00; Fri, 18 Mar 2005 10:40:13 -0800 Date: Fri, 18 Mar 2005 10:40:13 -0800 From: "David S. Miller" To: Herbert Xu Cc: kuznet@ms2.inr.ac.ru, yoshfuji@linux-ipv6.org, kaber@trash.net, netdev@oss.sgi.com Subject: Re: [22/*] [NETFILTER] Use correct IPsec MTU in TCPMSS Message-Id: <20050318104013.57d65e99.davem@davemloft.net> In-Reply-To: <20050318091129.GA28658@gondor.apana.org.au> References: <20050214221607.GC18465@gondor.apana.org.au> <20050306213214.7d8a143d.davem@davemloft.net> <20050307103536.GB7137@gondor.apana.org.au> <20050308102741.GA23468@gondor.apana.org.au> <20050314102614.GA9610@gondor.apana.org.au> <20050314105313.GA21001@gondor.apana.org.au> <20050314111002.GA29156@gondor.apana.org.au> <20050315091904.GA6256@gondor.apana.org.au> <20050315095837.GA7130@gondor.apana.org.au> <20050318090310.GA28443@gondor.apana.org.au> <20050318091129.GA28658@gondor.apana.org.au> X-Mailer: Sylpheed version 1.0.1 (GTK+ 1.2.10; sparc-unknown-linux-gnu) X-Face: "_;p5u5aPsO,_Vsx"^v-pEq09'CU4&Dc1$fQExov$62l60cgCc%FnIwD=.UF^a>?5'9Kn[;433QFVV9M..2eN.@4ZWPGbdi<=?[:T>y?SD(R*-3It"Vj:)"dP Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV 0.83/772/Fri Mar 18 00:59:17 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 321 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: davem@davemloft.net Precedence: bulk X-list: netdev Content-Length: 865 Lines: 23 On Fri, 18 Mar 2005 20:11:29 +1100 Herbert Xu wrote: > This patch makes ipt_TCPMSS use the correct MTU value for clamping. > This is a bit tricky actually since TCPMSS can be used in FORWARD, > LOCAL_OUT as well as POST_ROUTING. > > In the first two cases we haven't performed IPsec yet so dst_mtu > obviously does the right thing. As it is, POST_ROUTING is performed > after xfrm_output so MSS clamping is useless there. > > With Patrick's IPsec netfilter stuff, there will be a POST_ROUTING > processing before IPsec processing, in which case dst_mtu also returns > exactly what we want. > > Signed-off-by: Herbert Xu Applied, thanks Herbert. > BTW Patrick, how is the IPsec netfilter stuff going? That boy is seriously backlogged, so I'm not sure how much time he's gotten to work on that yet. From davem@davemloft.net Fri Mar 18 10:40:05 2005 Received: with ECARTIS (v1.0.0; list netdev); Fri, 18 Mar 2005 10:40:13 -0800 (PST) Received: from cheetah.davemloft.net (mail@dsl027-180-174.sfo1.dsl.speakeasy.net [216.27.180.174]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j2IIe5lQ031706 for ; Fri, 18 Mar 2005 10:40:05 -0800 Received: from localhost ([127.0.0.1] helo=cheetah.davemloft.net ident=davem) by cheetah.davemloft.net with smtp (Exim 3.36 #1 (Debian)) id 1DCMNF-0007Ca-00; Fri, 18 Mar 2005 10:39:05 -0800 Date: Fri, 18 Mar 2005 10:39:05 -0800 From: "David S. Miller" To: Herbert Xu Cc: kuznet@ms2.inr.ac.ru, yoshfuji@linux-ipv6.org, kaber@trash.net, netdev@oss.sgi.com Subject: Re: [21/*] [IPv4] Fix MTU check in ipmr_queue_xmit Message-Id: <20050318103905.0455cca8.davem@davemloft.net> In-Reply-To: <20050318090310.GA28443@gondor.apana.org.au> References: <20050214221433.GB18465@gondor.apana.org.au> <20050214221607.GC18465@gondor.apana.org.au> <20050306213214.7d8a143d.davem@davemloft.net> <20050307103536.GB7137@gondor.apana.org.au> <20050308102741.GA23468@gondor.apana.org.au> <20050314102614.GA9610@gondor.apana.org.au> <20050314105313.GA21001@gondor.apana.org.au> <20050314111002.GA29156@gondor.apana.org.au> <20050315091904.GA6256@gondor.apana.org.au> <20050315095837.GA7130@gondor.apana.org.au> <20050318090310.GA28443@gondor.apana.org.au> X-Mailer: Sylpheed version 1.0.1 (GTK+ 1.2.10; sparc-unknown-linux-gnu) X-Face: "_;p5u5aPsO,_Vsx"^v-pEq09'CU4&Dc1$fQExov$62l60cgCc%FnIwD=.UF^a>?5'9Kn[;433QFVV9M..2eN.@4ZWPGbdi<=?[:T>y?SD(R*-3It"Vj:)"dP Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV 0.83/772/Fri Mar 18 00:59:17 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 320 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: davem@davemloft.net Precedence: bulk X-list: netdev Content-Length: 660 Lines: 19 On Fri, 18 Mar 2005 20:03:10 +1100 Herbert Xu wrote: > Somehow I missed four files with dst_pmtu usages in them. I'm going > to split them along the sames lines I did before: bug fixes and then > the trivial changes. Must be some bug in your grep binary... kidding ;-) > Here is a patch that replaces dst_pmtu with dst_pmtu in ipmr.c > since this is straight IPIP tunneling equivalent to what we have > in ipip.c. > > As it is we may send ICMP packets when IPsec is present which is > exactly what the comment says that we shouldn't do. > > Signed-off-by: Herbert Xu Applied, thanks Herbert. From davem@davemloft.net Fri Mar 18 10:42:19 2005 Received: with ECARTIS (v1.0.0; list netdev); Fri, 18 Mar 2005 10:42:24 -0800 (PST) Received: from cheetah.davemloft.net (mail@dsl027-180-174.sfo1.dsl.speakeasy.net [216.27.180.174]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j2IIgJ1C032451 for ; Fri, 18 Mar 2005 10:42:19 -0800 Received: from localhost ([127.0.0.1] helo=cheetah.davemloft.net ident=davem) by cheetah.davemloft.net with smtp (Exim 3.36 #1 (Debian)) id 1DCMPv-0007Dx-00; Fri, 18 Mar 2005 10:41:51 -0800 Date: Fri, 18 Mar 2005 10:41:51 -0800 From: "David S. Miller" To: Herbert Xu Cc: kuznet@ms2.inr.ac.ru, yoshfuji@linux-ipv6.org, kaber@trash.net, netdev@oss.sgi.com Subject: Re: [23/*] [IPV4] Kill remaining unnecessary uses of dst_pmtu Message-Id: <20050318104151.068adf9f.davem@davemloft.net> In-Reply-To: <20050318091918.GA28944@gondor.apana.org.au> References: <20050306213214.7d8a143d.davem@davemloft.net> <20050307103536.GB7137@gondor.apana.org.au> <20050308102741.GA23468@gondor.apana.org.au> <20050314102614.GA9610@gondor.apana.org.au> <20050314105313.GA21001@gondor.apana.org.au> <20050314111002.GA29156@gondor.apana.org.au> <20050315091904.GA6256@gondor.apana.org.au> <20050315095837.GA7130@gondor.apana.org.au> <20050318090310.GA28443@gondor.apana.org.au> <20050318091129.GA28658@gondor.apana.org.au> <20050318091918.GA28944@gondor.apana.org.au> X-Mailer: Sylpheed version 1.0.1 (GTK+ 1.2.10; sparc-unknown-linux-gnu) X-Face: "_;p5u5aPsO,_Vsx"^v-pEq09'CU4&Dc1$fQExov$62l60cgCc%FnIwD=.UF^a>?5'9Kn[;433QFVV9M..2eN.@4ZWPGbdi<=?[:T>y?SD(R*-3It"Vj:)"dP Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV 0.83/772/Fri Mar 18 00:59:17 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 322 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: davem@davemloft.net Precedence: bulk X-list: netdev Content-Length: 959 Lines: 22 On Fri, 18 Mar 2005 20:19:18 +1100 Herbert Xu wrote: > Once again here is a couple of trivial dst_pmtu/dst_mtu replacements. > In both locations, we can only have simple dst entries which means > that dst == dst->path. > > BTW, this is the rule that we should apply in future for uses of > dst_mtu/dst_pmtu (or other metrics on dst). If the only dst's that > can appear are simple dst's (dst == dst->path), then we should use > dst_mtu or dst_metric. If dst != dst->path, then whoever is writing > the code will need to think about which of dst or dst->path is the > right one. > > In most instances dst will be the one. However, as we have seen in > ip_append_data, dst->path may be needed rarely. In particular, if > we're doing fragmentation immediately after IPsec, then you may need > it. > > Signed-off-by: Herbert Xu Applied, and thanks for the nice succinct version of the rule :-) From davem@davemloft.net Fri Mar 18 10:44:17 2005 Received: with ECARTIS (v1.0.0; list netdev); Fri, 18 Mar 2005 10:44:22 -0800 (PST) Received: from cheetah.davemloft.net (mail@dsl027-180-174.sfo1.dsl.speakeasy.net [216.27.180.174]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j2IIiGW4000712 for ; Fri, 18 Mar 2005 10:44:16 -0800 Received: from localhost ([127.0.0.1] helo=cheetah.davemloft.net ident=davem) by cheetah.davemloft.net with smtp (Exim 3.36 #1 (Debian)) id 1DCMRq-0007EK-00; Fri, 18 Mar 2005 10:43:50 -0800 Date: Fri, 18 Mar 2005 10:43:50 -0800 From: "David S. Miller" To: Herbert Xu Cc: kuznet@ms2.inr.ac.ru, yoshfuji@linux-ipv6.org, kaber@trash.net, netdev@oss.sgi.com Subject: Re: [24/*] [IPSEC] Get ttl from child instead of path Message-Id: <20050318104350.009e6af7.davem@davemloft.net> In-Reply-To: <20050318100757.GA29433@gondor.apana.org.au> References: <20050307103536.GB7137@gondor.apana.org.au> <20050308102741.GA23468@gondor.apana.org.au> <20050314102614.GA9610@gondor.apana.org.au> <20050314105313.GA21001@gondor.apana.org.au> <20050314111002.GA29156@gondor.apana.org.au> <20050315091904.GA6256@gondor.apana.org.au> <20050315095837.GA7130@gondor.apana.org.au> <20050318090310.GA28443@gondor.apana.org.au> <20050318091129.GA28658@gondor.apana.org.au> <20050318091918.GA28944@gondor.apana.org.au> <20050318100757.GA29433@gondor.apana.org.au> X-Mailer: Sylpheed version 1.0.1 (GTK+ 1.2.10; sparc-unknown-linux-gnu) X-Face: "_;p5u5aPsO,_Vsx"^v-pEq09'CU4&Dc1$fQExov$62l60cgCc%FnIwD=.UF^a>?5'9Kn[;433QFVV9M..2eN.@4ZWPGbdi<=?[:T>y?SD(R*-3It"Vj:)"dP Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV 0.83/772/Fri Mar 18 00:59:17 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 323 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: davem@davemloft.net Precedence: bulk X-list: netdev Content-Length: 612 Lines: 18 On Fri, 18 Mar 2005 21:07:57 +1100 Herbert Xu wrote: > Now that dst_pmtu is almost gone let's do the same to dst_path_metric. > I've only found one legitimate use of it and that's the one that was > recently added in dst_allfrag. > > This patch makes xfrm4_encap/xfrm6_encap use dst->child instead of > dst->path so that we choose the correct route to get the hoplimit > from when nested tunnels are present. > > For simple tunnels dst->child == dst->path so there is no change. > > Signed-off-by: Herbert Xu Looks good, applied. Thanks Herbert. From davem@davemloft.net Fri Mar 18 10:45:12 2005 Received: with ECARTIS (v1.0.0; list netdev); Fri, 18 Mar 2005 10:45:17 -0800 (PST) Received: from cheetah.davemloft.net (mail@dsl027-180-174.sfo1.dsl.speakeasy.net [216.27.180.174]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j2IIjAAR001133 for ; Fri, 18 Mar 2005 10:45:10 -0800 Received: from localhost ([127.0.0.1] helo=cheetah.davemloft.net ident=davem) by cheetah.davemloft.net with smtp (Exim 3.36 #1 (Debian)) id 1DCMSa-0007EY-00; Fri, 18 Mar 2005 10:44:36 -0800 Date: Fri, 18 Mar 2005 10:44:36 -0800 From: "David S. Miller" To: Herbert Xu Cc: kuznet@ms2.inr.ac.ru, yoshfuji@linux-ipv6.org, kaber@trash.net, netdev@oss.sgi.com Subject: Re: [25/*] [NET] Kill unnecessary uses of dst_path_metric Message-Id: <20050318104436.62535f2c.davem@davemloft.net> In-Reply-To: <20050318101126.GA29583@gondor.apana.org.au> References: <20050308102741.GA23468@gondor.apana.org.au> <20050314102614.GA9610@gondor.apana.org.au> <20050314105313.GA21001@gondor.apana.org.au> <20050314111002.GA29156@gondor.apana.org.au> <20050315091904.GA6256@gondor.apana.org.au> <20050315095837.GA7130@gondor.apana.org.au> <20050318090310.GA28443@gondor.apana.org.au> <20050318091129.GA28658@gondor.apana.org.au> <20050318091918.GA28944@gondor.apana.org.au> <20050318100757.GA29433@gondor.apana.org.au> <20050318101126.GA29583@gondor.apana.org.au> X-Mailer: Sylpheed version 1.0.1 (GTK+ 1.2.10; sparc-unknown-linux-gnu) X-Face: "_;p5u5aPsO,_Vsx"^v-pEq09'CU4&Dc1$fQExov$62l60cgCc%FnIwD=.UF^a>?5'9Kn[;433QFVV9M..2eN.@4ZWPGbdi<=?[:T>y?SD(R*-3It"Vj:)"dP Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV 0.83/772/Fri Mar 18 00:59:17 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 324 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: davem@davemloft.net Precedence: bulk X-list: netdev Content-Length: 275 Lines: 9 On Fri, 18 Mar 2005 21:11:26 +1100 Herbert Xu wrote: > This gets rid of the last unnecessary use of dst_path_metric. In > decnet dst->path is always equal to dst. > > Signed-off-by: Herbert Xu Applied, thanks. From davem@davemloft.net Fri Mar 18 10:46:29 2005 Received: with ECARTIS (v1.0.0; list netdev); Fri, 18 Mar 2005 10:46:34 -0800 (PST) Received: from cheetah.davemloft.net (mail@dsl027-180-174.sfo1.dsl.speakeasy.net [216.27.180.174]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j2IIkSH7001727 for ; Fri, 18 Mar 2005 10:46:28 -0800 Received: from localhost ([127.0.0.1] helo=cheetah.davemloft.net ident=davem) by cheetah.davemloft.net with smtp (Exim 3.36 #1 (Debian)) id 1DCMTx-0007FI-00; Fri, 18 Mar 2005 10:46:01 -0800 Date: Fri, 18 Mar 2005 10:46:00 -0800 From: "David S. Miller" To: Herbert Xu Cc: kuznet@ms2.inr.ac.ru, yoshfuji@linux-ipv6.org, kaber@trash.net, netdev@oss.sgi.com Subject: Re: [26/*] [NET] Kill dst_pmtu/dst_path_metric Message-Id: <20050318104600.3a3783c5.davem@davemloft.net> In-Reply-To: <20050318110611.GA5843@gondor.apana.org.au> References: <20050314102614.GA9610@gondor.apana.org.au> <20050314105313.GA21001@gondor.apana.org.au> <20050314111002.GA29156@gondor.apana.org.au> <20050315091904.GA6256@gondor.apana.org.au> <20050315095837.GA7130@gondor.apana.org.au> <20050318090310.GA28443@gondor.apana.org.au> <20050318091129.GA28658@gondor.apana.org.au> <20050318091918.GA28944@gondor.apana.org.au> <20050318100757.GA29433@gondor.apana.org.au> <20050318101126.GA29583@gondor.apana.org.au> <20050318110611.GA5843@gondor.apana.org.au> X-Mailer: Sylpheed version 1.0.1 (GTK+ 1.2.10; sparc-unknown-linux-gnu) X-Face: "_;p5u5aPsO,_Vsx"^v-pEq09'CU4&Dc1$fQExov$62l60cgCc%FnIwD=.UF^a>?5'9Kn[;433QFVV9M..2eN.@4ZWPGbdi<=?[:T>y?SD(R*-3It"Vj:)"dP Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV 0.83/772/Fri Mar 18 00:59:17 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 325 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: davem@davemloft.net Precedence: bulk X-list: netdev Content-Length: 573 Lines: 17 On Fri, 18 Mar 2005 22:06:11 +1100 Herbert Xu wrote: > This would have been the patch that removed dst->path. But > ip_append_data got in the way :) > > However, using dst->path is only needed rarely and should always > require a bit of deliberation. So let's get rid of dst_pmtu > and dst_path_metric and use dst_mtu and dst_metric directly. > > Signed-off-by: Herbert Xu Applied, thanks. > BTW, shouldn't dst_allfrag be called dst_path_allfrag? If you think that makes it's functionality clearer, sure. From davem@davemloft.net Fri Mar 18 10:48:02 2005 Received: with ECARTIS (v1.0.0; list netdev); Fri, 18 Mar 2005 10:48:07 -0800 (PST) Received: from cheetah.davemloft.net (mail@dsl027-180-174.sfo1.dsl.speakeasy.net [216.27.180.174]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j2IIm21o002447 for ; Fri, 18 Mar 2005 10:48:02 -0800 Received: from localhost ([127.0.0.1] helo=cheetah.davemloft.net ident=davem) by cheetah.davemloft.net with smtp (Exim 3.36 #1 (Debian)) id 1DCMVS-0007Fi-00; Fri, 18 Mar 2005 10:47:34 -0800 Date: Fri, 18 Mar 2005 10:47:34 -0800 From: "David S. Miller" To: Herbert Xu Cc: kuznet@ms2.inr.ac.ru, yoshfuji@linux-ipv6.org, kaber@trash.net, netdev@oss.sgi.com Subject: Re: [27/*] [NET] Make dst_allfrag use dst instead of dst->path Message-Id: <20050318104734.27da53e6.davem@davemloft.net> In-Reply-To: <20050318112804.GA6930@gondor.apana.org.au> References: <20050314105313.GA21001@gondor.apana.org.au> <20050314111002.GA29156@gondor.apana.org.au> <20050315091904.GA6256@gondor.apana.org.au> <20050315095837.GA7130@gondor.apana.org.au> <20050318090310.GA28443@gondor.apana.org.au> <20050318091129.GA28658@gondor.apana.org.au> <20050318091918.GA28944@gondor.apana.org.au> <20050318100757.GA29433@gondor.apana.org.au> <20050318101126.GA29583@gondor.apana.org.au> <20050318110611.GA5843@gondor.apana.org.au> <20050318112804.GA6930@gondor.apana.org.au> X-Mailer: Sylpheed version 1.0.1 (GTK+ 1.2.10; sparc-unknown-linux-gnu) X-Face: "_;p5u5aPsO,_Vsx"^v-pEq09'CU4&Dc1$fQExov$62l60cgCc%FnIwD=.UF^a>?5'9Kn[;433QFVV9M..2eN.@4ZWPGbdi<=?[:T>y?SD(R*-3It"Vj:)"dP Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV 0.83/772/Fri Mar 18 00:59:17 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 326 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: davem@davemloft.net Precedence: bulk X-list: netdev Content-Length: 512 Lines: 16 On Fri, 18 Mar 2005 22:28:04 +1100 Herbert Xu wrote: > Rather than doing that, let's make the path usage explicit in > the one place that it's needed (the same place where we use > dst_mtu(dst->path)). > > Signed-off-by: Herbert Xu Ok, applied. > Hmm, it still doesn't feel right to have an IPv6-specific helper > in net/dst.h. We have tons of stuff in the neighbour layer that really is only taken advantage of by ipv6, it's a similar situation. From chrisw@osdl.org Fri Mar 18 11:11:00 2005 Received: with ECARTIS (v1.0.0; list netdev); Fri, 18 Mar 2005 11:11:06 -0800 (PST) Received: from smtp.osdl.org (fire.osdl.org [65.172.181.4]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j2IJB0vg004268 for ; Fri, 18 Mar 2005 11:11:00 -0800 Received: from shell0.pdx.osdl.net (fw.osdl.org [65.172.181.6]) by smtp.osdl.org (8.12.8/8.12.8) with ESMTP id j2IJAsqi023065 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO); Fri, 18 Mar 2005 11:10:54 -0800 Received: from shell0.pdx.osdl.net (localhost [127.0.0.1]) by shell0.pdx.osdl.net (8.13.1/8.11.6) with ESMTP id j2IJArGk015125; Fri, 18 Mar 2005 11:10:53 -0800 Received: (from chrisw@localhost) by shell0.pdx.osdl.net (8.13.1/8.13.1/Submit) id j2IJArLK015124; Fri, 18 Mar 2005 11:10:53 -0800 Date: Fri, 18 Mar 2005 11:10:53 -0800 From: Chris Wright To: jgarzik@pobox.com Cc: netdev@oss.sgi.com Subject: [PATCH] remove unused ethertap_mc support Message-ID: <20050318191053.GN5389@shell0.pdx.osdl.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.5.6i Received-SPF: pass (domain of chrisw@osdl.org designates 65.172.181.6 as permitted sender) X-MIMEDefang-Filter: osdl$Revision: 1.105 $ X-Scanned-By: MIMEDefang 2.36 X-Virus-Scanned: ClamAV 0.83/772/Fri Mar 18 00:59:17 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 327 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: chrisw@osdl.org Precedence: bulk X-list: netdev Content-Length: 4198 Lines: 154 There is no Kconfig option to enable CONFIG_ETHERTAP_MC, and if you could the resulting source would not build. That code uses the obsolete protinfo union, then further pokes into a privately defined netlink structure to setup the groups. Remove this broken code altogether. Signed-off-by: Chris Wright drivers/net/ethertap.c | 84 ------------------------------------------------- 1 files changed, 84 deletions(-) ===== drivers/net/ethertap.c 1.16 vs edited ===== --- 1.16/drivers/net/ethertap.c 2005-02-16 06:40:17 -08:00 +++ edited/drivers/net/ethertap.c 2005-03-18 11:00:38 -08:00 @@ -38,9 +38,6 @@ static int ethertap_start_xmit(struct s static int ethertap_close(struct net_device *dev); static struct net_device_stats *ethertap_get_stats(struct net_device *dev); static void ethertap_rx(struct sock *sk, int len); -#ifdef CONFIG_ETHERTAP_MC -static void set_multicast_list(struct net_device *dev); -#endif static int ethertap_debug; @@ -57,9 +54,6 @@ static struct net_device **tap_map; /* R struct net_local { struct sock *nl; -#ifdef CONFIG_ETHERTAP_MC - __u32 groups; -#endif struct net_device_stats stats; }; @@ -96,9 +90,6 @@ static int __init ethertap_probe(int un dev->hard_start_xmit = ethertap_start_xmit; dev->stop = ethertap_close; dev->get_stats = ethertap_get_stats; -#ifdef CONFIG_ETHERTAP_MC - dev->set_multicast_list = set_multicast_list; -#endif dev->tx_queue_len = 0; dev->flags|=IFF_NOARP; @@ -134,41 +125,6 @@ static int ethertap_open(struct net_devi return 0; } -#ifdef CONFIG_ETHERTAP_MC -static unsigned ethertap_mc_hash(__u8 *dest) -{ - unsigned idx = 0; - idx ^= dest[0]; - idx ^= dest[1]; - idx ^= dest[2]; - idx ^= dest[3]; - idx ^= dest[4]; - idx ^= dest[5]; - return 1U << (idx&0x1F); -} - -static void set_multicast_list(struct net_device *dev) -{ - unsigned groups = ~0; - struct net_local *lp = netdev_priv(dev); - - if (!(dev->flags&(IFF_NOARP|IFF_PROMISC|IFF_ALLMULTI))) { - struct dev_mc_list *dmi; - - groups = ethertap_mc_hash(dev->broadcast); - - for (dmi=dev->mc_list; dmi; dmi=dmi->next) { - if (dmi->dmi_addrlen != 6) - continue; - groups |= ethertap_mc_hash(dmi->dmi_addr); - } - } - lp->groups = groups; - if (lp->nl) - lp->nl->protinfo.af_netlink.groups = groups; -} -#endif - /* * We transmit by throwing the packet at netlink. We have to clone * it for 2.0 so that we dev_kfree_skb() the locked original. @@ -177,9 +133,6 @@ static void set_multicast_list(struct ne static int ethertap_start_xmit(struct sk_buff *skb, struct net_device *dev) { struct net_local *lp = netdev_priv(dev); -#ifdef CONFIG_ETHERTAP_MC - struct ethhdr *eth = (struct ethhdr*)skb->data; -#endif if (skb_headroom(skb) < 2) { static int once; @@ -213,31 +166,13 @@ static int ethertap_start_xmit(struct sk lp->stats.tx_bytes+=skb->len; lp->stats.tx_packets++; -#ifndef CONFIG_ETHERTAP_MC netlink_broadcast(lp->nl, skb, 0, ~0, GFP_ATOMIC); -#else - if (dev->flags&IFF_NOARP) { - netlink_broadcast(lp->nl, skb, 0, ~0, GFP_ATOMIC); - return 0; - } - - if (!(eth->h_dest[0]&1)) { - /* Unicast packet */ - __u32 pid; - memcpy(&pid, eth->h_dest+2, 4); - netlink_unicast(lp->nl, skb, ntohl(pid), MSG_DONTWAIT); - } else - netlink_broadcast(lp->nl, skb, 0, ethertap_mc_hash(eth->h_dest), GFP_ATOMIC); -#endif return 0; } static __inline__ int ethertap_rx_skb(struct sk_buff *skb, struct net_device *dev) { struct net_local *lp = netdev_priv(dev); -#ifdef CONFIG_ETHERTAP_MC - struct ethhdr *eth = (struct ethhdr*)(skb->data + 2); -#endif int len = skb->len; if (len < 16) { @@ -250,25 +185,6 @@ static __inline__ int ethertap_rx_skb(st kfree_skb(skb); return -EPERM; } - -#ifdef CONFIG_ETHERTAP_MC - if (!(dev->flags&(IFF_NOARP|IFF_PROMISC))) { - int drop = 0; - - if (eth->h_dest[0]&1) { - if (!(ethertap_mc_hash(eth->h_dest)&lp->groups)) - drop = 1; - } else if (memcmp(eth->h_dest, dev->dev_addr, 6) != 0) - drop = 1; - - if (drop) { - if (ethertap_debug > 3) - printk(KERN_DEBUG "%s : not for us\n", dev->name); - kfree_skb(skb); - return -EINVAL; - } - } -#endif if (skb_shared(skb)) { struct sk_buff *skb2 = skb; From alexn@dsv.su.se Fri Mar 18 12:36:29 2005 Received: with ECARTIS (v1.0.0; list netdev); Fri, 18 Mar 2005 12:36:35 -0800 (PST) Received: from swip.net (mailfe10.swip.net [212.247.155.33]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j2IKaRsv011044 for ; Fri, 18 Mar 2005 12:36:28 -0800 X-T2-Posting-ID: icQHdNe7aEavrnKIz+aKnQ== Received: from c213-100-63-205.swipnet.se ([213.100.63.205] verified) by mailfe10.swip.net (CommuniGate Pro SMTP 4.2.9) with ESMTP id 115168661; Fri, 18 Mar 2005 21:36:20 +0100 Subject: Reproducible panics with tulip From: Alexander Nyberg To: jgarzik@pobox.com Cc: netdev@oss.sgi.com Content-Type: text/plain Date: Fri, 18 Mar 2005 21:36:07 +0100 Message-Id: <1111178167.1147.9.camel@localhost.localdomain> Mime-Version: 1.0 X-Mailer: Evolution 2.0.4 Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV 0.83/772/Fri Mar 18 00:59:17 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 328 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: alexn@dsv.su.se Precedence: bulk X-list: netdev Content-Length: 19544 Lines: 506 Using latest bk I basically mount a share over NFS and run dbench 20, I get this very fast, changing the NIC to a rtl8139-driver based one makes problems go away. I don't know how earlier kernels respond to this as I haven't tried it before. tulip card is: 0000:00:0f.0 Ethernet controller: Linksys NC100 Network Everywhere Fast Ethernet 10/100 (rev 11) Warning: kfree_skb on hard IRQ c46c3950 rpciod/0: page allocation failure. order:0, mode:0x20 [] dump_stack+0x17/0x20 [] __alloc_pages+0x251/0x390 [] kmem_getpages+0x2f/0x90 [] cache_grow+0x90/0x110 [] cache_alloc_refill+0x17d/0x250 [] __kmalloc+0x98/0xb0 [] alloc_skb+0x39/0xd0 [] find_skb+0x2a/0x80 [] netpoll_send_udp+0x2b/0x230 [] write_msg+0x3a/0x50 [] __call_console_drivers+0x52/0x60 [] call_console_drivers+0x7f/0x100 [] release_console_sem+0x36/0xa0 [] vprintk+0x171/0x200 [] printk+0x18/0x20 [] __alloc_pages+0x24c/0x390 [] kmem_getpages+0x2f/0x90 [] cache_grow+0x90/0x110 [] cache_alloc_refill+0x17d/0x250 [] __kmalloc+0x98/0xb0 [] alloc_skb+0x39/0xd0 [] tulip_rx+0x28e/0x3e0 [] tulip_interrupt+0x955/0x970 [] handle_IRQ_event+0x2a/0x60 [] __do_IRQ+0xa4/0xf0 [] do_IRQ+0x1c/0x30 [] common_interrupt+0x1a/0x20 [] kfree_skbmem+0xb/0x20 [] __kfree_skb+0x53/0xc0 [] packet_rcv_spkt+0x11b/0x200 [] netif_receive_skb+0x12b/0x190 [] process_backlog+0x7e/0x100 [] net_rx_action+0x65/0xe0 [] __do_softirq+0x7a/0x90 [] do_softirq+0x2c/0x30 [] do_IRQ+0x21/0x30 [] common_interrupt+0x1a/0x20 [] inet_sendpage+0x74/0xa0 [] xdr_sendpages+0x13e/0x220 [] xprt_transmit+0xcd/0x470 [] call_transmit+0x4b/0xb0 [] __rpc_execute+0x5c/0x300 [] worker_thread+0x150/0x1e0 [] kthread+0x95/0xa0 [] kernel_thread_helper+0x5/0x10 rpciod/0: page allocation failure. order:0, mode:0x20 [] dump_stack+0x17/0x20 [] __alloc_pages+0x251/0x390 [] kmem_getpages+0x2f/0x90 [] cache_grow+0x90/0x110 [] cache_alloc_refill+0x17d/0x250 [] __kmalloc+0x98/0xb0 [] alloc_skb+0x39/0xd0 [] find_skb+0x2a/0x80 [] netpoll_send_udp+0x2b/0x230 [] write_msg+0x3a/0x50 [] __call_console_drivers+0x52/0x60 [] call_console_drivers+0x7f/0x100 [] release_console_sem+0x36/0xa0 [] vprintk+0x171/0x200 [] printk+0x18/0x20 [] __alloc_pages+0x24c/0x390 [] kmem_getpages+0x2f/0x90 [] cache_grow+0x90/0x110 [] cache_alloc_refill+0x17d/0x250 [] __kmalloc+0x98/0xb0 [] alloc_skb+0x39/0xd0 [] tulip_rx+0x28e/0x3e0 [] tulip_interrupt+0x955/0x970 [] handle_IRQ_event+0x2a/0x60 [] __do_IRQ+0xa4/0xf0 [] do_IRQ+0x1c/0x30 [] common_interrupt+0x1a/0x20 [] kfree_skbmem+0xb/0x20 [] __kfree_skb+0x53/0xc0 [] packet_rcv_spkt+0x11b/0x200 [] netif_receive_skb+0x12b/0x190 [] process_backlog+0x7e/0x100 [] net_rx_action+0x65/0xe0 [] __do_softirq+0x7a/0x90 [] do_softirq+0x2c/0x30 [] do_IRQ+0x21/0x30 [] common_interrupt+0x1a/0x20 [] inet_sendpage+0x74/0xa0 [] xdr_sendpages+0x13e/0x220 [] xprt_transmit+0xcd/0x470 [] call_transmit+0x4b/0xb0 [] __rpc_execute+0x5c/0x300 [] worker_thread+0x150/0x1e0 [] kthread+0x95/0xa0 [] kernel_thread_helper+0x5/0x10 rpciod/0: page allocation failure. order:0, mode:0x20 [] dump_stack+0x17/0x20 [] __alloc_pages+0x251/0x390 [] kmem_getpages+0x2f/0x90 [] cache_grow+0x90/0x110 [] cache_alloc_refill+0x17d/0x250 [] __kmalloc+0x98/0xb0 [] alloc_skb+0x39/0xd0 [] find_skb+0x2a/0x80 [] netpoll_send_udp+0x2b/0x230 [] write_msg+0x3a/0x50 [] __call_console_drivers+0x52/0x60 [] call_console_drivers+0x7f/0x100 [] release_console_sem+0x36/0xa0 [] vprintk+0x171/0x200 [] printk+0x18/0x20 [] __alloc_pages+0x24c/0x390 [] kmem_getpages+0x2f/0x90 [] cache_grow+0x90/0x110 [] cache_alloc_refill+0x17d/0x250 [] __kmalloc+0x98/0xb0 [] alloc_skb+0x39/0xd0 [] tulip_rx+0x28e/0x3e0 [] tulip_interrupt+0x955/0x970 [] handle_IRQ_event+0x2a/0x60 [] __do_IRQ+0xa4/0xf0 [] do_IRQ+0x1c/0x30 [] common_interrupt+0x1a/0x20 [] kfree_skbmem+0xb/0x20 [] __kfree_skb+0x53/0xc0 [] packet_rcv_spkt+0x11b/0x200 [] netif_receive_skb+0x12b/0x190 [] process_backlog+0x7e/0x100 [] net_rx_action+0x65/0xe0 [] __do_softirq+0x7a/0x90 [] do_softirq+0x2c/0x30 [] do_IRQ+0x21/0x30 [] common_interrupt+0x1a/0x20 [] inet_sendpage+0x74/0xa0 [] xdr_sendpages+0x13e/0x220 [] xprt_transmit+0xcd/0x470 [] call_transmit+0x4b/0xb0 [] __rpc_execute+0x5c/0x300 [] worker_thread+0x150/0x1e0 [] kthread+0x95/0xa0 [] kernel_thread_helper+0x5/0x10 rpciod/0: page allocation failure. order:0, mode:0x20 [] dump_stack+0x17/0x20 [] __alloc_pages+0x251/0x390 [] kmem_getpages+0x2f/0x90 [] cache_grow+0x90/0x110 [] cache_alloc_refill+0x17d/0x250 [] __kmalloc+0x98/0xb0 [] alloc_skb+0x39/0xd0 [] find_skb+0x2a/0x80 [] netpoll_send_udp+0x2b/0x230 [] write_msg+0x3a/0x50 [] __call_console_drivers+0x52/0x60 [] call_console_drivers+0x7f/0x100 [] release_console_sem+0x36/0xa0 [] vprintk+0x171/0x200 [] printk+0x18/0x20 [] __alloc_pages+0x24c/0x390 [] kmem_getpages+0x2f/0x90 [] cache_grow+0x90/0x110 [] cache_alloc_refill+0x17d/0x250 [] __kmalloc+0x98/0xb0 [] alloc_skb+0x39/0xd0 [] tulip_rx+0x28e/0x3e0 [] tulip_interrupt+0x955/0x970 [] handle_IRQ_event+0x2a/0x60 [] __do_IRQ+0xa4/0xf0 [] do_IRQ+0x1c/0x30 [] common_interrupt+0x1a/0x20 [] kfree_skbmem+0xb/0x20 [] __kfree_skb+0x53/0xc0 [] packet_rcv_spkt+0x11b/0x200 [] netif_receive_skb+0x12b/0x190 [] process_backlog+0x7e/0x100 [] net_rx_action+0x65/0xe0 [] __do_softirq+0x7a/0x90 [] do_softirq+0x2c/0x30 [] do_IRQ+0x21/0x30 [] common_interrupt+0x1a/0x20 [] inet_sendpage+0x74/0xa0 [] xdr_sendpages+0x13e/0x220 [] xprt_transmit+0xcd/0x470 [] call_transmit+0x4b/0xb0 [] __rpc_execute+0x5c/0x300 [] worker_thread+0x150/0x1e0 [] kthread+0x95/0xa0 [] kernel_thread_helper+0x5/0x10 rpciod/0: page allocation failure. order:0, mode:0x20 [] dump_stack+0x17/0x20 [] __alloc_pages+0x251/0x390 [] kmem_getpages+0x2f/0x90 [] cache_grow+0x90/0x110 [] cache_alloc_refill+0x17d/0x250 [] __kmalloc+0x98/0xb0 [] alloc_skb+0x39/0xd0 [] find_skb+0x2a/0x80 [] netpoll_send_udp+0x2b/0x230 [] write_msg+0x3a/0x50 [] __call_console_drivers+0x52/0x60 [] call_console_drivers+0x7f/0x100 [] release_console_sem+0x36/0xa0 [] vprintk+0x171/0x200 [] printk+0x18/0x20 [] __alloc_pages+0x24c/0x390 [] kmem_getpages+0x2f/0x90 [] cache_grow+0x90/0x110 [] cache_alloc_refill+0x17d/0x250 [] __kmalloc+0x98/0xb0 [] alloc_skb+0x39/0xd0 [] tulip_rx+0x28e/0x3e0 [] tulip_interrupt+0x955/0x970 [] handle_IRQ_event+0x2a/0x60 [] __do_IRQ+0xa4/0xf0 [] do_IRQ+0x1c/0x30 [] common_interrupt+0x1a/0x20 [] kfree_skbmem+0xb/0x20 [] __kfree_skb+0x53/0xc0 [] packet_rcv_spkt+0x11b/0x200 [] netif_receive_skb+0x12b/0x190 [] process_backlog+0x7e/0x100 [] net_rx_action+0x65/0xe0 [] __do_softirq+0x7a/0x90 [] do_softirq+0x2c/0x30 [] do_IRQ+0x21/0x30 [] common_interrupt+0x1a/0x20 [] inet_sendpage+0x74/0xa0 [] xdr_sendpages+0x13e/0x220 [] xprt_transmit+0xcd/0x470 [] call_transmit+0x4b/0xb0 [] __rpc_execute+0x5c/0x300 [] worker_thread+0x150/0x1e0 [] kthread+0x95/0xa0 [] kernel_thread_helper+0x5/0x10 rpciod/0: page allocation failure. order:0, mode:0x20 [] dump_stack+0x17/0x20 [] __alloc_pages+0x251/0x390 [] kmem_getpages+0x2f/0x90 [] cache_grow+0x90/0x110 [] cache_alloc_refill+0x17d/0x250 [] __kmalloc+0x98/0xb0 [] alloc_skb+0x39/0xd0 [] find_skb+0x2a/0x80 [] netpoll_send_udp+0x2b/0x230 [] write_msg+0x3a/0x50 [] __call_console_drivers+0x52/0x60 [] call_console_drivers+0x7f/0x100 [] release_console_sem+0x36/0xa0 [] vprintk+0x171/0x200 [] printk+0x18/0x20 [] __alloc_pages+0x24c/0x390 [] kmem_getpages+0x2f/0x90 [] cache_grow+0x90/0x110 [] cache_alloc_refill+0x17d/0x250 [] __kmalloc+0x98/0xb0 [] alloc_skb+0x39/0xd0 [] tulip_rx+0x28e/0x3e0 [] tulip_interrupt+0x955/0x970 [] handle_IRQ_event+0x2a/0x60 [] __do_IRQ+0xa4/0xf0 [] do_IRQ+0x1c/0x30 [] common_interrupt+0x1a/0x20 [] kfree_skbmem+0xb/0x20 [] __kfree_skb+0x53/0xc0 [] packet_rcv_spkt+0x11b/0x200 [] netif_receive_skb+0x12b/0x190 [] process_backlog+0x7e/0x100 [] net_rx_action+0x65/0xe0 [] __do_softirq+0x7a/0x90 [] do_softirq+0x2c/0x30 [] do_IRQ+0x21/0x30 [] common_interrupt+0x1a/0x20 [] inet_sendpage+0x74/0xa0 [] xdr_sendpages+0x13e/0x220 [] xprt_transmit+0xcd/0x470 [] call_transmit+0x4b/0xb0 [] __rpc_execute+0x5c/0x300 [] worker_thread+0x150/0x1e0 [] kthread+0x95/0xa0 [] kernel_thread_helper+0x5/0x10 rpciod/0: page allocation failure. order:0, mode:0x20 [] dump_stack+0x17/0x20 [] __alloc_pages+0x251/0x390 [] kmem_getpages+0x2f/0x90 [] cache_grow+0x90/0x110 [] cache_alloc_refill+0x17d/0x250 [] __kmalloc+0x98/0xb0 [] alloc_skb+0x39/0xd0 [] find_skb+0x2a/0x80 [] netpoll_send_udp+0x2b/0x230 [] write_msg+0x3a/0x50 [] __call_console_drivers+0x52/0x60 [] call_console_drivers+0x7f/0x100 [] release_console_sem+0x36/0xa0 [] vprintk+0x171/0x200 [] printk+0x18/0x20 [] __alloc_pages+0x24c/0x390 [] kmem_getpages+0x2f/0x90 [] cache_grow+0x90/0x110 [] cache_alloc_refill+0x17d/0x250 [] __kmalloc+0x98/0xb0 [] alloc_skb+0x39/0xd0 [] tulip_rx+0x28e/0x3e0 [] tulip_interrupt+0x955/0x970 [] handle_IRQ_event+0x2a/0x60 [] __do_IRQ+0xa4/0xf0 [] do_IRQ+0x1c/0x30 [] common_interrupt+0x1a/0x20 [] kfree_skbmem+0xb/0x20 [] __kfree_skb+0x53/0xc0 [] packet_rcv_spkt+0x11b/0x200 [] netif_receive_skb+0x12b/0x190 [] process_backlog+0x7e/0x100 [] net_rx_action+0x65/0xe0 [] __do_softirq+0x7a/0x90 [] do_softirq+0x2c/0x30 [] do_IRQ+0x21/0x30 [] common_interrupt+0x1a/0x20 [] inet_sendpage+0x74/0xa0 [] xdr_sendpages+0x13e/0x220 [] xprt_transmit+0xcd/0x470 [] call_transmit+0x4b/0xb0 [] __rpc_execute+0x5c/0x300 [] worker_thread+0x150/0x1e0 [] kthread+0x95/0xa0 [] kernel_thread_helper+0x5/0x10 rpciod/0: page allocation failure. order:0, mode:0x20 [] dump_stack+0x17/0x20 [] __alloc_pages+0x251/0x390 [] kmem_getpages+0x2f/0x90 [] cache_grow+0x90/0x110 [] cache_alloc_refill+0x17d/0x250 [] __kmalloc+0x98/0xb0 [] alloc_skb+0x39/0xd0 [] find_skb+0x2a/0x80 [] netpoll_send_udp+0x2b/0x230 [] write_msg+0x3a/0x50 [] __call_console_drivers+0x52/0x60 [] call_console_drivers+0x7f/0x100 [] release_console_sem+0x36/0xa0 [] vprintk+0x171/0x200 [] printk+0x18/0x20 [] __alloc_pages+0x24c/0x390 [] kmem_getpages+0x2f/0x90 [] cache_grow+0x90/0x110 [] cache_alloc_refill+0x17d/0x250 [] __kmalloc+0x98/0xb0 [] alloc_skb+0x39/0xd0 [] tulip_rx+0x28e/0x3e0 [] tulip_interrupt+0x955/0x970 [] handle_IRQ_event+0x2a/0x60 [] __do_IRQ+0xa4/0xf0 [] do_IRQ+0x1c/0x30 [] common_interrupt+0x1a/0x20 [] kfree_skbmem+0xb/0x20 [] __kfree_skb+0x53/0xc0 [] packet_rcv_spkt+0x11b/0x200 [] netif_receive_skb+0x12b/0x190 [] process_backlog+0x7e/0x100 [] net_rx_action+0x65/0xe0 [] __do_softirq+0x7a/0x90 [] do_softirq+0x2c/0x30 [] do_IRQ+0x21/0x30 [] common_interrupt+0x1a/0x20 [] inet_sendpage+0x74/0xa0 [] xdr_sendpages+0x13e/0x220 [] xprt_transmit+0xcd/0x470 [] call_transmit+0x4b/0xb0 [] __rpc_execute+0x5c/0x300 [] worker_thread+0x150/0x1e0 [] kthread+0x95/0xa0 [] kernel_thread_helper+0x5/0x10 rpciod/0: page allocation failure. order:0, mode:0x20 [] dump_stack+0x17/0x20 [] __alloc_pages+0x251/0x390 [] kmem_getpages+0x2f/0x90 [] cache_grow+0x90/0x110 [] cache_alloc_refill+0x17d/0x250 [] __kmalloc+0x98/0xb0 [] alloc_skb+0x39/0xd0 [] find_skb+0x2a/0x80 [] netpoll_send_udp+0x2b/0x230 [] write_msg+0x3a/0x50 [] __call_console_drivers+0x52/0x60 [] call_console_drivers+0x7f/0x100 [] release_console_sem+0x36/0xa0 [] vprintk+0x171/0x200 [] printk+0x18/0x20 [] __alloc_pages+0x24c/0x390 [] kmem_getpages+0x2f/0x90 [] cache_grow+0x90/0x110 [] cache_alloc_refill+0x17d/0x250 [] __kmalloc+0x98/0xb0 [] alloc_skb+0x39/0xd0 [] tulip_rx+0x28e/0x3e0 [] tulip_interrupt+0x955/0x970 [] handle_IRQ_event+0x2a/0x60 [] __do_IRQ+0xa4/0xf0 [] do_IRQ+0x1c/0x30 [] common_interrupt+0x1a/0x20 [] kfree_skbmem+0xb/0x20 [] __kfree_skb+0x53/0xc0 [] packet_rcv_spkt+0x11b/0x200 [] netif_receive_skb+0x12b/0x190 [] process_backlog+0x7e/0x100 [] net_rx_action+0x65/0xe0 [] __do_softirq+0x7a/0x90 [] do_softirq+0x2c/0x30 [] do_IRQ+0x21/0x30 [] common_interrupt+0x1a/0x20 [] inet_sendpage+0x74/0xa0 [] xdr_sendpages+0x13e/0x220 [] xprt_transmit+0xcd/0x470 [] call_transmit+0x4b/0xb0 [] __rpc_execute+0x5c/0x300 [] worker_thread+0x150/0x1e0 [] kthread+0x95/0xa0 [] kernel_thread_helper+0x5/0x10 [] dump_stack+0x17/0x20 [] __alloc_pages+0x251/0x390 [] kmem_getpages+0x2f/0x90 [] cache_grow+0x90/0x110 [] cache_alloc_refill+0x17d/0x250 [] __kmalloc+0x98/0xb0 [] alloc_skb+0x39/0xd0 [] tulip_rx+0x28e/0x3e0 [] tulip_interrupt+0x955/0x970 [] handle_IRQ_event+0x2a/0x60 [] __do_IRQ+0xa4/0xf0 [] do_IRQ+0x1c/0x30 [] common_interrupt+0x1a/0x20 [] kfree_skbmem+0xb/0x20 [] __kfree_skb+0x53/0xc0 [] packet_rcv_spkt+0x11b/0x200 [] netif_receive_skb+0x12b/0x190 [] process_backlog+0x7e/0x100 [] net_rx_action+0x65/0xe0 [] __do_softirq+0x7a/0x90 [] do_softirq+0x2c/0x30 [] do_IRQ+0x21/0x30 [] common_interrupt+0x1a/0x20 [] inet_sendpage+0x74/0xa0 [] xdr_sendpages+0x13e/0x220 [] xprt_transmit+0xcd/0x470 [] call_transmit+0x4b/0xb0 [] __rpc_execute+0x5c/0x300 [] worker_thread+0x150/0x1e0 [] kthread+0x95/0xa0 [] kernel_thread_helper+0x5/0x10 Unable to handle kernel NULL pointer dereference at virtual address 00000064 printing eip: c023c9f7 *pde = 00000000 Oops: 0000 [#1] DEBUG_PAGEALLOC CPU: 0 EIP: 0060:[] Not tainted VLI EFLAGS: 00010246 (2.6.12-rc1) EIP is at tulip_rx+0x187/0x3e0 eax: 00000000 ebx: c70a0220 ecx: 00000000 edx: 00000640 esi: 00000040 edi: 00000000 ebp: c46c3ba8 esp: c46c3b64 ds: 007b es: 007b ss: 0068 Process rpciod/0 (pid: 595, threadinfo=c46c2000 task=c4673b10) Stack: c46c3e40 c07f5f60 c0c1f824 c46c3b90 c028ecb9 00000000 c46c3b80 00000000 0000003c 00000000 0000000f 00000070 00000031 c70a0000 c70a0220 00009fde 0000001e c46c3c00 c023d5a5 00000040 00000000 00000000 00000084 c4687e8c Call Trace: [] show_stack+0x7a/0x90 [] show_registers+0x148/0x1b0 [] die+0xda/0x150 [] do_page_fault+0x2f0/0x625 [] error_code+0x2b/0x30 [] tulip_interrupt+0x955/0x970 [] handle_IRQ_event+0x2a/0x60 [] __do_IRQ+0xa4/0xf0 [] do_IRQ+0x1c/0x30 [] common_interrupt+0x1a/0x20 [] kfree_skbmem+0xb/0x20 [] __kfree_skb+0x53/0xc0 [] packet_rcv_spkt+0x11b/0x200 [] netif_receive_skb+0x12b/0x190 [] process_backlog+0x7e/0x100 [] net_rx_action+0x65/0xe0 [] __do_softirq+0x7a/0x90 [] do_softirq+0x2c/0x30 [] do_IRQ+0x21/0x30 [] common_interrupt+0x1a/0x20 [] inet_sendpage+0x74/0xa0 [] xdr_sendpages+0x13e/0x220 [] xprt_transmit+0xcd/0x470 [] call_transmit+0x4b/0xb0 [] __rpc_execute+0x5c/0x300 [] worker_thread+0x150/0x1e0 [] kthread+0x95/0xa0 [] kernel_thread_helper+0x5/0x10 Code: 07 83 e8 04 66 3d ee 05 0f 8f f3 01 00 00 98 3b 05 90 d5 3f c0 89 45 dc 0f 8c 07 01 00 00 8b 4d ec 8b 8c cb 18 01 00 00 89 4d e0 <8b> 51 64 8b b1 90 00 00 00 85 d2 0f 85 dc 00 00 00 8b 55 dc 8b <0>Kernel panic - not syncing: Fatal exception in interrupt From mdomsch@lists.us.dell.com Fri Mar 18 13:23:06 2005 Received: with ECARTIS (v1.0.0; list netdev); Fri, 18 Mar 2005 13:23:12 -0800 (PST) Received: from ausc60pc101.us.dell.com (ausc60pc101.us.dell.com [143.166.85.206]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j2ILN5DV012918 for ; Fri, 18 Mar 2005 13:23:06 -0800 Received: from lists.us.dell.com (143.166.224.162) by ausc60pc101.us.dell.com with ESMTP; 18 Mar 2005 15:22:56 -0600 X-IronPort-AV: i="3.91,102,1110175200"; d="scan'208"; a="237578097:sNHT266654848" Date: Fri, 18 Mar 2005 15:22:56 -0600 From: Matt Domsch To: netdev@oss.sgi.com Subject: [PATCH 2.4.30-pre3] net/{icmp,ipv6}.h: include net/snmp.h Message-ID: <20050318212256.GB26112@lists.us.dell.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.4.1i X-Virus-Scanned: ClamAV 0.83/772/Fri Mar 18 00:59:17 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 329 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: Matt_Domsch@dell.com Precedence: bulk X-list: netdev Content-Length: 1123 Lines: 37 Compiling linux-2.4.30-pre3 with FC4-test1 compiler gcc-4.0.0-0.32 on x86_64 fails because icmp_statistics[NR_CPUS*2] is declared as a sized array without struct icmp_mib having been defined, likewise ipv6_statistics[NR_CPUS*2] without struct ipv6_mib first defined. Solution is to include before declaring either array. Signed-off-by: Matt Domsch -- Matt Domsch Software Architect Dell Linux Solutions linux.dell.com & www.dell.com/linux Linux on Dell mailing lists @ http://lists.us.dell.com ===== include/net/icmp.h 1.2 vs edited ===== --- 1.2/include/net/icmp.h 2002-02-05 01:39:17 -06:00 +++ edited/include/net/icmp.h 2005-03-18 15:11:59 -06:00 @@ -23,6 +23,7 @@ #include #include +#include struct icmp_err { int errno; ===== include/net/ipv6.h 1.9 vs edited ===== --- 1.9/include/net/ipv6.h 2004-07-15 15:33:03 -05:00 +++ edited/include/net/ipv6.h 2005-03-18 15:13:13 -06:00 @@ -19,6 +19,7 @@ #include #include #include +#include #define SIN6_LEN_RFC2133 24 From romieu@fr.zoreil.com Fri Mar 18 13:56:21 2005 Received: with ECARTIS (v1.0.0; list netdev); Fri, 18 Mar 2005 13:56:27 -0800 (PST) Received: from fr.zoreil.com (electric-eye.fr.zoreil.com [213.41.134.224]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j2ILuJNW014438 for ; Fri, 18 Mar 2005 13:56:20 -0800 Received: from electric-eye.fr.zoreil.com (localhost.localdomain [127.0.0.1]) by fr.zoreil.com (8.13.1/8.12.1) with ESMTP id j2ILqdUR025289; Fri, 18 Mar 2005 22:52:39 +0100 Received: (from romieu@localhost) by electric-eye.fr.zoreil.com (8.13.1/8.13.1/Submit) id j2ILqTEx025288; Fri, 18 Mar 2005 22:52:29 +0100 Date: Fri, 18 Mar 2005 22:52:29 +0100 From: Francois Romieu To: Alexander Nyberg Cc: jgarzik@pobox.com, netdev@oss.sgi.com Subject: Re: Reproducible panics with tulip Message-ID: <20050318215229.GA24509@electric-eye.fr.zoreil.com> References: <1111178167.1147.9.camel@localhost.localdomain> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1111178167.1147.9.camel@localhost.localdomain> User-Agent: Mutt/1.4.1i X-Organisation: Land of Sunshine Inc. X-Virus-Scanned: ClamAV 0.83/772/Fri Mar 18 00:59:17 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 330 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: romieu@fr.zoreil.com Precedence: bulk X-list: netdev Content-Length: 403 Lines: 14 Alexander Nyberg : [rpciod and friends complain from page allocation failure] You could try to increase /proc/sys/vm/min_free_kbytes but it may just fix the symptoms. You probably want to disable netpoll as the computer is getting low on network buffers: it should clean the output a lot... [...] > Warning: kfree_skb on hard IRQ c46c3950 ... however this one may stick. -- Ueimor From shemminger@osdl.org Fri Mar 18 13:57:08 2005 Received: with ECARTIS (v1.0.0; list netdev); Fri, 18 Mar 2005 13:57:15 -0800 (PST) Received: from smtp.osdl.org (fire.osdl.org [65.172.181.4]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j2ILv853014558 for ; Fri, 18 Mar 2005 13:57:08 -0800 Received: from shell0.pdx.osdl.net (fw.osdl.org [65.172.181.6]) by smtp.osdl.org (8.12.8/8.12.8) with ESMTP id j2ILuuqi004321 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO); Fri, 18 Mar 2005 13:56:56 -0800 Received: from dxpl.pdx.osdl.net (dxpl.pdx.osdl.net [172.20.1.103]) by shell0.pdx.osdl.net (8.13.1/8.11.6) with ESMTP id j2ILut8O022116; Fri, 18 Mar 2005 13:56:55 -0800 Date: Fri, 18 Mar 2005 13:57:13 -0800 From: Stephen Hemminger To: "David S. Miller" Cc: Injong Rhee , netdev@oss.sgi.com Subject: [PATCH] TCP BIC not binary searching correctly Message-ID: <20050318135713.1171df83@dxpl.pdx.osdl.net> Organization: Open Source Development Lab X-Mailer: Sylpheed-Claws 1.0.1 (GTK+ 1.2.10; x86_64-unknown-linux-gnu) X-Face: &@E+xe?c%:&e4D{>f1O<&U>2qwRREG5!}7R4;D<"NO^UI2mJ[eEOA2*3>(`Th.yP,VDPo9$ /`~cw![cmj~~jWe?AHY7D1S+\}5brN0k*NE?pPh_'_d>6;XGG[\KDRViCfumZT3@[ Mime-Version: 1.0 Content-Type: multipart/mixed; boundary=Multipart_Fri__18_Mar_2005_13_57_13_-0800_TtaZbFDznTSNNNQQ Received-SPF: pass (domain of shemminger@osdl.org designates 65.172.181.6 as permitted sender) X-MIMEDefang-Filter: osdl$Revision: 1.105 $ X-Scanned-By: MIMEDefang 2.36 X-Virus-Scanned: ClamAV 0.83/772/Fri Mar 18 00:59:17 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 331 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: shemminger@osdl.org Precedence: bulk X-list: netdev Content-Length: 42846 Lines: 582 --Multipart_Fri__18_Mar_2005_13_57_13_-0800_TtaZbFDznTSNNNQQ Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Disposition: inline While redoing BIC for the split up version, I discovered that the existing 2.6.11 code doesn't really do binary search. It ends up being just a slightly modified version of Reno. See attached graphs to see the effect over simulated 1mbit environment. The problem is that BIC is supposed to reset the cwnd to the last loss value rather than ssthresh when loss is detected. The correct code (from the BIC TCP code for Web100) is in this patch. 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 2005-03-18 13:53:52 -08:00 +++ b/net/ipv4/tcp_input.c 2005-03-18 13:53:53 -08:00 @@ -1654,7 +1654,10 @@ static void tcp_undo_cwr(struct tcp_sock *tp, int undo) { if (tp->prior_ssthresh) { - tp->snd_cwnd = max(tp->snd_cwnd, tp->snd_ssthresh<<1); + if (tcp_is_bic(tp)) + tp->snd_cwnd = max(tp->snd_cwnd, tp->bictcp.last_max_cwnd); + else + tp->snd_cwnd = max(tp->snd_cwnd, tp->snd_ssthresh<<1); if (undo && tp->prior_ssthresh > tp->snd_ssthresh) { tp->snd_ssthresh = tp->prior_ssthresh; --Multipart_Fri__18_Mar_2005_13_57_13_-0800_TtaZbFDznTSNNNQQ Content-Type: image/png; name=bic-bug.png Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename=bic-bug.png iVBORw0KGgoAAAANSUhEUgAAAWgAAAD8CAIAAADVB6ljAAAACXBIWXMAAABIAAAASABGyWs+AAA6 sElEQVR42u2dfZgcVZ3vvz2TzCQwk1AjE1gJEquJmvCi2RpMhrghD/ZIMEEDS7XLCuIKtxuINwZd qd6FTYjgY5XLXkxcFrt22cDqFezGFSUyw3b5GDYzTq52CYlGg9BlQBAM0LUkIZm8nvvHmalUV1f3 9Et1V3fP+Tx58tScOnXqVHXVr875nd9LgBACBoPBKIc2vzvAYDCaDyY4GAxG2TDBwWAwyoYJDgaD UTZMcDAYjLJhgoPBYJQNExwMRgtimmZN26+J4FAUhW4YhhEMBnt6epLJZE0vg8FoajRN6+npyS+3 XqVC5L9iuq7HYrFaCw4Qr0mn01azkUgklUplMhlBEDw/EYPRSuS/jPZXyYEkSXTD8Yql02lRFOvQ 2wDx1HLUNE3TNIPBIG02EAg4Niw+8pGP7N27F0BnZ+ecOXOqOemRI0c6Ozs96f+JEycAtLe3N1RT 3l5jYzbVwnc+k8mMjY0BOO+88371q18VquZ4R+yvkqZp4XDYNM1EIiGKItzeLLrR19fHcZymaZIk ybLsyR1wx1s5lEgk7LIzf8PinHPO8eqklvStnlQqlUqlGq0pb6+xMZuaCne++DPveEfsrxIVFgAk SQqFQtbLS7fth9P/s9ksx3FeddsVj3Uc4XA4EAhQ+adpmiiKiqIYhsFxXA2FH4PRcthfpUwmk8lk qAShMhEAISSVSjlesVAopKoqx3FNphy1C79QKCRJkqqqwWAwEonU9DIYjKYmGo0CiMVimNBu2l+l WCzW19cXDAbzD3S8YrIsK4oSCAQkSapphz3WcZROf3//6OioL6dmtAymaTbRYLaVnnlmx8FoVgzD cF3CLIKu6373ukVggoPRNBiGYf+T5/lSqlnout7X11fhuWttFtFsMMHBaFxisVgwGBwYGACQTCbp dl9fn67r1Oop/xB7NQDhcJgaR4XD4XA4DEDTtEq6woYquTAdB6NxGRgY4DhOkiRBEDBhqhAIBHie T6fTHMfl2wfZq9FddNEhHo/DzZ4IAIqLkoMH8cILePFFnH8+Fi0qVpPjIAhF9rfSMz/N7w6UwSOP AMCNN+KRR3DjjX73hlF7ZFk2TTMajVIbSgvDMOhifymNcBxnGEYxNarNMqIgmlZStSlDM01Vbr4Z X/4ypk/3ux+MehEOh+k6JSb0mlR/cf/990ej0XA4TIWC/RB7NdM0qQeHKIrBYFDTNI7jKtSPMqmR SzONOM45B3/4A7q6/O4Ho15kMhlrm/piYMI+ct26ddYuaihFoYaeVjVrVELNHLLZrN/X1CI0k+B4 9VW0t+PQIb/7wWgw/NLTTWWaaapyyy244QY8/7zf/WA0BjX3HGcUpplGHHPnQhRhGEwzyhiPQ8HG Gn7RTCMOjgPPswX1qUi+TVch66/iR1VyahiODQaaSHAkk+OK7RIeGEYrYFl/OWy6ilh/9fT0BAKB gYGBQCDgOCoajfb19dnVqCXCgVOg6NBVqH7fkgaiaaYqhgGqIPfiK8JoAnRdFwTBsv5KpVL0tQ+H w5b1l+OQbDYbCARoTbqeYh1FV1VcTc41TGJLOg3TbsJN9+G+4jU5cAIETA2aQ3AwLdgUxBPrLwtV VQtFxAqhmI2GDv0NvPFT/FSFKqG2vupNRHMIjmQS1nPCpipTBOpaYplsWTZd8Xg8Go0mk0lq/eVQ dvA8H4vFOI7btm2b/Sg6wQmFQn19fQ5JVBwevAwZAJMadprDV0VVYUUC0nWYJjPkYwB5pl+1jbJZ NcxXpa445imCAJVpqRgAmOmXfzTBqop9nsKYmnhl68VsxryiCQQHAIdbI1tYmVJUEOmrpu0wUDfB UbGkdz1OmCprXlOUEiN91acd2oZplvm5Codreot8x2PBQXXXgUCAxmsGEI1G7X+Wzq5dAJBM4oIL nLvYeLO5GBpybjioINKXtUtVVUVRYrGYFRlQURTqUF9KO5PCcVAUPPZYOZq1JUvw1FNYsqTgBTc/ HitHeZ7PZDKmadKHgIr8TCZTgbCncRhefx3HjuGVVxxnga6zcUfDMTKCq6/Ghz+Mn/8cP/gBli4d Lx8dxerV4Hn87nfYuhUrVjgPtGy9MOEITw23ith6WbvoYDYcDkuSRLOfcRzHcVyJ7aCEAGB79+JH P8K6dZPUHA8AZppYvhzvvIMdO/z+QWqIx4KDLq0rimItjPE8PzAwIEmSI7XK/v376TCE53nXrCtf +AJuvhmHDuGee5y7BAGaxgRHI8LzGBzEggVIp3H48HjhzJmYPh179uADH3CRGqjI1ss0TbrLNE2e 53mepyZesVgsP6VIcZux4kv7uo7Zs/HAA3j++RKMAHQdmgZJgi1rpKqq9Au6f//+uv0QNU8cUYv0 cIlEgud5608ajsVRZ8mSJcUbufdeMmsWOess4lpRlmvRcUZVJBKkq4tcdBHp7c0pHxwk7e1k5kzS 2el+IH3zrbTJmAjhc//999OxA8dxNJWZRTwepyOLdDpNj6IhfCKRCK1QYjuTks2WXDUeJ/F4kf1F nvlUKuVI2phOp+k4vXgOSjqc5ziOpoy0bkW5l1kuNREchBDHXbDLEcqkguOznyWpFNm5kzz6qMte JjgaimyWSBJ56CEyPHzqn8XgIBkcJJ/7HFm/ngwOVn4W+wfPw5Sunl3/ZO9q8WcebrljCyWs9z1b vceCIz4BzXApSRL9k34WSr+JZDLRMCFeGf6TShFZnvzLnEiU8/VuFlauJKkUyZViPOEJIYNkcD1Z by8vS3BQMpkMFQ103mENK1Agr7sgCDQTda0Fq/cjjmzu05Et8LAUv4nx+CTiu6G+N3VAEMjwMLnm GucsoKuLLFtGBgeJY0jX20uuuYYMD5OVK53lokhE0Vm/s9O9vLub3HYbue02smnTqcLhYcLzRBTJ mWeSUIiUmBk+nZ6kZrZMuZL/NfKqcqmsXEm6u8nixTl3h5Be0nsGOaOLdNE/4/G4JEmSJC1cuLBI Y66CIx6PZ7PZBsxW773JuUMlU4GGhq62Fl+HCYVgGFPI4e0zn8Hll+P4cVx6aY5u/73vxfbtGBnB pz+dU/7+9+OJJ/Dkk4hGc8rPPhvf/z4AXH99TvmMGXj8cQQCzvLTT8e3voXTTsO99+aUv/UWvv99 BAKIRkv1GyruK1BWRC9d13Vdj0ajJdZXVbX0yqVimrjwQhw7hqefduz5Ir54J+58F95F/7R0/888 80yZZzCpXuaNN96gugxd1+myg5UgJhwOK4pCq2EiW30kEqm5jWxNxVIRiow4Shn3ZjKlfuhag298 g0ybRjo6cnQHZELv2N7u1B0MD5OODtLZ6awviqStjXR1OdsXRRIIuCgvb7uNdHaS7m5neW8vaW8n eZqrSbAmmK6quxKfRmva76hffExR+aOeISQ18c+CTs/ojc5FJvIsMosQ0kt6RZKjbijyzFPhQucX VLtJM0gB4Dhuy5YtHMfRNFSOy3HoUEtUqVZPwwmOTKZU/cUUma1ks0SWyfveR4aHyaZNzqnH4sXj GkfHO7xyJdm0iQwPE0HIKe/tHa/v0KDRcjpbyW+HzlYs6Olo/dKVnZIknXEGHwqFEokE/TZa+jy6 LpD/bkuSxPN8KBSyNggh9MVIpVIABEGgjdAl2FAoZFcH2I+yVy6PVN6GLLt+tbIkKxEpQwrOsSfV 6zURDedWryiQSot7MBWc3zQNuo5IBDVdkq8PAwMDpsnF45IgCPYsjcFgsFA+RysFJA2xkZ8LkthS PdKNcDhMkzBJkqTrunWUo3LuXS7a72eBRcDrwGvA/AP43vfwqU+hq9tR65f45S5u12eFzxZpqZXc 6htlxEE/aN/4BrnqqlJbKLpkXi10BXFw0LmCaK010u+5Ba1G69vZtIns3EmGh3O+2LQ+PYvjC0// HBwkd9xR6MPWrKTT6dtvTznyKtH/6WJB/tOYTqdTqZQgCNYGLXccbi8MhUJ0HpROp+1HwW12UxL0 J1i8mHxdd4xyu0k3IeQ2ctvZ5OwUmfynaqURRwPF45g1C4cOYSLj3+TUVPuzYgW6u9HejrExjI2d Kl+6FHPmYNo0HDwIux1gfz9WrUJXF971LmzceKpcELBkCQD82Z/ltN/fj+5uHD2K2bOdp54xA4Tg Ax/Atm2tMNCwCIfDhw+ju7uMiF5WEDBrg5ZzHPfggw9a+R8Nw6AbmqZFIpG+vj5qEGUdRZM/WpXL c4DggeX34NkevLoZnzvPvucG3NCBjja0vYbXOLTQT1UCDSQ43nmnvPo8D9Os1as1NIS2Nuzfj3PP zVlN2L0b7e14/XUsXJhT/txzmDkT+/dj9uyc8h/+ECdP4uhRnHFGTvmjj2JsDCdPYsGCnPKZM3H8 OE6exPvf31JSAxNGnKoKQcgZL0QiEWvdwRHRy54C0g7N5HjrrbdajVALQ7rXWry0H04PIZVMzA0s eQfvvIFfPOXY8Rv8hoB0oGOqSQ2gYaYq3d3kqqvIu9/tosAvxKR2ARWTzZKPfIRMn04WLyZdXTlT lU2bSHc3WbnSaU9BLSAWLCDt7TnlgkB4nlx6KZk5M6ec50lvL1mwwNmOZR9RyDq72anpBNN7Eonx 1ZNcJXCWZGUin0ZOI4TcRm4TSEk611aaqjSK4CCkEilQi6cwHmf27DWkae4tXc1yW+JNk7REpCwp 2wy2lQRHA01VKsDbwbxhjEdFnjp2ZfWn0e/tyAiWLoWuI5mEJOU/YQoUK+75VKaBBEcFAQF1vdoV 2XAYuo7OThgGNm9GY0fJbgUaPezj176GT3wCgP1RmIEZT+CJG3DDcRzXofNocOFXDxoo5mgFj1T1 n68FC/DWW3j+eSxYALeoIAyPEYQGzv57883Ytg3f/nbOQhrwBJ74OD7+Dt4xYTKpQWkgweEL/f04 cQKnnYY6xliZ0ghCow46NA3z52P5cmzfjrVr7XuuxbWn4/SjODqElg0FWC4NJDgqGD5Un7x+dBQv v4w778T11/t9/VMDjmtIwaEoME1IErZutRfr0GOILcCCAziwFVvvxt1+d7RRaCAdRwWCIxRCMllV DMGNG6Fp6OtjqeGmKlQl7qYHTSJpwrT0oCuwYgVWlN1+i9JAgqMyCn6+gkDvxPYOYN7E9p+Aw7Zq S9C3H6efDvw1sM9WHgZenth+D5CY2F4DvAQA+C2QyWlnokO57aya2ChU/43ccqvbjvI+4GwAwOtA upz6AOwf0Tk4NUnfUUJ5EFgAADgPeMB2E7YDpxW+OY761s00gH2NsbCyYQM2bkQyCcOw9KAjGFmK pQCGMLQN20SIUyf7fLk00FTFY51ZL3BL7juwF9gInOWsmFiH6ffAqfN6GdgB3A3ssEkQAC8BW4G/ m3id7ND6+W9F8fq9uYW9BcrPnmjn7Lz6tJP59f8uV2RQ+In6JZYvmGjnJVvhS8D/KXpzHPVfzrk5 DTFVeeopxGLgebtL5RfwhTVYsxALv4KvSJCY1ChCA404KvM9cfl8mUAS2Ac8B2jAfkADxgAN+M3E hsV+tP0U+OBENVs5NOA5YFrurjcBDdg9sZFf39FOufUraCe/k7R+Gjhccv2y2nkTeBY4UfjmOOrT OluAE8CEftTPccfAAH79awDo7LRPdNNId6LzbJz9G/zGv841Bw3kVh+LVWJGkeOGbwWYEoG+Uqcq b2ZxZk/eFINNVaz2PZyq/Bo4CMOAYfinVKJhyDQNiYS92IS5EAtDCP0Wv12MxQ+c6r1nMLf6gjgC EOXHbrfIN7+tLP5wKkVe/2dCZELihFQUEb7JvCeamgwhMiF+BWEqHIs8QRIykYfJeKAEa8NbmMl5 QRyZ3BRFicfjPM+Hw+FT6XAeBDai3+zH2cDngU7gASCLT54E7gP6Jr5UjwE/BQC8B7gTgG3UsBG4 EdCBJBYR7LkIZ62pvM8NMeWeIvAAD+h+zFM0DZqWP6Y1YapQBQgSTik7qIqUUQzPRZEV0J24BXEn hJCzCLGkL/WFXUzISvK7yPjGOJG8jfMIIYSkCeEIkQmZ8D+q8vPVSsFymgOZbLm/jqcTRUdMJJq+ gBByIbmwMne1ymAjjmLQKI/RaLRQMAXKWcZZ/3bdv33myGdSX0ytfGsl3kb2VeBtABNKtVcBDfj9 xAaAMeAm4DpgFmyfh2pzQeo6M+KoLxHM+ziwrvYn2rABP/oRfvtbHDtmXz0RIMzAjBM4cQkuqYO7 mi8pIGtOjQQSTesgiqIsy5lMJifLw1mEnEVu77idnEVINyFfJ6STkOnkSAchHCFW0N1VhEQIiRBi ielphJw38c9GlUqKKRL0uKHY8S/kwJbanyaRIPE4WbzYUZwl2TbS1k7aK2q0ctiIoyDqROYMGsla kqRwOOzMA/w6AIz2j8JSMH8ZANY7VlWezGv9mPtJq4whyIYb9af3Cvzhn7FAR61MJUwTigJRhCDg 1VftezRoV+LKv8RfAuhG9wEc8PtmNCUeCw6aCcaKDSkIQvEJi52KX+BqYgg2rqdmS8PzUM7CgmRt BIcjmoYtBiyNpnGs0CeIUTLeW45WkLqtSqpxdatd1FJGcXgekADF63ZVddyKPPd3NWDEEIsgIsKz nBozZmDpUgSD6OvLKZ82DQsXIhjEhg01u302ap60zY1GMTmv5tqr9NSuUrfKqAzDADhAAJIetXjF FYjFIAhWcKc5mDOEoSEMzcTMJJIyZG+jCgsCRkfx6qvo7x9f7aX/zjkHe/bgrbfQ319qU5qm9fT0 lHDTjGAw2NPTQ3PH6Loei8V8ERzuytF0Ok3z2fI8n6hNYniHoiiVqmpZtOI+Ms2oX5wKPiqTatdD N20iixePJ8i2MUgG20l7G2n7Jvmm5/3PZAjHkc5OlzybPE9mz3bJy1lBtnqKlc+RGjpkMhmaa0Z0 ZOWpIy4jDl3Xk8mkLMuEEKqhUBTPB5QeU/FUpSE8NackVDMFeDFhOXwYX/oSli3DAzl24i/iRQIS QOB8nO9t55NJJJO47jr85Cf4yU+cj9/11+Oxx7B1K6h9ua7rmqZpmnbkyJFSGqejj0AgQIcVsL2A qqqGQiGafToajZqmGQgEYrGYt1dXEvmyxJG818qL5a3Eyh9xVHOGildkmfWXX+Rkt5gwRS+bTIZI 0niO8tzvfpzEZ5FZNCFfF+mqqHUXqNl6Wc8qTSiXSqUWLVpUpJr1Mlo21pIkhWxLBnTbqky3s9ls jq1DvSg4OhJsU/9anDhfcFRDxYKDTVV8JOdXS5wyBS4EzXG9fv1EMpqJpCeCkJORmyZ/TpM0z4/X d1hyVJypu7+/qvQOJU5V7FksHbvshlGhUCgej5PK8lpWTTHBQTcymYpcxybDW8FR8YCFebj5iFMz VYKyo6uLtLWdFFeP2ZOeDA+Tzk7S0UGGh0mapGUiUyvywUHS3u6iayhUPjxMOjpcdBaiSNraSEdH VYNiUlRw0Fx2VJeRSCQ4juN5Pl9w2J1IHQ6ldcZpx6Hret/E4hLNx8dxHE2fV1Oq9DSrOIYgW4v1 EeePHgEUFDEB37ABhw4BIHtGs9qNt8Hspr4I4g//4/jJvz55on0g9ou/3XB4GSSqc3j0UQA4eRJ3 3IFptif9jjtw8iTa2vDooznlGzfi+HG0t+Oxx3DYFnthzx4AOH4cP/pRrdbg4vF4PB6n26IoirlZ P8jE3MRhGFW6kZT35MuSeO5XOFUbNYBD+lYvNCsbQ7Kpio+4DPfShBQeA/I9by3r+sWyadt7Z7xt L1+5kpw2HJp2zRPv6j2WU58ng4Nk2TLSlavi6Ooiy5a5TFV6e8k115Dh4fEpj71cFMezfFZDi5uc R3Lzi4Ra2iSbGXE0FgKgAwVM0TP/9fvkd4+JI3+LHTkxDpdsvfcZ7Ji59P99CjfYwgeBfo9X5AUY PnAgp4LFvokITLmhzk+VMywKGoANDAzQaUufwyzOa4aGsGEDxsYwNIShKtJWVLCwysxG/YXnoWl5 pRFgAOgBeoD5tnJdh9J56ff7gR2n4qcBCpQ5m+ccWHVg/6r9y9csz2kqDCwBlgBhlFS+BlgFrAI2 55YvmfjnsARdNVn9Fk7DUmgowvO8KIqpVIqvcnxWAPuwrbOTdHW5KKvKooKpSpVWZ4zqcVdOc4RI ExuUdJokEmTxRP3FhNiTP1szi9wpBlmct1G8vNx2yqzf4lMViiiKuq7Xx/GE57FnD2bNqqqRykLg sqlKg3IU0IDjgAa88Du8dhDLROzHOXsAGQf2H/il9suDODgeTaN4ROi0W2RmGehzi8y8CbjArZ1y 6/8z8Hm/72EtKSg4LDuORG5MV88ZGsLvfodzz8Wf/oTRUZcZaYnwfNmCw8+QuQwAhXyU9gMPAw8D hwBOx5kGbhUB/OnIn87+zxPPn33gnD+c0xXqugyXjdePAd8AALwB2H/QN4G7JjYc5U8AT+SVR4EU kAKO55b/YaL+kdzyvy5c/zvAd/y+uTWl0FDE2luHqcrg4PhEo5qpCil/iYQtqfjOJE5GdIZi44zE /wqQQN2C/XlLK01VCipH6STFMIw6+N6tWDH+5al4uEEpd57Chhu+U/Dh6umBrsMwYLNoCGqRg9zL 1+LaPtRWYc+YlIKCI5FIiKIYjUYtu5TWg0Xx8R33WCrz52P/flx2GbZsoQUmzBhiH8QH9wlDCSSu B0sR7jMFBYeiKIlEIpVK1T8wT8WUOzbyJY4Bw45LLBVVxZe/jNNPx8GDeOopAEkkVagy5Pdpa8Zj emFjBedieIi7cpQ6AlOTc9gsXhuccmMIsqmK73CcTXDQ4F2RCHgeTzwB4J/wT8dx3Ep6wpbAGgf3 EYcgCJbnzLe//e3qT1OfIEXlxhBkU5WG4PAhKApUFaEQZBk8PxMz5z/1wjRMuwN3RBAJTaxYsNRZ dUPX9YGBgUAgEAwGrbAgdgpOVeiIIxAI3HDDDWWdLxgM2oOLRKPRusUaEQQmC5oK04Si8C/+FyKR 8YEGAOAwDhswCMgJnLAH+2ueSXNzU0oor2JRzukMxShHzhuGkclkqK26LMv0WJpBtviBXo1Cy1pY YUNf3zAMqCoEAZJkKLBHAjVhnokzAwhMx/T5mP8CXvC7r1MR2ZaphLrq6rpuj9HjHHHouk4HGtZG Wb4q9Bwcx1mecjzPDwwMWPlWCuHVx6R0KefiJcGoKTTmt2EgFhtP4yqKyNWPatBUqJfj8uM4fhiH 59ucVXRfMs5OSaiASCaTsVhM13Vd12GzCKUE8hWfqqraHWQ1TSvXQVZVVVEUreUYGprZcaILLrjg qquuAsDzfCQS0TRvVJWqilzn3oJoGjiODTrqyMKFuPFGCILjlzbN8SycNOlJofQFmgZBaMrZipUC 8sknn9y9e7ff3SkVujZCCAkGgy6BPwpZhllhOMqNNprNZrPZLN2wCvPNT72NAGZRekQv5t5WPwYH yTnnkNNOy8/GSLlFMidN/twCZr7NZTlKP/zO/K0TuOg47EHAUGYEMFVVo9EoPSqTycRiMardqLXD iwX11C5l8OLVGIcxCYaBbdvwq18hGoXbY5BEch/f/eBkyZ/Z2LDOJBIJ+jq7moC6CA6asiEcDlcQ mCwSidinObIs2zNC1gEaQ7AU2IS5HlDdFtW05UkNE6YKNYTQFSVkgmRrsXXGMIx4PG6apqstRUE7 Dpq7ofpAPiVKDQ/tPEpsqhlny82EaY7nVSugc9KhK1AiiAgQShEK7PeqM7FYjMZMHhgYyN9b0I7D MAxFUeiQoQ699ND+osT+MouPWrFmDXQdqgpJKjTBUKHq0K2cjKHQ5L8a8w+oMxzHmaaZLDCAb4hA Pl5fcEnV2FTFe0ZG8LWvYft27NiBzZtdfwkTJh1o8Dj1A1CT3yIqJ8NgOo56k0gk+vr6TNO023RY FBQcVm0/Q7BXBJuq+MbChbjwQrz9NrZvtxcPYWgN1mSQ6UDH1bj6e/ie4zieRzI5ieBggr7OWKkY ytBxoI7BimtwwSUp0thUxWN0HYoCSYLoNMRYgRUChDa09aM/X2pQissFZv1Vf/r6+qgJaE9PT/7e RtFxeEiJgoMNfb0kmYRhQJbBcVi71rHTgPED/OAcnPMKXinUQPGfrLWlhqqq1KOMunRRg8menp5k MmnfLn2XJ72yzDfc5xyFzD9owluaZq4W5iWeJ2Qqq7VMhhmAeUQ2a8/GmE+CJK4iV4lEJITQ/10p HqS+Bay/SGEDMI7j0um0lT46EomkUqlMJiMIgn279F3Vd9UhLPIr+JCu1vUmepvDddLWWGIEDxBF kk4TWSZZd4tPK/lzKY0lEoWaGd/bvMTjcUmSJElauHCha4VUKiUIgiiKNE8z8lLSW4Ul7vKk24mJ m+5qO17MO7ae1H8sysxGq2LJEuzaheeeK7R6okNPIilBsvvFF6H4wkpTW39ZJpHPPPOMawXqFKrr uqqqrksYfhGLxUTR3XVocuEkSVKiBgK/Rr4qlEmTM7Ek9VWRzRJJIh/6kKN4mAz3kl5CyGwy+x5y T7mtFvrVWmZeWWSqYh9riKIoyzJ1ErFvl77Lk95a8sFVWTG54KDxPLJZjwPS11RwpFKkeH9bY87s D6nU+O1bvz5/5yAZbCNtD5GHKmi40OcplSKZjN9X7QWFBIckSRzHcRxHw+5RxSIASZLs26Xv8qS3 xZ3cJhccmdr8aDUVHOn0JA22xhfMB2S5yL1Lk3QX6bqP3EfHHRW0XVZ509Fc3rGpVEoUxVAotGXL lvy9Th2HaZqOZduyvGMbBEGAohTTYhS3U2S4QGN2SVIhyzkFyjEcG8LQUixdgiUjGFmKpWWdoZBJ XmuvxTYslouKruuf/exnHXuddhzWdMsan5QbxadBYE+bZ6xahWQSyeS4mUYeNOmJCPEu3EWFxVIs LVdqFIGZ6vlCKBSiEiDi5qbosqpCZ0rUxUXTNK32MfZqcYbienhm/VUqV1yBkRG8/TZs2v4hDI1i dCM2DmFoGMPd6JYni6ZRCoViqbAfyxesBCk8z+ev9RRcjqUuLoZh3H///X5fQiUUd0VhU5WS0HUs WgQATz9tL16BFauxehu2jWI0gcRqrPbkbKEQXEPT6joKrQkyakdxHUVBk/NoNEoDJd5+++1+XwLD D2h6JFnG+vX5O+/Dfdux/WP4mFdSoxCmyUS8PzikhiPbQbGk03SG03TesRQ67i0EG/0Ww4rBQz/0 S53ainVY9yV86S28pUHbgA0enjl/gqnrzI/ZH3p6egI2gsGgfa+74DAMw0rI5DigWSgSG4YlRnBn aAhA8Rg8VA96A244giMcuDGMeZvGNf+cLBKHX5imaSlH6eqsfa+7joPneZqtHoDetErtIm69bM3F hbvvxssvg+MgSa77NWg0bFftutBsntitDM/z1DOeLo84VlcLTlWsekI5At+RAtJzV9+yKPQUmiYT HHlccgmeew4PPohf/9pe3Ic+AGuw5lJcasKkyZ9rR372XyZK/IIuj/T09Li6qxRcVVFVleO4UCg0 afZGO44UkIqixONxnufD4bBYVDPuuQJsxgycdx50HboOh5aGaemdJJO49lq0t2PHDsceE+YszDqK o6/htRLd1apBEMYTL1kwEe8XhmGIoliJk1s2m6XpDso1Vs1kMvQoFHb1XbRoUSqVSqVS6XS6Fgbg y5aRQIC0tbl4VDAPtxyKWpFfQa5oI208qUlMlkLdsdMCXkXpdJo+6osWLfK7L2VgyQdXJ7eCUxUa NDAUCrmmYymOpmm+ewefdRYCAQQC6O937mJa+nF0HbEYIhHX8R6NKrwd20/gBIA1WFP/DrK1WB+h Tm6GYbjHACwiJrPZrCzL5Trb2VNAFnH1tTv81GLE0dtL1q8nX/iCS9bBFviIVQUdgyUSRYZeaZKe NCdjjbB3KpUiZSYgbWia1MnNNapGwRFHMpkMh8N0nlO6lFJVtWcCAJIkqaoaDAYjJWaC9o59+7Bx IxYuzJ+2T/nlvaeeQiwGni+UKkmFasCwkp7UGfvnja3F+oiiKJIkmaapKEr+3oLKUY7jEolEuXlV HCkgrQjrDcWUVtRfdtn4uklnp/2lnIM5+7Dvaly9B3u+g+8IJeRkrBE01jTTifqOFa6cZoN2UExw YGKGU9aKbEVdrFXLrjKiqePQVYWi4POfRzKZn8b1P/Af0zF9Nma/iTf97aMgnEqGMKVFvN9MkpKt 0AzH0kp4FYnMgX2+Vzulg+skuakj31YIDfZXOCbTxeTiHtLTRbr87ightuehxda/mkXH4Rqd2FFY zFelSObIZiEUchoUGcbUW1VJJqGqkGXXCYABI4ZYBzrewltJJMMI+93dU91kIw6/UBSFerWZpqmq qqIojmlHQcFB7cai0ajvC6veMoXmKWvWAICiFLEiTyKpQZMh/wK/ALACKxJIlHOO2sI0Hb5Ak7Yo ikJd1QzDkPKeHxfBQZ1TqF6T2oChtTxWpoRpwJo1+N73MH++44KHMDR+W2DGEOPBR1DvBa9JocJd 06be2LBh4DguHo8TQqhNRn4Fd+WooiiiKFIvl2QyaZqmJNXWSaFuTJUQPh/8ILZvx65djuLVWP0J fGIUoz3o2YZtviy4TkooBMOAaTLPgMbFZcRRykCliQiFppgfvRVN4+ab83eOYexxPH4Yh3diZ2NK DQA8D8OYSpPKJsRdxzHpQMVbarraS5f36nMu/9G0cT2oIOQnfzZhcuCuxJUHcbARlKCFoD6yU3Ce 0lAJ3gcGBqi3al9fX/7etvIb9J5aPyL29ptWV1MCigLTLBJNQ4GyFmt/jB+PYWwBFvjd3WJMNbWo ruuxWIwKjgbJVm8ZgJXnq1Jrau2rYsduDtAy2X1OsXgxyWSIJBXJXicTOUGayXwlHm/BX6qQHUc6 nRZF0fqzEbLVE0IkSQqFQjRBXP7egoKDHiMIglf9KHIT6yk4Wi2HmyiSmTPJe9/rCB+wiWyiG9eT 6/1yV6uYtjbS3U1uvJHMmOF3VzylkOAQBIHGzaIOpWiYbPU00aSrPVjBc/A8L4piKpVylTfe3sRa v8z2jJAt5RpL7UEvvDB/D094nvAzycx+0u93L8tmzpzxWCpXXul3V7wgHo9LkiRJ0sKFC10r0Fc9 m81SK+0GERzWKcqLx/HhD3/YNE2O444ePerDnM9T7PrR1pk8W1GF//Ef83dmkNmLve1o/xl+5ndH y+aOOxAIgBB89KN+d8ULIpGILMuyLM+aNcu1QigUogH3qDZBFEVquElT0lvbpe/ypNtlx+NIp9OO 42shhus54iC22UqLTFXi8eLRNDpJ503kJjru8LuvZcNx5MoryX33TZWpSmUp6Wudrf7rX/86jcch u2mb3Ec1hTQiNbqJdZg+0LcslWpywTE8PKm7WpzE4yQ+TIbHj5jYYPhOEzm5TTp0cLcctcfRoBOW Go3i9u7FSy9h/3488wzOOw/z5tXoPKdo7qnKl76E5ctRwLKGBvsTIdqjaXiY/JkxRRAEIZ1Oh8Ph IsF0Csbj6Ovrs/xTyISmxHPmzcN11+GVV/Dssxgdrem9gKY1c2KEzZvxrW/htdccFmxBBDPIAFiI hTfixpomPWFMHSYNweVzCsi9ezFvHl57DfPmYe/emt6I8VQJTYlp4o9/xMgIli7FAw/kXBeEGZgx AzOuwTW1TnrCmFIEg0FqZua6133EYaWApH/WbsTx0kvYuxerV4/PWWo6VeG45hxuaBp0fXx6snWr Y6cM+T/xn21ouxf3+t1RRktBRwzhcJjjOGpvZt/rPuKgKSBdNSWVUcgI/7LLMDqKW27B6Cguu6y2 N8I0mzAwDI0TWziaxofx4a3Yuhqr52CO331ltBTRaHRgYIAmSBFFMRzOcW4q5qsSi8UqCMOhaRoN cW6d3soIWYj6+EFyXPM4XA4NjTu5Fk16woN/E2/S6Dv7sM/vTjNaCp7nU6kUHWhwHOdcISm0JGPt rWBd1mqWpnTLuK0d1nk5dvFiMmsWOf10EgjU/FwesGBBEVcNH5OeMKqhWZZjS6GYchRF7MbKkVsD AwOqqjrK9+/fH4vFYrGYqqp1cKC+9VaMjeHQIZx5Zs3PVRUbNmDePLz0kkOR24e+EYyMYGQWZvmY 9IRRAaqq0kd9//79fvelJGgsnlgsRhPIOyYp4xSSKMXzOBXH0SzVsjjq1Nly9OGHSSBApk8nZ5xR 83NVjuXkmp9+jpDZZHY7aX+IPOR3LxkV0iwjDo7jaPbFVCpFCLF77loUtOMIhULUY696936e54uk vK+PwnLbNmzZMr7RoCSTMIzx1ZO89HObsOkdvDMLs96P9/vdUUaLY5omDRtaRAIUFBw0aCDdJuUs x9K8T7FYTJblWCxGRUYiUTB2dn1sK6jUAHDjjfU4XXmYJlQVoVChGJsKlH/Hv2/DtqVYugqrtmJr mSdgMMqDmmJYBhkuFBquhEIhulGlz0y2QHQZa9jW9P4j1bB+PUmni8TgyZAM04O2DM0yVbHefYpr PI6CIw7TNC15U03Y0VL8XFo8DmgRvv1tXHhhId8TFSoAZkXOqDOpVMr+p2sGWJ9NzifO5cft8RdJ wty52LcPuRPIIIJhhK/G1dMxXYDQgElPGAz4bnKOqZPoxI6moacHr7yCcNiR/zmDzOk4fQxjb+JN tuDKaFgKmpzffvvtdMQxd+7cYDBYux40nxl4ldhjkefpjD+IDx7DsXmYF0XU744yGAUpOFW5//77 g8Ggruuf/vSnZVlWqNNEDWhKx7PKMIxxK3K31ROak3Eu5h7F0QwyDZ6+gDHFKabjyGQyAwMDAARB YIKjKtasQTKJZBKy7KrR0aCpUGXIP8aPaclGbPS70wxGQQquqvA8r2kaz/M0/Gntckw1jeNZZWze jB//GKOj2LMHP/mJVbwBG6hoGMLQNmwLIcSiaTCaiIKCIxKJhMPhdDqtqirNQV2jHrS44Fi6FIcP A8DTT9uLf4vfzsCMj+KjP8PPDBhMD8poLgoKDo7jIpGIaZqiKAq1NLRo5bVY6tonSZg507EngUQv egcxeBIn/e4lg1E2BQUHdYmTZTkYDNbUlKM1rb9ME4qCSGRchZOb/9mEeSkunYEZ1+LaGZgxhjG/ u8tglEexEYdpmtW71U9F7MH+8tCha9DuwT3X4loAQxjyu7sMRtkUFByJREJV1Wg0Go/Ha9oDTWsh A7AlS3D11eD5QsH+qBW5XQ+6Aiv87jSDUTbuy7GaptFIHDQqh9+dbAaGhnDJJXjuOTz+uN1MYxVW jWAEwCW4JIZYCCFmRc5wxbJ4MAwjGAz29PTQIOPWdum76tHdfL83mlIhm82GQiGaeroWHniWp2D5 cYIakkSCyHJ+AJ5hMtxJOueQOb2k1+8uMnymiHcsDQlOtyORSCqVymQyNLa4tV36rjpcS4Dk+aEE AgFCSDQa5ThOlmX6p+cCq7+/f3R0FK0xVVEUCAJCIQwNYYVz6jEbsw/i4H/jv1lStamJqqo0tM2T Tz65e/fu/AqmaZqmGQwG6YtmvXHUWcxeWOKuWrywTvJlCQ29E4lECCE0gljtpG863eTBOCaLpvHn 5M8XkoXDZLibdPvdV4bPFBpx0Oic1sto33AUlrirDtfiouOgQcmpTlTXdUmqoUVjs67YjIwAQDI5 vnriZouiQtWg6dB3Y/dSLN2P5ghUy6g/4XDYirilaZooioqiUItt+zaAEnfVo9P1l7sUKn1TqSJ5 1xuYj32MSBJxi4xECMmSrEzkNEmX2SijxSkeAcx6GdPpNB31S5Jk3y59Vx2upS7TITeojqP5FBwj I4jFsHMn+vvtVuRhhAEkkOhAxxfxRQkSsyJnOLD0ei1AW/VNOLBncpt0iaj5HFWGh7F2LZYtc/ie JJDQobejvQ99LOkJo+XxXnCEQiHL2FRRlHg8nk6nC3nlN5PgoNE0RBGimJ/82YT5Ml4+DafNxVy/ O8pg1BzvBYcdVVWpMUgFOWgbCyuahlv4EA3aciy/GlcfwIGX8bLffWUwas606puoDJoC8qWXzlfV kzSxbSOyYQPWrSue9ITag+7ETvrnDuwoo33GFMCy42iWFJClUBPlqGWCEg6HBUEQRbGvry+bzdrr NIdy9KKLsHIlJMl1wdWAoUJlelBGiTDlaDGsTG4AJElSVTUYDBYaU2ia3zegEENDeN/7kMlg2za7 1NiMzbMwC8AszNKgMT0oY2ri/VQlHo9bDrXU7cXvaywf08TOnXj0USiKIxD5WqzdhV3taP9X/Ovn 8Dm/O8pg+ENtlaOT0ohRfHQdqopIBIKQn75Ah/4YHvs4Pr4O6/zuKIPhG74pRykNFzdQVcFxRaJp 7MO+p/H0UizdjM0jGGF+a4ypic+Co1HSuA0NYfFiKApE0XUUZMJUoEQQ4TG+HLsWa8s7BYPRQvgs OBrFye3LX3asntCIfiuwYghDwxjuRjdL/sxgWPis4/B/qrJhAy66KH/1BMAqrLoX967G6uVYzpKe MBh2fB5x+K8cXbcOR45g2zbsyDHcWoEVUUTXY30CiRAaYTbFYDQQfo44/J+n0CQGsuyQGgDuwl0P 4aGn8NRf4a9YIHIGw4GfgsN//xVVzV9Aocmfr8bVYxhbgRVbsZUFImcwHPg8VfETRUEo5NBr6NCT SNqtyJnUYDDy8Vk56ttarKpCECAIG7CBFmzABhWqAYNZkTMYkzIlRxy6Do6jQosmf74SV27F1ufx vGWmwWAwiuDniMMfDzfTRDJp+cgnkJiFWT/ED4/hGJMaDEaJTLERx5IlWL7cntV1ARb8D/6HJX9m MMrCzxFHXY04HnkE8+YhncZ3v0sLDBgxxH6Gnx3F0QQSTGowGKXjp+Coq9nokSP4+7/Hu9+Nl1/G RNITpgdlMCrDz6lKzSMVL1mCHTugqjCMJRuevnXmuhtHP3oGzrgFt4gQBfhutcpgNCt+jjhqKzjC YezahblzsXs3ZHnHzGdvxs0dW/7vIRySIDGpwWgcdF0PBoOBQIDGzWvWbPV1y2olyzVrPR4nkkQ+ 9CF7WSfpbCNtD5OH/bpkxhSneO5YK2F9U2Sr91NweJ9uOpslskzi8fG8kuvXW3sWk8XTyXRCyAwy w69LZkxxiqeAzGQyNNM7miHpdJ10HKZp5ufC9dLJzTShqgAQiZxSum7caO3/HD73XXwXwGEcrs8l MxiUEtMjaJomy80T86XWkonGN6ei1CF9vUmOm8kQSSLxeJEqNAt0ra+UwShOkRFHNpvNZrN0QxRF WZYzmQxNSW9tE0JK3FWHa6mt4KCjr4xbQnoPBEc6TeLx4iKDIhM5S7I1vVIGY1IKCQ4rKwDHcdls timy1ddccMiyzPN8PO/1rlDHsXgxIYSkUkSSSGnHp0gqRTzXpjAYZVNcx9Fc1CSTmwO6UOQ40QUX XHDxxbefd96LPM+XmgJy3jy8+ipmz8batVi/vsSzxxBj4UIZPmLpOJ588sndu3f73R1vqIdylOd5 3iVX83k33XRzeW71t96KTZvwxz+WUncO5uzDvnVY9wJeqMM1MhiFsL6LzzzzjN998YzaCo5YLEZF RiIvs1F50EWTUAh79pR4xHIs70BHG9qYEwqD4Tm1FRyyLLsuxFL4UrzYd+3CuedCUcZzF2zZUsp5 dejd6D6Jk21+RypiMFqSmk9VuMKubCUJjrvvxvveh9LWt02YSSRNmAKEbdh2HMfDCAcRzKAJ89cy GA2Mb05uY2MzJqnx2GN46CHs2VOK+z2NFcqDFyFSh1cqLBKoborEYDDc8E1wHDkyc5IaL70ESUIy iTvvLFJLhUqHGGzphMGoG74Jjvb2YwX30XQnkQh4HnPmWMVLsGQHdjyCR7Zh2z/gH5JIAhAhspB/ DEad8U1wdHUddCkdGcGMGdC0U2lcL77Y2vk8np+P+b/H77+Kr+rQWVpGBsMvfFh0EEV0dMAw3t/R YcUMnmDtWui6PfmzndtxuwHjIlwkQRIhlnY2BoPhPT4Ijssvx4kTOHKk88QJXH75ROmaNfiLv4Bh YOdO16MUKF/BV07gxF7s/Rv8jW83jMFgAPUwOc+nowPHj8emTZOPHrWVKgq2b8fWrfSvr+Krd+JO AHfhruM4HkGE6TIYTU1/f//o6KjfvfAGH3QcDz6Ijg7MmvXG2BgefBC33mrbNyE1AFyFqz6AD3Sh 60ycydI+MxgNhQ9TlVtvxcGDmD//NwcP5kqNXC7GxcdwLIMMkxoMRqPRMBbZl11mTySrQ1+ERdfh umfwTD/6/e4cg8HIoTEyuS1Zgp07sWYN7r4bK1ZQs/Fn8SzdOYoWmRYyGC1DYwiOHTtmvdN+w+nC ETz+HawewQhLX8BgNDKNITiA/asv70j960mcfANvsOxqDEaD0xg6Dl1f8+8z29F+Gk67C3f53RsG gzEJjSE47rsP5557N+7ej/3VN8ZgMGqN31OVvXuHfnHv6kcSv1HvWHTTvYfaDz2AB/y+JwwGYxL8 HnHMm7eC+6tP7Hrv+RGls33mRmysvkkGg1FrfBYce9/etfcFbdvFb03DtLfxtt93g8FglIRvguPI kSMA5n3tu5+6KXWsA5fi0k/ikxuwoYKmDO/S3pumaXqUmdLDpry9xsZsaircefrMtwa1FRw0o0pP T08ymXTs2rdvH5JJiOLaji8ex/GH8XACicqmKirNGusFuq7rut5oTXl7jY3Z1FS48/v27XMtL/Ka NCy1FRyKosTj8XQ6rSiKVShC7EDHX/7pTx3XXLdQuGEzNh/Agdtw217s9ftuMBg+4PqaNDi1dasP BMbbtzYA4PHHOz75qeP/QNouD9zxzWXv8BfPnTu3mrMMDg5eeeWVnnT4xRdfBHD++ec3VFPeXmNj NtXCd/7ZZ5+leep//vOfuw463F+TxsYPwbF3b8e555/YSwIZ/O+HP3Wyt7dKwcFgNDKW4Fi0aNE9 99yTX6EZBUdt7ThEUVQURRRFe3YVcd6XgbYT37yt4xv/8srHjiWxye+bwGD4ietr0ujUNKV1Op2m KSAlSfI7vTaD0aA042vSNEMjBoPROPhtOcpgMJoQJjimKB6aSHneGqPx8UdweG7xomlaT09P9e3o uh4MBgOBQCwWa5ymKF4t8kejUQ97pet6LBarXnDEYrFAIBAIBKr/HVVVHRgY8OQaNU2LRqPVP6j2 57MZzb1c8EWzEolEUqlUJpMRBMGrNj25lkQiQQhJp9PVt5bNZun/nlyjJ10ihGQymUgkkslkqm+K 9koURU+aoreLEFK9gpDjuHQ6nc1mOY6rvikyobyssinr56vFw19//BEc1k30UHJ52BR9u7xqJ5VK VdlONpvNZDJeCQ5Zlnmej8fj1bcmCEIoFIJ3ywHpdJrK7mpIpVKCIIiiWL185DiO9qf6m5//zPv1 2fYEJjhciMfj1gewShKJRPUfK6+eXQuvxBBtxJNvO8UTAZROp+PxeCQSqb61eDzOcZwgCNWPDpjg 8ABRFGVZzmQyXj1wxLufIZvNWrMMTxqs/hrtU8vqxy+U6sUZISQUCtGRi1c33xPBwXEcHWt41atU KlV9x6zO1OLhrz/+CA7PLV4ikYgnrcXjcfp+chxXpeCIT+DVq+7JayBJEu1VOp2uvjVvf8dEIlH9 PIVeI8dxHMd50qt4PF59O/bnsxnNvfJhBmA1xDTNBjQibsxeNSaGYdCXnOGACQ4Gg1E2zACMwWCU DRMcDAajbJjgYDAYZcMEB4PBKBsmOBgMRtkwwcEoFeYCy7BggqM5oPH+qcdtWUd5lSjAMAyH36q3 WQgYzQUTHE2Arut9fX0ABEGgbrKlZAkyTVPTNEEQKjhjfvv5dlCCICSTSSY7piZMcDQB4XAYgKZp NKyDqqrBYHBgYKCvr29gYICOQeiuQCBgRXmIxWKiKNINWt9RjY5faIPJZJJGD7G2afuYGObQ4Ya9 KQCiKHoV14PRZPht884oCeS6VOb/T2UEbB4Q1iGhUEgUReqcYq/G87zlzkcdriyvWfv/VjUA9qYc Z2FMKdiIo0UwTZO6hFqigeM4qs6UZTkSiUSjUUc1OpfBhNaT+mXku7EYhkGrOZqiMFeOKYrfkotR EjSqFVVwzJs3DwAdHUiSBID6lXIcx/O8NRygjrCEEJ7neZ6nESXs1WiwCdpyIpGg2hDqOGu1n81m aTWa9eM973mP1RTxzp+V0XQwJ7dWRlEUKlmatH1Gw/L/AbmYQU7wEOVBAAAAPHRFWHRjb21tZW50 ACBJbWFnZSBnZW5lcmF0ZWQgYnkgRVNQIEdob3N0c2NyaXB0IChkZXZpY2U9cG5tcmF3KQqjlPTD AAAAAElFTkSuQmCC --Multipart_Fri__18_Mar_2005_13_57_13_-0800_TtaZbFDznTSNNNQQ Content-Type: image/png; name=bic-fix.png Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename=bic-fix.png iVBORw0KGgoAAAANSUhEUgAAAWgAAAD8CAIAAADVB6ljAAAACXBIWXMAAABIAAAASABGyWs+AAA7 F0lEQVR42u2de5Ac1X3vv7MPdiV5ZfUiIV4G0QP4SoTnTCzJhkSYGVt2bBLs7SEYY4zjmi0wRuGa crft3OVxE6c7dhXlxJhM3+vIBJeJZjaGmLgku9sGX8Xh4ekAVgF+MI2CMRFSPA0LlvU+94+z2+rt x0z3TM/0zO75FLX0zjl9+nRr+re/8zu/R4oQAgaDwYjCQNITYDAY/QcTHAwGIzJMcDAYjMgwwcFg MCLDBAeDwYgMExwMBiMynRIclmUlfWsMxuKl0y9g/IJjcnIylUpJkgTANM10Oj0+Pl6pVDp6GwxG X6Pr+vj4uPdzRVEan+h9xQzDkCSp43+5SazUarVisVir1eivxWJR07RarZbJZOK9EIOxwPC+jNVq NegNFUWRHrhesWq1KghCF2abIrF6jpqmWalUVFUVRbFYLKZSs+PbBzaXXnrp7t27AYyMjJx00knt XPTgwYMjIyOxzP/o0aMABgcHe2qoeO+xN4dawE++VqsdOHAAwJlnnrlr166gbq53xLIsy7LS6TQh RNf1QqFgWVa5XBYEwdnZdZDNZjmO03VdFEVZlmN5Av50QhrVajU6sj2+90KnnXZaXJezpW/7aJqm aVqvDRXvPfbmUIvhyTf+zrvekXK5bH9IhQUAURRzuZz98tJj5+n0Z71e5zgurmn70hHjKM/zPM8D EARBURTTNDmO66DwYzAWHIVCIZVKAUilUrVajS7/BUGgMhEAIUTTNNcrlsvlVFXlOK7PjKOSJKmq qqpquVwGIIqiqqrpdLpYLHb0NhiMvmZychIA3VKg1k2nHiFJUjabTafT3hNdr5gsy4qipFIpURQ7 OuGYbRwALMsKo19s3Ljxscce6+i9MRY8Ib9sPcJC+s7Hv1Tpo39IRl9jmqbvFmYDDMNIetYLBOY5 yugbTNN0/krtaE272RiGkc1mW7w2c2icDxMcjN5FkqR0Op3P5wFUKhV6nM1mDcOgXk/eU5zdABQK BeocVSgUCoUCAF3XW5kKU1XmE7+NIyQLab3H6BD5fJ7jOFEUM5kM5lwVUqkUz/PVapXjOK9/kLMb baKbDqVSCX7+RADQWJS8+SZ++Uu88ALOPhsXX9yoJ8chk2nQvpC+80NJT4DBCESWZcuyJicnqQ+l jWmauq7b3g2N4TjONM1GZlSHZ0Qguh6q26KBCQ5G70IXF/SFp3ZNar+4++67JycnK5UKFQpOY4ez m2VZdGEiCEI6nS6XyxzHGYaRaagX+MOkxnzYUoXR91BHKUrHXa3bYCF955nGweh7kvrjt5hhuyqM foXlfEkQJjgYfUkL3l+MGGGCg9EHeH26gry/Gp/VyqVhug4Y6H3BMTyMc87BffdhzZqkp8LoLrb3 l8unq4H31/j4eCqVyufzqVTKddbk5GQ2m3WaUUPCgVOgGDBUqEk/kh6i13dVzjkHtRpSKXzsY9i6 NZGZMpLB6f3l9OlKp9Mhvb+cP+k2bTab9Z6io4kv6TN45n7c/2V8uXE3DlwGi8UBrCOJfLzU63XX Jxs2bAhz4je+QQYGSCpFvvGN7syU0StUq1VN02hGPDiy1ABwJrlx4epp/ywWi/V6vYUvfJVURSLW SV0mcpt3FPI73xd0RHDI8vFHTNMEFItFV5+QD/HMM8m73kU++1myYkVyD4mRBDQdVCaToW6jNK1c vV4vlUocxwmCwHGcnd3WeZYoihzHPfLII86zMpkMx3G5XC5q+ts6qUfq3wAmOBrhzLDqyl3sJPxD lGVSKiX3hBg9jFN3jjHHX8zkcvT/C0lwxOwA5o0I4Hk+n8/T3MWtjcnziMM6zliAkN53/crnsXMn 1q1DPp/0VOIk5l0VXded+2RUb9Q0jWZGczIzMyNJEk012HhMw0CIrTfGQiYuX68EfMYE4bdLlkhX XiktWTIzM9Ptq3eOeBUY58jOTNM8z7t6hlTb6nWiaaRnlVBGF7CT5vfIOGGp14kokmqV3HIL/YAt VRqJITiyHkiSRBUQmru4BQwDHMdCExcXroDXML5enRvHNMHzsCxYVhTNV9dhGKDhdi0E4/Y8HXEA I3OqhyzLgiAUi8VWApkBAKaJTIalX1rgtJDpy25SVVVRFEmS7MyAiqJYlhVynKZwHBQF//RPaLak dqAosCx0OM94snQ8OjaW3MUs//HChubIoBn9aXoeTdNSqVShULB9vVyn2E3UbFEoFERRpNXPOI6j +7VhxkGIBGC7d+M738Gf/3mTnhyHDGdCVSGKC/8rm9QaKeR6j3qEaBrx29JlLBCcvl7E4biFYF8v juNoE93sLxaLsiyXy2Xn9n+YcULMjYgiefBBIjf2/xIEUi57O91CZg0cOZLrpo3D63IZL70uOMpl QgipVkl8Nf0YPYft60Xm/ICoIfPuu+8O8vWibmAcx1WrVXoW9eOwXQ1DjtOU5i/g1BTJZsnIiO2v 4WSMjI2RsSEy1FhwaJrmKtpYrVapUaaxf0qtVuN53haj9qOIeptR6XXBYT+0ucfCWLw4NeUecvei Okk269tYJ/UUSQ2RIdLsOw+/2rFBBesTr1bf04KD7sXOPamkZspgBFMqzfo1T015G6ukOkAGNpFN VO+IJDgo1Pea6iP2gov4lXOnB5lMhlai7rRg7emweroXS2E7sgueqN5ZkcqyxV/DzbIgSchkQF2i 77zT1a5CNWAcxdFr1Gtukm66SbqpBQcwXddlWVZVlT4cwzBo0gAANIGA9zY1TavX6039KtulwwI5 kDAahzNEhWkcC5tI3lnVapXWSQnZP1LnkDMgohhk/6iTukjEGnFbGaJqHPV6ndo4N23aRG0W1KDj 7CwIgizLtVqNmkhyuVypVCItmYEj0TeCg9k4FhK+pruQ33V72e/qb79UvrT+ItUI0eb+o9jLEz80 oonE/69cg+88jeSi6wtq3aTCDgDHcVu3buU4jpahct2Oy4Ya0qTaPj0tOJx7W3K7yRAYCSOKIs/z uVyOuhHbEe70u07X8EGn2AeEEPpiaJoGIJPJ0EGoD0gul3OaA5xnOTtHw5YXV331uBe5gykya93Y TrbLRNZI4P4fcznvEiy2bSFhe3lRN2LqmgWHK5fXO8s+RZIk20OsVqulUilqAqxWq/QsWZYVRdE0 rVAo2OYAp1+Zs7ObxgnAngIA7AF2vomb/hlXfwHWmPOUIQy9H++/GBf/mPvxg5kHOSx01y9KUhIr jPR1aluaFmJHndHDtJDRyz4lyEOMeLYVcrmcbQ4IumI0NEIqFXLKKWR4M1m71rfLSrIyRVJNR2Ia RzewLPdOimGwvZU+xq7n6KrSWCqVguo52qc4a0HSg3vvvZf2p0PRA13Xi8ViNpulDlH2WbquOztH i3Zb+Tq2HcH/ehSKgue2uxotWO/EO0cxOoGJUYwewIGkH3O3SEpiNZW+muZaSzLn0YWP85vZEy5e DXdPqqQqE7lCKvTX7WR748GYxtENTBOunGGsYPiCh/RURi9FAc8joBItrZYg4ngI7GZsTnrG3aN3 BYeXhZjWgNGTWBYUBcWir33egqVAKaLIY/Fa7zviOaooCj0wTZPmQahUKlEH8boRssyjjM4yPQ0A lQpUFbJsS41pTNsHOnQFigx5MUsNdEJwGIYhSRI9VhSlVCpVq1VblITHK+sXfIoDRsJMTUFRwHHe HDyjGJ3GdAGFHdghQ25p9AVFZ7Ocq6pKHeC8kQI0WTEAnud9E6AbBgQh6cfDWDzwPF5+GVu3Ip12 tUxg4vv4fgGFrdh6Pa6POrCqqnRDhyUrDsS1Ie89sGlsYXbGxdow51FGp6Be5AFuGp8hn0mR1GfI Z0bISDsXWUi7KjEvVQqFgh26p+u6IAiKopimGTWBoDMu1iaTQfez2zMWOM4g1+eeczfCUqCsxuoy yl/Gl7+JbyY93V6hs1nOqeuOJElixMSt3r1YCvMBY8SJMxe5BwNGBRURou1FPoGJpGfcK3RkO5bM 7cZnMhkaLh0LLN05I06om0bAnzQVKgeO2UGD6NFEPr5LEo5jgoPRHjt2AIBpQpJQLPqa3y1YEqQM MgKYcT6QHnUACwomYDuyjLa44w688QZM07s8GcTgNmz7U/wpD/4X+EXSE+11elTjYJoFI36uugpP P4277sL+/d7GbdhWQOFteBuTGmHoRY3DGxfrbGIwWsEwsGEDXn4ZP/mJt9GEeTWuPg/nPYfnpjHN jKBN6UWNw3cvlsJS+zBaQVVhGBBFX6lRQUWHfjNu3oVd27BtJ3YmPd0+oBc1jqC9WDB3UkZUaLia IPiGSFI3DQFCBrOtE5hg6kYYekvjuO8+AHjiidkDL3E5cUxPzwY0TU8nfc+MzqHrs+FqflLDgKFA ESHaUoMRnt4SHACGh1Eu45OfDOzQuPBvSG6+GTfcgJNPxlwqacYCgv41aFgyXoFiwpQhL5YUoXHT c0uVpUvx5pt429v8W+PyATv/fPzwhzhwAOvWJX3DjNj53OdQrXpLxp+Ek/4R/3gdrjuCIwaMRR4X 3yY9Jzj278db3oJf/9q/lfqAtb9g2bULw8NYtswbncDoZ7Zswbe/jVdf9TWw78XeQQyOYGQ/9rc0 OuM4PSc4Dh/GBz+IiQ7bp776VTz+OM49F+PjSd8wIy4sC6eeiocewnXXQdO87W/BW8YwdhRHd2DH Qkrz58pl0R16y8Zx/fUA8LGPzR740nxHdhRYBywDlgEbgDGfLhOfwBe+hQ9NYeLmpO+ZEQuGMZvs L5PBXXe5G2FIkPLIv4bX3sAbj+GxpKfrRtf18RB/xFwp9WjSrKg1d+PBN9i+Wq3Sgjc8z5c7U3wx KDdBrdYkm3nz3NdrCfk4IWsJOZOQjxGy1lHCz/7vTPL8+eTu2wlZ22w0Ru9TKjUoEVom5RIpRRmu U7RQrZ5iJ3ynletrtRqtNSMIQlL34jNXWrrSrlJZLpfltlPo1D0J5oMeoqY1ERzNiySsJaREyPo5 obDev88jD5JffJLsPyuOp8hICr+ajMcbSV0kYpVUIw4aM7QulKZpF198cYNutuBwVrF0NTkPMpkM /eueSB0Jf8Hh/NVVJrvpM3LVvKVpAYvFoqtnA8HRuGJb86e0mpDVhJxEyCmErCeE9+uzluxZSchZ ZM+pHXqwjM6jaQ2ywtGiJ3WSfPm/qIJDmPNxFEUx59gIoMd2Z3pcr9dpnfouE6gdZRw+M+GHo5pF vV6ndfdqtVqxWPQtTR4kOErNlMpQK6cQfeiFfvRRkvQfJEZ01q4lsuz9KoyRsRzJVUhljIyVw3wJ ukvIpYqziqWrSRAEWZZrtRrHcblcrlQqkdbqWrbNQFPzR6RMPLTQniRJ8lzYMs/z+XxeVVVXz4MH D+q6ruu6K49x0xoIobJyNOtgWbNG1p9dBlQAFjvXL0xP45xz8MIL2LrVG30wg5lH8MjVuPppPN07 2TQMw6Bf9YMHDwb1mZycBEDTd9MqlmlPzmQAoiiqqppOp4vFIq2znUqloqbXiweXIKlWq64OLShC 5XKZ54+vEKjocfW5+OKLqf7mWgQ1VSiaWk8JIaRZB9uSUi6TF58ipAeKDTJCUS4TWW6QVXiIDA2R oRzJJT3R44RcqvQXPkpOaf5qQWupZKtL3DjlCKXlpUrzPtVQgoNSr5NymZAq6Q27OyOYep3I8qwd tFLxtstEvoRcQo9Xk9VJT9eHhZTl3McBzFXlJBfFT9NekpTLZap6UVsp/TUMYcq1Ndm3ttDUmdh2 P+U4mCYgACZggIU79SiGgUrluBf5fAdBO6uwXcl1D/Z0bWq3344778SOHfiHf4D3a75lCy67DBMT yOcTfYBxE+g5ms/nZVmmSy/v+iWIYrHo9GOTZTmqW1uYArFNfMBMIIpP+uzsBEABeLCgp55DVcFx QbnIK6hYsBLMKvz88xgdBSF461t9WrduxT33IJXCpk1JTbAjBBpHTdNUFIW++ZFGdImJqM6wYa7W xDgaYgR/0SMCkStVMjqJXfQkOKswD76IYvShY+OUU3D4MA4fxtq10HX3f+ecg2PHcOzYQgunDNQ4 BEEwDKP7PvBhlipNtJIQQY/OhECZDHR9LnCuCChAElZqxjw2bMA990DXXUGueeSfwBMzmBnC0F/h r5xFT7oPrcqybRtOPBGE4IknfMIvf/pTLFuGVApbt+K885KaafwEahyZTIa6coQ3T8RCmKVKE+ES Iu7eeZV5ofo8wANxpPxgtM6GDXjmGVxzDS680BXkqkEDMICB83BeglJDVSFJs9Wp9+zB3r3Ytw8H Dvj0PHwYb7yBmRkspLqxaCA4CoWCoiiZTKZQKHRtNqYZqgBCkz4hDByNFkQCoDPPjsTYMT0z9JN/ Xzfw3OhLv7j9MXcM6+X5Q28O1wfOeGnX4FPec5cvx/LlGBvD8LDPyKOjWLUKJ50EPw8JDA7ijDMw POxjxdyyBcPDOOMMDA7iuutmUxEG5BVbLAQuVTiOsyzLNM1uxt6FWacA4HmYZrCJVG8uO5pcSAYk sCJeCaDrm6v6Wbz8s9qaZcuwZMm8hG//Dz967p27Bv+tePTl0wdX/reur3Sdnc/joYdACC6+2CdT 3Pr12LkTqRTe9z6f1hNPxMsvY2QE73ynu3XFCgwN4eWXMT6O++9P+hH1BoGCo1wuq6o6OTlZ6m52 vTBSnO6hBgqOECO41qKZjGdAkRk7uo6i6L/dYHDy7t1Yvjz15pu46KLj/1ISpBxyF7x289WHMDqK w9ZKr0FBUTAwAELwy1/6mBs+8hEMDyOVwu9+59NqWRgdxcGDOP98d+trr+HQIYyO4vXXk35EPUOg 4FAURdM0AHosST7DYZqhsntlMqhUAtqM5vup3hvK5aCq81Orc0AmlPLCiAHLUj/yiHXBJzP5Ey88 gs9/Hhs3Hm80YapQqUVjy05s2wYAOwNqGBw+jOlp/9ZNm/CJT2DzZtx+u0/rTTfhsstmR/bmkbIv Oj3d8SxT/YGvW5jLcaMTnme+XnTh44MDe2rNg9Y0jXjD7vzDLGXSA9GV7TI2RnI5cuGFZGTEp3Vk hPzBHxBBIB7nXlKpkKEhksuRsTFyyy3uVkEgq1YRQfAftvFFh4bIhReSXI6cdBKRP/mL0uZ/9guE JISQEin1SDaN9lngnqMAMpmMKIo0UO2b3/xm16RYeGtToGJiNdcR7Ag3J/4GV3EhGDtuuAF/93cA cNZZPtrWuefOrvw/+lGftf3wMH7wA6RSWLHC3XrJJXjwQUxPY/lyn2HzeTz4YOBFzzgDP/0pAVLv PvvF4rue5T7+IWdrGukaalfhqjfxpgyZlS/oPjS3mK7rPM/Lsix4/WiCJEprYfXh8ZW+YQJVKIEa RwidxffccjkgD0i9v0PgajVy1VUklSKpFMn5RX4JAhkYIIODZPt2n9axMTIwQIaG/AcfGSGDg2TV Kp+mSoUMDAReNJcjqdSxgdSxyj2v+EyJCEvJ0hVkRS9k04iRftE4wqTyijmsvk1C7qqggW4SwiTh q61QNzAfOCAHVNB3VCqQJJgm/v3fUS7j05/Grl0+3R59FH/xF/jXf8Udd7ibpqexdCluvhmbNmHL FndroYArr8QXvoAxv6yuN9+MbdsCL/rEI7/99NA9206/dWoq5W19ES8ew7FxjLOiJ0khy7KtOgiC IIqiK/1FR8Lqw+ArfcOnNw3M/BRCOwg6t5G+IxNSI2EQBLJ9O5ma8jEZEDIbDn7LLWS1X/RmLkdu uYVUKv5R44JApqZmf7qgZ9FhabyvKJJauAkngCgSTfNVRWiyvzPIGYQQgQhTZCry4D1Mv2gclHK5 TPUO3+x/nQqrb0qbS5VAwRFC9ASd2ySzaugFy1veQoaHAxX4kZFGCvzQEBkY8I0aJzxPRkf9bY2E kJERMjBARkeJLDfJvZgktRoRxaD5aUSTSbvZbXuZ/hIctmLB+/0NDAyr13WdBtR3M1wl0lLFsvws mu2HugQRzrNjxw4cOoSjR93OS5QHHsChQ0ilUK/7tJomjh7F4CAeeAArVrhbf/MbHDyI5cshy8hm 5zXt3InDhwFg1Sokkg4qFDTlQkCQK3XTEJnnTM/QxAXUK0tcq5XeXKoEJkMPobMEGVarVdIkJXO1 uUYjCGTlSvIHf+CvcdiblL5LFXuT0quPbN9ORkZmN029Vky6Y0p/9iLOHDweaqQmEnGB2UF96S+N Q9M0QRByuZxvgRQf4ygt2WDrJ/V6PbyUMgwjnU6nUimaPdFVP6Yx/hpEAP7bsWao0NggjSPQPnq8 B/BD4FRgCbAEWAd4it2X1+KXq/DdOvb6zWRmPbRf4+lD2HO+T+vhTXj6ELRfQ/OEYG/ejAMXofwS aqt8apBpk5g5HdqvMXO637S3AOuAdYBvLpkCsAHYAPi5Rc2e6Hen2DF34obgi67cgw2vHy+VNMej +UexDjPrZr6+5es6dHfxZ3vYHZ5hpx1T6tqdNr7o7XPD+gZ15edO3IL+wjTNUqlUKpV4Xx/tIHmT y+Wq1SqNkQ0vpVxZzp31Y1w9vdK3aUUVFz6KQwjvr8YpS5sXkFlLyEpC6nNFW7xWzPVzlpqAei7u g/Ct6z0HnR628blhTjzlFHL6a97G3Wt3D5LBFEntW7uvD+40pmH7S+Owlxq+a46hBvKGJvKhScBC QrOc0xMBqKpKQ10MT+6dmZkZqpXwPG8nK4xkffDpHML7q7EZJZTKcyIgAK8AOrDfE4M/g9N+BlwP zPiF59P+9/qdSFs/DNwY0DoDXA9c5zdy02EbtDYYtvGUaP/7A058+TdYUcTv7sXgAeju3Fgr9q8o f7hcurG0cv/KPrjTpsM2eA77YWZMNa/euu/WmVQ/hdZTG0dgxEmQvKHFYJxrlvDYWc7hqUBl45W+ UUtN+mgHITY+Gis15XKzXcy183UNv7/DsxNbzBqHppHV+wghJJfznlgipefWPlchlRzJ/Xztz/vg ThelxkHffY7jSn6bnYEah10YpQUHMEEQqJ4iCIKiKIIghNmacWblCicRPR+FUFiOJ/vyI5eDrjfM aXoX8D+BJQCAdcBdng7vxZ99HXgw4PTT5tbJpzVsDUpsS60Jd/jNqkFmunzDi54xN+x7A05fN3cJ F3cEWDckCbkcrl6JdQA050UtWAqUIor8afzadWsnMNEfd9r4ou+dG/YMv1bnv+mT6CMymQx998Pu qlBas3GU5qDeH96KkDbtaxw+cjCEE0BTV5HwviRBJFHKszeoVhu4aZRJeWG7aTSlvzSOxkEnMScr LhaLgiAUi0XqA0KFFiFEluMPFPOZV/vZw8JlS258epR6EguISgWGAVn2fcQKFA4cc9PwRVXVfD7v uxfp2pcM2RTLrGybqP+aI0jetGPjCINX+kb9Q+1jrWjDieP4GO1pHJrWzBlkgTE15VsyfjVZXSEV QsiJ5MRF4qbRlCCNg+O4arVql4927kW69iVDNrU/VZew8HZIoFxt0EOMulTx2b4NoQg3vUq1Gm1X 2EX7K50+g9Z/9ixPKqQyQAYGyMA6si7pKSZMqVQSRVEUxXXr/B+FpmmZTEYQBKqew1OS3v4wZFMs 07b9vnxjVRpFx/Y47u1YK5RxtKlX+7yk54wG7NiBNWuwezcefNC7PLkCVwAgIHfizqQnmjC0QLQs y8uXL/ftwHFcsVjkOM5bmz1ZJEkyAl6G5oJDkqS4Vk2Nifq6usvWx/e2txOd08XUzolimnj0UTz1 FD7wATz+uKtRh34KTnk33l1G+aP4aNJz7XXy+XwulyuVSoqiYG4v0jRNjuOcx+GbYplVkzoHTTUW msOjHnfEZftLFeJaF4RbX4RZhjT3Hw2mhbvoP2jJ+ABkIpfDBCkvPoJsHKIochzHcRzdfHTuRbr2 JUM2xTJbKoBqtZqv52hzwVHrTF4H10Os11uxLMwTHOG8v8JcpR0D58Lfi5XloIdIs2nUQmYuWXz0 13asHeS2detWb6vbAcyyrPHxcecnHMdFinNrSVXDO9+Jyy7Dli34ylcinDhvXRDOXT2MVztNet5C 9P0C34t1lYyfTwUVE2aCxZ8Z8ZKfq0xlGMbHP/5xV6vbxsFxHFUxbP0k1/lX4Ykn8Jd/ic2b8dxz 0U6c5+IZIhNHyEpxaNVUsTCtqjRroMdN43bcvgM7ABRQYG4aC4/cXHKHYtGnprePcZSulGiIS6VS 6UJdlfXrQQgIiVzRO+qLGj5RUGsGppB1YfqM730PkgSen194BnfiTgFCBhkNWhHFHKtAs7DQdT2V SqVSKd+9kcBdlXK5nM1mC4XC1NRUp6f46KMYHcWyZbNlb8Iz7y0NkYkj/FvNca0oHQtwS4WW23zo Ibz4orfxfJz/NJ5+AA+wrMILj8aeo4GCY3Jy0jRNALfeemunp3j4MG65BTMz2LMn8rnH9aEQ2kd4 5al5Up/FgKJAUXD22fjZz1z1yyxYl+GyX+FXR3FUQJTYREaf4LJsmvPV9UDB0cRTvTeYZ78MoU3w IbQSu2cL6kMX07N2GMuCJEEQIAhey5MBQ4X6HXznV/gVgDfwRtLTZcTP+Ph4ykE6nXa2+ofVm6ZJ Vzj0VzLn4tpr0OrTgF8ClYD+4Vm8S5VKBaYZlFVYgcKDZ3bQBY9lWfTFp5XnXbZOf42D53mnp3os k+jY7c0dhdg97fSuR3iNpndRFHCcb650C5YESYDA1iaLAZ7nLcuyk4C5dlcDlyp2v0wUfwZXsmIA k5OTzl+DaLFkgf2uhihSH/UqNKlPeHS9b5cqO3YAgGFAklAs2jbkaUxvwRZ6cBtuU6HKkPkwVmhG /0O3R8bHxwW//FqBgkNVVVVVzfAbmAAA0zRrtVq1WqVe9/T0Wq1GM482oOVXblaJCHG6YUS7StRo tz72/rrjDt9sGhOY+Bq+dhEuKqCwDMvY8mRRYZqmIAjVatVXcASmDhRF0bIsqik0fe1t6DVotB/9 hOf5fD4viqLLjeTgwYNUBeI4LpJS4yL8uxqp/EILRJSxPcNVV+Hpp3HXXfjQh7yNX8QXRYjrsI4F ubaMYRh0qX7w4MGk5xIBGtsmy3I6nfbukARqHNlsNpvN0qC9qJfUdZ2m/OJ5XhRFTdMipUqPeC0A QDgTSlQBFUnQ9OU6xTCwYQPOPx+7duFOt2i4DbeJEMso/xw/39J3dUEY7UGD3CJUcrNtovV6XZbl qMF29Xrdrq5if+hNI+YK+Gk5qHT2xBCntxB+pmkRSjf3XwofWQ567jRcrdq0Sg0jCn0a5Ba2khul UqkUCgW6zgkvpVRVHZ8DgCRJ1FZSLpcbn9jyfsdsVo4Qp7ew5RHJDayf9mKdbhoeqJuGCDETMnCQ sRBRFIXaK6i90kWgjYPjuHK5HDUpSLFYdNoyaK7jjpatpi7RHfqGR5p43+zFMjcNRggal2Rr5DlK Tzbac37odLF7nsfMo6F2VVozXobUI/pgL3Z6GvBx09gxV6BVhMjcNBg2giA0+qsftMJpXDmyfVzr vXby3/yfPyVhcse0loI4pOWiDxJ/nXWWb9ETnvACEYbJ8AXkgqSnuMDpFxuHb3Zi14eNNA4aVt8d 8dbGhizedUqo0NjWNKeQbmA9vRe7ZQtOPRW//rWvK0sNtWlMr8CKZ/BM0hNl9Ao0fSkAy7JUVaXJ R50dmoTVT05OdqKWkpd29PzdT3XwEjwfSuL07jrFsrBkCR5+GOk0NM3VaMAYxvAf44/HMFZAoaUL MBYatGiLoig0ts00TdETguBjHDUMg1Z+dHp90A+TviN/VlzSvI9l9Y/xMkacyf48Qa4VVCxYD+Ph zdgMh7GDwaC1phv4cPnvqtBK0TTKpVKpWJYlir1rZk/9R/M+nQ5v68W9WFqkw09hpMWfaf4u+0Mq PhiMMPgsVcIoKrHTzov3m4tDdWtZYQoTtNJb6gx108hk4JctUofO3DQYbeJv46CKCiGEOo92YR7t aATn/Vdz22TUCDcnuVyT6fXWXqxhQFEgiraknMa0faBAsWCJEFmyvx6kc9knWiCfzxuGQUNPvK19 XALS5thFCW9q9Epc7Lp1vkGuJZROxsmX4bKP4+NFFJmbRg9iGIYkSVRw9Ei1etsBLFqsSqeJzY+j SojW3I2inTrSpFltt3Yqv8VDpULe/nYyPEzOOsu3fYyMDZCBpGe52Any46Ch6/avvVCtnhAiimIu l6MF4rytgYKDnkO3V7rwEFsXHBoh1eant1lgrVwmDWpgJh/eVq0SWSZvf7u3pU7q55BzTiQn5khu NVmd9EQXNUGCI5PJ0LxZNKAUPVOtnhaa9PUHG2qqqHQuIt5J68ZFC8gh12xt2Kbxkka7RQn36yJ0 90QU8corrhYDRgWVL+AL1+N6OIwdjG5iJ8SamZnx7WAYBiHEsqx0Ot0dk2IYWszH8Y53vIN6qh86 dKgLs2z9xTaAKHUPWp5eA7tVYiYtunuSy83unswvn6lCpTUZqdQAMIGJ6NdgtEuxWJRlWZbl5cuX +3bI5XKqqlJfbfRMtfrI+Thc2Ym7E6vSug1CIyTEYqH9WtANLpFMoIqmBd0Vy6bRmzSwcbRQkr7T 1er/5m/+hubjkP1seP7LoSCLSFNcs6/VajzP0wj9xg+xdcEhEhJCcLRpHCXBFlBNi2HwVmbjuGqF VOwDjWgySdxay/Chj4LcmqoO/ksVp795pL1lV7JiRVFKpZL9axBtqfqZ5iPE4jYaFO3W1b3YQgGm 6cpFDqCE0jCGpzFdQIG6aXRrQowFSCaTcaoOrpJuswRJHWdkSlSJVavVisUiaWjpdUrftv5oy7Mj NNj1iJQBsNGl5LAfdoT168mSJeSss8j27d7GdWRdiqS+Qb7RrdkwItMvGkcYGmUAI4TAUzMyDHay 4gbMzMzQFOo8z/N8MdS4/hOd/b9hBP7l72iEW5d8Ri0Lmzbht7/Frl3exttw2/N4/gJc8El80jaF MnqEprsqvQnd4slkMrzfyxN/CUjLsgRBoCZiaumlv7q6LV++3BYure+JmLOZOBpnzTCMeHZSE/Mr NwzoOkQRIyOuFguWCvUVvFJGeQITLBd5D2In0/zRj36U9FwiQI0VhUKBFjBxlTcJXIY4S0CGV2Ds OFyO4+r1egNLbzxLFY3YWwcNbMlx7Xr4Lnk6vlQplYJsv1VSFYlYJ/WIIzKSob+WKsVikVZHIYTU 63WnbytpsFQBIElSpBTn8CQrdiX1aEDrS4k5U0yD4Ne4/CwyGVQq7ojTDsbFWhYUBcWi7zVUqBw4 Gb3iL8RYYPA879QDXIuGQMHR2G+sA7Ns6TQdmLNrNDDFxCU4vEuVDsbF6vpsuJr3dvyyaTAY8eJK puFK6tM8y3lPhfq6cbw4DV7gGFOXuR5G/Hux+TwA0Brd8//lxjAG4AScUEBBhsykBqND0Fw8kiTR AvJUh3DRKOeoIAiTk5MtlIDsHuE2fGJ0SOe4ebIj5nD+fB47d2LVKrz2mlcgVVAZwEAWWQ1aS6Mz GKFQFKVWq6mqSg0cvn0Clyq5XI5G7HUh0XnrOo1Dy2jwDsdohqBJfeyXOuZ1SrGIZ5/1xqoBsGB9 EB/MIrsLu6KPy2BEwLIsmja0gQQI1DiolhKkqMRLXJ6dvphmnIIjZNLzyNBwNZ733TeuoHIbbvs8 Pv8knqygwrIKMzoNdcWgEsC3Q6DGwfM8tYlSN60eZb6qous+4qOjycHisf/Ybhoc57XHKFAyyHwd X6e/spTCjE6Ty+U0RyUN31qOgYLDsixb2PROjoD5U5xnHG2QUjhe+6VzeRKDLqMo4Hn4pYOm2TRY flBGl9Hm19/xrYvSEZfzLjFfTNCy9V4Z0cAVvQXyedTrePRR/PCH+OY327NxmCZUNchNgxY9YW4a jN4kfpfzFmj97/Z8idAFl3BNw/Awnn4ay5bBslr1ZM/nUSx6S8YPY/gBPHAP7tmN3dOYZhuujJ7F 3zjK8/ytt95KfUtPP/30dDrd0Um07v3VucEDmJ4GIbP/taiKWRZ27fJdnjyABwooPIkn/wP/waQG o5cJ3FW5++670+m0YRjXXnutLMuNE2okg+fN8jVVxrsJUiph6VKcfTYOHGhJwfnIR3DuuXj9dfiZ nD+Pzy/DsgM48AP8oGNPjcGIgUaeo7VaLZ/PA8hkMh0SHLt3Y/duvPrq7EE0PGLCV7mIt+KtpmFm BrfdhsOHo5+sqrjqKuzbh0svddV/tmBJkFZj9Rt4Yxu2TWEqzkkzGHETKDh4ntd1ned5mv60Q47n a9bgpptQqeD9749+smdGvspF5zzmI4xs12SkRpH5UqOCigpVhrwTOwFMYOI5PBd6aAYjAQIFR7FY LBQK5XKZ53maU6NDM7joIjz8MC6/PPqZHv3Cd/ekE4KDuoGFtZ7oOlQVsuxVfmi4Gg+eJftj9BeN tmOLxSJNxpNpW92nlRa8n+/ejYcewvr1ePHF6IMa8BYz9PqAxbtUscdUlHC7vMxNg7EgCUrjYbdG TXeuaZozLTJNz0FTkDqxk5q8+GKriXY8uX9qNXdCoM6lIG9S325qitRqRBRdqVBXk9UVUqmQyhAZ KpNEqiowEqO/Evk0ppHGYVlWC2H1uVzOPoU6j9EiCUH916zBCy9EF3h+e7E87xMIG3uinelpXHMN li3D8DBuuslVBWmOBx7A0qXebBp7sOcEnHAER2hCjZhnxmB0i0DBUS6XVVVtP6ye5/l8Pi+Koitn oTNZsWkWW3Hu9FuDePNlxC44JiZwww2YmcGyZbjsMk/zjh246Sa8+ioefNC7Qrkdtx/BkWEMn4Wz Yp4Wo1fp02TFTfDVQ7T29HvXsDRYztXHqba1UnoqINOna9UTU1ErN0NDs//5z6BUIvMTNM5NWR4n 47R40lqytiMzY/QwjZcqdsE0ZxkzV0mzkE1duBcfwUEThdbr9Vwux/O84PcONBnUIya8hhJXsuLI BJRuc0mKThg4KhWSy5Fbbpn9OY9q1ddgUyM1llWY0UBw0OJp9LhYLGqaVqvVaG5x+zh8UxfuJUU8 cSipVIoQMjk5yXGcLMv01/AqzOTkpKqqoijKsixJErVuZDIZ19bMxo0bH3vsMQCmCdOMHoemAn7F WOxdldtvx/PP4+c/x5tvovMpUwEAhgHDcOcyngtXK6KN2jGMfsZeqjz88MPPPvust4NlWbRUPX3R 7DeOBos5PwzZFOmFbRGvLKGvOt0HqdVqbRadrgdUWLOlb4sbHwFrEKfGwfNkcJBEV5hagu6huO6d FX9mOAjSOOjiAp6yh8431BYTYZq6cC8+DmC1Wo3MVUgxDEMU2/JN4kJEdLRivwzQUGy1ZscOvPIK CMEjj7QpWkNgWahU6B5KAYUCCgBOwAkKFBEiC1djNKZQKNgZt3Rdp2XMqMe28xhAyKZuTLr7cpfi 1DhaIUDj0DRCC0hNTRFBINksieiGEp163aVr8IQfIAMbycYOX5jRZzQ2jtovo7OMmaukWcimLtzL UDtCJxZaTLQT8Fec52ej3e+8c9ano+Ol5CXJ6a9hwXoJLy3F0tNxeocvzFhQkLkFiKuMmfM4fFOn GWh/iDZpJZbEQJCXti04gJZsrlFRFMiyHWCvQ9+ETVfhqjfwxkt4qcPXZjASI3mNo5VYEssnws2m G6kOt2yBpuHKK2czDAMAJEg55J7BM/TXx/F45+fBYCRD8oKjFVOOGWgchWNt0sESdKqKo0dRLiOb xcSECVOFysLVGIuH5JcqrZRZaygR7AE7Ug76a1/DqlU4dgyDgzBNTEyoUHXoMmQmNRiLh+QFRys0 lAj22ifmNYtpQpIwNDS9796T/yuFYvFyXH4drssgw5y7GIuN5Jcqrdgv/TJx2FB5YRjxZeKgdQx4 nu6eTACfGP/E8Fe+NoKRb+PbTNFgLEKSFxytWCIayhpqNIlnS2W+yLBZj/U/xA8HMMCkBmNxkvxS pZUs5A3NInRH1jTbrpYkSdB1yLIr/GQa07uw64v4IoAt2JLEM2MwEiZ5jaOV17uhjYPj2pMaAVqG zQQmrsAVOvQZLKD0CgxGFJIXHJEtEWZz42il0toubxORYWPA4NGJPRsGoz9IWHC0svFhoqlhwTAi Co7QImN2fBgsLzljMRO/jUPX9fHxcXpsmmY6nR4fH69UKr6dWxEcFpqGm/J8CEUmn5+dQYAtw5ct 2JJHngc/jOHYHx2D0S/Er3E4kxUrilIqlXieLxQKQZVZIrtpNdyLBXDyyVixAqtWQVFclY8c5PP4 t3/DqlW48MJILmhfwVdOxslX4+orcEXsj47B6Bc6u1RRVdXO6xHUJ7LgaLbJun8/9u1DrdawSmO5 jHPPxb59ka5swqygsg/7TsAJHX1uDEaPk5iNg2Y5/9GPNpvmL4oh1gjH0ZvIDrua/PQ0JiYCOqkq PvzhKNfUDRgcOB36u/FuDdo6rEvq0TH6iwWZ5bwj6QntrIeFQiGTyQiCkM1m6/W6sw/NOTo/l0U4 Kk2WKsPDuPRSGAbWrw9YqqgqMpkw2zkWrAoqJkwBAkvkxWgTO8/uAiB+jWNychKAJEmyLIuiWCgU JEkKyj/YinNnM3tqkzryug6Oayo1aMArD16AwNxDGQwX8QuOUqlk13BqmpWoFX/zdt5iy4JhoGEW Vapi8OBlRNWFGIzFQsJ+HIYBIVIhxGbeX02gCbv8sGCpUAEIEFhxRgajMQkLjsj+ne1EykuSrWss x/IZzExjegpTf4u/pYZP5tPFYIQkYcHRSuR7azGvlQoEwRZU67F+CEPHcOxaXMtEBoMRlYSjYyN7 jraQLgyAYcCynFLqPXjPMRwbwMD9uJ9tlzAYUek3wdFKZmMLuu50J1ehfg6fK6N8OS4/GScn+wQY jH4kYcER2W00qqApFKAotmnDgkVzkR/BkQlMaND2YE+yT4DBMAwjnU6nUilJkjA/wssV7RWyqRuT TraqVeQybqXQPbdvJ+vXk5ERks3SDzSiiaQbRa4YDF8a1461C9b3RbX6JAVHtdpJwUEIKZfJ7/0e PZSJrJHWik0yGPHQuARkrVajld7RD0Wnk9xVacX7K+Qp+fztf73k+Q3/Xf7Qh87EmdfgGlb0hJEU IWNVdF2XI8dfJEfXxe4sGzZs0DRSr0c5p07CKg1nnknKZZ7wo2Q0S7JJ3SOD4aSBxlGv1+v1Oj0Q BEGW5VqtRkvS28eEkJBNXbiXhAVHNLSGgqNaJbJMZJmsXk1GRsjatWvePGkJWSIQIal7ZDCcBAkO O0SD47h6vd4X1eo7Eh0bho0bN/7hHz4WTTXzBtQbxvE0PJnM8Zi5fP527Z0atO/iu1lka+heFW8G IwgWHdtdbrgBW7cCc4LDJSx8I9Y07U7gIA5y4JjUYDBiJ0nBETam/pFHZoXFLy+E8kygsJiPDp3F qjEYHaJLDmCW3w5KqF2VDRvw8sv4oz/Cz36G926GKIaUNwYM5kvOYHSIjguOyclJ2yXORagabldd hYsvxp492Lo15F7sMIYtWHfgjjzynb47BmNx0tmlCt2+rtVqvJ9vefOYehoIby9Mwvmnb8KmE3Hi MizToIU6gcFgRKTjNg6e5/P5vCiKrozEMzMzTz/9fyXpBZ7n/ZMVS5IzEB5oXhiBpgjdiZ2DGDyA A116hAxGQ1iy4hah4TeuC23cuPFP/uQxfyvn5Zdj/XoIgjtdR3B+c1q4gAMnQFiLtXuwh65TmNLB 6B3Ydmw0eJ73Xar4GEenpzE1hRdewH/+pzvHX0AmDrtwgZ2Mhwa8MpHBYHSOzgoOSZKoyCiXy95W n/RfV1yBFSsgCFBVn+Hm91eh0sIFLH8Xg9FlOis4ZFm2LIsLsIL6fMxxMAxceqnPnqsxu06hqxIA RRRZ3BqDkQgdX6oESY2ZGb/PLQsch4cfPn46OAvWfbjvKe6p63CdDp2lCGUwEqfHXM495QvejrcP YpCAbMVWCxYTGQxGL9BLLueG4V2hCBCexJMppK43r09wqgwGw0liOUePHJkvszZsQKXiEhwqVBHi Vmz9ffz++3PvT2qqDAbDRWIax29/O3b8l0IBP/0pDh68ofD95y854XE8vgIr3ov3fhafPYIjAK7H 9U2L1DMYjK6RmOAYHHTUhhZFPPoovvSlrSv4QZwziMFBDP49/n7epgkLWGMweoYEBMe99wLAkSMn 0IMbbwQyGWSzdJ0yjOFDOHQJLpknNYz2ak0zGIxYScbG8alP4dVXT/3Upxwfvec9AK7Ftcdw7BiO /QQ/uQ/3HW+12qs1zWAwYiWZpcrSpdi/f2Dp0tlfd7zyjc2nnQbgCI4cwiEAR3F03gkmM3AwGD1E MhrH/v0YHDyyf//sr1ee9GeFK7/FgXsZL/uf0EIhBQaD0TESEBw33ohjx5DN/vjYMdx4I/ClL726 6X9Mn/AvR48c+TF+7H8OW6cwGL1EwrVjAWDNmkv+5eWVqZW/GzpQQMG/T5hcYQwGo1skLDh2v/7T z5z5dx8euvpKXGnAWIIl/v2YgYPB6CUSExwHDx4EsOavv7X3HWd+9607RzByAS6Yt5PipKHGQdMr xYJlWVYrlSk7O1S899ibQy2GJ0+/8wuDzgoOmvtrfHy8Uqm4mvbu3QtdRy43gpE38eYMGmZVa+jE ofom72gJwzCMUDmUuzpUvPfYm0Mthie/d+9e388bvCY9S2cFh6IopVKpWq0qimJ/+NL5L+09ee+1 //WhvR89/5VPrLviS1f8avmvvnryVw+cfgDLgDXAGhxfsnDA6cAUsCbpR8VgdAbf16TH6WzO0VRq dnz7AAC4352w9y3nf+CiZz7z9L9+4OHtN34v/638K+97ZaQ+csr3Tnnmi89wBnfq90999nPPAjjv r8+rX1h/7YLX+Pt5+omX7du3v+9974tlwi+88AKAs88+u6eGivcee3OoBfzkn3rqKZqm+Mknn/RV Ovxfk94mCQewoSEMpN513rsGnkqlMLDqV6sGDg+M7hk9YeYEEIy9MDb66mjqSGrshTEAqSMpAL87 /XcNxovru4v4vm3xDhXvPfbmUIvhyU9OTsY4sWTprIQrFAqZTEYQhGw2W6/X6Ycvnf/S6L7Rk14f 3vvWwwMnDKz89Er8b2ApMARYwCoAwKsAlRUc8Na54XYn/bQYjA7g+5r0OvEVvvehWq3SZMWiKHb0 QgxG/9KPr0nfrKkYDEbv0AOeowwGo99ggmOREqOLVOyjMXqfZARH7B4vuq6Pj4+3P45hGOl0OpVK SZLUO0NR4trkn5ycjHFWhmFIktS+4JAkKZVKpVKp9v8dVVXN5/Ox3KOu65OTk+1/UZ3fz3509/Ih EctKsVjUNK1Wq2UymbjGjOVeyuUyIaRarbY/Wr1epz9jucdYpkQIqdVqxWKxVqu1PxSdlSAIsQxF HxchpH0DIcdx1Wq1Xq9zHNf+UGTOeNnmUPY/Xye+/N0nGcFhP8QYJVeMQ9G3K65xNE1rc5x6vV6r 1eISHLIs8zxfKpXaHy2TyeRyOcS3HVCtVqnsbgdN0+juZvvykeM4Op/2H773O5/Un+1YYILDh1Kp ZP8BbJNyudz+H6u4vrs2cYkhOkgsf9spsQigarVaKpWKxWL7o5VKJY7jMplM+9oBExwxIAiCLMu1 Wi2uLxyJ75+hXq/bq4xYBmz/Hp1Ly/b1F0r74owQksvlqOYS18OPRXBwHEd1jbhmpWla+xOzJ9OJ L3/3SUZwxO7xUiwWYxmtVCrR95PjuDYFR2mOuF71WF4DURTprKrVavujxfvvWC6X21+n0HvkOI7j uFhmVSqV2h/H+f3sR3cvL8wBrINYlhVUc5vNqi8wTZO+5AwXTHAwGIzIMAcwBoMRGSY4GAxGZJjg YDAYkWGCg8FgRIYJDgaDERkmOBhhYSGwDBsmOPoDmu+fRtxGOiuuQgGmabriVuOtQsDoL5jg6AMM w8hmswAymQwNkw1TJciyLF3XM5lMC1f0ju/1g8pkMpVKhcmOxQkTHH1AoVAAoOs6Teugqmo6nc7n 89lsNp/PUx2ENqVSKTvLgyRJgiDQA9rf1Y3qL3TASqVCs4fYx3R8zKk5VN1wDgVAEIS48now+oyk fd4ZocD8kErvTyoj4IiAsE/J5XKCINDgFGc3nuftcD4acGVHzTp/2t0AOIdyXYWxqGAaxwLBsiwa EmqLBo7jqDlTluVisUiLeji70bUM5qyeNC7DG8Zimibt5hqKwkI5FilJSy5GKGhWK2rgWLNmDQCq HYiiCIDGlXIcx/O8rQ7QQFhCCM/zPM/TjBLObjTZBB25XC5TawgNnLXHr9frtJsgCBzHnXHGGfZQ JL54VkbfwYLcFjKKolDJ0qfjM3qW/w9uqhJrTq9urwAAADx0RVh0Y29tbWVudAAgSW1hZ2UgZ2Vu ZXJhdGVkIGJ5IEVTUCBHaG9zdHNjcmlwdCAoZGV2aWNlPXBubXJhdykKo5T0wwAAAABJRU5ErkJg gg== --Multipart_Fri__18_Mar_2005_13_57_13_-0800_TtaZbFDznTSNNNQQ-- From shemminger@osdl.org Fri Mar 18 14:05:59 2005 Received: with ECARTIS (v1.0.0; list netdev); Fri, 18 Mar 2005 14:06:05 -0800 (PST) Received: from smtp.osdl.org (fire.osdl.org [65.172.181.4]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j2IM5xPm015851 for ; Fri, 18 Mar 2005 14:05:59 -0800 Received: from shell0.pdx.osdl.net (fw.osdl.org [65.172.181.6]) by smtp.osdl.org (8.12.8/8.12.8) with ESMTP id j2IM5Uqi004936 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO); Fri, 18 Mar 2005 14:05:30 -0800 Received: from dxpl.pdx.osdl.net (dxpl.pdx.osdl.net [172.20.1.103]) by shell0.pdx.osdl.net (8.13.1/8.11.6) with ESMTP id j2IM5T7H022520; Fri, 18 Mar 2005 14:05:29 -0800 Date: Fri, 18 Mar 2005 14:05:47 -0800 From: Stephen Hemminger To: "David S. Miller" Cc: "Marcelo W. Tosatti" , netdev@oss.sgi.com Subject: Re: [PATCH] TCP BIC not binary searching correctly Message-ID: <20050318140547.1ca66106@dxpl.pdx.osdl.net> In-Reply-To: <20050318135713.1171df83@dxpl.pdx.osdl.net> References: <20050318135713.1171df83@dxpl.pdx.osdl.net> Organization: Open Source Development Lab X-Mailer: Sylpheed-Claws 1.0.1 (GTK+ 1.2.10; x86_64-unknown-linux-gnu) X-Face: &@E+xe?c%:&e4D{>f1O<&U>2qwRREG5!}7R4;D<"NO^UI2mJ[eEOA2*3>(`Th.yP,VDPo9$ /`~cw![cmj~~jWe?AHY7D1S+\}5brN0k*NE?pPh_'_d>6;XGG[\KDRViCfumZT3@[ Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Received-SPF: pass (domain of shemminger@osdl.org designates 65.172.181.6 as permitted sender) X-MIMEDefang-Filter: osdl$Revision: 1.105 $ X-Scanned-By: MIMEDefang 2.36 X-Virus-Scanned: ClamAV 0.83/772/Fri Mar 18 00:59:17 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 332 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: shemminger@osdl.org Precedence: bulk X-list: netdev Content-Length: 872 Lines: 23 2.4 version of same fix as 2.6.11. The problem is that BIC is supposed to reset the cwnd to the last loss value rather than ssthresh when loss is detected. The correct code (from the BIC TCP code for Web100) is in this patch. 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 2005-03-18 14:03:44 -08:00 +++ b/net/ipv4/tcp_input.c 2005-03-18 14:03:44 -08:00 @@ -1642,7 +1642,10 @@ static void tcp_undo_cwr(struct tcp_opt *tp, int undo) { if (tp->prior_ssthresh) { - tp->snd_cwnd = max(tp->snd_cwnd, tp->snd_ssthresh<<1); + if (tcp_is_bic(tp)) + tp->snd_cwnd = max(tp->snd_cwnd, tp->bictcp.last_max_cwnd); + else + tp->snd_cwnd = max(tp->snd_cwnd, tp->snd_ssthresh<<1); if (undo && tp->prior_ssthresh > tp->snd_ssthresh) { tp->snd_ssthresh = tp->prior_ssthresh; From romieu@fr.zoreil.com Fri Mar 18 14:40:19 2005 Received: with ECARTIS (v1.0.0; list netdev); Fri, 18 Mar 2005 14:40:26 -0800 (PST) Received: from fr.zoreil.com (electric-eye.fr.zoreil.com [213.41.134.224]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j2IMeIJu017238 for ; Fri, 18 Mar 2005 14:40:19 -0800 Received: from electric-eye.fr.zoreil.com (localhost.localdomain [127.0.0.1]) by fr.zoreil.com (8.13.1/8.12.1) with ESMTP id j2IMdjXH026203; Fri, 18 Mar 2005 23:39:45 +0100 Received: (from romieu@localhost) by electric-eye.fr.zoreil.com (8.13.1/8.13.1/Submit) id j2IMddYh026202; Fri, 18 Mar 2005 23:39:39 +0100 Date: Fri, 18 Mar 2005 23:39:39 +0100 From: Francois Romieu To: Alexander Nyberg Cc: jgarzik@pobox.com, netdev@oss.sgi.com Subject: Re: Reproducible panics with tulip Message-ID: <20050318223939.GB24509@electric-eye.fr.zoreil.com> References: <1111178167.1147.9.camel@localhost.localdomain> <20050318215229.GA24509@electric-eye.fr.zoreil.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20050318215229.GA24509@electric-eye.fr.zoreil.com> User-Agent: Mutt/1.4.1i X-Organisation: Land of Sunshine Inc. X-Virus-Scanned: ClamAV 0.83/772/Fri Mar 18 00:59:17 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 333 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: romieu@fr.zoreil.com Precedence: bulk X-list: netdev Content-Length: 1091 Lines: 40 Francois Romieu : > Alexander Nyberg : > [...] > > Warning: kfree_skb on hard IRQ c46c3950 > > ... however this one may stick. /me slaps his head Nope, it should go away with netconsole: tulip_rx fails an allocation, netconsole tries to printk in IRQ context and issues: -> netpoll_send_udp -> find_skb -> zap_completion_queue -> __kfree_skb <- whence the warning. So, please increase /proc/sys/vm/min_free_kbytes as a start and, at your option: - disable netconsole - apply patch below: zap_completion_queue can be called in any context through netpoll_send_udp. Signed-off-by: Francois Romieu diff -puN net/core/netpoll.c~netconsole-000 net/core/netpoll.c --- a/net/core/netpoll.c~netconsole-000 2005-03-18 23:29:28.499641348 +0100 +++ b/net/core/netpoll.c 2005-03-18 23:33:13.856959994 +0100 @@ -142,7 +142,7 @@ static void zap_completion_queue(void) while (clist != NULL) { struct sk_buff *skb = clist; clist = clist->next; - __kfree_skb(skb); + dev_kfree_skb_any(skb); } } _ From afleming@freescale.com Fri Mar 18 15:14:25 2005 Received: with ECARTIS (v1.0.0; list netdev); Fri, 18 Mar 2005 15:14:30 -0800 (PST) Received: from az33egw02.freescale.net (az33egw02.freescale.net [192.88.158.103]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j2INEO8X019413 for ; Fri, 18 Mar 2005 15:14:25 -0800 Received: from az33smr01.freescale.net (az33smr01.freescale.net [10.64.34.199]) by az33egw02.freescale.net (8.12.11/az33egw02) with ESMTP id j2INFqpL011355; Fri, 18 Mar 2005 16:15:57 -0700 (MST) Received: from [10.82.16.201] ([10.82.16.201]) by az33smr01.freescale.net (8.13.1/8.13.0) with ESMTP id j2INFqq4028327; Fri, 18 Mar 2005 17:15:52 -0600 (CST) In-Reply-To: <423734FB.40101@katalix.com> References: <1107b64b01fb8e9a6c84359bb56881a6@freescale.com> <1110334456.32556.21.camel@gaston> <20050308194229.41c23707.davem@davemloft.net> <1110340214.32524.32.camel@gaston> <57a429f8eb807987d88b06129861d507@freescale.com> <4230D1AC.5070506@katalix.com> <423734FB.40101@katalix.com> Mime-Version: 1.0 (Apple Message framework v619.2) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <1925682251c3a74c9c349e15cb44d48a@freescale.com> Content-Transfer-Encoding: 7bit Cc: netdev@oss.sgi.com, "David S. Miller" , linuxppc-embedded@ozlabs.org, Benjamin Herrenschmidt From: Andy Fleming Subject: Re: RFC: PHY Abstraction Layer II Date: Fri, 18 Mar 2005 17:14:19 -0600 To: James Chapman X-Mailer: Apple Mail (2.619.2) X-Virus-Scanned: ClamAV 0.83/772/Fri Mar 18 00:59:17 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 335 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: afleming@freescale.com Precedence: bulk X-list: netdev Content-Length: 8135 Lines: 209 On Mar 15, 2005, at 13:18, James Chapman wrote: > Hi Andy, > > I finally found some time to review your phy abstraction code. > > I haven't reviewed the low level MII functions; I focused mostly on > its API to the net driver and whether it has the necessary hooks to > handle the various hardware that I know. > > General comment: nice, clean code. No serious style or Linux kernel > core API issues that I can see. Thank you > > Specific comments follow. > > - It isn't obvious what has to be done in net drivers to hook up this > code. Consider writing a Documentation/networking/phy.txt to > describe typical net driver code changes needed. Oh, definitely, that's on my plate. > > - If a net driver is modified to use your new code, should it use any > functions from mii.c at all? I guess I'm unclear about the > relationship with mii.c. Well, I didn't want to interfere with mii.c, since so many drivers use it already. This code is designed to be separate to not break anything, but also to serve as a superset of the mii.c functionality. So I think the PHY code should add the functionality provided by these functions: int mii_ethtool_sset(struct mii_if_info *mii, struct ethtool_cmd *ecmd) int mii_ethtool_gset(struct mii_if_info *mii, struct ethtool_cmd *ecmd) int generic_mii_ioctl(struct mii_if_info *mii_if, struct mii_ioctl_data *mii_data, int cmd, unsigned int *duplex_chg_out) While these functions are already handled by the existing PHY code: unsigned int mii_check_media (struct mii_if_info *mii, unsigned int ok_to_print, unsigned int init_media) // determines duplex/speed int mii_link_ok (struct mii_if_info *mii) // returns link status int mii_nway_restart (struct mii_if_info *mii) // does this do anything? void mii_check_link (struct mii_if_info *mii) // reads link, and updates carrier > > - netif_carrier_on()/off() calls are done by mii.c on link state > changes. Consider doing the same inside your phy code. That's reasonable. > > - Some hardware does not use a separate irq for phy but instead > indicates phy events via the ethernet chip's irq. > > There are registered phy_driver callbacks to handle things like > read/clear/ack interrupt status. But if my ethernet device's phy > interrupt is effectively one or more bits in the ethernet chip's > status register (where there is no separate phy interrupt), how > would this hook into your phy code? For example, in the interrupt > handler of mv643xx_eth, we check status bits that indicate link > state change from the same register that indicates rx/tx packet > events. > > Also, NAPI drivers will disable irqs and poll for tx/rx while there > is work to do. If they have a combined tx/rx/phy interrupt then does > this pose other issues for hooking up the new phy code? > > - What determines whether the phy driver uses interrupts or polling? For handling such interrupts, there are two options I can see: 1) Let the PHY code share the interrupt, and it will handle it, then the enet driver can clear it. 2) Have the enet code handle the interrupt. This is more difficult, in that it is absolutely verboten to access the PHYs from interrupt time. The reason I did this is to allow for PHY read/write mechanisms which block until an interrupt signals the operation is complete. 3) Set the PHY to poll. This is simple, just set phydev->irq to -1 before you call phy_start(). I will make sure to document this. > > - The callback registered in phy_connect() is called when phy link > changes are detected. It is passed a struct device*. How about > letting the net driver register its struct net_device* which would > be passed back in the callback? It is likely that the callback will > need access to net driver data anyway. Some net drivers will need to > reconfigure their ethernet chip for duplex/speed setting changes, > for example. Passing in the struct net_device* also lets the phy > code call netif_xxx() functions such as netif_carrier_on()/off() > mentioned earlier as well as the netif_msg_xxx message control > macros. Ok. The reason I didn't do this (actually, I did, and then changed it) was to allow drivers which weren't net devices to use the code. I didn't have a particular use in mind. If no one thinks that would be useful (I'm not sure I do), then I will change it back. > > - The callback function is only called by the phy timer poll as > far as I can tell. Shouldn't it also be called in the phy interrupt > handler when link state changes? The phy interrupt is a bit awkward. For the reasons mentioned above, I can't call phy read/write functions from interrupt context. The lock on phydev->state has the same issue. So the interrupt handler just disables the interrupt (because otherwise the PHY keeps generating it), and schedules a task to clear the interrupt, and tell the state machine there's a change. That task just sets phydev->state to CHANGELINK. When interrupts are being used, this is the only way state gets updated. When interrupts are off, this state gets hit every other interval (2 seconds, total). > > - Have all phy printk messages controlled by the netif_msg_ macros. Ok > > - Many drivers use mii.c to implement ethtool functions. I don't see > equivalents in your new code. See above...way above. > > - Does include/linux/phy.h represent a public API for use by net > drivers or is it also the internal API used by various C files in > your phy code? It seems to contain some data/defs that are > private to the implementation. Separate some members of struct > phy_device into public and private parts and move the private bits > into separate files away from include/linux? Hmm... So the fields I see in phy_device which are internal are: int link_timeout; struct work_struct phy_queue; struct timer_list phy_timer; I'm not convinced it's worth creating a new file, and adding a new level of indirection for these three fields. However, I do see a couple function prototypes which probably could move into the C files, since they are internal functions: void phy_change(void *data); void phy_timer(unsigned long data); The rest of the functions and fields are public. Especially in the early stages of its existence, when I would hate to lock someone out of using the code in a certain way before it's clear what the best ways to use it are. > > - phy_sanitize_settings() / phy_force_reduction() > > I don't understand why this is done. Are you trying to handle > link negotiation in software for phy chips that can't autoneg? This code is there for the case where someone manually sets their controller to a certain speed/duplex setting which doesn't work. The sanitize function makes sure that the next highest setting supported by the PHY is chosen, and the force function is used to choose a new setting if the selected setting did not achieve a link. I added this functionality to enable recoverability (eg - when I change the setting on an NFS-rooted system, and choose one that doesn't work with the network I am on. This way, the network will eventually come up again) > > Other minor notes:- > > - Rename register_mdiobus() --> mdiobus_register()? Ok > > - I personally try to avoid listing parameter names in function header > comment blocks; they seldom contain useful info and they're a > maintenance overhead. If it would be useful for docbook-generated > documentation then ok, but your comment blocks don't follow that > format anyway. Yeah. I think I got stuck in the mode, early on, when I was writing some functions for which their parameters weren't intuitively obvious. For consistency, I ended up with a lot of functions with: phydev: The phy device Which is really just a waste of space. I will attempt to prune out the ones I feel are obvious without the comment. > > I hope this was useful. It was, indeed. I will post an updated patch early next week. Andy From chrisw@osdl.org Fri Mar 18 15:36:45 2005 Received: with ECARTIS (v1.0.0; list netdev); Fri, 18 Mar 2005 15:36:50 -0800 (PST) Received: from smtp.osdl.org (fire.osdl.org [65.172.181.4]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j2INaiI8020630 for ; Fri, 18 Mar 2005 15:36:45 -0800 Received: from shell0.pdx.osdl.net (fw.osdl.org [65.172.181.6]) by smtp.osdl.org (8.12.8/8.12.8) with ESMTP id j2INabqi012062 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO); Fri, 18 Mar 2005 15:36:38 -0800 Received: from shell0.pdx.osdl.net (localhost [127.0.0.1]) by shell0.pdx.osdl.net (8.13.1/8.11.6) with ESMTP id j2INabNb026933; Fri, 18 Mar 2005 15:36:37 -0800 Received: (from chrisw@localhost) by shell0.pdx.osdl.net (8.13.1/8.13.1/Submit) id j2INabcA026932; Fri, 18 Mar 2005 15:36:37 -0800 Date: Fri, 18 Mar 2005 15:36:37 -0800 From: Chris Wright To: davem@davemloft.net Cc: netdev@oss.sgi.com Subject: [PATCH] remove unused netlink NL_EMULATE_DEV code Message-ID: <20050318233637.GS5389@shell0.pdx.osdl.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.5.6i Received-SPF: pass (domain of chrisw@osdl.org designates 65.172.181.6 as permitted sender) X-MIMEDefang-Filter: osdl$Revision: 1.105 $ X-Scanned-By: MIMEDefang 2.36 X-Virus-Scanned: ClamAV 0.83/772/Fri Mar 18 00:59:17 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 336 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: chrisw@osdl.org Precedence: bulk X-list: netdev Content-Length: 2012 Lines: 71 Now that netlink_attach() has been removed, the NL_EMULATE_DEV handler functions can't ever be set. So let's rip them out too, because what's left behind can't be used at all. Signed-off-by: Chris Wright net/netlink/af_netlink.c | 24 +----------------------- 1 files changed, 1 insertion(+), 23 deletions(-) ===== net/netlink/af_netlink.c 1.71 vs edited ===== --- 1.71/net/netlink/af_netlink.c 2005-03-14 21:27:59 -08:00 +++ edited/net/netlink/af_netlink.c 2005-03-18 11:57:32 -08:00 @@ -55,10 +55,6 @@ #define Nprintk(a...) -#if defined(CONFIG_NETLINK_DEV) || defined(CONFIG_NETLINK_DEV_MODULE) -#define NL_EMULATE_DEV -#endif - struct netlink_sock { /* struct sock has to be the first member of netlink_sock */ struct sock sk; @@ -67,7 +63,6 @@ struct netlink_sock { u32 dst_pid; unsigned int dst_groups; unsigned long state; - int (*handler)(int unit, struct sk_buff *skb); wait_queue_head_t wait; struct netlink_callback *cb; spinlock_t cb_lock; @@ -593,10 +588,6 @@ int netlink_attachskb(struct sock *sk, s nlk = nlk_sk(sk); -#ifdef NL_EMULATE_DEV - if (nlk->handler) - return 0; -#endif if (atomic_read(&sk->sk_rmem_alloc) > sk->sk_rcvbuf || test_bit(0, &nlk->state)) { DECLARE_WAITQUEUE(wait, current); @@ -636,14 +627,6 @@ int netlink_sendskb(struct sock *sk, str int len = skb->len; nlk = nlk_sk(sk); -#ifdef NL_EMULATE_DEV - if (nlk->handler) { - skb_orphan(skb); - len = nlk->handler(protocol, skb); - sock_put(sk); - return len; - } -#endif skb_queue_tail(&sk->sk_receive_queue, skb); sk->sk_data_ready(sk, len); @@ -708,12 +691,7 @@ retry: static __inline__ int netlink_broadcast_deliver(struct sock *sk, struct sk_buff *skb) { struct netlink_sock *nlk = nlk_sk(sk); -#ifdef NL_EMULATE_DEV - if (nlk->handler) { - nlk->handler(sk->sk_protocol, skb); - return 0; - } else -#endif + if (atomic_read(&sk->sk_rmem_alloc) <= sk->sk_rcvbuf && !test_bit(0, &nlk->state)) { skb_set_owner_r(skb, sk); From maxk@qualcomm.com Fri Mar 18 16:10:28 2005 Received: with ECARTIS (v1.0.0; list netdev); Fri, 18 Mar 2005 16:10:33 -0800 (PST) Received: from numenor.qualcomm.com (numenor.qualcomm.com [129.46.51.58]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j2J0A76C024635 for ; Fri, 18 Mar 2005 16:10:28 -0800 Received: from magus.qualcomm.com (magus.qualcomm.com [129.46.61.148]) by numenor.qualcomm.com (8.12.10/8.12.5/1.0) with ESMTP id j2J09Me2020821 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Fri, 18 Mar 2005 16:09:22 -0800 (PST) Received: from [129.46.90.158] (workie.qualcomm.com [129.46.90.158]) by magus.qualcomm.com (8.12.10/8.12.5/1.0) with ESMTP id j2J09IfX018666; Fri, 18 Mar 2005 16:09:19 -0800 (PST) Message-ID: <423B6DAE.9050803@qualcomm.com> Date: Fri, 18 Mar 2005 16:09:18 -0800 From: Max Krasnyansky User-Agent: Mozilla Thunderbird 0.9 (X11/20041127) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Chris Wright CC: davem@davemloft.net, netdev@oss.sgi.com Subject: Re: [PATCH] remove unused netlink NL_EMULATE_DEV code References: <20050318233637.GS5389@shell0.pdx.osdl.net> In-Reply-To: <20050318233637.GS5389@shell0.pdx.osdl.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-PMX-Version: 4.7.0.111621 X-Virus-Scanned: ClamAV 0.83/772/Fri Mar 18 00:59:17 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 337 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: maxk@qualcomm.com Precedence: bulk X-list: netdev Content-Length: 263 Lines: 9 Hi Chris, Why don't you kill Ethertap completely while you're at it. Ethertap needs "Netlink device emulation" stuff. And this whole thing has been marked OBSOLETE for more than two years now. Most projects seem to have switched to TUN/TAP long time ago. Max From shemminger@osdl.org Fri Mar 18 16:30:52 2005 Received: with ECARTIS (v1.0.0; list netdev); Fri, 18 Mar 2005 16:31:02 -0800 (PST) Received: from smtp.osdl.org (fire.osdl.org [65.172.181.4]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j2J0UWgE029086 for ; Fri, 18 Mar 2005 16:30:52 -0800 Received: from shell0.pdx.osdl.net (fw.osdl.org [65.172.181.6]) by smtp.osdl.org (8.12.8/8.12.8) with ESMTP id j2J0UMqi016958 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO); Fri, 18 Mar 2005 16:30:22 -0800 Received: from dxpl.pdx.osdl.net (dxpl.pdx.osdl.net [172.20.1.103]) by shell0.pdx.osdl.net (8.13.1/8.11.6) with ESMTP id j2J0UMdT029546; Fri, 18 Mar 2005 16:30:22 -0800 Date: Fri, 18 Mar 2005 16:26:26 -0800 From: Stephen Hemminger To: Andrew Morton , "David S. Miller" Cc: netdev@oss.sgi.com Subject: [PATCH 4/5] TCP Vegas support Message-ID: <20050318162626.3eab2b8b@dxpl.pdx.osdl.net> Organization: Open Source Development Lab X-Mailer: Sylpheed-Claws 1.0.1 (GTK+ 1.2.10; x86_64-unknown-linux-gnu) X-Face: &@E+xe?c%:&e4D{>f1O<&U>2qwRREG5!}7R4;D<"NO^UI2mJ[eEOA2*3>(`Th.yP,VDPo9$ /`~cw![cmj~~jWe?AHY7D1S+\}5brN0k*NE?pPh_'_d>6;XGG[\KDRViCfumZT3@[ Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Received-SPF: pass (domain of shemminger@osdl.org designates 65.172.181.6 as permitted sender) X-MIMEDefang-Filter: osdl$Revision: 1.105 $ X-Scanned-By: MIMEDefang 2.36 X-Virus-Scanned: ClamAV 0.83/772/Fri Mar 18 00:59:17 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 339 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: shemminger@osdl.org Precedence: bulk X-list: netdev Content-Length: 14951 Lines: 451 Add TCP Vegas support back as a configurable algorithm. Since it has issues that make it perform poorly in many environments make it default to off. Signed-off-by: Stephen Hemminger diff -Nru a/net/ipv4/Kconfig b/net/ipv4/Kconfig --- a/net/ipv4/Kconfig 2005-03-18 16:11:05 -08:00 +++ b/net/ipv4/Kconfig 2005-03-18 16:11:05 -08:00 @@ -396,6 +396,16 @@ TCP Westwood+ significantly increases fairness wrt TCP Reno in wired networks and throughput over wireless links. +config TCP_CONG_VEGAS + tristate "TCP Vegas" + default n + ---help--- + TCP Vegas is a sender-side only change to TCP that anticipates + the onset of congestion by estimating the bandwidth. TCP Vegas + adjusts the sending rate by modifying the congestion + window. TCP Vegas should provide less packet loss, but it is + not as aggressive as TCP Reno. + endmenu source "net/ipv4/ipvs/Kconfig" diff -Nru a/net/ipv4/Makefile b/net/ipv4/Makefile --- a/net/ipv4/Makefile 2005-03-18 16:11:05 -08:00 +++ b/net/ipv4/Makefile 2005-03-18 16:11:05 -08:00 @@ -26,6 +26,7 @@ obj-$(CONFIG_IP_TCPDIAG) += tcp_diag.o obj-$(CONFIG_TCP_CONG_BIC) += tcp_bic.o obj-$(CONFIG_TCP_CONG_WESTWOOD) += tcp_westwood.o +obj-$(CONFIG_TCP_CONG_VEGAS) += tcp_vegas.o obj-$(CONFIG_XFRM) += xfrm4_policy.o xfrm4_state.o xfrm4_input.o \ xfrm4_output.o diff -Nru a/net/ipv4/tcp_vegas.c b/net/ipv4/tcp_vegas.c --- /dev/null Wed Dec 31 16:00:00 196900 +++ b/net/ipv4/tcp_vegas.c 2005-03-18 16:11:05 -08:00 @@ -0,0 +1,409 @@ +/* + * TCP Vegas congestion control + * + * This is based on the congestion detection/avoidance scheme described in + * Lawrence S. Brakmo and Larry L. Peterson. + * "TCP Vegas: End to end congestion avoidance on a global internet." + * IEEE Journal on Selected Areas in Communication, 13(8):1465--1480, + * October 1995. Available from: + * ftp://ftp.cs.arizona.edu/xkernel/Papers/jsac.ps + * + * See http://www.cs.arizona.edu/xkernel/ for their implementation. + * The main aspects that distinguish this implementation from the + * Arizona Vegas implementation are: + * o We do not change the loss detection or recovery mechanisms of + * Linux in any way. Linux already recovers from losses quite well, + * using fine-grained timers, NewReno, and FACK. + * o To avoid the performance penalty imposed by increasing cwnd + * only every-other RTT during slow start, we increase during + * every RTT during slow start, just like Reno. + * o Largely to allow continuous cwnd growth during slow start, + * we use the rate at which ACKs come back as the "actual" + * rate, rather than the rate at which data is sent. + * o To speed convergence to the right rate, we set the cwnd + * to achieve the right ("actual") rate when we exit slow start. + * o To filter out the noise caused by delayed ACKs, we use the + * minimum RTT sample observed during the last RTT to calculate + * the actual rate. + * o When the sender re-starts from idle, it waits until it has + * received ACKs for an entire flight of new data before making + * a cwnd adjustment decision. The original Vegas implementation + * assumed senders never went idle. + */ + +#include +#include +#include +#include +#include + +#include + +/* Default values of the Vegas variables, in fixed-point representation + * with V_PARAM_SHIFT bits to the right of the binary point. + */ +#define V_PARAM_SHIFT 1 +static int alpha = 1<doing_vegas_now = 1; + + /* Set the beginning of the next send window. */ + vegas->beg_snd_nxt = tp->snd_nxt; + + vegas->cntRTT = 0; + vegas->minRTT = 0x7fffffff; +} + +/* Stop taking Vegas samples for now. */ +static inline void tcp_vegas_disable(struct tcp_sock *tp) +{ + struct vegas_ca *vegas = tcp_ca(tp); + + vegas->doing_vegas_now = 0; +} + +static void tcp_vegas_start(struct tcp_sock *tp) +{ + struct vegas_ca *vegas = tcp_ca(tp); + + vegas->baseRTT = 0x7fffffff; + tcp_vegas_enable(tp); +} + +/* Do RTT sampling needed for Vegas. + * Basically we: + * o min-filter RTT samples from within an RTT to get the current + * propagation delay + queuing delay (we are min-filtering to try to + * avoid the effects of delayed ACKs) + * o min-filter RTT samples from a much longer window (forever for now) + * to find the propagation delay (baseRTT) + */ +static void tcp_vegas_rtt_calc(struct tcp_sock *tp, u32 rtt) +{ + struct vegas_ca *vegas = tcp_ca(tp); + u32 vrtt = rtt + 1; /* Never allow zero rtt or baseRTT */ + + /* Filter to find propagation delay: */ + if (vrtt < vegas->baseRTT) + vegas->baseRTT = vrtt; + + /* Find the min RTT during the last RTT to find + * the current prop. delay + queuing delay: + */ + vegas->minRTT = min(vegas->minRTT, vrtt); + vegas->cntRTT++; +} + +static void tcp_vegas_ca_state(struct tcp_sock *tp, u8 ca_state) +{ + if (ca_state == TCP_CA_Open) + tcp_vegas_enable(tp); + else + tcp_vegas_disable(tp); +} + +/* + * If the connection is idle and we are restarting, + * then we don't want to do any Vegas calculations + * until we get fresh RTT samples. So when we + * restart, we reset our Vegas state to a clean + * slate. After we get acks for this flight of + * packets, _then_ we can make Vegas calculations + * again. + */ +static void tcp_vegas_cwnd_event(struct tcp_sock *tp, enum tcp_ca_event event) +{ + if (event == CA_EVENT_CWND_RESTART || event == CA_EVENT_TX_START) + tcp_vegas_enable(tp); +} + +static void tcp_vegas_cong_avoid(struct tcp_sock *tp, u32 ack, + u32 seq_rtt, u32 in_flight, int flag) +{ + struct vegas_ca *vegas = tcp_ca(tp); + + if (!vegas->doing_vegas_now) { + tcp_reno_cong_avoid(tp, ack, seq_rtt, in_flight, flag); + return; + } + + /* The key players are v_beg_snd_una and v_beg_snd_nxt. + * + * These are so named because they represent the approximate values + * of snd_una and snd_nxt at the beginning of the current RTT. More + * precisely, they represent the amount of data sent during the RTT. + * At the end of the RTT, when we receive an ACK for v_beg_snd_nxt, + * we will calculate that (v_beg_snd_nxt - v_beg_snd_una) outstanding + * bytes of data have been ACKed during the course of the RTT, giving + * an "actual" rate of: + * + * (v_beg_snd_nxt - v_beg_snd_una) / (rtt duration) + * + * Unfortunately, v_beg_snd_una is not exactly equal to snd_una, + * because delayed ACKs can cover more than one segment, so they + * don't line up nicely with the boundaries of RTTs. + * + * Another unfortunate fact of life is that delayed ACKs delay the + * advance of the left edge of our send window, so that the number + * of bytes we send in an RTT is often less than our cwnd will allow. + * So we keep track of our cwnd separately, in v_beg_snd_cwnd. + */ + + if (after(ack, vegas->beg_snd_nxt)) { + /* Do the Vegas once-per-RTT cwnd adjustment. */ + u32 old_wnd, old_snd_cwnd; + + + /* Here old_wnd is essentially the window of data that was + * sent during the previous RTT, and has all + * been acknowledged in the course of the RTT that ended + * with the ACK we just received. Likewise, old_snd_cwnd + * is the cwnd during the previous RTT. + */ + old_wnd = (vegas->beg_snd_nxt - vegas->beg_snd_una) / + tp->mss_cache_std; + old_snd_cwnd = vegas->beg_snd_cwnd; + + /* Save the extent of the current window so we can use this + * at the end of the next RTT. + */ + vegas->beg_snd_una = vegas->beg_snd_nxt; + vegas->beg_snd_nxt = tp->snd_nxt; + vegas->beg_snd_cwnd = tp->snd_cwnd; + + /* Take into account the current RTT sample too, to + * decrease the impact of delayed acks. This double counts + * this sample since we count it for the next window as well, + * but that's not too awful, since we're taking the min, + * rather than averaging. + */ + tcp_vegas_rtt_calc(tp, seq_rtt); + + /* We do the Vegas calculations only if we got enough RTT + * samples that we can be reasonably sure that we got + * at least one RTT sample that wasn't from a delayed ACK. + * If we only had 2 samples total, + * then that means we're getting only 1 ACK per RTT, which + * means they're almost certainly delayed ACKs. + * If we have 3 samples, we should be OK. + */ + + if (vegas->cntRTT <= 2) { + /* We don't have enough RTT samples to do the Vegas + * calculation, so we'll behave like Reno. + */ + if (tp->snd_cwnd > tp->snd_ssthresh) + tp->snd_cwnd++; + } else { + u32 rtt, target_cwnd, diff; + + /* We have enough RTT samples, so, using the Vegas + * algorithm, we determine if we should increase or + * decrease cwnd, and by how much. + */ + + /* Pluck out the RTT we are using for the Vegas + * calculations. This is the min RTT seen during the + * last RTT. Taking the min filters out the effects + * of delayed ACKs, at the cost of noticing congestion + * a bit later. + */ + rtt = vegas->minRTT; + + /* Calculate the cwnd we should have, if we weren't + * going too fast. + * + * This is: + * (actual rate in segments) * baseRTT + * We keep it as a fixed point number with + * V_PARAM_SHIFT bits to the right of the binary point. + */ + target_cwnd = ((old_wnd * vegas->baseRTT) + << V_PARAM_SHIFT) / rtt; + + /* Calculate the difference between the window we had, + * and the window we would like to have. This quantity + * is the "Diff" from the Arizona Vegas papers. + * + * Again, this is a fixed point number with + * V_PARAM_SHIFT bits to the right of the binary + * point. + */ + diff = (old_wnd << V_PARAM_SHIFT) - target_cwnd; + + if (tp->snd_cwnd < tp->snd_ssthresh) { + /* Slow start. */ + if (diff > gamma) { + /* Going too fast. Time to slow down + * and switch to congestion avoidance. + */ + tp->snd_ssthresh = 2; + + /* Set cwnd to match the actual rate + * exactly: + * cwnd = (actual rate) * baseRTT + * Then we add 1 because the integer + * truncation robs us of full link + * utilization. + */ + tp->snd_cwnd = min(tp->snd_cwnd, + (target_cwnd >> + V_PARAM_SHIFT)+1); + + } + } else { + /* Congestion avoidance. */ + u32 next_snd_cwnd; + + /* Figure out where we would like cwnd + * to be. + */ + if (diff > beta) { + /* The old window was too fast, so + * we slow down. + */ + next_snd_cwnd = old_snd_cwnd - 1; + } else if (diff < alpha) { + /* We don't have enough extra packets + * in the network, so speed up. + */ + next_snd_cwnd = old_snd_cwnd + 1; + } else { + /* Sending just as fast as we + * should be. + */ + next_snd_cwnd = old_snd_cwnd; + } + + /* Adjust cwnd upward or downward, toward the + * desired value. + */ + if (next_snd_cwnd > tp->snd_cwnd) + tp->snd_cwnd++; + else if (next_snd_cwnd < tp->snd_cwnd) + tp->snd_cwnd--; + } + } + + /* Wipe the slate clean for the next RTT. */ + vegas->cntRTT = 0; + vegas->minRTT = 0x7fffffff; + } + + /* The following code is executed for every ack we receive, + * except for conditions checked in should_advance_cwnd() + * before the call to tcp_cong_avoid(). Mainly this means that + * we only execute this code if the ack actually acked some + * data. + */ + + /* If we are in slow start, increase our cwnd in response to this ACK. + * (If we are not in slow start then we are in congestion avoidance, + * and adjust our congestion window only once per RTT. See the code + * above.) + */ + if (tp->snd_cwnd <= tp->snd_ssthresh) + tp->snd_cwnd++; + + /* to keep cwnd from growing without bound */ + tp->snd_cwnd = min_t(u32, tp->snd_cwnd, tp->snd_cwnd_clamp); + + /* Make sure that we are never so timid as to reduce our cwnd below + * 2 MSS. + * + * Going below 2 MSS would risk huge delayed ACKs from our receiver. + */ + tp->snd_cwnd = max(tp->snd_cwnd, 2U); +} + +/* Extract info for Tcp socket info provided via netlink. */ +static void tcp_vegas_get_info(struct tcp_sock *tp, u32 ext, + struct sk_buff *skb) +{ + if (ext & (1<<(TCPDIAG_VEGASINFO-1))) { + struct tcpvegas_info *info + = tcpdiag_put(skb, TCPDIAG_VEGASINFO, sizeof(*info)); + if (info) { + struct vegas_ca *ca = tcp_ca(tp); + info->tcpv_enabled = ca->doing_vegas_now; + info->tcpv_rttcnt = ca->cntRTT; + info->tcpv_rtt = jiffies_to_usecs(ca->baseRTT); + info->tcpv_minrtt = jiffies_to_usecs(ca->minRTT); + } + } +} + +static struct tcp_ca_type tcp_vegas = { + .start = tcp_vegas_start, + .ssthresh = tcp_reno_ssthresh, + .min_cwnd = tcp_reno_cwnd_min, + .cong_avoid = tcp_vegas_cong_avoid, + .rtt_sample = tcp_vegas_rtt_calc, + .set_state = tcp_vegas_ca_state, + .cwnd_event = tcp_vegas_cwnd_event, + .get_info = tcp_vegas_get_info, + + .owner = THIS_MODULE, + .name = "vegas", +}; + +static int __init tcp_vegas_init(void) +{ + BUG_ON(sizeof(struct vegas_ca) > TCP_CA_PRIV_SIZE); + tcp_ca_register(&tcp_vegas); + return 0; +} + +static void __exit tcp_vegas_exit(void) +{ + tcp_ca_unregister(&tcp_vegas); +} + +module_init(tcp_vegas_init); +module_exit(tcp_vegas_exit); + +MODULE_AUTHOR("Stephen Hemminger"); +MODULE_LICENSE("GPL"); +MODULE_DESCRIPTION("TCP Vegas"); From shemminger@osdl.org Fri Mar 18 16:30:52 2005 Received: with ECARTIS (v1.0.0; list netdev); Fri, 18 Mar 2005 16:30:59 -0800 (PST) Received: from smtp.osdl.org (fire.osdl.org [65.172.181.4]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j2J0UWi5029085 for ; Fri, 18 Mar 2005 16:30:52 -0800 Received: from shell0.pdx.osdl.net (fw.osdl.org [65.172.181.6]) by smtp.osdl.org (8.12.8/8.12.8) with ESMTP id j2J0UMqi016956 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO); Fri, 18 Mar 2005 16:30:22 -0800 Received: from dxpl.pdx.osdl.net (dxpl.pdx.osdl.net [172.20.1.103]) by shell0.pdx.osdl.net (8.13.1/8.11.6) with ESMTP id j2J0UMTA029543; Fri, 18 Mar 2005 16:30:22 -0800 Date: Fri, 18 Mar 2005 16:24:12 -0800 From: Stephen Hemminger To: Andrew Morton , "David S. Miller" Cc: netdev@oss.sgi.com Subject: [PATCH 3/5] TCP Westwood+ support Message-ID: <20050318162412.189ccf9c@dxpl.pdx.osdl.net> Organization: Open Source Development Lab X-Mailer: Sylpheed-Claws 1.0.1 (GTK+ 1.2.10; x86_64-unknown-linux-gnu) X-Face: &@E+xe?c%:&e4D{>f1O<&U>2qwRREG5!}7R4;D<"NO^UI2mJ[eEOA2*3>(`Th.yP,VDPo9$ /`~cw![cmj~~jWe?AHY7D1S+\}5brN0k*NE?pPh_'_d>6;XGG[\KDRViCfumZT3@[ Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Received-SPF: pass (domain of shemminger@osdl.org designates 65.172.181.6 as permitted sender) X-MIMEDefang-Filter: osdl$Revision: 1.105 $ X-Scanned-By: MIMEDefang 2.36 X-Virus-Scanned: ClamAV 0.83/772/Fri Mar 18 00:59:17 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 338 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: shemminger@osdl.org Precedence: bulk X-list: netdev Content-Length: 10663 Lines: 394 Add TCP Westwood+ support back in as a separate pluggable algorithm. The mechanism and policy is unchanged from existing code. Signed-off-by: Stephen Hemminger diff -Nru a/net/ipv4/Kconfig b/net/ipv4/Kconfig --- a/net/ipv4/Kconfig 2005-03-18 16:10:43 -08:00 +++ b/net/ipv4/Kconfig 2005-03-18 16:10:43 -08:00 @@ -382,6 +382,20 @@ increase provides TCP friendliness. See http://www.csc.ncsu.edu/faculty/rhee/export/bitcp/ +config TCP_CONG_WESTWOOD + tristate "TCP Westwood+" + default y + ---help--- + TCP Westwood+ is a sender-side only modification of the TCP Reno + protocol stack that optimizes the performance of TCP congestion + control. It is based on end-to-end bandwidth estimation to set + congestion window and slow start threshold after a congestion + episode. Using this estimation, TCP Westwood+ adaptively sets a + slow start threshold and a congestion window which takes into + account the bandwidth used at the time congestion is experienced. + TCP Westwood+ significantly increases fairness wrt TCP Reno in + wired networks and throughput over wireless links. + endmenu source "net/ipv4/ipvs/Kconfig" diff -Nru a/net/ipv4/Makefile b/net/ipv4/Makefile --- a/net/ipv4/Makefile 2005-03-18 16:10:43 -08:00 +++ b/net/ipv4/Makefile 2005-03-18 16:10:43 -08:00 @@ -25,6 +25,7 @@ obj-$(CONFIG_IP_VS) += ipvs/ obj-$(CONFIG_IP_TCPDIAG) += tcp_diag.o obj-$(CONFIG_TCP_CONG_BIC) += tcp_bic.o +obj-$(CONFIG_TCP_CONG_WESTWOOD) += tcp_westwood.o obj-$(CONFIG_XFRM) += xfrm4_policy.o xfrm4_state.o xfrm4_input.o \ xfrm4_output.o diff -Nru a/net/ipv4/tcp_westwood.c b/net/ipv4/tcp_westwood.c --- /dev/null Wed Dec 31 16:00:00 196900 +++ b/net/ipv4/tcp_westwood.c 2005-03-18 16:10:43 -08:00 @@ -0,0 +1,349 @@ +/* + * TCP Westwood+ + * + * Angelo Dell'Aera: TCP Westwood+ support + */ + +#include +#include +#include +#include +#include +#include + +/* TCP Westwood structure */ +struct westwood_ca { + u32 bw_ns_est; /* first bandwidth estimation..not too smoothed 8) */ + u32 bw_est; /* bandwidth estimate */ + u32 rtt_win_sx; /* here starts a new evaluation... */ + u32 bk; + u32 snd_una; /* used for evaluating the number of acked bytes */ + u32 cumul_ack; + u32 accounted; + u32 rtt; + u32 rtt_min; /* minimum observed RTT */ +}; + + +/* TCP Westwood functions and constants */ +#define TCP_WESTWOOD_INIT_RTT (20*HZ) /* maybe too conservative?! */ +#define TCP_WESTWOOD_RTT_MIN (HZ/20) /* 50ms */ + +/* + * @tcp_westwood_create + * This function initializes fields used in TCP Westwood+. We can't + * get no information about RTTmin at this time so we simply set it to + * TCP_WESTWOOD_INIT_RTT. This value was chosen to be too conservative + * since in this way we're sure it will be updated in a consistent + * way as soon as possible. It will reasonably happen within the first + * RTT period of the connection lifetime. + */ +static void tcp_westwood_start(struct tcp_sock *tp) +{ + struct westwood_ca *w = tcp_ca(tp); + + w->bw_ns_est = 0; + w->bw_est = 0; + w->accounted = 0; + w->cumul_ack = 0; + w->rtt_win_sx = tcp_time_stamp; + w->rtt = TCP_WESTWOOD_INIT_RTT; + w->rtt_min = TCP_WESTWOOD_INIT_RTT; + w->snd_una = tp->snd_una; +} + +/* + * @westwood_do_filter + * Low-pass filter. Implemented using constant coefficents. + */ +static inline u32 westwood_do_filter(u32 a, u32 b) +{ + return (((7 * a) + b) >> 3); +} + +static inline void westwood_filter(struct westwood_ca *w, u32 delta) +{ + w->bw_ns_est = westwood_do_filter(w->bw_ns_est, w->bk / delta); + w->bw_est = westwood_do_filter(w->bw_est, w->bw_ns_est); +} + +/* + * @westwood_update_rttmin + * It is used to update RTTmin. In this case we MUST NOT use + * WESTWOOD_RTT_MIN minimum bound since we could be on a LAN! + */ +static inline u32 westwood_update_rttmin(const struct westwood_ca *w) +{ + u32 rttmin = w->rtt_min; + + if (w->rtt != 0 && + (w->rtt < w->rtt_min || !rttmin)) + rttmin = w->rtt; + + return rttmin; +} + +static void tcp_westwood_sample_rtt(struct tcp_sock *tp, u32 rtt) +{ + struct westwood_ca *w = tcp_ca(tp); + w->rtt = tp->srtt >> 3; +} + +/* + * @westwood_acked + * Evaluate increases for dk. + */ +static inline u32 westwood_acked(struct tcp_sock *tp) +{ + struct westwood_ca *w = tcp_ca(tp); + return tp->snd_una - w->snd_una; +} + +/* + * @westwood_new_window + * It evaluates if we are receiving data inside the same RTT window as + * when we started. + * Return value: + * It returns 0 if we are still evaluating samples in the same RTT + * window, 1 if the sample has to be considered in the next window. + */ +static inline int westwood_new_window(const struct tcp_sock *tp) +{ + struct westwood_ca *w = tcp_ca(tp); + u32 left_bound; + u32 rtt; + int ret = 0; + + left_bound = w->rtt_win_sx; + rtt = max(w->rtt, (u32) TCP_WESTWOOD_RTT_MIN); + + /* + * A RTT-window has passed. Be careful since if RTT is less than + * 50ms we don't filter but we continue 'building the sample'. + * This minimum limit was choosen since an estimation on small + * time intervals is better to avoid... + * Obvioulsy on a LAN we reasonably will always have + * right_bound = left_bound + WESTWOOD_RTT_MIN + */ + + if ((left_bound + rtt) < tcp_time_stamp) + ret = 1; + + return ret; +} + +/* + * @westwood_update_window + * It updates RTT evaluation window if it is the right moment to do + * it. If so it calls filter for evaluating bandwidth. + */ +static void westwood_update_window(struct tcp_sock *tp, u32 now) +{ + struct westwood_ca *w = tcp_ca(tp); + if (westwood_new_window(tp)) { + u32 delta = now - w->rtt_win_sx; + + if (delta) { + if (w->rtt) + westwood_filter(w, delta); + + w->bk = 0; + w->rtt_win_sx = tcp_time_stamp; + } + } +} + +/* + * @tcp_westwood_fast_bw + * It is called when we are in fast path. In particular it is called when + * header prediction is successfull. In such case infact update is + * straight forward and doesn't need any particular care. + */ +static void tcp_westwood_fast_bw(struct tcp_sock *tp) +{ + struct westwood_ca *w = tcp_ca(tp); + westwood_update_window(tp, tcp_time_stamp); + + w->bk += westwood_acked(tp); + w->snd_una = tp->snd_una; + w->rtt_min = westwood_update_rttmin(w); +} + +/* + * @westwood_acked_count + * This function evaluates cumul_ack for evaluating dk in case of + * delayed or partial acks. + */ +static u32 westwood_acked_count(struct tcp_sock *tp) +{ + struct westwood_ca *w = tcp_ca(tp); + + w->cumul_ack = westwood_acked(tp); + + /* If cumul_ack is 0 this is a dupack since it's not moving + * tp->snd_una. + */ + if (!w->cumul_ack) { + w->accounted += tp->mss_cache_std; + w->cumul_ack = tp->mss_cache_std; + } + + if (w->cumul_ack > tp->mss_cache_std) { + /* Partial or delayed ack */ + if (w->accounted >= w->cumul_ack) { + w->accounted -= w->cumul_ack; + w->cumul_ack = tp->mss_cache_std; + } else { + w->cumul_ack -= w->accounted; + w->accounted = 0; + } + } + + w->snd_una = tp->snd_una; + + return w->cumul_ack; +} + + +/* + * @tcp_westwood_slow_bw + * It is called when something is going wrong..even if there could + * be no problems! Infact a simple delayed packet may trigger a + * dupack. But we need to be careful in such case. + */ +static void tcp_westwood_slow_bw(struct tcp_sock *tp) +{ + struct westwood_ca *w = tcp_ca(tp); + + westwood_update_window(tp, tcp_time_stamp); + + w->bk += westwood_acked_count(tp); + w->rtt_min = westwood_update_rttmin(w); +} + +static inline u32 tcp_westwood_bw_rttmin(const struct tcp_sock *tp) +{ + struct westwood_ca *w = tcp_ca(tp); + + return max((w->bw_est) * (w->rtt_min) / (u32) (tp->mss_cache_std), + 2U); +} + +static inline u32 tcp_westwood_ssthresh(struct tcp_sock *tp) +{ + u32 ssthresh = tcp_westwood_bw_rttmin(tp); + if (ssthresh) + tp->snd_ssthresh = ssthresh; + + return (ssthresh != 0); +} + +static inline int tcp_westwood_cwnd(struct tcp_sock *tp) +{ + u32 cwnd = 0; + + cwnd = tcp_westwood_bw_rttmin(tp); + if (cwnd) + tp->snd_cwnd = cwnd; + + return (cwnd != 0); +} + +/* + * TCP Westwood + * Here limit is evaluated as BWestimation*RTTmin (for obtaining it + * in packets we use mss_cache). If sysctl_tcp_westwood is off + * tcp_westwood_bw_rttmin() returns 0. In such case snd_ssthresh is + * still used as usual. It prevents other strange cases in which + * BWE*RTTmin could assume value 0. It should not happen but... + */ +static u32 tcp_westwood_cwnd_min(struct tcp_sock *tp) +{ + u32 limit; + + limit = tcp_westwood_bw_rttmin(tp); + if (limit == 0) + limit = tp->snd_ssthresh/2; + return limit; +} + +static void tcp_westwood_event(struct tcp_sock *tp, enum tcp_ca_event event) +{ + switch(event) { + case CA_EVENT_CWND_RESTART: + break; + + case CA_EVENT_COMPLETE_CWR: + if (tcp_westwood_cwnd(tp)) + tp->snd_ssthresh = tp->snd_cwnd; + break; + + case CA_EVENT_FRTO: + if (!tcp_westwood_ssthresh(tp)) + tp->snd_ssthresh = tcp_westwood_ssthresh(tp); + break; + + case CA_EVENT_FAST_ACK: + tcp_westwood_fast_bw(tp); + break; + + case CA_EVENT_SLOW_ACK: + tcp_westwood_slow_bw(tp); + break; + + default: + break; + } +} + + +/* Extract info for Tcp socket info provided via netlink. */ +static void tcp_westwood_info(struct tcp_sock *tp, u32 ext, + struct sk_buff *skb) +{ + + if (ext & (1<<(TCPDIAG_VEGASINFO-1))) { + struct tcpvegas_info *info + = tcpdiag_put(skb, TCPDIAG_VEGASINFO, sizeof(*info)); + if (info) { + struct westwood_ca *ca = tcp_ca(tp); + info->tcpv_enabled = 1; + info->tcpv_rttcnt = 0; + info->tcpv_rtt = jiffies_to_usecs(ca->rtt); + info->tcpv_minrtt = jiffies_to_usecs(ca->rtt_min); + } + } +} + + +static struct tcp_ca_type tcp_westwood = { + .start = tcp_westwood_start, + .ssthresh = tcp_reno_ssthresh, + .rtt_sample = tcp_westwood_sample_rtt, + .cong_avoid = tcp_reno_cong_avoid, + .min_cwnd = tcp_westwood_cwnd_min, + .cwnd_event = tcp_westwood_event, + .get_info = tcp_westwood_info, + + .owner = THIS_MODULE, + .name = "westwood" +}; + +static int __init tcp_westwood_init(void) +{ + BUG_ON(sizeof(struct westwood_ca) > TCP_CA_PRIV_SIZE); + tcp_ca_register(&tcp_westwood); + return 0; +} + +static void __exit tcp_westwood_exit(void) +{ + tcp_ca_unregister(&tcp_westwood); +} + +module_init(tcp_westwood_init); +module_exit(tcp_westwood_exit); + +MODULE_AUTHOR("Stephen Hemminger, Angelo Del'Aera"); +MODULE_LICENSE("GPL"); +MODULE_DESCRIPTION("TCP Westwood+"); From shemminger@osdl.org Fri Mar 18 16:30:58 2005 Received: with ECARTIS (v1.0.0; list netdev); Fri, 18 Mar 2005 16:31:05 -0800 (PST) Received: from smtp.osdl.org (fire.osdl.org [65.172.181.4]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j2J0Ubd5029087 for ; Fri, 18 Mar 2005 16:30:57 -0800 Received: from shell0.pdx.osdl.net (fw.osdl.org [65.172.181.6]) by smtp.osdl.org (8.12.8/8.12.8) with ESMTP id j2J0UMqi016960 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO); Fri, 18 Mar 2005 16:30:22 -0800 Received: from dxpl.pdx.osdl.net (dxpl.pdx.osdl.net [172.20.1.103]) by shell0.pdx.osdl.net (8.13.1/8.11.6) with ESMTP id j2J0UMu7029549; Fri, 18 Mar 2005 16:30:22 -0800 Date: Fri, 18 Mar 2005 16:28:28 -0800 From: Stephen Hemminger To: Andrew Morton , "David S. Miller" , John Heffner Cc: netdev@oss.sgi.com Subject: [PATCH 5/5] TCP High speed support Message-ID: <20050318162828.29c52d5a@dxpl.pdx.osdl.net> Organization: Open Source Development Lab X-Mailer: Sylpheed-Claws 1.0.1 (GTK+ 1.2.10; x86_64-unknown-linux-gnu) X-Face: &@E+xe?c%:&e4D{>f1O<&U>2qwRREG5!}7R4;D<"NO^UI2mJ[eEOA2*3>(`Th.yP,VDPo9$ /`~cw![cmj~~jWe?AHY7D1S+\}5brN0k*NE?pPh_'_d>6;XGG[\KDRViCfumZT3@[ Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Received-SPF: pass (domain of shemminger@osdl.org designates 65.172.181.6 as permitted sender) X-MIMEDefang-Filter: osdl$Revision: 1.105 $ X-Scanned-By: MIMEDefang 2.36 X-Virus-Scanned: ClamAV 0.83/772/Fri Mar 18 00:59:17 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 340 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: shemminger@osdl.org Precedence: bulk X-list: netdev Content-Length: 6464 Lines: 222 John Heffner ported the High speed TCP algorithm from Web100 to the new pluggable infrastructure. I just cleaned it up slightly. Signed-off-by: Stephen Hemminger diff -Nru a/net/ipv4/Kconfig b/net/ipv4/Kconfig --- a/net/ipv4/Kconfig 2005-03-18 16:11:16 -08:00 +++ b/net/ipv4/Kconfig 2005-03-18 16:11:16 -08:00 @@ -406,6 +406,17 @@ window. TCP Vegas should provide less packet loss, but it is not as aggressive as TCP Reno. +config TCP_CONG_HSTCP + tristate "High Speed TCP" + depends on EXPERIMENTAL + default n + ---help--- + Sally Floyd's High Speed TCP (RFC 3649) congestion control. + A modification to TCP's congestion control mechanism for use + with large congestion windows. A table indicates how much to + increase the congestion window by when an ACK is received. + For more detail see http://www.icir.org/floyd/hstcp.html + endmenu source "net/ipv4/ipvs/Kconfig" diff -Nru a/net/ipv4/Makefile b/net/ipv4/Makefile --- a/net/ipv4/Makefile 2005-03-18 16:11:16 -08:00 +++ b/net/ipv4/Makefile 2005-03-18 16:11:16 -08:00 @@ -27,6 +27,7 @@ obj-$(CONFIG_TCP_CONG_BIC) += tcp_bic.o obj-$(CONFIG_TCP_CONG_WESTWOOD) += tcp_westwood.o obj-$(CONFIG_TCP_CONG_VEGAS) += tcp_vegas.o +obj-$(CONFIG_TCP_CONG_HSTCP) += tcp_hstcp.o obj-$(CONFIG_XFRM) += xfrm4_policy.o xfrm4_state.o xfrm4_input.o \ xfrm4_output.o diff -Nru a/net/ipv4/tcp_hstcp.c b/net/ipv4/tcp_hstcp.c --- /dev/null Wed Dec 31 16:00:00 196900 +++ b/net/ipv4/tcp_hstcp.c 2005-03-18 16:11:16 -08:00 @@ -0,0 +1,181 @@ +/* + * Sally Floyd's High Speed TCP (RFC 3649) congestion control + * + * See http://www.icir.org/floyd/hstcp.html + * + * John Heffner + */ + +#include +#include +#include + + +/* From AIMD tables from RFC 3649 appendix B, + * with fixed-point MD scaled <<8. + */ +static const struct hstcp_aimd_val { + unsigned int cwnd; + unsigned int md; +} hstcp_aimd_vals[] = { + { 38, 128, /* 0.50 */ }, + { 118, 112, /* 0.44 */ }, + { 221, 104, /* 0.41 */ }, + { 347, 98, /* 0.38 */ }, + { 495, 93, /* 0.37 */ }, + { 663, 89, /* 0.35 */ }, + { 851, 86, /* 0.34 */ }, + { 1058, 83, /* 0.33 */ }, + { 1284, 81, /* 0.32 */ }, + { 1529, 78, /* 0.31 */ }, + { 1793, 76, /* 0.30 */ }, + { 2076, 74, /* 0.29 */ }, + { 2378, 72, /* 0.28 */ }, + { 2699, 71, /* 0.28 */ }, + { 3039, 69, /* 0.27 */ }, + { 3399, 68, /* 0.27 */ }, + { 3778, 66, /* 0.26 */ }, + { 4177, 65, /* 0.26 */ }, + { 4596, 64, /* 0.25 */ }, + { 5036, 62, /* 0.25 */ }, + { 5497, 61, /* 0.24 */ }, + { 5979, 60, /* 0.24 */ }, + { 6483, 59, /* 0.23 */ }, + { 7009, 58, /* 0.23 */ }, + { 7558, 57, /* 0.22 */ }, + { 8130, 56, /* 0.22 */ }, + { 8726, 55, /* 0.22 */ }, + { 9346, 54, /* 0.21 */ }, + { 9991, 53, /* 0.21 */ }, + { 10661, 52, /* 0.21 */ }, + { 11358, 52, /* 0.20 */ }, + { 12082, 51, /* 0.20 */ }, + { 12834, 50, /* 0.20 */ }, + { 13614, 49, /* 0.19 */ }, + { 14424, 48, /* 0.19 */ }, + { 15265, 48, /* 0.19 */ }, + { 16137, 47, /* 0.19 */ }, + { 17042, 46, /* 0.18 */ }, + { 17981, 45, /* 0.18 */ }, + { 18955, 45, /* 0.18 */ }, + { 19965, 44, /* 0.17 */ }, + { 21013, 43, /* 0.17 */ }, + { 22101, 43, /* 0.17 */ }, + { 23230, 42, /* 0.17 */ }, + { 24402, 41, /* 0.16 */ }, + { 25618, 41, /* 0.16 */ }, + { 26881, 40, /* 0.16 */ }, + { 28193, 39, /* 0.16 */ }, + { 29557, 39, /* 0.15 */ }, + { 30975, 38, /* 0.15 */ }, + { 32450, 38, /* 0.15 */ }, + { 33986, 37, /* 0.15 */ }, + { 35586, 36, /* 0.14 */ }, + { 37253, 36, /* 0.14 */ }, + { 38992, 35, /* 0.14 */ }, + { 40808, 35, /* 0.14 */ }, + { 42707, 34, /* 0.13 */ }, + { 44694, 33, /* 0.13 */ }, + { 46776, 33, /* 0.13 */ }, + { 48961, 32, /* 0.13 */ }, + { 51258, 32, /* 0.13 */ }, + { 53677, 31, /* 0.12 */ }, + { 56230, 30, /* 0.12 */ }, + { 58932, 30, /* 0.12 */ }, + { 61799, 29, /* 0.12 */ }, + { 64851, 28, /* 0.11 */ }, + { 68113, 28, /* 0.11 */ }, + { 71617, 27, /* 0.11 */ }, + { 75401, 26, /* 0.10 */ }, + { 79517, 26, /* 0.10 */ }, + { 84035, 25, /* 0.10 */ }, + { 89053, 24, /* 0.10 */ }, +}; + +#define HSTCP_AIMD_MAX ARRAY_SIZE(hstcp_aimd_vals) + +struct hstcp_ca { + u32 ai; +}; + +static void hstcp_start(struct tcp_sock *tp) +{ + struct hstcp_ca *ca = tcp_ca(tp); + + ca->ai = 0; + + /* Ensure the MD arithmetic works. This is somewhat pedantic, + * since I don't think we will see a cwnd this large. :) */ + tp->snd_cwnd_clamp = min_t(u32, tp->snd_cwnd_clamp, 0xffffffff/128); +} + +static void hstcp_cong_avoid(struct tcp_sock *tp, u32 adk, u32 rtt, + u32 in_flight, int good) +{ + struct hstcp_ca *ca = tcp_ca(tp); + + if (in_flight < tp->snd_cwnd) + return; + + if (tp->snd_cwnd <= tp->snd_ssthresh) { + if (tp->snd_cwnd < tp->snd_cwnd_clamp) + tp->snd_cwnd++; + } else { + /* Update AIMD parameters */ + if (tp->snd_cwnd > hstcp_aimd_vals[ca->ai].cwnd) { + while (tp->snd_cwnd > hstcp_aimd_vals[ca->ai].cwnd && + ca->ai < HSTCP_AIMD_MAX) + ca->ai++; + } else if (tp->snd_cwnd < hstcp_aimd_vals[ca->ai].cwnd) { + while (tp->snd_cwnd > hstcp_aimd_vals[ca->ai].cwnd && + ca->ai > 0) + ca->ai--; + } + + /* Do additive increase */ + if (tp->snd_cwnd < tp->snd_cwnd_clamp) { + tp->snd_cwnd_cnt += ca->ai; + if (tp->snd_cwnd_cnt >= tp->snd_cwnd) { + tp->snd_cwnd++; + tp->snd_cwnd_cnt -= tp->snd_cwnd; + } + } + } +} + +static u32 hstcp_ssthresh(struct tcp_sock *tp) +{ + struct hstcp_ca *ca = tcp_ca(tp); + + /* Do multiplicative decrease */ + return max(tp->snd_cwnd - ((tp->snd_cwnd * hstcp_aimd_vals[ca->ai].md) >> 8), 2U); +} + +static struct tcp_ca_type tcp_highspeed = { + .start = hstcp_start, + .ssthresh = hstcp_ssthresh, + .min_cwnd = tcp_reno_cwnd_min, + .cong_avoid = hstcp_cong_avoid, + + .owner = THIS_MODULE, + .name = "highspeed" +}; + +static int __init hstcp_init(void) +{ + BUILD_BUG_ON(sizeof(struct hstcp_ca) > TCP_CA_PRIV_SIZE); + tcp_ca_register(&tcp_highspeed); + return 0; +} + +static void __exit hstcp_exit(void) +{ + tcp_ca_unregister(&tcp_highspeed); +} + +module_init(hstcp_init); +module_exit(hstcp_exit); + +MODULE_AUTHOR("John Heffner"); +MODULE_LICENSE("GPL"); +MODULE_DESCRIPTION("High Speed TCP"); From shemminger@osdl.org Fri Mar 18 16:31:03 2005 Received: with ECARTIS (v1.0.0; list netdev); Fri, 18 Mar 2005 16:31:09 -0800 (PST) Received: from smtp.osdl.org (fire.osdl.org [65.172.181.4]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j2J0Uhdo029093 for ; Fri, 18 Mar 2005 16:31:03 -0800 Received: from shell0.pdx.osdl.net (fw.osdl.org [65.172.181.6]) by smtp.osdl.org (8.12.8/8.12.8) with ESMTP id j2J0ULqi016952 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO); Fri, 18 Mar 2005 16:30:22 -0800 Received: from dxpl.pdx.osdl.net (dxpl.pdx.osdl.net [172.20.1.103]) by shell0.pdx.osdl.net (8.13.1/8.11.6) with ESMTP id j2J0ULBi029537; Fri, 18 Mar 2005 16:30:21 -0800 Date: Fri, 18 Mar 2005 16:22:11 -0800 From: Stephen Hemminger To: Andrew Morton , "David S. Miller" Cc: netdev@oss.sgi.com, Injong Rhee Subject: [PATCH 2/5] TCP BIC 1.1 support Message-ID: <20050318162211.366ca490@dxpl.pdx.osdl.net> Organization: Open Source Development Lab X-Mailer: Sylpheed-Claws 1.0.1 (GTK+ 1.2.10; x86_64-unknown-linux-gnu) X-Face: &@E+xe?c%:&e4D{>f1O<&U>2qwRREG5!}7R4;D<"NO^UI2mJ[eEOA2*3>(`Th.yP,VDPo9$ /`~cw![cmj~~jWe?AHY7D1S+\}5brN0k*NE?pPh_'_d>6;XGG[\KDRViCfumZT3@[ Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Received-SPF: pass (domain of shemminger@osdl.org designates 65.172.181.6 as permitted sender) X-MIMEDefang-Filter: osdl$Revision: 1.105 $ X-Scanned-By: MIMEDefang 2.36 X-Virus-Scanned: ClamAV 0.83/772/Fri Mar 18 00:59:17 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 341 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: shemminger@osdl.org Precedence: bulk X-list: netdev Content-Length: 10398 Lines: 348 This patch adds TCP BIC back in as a pluggable TCP congestion mechanism. This version is closer to the TCP BIC 1.1 released for Web100. The changes from 2.6.11 are: * congestion window undo fix * delayed ack compensation * low utilization detection * more parameter (less hardcoded constants) The parts that are in the Web100 version are missing are general (not BIC specific): * burst moderation * network device throttling drop tail behaviour They will be addressed later. Signed-off-by: Stephen Hemminger diff -Nru a/net/ipv4/Kconfig b/net/ipv4/Kconfig --- a/net/ipv4/Kconfig 2005-03-18 16:09:40 -08:00 +++ b/net/ipv4/Kconfig 2005-03-18 16:09:40 -08:00 @@ -368,6 +368,20 @@ menu "TCP congestion control" +config TCP_CONG_BIC + tristate "Binary Increase Congestion (BIC) control" + default y + ---help--- + BIC-TCP is a sender-side only change that ensures a linear RTT + fairness under large windows while offering both scalability and + bounded TCP-friendliness. The protocol combines two schemes + called additive increase and binary search increase. When the + congestion window is large, additive increase with a large + increment ensures linear RTT fairness as well as good + scalability. Under small congestion windows, binary search + increase provides TCP friendliness. + See http://www.csc.ncsu.edu/faculty/rhee/export/bitcp/ + endmenu source "net/ipv4/ipvs/Kconfig" diff -Nru a/net/ipv4/Makefile b/net/ipv4/Makefile --- a/net/ipv4/Makefile 2005-03-18 16:09:40 -08:00 +++ b/net/ipv4/Makefile 2005-03-18 16:09:40 -08:00 @@ -24,6 +24,7 @@ obj-$(CONFIG_NETFILTER) += netfilter/ obj-$(CONFIG_IP_VS) += ipvs/ obj-$(CONFIG_IP_TCPDIAG) += tcp_diag.o +obj-$(CONFIG_TCP_CONG_BIC) += tcp_bic.o obj-$(CONFIG_XFRM) += xfrm4_policy.o xfrm4_state.o xfrm4_input.o \ xfrm4_output.o diff -Nru a/net/ipv4/tcp_bic.c b/net/ipv4/tcp_bic.c --- /dev/null Wed Dec 31 16:00:00 196900 +++ b/net/ipv4/tcp_bic.c 2005-03-18 16:09:40 -08:00 @@ -0,0 +1,293 @@ +/* + * Binary Increase Congestion control for TCP + * + * This is from the implementation of BICTCP in + * Lison-Xu, Kahaled Harfoush, and Injong Rhee. + * "Binary Increase Congestion Control for Fast, Long Distance + * Networks" in InfoComm 2004 + * Available from: + * http://www.csc.ncsu.edu/faculty/rhee/export/bitcp.pdf + * + * Unless BIC is enabled and congestion window is large + * this behaves the same as the original Reno. + */ + +#include +#include +#include +#include + + +#define BICTCP_BETA_SCALE 1024 /* Scale factor beta calculation + * max_cwnd = snd_cwnd * beta + */ +#define BICTCP_B 4 /* + * In binary search, + * go to point (max+min)/N + */ + +static int fast_convergence = 1; +static int max_increment = 32; +static int low_window = 14; +static int beta = 819; /* = 819/1024 (BICTCP_BETA_SCALE) */ +static int low_utilization_threshold = 153; +static int low_utilization_period = 2; +static int initial_ssthresh = 100; +static int smooth_part = 20; + +module_param(fast_convergence, int, 0644); +MODULE_PARM_DESC(fast_convergence, "turn on/off fast convergence"); +module_param(max_increment, int, 0644); +MODULE_PARM_DESC(max_increment, "Limit on increment allowed during binary search"); +module_param(low_window, int, 0644); +MODULE_PARM_DESC(low_window, "lower bound on congestion window (for TCP friendliness)"); +module_param(beta, int, 0644); +MODULE_PARM_DESC(beta, "beta for multiplicative increase"); +module_param(low_utilization_threshold, int, 0644); +MODULE_PARM_DESC(low_utilization_threshold, "percent (scaled by 1024) for low utilization mode"); +module_param(low_utilization_period, int, 0644); +MODULE_PARM_DESC(low_utilization_period, "if average delay exceeds then goto to low utilization mode (seconds)"); +module_param(initial_ssthresh, int, 0644); +MODULE_PARM_DESC(initial_ssthresh, "initial value of slow start threshold"); +module_param(smooth_part, int, 0644); +MODULE_PARM_DESC(smooth_part, "log(B/(B*Smin))/log(B/(B-1))+B, # of RTT from Wmax-B to Wmax"); + + +/* BIC TCP Parameters */ +struct bictcp_ca { + u32 cnt; /* increase cwnd by 1 after ACKs */ + u32 last_max_cwnd; /* last maximum snd_cwnd */ + u32 loss_cwnd; /* congestion window at last loss */ + u32 last_cwnd; /* the last snd_cwnd */ + u32 last_time; /* time when updated last_cwnd */ + u32 delay_min; /* min delay */ + u32 delay_max; /* max delay */ + u32 last_delay; + u8 low_utilization;/* 0: high; 1: low */ + u32 low_utilization_start; /* starting time of low utilization detection*/ + u32 epoch_start; /* beginning of an epoch */ +}; + +static inline void bictcp_init(struct bictcp_ca *ca) +{ + memset(ca, 0, sizeof(*ca)); +} + +static void bictcp_start(struct tcp_sock *tp) +{ + bictcp_init(tcp_ca(tp)); + if (initial_ssthresh) + tp->snd_ssthresh = initial_ssthresh; +} + +/* + * Compute congestion window to use. + */ +static inline u32 bictcp_cwnd(struct tcp_sock *tp) +{ + struct bictcp_ca *ca = tcp_ca(tp); + + if (ca->last_cwnd == tp->snd_cwnd && + (s32)(tcp_time_stamp - ca->last_time) <= (HZ>>5)) + return ca->cnt; + + ca->last_cwnd = tp->snd_cwnd; + ca->last_time = tcp_time_stamp; + + if (ca->epoch_start == 0) /* record the beginning of an epoch */ + ca->epoch_start = tcp_time_stamp; + + /* start off normal */ + if (tp->snd_cwnd <= low_window) { + ca->cnt = tp->snd_cwnd; + return ca->cnt; + } + + /* binary increase */ + if (tp->snd_cwnd < ca->last_max_cwnd) { + __u32 dist = (ca->last_max_cwnd - tp->snd_cwnd) + / BICTCP_B; + + if (dist > max_increment) + /* linear increase */ + ca->cnt = tp->snd_cwnd / max_increment; + else if (dist <= 1U) + /* binary search increase */ + ca->cnt = (tp->snd_cwnd * smooth_part) / BICTCP_B; + else + /* binary search increase */ + ca->cnt = tp->snd_cwnd / dist; + } else { + /* slow start AMD linear increase */ + if (tp->snd_cwnd < ca->last_max_cwnd + BICTCP_B) + /* slow start */ + ca->cnt = (tp->snd_cwnd * smooth_part) / BICTCP_B; + else if (tp->snd_cwnd < ca->last_max_cwnd + max_increment*(BICTCP_B-1)) + /* slow start */ + ca->cnt = (tp->snd_cwnd * (BICTCP_B-1)) + / tp->snd_cwnd-ca->last_max_cwnd; + else + /* linear increase */ + ca->cnt = tp->snd_cwnd / max_increment; + } + + /* if in slow start or link utilization is very low */ + if ( ca->loss_cwnd == 0 || + (tp->snd_cwnd > ca->loss_cwnd && ca->low_utilization)) { + if (ca->cnt > 20) /* increase cwnd 5% per RTT */ + ca->cnt = 20; + } + + ca->cnt = (ca->cnt << 3) / tp->ack_ratio; + if (ca->cnt == 0) /* cannot be zero */ + ca->cnt = 1; + + return ca->cnt; +} + + +/* Detect low utilization in congestion avoidance */ +static inline void bictcp_low_utilization(struct tcp_sock *tp, int flag) +{ + struct bictcp_ca *ca = tcp_ca(tp); + u32 dist, delay; + + /* No time stamp */ + if (!(tp->rx_opt.saw_tstamp && tp->rx_opt.rcv_tsecr) || + /* Discard delay samples right after fast recovery */ + tcp_time_stamp < ca->epoch_start + HZ || + /* this delay samples may not be accurate */ + flag == 0) { + ca->last_delay = 0; + goto notlow; + } + + delay = ca->last_delay<<3; /* use the same scale as tp->srtt*/ + ca->last_delay = tcp_time_stamp - tp->rx_opt.rcv_tsecr; + if (delay == 0) /* no previous delay sample */ + goto notlow; + + /* first time call or link delay decreases */ + if (ca->delay_min == 0 || ca->delay_min > delay) { + ca->delay_min = ca->delay_max = delay; + goto notlow; + } + + if (ca->delay_max < delay) + ca->delay_max = delay; + + /* utilization is low, if avg delay < dist*threshold + for checking_period time */ + dist = ca->delay_max - ca->delay_min; + if (dist <= ca->delay_min>>6 || + tp->srtt - ca->delay_min >= (dist*low_utilization_threshold)>>10) + goto notlow; + + if (ca->low_utilization_start == 0) { + ca->low_utilization = 0; + ca->low_utilization_start = tcp_time_stamp; + } else if (after(tcp_time_stamp, + ca->low_utilization_start + low_utilization_period*HZ)) + ca->low_utilization = 1; + + return; + + notlow: + ca->low_utilization = 0; + ca->low_utilization_start = 0; + +} + +static void bictcp_cong_avoid(struct tcp_sock *tp, u32 ack, + u32 seq_rtt, u32 in_flight, int good) +{ + bictcp_low_utilization(tp, good); + + if (in_flight < tp->snd_cwnd) + return; + + if (tp->snd_cwnd <= tp->snd_ssthresh) { + /* In "safe" area, increase. */ + if (tp->snd_cwnd < tp->snd_cwnd_clamp) + tp->snd_cwnd++; + } else { + if (tp->snd_cwnd_cnt > (bictcp_cwnd(tp) << 3)) { + tp->snd_cwnd_cnt = 0; + tp->snd_cwnd++; + } + } + +} + +/* + * behave like Reno until low_window is reached, + * then increase congestion window slowly + */ +static u32 bictcp_recalc_ssthresh(struct tcp_sock *tp) +{ + struct bictcp_ca *ca = tcp_ca(tp); + + ca->epoch_start = 0; /* end of epoch */ + + /* in case of wrong delay_max*/ + if (ca->delay_min > 0 && ca->delay_max > ca->delay_min) + ca->delay_max = ca->delay_min + + ((ca->delay_max - ca->delay_min)* 90) / 100; + + /* Wmax and fast convergence */ + if (tp->snd_cwnd < ca->last_max_cwnd && fast_convergence) + ca->last_max_cwnd = (tp->snd_cwnd * (BICTCP_BETA_SCALE + beta)) + / (2 * BICTCP_BETA_SCALE); + else + ca->last_max_cwnd = tp->snd_cwnd; + + ca->loss_cwnd = tp->snd_cwnd; + + if (tp->snd_cwnd <= low_window) + return max(tp->snd_cwnd >> 1U, 2U); + else + return max((tp->snd_cwnd * beta) / BICTCP_BETA_SCALE, 2U); +} + +static u32 bictcp_undo_cwnd(struct tcp_sock *tp) +{ + struct bictcp_ca *ca = tcp_ca(tp); + return max(tp->snd_cwnd, ca->last_max_cwnd); +} + +static void bictcp_ca_state(struct tcp_sock *tp, u8 new_state) +{ + if (new_state == TCP_CA_Loss) + bictcp_init(tcp_ca(tp)); +} + +static struct tcp_ca_type bictcp = { + .start = bictcp_start, + .ssthresh = bictcp_recalc_ssthresh, + .cong_avoid = bictcp_cong_avoid, + .min_cwnd = tcp_reno_cwnd_min, + .set_state = bictcp_ca_state, + .undo_cwnd = bictcp_undo_cwnd, + + .owner = THIS_MODULE, + .name = "bic", +}; + +static int __init bictcp_register(void) +{ + BUG_ON(sizeof(struct bictcp_ca) > TCP_CA_PRIV_SIZE); + tcp_ca_register(&bictcp); + return 0; +} + +static void __exit bictcp_unregister(void) +{ + tcp_ca_unregister(&bictcp); +} + +module_init(bictcp_register); +module_exit(bictcp_unregister); + +MODULE_AUTHOR("Stephen Hemminger"); +MODULE_LICENSE("GPL"); +MODULE_DESCRIPTION("BIC TCP"); From shemminger@osdl.org Fri Mar 18 16:31:15 2005 Received: with ECARTIS (v1.0.0; list netdev); Fri, 18 Mar 2005 16:31:25 -0800 (PST) Received: from smtp.osdl.org (fire.osdl.org [65.172.181.4]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j2J0UsXD029096 for ; Fri, 18 Mar 2005 16:31:14 -0800 Received: from shell0.pdx.osdl.net (fw.osdl.org [65.172.181.6]) by smtp.osdl.org (8.12.8/8.12.8) with ESMTP id j2J0UMqi016954 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO); Fri, 18 Mar 2005 16:30:22 -0800 Received: from dxpl.pdx.osdl.net (dxpl.pdx.osdl.net [172.20.1.103]) by shell0.pdx.osdl.net (8.13.1/8.11.6) with ESMTP id j2J0UMW6029540; Fri, 18 Mar 2005 16:30:22 -0800 Date: Fri, 18 Mar 2005 16:22:21 -0800 From: Stephen Hemminger To: Andrew Morton , "David S. Miller" Cc: netdev@oss.sgi.com, Injong Rhee Subject: [PATCH 1/5] TCP infrastructure split out Message-ID: <20050318162221.501ff05a@dxpl.pdx.osdl.net> Organization: Open Source Development Lab X-Mailer: Sylpheed-Claws 1.0.1 (GTK+ 1.2.10; x86_64-unknown-linux-gnu) X-Face: &@E+xe?c%:&e4D{>f1O<&U>2qwRREG5!}7R4;D<"NO^UI2mJ[eEOA2*3>(`Th.yP,VDPo9$ /`~cw![cmj~~jWe?AHY7D1S+\}5brN0k*NE?pPh_'_d>6;XGG[\KDRViCfumZT3@[ Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Received-SPF: pass (domain of shemminger@osdl.org designates 65.172.181.6 as permitted sender) X-MIMEDefang-Filter: osdl$Revision: 1.105 $ X-Scanned-By: MIMEDefang 2.36 X-Virus-Scanned: ClamAV 0.83/772/Fri Mar 18 00:59:17 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 342 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: shemminger@osdl.org Precedence: bulk X-list: netdev Content-Length: 51745 Lines: 1734 Since developers want to experiment with different congestion control mechanisms, and the kernel is getting bloated with overlapping data structure and code for multiple algorithms; here is a patch to split out the Reno, Vegas, Westwood, BIC congestion control stuff into an infrastructure similar to the I/O schedulers. Here is the more cleaned up version of the TCP congestion algorithm splitout This first patch removes everything but Reno and puts in the infrastructure. It also adds tracking of the average acks per packet ratio for TCP BIC, because other algorithms might want it. Given the possibility for major screwup, let's put it in the -mm tree until 2.6.13. Signed-off-by: Stephen Hemminger diff -Nru a/include/linux/sysctl.h b/include/linux/sysctl.h --- a/include/linux/sysctl.h 2005-03-18 16:09:08 -08:00 +++ b/include/linux/sysctl.h 2005-03-18 16:09:08 -08:00 @@ -346,6 +346,7 @@ NET_TCP_MODERATE_RCVBUF=106, NET_TCP_TSO_WIN_DIVISOR=107, NET_TCP_BIC_BETA=108, + NET_TCP_CONG_CONTROL=109, }; enum { diff -Nru a/include/linux/tcp.h b/include/linux/tcp.h --- a/include/linux/tcp.h 2005-03-18 16:09:08 -08:00 +++ b/include/linux/tcp.h 2005-03-18 16:09:08 -08:00 @@ -203,13 +203,6 @@ __u32 end_seq; }; -enum tcp_congestion_algo { - TCP_RENO=0, - TCP_VEGAS, - TCP_WESTWOOD, - TCP_BIC, -}; - struct tcp_options_received { /* PAWS/RTTM data */ long ts_recent_stamp;/* Time we stored ts_recent (for aging) */ @@ -294,7 +287,7 @@ __u8 reordering; /* Packet reordering metric. */ __u8 frto_counter; /* Number of new acks after RTO */ - __u8 adv_cong; /* Using Vegas, Westwood, or BIC */ + __u8 unused; __u8 defer_accept; /* User waits for some data after accept() */ /* RTT measurement */ @@ -316,6 +309,7 @@ __u8 keepalive_probes; /* num of allowed keep alive probes */ __u8 probes_out; /* unanswered 0 window probes */ + __u32 ack_ratio; /* estimate the ratio of Packets/ACKs << 3 */ struct tcp_options_received rx_opt; /* @@ -405,42 +399,21 @@ __u32 time; } rcvq_space; -/* TCP Westwood structure */ - struct { - __u32 bw_ns_est; /* first bandwidth estimation..not too smoothed 8) */ - __u32 bw_est; /* bandwidth estimate */ - __u32 rtt_win_sx; /* here starts a new evaluation... */ - __u32 bk; - __u32 snd_una; /* used for evaluating the number of acked bytes */ - __u32 cumul_ack; - __u32 accounted; - __u32 rtt; - __u32 rtt_min; /* minimum observed RTT */ - } westwood; - -/* Vegas variables */ - struct { - __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 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) */ - __u32 baseRTT; /* the min of all Vegas RTT measurements seen (in usec) */ - } vegas; +/* Hook for advanced congestion control */ + struct tcp_ca_type *ca_proto; - /* BI TCP Parameters */ - struct { - __u32 cnt; /* increase cwnd by 1 after this number of ACKs */ - __u32 last_max_cwnd; /* last maximium snd_cwnd */ - __u32 last_cwnd; /* the last snd_cwnd */ - __u32 last_stamp; /* time when updated last_cwnd */ - } bictcp; +#define TCP_CA_PRIV_SIZE 48 + u32 ca_priv[TCP_CA_PRIV_SIZE/sizeof(u32)]; }; static inline struct tcp_sock *tcp_sk(const struct sock *sk) { return (struct tcp_sock *)sk; +} + +static inline void *tcp_ca(const struct tcp_sock *tp) +{ + return (void *) tp->ca_priv; } #endif diff -Nru a/include/linux/tcp_diag.h b/include/linux/tcp_diag.h --- a/include/linux/tcp_diag.h 2005-03-18 16:09:08 -08:00 +++ b/include/linux/tcp_diag.h 2005-03-18 16:09:08 -08:00 @@ -123,5 +123,9 @@ __u32 tcpv_minrtt; }; +#ifdef __KERNEL__ +extern void *tcpdiag_put(struct sk_buff *skb, int attrtype, size_t len); +#endif + #endif /* _TCP_DIAG_H_ */ diff -Nru a/include/net/tcp.h b/include/net/tcp.h --- a/include/net/tcp.h 2005-03-18 16:09:08 -08:00 +++ b/include/net/tcp.h 2005-03-18 16:09:08 -08:00 @@ -504,25 +504,6 @@ #else # define TCP_TW_RECYCLE_TICK (12+2-TCP_TW_RECYCLE_SLOTS_LOG) #endif - -#define BICTCP_BETA_SCALE 1024 /* Scale factor beta calculation - * max_cwnd = snd_cwnd * beta - */ -#define BICTCP_MAX_INCREMENT 32 /* - * Limit on the amount of - * increment allowed during - * binary search. - */ -#define BICTCP_FUNC_OF_MIN_INCR 11 /* - * log(B/Smin)/log(B/(B-1))+1, - * Smin:min increment - * B:log factor - */ -#define BICTCP_B 4 /* - * In binary search, - * go to point (max+min)/N - */ - /* * TCP option */ @@ -596,16 +577,7 @@ extern int sysctl_tcp_tw_reuse; extern int sysctl_tcp_frto; extern int sysctl_tcp_low_latency; -extern int sysctl_tcp_westwood; -extern int sysctl_tcp_vegas_cong_avoid; -extern int sysctl_tcp_vegas_alpha; -extern int sysctl_tcp_vegas_beta; -extern int sysctl_tcp_vegas_gamma; extern int sysctl_tcp_nometrics_save; -extern int sysctl_tcp_bic; -extern int sysctl_tcp_bic_fast_convergence; -extern int sysctl_tcp_bic_low_window; -extern int sysctl_tcp_bic_beta; extern int sysctl_tcp_moderate_rcvbuf; extern int sysctl_tcp_tso_win_divisor; @@ -1204,6 +1176,64 @@ tp->packets_out -= tcp_skb_pcount(skb); } +/* + * Hooks for TCP congestion control algorithms + */ +enum tcp_ca_event { + CA_EVENT_CWND_RESTART, + CA_EVENT_COMPLETE_CWR, + CA_EVENT_FRTO, + CA_EVENT_FAST_ACK, + CA_EVENT_SLOW_ACK, + CA_EVENT_TX_START, +}; + +struct tcp_ca_type { + void (*start)(struct tcp_sock *tp); + u32 (*ssthresh)(struct tcp_sock *tp); + u32 (*min_cwnd)(struct tcp_sock *tp); + void (*cong_avoid)(struct tcp_sock *tp, u32 ack, + u32 rtt, u32 in_flight, int good); + void (*rtt_sample)(struct tcp_sock *tp, u32 rtt); + void (*set_state)(struct tcp_sock *tp, u8 new_state); + + void (*cwnd_event)(struct tcp_sock *tp, enum tcp_ca_event ev); + u32 (*undo_cwnd)(struct tcp_sock *tp); + void (*get_info)(struct tcp_sock *tp, u32 ext, struct sk_buff *skb); + + struct list_head list; + struct module *owner; + const char *name; +}; + + +#define TCP_CA_NAME_MAX 32 +extern char sysctl_tcp_ca_protocol[TCP_CA_NAME_MAX]; +extern void tcp_ca_register(struct tcp_ca_type *type); +extern void tcp_ca_unregister(struct tcp_ca_type *type); +extern void tcp_ca_init(struct tcp_sock *tp); +extern void tcp_ca_destroy(struct tcp_sock *tp); + +extern struct tcp_ca_type tcp_reno; +extern void tcp_reno_cong_avoid(struct tcp_sock *tp, u32 ack, + u32 rtt, u32 in_flight, int flag); +extern u32 tcp_reno_cwnd_min(struct tcp_sock *tp); +extern u32 tcp_reno_ssthresh(struct tcp_sock *tp); + +static inline void tcp_set_ca_state(struct tcp_sock *tp, u8 ca_state) +{ + if (tp->ca_proto && tp->ca_proto->set_state) + tp->ca_proto->set_state(tp, ca_state); + tp->ca_state = ca_state; +} + +static inline void tcp_ca_event(struct tcp_sock *tp, enum tcp_ca_event event) +{ + if (tp->ca_proto->cwnd_event) + tp->ca_proto->cwnd_event(tp, event); +} + + /* This determines how many packets are "in the network" to the best * of our knowledge. In many cases it is conservative, but where * detailed information is available from the receiver (via SACK @@ -1223,91 +1253,6 @@ 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: - * one half the current congestion window, but no - * less than two segments - * - * BIC: - * behave like Reno until low_window is reached, - * then increase congestion window slowly - */ -static inline __u32 tcp_recalc_ssthresh(struct tcp_sock *tp) -{ - if (tcp_is_bic(tp)) { - if (sysctl_tcp_bic_fast_convergence && - tp->snd_cwnd < tp->bictcp.last_max_cwnd) - tp->bictcp.last_max_cwnd = (tp->snd_cwnd * - (BICTCP_BETA_SCALE - + sysctl_tcp_bic_beta)) - / (2 * BICTCP_BETA_SCALE); - else - tp->bictcp.last_max_cwnd = tp->snd_cwnd; - - if (tp->snd_cwnd > sysctl_tcp_bic_low_window) - return max((tp->snd_cwnd * sysctl_tcp_bic_beta) - / BICTCP_BETA_SCALE, 2U); - } - - return max(tp->snd_cwnd >> 1U, 2U); -} - -/* Stop taking Vegas samples for now. */ -#define tcp_vegas_disable(__tp) ((__tp)->vegas.doing_vegas_now = 0) - -static inline void tcp_vegas_enable(struct tcp_sock *tp) -{ - /* There are several situations when we must "re-start" Vegas: - * - * o when a connection is established - * o after an RTO - * o after fast recovery - * o when we send a packet and there is no outstanding - * unacknowledged data (restarting an idle connection) - * - * In these circumstances we cannot do a Vegas calculation at the - * end of the first RTT, because any calculation we do is using - * stale info -- both the saved cwnd and congestion feedback are - * stale. - * - * Instead we must wait until the completion of an RTT during - * which we actually receive ACKs. - */ - - /* Begin taking Vegas samples next time we send something. */ - tp->vegas.doing_vegas_now = 1; - - /* Set the beginning of the next send window. */ - tp->vegas.beg_snd_nxt = tp->snd_nxt; - - tp->vegas.cntRTT = 0; - tp->vegas.minRTT = 0x7fffffff; -} - -/* Should we be taking Vegas samples right now? */ -#define tcp_vegas_enabled(__tp) ((__tp)->vegas.doing_vegas_now) - -extern void tcp_ca_init(struct tcp_sock *tp); - -static inline void tcp_set_ca_state(struct tcp_sock *tp, u8 ca_state) -{ - if (tcp_is_vegas(tp)) { - if (ca_state == TCP_CA_Open) - tcp_vegas_enable(tp); - else - tcp_vegas_disable(tp); - } - tp->ca_state = ca_state; -} - /* If cwnd > ssthresh, we may raise ssthresh to be half-way to cwnd. * The exception is rate halving phase, when cwnd is decreasing towards * ssthresh. @@ -1356,7 +1301,7 @@ static inline void __tcp_enter_cwr(struct tcp_sock *tp) { tp->undo_marker = 0; - tp->snd_ssthresh = tcp_recalc_ssthresh(tp); + tp->snd_ssthresh = tp->ca_proto->ssthresh(tp); tp->snd_cwnd = min(tp->snd_cwnd, tcp_packets_in_flight(tp) + 1U); tp->snd_cwnd_cnt = 0; @@ -1971,52 +1916,4 @@ extern int tcp_proc_register(struct tcp_seq_afinfo *afinfo); extern void tcp_proc_unregister(struct tcp_seq_afinfo *afinfo); -/* TCP Westwood functions and constants */ - -#define TCP_WESTWOOD_INIT_RTT (20*HZ) /* maybe too conservative?! */ -#define TCP_WESTWOOD_RTT_MIN (HZ/20) /* 50ms */ - -static inline void tcp_westwood_update_rtt(struct tcp_sock *tp, __u32 rtt_seq) -{ - if (tcp_is_westwood(tp)) - tp->westwood.rtt = rtt_seq; -} - -static inline __u32 __tcp_westwood_bw_rttmin(const struct tcp_sock *tp) -{ - return max((tp->westwood.bw_est) * (tp->westwood.rtt_min) / - (__u32) (tp->mss_cache_std), - 2U); -} - -static inline __u32 tcp_westwood_bw_rttmin(const struct tcp_sock *tp) -{ - return tcp_is_westwood(tp) ? __tcp_westwood_bw_rttmin(tp) : 0; -} - -static inline int tcp_westwood_ssthresh(struct tcp_sock *tp) -{ - __u32 ssthresh = 0; - - if (tcp_is_westwood(tp)) { - ssthresh = __tcp_westwood_bw_rttmin(tp); - if (ssthresh) - tp->snd_ssthresh = ssthresh; - } - - return (ssthresh != 0); -} - -static inline int tcp_westwood_cwnd(struct tcp_sock *tp) -{ - __u32 cwnd = 0; - - if (tcp_is_westwood(tp)) { - cwnd = __tcp_westwood_bw_rttmin(tp); - if (cwnd) - tp->snd_cwnd = cwnd; - } - - return (cwnd != 0); -} #endif /* _TCP_H */ diff -Nru a/net/ipv4/Kconfig b/net/ipv4/Kconfig --- a/net/ipv4/Kconfig 2005-03-18 16:09:08 -08:00 +++ b/net/ipv4/Kconfig 2005-03-18 16:09:08 -08:00 @@ -365,5 +365,10 @@ config IP_TCPDIAG_IPV6 def_bool (IP_TCPDIAG=y && IPV6=y) || (IP_TCPDIAG=m && IPV6) + +menu "TCP congestion control" + +endmenu + source "net/ipv4/ipvs/Kconfig" diff -Nru a/net/ipv4/Makefile b/net/ipv4/Makefile --- a/net/ipv4/Makefile 2005-03-18 16:09:08 -08:00 +++ b/net/ipv4/Makefile 2005-03-18 16:09:08 -08:00 @@ -5,7 +5,8 @@ obj-y := utils.o route.o inetpeer.o protocol.o \ ip_input.o ip_fragment.o ip_forward.o ip_options.o \ ip_output.o ip_sockglue.o \ - tcp.o tcp_input.o tcp_output.o tcp_timer.o tcp_ipv4.o tcp_minisocks.o \ + tcp.o tcp_input.o tcp_output.o tcp_timer.o tcp_ipv4.o \ + tcp_minisocks.o tcp_cong.o tcp_reno.o \ datagram.o raw.o udp.o arp.o icmp.o devinet.o af_inet.o igmp.o \ sysctl_net_ipv4.o fib_frontend.o fib_semantics.o fib_hash.o diff -Nru a/net/ipv4/sysctl_net_ipv4.c b/net/ipv4/sysctl_net_ipv4.c --- a/net/ipv4/sysctl_net_ipv4.c 2005-03-18 16:09:08 -08:00 +++ b/net/ipv4/sysctl_net_ipv4.c 2005-03-18 16:09:08 -08:00 @@ -603,70 +603,6 @@ .proc_handler = &proc_dointvec, }, { - .ctl_name = NET_TCP_WESTWOOD, - .procname = "tcp_westwood", - .data = &sysctl_tcp_westwood, - .maxlen = sizeof(int), - .mode = 0644, - .proc_handler = &proc_dointvec, - }, - { - .ctl_name = NET_TCP_VEGAS, - .procname = "tcp_vegas_cong_avoid", - .data = &sysctl_tcp_vegas_cong_avoid, - .maxlen = sizeof(int), - .mode = 0644, - .proc_handler = &proc_dointvec, - }, - { - .ctl_name = NET_TCP_VEGAS_ALPHA, - .procname = "tcp_vegas_alpha", - .data = &sysctl_tcp_vegas_alpha, - .maxlen = sizeof(int), - .mode = 0644, - .proc_handler = &proc_dointvec, - }, - { - .ctl_name = NET_TCP_VEGAS_BETA, - .procname = "tcp_vegas_beta", - .data = &sysctl_tcp_vegas_beta, - .maxlen = sizeof(int), - .mode = 0644, - .proc_handler = &proc_dointvec, - }, - { - .ctl_name = NET_TCP_VEGAS_GAMMA, - .procname = "tcp_vegas_gamma", - .data = &sysctl_tcp_vegas_gamma, - .maxlen = sizeof(int), - .mode = 0644, - .proc_handler = &proc_dointvec, - }, - { - .ctl_name = NET_TCP_BIC, - .procname = "tcp_bic", - .data = &sysctl_tcp_bic, - .maxlen = sizeof(int), - .mode = 0644, - .proc_handler = &proc_dointvec, - }, - { - .ctl_name = NET_TCP_BIC_FAST_CONVERGENCE, - .procname = "tcp_bic_fast_convergence", - .data = &sysctl_tcp_bic_fast_convergence, - .maxlen = sizeof(int), - .mode = 0644, - .proc_handler = &proc_dointvec, - }, - { - .ctl_name = NET_TCP_BIC_LOW_WINDOW, - .procname = "tcp_bic_low_window", - .data = &sysctl_tcp_bic_low_window, - .maxlen = sizeof(int), - .mode = 0644, - .proc_handler = &proc_dointvec, - }, - { .ctl_name = NET_TCP_MODERATE_RCVBUF, .procname = "tcp_moderate_rcvbuf", .data = &sysctl_tcp_moderate_rcvbuf, @@ -683,12 +619,13 @@ .proc_handler = &proc_dointvec, }, { - .ctl_name = NET_TCP_BIC_BETA, - .procname = "tcp_bic_beta", - .data = &sysctl_tcp_bic_beta, - .maxlen = sizeof(int), + .ctl_name = NET_TCP_CONG_CONTROL, + .procname = "tcp_congestion_control", + .data = &sysctl_tcp_ca_protocol, + .maxlen = TCP_CA_NAME_MAX, .mode = 0644, - .proc_handler = &proc_dointvec, + .proc_handler = &proc_dostring, + .strategy = &sysctl_string, }, { .ctl_name = 0 } }; diff -Nru a/net/ipv4/tcp.c b/net/ipv4/tcp.c --- a/net/ipv4/tcp.c 2005-03-18 16:09:08 -08:00 +++ b/net/ipv4/tcp.c 2005-03-18 16:09:08 -08:00 @@ -2366,6 +2366,8 @@ printk(KERN_INFO "TCP: Hash tables configured " "(established %d bind %d)\n", tcp_ehash_size << 1, tcp_bhash_size); + + tcp_ca_register(&tcp_reno); } EXPORT_SYMBOL(tcp_accept); diff -Nru a/net/ipv4/tcp_cong.c b/net/ipv4/tcp_cong.c --- /dev/null Wed Dec 31 16:00:00 196900 +++ b/net/ipv4/tcp_cong.c 2005-03-18 16:09:08 -08:00 @@ -0,0 +1,112 @@ +/* + * Plugable TCP congestion control support. + * + * Based on ideas from I/O scheduler suport and Web100. + * + * Copyright (C) 2005 Stephen Hemminger + */ + +#include +#include +#include +#include +#include + +static DEFINE_SPINLOCK(tcp_ca_list_lock); +static LIST_HEAD(tcp_ca_list); + +char sysctl_tcp_ca_protocol[TCP_CA_NAME_MAX] = +#if defined(CONFIG_TCP_CONG_BIC) + "bic"; +#elif defined(CONFIG_TCP_CONG_WESTWOOD) + "westwood"; +#elif defined(CONFIG_TCP_CONG_VEGAS) + "vegas"; +#else + "reno"; +#endif + +static struct tcp_ca_type *tcp_ca_find(const char *name) +{ + struct tcp_ca_type *match = NULL; + struct list_head *entry; + + rcu_read_lock(); + list_for_each_rcu(entry, &tcp_ca_list) { + struct tcp_ca_type *ca + = list_entry(entry, struct tcp_ca_type, list); + + if (strcmp(ca->name, name) == 0) { + match = ca; + break; + } + } + rcu_read_unlock(); + return match; +} + +void tcp_ca_register(struct tcp_ca_type *ca) +{ + BUG_ON(tcp_ca_find(ca->name)); + + spin_lock_irq(&tcp_ca_list_lock); + list_add_tail_rcu(&ca->list, &tcp_ca_list); + spin_unlock_irq(&tcp_ca_list_lock); + + printk(KERN_INFO "TCP %s registered\n", ca->name); +} + +void tcp_ca_unregister(struct tcp_ca_type *ca) +{ + spin_lock(&tcp_ca_list_lock); + list_del_rcu(&ca->list); + spin_unlock(&tcp_ca_list_lock); +} + +/* allow setting on boot cmdline */ +static int __init tcp_congestion_setup(char *str) +{ + strncpy(sysctl_tcp_ca_protocol, str, TCP_CA_NAME_MAX-1); + return 0; +} +__setup("tcp_congestion=", tcp_congestion_setup); + +/* When starting a new connection, pin down the current choice of + * congestion algorithm. + * NB: this depends on tcp_reno being always available. + */ +void tcp_ca_init(struct tcp_sock *tp) +{ + struct tcp_ca_type *ca; + + if (tp->ca_proto) + return; + + ca = tcp_ca_find(sysctl_tcp_ca_protocol); + + if (!ca && capable(CAP_SYS_MODULE)) { + request_module("tcp_%s", sysctl_tcp_ca_protocol); + ca = tcp_ca_find(sysctl_tcp_ca_protocol); + } + + if (!ca || !try_module_get(ca->owner)) { + if (net_ratelimit()) + printk(KERN_WARNING "%s unavailable using TCP reno\n", + sysctl_tcp_ca_protocol); + tp->ca_proto = &tcp_reno; + } else { + tp->ca_proto = ca; + ca->start(tp); + } +} + +void tcp_ca_destroy(struct tcp_sock *tp) +{ + if (tp->ca_proto) { + module_put(tp->ca_proto->owner); + tp->ca_proto = NULL; + } +} + +EXPORT_SYMBOL_GPL(tcp_ca_register); +EXPORT_SYMBOL_GPL(tcp_ca_unregister); diff -Nru a/net/ipv4/tcp_diag.c b/net/ipv4/tcp_diag.c --- a/net/ipv4/tcp_diag.c 2005-03-18 16:09:08 -08:00 +++ b/net/ipv4/tcp_diag.c 2005-03-18 16:09:08 -08:00 @@ -42,18 +42,24 @@ static struct sock *tcpnl; +void *tcpdiag_put(struct sk_buff *skb, int attrtype, size_t attrlen) +{ + int rtalen = RTA_LENGTH(attrlen); + struct rtattr *rta; + + if (skb_tailroom(skb) < RTA_ALIGN(rtalen)) + return NULL; -#define TCPDIAG_PUT(skb, attrtype, attrlen) \ -({ int rtalen = RTA_LENGTH(attrlen); \ - struct rtattr *rta; \ - if (skb_tailroom(skb) < RTA_ALIGN(rtalen)) goto nlmsg_failure; \ - rta = (void*)__skb_put(skb, RTA_ALIGN(rtalen)); \ - rta->rta_type = attrtype; \ - rta->rta_len = rtalen; \ - RTA_DATA(rta); }) + rta = (void *)__skb_put(skb, RTA_ALIGN(rtalen)); + rta->rta_type = attrtype; + rta->rta_len = rtalen; + + return RTA_DATA(rta); +} +EXPORT_SYMBOL(tcpdiag_put); static int tcpdiag_fill(struct sk_buff *skb, struct sock *sk, - int ext, u32 pid, u32 seq, u16 nlmsg_flags) + u32 ext, u32 pid, u32 seq, u16 nlmsg_flags) { struct inet_sock *inet = inet_sk(sk); struct tcp_sock *tp = tcp_sk(sk); @@ -61,7 +67,6 @@ 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)); @@ -69,13 +74,10 @@ r = NLMSG_DATA(nlh); if (sk->sk_state != TCP_TIME_WAIT) { if (ext & (1<<(TCPDIAG_MEMINFO-1))) - minfo = TCPDIAG_PUT(skb, TCPDIAG_MEMINFO, sizeof(*minfo)); + minfo = tcpdiag_put(skb, TCPDIAG_MEMINFO, sizeof(*minfo)); if (ext & (1<<(TCPDIAG_INFO-1))) - info = TCPDIAG_PUT(skb, TCPDIAG_INFO, sizeof(*info)); + 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->sk_family; r->tcpdiag_state = sk->sk_state; @@ -166,20 +168,10 @@ if (info) tcp_get_info(sk, info); - if (vinfo) { - if (tcp_is_vegas(tp)) { - vinfo->tcpv_enabled = tp->vegas.doing_vegas_now; - vinfo->tcpv_rttcnt = tp->vegas.cntRTT; - vinfo->tcpv_rtt = jiffies_to_usecs(tp->vegas.baseRTT); - vinfo->tcpv_minrtt = jiffies_to_usecs(tp->vegas.minRTT); - } else { - vinfo->tcpv_enabled = 0; - vinfo->tcpv_rttcnt = 0; - vinfo->tcpv_rtt = jiffies_to_usecs(tp->westwood.rtt); - vinfo->tcpv_minrtt = jiffies_to_usecs(tp->westwood.rtt_min); - } - } - + if (sk->sk_state != TCP_TIME_WAIT && + tp->ca_proto && tp->ca_proto->get_info) + tp->ca_proto->get_info(tp, ext, skb); + nlh->nlmsg_len = skb->tail - b; return skb->len; diff -Nru a/net/ipv4/tcp_input.c b/net/ipv4/tcp_input.c --- a/net/ipv4/tcp_input.c 2005-03-18 16:09:08 -08:00 +++ b/net/ipv4/tcp_input.c 2005-03-18 16:09:08 -08:00 @@ -61,7 +61,6 @@ * Panu Kuhlberg: Experimental audit of TCP (re)transmission * engine. Lots of bugs are found. * Pasi Sarolahti: F-RTO for dealing with spurious RTOs - * Angelo Dell'Aera: TCP Westwood+ support */ #include @@ -88,23 +87,9 @@ int sysctl_tcp_max_orphans = NR_FILE; int sysctl_tcp_frto; int sysctl_tcp_nometrics_save; -int sysctl_tcp_westwood; -int sysctl_tcp_vegas_cong_avoid; int sysctl_tcp_moderate_rcvbuf = 1; -/* Default values of the Vegas variables, in fixed-point representation - * with V_PARAM_SHIFT bits to the right of the binary point. - */ -#define V_PARAM_SHIFT 1 -int sysctl_tcp_vegas_alpha = 1<snd_cwnd_stamp = tcp_time_stamp; } -static void init_bictcp(struct tcp_sock *tp) -{ - tp->bictcp.cnt = 0; - - tp->bictcp.last_max_cwnd = 0; - tp->bictcp.last_cwnd = 0; - tp->bictcp.last_stamp = 0; -} - /* 5. Recalculate window clamp after socket hit its memory bounds. */ static void tcp_clamp_window(struct sock *sk, struct tcp_sock *tp) { @@ -558,45 +534,6 @@ tcp_grow_window(sk, tp, skb); } -/* When starting a new connection, pin down the current choice of - * congestion algorithm. - */ -void tcp_ca_init(struct tcp_sock *tp) -{ - 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); - } -} - -/* Do RTT sampling needed for Vegas. - * Basically we: - * o min-filter RTT samples from within an RTT to get the current - * propagation delay + queuing delay (we are min-filtering to try to - * avoid the effects of delayed ACKs) - * o min-filter RTT samples from a much longer window (forever for now) - * to find the propagation delay (baseRTT) - */ -static inline void vegas_rtt_calc(struct tcp_sock *tp, __u32 rtt) -{ - __u32 vrtt = rtt + 1; /* Never allow zero rtt or baseRTT */ - - /* Filter to find propagation delay: */ - if (vrtt < tp->vegas.baseRTT) - tp->vegas.baseRTT = vrtt; - - /* Find the min RTT during the last RTT to find - * the current prop. delay + queuing delay: - */ - tp->vegas.minRTT = min(tp->vegas.minRTT, vrtt); - tp->vegas.cntRTT++; -} - /* Called to compute a smoothed rtt estimate. The data fed to this * routine either comes from timestamps, or from segments that were * known _not_ to have been retransmitted [see Karn/Partridge @@ -610,9 +547,6 @@ { long m = mrtt; /* RTT */ - if (tcp_vegas_enabled(tp)) - vegas_rtt_calc(tp, mrtt); - /* The following amusing code comes from Jacobson's * article in SIGCOMM '88. Note that rtt and mdev * are scaled versions of rtt and mean deviation. @@ -670,7 +604,8 @@ tp->rtt_seq = tp->snd_nxt; } - tcp_westwood_update_rtt(tp, tp->srtt >> 3); + if (tp->ca_proto->rtt_sample) + tp->ca_proto->rtt_sample(tp, mrtt); } /* Calculate rto without backoff. This is the second half of Van Jacobson's @@ -1185,8 +1120,7 @@ tp->snd_una == tp->high_seq || (tp->ca_state == TCP_CA_Loss && !tp->retransmits)) { tp->prior_ssthresh = tcp_current_ssthresh(tp); - if (!tcp_westwood_ssthresh(tp)) - tp->snd_ssthresh = tcp_recalc_ssthresh(tp); + tcp_ca_event(tp, CA_EVENT_FRTO); } /* Have to clear retransmission markers here to keep the bookkeeping @@ -1252,8 +1186,6 @@ tcp_set_ca_state(tp, TCP_CA_Loss); tp->high_seq = tp->frto_highmark; TCP_ECN_queue_cwr(tp); - - init_bictcp(tp); } void tcp_clear_retrans(struct tcp_sock *tp) @@ -1283,7 +1215,7 @@ if (tp->ca_state <= TCP_CA_Disorder || tp->snd_una == tp->high_seq || (tp->ca_state == TCP_CA_Loss && !tp->retransmits)) { tp->prior_ssthresh = tcp_current_ssthresh(tp); - tp->snd_ssthresh = tcp_recalc_ssthresh(tp); + tp->snd_ssthresh = tp->ca_proto->ssthresh(tp); } tp->snd_cwnd = 1; tp->snd_cwnd_cnt = 0; @@ -1314,6 +1246,7 @@ tp->reordering = min_t(unsigned int, tp->reordering, sysctl_tcp_reordering); + tcp_set_ca_state(tp, TCP_CA_Loss); tp->high_seq = tp->snd_nxt; TCP_ECN_queue_cwr(tp); @@ -1600,24 +1533,11 @@ static void tcp_cwnd_down(struct tcp_sock *tp) { int decr = tp->snd_cwnd_cnt + 1; - __u32 limit; - - /* - * TCP Westwood - * Here limit is evaluated as BWestimation*RTTmin (for obtaining it - * in packets we use mss_cache). If sysctl_tcp_westwood is off - * tcp_westwood_bw_rttmin() returns 0. In such case snd_ssthresh is - * still used as usual. It prevents other strange cases in which - * BWE*RTTmin could assume value 0. It should not happen but... - */ - - if (!(limit = tcp_westwood_bw_rttmin(tp))) - limit = tp->snd_ssthresh/2; tp->snd_cwnd_cnt = decr&1; decr >>= 1; - if (decr && tp->snd_cwnd > limit) + if (decr && tp->snd_cwnd > tp->ca_proto->min_cwnd(tp)) tp->snd_cwnd -= decr; tp->snd_cwnd = min(tp->snd_cwnd, tcp_packets_in_flight(tp)+1); @@ -1654,7 +1574,10 @@ static void tcp_undo_cwr(struct tcp_sock *tp, int undo) { if (tp->prior_ssthresh) { - tp->snd_cwnd = max(tp->snd_cwnd, tp->snd_ssthresh<<1); + if (tp->ca_proto->undo_cwnd) + tp->snd_cwnd = tp->ca_proto->undo_cwnd(tp); + else + tp->snd_cwnd = max(tp->snd_cwnd, tp->snd_ssthresh<<1); if (undo && tp->prior_ssthresh > tp->snd_ssthresh) { tp->snd_ssthresh = tp->prior_ssthresh; @@ -1764,10 +1687,8 @@ static inline void tcp_complete_cwr(struct tcp_sock *tp) { - if (tcp_westwood_cwnd(tp)) - tp->snd_ssthresh = tp->snd_cwnd; - else - tp->snd_cwnd = min(tp->snd_cwnd, tp->snd_ssthresh); + tcp_ca_event(tp, CA_EVENT_COMPLETE_CWR); + tp->snd_cwnd = min(tp->snd_cwnd, tp->snd_ssthresh); tp->snd_cwnd_stamp = tcp_time_stamp; } @@ -1943,7 +1864,7 @@ if (tp->ca_state < TCP_CA_CWR) { if (!(flag&FLAG_ECE)) tp->prior_ssthresh = tcp_current_ssthresh(tp); - tp->snd_ssthresh = tcp_recalc_ssthresh(tp); + tp->snd_ssthresh = tp->ca_proto->ssthresh(tp); TCP_ECN_queue_cwr(tp); } @@ -2016,322 +1937,13 @@ tcp_ack_no_tstamp(tp, seq_rtt, flag); } -/* - * Compute congestion window to use. - * - * This is from the implementation of BICTCP in - * Lison-Xu, Kahaled Harfoush, and Injog Rhee. - * "Binary Increase Congestion Control for Fast, Long Distance - * Networks" in InfoComm 2004 - * Available from: - * http://www.csc.ncsu.edu/faculty/rhee/export/bitcp.pdf - * - * Unless BIC is enabled and congestion window is large - * this behaves the same as the original Reno. - */ -static inline __u32 bictcp_cwnd(struct tcp_sock *tp) -{ - /* orignal Reno behaviour */ - if (!tcp_is_bic(tp)) - return tp->snd_cwnd; - - if (tp->bictcp.last_cwnd == tp->snd_cwnd && - (s32)(tcp_time_stamp - tp->bictcp.last_stamp) <= (HZ>>5)) - return tp->bictcp.cnt; - - tp->bictcp.last_cwnd = tp->snd_cwnd; - tp->bictcp.last_stamp = tcp_time_stamp; - - /* start off normal */ - if (tp->snd_cwnd <= sysctl_tcp_bic_low_window) - tp->bictcp.cnt = tp->snd_cwnd; - - /* binary increase */ - else if (tp->snd_cwnd < tp->bictcp.last_max_cwnd) { - __u32 dist = (tp->bictcp.last_max_cwnd - tp->snd_cwnd) - / BICTCP_B; - - if (dist > BICTCP_MAX_INCREMENT) - /* linear increase */ - tp->bictcp.cnt = tp->snd_cwnd / BICTCP_MAX_INCREMENT; - else if (dist <= 1U) - /* binary search increase */ - tp->bictcp.cnt = tp->snd_cwnd * BICTCP_FUNC_OF_MIN_INCR - / BICTCP_B; - else - /* binary search increase */ - tp->bictcp.cnt = tp->snd_cwnd / dist; - } else { - /* slow start amd linear increase */ - if (tp->snd_cwnd < tp->bictcp.last_max_cwnd + BICTCP_B) - /* slow start */ - tp->bictcp.cnt = tp->snd_cwnd * BICTCP_FUNC_OF_MIN_INCR - / BICTCP_B; - else if (tp->snd_cwnd < tp->bictcp.last_max_cwnd - + BICTCP_MAX_INCREMENT*(BICTCP_B-1)) - /* slow start */ - tp->bictcp.cnt = tp->snd_cwnd * (BICTCP_B-1) - / (tp->snd_cwnd-tp->bictcp.last_max_cwnd); - else - /* linear increase */ - tp->bictcp.cnt = tp->snd_cwnd / BICTCP_MAX_INCREMENT; - } - return tp->bictcp.cnt; -} - -/* This is Jacobson's slow start and congestion avoidance. - * SIGCOMM '88, p. 328. - */ -static inline void reno_cong_avoid(struct tcp_sock *tp) +static inline void tcp_cong_avoid(struct tcp_sock *tp, u32 ack, u32 seq_rtt, + u32 in_flight, int good) { - if (tp->snd_cwnd <= tp->snd_ssthresh) { - /* In "safe" area, increase. */ - if (tp->snd_cwnd < tp->snd_cwnd_clamp) - tp->snd_cwnd++; - } else { - /* In dangerous area, increase slowly. - * In theory this is tp->snd_cwnd += 1 / tp->snd_cwnd - */ - if (tp->snd_cwnd_cnt >= bictcp_cwnd(tp)) { - if (tp->snd_cwnd < tp->snd_cwnd_clamp) - tp->snd_cwnd++; - tp->snd_cwnd_cnt=0; - } else - tp->snd_cwnd_cnt++; - } + tp->ca_proto->cong_avoid(tp, ack, seq_rtt, in_flight, good); tp->snd_cwnd_stamp = tcp_time_stamp; } -/* This is based on the congestion detection/avoidance scheme described in - * Lawrence S. Brakmo and Larry L. Peterson. - * "TCP Vegas: End to end congestion avoidance on a global internet." - * IEEE Journal on Selected Areas in Communication, 13(8):1465--1480, - * October 1995. Available from: - * ftp://ftp.cs.arizona.edu/xkernel/Papers/jsac.ps - * - * See http://www.cs.arizona.edu/xkernel/ for their implementation. - * The main aspects that distinguish this implementation from the - * Arizona Vegas implementation are: - * o We do not change the loss detection or recovery mechanisms of - * Linux in any way. Linux already recovers from losses quite well, - * using fine-grained timers, NewReno, and FACK. - * o To avoid the performance penalty imposed by increasing cwnd - * only every-other RTT during slow start, we increase during - * every RTT during slow start, just like Reno. - * o Largely to allow continuous cwnd growth during slow start, - * we use the rate at which ACKs come back as the "actual" - * rate, rather than the rate at which data is sent. - * o To speed convergence to the right rate, we set the cwnd - * to achieve the right ("actual") rate when we exit slow start. - * o To filter out the noise caused by delayed ACKs, we use the - * minimum RTT sample observed during the last RTT to calculate - * the actual rate. - * o When the sender re-starts from idle, it waits until it has - * received ACKs for an entire flight of new data before making - * a cwnd adjustment decision. The original Vegas implementation - * assumed senders never went idle. - */ -static void vegas_cong_avoid(struct tcp_sock *tp, u32 ack, u32 seq_rtt) -{ - /* The key players are v_beg_snd_una and v_beg_snd_nxt. - * - * These are so named because they represent the approximate values - * of snd_una and snd_nxt at the beginning of the current RTT. More - * precisely, they represent the amount of data sent during the RTT. - * At the end of the RTT, when we receive an ACK for v_beg_snd_nxt, - * we will calculate that (v_beg_snd_nxt - v_beg_snd_una) outstanding - * bytes of data have been ACKed during the course of the RTT, giving - * an "actual" rate of: - * - * (v_beg_snd_nxt - v_beg_snd_una) / (rtt duration) - * - * Unfortunately, v_beg_snd_una is not exactly equal to snd_una, - * because delayed ACKs can cover more than one segment, so they - * don't line up nicely with the boundaries of RTTs. - * - * Another unfortunate fact of life is that delayed ACKs delay the - * advance of the left edge of our send window, so that the number - * of bytes we send in an RTT is often less than our cwnd will allow. - * So we keep track of our cwnd separately, in v_beg_snd_cwnd. - */ - - if (after(ack, tp->vegas.beg_snd_nxt)) { - /* Do the Vegas once-per-RTT cwnd adjustment. */ - u32 old_wnd, old_snd_cwnd; - - - /* Here old_wnd is essentially the window of data that was - * sent during the previous RTT, and has all - * been acknowledged in the course of the RTT that ended - * with the ACK we just received. Likewise, old_snd_cwnd - * is the cwnd during the previous RTT. - */ - old_wnd = (tp->vegas.beg_snd_nxt - tp->vegas.beg_snd_una) / - tp->mss_cache_std; - old_snd_cwnd = tp->vegas.beg_snd_cwnd; - - /* Save the extent of the current window so we can use this - * at the end of the next RTT. - */ - tp->vegas.beg_snd_una = tp->vegas.beg_snd_nxt; - tp->vegas.beg_snd_nxt = tp->snd_nxt; - tp->vegas.beg_snd_cwnd = tp->snd_cwnd; - - /* Take into account the current RTT sample too, to - * decrease the impact of delayed acks. This double counts - * this sample since we count it for the next window as well, - * but that's not too awful, since we're taking the min, - * rather than averaging. - */ - vegas_rtt_calc(tp, seq_rtt); - - /* We do the Vegas calculations only if we got enough RTT - * samples that we can be reasonably sure that we got - * at least one RTT sample that wasn't from a delayed ACK. - * If we only had 2 samples total, - * then that means we're getting only 1 ACK per RTT, which - * means they're almost certainly delayed ACKs. - * If we have 3 samples, we should be OK. - */ - - if (tp->vegas.cntRTT <= 2) { - /* We don't have enough RTT samples to do the Vegas - * calculation, so we'll behave like Reno. - */ - if (tp->snd_cwnd > tp->snd_ssthresh) - tp->snd_cwnd++; - } else { - u32 rtt, target_cwnd, diff; - - /* We have enough RTT samples, so, using the Vegas - * algorithm, we determine if we should increase or - * decrease cwnd, and by how much. - */ - - /* Pluck out the RTT we are using for the Vegas - * calculations. This is the min RTT seen during the - * last RTT. Taking the min filters out the effects - * of delayed ACKs, at the cost of noticing congestion - * a bit later. - */ - rtt = tp->vegas.minRTT; - - /* Calculate the cwnd we should have, if we weren't - * going too fast. - * - * This is: - * (actual rate in segments) * baseRTT - * We keep it as a fixed point number with - * V_PARAM_SHIFT bits to the right of the binary point. - */ - target_cwnd = ((old_wnd * tp->vegas.baseRTT) - << V_PARAM_SHIFT) / rtt; - - /* Calculate the difference between the window we had, - * and the window we would like to have. This quantity - * is the "Diff" from the Arizona Vegas papers. - * - * Again, this is a fixed point number with - * V_PARAM_SHIFT bits to the right of the binary - * point. - */ - diff = (old_wnd << V_PARAM_SHIFT) - target_cwnd; - - if (tp->snd_cwnd < tp->snd_ssthresh) { - /* Slow start. */ - if (diff > sysctl_tcp_vegas_gamma) { - /* Going too fast. Time to slow down - * and switch to congestion avoidance. - */ - tp->snd_ssthresh = 2; - - /* Set cwnd to match the actual rate - * exactly: - * cwnd = (actual rate) * baseRTT - * Then we add 1 because the integer - * truncation robs us of full link - * utilization. - */ - tp->snd_cwnd = min(tp->snd_cwnd, - (target_cwnd >> - V_PARAM_SHIFT)+1); - - } - } else { - /* Congestion avoidance. */ - u32 next_snd_cwnd; - - /* Figure out where we would like cwnd - * to be. - */ - if (diff > sysctl_tcp_vegas_beta) { - /* The old window was too fast, so - * we slow down. - */ - next_snd_cwnd = old_snd_cwnd - 1; - } else if (diff < sysctl_tcp_vegas_alpha) { - /* We don't have enough extra packets - * in the network, so speed up. - */ - next_snd_cwnd = old_snd_cwnd + 1; - } else { - /* Sending just as fast as we - * should be. - */ - next_snd_cwnd = old_snd_cwnd; - } - - /* Adjust cwnd upward or downward, toward the - * desired value. - */ - if (next_snd_cwnd > tp->snd_cwnd) - tp->snd_cwnd++; - else if (next_snd_cwnd < tp->snd_cwnd) - tp->snd_cwnd--; - } - } - - /* Wipe the slate clean for the next RTT. */ - tp->vegas.cntRTT = 0; - tp->vegas.minRTT = 0x7fffffff; - } - - /* The following code is executed for every ack we receive, - * except for conditions checked in should_advance_cwnd() - * before the call to tcp_cong_avoid(). Mainly this means that - * we only execute this code if the ack actually acked some - * data. - */ - - /* If we are in slow start, increase our cwnd in response to this ACK. - * (If we are not in slow start then we are in congestion avoidance, - * and adjust our congestion window only once per RTT. See the code - * above.) - */ - if (tp->snd_cwnd <= tp->snd_ssthresh) - tp->snd_cwnd++; - - /* to keep cwnd from growing without bound */ - tp->snd_cwnd = min_t(u32, tp->snd_cwnd, tp->snd_cwnd_clamp); - - /* Make sure that we are never so timid as to reduce our cwnd below - * 2 MSS. - * - * Going below 2 MSS would risk huge delayed ACKs from our receiver. - */ - tp->snd_cwnd = max(tp->snd_cwnd, 2U); - - tp->snd_cwnd_stamp = tcp_time_stamp; -} - -static inline void tcp_cong_avoid(struct tcp_sock *tp, u32 ack, u32 seq_rtt) -{ - if (tcp_vegas_enabled(tp)) - vegas_cong_avoid(tp, ack, seq_rtt); - else - reno_cong_avoid(tp); -} - /* Restart timer after forward progress on connection. * RFC2988 recommends to restart timer to now+rto. */ @@ -2419,6 +2031,7 @@ __u32 now = tcp_time_stamp; int acked = 0; __s32 seq_rtt = -1; + int cnt = 0; while ((skb = skb_peek(&sk->sk_write_queue)) && skb != sk->sk_send_head) { @@ -2473,6 +2086,7 @@ tcp_packets_out_dec(tp, skb); __skb_unlink(skb, skb->list); sk_stream_free_skb(sk, skb); + cnt += 1<<3; } if (acked&FLAG_ACKED) { @@ -2480,6 +2094,10 @@ tcp_ack_packets_out(sk, tp); } + /* smoothed average of # packets per ack */ + cnt -= tp->ack_ratio >> 3; + tp->ack_ratio += cnt; + #if FASTRETRANS_DEBUG > 0 BUG_TRAP((int)tp->sacked_out >= 0); BUG_TRAP((int)tp->lost_out >= 0); @@ -2621,256 +2239,6 @@ tp->frto_counter = (tp->frto_counter + 1) % 3; } -/* - * TCP Westwood+ - */ - -/* - * @init_westwood - * This function initializes fields used in TCP Westwood+. We can't - * get no information about RTTmin at this time so we simply set it to - * TCP_WESTWOOD_INIT_RTT. This value was chosen to be too conservative - * since in this way we're sure it will be updated in a consistent - * way as soon as possible. It will reasonably happen within the first - * RTT period of the connection lifetime. - */ - -static void init_westwood(struct sock *sk) -{ - struct tcp_sock *tp = tcp_sk(sk); - - tp->westwood.bw_ns_est = 0; - tp->westwood.bw_est = 0; - tp->westwood.accounted = 0; - tp->westwood.cumul_ack = 0; - tp->westwood.rtt_win_sx = tcp_time_stamp; - tp->westwood.rtt = TCP_WESTWOOD_INIT_RTT; - tp->westwood.rtt_min = TCP_WESTWOOD_INIT_RTT; - tp->westwood.snd_una = tp->snd_una; -} - -/* - * @westwood_do_filter - * Low-pass filter. Implemented using constant coeffients. - */ - -static inline __u32 westwood_do_filter(__u32 a, __u32 b) -{ - return (((7 * a) + b) >> 3); -} - -static void westwood_filter(struct sock *sk, __u32 delta) -{ - struct tcp_sock *tp = tcp_sk(sk); - - tp->westwood.bw_ns_est = - westwood_do_filter(tp->westwood.bw_ns_est, - tp->westwood.bk / delta); - tp->westwood.bw_est = - westwood_do_filter(tp->westwood.bw_est, - tp->westwood.bw_ns_est); -} - -/* - * @westwood_update_rttmin - * It is used to update RTTmin. In this case we MUST NOT use - * WESTWOOD_RTT_MIN minimum bound since we could be on a LAN! - */ - -static inline __u32 westwood_update_rttmin(const struct sock *sk) -{ - const struct tcp_sock *tp = tcp_sk(sk); - __u32 rttmin = tp->westwood.rtt_min; - - if (tp->westwood.rtt != 0 && - (tp->westwood.rtt < tp->westwood.rtt_min || !rttmin)) - rttmin = tp->westwood.rtt; - - return rttmin; -} - -/* - * @westwood_acked - * Evaluate increases for dk. - */ - -static inline __u32 westwood_acked(const struct sock *sk) -{ - const struct tcp_sock *tp = tcp_sk(sk); - - return tp->snd_una - tp->westwood.snd_una; -} - -/* - * @westwood_new_window - * It evaluates if we are receiving data inside the same RTT window as - * when we started. - * Return value: - * It returns 0 if we are still evaluating samples in the same RTT - * window, 1 if the sample has to be considered in the next window. - */ - -static int westwood_new_window(const struct sock *sk) -{ - const struct tcp_sock *tp = tcp_sk(sk); - __u32 left_bound; - __u32 rtt; - int ret = 0; - - left_bound = tp->westwood.rtt_win_sx; - rtt = max(tp->westwood.rtt, (u32) TCP_WESTWOOD_RTT_MIN); - - /* - * A RTT-window has passed. Be careful since if RTT is less than - * 50ms we don't filter but we continue 'building the sample'. - * This minimum limit was choosen since an estimation on small - * time intervals is better to avoid... - * Obvioulsy on a LAN we reasonably will always have - * right_bound = left_bound + WESTWOOD_RTT_MIN - */ - - if ((left_bound + rtt) < tcp_time_stamp) - ret = 1; - - return ret; -} - -/* - * @westwood_update_window - * It updates RTT evaluation window if it is the right moment to do - * it. If so it calls filter for evaluating bandwidth. - */ - -static void __westwood_update_window(struct sock *sk, __u32 now) -{ - struct tcp_sock *tp = tcp_sk(sk); - __u32 delta = now - tp->westwood.rtt_win_sx; - - 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) -{ - if (westwood_new_window(sk)) - __westwood_update_window(sk, now); -} - -/* - * @__tcp_westwood_fast_bw - * It is called when we are in fast path. In particular it is called when - * header prediction is successfull. In such case infact update is - * straight forward and doesn't need any particular care. - */ - -static void __tcp_westwood_fast_bw(struct sock *sk, struct sk_buff *skb) -{ - struct tcp_sock *tp = tcp_sk(sk); - - westwood_update_window(sk, tcp_time_stamp); - - tp->westwood.bk += westwood_acked(sk); - tp->westwood.snd_una = tp->snd_una; - tp->westwood.rtt_min = westwood_update_rttmin(sk); -} - -static inline void tcp_westwood_fast_bw(struct sock *sk, struct sk_buff *skb) -{ - if (tcp_is_westwood(tcp_sk(sk))) - __tcp_westwood_fast_bw(sk, skb); -} - - -/* - * @westwood_dupack_update - * It updates accounted and cumul_ack when receiving a dupack. - */ - -static void westwood_dupack_update(struct sock *sk) -{ - struct tcp_sock *tp = tcp_sk(sk); - - tp->westwood.accounted += tp->mss_cache_std; - tp->westwood.cumul_ack = tp->mss_cache_std; -} - -static inline int westwood_may_change_cumul(struct tcp_sock *tp) -{ - return (tp->westwood.cumul_ack > tp->mss_cache_std); -} - -static inline void westwood_partial_update(struct tcp_sock *tp) -{ - tp->westwood.accounted -= tp->westwood.cumul_ack; - tp->westwood.cumul_ack = tp->mss_cache_std; -} - -static inline void westwood_complete_update(struct tcp_sock *tp) -{ - tp->westwood.cumul_ack -= tp->westwood.accounted; - tp->westwood.accounted = 0; -} - -/* - * @westwood_acked_count - * This function evaluates cumul_ack for evaluating dk in case of - * delayed or partial acks. - */ - -static inline __u32 westwood_acked_count(struct sock *sk) -{ - struct tcp_sock *tp = tcp_sk(sk); - - tp->westwood.cumul_ack = westwood_acked(sk); - - /* If cumul_ack is 0 this is a dupack since it's not moving - * tp->snd_una. - */ - if (!(tp->westwood.cumul_ack)) - westwood_dupack_update(sk); - - if (westwood_may_change_cumul(tp)) { - /* Partial or delayed ack */ - if (tp->westwood.accounted >= tp->westwood.cumul_ack) - westwood_partial_update(tp); - else - westwood_complete_update(tp); - } - - tp->westwood.snd_una = tp->snd_una; - - return tp->westwood.cumul_ack; -} - - -/* - * @__tcp_westwood_slow_bw - * It is called when something is going wrong..even if there could - * be no problems! Infact a simple delayed packet may trigger a - * dupack. But we need to be careful in such case. - */ - -static void __tcp_westwood_slow_bw(struct sock *sk, struct sk_buff *skb) -{ - struct tcp_sock *tp = tcp_sk(sk); - - westwood_update_window(sk, tcp_time_stamp); - - tp->westwood.bk += westwood_acked_count(sk); - tp->westwood.rtt_min = westwood_update_rttmin(sk); -} - -static inline void tcp_westwood_slow_bw(struct sock *sk, struct sk_buff *skb) -{ - if (tcp_is_westwood(tcp_sk(sk))) - __tcp_westwood_slow_bw(sk, skb); -} /* This routine deals with incoming acks, but not outgoing ones. */ static int tcp_ack(struct sock *sk, struct sk_buff *skb, int flag) @@ -2899,9 +2267,10 @@ */ tcp_update_wl(tp, ack, ack_seq); tp->snd_una = ack; - tcp_westwood_fast_bw(sk, skb); flag |= FLAG_WIN_UPDATE; + tcp_ca_event(tp, CA_EVENT_FAST_ACK); + NET_INC_STATS_BH(LINUX_MIB_TCPHPACKS); } else { if (ack_seq != TCP_SKB_CB(skb)->end_seq) @@ -2917,7 +2286,7 @@ if (TCP_ECN_rcv_ecn_echo(tp, skb->h.th)) flag |= FLAG_ECE; - tcp_westwood_slow_bw(sk,skb); + tcp_ca_event(tp, CA_EVENT_SLOW_ACK); } /* We passed data and got it acked, remove any soft error @@ -2938,16 +2307,13 @@ tcp_process_frto(sk, prior_snd_una); if (tcp_ack_is_dubious(tp, flag)) { - /* Advanve CWND, if state allows this. */ - if ((flag & FLAG_DATA_ACKED) && - (tcp_vegas_enabled(tp) || prior_in_flight >= tp->snd_cwnd) && - tcp_may_raise_cwnd(tp, flag)) - tcp_cong_avoid(tp, ack, seq_rtt); + /* Advance CWND, if state allows this. */ + if ((flag & FLAG_DATA_ACKED) && tcp_may_raise_cwnd(tp, flag)) + tcp_cong_avoid(tp, ack, seq_rtt, prior_in_flight, 0); tcp_fastretrans_alert(sk, prior_snd_una, prior_packets, flag); } else { - if ((flag & FLAG_DATA_ACKED) && - (tcp_vegas_enabled(tp) || prior_in_flight >= tp->snd_cwnd)) - tcp_cong_avoid(tp, ack, seq_rtt); + if ((flag & FLAG_DATA_ACKED)) + tcp_cong_avoid(tp, ack, seq_rtt, prior_in_flight, 1); } if ((flag & FLAG_FORWARD_PROGRESS) || !(flag&FLAG_NOT_DUP)) @@ -4715,8 +4081,7 @@ if(tp->af_specific->conn_request(sk, skb) < 0) return 1; - init_westwood(sk); - init_bictcp(tp); + tcp_ca_init(tp); /* Now we have several options: In theory there is * nothing else in the frame. KA9Q has an option to @@ -4739,8 +4104,7 @@ goto discard; case TCP_SYN_SENT: - init_westwood(sk); - init_bictcp(tp); + tcp_ca_init(tp); queued = tcp_rcv_synsent_state_process(sk, skb, th, len); if (queued >= 0) diff -Nru a/net/ipv4/tcp_ipv4.c b/net/ipv4/tcp_ipv4.c --- a/net/ipv4/tcp_ipv4.c 2005-03-18 16:09:08 -08:00 +++ b/net/ipv4/tcp_ipv4.c 2005-03-18 16:09:08 -08:00 @@ -2058,7 +2058,6 @@ tp->snd_ssthresh = 0x7fffffff; /* Infinity */ tp->snd_cwnd_clamp = ~0; tp->mss_cache_std = tp->mss_cache = 536; - tp->reordering = sysctl_tcp_reordering; sk->sk_state = TCP_CLOSE; @@ -2081,6 +2080,8 @@ struct tcp_sock *tp = tcp_sk(sk); tcp_clear_xmit_timers(sk); + + tcp_ca_destroy(tp); /* Cleanup up the write buffer. */ sk_stream_writequeue_purge(sk); diff -Nru a/net/ipv4/tcp_output.c b/net/ipv4/tcp_output.c --- a/net/ipv4/tcp_output.c 2005-03-18 16:09:08 -08:00 +++ b/net/ipv4/tcp_output.c 2005-03-18 16:09:08 -08:00 @@ -111,8 +111,7 @@ u32 restart_cwnd = tcp_init_cwnd(tp, dst); u32 cwnd = tp->snd_cwnd; - if (tcp_is_vegas(tp)) - tcp_vegas_enable(tp); + tcp_ca_event(tp, CA_EVENT_CWND_RESTART); tp->snd_ssthresh = tcp_current_ssthresh(tp); restart_cwnd = min(restart_cwnd, cwnd); @@ -304,17 +303,9 @@ (tp->rx_opt.eff_sacks * TCPOLEN_SACK_PERBLOCK)); } - /* - * If the connection is idle and we are restarting, - * then we don't want to do any Vegas calculations - * until we get fresh RTT samples. So when we - * restart, we reset our Vegas state to a clean - * slate. After we get acks for this flight of - * packets, _then_ we can make Vegas calculations - * again. - */ - if (tcp_is_vegas(tp) && tcp_packets_in_flight(tp) == 0) - tcp_vegas_enable(tp); + if (tcp_packets_in_flight(tp) == 0 && + tp->ca_proto && tp->ca_proto->cwnd_event) + tp->ca_proto->cwnd_event(tp, CA_EVENT_TX_START); th = (struct tcphdr *) skb_push(skb, tcp_header_size); skb->h.th = th; diff -Nru a/net/ipv4/tcp_reno.c b/net/ipv4/tcp_reno.c --- /dev/null Wed Dec 31 16:00:00 196900 +++ b/net/ipv4/tcp_reno.c 2005-03-18 16:09:08 -08:00 @@ -0,0 +1,64 @@ +/* + * TCP Reno congestion control + * + * This is special case used for fallback as well. + */ + +#include +#include +#include +#include + +/* This is Jacobson's slow start and congestion avoidance. + * SIGCOMM '88, p. 328. + */ +u32 tcp_reno_ssthresh(struct tcp_sock *tp) +{ + return max(tp->snd_cwnd >> 1U, 2U); +} +EXPORT_SYMBOL_GPL(tcp_reno_ssthresh); + +void tcp_reno_cong_avoid(struct tcp_sock *tp, u32 ack, u32 rtt, u32 in_flight, + int flag) +{ + if (in_flight < tp->snd_cwnd) + return; + + if (tp->snd_cwnd <= tp->snd_ssthresh) { + /* In "safe" area, increase. */ + if (tp->snd_cwnd < tp->snd_cwnd_clamp) + tp->snd_cwnd++; + } else { + /* In dangerous area, increase slowly. + * In theory this is tp->snd_cwnd += 1 / tp->snd_cwnd + */ + if (tp->snd_cwnd_cnt >= tp->snd_cwnd) { + if (tp->snd_cwnd < tp->snd_cwnd_clamp) + tp->snd_cwnd++; + tp->snd_cwnd_cnt = 0; + } else + tp->snd_cwnd_cnt++; + } +} +EXPORT_SYMBOL_GPL(tcp_reno_cong_avoid); + +u32 tcp_reno_cwnd_min(struct tcp_sock *tp) +{ + return tp->snd_ssthresh/2; +} +EXPORT_SYMBOL_GPL(tcp_reno_cwnd_min); + +static void tcp_reno_start(struct tcp_sock *tp) +{ + return; +} + +struct tcp_ca_type tcp_reno = { + .start = tcp_reno_start, + .ssthresh = tcp_reno_ssthresh, + .min_cwnd = tcp_reno_cwnd_min, + .cong_avoid = tcp_reno_cong_avoid, + + .owner = THIS_MODULE, + .name = "reno", +}; From shemminger@osdl.org Fri Mar 18 16:34:51 2005 Received: with ECARTIS (v1.0.0; list netdev); Fri, 18 Mar 2005 16:35:13 -0800 (PST) Received: from smtp.osdl.org (fire.osdl.org [65.172.181.4]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j2J0YpZb031156 for ; Fri, 18 Mar 2005 16:34:51 -0800 Received: from shell0.pdx.osdl.net (fw.osdl.org [65.172.181.6]) by smtp.osdl.org (8.12.8/8.12.8) with ESMTP id j2J0V5qi017035 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO); Fri, 18 Mar 2005 16:31:06 -0800 Received: from dxpl.pdx.osdl.net (dxpl.pdx.osdl.net [172.20.1.103]) by shell0.pdx.osdl.net (8.13.1/8.11.6) with ESMTP id j2J0V51Q029595; Fri, 18 Mar 2005 16:31:05 -0800 Date: Fri, 18 Mar 2005 16:31:23 -0800 From: Stephen Hemminger To: "David S. Miller" , Daniele Lacamera Cc: netdev@oss.sgi.com Subject: [PATCH] TCP Hybla Message-ID: <20050318163123.14969084@dxpl.pdx.osdl.net> Organization: Open Source Development Lab X-Mailer: Sylpheed-Claws 1.0.1 (GTK+ 1.2.10; x86_64-unknown-linux-gnu) X-Face: &@E+xe?c%:&e4D{>f1O<&U>2qwRREG5!}7R4;D<"NO^UI2mJ[eEOA2*3>(`Th.yP,VDPo9$ /`~cw![cmj~~jWe?AHY7D1S+\}5brN0k*NE?pPh_'_d>6;XGG[\KDRViCfumZT3@[ Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Received-SPF: pass (domain of shemminger@osdl.org designates 65.172.181.6 as permitted sender) X-MIMEDefang-Filter: osdl$Revision: 1.105 $ X-Scanned-By: MIMEDefang 2.36 X-Virus-Scanned: ClamAV 0.83/772/Fri Mar 18 00:59:17 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 343 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: shemminger@osdl.org Precedence: bulk X-list: netdev Content-Length: 6527 Lines: 235 Here is a version of TCP Hybla based on the new split out of TCP algorithms. It doesn't work right, I probably broke something. Original code for RTT0 was wrong because HZ=1000 on 2.6, so I changed it to be a parameter explicitly in ms. Don't put it into production system till worked out. diff -Nru a/net/ipv4/Kconfig b/net/ipv4/Kconfig --- a/net/ipv4/Kconfig 2005-03-18 16:11:27 -08:00 +++ b/net/ipv4/Kconfig 2005-03-18 16:11:27 -08:00 @@ -417,6 +417,16 @@ increase the congestion window by when an ACK is received. For more detail see http://www.icir.org/floyd/hstcp.html +config TCP_CONG_HYBLA + tristate "TCP-Hybla congestion control algorithm" + depends on EXPERIMENTAL + default n + ---help--- + TCP-Hybla is a sender-side only change that eliminates penalization of + long-RTT, large-bandwidth connections, like when satellite legs are + involved, expecially when sharing a common bottleneck with normal + terrestrial connections. + endmenu source "net/ipv4/ipvs/Kconfig" diff -Nru a/net/ipv4/Makefile b/net/ipv4/Makefile --- a/net/ipv4/Makefile 2005-03-18 16:11:27 -08:00 +++ b/net/ipv4/Makefile 2005-03-18 16:11:27 -08:00 @@ -28,6 +28,7 @@ obj-$(CONFIG_TCP_CONG_WESTWOOD) += tcp_westwood.o obj-$(CONFIG_TCP_CONG_VEGAS) += tcp_vegas.o obj-$(CONFIG_TCP_CONG_HSTCP) += tcp_hstcp.o +obj-$(CONFIG_TCP_CONG_HYBLA) += tcp_hybla.o obj-$(CONFIG_XFRM) += xfrm4_policy.o xfrm4_state.o xfrm4_input.o \ xfrm4_output.o diff -Nru a/net/ipv4/tcp_hybla.c b/net/ipv4/tcp_hybla.c --- /dev/null Wed Dec 31 16:00:00 196900 +++ b/net/ipv4/tcp_hybla.c 2005-03-18 16:11:27 -08:00 @@ -0,0 +1,191 @@ +/* + * TCP HYBLA + * + * TCP-HYBLA Congestion control algorithm, based on: + * C.Caini, R.Firrincieli, "TCP-Hybla: A TCP Enhancement + * for Heterogeneous Networks", + * International Journal on satellite Communications, + * September 2004 + * Daniele Lacamera + * root at danielinux.net + */ + +#include +#include +#include + +/* Tcp Hybla structure. */ +struct hybla_ca { + u32 snd_cwnd_cents; /* Keeps increment values when it is <1, <<7 */ + u32 rho; /* Rho parameter, integer part */ + u32 rho2; /* Rho * Rho, integer part */ + u32 rho_3ls; /* Rho parameter, <<3 */ + u32 rho2_7ls; /* Rho^2, <<7 */ + u32 minrtt; /* Minimum smoothed round trip time value seen */ +}; + +/* Hybla reference round trip time (default= 1/40 sec = 25 ms), + expressed in jiffies */ +static int rtt0 = 25; +module_param(rtt0, int, 0644); +MODULE_PARM_DESC(rtt0, "reference rout trip time (ms)"); + + +/* This is called to refresh values for hybla parameters */ +static inline void hybla_recalc_param (struct tcp_sock *tp) +{ + struct hybla_ca *ca = tcp_ca(tp); + + ca->rho_3ls = max_t(u32, tp->srtt / msecs_to_jiffies(rtt0), 8); + ca->rho = ca->rho_3ls >> 3; + ca->rho2_7ls = (ca->rho_3ls * ca->rho_3ls) << 1; + ca->rho2 = ca->rho2_7ls >>7; + + tp->snd_cwnd_clamp = min_t(u16, tp->snd_cwnd_clamp, ca->rho << 16); +} + + +static void hybla_start(struct tcp_sock *tp) +{ + struct hybla_ca *ca = tcp_ca(tp); + + ca->rho = 0; + ca->rho2 = 0; + ca->rho_3ls = 0; + ca->rho2_7ls = 0; + ca->snd_cwnd_cents = 0; + + tp->snd_cwnd = 2; +} + + +static inline u32 hybla_fraction(u32 odds) +{ + static const u32 fractions[] = { + 128, 139, 152, 165, 181, 197, 215, 234, + }; + + return (odds < ARRAY_SIZE(fractions)) ? fractions[odds] : 128; +} + +/* TCP Hybla main routine. + * This is the algorithm behavior: + * o Recalc Hybla parameters if min_rtt has changed + * o Give cwnd a new value based on the model proposed + * o remember increments <1 + */ +static void hybla_cong_avoid(struct tcp_sock *tp, u32 ack, u32 rtt, + u32 in_flight, int good) +{ + struct hybla_ca *ca = tcp_ca(tp); + u32 increment, odd, rho_fractions; + int is_slowstart = 0; + + if (ca->rho==0) + hybla_recalc_param(tp); + + rho_fractions = ca->rho_3ls - (ca->rho << 3); + + if (tp->snd_cwnd < tp->snd_ssthresh) { + /* + * slow start + * INC = 2^RHO - 1 + * This is done by splitting the rho parameter + * into 2 parts: an integer part and a fraction part. + * Inrement<<7 is estimated by doing: + * [2^(int+fract)]<<7 + * that is equal to: + * (2^int) * [(2^fract) <<7] + * 2^int is straightly computed as 1<rho) * hybla_fraction(rho_fractions)) + - 128; + } else { + /* + * congestion avoidance + * INC = RHO^2 / W + * as long as increment is estimated as (rho<<7)/window + * it already is <<7 and we can easily count its fractions. + */ + increment = ca->rho2_7ls / tp->snd_cwnd; + if (increment < 128) + tp->snd_cwnd_cnt++; + } + + odd = increment % 128; + tp->snd_cwnd += increment >> 7; + ca->snd_cwnd_cents += odd; + + /* check when fractions goes >=128 and increase cwnd by 1. */ + while(ca->snd_cwnd_cents >= 128) { + tp->snd_cwnd++; + ca->snd_cwnd_cents -= 128; + tp->snd_cwnd_cnt = 0; + } + + /*clamp down slowstart cwnd to ssthresh value. */ + if (is_slowstart) + tp->snd_cwnd = min(tp->snd_cwnd, tp->snd_ssthresh); + + tp->snd_cwnd = min_t(u32, tp->snd_cwnd, tp->snd_cwnd_clamp); +} + +/* + * Update Values, if necessary, when a new + * smoothed RTT Estimation becomes available + */ +static void hybla_update_rtt(struct tcp_sock *tp, u32 m) +{ + struct hybla_ca *ca = tcp_ca(tp); + + /* This sets rho to the smallest RTT received. */ + if (tp->srtt) { + /* Recalculate rho only if this srtt is the lowest */ + if (tp->srtt < ca->minrtt){ + hybla_recalc_param(tp); + ca->minrtt = tp->srtt; + } + } else { + /* 1st Rho measurement */ + hybla_recalc_param(tp); + + /* set minimum rtt as this is the 1st ever seen */ + ca->minrtt = tp->srtt; + tp->snd_cwnd = ca->rho; + } +} + + + +static struct tcp_ca_type tcp_hybla = { + .start = hybla_start, + .ssthresh = tcp_reno_ssthresh, + .min_cwnd = tcp_reno_cwnd_min, + .cong_avoid = hybla_cong_avoid, + .rtt_sample = hybla_update_rtt, + + .owner = THIS_MODULE, + .name = "hybla" +}; + +static int __init hybla_init(void) +{ + BUG_ON(sizeof(struct hybla_ca) > TCP_CA_PRIV_SIZE); + tcp_ca_register(&tcp_hybla); + return 0; +} + +static void __exit hybla_exit(void) +{ + tcp_ca_unregister(&tcp_hybla); +} + +module_init(hybla_init); +module_exit(hybla_exit); + +MODULE_AUTHOR("Daniele Lacmera"); +MODULE_LICENSE("GPL"); +MODULE_DESCRIPTION("High Speed TCP"); From chrisw@osdl.org Fri Mar 18 17:03:04 2005 Received: with ECARTIS (v1.0.0; list netdev); Fri, 18 Mar 2005 17:03:09 -0800 (PST) Received: from smtp.osdl.org (fire.osdl.org [65.172.181.4]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j2J133lf000766 for ; Fri, 18 Mar 2005 17:03:03 -0800 Received: from shell0.pdx.osdl.net (fw.osdl.org [65.172.181.6]) by smtp.osdl.org (8.12.8/8.12.8) with ESMTP id j2J12rqi019017 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO); Fri, 18 Mar 2005 17:02:54 -0800 Received: from shell0.pdx.osdl.net (localhost [127.0.0.1]) by shell0.pdx.osdl.net (8.13.1/8.11.6) with ESMTP id j2J12rtQ030900; Fri, 18 Mar 2005 17:02:53 -0800 Received: (from chrisw@localhost) by shell0.pdx.osdl.net (8.13.1/8.13.1/Submit) id j2J12rZD030899; Fri, 18 Mar 2005 17:02:53 -0800 Date: Fri, 18 Mar 2005 17:02:53 -0800 From: Chris Wright To: Max Krasnyansky Cc: Chris Wright , davem@davemloft.net, netdev@oss.sgi.com Subject: Re: [PATCH] remove unused netlink NL_EMULATE_DEV code Message-ID: <20050319010253.GU5389@shell0.pdx.osdl.net> References: <20050318233637.GS5389@shell0.pdx.osdl.net> <423B6DAE.9050803@qualcomm.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <423B6DAE.9050803@qualcomm.com> User-Agent: Mutt/1.5.6i Received-SPF: pass (domain of chrisw@osdl.org designates 65.172.181.6 as permitted sender) X-MIMEDefang-Filter: osdl$Revision: 1.105 $ X-Scanned-By: MIMEDefang 2.36 X-Virus-Scanned: ClamAV 0.83/772/Fri Mar 18 00:59:17 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 344 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: chrisw@osdl.org Precedence: bulk X-list: netdev Content-Length: 421 Lines: 12 * Max Krasnyansky (maxk@qualcomm.com) wrote: > Why don't you kill Ethertap completely while you're at it. Ethertap needs > "Netlink device emulation" > stuff. And this whole thing has been marked OBSOLETE for more than two > years now. > Most projects seem to have switched to TUN/TAP long time ago. I'd prefer that too. What about the netlink_dev implementation itself? Should it be marked obsolete? thanks, -chris From andy.furniss@dsl.pipex.com Fri Mar 18 17:09:28 2005 Received: with ECARTIS (v1.0.0; list netdev); Fri, 18 Mar 2005 17:09:34 -0800 (PST) Received: from astro.systems.pipex.net (astro.systems.pipex.net [62.241.163.6]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j2J19NvJ001526 for ; Fri, 18 Mar 2005 17:09:28 -0800 Received: from [192.168.0.3] (81-178-208-114.dsl.pipex.com [81.178.208.114]) by astro.systems.pipex.net (Postfix) with ESMTP id 68D6FE0000B9; Sat, 19 Mar 2005 01:09:11 +0000 (GMT) Message-ID: <423B7BCB.10400@dsl.pipex.com> Date: Sat, 19 Mar 2005 01:09:31 +0000 From: Andy Furniss User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.8a6) Gecko/20050111 X-Accept-Language: en-us, en MIME-Version: 1.0 To: hadi@cyberus.ca CC: Remus , netdev@oss.sgi.com, Nguyen Dinh Nam , Andre Tomt , syrius.ml@no-log.org, Damion de Soto Subject: Re: dummy as IMQ replacement References: <1107123123.8021.80.camel@jzny.localdomain> <0fcf01c5077f$579e4b80$6e69690a@RIMAS> <1107174142.8021.121.camel@jzny.localdomain> <00c301c524b4$938cd240$6e69690a@RIMAS> <1110379135.1091.143.camel@jzny.localdomain> <1110416767.1111.76.camel@jzny.localdomain> <025501c52552$2dbf87c0$6e69690a@RIMAS> <1110453757.1108.87.camel@jzny.localdomain> In-Reply-To: <1110453757.1108.87.camel@jzny.localdomain> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV 0.83/772/Fri Mar 18 00:59:17 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 345 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: andy.furniss@dsl.pipex.com Precedence: bulk X-list: netdev Content-Length: 2317 Lines: 93 jamal wrote: > Hi Remus, > I could not reproduce this one - it is also a bit odd for calloc to > fail. I dont have iptables 1.3.1 but i will get and retry. > Does this happen all the time? I get the same with iptables 1.3.1 and 1.3.0 iptables: calloc failed: Cannot allocate memory using kernel 2.6.11.3 and tc iproute2-ss050314 If I try an earlier iptables (tested 9, 10, 11) I get tablename: mangle hook: NF_IP_PRE_ROUTING target: MARK set 0x1 index 0 bad action type mirred Usage: ... gact [RAND] [INDEX] Where: ACTION := reclassify | drop | continue | pass RAND := random RANDTYPE := netrand | determVAL : = value not exceeding 10000INDEX := index value used bad action parsing parse_action: bad value (5:mirred)! Illegal "action" Andy. > cheers, > jamal > > On Thu, 2005-03-10 at 04:18, Remus wrote: > >>Hi Jamal, >> >>Thanks for the patch. >>That error is gone but I got a new error: >> >>ifconfig dummy0 up >>tc qdisc add dev eth2 ingress >>tc filter add dev eth2 parent ffff: protocol ip prio 10 u32 match u32 0 0 >>flowid 1:1 action ipt -j MARK --set-mark 1 action mirred egress redirect dev >>dummy0 >>iptables: calloc failed: Cannot allocate memory >> >>I use 2.6.11.2 kernel patched with your dummy patch, iptables 1.3.1 and the >>latest iproute2 patched with the pacth you sent yesterday. >> >> >>Regards >> >>Remus >> >> >>----- Original Message ----- >>From: "Jamal Hadi Salim" >>To: "Remus" >>Cc: ; "Nguyen Dinh Nam" ; >>"Andre Tomt" ; ; "Andy Furniss" >>; "Damion de Soto" >>Sent: Thursday, March 10, 2005 1:06 AM >>Subject: Re: dummy as IMQ replacement >> >> >> >>>Hi Remus, >>> >>>Please try this patch on top of latest iproute2. Credit to Patrick for >>>spoting it. I dont know when or who made this change - in any case it >>>doesnt matter if it works for you. >>> >>>cheers, >>> >>>On Wed, 2005-03-09 at 09:38, jamal wrote: >>> >>> >>>>I have to go to work - so wont have time to look at this for sometime. >>>>Maybe some of the netfilter folks like Patrick can solve it for you >>>>before i get back. >>>> >>>>cheers, >>>>jamal >>>> >>> >> >> >> > > > From hadi@cyberus.ca Fri Mar 18 17:46:04 2005 Received: with ECARTIS (v1.0.0; list netdev); Fri, 18 Mar 2005 17:46:10 -0800 (PST) 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 j2J1k4ha002940 for ; Fri, 18 Mar 2005 17:46:04 -0800 Received: from [127.0.0.1] ([208.2.156.2]) by lotus.znyx.com (Lotus Domino Release 5.0.11) with ESMTP id 2005031817470315:17064 ; Fri, 18 Mar 2005 17:47:03 -0800 Subject: Re: dummy as IMQ replacement From: jamal Reply-To: hadi@cyberus.ca To: Andy Furniss Cc: Remus , netdev@oss.sgi.com, Nguyen Dinh Nam , Andre Tomt , syrius.ml@no-log.org, Damion de Soto In-Reply-To: <423B7BCB.10400@dsl.pipex.com> References: <1107123123.8021.80.camel@jzny.localdomain> <0fcf01c5077f$579e4b80$6e69690a@RIMAS> <1107174142.8021.121.camel@jzny.localdomain> <00c301c524b4$938cd240$6e69690a@RIMAS> <1110379135.1091.143.camel@jzny.localdomain> <1110416767.1111.76.camel@jzny.localdomain> <025501c52552$2dbf87c0$6e69690a@RIMAS> <1110453757.1108.87.camel@jzny.localdomain> <423B7BCB.10400@dsl.pipex.com> Organization: jamalopolis Message-Id: <1111196668.1146.114.camel@jzny.localdomain> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.2.2 Date: 18 Mar 2005 20:45:33 -0500 X-MIMETrack: Itemize by SMTP Server on Lotus/Znyx(Release 5.0.11 |July 24, 2002) at 03/18/2005 05:47:03 PM, Serialize by Router on Lotus/Znyx(Release 5.0.11 |July 24, 2002) at 03/18/2005 05:47:13 PM, Serialize complete at 03/18/2005 05:47:13 PM Content-Transfer-Encoding: 7bit Content-Type: text/plain X-Virus-Scanned: ClamAV 0.83/772/Fri Mar 18 00:59:17 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 346 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: hadi@cyberus.ca Precedence: bulk X-list: netdev Content-Length: 2796 Lines: 106 Remus seems to have got it working with iptables earlier than 1.3.0 works fine. Unfortunately i am not close to my machines and wont be for a while. Can you try not to pass mirred in the command line and see if that works? cheers, jamal On Fri, 2005-03-18 at 20:09, Andy Furniss wrote: > jamal wrote: > > Hi Remus, > > I could not reproduce this one - it is also a bit odd for calloc to > > fail. I dont have iptables 1.3.1 but i will get and retry. > > Does this happen all the time? > > I get the same with iptables 1.3.1 and 1.3.0 > > iptables: calloc failed: Cannot allocate memory > > using kernel 2.6.11.3 and tc iproute2-ss050314 > > If I try an earlier iptables (tested 9, 10, 11) I get > > tablename: mangle hook: NF_IP_PRE_ROUTING > target: MARK set 0x1 index 0 > bad action type mirred > Usage: ... gact [RAND] [INDEX] > Where: ACTION := reclassify | drop | continue | pass RAND := random > RANDTYPE := netrand | determVAL : = value not > exceeding 10000INDEX := index value used > bad action parsing > parse_action: bad value (5:mirred)! > Illegal "action" > > Andy. > > > > > > cheers, > > jamal > > > > On Thu, 2005-03-10 at 04:18, Remus wrote: > > > >>Hi Jamal, > >> > >>Thanks for the patch. > >>That error is gone but I got a new error: > >> > >>ifconfig dummy0 up > >>tc qdisc add dev eth2 ingress > >>tc filter add dev eth2 parent ffff: protocol ip prio 10 u32 match u32 0 0 > >>flowid 1:1 action ipt -j MARK --set-mark 1 action mirred egress redirect dev > >>dummy0 > >>iptables: calloc failed: Cannot allocate memory > >> > >>I use 2.6.11.2 kernel patched with your dummy patch, iptables 1.3.1 and the > >>latest iproute2 patched with the pacth you sent yesterday. > >> > >> > >>Regards > >> > >>Remus > >> > >> > >>----- Original Message ----- > >>From: "Jamal Hadi Salim" > >>To: "Remus" > >>Cc: ; "Nguyen Dinh Nam" ; > >>"Andre Tomt" ; ; "Andy Furniss" > >>; "Damion de Soto" > >>Sent: Thursday, March 10, 2005 1:06 AM > >>Subject: Re: dummy as IMQ replacement > >> > >> > >> > >>>Hi Remus, > >>> > >>>Please try this patch on top of latest iproute2. Credit to Patrick for > >>>spoting it. I dont know when or who made this change - in any case it > >>>doesnt matter if it works for you. > >>> > >>>cheers, > >>> > >>>On Wed, 2005-03-09 at 09:38, jamal wrote: > >>> > >>> > >>>>I have to go to work - so wont have time to look at this for sometime. > >>>>Maybe some of the netfilter folks like Patrick can solve it for you > >>>>before i get back. > >>>> > >>>>cheers, > >>>>jamal > >>>> > >>> > >> > >> > >> > > > > > > > > From hadi@cyberus.ca Fri Mar 18 17:48:42 2005 Received: with ECARTIS (v1.0.0; list netdev); Fri, 18 Mar 2005 17:48:46 -0800 (PST) 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 j2J1mfZA003387 for ; Fri, 18 Mar 2005 17:48:42 -0800 Received: from [127.0.0.1] ([208.2.156.2]) by lotus.znyx.com (Lotus Domino Release 5.0.11) with ESMTP id 2005031817495004:17070 ; Fri, 18 Mar 2005 17:49:50 -0800 Subject: Re: [PATCH] remove unused netlink NL_EMULATE_DEV code From: jamal Reply-To: hadi@cyberus.ca To: Chris Wright Cc: Max Krasnyansky , "David S. Miller" , netdev@oss.sgi.com In-Reply-To: <20050319010253.GU5389@shell0.pdx.osdl.net> References: <20050318233637.GS5389@shell0.pdx.osdl.net> <423B6DAE.9050803@qualcomm.com> <20050319010253.GU5389@shell0.pdx.osdl.net> Organization: jamalopolis Message-Id: <1111196899.1264.118.camel@jzny.localdomain> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.2.2 Date: 18 Mar 2005 20:48:20 -0500 X-MIMETrack: Itemize by SMTP Server on Lotus/Znyx(Release 5.0.11 |July 24, 2002) at 03/18/2005 05:49:50 PM, Serialize by Router on Lotus/Znyx(Release 5.0.11 |July 24, 2002) at 03/18/2005 05:49:51 PM, Serialize complete at 03/18/2005 05:49:51 PM Content-Transfer-Encoding: 7bit Content-Type: text/plain X-Virus-Scanned: ClamAV 0.83/772/Fri Mar 18 00:59:17 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 347 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: hadi@cyberus.ca Precedence: bulk X-list: netdev Content-Length: 247 Lines: 14 1 On Fri, 2005-03-18 at 20:02, Chris Wright wrote: > I'd prefer that too. What about the netlink_dev implementation itself? > Should it be marked obsolete? > It should die - pieces of it have already been slowly disapearing. cheers, jamal From baruch@ev-en.org Fri Mar 18 18:17:26 2005 Received: with ECARTIS (v1.0.0; list netdev); Fri, 18 Mar 2005 18:17:30 -0800 (PST) Received: from galon.ev-en.org (rrcs-24-123-59-149.central.biz.rr.com [24.123.59.149]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j2J2HLi4004867 for ; Fri, 18 Mar 2005 18:17:26 -0800 Received: by galon.ev-en.org (Postfix, from userid 105) id 8AE6511A607; Sat, 19 Mar 2005 04:16:58 +0200 (IST) Received: from [10.220.3.66] (hamilton.nuim.ie [149.157.192.252]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by galon.ev-en.org (Postfix) with ESMTP id 47EC911A5A3; Sat, 19 Mar 2005 04:16:49 +0200 (IST) Message-ID: <423B8B88.70504@ev-en.org> Date: Sat, 19 Mar 2005 02:16:40 +0000 From: Baruch Even User-Agent: Debian Thunderbird 1.0 (X11/20050116) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Stephen Hemminger Cc: Andrew Morton , "David S. Miller" , netdev@oss.sgi.com, Injong Rhee Subject: Re: [PATCH 1/5] TCP infrastructure split out References: <20050318162221.501ff05a@dxpl.pdx.osdl.net> In-Reply-To: <20050318162221.501ff05a@dxpl.pdx.osdl.net> X-Enigmail-Version: 0.90.0.0 X-Enigmail-Supports: pgp-inline, pgp-mime Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV 0.83/772/Fri Mar 18 00:59:17 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 348 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: baruch@ev-en.org Precedence: bulk X-list: netdev Content-Length: 717 Lines: 25 Stephen Hemminger wrote: > @@ -1356,7 +1301,7 @@ > static inline void __tcp_enter_cwr(struct tcp_sock *tp) > { > tp->undo_marker = 0; > - tp->snd_ssthresh = tcp_recalc_ssthresh(tp); > + tp->snd_ssthresh = tp->ca_proto->ssthresh(tp); > +void tcp_ca_register(struct tcp_ca_type *ca) > +{ > + BUG_ON(tcp_ca_find(ca->name)); > + > + spin_lock_irq(&tcp_ca_list_lock); > + list_add_tail_rcu(&ca->list, &tcp_ca_list); > + spin_unlock_irq(&tcp_ca_list_lock); > + > + printk(KERN_INFO "TCP %s registered\n", ca->name); > +} Since we have some calls to callbacks unprotected, shouldn't we check them on tcp_ca_register to make sure they are in fact available so that we don't needlessly crash? Baruch From baruch@ev-en.org Fri Mar 18 18:53:20 2005 Received: with ECARTIS (v1.0.0; list netdev); Fri, 18 Mar 2005 18:53:25 -0800 (PST) Received: from galon.ev-en.org (rrcs-24-123-59-149.central.biz.rr.com [24.123.59.149]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j2J2rKKR006100 for ; Fri, 18 Mar 2005 18:53:20 -0800 Received: by galon.ev-en.org (Postfix, from userid 105) id AECBA11A607; Sat, 19 Mar 2005 04:53:14 +0200 (IST) Received: from [10.220.3.66] (hamilton.nuim.ie [149.157.192.252]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by galon.ev-en.org (Postfix) with ESMTP id 7875C11A5A3; Sat, 19 Mar 2005 04:53:11 +0200 (IST) Message-ID: <423B9415.2010906@ev-en.org> Date: Sat, 19 Mar 2005 02:53:09 +0000 From: Baruch Even User-Agent: Debian Thunderbird 1.0 (X11/20050116) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Stephen Hemminger Cc: Andrew Morton , "David S. Miller" , netdev@oss.sgi.com, Injong Rhee Subject: Re: [PATCH 2/5] TCP BIC 1.1 support References: <20050318162211.366ca490@dxpl.pdx.osdl.net> In-Reply-To: <20050318162211.366ca490@dxpl.pdx.osdl.net> X-Enigmail-Version: 0.90.0.0 X-Enigmail-Supports: pgp-inline, pgp-mime Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV 0.83/772/Fri Mar 18 00:59:17 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 349 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: baruch@ev-en.org Precedence: bulk X-list: netdev Content-Length: 670 Lines: 20 Stephen Hemminger wrote: > This patch adds TCP BIC back in as a pluggable TCP congestion mechanism. > This version is closer to the TCP BIC 1.1 released for Web100. > The changes from 2.6.11 are: > * congestion window undo fix > * delayed ack compensation This can cause overshooting if the other side doesn't do delayed acking, did anyone consider the ABC (Appropriate Byte Counting) patch from Yee-Ting Li? http://marc.theaimsgroup.com/?l=linux-netdev&m=110917262615630&w=2 FreeBSD has an option to disable delayed acking so it's not that hard to work against a host with no delayed acks at all. > + /* slow start AMD linear increase */ AIMD maybe? Baruch From oxymoron@waste.org Fri Mar 18 19:13:41 2005 Received: with ECARTIS (v1.0.0; list netdev); Fri, 18 Mar 2005 19:13:46 -0800 (PST) Received: from waste.org (waste.org [216.27.176.166]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j2J3DbWh007122 for ; Fri, 18 Mar 2005 19:13:41 -0800 Received: from waste.org (localhost [127.0.0.1]) by waste.org (8.13.2/8.13.2/Debian-1) with ESMTP id j2J3DMWe026329 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Fri, 18 Mar 2005 21:13:22 -0600 Received: (from oxymoron@localhost) by waste.org (8.13.2/8.13.2/Submit) id j2J3DLoZ026326; Fri, 18 Mar 2005 21:13:21 -0600 Date: Fri, 18 Mar 2005 19:13:21 -0800 From: Matt Mackall To: Francois Romieu Cc: Alexander Nyberg , jgarzik@pobox.com, netdev@oss.sgi.com, davem@davemloft.net Subject: Re: Reproducible panics with tulip Message-ID: <20050319031321.GA25554@waste.org> References: <1111178167.1147.9.camel@localhost.localdomain> <20050318215229.GA24509@electric-eye.fr.zoreil.com> <20050318223939.GB24509@electric-eye.fr.zoreil.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20050318223939.GB24509@electric-eye.fr.zoreil.com> User-Agent: Mutt/1.5.6+20040907i X-Virus-Scanned: ClamAV 0.83/772/Fri Mar 18 00:59:17 2005 on oss.sgi.com X-Virus-Scanned: by amavisd-new X-Virus-Status: Clean X-archive-position: 350 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: mpm@selenic.com Precedence: bulk X-list: netdev Content-Length: 776 Lines: 23 On Fri, Mar 18, 2005 at 11:39:39PM +0100, Francois Romieu wrote: > > zap_completion_queue can be called in any context through netpoll_send_udp. > > Signed-off-by: Francois Romieu > > diff -puN net/core/netpoll.c~netconsole-000 net/core/netpoll.c > --- a/net/core/netpoll.c~netconsole-000 2005-03-18 23:29:28.499641348 +0100 > +++ b/net/core/netpoll.c 2005-03-18 23:33:13.856959994 +0100 > @@ -142,7 +142,7 @@ static void zap_completion_queue(void) > while (clist != NULL) { > struct sk_buff *skb = clist; > clist = clist->next; > - __kfree_skb(skb); > + dev_kfree_skb_any(skb); > } > } Please, cc: me on such things. I sent this fix a while back, but DaveM never acked it. -- Mathematics is the supreme nostalgia of our time. From davem@davemloft.net Fri Mar 18 19:48:18 2005 Received: with ECARTIS (v1.0.0; list netdev); Fri, 18 Mar 2005 19:48:23 -0800 (PST) Received: from cheetah.davemloft.net (mail@dsl027-180-174.sfo1.dsl.speakeasy.net [216.27.180.174]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j2J3mIMW009026 for ; Fri, 18 Mar 2005 19:48:18 -0800 Received: from localhost ([127.0.0.1] helo=cheetah.davemloft.net ident=davem) by cheetah.davemloft.net with smtp (Exim 3.36 #1 (Debian)) id 1DCUwK-0001cq-00; Fri, 18 Mar 2005 19:47:52 -0800 Date: Fri, 18 Mar 2005 19:47:51 -0800 From: "David S. Miller" To: Matt Mackall Cc: romieu@fr.zoreil.com, alexn@dsv.su.se, jgarzik@pobox.com, netdev@oss.sgi.com Subject: Re: Reproducible panics with tulip Message-Id: <20050318194751.3fade099.davem@davemloft.net> In-Reply-To: <20050319031321.GA25554@waste.org> References: <1111178167.1147.9.camel@localhost.localdomain> <20050318215229.GA24509@electric-eye.fr.zoreil.com> <20050318223939.GB24509@electric-eye.fr.zoreil.com> <20050319031321.GA25554@waste.org> X-Mailer: Sylpheed version 1.0.1 (GTK+ 1.2.10; sparc-unknown-linux-gnu) X-Face: "_;p5u5aPsO,_Vsx"^v-pEq09'CU4&Dc1$fQExov$62l60cgCc%FnIwD=.UF^a>?5'9Kn[;433QFVV9M..2eN.@4ZWPGbdi<=?[:T>y?SD(R*-3It"Vj:)"dP Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV 0.83/772/Fri Mar 18 00:59:17 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 351 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: davem@davemloft.net Precedence: bulk X-list: netdev Content-Length: 197 Lines: 7 On Fri, 18 Mar 2005 19:13:21 - Matt Mackall wrote: > Please, cc: me on such things. I sent this fix a while back, but DaveM > never acked it. It's in my backlog, never fear :-) From jdmason@us.ibm.com Fri Mar 18 21:34:07 2005 Received: with ECARTIS (v1.0.0; list netdev); Fri, 18 Mar 2005 21:34:13 -0800 (PST) Received: from e31.co.us.ibm.com (e31.co.us.ibm.com [32.97.110.129]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j2J5Y0Ao015866 for ; Fri, 18 Mar 2005 21:34:07 -0800 Received: from westrelay01.boulder.ibm.com (westrelay01.boulder.ibm.com [9.17.195.10]) by e31.co.us.ibm.com (8.12.10/8.12.9) with ESMTP id j2J5Xsua314740 for ; Sat, 19 Mar 2005 00:33:54 -0500 Received: from d03av01.boulder.ibm.com (d03av01.boulder.ibm.com [9.17.195.167]) by westrelay01.boulder.ibm.com (8.12.10/NCO/VER6.6) with ESMTP id j2J5Xsx0190054 for ; Fri, 18 Mar 2005 22:33:54 -0700 Received: from d03av01.boulder.ibm.com (loopback [127.0.0.1]) by d03av01.boulder.ibm.com (8.12.11/8.12.11) with ESMTP id j2J5Xr7C032173 for ; Fri, 18 Mar 2005 22:33:54 -0700 Received: from sig-9-65-41-173.mts.ibm.com (sig-9-65-41-173.mts.ibm.com [9.65.41.173]) by d03av01.boulder.ibm.com (8.12.11/8.12.11) with ESMTP id j2J5XrJI032162; Fri, 18 Mar 2005 22:33:53 -0700 From: Jon Mason Organization: IBM To: Ben Greear Subject: Re: Network card driver problem (znb.o/tulip) Date: Fri, 18 Mar 2005 23:33:51 -0600 User-Agent: KMail/1.7.2 Cc: Kosta Todorovic , jgarzik@pobox.com, tulip-users@lists.sourceforge.net, netdev@oss.sgi.com References: <423133F7.7040400@candelatech.com> In-Reply-To: <423133F7.7040400@candelatech.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200503182333.51470.jdmason@us.ibm.com> X-Virus-Scanned: ClamAV 0.83/772/Fri Mar 18 00:59:17 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 352 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: jdmason@us.ibm.com Precedence: bulk X-list: netdev Content-Length: 1879 Lines: 46 On Friday 11 March 2005 12:00 am, Ben Greear wrote: > Kosta Todorovic wrote: > > My company has recently purchased several ZNYX ZX274 network cards. > > These cards are Four Channel, 10/100 PCI Adapters. They use Intel > > chipsets. > > > > Unfortunately there exists no drivers for linux amd64 architecture. > > There are 32bit drivers found at: > > http://www.znyx.com/support/drivers/ZX374_drivers.htm but naturally > > they wont compile under my amd64 system. > > > > The driver itself is called znb.o and can be downloaded from ZNYX's > > website. I spoke to support staff there but they told me they have > > discontinued support and development for this series of cards. > > > > The system I am running gentoo and have tried both 2.4.x and 2.6.x > > kernels but no luck. > > > > Unfortunately there is NO 64bit drivers available for ANY platform. not > > even MS. > > > > Does anyone know of a customised znb.o driver built for amd64? > > Is there any chance of anyone modifying the source code of the driver > > to compile under a amd64 system? > > > > I've noticed that "tulip" drivers get loaded as a module at boot time. > > but they dont function correctly. (lets you start the device and > > attach ips but cant talk through it) > > > > Is there any variants of the tulip driver that will work for this? > > > > Help much appreciated. > > My personal opinion is that those NICs suck. I never did get mine > to work. I'd suggest getting a DFE-570tx if you can find it, or > perhaps a p430tx. You can also get 4-port GigE NICs from Intel for > around $400 these days... > > Ben Suck or not, it would be good to have these adapters working. Some people might not be willing to spend $400 on a new adapter. Hopefully some generous soul would be willing to spend their valuable time trying to make this work (or send me an adapter and I'll give it a go). Jon From alexn@dsv.su.se Sat Mar 19 01:21:40 2005 Received: with ECARTIS (v1.0.0; list netdev); Sat, 19 Mar 2005 01:21:45 -0800 (PST) Received: from swip.net (mailfe09.swip.net [212.247.155.1]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j2J9LcW9025722 for ; Sat, 19 Mar 2005 01:21:39 -0800 X-T2-Posting-ID: icQHdNe7aEavrnKIz+aKnQ== Received: from c213-100-63-205.swipnet.se ([213.100.63.205] verified) by mailfe09.swip.net (CommuniGate Pro SMTP 4.2.9) with ESMTP id 112362803; Sat, 19 Mar 2005 10:21:32 +0100 Subject: Re: Reproducible panics with tulip From: Alexander Nyberg To: Francois Romieu Cc: jgarzik@pobox.com, netdev@oss.sgi.com In-Reply-To: <20050318223939.GB24509@electric-eye.fr.zoreil.com> References: <1111178167.1147.9.camel@localhost.localdomain> <20050318215229.GA24509@electric-eye.fr.zoreil.com> <20050318223939.GB24509@electric-eye.fr.zoreil.com> Content-Type: text/plain Date: Sat, 19 Mar 2005 10:21:32 +0100 Message-Id: <1111224092.964.2.camel@localhost.localdomain> Mime-Version: 1.0 X-Mailer: Evolution 2.0.4 Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV 0.83/772/Fri Mar 18 00:59:17 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 353 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: alexn@dsv.su.se Precedence: bulk X-list: netdev Content-Length: 2631 Lines: 70 > > > Warning: kfree_skb on hard IRQ c46c3950 > > > > ... however this one may stick. > > /me slaps his head > > Nope, it should go away with netconsole: tulip_rx fails an allocation, > netconsole tries to printk in IRQ context and issues: > -> netpoll_send_udp > -> find_skb > -> zap_completion_queue > -> __kfree_skb <- whence the warning. > > So, please increase /proc/sys/vm/min_free_kbytes as a start and, at your > option: > - disable netconsole > - apply patch below: I guess it was unclear in the output mess, the real problem at the bottom was: Unable to handle kernel NULL pointer dereference at virtual address 00000064 printing eip: c023c9f7 *pde = 00000000 Oops: 0000 [#1] DEBUG_PAGEALLOC CPU: 0 EIP: 0060:[] Not tainted VLI EFLAGS: 00010246 (2.6.12-rc1) EIP is at tulip_rx+0x187/0x3e0 eax: 00000000 ebx: c70a0220 ecx: 00000000 edx: 00000640 esi: 00000040 edi: 00000000 ebp: c46c3ba8 esp: c46c3b64 ds: 007b es: 007b ss: 0068 Process rpciod/0 (pid: 595, threadinfo=c46c2000 task=c4673b10) Stack: c46c3e40 c07f5f60 c0c1f824 c46c3b90 c028ecb9 00000000 c46c3b80 00000000 0000003c 00000000 0000000f 00000070 00000031 c70a0000 c70a0220 00009fde 0000001e c46c3c00 c023d5a5 00000040 00000000 00000000 00000084 c4687e8c Call Trace: [] show_stack+0x7a/0x90 [] show_registers+0x148/0x1b0 [] die+0xda/0x150 [] do_page_fault+0x2f0/0x625 [] error_code+0x2b/0x30 [] tulip_interrupt+0x955/0x970 [] handle_IRQ_event+0x2a/0x60 [] __do_IRQ+0xa4/0xf0 [] do_IRQ+0x1c/0x30 [] common_interrupt+0x1a/0x20 [] kfree_skbmem+0xb/0x20 [] __kfree_skb+0x53/0xc0 [] packet_rcv_spkt+0x11b/0x200 [] netif_receive_skb+0x12b/0x190 [] process_backlog+0x7e/0x100 [] net_rx_action+0x65/0xe0 [] __do_softirq+0x7a/0x90 [] do_softirq+0x2c/0x30 [] do_IRQ+0x21/0x30 [] common_interrupt+0x1a/0x20 [] inet_sendpage+0x74/0xa0 [] xdr_sendpages+0x13e/0x220 [] xprt_transmit+0xcd/0x470 [] call_transmit+0x4b/0xb0 [] __rpc_execute+0x5c/0x300 [] worker_thread+0x150/0x1e0 [] kthread+0x95/0xa0 [] kernel_thread_helper+0x5/0x10 Code: 07 83 e8 04 66 3d ee 05 0f 8f f3 01 00 00 98 3b 05 90 d5 3f c0 89 45 dc 0f 8c 07 01 00 00 8b 4d ec 8b 8c cb 18 01 00 00 89 4d e0 <8b> 51 64 8b b1 90 00 00 00 85 d2 0f 85 dc 00 00 00 8b 55 dc 8b <0>Kernel panic - not syncing: Fatal exception in interrupt From ludo@protactive.nl Sat Mar 19 02:07:57 2005 Received: with ECARTIS (v1.0.0; list netdev); Sat, 19 Mar 2005 02:08:05 -0800 (PST) Received: from protactive.stwerff.xs4all.nl (stwerff.xs4all.nl [213.84.145.135]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j2JA7u1t027882 for ; Sat, 19 Mar 2005 02:07:57 -0800 Received: from localhost (protactive.stwerff.xs4all.nl [127.0.0.1]) by protactive.stwerff.xs4all.nl (Postfix) with ESMTP id C377A7F for ; Sat, 19 Mar 2005 11:07:39 +0100 (CET) Received: from protactive.stwerff.xs4all.nl ([127.0.0.1]) by localhost (protactive.stwerff.xs4all.nl [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 12399-06 for ; Sat, 19 Mar 2005 11:07:00 +0100 (CET) Received: from [192.168.99.90] (host-192.168.99.90 [192.168.99.90]) by protactive.stwerff.xs4all.nl (Postfix) with ESMTP id D3FCD7D for ; Sat, 19 Mar 2005 11:06:52 +0100 (CET) Message-ID: <423BF9BA.8090408@protactive.nl> Date: Sat, 19 Mar 2005 11:06:50 +0100 From: Ludo Stellingwerff User-Agent: Debian Thunderbird 1.0 (X11/20050116) X-Accept-Language: en-us, en MIME-Version: 1.0 To: netdev@oss.sgi.com Subject: [RFC] Using Fwmark as SPD filter. X-Enigmail-Version: 0.90.0.0 X-Enigmail-Supports: pgp-inline, pgp-mime Content-Type: multipart/mixed; boundary="------------040506020609010907000306" X-Virus-Scanned: ClamAV 0.83/772/Fri Mar 18 00:59:17 2005 on oss.sgi.com X-Virus-Scanned: by amavisd-new-20030616-p10 at stwerff.xs4all.nl X-Virus-Status: Clean X-archive-position: 354 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: ludo@protactive.nl Precedence: bulk X-list: netdev Content-Length: 7470 Lines: 197 This is a multi-part message in MIME format. --------------040506020609010907000306 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi All, I have a kind of feature request, which I like to try and implement. But I'm not a kernel hacker and terribly short on time, therefor I like to discuss this feature with you guys first to see if you like the idea. I have a problem with the scalability of the SPD database. Because it's a linear list, sorted by priority, it's possible to make quite complex ipsecpolicies, but the list will grow enormously. Especially when using seperate ports in the policy, matching various addresses, trying to encrypt the default route:), various protocols, etc. Due to caching this scalability might not be a problem for the kernel, but for me as maintainer it's quite dainting. But the netfilter stack allready has a very flexible, advanced traffic matching structure. It would be nice if we could use the netfilter-mark as a match in the SPD. A similar approach exists in NetBSD where it's possible to use a packetfilter "tag" as a ipsecmatch. I have been looking into the neccesary changes to the kernel to use fwmark as SPD match, attached is a unfinished, unclean, old patch against the debian 2.6.9 source tree. As far as I know the pfkey interface is still very buggy. Patrick McHardy already pointed out one omission: "One thing that is missing is setting fl->fwmark for policy checks of incoming packets in xfrm{46}_decode_session()" I don't have a patch for the userland side yet. Hopefully I will have time to continue work on these patches the coming month. My question concerns the basics: Do you agree that using the fwmark as a SPD key is a usable way to describe ipsec policies? Would you consider applying such a patch to the kernel (or through POMng)? In general, is this work a waste of time or am I hitting something here? Thanks in advance, Ludo. - -- Ludo Stellingwerff V&S B.V. The Netherlands ProTactive firewall solution. Tel: +31 172 416116 Fax: +31 172 416124 site: www.protactive.nl -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.0 (GNU/Linux) iD8DBQFCO/m6OF3sCpZ+AJgRAr8gAJ9Nhg62dtusJ/rLLqFBw+vEIOmFJgCeLxm4 F36sywqctCAJLz/58N0o64Q= =yZQF -----END PGP SIGNATURE----- --------------040506020609010907000306 Content-Type: text/x-patch; name="NF_Mark_SPD_match.patch" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="NF_Mark_SPD_match.patch" diff -wur kernel-source-2.6.9/include/linux/pfkeyv2.h kernel-source-2.6.9b/include/linux/pfkeyv2.h --- kernel-source-2.6.9/include/linux/pfkeyv2.h 2004-10-18 23:54:55.000000000 +0200 +++ kernel-source-2.6.9b/include/linux/pfkeyv2.h 2005-02-16 08:18:37.000000000 +0100 @@ -216,6 +216,14 @@ } __attribute__((packed)); /* sizeof(struct sadb_x_nat_t_port) == 8 */ +/* Pass a Fwmark match */ +struct sadb_x_mark { + uint16_t sadb_x_mark_len; + uint16_t sadb_x_mark_exttype; + uint32_t sadb_x_mark_match; +} __attribute__((packed)); +/* sizeof(struct sadb_x_mark) == 8 */ + /* Message types */ #define SADB_RESERVED 0 #define SADB_GETSPI 1 @@ -324,7 +332,9 @@ #define SADB_X_EXT_NAT_T_SPORT 21 #define SADB_X_EXT_NAT_T_DPORT 22 #define SADB_X_EXT_NAT_T_OA 23 -#define SADB_EXT_MAX 23 +/* The following entry is for matching SPD to fwmark */ +#define SADB_X_EXT_MARK 24 +#define SADB_EXT_MAX 24 /* Identity Extension values */ #define SADB_IDENTTYPE_RESERVED 0 diff -wur kernel-source-2.6.9/include/linux/xfrm.h kernel-source-2.6.9b/include/linux/xfrm.h --- kernel-source-2.6.9/include/linux/xfrm.h 2004-10-18 23:53:43.000000000 +0200 +++ kernel-source-2.6.9b/include/linux/xfrm.h 2005-01-20 21:08:27.000000000 +0100 @@ -43,6 +43,7 @@ __u8 proto; int ifindex; uid_t user; + __u32 fwmark; }; #define XFRM_INF (~(__u64)0) diff -wur kernel-source-2.6.9/include/net/xfrm.h kernel-source-2.6.9b/include/net/xfrm.h --- kernel-source-2.6.9/include/net/xfrm.h 2004-11-17 11:47:11.000000000 +0100 +++ kernel-source-2.6.9b/include/net/xfrm.h 2005-01-20 21:15:19.000000000 +0100 @@ -469,7 +469,8 @@ !((xfrm_flowi_dport(fl) ^ sel->dport) & sel->dport_mask) && !((xfrm_flowi_sport(fl) ^ sel->sport) & sel->sport_mask) && (fl->proto == sel->proto || !sel->proto) && - (fl->oif == sel->ifindex || !sel->ifindex); + (fl->oif == sel->ifindex || !sel->ifindex) && + (fl->fl4_fwmark == sel->fwmark || !sel->fwmark); } static inline int diff -wur kernel-source-2.6.9/net/key/af_key.c kernel-source-2.6.9b/net/key/af_key.c --- kernel-source-2.6.9/net/key/af_key.c 2004-10-18 23:55:36.000000000 +0200 +++ kernel-source-2.6.9b/net/key/af_key.c 2005-01-20 21:25:24.000000000 +0100 @@ -336,6 +336,7 @@ [SADB_X_EXT_NAT_T_SPORT] = (u8) sizeof(struct sadb_x_nat_t_port), [SADB_X_EXT_NAT_T_DPORT] = (u8) sizeof(struct sadb_x_nat_t_port), [SADB_X_EXT_NAT_T_OA] = (u8) sizeof(struct sadb_address), + [SADB_X_EXT_MARK] = (u8) sizeof(struct sadb_x_mark), }; /* Verify sadb_address_{len,prefixlen} against sa_family. */ @@ -892,6 +893,7 @@ n_port->sadb_x_nat_t_port_reserved = 0; } + return skb; } @@ -1647,7 +1649,8 @@ (sockaddr_size * 2) + sizeof(struct sadb_x_policy) + (xp->xfrm_nr * (sizeof(struct sadb_x_ipsecrequest) + - (socklen * 2))); + (socklen * 2))) + + sizeof(struct sadb_x_mark); } static struct sk_buff * pfkey_xfrm_policy2msg_prep(struct xfrm_policy *xp) @@ -1671,6 +1674,7 @@ struct sadb_lifetime *lifetime; struct sadb_x_policy *pol; struct sockaddr_in *sin; + struct sadb_x_mark *match; #if defined(CONFIG_IPV6) || defined(CONFIG_IPV6_MODULE) struct sockaddr_in6 *sin6; #endif @@ -1855,6 +1859,11 @@ } } } + match = (struct sadb_x_mark*) skb_put(skb, sizeof (struct sadb_x_mark)); + match->sadb_x_mark_len = sizeof(*match)/sizeof(uint64_t); + match->sadb_x_mark_exttype = SADB_X_EXT_MARK; + match->sadb_x_mark_match = xp->selector.fwmark; + hdr->sadb_msg_len = size / sizeof(uint64_t); hdr->sadb_msg_reserved = atomic_read(&xp->refcnt); } @@ -1868,6 +1877,7 @@ struct xfrm_policy *xp; struct sk_buff *out_skb; struct sadb_msg *out_hdr; + struct sadb_x_mark *mark; if (!present_and_same_family(ext_hdrs[SADB_EXT_ADDRESS_SRC-1], ext_hdrs[SADB_EXT_ADDRESS_DST-1]) || @@ -1930,6 +1940,9 @@ xp->lft.soft_add_expires_seconds = lifetime->sadb_lifetime_addtime; xp->lft.soft_use_expires_seconds = lifetime->sadb_lifetime_usetime; } + if ((mark = ext_hdrs[SADB_X_EXT_MARK-1]) != NULL) { + xp->selector.fwmark = mark->sadb_x_mark_match; + } xp->xfrm_nr = 0; if (pol->sadb_x_policy_type == IPSEC_POLICY_IPSEC && (err = parse_ipsecrequests(xp, pol)) < 0) --------------040506020609010907000306-- From herbert@gondor.apana.org.au Sat Mar 19 02:16:16 2005 Received: with ECARTIS (v1.0.0; list netdev); Sat, 19 Mar 2005 02:16:23 -0800 (PST) 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 j2JAGEcu028755 for ; Sat, 19 Mar 2005 02:16:15 -0800 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 1DCazu-0005Tu-00; Sat, 19 Mar 2005 21:15:58 +1100 Received: from herbert by gondolin.me.apana.org.au with local (Exim 3.36 #1 (Debian)) id 1DCazI-0003sx-00; Sat, 19 Mar 2005 21:15:20 +1100 From: Herbert Xu To: ludo@protactive.nl (Ludo Stellingwerff) Subject: Re: [RFC] Using Fwmark as SPD filter. Cc: netdev@oss.sgi.com Organization: Core In-Reply-To: <423BF9BA.8090408@protactive.nl> 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, 19 Mar 2005 21:15:20 +1100 X-Virus-Scanned: ClamAV 0.83/772/Fri Mar 18 00:59:17 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 355 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: herbert@gondor.apana.org.au Precedence: bulk X-list: netdev Content-Length: 808 Lines: 21 Ludo Stellingwerff wrote: > > In general, is this work a waste of time or am I hitting something here? Yes you're hitting the right spot :) This is a planned feature. We just need to fix the bundle structure so that they live in the flow cache instead of the policy to make this workable. As to your patch: There is no point in adding more Linux-specific extensions when we already have a Linux-specific netlink interface that supports fwmark. So these efforts would be better spent in converting whatever application you're using (e.g., racoon) over to netlink. Cheers, -- Visit Openswan at http://www.openswan.org/ Email: Herbert Xu ~{PmV>HI~} Home Page: http://gondor.apana.org.au/~herbert/ PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt From romieu@fr.zoreil.com Sat Mar 19 02:24:24 2005 Received: with ECARTIS (v1.0.0; list netdev); Sat, 19 Mar 2005 02:24:30 -0800 (PST) Received: from fr.zoreil.com (electric-eye.fr.zoreil.com [213.41.134.224]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j2JAON6K029890 for ; Sat, 19 Mar 2005 02:24:24 -0800 Received: from electric-eye.fr.zoreil.com (localhost.localdomain [127.0.0.1]) by fr.zoreil.com (8.13.1/8.12.1) with ESMTP id j2JAKxeW002044; Sat, 19 Mar 2005 11:20:59 +0100 Received: (from romieu@localhost) by electric-eye.fr.zoreil.com (8.13.1/8.13.1/Submit) id j2JAKri8002043; Sat, 19 Mar 2005 11:20:53 +0100 Date: Sat, 19 Mar 2005 11:20:53 +0100 From: Francois Romieu To: Alexander Nyberg Cc: jgarzik@pobox.com, netdev@oss.sgi.com Subject: Re: Reproducible panics with tulip Message-ID: <20050319102053.GA1704@electric-eye.fr.zoreil.com> References: <1111178167.1147.9.camel@localhost.localdomain> <20050318215229.GA24509@electric-eye.fr.zoreil.com> <20050318223939.GB24509@electric-eye.fr.zoreil.com> <1111224092.964.2.camel@localhost.localdomain> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1111224092.964.2.camel@localhost.localdomain> User-Agent: Mutt/1.4.1i X-Organisation: Land of Sunshine Inc. X-Virus-Scanned: ClamAV 0.83/772/Fri Mar 18 00:59:17 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 357 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: romieu@fr.zoreil.com Precedence: bulk X-list: netdev Content-Length: 313 Lines: 11 Alexander Nyberg : [...] > I guess it was unclear in the output mess, the real problem at the > bottom was: No, no, not at all. It is clear but I'd prefer to see the same oops without the netconsole parameter into play. A pure nfs + driver + race oops will be fun enough for me. :o) -- Ueimor From andy.furniss@dsl.pipex.com Sat Mar 19 02:23:21 2005 Received: with ECARTIS (v1.0.0; list netdev); Sat, 19 Mar 2005 02:23:26 -0800 (PST) Received: from blaster.systems.pipex.net (blaster.systems.pipex.net [62.241.163.7]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j2JANJmC029651 for ; Sat, 19 Mar 2005 02:23:20 -0800 Received: from [192.168.0.3] (81-178-236-119.dsl.pipex.com [81.178.236.119]) by blaster.systems.pipex.net (Postfix) with ESMTP id 7B7CEE000191; Sat, 19 Mar 2005 10:23:07 +0000 (GMT) Message-ID: <423BFD9F.50401@dsl.pipex.com> Date: Sat, 19 Mar 2005 10:23:27 +0000 From: Andy Furniss User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.8a6) Gecko/20050111 X-Accept-Language: en-us, en MIME-Version: 1.0 To: hadi@cyberus.ca Cc: Remus , netdev@oss.sgi.com, Nguyen Dinh Nam , Andre Tomt , syrius.ml@no-log.org, Damion de Soto Subject: Re: dummy as IMQ replacement References: <1107123123.8021.80.camel@jzny.localdomain> <0fcf01c5077f$579e4b80$6e69690a@RIMAS> <1107174142.8021.121.camel@jzny.localdomain> <00c301c524b4$938cd240$6e69690a@RIMAS> <1110379135.1091.143.camel@jzny.localdomain> <1110416767.1111.76.camel@jzny.localdomain> <025501c52552$2dbf87c0$6e69690a@RIMAS> <1110453757.1108.87.camel@jzny.localdomain> <423B7BCB.10400@dsl.pipex.com> <1111196668.1146.114.camel@jzny.localdomain> In-Reply-To: <1111196668.1146.114.camel@jzny.localdomain> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV 0.83/772/Fri Mar 18 00:59:17 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 356 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: andy.furniss@dsl.pipex.com Precedence: bulk X-list: netdev Content-Length: 2760 Lines: 94 jamal wrote: > Remus seems to have got it working with iptables earlier than > 1.3.0 works fine. > Unfortunately i am not close to my machines and wont be for a while. > Can you try not to pass mirred in the command line and see if that > works? > > cheers, > jamal If I just do - .... $TC filter add dev eth0 parent ffff: protocol ip prio 10 u32 \ match u32 0 0 flowid 1:1 \ action ipt -j MARK --set-mark 1 It still gives memory error with 1.3.1 , with 1.2.11 it parses OK but I get bogus stats - hit count is OK [root@amd /home/andy/Qos]# tc -s filter ls dev eth0 parent ffff: filter protocol ip pref 10 u32 filter protocol ip pref 10 u32 fh 800: ht divisor 1 filter protocol ip pref 10 u32 fh 800::800 order 2048 key ht 800 bkt 0 flowid 1:1 (rule hit 12 success 12) match 00000000/00000000 at 0 (success 12 ) action order 1: tablename: mangle hook: NF_IP_PRE_ROUTING target MARK set 0x1 index 1 ref 1 bind 1 installed 251 sec expires 1 sec Action statistics: Sent 7630953 bytes 0 pkt rate 3146Kbit 1095565348pps If I try with the lines below added action egress redirect dev dummy0 or action redirect dev dummy0 I just get errors on whatever is after action - or memory errors with 1.3.1. Using tc iproute2-ss050112 + patch for these tests. I don't know if it's relevant but I am using gcc-2.95.3, which meant I had to change the dummy patch a bit as it doesn't (for me) like variable declarations in the middle of functions. drivers/net/dummy.c: In function `dummy_xmit': drivers/net/dummy.c:218: parse error before `from' drivers/net/dummy.c:219: `from' undeclared (first use in this function) So I changed to static int dummy_xmit(struct sk_buff *skb, struct net_device *dev) { struct dummy_private *dp = ((struct net_device *)dev)->priv; struct net_device_stats *stats = &dp->stats; int ret = 0; __u32 from; { stats->tx_packets++; stats->tx_bytes+=skb->len; } #ifdef CONFIG_NET_CLS_ACT from = G_TC_FROM(skb->tc_verd); Is there a switch for this? - or am I the only one who actually does kernel stuff with 2.95.3 (using LFS 5.1, which uses 3.3 by default but keeps 2.95.3 in /opt specially for kernels) I am using it for iptables and tc aswell (though I tried 3.3 - but not for kernel yet) I have manually loaded modules dummy 3972 0 mirred 6400 0 pedit 6624 0 gact 5984 0 ipt_MARK 2432 0 ipt 6944 0 ip_tables 19728 2 ipt_MARK,ipt sch_tbf 5120 1 sch_ingress 3136 1 cls_fw 3904 2 sch_sfq 5184 2 sch_prio 4736 1 cls_u32 6916 0 Andy. From kostodo@gmail.com Sat Mar 19 02:29:16 2005 Received: with ECARTIS (v1.0.0; list netdev); Sat, 19 Mar 2005 02:29:25 -0800 (PST) Received: from rproxy.gmail.com (rproxy.gmail.com [64.233.170.199]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j2JATFdl030878 for ; Sat, 19 Mar 2005 02:29:15 -0800 Received: by rproxy.gmail.com with SMTP id c51so436630rne for ; Sat, 19 Mar 2005 02:29:15 -0800 (PST) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:reply-to:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:references; b=N7k/xLysMBnYaaa2yiHOFL7d00oth9BAK4PyKtmekOYNCj6TriV9gFs6ZABCgyvX1lZAfBArETXufeYKRyJfASPaXG4ZwGpx1CIk2OMPBWwPo010eKmOd2hVdyTLz4HcKpvU3b00JWeNDmybayHZPxP65uwa1f7iITFaA5q4EG8= Received: by 10.38.65.20 with SMTP id n20mr3593146rna; Sat, 19 Mar 2005 02:29:14 -0800 (PST) Received: by 10.38.208.49 with HTTP; Sat, 19 Mar 2005 02:29:14 -0800 (PST) Message-ID: Date: Sat, 19 Mar 2005 14:29:14 +0400 From: Kosta Todorovic Reply-To: Kosta Todorovic To: Jon Mason Subject: Re: Network card driver problem (znb.o/tulip) Cc: Ben Greear , jgarzik@pobox.com, tulip-users@lists.sourceforge.net, netdev@oss.sgi.com In-Reply-To: <200503182333.51470.jdmason@us.ibm.com> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit References: <423133F7.7040400@candelatech.com> <200503182333.51470.jdmason@us.ibm.com> X-Virus-Scanned: ClamAV 0.83/772/Fri Mar 18 00:59:17 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 358 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: kostodo@gmail.com Precedence: bulk X-list: netdev Content-Length: 667 Lines: 17 Problem is that all the adapters are currently in use in 32bit mode. It was my only solution. I'm hoping that will not be a permanent thing. Im just a little lost as in to what I should do. I've been told by ZNXY that they *might* provide the source code to the entire driver, so if there is someone that is willing to try make it work I would be eternally greatful. > > Suck or not, it would be good to have these adapters working. Some people > might not be willing to spend $400 on a new adapter. Hopefully some generous > soul would be willing to spend their valuable time trying to make this work > (or send me an adapter and I'll give it a go). > > Jon > From alexn@dsv.su.se Sat Mar 19 03:29:58 2005 Received: with ECARTIS (v1.0.0; list netdev); Sat, 19 Mar 2005 03:30:03 -0800 (PST) Received: from swip.net (mailfe04.swip.net [212.247.154.97]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j2JBTuhA003049 for ; Sat, 19 Mar 2005 03:29:57 -0800 X-T2-Posting-ID: icQHdNe7aEavrnKIz+aKnQ== Received: from c213-100-63-205.swipnet.se ([213.100.63.205] verified) by mailfe04.swip.net (CommuniGate Pro SMTP 4.2.9) with ESMTP id 323644975; Sat, 19 Mar 2005 12:29:46 +0100 Subject: Re: Reproducible panics with tulip From: Alexander Nyberg To: "David S. Miller" Cc: Matt Mackall , romieu@fr.zoreil.com, jgarzik@pobox.com, netdev@oss.sgi.com In-Reply-To: <20050318194751.3fade099.davem@davemloft.net> References: <1111178167.1147.9.camel@localhost.localdomain> <20050318215229.GA24509@electric-eye.fr.zoreil.com> <20050318223939.GB24509@electric-eye.fr.zoreil.com> <20050319031321.GA25554@waste.org> <20050318194751.3fade099.davem@davemloft.net> Content-Type: text/plain Date: Sat, 19 Mar 2005 12:29:45 +0100 Message-Id: <1111231785.964.5.camel@localhost.localdomain> Mime-Version: 1.0 X-Mailer: Evolution 2.0.4 Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV 0.83/772/Fri Mar 18 00:59:17 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 359 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: alexn@dsv.su.se Precedence: bulk X-list: netdev Content-Length: 367 Lines: 15 fre 2005-03-18 klockan 19:47 -0800 skrev David S. Miller: > On Fri, 18 Mar 2005 19:13:21 - > Matt Mackall wrote: > > > Please, cc: me on such things. I sent this fix a while back, but DaveM > > never acked it. > > It's in my backlog, never fear :-) [so that everyone sees this] The patch Francois Romieu sent me fixes my panic issues. Thanks! From s.schmidt@mcbone.net Sat Mar 19 05:54:16 2005 Received: with ECARTIS (v1.0.0; list netdev); Sat, 19 Mar 2005 05:54:21 -0800 (PST) Received: from mout0.freenet.de (mout0.freenet.de [194.97.50.131]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j2JDsEKk013512 for ; Sat, 19 Mar 2005 05:54:15 -0800 Received: from [194.97.50.136] (helo=mx3.freenet.de) by mout0.freenet.de with esmtpa (Exim 4.51) id 1DCeP7-0008U0-K3; Sat, 19 Mar 2005 14:54:13 +0100 Received: from giscard.mcbone.net ([194.97.7.90]) by mx3.freenet.de with esmtps (TLSv1:AES256-SHA:256) (Exim 4.43 #13) id 1DCeP7-00015j-Ix; Sat, 19 Mar 2005 14:54:13 +0100 Received: from schmidt by giscard.mcbone.net with local (Exim 4.50) id 1DCeP7-0001hV-0C; Sat, 19 Mar 2005 14:54:13 +0100 Date: Sat, 19 Mar 2005 14:54:12 +0100 From: Stefan Schmidt To: Andrew Morton Cc: netdev@oss.sgi.com Subject: (solved) Re: Fw: 2.6.11-mm2 weird ethernet RTTs Message-ID: <20050319135412.GA5134@giscard.mcbone.net> References: <20050317115254.4f8e462a.akpm@osdl.org> <20050318091140.GE30259@giscard.mcbone.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20050318091140.GE30259@giscard.mcbone.net> User-Agent: Mutt/1.5.6+20040907i X-Virus-Scanned: ClamAV 0.83/774/Fri Mar 18 17:04:06 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 360 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: s.schmidt@mcbone.net Precedence: bulk X-list: netdev Content-Length: 1495 Lines: 26 On Fri, Mar 18, 2005 at 10:11:40AM +0100, Stefan Schmidt wrote: > > I'm not aware of any changes which would cause this. Generally -mm's > > networking is the same as Linus's. Could you test Linus's latest tree? > > (-rc1 should be out very soon, so that would be appropriate) > 2.6.10-mm1 was the kernel i ran before 2.6.11-mm2 on this machine which > did not show this behaviour. I will try the latest vanilla as soon as > i'm in office. Perhaps this problem is e1000-driver inflicted, i am > using it as a module - will try latest vanilla with the same setup. I tried booting 2.6.12-rc1. It hung 50% of the time intermittent with a harddisk DMA timeout due to some weird things on irq 117 and the other time a kernel BUG in e1000 was triggered for which i will open another thread. Anyway i saw in a wink that ide_cd reported to CD-ROM drive to do weird things and removed the thing. The system went up fine after that and ping RTTs were back to what i experienced before that whole story. I labeled the delinquent device 'CD-ROM drive of doom' and just assumed that it behave so bad on the other IDE bus (not the one the HD is attached too) that the IDE-Controller was hogged up with handling that bus and either generated some interrupts by itself or was not able to respond to them properly anymore. The CD-ROM drive also gives interesting rattling noises when shaken - its a LG 52x, don't have the model # at hand now. Stefan -- A day without fusion is like a day without sunshine. From jdmason@us.ibm.com Sat Mar 19 05:57:37 2005 Received: with ECARTIS (v1.0.0; list netdev); Sat, 19 Mar 2005 05:57:43 -0800 (PST) Received: from e35.co.us.ibm.com (e35.co.us.ibm.com [32.97.110.133]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j2JDvaFR014028 for ; Sat, 19 Mar 2005 05:57:36 -0800 Received: from d03relay04.boulder.ibm.com (d03relay04.boulder.ibm.com [9.17.195.106]) by e35.co.us.ibm.com (8.12.10/8.12.9) with ESMTP id j2JDvULg022886 for ; Sat, 19 Mar 2005 08:57:30 -0500 Received: from d03av04.boulder.ibm.com (d03av04.boulder.ibm.com [9.17.195.170]) by d03relay04.boulder.ibm.com (8.12.10/NCO/VER6.6) with ESMTP id j2JDvUWX196306 for ; Sat, 19 Mar 2005 06:57:30 -0700 Received: from d03av04.boulder.ibm.com (loopback [127.0.0.1]) by d03av04.boulder.ibm.com (8.12.11/8.12.11) with ESMTP id j2JDvTWW008430 for ; Sat, 19 Mar 2005 06:57:30 -0700 Received: from sig-9-65-41-173.mts.ibm.com (sig-9-65-41-173.mts.ibm.com [9.65.41.173]) by d03av04.boulder.ibm.com (8.12.11/8.12.11) with ESMTP id j2JDvTBf008427; Sat, 19 Mar 2005 06:57:29 -0700 From: Jon Mason Organization: IBM To: Kosta Todorovic Subject: Re: Network card driver problem (znb.o/tulip) Date: Sat, 19 Mar 2005 07:57:27 -0600 User-Agent: KMail/1.7.2 Cc: Ben Greear , jgarzik@pobox.com, tulip-users@lists.sourceforge.net, netdev@oss.sgi.com References: <200503182333.51470.jdmason@us.ibm.com> In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200503190757.27727.jdmason@us.ibm.com> X-Virus-Scanned: ClamAV 0.83/774/Fri Mar 18 17:04:06 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 361 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: jdmason@us.ibm.com Precedence: bulk X-list: netdev Content-Length: 824 Lines: 20 On Saturday 19 March 2005 04:29 am, Kosta Todorovic wrote: > Problem is that all the adapters are currently in use in 32bit mode. > It was my only solution. I'm hoping that will not be a permanent > thing. > Im just a little lost as in to what I should do. > > I've been told by ZNXY that they *might* provide the source code to > the entire driver, so if there is someone that is willing to try make > it work I would be eternally greatful. I have a tulip adapter laying around somewhere. I can give that a try and verify that tulip works on a 64bit system (assuming it hasn't been already tried). The ZNXY website provides the driver source for the 4port adapter (and it is GPL'ed), but it seems to me that this is really an issue of getting the adapter to work with the "real" kernel driver, tulip. Thanks, Jon From s.schmidt@mcbone.net Sat Mar 19 06:30:55 2005 Received: with ECARTIS (v1.0.0; list netdev); Sat, 19 Mar 2005 06:31:05 -0800 (PST) Received: from mout1.freenet.de (mout1.freenet.de [194.97.50.132]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j2JEUrX2016106 for ; Sat, 19 Mar 2005 06:30:54 -0800 Received: from [194.97.55.148] (helo=mx5.freenet.de) by mout1.freenet.de with esmtpa (Exim 4.51) id 1DCeya-0001zh-9f; Sat, 19 Mar 2005 15:30:52 +0100 Received: from giscard.mcbone.net ([194.97.7.90]) by mx5.freenet.de with esmtps (TLSv1:AES256-SHA:256) (Exim 4.43 #13) id 1DCeyZ-0002yX-Ti; Sat, 19 Mar 2005 15:30:51 +0100 Received: from schmidt by giscard.mcbone.net with local (Exim 4.50) id 1DCeyZ-0002CU-Dx; Sat, 19 Mar 2005 15:30:51 +0100 Date: Sat, 19 Mar 2005 15:30:51 +0100 From: Stefan Schmidt To: netdev@oss.sgi.com, linux-kernel@vger.kernel.org Subject: e1000||ICH5-ATA BUG in 2.6.12-rc1 triggered by ill behaved CD-ROM drive Message-ID: <20050319143051.GB5134@giscard.mcbone.net> Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="5vNYLRcllDrimb99" Content-Disposition: inline Content-Transfer-Encoding: 8bit User-Agent: Mutt/1.5.6+20040907i X-Virus-Scanned: ClamAV 0.83/774/Fri Mar 18 17:04:06 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 362 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: s.schmidt@mcbone.net Precedence: bulk X-list: netdev Content-Length: 50551 Lines: 1995 --5vNYLRcllDrimb99 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit Here's the story again but shorter: (-> netdev: "(solved) Re: Fw: 2.6.11-mm2 weird ethernet RTTs" ) It seems after some reboot my CD-ROM drive went nuts and hogged up my IDE-Controller (ICH5) which in turn either generated a lot of interrupts or did not properly respond to em. Half of the time i tried booting the machine with the CD-ROM drive attached to ide1 and the HD at ide0 i experienced heavy disk timeouts due to DMA timeouts (°1) and the other half of the time the following kernel BUG was triggered. Removing the CD-ROM resolved all those problems. (typos probable - no camera was handy ;-() Configuring network interfaces ... --- cut here --- kernel BUG at include/linux/netdevice.h:860! invalid operand: 0000 [#1] PREEMPT SMP Modules linked in: ide_cd cdrom ... (left out some here) ... commoncap e1000 3c59x mii CPU: 0 EIP: 0060: [] Not tainted VLI EFLAGS: 00010046 (2.6.12-rc1) EIP is at e1000_clean+0xcb/0xe0 [e1000] eax: 00000017 ebx: 00000287 ecx: 00000000 edx: e81e6000 esi: 00000000 edi: de67e800 ebp: 00000040 esp: c042efb0 ds: 007b es: 007b ss: 0068 Process swapper (pid: 0, threadinfo=c042e000 task=c0360c00) Stack: de67ea40 00000000 de67e904 de67e800 c13f5fa0 c13f5f80 c02adedf fffbbf83 0000012c 00000001 c03ec198 c0427bc0 00000000 c0123fc6 0000000a c03f4f88 00000046 c03f4000 0047a007 c010552a Call Trace: [] net_rx_action+0x7f/0x110 [] __do_softirq+0xb6/0xd0 [] do_softirq+0x4a/0x60 [] irq_exit+0x39/0x40 [] do_IRQ+0x4d/0x70 [] common_interrupt+0x1a/0x20 [] default_idle+0x23/0x30 [] start_kernel+0x15f/0x180 [] unknown_bootoption+0x0/0x1e0 Code: c0 84 c0 74 1a 8b 82 24 02 00 00 b9 9d 00 00 00 89 88 d0 00 00 00 8b 82 24 02 00 00 8b 40 08 31 d2 82 c4 08 89 d0 5b 5e 5f 5d c3 <0f> 0b 5c 03 35 c6 05 e0 eb 91 8d 74 26 00 8d bc 27 00 00 00 00 <0> Kernel panic - not syncing: Fatal exception in interrupt e1000: eth1: e1000_watchdog: NIC Link is Up 100 Mbps Full Duplex --- The End --- Kernel-config and lspci -vvv attached. °1: Mar 18 14:47:53 giscard kernel: irq 177: nobody cared! Mar 18 14:47:53 giscard kernel: [__report_bad_irq+36/144] __report_bad_irq+0x24/0x90 Mar 18 14:47:53 giscard kernel: [note_interrupt+97/144] note_interrupt+0x61/0x90 Mar 18 14:47:53 giscard kernel: [__do_IRQ+284/288] __do_IRQ+0x11c/0x120 Mar 18 14:47:53 giscard kernel: [do_IRQ+70/112] do_IRQ+0x46/0x70 Mar 18 14:47:53 giscard kernel: ======================= Mar 18 14:47:53 giscard kernel: [common_interrupt+26/32] common_interrupt+0x1a/0x20 Mar 18 14:47:53 giscard kernel: [default_idle+35/48] default_idle+0x23/0x30 Mar 18 14:47:53 giscard kernel: [cpu_idle+95/112] cpu_idle+0x5f/0x70 Mar 18 14:47:53 giscard kernel: [start_kernel+351/384] start_kernel+0x15f/0x180 Mar 18 14:47:53 giscard kernel: [unknown_bootoption+0/448] unknown_bootoption+0x0/0x1c0 Mar 18 14:47:53 giscard kernel: handlers: Mar 18 14:47:53 giscard kernel: [ide_intr+0/336] (ide_intr+0x0/0x150) Mar 18 14:47:53 giscard kernel: [ide_intr+0/336] (ide_intr+0x0/0x150) Mar 18 14:47:53 giscard kernel: [usb_hcd_irq+0/96] (usb_hcd_irq+0x0/0x60) Mar 18 14:47:53 giscard kernel: [pg0+532648896/1069179904] (e1000_intr+0x0/0x110 [e1000]) Mar 18 14:47:53 giscard kernel: Disabling IRQ #177 Mar 18 14:47:53 giscard kernel: hda: dma_timer_expiry: dma status == 0x24 Mar 18 14:47:53 giscard kernel: hda: DMA interrupt recovery Mar 18 14:47:53 giscard kernel: hda: lost interrupt Stefan -- "Reality is a poor substitute for my dreams." - anonymous --5vNYLRcllDrimb99 Content-Type: text/plain; charset=us-ascii Content-Disposition: attachment; filename=lcpci 0000:00:00.0 Host bridge: Intel Corp. 82865G/PE/P DRAM Controller/Host-Hub Interface (rev 02) Subsystem: Asustek Computer, Inc.: Unknown device 80a5 Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- Status: Cap+ 66MHz- UDF- FastB2B+ ParErr- DEVSEL=fast >TAbort- SERR- TAbort- SERR- TAbort- SERR- Reset- FastB2B- 0000:00:1d.0 USB Controller: Intel Corp. 82801EB/ER (ICH5/ICH5R) USB UHCI #1 (rev 02) (prog-if 00 [UHCI]) Subsystem: Asustek Computer, Inc. P4P800 Mainboard Control: I/O+ Mem- BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- Status: Cap- 66MHz- UDF- FastB2B+ ParErr- DEVSEL=medium >TAbort- SERR- TAbort- SERR- TAbort- SERR- TAbort- SERR- TAbort- SERR- TAbort- SERR- Reset- FastB2B- 0000:00:1f.0 ISA bridge: Intel Corp. 82801EB/ER (ICH5/ICH5R) LPC Bridge (rev 02) Control: I/O+ Mem+ BusMaster+ SpecCycle+ MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- Status: Cap- 66MHz- UDF- FastB2B+ ParErr- DEVSEL=medium >TAbort- SERR- TAbort- SERR- TAbort- SERR- TAbort- SERR- TAbort- SERR- TAbort- SERR- ; Sat, 19 Mar 2005 07:24:33 -0800 Received: from electric-eye.fr.zoreil.com (localhost.localdomain [127.0.0.1]) by fr.zoreil.com (8.13.1/8.12.1) with ESMTP id j2JFO1Rp005152; Sat, 19 Mar 2005 16:24:01 +0100 Received: (from romieu@localhost) by electric-eye.fr.zoreil.com (8.13.1/8.13.1/Submit) id j2JFNtNG005151; Sat, 19 Mar 2005 16:23:55 +0100 Date: Sat, 19 Mar 2005 16:23:54 +0100 From: Francois Romieu To: Jon Mason Cc: Kosta Todorovic , Ben Greear , jgarzik@pobox.com, tulip-users@lists.sourceforge.net, netdev@oss.sgi.com Subject: Re: Network card driver problem (znb.o/tulip) Message-ID: <20050319152354.GA4946@electric-eye.fr.zoreil.com> References: <200503182333.51470.jdmason@us.ibm.com> <200503190757.27727.jdmason@us.ibm.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200503190757.27727.jdmason@us.ibm.com> User-Agent: Mutt/1.4.1i X-Organisation: Land of Sunshine Inc. X-Virus-Scanned: ClamAV 0.83/774/Fri Mar 18 17:04:06 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 363 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: romieu@fr.zoreil.com Precedence: bulk X-list: netdev Content-Length: 518 Lines: 13 Jon Mason : [...] > The ZNXY website provides the driver source for the 4port adapter (and it is > GPL'ed), but it seems to me that this is really an issue of getting the > adapter to work with the "real" kernel driver, tulip. There are no sources for the rlk.O file and the driver suffers a bit from the usual out-of-tree hal braindamage. Both can probably be worked around but I would not make my business depend on the availability of a sane driver within a reasonable timescale. -- Ueimor From colin@colino.net Sat Mar 19 08:37:24 2005 Received: with ECARTIS (v1.0.0; list netdev); Sat, 19 Mar 2005 08:37:33 -0800 (PST) Received: from paperstreet.colino.net (colino.net [213.41.131.56]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j2JGbNha025132 for ; Sat, 19 Mar 2005 08:37:23 -0800 Received: by paperstreet.colino.net (Postfix, from userid 1015) id 053EF101A0; Sat, 19 Mar 2005 17:37:07 +0100 (CET) Received: from jack.colino.net (jack.colino.net [192.168.0.11]) by paperstreet.colino.net (Postfix) with ESMTP id 03E7910183; Sat, 19 Mar 2005 17:37:05 +0100 (CET) Date: Sat, 19 Mar 2005 17:37:04 +0100 From: Colin Leroy To: Andrew Morton Cc: linux-usb-devel@lists.sourceforge.net, netdev@oss.sgi.com Subject: [PATCH] Missing hunk in drivers/usb/Makefile Message-ID: <20050319173704.39983cf7@jack.colino.net> X-Mailer: Sylpheed-Claws 1.0.3cvs2.6 (GTK+ 2.6.1; powerpc-unknown-linux-gnu) X-Face: Fy:*XpRna1/tz}cJ@O'0^:qYs:8b[Rg`*8,+o^[fI?<%5LeB,Xz8ZJK[r7V0hBs8G)*&C+XA0qHoR=LoTohe@7X5K$A-@cN6n~~J/]+{[)E4h'lK$13WQf$.R+Pi;E09tk&{t|;~dakRD%CLHrk6m!?gA,5|Sb=fJ=>[9#n1Bu8?VngkVM4{'^'V_qgdA.8yn3) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV 0.83/774/Fri Mar 18 17:04:06 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 364 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: colin@colino.net Precedence: bulk X-list: netdev Content-Length: 608 Lines: 17 Hi, I see there's been a driver for zd1201 added in drivers/usb/net/. There's a hunk missing in drivers/usb/Makefile, the driver doesn't get built if nothing else in drivers/usb/net is configured in : Signed-off-by: Colin Leroy --- a/drivers/usb/Makefile 2005-03-18 10:26:38.000000000 +0100 +++ b/drivers/usb/Makefile 2005-03-18 10:27:22.000000000 +0100 @@ -50,6 +50,7 @@ obj-$(CONFIG_USB_PEGASUS) += net/ obj-$(CONFIG_USB_RTL8150) += net/ obj-$(CONFIG_USB_USBNET) += net/ +obj-$(CONFIG_USB_ZD1201) += net/ obj-$(CONFIG_USB_HPUSBSCSI) += image/ obj-$(CONFIG_USB_MDC800) += image/ From mlists@danielinux.net Sat Mar 19 09:00:27 2005 Received: with ECARTIS (v1.0.0; list netdev); Sat, 19 Mar 2005 09:00:32 -0800 (PST) Received: from ms004msg.fastwebnet.it (ms004msg.fastwebnet.it [213.140.2.58]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j2JH0Q1W026961 for ; Sat, 19 Mar 2005 09:00:27 -0800 Received: from [192.168.1.66] (37.10.150.65) by ms004msg.fastwebnet.it (7.2.052.3) id 42386767000A3941; Sat, 19 Mar 2005 17:59:41 +0100 From: Daniele Lacamera Reply-To: mlists@danielinux.net To: Stephen Hemminger Subject: Re: [PATCH] TCP Hybla Date: Sat, 19 Mar 2005 17:59:37 +0100 User-Agent: KMail/1.7.1 References: <20050318163123.14969084@dxpl.pdx.osdl.net> In-Reply-To: <20050318163123.14969084@dxpl.pdx.osdl.net> Cc: "David S. Miller" , netdev@oss.sgi.com MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200503191759.38103.mlists@danielinux.net> X-Virus-Scanned: ClamAV 0.83/774/Fri Mar 18 17:04:06 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 365 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: mlists@danielinux.net Precedence: bulk X-list: netdev Content-Length: 570 Lines: 17 On Saturday 19 March 2005 01:31, you wrote: > Here is a version of TCP Hybla based on the new split out of TCP > algorithms. It doesn't work right, I probably broke something. Stephen, please, could you point me to the tree having this new cool feature that splits tcp enhancements in separate modules? I'd like to fix the hybla module and make the necessary experiments. > Original code for RTT0 was wrong because HZ=1000 on 2.6, so I changed > it to be a parameter explicitly in ms. Is this true for any arch? Regards, -- Daniele Lacamera root at danielinux.net From arnaldo.melo@gmail.com Sat Mar 19 09:19:44 2005 Received: with ECARTIS (v1.0.0; list netdev); Sat, 19 Mar 2005 09:19:52 -0800 (PST) Received: from wproxy.gmail.com (wproxy.gmail.com [64.233.184.204]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j2JHJiBW028512 for ; Sat, 19 Mar 2005 09:19:44 -0800 Received: by wproxy.gmail.com with SMTP id 50so538542wri for ; Sat, 19 Mar 2005 09:19:36 -0800 (PST) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:reply-to:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:references; b=IGKCqMnuF5qmRYX6JuaYkWA/14SnjLTktkcImPmpQ5sn6Czf494GhPV04g3eHKOSobYQykZGp4tMPKc5yyayXDioWj4enF8a8UUxlrQT6wO+lWy8ipKQRp+EW4zkd1lyHtZi4VXcKVxIb6l1GPpOE38byRb0s4LzuZKjH7hUoto= Received: by 10.54.18.29 with SMTP id 29mr5117304wrr; Sat, 19 Mar 2005 09:19:36 -0800 (PST) Received: by 10.54.10.49 with HTTP; Sat, 19 Mar 2005 09:19:36 -0800 (PST) Message-ID: <39e6f6c7050319091910bff678@mail.gmail.com> Date: Sat, 19 Mar 2005 14:19:36 -0300 From: Arnaldo Carvalho de Melo Reply-To: acme@conectiva.com.br To: mlists@danielinux.net Subject: Re: [PATCH] TCP Hybla Cc: Stephen Hemminger , "David S. Miller" , netdev@oss.sgi.com In-Reply-To: <200503191759.38103.mlists@danielinux.net> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit References: <20050318163123.14969084@dxpl.pdx.osdl.net> <200503191759.38103.mlists@danielinux.net> X-Virus-Scanned: ClamAV 0.83/774/Fri Mar 18 17:04:06 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 366 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: arnaldo.melo@gmail.com Precedence: bulk X-list: netdev Content-Length: 626 Lines: 17 On Sat, 19 Mar 2005 17:59:37 +0100, Daniele Lacamera wrote: > On Saturday 19 March 2005 01:31, you wrote: > > Here is a version of TCP Hybla based on the new split out of TCP > > algorithms. It doesn't work right, I probably broke something. > > Stephen, please, could you point me to the tree having this new cool > feature that splits tcp enhancements in separate modules? > I'd like to fix the hybla module and make the necessary experiments. Daniele, AFAIK Stephen posted all he had here in netdev, look at previous messages for a series of patches posted by him, IIRC yesterday. - Arnaldo From acme@conectiva.com.br Sat Mar 19 10:06:36 2005 Received: with ECARTIS (v1.0.0; list netdev); Sat, 19 Mar 2005 10:06:43 -0800 (PST) Received: from orion.netbank.com.br (orion.netbank.com.br [200.203.199.90]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j2JI6Y1M031368 for ; Sat, 19 Mar 2005 10:06:35 -0800 Received: from [200.181.148.103] (helo=oops.ghostprotocols.net) by orion.netbank.com.br with asmtp (Exim 3.33 #1) id 1DCiLQ-0002mj-00; Sat, 19 Mar 2005 15:06:40 -0300 Received: by oops.ghostprotocols.net (Postfix, from userid 500) id D38CE74629; Sat, 19 Mar 2005 15:06:03 -0300 (BRT) Date: Sat, 19 Mar 2005 15:06:03 -0300 From: Arnaldo Carvalho de Melo To: davem@davemloft.net, Marcel Holtmann Cc: netdev@oss.sgi.com Subject: [PATCH][BLUETOOTH] remove now unneeded references to sk_protinfo Message-ID: <20050319180603.GB29585@conectiva.com.br> Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="RnlQjJ0d97Da+TV1" Content-Disposition: inline X-Url: http://advogato.org/person/acme User-Agent: Mutt/1.5.6i X-Virus-Scanned: ClamAV 0.83/774/Fri Mar 18 17:04:06 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 367 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: acme@conectiva.com.br Precedence: bulk X-list: netdev Content-Length: 2240 Lines: 83 --RnlQjJ0d97Da+TV1 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Hi David, Marcel, Please apply this patch, now only the HAM radio protocols and af_wanpipe uses sk_protinfo. Available at: bk://kernel.bkbits.net/acme/connection_sock-2.6 - Arnaldo --RnlQjJ0d97Da+TV1 Content-Type: text/plain; charset=us-ascii Content-Disposition: attachment; filename="bluetooth_sk_protinfo_removal.patch" =================================================================== ChangeSet@1.2289, 2005-03-19 14:41:18-03:00, acme@toy.ghostprotocols.net [BLUETOOTH] remove now unneeded references to sk_protinfo Now that sk_protinfo is not used anymore for storing private proto state, we can safely remove the code in the sock destruct path to kfree it. Signed-off-by: Arnaldo Carvalho de Melo Signed-off-by: Marcel Holtmann Signed-off-by: David S. Miller l2cap.c | 3 --- rfcomm/sock.c | 3 --- sco.c | 3 --- 3 files changed, 9 deletions(-) diff -Nru a/net/bluetooth/l2cap.c b/net/bluetooth/l2cap.c --- a/net/bluetooth/l2cap.c 2005-03-19 15:01:55 -03:00 +++ b/net/bluetooth/l2cap.c 2005-03-19 15:01:55 -03:00 @@ -264,9 +264,6 @@ skb_queue_purge(&sk->sk_receive_queue); skb_queue_purge(&sk->sk_write_queue); - - if (sk->sk_protinfo) - kfree(sk->sk_protinfo); } static void l2cap_sock_cleanup_listen(struct sock *parent) diff -Nru a/net/bluetooth/rfcomm/sock.c b/net/bluetooth/rfcomm/sock.c --- a/net/bluetooth/rfcomm/sock.c 2005-03-19 15:01:55 -03:00 +++ b/net/bluetooth/rfcomm/sock.c 2005-03-19 15:01:55 -03:00 @@ -196,9 +196,6 @@ rfcomm_dlc_unlock(d); rfcomm_dlc_put(d); - - if (sk->sk_protinfo) - kfree(sk->sk_protinfo); } static void rfcomm_sock_cleanup_listen(struct sock *parent) diff -Nru a/net/bluetooth/sco.c b/net/bluetooth/sco.c --- a/net/bluetooth/sco.c 2005-03-19 15:01:55 -03:00 +++ b/net/bluetooth/sco.c 2005-03-19 15:01:55 -03:00 @@ -334,9 +334,6 @@ skb_queue_purge(&sk->sk_receive_queue); skb_queue_purge(&sk->sk_write_queue); - - if (sk->sk_protinfo) - kfree(sk->sk_protinfo); } static void sco_sock_cleanup_listen(struct sock *parent) --RnlQjJ0d97Da+TV1-- From marcel@holtmann.org Sat Mar 19 10:29:34 2005 Received: with ECARTIS (v1.0.0; list netdev); Sat, 19 Mar 2005 10:29:38 -0800 (PST) Received: from mail.holtmann.net (coyote.holtmann.net [217.160.111.169]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j2JITXDQ000316 for ; Sat, 19 Mar 2005 10:29:34 -0800 Received: from pegasus (pD9E11C1C.dip.t-dialin.net [217.225.28.28]) by mail.holtmann.net (8.12.3/8.12.3/Debian-7.1) with ESMTP id j2JISxJG025415 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NO); Sat, 19 Mar 2005 19:28:59 +0100 Subject: Re: [PATCH][BLUETOOTH] remove now unneeded references to sk_protinfo From: Marcel Holtmann To: Arnaldo Carvalho de Melo Cc: "David S. Miller" , Network Development Mailing List In-Reply-To: <20050319180603.GB29585@conectiva.com.br> References: <20050319180603.GB29585@conectiva.com.br> Content-Type: text/plain Date: Sat, 19 Mar 2005 19:28:48 +0100 Message-Id: <1111256928.9930.1.camel@pegasus> Mime-Version: 1.0 X-Mailer: Evolution 2.0.4 Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV 0.83/774/Fri Mar 18 17:04:06 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 368 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: marcel@holtmann.org Precedence: bulk X-list: netdev Content-Length: 344 Lines: 17 Hi Arnaldo, > Please apply this patch, now only the HAM radio protocols > and af_wanpipe uses sk_protinfo. > > Available at: > > bk://kernel.bkbits.net/acme/connection_sock-2.6 patch is in my tree now and I will send it to Dave with fixes for some other race conditions very soon. One of them needs some extra testing. Regards Marcel From marcel@holtmann.org Sat Mar 19 12:07:15 2005 Received: with ECARTIS (v1.0.0; list netdev); Sat, 19 Mar 2005 12:07:19 -0800 (PST) Received: from mail.holtmann.net (coyote.holtmann.net [217.160.111.169]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j2JK7E8B005026 for ; Sat, 19 Mar 2005 12:07:15 -0800 Received: from pegasus (pD9E11C1C.dip.t-dialin.net [217.225.28.28]) by mail.holtmann.net (8.12.3/8.12.3/Debian-7.1) with ESMTP id j2JK77JG025821 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NO); Sat, 19 Mar 2005 21:07:07 +0100 Subject: Re: [2.6 patch] net/bluetooth/rfcomm/core.: make a variable static From: Marcel Holtmann To: Adrian Bunk Cc: Max Krasnyansky , bluez-devel@lists.sourceforge.net, Network Development Mailing List , Linux Kernel Mailing List In-Reply-To: <20050315143903.GK3189@stusta.de> References: <20050315143903.GK3189@stusta.de> Content-Type: text/plain Date: Sat, 19 Mar 2005 21:06:57 +0100 Message-Id: <1111262817.9203.0.camel@pegasus> Mime-Version: 1.0 X-Mailer: Evolution 2.0.4 Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV 0.83/774/Fri Mar 18 17:04:06 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 369 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: marcel@holtmann.org Precedence: bulk X-list: netdev Content-Length: 125 Lines: 11 Hi Adrian, > This patch makes a needlessly global variable static. the patch is in my tree now. Thanks. Regards Marcel From ak@muc.de Sat Mar 19 12:15:05 2005 Received: with ECARTIS (v1.0.0; list netdev); Sat, 19 Mar 2005 12:15:11 -0800 (PST) Received: from one.firstfloor.org (one.firstfloor.org [213.235.205.2]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j2JKF47K005818 for ; Sat, 19 Mar 2005 12:15:04 -0800 Received: by one.firstfloor.org (Postfix, from userid 502) id 0FC4AD033E; Sat, 19 Mar 2005 21:15:02 +0100 (CET) To: "Leonid Grossman" Cc: , , , "'Andi Kleen'" Subject: Re: [ANNOUNCE] Experimental Driver for Neterion/S2io 10GbE Adapters References: <200503151507.j2FF7sDD011131@guinness.s2io.com> <200503151555.j2FFtqDD019050@guinness.s2io.com> From: Andi Kleen Date: Sat, 19 Mar 2005 21:15:02 +0100 In-Reply-To: <200503151555.j2FFtqDD019050@guinness.s2io.com> (Leonid Grossman's message of "Tue, 15 Mar 2005 07:55:51 -0800") Message-ID: User-Agent: Gnus/5.110002 (No Gnus v0.2) Emacs/21.3 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Virus-Scanned: ClamAV 0.83/774/Fri Mar 18 17:04:06 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 370 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: ak@muc.de Precedence: bulk X-list: netdev Content-Length: 3071 Lines: 72 "Leonid Grossman" writes: >> >> > Leonid Grossman writes: >> It's not the best maintenance option (both for us and arguably, even for a >> non-primary-author kernel hackers) but it's workable. > > The statement about non-primary-author kernel hacker interests needs some > clarification, before people started to throw things at me. > This is the last argument before I shut up, I promise :-) First you wont like it, but Linux kernel maintainers usually dont give firm promises to merge anything. They just say "with that i wont merge it" and even that is flexible sometimes. It is not like a company who gives commitments or signs contracts, it is really the final patch that counts. The best way to get code merged is to write it like the maintainers wants it, but of course that does not happen always. However when the code is clean and the biggest issues are fixed and only some relatively small ones are left I think you have a good chance to see your code merged. > > Arguably, a hacker will be much more interested in changing the non-HAL part > of a driver. This part of the code has to look and feel the same as any > other Linux net driver. If it doesn't, then we've done a poor job and need > to go back. There are currently some issues, mostly the "LAL" in it (Linux Adaption Layer that wraps everything) and all the ugly function parameters (IN and __STATIC_* and the wrapped list functions ). That is what just poked in my eyes at the first look. I personally dont care that much about the later stuff which is more cosmetic, but a lot of other people strongly object to code that does not look like other Linux code so I would recommend to fix it. What I also did not like was that you had high level logic in these HAL parts - like handling packet queues etc. Normally IMHO high level logic should be directly in the functions that are directly called from the kernel. This way it is easy to follow the main logic of the driver if someone is familiar with linux network drivers in general LALs are strongly frowned at upon and I personally also dont like them at all. AFAIK there is one two drivers in the kernel tree that have it and it is considered an historic accident by everybody I know ,=) > In our experience, the vast majority of code fixes and new features in the > HAL code comes from our team (hey, we planted all these bugs to begin with > :-)), and to a much lesser extend from other OS developers, and only then > from Linux community. The problem is usually that when there is some bug in your driver and someone not in your company wants to debug it because the bug is causing them problems (that is one of the great advantages of free software that they can do it themselves), then they want relatively clean code. The same happens for the maintainer who is hunting some issue and needs to change your driver slightly for some infrastructure change. So even though most changes come likely from you there is a need for other people to understand and change your code. -Andi From ak@muc.de Sat Mar 19 12:19:13 2005 Received: with ECARTIS (v1.0.0; list netdev); Sat, 19 Mar 2005 12:19:18 -0800 (PST) Received: from one.firstfloor.org (one.firstfloor.org [213.235.205.2]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j2JKJC75009881 for ; Sat, 19 Mar 2005 12:19:13 -0800 Received: by one.firstfloor.org (Postfix, from userid 502) id E2B30D033E; Sat, 19 Mar 2005 21:19:11 +0100 (CET) To: Stephen Hemminger Cc: baruch@ev-en.org, netdev@oss.sgi.com Subject: Re: [RFC] TCP congestion schedulers References: <421CF5E5.1060606@ev-en.org> <20050223135732.39e62c6c.davem@davemloft.net> <421D1E66.5090301@osdl.org> <421D30FA.1060900@ev-en.org> <20050225120814.5fa77b13@dxpl.pdx.osdl.net> <20050309210442.3e9786a6.davem@davemloft.net> <4230288F.1030202@ev-en.org> <20050310182629.1eab09ec.davem@davemloft.net> <20050311120054.4bbf675a@dxpl.pdx.osdl.net> <20050311201011.360c00da.davem@davemloft.net> <20050314151726.532af90d@dxpl.pdx.osdl.net> From: Andi Kleen Date: Sat, 19 Mar 2005 21:19:11 +0100 In-Reply-To: <20050314151726.532af90d@dxpl.pdx.osdl.net> (Stephen Hemminger's message of "Mon, 14 Mar 2005 15:17:26 -0800") Message-ID: User-Agent: Gnus/5.110002 (No Gnus v0.2) Emacs/21.3 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Virus-Scanned: ClamAV 0.83/774/Fri Mar 18 17:04:06 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 371 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: ak@muc.de Precedence: bulk X-list: netdev Content-Length: 849 Lines: 23 Stephen Hemminger writes: > Since developers want to experiment with different congestion > control mechanisms, and the kernel is getting bloated with overlapping > data structure and code for multiple algorithms; here is a patch to > split out the Reno, Vegas, Westwood, BIC congestion control stuff > into an infrastructure similar to the I/O schedulers. [...] Did you do any benchmarks to check that wont slow it down? I would recommend to try it on a IA64 machine if possible. In the past we found that adding indirect function calls on IA64 to networking caused measurable slowdowns in macrobenchmarks. In that case it was LSM callbacks, but your code looks like it will add even more. One way to avoid this concern would be to set up the "standard" congestion avoidance in a way that it could be inlined. -Andi From leonid.grossman@neterion.com Sat Mar 19 14:20:28 2005 Received: with ECARTIS (v1.0.0; list netdev); Sat, 19 Mar 2005 14:20:33 -0800 (PST) Received: from ns1.s2io.com (ns1.s2io.com [142.46.200.198]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j2JMKRrE015114 for ; Sat, 19 Mar 2005 14:20:28 -0800 Received: from guinness.s2io.com (sentry.s2io.com [142.46.200.199]) by ns1.s2io.com (8.12.10/8.12.10) with ESMTP id j2JMJnuN021220; Sat, 19 Mar 2005 17:19:49 -0500 (EST) Received: from lgt40 ([10.16.16.166]) by guinness.s2io.com (8.12.6/8.12.6) with ESMTP id j2JMJmDD014063; Sat, 19 Mar 2005 17:19:48 -0500 (EST) Message-Id: <200503192219.j2JMJmDD014063@guinness.s2io.com> From: "Leonid Grossman" To: "'Andi Kleen'" Cc: , , Subject: RE: [ANNOUNCE] Experimental Driver for Neterion/S2io 10GbE Adapters Date: Sat, 19 Mar 2005 14:19:47 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook, Build 11.0.5510 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1409 In-Reply-To: Thread-Index: AcUswF3c9/7R37PfQqiw+Ae707HAJgACF4yg X-Scanned-By: MIMEDefang 2.34 X-Virus-Scanned: ClamAV 0.83/774/Fri Mar 18 17:04:06 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 372 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: leonid.grossman@neterion.com Precedence: bulk X-list: netdev Content-Length: 3582 Lines: 92 > First you wont like it, but Linux kernel maintainers usually dont give > firm promises to merge anything. They just say "with that i wont merge > it" > and even that is flexible sometimes. It is not like a company who > gives commitments or signs contracts, it is really the final patch that > counts. > > The best way to get code merged is to write it like the maintainers > wants it, but of course that does not happen always. > > However when the code is clean and the biggest issues are fixed > and only some relatively small ones are left I think you have a good > chance to see your code merged. Sure. I was not asking for a promise to merge the code, only for a rough consensus that a HAL-based approach by itself is not a showstopper. Without such a consensus, it doesn't matter if we address other issues, right? > > > > > Arguably, a hacker will be much more interested in changing the non-HAL > part > > of a driver. This part of the code has to look and feel the same as any > > other Linux net driver. If it doesn't, then we've done a poor job and > need > > to go back. > > There are currently some issues, mostly the "LAL" in it (Linux Adaption > Layer that wraps everything) and all the ugly function parameters (IN and > __STATIC_* and the wrapped list functions ). That is what just poked in my > eyes at the first look. > > I personally dont care that much about the later stuff which > is more cosmetic, but a lot of other people strongly object to > code that does not look like other Linux code so I would recommend to > fix it. Agreed; we are fixing this for the new submission. > > > What I also did not like was that you had high level logic in these > HAL parts - like handling packet queues etc. Normally IMHO high level > logic should be directly in the functions that are directly called > from the kernel. This way it is easy to follow the main logic > of the driver if someone is familiar with linux network drivers > in general In general, I agree that low level logic (AKA HAL code) needs to be as small as possible, and should not include a code that is typically common in Linux (or any other) network driver. Unfortunately MAC driver models for different Operating Systems diverged so much, the interface for the low level logic ends up higher than anyone would like... This is a valid comment though, we will see if there is room for improvement. Skip... > The problem is usually that when there is some bug in your driver > and someone not in your company wants to debug it because the bug > is causing them problems (that is one of the great advantages of free > software that they can do it themselves), then they want relatively > clean code. The same happens for the maintainer who is hunting some > issue and needs to change your driver slightly for some infrastructure > change. > > So even though most changes come likely from you there is a need > for other people to understand and change your code. I agree, to a point - if for a hacker or a maintainer this driver is way hard to understand (comparing to it's "s2io" sibling), then is not a good thing and has to be addressed as much as practical. Hopefully follow-up submissions will get to the point when HAL code still has some non-Linux "accent" but it's sufficiently clean for people to understand it. This will be a tradeoff for some, but hopefully a good one - I still think the majority of low-level code fixes will come from our team (sometimes by virtue of fixing a problem in different OS). Thanks for the detailed feedback! Leonid > > -Andi From bunk@stusta.de Sat Mar 19 15:05:07 2005 Received: with ECARTIS (v1.0.0; list netdev); Sat, 19 Mar 2005 15:05:13 -0800 (PST) Received: from mailout.stusta.mhn.de (mailout.stusta.mhn.de [141.84.69.5]) by oss.sgi.com (8.13.0/8.13.0) with SMTP id j2JN55Bj017369 for ; Sat, 19 Mar 2005 15:05:06 -0800 Received: (qmail 26571 invoked from network); 19 Mar 2005 23:04:59 -0000 Received: from r063144.stusta.swh.mhn.de (10.150.63.144) by mailhub.stusta.mhn.de with SMTP; 19 Mar 2005 23:04:59 -0000 Received: by r063144.stusta.swh.mhn.de (Postfix, from userid 1000) id BD9E6E7F4F; Sun, 20 Mar 2005 00:04:58 +0100 (CET) Date: Sun, 20 Mar 2005 00:04:58 +0100 From: Adrian Bunk To: chas3@users.sourceforge.net Cc: shemminger@osdl.org, bridge@osdl.org, linux-atm-general@lists.sourceforge.net, netdev@oss.sgi.com, linux-kernel@vger.kernel.org Subject: Re: [2.6 patch] fix bridge <-> ATM compile error Message-ID: <20050319230458.GB18495@stusta.de> References: <20050316181532.GA3251@stusta.de> <200503172036.j2HKadfm000732@ginger.cmf.nrl.navy.mil> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200503172036.j2HKadfm000732@ginger.cmf.nrl.navy.mil> User-Agent: Mutt/1.5.6+20040907i X-Virus-Scanned: ClamAV 0.83/774/Fri Mar 18 17:04:06 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 373 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: bunk@stusta.de Precedence: bulk X-list: netdev Content-Length: 603 Lines: 21 On Thu, Mar 17, 2005 at 03:36:40PM -0500, chas williams - CONTRACTOR wrote: > In message <20050316181532.GA3251@stusta.de>,Adrian Bunk writes: > >Letting CONFIG_BRIDGE depend on CONFIG_ATM doesn't sound like a good > >idea, since I doubt all people using the Bridge code require ATM > >support. > > how about the following? >... Looks good. cu Adrian -- "Is there not promise of rain?" Ling Tan asked suddenly out of the darkness. There had been need of rain for many days. "Only a promise," Lao Er said. Pearl S. Buck - Dragon Seed From hadi@cyberus.ca Sun Mar 20 05:20:20 2005 Received: with ECARTIS (v1.0.0; list netdev); Sun, 20 Mar 2005 05:20:34 -0800 (PST) Received: from mx03.cybersurf.com (mx03.cybersurf.com [209.197.145.106]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j2KDKJca013586 for ; Sun, 20 Mar 2005 05:20:20 -0800 Received: from mail.cyberus.ca ([209.197.145.21]) by mx03.cybersurf.com with esmtp (Exim 4.30) id 1DD0Lo-0005vq-Sz for netdev@oss.sgi.com; Sun, 20 Mar 2005 08:20:16 -0500 Received: from [24.103.99.32] (helo=[10.0.0.9]) by mail.cyberus.ca with esmtp (Exim 4.20) id 1DD0Lh-0007TA-29; Sun, 20 Mar 2005 08:20:09 -0500 Subject: Re: dummy as IMQ replacement From: jamal Reply-To: hadi@cyberus.ca To: Andy Furniss Cc: Thomas Graf , Remus , netdev@oss.sgi.com, Nguyen Dinh Nam , Andre Tomt , syrius.ml@no-log.org, Damion de Soto In-Reply-To: <423BFD9F.50401@dsl.pipex.com> References: <1107123123.8021.80.camel@jzny.localdomain> <0fcf01c5077f$579e4b80$6e69690a@RIMAS> <1107174142.8021.121.camel@jzny.localdomain> <00c301c524b4$938cd240$6e69690a@RIMAS> <1110379135.1091.143.camel@jzny.localdomain> <1110416767.1111.76.camel@jzny.localdomain> <025501c52552$2dbf87c0$6e69690a@RIMAS> <1110453757.1108.87.camel@jzny.localdomain> <423B7BCB.10400@dsl.pipex.com> <1111196668.1146.114.camel@jzny.localdomain> <423BFD9F.50401@dsl.pipex.com> Content-Type: multipart/mixed; boundary="=-HeZj/BB8k5iDZlF/HZDh" Organization: jamalopolous Message-Id: <1111324805.1094.11.camel@jzny.localdomain> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.2.2 Date: 20 Mar 2005 08:20:05 -0500 X-Virus-Scanned: ClamAV 0.83/774/Fri Mar 18 17:04:06 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 374 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: hadi@cyberus.ca Precedence: bulk X-list: netdev Content-Length: 7348 Lines: 155 --=-HeZj/BB8k5iDZlF/HZDh Content-Type: text/plain Content-Transfer-Encoding: 7bit Hi Andy, Apologies again - I wont be able to get access to my test machine until tuesday. On Sat, 2005-03-19 at 05:23, Andy Furniss wrote: > $TC filter add dev eth0 parent ffff: protocol ip prio 10 u32 \ > match u32 0 0 flowid 1:1 \ > action ipt -j MARK --set-mark 1 > > It still gives memory error with 1.3.1 , with 1.2.11 it parses OK but I > get bogus stats - hit count is OK > > [root@amd /home/andy/Qos]# tc -s filter ls dev eth0 parent ffff: > > filter protocol ip pref 10 u32 > filter protocol ip pref 10 u32 fh 800: ht divisor 1 > filter protocol ip pref 10 u32 fh 800::800 order 2048 key ht 800 bkt 0 > flowid 1:1 (rule hit 12 success 12) > match 00000000/00000000 at 0 (success 12 ) > action order 1: tablename: mangle hook: NF_IP_PRE_ROUTING > target MARK set 0x1 > index 1 ref 1 bind 1 installed 251 sec expires 1 sec > Action statistics: > Sent 7630953 bytes 0 pkt > rate 3146Kbit 1095565348pps > Ok, this seems to be a bug in the stats - I think it may have been introduced during the new kernel stats code updates. Ive cced Thomas who added that code, he may be able to figure it oput before i get back > If I try with the lines below added > > action egress redirect dev dummy0 or > action redirect dev dummy0 > > I just get errors on whatever is after action - or memory errors with 1.3.1. > > Using tc iproute2-ss050112 + patch for these tests. > So if i have understood you correctly, with this version of tc and version of iproute2, you have no problems other than stats being messed up? i.e action ipt .. action mirred .. looks/works fine? I think iptables >= 1.2.11 may have broken backward compatibility, i will investigate when i get back. Lets narrow down to what version of iproute2 that things break - stick with iptables 1.2.11 > I don't know if it's relevant but I am using gcc-2.95.3, which meant I > had to change the dummy patch a bit as it doesn't (for me) like variable > declarations in the middle of functions. > > drivers/net/dummy.c: In function `dummy_xmit': > drivers/net/dummy.c:218: parse error before `from' > drivers/net/dummy.c:219: `from' undeclared (first use in this function) > > So I changed to > > static int dummy_xmit(struct sk_buff *skb, struct net_device *dev) > { > struct dummy_private *dp = ((struct net_device *)dev)->priv; > struct net_device_stats *stats = &dp->stats; > int ret = 0; > __u32 from; > > { > stats->tx_packets++; > stats->tx_bytes+=skb->len; > } > #ifdef CONFIG_NET_CLS_ACT > from = G_TC_FROM(skb->tc_verd); > > Is there a switch for this? - or am I the only one who actually does > kernel stuff with 2.95.3 (using LFS 5.1, which uses 3.3 by default but > keeps 2.95.3 in /opt specially for kernels) > The change you have above is needed - dont recall of any gcc switches which will resolve this. I have fixed this for Remus as well back when he was testing (attached dummy.c he is using); the stats are also a little misleading on whats rx or tx. So those are fixed too in the attached version. cheers, jamal --=-HeZj/BB8k5iDZlF/HZDh Content-Disposition: attachment; filename=dummy.c.gz Content-Type: application/x-gzip; name=dummy.c.gz Content-Transfer-Encoding: base64 H4sICEhkMkIAA2R1bW15LmMAvVn7cxpHEv6Z/StaStkBjF52HCcm8pUiY5s7CSkSvlxdLrU1sAOM WXbX+xDizrq//b6emX0JkJ1LKq5EQtM9PT39/Ho4aJOXLRar/fFLEuYjBTIlL1Y3MnacxnAmKcri KEwkhRNKZyqxRMKnNKQoDm+UJ3m3vFFjqddCFaQknEYcZilWZvg9nXVolKUUhCmziHGaCd9fURqL IFmolCIxnss02cehP89WfyHqT2gVZjQTNyx9IcYzFUhazrQqAbaOwyCQ41SFAesiAgrHY5HgT+E7 jcvLy4Prs/7lwSV+kK+CeUeLGzNfZTcrg/WYwmVAkJ0GYiGdxnImAygu9U4Wn0X7RBdYiZcKChSa YXuGv/1wLHzevs82A79Kgq9Tgp30SYlKUhmkfLkLXCIJ/SzXGwISWDyLCgfoI7NEBVOq3aLjNNiC 2geJlIuEmti8kC3IwO9sPKMQB86k8GgSxnrVV2nqS5oKFeSaWfdZx8FwlCzgChJ+KuNApKDu03CW JYW9vNBpOI1ftE3Yf3EWBKxd4qvoV6fRUBNccaKmVn9e3heeF+/LJNmHxSRuh/1Qdhrq+27e58EF WPVUBC+LVOYRCJ2XAv/HuAs0GMFCYThnBURKr9ndHv0oET3x1zDMXPoyhWltCDdE4BlHhmE0QoxZ ArzZ53X2ciyXJJZihRhawboQnOJ88pQHH0JCFPmrHSgigrn214kPo5yGt8bKkD2X8LKfcVxq1ZnJ C2mp0pnTWKhkmsHSXjXEG42Bgi7vQt8PcXKHnr5IZ3QOHY6+//4bGAvKLaWYS8/4W95GOFTooBG5 V000iBTXhgPZoo1ctQ49O6wKdNoHzkHbabRpWEthztMRAtgjGXCSUnfvFXO9Y69xnnqeSRf3Q5ak Ls52J1LCXoswli5NpEizWCYd3nN0SCspYigzQSTRySnvhuRxuFhIfRDCkw+gmYTR9uiv765ZL8f5 SgUwH6rID4j97PbAhMX+7NUaZRF6mS83UeD+QPqbKChopjZtIkpO6e1kFah0ux6RiMXCkCeenNDp xeBN/6076A3d07Nr9+R0WNkINQ6ieeom45n0sImcr2TgqQmuj71c24b/cIf9897F+yFR82n73T9b Dv3B/6pn/eSe9c/7Q15+9tRJ0jhDOdSp6EaID2Qg/cdp2HVo7xozuUkqUiQa/+w+cPN8ZyqSOVLS tX+SPcIud50GNwv+lzNGbJZgCspBG3GWpAg/T46yqTmTfMmFVwU6/YJwSYihRoYaOw0QbX6I/CXN 6sZH3W2Up1spz7ZSvtlKeb6V8u1WyoutlO+6hfGSuTvKJhNXF3X+F398gJiCaIPqrus84Bs+R43p JlQexSr3RbOuDtzdKuQ5+R72VpAt2IkK3eOYYOMqzXj3Fi29WVeT2sl81KG1eKK2OcjK2BZvbSN4 qiMJC83PCdKXs7GmFhJQ5LNbSv1DBOFvYB/7QCXb+X+7Ssg8kxjjKIONk0WEnAzHaKhh7CqvyUIb YNx7pQEUmyROwfhBTSZwC2IEKRyk8+buo+Ql/fj+LaW3ZM/kLnV6+Z4eef8KdjtaCIOeDo5qcTpO qJlEKnBV4gLWoAU1m481FztVL7VaLTSb/AReZgA0p2ksRiOEj/BjhOQK4h8W+DGTmdwgUa8/IPLu D4ltbeNN9r+BITc5poUPZfbVK2Xbi3jXtm2tvVfM2d1eT9vm1zE99qK9V7a6NjakEFgG78/OdABY TpQmenJ8ZG3NVDrmK2hm/ERJlfOmFpx+hKm5rlc2P7ebS0+l8Yqtjy11t+uNlZ3f5TsBmBUQiTl7 p3a2J7U7zfFxcXyjwUQTAalQfq5ehze1tMw7/qH1yYJN6jDTHUk/0Y0KzQJIhJsrOrPuCVVNjwpN pyFwjeXUEhz853zpBUr7uW727ClN4nABvrfu8NR9c3VxzvvANXaBrzydpY3qClgPu+tr14hfCBgg hu8LAC/HApZuXQsgnzypL49WqUyeHOuNvgxyT2rVHtPJ0O29vepdX69579vCJohE6wpTuK0HrHHr wvqDQlpd3ItCHIJbTdz49r4gfT78BIFgmSg/5QkI+DCC7T1u6YzWzS1BYe5UTKfS69BSgi8D0o+l Cj7owY1HU8PKuF4z61lBsy2AnQl1yWNfLzD+MKw/OnzEbBhkNUofZ3HMwLR//hP40MyIqVAuCVEo AZJQcnhGtb+UHuMSPTUUpyn9NyUR5qL9ffowS/LQg0nnk1giv+ejwhAVr3lxGEXSM860QfhlCVia /Fk1cx/M+0ri6TCuY608LFmMcZ6JhiTVOja9G12fGwcHhqrbjeFhWsXpS9i9Tqj6vtT8aREsn0nw Tfn6xUXBbnu5/dpGhwKj2vJhbFYDqkawg96TI6I1FIA53uW5F116S1/vmLbUjlpOCa0TqM3bUN0F NIq6NhB20C9vhK88Vw8pWnQzEbCgcD2RCvgTKsUSE1hAe72T16+vBhfDk7+f9M9YV0yecjGOVk3d ajkcWQDKaymhQ73hO/fkrDfg21lJh7q/IksnnEKLzMclRcLjm8LcueLwrrZYvnTB5PrIkG2YBle+ q0Mh1+X5qrReFj2wlwtHH+wKJvm31FlnOcwezKH7Ovf0fQucCIveQ45dyzITsWcjWUOY4wp2zXmQ pzlq4s5chW45y1Kk45kXTs062MoxLmdhNFnu579yCidYSdEwskB265blrF5b7FbZxTiPwOI6lahk 0bDiG+X7XGzvm08/WJAONth/byoDGbOrhJ/JxNjWRKJxlcG2hZ0smNM3LafLnGE8E8FUuos0K/CL IUx8MU3o0zH137xxBxcnV5d1yuNj+i+Tzt+fDfunJ9cskdvl+cXr92c99+LnQe8qVwVQ2AsX1XSp xb5Bjr9/Vqnk7p8CAllVJKcp0g9N3F8KSWwTiuuIolxdAxS2IGnJnz7RjqaoIMq0/sSNxbYzLrW0 ufdReUCt95EtPLF+Dai0C90NayfpJqSX+Fjd4ypUFsabmSkfJZYi5ta/s7NDQUiKtz1KeO7JpZjh p4LUymsdkxW6FQBZFBtlvt80EVNI1dWFJ3OEImy41gq1QdcxWg6OddezZirAsEYJuVnKhCs6PL3S KtfT0UjM+3YY5d3ZpMzdZ8bITSA9LkG6vsWGzloClS0t9ws7Lk96xqWbUfBDIHgz1NoUm7ajN6qB WFaK3/si8SeXi631wX3d+7F8F7BGtg959Mj3Xj7wP3HK1KDnUacC5iqfn1U+f1Pf8rxC+rby+UXl 83eVJ6fcH/ZiD3iE2m37INXV0GWQLUYy5m+s7FcLmks/3o9k/n3LaGXe1u2bMvc389HV77rN8pWr w92iQ4fQzbady5Orc9jz+rTGtXv/3CiRGSYQe/xua9NT2YNvR4idL3hi/f/CyimScA5AsCUBy/yP snhaTvHbSOnHSj5tKzo1pPmb3t7+HHswKt1gj07lPalD9Rellr1aaRSu/RVJ9212j7zRbpUha4Ph qparIWn+6GJ+bTJFBZ68rdageyZ19R6LMmQcW/hplmE3jL7h2DXfoTQTIO9w0txk5lZH9y3a1auP vN1OFde3CgxRyG5Vh5fBxXnvPOdpQg2cHMspf20a54eXO22X1FV8jcjdpXoBCzYrvdfm6y/aNL+a Nm/NQGYOt3ppc9xter7VR6+bOAvWlK6dxcrVtL5PvaPPuNVUqCarghPJuE11yJiMh/jyZX6+0M6r lChqk3WhmUNbHXr75tL9W+9q0Dtr8e2Njwz3Bg+Bg791aSp9GCn6ofplwOPHtMM2I/XkCW82St0P yuIckOFIHmLt49venmIIc6hh3n1DW7RScw3dnyflrSrrqhRBFt2zmDVY96F7GP3J2aQDVjV6yF3X 6jY4Qmzj0Pm85i1obumsXnOTemVnOeuf9gbXvebu28szbhj/A1nQrxmjIQAA --=-HeZj/BB8k5iDZlF/HZDh-- From hadi@cyberus.ca Sun Mar 20 05:40:20 2005 Received: with ECARTIS (v1.0.0; list netdev); Sun, 20 Mar 2005 05:40:24 -0800 (PST) Received: from mx01.cybersurf.com (mx01.cybersurf.com [209.197.145.104]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j2KDeKHq015597 for ; Sun, 20 Mar 2005 05:40:20 -0800 Received: from mail.cyberus.ca ([209.197.145.21]) by mx01.cybersurf.com with esmtp (Exim 4.30) id 1DD0f7-00032N-Hf for netdev@oss.sgi.com; Sun, 20 Mar 2005 06:40:13 -0700 Received: from [24.103.99.32] (helo=[10.0.0.9]) by mail.cyberus.ca with esmtp (Exim 4.20) id 1DD0f7-0000sO-SK; Sun, 20 Mar 2005 08:40:14 -0500 Subject: RE: [ANNOUNCE] Experimental Driver for Neterion/S2io 10GbE Adapters From: jamal Reply-To: hadi@cyberus.ca To: Leonid Grossman Cc: "'Andi Kleen'" , netdev@oss.sgi.com, leonid@neterion.com, jgarzik@pobox.com In-Reply-To: <200503192219.j2JMJmDD014063@guinness.s2io.com> References: <200503192219.j2JMJmDD014063@guinness.s2io.com> Content-Type: text/plain Organization: jamalopolous Message-Id: <1111326010.1093.32.camel@jzny.localdomain> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.2.2 Date: 20 Mar 2005 08:40:11 -0500 Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV 0.83/774/Fri Mar 18 17:04:06 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 375 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: hadi@cyberus.ca Precedence: bulk X-list: netdev Content-Length: 1615 Lines: 37 On Sat, 2005-03-19 at 17:19, Leonid Grossman wrote: > Sure. I was not asking for a promise to merge the code, only for a rough > consensus that a HAL-based approach by itself is not a showstopper. > Without such a consensus, it doesn't matter if we address other issues, > right? Typically theres only one motivation for HALs - maintain the same code base for 20 OSes. Makes it easier for a small company (not sure if yours fits that category) to maintain. It doesnt matter how differently you position or spin it (no offense intended), that is the main if not only motivation. OTOH, you shift the burden of the extra maintainance work to the people on the Linux side who know may have to understand what your layer does. This is why people hate it. I dont think it is sufficient to say your company will be updating the driver: - Years from now your company may not be around anymore but your hardware may still be. Who is going to fix the bugs then? - APIs, mechanisms etc change on Linux as well. You become a bottleneck if nobody understands your HAL because they have to wait for you to make the changes. Traditionaly whoever makes the changes on dirver schemes ensures all drivers are updated. Think positively that this is now offloaded from you. My suggestion: have a dedicated resource just for Linux - it is big enough to justify; maintain HAL for other OSes that will never change, I bet you whatever works for NDIS probably will continue to work for vxworks for the next 10 years - not much innovation going on there;-> or you could claim (bah!) theres stability on those OSes. cheers, jamal From hadi@cyberus.ca Sun Mar 20 05:55:22 2005 Received: with ECARTIS (v1.0.0; list netdev); Sun, 20 Mar 2005 05:55:27 -0800 (PST) Received: from mx04.cybersurf.com (mx04.cybersurf.com [209.197.145.108]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j2KDtMrq017285 for ; Sun, 20 Mar 2005 05:55:22 -0800 Received: from mail.cyberus.ca ([209.197.145.21]) by mx04.cybersurf.com with esmtp (Exim 4.30) id 1DD0ti-0002Af-QT for netdev@oss.sgi.com; Sun, 20 Mar 2005 08:55:18 -0500 Received: from [24.103.99.32] (helo=[10.0.0.9]) by mail.cyberus.ca with esmtp (Exim 4.20) id 1DD0tg-0002IJ-6Q; Sun, 20 Mar 2005 08:55:16 -0500 Subject: Re: dummy as IMQ replacement From: jamal Reply-To: hadi@cyberus.ca To: Andy Furniss Cc: Thomas Graf , Remus , netdev@oss.sgi.com, Nguyen Dinh Nam , Andre Tomt , syrius.ml@no-log.org, Damion de Soto In-Reply-To: <1111324805.1094.11.camel@jzny.localdomain> References: <1107123123.8021.80.camel@jzny.localdomain> <0fcf01c5077f$579e4b80$6e69690a@RIMAS> <1107174142.8021.121.camel@jzny.localdomain> <00c301c524b4$938cd240$6e69690a@RIMAS> <1110379135.1091.143.camel@jzny.localdomain> <1110416767.1111.76.camel@jzny.localdomain> <025501c52552$2dbf87c0$6e69690a@RIMAS> <1110453757.1108.87.camel@jzny.localdomain> <423B7BCB.10400@dsl.pipex.com> <1111196668.1146.114.camel@jzny.localdomain> <423BFD9F.50401@dsl.pipex.com> <1111324805.1094.11.camel@jzny.localdomain> Content-Type: text/plain Organization: jamalopolous Message-Id: <1111326913.1093.37.camel@jzny.localdomain> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.2.2 Date: 20 Mar 2005 08:55:13 -0500 Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV 0.83/774/Fri Mar 18 17:04:06 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 376 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: hadi@cyberus.ca Precedence: bulk X-list: netdev Content-Length: 1358 Lines: 38 On Sun, 2005-03-20 at 08:20, jamal wrote: > On Sat, 2005-03-19 at 05:23, Andy Furniss wrote: > > > [root@amd /home/andy/Qos]# tc -s filter ls dev eth0 parent ffff: > > > > filter protocol ip pref 10 u32 > > filter protocol ip pref 10 u32 fh 800: ht divisor 1 > > filter protocol ip pref 10 u32 fh 800::800 order 2048 key ht 800 bkt 0 > > flowid 1:1 (rule hit 12 success 12) > > match 00000000/00000000 at 0 (success 12 ) > > action order 1: tablename: mangle hook: NF_IP_PRE_ROUTING > > target MARK set 0x1 > > index 1 ref 1 bind 1 installed 251 sec expires 1 sec > > Action statistics: > > Sent 7630953 bytes 0 pkt > > rate 3146Kbit 1095565348pps > > > > Ok, this seems to be a bug in the stats - I think it may have been > introduced during the new kernel stats code updates. > Ive cced Thomas who added that code, he may be able to figure it oput > before i get back > OTOH, this may be a kernel issue. There have been some changes recently which updated some counters from 32 bit to 64 bit ;-> Clearly this will break the ABI and will give crap stats. Try also if you can kernel 2.6.10. I think weve narrowed down iptables to be working if <= 1.2.11 It will help me if you can narrow down the iproute2 version as well as the kernel version where things start breaking. cheers, jamal From hadi@cyberus.ca Sun Mar 20 06:05:54 2005 Received: with ECARTIS (v1.0.0; list netdev); Sun, 20 Mar 2005 06:06:01 -0800 (PST) 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 j2KE5r4Y018741 for ; Sun, 20 Mar 2005 06:05:54 -0800 Received: from localhost ([208.2.156.2]) by lotus.znyx.com (Lotus Domino Release 5.0.11) with ESMTP id 2005032006065675:17878 ; Sun, 20 Mar 2005 06:06:56 -0800 Subject: Re: Network card driver problem (znb.o/tulip) From: jamal Reply-To: hadi@cyberus.ca To: Francois Romieu Cc: Jon Mason , Kosta Todorovic , Ben Greear , jgarzik@pobox.com, tulip-users@lists.sourceforge.net, netdev@oss.sgi.com In-Reply-To: <20050319152354.GA4946@electric-eye.fr.zoreil.com> References: <200503182333.51470.jdmason@us.ibm.com> <200503190757.27727.jdmason@us.ibm.com> <20050319152354.GA4946@electric-eye.fr.zoreil.com> Organization: jamalopolis Message-Id: <1111327546.1094.47.camel@jzny.localdomain> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.2.2 Date: 20 Mar 2005 09:05:46 -0500 X-MIMETrack: Itemize by SMTP Server on Lotus/Znyx(Release 5.0.11 |July 24, 2002) at 03/20/2005 06:06:57 AM, Serialize by Router on Lotus/Znyx(Release 5.0.11 |July 24, 2002) at 03/20/2005 06:07:02 AM, Serialize complete at 03/20/2005 06:07:02 AM Content-Transfer-Encoding: 7bit Content-Type: text/plain X-Virus-Scanned: ClamAV 0.83/774/Fri Mar 18 17:04:06 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 377 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: hadi@cyberus.ca Precedence: bulk X-list: netdev Content-Length: 1266 Lines: 34 I have those 4 port cards(quiet a few i may add and used in all my experiments on NAPI with 10/100 etc for the last few eons) and they work just fine with standard linux driver on my 32 bit hardware - not sure about 64 bit. There is one subtle difference. They use SYM PHY. Donald Beckers drivers had this right - the current tulip driver still has it wrong. I attempted to incorporate Donalds fixes a while back: http://www.cyberus.ca/~hadi/patches/tulip-sym-fixed-20030103.tgz In my experience i have found even with current tulip driver no issues unless you start doing things like 10Mbps half-duplex. I.e you dont need the SYM PHY support. cheers, jamal On Sat, 2005-03-19 at 10:23, Francois Romieu wrote: > Jon Mason : > [...] > > The ZNXY website provides the driver source for the 4port adapter (and it is > > GPL'ed), but it seems to me that this is really an issue of getting the > > adapter to work with the "real" kernel driver, tulip. > > There are no sources for the rlk.O file and the driver suffers a bit from > the usual out-of-tree hal braindamage. Both can probably be worked around > but I would not make my business depend on the availability of a sane > driver within a reasonable timescale. > > -- > Ueimor > > From Wilfried.Weissmann@gmx.at Sun Mar 20 06:07:02 2005 Received: with ECARTIS (v1.0.0; list netdev); Sun, 20 Mar 2005 06:07:08 -0800 (PST) Received: from mail.gmx.net (pop.gmx.net [213.165.64.20]) by oss.sgi.com (8.13.0/8.13.0) with SMTP id j2KE71jc019103 for ; Sun, 20 Mar 2005 06:07:02 -0800 Received: (qmail invoked by alias); 20 Mar 2005 14:06:55 -0000 Received: from chello213047196069.tirol.surfer.at (EHLO [213.47.196.69]) [213.47.196.69] by mail.gmx.net (mp004) with SMTP; 20 Mar 2005 15:06:55 +0100 X-Authenticated: #7370606 Message-ID: <423D837E.4040203@gmx.at> Date: Sun, 20 Mar 2005 15:06:54 +0100 From: Wilfried Weissmann User-Agent: Debian Thunderbird 1.0 (X11/20050116) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Krzysztof Oledzki CC: ipsec-tools-devel@lists.sourceforge.net, netdev@oss.sgi.com Subject: Re: [Ipsec-tools-devel] more phase 2 reinitiation problems References: <42334B29.2080504@gmx.at> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 X-Virus-Scanned: ClamAV 0.83/774/Fri Mar 18 17:04:06 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 378 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: Wilfried.Weissmann@gmx.at Precedence: bulk X-list: netdev Content-Length: 536 Lines: 15 Krzysztof Oledzki wrote: > Please giva a try try the 2.6.12-rc1 kernel. I have just upgraded my > system to this kernel and it seems that IPSec is able to survive first > rekeying. Unfortunately only a first one - after a while (just before > removing old expired keys) one of newly generated keys get removed and > new traffic racoon generates two news keys. OK, it is _much_ better but > still... not perfect. Hi, I have not got time to try 2.6.12-rc1 yet but kernel 2.6.11.5 with ipsec-tools 0.3.3 works fine. Bye, Wilfried From kaber@trash.net Sun Mar 20 07:47:46 2005 Received: with ECARTIS (v1.0.0; list netdev); Sun, 20 Mar 2005 07:47:53 -0800 (PST) Received: from kaber.coreworks.de ([62.206.217.67]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j2KFljQv027650 for ; Sun, 20 Mar 2005 07:47:46 -0800 Received: from localhost ([127.0.0.1]) by kaber.coreworks.de with esmtp (Exim 4.50) id 1DD2dO-0007AD-KW; Sun, 20 Mar 2005 16:46:34 +0100 Message-ID: <423D9ADA.6050407@trash.net> Date: Sun, 20 Mar 2005 16:46:34 +0100 From: Patrick McHardy User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.7.5) Gecko/20050106 Debian/1.7.5-1 X-Accept-Language: en MIME-Version: 1.0 To: "David S. Miller" CC: Herbert Xu , kuznet@ms2.inr.ac.ru, yoshfuji@linux-ipv6.org, netdev@oss.sgi.com Subject: Re: [22/*] [NETFILTER] Use correct IPsec MTU in TCPMSS References: <20050214221607.GC18465@gondor.apana.org.au> <20050306213214.7d8a143d.davem@davemloft.net> <20050307103536.GB7137@gondor.apana.org.au> <20050308102741.GA23468@gondor.apana.org.au> <20050314102614.GA9610@gondor.apana.org.au> <20050314105313.GA21001@gondor.apana.org.au> <20050314111002.GA29156@gondor.apana.org.au> <20050315091904.GA6256@gondor.apana.org.au> <20050315095837.GA7130@gondor.apana.org.au> <20050318090310.GA28443@gondor.apana.org.au> <20050318091129.GA28658@gondor.apana.org.au> <20050318104013.57d65e99.davem@davemloft.net> In-Reply-To: <20050318104013.57d65e99.davem@davemloft.net> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV 0.83/774/Fri Mar 18 17:04:06 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 379 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: kaber@trash.net Precedence: bulk X-list: netdev Content-Length: 1887 Lines: 42 David S. Miller wrote: > On Fri, 18 Mar 2005 20:11:29 +1100 > Herbert Xu wrote: > >>BTW Patrick, how is the IPsec netfilter stuff going? > > That boy is seriously backlogged, so I'm not sure how much time > he's gotten to work on that yet. Indeed, but in case of the netfilter patches that's not the problem. They are basically working fine, but I have doubts about submitting them. First, and most importantly, the input patch is incredible ugly. To recap, we want to pass the encapsulated packets to the netfilter hooks, then again the decapsulated packets after all decapsulation has been done. The current input patch makes packets that have been handled by IPsec skip the netfilter hooks until we know no further IPsec processing will be done (route is non-local or protocol handler is not marked as xfrm_prot). The packet is then marked as completely decapsulated and passed through the stack again and the plain packets go through netfilter again. There are a couple of problems with this approach: - decapsulated tunnel-mode packets go through the stack twice - netfilter only sees them once, everything else multiple times (statistics, packet sockets, ...) - racy, xfrm protocol could be registered after we determined decapsulation is done. - inefficient The second reason is that I'm not sure at all wether this is the way to go. With KLIPS-like IPsec-devices you can sniff the plain packets before they are handled by IPsec and you can perform traffic shaping on them. These two points are completely unhandled, and people seem to want them. So what's holding back these patches is getting some consensus on what exactly we want to do and finding a better method for determining when decapsulation is done. One possibility would be stealing packets in xfrm_policy_check(), but I haven't thought much about this yet. Regards Patrick From kaber@trash.net Sun Mar 20 07:51:59 2005 Received: with ECARTIS (v1.0.0; list netdev); Sun, 20 Mar 2005 07:52:03 -0800 (PST) Received: from kaber.coreworks.de ([62.206.217.67]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j2KFpx7h028493 for ; Sun, 20 Mar 2005 07:51:59 -0800 Received: from localhost ([127.0.0.1]) by kaber.coreworks.de with esmtp (Exim 4.50) id 1DD2i3-0007An-6t; Sun, 20 Mar 2005 16:51:23 +0100 Message-ID: <423D9BFB.2090309@trash.net> Date: Sun, 20 Mar 2005 16:51:23 +0100 From: Patrick McHardy User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.7.5) Gecko/20050106 Debian/1.7.5-1 X-Accept-Language: en MIME-Version: 1.0 To: "David S. Miller" CC: Herbert Xu , netdev@oss.sgi.com Subject: Re: IPsec xfrm resolution References: <20050209085251.GA9030@gondor.apana.org.au> <420B9DF1.3020704@trash.net> <20050210202810.GA1609@gondor.apana.org.au> <42144C3F.2060501@trash.net> <20050217091137.GA9476@gondor.apana.org.au> <42152841.5000707@trash.net> <20050218100854.GA19427@gondor.apana.org.au> <4216D6B4.5070901@trash.net> <20050219092314.GA8153@gondor.apana.org.au> <20050317203231.1b649f60.davem@davemloft.net> In-Reply-To: <20050317203231.1b649f60.davem@davemloft.net> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV 0.83/774/Fri Mar 18 17:04:06 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 380 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: kaber@trash.net Precedence: bulk X-list: netdev Content-Length: 297 Lines: 12 David S. Miller wrote: > Anyways, in truth I'm being very picky :-) Is there any prototype > or beginnings of these ideas anywhere? Not yet, I've put it on hold after clashing with Herbert's MTU work. I'll have a few free days this week where I will continue to work on this. Regards Patrick From mkomu@twilight.cs.hut.fi Sun Mar 20 08:08:39 2005 Received: with ECARTIS (v1.0.0; list netdev); Sun, 20 Mar 2005 08:08:45 -0800 (PST) Received: from twilight.cs.hut.fi (twilight.cs.hut.fi [130.233.40.5]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j2KG8cII030246 for ; Sun, 20 Mar 2005 08:08:38 -0800 Received: by twilight.cs.hut.fi (Postfix, from userid 60001) id 52F542D96; Sun, 20 Mar 2005 18:08:32 +0200 (EET) Received: from kekkonen.cs.hut.fi (kekkonen.cs.hut.fi [130.233.41.50]) by twilight.cs.hut.fi (Postfix) with ESMTP id 99BF52D95; Sun, 20 Mar 2005 18:08:30 +0200 (EET) Received: (from mkomu@localhost) by kekkonen.cs.hut.fi (8.11.7p1+Sun/8.10.2) id j2KG8Ua02339; Sun, 20 Mar 2005 18:08:30 +0200 (EET) Date: Sun, 20 Mar 2005 18:08:30 +0200 (EET) From: Miika Komu X-X-Sender: mkomu@kekkonen.cs.hut.fi To: Andrei Gurtov Cc: netdev@oss.sgi.com, infrahip@hiit.fi Subject: Re: [Infrahip] [PATCH] Host Identity Protocol In-Reply-To: <42369919.9010203@cs.helsinki.fi> Message-ID: References: <42369919.9010203@cs.helsinki.fi> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Virus-Scanned: ClamAV 0.83/774/Fri Mar 18 17:04:06 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 381 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: miika@iki.fi Precedence: bulk X-list: netdev Content-Length: 551 Lines: 18 On Tue, 15 Mar 2005, Andrei Gurtov wrote: > Please have a look at Host Identity Protocol, a better solution for > secure mobility and multihoming than Mobile IP. > > http://hipl.hiit.fi/hipl/release/kernel-patches/linux-2.6.10-hipl-0.1.patch > > Project info: http://infrahip.hiit.fi/ I made the release directory structure more usable. The latest patch can be found from: http://infrahip.hiit.fi/hipl/release/0.1.2/linux-2.6.10-hipl-0.1.2.patch All feedback is welcome. -- Miika Komu miika@iki.fi http://www.iki.fi/miika/ From kaber@trash.net Sun Mar 20 08:10:27 2005 Received: with ECARTIS (v1.0.0; list netdev); Sun, 20 Mar 2005 08:10:34 -0800 (PST) Received: from kaber.coreworks.de ([62.206.217.67]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j2KGARMl030893 for ; Sun, 20 Mar 2005 08:10:27 -0800 Received: from localhost ([127.0.0.1]) by kaber.coreworks.de with esmtp (Exim 4.50) id 1DD30P-0007Cy-On; Sun, 20 Mar 2005 17:10:21 +0100 Message-ID: <423DA06D.6070603@trash.net> Date: Sun, 20 Mar 2005 17:10:21 +0100 From: Patrick McHardy User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.7.5) Gecko/20050106 Debian/1.7.5-1 X-Accept-Language: en MIME-Version: 1.0 To: Herbert Xu CC: Ludo Stellingwerff , netdev@oss.sgi.com Subject: Re: [RFC] Using Fwmark as SPD filter. References: In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV 0.83/774/Fri Mar 18 17:04:06 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 382 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: kaber@trash.net Precedence: bulk X-list: netdev Content-Length: 621 Lines: 19 Herbert Xu wrote: > Ludo Stellingwerff wrote: > >>In general, is this work a waste of time or am I hitting something here? > > > Yes you're hitting the right spot :) > > This is a planned feature. We just need to fix the bundle structure > so that they live in the flow cache instead of the policy to make this > workable. Agreed. I had a look at putting the bundles in the flow cache, it seems to me this needs the xfrm resolution first since resolving the bundle would be done in flow cache resolver and we can't sleep in there. Once that's done it looks like a simple task. Regards Patrick From ludo@protactive.nl Sun Mar 20 08:33:01 2005 Received: with ECARTIS (v1.0.0; list netdev); Sun, 20 Mar 2005 08:33:07 -0800 (PST) Received: from protactive.stwerff.xs4all.nl (stwerff.xs4all.nl [213.84.145.135]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j2KGX0DJ004059 for ; Sun, 20 Mar 2005 08:33:00 -0800 Received: from localhost (protactive.stwerff.xs4all.nl [127.0.0.1]) by protactive.stwerff.xs4all.nl (Postfix) with ESMTP id C9A617D for ; Sun, 20 Mar 2005 17:32:53 +0100 (CET) Received: from protactive.stwerff.xs4all.nl ([127.0.0.1]) by localhost (protactive.stwerff.xs4all.nl [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 32106-09 for ; Sun, 20 Mar 2005 17:32:30 +0100 (CET) Received: from [192.168.99.90] (host-192.168.99.90 [192.168.99.90]) by protactive.stwerff.xs4all.nl (Postfix) with ESMTP id E77267B for ; Sun, 20 Mar 2005 17:32:15 +0100 (CET) Message-ID: <423DA58D.4050406@protactive.nl> Date: Sun, 20 Mar 2005 17:32:13 +0100 From: Ludo Stellingwerff User-Agent: Debian Thunderbird 1.0 (X11/20050116) X-Accept-Language: en-us, en MIME-Version: 1.0 To: netdev@oss.sgi.com Subject: Re: [22/*] [NETFILTER] Use correct IPsec MTU in TCPMSS References: <20050214221607.GC18465@gondor.apana.org.au> <20050306213214.7d8a143d.davem@davemloft.net> <20050307103536.GB7137@gondor.apana.org.au> <20050308102741.GA23468@gondor.apana.org.au> <20050314102614.GA9610@gondor.apana.org.au> <20050314105313.GA21001@gondor.apana.org.au> <20050314111002.GA29156@gondor.apana.org.au> <20050315091904.GA6256@gondor.apana.org.au> <20050315095837.GA7130@gondor.apana.org.au> <20050318090310.GA28443@gondor.apana.org.au> <20050318091129.GA28658@gondor.apana.org.au> <20050318104013.57d65e99.davem@davemloft.net> <423D9ADA.6050407@trash.net> In-Reply-To: <423D9ADA.6050407@trash.net> X-Enigmail-Version: 0.90.0.0 X-Enigmail-Supports: pgp-inline, pgp-mime Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV 0.83/774/Fri Mar 18 17:04:06 2005 on oss.sgi.com X-Virus-Scanned: by amavisd-new-20030616-p10 at stwerff.xs4all.nl X-Virus-Status: Clean X-archive-position: 383 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: ludo@protactive.nl Precedence: bulk X-list: netdev Content-Length: 2862 Lines: 81 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 As an daily user of Patricks patches, I like to agree with Patricks analysis about the loosing of flexibility with the choice not to use virtual devices. In a real-life situation I had to revert to using plain, unsave GRE-tunnels because of the complexity of using 2.6-ipsec for the same purpose. I'm routing one of multiple defaultroutes over this tunnel:) It felt like a relieve having a device to work with. Just my 2 cents, Greetings, Ludo. Patrick McHardy wrote: | David S. Miller wrote: | |> On Fri, 18 Mar 2005 20:11:29 +1100 Herbert Xu |> wrote: |> |>> BTW Patrick, how is the IPsec netfilter stuff going? |> |> |> That boy is seriously backlogged, so I'm not sure how much time |> he's gotten to work on that yet. | | | Indeed, but in case of the netfilter patches that's not the | problem. They are basically working fine, but I have doubts about | submitting them. First, and most importantly, the input patch is | incredible ugly. To recap, we want to pass the encapsulated packets | to the netfilter hooks, then again the decapsulated packets after | all decapsulation has been done. The current input patch makes | packets that have been handled by IPsec skip the netfilter hooks | until we know no further IPsec processing will be done (route is | non-local or protocol handler is not marked as xfrm_prot). The | packet is then marked as completely decapsulated and passed through | the stack again and the plain packets go through netfilter again. | There are a couple of problems with this approach: | | - decapsulated tunnel-mode packets go through the stack twice - | netfilter only sees them once, everything else multiple times | (statistics, packet sockets, ...) - racy, xfrm protocol could be | registered after we determined decapsulation is done. - inefficient | | | The second reason is that I'm not sure at all wether this is the | way to go. With KLIPS-like IPsec-devices you can sniff the plain | packets before they are handled by IPsec and you can perform | traffic shaping on them. These two points are completely unhandled, | and people seem to want them. | | So what's holding back these patches is getting some consensus on | what exactly we want to do and finding a better method for | determining when decapsulation is done. One possibility would be | stealing packets in xfrm_policy_check(), but I haven't thought much | about this yet. | | Regards Patrick | | - -- Ludo Stellingwerff V&S B.V. The Netherlands ProTactive firewall solution. Tel: +31 172 416116 Fax: +31 172 416124 site: www.protactive.nl demo: http://www.protactive.nl:81/netview.html -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.0 (GNU/Linux) iD8DBQFCPaWMOF3sCpZ+AJgRAiofAJ9VlmQ3GF+D3q5FLfsyj3vcRJUbogCgzy86 pS4CRtw1sGe3K3vUVgIqi8E= =5IAn -----END PGP SIGNATURE----- From buytenh@wantstofly.org Sun Mar 20 09:17:09 2005 Received: with ECARTIS (v1.0.0; list netdev); Sun, 20 Mar 2005 09:17:13 -0800 (PST) Received: from xi.wantstofly.org (alephnull.demon.nl [212.238.201.82]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j2KHH8aD007481 for ; Sun, 20 Mar 2005 09:17:08 -0800 Received: by xi.wantstofly.org (Postfix, from userid 500) id 1E6B12B0EC; Sun, 20 Mar 2005 18:17:07 +0100 (MET) Date: Sun, 20 Mar 2005 18:17:07 +0100 From: Lennert Buytenhek To: Ludo Stellingwerff , Herbert Xu Cc: netdev@oss.sgi.com Subject: Re: [22/*] [NETFILTER] Use correct IPsec MTU in TCPMSS Message-ID: <20050320171707.GE4201@xi.wantstofly.org> References: <20050314102614.GA9610@gondor.apana.org.au> <20050314105313.GA21001@gondor.apana.org.au> <20050314111002.GA29156@gondor.apana.org.au> <20050315091904.GA6256@gondor.apana.org.au> <20050315095837.GA7130@gondor.apana.org.au> <20050318090310.GA28443@gondor.apana.org.au> <20050318091129.GA28658@gondor.apana.org.au> <20050318104013.57d65e99.davem@davemloft.net> <423D9ADA.6050407@trash.net> <423DA58D.4050406@protactive.nl> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <423DA58D.4050406@protactive.nl> User-Agent: Mutt/1.4.1i X-Virus-Scanned: ClamAV 0.83/774/Fri Mar 18 17:04:06 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 384 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: buytenh@wantstofly.org Precedence: bulk X-list: netdev Content-Length: 2636 Lines: 55 On Sun, Mar 20, 2005 at 05:32:13PM +0100, Ludo Stellingwerff wrote: > As an daily user of Patricks patches, I like to agree with Patricks > analysis about the loosing of flexibility with the choice not to use > virtual devices. In a real-life situation I had to revert to using > plain, unsave GRE-tunnels because of the complexity of using 2.6-ipsec > for the same purpose. I'm routing one of multiple defaultroutes over > this tunnel:) It felt like a relieve having a device to work with. I'll add my 2 cents to this. In my situation, there are three different sites in the same city (Amsterdam), interconnected using a shared L2 vlan, and six routers (A1, A2, B1, B2, C1, C2) on that vlan, two per site for redundancy reasons. Each router runs ospf. The vlan is provided to us by a telco that we do not necessarily trust. So ideally, we'd like all traffic that goes over the vlan (modulo ARPs and STP and stuff) to be encrypted. ("-o eth3 -j ENCRYPT") The problem I kept running into with tunnel mode is that tunnel mode SPD rules appear to dictate routing policy in a way that's not compatible with dynamic routing. I.e., a line like: spdadd 10.10.1.0/24 10.0.1.0/24 any -P out ipsec esp/tunnel/1.2.3.4-5.6.7.8/require; effectively says "All traffic from 10.10.1.0/24 to 10.0.1.0/24 will be sent over a tunnel with local endpoint 1.2.3.4 and remote endpoint 5.6.7.8", but: - I have no idea beforehand what address ranges are going to be routed over this vlan. (Customers might send traffic with source addresses in address ranges that they don't announce to us (asymmetric routing), and I don't want those packets to remain unencrypted just because they don't match the SPD rule.) A 0.0.0.0/0 0.0.0.0/0 rule would not be appropriate either since that'd suck _all_ traffic into this tunnel. - I have no idea beforehand what the remote nexthop is going to be. A1 might ordinarily send its traffic for site B to B1, but if B1 fails it'll want to start using B2 instead, which would be prevented by the SPD rule hardcoding the remote tunnel endpoint to B1. The workaround we tried at first was to create GRE tunnels between each pair of routers on the vlan, and to run ospf over the tunnels instead of directly over the vlan interface. That gave MTU problems, though, which made us just forget about ipsec altogether and use vtund instead, hardly better than nothing. (Now that Herbert has submitted a number of fixes for ipsec MTU issues with tunnels, I guess I should go and give the GRE-over-ipsec setup a go again.) Then again, maybe I totally misunderstood the way this is supposed to work. --L From yoshfuji@linux-ipv6.org Sun Mar 20 09:40:53 2005 Received: with ECARTIS (v1.0.0; list netdev); Sun, 20 Mar 2005 09:40:59 -0800 (PST) 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 j2KHeqpj008778 for ; Sun, 20 Mar 2005 09:40:53 -0800 Received: from localhost (localhost [127.0.0.1]) by yue.st-paulia.net (Postfix) with ESMTP id 33B6333CC2; Mon, 21 Mar 2005 02:42:43 +0900 (JST) Date: Mon, 21 Mar 2005 02:42:41 +0900 (JST) Message-Id: <20050321.024241.67451836.yoshfuji@linux-ipv6.org> To: miika@iki.fi Cc: gurtov@cs.helsinki.fi, netdev@oss.sgi.com, infrahip@hiit.fi, yoshfuji@linux-ipv6.org Subject: Re: [Infrahip] [PATCH] Host Identity Protocol From: YOSHIFUJI Hideaki / =?iso-2022-jp?B?GyRCNUhGIzFRTEAbKEI=?= In-Reply-To: References: <42369919.9010203@cs.helsinki.fi> 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-Virus-Scanned: ClamAV 0.83/774/Fri Mar 18 17:04:06 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 385 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: yoshfuji@linux-ipv6.org Precedence: bulk X-list: netdev Content-Length: 723 Lines: 18 In article (at Sun, 20 Mar 2005 18:08:30 +0200 (EET)), Miika Komu says: > On Tue, 15 Mar 2005, Andrei Gurtov wrote: > > > Please have a look at Host Identity Protocol, a better solution for > > secure mobility and multihoming than Mobile IP. : > I made the release directory structure more usable. The latest patch can > be found from: > > http://infrahip.hiit.fi/hipl/release/0.1.2/linux-2.6.10-hipl-0.1.2.patch I think you're doing great work. However, all signaling should be handled in userspace as we (will) do for MIP6. -- Hideaki YOSHIFUJI @ USAGI Project GPG FP: 9022 65EB 1ECF 3AD1 0BDF 80D8 4807 F894 E062 0EEA From kaber@trash.net Sun Mar 20 09:49:55 2005 Received: with ECARTIS (v1.0.0; list netdev); Sun, 20 Mar 2005 09:50:00 -0800 (PST) Received: from kaber.coreworks.de ([62.206.217.67]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j2KHnm0Z009595 for ; Sun, 20 Mar 2005 09:49:55 -0800 Received: from localhost ([127.0.0.1]) by kaber.coreworks.de with esmtp (Exim 4.50) id 1DD4YZ-00013J-F6; Sun, 20 Mar 2005 18:49:43 +0100 Message-ID: <423DB7B7.1070604@trash.net> Date: Sun, 20 Mar 2005 18:49:43 +0100 From: Patrick McHardy User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.7.5) Gecko/20050106 Debian/1.7.5-1 X-Accept-Language: en MIME-Version: 1.0 To: Lennert Buytenhek CC: Ludo Stellingwerff , Herbert Xu , netdev@oss.sgi.com Subject: Re: [22/*] [NETFILTER] Use correct IPsec MTU in TCPMSS References: <20050314102614.GA9610@gondor.apana.org.au> <20050314105313.GA21001@gondor.apana.org.au> <20050314111002.GA29156@gondor.apana.org.au> <20050315091904.GA6256@gondor.apana.org.au> <20050315095837.GA7130@gondor.apana.org.au> <20050318090310.GA28443@gondor.apana.org.au> <20050318091129.GA28658@gondor.apana.org.au> <20050318104013.57d65e99.davem@davemloft.net> <423D9ADA.6050407@trash.net> <423DA58D.4050406@protactive.nl> <20050320171707.GE4201@xi.wantstofly.org> In-Reply-To: <20050320171707.GE4201@xi.wantstofly.org> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV 0.83/774/Fri Mar 18 17:04:06 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 386 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: kaber@trash.net Precedence: bulk X-list: netdev Content-Length: 2356 Lines: 49 Lennert Buytenhek wrote: > In my situation, there are three different sites in the same city > (Amsterdam), interconnected using a shared L2 vlan, and six routers > (A1, A2, B1, B2, C1, C2) on that vlan, two per site for redundancy > reasons. Each router runs ospf. > > The vlan is provided to us by a telco that we do not necessarily trust. > So ideally, we'd like all traffic that goes over the vlan (modulo ARPs > and STP and stuff) to be encrypted. ("-o eth3 -j ENCRYPT") > > The problem I kept running into with tunnel mode is that tunnel > mode SPD rules appear to dictate routing policy in a way that's not > compatible with dynamic routing. > > I.e., a line like: > > spdadd 10.10.1.0/24 10.0.1.0/24 any -P out ipsec esp/tunnel/1.2.3.4-5.6.7.8/require; > > effectively says "All traffic from 10.10.1.0/24 to 10.0.1.0/24 will > be sent over a tunnel with local endpoint 1.2.3.4 and remote endpoint > 5.6.7.8", but: > - I have no idea beforehand what address ranges are going to be routed > over this vlan. (Customers might send traffic with source addresses > in address ranges that they don't announce to us (asymmetric routing), > and I don't want those packets to remain unencrypted just because they > don't match the SPD rule.) A 0.0.0.0/0 0.0.0.0/0 rule would not be > appropriate either since that'd suck _all_ traffic into this tunnel You can specify an ifindex for oif in the selector, but you need to use the xfrm_user interface. > - I have no idea beforehand what the remote nexthop is going to be. A1 > might ordinarily send its traffic for site B to B1, but if B1 fails > it'll want to start using B2 instead, which would be prevented by the > SPD rule hardcoding the remote tunnel endpoint to B1. > > The workaround we tried at first was to create GRE tunnels between each > pair of routers on the vlan, and to run ospf over the tunnels instead of > directly over the vlan interface. That gave MTU problems, though, which > made us just forget about ipsec altogether and use vtund instead, hardly > better than nothing. (Now that Herbert has submitted a number of fixes > for ipsec MTU issues with tunnels, I guess I should go and give the > GRE-over-ipsec setup a go again.) Hmm .. sounds like using the routing realm in the selector would solve this while avoiding the GRE overhead. Regards Patrick From ludo@protactive.nl Sun Mar 20 10:12:03 2005 Received: with ECARTIS (v1.0.0; list netdev); Sun, 20 Mar 2005 10:12:09 -0800 (PST) Received: from protactive.stwerff.xs4all.nl (stwerff.xs4all.nl [213.84.145.135]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j2KIC2YW011037 for ; Sun, 20 Mar 2005 10:12:02 -0800 Received: from localhost (protactive.stwerff.xs4all.nl [127.0.0.1]) by protactive.stwerff.xs4all.nl (Postfix) with ESMTP id 5F4E37B for ; Sun, 20 Mar 2005 19:11:56 +0100 (CET) Received: from protactive.stwerff.xs4all.nl ([127.0.0.1]) by localhost (protactive.stwerff.xs4all.nl [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 21525-06 for ; Sun, 20 Mar 2005 19:11:30 +0100 (CET) Received: from [192.168.99.90] (host-192.168.99.90 [192.168.99.90]) by protactive.stwerff.xs4all.nl (Postfix) with ESMTP id D28267D for ; Sun, 20 Mar 2005 19:11:26 +0100 (CET) Message-ID: <423DBCCE.8090006@protactive.nl> Date: Sun, 20 Mar 2005 19:11:26 +0100 From: Ludo Stellingwerff User-Agent: Debian Thunderbird 1.0 (X11/20050116) X-Accept-Language: en-us, en MIME-Version: 1.0 To: netdev@oss.sgi.com Subject: Re: [22/*] [NETFILTER] Use correct IPsec MTU in TCPMSS References: <20050314102614.GA9610@gondor.apana.org.au> <20050314105313.GA21001@gondor.apana.org.au> <20050314111002.GA29156@gondor.apana.org.au> <20050315091904.GA6256@gondor.apana.org.au> <20050315095837.GA7130@gondor.apana.org.au> <20050318090310.GA28443@gondor.apana.org.au> <20050318091129.GA28658@gondor.apana.org.au> <20050318104013.57d65e99.davem@davemloft.net> <423D9ADA.6050407@trash.net> <423DA58D.4050406@protactive.nl> <20050320171707.GE4201@xi.wantstofly.org> <423DB7B7.1070604@trash.net> In-Reply-To: <423DB7B7.1070604@trash.net> X-Enigmail-Version: 0.90.0.0 X-Enigmail-Supports: pgp-inline, pgp-mime Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV 0.83/774/Fri Mar 18 17:04:06 2005 on oss.sgi.com X-Virus-Scanned: by amavisd-new-20030616-p10 at stwerff.xs4all.nl X-Virus-Status: Clean X-archive-position: 387 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: ludo@protactive.nl Precedence: bulk X-list: netdev Content-Length: 1382 Lines: 50 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Patrick McHardy wrote: | Lennert Buytenhek wrote: |> - I have no idea beforehand what the remote nexthop is going to |> be. A1 might ordinarily send its traffic for site B to B1, but |> if B1 fails it'll want to start using B2 instead, which would be |> prevented by the SPD rule hardcoding the remote tunnel endpoint |> to B1. |> | | Hmm .. sounds like using the routing realm in the selector would | solve this while avoiding the GRE overhead. | | Regards Patrick | I'm hoping that using the fwmark as a selector can provide a workable solution for both mine and Lennert's problem, any many more related situations. Netfilter has a (almost) complete range of selectors. e.g. Lennerts problem could be solved using a combination of the "realm" match of iptables, in combination with a fwmark for SPD matching. Greetings, Ludo. PS. On a side note: Wouldn't it be possible to have a netfilter target stating that an transformation should be done? - -- Ludo Stellingwerff V&S B.V. The Netherlands ProTactive firewall solution. Tel: +31 172 416116 Fax: +31 172 416124 site: www.protactive.nl demo: http://www.protactive.nl:81/netview.html -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.0 (GNU/Linux) iD8DBQFCPbzNOF3sCpZ+AJgRApxBAJ9akLfP1onp+WKRgmJ1YDImkrXLHwCgkPS4 GvwO1PoUwkJnVTOjeaf/ZEw= =OebA -----END PGP SIGNATURE----- From kaber@trash.net Sun Mar 20 10:22:41 2005 Received: with ECARTIS (v1.0.0; list netdev); Sun, 20 Mar 2005 10:22:45 -0800 (PST) Received: from kaber.coreworks.de ([62.206.217.67]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j2KIMft3011899 for ; Sun, 20 Mar 2005 10:22:41 -0800 Received: from localhost ([127.0.0.1]) by kaber.coreworks.de with esmtp (Exim 4.50) id 1DD54M-00016d-Mg; Sun, 20 Mar 2005 19:22:34 +0100 Message-ID: <423DBF6A.1080907@trash.net> Date: Sun, 20 Mar 2005 19:22:34 +0100 From: Patrick McHardy User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.7.5) Gecko/20050106 Debian/1.7.5-1 X-Accept-Language: en MIME-Version: 1.0 To: Ludo Stellingwerff CC: netdev@oss.sgi.com Subject: Re: [22/*] [NETFILTER] Use correct IPsec MTU in TCPMSS References: <20050314102614.GA9610@gondor.apana.org.au> <20050314105313.GA21001@gondor.apana.org.au> <20050314111002.GA29156@gondor.apana.org.au> <20050315091904.GA6256@gondor.apana.org.au> <20050315095837.GA7130@gondor.apana.org.au> <20050318090310.GA28443@gondor.apana.org.au> <20050318091129.GA28658@gondor.apana.org.au> <20050318104013.57d65e99.davem@davemloft.net> <423D9ADA.6050407@trash.net> <423DA58D.4050406@protactive.nl> <20050320171707.GE4201@xi.wantstofly.org> <423DB7B7.1070604@trash.net> <423DBCCE.8090006@protactive.nl> In-Reply-To: <423DBCCE.8090006@protactive.nl> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV 0.83/774/Fri Mar 18 17:04:06 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 388 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: kaber@trash.net Precedence: bulk X-list: netdev Content-Length: 592 Lines: 13 Ludo Stellingwerff wrote: > I'm hoping that using the fwmark as a selector can provide a workable > solution for both mine and Lennert's problem, any many more related > situations. Netfilter has a (almost) complete range of selectors. > e.g. Lennerts problem could be solved using a combination of the > "realm" match of iptables, in combination with a fwmark for SPD matching. Routing of local packets is done before the first netfilter hook is called, but I forgot about ip_route_me_harder(). So you're right, the realm can be translated to nfmark values using iptables. Regards Patrick From hadi@cyberus.ca Sun Mar 20 10:32:06 2005 Received: with ECARTIS (v1.0.0; list netdev); Sun, 20 Mar 2005 10:32:11 -0800 (PST) Received: from mx02.cybersurf.com (mx02.cybersurf.com [209.197.145.105]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j2KIW5HH012743 for ; Sun, 20 Mar 2005 10:32:05 -0800 Received: from mail.cyberus.ca ([209.197.145.21]) by mx02.cybersurf.com with esmtp (Exim 4.30) id 1DD5DW-0007me-SV for netdev@oss.sgi.com; Sun, 20 Mar 2005 13:32:02 -0500 Received: from [24.103.99.32] (helo=[10.0.0.9]) by mail.cyberus.ca with esmtp (Exim 4.20) id 1DD5DS-0005MN-RX; Sun, 20 Mar 2005 13:31:59 -0500 Subject: Re: dummy as IMQ replacement From: jamal Reply-To: hadi@cyberus.ca To: Andy Furniss Cc: Thomas Graf , Remus , netdev@oss.sgi.com, Nguyen Dinh Nam , Andre Tomt , syrius.ml@no-log.org, Damion de Soto In-Reply-To: <1111326913.1093.37.camel@jzny.localdomain> References: <1107123123.8021.80.camel@jzny.localdomain> <0fcf01c5077f$579e4b80$6e69690a@RIMAS> <1107174142.8021.121.camel@jzny.localdomain> <00c301c524b4$938cd240$6e69690a@RIMAS> <1110379135.1091.143.camel@jzny.localdomain> <1110416767.1111.76.camel@jzny.localdomain> <025501c52552$2dbf87c0$6e69690a@RIMAS> <1110453757.1108.87.camel@jzny.localdomain> <423B7BCB.10400@dsl.pipex.com> <1111196668.1146.114.camel@jzny.localdomain> <423BFD9F.50401@dsl.pipex.com> <1111324805.1094.11.camel@jzny.localdomain> <1111326913.1093.37.camel@jzny.localdomain> Content-Type: multipart/mixed; boundary="=-qx2mkIvoXQ+XYLg1iBzK" Organization: jamalopolous Message-Id: <1111343514.1092.55.camel@jzny.localdomain> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.2.2 Date: 20 Mar 2005 13:31:54 -0500 X-Virus-Scanned: ClamAV 0.83/774/Fri Mar 18 17:04:06 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 389 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: hadi@cyberus.ca Precedence: bulk X-list: netdev Content-Length: 3496 Lines: 129 --=-qx2mkIvoXQ+XYLg1iBzK Content-Type: text/plain Content-Transfer-Encoding: 7bit [Its amazing how much time i seem to have when i have no test machine]. Andy, dont bother trying to figure what kernels break. I think that i may have found the bug though not 100% sure -its subtle but tricky. I think my suspicion was correct - the stats changes that happened a while back are causing havoc. Patch "p_kstats" should resolve a kernel side bug introduced at the time. Patch "p_tcstats" for now should resolve the tc side. I have not tested but was able to compile courtesy of someones machine. cheers, jamal On Sun, 2005-03-20 at 08:55, jamal wrote: > On Sun, 2005-03-20 at 08:20, jamal wrote: > > > On Sat, 2005-03-19 at 05:23, Andy Furniss wrote: > > > > > > [root@amd /home/andy/Qos]# tc -s filter ls dev eth0 parent ffff: > > > > > > filter protocol ip pref 10 u32 > > > filter protocol ip pref 10 u32 fh 800: ht divisor 1 > > > filter protocol ip pref 10 u32 fh 800::800 order 2048 key ht 800 bkt 0 > > > flowid 1:1 (rule hit 12 success 12) > > > match 00000000/00000000 at 0 (success 12 ) > > > action order 1: tablename: mangle hook: NF_IP_PRE_ROUTING > > > target MARK set 0x1 > > > index 1 ref 1 bind 1 installed 251 sec expires 1 sec > > > Action statistics: > > > Sent 7630953 bytes 0 pkt > > > rate 3146Kbit 1095565348pps > > > > > > > Ok, this seems to be a bug in the stats - I think it may have been > > introduced during the new kernel stats code updates. > > Ive cced Thomas who added that code, he may be able to figure it oput > > before i get back > > > > OTOH, this may be a kernel issue. There have been some changes recently > which updated some counters from 32 bit to 64 bit ;-> Clearly this > will break the ABI and will give crap stats. > > Try also if you can kernel 2.6.10. > I think weve narrowed down iptables to be working if <= 1.2.11 > It will help me if you can narrow down the iproute2 version as well > as the kernel version where things start breaking. > > cheers, > jamal > > > --=-qx2mkIvoXQ+XYLg1iBzK Content-Disposition: attachment; filename=p_kstats Content-Type: text/plain; name=p_kstats; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit --- a/include/linux/rtnetlink.h 2005/03/20 17:53:07 1.1 +++ b/include/linux/rtnetlink.h 2005/03/20 17:53:34 @@ -699,7 +699,6 @@ TCA_RATE, TCA_FCNT, TCA_STATS2, - TCA_ACT_STATS, __TCA_MAX }; --- a/include/linux/pkt_cls.h 2005/03/22 17:54:23 1.1 +++ b/include/linux/pkt_cls.h 2005/03/22 17:55:15 @@ -80,6 +80,7 @@ TCA_ACT_KIND, TCA_ACT_OPTIONS, TCA_ACT_INDEX, + TCA_ACT_STATS, __TCA_ACT_MAX }; --=-qx2mkIvoXQ+XYLg1iBzK Content-Disposition: attachment; filename=p_tcstats Content-Type: text/plain; name=p_tcstats; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit --- a/include/linux/rtnetlink.h 2005/03/20 17:56:53 1.1 +++ b/include/linux/rtnetlink.h 2005/03/20 17:57:17 @@ -699,7 +699,6 @@ TCA_RATE, TCA_FCNT, TCA_STATS2, - TCA_ACT_STATS, __TCA_MAX }; --- a/include/linux/pkt_cls.h 2005-03-20 08:45:44.000000000 -0500 +++ b/include/linux/pkt_cls.h 2005-03-20 12:56:19.000000000 -0500 @@ -78,6 +78,7 @@ TCA_ACT_KIND, TCA_ACT_OPTIONS, TCA_ACT_INDEX, + TCA_ACT_STATS, __TCA_ACT_MAX }; @@ -136,9 +137,9 @@ struct tcf_t { - __u32 install; - __u32 lastuse; - __u32 expires; + __u64 install; + __u64 lastuse; + __u64 expires; }; struct tc_cnt --=-qx2mkIvoXQ+XYLg1iBzK-- From hadi@cyberus.ca Sun Mar 20 10:43:57 2005 Received: with ECARTIS (v1.0.0; list netdev); Sun, 20 Mar 2005 10:44:01 -0800 (PST) Received: from mx03.cybersurf.com (mx03.cybersurf.com [209.197.145.106]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j2KIht9s014062 for ; Sun, 20 Mar 2005 10:43:55 -0800 Received: from mail.cyberus.ca ([209.197.145.21]) by mx03.cybersurf.com with esmtp (Exim 4.30) id 1DD5P0-0007po-AZ for netdev@oss.sgi.com; Sun, 20 Mar 2005 13:43:54 -0500 Received: from [24.103.99.32] (helo=[10.0.0.9]) by mail.cyberus.ca with esmtp (Exim 4.20) id 1DD5Ow-0006Sg-4G; Sun, 20 Mar 2005 13:43:50 -0500 Subject: Re: [22/*] [NETFILTER] Use correct IPsec MTU in TCPMSS From: jamal Reply-To: hadi@cyberus.ca To: Patrick McHardy Cc: Ludo Stellingwerff , netdev@oss.sgi.com In-Reply-To: <423DBF6A.1080907@trash.net> References: <20050314102614.GA9610@gondor.apana.org.au> <20050314105313.GA21001@gondor.apana.org.au> <20050314111002.GA29156@gondor.apana.org.au> <20050315091904.GA6256@gondor.apana.org.au> <20050315095837.GA7130@gondor.apana.org.au> <20050318090310.GA28443@gondor.apana.org.au> <20050318091129.GA28658@gondor.apana.org.au> <20050318104013.57d65e99.davem@davemloft.net> <423D9ADA.6050407@trash.net> <423DA58D.4050406@protactive.nl> <20050320171707.GE4201@xi.wantstofly.org> <423DB7B7.1070604@trash.net> <423DBCCE.8090006@protactive.nl> <423DBF6A.1080907@trash.net> Content-Type: text/plain Organization: jamalopolous Message-Id: <1111344225.1093.68.camel@jzny.localdomain> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.2.2 Date: 20 Mar 2005 13:43:45 -0500 Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV 0.83/774/Fri Mar 18 17:04:06 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 390 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: hadi@cyberus.ca Precedence: bulk X-list: netdev Content-Length: 872 Lines: 20 On Sun, 2005-03-20 at 13:22, Patrick McHardy wrote: > Ludo Stellingwerff wrote: > > I'm hoping that using the fwmark as a selector can provide a workable > > solution for both mine and Lennert's problem, any many more related > > situations. Netfilter has a (almost) complete range of selectors. > > e.g. Lennerts problem could be solved using a combination of the > > "realm" match of iptables, in combination with a fwmark for SPD matching. > > Routing of local packets is done before the first netfilter hook > is called, but I forgot about ip_route_me_harder(). So you're right, > the realm can be translated to nfmark values using iptables. BTW, is there any reason the SPD couldnt have been implemented from day one using netfilter classification ? Why did we need another speacilized classifier? the actions are clearly implementable as targets. cheers, jamal From kostodo@gmail.com Sun Mar 20 11:02:56 2005 Received: with ECARTIS (v1.0.0; list netdev); Sun, 20 Mar 2005 11:03:07 -0800 (PST) Received: from rproxy.gmail.com (rproxy.gmail.com [64.233.170.195]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j2KJ2sHm016015 for ; Sun, 20 Mar 2005 11:02:55 -0800 Received: by rproxy.gmail.com with SMTP id i8so659105rne for ; Sun, 20 Mar 2005 11:02:54 -0800 (PST) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:reply-to:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:references; b=YWiyEbnq2tm7MaTgzH6pI081/+TeaoQnRTeUogphGKi4x3fIKjGTycMqGYOTGxV+Y3jtL094CKHmT9V0r+uiAkPebG6HGhhVWkIUErbMRefQo4a56I0LPHbKoo5WNl5+UsmBxNOR1gIj3gFkm4tfSQ/tVLG+YuuCp3hy/AifBfA= Received: by 10.38.101.66 with SMTP id y66mr4590665rnb; Sun, 20 Mar 2005 11:02:53 -0800 (PST) Received: by 10.38.208.49 with HTTP; Sun, 20 Mar 2005 11:02:53 -0800 (PST) Message-ID: Date: Sun, 20 Mar 2005 23:02:53 +0400 From: Kosta Todorovic Reply-To: Kosta Todorovic To: hadi@cyberus.ca Subject: Re: Network card driver problem (znb.o/tulip) Cc: Francois Romieu , Jon Mason , Ben Greear , jgarzik@pobox.com, tulip-users@lists.sourceforge.net, netdev@oss.sgi.com In-Reply-To: <1111327546.1094.47.camel@jzny.localdomain> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit References: <200503182333.51470.jdmason@us.ibm.com> <200503190757.27727.jdmason@us.ibm.com> <20050319152354.GA4946@electric-eye.fr.zoreil.com> <1111327546.1094.47.camel@jzny.localdomain> X-Virus-Scanned: ClamAV 0.83/774/Fri Mar 18 17:04:06 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 392 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: kostodo@gmail.com Precedence: bulk X-list: netdev Content-Length: 1563 Lines: 42 Using the standard tulip driver in 64bit mode loads the cards but they just dont seem to work. When i tested with "mii-tool -w" it keep saying "Autonegotiation Failed". On 20 Mar 2005 09:05:46 -0500, jamal wrote: > > I have those 4 port cards(quiet a few i may add and used in all my > experiments on NAPI with 10/100 etc for the last few eons) and they work > just fine with standard linux driver on my 32 bit hardware - not sure > about 64 bit. > There is one subtle difference. They use SYM PHY. > Donald Beckers drivers had this right - the current tulip driver still > has it wrong. I attempted to incorporate Donalds fixes a while back: > http://www.cyberus.ca/~hadi/patches/tulip-sym-fixed-20030103.tgz > > In my experience i have found even with current tulip driver no issues > unless you start doing things like 10Mbps half-duplex. I.e you dont need > the SYM PHY support. > > cheers, > jamal > > On Sat, 2005-03-19 at 10:23, Francois Romieu wrote: > > Jon Mason : > > [...] > > > The ZNXY website provides the driver source for the 4port adapter (and it is > > > GPL'ed), but it seems to me that this is really an issue of getting the > > > adapter to work with the "real" kernel driver, tulip. > > > > There are no sources for the rlk.O file and the driver suffers a bit from > > the usual out-of-tree hal braindamage. Both can probably be worked around > > but I would not make my business depend on the availability of a sane > > driver within a reasonable timescale. > > > > -- > > Ueimor > > > > > > From hadi@znyx.com Sun Mar 20 11:05:59 2005 Received: with ECARTIS (v1.0.0; list netdev); Sun, 20 Mar 2005 11:06:04 -0800 (PST) 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 j2KJ5xAW017239 for ; Sun, 20 Mar 2005 11:05:59 -0800 Received: from localhost ([208.2.156.2]) by lotus.znyx.com (Lotus Domino Release 5.0.11) with ESMTP id 2005032011070106:17996 ; Sun, 20 Mar 2005 11:07:01 -0800 Subject: patch: introduce simple actions From: Jamal Hadi Salim Reply-To: hadi@znyx.com To: "David S. Miller" Cc: netdev@oss.sgi.com, Thomas Graf , Patrick McHardy Organization: ZNYX Networks Message-Id: <1111345551.1095.82.camel@jzny.localdomain> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.2.2 Date: 20 Mar 2005 14:05:51 -0500 X-MIMETrack: Itemize by SMTP Server on Lotus/Znyx(Release 5.0.11 |July 24, 2002) at 03/20/2005 11:07:01 AM, Serialize by Router on Lotus/Znyx(Release 5.0.11 |July 24, 2002) at 03/20/2005 11:07:07 AM, Serialize complete at 03/20/2005 11:07:07 AM Content-Type: multipart/mixed; boundary="=-p2AQKKbb0wN2vG7zJ3CB" X-Virus-Scanned: ClamAV 0.83/774/Fri Mar 18 17:04:06 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 393 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: hadi@znyx.com Precedence: bulk X-list: netdev Content-Length: 4718 Lines: 199 --=-p2AQKKbb0wN2vG7zJ3CB Content-Transfer-Encoding: 7bit Content-Type: text/plain Ive posted this before - dont want it to sit here rotting. If theres nothing glaringly wrong with it (Thomas/Patrick?) then Dave please apply so i can start shooting other patches based on it. cheers, jamal --=-p2AQKKbb0wN2vG7zJ3CB Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=p15 Content-Type: text/plain; name=p15; charset=ISO-8859-1 --- /dev/null 2004-01-29 13:33:32.773091056 -0500 +++ 2611-rc3+bk3/include/net/act_generic.h 2005-02-06 15:55:36.000000000 -0500 @@ -0,0 +1,135 @@ +/* +*/ +static inline int tcf_defact_release(struct tcf_defact *p, int bind) +{ + int ret = 0; + if (p) { + if (bind) { + p->bindcnt--; + } + p->refcnt--; + if (p->bindcnt <= 0 && p->refcnt <= 0) { + kfree(p->defdata); + tcf_hash_destroy(p); + ret = 1; + } + } + return ret; +} + +static inline int +alloc_defdata(struct tcf_defact *p, u32 datalen, void *defdata) +{ + p->defdata = kmalloc(datalen, GFP_KERNEL); + if (p->defdata == NULL) + return -ENOMEM; + p->datalen = datalen; + memcpy(p->defdata, defdata, datalen); + return 0; +} + +static inline int +realloc_defdata(struct tcf_defact *p, u32 datalen, void *defdata) +{ + /* safer to be just brute force for now */ + kfree(p->defdata); + return alloc_defdata(p, datalen, defdata); +} + +static inline int +tcf_defact_init(struct rtattr *rta, struct rtattr *est, + struct tc_action *a, int ovr, int bind) +{ + struct rtattr *tb[TCA_DEF_MAX]; + struct tc_defact *parm; + struct tcf_defact *p; + void *defdata; + u32 datalen = 0; + int ret = 0; + + if (rta == NULL || rtattr_parse_nested(tb, TCA_DEF_MAX, rta) < 0) + return -EINVAL; + + if (tb[TCA_DEF_PARMS - 1] == NULL) + return -EINVAL; + parm = RTA_DATA(tb[TCA_DEF_PARMS - 1]); + defdata = RTA_DATA(tb[TCA_DEF_DATA - 1]); + if (defdata == NULL) + return -EINVAL; + + datalen = RTA_PAYLOAD(tb[TCA_DEF_DATA - 1]); + if (datalen <= 0) + return -EINVAL; + + p = tcf_hash_check(parm->index, a, ovr, bind); + if (p == NULL) { + p = tcf_hash_create(parm->index, est, a, sizeof(*p), ovr, bind); + if (p == NULL) + return -ENOMEM; + + ret = alloc_defdata(p, datalen, defdata); + if (ret < 0) { + kfree(p); + return ret; + } + ret = ACT_P_CREATED; + } else { + if (!ovr) { + tcf_defact_release(p, bind); + return -EEXIST; + } + realloc_defdata(p, datalen, defdata); + } + + spin_lock_bh(&p->lock); + p->action = parm->action; + spin_unlock_bh(&p->lock); + if (ret == ACT_P_CREATED) + tcf_hash_insert(p); + return ret; +} + +static inline int tcf_defact_cleanup(struct tc_action *a, int bind) +{ + struct tcf_defact *p = PRIV(a, defact); + + if (p != NULL) + return tcf_defact_release(p, bind); + return 0; +} + +static inline int +tcf_defact_dump(struct sk_buff *skb, struct tc_action *a, int bind, int ref) +{ + unsigned char *b = skb->tail; + struct tc_defact opt; + struct tcf_defact *p = PRIV(a, defact); + struct tcf_t t; + + opt.index = p->index; + opt.refcnt = p->refcnt - ref; + opt.bindcnt = p->bindcnt - bind; + opt.action = p->action; + RTA_PUT(skb, TCA_DEF_PARMS, sizeof(opt), &opt); + RTA_PUT(skb, TCA_DEF_DATA, p->datalen, p->defdata); + t.install = jiffies_to_clock_t(jiffies - p->tm.install); + t.lastuse = jiffies_to_clock_t(jiffies - p->tm.lastuse); + t.expires = jiffies_to_clock_t(p->tm.expires); + RTA_PUT(skb, TCA_DEF_TM, sizeof(t), &t); + return skb->len; + +rtattr_failure: + skb_trim(skb, b - skb->data); + return -1; +} + +#define tca_use_default_ops \ + .dump = tcf_defact_dump, \ + .cleanup = tcf_defact_cleanup, \ + .init = tcf_defact_init, \ + .walk = tcf_generic_walker, \ + +#define tca_use_default_defines(name) \ + static u32 idx_gen; \ + static struct tcf_defact *tcf_##name_ht[MY_TAB_SIZE]; \ + static DEFINE_RWLOCK(##name_lock); --- /dev/null 2004-01-29 13:33:32.773091056 -0500 +++ 2611-rc3+bk3/include/net/tc_act/tc_defact.h 2005-02-06 15:03:05.000000000 -0500 @@ -0,0 +1,13 @@ +#ifndef __NET_TC_DEF_H +#define __NET_TC_DEF_H + +#include + +struct tcf_defact +{ + tca_gen(defact); + u32 datalen; + void *defdata; +}; + +#endif --- /dev/null 2004-01-29 13:33:32.773091056 -0500 +++ 2611-rc3+bk3/include/linux/tc_act/tc_defact.h 2005-02-06 16:47:20.039209336 -0500 @@ -0,0 +1,21 @@ +#ifndef __LINUX_TC_DEF_H +#define __LINUX_TC_DEF_H + +#include + +struct tc_defact +{ + tc_gen; +}; + +enum +{ + TCA_DEF_UNSPEC, + TCA_DEF_TM, + TCA_DEF_PARMS, + TCA_DEF_DATA, + __TCA_DEF_MAX +}; +#define TCA_DEF_MAX (__TCA_DEF_MAX - 1) + +#endif --=-p2AQKKbb0wN2vG7zJ3CB-- From hadi@cyberus.ca Sun Mar 20 11:10:02 2005 Received: with ECARTIS (v1.0.0; list netdev); Sun, 20 Mar 2005 11:10:06 -0800 (PST) Received: from mx01.cybersurf.com (mx01.cybersurf.com [209.197.145.104]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j2KJA20J018058 for ; Sun, 20 Mar 2005 11:10:02 -0800 Received: from mail.cyberus.ca ([209.197.145.21]) by mx01.cybersurf.com with esmtp (Exim 4.30) id 1DD5oA-00061b-Vn for netdev@oss.sgi.com; Sun, 20 Mar 2005 12:09:54 -0700 Received: from [24.103.99.32] (helo=[10.0.0.9]) by mail.cyberus.ca with esmtp (Exim 4.20) id 1DD5oB-0000LM-Np; Sun, 20 Mar 2005 14:09:55 -0500 Subject: Re: Network card driver problem (znb.o/tulip) From: jamal Reply-To: hadi@cyberus.ca To: Kosta Todorovic Cc: Francois Romieu , Jon Mason , Ben Greear , jgarzik@pobox.com, tulip-users@lists.sourceforge.net, netdev@oss.sgi.com In-Reply-To: References: <200503182333.51470.jdmason@us.ibm.com> <200503190757.27727.jdmason@us.ibm.com> <20050319152354.GA4946@electric-eye.fr.zoreil.com> <1111327546.1094.47.camel@jzny.localdomain> Content-Type: text/plain Organization: jamalopolous Message-Id: <1111345791.1095.86.camel@jzny.localdomain> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.2.2 Date: 20 Mar 2005 14:09:51 -0500 Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV 0.83/774/Fri Mar 18 17:04:06 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 394 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: hadi@cyberus.ca Precedence: bulk X-list: netdev Content-Length: 467 Lines: 16 I dont think mii-tool will tell you the truth with these cards. Like i was saying earlier - they use SYM PHYs. Does it work on 32 bit machines? I am assuming when you say "64 bit" you mean the architecture not PCI bus. cheers, jamal On Sun, 2005-03-20 at 14:02, Kosta Todorovic wrote: > Using the standard tulip driver in 64bit mode loads the cards but they > just dont seem to work. > When i tested with "mii-tool -w" it keep saying "Autonegotiation Failed". From kaber@trash.net Sun Mar 20 11:10:59 2005 Received: with ECARTIS (v1.0.0; list netdev); Sun, 20 Mar 2005 11:11:04 -0800 (PST) Received: from kaber.coreworks.de ([62.206.217.67]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j2KJAwak018357 for ; Sun, 20 Mar 2005 11:10:59 -0800 Received: from localhost ([127.0.0.1]) by kaber.coreworks.de with esmtp (Exim 4.50) id 1DD5p6-0001AZ-Eu; Sun, 20 Mar 2005 20:10:52 +0100 Message-ID: <423DCABC.3030307@trash.net> Date: Sun, 20 Mar 2005 20:10:52 +0100 From: Patrick McHardy User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.7.5) Gecko/20050106 Debian/1.7.5-1 X-Accept-Language: en MIME-Version: 1.0 To: hadi@cyberus.ca CC: Ludo Stellingwerff , netdev@oss.sgi.com Subject: Re: [22/*] [NETFILTER] Use correct IPsec MTU in TCPMSS References: <20050314102614.GA9610@gondor.apana.org.au> <20050314105313.GA21001@gondor.apana.org.au> <20050314111002.GA29156@gondor.apana.org.au> <20050315091904.GA6256@gondor.apana.org.au> <20050315095837.GA7130@gondor.apana.org.au> <20050318090310.GA28443@gondor.apana.org.au> <20050318091129.GA28658@gondor.apana.org.au> <20050318104013.57d65e99.davem@davemloft.net> <423D9ADA.6050407@trash.net> <423DA58D.4050406@protactive.nl> <20050320171707.GE4201@xi.wantstofly.org> <423DB7B7.1070604@trash.net> <423DBCCE.8090006@protactive.nl> <423DBF6A.1080907@trash.net> <1111344225.1093.68.camel@jzny.localdomain> In-Reply-To: <1111344225.1093.68.camel@jzny.localdomain> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV 0.83/774/Fri Mar 18 17:04:06 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 395 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: kaber@trash.net Precedence: bulk X-list: netdev Content-Length: 729 Lines: 15 jamal wrote: > BTW, is there any reason the SPD couldnt have been implemented from day > one using netfilter classification ? Why did we need another speacilized > classifier? the actions are clearly implementable as targets. IMO iptables isn't so great that one would actually want to do this. The entire ruleset needs to be one continous area in memory, so it can not be changed, only replaced. To make it useable over pfkey would mean many things that are currently done by iptables in userspace need to be done in the kernel. There are multiple other reasons, but I don't think its even worth discussing this. This of course doesn't mean I'm against reducing the number of different classification engines. Regards Patrick From kostodo@gmail.com Sun Mar 20 11:18:17 2005 Received: with ECARTIS (v1.0.0; list netdev); Sun, 20 Mar 2005 11:18:21 -0800 (PST) Received: from rproxy.gmail.com (rproxy.gmail.com [64.233.170.198]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j2KJIHWY019588 for ; Sun, 20 Mar 2005 11:18:17 -0800 Received: by rproxy.gmail.com with SMTP id a36so798734rnf for ; Sun, 20 Mar 2005 11:18:15 -0800 (PST) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:reply-to:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:references; b=gvPxs6B2ZXbZo5VQqONm0P2KGk/QYLZmiblcXgyvCt2BtevYNY5ojo88YTsYUKAbjiWMKdN+eNtNUzS9g8kmue05hUGoBuTkBylGjAxdZL4XqwKUNhl98eyNGlHU8LsQGZE0XITbHyni+Ocd6pHp8gEDUnvNTllBKQzbU0ZDg0M= Received: by 10.38.99.9 with SMTP id w9mr4570813rnb; Sun, 20 Mar 2005 11:18:14 -0800 (PST) Received: by 10.38.208.49 with HTTP; Sun, 20 Mar 2005 11:18:14 -0800 (PST) Message-ID: Date: Sun, 20 Mar 2005 23:18:14 +0400 From: Kosta Todorovic Reply-To: Kosta Todorovic To: hadi@cyberus.ca Subject: Re: Network card driver problem (znb.o/tulip) Cc: Francois Romieu , Jon Mason , Ben Greear , jgarzik@pobox.com, tulip-users@lists.sourceforge.net, netdev@oss.sgi.com In-Reply-To: <1111345791.1095.86.camel@jzny.localdomain> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit References: <200503182333.51470.jdmason@us.ibm.com> <200503190757.27727.jdmason@us.ibm.com> <20050319152354.GA4946@electric-eye.fr.zoreil.com> <1111327546.1094.47.camel@jzny.localdomain> <1111345791.1095.86.camel@jzny.localdomain> X-Virus-Scanned: ClamAV 0.83/774/Fri Mar 18 17:04:06 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 396 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: kostodo@gmail.com Precedence: bulk X-list: netdev Content-Length: 434 Lines: 12 > I dont think mii-tool will tell you the truth with these cards. > Like i was saying earlier - they use SYM PHYs. Either way, no traffic moved across them when I tried. > Does it work on 32 bit machines? I am assuming when you say "64 bit" you > mean the architecture not PCI bus. Yes it does work on 32bit machines, but with the actual znb.o driver thats supplied by ZNXY. And yes i am refering to architecture and NOT pci bus. From kaber@trash.net Sun Mar 20 11:23:07 2005 Received: with ECARTIS (v1.0.0; list netdev); Sun, 20 Mar 2005 11:23:11 -0800 (PST) Received: from kaber.coreworks.de ([62.206.217.67]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j2KJN62P020405 for ; Sun, 20 Mar 2005 11:23:06 -0800 Received: from localhost ([127.0.0.1]) by kaber.coreworks.de with esmtp (Exim 4.50) id 1DD60i-0001Ba-3y; Sun, 20 Mar 2005 20:22:52 +0100 Message-ID: <423DCD8C.6030100@trash.net> Date: Sun, 20 Mar 2005 20:22:52 +0100 From: Patrick McHardy User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.7.5) Gecko/20050106 Debian/1.7.5-1 X-Accept-Language: en MIME-Version: 1.0 To: hadi@znyx.com CC: "David S. Miller" , netdev@oss.sgi.com, Thomas Graf Subject: Re: patch: introduce simple actions References: <1111345551.1095.82.camel@jzny.localdomain> In-Reply-To: <1111345551.1095.82.camel@jzny.localdomain> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV 0.83/774/Fri Mar 18 17:04:06 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 398 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: kaber@trash.net Precedence: bulk X-list: netdev Content-Length: 476 Lines: 13 Jamal Hadi Salim wrote: > Ive posted this before - dont want it to sit here rotting. > If theres nothing glaringly wrong with it (Thomas/Patrick?) then Dave > please apply so i can start shooting other patches based on it. Any reasons why all of these need to be inline functions? One of the next things I wanted to do in this area was moving all the large inline functions to act_generic.c, so if possible I would prefer not to put these in a header file. Regards Patrick From bunk@stusta.de Sun Mar 20 11:23:00 2005 Received: with ECARTIS (v1.0.0; list netdev); Sun, 20 Mar 2005 11:23:07 -0800 (PST) Received: from mailout.stusta.mhn.de (emailhub.stusta.mhn.de [141.84.69.5]) by oss.sgi.com (8.13.0/8.13.0) with SMTP id j2KJMvfn020390 for ; Sun, 20 Mar 2005 11:22:58 -0800 Received: (qmail 15571 invoked from network); 20 Mar 2005 19:22:52 -0000 Received: from r063144.stusta.swh.mhn.de (10.150.63.144) by mailhub.stusta.mhn.de with SMTP; 20 Mar 2005 19:22:52 -0000 Received: by r063144.stusta.swh.mhn.de (Postfix, from userid 1000) id ED56FBB862; Sun, 20 Mar 2005 20:22:50 +0100 (CET) Date: Sun, 20 Mar 2005 20:22:50 +0100 From: Adrian Bunk To: chas@cmf.nrl.navy.mil Cc: linux-atm-general@lists.sourceforge.net, linux-kernel@vger.kernel.org, netdev@oss.sgi.com Subject: [2.6 patch] net/atm/: possible cleanups Message-ID: <20050320192250.GN4449@stusta.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.5.6+20040907i X-Virus-Scanned: ClamAV 0.83/774/Fri Mar 18 17:04:06 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 397 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: bunk@stusta.de Precedence: bulk X-list: netdev Content-Length: 12397 Lines: 400 This patch contains the following possible cleanups: - make needlessly global code static - lec.c: remove the unused global function get_dev_lec Signed-off-by: Adrian Bunk --- net/atm/common.c | 2 - net/atm/lec.c | 83 +++++++++++++++++++++++--------------------- net/atm/lec.h | 9 ---- net/atm/lec_arpc.h | 24 ------------ net/atm/mpc.c | 6 +-- net/atm/mpc.h | 4 -- net/atm/pppoatm.c | 2 - net/atm/protocols.h | 2 - net/atm/raw.c | 2 - 9 files changed, 51 insertions(+), 83 deletions(-) --- linux-2.6.11-mm3-full/net/atm/common.c.old 2005-03-13 05:06:33.000000000 +0100 +++ linux-2.6.11-mm3-full/net/atm/common.c 2005-03-13 05:06:53.000000000 +0100 @@ -41,7 +41,7 @@ struct hlist_head vcc_hash[VCC_HTABLE_SIZE]; DEFINE_RWLOCK(vcc_sklist_lock); -void __vcc_insert_socket(struct sock *sk) +static void __vcc_insert_socket(struct sock *sk) { struct atm_vcc *vcc = atm_sk(sk); struct hlist_head *head = &vcc_hash[vcc->vci & --- linux-2.6.11-mm3-full/net/atm/lec.h.old 2005-03-13 05:08:02.000000000 +0100 +++ linux-2.6.11-mm3-full/net/atm/lec.h 2005-03-13 05:19:21.000000000 +0100 @@ -146,14 +146,5 @@ #define LEC_VCC_PRIV(vcc) ((struct lec_vcc_priv *)((vcc)->user_back)) -int lecd_attach(struct atm_vcc *vcc, int arg); -int lec_vcc_attach(struct atm_vcc *vcc, void __user *arg); -int lec_mcast_attach(struct atm_vcc *vcc, int arg); -struct net_device *get_dev_lec(int itf); -int send_to_lecd(struct lec_priv *priv, - atmlec_msg_type type, unsigned char *mac_addr, - unsigned char *atm_addr, struct sk_buff *data); -void lec_push(struct atm_vcc *vcc, struct sk_buff *skb); - #endif /* _LEC_H_ */ --- linux-2.6.11-mm3-full/net/atm/lec_arpc.h.old 2005-03-13 05:09:21.000000000 +0100 +++ linux-2.6.11-mm3-full/net/atm/lec_arpc.h 2005-03-13 05:18:30.000000000 +0100 @@ -89,28 +89,4 @@ #define LEC_REMOTE_FLAG 0x0001 #define LEC_PERMANENT_FLAG 0x0002 -/* Protos */ -void lec_arp_init(struct lec_priv *priv); -int lec_mcast_make(struct lec_priv *priv, struct atm_vcc *vcc); -void lec_arp_destroy(struct lec_priv *priv); -void lec_vcc_close(struct lec_priv *priv, struct atm_vcc *vcc); - -struct atm_vcc *lec_arp_resolve(struct lec_priv *priv, - unsigned char *mac_to_addr, - int is_rdesc, - struct lec_arp_table **ret_entry); -void lec_vcc_added(struct lec_priv *dev, - struct atmlec_ioc *ioc_data, struct atm_vcc *vcc, - void (*old_push)(struct atm_vcc *vcc, struct sk_buff *skb)); -void lec_arp_check_empties(struct lec_priv *priv, - struct atm_vcc *vcc, struct sk_buff *skb); -int lec_addr_delete(struct lec_priv *priv, - unsigned char *mac_addr, unsigned long permanent); -void lec_flush_complete(struct lec_priv *priv, unsigned long tran_id); -void lec_arp_update(struct lec_priv *priv, - unsigned char *mac_addr, unsigned char *atm_addr, - unsigned long remoteflag, unsigned int targetless_le_arp); -void lec_set_flush_tran_id(struct lec_priv *priv, - unsigned char *mac_addr, unsigned long tran_id); - #endif --- linux-2.6.11-mm3-full/net/atm/lec.c.old 2005-03-13 05:07:11.000000000 +0100 +++ linux-2.6.11-mm3-full/net/atm/lec.c 2005-03-13 05:19:26.000000000 +0100 @@ -83,6 +83,29 @@ static int lane2_associate_req (struct net_device *dev, u8 *lan_dst, u8 *tlvs, u32 sizeoftlvs); +static int lec_addr_delete(struct lec_priv *priv, unsigned char *atm_addr, + unsigned long permanent); +static void lec_arp_check_empties(struct lec_priv *priv, + struct atm_vcc *vcc, struct sk_buff *skb); +static void lec_arp_destroy(struct lec_priv *priv); +static void lec_arp_init(struct lec_priv *priv); +static struct atm_vcc* lec_arp_resolve(struct lec_priv *priv, + unsigned char *mac_to_find, + int is_rdesc, + struct lec_arp_table **ret_entry); +static void lec_arp_update(struct lec_priv *priv, unsigned char *mac_addr, + unsigned char *atm_addr, unsigned long remoteflag, + unsigned int targetless_le_arp); +static void lec_flush_complete(struct lec_priv *priv, unsigned long tran_id); +static int lec_mcast_make(struct lec_priv *priv, struct atm_vcc *vcc); +static void lec_set_flush_tran_id(struct lec_priv *priv, + unsigned char *atm_addr, + unsigned long tran_id); +static void lec_vcc_added(struct lec_priv *priv, struct atmlec_ioc *ioc_data, + struct atm_vcc *vcc, + void (*old_push)(struct atm_vcc *vcc, struct sk_buff *skb)); +static void lec_vcc_close(struct lec_priv *priv, struct atm_vcc *vcc); + static struct lane2_ops lane2_ops = { lane2_resolve, /* resolve, spec 3.1.3 */ lane2_associate_req, /* associate_req, spec 3.1.4 */ @@ -94,21 +117,6 @@ /* Device structures */ static struct net_device *dev_lec[MAX_LEC_ITF]; -/* This will be called from proc.c via function pointer */ -struct net_device *get_dev_lec(int itf) -{ - struct net_device *dev; - - if (itf >= MAX_LEC_ITF) - return NULL; - rtnl_lock(); - dev = dev_lec[itf]; - if (dev) - dev_hold(dev); - rtnl_unlock(); - return dev; -} - #if defined(CONFIG_BRIDGE) || defined(CONFIG_BRIDGE_MODULE) static void lec_handle_bridge(struct sk_buff *skb, struct net_device *dev) { @@ -155,7 +163,7 @@ * and returns NULL. */ #ifdef CONFIG_TR -unsigned char *get_tr_dst(unsigned char *packet, unsigned char *rdesc) +static unsigned char *get_tr_dst(unsigned char *packet, unsigned char *rdesc) { struct trh_hdr *trh; int riflen, num_rdsc; @@ -599,7 +607,7 @@ * LANE2: new argument struct sk_buff *data contains * the LE_ARP based TLVs introduced in the LANE2 spec */ -int +static int send_to_lecd(struct lec_priv *priv, atmlec_msg_type type, unsigned char *mac_addr, unsigned char *atm_addr, struct sk_buff *data) @@ -681,7 +689,7 @@ 0x01, 0x01 }; -void +static void lec_push(struct atm_vcc *vcc, struct sk_buff *skb) { struct net_device *dev = (struct net_device *)vcc->proto_data; @@ -764,7 +772,7 @@ } } -void +static void lec_pop(struct atm_vcc *vcc, struct sk_buff *skb) { struct lec_vcc_priv *vpriv = LEC_VCC_PRIV(vcc); @@ -784,7 +792,7 @@ } } -int +static int lec_vcc_attach(struct atm_vcc *vcc, void __user *arg) { struct lec_vcc_priv *vpriv; @@ -813,7 +821,7 @@ return 0; } -int +static int lec_mcast_attach(struct atm_vcc *vcc, int arg) { if (arg <0 || arg >= MAX_LEC_ITF || !dev_lec[arg]) @@ -823,7 +831,7 @@ } /* Initialize device. */ -int +static int lecd_attach(struct atm_vcc *vcc, int arg) { int i; @@ -1383,7 +1391,6 @@ static void lec_arp_check_expire(unsigned long data); static void lec_arp_expire_arp(unsigned long data); -void dump_arp_table(struct lec_priv *priv); /* * Arp table funcs @@ -1394,7 +1401,7 @@ /* * Initialization of arp-cache */ -void +static void lec_arp_init(struct lec_priv *priv) { unsigned short i; @@ -1410,7 +1417,7 @@ add_timer(&priv->lec_arp_timer); } -void +static void lec_arp_clear_vccs(struct lec_arp_table *entry) { if (entry->vcc) { @@ -1539,7 +1546,7 @@ } #endif -void +static void dump_arp_table(struct lec_priv *priv) { #if DEBUG_ARP_TABLE @@ -1691,7 +1698,7 @@ /* * Destruction of arp-cache */ -void +static void lec_arp_destroy(struct lec_priv *priv) { unsigned long flags; @@ -1953,9 +1960,9 @@ * Try to find vcc where mac_address is attached. * */ -struct atm_vcc* -lec_arp_resolve(struct lec_priv *priv, unsigned char *mac_to_find, int is_rdesc, - struct lec_arp_table **ret_entry) +static struct atm_vcc* +lec_arp_resolve(struct lec_priv *priv, unsigned char *mac_to_find, + int is_rdesc, struct lec_arp_table **ret_entry) { unsigned long flags; struct lec_arp_table *entry; @@ -2034,7 +2041,7 @@ return found; } -int +static int lec_addr_delete(struct lec_priv *priv, unsigned char *atm_addr, unsigned long permanent) { @@ -2064,7 +2071,7 @@ /* * Notifies: Response to arp_request (atm_addr != NULL) */ -void +static void lec_arp_update(struct lec_priv *priv, unsigned char *mac_addr, unsigned char *atm_addr, unsigned long remoteflag, unsigned int targetless_le_arp) @@ -2176,7 +2183,7 @@ /* * Notifies: Vcc setup ready */ -void +static void lec_vcc_added(struct lec_priv *priv, struct atmlec_ioc *ioc_data, struct atm_vcc *vcc, void (*old_push)(struct atm_vcc *vcc, struct sk_buff *skb)) @@ -2320,7 +2327,7 @@ spin_unlock_irqrestore(&priv->lec_arp_lock, flags); } -void +static void lec_flush_complete(struct lec_priv *priv, unsigned long tran_id) { unsigned long flags; @@ -2346,7 +2353,7 @@ dump_arp_table(priv); } -void +static void lec_set_flush_tran_id(struct lec_priv *priv, unsigned char *atm_addr, unsigned long tran_id) { @@ -2364,7 +2371,7 @@ spin_unlock_irqrestore(&priv->lec_arp_lock, flags); } -int +static int lec_mcast_make(struct lec_priv *priv, struct atm_vcc *vcc) { unsigned long flags; @@ -2401,7 +2408,7 @@ return err; } -void +static void lec_vcc_close(struct lec_priv *priv, struct atm_vcc *vcc) { unsigned long flags; @@ -2476,7 +2483,7 @@ dump_arp_table(priv); } -void +static void lec_arp_check_empties(struct lec_priv *priv, struct atm_vcc *vcc, struct sk_buff *skb) { --- linux-2.6.11-mm3-full/net/atm/mpc.h.old 2005-03-13 05:20:07.000000000 +0100 +++ linux-2.6.11-mm3-full/net/atm/mpc.h 2005-03-13 05:20:22.000000000 +0100 @@ -11,10 +11,6 @@ /* kernel -> mpc-daemon */ int msg_to_mpoad(struct k_message *msg, struct mpoa_client *mpc); -/* Functions for ioctl(ATMMPC_*) operations */ -int atm_mpoa_mpoad_attach(struct atm_vcc *vcc, int arg); -int atm_mpoa_vcc_attach(struct atm_vcc *vcc, void __user *arg); - struct mpoa_client { struct mpoa_client *next; struct net_device *dev; /* lec in question */ --- linux-2.6.11-mm3-full/net/atm/mpc.c.old 2005-03-13 05:19:38.000000000 +0100 +++ linux-2.6.11-mm3-full/net/atm/mpc.c 2005-03-13 05:20:29.000000000 +0100 @@ -564,7 +564,7 @@ return retval; } -int atm_mpoa_vcc_attach(struct atm_vcc *vcc, void __user *arg) +static int atm_mpoa_vcc_attach(struct atm_vcc *vcc, void __user *arg) { int bytes_left; struct mpoa_client *mpc; @@ -753,7 +753,7 @@ /* members not explicitly initialised will be 0 */ }; -int atm_mpoa_mpoad_attach (struct atm_vcc *vcc, int arg) +static int atm_mpoa_mpoad_attach (struct atm_vcc *vcc, int arg) { struct mpoa_client *mpc; struct lec_priv *priv; @@ -1460,7 +1460,7 @@ return 0; } -void __exit atm_mpoa_cleanup(void) +static void __exit atm_mpoa_cleanup(void) { struct mpoa_client *mpc, *tmp; struct atm_mpoa_qos *qos, *nextqos; --- linux-2.6.11-mm3-full/net/atm/pppoatm.c.old 2005-03-13 05:20:41.000000000 +0100 +++ linux-2.6.11-mm3-full/net/atm/pppoatm.c 2005-03-13 05:20:50.000000000 +0100 @@ -345,7 +345,7 @@ return -ENOIOCTLCMD; } -struct atm_ioctl pppoatm_ioctl_ops = { +static struct atm_ioctl pppoatm_ioctl_ops = { .owner = THIS_MODULE, .ioctl = pppoatm_ioctl, }; --- linux-2.6.11-mm3-full/net/atm/protocols.h.old 2005-03-13 05:21:05.000000000 +0100 +++ linux-2.6.11-mm3-full/net/atm/protocols.h 2005-03-13 05:21:19.000000000 +0100 @@ -6,8 +6,6 @@ #ifndef NET_ATM_PROTOCOLS_H #define NET_ATM_PROTOCOLS_H -void atm_push_raw(struct atm_vcc *vcc,struct sk_buff *skb); - int atm_init_aal0(struct atm_vcc *vcc); /* "raw" AAL0 */ int atm_init_aal34(struct atm_vcc *vcc);/* "raw" AAL3/4 transport */ int atm_init_aal5(struct atm_vcc *vcc); /* "raw" AAL5 transport */ --- linux-2.6.11-mm3-full/net/atm/raw.c.old 2005-03-13 05:21:26.000000000 +0100 +++ linux-2.6.11-mm3-full/net/atm/raw.c 2005-03-13 05:21:37.000000000 +0100 @@ -25,7 +25,7 @@ * SKB == NULL indicates that the link is being closed */ -void atm_push_raw(struct atm_vcc *vcc,struct sk_buff *skb) +static void atm_push_raw(struct atm_vcc *vcc,struct sk_buff *skb) { if (skb) { struct sock *sk = sk_atm(vcc); From hadi@cyberus.ca Sun Mar 20 11:29:13 2005 Received: with ECARTIS (v1.0.0; list netdev); Sun, 20 Mar 2005 11:29:17 -0800 (PST) Received: from mx02.cybersurf.com (mx02.cybersurf.com [209.197.145.105]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j2KJTDdm021919 for ; Sun, 20 Mar 2005 11:29:13 -0800 Received: from mail.cyberus.ca ([209.197.145.21]) by mx02.cybersurf.com with esmtp (Exim 4.30) id 1DD66p-0001aB-33 for netdev@oss.sgi.com; Sun, 20 Mar 2005 14:29:11 -0500 Received: from [24.103.99.32] (helo=[10.0.0.9]) by mail.cyberus.ca with esmtp (Exim 4.20) id 1DD66m-0002ge-Uz; Sun, 20 Mar 2005 14:29:09 -0500 Subject: Re: Network card driver problem (znb.o/tulip) From: jamal Reply-To: hadi@cyberus.ca To: Kosta Todorovic Cc: Francois Romieu , Jon Mason , Ben Greear , jgarzik@pobox.com, tulip-users@lists.sourceforge.net, netdev@oss.sgi.com In-Reply-To: References: <200503182333.51470.jdmason@us.ibm.com> <200503190757.27727.jdmason@us.ibm.com> <20050319152354.GA4946@electric-eye.fr.zoreil.com> <1111327546.1094.47.camel@jzny.localdomain> <1111345791.1095.86.camel@jzny.localdomain> Content-Type: text/plain Organization: jamalopolous Message-Id: <1111346944.1094.91.camel@jzny.localdomain> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.2.2 Date: 20 Mar 2005 14:29:04 -0500 Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV 0.83/774/Fri Mar 18 17:04:06 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 399 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: hadi@cyberus.ca Precedence: bulk X-list: netdev Content-Length: 869 Lines: 26 On Sun, 2005-03-20 at 14:18, Kosta Todorovic wrote: > > I dont think mii-tool will tell you the truth with these cards. > > Like i was saying earlier - they use SYM PHYs. > > Either way, no traffic moved across them when I tried. > Probably the stats display is your best bet for debugging. > > Does it work on 32 bit machines? I am assuming when you say "64 bit" you > > mean the architecture not PCI bus. > > Yes it does work on 32bit machines, but with the actual znb.o driver > thats supplied by ZNXY. > And yes i am refering to architecture and NOT pci bus. It works just fine for me with 32 bit machine with the standard tulip driver(sorry dont have 64 bit - too poor); does it work for you? i.e i dont use the Znyx driver at all. I always have mine running 100Mbps FDX. If it works on 32 bit, then it maybe an issue with the tulip driver. cheers, jamal From kostodo@gmail.com Sun Mar 20 11:36:17 2005 Received: with ECARTIS (v1.0.0; list netdev); Sun, 20 Mar 2005 11:36:23 -0800 (PST) Received: from rproxy.gmail.com (rproxy.gmail.com [64.233.170.207]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j2KJaGre022953 for ; Sun, 20 Mar 2005 11:36:17 -0800 Received: by rproxy.gmail.com with SMTP id c51so758838rne for ; Sun, 20 Mar 2005 11:36:16 -0800 (PST) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:reply-to:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:references; b=b/r0Nd1O9FT+nbMjIkHLiyJIUMfh2RmdOnJpesOml2T/Cb8Q4lzTGFm9V+bh/D2kD+Ob+pHMO9udAqyG88htQlzrigpF35CUKndaFGnT1kXbduIaLSCJALCCKjYeb5CVOFzABWA6qcSzbd0AKcMlHDdIjlawZzo9NlEir+Lyl1U= Received: by 10.39.3.74 with SMTP id f74mr749387rni; Sun, 20 Mar 2005 11:36:16 -0800 (PST) Received: by 10.38.208.49 with HTTP; Sun, 20 Mar 2005 11:36:16 -0800 (PST) Message-ID: Date: Sun, 20 Mar 2005 23:36:16 +0400 From: Kosta Todorovic Reply-To: Kosta Todorovic To: hadi@cyberus.ca Subject: Re: Network card driver problem (znb.o/tulip) Cc: Francois Romieu , Jon Mason , Ben Greear , jgarzik@pobox.com, tulip-users@lists.sourceforge.net, netdev@oss.sgi.com In-Reply-To: <1111346944.1094.91.camel@jzny.localdomain> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit References: <200503182333.51470.jdmason@us.ibm.com> <200503190757.27727.jdmason@us.ibm.com> <20050319152354.GA4946@electric-eye.fr.zoreil.com> <1111327546.1094.47.camel@jzny.localdomain> <1111345791.1095.86.camel@jzny.localdomain> <1111346944.1094.91.camel@jzny.localdomain> X-Virus-Scanned: ClamAV 0.83/774/Fri Mar 18 17:04:06 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 401 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: kostodo@gmail.com Precedence: bulk X-list: netdev Content-Length: 1143 Lines: 33 I'm not sure if the tulip driver works in 32bit mode. I know that the znb driver works. I will check the tulip driver in 32bit mode tomorrow and let you know. On 20 Mar 2005 14:29:04 -0500, jamal wrote: > On Sun, 2005-03-20 at 14:18, Kosta Todorovic wrote: > > > I dont think mii-tool will tell you the truth with these cards. > > > Like i was saying earlier - they use SYM PHYs. > > > > Either way, no traffic moved across them when I tried. > > > > Probably the stats display is your best bet for debugging. > > > > Does it work on 32 bit machines? I am assuming when you say "64 bit" you > > > mean the architecture not PCI bus. > > > > Yes it does work on 32bit machines, but with the actual znb.o driver > > thats supplied by ZNXY. > > And yes i am refering to architecture and NOT pci bus. > > It works just fine for me with 32 bit machine with the standard tulip > driver(sorry dont have 64 bit - too poor); does it work for you? > i.e i dont use the Znyx driver at all. I always have mine running > 100Mbps FDX. > > If it works on 32 bit, then it maybe an issue with the tulip driver. > > cheers, > jamal > > From hadi@znyx.com Sun Mar 20 11:35:51 2005 Received: with ECARTIS (v1.0.0; list netdev); Sun, 20 Mar 2005 11:35:57 -0800 (PST) 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 j2KJZpd3022903 for ; Sun, 20 Mar 2005 11:35:51 -0800 Received: from localhost ([208.2.156.2]) by lotus.znyx.com (Lotus Domino Release 5.0.11) with ESMTP id 2005032011365584:18021 ; Sun, 20 Mar 2005 11:36:55 -0800 Subject: Re: patch: introduce simple actions From: Jamal Hadi Salim Reply-To: hadi@znyx.com To: Patrick McHardy Cc: "David S. Miller" , netdev@oss.sgi.com, Thomas Graf In-Reply-To: <423DCD8C.6030100@trash.net> References: <1111345551.1095.82.camel@jzny.localdomain> <423DCD8C.6030100@trash.net> Organization: ZNYX Networks Message-Id: <1111347345.1094.98.camel@jzny.localdomain> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.2.2 Date: 20 Mar 2005 14:35:45 -0500 X-MIMETrack: Itemize by SMTP Server on Lotus/Znyx(Release 5.0.11 |July 24, 2002) at 03/20/2005 11:36:56 AM, Serialize by Router on Lotus/Znyx(Release 5.0.11 |July 24, 2002) at 03/20/2005 11:36:59 AM, Serialize complete at 03/20/2005 11:36:59 AM Content-Type: multipart/mixed; boundary="=-c9/4dXqnMUKz+Hz7wNN4" X-Virus-Scanned: ClamAV 0.83/774/Fri Mar 18 17:04:06 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 400 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: hadi@znyx.com Precedence: bulk X-list: netdev Content-Length: 4173 Lines: 151 --=-c9/4dXqnMUKz+Hz7wNN4 Content-Transfer-Encoding: 7bit Content-Type: text/plain On Sun, 2005-03-20 at 14:22, Patrick McHardy wrote: > Jamal Hadi Salim wrote: > > Ive posted this before - dont want it to sit here rotting. > > If theres nothing glaringly wrong with it (Thomas/Patrick?) then Dave > > please apply so i can start shooting other patches based on it. > > Any reasons why all of these need to be inline functions? A lot of the code is very common. I am essentially sticking some common code as inlines to allow someone to write some very simple code - probably just the packet processing function - see attached simple action. Inlines seem easy to allow this. > One of the next things I wanted to do in this area was > moving all the large inline functions to act_generic.c, > so if possible I would prefer not to put these in a header > file. > These are small functions. Take a look at the simple action i attached. If you can give me the same functionality and still move things de_inlined to act_generic.c i would be fine with it. cheers, jamal --=-c9/4dXqnMUKz+Hz7wNN4 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=p16 Content-Type: text/plain; name=p16; charset=ISO-8859-1 --- /dev/null 2004-01-29 13:33:32.773091056 -0500 +++ 2611-rc3+bk3/net/sched/simple.c 2005-02-06 15:55:57.000000000 -0500 @@ -0,0 +1,107 @@ +/* + * net/sched/simp.c Simple example of an action + * + * This program is free software; you can redistribute it and/or + * modify it under the terms of the GNU General Public License + * as published by the Free Software Foundation; either version + * 2 of the License, or (at your option) any later version. + * + * Authors: Jamal Hadi Salim (2005) + * + */ + +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include + +#define TCA_ACT_SIMP 22 + +/* XXX: Hide all these common elements under some macro + * probably +*/ +#include +#include + +/* use generic hash table with 8 buckets */ +#define MY_TAB_SIZE 8 +#define MY_TAB_MASK (MY_TAB_SIZE - 1) +static u32 idx_gen; +static struct tcf_defact *tcf_simp_ht[MY_TAB_SIZE]; +static DEFINE_RWLOCK(simp_lock); + +/* override the defaults */ +#define tcf_st tcf_defact +#define tc_st tc_defact +#define tcf_t_lock simp_lock +#define tcf_ht tcf_simp_ht + +#define CONFIG_NET_ACT_INIT 1 +#include +#include + +static int tcf_simp(struct sk_buff **pskb, struct tc_action *a) +{ + struct sk_buff *skb = *pskb; + struct tcf_defact *p = PRIV(a, defact); + + spin_lock(&p->lock); + p->tm.lastuse = jiffies; + p->bstats.bytes += skb->len; + p->bstats.packets++; + + /* print policy string followed by _ then packet count + * Example if this was the 3rd packet and the string was "hello" + * then it would look like "hello_3" (without quotes) + **/ + printk("simple: %s_%d\n", (char *)p->defdata, p->bstats.packets); + spin_unlock(&p->lock); + return p->action; +} + +static struct tc_action_ops act_simp_ops = { + .kind = "simple", + .type = TCA_ACT_SIMP, + .capab = TCA_CAP_NONE, + .owner = THIS_MODULE, + .act = tcf_simp, + tca_use_default_ops +}; + +MODULE_AUTHOR("Jamal Hadi Salim(2005)"); +MODULE_DESCRIPTION("Simple example action"); +MODULE_LICENSE("GPL"); + +static int __init simp_init_module(void) +{ + int ret = tcf_register_action(&act_simp_ops); + if (!ret) + printk("Simple TC action Loaded\n"); + return ret; +} + +static void __exit simp_cleanup_module(void) +{ + tcf_unregister_action(&act_simp_ops); +} + +module_init(simp_init_module); +module_exit(simp_cleanup_module); --=-c9/4dXqnMUKz+Hz7wNN4-- From hadi@cyberus.ca Sun Mar 20 11:38:33 2005 Received: with ECARTIS (v1.0.0; list netdev); Sun, 20 Mar 2005 11:38:38 -0800 (PST) Received: from mx03.cybersurf.com (mx03.cybersurf.com [209.197.145.106]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j2KJcXhr023968 for ; Sun, 20 Mar 2005 11:38:33 -0800 Received: from mail.cyberus.ca ([209.197.145.21]) by mx03.cybersurf.com with esmtp (Exim 4.30) id 1DD6Fs-00032L-Sj for netdev@oss.sgi.com; Sun, 20 Mar 2005 14:38:32 -0500 Received: from [24.103.99.32] (helo=[10.0.0.9]) by mail.cyberus.ca with esmtp (Exim 4.20) id 1DD6Fo-0003bg-DV; Sun, 20 Mar 2005 14:38:28 -0500 Subject: Re: Network card driver problem (znb.o/tulip) From: jamal Reply-To: hadi@cyberus.ca To: Kosta Todorovic Cc: Francois Romieu , Jon Mason , Ben Greear , jgarzik@pobox.com, tulip-users@lists.sourceforge.net, netdev@oss.sgi.com In-Reply-To: References: <200503182333.51470.jdmason@us.ibm.com> <200503190757.27727.jdmason@us.ibm.com> <20050319152354.GA4946@electric-eye.fr.zoreil.com> <1111327546.1094.47.camel@jzny.localdomain> <1111345791.1095.86.camel@jzny.localdomain> <1111346944.1094.91.camel@jzny.localdomain> Content-Type: text/plain Organization: jamalopolous Message-Id: <1111347503.1095.101.camel@jzny.localdomain> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.2.2 Date: 20 Mar 2005 14:38:23 -0500 Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV 0.83/774/Fri Mar 18 17:04:06 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 402 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: hadi@cyberus.ca Precedence: bulk X-list: netdev Content-Length: 1430 Lines: 44 Your best is to get the tulip driver working. The card is EOLed; Also if you can (If Donald still does this) try out Donalds version of the driver. cheers, jamal On Sun, 2005-03-20 at 14:36, Kosta Todorovic wrote: > I'm not sure if the tulip driver works in 32bit mode. I know that the > znb driver works. > I will check the tulip driver in 32bit mode tomorrow and let you know. > > > On 20 Mar 2005 14:29:04 -0500, jamal wrote: > > On Sun, 2005-03-20 at 14:18, Kosta Todorovic wrote: > > > > I dont think mii-tool will tell you the truth with these cards. > > > > Like i was saying earlier - they use SYM PHYs. > > > > > > Either way, no traffic moved across them when I tried. > > > > > > > Probably the stats display is your best bet for debugging. > > > > > > Does it work on 32 bit machines? I am assuming when you say "64 bit" you > > > > mean the architecture not PCI bus. > > > > > > Yes it does work on 32bit machines, but with the actual znb.o driver > > > thats supplied by ZNXY. > > > And yes i am refering to architecture and NOT pci bus. > > > > It works just fine for me with 32 bit machine with the standard tulip > > driver(sorry dont have 64 bit - too poor); does it work for you? > > i.e i dont use the Znyx driver at all. I always have mine running > > 100Mbps FDX. > > > > If it works on 32 bit, then it maybe an issue with the tulip driver. > > > > cheers, > > jamal > > > > > From tgraf@suug.ch Sun Mar 20 11:43:51 2005 Received: with ECARTIS (v1.0.0; list netdev); Sun, 20 Mar 2005 11:43:55 -0800 (PST) Received: from b.mx.projectdream.org (eth0-0.arisu.projectdream.org [194.158.4.191]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j2KJhorQ025017 for ; Sun, 20 Mar 2005 11:43:50 -0800 Received: from postel.suug.ch (postel.suug.ch [195.134.158.23]) (using TLSv1 with cipher EDH-RSA-DES-CBC3-SHA (168/168 bits)) (No client certificate requested) by b.mx.projectdream.org (Postfix) with ESMTP id 9E35982; Sun, 20 Mar 2005 20:43:25 +0100 (CET) Received: by postel.suug.ch (Postfix, from userid 10001) id AFAB81C0EA; Sun, 20 Mar 2005 20:44:08 +0100 (CET) Date: Sun, 20 Mar 2005 20:44:08 +0100 From: Thomas Graf To: Jamal Hadi Salim Cc: "David S. Miller" , netdev@oss.sgi.com, Patrick McHardy Subject: Re: patch: introduce simple actions Message-ID: <20050320194408.GU3086@postel.suug.ch> References: <1111345551.1095.82.camel@jzny.localdomain> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1111345551.1095.82.camel@jzny.localdomain> X-Virus-Scanned: ClamAV 0.83/774/Fri Mar 18 17:04:06 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 403 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: tgraf@suug.ch Precedence: bulk X-list: netdev Content-Length: 1789 Lines: 64 * Jamal Hadi Salim <1111345551.1095.82.camel@jzny.localdomain> 2005-03-20 14:05 > > Ive posted this before - dont want it to sit here rotting. > If theres nothing glaringly wrong with it (Thomas/Patrick?) then Dave > please apply so i can start shooting other patches based on it. Looks good to me, see two minor comments below. > +static inline int > +tcf_defact_init(struct rtattr *rta, struct rtattr *est, > + struct tc_action *a, int ovr, int bind) > +{ > + struct rtattr *tb[TCA_DEF_MAX]; > + struct tc_defact *parm; > + struct tcf_defact *p; > + void *defdata; > + u32 datalen = 0; > + int ret = 0; > + > + if (rta == NULL || rtattr_parse_nested(tb, TCA_DEF_MAX, rta) < 0) > + return -EINVAL; > + > + if (tb[TCA_DEF_PARMS - 1] == NULL) > + return -EINVAL; > + parm = RTA_DATA(tb[TCA_DEF_PARMS - 1]); > + defdata = RTA_DATA(tb[TCA_DEF_DATA - 1]); Maybe do a size sanity check here for TCA_DEF_PARMS? > + if (defdata == NULL) > + return -EINVAL; > + > + datalen = RTA_PAYLOAD(tb[TCA_DEF_DATA - 1]); > --- /dev/null 2004-01-29 13:33:32.773091056 -0500 > +++ 2611-rc3+bk3/include/net/tc_act/tc_defact.h 2005-02-06 15:03:05.000000000 -0500 > @@ -0,0 +1,13 @@ > +#ifndef __NET_TC_DEF_H > +#define __NET_TC_DEF_H > + > +#include > + > +struct tcf_defact > +{ > + tca_gen(defact); > + u32 datalen; > + void *defdata; > +}; > + > +#endif > --- /dev/null 2004-01-29 13:33:32.773091056 -0500 > +++ 2611-rc3+bk3/include/linux/tc_act/tc_defact.h 2005-02-06 16:47:20.039209336 -0500 > @@ -0,0 +1,21 @@ > +#ifndef __LINUX_TC_DEF_H > +#define __LINUX_TC_DEF_H > + > +#include > + > +struct tc_defact > +{ > + tc_gen; > +}; tcf_defact, tc_defact, .. quite easy to get this wrong. Maybe it would a good idea to rename tcf_defact to tcf_defact_parm? From kaber@trash.net Sun Mar 20 11:58:44 2005 Received: with ECARTIS (v1.0.0; list netdev); Sun, 20 Mar 2005 11:58:50 -0800 (PST) Received: from kaber.coreworks.de ([62.206.217.67]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j2KJwg96026526 for ; Sun, 20 Mar 2005 11:58:42 -0800 Received: from localhost ([127.0.0.1]) by kaber.coreworks.de with esmtp (Exim 4.50) id 1DD6ZD-0001G9-1m; Sun, 20 Mar 2005 20:58:31 +0100 Message-ID: <423DD5E6.2020708@trash.net> Date: Sun, 20 Mar 2005 20:58:30 +0100 From: Patrick McHardy User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.7.5) Gecko/20050106 Debian/1.7.5-1 X-Accept-Language: en MIME-Version: 1.0 To: hadi@znyx.com CC: "David S. Miller" , netdev@oss.sgi.com, Thomas Graf Subject: Re: patch: introduce simple actions References: <1111345551.1095.82.camel@jzny.localdomain> <423DCD8C.6030100@trash.net> <1111347345.1094.98.camel@jzny.localdomain> In-Reply-To: <1111347345.1094.98.camel@jzny.localdomain> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV 0.83/774/Fri Mar 18 17:04:06 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 404 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: kaber@trash.net Precedence: bulk X-list: netdev Content-Length: 1104 Lines: 25 Jamal Hadi Salim wrote: > On Sun, 2005-03-20 at 14:22, Patrick McHardy wrote: > >>One of the next things I wanted to do in this area was >>moving all the large inline functions to act_generic.c, >>so if possible I would prefer not to put these in a header >>file. > > These are small functions. Take a look at the simple action i attached. > If you can give me the same functionality and still move things > de_inlined to act_generic.c i would be fine with it. The functions are not inlined anyway, so the question is whether any #define magic is done as with pkt_act.h, otherwise there is no reason to have them in a header file. Looking at your patch, it seems tc_defact.h uses the redefined pkt_act.h functions, so it does need to be in a header file, but frankly, I find this horrible. The patch doesn't conflict with cleanup of pkt_act.h, but it means more work when doing it, so I think this is what should be done first. Especially since this is only an example, not useful for users, but it will be possibly used to create more actions that also need to be changed afterwards. Regards Patrick From hadi@cyberus.ca Sun Mar 20 12:10:37 2005 Received: with ECARTIS (v1.0.0; list netdev); Sun, 20 Mar 2005 12:10:42 -0800 (PST) Received: from mx01.cybersurf.com (mx01.cybersurf.com [209.197.145.104]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j2KKAbvP027935 for ; Sun, 20 Mar 2005 12:10:37 -0800 Received: from mail.cyberus.ca ([209.197.145.21]) by mx01.cybersurf.com with esmtp (Exim 4.30) id 1DD6ko-0006LF-5j for netdev@oss.sgi.com; Sun, 20 Mar 2005 13:10:30 -0700 Received: from [24.103.99.32] (helo=[10.0.0.9]) by mail.cyberus.ca with esmtp (Exim 4.20) id 1DD6kp-0000OD-2T; Sun, 20 Mar 2005 15:10:31 -0500 Subject: Re: patch: introduce simple actions From: jamal Reply-To: hadi@cyberus.ca To: Thomas Graf Cc: "David S. Miller" , netdev@oss.sgi.com, Patrick McHardy In-Reply-To: <20050320194408.GU3086@postel.suug.ch> References: <1111345551.1095.82.camel@jzny.localdomain> <20050320194408.GU3086@postel.suug.ch> Content-Type: text/plain Organization: jamalopolous Message-Id: <1111349426.1092.128.camel@jzny.localdomain> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.2.2 Date: 20 Mar 2005 15:10:27 -0500 Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV 0.83/774/Fri Mar 18 17:04:06 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 405 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: hadi@cyberus.ca Precedence: bulk X-list: netdev Content-Length: 1255 Lines: 46 On Sun, 2005-03-20 at 14:44, Thomas Graf wrote: > * Jamal Hadi Salim <1111345551.1095.82.camel@jzny.localdomain> 2005-03-20 14:05 > > +static inline int > > +tcf_defact_init(struct rtattr *rta, struct rtattr *est, > > + struct tc_action *a, int ovr, int bind) > > +{ > > + struct rtattr *tb[TCA_DEF_MAX]; > > + struct tc_defact *parm; > > + struct tcf_defact *p; > > + void *defdata; > > + u32 datalen = 0; > > + int ret = 0; > > + > > + if (rta == NULL || rtattr_parse_nested(tb, TCA_DEF_MAX, rta) < 0) > > + return -EINVAL; > > + > > + if (tb[TCA_DEF_PARMS - 1] == NULL) > > + return -EINVAL; > > + parm = RTA_DATA(tb[TCA_DEF_PARMS - 1]); > > + defdata = RTA_DATA(tb[TCA_DEF_DATA - 1]); > > Maybe do a size sanity check here for TCA_DEF_PARMS? > Will do. > > + > > +struct tc_defact > > +{ > > + tc_gen; > > +}; > > tcf_defact, tc_defact, .. quite easy to get this wrong. Maybe > it would a good idea to rename tcf_defact to tcf_defact_parm? > sigh. another LinuxWay(tm). Unfortunately this is all over the net/sched code to imply something thats user specific vs kernel specific. If you feel strongly about it i will change it - otherwise maybe we can leave it till some day some brave person will clean up the whole thing? cheers, jamal From leonid.grossman@neterion.com Sun Mar 20 12:15:07 2005 Received: with ECARTIS (v1.0.0; list netdev); Sun, 20 Mar 2005 12:15:11 -0800 (PST) Received: from ns1.s2io.com (ns1.s2io.com [142.46.200.198]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j2KKF6YJ028765 for ; Sun, 20 Mar 2005 12:15:06 -0800 Received: from guinness.s2io.com (sentry.s2io.com [142.46.200.199]) by ns1.s2io.com (8.12.10/8.12.10) with ESMTP id j2KKDvuN025395; Sun, 20 Mar 2005 15:13:57 -0500 (EST) Received: from lgt40 ([10.16.16.166]) by guinness.s2io.com (8.12.6/8.12.6) with ESMTP id j2KKDtDD000198; Sun, 20 Mar 2005 15:13:56 -0500 (EST) Message-Id: <200503202013.j2KKDtDD000198@guinness.s2io.com> From: "Leonid Grossman" To: Cc: "'Andi Kleen'" , , Subject: RE: [ANNOUNCE] Experimental Driver for Neterion/S2io 10GbE Adapters Date: Sun, 20 Mar 2005 12:13:55 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook, Build 11.0.5510 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1409 In-Reply-To: <1111326010.1093.32.camel@jzny.localdomain> Thread-Index: AcUtUm9uNjfD6maYRGamOrxZU6qBHgAKQ7mg X-Scanned-By: MIMEDefang 2.34 X-Virus-Scanned: ClamAV 0.83/774/Fri Mar 18 17:04:06 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 406 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: leonid.grossman@neterion.com Precedence: bulk X-list: netdev Content-Length: 5357 Lines: 114 Hi Jamal, You are right on target, it's all about finding the best driver support model - for the end users, not for a Neterion developer or even for a Linux hacker. At the moment, "s2io" driver is supported in exactly the way you suggest; the model works well but we think it's possible to do better - again, for the end user sake. If we could write a driver, put it in the kernel and let it "heal itself", then I'd agree that the current model would have been the best. We'd have been happy to stay with it, rather than to go through with a considerable extra effort - preserving the status quo is always easier. I'd argue that the vast majority of a 10GbE NICs will be initially developed by a smaller company like Neterion, shipped by large server OEMs and supported (from end-user prospective) by these two entities, as well as by Linux community and major Linux distributors. In our experience, even early adopters of 10GbE adapters in Linux space rarely attempt to fix hardware-dependent bugs themselves - they ask for support from one of the three entities above (a NIC vendor, a server vendor an a Linux distributor), with a lion share of urgent level 2 and level 3 issues ending up with a NIC vendor. As 10GbE adoption accelerates, I expect this trend will accelerate as well - I wish we could shift the support burden to someone else, but the chances of that to happen are getting slimmer over time :-). BTW this is precisely the reason the NIC vendors favor HAL model. Software teams are about the same size, no matter whether it's a big or small company - and no NIC vendor likes spending 30% of their resources on one (out of 10) device drivers. So, at least from what we see in our space, open source is a great thing but it doesn't make driver support (at least for the low level NIC code) fundamentally different from other Operating Systems, at least not for a foreseeable future. IMHO, nor should it - ability to have source and fix hw-dependent bugs is great, but I'd argue that much bigger value of the open source model is in the (more strategic) ability to timely identify and fix existing networking bottlenecks that are common to most/all NIC drivers. An example - at present, there are no Linux UDP TSO APIs. We see a customer need for it and we have the ASIC support as well; from an end user (and about everybody else) prospective it would be great to add these APIs by people who know Linux best. Whether the hw-dependent part of the UDP TSO is done by a hacker or it is an existing and working HAL code from a Neterion developer, is not that important to the end user - though the latter will be a more likely and more efficient way to go. BTW all arguments above make sense only if a high-level part of the driver is very much "Linux-like" - we are obviously motivated to make the high level code suitable to the changes by the community, since this is where the value for the end user is. We could talk about some other points that you brought up (for example, the statement about other OSes not changing is applicable only to a small subset of "legacy" OSes - I suspect the rest of them will be changing NIC APIs rather fast and HAL is actually a good way to deal with the change across the board), but as you pointed out the support model is the key here... Cheers, Leonid > -----Original Message----- > From: netdev-bounce@oss.sgi.com [mailto:netdev-bounce@oss.sgi.com] On > Behalf Of jamal > Sent: Sunday, March 20, 2005 5:40 AM > To: Leonid Grossman > Cc: 'Andi Kleen'; netdev@oss.sgi.com; leonid@neterion.com; > jgarzik@pobox.com > Subject: RE: [ANNOUNCE] Experimental Driver for Neterion/S2io 10GbE > Adapters > > On Sat, 2005-03-19 at 17:19, Leonid Grossman wrote: > > > Sure. I was not asking for a promise to merge the code, only for a rough > > consensus that a HAL-based approach by itself is not a showstopper. > > Without such a consensus, it doesn't matter if we address other issues, > > right? > > Typically theres only one motivation for HALs - maintain the same code > base for 20 OSes. Makes it easier for a small company (not sure if yours > fits that category) to maintain. It doesnt matter how differently you > position or spin it (no offense intended), that is the main if not only > motivation. > > OTOH, you shift the burden of the extra maintainance work to the people > on the Linux side who know may have to understand what your layer does. > This is why people hate it. > I dont think it is sufficient to say your company will be updating the > driver: > - Years from now your company may not be around anymore but your > hardware may still be. Who is going to fix the bugs then? > - APIs, mechanisms etc change on Linux as well. You become a bottleneck > if nobody understands your HAL because they have to wait for you to make > the changes. > Traditionaly whoever makes the changes on dirver schemes ensures all > drivers are updated. Think positively that this is now offloaded from > you. > > My suggestion: have a dedicated resource just for Linux - it is big > enough to justify; maintain HAL for other OSes that will never change, I > bet you whatever works for NDIS probably will continue to work for > vxworks for the next 10 years - not much innovation going on there;-> or > you could claim (bah!) theres stability on those OSes. > > cheers, > jamal > > From hadi@znyx.com Sun Mar 20 12:17:38 2005 Received: with ECARTIS (v1.0.0; list netdev); Sun, 20 Mar 2005 12:17:44 -0800 (PST) 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 j2KKHcTY029470 for ; Sun, 20 Mar 2005 12:17:38 -0800 Received: from localhost ([208.2.156.2]) by lotus.znyx.com (Lotus Domino Release 5.0.11) with ESMTP id 2005032012184401:18041 ; Sun, 20 Mar 2005 12:18:44 -0800 Subject: Re: patch: introduce simple actions From: Jamal Hadi Salim Reply-To: hadi@znyx.com To: Patrick McHardy Cc: "David S. Miller" , netdev@oss.sgi.com, Thomas Graf In-Reply-To: <423DD5E6.2020708@trash.net> References: <1111345551.1095.82.camel@jzny.localdomain> <423DCD8C.6030100@trash.net> <1111347345.1094.98.camel@jzny.localdomain> <423DD5E6.2020708@trash.net> Organization: ZNYX Networks Message-Id: <1111349853.1093.136.camel@jzny.localdomain> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.2.2 Date: 20 Mar 2005 15:17:34 -0500 X-MIMETrack: Itemize by SMTP Server on Lotus/Znyx(Release 5.0.11 |July 24, 2002) at 03/20/2005 12:18:44 PM, Serialize by Router on Lotus/Znyx(Release 5.0.11 |July 24, 2002) at 03/20/2005 12:18:46 PM, Serialize complete at 03/20/2005 12:18:46 PM Content-Transfer-Encoding: 7bit Content-Type: text/plain X-Virus-Scanned: ClamAV 0.83/774/Fri Mar 18 17:04:06 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 407 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: hadi@znyx.com Precedence: bulk X-list: netdev Content-Length: 1971 Lines: 41 On Sun, 2005-03-20 at 14:58, Patrick McHardy wrote: > Jamal Hadi Salim wrote: > > On Sun, 2005-03-20 at 14:22, Patrick McHardy wrote: > > > >>One of the next things I wanted to do in this area was > >>moving all the large inline functions to act_generic.c, > >>so if possible I would prefer not to put these in a header > >>file. > > > > These are small functions. Take a look at the simple action i attached. > > If you can give me the same functionality and still move things > > de_inlined to act_generic.c i would be fine with it. > > The functions are not inlined anyway, so the question is whether any > #define magic is done as with pkt_act.h, otherwise there is no reason > to have them in a header file. Looking at your patch, it seems > tc_defact.h uses the redefined pkt_act.h functions, so it does need to > be in a header file, but frankly, I find this horrible. The patch > doesn't conflict with cleanup of pkt_act.h, but it means more work when > doing it, so I think this is what should be done first. Especially > since this is only an example, not useful for users, but it will be > possibly used to create more actions that also need to be changed > afterwards. Unfortunately code "augmentation"( as opposed to inheritance - cant think of a better word) is much easier to do this way. The benefit of it is the user gets a very simple programming interface - which is the main reason this was written to begin with. The standard interface exists, and more versed people or someone wanting to write something complex can go that path. At some point i would like to document all this stuff. How about this: I submit this patch (with Thomas cleanup) and the simple action. I will hold onto the 4 other actions i already have some of them complete until you get around to moving things around and then i will redo them to conform. This gets it off my back and we dont have any miscommunication of what you are trying to do. sounds fair? cheers, jamal From tgraf@suug.ch Sun Mar 20 12:18:18 2005 Received: with ECARTIS (v1.0.0; list netdev); Sun, 20 Mar 2005 12:18:22 -0800 (PST) Received: from b.mx.projectdream.org (eth0-0.arisu.projectdream.org [194.158.4.191]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j2KKIHgD029786 for ; Sun, 20 Mar 2005 12:18:17 -0800 Received: from postel.suug.ch (postel.suug.ch [195.134.158.23]) (using TLSv1 with cipher EDH-RSA-DES-CBC3-SHA (168/168 bits)) (No client certificate requested) by b.mx.projectdream.org (Postfix) with ESMTP id 6BCC782; Sun, 20 Mar 2005 21:17:54 +0100 (CET) Received: by postel.suug.ch (Postfix, from userid 10001) id B12EB1C0EA; Sun, 20 Mar 2005 21:18:36 +0100 (CET) Date: Sun, 20 Mar 2005 21:18:36 +0100 From: Thomas Graf To: jamal Cc: "David S. Miller" , netdev@oss.sgi.com, Patrick McHardy Subject: Re: patch: introduce simple actions Message-ID: <20050320201836.GW3086@postel.suug.ch> References: <1111345551.1095.82.camel@jzny.localdomain> <20050320194408.GU3086@postel.suug.ch> <1111349426.1092.128.camel@jzny.localdomain> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1111349426.1092.128.camel@jzny.localdomain> X-Virus-Scanned: ClamAV 0.83/774/Fri Mar 18 17:04:06 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 408 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: tgraf@suug.ch Precedence: bulk X-list: netdev Content-Length: 685 Lines: 18 > > > + > > > +struct tc_defact > > > +{ > > > + tc_gen; > > > +}; > > > > tcf_defact, tc_defact, .. quite easy to get this wrong. Maybe > > it would a good idea to rename tcf_defact to tcf_defact_parm? > > > > sigh. another LinuxWay(tm). Unfortunately this is all over the net/sched > code to imply something thats user specific vs kernel specific. If > you feel strongly about it i will change it - otherwise maybe we can > leave it till some day some brave person will clean up the whole thing? Yes I know and I don't feel that strong about it. I just tend to dislike it a tiny bit, I do like the struct rta_kern style better. Let's wait for the brave knight to appear someday. From tgraf@suug.ch Sun Mar 20 12:31:04 2005 Received: with ECARTIS (v1.0.0; list netdev); Sun, 20 Mar 2005 12:31:09 -0800 (PST) Received: from b.mx.projectdream.org (eth0-0.arisu.projectdream.org [194.158.4.191]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j2KKV444002507 for ; Sun, 20 Mar 2005 12:31:04 -0800 Received: from postel.suug.ch (postel.suug.ch [195.134.158.23]) (using TLSv1 with cipher EDH-RSA-DES-CBC3-SHA (168/168 bits)) (No client certificate requested) by b.mx.projectdream.org (Postfix) with ESMTP id 637CD82; Sun, 20 Mar 2005 21:30:40 +0100 (CET) Received: by postel.suug.ch (Postfix, from userid 10001) id 665451C0EA; Sun, 20 Mar 2005 21:31:22 +0100 (CET) Date: Sun, 20 Mar 2005 21:31:22 +0100 From: Thomas Graf To: Jamal Hadi Salim Cc: Patrick McHardy , "David S. Miller" , netdev@oss.sgi.com Subject: Re: patch: introduce simple actions Message-ID: <20050320203122.GX3086@postel.suug.ch> References: <1111345551.1095.82.camel@jzny.localdomain> <423DCD8C.6030100@trash.net> <1111347345.1094.98.camel@jzny.localdomain> <423DD5E6.2020708@trash.net> <1111349853.1093.136.camel@jzny.localdomain> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1111349853.1093.136.camel@jzny.localdomain> X-Virus-Scanned: ClamAV 0.83/774/Fri Mar 18 17:04:06 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 409 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: tgraf@suug.ch Precedence: bulk X-list: netdev Content-Length: 540 Lines: 9 * Jamal Hadi Salim <1111349853.1093.136.camel@jzny.localdomain> 2005-03-20 15:17 > reason this was written to begin with. The standard interface exists, > and more versed people or someone wanting to write something complex can > go that path. At some point i would like to document all this stuff. Yes, we do have to find some way to document all this in a proper way. Maybe we can write some _really_ technical reference brought down to the bare minimum required and extend the LARTC howto with new examples to cover the practical side. From herbert@gondor.apana.org.au Sun Mar 20 12:39:33 2005 Received: with ECARTIS (v1.0.0; list netdev); Sun, 20 Mar 2005 12:39:40 -0800 (PST) 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 j2KKdV3V003515 for ; Sun, 20 Mar 2005 12:39:32 -0800 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 1DD7CX-000100-00; Mon, 21 Mar 2005 07:39:09 +1100 Received: from herbert by gondolin.me.apana.org.au with local (Exim 3.36 #1 (Debian)) id 1DD7C5-0007ZI-00; Mon, 21 Mar 2005 07:38:41 +1100 Date: Mon, 21 Mar 2005 07:38:41 +1100 To: Patrick McHardy Cc: "David S. Miller" , netdev@oss.sgi.com Subject: Re: IPsec xfrm resolution Message-ID: <20050320203841.GA29078@gondor.apana.org.au> References: <420B9DF1.3020704@trash.net> <20050210202810.GA1609@gondor.apana.org.au> <42144C3F.2060501@trash.net> <20050217091137.GA9476@gondor.apana.org.au> <42152841.5000707@trash.net> <20050218100854.GA19427@gondor.apana.org.au> <4216D6B4.5070901@trash.net> <20050219092314.GA8153@gondor.apana.org.au> <20050317203231.1b649f60.davem@davemloft.net> <423D9BFB.2090309@trash.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <423D9BFB.2090309@trash.net> User-Agent: Mutt/1.5.6+20040907i From: Herbert Xu X-Virus-Scanned: ClamAV 0.83/774/Fri Mar 18 17:04:06 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 410 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: herbert@gondor.apana.org.au Precedence: bulk X-list: netdev Content-Length: 529 Lines: 15 On Sun, Mar 20, 2005 at 04:51:23PM +0100, Patrick McHardy wrote: > > Not yet, I've put it on hold after clashing with Herbert's MTU work. > I'll have a few free days this week where I will continue to work > on this. I've completed the first stage of the MTU work so please feel free to send patches through. Thanks, -- Visit Openswan at http://www.openswan.org/ Email: Herbert Xu ~{PmV>HI~} Home Page: http://gondor.apana.org.au/~herbert/ PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt From hadi@cyberus.ca Sun Mar 20 12:42:02 2005 Received: with ECARTIS (v1.0.0; list netdev); Sun, 20 Mar 2005 12:42:06 -0800 (PST) Received: from mx02.cybersurf.com (mx02.cybersurf.com [209.197.145.105]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j2KKg2SL004177 for ; Sun, 20 Mar 2005 12:42:02 -0800 Received: from mail.cyberus.ca ([209.197.145.21]) by mx02.cybersurf.com with esmtp (Exim 4.30) id 1DD7FH-0002uf-UE for netdev@oss.sgi.com; Sun, 20 Mar 2005 15:41:59 -0500 Received: from [24.103.99.32] (helo=[10.0.0.9]) by mail.cyberus.ca with esmtp (Exim 4.20) id 1DD7FG-0003NE-AV; Sun, 20 Mar 2005 15:41:58 -0500 Subject: Re: patch: introduce simple actions From: jamal Reply-To: hadi@cyberus.ca To: Thomas Graf Cc: Patrick McHardy , "David S. Miller" , netdev@oss.sgi.com In-Reply-To: <20050320203122.GX3086@postel.suug.ch> References: <1111345551.1095.82.camel@jzny.localdomain> <423DCD8C.6030100@trash.net> <1111347345.1094.98.camel@jzny.localdomain> <423DD5E6.2020708@trash.net> <1111349853.1093.136.camel@jzny.localdomain> <20050320203122.GX3086@postel.suug.ch> Content-Type: text/plain Organization: jamalopolous Message-Id: <1111351313.1092.141.camel@jzny.localdomain> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.2.2 Date: 20 Mar 2005 15:41:53 -0500 Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV 0.83/774/Fri Mar 18 17:04:06 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 411 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: hadi@cyberus.ca Precedence: bulk X-list: netdev Content-Length: 983 Lines: 24 On Sun, 2005-03-20 at 15:31, Thomas Graf wrote: > * Jamal Hadi Salim <1111349853.1093.136.camel@jzny.localdomain> 2005-03-20 15:17 > > reason this was written to begin with. The standard interface exists, > > and more versed people or someone wanting to write something complex can > > go that path. At some point i would like to document all this stuff. > > Yes, we do have to find some way to document all this in a proper way. > Maybe we can write some _really_ technical reference brought down to > the bare minimum required and extend the LARTC howto with new examples > to cover the practical side. Agreed - this as well as the ematch etc. not sure if the current howto will be the proper place - but somewhere close to it. There has been a lot of very interesting new things going in and there seems to be stability now - Lets talk offline. cheers, jamal PS:- stupid mailer sometimes sticks my work email as posting address. None of this is not work related at all ;-> From akpm@osdl.org Sun Mar 20 16:37:51 2005 Received: with ECARTIS (v1.0.0; list netdev); Sun, 20 Mar 2005 16:37:56 -0800 (PST) Received: from smtp.osdl.org (fire.osdl.org [65.172.181.4]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j2L0boX0016671 for ; Sun, 20 Mar 2005 16:37:50 -0800 Received: from shell0.pdx.osdl.net (fw.osdl.org [65.172.181.6]) by smtp.osdl.org (8.12.8/8.12.8) with ESMTP id j2L0beqi028086 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO); Sun, 20 Mar 2005 16:37:41 -0800 Received: from bix (shell0.pdx.osdl.net [10.9.0.31]) by shell0.pdx.osdl.net (8.13.1/8.11.6) with SMTP id j2L0be4K001958; Sun, 20 Mar 2005 16:37:40 -0800 Date: Sun, 20 Mar 2005 16:37:25 -0800 From: Andrew Morton To: netdev@oss.sgi.com Cc: buakaw@buakaw.homelinux.net Subject: Fw: dst cache overflow messages Message-Id: <20050320163725.4ec79214.akpm@osdl.org> X-Mailer: Sylpheed version 0.9.7 (GTK+ 1.2.10; i386-redhat-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Received-SPF: pass (domain of akpm@osdl.org designates 65.172.181.6 as permitted sender) X-MIMEDefang-Filter: osdl$Revision: 1.105 $ X-Scanned-By: MIMEDefang 2.36 X-Virus-Scanned: ClamAV 0.83/774/Fri Mar 18 17:04:06 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 412 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: akpm@osdl.org Precedence: bulk X-list: netdev Content-Length: 840 Lines: 27 Begin forwarded message: Date: Sun, 20 Mar 2005 22:51:08 +0200 (EET) From: buakaw@buakaw.homelinux.net To: linux-kernel@vger.kernel.org Subject: the system become very laggy. i use kernel 2.6.10/2.6.11.3 on p4 2.8, msi915p, 3 x 3com905 boomerang. and the cpu usage normally be about 12% and after something happens it boost to 100% and it is used mostly by ksoftirqd/0, and a little bit by migration/0 and event/0. and in syslog i found thies lines Mar 20 22:21:09 buakaw kernel: printk: 5543 messages suppressed. Mar 20 22:21:09 buakaw kernel: dst cache overflow what can cause this? - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/ From boian@bonev.com Sun Mar 20 18:05:28 2005 Received: with ECARTIS (v1.0.0; list netdev); Sun, 20 Mar 2005 18:05:41 -0800 (PST) Received: from mx.cisbg.com (ns.cisbg.com [195.69.109.188]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j2L25RpQ022765 for ; Sun, 20 Mar 2005 18:05:28 -0800 Received: from orange.bonev.com (orange.bonev.com [195.69.108.254]) by mx.cisbg.com (8.13.1/8.13.1) with SMTP id j2L25QVl026097 for ; Mon, 21 Mar 2005 04:05:26 +0200 Received: (qmail 20421 invoked by uid 99); 21 Mar 2005 02:05:26 -0000 Message-ID: <20050321020526.20420.qmail@orange.bonev.com> Mime-Version: 1.0 Received: from firewall.cisbg.com (195.69.108.252) by mail.bonev.com with HTTP; Mon, 21 Mar 2005 04:05:26 +0200 From: Boian Bonev Cc: buakaw@buakaw.homelinux.net To: Andrew Morton , netdev@oss.sgi.com Subject: Re: dst cache overflow messages Date: Mon, 21 Mar 2005 04:05:26 +0200 Content-Type: multipart/mixed; boundary="=_1_1111370726_20417" Content-Transfer-Encoding: 8bit X-BIS.BG-Antispam-Check: Yes X-Scanned-By: MIMEDefang 2.48 on 195.69.109.187 X-Virus-Scanned: ClamAV 0.83/774/Fri Mar 18 17:04:06 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 413 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: boian@bonev.com Precedence: bulk X-list: netdev Content-Length: 1600 Lines: 55 This is a MIME-formatted message. If you see this text it means that your E-mail software does not support MIME-formatted messages. --=_1_1111370726_20417 Content-Type: text/plain; charset=windows-1251 Content-Transfer-Encoding: quoted-printable hi, this happens very rare. it is mostly seen on systems with full bgp table = combined with a massive scan on diverse networks caused by worms/troyans/= etc. you can tuneup your systems' max route cache size by echo sane-big-value > /proc/sys/net/ipv4/route/max_size if you happen to get a permanent attack, you may also need to twiddle wit= h garbage collection values in /proc/sys/net/ipv4/route/gc_* to ensure th= at the route cache will not grow more than the max value for the period o= f gc. b. > ----- Original Message ---- > From: Andrew Morton > To: netdev@oss.sgi.com > Sent: Sun, 20 Mar 2005 16:37:25 -0800 > Subject: Fw: dst cache overflow messages > > > > Begin forwarded message: > > Date: Sun, 20 Mar 2005 22:51:08 +0200 (EET) > From: buakaw@buakaw.homelinux.net > To: linux-kernel@vger.kernel.org > Subject: > > > the system become very laggy. > i use kernel 2.6.10/2.6.11.3 on p4 2.8, msi915p, 3 x 3com905 boomerang.= > and the cpu usage normally be about 12% and after something happens it > boost to 100% and it is used mostly by ksoftirqd/0, and a little bit by= > migration/0 and event/0. and in syslog i found thies lines > > Mar 20 22:21:09 buakaw kernel: printk: 5543 messages suppressed. > Mar 20 22:21:09 buakaw kernel: dst cache overflow > > what can cause this? --=_1_1111370726_20417-- From akpm@osdl.org Sun Mar 20 19:17:47 2005 Received: with ECARTIS (v1.0.0; list netdev); Sun, 20 Mar 2005 19:17:54 -0800 (PST) Received: from smtp.osdl.org (fire.osdl.org [65.172.181.4]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j2L3HlL5026777 for ; Sun, 20 Mar 2005 19:17:47 -0800 Received: from shell0.pdx.osdl.net (fw.osdl.org [65.172.181.6]) by smtp.osdl.org (8.12.8/8.12.8) with ESMTP id j2L3Hdqi005806 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO); Sun, 20 Mar 2005 19:17:40 -0800 Received: from bix (shell0.pdx.osdl.net [10.9.0.31]) by shell0.pdx.osdl.net (8.13.1/8.11.6) with SMTP id j2L3Hdlp005648; Sun, 20 Mar 2005 19:17:39 -0800 Date: Sun, 20 Mar 2005 19:17:24 -0800 From: Andrew Morton To: Stephen Hemminger Cc: davem@davemloft.net, netdev@oss.sgi.com Subject: Re: [PATCH 3/5] TCP Westwood+ support Message-Id: <20050320191724.72089c5a.akpm@osdl.org> In-Reply-To: <20050318162412.189ccf9c@dxpl.pdx.osdl.net> References: <20050318162412.189ccf9c@dxpl.pdx.osdl.net> X-Mailer: Sylpheed version 0.9.7 (GTK+ 1.2.10; i386-redhat-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Received-SPF: pass (domain of akpm@osdl.org designates 65.172.181.6 as permitted sender) X-MIMEDefang-Filter: osdl$Revision: 1.105 $ X-Scanned-By: MIMEDefang 2.36 X-Virus-Scanned: ClamAV 0.83/774/Fri Mar 18 17:04:06 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 414 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: akpm@osdl.org Precedence: bulk X-list: netdev Content-Length: 466 Lines: 15 Stephen Hemminger wrote: > > Add TCP Westwood+ support back in as a separate pluggable algorithm. > The mechanism and policy is unchanged from existing code. net/built-in.o(.text+0x4b052): In function `tcp_westwood_info': net/ipv4/tcp_westwood.c:307: undefined reference to `tcpdiag_put' linux:/usr/src/25> grep WESTW .config CONFIG_TCP_CONG_WESTWOOD=y linux:/usr/src/25> grep TCPDIAG .config CONFIG_IP_TCPDIAG=m CONFIG_IP_TCPDIAG_IPV6=y From davem@davemloft.net Sun Mar 20 20:05:06 2005 Received: with ECARTIS (v1.0.0; list netdev); Sun, 20 Mar 2005 20:05:13 -0800 (PST) Received: from cheetah.davemloft.net (mail@dsl027-180-174.sfo1.dsl.speakeasy.net [216.27.180.174]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j2L455Mm031151 for ; Sun, 20 Mar 2005 20:05:06 -0800 Received: from localhost ([127.0.0.1] helo=cheetah.davemloft.net ident=davem) by cheetah.davemloft.net with smtp (Exim 3.36 #1 (Debian)) id 1DDE8y-0002vl-00; Sun, 20 Mar 2005 20:03:56 -0800 Date: Sun, 20 Mar 2005 20:03:56 -0800 From: "David S. Miller" To: yoshfuji@linux-ipv6.org Cc: miika@iki.fi, gurtov@cs.helsinki.fi, netdev@oss.sgi.com, infrahip@hiit.fi Subject: Re: [Infrahip] [PATCH] Host Identity Protocol Message-Id: <20050320200356.5f8fa583.davem@davemloft.net> In-Reply-To: <20050321.024241.67451836.yoshfuji@linux-ipv6.org> References: <42369919.9010203@cs.helsinki.fi> <20050321.024241.67451836.yoshfuji@linux-ipv6.org> X-Mailer: Sylpheed version 1.0.1 (GTK+ 1.2.10; sparc-unknown-linux-gnu) X-Face: "_;p5u5aPsO,_Vsx"^v-pEq09'CU4&Dc1$fQExov$62l60cgCc%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 X-Virus-Scanned: ClamAV 0.83/774/Fri Mar 18 17:04:06 2005 on oss.sgi.com X-Virus-Status: Clean Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by oss.sgi.com id j2L455Mm031151 X-archive-position: 415 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: davem@davemloft.net Precedence: bulk X-list: netdev Content-Length: 366 Lines: 10 On Mon, 21 Mar 2005 02:42:41 +0900 (JST) YOSHIFUJI Hideaki / $B5HF#1QL@(B wrote: > However, all signaling should be handled in userspace as we (will) do for MIP6. Yes, I've been telling them similarly in a private email discussion. I'm very glad someone else says this too, so I don't appear as the only person who feels this way :-) From akpm@osdl.org Sun Mar 20 20:54:07 2005 Received: with ECARTIS (v1.0.0; list netdev); Sun, 20 Mar 2005 20:54:13 -0800 (PST) Received: from smtp.osdl.org (fire.osdl.org [65.172.181.4]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j2L4s75E007792 for ; Sun, 20 Mar 2005 20:54:07 -0800 Received: from shell0.pdx.osdl.net (fw.osdl.org [65.172.181.6]) by smtp.osdl.org (8.12.8/8.12.8) with ESMTP id j2L4s0qi012076 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO); Sun, 20 Mar 2005 20:54:01 -0800 Received: from bix (shell0.pdx.osdl.net [10.9.0.31]) by shell0.pdx.osdl.net (8.13.1/8.11.6) with SMTP id j2L4s0Dw007992; Sun, 20 Mar 2005 20:54:00 -0800 Date: Sun, 20 Mar 2005 20:53:45 -0800 From: Andrew Morton To: shemminger@osdl.org, davem@davemloft.net, netdev@oss.sgi.com Subject: Re: [PATCH 3/5] TCP Westwood+ support Message-Id: <20050320205345.13930cd8.akpm@osdl.org> In-Reply-To: <20050320191724.72089c5a.akpm@osdl.org> References: <20050318162412.189ccf9c@dxpl.pdx.osdl.net> <20050320191724.72089c5a.akpm@osdl.org> X-Mailer: Sylpheed version 0.9.7 (GTK+ 1.2.10; i386-redhat-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Received-SPF: pass (domain of akpm@osdl.org designates 65.172.181.6 as permitted sender) X-MIMEDefang-Filter: osdl$Revision: 1.105 $ X-Scanned-By: MIMEDefang 2.36 X-Virus-Scanned: ClamAV 0.83/774/Fri Mar 18 17:04:06 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 416 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: akpm@osdl.org Precedence: bulk X-list: netdev Content-Length: 793 Lines: 24 Andrew Morton wrote: > > Stephen Hemminger wrote: > > > > Add TCP Westwood+ support back in as a separate pluggable algorithm. > > The mechanism and policy is unchanged from existing code. > > net/built-in.o(.text+0x4b052): In function `tcp_westwood_info': > net/ipv4/tcp_westwood.c:307: undefined reference to `tcpdiag_put' I got bored of this, so I fixed it. --- 25-sparc64/net/ipv4/Kconfig~tcp-westwood-support-kconfig-fix 2005-03-20 20:51:18.000000000 -0800 +++ 25-sparc64-akpm/net/ipv4/Kconfig 2005-03-20 20:52:02.000000000 -0800 @@ -426,6 +426,7 @@ config TCP_CONG_BIC config TCP_CONG_WESTWOOD tristate "TCP Westwood+" + select IP_TCPDIAG default y ---help--- TCP Westwood+ is a sender-side only modification of the TCP Reno _ From mchan@broadcom.com Sun Mar 20 23:15:02 2005 Received: with ECARTIS (v1.0.0; list netdev); Sun, 20 Mar 2005 23:15:09 -0800 (PST) Received: from MMS1.broadcom.com (mms1.broadcom.com [216.31.210.17]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j2L7F2XK019243 for ; Sun, 20 Mar 2005 23:15:02 -0800 Received: from 10.10.64.121 by MMS1.broadcom.com with SMTP (Broadcom SMTP Relay (Email Firewall v6.1.0)); Sun, 20 Mar 2005 23:14:43 -0800 X-Server-Uuid: 146C3151-C1DE-4F71-9D02-C3BE503878DD Received: from mail-irva-8.broadcom.com ([10.10.64.221]) by mail-irva-1.broadcom.com (Post.Office MTA v3.5.3 release 223 ID# 0-72233U7200L2200S0V35) with ESMTP id com; Sun, 20 Mar 2005 23:14:43 -0800 Received: from mon-irva-10.broadcom.com (mon-irva-10.broadcom.com [10.10.64.171]) by mail-irva-8.broadcom.com (MOS 3.5.6-GR) with ESMTP id APJ67594; Sun, 20 Mar 2005 23:14:42 -0800 (PST) Received: from nt-irva-0741.brcm.ad.broadcom.com ( nt-irva-0741.brcm.ad.broadcom.com [10.8.194.54]) by mon-irva-10.broadcom.com (8.9.1/8.9.1) with ESMTP id XAA07098; Sun, 20 Mar 2005 23:14:42 -0800 (PST) X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Subject: [PATCH 2.6.11 1/8] tg3: add 5705_plus flag Date: Sun, 20 Mar 2005 23:14:42 -0800 Message-ID: X-MS-Has-Attach: yes Thread-Topic: [PATCH 2.6.11 1/8] tg3: add 5705_plus flag Thread-Index: AcUQenBthEVwCOEDSUG7grDnD7JTOgdadRIA From: "Michael Chan" To: "David S. Miller" cc: netdev@oss.sgi.com X-WSS-ID: 6E20ABE92982016944-01-01 Content-Type: multipart/mixed; boundary="----_=_NextPart_001_01C52DE5.A6E5415B" X-Virus-Scanned: ClamAV 0.83/774/Fri Mar 18 17:04:06 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 417 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: mchan@broadcom.com Precedence: bulk X-list: netdev Content-Length: 12673 Lines: 182 This is a multi-part message in MIME format. ------_=_NextPart_001_01C52DE5.A6E5415B Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Add a 5705_plus flag to indicate the device is 5705, 5750, or future = chips that all share the same basic architecture. This makes it easier to add support for future devices. Signed-off-by: Michael Chan ------_=_NextPart_001_01C52DE5.A6E5415B Content-Type: application/octet-stream; name=tg3-1.patch Content-Transfer-Encoding: base64 Content-Description: tg3-1.patch Content-Disposition: attachment; filename=tg3-1.patch ZGlmZiAtTnJ1IDEvZHJpdmVycy9uZXQvdGczLmMgMi9kcml2ZXJzL25ldC90ZzMuYwotLS0gMS9k cml2ZXJzL25ldC90ZzMuYwkyMDA1LTAzLTE0IDIyOjExOjIyLjAwMDAwMDAwMCAtMDgwMAorKysg Mi9kcml2ZXJzL25ldC90ZzMuYwkyMDA1LTAzLTE0IDIyOjA5OjUxLjAwMDAwMDAwMCAtMDgwMApA QCAtMTAzLDkgKzEwMyw3IEBACiAgKiByZXBsYWNlIHRoaW5ncyBsaWtlICclIGZvbycgd2l0aCAn JiAoZm9vIC0gMSknLgogICovCiAjZGVmaW5lIFRHM19SWF9SQ0JfUklOR19TSVpFKHRwKQlcCi0J KChHRVRfQVNJQ19SRVYodHAtPnBjaV9jaGlwX3Jldl9pZCkgPT0gQVNJQ19SRVZfNTcwNSB8fCBc Ci0JICBHRVRfQVNJQ19SRVYodHAtPnBjaV9jaGlwX3Jldl9pZCkgPT0gQVNJQ19SRVZfNTc1MCkg PyBcCi0JIDUxMiA6IDEwMjQpCisJKCh0cC0+dGczX2ZsYWdzMiAmIFRHM19GTEcyXzU3MDVfUExV UykgPyAgNTEyIDogMTAyNCkKIAogI2RlZmluZSBURzNfVFhfUklOR19TSVpFCQk1MTIKICNkZWZp bmUgVEczX0RFRl9UWF9SSU5HX1BFTkRJTkcJCShURzNfVFhfUklOR19TSVpFIC0gMSkKQEAgLTQ2 OCw4ICs0NjYsNyBAQAogCQkgICAgICAgMHgxZik7CiAJdHAtPnBjaV9jbG9ja19jdHJsID0gY2xv Y2tfY3RybDsKIAotCWlmIChHRVRfQVNJQ19SRVYodHAtPnBjaV9jaGlwX3Jldl9pZCkgPT0gQVNJ Q19SRVZfNTcwNSB8fAotCSAgICBHRVRfQVNJQ19SRVYodHAtPnBjaV9jaGlwX3Jldl9pZCkgPT0g QVNJQ19SRVZfNTc1MCkgeworCWlmICh0cC0+dGczX2ZsYWdzMiAmIFRHM19GTEcyXzU3MDVfUExV UykgewogCQlpZiAob3JpZ19jbG9ja19jdHJsICYgQ0xPQ0tfQ1RSTF82MjVfQ09SRSkgewogCQkJ dHczMl9mKFRHM1BDSV9DTE9DS19DVFJMLAogCQkJICAgICAgIGNsb2NrX2N0cmwgfCBDTE9DS19D VFJMXzYyNV9DT1JFKTsKQEAgLTEwOTMsOCArMTA5MCw3IEBACiAJCQkJICAgIENMT0NLX0NUUkxf VFhDTEtfRElTQUJMRSB8CiAJCQkJICAgIENMT0NLX0NUUkxfQUxUQ0xLKTsKIAkJCW5ld2JpdHMy ID0gbmV3Yml0czEgfCBDTE9DS19DVFJMXzQ0TUhaX0NPUkU7Ci0JCX0gZWxzZSBpZiAoR0VUX0FT SUNfUkVWKHRwLT5wY2lfY2hpcF9yZXZfaWQpID09IEFTSUNfUkVWXzU3MDUgfHwKLQkJCSAgIEdF VF9BU0lDX1JFVih0cC0+cGNpX2NoaXBfcmV2X2lkKSA9PSBBU0lDX1JFVl81NzUwKSB7CisJCX0g ZWxzZSBpZiAodHAtPnRnM19mbGFnczIgJiBURzNfRkxHMl81NzA1X1BMVVMpIHsKIAkJCW5ld2Jp dHMxID0gQ0xPQ0tfQ1RSTF82MjVfQ09SRTsKIAkJCW5ld2JpdHMyID0gbmV3Yml0czEgfCBDTE9D S19DVFJMX0FMVENMSzsKIAkJfSBlbHNlIHsKQEAgLTExMDgsOCArMTEwNCw3IEBACiAJCXR3MzJf ZihURzNQQ0lfQ0xPQ0tfQ1RSTCwgdHAtPnBjaV9jbG9ja19jdHJsIHwgbmV3Yml0czIpOwogCQl1 ZGVsYXkoNDApOwogCi0JCWlmIChHRVRfQVNJQ19SRVYodHAtPnBjaV9jaGlwX3Jldl9pZCkgIT0g QVNJQ19SRVZfNTcwNSAmJgotCQkgICAgR0VUX0FTSUNfUkVWKHRwLT5wY2lfY2hpcF9yZXZfaWQp ICE9IEFTSUNfUkVWXzU3NTApIHsKKwkJaWYgKCEodHAtPnRnM19mbGFnczIgJiBURzNfRkxHMl81 NzA1X1BMVVMpKSB7CiAJCQl1MzIgbmV3Yml0czM7CiAKIAkJCWlmIChHRVRfQVNJQ19SRVYodHAt PnBjaV9jaGlwX3Jldl9pZCkgPT0gQVNJQ19SRVZfNTcwMCB8fApAQCAtMjQ0OCw4ICsyNDQzLDcg QEAKIAkJICAgICAgKDYgPDwgVFhfTEVOR1RIU19JUEdfU0hJRlQpIHwKIAkJICAgICAgKDMyIDw8 IFRYX0xFTkdUSFNfU0xPVF9USU1FX1NISUZUKSkpOwogCi0JaWYgKEdFVF9BU0lDX1JFVih0cC0+ cGNpX2NoaXBfcmV2X2lkKSAhPSBBU0lDX1JFVl81NzA1ICYmCi0JICAgIEdFVF9BU0lDX1JFVih0 cC0+cGNpX2NoaXBfcmV2X2lkKSAhPSBBU0lDX1JFVl81NzUwKSB7CisJaWYgKCEodHAtPnRnM19m bGFnczIgJiBURzNfRkxHMl81NzA1X1BMVVMpKSB7CiAJCWlmIChuZXRpZl9jYXJyaWVyX29rKHRw LT5kZXYpKSB7CiAJCQl0dzMyKEhPU1RDQ19TVEFUX0NPQUxfVElDS1MsCiAJCQkgICAgIERFRkFV TFRfU1RBVF9DT0FMX1RJQ0tTKTsKQEAgLTM1NjgsOCArMzU2Miw3IEBACiAJdW5zaWduZWQgaW50 IGk7CiAJdTMyIHZhbDsKIAotCWlmIChHRVRfQVNJQ19SRVYodHAtPnBjaV9jaGlwX3Jldl9pZCkg PT0gQVNJQ19SRVZfNTcwNSB8fAotCSAgICBHRVRfQVNJQ19SRVYodHAtPnBjaV9jaGlwX3Jldl9p ZCkgPT0gQVNJQ19SRVZfNTc1MCkgeworCWlmICh0cC0+dGczX2ZsYWdzMiAmIFRHM19GTEcyXzU3 MDVfUExVUykgewogCQlzd2l0Y2ggKG9mcykgewogCQljYXNlIFJDVkxTQ19NT0RFOgogCQljYXNl IERNQUNfTU9ERToKQEAgLTM4MTEsOCArMzgwNCw3IEBACiAJCX0KIAl9CiAKLQlpZiAoR0VUX0FT SUNfUkVWKHRwLT5wY2lfY2hpcF9yZXZfaWQpID09IEFTSUNfUkVWXzU3MDUgfHwKLQkgICAgR0VU X0FTSUNfUkVWKHRwLT5wY2lfY2hpcF9yZXZfaWQpID09IEFTSUNfUkVWXzU3NTApCisJaWYgKHRw LT50ZzNfZmxhZ3MyICYgVEczX0ZMRzJfNTcwNV9QTFVTKQogCQl2YWwgfD0gR1JDX01JU0NfQ0ZH X0tFRVBfR1BIWV9QT1dFUjsKIAl0dzMyKEdSQ19NSVNDX0NGRywgdmFsKTsKIApAQCAtNDEyNyw3 ICs0MTE5LDcgQEAKIAlpbnQgaTsKIAogCWlmIChvZmZzZXQgPT0gVFhfQ1BVX0JBU0UgJiYKLQkg ICAgR0VUX0FTSUNfUkVWKHRwLT5wY2lfY2hpcF9yZXZfaWQpID09IEFTSUNfUkVWXzU3MDUpCisJ ICAgICh0cC0+dGczX2ZsYWdzMiAmIFRHM19GTEcyXzU3MDVfUExVUykpCiAJCUJVRygpOwogCiAJ aWYgKG9mZnNldCA9PSBSWF9DUFVfQkFTRSkgewpAQCAtNDE4MSwxNCArNDE3MywxNCBAQAogCXZv aWQgKCp3cml0ZV9vcCkoc3RydWN0IHRnMyAqLCB1MzIsIHUzMik7CiAKIAlpZiAoY3B1X2Jhc2Ug PT0gVFhfQ1BVX0JBU0UgJiYKLQkgICAgR0VUX0FTSUNfUkVWKHRwLT5wY2lfY2hpcF9yZXZfaWQp ID09IEFTSUNfUkVWXzU3MDUpIHsKKwkgICAgKHRwLT50ZzNfZmxhZ3MyICYgVEczX0ZMRzJfNTcw NV9QTFVTKSkgewogCQlwcmludGsoS0VSTl9FUlIgUEZYICJ0ZzNfbG9hZF9maXJtd2FyZV9jcHU6 IFRyeWluZyB0byBsb2FkICIKIAkJICAgICAgICJUWCBjcHUgZmlybXdhcmUgb24gJXMgd2hpY2gg aXMgNTcwNS5cbiIsCiAJCSAgICAgICB0cC0+ZGV2LT5uYW1lKTsKIAkJcmV0dXJuIC1FSU5WQUw7 CiAJfQogCi0JaWYgKEdFVF9BU0lDX1JFVih0cC0+cGNpX2NoaXBfcmV2X2lkKSA9PSBBU0lDX1JF Vl81NzA1KQorCWlmICh0cC0+dGczX2ZsYWdzMiAmIFRHM19GTEcyXzU3MDVfUExVUykKIAkJd3Jp dGVfb3AgPSB0ZzNfd3JpdGVfbWVtOwogCWVsc2UKIAkJd3JpdGVfb3AgPSB0ZzNfd3JpdGVfaW5k aXJlY3RfcmVnMzI7CkBAIC00OTI4LDggKzQ5MjAsNyBAQAogCQkgICAgICAoYmRpbmZvX2FkZHIg KyBURzNfQkRJTkZPX01BWExFTl9GTEFHUyksCiAJCSAgICAgICBtYXhsZW5fZmxhZ3MpOwogCi0J aWYgKChHRVRfQVNJQ19SRVYodHAtPnBjaV9jaGlwX3Jldl9pZCkgIT0gQVNJQ19SRVZfNTcwNSkg JiYKLQkgICAgKEdFVF9BU0lDX1JFVih0cC0+cGNpX2NoaXBfcmV2X2lkKSAhPSBBU0lDX1JFVl81 NzUwKSkKKwlpZiAoISh0cC0+dGczX2ZsYWdzMiAmIFRHM19GTEcyXzU3MDVfUExVUykpCiAJCXRn M193cml0ZV9tZW0odHAsCiAJCQkgICAgICAoYmRpbmZvX2FkZHIgKyBURzNfQkRJTkZPX05JQ19B RERSKSwKIAkJCSAgICAgIG5pY19hZGRyKTsKQEAgLTUxMDcsOCArNTA5OCw3IEBACiAJLyogRG9u J3QgZXZlbiB0cnkgdG8gcHJvZ3JhbSB0aGUgSlVNQk8vTUlOSSBidWZmZXIgZGVzY3JpcHRvcgog CSAqIGNvbmZpZ3Mgb24gNTcwNS4KIAkgKi8KLQlpZiAoR0VUX0FTSUNfUkVWKHRwLT5wY2lfY2hp cF9yZXZfaWQpID09IEFTSUNfUkVWXzU3MDUgfHwKLQkgICAgR0VUX0FTSUNfUkVWKHRwLT5wY2lf Y2hpcF9yZXZfaWQpID09IEFTSUNfUkVWXzU3NTApIHsKKwlpZiAodHAtPnRnM19mbGFnczIgJiBU RzNfRkxHMl81NzA1X1BMVVMpIHsKIAkJdHczMihSQ1ZEQkRJX1NURF9CRCArIFRHM19CRElORk9f TUFYTEVOX0ZMQUdTLAogCQkgICAgIFJYX1NURF9NQVhfU0laRV81NzA1IDw8IEJESU5GT19GTEFH U19NQVhMRU5fU0hJRlQpOwogCX0gZWxzZSB7CkBAIC01MTQwLDggKzUxMzAsNyBAQAogCS8qIFRo ZXJlIGlzIG9ubHkgb25lIHNlbmQgcmluZyBvbiA1NzA1LzU3NTAsIG5vIG5lZWQgdG8gZXhwbGlj aXRseQogCSAqIGRpc2FibGUgdGhlIG90aGVycy4KIAkgKi8KLQlpZiAoR0VUX0FTSUNfUkVWKHRw LT5wY2lfY2hpcF9yZXZfaWQpICE9IEFTSUNfUkVWXzU3MDUgJiYKLQkgICAgR0VUX0FTSUNfUkVW KHRwLT5wY2lfY2hpcF9yZXZfaWQpICE9IEFTSUNfUkVWXzU3NTApIHsKKwlpZiAoISh0cC0+dGcz X2ZsYWdzMiAmIFRHM19GTEcyXzU3MDVfUExVUykpIHsKIAkJLyogQ2xlYXIgb3V0IHNlbmQgUkNC IHJpbmcgaW4gU1JBTS4gKi8KIAkJZm9yIChpID0gTklDX1NSQU1fU0VORF9SQ0I7IGkgPCBOSUNf U1JBTV9SQ1ZfUkVUX1JDQjsgaSArPSBURzNfQkRJTkZPX1NJWkUpCiAJCQl0ZzNfd3JpdGVfbWVt KHRwLCBpICsgVEczX0JESU5GT19NQVhMRU5fRkxBR1MsCkBAIC01MTYyLDggKzUxNTEsNyBAQAog CS8qIFRoZXJlIGlzIG9ubHkgb25lIHJlY2VpdmUgcmV0dXJuIHJpbmcgb24gNTcwNS81NzUwLCBu byBuZWVkCiAJICogdG8gZXhwbGljaXRseSBkaXNhYmxlIHRoZSBvdGhlcnMuCiAJICovCi0JaWYg KEdFVF9BU0lDX1JFVih0cC0+cGNpX2NoaXBfcmV2X2lkKSAhPSBBU0lDX1JFVl81NzA1ICYmCi0J ICAgIEdFVF9BU0lDX1JFVih0cC0+cGNpX2NoaXBfcmV2X2lkKSAhPSBBU0lDX1JFVl81NzUwKSB7 CisJaWYgKCEodHAtPnRnM19mbGFnczIgJiBURzNfRkxHMl81NzA1X1BMVVMpKSB7CiAJCWZvciAo aSA9IE5JQ19TUkFNX1JDVl9SRVRfUkNCOyBpIDwgTklDX1NSQU1fU1RBVFNfQkxLOwogCQkgICAg IGkgKz0gVEczX0JESU5GT19TSVpFKSB7CiAJCQl0ZzNfd3JpdGVfbWVtKHRwLCBpICsgVEczX0JE SU5GT19NQVhMRU5fRkxBR1MsCkBAIC01MjYyLDggKzUyNTAsNyBAQAogCXR3MzIoSE9TVENDX1RY Q09MX1RJQ0tTLCBMT1dfVFhDT0xfVElDS1MpOwogCXR3MzIoSE9TVENDX1JYTUFYX0ZSQU1FUywg MSk7CiAJdHczMihIT1NUQ0NfVFhNQVhfRlJBTUVTLCBMT1dfUlhNQVhfRlJBTUVTKTsKLQlpZiAo R0VUX0FTSUNfUkVWKHRwLT5wY2lfY2hpcF9yZXZfaWQpICE9IEFTSUNfUkVWXzU3MDUgJiYKLQkg ICAgR0VUX0FTSUNfUkVWKHRwLT5wY2lfY2hpcF9yZXZfaWQpICE9IEFTSUNfUkVWXzU3NTApIHsK KwlpZiAoISh0cC0+dGczX2ZsYWdzMiAmIFRHM19GTEcyXzU3MDVfUExVUykpIHsKIAkJdHczMihI T1NUQ0NfUlhDT0FMX1RJQ0tfSU5ULCAwKTsKIAkJdHczMihIT1NUQ0NfVFhDT0FMX1RJQ0tfSU5U LCAwKTsKIAl9CkBAIC01Mjc2LDggKzUyNjMsNyBAQAogCXR3MzIoSE9TVENDX1NUQVRVU19CTEtf SE9TVF9BRERSICsgVEczXzY0QklUX1JFR19MT1csCiAJICAgICAoKHU2NCkgdHAtPnN0YXR1c19t YXBwaW5nICYgMHhmZmZmZmZmZikpOwogCi0JaWYgKEdFVF9BU0lDX1JFVih0cC0+cGNpX2NoaXBf cmV2X2lkKSAhPSBBU0lDX1JFVl81NzA1ICYmCi0JICAgIEdFVF9BU0lDX1JFVih0cC0+cGNpX2No aXBfcmV2X2lkKSAhPSBBU0lDX1JFVl81NzUwKSB7CisJaWYgKCEodHAtPnRnM19mbGFnczIgJiBU RzNfRkxHMl81NzA1X1BMVVMpKSB7CiAJCS8qIFN0YXR1cy9zdGF0aXN0aWNzIGJsb2NrIGFkZHJl c3MuICBTZWUgdGczX3RpbWVyLAogCQkgKiB0aGUgdGczX3BlcmlvZGljX2ZldGNoX3N0YXRzIGNh bGwgdGhlcmUsIGFuZAogCQkgKiB0ZzNfZ2V0X3N0YXRzIHRvIHNlZSBob3cgdGhpcyB3b3JrcyBm b3IgNTcwNS81NzUwIGNoaXBzLgpAQCAtNTI5Niw4ICs1MjgyLDcgQEAKIAogCXR3MzIoUkNWQ0Nf TU9ERSwgUkNWQ0NfTU9ERV9FTkFCTEUgfCBSQ1ZDQ19NT0RFX0FUVE5fRU5BQkxFKTsKIAl0dzMy KFJDVkxQQ19NT0RFLCBSQ1ZMUENfTU9ERV9FTkFCTEUpOwotCWlmIChHRVRfQVNJQ19SRVYodHAt PnBjaV9jaGlwX3Jldl9pZCkgIT0gQVNJQ19SRVZfNTcwNSAmJgotCSAgICBHRVRfQVNJQ19SRVYo dHAtPnBjaV9jaGlwX3Jldl9pZCkgIT0gQVNJQ19SRVZfNTc1MCkKKwlpZiAoISh0cC0+dGczX2Zs YWdzMiAmIFRHM19GTEcyXzU3MDVfUExVUykpCiAJCXR3MzIoUkNWTFNDX01PREUsIFJDVkxTQ19N T0RFX0VOQUJMRSB8IFJDVkxTQ19NT0RFX0FUVE5fRU5BQkxFKTsKIAogCS8qIENsZWFyIHN0YXRp c3RpY3Mvc3RhdHVzIGJsb2NrIGluIGNoaXAsIGFuZCBzdGF0dXMgYmxvY2sgaW4gcmFtLiAqLwpA QCAtNTMyNCw4ICs1MzA5LDcgQEAKIAl0dzMyX21haWxib3goTUFJTEJPWF9JTlRFUlJVUFRfMCAr IFRHM182NEJJVF9SRUdfTE9XLCAwKTsKIAl0cjMyKE1BSUxCT1hfSU5URVJSVVBUXzApOwogCi0J aWYgKEdFVF9BU0lDX1JFVih0cC0+cGNpX2NoaXBfcmV2X2lkKSAhPSBBU0lDX1JFVl81NzA1ICYm Ci0JICAgIEdFVF9BU0lDX1JFVih0cC0+cGNpX2NoaXBfcmV2X2lkKSAhPSBBU0lDX1JFVl81NzUw KSB7CisJaWYgKCEodHAtPnRnM19mbGFnczIgJiBURzNfRkxHMl81NzA1X1BMVVMpKSB7CiAJCXR3 MzJfZihETUFDX01PREUsIERNQUNfTU9ERV9FTkFCTEUpOwogCQl1ZGVsYXkoNDApOwogCX0KQEAg LTUzNzIsOCArNTM1Niw3IEBACiAJdWRlbGF5KDQwKTsKIAogCXR3MzIoUkNWRENDX01PREUsIFJD VkRDQ19NT0RFX0VOQUJMRSB8IFJDVkRDQ19NT0RFX0FUVE5fRU5BQkxFKTsKLQlpZiAoR0VUX0FT SUNfUkVWKHRwLT5wY2lfY2hpcF9yZXZfaWQpICE9IEFTSUNfUkVWXzU3MDUgJiYKLQkgICAgR0VU X0FTSUNfUkVWKHRwLT5wY2lfY2hpcF9yZXZfaWQpICE9IEFTSUNfUkVWXzU3NTApCisJaWYgKCEo dHAtPnRnM19mbGFnczIgJiBURzNfRkxHMl81NzA1X1BMVVMpKQogCQl0dzMyKE1CRlJFRV9NT0RF LCBNQkZSRUVfTU9ERV9FTkFCTEUpOwogCXR3MzIoU05EREFUQUNfTU9ERSwgU05EREFUQUNfTU9E RV9FTkFCTEUpOwogCXR3MzIoU05EQkRDX01PREUsIFNOREJEQ19NT0RFX0VOQUJMRSB8IFNOREJE Q19NT0RFX0FUVE5fRU5BQkxFKTsKQEAgLTU0NzcsOCArNTQ2MCw3IEBACiAJdHczMihNQUNfUkNW X1JVTEVfMSwgIDB4ODYwMDAwMDQgJiBSQ1ZfUlVMRV9ESVNBQkxFX01BU0spOwogCXR3MzIoTUFD X1JDVl9WQUxVRV8xLCAweGZmZmZmZmZmICYgUkNWX1JVTEVfRElTQUJMRV9NQVNLKTsKIAotCWlm IChHRVRfQVNJQ19SRVYodHAtPnBjaV9jaGlwX3Jldl9pZCkgPT0gQVNJQ19SRVZfNTcwNSB8fAot CSAgICBHRVRfQVNJQ19SRVYodHAtPnBjaV9jaGlwX3Jldl9pZCkgPT0gQVNJQ19SRVZfNTc1MCkK KwlpZiAodHAtPnRnM19mbGFnczIgJiBURzNfRkxHMl81NzA1X1BMVVMpCiAJCWxpbWl0ID0gODsK IAllbHNlCiAJCWxpbWl0ID0gMTY7CkBAIC01NjIyLDggKzU2MDQsNyBAQAogCQlyZXR1cm47CiAJ fQogCi0JaWYgKEdFVF9BU0lDX1JFVih0cC0+cGNpX2NoaXBfcmV2X2lkKSA9PSBBU0lDX1JFVl81 NzA1IHx8Ci0JICAgIEdFVF9BU0lDX1JFVih0cC0+cGNpX2NoaXBfcmV2X2lkKSA9PSBBU0lDX1JF Vl81NzUwKQorCWlmICh0cC0+dGczX2ZsYWdzMiAmIFRHM19GTEcyXzU3MDVfUExVUykKIAkJdGcz X3BlcmlvZGljX2ZldGNoX3N0YXRzKHRwKTsKIAogCS8qIFRoaXMgcGFydCBvbmx5IHJ1bnMgb25j ZSBwZXIgc2Vjb25kLiAqLwpAQCAtNzkwOCw2ICs3ODg5LDEwIEBACiAJdHAtPnBjaV9oZHJfdHlw ZSAgICAgPSAoY2FjaGVsaW5lX3N6X3JlZyA+PiAxNikgJiAweGZmOwogCXRwLT5wY2lfYmlzdCAg ICAgICAgID0gKGNhY2hlbGluZV9zel9yZWcgPj4gMjQpICYgMHhmZjsKIAorCWlmICgoR0VUX0FT SUNfUkVWKHRwLT5wY2lfY2hpcF9yZXZfaWQpID09IEFTSUNfUkVWXzU3MDUpIHx8CisJICAgIChH RVRfQVNJQ19SRVYodHAtPnBjaV9jaGlwX3Jldl9pZCkgPT0gQVNJQ19SRVZfNTc1MCkpCisJCXRw LT50ZzNfZmxhZ3MyIHw9IFRHM19GTEcyXzU3MDVfUExVUzsKKwogCWlmIChHRVRfQVNJQ19SRVYo dHAtPnBjaV9jaGlwX3Jldl9pZCkgPT0gQVNJQ19SRVZfNTc1MCkKIAkJdHAtPnRnM19mbGFnczIg fD0gVEczX0ZMRzJfSFdfVFNPOwogCkBAIC04Nzk1LDggKzg3ODAsNyBAQAogCQlnb3RvIGVycl9v dXRfaW91bm1hcDsKIAl9CiAKLQlpZiAoR0VUX0FTSUNfUkVWKHRwLT5wY2lfY2hpcF9yZXZfaWQp ID09IEFTSUNfUkVWXzU3MDUgfHwKLQkgICAgR0VUX0FTSUNfUkVWKHRwLT5wY2lfY2hpcF9yZXZf aWQpID09IEFTSUNfUkVWXzU3NTApIHsKKwlpZiAodHAtPnRnM19mbGFnczIgJiBURzNfRkxHMl81 NzA1X1BMVVMpIHsKIAkJdHAtPmJ1Zm1ncl9jb25maWcubWJ1Zl9yZWFkX2RtYV9sb3dfd2F0ZXIg PQogCQkJREVGQVVMVF9NQl9SRE1BX0xPV19XQVRFUl81NzA1OwogCQl0cC0+YnVmbWdyX2NvbmZp Zy5tYnVmX21hY19yeF9sb3dfd2F0ZXIgPQpkaWZmIC1OcnUgMS9kcml2ZXJzL25ldC90ZzMuaCAy L2RyaXZlcnMvbmV0L3RnMy5oCi0tLSAxL2RyaXZlcnMvbmV0L3RnMy5oCTIwMDUtMDMtMTQgMjI6 MTE6MjkuMDAwMDAwMDAwIC0wODAwCisrKyAyL2RyaXZlcnMvbmV0L3RnMy5oCTIwMDUtMDMtMTQg MjI6MDk6NTUuMDAwMDAwMDAwIC0wODAwCkBAIC0yMDk2LDYgKzIwOTYsNyBAQAogI2RlZmluZSBU RzNfRkxHMl9GTEFTSAkJCTB4MDAwMDgwMDAKICNkZWZpbmUgVEczX0ZMRzJfSFdfVFNPCQkJMHgw MDAxMDAwMAogI2RlZmluZSBURzNfRkxHMl9TRVJERVNfUFJFRU1QSEFTSVMJMHgwMDAyMDAwMAor I2RlZmluZSBURzNfRkxHMl81NzA1X1BMVVMJCTB4MDAwNDAwMDAKIAogCXUzMgkJCQlzcGxpdF9t b2RlX21heF9yZXFzOwogI2RlZmluZSBTUExJVF9NT0RFXzU3MDRfTUFYX1JFUQkJMwo= ------_=_NextPart_001_01C52DE5.A6E5415B-- From mchan@broadcom.com Sun Mar 20 23:26:46 2005 Received: with ECARTIS (v1.0.0; list netdev); Sun, 20 Mar 2005 23:26:50 -0800 (PST) Received: from MMS2.broadcom.com (mms2.broadcom.com [216.31.210.18]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j2L7Qjmt020658 for ; Sun, 20 Mar 2005 23:26:45 -0800 Received: from 10.10.64.121 by MMS2.broadcom.com with SMTP (Broadcom SMTP Relay (Email Firewall v6.1.0)); Sun, 20 Mar 2005 23:26:28 -0800 X-Server-Uuid: 1F20ACF3-9CAF-44F7-AB47-F294E2D5B4EA Received: from mail-irva-8.broadcom.com ([10.10.64.221]) by mail-irva-1.broadcom.com (Post.Office MTA v3.5.3 release 223 ID# 0-72233U7200L2200S0V35) with ESMTP id com; Sun, 20 Mar 2005 23:26:28 -0800 Received: from mon-irva-10.broadcom.com (mon-irva-10.broadcom.com [10.10.64.171]) by mail-irva-8.broadcom.com (MOS 3.5.6-GR) with ESMTP id APJ68606; Sun, 20 Mar 2005 23:26:27 -0800 (PST) Received: from nt-irva-0741.brcm.ad.broadcom.com ( nt-irva-0741.brcm.ad.broadcom.com [10.8.194.54]) by mon-irva-10.broadcom.com (8.9.1/8.9.1) with ESMTP id XAA08111; Sun, 20 Mar 2005 23:26:27 -0800 (PST) X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Subject: [PATCH 2.6.11 2/8] tg3: flush status block in tg3_interrupt Date: Sun, 20 Mar 2005 23:26:26 -0800 Message-ID: X-MS-Has-Attach: yes Thread-Topic: [PATCH 2.6.11 2/8] tg3: flush status block in tg3_interrupt Thread-Index: AcUQenBthEVwCOEDSUG7grDnD7JTOgdadRIAAABhWpA= From: "Michael Chan" To: "David S. Miller" cc: netdev@oss.sgi.com X-WSS-ID: 6E20A8AE2WW898804-01-01 Content-Type: multipart/mixed; boundary="----_=_NextPart_001_01C52DE7.4AAD9CD4" X-Virus-Scanned: ClamAV 0.83/774/Fri Mar 18 17:04:06 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 418 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: mchan@broadcom.com Precedence: bulk X-list: netdev Content-Length: 1814 Lines: 42 This is a multi-part message in MIME format. ------_=_NextPart_001_01C52DE7.4AAD9CD4 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Add register read of PCI state register in tg3_interrupt() if status = block's updated bit is not set. This will flush the status block and confirm = whether the interrupt is ours or not. PCI ordering rules allow the interrupt to arrive at the CPU ahead of the status block that may be posted at the chipset. Signed-off-by: Michael Chan ------_=_NextPart_001_01C52DE7.4AAD9CD4 Content-Type: application/octet-stream; name=tg3-2.patch Content-Transfer-Encoding: base64 Content-Description: tg3-2.patch Content-Disposition: attachment; filename=tg3-2.patch ZGlmZiAtTnJ1IDIvZHJpdmVycy9uZXQvdGczLmMgMy9kcml2ZXJzL25ldC90ZzMuYwotLS0gMi9k cml2ZXJzL25ldC90ZzMuYwkyMDA1LTAzLTE0IDIyOjA5OjUxLjAwMDAwMDAwMCAtMDgwMAorKysg My9kcml2ZXJzL25ldC90ZzMuYwkyMDA1LTAzLTE0IDIyOjI0OjM1LjAwMDAwMDAwMCAtMDgwMApA QCAtMjg4Niw3ICsyODg2LDEzIEBACiAKIAlzcGluX2xvY2tfaXJxc2F2ZSgmdHAtPmxvY2ssIGZs YWdzKTsKIAotCWlmIChzYmxrLT5zdGF0dXMgJiBTRF9TVEFUVVNfVVBEQVRFRCkgeworCS8qIElu IElOVHggbW9kZSwgaXQgaXMgcG9zc2libGUgZm9yIHRoZSBpbnRlcnJ1cHQgdG8gYXJyaXZlIGF0 CisJICogdGhlIENQVSBiZWZvcmUgdGhlIHN0YXR1cyBibG9jayBwb3N0ZWQgcHJpb3IgdG8gdGhl IGludGVycnVwdC4KKwkgKiBSZWFkaW5nIHRoZSBQQ0kgU3RhdGUgcmVnaXN0ZXIgd2lsbCBjb25m aXJtIHdoZXRoZXIgdGhlCisJICogaW50ZXJydXB0IGlzIG91cnMgYW5kIHdpbGwgZmx1c2ggdGhl IHN0YXR1cyBibG9jay4KKwkgKi8KKwlpZiAoKHNibGstPnN0YXR1cyAmIFNEX1NUQVRVU19VUERB VEVEKSB8fAorCSAgICAhKHRyMzIoVEczUENJX1BDSVNUQVRFKSAmIFBDSVNUQVRFX0lOVF9OT1Rf QUNUSVZFKSkgewogCQkvKgogCQkgKiB3cml0aW5nIGFueSB2YWx1ZSB0byBpbnRyLW1ib3gtMCBj bGVhcnMgUENJIElOVEEjIGFuZAogCQkgKiBjaGlwLWludGVybmFsIGludGVycnVwdCBwZW5kaW5n IGV2ZW50cy4K ------_=_NextPart_001_01C52DE7.4AAD9CD4-- From mchan@broadcom.com Sun Mar 20 23:34:39 2005 Received: with ECARTIS (v1.0.0; list netdev); Sun, 20 Mar 2005 23:34:45 -0800 (PST) Received: from MMS2.broadcom.com (mms2.broadcom.com [216.31.210.18]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j2L7YddS021815 for ; Sun, 20 Mar 2005 23:34:39 -0800 Received: from 10.10.64.121 by MMS2.broadcom.com with SMTP (Broadcom SMTP Relay (Email Firewall v6.1.0)); Sun, 20 Mar 2005 23:34:20 -0800 X-Server-Uuid: 1F20ACF3-9CAF-44F7-AB47-F294E2D5B4EA Received: from mail-irva-8.broadcom.com ([10.10.64.221]) by mail-irva-1.broadcom.com (Post.Office MTA v3.5.3 release 223 ID# 0-72233U7200L2200S0V35) with ESMTP id com; Sun, 20 Mar 2005 23:34:20 -0800 Received: from mon-irva-10.broadcom.com (mon-irva-10.broadcom.com [10.10.64.171]) by mail-irva-8.broadcom.com (MOS 3.5.6-GR) with ESMTP id APJ69228; Sun, 20 Mar 2005 23:34:19 -0800 (PST) Received: from nt-irva-0741.brcm.ad.broadcom.com ( nt-irva-0741.brcm.ad.broadcom.com [10.8.194.54]) by mon-irva-10.broadcom.com (8.9.1/8.9.1) with ESMTP id XAA08786; Sun, 20 Mar 2005 23:34:19 -0800 (PST) X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Subject: [PATCH 2.6.11 3/8] tg3: Add msi support for 5750 C0 Date: Sun, 20 Mar 2005 23:34:18 -0800 Message-ID: X-MS-Has-Attach: yes Thread-Topic: [PATCH 2.6.11 3/8] tg3: Add msi support for 5750 C0 Thread-Index: AcUQenBthEVwCOEDSUG7grDnD7JTOgdadRIAAABhWpAAAGS18A== From: "Michael Chan" To: "David S. Miller" cc: netdev@oss.sgi.com X-WSS-ID: 6E20A7762WW900048-01-01 Content-Type: multipart/mixed; boundary="----_=_NextPart_001_01C52DE8.64120F8B" X-Virus-Scanned: ClamAV 0.83/774/Fri Mar 18 17:04:06 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 419 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: mchan@broadcom.com Precedence: bulk X-list: netdev Content-Length: 6285 Lines: 101 This is a multi-part message in MIME format. ------_=_NextPart_001_01C52DE8.64120F8B Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Add MSI support for 5750 C0 and newer chips. MSI is handled by a new interrupt service routine that is very similar to the existing tg3_interrupt() for INTx mode. The MSI version is optimized by not = checking for shared interrupt and not flushing the status block. The code is also changed to reference the irq from tp->pdev->irq instead = of dev->irq. Signed-off-by: Michael Chan ------_=_NextPart_001_01C52DE8.64120F8B Content-Type: application/octet-stream; name=tg3-3.patch Content-Transfer-Encoding: base64 Content-Description: tg3-3.patch Content-Disposition: attachment; filename=tg3-3.patch ZGlmZiAtTnJ1IDMvZHJpdmVycy9uZXQvdGczLmMgNC9kcml2ZXJzL25ldC90ZzMuYwotLS0gMy9k cml2ZXJzL25ldC90ZzMuYwkyMDA1LTAzLTE0IDIyOjI0OjM1LjAwMDAwMDAwMCAtMDgwMAorKysg NC9kcml2ZXJzL25ldC90ZzMuYwkyMDA1LTAzLTE1IDIwOjQxOjUxLjAwMDAwMDAwMCAtMDgwMApA QCAtMjg3Niw2ICsyODc2LDQzIEBACiAJcmV0dXJuIHdvcmtfZXhpc3RzOwogfQogCisvKiBNU0kg SVNSIC0gTm8gbmVlZCB0byBjaGVjayBmb3IgaW50ZXJydXB0IHNoYXJpbmcgYW5kIG5vIG5lZWQg dG8KKyAqIGZsdXNoIHN0YXR1cyBibG9jayBhbmQgaW50ZXJydXB0IG1haWxib3guIFBDSSBvcmRl cmluZyBydWxlcworICogZ3VhcmFudGVlIHRoYXQgTVNJIHdpbGwgYXJyaXZlIGFmdGVyIHRoZSBz dGF0dXMgYmxvY2suCisgKi8KK3N0YXRpYyBpcnFyZXR1cm5fdCB0ZzNfbXNpKGludCBpcnEsIHZv aWQgKmRldl9pZCwgc3RydWN0IHB0X3JlZ3MgKnJlZ3MpCit7CisJc3RydWN0IG5ldF9kZXZpY2Ug KmRldiA9IGRldl9pZDsKKwlzdHJ1Y3QgdGczICp0cCA9IG5ldGRldl9wcml2KGRldik7CisJc3Ry dWN0IHRnM19od19zdGF0dXMgKnNibGsgPSB0cC0+aHdfc3RhdHVzOworCXVuc2lnbmVkIGxvbmcg ZmxhZ3M7CisKKwlzcGluX2xvY2tfaXJxc2F2ZSgmdHAtPmxvY2ssIGZsYWdzKTsKKworCS8qCisJ ICogd3JpdGluZyBhbnkgdmFsdWUgdG8gaW50ci1tYm94LTAgY2xlYXJzIFBDSSBJTlRBIyBhbmQK KwkgKiBjaGlwLWludGVybmFsIGludGVycnVwdCBwZW5kaW5nIGV2ZW50cy4KKwkgKiB3cml0aW5n IG5vbi16ZXJvIHRvIGludHItbWJveC0wIGFkZGl0aW9uYWwgdGVsbHMgdGhlCisJICogTklDIHRv IHN0b3Agc2VuZGluZyB1cyBpcnFzLCBlbmdhZ2luZyAiaW4taW50ci1oYW5kbGVyIgorCSAqIGV2 ZW50IGNvYWxlc2NpbmcuCisJICovCisJdHczMl9tYWlsYm94KE1BSUxCT1hfSU5URVJSVVBUXzAg KyBURzNfNjRCSVRfUkVHX0xPVywgMHgwMDAwMDAwMSk7CisJc2Jsay0+c3RhdHVzICY9IH5TRF9T VEFUVVNfVVBEQVRFRDsKKworCWlmIChsaWtlbHkodGczX2hhc193b3JrKGRldiwgdHApKSkKKwkJ bmV0aWZfcnhfc2NoZWR1bGUoZGV2KTsJCS8qIHNjaGVkdWxlIE5BUEkgcG9sbCAqLworCWVsc2Ug eworCQkvKiBubyB3b3JrLCByZS1lbmFibGUgaW50ZXJydXB0cworCQkgKi8KKwkJdHczMl9tYWls Ym94KE1BSUxCT1hfSU5URVJSVVBUXzAgKyBURzNfNjRCSVRfUkVHX0xPVywKKwkJCSAgICAgMHgw MDAwMDAwMCk7CisJfQorCisJc3Bpbl91bmxvY2tfaXJxcmVzdG9yZSgmdHAtPmxvY2ssIGZsYWdz KTsKKworCXJldHVybiBJUlFfUkVUVkFMKDEpOworfQorCiBzdGF0aWMgaXJxcmV0dXJuX3QgdGcz X2ludGVycnVwdChpbnQgaXJxLCB2b2lkICpkZXZfaWQsIHN0cnVjdCBwdF9yZWdzICpyZWdzKQog ewogCXN0cnVjdCBuZXRfZGV2aWNlICpkZXYgPSBkZXZfaWQ7CkBAIC0yOTM0LDcgKzI5NzEsOSBA QAogI2lmZGVmIENPTkZJR19ORVRfUE9MTF9DT05UUk9MTEVSCiBzdGF0aWMgdm9pZCB0ZzNfcG9s bF9jb250cm9sbGVyKHN0cnVjdCBuZXRfZGV2aWNlICpkZXYpCiB7Ci0JdGczX2ludGVycnVwdChk ZXYtPmlycSwgZGV2LCBOVUxMKTsKKwlzdHJ1Y3QgdGczICp0cCA9IG5ldGRldl9wcml2KGRldik7 CisKKwl0ZzNfaW50ZXJydXB0KHRwLT5wZGV2LT5pcnEsIGRldiwgTlVMTCk7CiB9CiAjZW5kaWYK IApAQCAtNTcwMCwxMCArNTczOSwyOSBAQAogCWlmIChlcnIpCiAJCXJldHVybiBlcnI7CiAKLQll cnIgPSByZXF1ZXN0X2lycShkZXYtPmlycSwgdGczX2ludGVycnVwdCwKLQkJCSAgU0FfU0hJUlEs IGRldi0+bmFtZSwgZGV2KTsKKwlpZiAoKEdFVF9BU0lDX1JFVih0cC0+cGNpX2NoaXBfcmV2X2lk KSA9PSBBU0lDX1JFVl81NzUwKSAmJgorCSAgICAoR0VUX0NISVBfUkVWKHRwLT5wY2lfY2hpcF9y ZXZfaWQpICE9IENISVBSRVZfNTc1MF9BWCkgJiYKKwkgICAgKEdFVF9DSElQX1JFVih0cC0+cGNp X2NoaXBfcmV2X2lkKSAhPSBDSElQUkVWXzU3NTBfQlgpKSB7CisJCWlmIChwY2lfZW5hYmxlX21z aSh0cC0+cGRldikgPT0gMCkgeworCQkJdTMyIG1zaV9tb2RlOworCisJCQltc2lfbW9kZSA9IHRy MzIoTVNHSU5UX01PREUpOworCQkJdHczMihNU0dJTlRfTU9ERSwgbXNpX21vZGUgfCBNU0dJTlRf TU9ERV9FTkFCTEUpOworCQkJdHAtPnRnM19mbGFnczIgfD0gVEczX0ZMRzJfVVNJTkdfTVNJOwor CQl9CisJfQorCWlmICh0cC0+dGczX2ZsYWdzMiAmIFRHM19GTEcyX1VTSU5HX01TSSkKKwkJZXJy ID0gcmVxdWVzdF9pcnEodHAtPnBkZXYtPmlycSwgdGczX21zaSwKKwkJCQkgIDAsIGRldi0+bmFt ZSwgZGV2KTsKKwllbHNlCisJCWVyciA9IHJlcXVlc3RfaXJxKHRwLT5wZGV2LT5pcnEsIHRnM19p bnRlcnJ1cHQsCisJCQkJICBTQV9TSElSUSwgZGV2LT5uYW1lLCBkZXYpOwogCiAJaWYgKGVycikg eworCQlpZiAodHAtPnRnM19mbGFnczIgJiBURzNfRkxHMl9VU0lOR19NU0kpIHsKKwkJCXBjaV9k aXNhYmxlX21zaSh0cC0+cGRldik7CisJCQl0cC0+dGczX2ZsYWdzMiAmPSB+VEczX0ZMRzJfVVNJ TkdfTVNJOworCQl9CiAJCXRnM19mcmVlX2NvbnNpc3RlbnQodHApOwogCQlyZXR1cm4gZXJyOwog CX0KQEAgLTU3MzMsNyArNTc5MSwxMSBAQAogCXNwaW5fdW5sb2NrX2lycSgmdHAtPmxvY2spOwog CiAJaWYgKGVycikgewotCQlmcmVlX2lycShkZXYtPmlycSwgZGV2KTsKKwkJZnJlZV9pcnEodHAt PnBkZXYtPmlycSwgZGV2KTsKKwkJaWYgKHRwLT50ZzNfZmxhZ3MyICYgVEczX0ZMRzJfVVNJTkdf TVNJKSB7CisJCQlwY2lfZGlzYWJsZV9tc2kodHAtPnBkZXYpOworCQkJdHAtPnRnM19mbGFnczIg Jj0gflRHM19GTEcyX1VTSU5HX01TSTsKKwkJfQogCQl0ZzNfZnJlZV9jb25zaXN0ZW50KHRwKTsK IAkJcmV0dXJuIGVycjsKIAl9CkBAIC02MDA4LDcgKzYwNzAsMTEgQEAKIAlzcGluX3VubG9jaygm dHAtPnR4X2xvY2spOwogCXNwaW5fdW5sb2NrX2lycSgmdHAtPmxvY2spOwogCi0JZnJlZV9pcnEo ZGV2LT5pcnEsIGRldik7CisJZnJlZV9pcnEodHAtPnBkZXYtPmlycSwgZGV2KTsKKwlpZiAodHAt PnRnM19mbGFnczIgJiBURzNfRkxHMl9VU0lOR19NU0kpIHsKKwkJcGNpX2Rpc2FibGVfbXNpKHRw LT5wZGV2KTsKKwkJdHAtPnRnM19mbGFnczIgJj0gflRHM19GTEcyX1VTSU5HX01TSTsKKwl9CiAK IAltZW1jcHkoJnRwLT5uZXRfc3RhdHNfcHJldiwgdGczX2dldF9zdGF0cyh0cC0+ZGV2KSwKIAkg ICAgICAgc2l6ZW9mKHRwLT5uZXRfc3RhdHNfcHJldikpOwpkaWZmIC1OcnUgMy9kcml2ZXJzL25l dC90ZzMuaCA0L2RyaXZlcnMvbmV0L3RnMy5oCi0tLSAzL2RyaXZlcnMvbmV0L3RnMy5oCTIwMDUt MDMtMTQgMjI6MjQ6MzguMDAwMDAwMDAwIC0wODAwCisrKyA0L2RyaXZlcnMvbmV0L3RnMy5oCTIw MDUtMDMtMTUgMjA6MzY6MDcuMDAwMDAwMDAwIC0wODAwCkBAIC0xNDAsNiArMTQwLDggQEAKICNk ZWZpbmUgICBDSElQUkVWXzU3MDNfQVgJCSAweDEwCiAjZGVmaW5lICAgQ0hJUFJFVl81NzA0X0FY CQkgMHgyMAogI2RlZmluZSAgIENISVBSRVZfNTcwNF9CWAkJIDB4MjEKKyNkZWZpbmUgICBDSElQ UkVWXzU3NTBfQVgJCSAweDQwCisjZGVmaW5lICAgQ0hJUFJFVl81NzUwX0JYCQkgMHg0MQogI2Rl ZmluZSAgR0VUX01FVEFMX1JFVihDSElQX1JFVl9JRCkJKChDSElQX1JFVl9JRCkgJiAweGZmKQog I2RlZmluZSAgIE1FVEFMX1JFVl9BMAkJCSAweDAwCiAjZGVmaW5lICAgTUVUQUxfUkVWX0ExCQkJ IDB4MDEKQEAgLTIwOTcsNiArMjA5OSw3IEBACiAjZGVmaW5lIFRHM19GTEcyX0hXX1RTTwkJCTB4 MDAwMTAwMDAKICNkZWZpbmUgVEczX0ZMRzJfU0VSREVTX1BSRUVNUEhBU0lTCTB4MDAwMjAwMDAK ICNkZWZpbmUgVEczX0ZMRzJfNTcwNV9QTFVTCQkweDAwMDQwMDAwCisjZGVmaW5lIFRHM19GTEcy X1VTSU5HX01TSQkJMHgwMDA4MDAwMAogCiAJdTMyCQkJCXNwbGl0X21vZGVfbWF4X3JlcXM7CiAj ZGVmaW5lIFNQTElUX01PREVfNTcwNF9NQVhfUkVRCQkzCg== ------_=_NextPart_001_01C52DE8.64120F8B-- From mchan@broadcom.com Sun Mar 20 23:43:31 2005 Received: with ECARTIS (v1.0.0; list netdev); Sun, 20 Mar 2005 23:43:35 -0800 (PST) Received: from MMS3.broadcom.com (mms3.broadcom.com [216.31.210.19]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j2L7hVXq023121 for ; Sun, 20 Mar 2005 23:43:31 -0800 Received: from 10.10.64.121 by MMS3.broadcom.com with SMTP (Broadcom SMTP Relay (Email Firewall v6.1.0)); Sun, 20 Mar 2005 23:43:06 -0800 X-Server-Uuid: 35E76369-CF33-4172-911A-D1698BD5E887 Received: from mail-irva-8.broadcom.com ([10.10.64.221]) by mail-irva-1.broadcom.com (Post.Office MTA v3.5.3 release 223 ID# 0-72233U7200L2200S0V35) with ESMTP id com; Sun, 20 Mar 2005 23:43:05 -0800 Received: from mon-irva-10.broadcom.com (mon-irva-10.broadcom.com [10.10.64.171]) by mail-irva-8.broadcom.com (MOS 3.5.6-GR) with ESMTP id APJ69906; Sun, 20 Mar 2005 23:43:04 -0800 (PST) Received: from nt-irva-0741.brcm.ad.broadcom.com ( nt-irva-0741.brcm.ad.broadcom.com [10.8.194.54]) by mon-irva-10.broadcom.com (8.9.1/8.9.1) with ESMTP id XAA09546; Sun, 20 Mar 2005 23:43:04 -0800 (PST) X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Subject: [PATCH 2.6.11 4/8] tg3: Add msi test Date: Sun, 20 Mar 2005 23:43:03 -0800 Message-ID: X-MS-Has-Attach: yes Thread-Topic: [PATCH 2.6.11 4/8] tg3: Add msi test Thread-Index: AcUQenBthEVwCOEDSUG7grDnD7JTOgdadRIAAABhWpAAAGS18AAARWAg From: "Michael Chan" To: "David S. Miller" cc: netdev@oss.sgi.com X-WSS-ID: 6E20A48025S1858204-01-01 Content-Type: multipart/mixed; boundary="----_=_NextPart_001_01C52DE9.9D3F955E" X-Virus-Scanned: ClamAV 0.83/774/Fri Mar 18 17:04:06 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 420 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: mchan@broadcom.com Precedence: bulk X-list: netdev Content-Length: 5953 Lines: 94 This is a multi-part message in MIME format. ------_=_NextPart_001_01C52DE9.9D3F955E Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Add an MSI test to make sure MSI is working at the system level. If the = test fails, the driver will go back to INTx mode. Signed-off-by: Michael Chan ------_=_NextPart_001_01C52DE9.9D3F955E Content-Type: application/octet-stream; name=tg3-4.patch Content-Transfer-Encoding: base64 Content-Description: tg3-4.patch Content-Disposition: attachment; filename=tg3-4.patch ZGlmZiAtTnJ1IDQvZHJpdmVycy9uZXQvdGczLmMgNS9kcml2ZXJzL25ldC90ZzMuYwotLS0gNC9k cml2ZXJzL25ldC90ZzMuYwkyMDA1LTAzLTE1IDIwOjQxOjUxLjAwMDAwMDAwMCAtMDgwMAorKysg NS9kcml2ZXJzL25ldC90ZzMuYwkyMDA1LTAzLTE3IDE3OjE1OjQwLjAwMDAwMDAwMCAtMDgwMApA QCAtMjk2NSw2ICsyOTY1LDIyIEBACiAJcmV0dXJuIElSUV9SRVRWQUwoaGFuZGxlZCk7CiB9CiAK Ky8qIElTUiBmb3IgaW50ZXJydXB0IHRlc3QgKi8KK3N0YXRpYyBpcnFyZXR1cm5fdCB0ZzNfdGVz dF9pc3IoaW50IGlycSwgdm9pZCAqZGV2X2lkLAorCQlzdHJ1Y3QgcHRfcmVncyAqcmVncykKK3sK KwlzdHJ1Y3QgbmV0X2RldmljZSAqZGV2ID0gZGV2X2lkOworCXN0cnVjdCB0ZzMgKnRwID0gbmV0 ZGV2X3ByaXYoZGV2KTsKKwlzdHJ1Y3QgdGczX2h3X3N0YXR1cyAqc2JsayA9IHRwLT5od19zdGF0 dXM7CisKKwlpZiAoc2Jsay0+c3RhdHVzICYgU0RfU1RBVFVTX1VQREFURUQpIHsKKwkJdHczMl9t YWlsYm94KE1BSUxCT1hfSU5URVJSVVBUXzAgKyBURzNfNjRCSVRfUkVHX0xPVywKKwkJCSAgICAg MHgwMDAwMDAwMSk7CisJCXJldHVybiBJUlFfUkVUVkFMKDEpOworCX0KKwlyZXR1cm4gSVJRX1JF VFZBTCgwKTsKK30KKwogc3RhdGljIGludCB0ZzNfaW5pdF9odyhzdHJ1Y3QgdGczICopOwogc3Rh dGljIGludCB0ZzNfaGFsdChzdHJ1Y3QgdGczICopOwogCkBAIC01NzE4LDYgKzU3MzQsMTEzIEBA CiAJYWRkX3RpbWVyKCZ0cC0+dGltZXIpOwogfQogCitzdGF0aWMgaW50IHRnM190ZXN0X2ludGVy cnVwdChzdHJ1Y3QgdGczICp0cCkKK3sKKwlzdHJ1Y3QgbmV0X2RldmljZSAqZGV2ID0gdHAtPmRl djsKKwlpbnQgZXJyLCBpOworCXUzMiBpbnRfbWJveCA9IDA7CisKKwl0ZzNfZGlzYWJsZV9pbnRz KHRwKTsKKworCWZyZWVfaXJxKHRwLT5wZGV2LT5pcnEsIGRldik7CisKKwllcnIgPSByZXF1ZXN0 X2lycSh0cC0+cGRldi0+aXJxLCB0ZzNfdGVzdF9pc3IsCisJCQkgIFNBX1NISVJRLCBkZXYtPm5h bWUsIGRldik7CisJaWYgKGVycikKKwkJcmV0dXJuIGVycjsKKworCXRnM19lbmFibGVfaW50cyh0 cCk7CisKKwl0dzMyX2YoSE9TVENDX01PREUsIHRwLT5jb2FsZXNjZV9tb2RlIHwgSE9TVENDX01P REVfRU5BQkxFIHwKKwkgICAgICAgSE9TVENDX01PREVfTk9XKTsKKworCWZvciAoaSA9IDA7IGkg PCA1OyBpKyspIHsKKwkJaW50X21ib3ggPSB0cjMyKE1BSUxCT1hfSU5URVJSVVBUXzAgKyBURzNf NjRCSVRfUkVHX0xPVyk7CisJCWlmIChpbnRfbWJveCAhPSAwKQorCQkJYnJlYWs7CisJCW1zbGVl cCgxMCk7CisJfQorCisJdGczX2Rpc2FibGVfaW50cyh0cCk7CisKKwlmcmVlX2lycSh0cC0+cGRl di0+aXJxLCBkZXYpOworCQorCWlmICh0cC0+dGczX2ZsYWdzMiAmIFRHM19GTEcyX1VTSU5HX01T SSkKKwkJZXJyID0gcmVxdWVzdF9pcnEodHAtPnBkZXYtPmlycSwgdGczX21zaSwKKwkJCQkgIDAs IGRldi0+bmFtZSwgZGV2KTsKKwllbHNlCisJCWVyciA9IHJlcXVlc3RfaXJxKHRwLT5wZGV2LT5p cnEsIHRnM19pbnRlcnJ1cHQsCisJCQkJICBTQV9TSElSUSwgZGV2LT5uYW1lLCBkZXYpOworCisJ aWYgKGVycikKKwkJcmV0dXJuIGVycjsKKworCWlmIChpbnRfbWJveCAhPSAwKQorCQlyZXR1cm4g MDsKKworCXJldHVybiAtRUlPOworfQorCisvKiBSZXR1cm5zIDAgaWYgTVNJIHRlc3Qgc3VjY2Vl ZHMgb3IgTVNJIHRlc3QgZmFpbHMgYW5kIElOVHggbW9kZSBpcworICogc3VjY2Vzc2Z1bGx5IHJl c3RvcmVkCisgKi8KK3N0YXRpYyBpbnQgdGczX3Rlc3RfbXNpKHN0cnVjdCB0ZzMgKnRwKQorewor CXN0cnVjdCBuZXRfZGV2aWNlICpkZXYgPSB0cC0+ZGV2OworCWludCBlcnI7CisJdTE2IHBjaV9j bWQ7CisKKwlpZiAoISh0cC0+dGczX2ZsYWdzMiAmIFRHM19GTEcyX1VTSU5HX01TSSkpCisJCXJl dHVybiAwOworCisJLyogVHVybiBvZmYgU0VSUiByZXBvcnRpbmcgaW4gY2FzZSBNU0kgdGVybWlu YXRlcyB3aXRoIE1hc3RlcgorCSAqIEFib3J0LgorCSAqLworCXBjaV9yZWFkX2NvbmZpZ193b3Jk KHRwLT5wZGV2LCBQQ0lfQ09NTUFORCwgJnBjaV9jbWQpOworCXBjaV93cml0ZV9jb25maWdfd29y ZCh0cC0+cGRldiwgUENJX0NPTU1BTkQsCisJCQkgICAgICBwY2lfY21kICYgflBDSV9DT01NQU5E X1NFUlIpOworCisJZXJyID0gdGczX3Rlc3RfaW50ZXJydXB0KHRwKTsKKworCXBjaV93cml0ZV9j b25maWdfd29yZCh0cC0+cGRldiwgUENJX0NPTU1BTkQsIHBjaV9jbWQpOworCisJaWYgKCFlcnIp CisJCXJldHVybiAwOworCisJLyogb3RoZXIgZmFpbHVyZXMgKi8KKwlpZiAoZXJyICE9IC1FSU8p CisJCXJldHVybiBlcnI7CisKKwkvKiBNU0kgdGVzdCBmYWlsZWQsIGdvIGJhY2sgdG8gSU5UeCBt b2RlICovCisJZnJlZV9pcnEodHAtPnBkZXYtPmlycSwgZGV2KTsKKwlwY2lfZGlzYWJsZV9tc2ko dHAtPnBkZXYpOworCisJdHAtPnRnM19mbGFnczIgJj0gflRHM19GTEcyX1VTSU5HX01TSTsKKwor CWVyciA9IHJlcXVlc3RfaXJxKHRwLT5wZGV2LT5pcnEsIHRnM19pbnRlcnJ1cHQsCisJCQkgIFNB X1NISVJRLCBkZXYtPm5hbWUsIGRldik7CisKKwlpZiAoZXJyKQorCQlyZXR1cm4gZXJyOworCisJ LyogTmVlZCB0byByZXNldCB0aGUgY2hpcCBiZWNhdXNlIHRoZSBNU0kgY3ljbGUgbWF5IGhhdmUg dGVybWluYXRlZAorCSAqIHdpdGggTWFzdGVyIEFib3J0LgorCSAqLworCXNwaW5fbG9ja19pcnEo JnRwLT5sb2NrKTsKKwlzcGluX2xvY2soJnRwLT50eF9sb2NrKTsKKworCXRnM19oYWx0KHRwKTsK KwllcnIgPSB0ZzNfaW5pdF9odyh0cCk7CisKKwlzcGluX3VubG9jaygmdHAtPnR4X2xvY2spOwor CXNwaW5fdW5sb2NrX2lycSgmdHAtPmxvY2spOworCisJaWYgKGVycikKKwkJZnJlZV9pcnEodHAt PnBkZXYtPmlycSwgZGV2KTsKKworCXJldHVybiBlcnI7Cit9CisKIHN0YXRpYyBpbnQgdGczX29w ZW4oc3RydWN0IG5ldF9kZXZpY2UgKmRldikKIHsKIAlzdHJ1Y3QgdGczICp0cCA9IG5ldGRldl9w cml2KGRldik7CkBAIC01NzgyLDkgKzU5MDUsNiBAQAogCQl0cC0+dGltZXIuZXhwaXJlcyA9IGpp ZmZpZXMgKyB0cC0+dGltZXJfb2Zmc2V0OwogCQl0cC0+dGltZXIuZGF0YSA9ICh1bnNpZ25lZCBs b25nKSB0cDsKIAkJdHAtPnRpbWVyLmZ1bmN0aW9uID0gdGczX3RpbWVyOwotCQlhZGRfdGltZXIo JnRwLT50aW1lcik7Ci0KLQkJdHAtPnRnM19mbGFncyB8PSBURzNfRkxBR19JTklUX0NPTVBMRVRF OwogCX0KIAogCXNwaW5fdW5sb2NrKCZ0cC0+dHhfbG9jayk7CkBAIC01ODAwLDkgKzU5MjAsMzIg QEAKIAkJcmV0dXJuIGVycjsKIAl9CiAKKwlpZiAodHAtPnRnM19mbGFnczIgJiBURzNfRkxHMl9V U0lOR19NU0kpIHsKKwkJZXJyID0gdGczX3Rlc3RfbXNpKHRwKTsKKwkJaWYgKGVycikgeworCQkJ c3Bpbl9sb2NrX2lycSgmdHAtPmxvY2spOworCQkJc3Bpbl9sb2NrKCZ0cC0+dHhfbG9jayk7CisK KwkJCWlmICh0cC0+dGczX2ZsYWdzMiAmIFRHM19GTEcyX1VTSU5HX01TSSkgeworCQkJCXBjaV9k aXNhYmxlX21zaSh0cC0+cGRldik7CisJCQkJdHAtPnRnM19mbGFnczIgJj0gflRHM19GTEcyX1VT SU5HX01TSTsKKwkJCX0KKwkJCXRnM19oYWx0KHRwKTsKKwkJCXRnM19mcmVlX3JpbmdzKHRwKTsK KwkJCXRnM19mcmVlX2NvbnNpc3RlbnQodHApOworCisJCQlzcGluX3VubG9jaygmdHAtPnR4X2xv Y2spOworCQkJc3Bpbl91bmxvY2tfaXJxKCZ0cC0+bG9jayk7CisKKwkJCXJldHVybiBlcnI7CisJ CX0KKwl9CisKIAlzcGluX2xvY2tfaXJxKCZ0cC0+bG9jayk7CiAJc3Bpbl9sb2NrKCZ0cC0+dHhf bG9jayk7CiAKKwlhZGRfdGltZXIoJnRwLT50aW1lcik7CisJdHAtPnRnM19mbGFncyB8PSBURzNf RkxBR19JTklUX0NPTVBMRVRFOwogCXRnM19lbmFibGVfaW50cyh0cCk7CiAKIAlzcGluX3VubG9j aygmdHAtPnR4X2xvY2spOwo= ------_=_NextPart_001_01C52DE9.9D3F955E-- From mchan@broadcom.com Sun Mar 20 23:48:29 2005 Received: with ECARTIS (v1.0.0; list netdev); Sun, 20 Mar 2005 23:48:34 -0800 (PST) Received: from MMS3.broadcom.com (mms3.broadcom.com [216.31.210.19]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j2L7mTSn024041 for ; Sun, 20 Mar 2005 23:48:29 -0800 Received: from 10.10.64.121 by MMS3.broadcom.com with SMTP (Broadcom SMTP Relay (Email Firewall v6.1.0)); Sun, 20 Mar 2005 23:48:15 -0800 X-Server-Uuid: 35E76369-CF33-4172-911A-D1698BD5E887 Received: from mail-irva-8.broadcom.com ([10.10.64.221]) by mail-irva-1.broadcom.com (Post.Office MTA v3.5.3 release 223 ID# 0-72233U7200L2200S0V35) with ESMTP id com; Sun, 20 Mar 2005 23:48:15 -0800 Received: from mon-irva-10.broadcom.com (mon-irva-10.broadcom.com [10.10.64.171]) by mail-irva-8.broadcom.com (MOS 3.5.6-GR) with ESMTP id APJ70320; Sun, 20 Mar 2005 23:48:14 -0800 (PST) Received: from nt-irva-0741.brcm.ad.broadcom.com ( nt-irva-0741.brcm.ad.broadcom.com [10.8.194.54]) by mon-irva-10.broadcom.com (8.9.1/8.9.1) with ESMTP id XAA09987; Sun, 20 Mar 2005 23:48:13 -0800 (PST) X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Subject: [PATCH 2.6.11 5/8] tg3: Add unstable PLL workaround for 5750 Date: Sun, 20 Mar 2005 23:48:13 -0800 Message-ID: X-MS-Has-Attach: yes Thread-Topic: [PATCH 2.6.11 5/8] tg3: Add unstable PLL workaround for 5750 Thread-Index: AcUQenBthEVwCOEDSUG7grDnD7JTOgdadRIAAABhWpAAAGS18AAARWAgAABS6GA= From: "Michael Chan" To: "David S. Miller" cc: netdev@oss.sgi.com X-WSS-ID: 6E20A3B525S1858747-01-01 Content-Type: multipart/mixed; boundary="----_=_NextPart_001_01C52DEA.55A920F9" X-Virus-Scanned: ClamAV 0.83/774/Fri Mar 18 17:04:06 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 421 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: mchan@broadcom.com Precedence: bulk X-list: netdev Content-Length: 1865 Lines: 41 This is a multi-part message in MIME format. ------_=_NextPart_001_01C52DEA.55A920F9 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Add unstable PLL clock workaround for 5750 Ax and Bx devices. The = workaround code is run just before entering D3hot state. Signed-off-by: Michael Chan ------_=_NextPart_001_01C52DEA.55A920F9 Content-Type: application/octet-stream; name=tg3-5.patch Content-Transfer-Encoding: base64 Content-Description: tg3-5.patch Content-Disposition: attachment; filename=tg3-5.patch ZGlmZiAtTnJ1IDUvZHJpdmVycy9uZXQvdGczLmMgNi9kcml2ZXJzL25ldC90ZzMuYwotLS0gNS9k cml2ZXJzL25ldC90ZzMuYwkyMDA1LTAzLTE3IDE3OjE1OjQwLjAwMDAwMDAwMCAtMDgwMAorKysg Ni9kcml2ZXJzL25ldC90ZzMuYwkyMDA1LTAzLTE3IDE4OjUxOjM4LjAwMDAwMDAwMCAtMDgwMApA QCAtOTY2LDYgKzk2Niw3IEBACiAjZGVmaW5lIFJFU0VUX0tJTkRfU1VTUEVORAkyCiAKIHN0YXRp YyB2b2lkIHRnM193cml0ZV9zaWdfcG9zdF9yZXNldChzdHJ1Y3QgdGczICosIGludCk7CitzdGF0 aWMgaW50IHRnM19oYWx0X2NwdShzdHJ1Y3QgdGczICosIHUzMik7CiAKIHN0YXRpYyBpbnQgdGcz X3NldF9wb3dlcl9zdGF0ZShzdHJ1Y3QgdGczICp0cCwgaW50IHN0YXRlKQogewpAQCAtMTEyNCw2 ICsxMTI1LDE3IEBACiAKIAl0ZzNfZnJvYl9hdXhfcG93ZXIodHApOwogCisJLyogV29ya2Fyb3Vu ZCBmb3IgdW5zdGFibGUgUExMIGNsb2NrICovCisJaWYgKChHRVRfQ0hJUF9SRVYodHAtPnBjaV9j aGlwX3Jldl9pZCkgPT0gQ0hJUFJFVl81NzUwX0FYKSB8fAorCSAgICAoR0VUX0NISVBfUkVWKHRw LT5wY2lfY2hpcF9yZXZfaWQpID09IENISVBSRVZfNTc1MF9CWCkpIHsKKwkJdTMyIHZhbCA9IHRy MzIoMHg3ZDAwKTsKKworCQl2YWwgJj0gfigoMSA8PCAxNikgfCAoMSA8PCA0KSB8ICgxIDw8IDIp IHwgKDEgPDwgMSkgfCAxKTsKKwkJdHczMigweDdkMDAsIHZhbCk7CisJCWlmICghKHRwLT50ZzNf ZmxhZ3MgJiBURzNfRkxBR19FTkFCTEVfQVNGKSkKKwkJCXRnM19oYWx0X2NwdSh0cCwgUlhfQ1BV X0JBU0UpOworCX0KKwogCS8qIEZpbmFsbHksIHNldCB0aGUgbmV3IHBvd2VyIHN0YXRlLiAqLwog CXBjaV93cml0ZV9jb25maWdfd29yZCh0cC0+cGRldiwgcG0gKyBQQ0lfUE1fQ1RSTCwgcG93ZXJf Y29udHJvbCk7CiAK ------_=_NextPart_001_01C52DEA.55A920F9-- From mchan@broadcom.com Mon Mar 21 00:02:30 2005 Received: with ECARTIS (v1.0.0; list netdev); Mon, 21 Mar 2005 00:02:36 -0800 (PST) Received: from MMS1.broadcom.com (mms1.broadcom.com [216.31.210.17]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j2L82UaY026090 for ; Mon, 21 Mar 2005 00:02:30 -0800 Received: from 10.10.64.121 by MMS1.broadcom.com with SMTP (Broadcom SMTP Relay (Email Firewall v6.1.0)); Mon, 21 Mar 2005 00:02:11 -0800 X-Server-Uuid: 146C3151-C1DE-4F71-9D02-C3BE503878DD Received: from mail-irva-8.broadcom.com ([10.10.64.221]) by mail-irva-1.broadcom.com (Post.Office MTA v3.5.3 release 223 ID# 0-72233U7200L2200S0V35) with ESMTP id com; Mon, 21 Mar 2005 00:02:10 -0800 Received: from mon-irva-10.broadcom.com (mon-irva-10.broadcom.com [10.10.64.171]) by mail-irva-8.broadcom.com (MOS 3.5.6-GR) with ESMTP id APJ71871; Mon, 21 Mar 2005 00:02:03 -0800 (PST) Received: from nt-irva-0741.brcm.ad.broadcom.com ( nt-irva-0741.brcm.ad.broadcom.com [10.8.194.54]) by mon-irva-10.broadcom.com (8.9.1/8.9.1) with ESMTP id AAA11548; Mon, 21 Mar 2005 00:02:03 -0800 (PST) X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Subject: [PATCH 2.6.11 6/8] tg3: Fix jumbo frames phy settings Date: Mon, 21 Mar 2005 00:02:02 -0800 Message-ID: X-MS-Has-Attach: yes Thread-Topic: [PATCH 2.6.11 6/8] tg3: Fix jumbo frames phy settings Thread-Index: AcUQenBthEVwCOEDSUG7grDnD7JTOgdadRIAAABhWpAAAGS18AAARWAgAABS6GAAACdocA== From: "Michael Chan" To: "David S. Miller" cc: netdev@oss.sgi.com X-WSS-ID: 6E20A0092982023288-01-01 Content-Type: multipart/mixed; boundary="----_=_NextPart_001_01C52DEC.440131E7" X-Virus-Scanned: ClamAV 0.83/774/Fri Mar 18 17:04:06 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 422 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: mchan@broadcom.com Precedence: bulk X-list: netdev Content-Length: 2364 Lines: 48 This is a multi-part message in MIME format. ------_=_NextPart_001_01C52DEC.440131E7 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Fix jumbo frame settings on all copper phys that support jumbo frames by setting the fifo elasticity bit. This setting is for the phy's tx fifo = to properly handle jumbo frames. Note that a similar jumbo frame fix for = the phy's rx fifo was made to tg3 in the past. Signed-off-by: Michael Chan ------_=_NextPart_001_01C52DEC.440131E7 Content-Type: application/octet-stream; name=tg3-6.patch Content-Transfer-Encoding: base64 Content-Description: tg3-6.patch Content-Disposition: attachment; filename=tg3-6.patch ZGlmZiAtTnJ1IDYvZHJpdmVycy9uZXQvdGczLmMgNy9kcml2ZXJzL25ldC90ZzMuYwotLS0gNi9k cml2ZXJzL25ldC90ZzMuYwkyMDA1LTAzLTE3IDE4OjUxOjM4LjAwMDAwMDAwMCAtMDgwMAorKysg Ny9kcml2ZXJzL25ldC90ZzMuYwkyMDA1LTAzLTE4IDE2OjQxOjU5LjAwMDAwMDAwMCAtMDgwMApA QCAtODY4LDYgKzg2OCwxOSBAQAogCQkgICAgIXRnM19yZWFkcGh5KHRwLCBNSUlfVEczX0FVWF9D VFJMLCAmcGh5X3JlZykpCiAJCQl0ZzNfd3JpdGVwaHkodHAsIE1JSV9URzNfQVVYX0NUUkwsIHBo eV9yZWcgfCAweDQwMDApOwogCX0KKworCS8qIFNldCBwaHkgcmVnaXN0ZXIgMHgxMCBiaXQgMCB0 byBoaWdoIGZpZm8gZWxhc3RpY2l0eSB0byBzdXBwb3J0CisJICoganVtYm8gZnJhbWVzIHRyYW5z bWlzc2lvbi4KKwkgKi8KKwlpZiAoR0VUX0FTSUNfUkVWKHRwLT5wY2lfY2hpcF9yZXZfaWQpICE9 IEFTSUNfUkVWXzU3MDUgJiYKKwkgICAgR0VUX0FTSUNfUkVWKHRwLT5wY2lfY2hpcF9yZXZfaWQp ICE9IEFTSUNfUkVWXzU3NTApIHsKKwkJdTMyIHBoeV9yZWc7CisKKwkJaWYgKCF0ZzNfcmVhZHBo eSh0cCwgTUlJX1RHM19FWFRfQ1RSTCwgJnBoeV9yZWcpKQorCQkgICAgdGczX3dyaXRlcGh5KHRw LCBNSUlfVEczX0VYVF9DVFJMLAorCQkJCSBwaHlfcmVnIHwgTUlJX1RHM19FWFRfQ1RSTF9GSUZP X0VMQVNUSUMpOworCX0KKwogCXRnM19waHlfc2V0X3dpcmVzcGVlZCh0cCk7CiAJcmV0dXJuIDA7 CiB9CmRpZmYgLU5ydSA2L2RyaXZlcnMvbmV0L3RnMy5oIDcvZHJpdmVycy9uZXQvdGczLmgKLS0t IDYvZHJpdmVycy9uZXQvdGczLmgJMjAwNS0wMy0xNyAxODo1MTo0Mi4wMDAwMDAwMDAgLTA4MDAK KysrIDcvZHJpdmVycy9uZXQvdGczLmgJMjAwNS0wMy0xOCAxNjo0MjowMy4wMDAwMDAwMDAgLTA4 MDAKQEAgLTE1MTgsNiArMTUxOCw3IEBACiAjZGVmaW5lICBNSUlfVEczX0NUUkxfRU5BQkxFX0FT X01BU1RFUgkweDEwMDAKIAogI2RlZmluZSBNSUlfVEczX0VYVF9DVFJMCQkweDEwIC8qIEV4dGVu ZGVkIGNvbnRyb2wgcmVnaXN0ZXIgKi8KKyNkZWZpbmUgIE1JSV9URzNfRVhUX0NUUkxfRklGT19F TEFTVElDCTB4MDAwMQogI2RlZmluZSAgTUlJX1RHM19FWFRfQ1RSTF9MTkszX0xFRF9NT0RFCTB4 MDAwMgogI2RlZmluZSAgTUlJX1RHM19FWFRfQ1RSTF9UQkkJCTB4ODAwMAogCg== ------_=_NextPart_001_01C52DEC.440131E7-- From mchan@broadcom.com Mon Mar 21 00:13:44 2005 Received: with ECARTIS (v1.0.0; list netdev); Mon, 21 Mar 2005 00:13:52 -0800 (PST) Received: from MMS1.broadcom.com (mms1.broadcom.com [216.31.210.17]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j2L8Dg3C027515 for ; Mon, 21 Mar 2005 00:13:44 -0800 Received: from 10.10.64.121 by MMS1.broadcom.com with SMTP (Broadcom SMTP Relay (Email Firewall v6.1.0)); Mon, 21 Mar 2005 00:13:14 -0800 X-Server-Uuid: 146C3151-C1DE-4F71-9D02-C3BE503878DD Received: from mail-irva-8.broadcom.com ([10.10.64.221]) by mail-irva-1.broadcom.com (Post.Office MTA v3.5.3 release 223 ID# 0-72233U7200L2200S0V35) with ESMTP id com; Mon, 21 Mar 2005 00:13:14 -0800 Received: from mon-irva-10.broadcom.com (mon-irva-10.broadcom.com [10.10.64.171]) by mail-irva-8.broadcom.com (MOS 3.5.6-GR) with ESMTP id APJ72935; Mon, 21 Mar 2005 00:13:08 -0800 (PST) Received: from nt-irva-0741.brcm.ad.broadcom.com ( nt-irva-0741.brcm.ad.broadcom.com [10.8.194.54]) by mon-irva-10.broadcom.com (8.9.1/8.9.1) with ESMTP id AAA12437; Mon, 21 Mar 2005 00:13:08 -0800 (PST) X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Subject: [PATCH 2.6.11 7/8] tg3: Fix ethtool set functions Date: Mon, 21 Mar 2005 00:13:07 -0800 Message-ID: X-MS-Has-Attach: yes Thread-Topic: [PATCH 2.6.11 7/8] tg3: Fix ethtool set functions Thread-Index: AcUQenBthEVwCOEDSUG7grDnD7JTOgdadRIAAABhWpAAAGS18AAARWAgAABS6GAAACdocAAAfVFQ From: "Michael Chan" To: "David S. Miller" cc: netdev@oss.sgi.com X-WSS-ID: 6E205D902982025237-01-01 Content-Type: multipart/mixed; boundary="----_=_NextPart_001_01C52DED.D05F7E27" X-Virus-Scanned: ClamAV 0.83/774/Fri Mar 18 17:04:06 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 423 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: mchan@broadcom.com Precedence: bulk X-list: netdev Content-Length: 4435 Lines: 77 This is a multi-part message in MIME format. ------_=_NextPart_001_01C52DED.D05F7E27 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Fix all relevant ethtool set functions to properly handle the !netif_running() case. In most cases, the new settings are accepted = without setting the hardware if !netif_running(). The new settings will take = effect when the device is subsequently brought up. tg3_nway_reset() is the = exception where it will return -EAGAIN if !netif_running(). Signed-off-by: Michael Chan ------_=_NextPart_001_01C52DED.D05F7E27 Content-Type: application/octet-stream; name=tg3-7.patch Content-Transfer-Encoding: base64 Content-Description: tg3-7.patch Content-Disposition: attachment; filename=tg3-7.patch ZGlmZiAtTnJ1IDcvZHJpdmVycy9uZXQvdGczLmMgOC9kcml2ZXJzL25ldC90ZzMuYwotLS0gNy9k cml2ZXJzL25ldC90ZzMuYwkyMDA1LTAzLTE4IDE2OjQxOjU5LjAwMDAwMDAwMCAtMDgwMAorKysg OC9kcml2ZXJzL25ldC90ZzMuYwkyMDA1LTAzLTIwIDIxOjUxOjUzLjAwMDAwMDAwMCAtMDgwMApA QCAtNjc1MywxMCArNjc1Myw2IEBACiB7CiAgIAlzdHJ1Y3QgdGczICp0cCA9IG5ldGRldl9wcml2 KGRldik7CiAgIAotCWlmICghKHRwLT50ZzNfZmxhZ3MgJiBURzNfRkxBR19JTklUX0NPTVBMRVRF KSB8fAotCQkJCQl0cC0+bGlua19jb25maWcucGh5X2lzX2xvd19wb3dlcikKLQkJcmV0dXJuIC1F QUdBSU47Ci0KIAljbWQtPnN1cHBvcnRlZCA9IChTVVBQT1JURURfQXV0b25lZyk7CiAKIAlpZiAo ISh0cC0+dGczX2ZsYWdzICYgVEczX0ZMQUdfMTBfMTAwX09OTFkpKQpAQCAtNjc3Myw4ICs2NzY5 LDEwIEBACiAJCWNtZC0+c3VwcG9ydGVkIHw9IFNVUFBPUlRFRF9GSUJSRTsKICAgCiAJY21kLT5h ZHZlcnRpc2luZyA9IHRwLT5saW5rX2NvbmZpZy5hZHZlcnRpc2luZzsKLQljbWQtPnNwZWVkID0g dHAtPmxpbmtfY29uZmlnLmFjdGl2ZV9zcGVlZDsKLQljbWQtPmR1cGxleCA9IHRwLT5saW5rX2Nv bmZpZy5hY3RpdmVfZHVwbGV4OworCWlmIChuZXRpZl9ydW5uaW5nKGRldikpIHsKKwkJY21kLT5z cGVlZCA9IHRwLT5saW5rX2NvbmZpZy5hY3RpdmVfc3BlZWQ7CisJCWNtZC0+ZHVwbGV4ID0gdHAt PmxpbmtfY29uZmlnLmFjdGl2ZV9kdXBsZXg7CisJfQogCWNtZC0+cG9ydCA9IDA7CiAJY21kLT5w aHlfYWRkcmVzcyA9IFBIWV9BRERSOwogCWNtZC0+dHJhbnNjZWl2ZXIgPSAwOwpAQCAtNjc4OCwx MCArNjc4Niw2IEBACiB7CiAJc3RydWN0IHRnMyAqdHAgPSBuZXRkZXZfcHJpdihkZXYpOwogICAK LQlpZiAoISh0cC0+dGczX2ZsYWdzICYgVEczX0ZMQUdfSU5JVF9DT01QTEVURSkgfHwKLQkgICAg dHAtPmxpbmtfY29uZmlnLnBoeV9pc19sb3dfcG93ZXIpCi0JCXJldHVybiAtRUFHQUlOOwotCiAJ aWYgKHRwLT50ZzNfZmxhZ3MyICYgVEczX0ZMRzJfUEhZX1NFUkRFUykgewogCQkvKiBUaGVzZSBh cmUgdGhlIG9ubHkgdmFsaWQgYWR2ZXJ0aXNlbWVudCBiaXRzIGFsbG93ZWQuICAqLwogCQlpZiAo Y21kLT5hdXRvbmVnID09IEFVVE9ORUdfRU5BQkxFICYmCkBAIC02ODE2LDcgKzY4MTAsOSBAQAog CQl0cC0+bGlua19jb25maWcuZHVwbGV4ID0gY21kLT5kdXBsZXg7CiAgIAl9CiAgIAotCXRnM19z ZXR1cF9waHkodHAsIDEpOworCWlmIChuZXRpZl9ydW5uaW5nKGRldikpCisJCXRnM19zZXR1cF9w aHkodHAsIDEpOworCiAJc3Bpbl91bmxvY2soJnRwLT50eF9sb2NrKTsKIAlzcGluX3VubG9ja19p cnEoJnRwLT5sb2NrKTsKICAgCkBAIC02ODk2LDYgKzY4OTIsOSBAQAogCXUzMiBibWNyOwogCWlu dCByOwogICAKKwlpZiAoIW5ldGlmX3J1bm5pbmcoZGV2KSkKKwkJcmV0dXJuIC1FQUdBSU47CisK IAlzcGluX2xvY2tfaXJxKCZ0cC0+bG9jayk7CiAJciA9IC1FSU5WQUw7CiAJdGczX3JlYWRwaHko dHAsIE1JSV9CTUNSLCAmYm1jcik7CkBAIC02OTMyLDcgKzY5MzEsOSBAQAogCSAgICAoZXJpbmct PnR4X3BlbmRpbmcgPiBURzNfVFhfUklOR19TSVpFIC0gMSkpCiAJCXJldHVybiAtRUlOVkFMOwog ICAKLQl0ZzNfbmV0aWZfc3RvcCh0cCk7CisJaWYgKG5ldGlmX3J1bm5pbmcoZGV2KSkKKwkJdGcz X25ldGlmX3N0b3AodHApOworCiAJc3Bpbl9sb2NrX2lycSgmdHAtPmxvY2spOwogCXNwaW5fbG9j aygmdHAtPnR4X2xvY2spOwogICAKQEAgLTY5NDQsOSArNjk0NSwxMiBAQAogCXRwLT5yeF9qdW1i b19wZW5kaW5nID0gZXJpbmctPnJ4X2p1bWJvX3BlbmRpbmc7CiAJdHAtPnR4X3BlbmRpbmcgPSBl cmluZy0+dHhfcGVuZGluZzsKIAotCXRnM19oYWx0KHRwKTsKLQl0ZzNfaW5pdF9odyh0cCk7Ci0J dGczX25ldGlmX3N0YXJ0KHRwKTsKKwlpZiAobmV0aWZfcnVubmluZyhkZXYpKSB7CisJCXRnM19o YWx0KHRwKTsKKwkJdGczX2luaXRfaHcodHApOworCQl0ZzNfbmV0aWZfc3RhcnQodHApOworCX0K KwogCXNwaW5fdW5sb2NrKCZ0cC0+dHhfbG9jayk7CiAJc3Bpbl91bmxvY2tfaXJxKCZ0cC0+bG9j ayk7CiAgIApAQCAtNjk2Niw3ICs2OTcwLDkgQEAKIHsKIAlzdHJ1Y3QgdGczICp0cCA9IG5ldGRl dl9wcml2KGRldik7CiAgIAotCXRnM19uZXRpZl9zdG9wKHRwKTsKKwlpZiAobmV0aWZfcnVubmlu ZyhkZXYpKQorCQl0ZzNfbmV0aWZfc3RvcCh0cCk7CisKIAlzcGluX2xvY2tfaXJxKCZ0cC0+bG9j ayk7CiAJc3Bpbl9sb2NrKCZ0cC0+dHhfbG9jayk7CiAJaWYgKGVwYXVzZS0+YXV0b25lZykKQEAg LTY5ODEsOSArNjk4NywxMiBAQAogCQl0cC0+dGczX2ZsYWdzIHw9IFRHM19GTEFHX1RYX1BBVVNF OwogCWVsc2UKIAkJdHAtPnRnM19mbGFncyAmPSB+VEczX0ZMQUdfVFhfUEFVU0U7Ci0JdGczX2hh bHQodHApOwotCXRnM19pbml0X2h3KHRwKTsKLQl0ZzNfbmV0aWZfc3RhcnQodHApOworCisJaWYg KG5ldGlmX3J1bm5pbmcoZGV2KSkgeworCQl0ZzNfaGFsdCh0cCk7CisJCXRnM19pbml0X2h3KHRw KTsKKwkJdGczX25ldGlmX3N0YXJ0KHRwKTsKKwl9CiAJc3Bpbl91bmxvY2soJnRwLT50eF9sb2Nr KTsKIAlzcGluX3VubG9ja19pcnEoJnRwLT5sb2NrKTsKICAgCg== ------_=_NextPart_001_01C52DED.D05F7E27-- From mchan@broadcom.com Mon Mar 21 00:16:47 2005 Received: with ECARTIS (v1.0.0; list netdev); Mon, 21 Mar 2005 00:16:54 -0800 (PST) Received: from MMS1.broadcom.com (mms1.broadcom.com [216.31.210.17]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j2L8GlEZ028247 for ; Mon, 21 Mar 2005 00:16:47 -0800 Received: from 10.10.64.121 by MMS1.broadcom.com with SMTP (Broadcom SMTP Relay (Email Firewall v6.1.0)); Mon, 21 Mar 2005 00:16:35 -0800 X-Server-Uuid: 146C3151-C1DE-4F71-9D02-C3BE503878DD Received: from mail-irva-8.broadcom.com ([10.10.64.221]) by mail-irva-1.broadcom.com (Post.Office MTA v3.5.3 release 223 ID# 0-72233U7200L2200S0V35) with ESMTP id com; Mon, 21 Mar 2005 00:16:34 -0800 Received: from mon-irva-10.broadcom.com (mon-irva-10.broadcom.com [10.10.64.171]) by mail-irva-8.broadcom.com (MOS 3.5.6-GR) with ESMTP id APJ73419; Mon, 21 Mar 2005 00:16:32 -0800 (PST) Received: from nt-irva-0741.brcm.ad.broadcom.com ( nt-irva-0741.brcm.ad.broadcom.com [10.8.194.54]) by mon-irva-10.broadcom.com (8.9.1/8.9.1) with ESMTP id AAA12739; Mon, 21 Mar 2005 00:16:32 -0800 (PST) X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Subject: [PATCH 2.6.11 8/8] tg3: Add Broadcom copyright Date: Mon, 21 Mar 2005 00:16:31 -0800 Message-ID: X-MS-Has-Attach: yes Thread-Topic: [PATCH 2.6.11 8/8] tg3: Add Broadcom copyright Thread-Index: AcUQenBthEVwCOEDSUG7grDnD7JTOgdadRIAAABhWpAAAGS18AAARWAgAABS6GAAACdocAAAfVFQAABkM1A= From: "Michael Chan" To: "David S. Miller" cc: netdev@oss.sgi.com X-WSS-ID: 6E205D692982025868-01-01 Content-Type: multipart/mixed; boundary="----_=_NextPart_001_01C52DEE.4A222369" X-Virus-Scanned: ClamAV 0.83/774/Fri Mar 18 17:04:06 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 424 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: mchan@broadcom.com Precedence: bulk X-list: netdev Content-Length: 1180 Lines: 31 This is a multi-part message in MIME format. ------_=_NextPart_001_01C52DEE.4A222369 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Add Broadcom copyright. Signed-off-by: Michael Chan ------_=_NextPart_001_01C52DEE.4A222369 Content-Type: application/octet-stream; name=tg3-8.patch Content-Transfer-Encoding: base64 Content-Description: tg3-8.patch Content-Disposition: attachment; filename=tg3-8.patch ZGlmZiAtTnJ1IDgvZHJpdmVycy9uZXQvdGczLmMgOS9kcml2ZXJzL25ldC90ZzMuYwotLS0gOC9k cml2ZXJzL25ldC90ZzMuYwkyMDA1LTAzLTIwIDIxOjUxOjUzLjAwMDAwMDAwMCAtMDgwMAorKysg OS9kcml2ZXJzL25ldC90ZzMuYwkyMDA1LTAzLTIwIDIxOjUyOjQxLjAwMDAwMDAwMCAtMDgwMApA QCAtNCw2ICs0LDcgQEAKICAqIENvcHlyaWdodCAoQykgMjAwMSwgMjAwMiwgMjAwMywgMjAwNCBE YXZpZCBTLiBNaWxsZXIgKGRhdmVtQHJlZGhhdC5jb20pCiAgKiBDb3B5cmlnaHQgKEMpIDIwMDEs IDIwMDIsIDIwMDMgSmVmZiBHYXJ6aWsgKGpnYXJ6aWtAcG9ib3guY29tKQogICogQ29weXJpZ2h0 IChDKSAyMDA0IFN1biBNaWNyb3N5c3RlbXMgSW5jLgorICogQ29weXJpZ2h0IChDKSAyMDA1IEJy b2FkY29tIENvcnBvcmF0aW9uLgogICoKICAqIEZpcm13YXJlIGlzOgogICogCUNvcHlyaWdodCAo QykgMjAwMC0yMDAzIEJyb2FkY29tIENvcnBvcmF0aW9uLgo= ------_=_NextPart_001_01C52DEE.4A222369-- From ralf@linux-mips.org Mon Mar 21 01:50:39 2005 Received: with ECARTIS (v1.0.0; list netdev); Mon, 21 Mar 2005 01:50:44 -0800 (PST) Received: from mail.linux-mips.net (p3EE066C8.dip.t-dialin.net [62.224.102.200]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j2L9oa2H008940 for ; Mon, 21 Mar 2005 01:50:37 -0800 Received: from dea.linux-mips.net (localhost.localdomain [127.0.0.1]) by mail.linux-mips.net (8.13.1/8.13.1) with ESMTP id j2L9nAB5010195; Mon, 21 Mar 2005 09:49:10 GMT Received: (from ralf@localhost) by dea.linux-mips.net (8.13.1/8.13.1/Submit) id j2L9n5Ec010194; Mon, 21 Mar 2005 09:49:05 GMT Date: Mon, 21 Mar 2005 09:49:05 +0000 From: Ralf Baechle DL5RB To: netdev@oss.sgi.com, linux-hams@vger.kernel.org Cc: "David S. Miller" Subject: [PATCH] Get rid of sk_protinfo use in netrom Message-ID: <20050321094905.GA10022@linux-mips.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.4.1i X-Virus-Scanned: ClamAV 0.83/774/Fri Mar 18 17:04:06 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 425 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: ralf@linux-mips.org Precedence: bulk X-list: netdev Content-Length: 10733 Lines: 416 Below patch puts struct sock into nr_cb to get rid of the need for the use of sk_protinfo in nr_sk(). While we're touching the data structure convert it from a typedef into a struct. Index: bk-afu/net/netrom/nr_timer.c =================================================================== --- bk-afu.orig/net/netrom/nr_timer.c 2005-03-17 23:54:00.000000000 +0000 +++ bk-afu/net/netrom/nr_timer.c 2005-03-20 10:40:08.000000000 +0000 @@ -38,7 +38,7 @@ void nr_init_timers(struct sock *sk) { - nr_cb *nr = nr_sk(sk); + struct nr_sock *nr = nr_sk(sk); init_timer(&nr->t1timer); nr->t1timer.data = (unsigned long)sk; @@ -63,28 +63,28 @@ void nr_start_t1timer(struct sock *sk) { - nr_cb *nr = nr_sk(sk); + struct nr_sock *nr = nr_sk(sk); mod_timer(&nr->t1timer, jiffies + nr->t1); } void nr_start_t2timer(struct sock *sk) { - nr_cb *nr = nr_sk(sk); + struct nr_sock *nr = nr_sk(sk); mod_timer(&nr->t2timer, jiffies + nr->t2); } void nr_start_t4timer(struct sock *sk) { - nr_cb *nr = nr_sk(sk); + struct nr_sock *nr = nr_sk(sk); mod_timer(&nr->t4timer, jiffies + nr->t4); } void nr_start_idletimer(struct sock *sk) { - nr_cb *nr = nr_sk(sk); + struct nr_sock *nr = nr_sk(sk); if (nr->idle > 0) mod_timer(&nr->idletimer, jiffies + nr->idle); @@ -128,7 +128,7 @@ static void nr_heartbeat_expiry(unsigned long param) { struct sock *sk = (struct sock *)param; - nr_cb *nr = nr_sk(sk); + struct nr_sock *nr = nr_sk(sk); bh_lock_sock(sk); switch (nr->state) { @@ -167,7 +167,7 @@ static void nr_t2timer_expiry(unsigned long param) { struct sock *sk = (struct sock *)param; - nr_cb *nr = nr_sk(sk); + struct nr_sock *nr = nr_sk(sk); bh_lock_sock(sk); if (nr->condition & NR_COND_ACK_PENDING) { @@ -189,7 +189,7 @@ static void nr_idletimer_expiry(unsigned long param) { struct sock *sk = (struct sock *)param; - nr_cb *nr = nr_sk(sk); + struct nr_sock *nr = nr_sk(sk); bh_lock_sock(sk); @@ -217,7 +217,7 @@ static void nr_t1timer_expiry(unsigned long param) { struct sock *sk = (struct sock *)param; - nr_cb *nr = nr_sk(sk); + struct nr_sock *nr = nr_sk(sk); bh_lock_sock(sk); switch (nr->state) { Index: bk-afu/include/net/netrom.h =================================================================== --- bk-afu.orig/include/net/netrom.h 2005-03-19 20:00:15.000000000 +0000 +++ bk-afu/include/net/netrom.h 2005-03-20 10:36:50.000000000 +0000 @@ -55,7 +55,8 @@ #define NR_MAX_WINDOW_SIZE 127 /* Maximum Window Allowable - 127 */ #define NR_MAX_PACKET_SIZE 236 /* Maximum Packet Length - 236 */ -typedef struct { +struct nr_sock { + struct sock sock; ax25_address user_addr, source_addr, dest_addr; struct net_device *device; unsigned char my_index, my_id; @@ -72,10 +73,9 @@ struct sk_buff_head ack_queue; struct sk_buff_head reseq_queue; struct sk_buff_head frag_queue; - struct sock *sk; /* Backlink to socket */ -} nr_cb; +}; -#define nr_sk(__sk) ((nr_cb *)(__sk)->sk_protinfo) +#define nr_sk(sk) ((struct nr_sock *)(sk)) struct nr_neigh { struct hlist_node neigh_node; Index: bk-afu/net/netrom/af_netrom.c =================================================================== --- bk-afu.orig/net/netrom/af_netrom.c 2005-03-19 20:00:13.000000000 +0000 +++ bk-afu/net/netrom/af_netrom.c 2005-03-20 10:44:54.000000000 +0000 @@ -66,24 +66,7 @@ static struct sock *nr_alloc_sock(void) { - nr_cb *nr; - struct sock *sk = sk_alloc(PF_NETROM, GFP_ATOMIC, 1, NULL); - - if (!sk) - goto out; - - nr = sk->sk_protinfo = kmalloc(sizeof(*nr), GFP_ATOMIC); - if (!nr) - goto frees; - - memset(nr, 0x00, sizeof(*nr)); - nr->sk = sk; -out: - return sk; -frees: - sk_free(sk); - sk = NULL; - goto out; + return sk_alloc(PF_NETROM, GFP_ATOMIC, sizeof(struct nr_sock), NULL); } /* @@ -169,7 +152,7 @@ spin_lock_bh(&nr_list_lock); sk_for_each(s, node, &nr_list) { - nr_cb *nr = nr_sk(s); + struct nr_sock *nr = nr_sk(s); if (nr->my_index == index && nr->my_id == id) { bh_lock_sock(s); @@ -193,7 +176,7 @@ spin_lock_bh(&nr_list_lock); sk_for_each(s, node, &nr_list) { - nr_cb *nr = nr_sk(s); + struct nr_sock *nr = nr_sk(s); if (nr->your_index == index && nr->your_id == id && !ax25cmp(&nr->dest_addr, dest)) { @@ -300,7 +283,7 @@ char __user *optval, int optlen) { struct sock *sk = sock->sk; - nr_cb *nr = nr_sk(sk); + struct nr_sock *nr = nr_sk(sk); int opt; if (level != SOL_NETROM) @@ -352,7 +335,7 @@ char __user *optval, int __user *optlen) { struct sock *sk = sock->sk; - nr_cb *nr = nr_sk(sk); + struct nr_sock *nr = nr_sk(sk); int val = 0; int len; @@ -418,7 +401,7 @@ static int nr_create(struct socket *sock, int protocol) { struct sock *sk; - nr_cb *nr; + struct nr_sock *nr; if (sock->type != SOCK_SEQPACKET || protocol != 0) return -ESOCKTNOSUPPORT; @@ -456,7 +439,7 @@ static struct sock *nr_make_new(struct sock *osk) { struct sock *sk; - nr_cb *nr, *onr; + struct nr_sock *nr, *onr; if (osk->sk_type != SOCK_SEQPACKET) return NULL; @@ -508,7 +491,7 @@ static int nr_release(struct socket *sock) { struct sock *sk = sock->sk; - nr_cb *nr; + struct nr_sock *nr; if (sk == NULL) return 0; @@ -556,7 +539,7 @@ static int nr_bind(struct socket *sock, struct sockaddr *uaddr, int addr_len) { struct sock *sk = sock->sk; - nr_cb *nr = nr_sk(sk); + struct nr_sock *nr = nr_sk(sk); struct full_sockaddr_ax25 *addr = (struct full_sockaddr_ax25 *)uaddr; struct net_device *dev; ax25_address *user, *source; @@ -625,7 +608,7 @@ int addr_len, int flags) { struct sock *sk = sock->sk; - nr_cb *nr = nr_sk(sk); + struct nr_sock *nr = nr_sk(sk); struct sockaddr_ax25 *addr = (struct sockaddr_ax25 *)uaddr; ax25_address *user, *source = NULL; struct net_device *dev; @@ -822,7 +805,7 @@ { struct full_sockaddr_ax25 *sax = (struct full_sockaddr_ax25 *)uaddr; struct sock *sk = sock->sk; - nr_cb *nr = nr_sk(sk); + struct nr_sock *nr = nr_sk(sk); lock_sock(sk); if (peer != 0) { @@ -850,7 +833,7 @@ { struct sock *sk; struct sock *make; - nr_cb *nr_make; + struct nr_sock *nr_make; ax25_address *src, *dest, *user; unsigned short circuit_index, circuit_id; unsigned short peer_circuit_index, peer_circuit_id; @@ -1015,7 +998,7 @@ struct msghdr *msg, size_t len) { struct sock *sk = sock->sk; - nr_cb *nr = nr_sk(sk); + struct nr_sock *nr = nr_sk(sk); struct sockaddr_ax25 *usax = (struct sockaddr_ax25 *)msg->msg_name; int err; struct sockaddr_ax25 sax; @@ -1273,7 +1256,7 @@ { struct sock *s = v; struct net_device *dev; - nr_cb *nr; + struct nr_sock *nr; const char *devname; if (v == SEQ_START_TOKEN) Index: bk-afu/net/netrom/nr_in.c =================================================================== --- bk-afu.orig/net/netrom/nr_in.c 2005-03-17 23:53:59.000000000 +0000 +++ bk-afu/net/netrom/nr_in.c 2005-03-20 10:38:57.000000000 +0000 @@ -34,7 +34,7 @@ static int nr_queue_rx_frame(struct sock *sk, struct sk_buff *skb, int more) { struct sk_buff *skbo, *skbn = skb; - nr_cb *nr = nr_sk(sk); + struct nr_sock *nr = nr_sk(sk); skb_pull(skb, NR_NETWORK_LEN + NR_TRANSPORT_LEN); @@ -76,7 +76,7 @@ { switch (frametype) { case NR_CONNACK: { - nr_cb *nr = nr_sk(sk); + struct nr_sock *nr = nr_sk(sk); nr_stop_t1timer(sk); nr_start_idletimer(sk); @@ -138,7 +138,7 @@ */ static int nr_state3_machine(struct sock *sk, struct sk_buff *skb, int frametype) { - nr_cb *nrom = nr_sk(sk); + struct nr_sock *nrom = nr_sk(sk); struct sk_buff_head temp_queue; struct sk_buff *skbn; unsigned short save_vr; @@ -264,7 +264,7 @@ /* Higher level upcall for a LAPB frame - called with sk locked */ int nr_process_rx_frame(struct sock *sk, struct sk_buff *skb) { - nr_cb *nr = nr_sk(sk); + struct nr_sock *nr = nr_sk(sk); int queued = 0, frametype; if (nr->state == NR_STATE_0) Index: bk-afu/net/netrom/nr_subr.c =================================================================== --- bk-afu.orig/net/netrom/nr_subr.c 2005-03-17 23:54:00.000000000 +0000 +++ bk-afu/net/netrom/nr_subr.c 2005-03-20 10:39:42.000000000 +0000 @@ -34,7 +34,7 @@ */ void nr_clear_queues(struct sock *sk) { - nr_cb *nr = nr_sk(sk); + struct nr_sock *nr = nr_sk(sk); skb_queue_purge(&sk->sk_write_queue); skb_queue_purge(&nr->ack_queue); @@ -49,7 +49,7 @@ */ void nr_frames_acked(struct sock *sk, unsigned short nr) { - nr_cb *nrom = nr_sk(sk); + struct nr_sock *nrom = nr_sk(sk); struct sk_buff *skb; /* @@ -88,7 +88,7 @@ */ int nr_validate_nr(struct sock *sk, unsigned short nr) { - nr_cb *nrom = nr_sk(sk); + struct nr_sock *nrom = nr_sk(sk); unsigned short vc = nrom->va; while (vc != nrom->vs) { @@ -104,7 +104,7 @@ */ int nr_in_rx_window(struct sock *sk, unsigned short ns) { - nr_cb *nr = nr_sk(sk); + struct nr_sock *nr = nr_sk(sk); unsigned short vc = nr->vr; unsigned short vt = (nr->vl + nr->window) % NR_MODULUS; @@ -122,7 +122,7 @@ */ void nr_write_internal(struct sock *sk, int frametype) { - nr_cb *nr = nr_sk(sk); + struct nr_sock *nr = nr_sk(sk); struct sk_buff *skb; unsigned char *dptr; int len, timeout; Index: bk-afu/net/netrom/nr_out.c =================================================================== --- bk-afu.orig/net/netrom/nr_out.c 2005-03-17 23:53:59.000000000 +0000 +++ bk-afu/net/netrom/nr_out.c 2005-03-20 10:39:20.000000000 +0000 @@ -82,7 +82,7 @@ */ static void nr_send_iframe(struct sock *sk, struct sk_buff *skb) { - nr_cb *nr = nr_sk(sk); + struct nr_sock *nr = nr_sk(sk); if (skb == NULL) return; @@ -101,7 +101,7 @@ void nr_send_nak_frame(struct sock *sk) { struct sk_buff *skb, *skbn; - nr_cb *nr = nr_sk(sk); + struct nr_sock *nr = nr_sk(sk); if ((skb = skb_peek(&nr->ack_queue)) == NULL) return; @@ -125,7 +125,7 @@ void nr_kick(struct sock *sk) { - nr_cb *nr = nr_sk(sk); + struct nr_sock *nr = nr_sk(sk); struct sk_buff *skb, *skbn; unsigned short start, end; @@ -188,7 +188,7 @@ void nr_transmit_buffer(struct sock *sk, struct sk_buff *skb) { - nr_cb *nr = nr_sk(sk); + struct nr_sock *nr = nr_sk(sk); unsigned char *dptr; /* @@ -223,7 +223,7 @@ void nr_establish_data_link(struct sock *sk) { - nr_cb *nr = nr_sk(sk); + struct nr_sock *nr = nr_sk(sk); nr->condition = 0x00; nr->n2count = 0; @@ -241,7 +241,7 @@ */ void nr_enquiry_response(struct sock *sk) { - nr_cb *nr = nr_sk(sk); + struct nr_sock *nr = nr_sk(sk); int frametype = NR_INFOACK; if (nr->condition & NR_COND_OWN_RX_BUSY) { @@ -259,7 +259,7 @@ void nr_check_iframes_acked(struct sock *sk, unsigned short nr) { - nr_cb *nrom = nr_sk(sk); + struct nr_sock *nrom = nr_sk(sk); if (nrom->vs == nr) { nr_frames_acked(sk, nr); From ralf@linux-mips.org Mon Mar 21 01:52:04 2005 Received: with ECARTIS (v1.0.0; list netdev); Mon, 21 Mar 2005 01:52:10 -0800 (PST) Received: from mail.linux-mips.net (p3EE066C8.dip.t-dialin.net [62.224.102.200]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j2L9q2Kj009333 for ; Mon, 21 Mar 2005 01:52:03 -0800 Received: from dea.linux-mips.net (localhost.localdomain [127.0.0.1]) by mail.linux-mips.net (8.13.1/8.13.1) with ESMTP id j2L9ob8a010272; Mon, 21 Mar 2005 09:50:37 GMT Received: (from ralf@localhost) by dea.linux-mips.net (8.13.1/8.13.1/Submit) id j2L9objf010271; Mon, 21 Mar 2005 09:50:37 GMT Date: Mon, 21 Mar 2005 09:50:37 +0000 From: Ralf Baechle DL5RB To: netdev@oss.sgi.com, linux-hams@vger.kernel.org Cc: "David S. Miller" Subject: [PATCH] Get rid of sk_protinfo use in rose Message-ID: <20050321095037.GA10220@linux-mips.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.4.1i X-Virus-Scanned: ClamAV 0.83/774/Fri Mar 18 17:04:06 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 426 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: ralf@linux-mips.org Precedence: bulk X-list: netdev Content-Length: 12603 Lines: 461 Below patch puts struct sock into rose_cb to get rid of the need for the use of sk_protinfo in rose_sk(). While we're touching the data structure convert it from a typedef into a struct. Index: bk-afu/net/rose/rose_in.c =================================================================== --- bk-afu.orig/net/rose/rose_in.c 2005-03-21 09:33:42.000000000 +0000 +++ bk-afu/net/rose/rose_in.c 2005-03-21 09:34:39.000000000 +0000 @@ -41,7 +41,7 @@ */ static int rose_state1_machine(struct sock *sk, struct sk_buff *skb, int frametype) { - rose_cb *rose = rose_sk(sk); + struct rose_sock *rose = rose_sk(sk); switch (frametype) { case ROSE_CALL_ACCEPTED: @@ -78,7 +78,7 @@ */ static int rose_state2_machine(struct sock *sk, struct sk_buff *skb, int frametype) { - rose_cb *rose = rose_sk(sk); + struct rose_sock *rose = rose_sk(sk); switch (frametype) { case ROSE_CLEAR_REQUEST: @@ -106,7 +106,7 @@ */ static int rose_state3_machine(struct sock *sk, struct sk_buff *skb, int frametype, int ns, int nr, int q, int d, int m) { - rose_cb *rose = rose_sk(sk); + struct rose_sock *rose = rose_sk(sk); int queued = 0; switch (frametype) { @@ -216,7 +216,7 @@ */ static int rose_state4_machine(struct sock *sk, struct sk_buff *skb, int frametype) { - rose_cb *rose = rose_sk(sk); + struct rose_sock *rose = rose_sk(sk); switch (frametype) { case ROSE_RESET_REQUEST: @@ -265,7 +265,7 @@ /* Higher level upcall for a LAPB frame */ int rose_process_rx_frame(struct sock *sk, struct sk_buff *skb) { - rose_cb *rose = rose_sk(sk); + struct rose_sock *rose = rose_sk(sk); int queued = 0, frametype, ns, nr, q, d, m; if (rose->state == ROSE_STATE_0) Index: bk-afu/net/rose/rose_route.c =================================================================== --- bk-afu.orig/net/rose/rose_route.c 2005-03-21 09:33:42.000000000 +0000 +++ bk-afu/net/rose/rose_route.c 2005-03-21 09:34:39.000000000 +0000 @@ -899,7 +899,8 @@ */ if ((sk = rose_find_socket(lci, rose_neigh)) != NULL) { if (frametype == ROSE_CALL_REQUEST) { - rose_cb *rose = rose_sk(sk); + struct rose_sock *rose = rose_sk(sk); + /* Remove an existing unused socket */ rose_clear_queues(sk); rose->cause = ROSE_NETWORK_CONGESTION; Index: bk-afu/net/rose/rose_timer.c =================================================================== --- bk-afu.orig/net/rose/rose_timer.c 2005-03-21 09:33:42.000000000 +0000 +++ bk-afu/net/rose/rose_timer.c 2005-03-21 09:34:39.000000000 +0000 @@ -46,7 +46,7 @@ void rose_start_t1timer(struct sock *sk) { - rose_cb *rose = rose_sk(sk); + struct rose_sock *rose = rose_sk(sk); del_timer(&rose->timer); @@ -59,7 +59,7 @@ void rose_start_t2timer(struct sock *sk) { - rose_cb *rose = rose_sk(sk); + struct rose_sock *rose = rose_sk(sk); del_timer(&rose->timer); @@ -72,7 +72,7 @@ void rose_start_t3timer(struct sock *sk) { - rose_cb *rose = rose_sk(sk); + struct rose_sock *rose = rose_sk(sk); del_timer(&rose->timer); @@ -85,7 +85,7 @@ void rose_start_hbtimer(struct sock *sk) { - rose_cb *rose = rose_sk(sk); + struct rose_sock *rose = rose_sk(sk); del_timer(&rose->timer); @@ -98,7 +98,7 @@ void rose_start_idletimer(struct sock *sk) { - rose_cb *rose = rose_sk(sk); + struct rose_sock *rose = rose_sk(sk); del_timer(&rose->idletimer); @@ -129,7 +129,7 @@ static void rose_heartbeat_expiry(unsigned long param) { struct sock *sk = (struct sock *)param; - rose_cb *rose = rose_sk(sk); + struct rose_sock *rose = rose_sk(sk); bh_lock_sock(sk); switch (rose->state) { @@ -166,7 +166,7 @@ static void rose_timer_expiry(unsigned long param) { struct sock *sk = (struct sock *)param; - rose_cb *rose = rose_sk(sk); + struct rose_sock *rose = rose_sk(sk); bh_lock_sock(sk); switch (rose->state) { Index: bk-afu/include/net/rose.h =================================================================== --- bk-afu.orig/include/net/rose.h 2005-03-21 09:33:42.000000000 +0000 +++ bk-afu/include/net/rose.h 2005-03-21 09:34:39.000000000 +0000 @@ -6,7 +6,9 @@ #ifndef _ROSE_H #define _ROSE_H + #include +#include #define ROSE_ADDR_LEN 5 @@ -114,7 +116,8 @@ unsigned int rand; }; -typedef struct { +struct rose_sock { + struct sock sock; rose_address source_addr, dest_addr; ax25_address source_call, dest_call; unsigned char source_ndigis, dest_ndigis; @@ -135,10 +138,9 @@ struct rose_facilities_struct facilities; struct timer_list timer; struct timer_list idletimer; - struct sock *sk; /* Backlink to socket */ -} rose_cb; +}; -#define rose_sk(__sk) ((rose_cb *)(__sk)->sk_protinfo) +#define rose_sk(sk) ((struct rose_sock *)(sk)) /* af_rose.c */ extern ax25_address rose_callsign; Index: bk-afu/net/rose/rose_subr.c =================================================================== --- bk-afu.orig/net/rose/rose_subr.c 2005-03-21 09:33:42.000000000 +0000 +++ bk-afu/net/rose/rose_subr.c 2005-03-21 09:34:39.000000000 +0000 @@ -28,7 +28,7 @@ #include #include -static int rose_create_facilities(unsigned char *buffer, rose_cb *rose); +static int rose_create_facilities(unsigned char *buffer, struct rose_sock *rose); /* * This routine purges all of the queues of frames. @@ -47,7 +47,7 @@ void rose_frames_acked(struct sock *sk, unsigned short nr) { struct sk_buff *skb; - rose_cb *rose = rose_sk(sk); + struct rose_sock *rose = rose_sk(sk); /* * Remove all the ack-ed frames from the ack queue. @@ -85,7 +85,7 @@ */ int rose_validate_nr(struct sock *sk, unsigned short nr) { - rose_cb *rose = rose_sk(sk); + struct rose_sock *rose = rose_sk(sk); unsigned short vc = rose->va; while (vc != rose->vs) { @@ -102,7 +102,7 @@ */ void rose_write_internal(struct sock *sk, int frametype) { - rose_cb *rose = rose_sk(sk); + struct rose_sock *rose = rose_sk(sk); struct sk_buff *skb; unsigned char *dptr; unsigned char lci1, lci2; @@ -396,7 +396,7 @@ return 1; } -static int rose_create_facilities(unsigned char *buffer, rose_cb *rose) +static int rose_create_facilities(unsigned char *buffer, struct rose_sock *rose) { unsigned char *p = buffer + 1; char *callsign; @@ -492,7 +492,7 @@ void rose_disconnect(struct sock *sk, int reason, int cause, int diagnostic) { - rose_cb *rose = rose_sk(sk); + struct rose_sock *rose = rose_sk(sk); rose_stop_timer(sk); rose_stop_idletimer(sk); Index: bk-afu/net/rose/rose_out.c =================================================================== --- bk-afu.orig/net/rose/rose_out.c 2005-03-21 09:33:42.000000000 +0000 +++ bk-afu/net/rose/rose_out.c 2005-03-21 09:34:39.000000000 +0000 @@ -33,7 +33,7 @@ */ static void rose_send_iframe(struct sock *sk, struct sk_buff *skb) { - rose_cb *rose = rose_sk(sk); + struct rose_sock *rose = rose_sk(sk); if (skb == NULL) return; @@ -48,7 +48,7 @@ void rose_kick(struct sock *sk) { - rose_cb *rose = rose_sk(sk); + struct rose_sock *rose = rose_sk(sk); struct sk_buff *skb, *skbn; unsigned short start, end; @@ -112,7 +112,7 @@ void rose_enquiry_response(struct sock *sk) { - rose_cb *rose = rose_sk(sk); + struct rose_sock *rose = rose_sk(sk); if (rose->condition & ROSE_COND_OWN_RX_BUSY) rose_write_internal(sk, ROSE_RNR); Index: bk-afu/net/rose/af_rose.c =================================================================== --- bk-afu.orig/net/rose/af_rose.c 2005-03-21 09:33:42.000000000 +0000 +++ bk-afu/net/rose/af_rose.c 2005-03-21 09:34:39.000000000 +0000 @@ -128,24 +128,7 @@ static struct sock *rose_alloc_sock(void) { - rose_cb *rose; - struct sock *sk = sk_alloc(PF_ROSE, GFP_ATOMIC, 1, NULL); - - if (!sk) - goto out; - - rose = sk->sk_protinfo = kmalloc(sizeof(*rose), GFP_ATOMIC); - if (!rose) - goto frees; - - memset(rose, 0x00, sizeof(*rose)); - rose->sk = sk; -out: - return sk; -frees: - sk_free(sk); - sk = NULL; - goto out; + return sk_alloc(PF_ROSE, GFP_ATOMIC, sizeof(struct rose_sock), NULL); } /* @@ -169,7 +152,7 @@ spin_lock_bh(&rose_list_lock); sk_for_each(s, node, &rose_list) { - rose_cb *rose = rose_sk(s); + struct rose_sock *rose = rose_sk(s); if (rose->neighbour == neigh) { rose_disconnect(s, ENETUNREACH, ROSE_OUT_OF_ORDER, 0); @@ -190,7 +173,7 @@ spin_lock_bh(&rose_list_lock); sk_for_each(s, node, &rose_list) { - rose_cb *rose = rose_sk(s); + struct rose_sock *rose = rose_sk(s); if (rose->device == dev) { rose_disconnect(s, ENETUNREACH, ROSE_OUT_OF_ORDER, 0); @@ -247,7 +230,7 @@ spin_lock_bh(&rose_list_lock); sk_for_each(s, node, &rose_list) { - rose_cb *rose = rose_sk(s); + struct rose_sock *rose = rose_sk(s); if (!rosecmp(&rose->source_addr, addr) && !ax25cmp(&rose->source_call, call) && @@ -256,7 +239,7 @@ } sk_for_each(s, node, &rose_list) { - rose_cb *rose = rose_sk(s); + struct rose_sock *rose = rose_sk(s); if (!rosecmp(&rose->source_addr, addr) && !ax25cmp(&rose->source_call, &null_ax25_address) && @@ -279,7 +262,7 @@ spin_lock_bh(&rose_list_lock); sk_for_each(s, node, &rose_list) { - rose_cb *rose = rose_sk(s); + struct rose_sock *rose = rose_sk(s); if (rose->lci == lci && rose->neighbour == neigh) goto found; @@ -372,7 +355,7 @@ char __user *optval, int optlen) { struct sock *sk = sock->sk; - rose_cb *rose = rose_sk(sk); + struct rose_sock *rose = rose_sk(sk); int opt; if (level != SOL_ROSE) @@ -432,7 +415,7 @@ char __user *optval, int __user *optlen) { struct sock *sk = sock->sk; - rose_cb *rose = rose_sk(sk); + struct rose_sock *rose = rose_sk(sk); int val = 0; int len; @@ -491,7 +474,7 @@ struct sock *sk = sock->sk; if (sk->sk_state != TCP_LISTEN) { - rose_cb *rose = rose_sk(sk); + struct rose_sock *rose = rose_sk(sk); rose->dest_ndigis = 0; memset(&rose->dest_addr, 0, ROSE_ADDR_LEN); @@ -508,7 +491,7 @@ static int rose_create(struct socket *sock, int protocol) { struct sock *sk; - rose_cb *rose; + struct rose_sock *rose; if (sock->type != SOCK_SEQPACKET || protocol != 0) return -ESOCKTNOSUPPORT; @@ -547,7 +530,7 @@ static struct sock *rose_make_new(struct sock *osk) { struct sock *sk; - rose_cb *rose, *orose; + struct rose_sock *rose, *orose; if (osk->sk_type != SOCK_SEQPACKET) return NULL; @@ -600,7 +583,7 @@ static int rose_release(struct socket *sock) { struct sock *sk = sock->sk; - rose_cb *rose; + struct rose_sock *rose; if (sk == NULL) return 0; @@ -646,7 +629,7 @@ static int rose_bind(struct socket *sock, struct sockaddr *uaddr, int addr_len) { struct sock *sk = sock->sk; - rose_cb *rose = rose_sk(sk); + struct rose_sock *rose = rose_sk(sk); struct sockaddr_rose *addr = (struct sockaddr_rose *)uaddr; struct net_device *dev; ax25_address *user, *source; @@ -705,7 +688,7 @@ static int rose_connect(struct socket *sock, struct sockaddr *uaddr, int addr_len, int flags) { struct sock *sk = sock->sk; - rose_cb *rose = rose_sk(sk); + struct rose_sock *rose = rose_sk(sk); struct sockaddr_rose *addr = (struct sockaddr_rose *)uaddr; unsigned char cause, diagnostic; ax25_address *user; @@ -906,7 +889,7 @@ { struct full_sockaddr_rose *srose = (struct full_sockaddr_rose *)uaddr; struct sock *sk = sock->sk; - rose_cb *rose = rose_sk(sk); + struct rose_sock *rose = rose_sk(sk); int n; if (peer != 0) { @@ -935,7 +918,7 @@ { struct sock *sk; struct sock *make; - rose_cb *make_rose; + struct rose_sock *make_rose; struct rose_facilities_struct facilities; int n, len; @@ -1016,7 +999,7 @@ struct msghdr *msg, size_t len) { struct sock *sk = sock->sk; - rose_cb *rose = rose_sk(sk); + struct rose_sock *rose = rose_sk(sk); struct sockaddr_rose *usrose = (struct sockaddr_rose *)msg->msg_name; int err; struct full_sockaddr_rose srose; @@ -1186,7 +1169,7 @@ struct msghdr *msg, size_t size, int flags) { struct sock *sk = sock->sk; - rose_cb *rose = rose_sk(sk); + struct rose_sock *rose = rose_sk(sk); struct sockaddr_rose *srose = (struct sockaddr_rose *)msg->msg_name; size_t copied; unsigned char *asmptr; @@ -1251,7 +1234,7 @@ static int rose_ioctl(struct socket *sock, unsigned int cmd, unsigned long arg) { struct sock *sk = sock->sk; - rose_cb *rose = rose_sk(sk); + struct rose_sock *rose = rose_sk(sk); void __user *argp = (void __user *)arg; switch (cmd) { @@ -1384,7 +1367,7 @@ else { struct sock *s = v; - rose_cb *rose = rose_sk(s); + struct rose_sock *rose = rose_sk(s); const char *devname, *callsign; const struct net_device *dev = rose->device; From ralf@linux-mips.org Mon Mar 21 02:00:06 2005 Received: with ECARTIS (v1.0.0; list netdev); Mon, 21 Mar 2005 02:00:10 -0800 (PST) Received: from mail.linux-mips.net (p3EE066C8.dip.t-dialin.net [62.224.102.200]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j2LA05du010963 for ; Mon, 21 Mar 2005 02:00:05 -0800 Received: from dea.linux-mips.net (localhost.localdomain [127.0.0.1]) by mail.linux-mips.net (8.13.1/8.13.1) with ESMTP id j2L9webX010545; Mon, 21 Mar 2005 09:58:40 GMT Received: (from ralf@localhost) by dea.linux-mips.net (8.13.1/8.13.1/Submit) id j2L9wef6010544; Mon, 21 Mar 2005 09:58:40 GMT Date: Mon, 21 Mar 2005 09:58:40 +0000 From: Ralf Baechle DL5RB To: netdev@oss.sgi.com, linux-hams@vger.kernel.org Cc: "David S. Miller" Subject: Re: [PATCH] Get rid of sk_protinfo use in rose Message-ID: <20050321095840.GB10220@linux-mips.org> References: <20050321095037.GA10220@linux-mips.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20050321095037.GA10220@linux-mips.org> User-Agent: Mutt/1.4.1i X-Virus-Scanned: ClamAV 0.83/774/Fri Mar 18 17:04:06 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 427 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: ralf@linux-mips.org Precedence: bulk X-list: netdev Content-Length: 481 Lines: 11 On Mon, Mar 21, 2005 at 09:50:37AM +0000, Ralf Baechle DL5RB wrote: > Below patch puts struct sock into rose_cb to get rid of the need for the > use of sk_protinfo in rose_sk(). While we're touching the data structure > convert it from a typedef into a struct. The previous two patches leave the same thing to do in ax25 also - where it's a more complicated thing to do since currently an ax25_cb may exist without a struct sock - which unfortunately messes up locking. Ralf From herbert@gondor.apana.org.au Mon Mar 21 02:56:57 2005 Received: with ECARTIS (v1.0.0; list netdev); Mon, 21 Mar 2005 02:57:04 -0800 (PST) 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 j2LAusUP019687 for ; Mon, 21 Mar 2005 02:56:55 -0800 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 1DDKaN-0006L6-00; Mon, 21 Mar 2005 21:56:39 +1100 Received: from herbert by gondolin.me.apana.org.au with local (Exim 3.36 #1 (Debian)) id 1DDKa6-0006Dx-00; Mon, 21 Mar 2005 21:56:22 +1100 Date: Mon, 21 Mar 2005 21:56:22 +1100 To: "David S. Miller" , netdev@oss.sgi.com Subject: [IPV4] Check mtu instead of frag_list in ip_push_pending_frames Message-ID: <20050321105622.GA23809@gondor.apana.org.au> Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="nFreZHaLTZJo0R7j" Content-Disposition: inline User-Agent: Mutt/1.5.6+20040907i From: Herbert Xu X-Virus-Scanned: ClamAV 0.83/774/Fri Mar 18 17:04:06 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 428 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: herbert@gondor.apana.org.au Precedence: bulk X-list: netdev Content-Length: 2707 Lines: 71 --nFreZHaLTZJo0R7j Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Hi Dave: I still didn't like the fact that ip_append_data was the only user of dst_pmtu :) So I went looking for bugs in the surrounding code. I managed to find something in ip_push_pending_frames. When dst_mtu < dst_pmtu - IPsec overhead (which can be caused by PMTU discovery within an IPsec tunnel), and we transmit a packet that's longer than dst_mtu but shorter than dst_pmtu - IPsec overhead, then the DF bit will be incorrectly set in the inner IP header. This will cause the packet to be dropped when it hits the router that generated the original PMTU event. Unfortunately the ICMP packet coming back doesn't tell us anything new so the next time we send a packet we will do exactly the same thing. The fix is similar to what we did in ip_output. Instead of checking whether frag_list is empty, we check the condition skb->len <= dst_mtu directly and set the DF bit based on that. We can enumerate all the possibilities to see that this is correct. If skb->len <= dst_mtu and frag_list is empty then this does the samething as before and is obviously correct. If skb->len <= dst_mtu and frag_list is non-empty then it implies that dst_pmtu has increased since the fragments were constructed as dst_pmtu = dst_mtu + IPsec overhead. So the skb will now fit within a single fragment which means that setting DF is correct. The fragments will be merged by skb_linearise in dev_queue_xmit. If skb->len > dst_mtu and frag_list is non-empty then again this maintains the status quo. If skb->len > dst_mtu and frag_list is empty then we will leave the DF bit clear as the packet will need to be fragmented between the remote IPsec gateway and the final destination. 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 --nFreZHaLTZJo0R7j Content-Type: text/plain; charset=us-ascii Content-Disposition: attachment; filename=p ===== net/ipv4/ip_output.c 1.80 vs edited ===== --- 1.80/net/ipv4/ip_output.c 2005-03-19 05:43:26 +11:00 +++ edited/net/ipv4/ip_output.c 2005-03-21 21:36:51 +11:00 @@ -1152,7 +1152,8 @@ * If local_df is set too, we still allow to fragment this frame * locally. */ if (inet->pmtudisc == IP_PMTUDISC_DO || - (!skb_shinfo(skb)->frag_list && ip_dont_fragment(sk, &rt->u.dst))) + (skb->len <= dst_mtu(&rt->u.dst) && + ip_dont_fragment(sk, &rt->u.dst))) df = htons(IP_DF); if (inet->cork.flags & IPCORK_OPT) --nFreZHaLTZJo0R7j-- From bcrl@kvack.org Mon Mar 21 03:00:17 2005 Received: with ECARTIS (v1.0.0; list netdev); Mon, 21 Mar 2005 03:00:24 -0800 (PST) Received: from kanga.kvack.org (kanga.kvack.org [66.96.29.28]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j2LB0GFs020504 for ; Mon, 21 Mar 2005 03:00:17 -0800 Received: (from localhost user: 'bcrl' uid#63042 fake: STDIN (bcrl@kanga.kvack.org)) by kvack.org id ; Mon, 21 Mar 2005 05:59:47 -0500 Date: Mon, 21 Mar 2005 05:59:47 -0500 From: Benjamin LaHaise To: Andi Kleen Cc: jgarzik@pobox.com, netdev@oss.sgi.com Subject: Re: [PATCH] Fix ns82830 driver for x86-64 Message-ID: <20050321105947.GB808@kvack.org> References: <20050314000543.GA85950@muc.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20050314000543.GA85950@muc.de> User-Agent: Mutt/1.4.1i X-Virus-Scanned: ClamAV 0.83/774/Fri Mar 18 17:04:06 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 429 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: bcrl@kvack.org Precedence: bulk X-list: netdev Content-Length: 3225 Lines: 100 I'll have a closer look at this when I'm back in Canada later this week, as there are a few other ns83820 patches which should be applied. The patch looks right -- those ifdefs date back to the 2.4.9 days. -ben On Mon, Mar 14, 2005 at 01:05:43AM +0100, Andi Kleen wrote: > Fix up some dodgy ifdefs in the ns82820 driver > and support DAC mode on x86-64. Do proper sizeof(dma_addr_t) checks > instead. > > Only compile tested due to lack of hardware. > > Originally pointed out by Al Viro > > Signed-off-by: Andi Kleen > > Index: linux/drivers/net/ns83820.c > =================================================================== > --- linux.orig/drivers/net/ns83820.c 2005-03-12 15:06:34.000000000 +0100 > +++ linux/drivers/net/ns83820.c 2005-03-14 00:50:07.547865056 +0100 > @@ -1,4 +1,4 @@ > -#define _VERSION "0.20" > +#define VERSION "0.20" > /* ns83820.c by Benjamin LaHaise with contributions. > * > * Questions/comments/discussion to linux-ns83820@kvack.org. > @@ -129,18 +129,6 @@ > #undef Dprintk > #define Dprintk dprintk > > -#if defined(CONFIG_HIGHMEM64G) || defined(__ia64__) > -#define USE_64BIT_ADDR "+" > -#endif > - > -#if defined(USE_64BIT_ADDR) > -#define VERSION _VERSION USE_64BIT_ADDR > -#define TRY_DAC 1 > -#else > -#define VERSION _VERSION > -#define TRY_DAC 0 > -#endif > - > /* tunables */ > #define RX_BUF_SIZE 1500 /* 8192 */ > #if defined(CONFIG_VLAN_8021Q) || defined(CONFIG_VLAN_8021Q_MODULE) > @@ -386,22 +374,16 @@ > #define LINK_DOWN 0x02 > #define LINK_UP 0x04 > > -#ifdef USE_64BIT_ADDR > -#define HW_ADDR_LEN 8 > +#define HW_ADDR_LEN sizeof(dma_addr_t) > #define desc_addr_set(desc, addr) \ > do { \ > - u64 __addr = (addr); \ > - (desc)[0] = cpu_to_le32(__addr); \ > - (desc)[1] = cpu_to_le32(__addr >> 32); \ > + ((desc)[0] = cpu_to_le32(addr)); \ > + if (HW_ADDR_LEN == 8) \ > + (desc)[1] = cpu_to_le32(((u64)addr) >> 32); \ > } while(0) > #define desc_addr_get(desc) \ > - (((u64)le32_to_cpu((desc)[1]) << 32) \ > - | le32_to_cpu((desc)[0])) > -#else > -#define HW_ADDR_LEN 4 > -#define desc_addr_set(desc, addr) ((desc)[0] = cpu_to_le32(addr)) > -#define desc_addr_get(desc) (le32_to_cpu((desc)[0])) > -#endif > + (le32_to_cpu((desc)[0]) | \ > + (HW_ADDR_LEN == 8 ? ((dma_addr_t)le32_to_cpu((desc)[1]))<<32 : 0)) > > #define DESC_LINK 0 > #define DESC_BUFPTR (DESC_LINK + HW_ADDR_LEN/4) > @@ -1841,7 +1823,8 @@ > int using_dac = 0; > > /* See if we can set the dma mask early on; failure is fatal. */ > - if (TRY_DAC && !pci_set_dma_mask(pci_dev, 0xffffffffffffffffULL)) { > + if (sizeof(dma_addr_t) == 8 && > + !pci_set_dma_mask(pci_dev, 0xffffffffffffffffULL)) { > using_dac = 1; > } else if (!pci_set_dma_mask(pci_dev, 0xffffffff)) { > using_dac = 0; > @@ -1972,9 +1955,8 @@ > /* When compiled with 64 bit addressing, we must always enable > * the 64 bit descriptor format. > */ > -#ifdef USE_64BIT_ADDR > - dev->CFG_cache |= CFG_M64ADDR; > -#endif > + if (sizeof(dma_addr_t) == 8) > + dev->CFG_cache |= CFG_M64ADDR; > if (using_dac) > dev->CFG_cache |= CFG_T64ADDR; > -- "Time is what keeps everything from happening all at once." -- John Wheeler From herbert@gondor.apana.org.au Mon Mar 21 03:17:21 2005 Received: with ECARTIS (v1.0.0; list netdev); Mon, 21 Mar 2005 03:17:29 -0800 (PST) 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 j2LBHJRT022836 for ; Mon, 21 Mar 2005 03:17:20 -0800 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 1DDKu8-0006S7-00; Mon, 21 Mar 2005 22:17:04 +1100 Received: from herbert by gondolin.me.apana.org.au with local (Exim 3.36 #1 (Debian)) id 1DDKth-0006PR-00; Mon, 21 Mar 2005 22:16:37 +1100 Date: Mon, 21 Mar 2005 22:16:37 +1100 To: "David S. Miller" , netdev@oss.sgi.com Subject: [IPV4] Clear DF bit in ip_fragment fast path Message-ID: <20050321111637.GA24617@gondor.apana.org.au> References: <20050321105622.GA23809@gondor.apana.org.au> Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="FCuugMFkClbJLl1L" Content-Disposition: inline In-Reply-To: <20050321105622.GA23809@gondor.apana.org.au> User-Agent: Mutt/1.5.6+20040907i From: Herbert Xu X-Virus-Scanned: ClamAV 0.83/774/Fri Mar 18 17:04:06 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 430 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: herbert@gondor.apana.org.au Precedence: bulk X-list: netdev Content-Length: 1274 Lines: 43 --FCuugMFkClbJLl1L Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Hi Dave: It is possible for ip_fragment() to send out head fragments with both DF and MF set for packets with local_df set to true. This is because the fast path tries to only modify the MF bit of the head fragment. Since the offset is always zero for the head fragment, and we know that DF should be cleared in case of local_df, we can change |= to a straight assignment. 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 --FCuugMFkClbJLl1L Content-Type: text/plain; charset=us-ascii Content-Disposition: attachment; filename=p ===== net/ipv4/ip_output.c 1.80 vs edited ===== --- 1.80/net/ipv4/ip_output.c 2005-03-19 05:43:26 +11:00 +++ edited/net/ipv4/ip_output.c 2005-03-21 22:09:45 +11:00 @@ -498,7 +498,7 @@ skb->data_len = first_len - skb_headlen(skb); skb->len = first_len; iph->tot_len = htons(first_len); - iph->frag_off |= htons(IP_MF); + iph->frag_off = htons(IP_MF); ip_send_check(iph); for (;;) { --FCuugMFkClbJLl1L-- From mlists@danielinux.net Mon Mar 21 03:51:04 2005 Received: with ECARTIS (v1.0.0; list netdev); Mon, 21 Mar 2005 03:51:10 -0800 (PST) Received: from ms005msg.fastwebnet.it (ms005msg.fastwebnet.it [213.140.2.50]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j2LBp3AR026930 for ; Mon, 21 Mar 2005 03:51:03 -0800 Received: from [192.168.1.66] (37.10.150.65) by ms005msg.fastwebnet.it (7.2.052.3) id 41FFB24D009C3A93; Mon, 21 Mar 2005 12:50:09 +0100 From: Daniele Lacamera Reply-To: mlists@danielinux.net To: Stephen Hemminger Subject: Re: [PATCH] TCP Hybla Date: Mon, 21 Mar 2005 12:50:07 +0100 User-Agent: KMail/1.7.1 Cc: "David S. Miller" , netdev@oss.sgi.com References: <20050318163123.14969084@dxpl.pdx.osdl.net> In-Reply-To: <20050318163123.14969084@dxpl.pdx.osdl.net> MIME-Version: 1.0 Content-Type: Multipart/Mixed; boundary="Boundary-00=_vTrPCXRNYzoQLAt" Message-Id: <200503211250.07814.mlists@danielinux.net> X-Virus-Scanned: ClamAV 0.83/774/Fri Mar 18 17:04:06 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 431 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: mlists@danielinux.net Precedence: bulk X-list: netdev Content-Length: 8668 Lines: 276 --Boundary-00=_vTrPCXRNYzoQLAt Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline On Saturday 19 March 2005 01:31, Stephen Hemminger wrote: > Here is a version of TCP Hybla based on the new split out of TCP > algorithms. It doesn't work right, I probably broke something. > > Original code for RTT0 was wrong because HZ=1000 on 2.6, so I changed > it to be a parameter explicitly in ms. > > Don't put it into production system till worked out. This one is working. I've also made some changes. The cong_avoid checks for a flightsize not smaller than actual cwnd before giving the increment. Also, the tcp_reno_cong_avoid is called when not in TCP_CA_Open, as happens in vegas too. -- Signed-off by: Daniele Lacamera (root at danielinux.net) --Boundary-00=_vTrPCXRNYzoQLAt Content-Type: text/x-diff; charset="iso-8859-1"; name="SH_tcpsplit_hybla.patch" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="SH_tcpsplit_hybla.patch" diff -ruN a/net/ipv4/Kconfig b/net/ipv4/Kconfig --- a/net/ipv4/Kconfig 2005-03-21 12:17:59.000000000 +0100 +++ b/net/ipv4/Kconfig 2005-03-21 12:15:05.000000000 +0100 @@ -405,6 +405,16 @@ TCP Westwood+ significantly increases fairness wrt TCP Reno in wired networks and throughput over wireless links. +config TCP_CONG_HYBLA + tristate "TCP-Hybla congestion control algorithm" + depends on EXPERIMENTAL + default n + ---help--- + TCP-Hybla is a sender-side only change that eliminates penalization of + long-RTT, large-bandwidth connections, like when satellite legs are + involved, expecially when sharing a common bottleneck with normal + terrestrial connections. + endmenu diff -ruN a/net/ipv4/Makefile b/net/ipv4/Makefile --- a/net/ipv4/Makefile 2005-03-21 12:17:37.000000000 +0100 +++ b/net/ipv4/Makefile 2005-03-21 12:15:05.000000000 +0100 @@ -27,6 +27,7 @@ obj-$(CONFIG_TCP_CONG_VEGAS) += tcp_vegas.o obj-$(CONFIG_TCP_CONG_BIC) += tcp_bic.o obj-$(CONFIG_TCP_CONG_WESTWOOD) += tcp_westwood.o +obj-$(CONFIG_TCP_CONG_HYBLA) += tcp_hybla.o obj-$(CONFIG_XFRM) += xfrm4_policy.o xfrm4_state.o xfrm4_input.o \ xfrm4_output.o diff -ruN a/net/ipv4/tcp_hybla.c b/net/ipv4/tcp_hybla.c --- a/net/ipv4/tcp_hybla.c 1970-01-01 01:00:00.000000000 +0100 +++ b/net/ipv4/tcp_hybla.c 2005-03-21 12:15:06.000000000 +0100 @@ -0,0 +1,207 @@ +/* + * TCP HYBLA + * + * TCP-HYBLA Congestion control algorithm, based on: + * C.Caini, R.Firrincieli, "TCP-Hybla: A TCP Enhancement + * for Heterogeneous Networks", + * International Journal on satellite Communications, + * September 2004 + * Daniele Lacamera + * root at danielinux.net + */ + +#include +#include +#include + +/* Tcp Hybla structure. */ +struct hybla_ca { + u8 hybla_en; + u32 snd_cwnd_cents; /* Keeps increment values when it is <1, <<7 */ + u32 rho; /* Rho parameter, integer part */ + u32 rho2; /* Rho * Rho, integer part */ + u32 rho_3ls; /* Rho parameter, <<3 */ + u32 rho2_7ls; /* Rho^2, <<7 */ + u32 minrtt; /* Minimum smoothed round trip time value seen */ +}; + +/* Hybla reference round trip time (default= 1/40 sec = 25 ms), + expressed in jiffies */ +static int rtt0 = 25; +module_param(rtt0, int, 0644); +MODULE_PARM_DESC(rtt0, "reference rout trip time (ms)"); + + +/* This is called to refresh values for hybla parameters */ +static inline void hybla_recalc_param (struct tcp_sock *tp) +{ + struct hybla_ca *ca = tcp_ca(tp); + + ca->rho_3ls = max_t(u32, tp->srtt / msecs_to_jiffies(rtt0), 8); + ca->rho = ca->rho_3ls >> 3; + ca->rho2_7ls = (ca->rho_3ls * ca->rho_3ls) << 1; + ca->rho2 = ca->rho2_7ls >>7; +} + + +static void hybla_start(struct tcp_sock *tp) +{ + struct hybla_ca *ca = tcp_ca(tp); + + ca->rho = 0; + ca->rho2 = 0; + ca->rho_3ls = 0; + ca->rho2_7ls = 0; + ca->snd_cwnd_cents = 0; + ca->hybla_en = 1; + + tp->snd_cwnd = 2; + tp->snd_cwnd_clamp=65535; +} + + +static void hybla_ca_state(struct tcp_sock *tp, u8 ca_state) +{ + struct hybla_ca *ca = tcp_ca(tp); + if (ca_state == TCP_CA_Open) + ca->hybla_en=1; + else + ca->hybla_en=0; +} + +static inline u32 hybla_fraction(u32 odds) +{ + static const u32 fractions[] = { + 128, 139, 152, 165, 181, 197, 215, 234, + }; + + return (odds < ARRAY_SIZE(fractions)) ? fractions[odds] : 128; +} + +/* TCP Hybla main routine. + * This is the algorithm behavior: + * o Recalc Hybla parameters if min_rtt has changed + * o Give cwnd a new value based on the model proposed + * o remember increments <1 + */ +static void hybla_cong_avoid(struct tcp_sock *tp, u32 ack, u32 rtt, + u32 in_flight) +{ + struct hybla_ca *ca = tcp_ca(tp); + u32 increment, odd, rho_fractions; + int is_slowstart = 0; + + if(!ca->hybla_en) + return tcp_reno_cong_avoid(tp,ack,rtt,in_flight); + if (in_flight < tp->snd_cwnd) + return; + + if (ca->rho==0) + hybla_recalc_param(tp); + + rho_fractions = ca->rho_3ls - (ca->rho << 3); + + if (tp->snd_cwnd < tp->snd_ssthresh) { + /* + * slow start + * INC = 2^RHO - 1 + * This is done by splitting the rho parameter + * into 2 parts: an integer part and a fraction part. + * Inrement<<7 is estimated by doing: + * [2^(int+fract)]<<7 + * that is equal to: + * (2^int) * [(2^fract) <<7] + * 2^int is straightly computed as 1<rho) * hybla_fraction(rho_fractions)) + - 128; + } else { + /* + * congestion avoidance + * INC = RHO^2 / W + * as long as increment is estimated as (rho<<7)/window + * it already is <<7 and we can easily count its fractions. + */ + increment = ca->rho2_7ls / tp->snd_cwnd; + if (increment < 128) + tp->snd_cwnd_cnt++; + } + + odd = increment % 128; + tp->snd_cwnd += increment >> 7; + ca->snd_cwnd_cents += odd; + + /* check when fractions goes >=128 and increase cwnd by 1. */ + while(ca->snd_cwnd_cents >= 128) { + tp->snd_cwnd++; + ca->snd_cwnd_cents -= 128; + tp->snd_cwnd_cnt = 0; + } + + /*clamp down slowstart cwnd to ssthresh value. */ + if (is_slowstart) + tp->snd_cwnd = min(tp->snd_cwnd, tp->snd_ssthresh); + + tp->snd_cwnd = min_t(u32, tp->snd_cwnd, tp->snd_cwnd_clamp); +} + +/* + * Update Values, if necessary, when a new + * smoothed RTT Estimation becomes available + */ +static void hybla_update_rtt(struct tcp_sock *tp, u32 m) +{ + struct hybla_ca *ca = tcp_ca(tp); + + /* This sets rho to the smallest RTT received. */ + if (tp->srtt) { + /* Recalculate rho only if this srtt is the lowest */ + if (tp->srtt < ca->minrtt){ + hybla_recalc_param(tp); + ca->minrtt = tp->srtt; + } + } else { + /* 1st Rho measurement */ + hybla_recalc_param(tp); + + /* set minimum rtt as this is the 1st ever seen */ + ca->minrtt = tp->srtt; + tp->snd_cwnd = ca->rho; + } +} + + + +static struct tcp_ca_type tcp_hybla = { + .start = hybla_start, + .ssthresh = tcp_reno_ssthresh, + .min_cwnd = tcp_reno_cwnd_min, + .cong_avoid = hybla_cong_avoid, + .rtt_sample = hybla_update_rtt, + .set_state = hybla_ca_state, + + .owner = THIS_MODULE, + .name = "hybla" +}; + +static int __init hybla_init(void) +{ + BUG_ON(sizeof(struct hybla_ca) > TCP_CA_PRIV_SIZE); + tcp_ca_register(&tcp_hybla); + return 0; +} + +static void __exit hybla_exit(void) +{ + tcp_ca_unregister(&tcp_hybla); +} + +module_init(hybla_init); +module_exit(hybla_exit); + +MODULE_AUTHOR("Daniele Lacamera"); +MODULE_LICENSE("GPL"); +MODULE_DESCRIPTION("TCP Hybla"); --Boundary-00=_vTrPCXRNYzoQLAt-- From hadi@cyberus.ca Mon Mar 21 05:15:05 2005 Received: with ECARTIS (v1.0.0; list netdev); Mon, 21 Mar 2005 05:15:11 -0800 (PST) Received: from mx01.cybersurf.com (mx01.cybersurf.com [209.197.145.104]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j2LDF51Z009084 for ; Mon, 21 Mar 2005 05:15:05 -0800 Received: from mail.cyberus.ca ([209.197.145.21]) by mx01.cybersurf.com with esmtp (Exim 4.30) id 1DDMkE-00025U-Jx for netdev@oss.sgi.com; Mon, 21 Mar 2005 06:14:58 -0700 Received: from [24.103.99.32] (helo=[10.0.0.9]) by mail.cyberus.ca with esmtp (Exim 4.20) id 1DDMkA-0007HB-27; Mon, 21 Mar 2005 08:14:54 -0500 Subject: iptables breakage WAS(Re: dummy as IMQ replacement From: jamal Reply-To: hadi@cyberus.ca To: Andy Furniss Cc: Harald Welte , Patrick McHardy , Remus , netdev@oss.sgi.com, Nguyen Dinh Nam , Andre Tomt , syrius.ml@no-log.org, Damion de Soto In-Reply-To: <423B7BCB.10400@dsl.pipex.com> References: <1107123123.8021.80.camel@jzny.localdomain> <0fcf01c5077f$579e4b80$6e69690a@RIMAS> <1107174142.8021.121.camel@jzny.localdomain> <00c301c524b4$938cd240$6e69690a@RIMAS> <1110379135.1091.143.camel@jzny.localdomain> <1110416767.1111.76.camel@jzny.localdomain> <025501c52552$2dbf87c0$6e69690a@RIMAS> <1110453757.1108.87.camel@jzny.localdomain> <423B7BCB.10400@dsl.pipex.com> Content-Type: text/plain Organization: jamalopolous Message-Id: <1111410890.1092.195.camel@jzny.localdomain> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.2.2 Date: 21 Mar 2005 08:14:50 -0500 Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV 0.83/778/Mon Mar 21 02:48:43 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 432 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: hadi@cyberus.ca Precedence: bulk X-list: netdev Content-Length: 1486 Lines: 40 On Fri, 2005-03-18 at 20:09, Andy Furniss wrote: > jamal wrote: > > Hi Remus, > > I could not reproduce this one - it is also a bit odd for calloc to > > fail. I dont have iptables 1.3.1 but i will get and retry. > > Does this happen all the time? > > I get the same with iptables 1.3.1 and 1.3.0 > > iptables: calloc failed: Cannot allocate memory > > using kernel 2.6.11.3 and tc iproute2-ss050314 > > If I try an earlier iptables (tested 9, 10, 11) I get > Ok, I think i figured this one out as well - sorry dont have access to my test hardware still to verify. As i was suspecting this is related to iptables breaking backwards compatibility. Starting with 1.3.0 the target structure changed ;-> (right at the top is a new field called version) I suspect the iptables folks maybe unaware that there are other users of iptables and assume that anyone needing to use new iptables will recompile everything from scratch. BAD! BAD! I am ccing the necessary evil doers (Harald and Patrick - at least they would know who the real evildoer is). To test the theory copy iptables.h and iptables_common.h from iptables-1.3.1/include into iproute2/include with the latest iproute2 and recompile. Make sure m_ipt.c is recompiled - you may have to do a make clean in iproute2/tc/ I should be able to validate all this stuff starting tommorow evening. Also I have a feeling if you make this change, things will not work for iptables <=1.2.9/10/11. Can you verify that? cheers, jamal From sfrost@ns.snowman.net Mon Mar 21 06:52:00 2005 Received: with ECARTIS (v1.0.0; list netdev); Mon, 21 Mar 2005 06:52:05 -0800 (PST) Received: from relay.snowman.net (relay.snowman.net [66.92.160.56]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j2LEpx1I021841 for ; Mon, 21 Mar 2005 06:52:00 -0800 Received: from ns.snowman.net (ns.snowman.net [10.10.0.2]) by relay.snowman.net (8.13.1/8.13.1/Debian-19) with ESMTP id j2LEpqFs003382 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT) for ; Mon, 21 Mar 2005 09:51:52 -0500 Received: from ns.snowman.net (localhost [127.0.0.1]) by ns.snowman.net (8.13.1/8.13.1/Debian-19) with ESMTP id j2LEqNcN007759 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT) for ; Mon, 21 Mar 2005 09:52:23 -0500 Received: (from sfrost@localhost) by ns.snowman.net (8.13.1/8.13.1/Submit) id j2LEqN0M007757 for netdev@oss.sgi.com; Mon, 21 Mar 2005 09:52:23 -0500 Date: Mon, 21 Mar 2005 09:52:23 -0500 From: Stephen Frost To: netdev@oss.sgi.com Subject: [IPSEC] Too many SADs! Message-ID: <20050321145223.GA5834@ns.snowman.net> Mail-Followup-To: netdev@oss.sgi.com Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline X-Editor: Vim http://www.vim.org/ X-Info: http://www.snowman.net X-Operating-System: Linux/2.4.24ns.3.0 (i686) X-Uptime: 09:21:35 up 415 days, 9:13, 14 users, load average: 0.81, 0.26, 0.19 User-Agent: Mutt/1.5.6+20040907i X-Virus-Scanned: ClamAV 0.83/778/Mon Mar 21 02:48:43 2005 on oss.sgi.com X-Virus-Status: Clean Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by oss.sgi.com id j2LEpx1I021841 X-archive-position: 433 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: sfrost@snowman.net Precedence: bulk X-list: netdev Content-Length: 1744 Lines: 51 Greetings, This seems to be the right place for Linux 2.6 ipsec issues: Linux 2.6.10 + Virtual Server 1.9.4 + Patrick's IPSEC Netfilter patches i386 & amd64 (same source for both) Debian Racoon & ipsec-tools 0.5-4 Setting policies using setkey (not using racoon-tool) Using both transport and tunnels Problem: ===# setkey -D | grep '^[0-9]' | wc -l recv: Resource temporarily unavailable 443 ===# setkey -D | grep mature | wc -l recv: Resource temporarily unavailable 443 ===# setkey -D | grep tunnel | wc -l recv: Resource temporarily unavailable 18 ===# setkey -D | grep transport | wc -l recv: Resource temporarily unavailable 425 ===# ps auwx | grep racoon root 17722 3.8 2.0 178268 168252 ? Ss Mar20 28:39 /usr/sbin/racoon ===# setkey -D -P | grep '^[0-9]' | wc -l 34 ===# setkey -D -P | grep transport | wc -l 20 ===# setkey -D -P | grep tunnel | wc -l 14 I've seen the number of tunnel SADs go up a bunch too on another machine. I see that there's been some changes in 2.6.11.3 (or so?) wrt IPSEC and __xfrm_state_find_acq_byseq(), would that likely fix this problem? I don't tend to use /unique:x but rather /require; in my policies, would changing that fix this? I had originally been using a /24 for my transport policy and thought changing that to be a bunch of /32 policies for the specific machines I'm talking to would help- it didn't. Occationally (generally when I first get ipsec going between a couple machines) I see pmtu problems which kill that ssh, but after that it works. Not a big deal but I see alot of MTU discussion and patches, is that expected to be in 2.6.12? Thanks for any help, Stephen From mika.penttila@kolumbus.fi Mon Mar 21 08:10:30 2005 Received: with ECARTIS (v1.0.0; list netdev); Mon, 21 Mar 2005 08:10:35 -0800 (PST) Received: from mail-gw.turkuamk.fi (mail-gw.turkuamk.fi [195.148.208.32]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j2LGAStw030798 for ; Mon, 21 Mar 2005 08:10:29 -0800 Received: from localhost (localhost.localdomain [127.0.0.1]) by mail-gw.turkuamk.fi (Postfix) with ESMTP id 2AEF4F30E4; Mon, 21 Mar 2005 18:10:22 +0200 (EET) Received: from mail-gw.turkuamk.fi ([127.0.0.1]) by localhost (mail-gw.turkuamk.fi [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 01959-06; Mon, 21 Mar 2005 18:10:22 +0200 (EET) Received: from notes.hallinto.turkuamk.fi (notes.hallinto.turkuamk.fi [195.148.215.149]) by mail-gw.turkuamk.fi (Postfix) with ESMTP id 07703F30C8; Mon, 21 Mar 2005 18:10:22 +0200 (EET) Received: from [192.168.0.34] ([193.166.136.70]) by marconi.hallinto.turkuamk.fi (Lotus Domino Release 5.0.8) with ESMTP id 2005032118122148:54175 ; Mon, 21 Mar 2005 18:12:21 +0200 Message-ID: <423EF2CF.7020403@kolumbus.fi> Date: Mon, 21 Mar 2005 18:14:07 +0200 From: =?ISO-8859-1?Q?Mika_Penttil=E4?= User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.3) Gecko/20041020 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Herbert Xu Cc: "David S. Miller" , Alexey Kuznetsov , YOSHIFUJI Hideaki , Patrick McHardy , netdev@oss.sgi.com Subject: Re: [15/*] [INET] Fix IPsec calculation in ip_append_data/ip6_append_data References: <20050214221200.GA18465@gondor.apana.org.au> <20050214221433.GB18465@gondor.apana.org.au> <20050214221607.GC18465@gondor.apana.org.au> <20050306213214.7d8a143d.davem@davemloft.net> <20050307103536.GB7137@gondor.apana.org.au> <20050308102741.GA23468@gondor.apana.org.au> <20050314102614.GA9610@gondor.apana.org.au> <20050314105313.GA21001@gondor.apana.org.au> <20050314111002.GA29156@gondor.apana.org.au> <20050315091904.GA6256@gondor.apana.org.au> <20050316113149.GA10960@gondor.apana.org.au> In-Reply-To: <20050316113149.GA10960@gondor.apana.org.au> X-MIMETrack: Itemize by SMTP Server on marconi.hallinto.turkuamk.fi/TAMK(Release 5.0.8 |June 18, 2001) at 21.03.2005 18:12:21, Serialize by Router on notes.hallinto.turkuamk.fi/TAMK(Release 5.0.10 |March 22, 2002) at 21.03.2005 18:12:49, Serialize complete at 21.03.2005 18:12:49 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii; format=flowed X-Virus-Scanned: ClamAV 0.83/778/Mon Mar 21 02:48:43 2005 on oss.sgi.com X-Virus-Scanned: by amavisd-new at tekniikka.turkuamk.fi X-Virus-Status: Clean X-archive-position: 434 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: mika.penttila@kolumbus.fi Precedence: bulk X-list: netdev Content-Length: 935 Lines: 33 Herbert Xu wrote: >Hi Dave: > >On Tue, Mar 15, 2005 at 08:19:04PM +1100, herbert wrote: > > >>This patch fixes the IPsec overhead handling in ip_append_data and >>ip6_append_data. As it is they assume that the IPsec overhead is >>constant. This is not true as with ESP the IPsec overhead will vary >>as the MTU varies. >> >> > >This patch is wrong. This is the *one* place where we do need to >use the path MTU. The reason is that when the packet is fragmented >we only pay for the IPsec overhead once over all and not once for >each fragment. > >Please revert it for now. > >The trailer_len in ip_append_data is not quite right as the trailer's >length depends on the length of the entire packet. However, it should >be harmless since ESP knows how to extend the packet when necessary. > >Thanks, > > Shouldn't ip_output also use the path variant, dst_mtu(skb->dst->path), it's surely after ipsec- processing? --Mika From tgraf@suug.ch Mon Mar 21 10:17:14 2005 Received: with ECARTIS (v1.0.0; list netdev); Mon, 21 Mar 2005 10:17:22 -0800 (PST) Received: from b.mx.projectdream.org (eth0-0.arisu.projectdream.org [194.158.4.191]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j2LIHDYg016647 for ; Mon, 21 Mar 2005 10:17:14 -0800 Received: from postel.suug.ch (postel.suug.ch [195.134.158.23]) (using TLSv1 with cipher EDH-RSA-DES-CBC3-SHA (168/168 bits)) (No client certificate requested) by b.mx.projectdream.org (Postfix) with ESMTP id 109F682 for ; Mon, 21 Mar 2005 19:16:46 +0100 (CET) Received: by postel.suug.ch (Postfix, from userid 10001) id C9D6C1C0EA; Mon, 21 Mar 2005 19:17:29 +0100 (CET) Date: Mon, 21 Mar 2005 19:17:29 +0100 From: Thomas Graf To: netdev@oss.sgi.com Subject: [IPROUTE2] Routing attribute alignment fix Message-ID: <20050321181729.GK3086@postel.suug.ch> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline X-Virus-Scanned: ClamAV 0.83/778/Mon Mar 21 02:48:43 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 435 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: tgraf@suug.ch Precedence: bulk X-list: netdev Content-Length: 2122 Lines: 61 In case someone experiences dsmark qdisc not working correctly with the latest iproute2 release, here's patch which fixes the problem (and possibly other problem as well). The alignment of nlmsg_len is calculated wrong leading to wrong rta_len calculations for nested TLVs when the data length of the last TLV added to the nested TLV is not aligned to RTA_ALIGNTO already. bk tree with this fix and support for multipath algorithm selection can be found here: bk://kernel.bkbits.net/tgraf/iproute2-tgr # This is a BitKeeper generated diff -Nru style patch. # # ChangeSet # 2005/03/20 17:19:39+01:00 tgraf@suug.ch # Fix netlink message alignment when the last routing attribute added # has a data length not aligned to RTA_ALIGNTO. # # lib/libnetlink.c # 2005/03/20 17:19:38+01:00 tgraf@suug.ch +4 -4 # Fix netlink message alignment when the last routing attribute added # has a data length not aligned to RTA_ALIGNTO. # diff -Nru a/lib/libnetlink.c b/lib/libnetlink.c --- a/lib/libnetlink.c 2005-03-21 19:12:49 +01:00 +++ b/lib/libnetlink.c 2005-03-21 19:12:49 +01:00 @@ -491,7 +491,7 @@ int len = RTA_LENGTH(alen); struct rtattr *rta; - if (NLMSG_ALIGN(n->nlmsg_len) + len > maxlen) { + if (NLMSG_ALIGN(n->nlmsg_len) + RTA_ALIGN(len) > maxlen) { fprintf(stderr, "addattr_l ERROR: message exceeded bound of %d\n",maxlen); return -1; } @@ -499,7 +499,7 @@ rta->rta_type = type; rta->rta_len = len; memcpy(RTA_DATA(rta), data, alen); - n->nlmsg_len = NLMSG_ALIGN(n->nlmsg_len) + len; + n->nlmsg_len = NLMSG_ALIGN(n->nlmsg_len) + RTA_ALIGN(len); return 0; } @@ -539,7 +539,7 @@ struct rtattr *subrta; int len = RTA_LENGTH(alen); - if (RTA_ALIGN(rta->rta_len) + len > maxlen) { + if (RTA_ALIGN(rta->rta_len) + RTA_ALIGN(len) > maxlen) { fprintf(stderr,"rta_addattr_l: Error! max allowed bound %d exceeded\n",maxlen); return -1; } @@ -547,7 +547,7 @@ subrta->rta_type = type; subrta->rta_len = len; memcpy(RTA_DATA(subrta), data, alen); - rta->rta_len = NLMSG_ALIGN(rta->rta_len) + len; + rta->rta_len = NLMSG_ALIGN(rta->rta_len) + RTA_ALIGN(len); return 0; } From maxk@qualcomm.com Mon Mar 21 10:27:35 2005 Received: with ECARTIS (v1.0.0; list netdev); Mon, 21 Mar 2005 10:27:40 -0800 (PST) Received: from numenor.qualcomm.com (numenor.qualcomm.com [129.46.51.58]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j2LIRZio018010 for ; Mon, 21 Mar 2005 10:27:35 -0800 Received: from magus.qualcomm.com (magus.qualcomm.com [129.46.61.148]) by numenor.qualcomm.com (8.12.10/8.12.5/1.0) with ESMTP id j2LIQEe2018517 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Mon, 21 Mar 2005 10:26:15 -0800 (PST) Received: from [129.46.90.158] (workie.qualcomm.com [129.46.90.158]) by magus.qualcomm.com (8.12.10/8.12.5/1.0) with ESMTP id j2LIQBfX006619; Mon, 21 Mar 2005 10:26:11 -0800 (PST) Message-ID: <423F11C3.2020803@qualcomm.com> Date: Mon, 21 Mar 2005 10:26:11 -0800 From: Max Krasnyansky User-Agent: Mozilla Thunderbird 0.9 (X11/20041127) X-Accept-Language: en-us, en MIME-Version: 1.0 To: hadi@cyberus.ca CC: Chris Wright , "David S. Miller" , netdev@oss.sgi.com Subject: Re: [PATCH] remove unused netlink NL_EMULATE_DEV code References: <20050318233637.GS5389@shell0.pdx.osdl.net> <423B6DAE.9050803@qualcomm.com> <20050319010253.GU5389@shell0.pdx.osdl.net> <1111196899.1264.118.camel@jzny.localdomain> In-Reply-To: <1111196899.1264.118.camel@jzny.localdomain> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-PMX-Version: 4.7.0.111621 X-Virus-Scanned: ClamAV 0.83/778/Mon Mar 21 02:48:43 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 436 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: maxk@qualcomm.com Precedence: bulk X-list: netdev Content-Length: 340 Lines: 15 jamal wrote: > 1 > On Fri, 2005-03-18 at 20:02, Chris Wright wrote: > > >>I'd prefer that too. What about the netlink_dev implementation itself? >>Should it be marked obsolete? >> > > It should die - pieces of it have already been slowly disapearing. Totally agree. Even for Ethertap it was easy to use Netlink sockets directly. Max From linville@bilbo.tuxdriver.com Mon Mar 21 12:02:39 2005 Received: with ECARTIS (v1.0.0; list netdev); Mon, 21 Mar 2005 12:02:46 -0800 (PST) Received: from ra.tuxdriver.com (ra.tuxdriver.com [24.172.12.4]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j2LK2c1U027417 for ; Mon, 21 Mar 2005 12:02:39 -0800 Received: from bilbo.tuxdriver.com (bilbo.tuxdriver.com [24.172.12.5]) by ra.tuxdriver.com (8.11.6/8.11.6) with ESMTP id j2LJsoM31065; Mon, 21 Mar 2005 14:54:50 -0500 Received: from bilbo.tuxdriver.com (localhost.localdomain [127.0.0.1]) by bilbo.tuxdriver.com (8.13.1/8.13.1) with ESMTP id j2LK2Su7032421; Mon, 21 Mar 2005 15:02:28 -0500 Received: (from linville@localhost) by bilbo.tuxdriver.com (8.13.1/8.13.1/Submit) id j2LK2RCf032420; Mon, 21 Mar 2005 15:02:27 -0500 Date: Mon, 21 Mar 2005 15:02:27 -0500 From: "John W. Linville" To: linux-kernel@vger.kernel.org Cc: cramerj@intel.com, john.ronciak@intel.com, ganesh.venkatesan@intel.com, netdev@oss.sgi.com, jgarzik@pobox.com Subject: [patch 2.6.11] e1000: flush work queues on remove Message-ID: <20050321200222.GA32390@tuxdriver.com> Mail-Followup-To: linux-kernel@vger.kernel.org, cramerj@intel.com, john.ronciak@intel.com, ganesh.venkatesan@intel.com, netdev@oss.sgi.com, jgarzik@pobox.com Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.4.1i X-Virus-Scanned: ClamAV 0.83/778/Mon Mar 21 02:48:43 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 437 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: linville@tuxdriver.com Precedence: bulk X-list: netdev Content-Length: 923 Lines: 26 Flush work queues in ->remove() for e1000. Acked-by: Ganesh Venkatesan Signed-off-by: John W. Linville --- Since e1000 is using work queues, we need to call flush_scheduled_work() before removing the driver from memory. Otherwise, we are prone to an Oops... drivers/net/e1000/e1000_main.c | 2 ++ 1 files changed, 2 insertions(+) --- e1000-work-flush-2.6/drivers/net/e1000/e1000_main.c.orig 2005-03-17 21:37:30.000000000 -0500 +++ e1000-work-flush-2.6/drivers/net/e1000/e1000_main.c 2005-03-21 14:52:46.077220964 -0500 @@ -660,6 +660,8 @@ e1000_remove(struct pci_dev *pdev) struct e1000_adapter *adapter = netdev->priv; uint32_t manc; + flush_scheduled_work(); + if(adapter->hw.mac_type >= e1000_82540 && adapter->hw.media_type == e1000_media_type_copper) { manc = E1000_READ_REG(&adapter->hw, MANC); -- John W. Linville linville@tuxdriver.com From buytenh@wantstofly.org Mon Mar 21 12:11:30 2005 Received: with ECARTIS (v1.0.0; list netdev); Mon, 21 Mar 2005 12:11:36 -0800 (PST) Received: from xi.wantstofly.org (alephnull.demon.nl [212.238.201.82]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j2LKBTtJ028832 for ; Mon, 21 Mar 2005 12:11:30 -0800 Received: by xi.wantstofly.org (Postfix, from userid 500) id C014B2B0EC; Mon, 21 Mar 2005 21:11:28 +0100 (MET) Date: Mon, 21 Mar 2005 21:11:28 +0100 From: Lennert Buytenhek To: Stephen Hemminger Cc: netdev@oss.sgi.com Subject: Re: Iproute2: update Message-ID: <20050321201128.GA10625@xi.wantstofly.org> References: <20050112125903.64d42737@dxpl.pdx.osdl.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20050112125903.64d42737@dxpl.pdx.osdl.net> User-Agent: Mutt/1.4.1i X-Virus-Scanned: ClamAV 0.83/778/Mon Mar 21 02:48:43 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 438 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: buytenh@wantstofly.org Precedence: bulk X-list: netdev Content-Length: 1779 Lines: 57 On Wed, Jan 12, 2005 at 12:59:03PM -0800, Stephen Hemminger wrote: > There is an new version of iproute2 for testing. > http://developer.osdl.org/dev/iproute2/download/iproute2-2.6.10-ss050112.tar.gz Doesn't build on my box (ARM platform): gcc -D_GNU_SOURCE -O2 -Wstrict-prototypes -Wall -g -I../include -DRESOLVE_HOSTNAMES -DCONFIG_GACT -DCONFIG_GACT_PROB -o normal normal.c -lm ./normal >normal.dist *** glibc detected *** double free or corruption: 0x00011050 *** /bin/sh: line 1: 30106 Aborted ./normal >normal.dist make[1]: *** [normal.dist] Error 134 The same thing for paretonormal. TABLESIZE is 16384, and some debug code shows that it's trying to write one element past the end of the table: setting table[16384] to 4.008800 setting table[16384] to 4.008850 [...] setting table[16384] to 10.049950 setting table[16384] to 10.050000 I thought it was a floating point emulation bug at first, but it also appears to do this on my x86. We don't use table[16384] anyway, so this works: --L --- iproute2-2.6.9/tc/paretonormal.c.orig 2005-03-21 21:04:21.863592000 +0100 +++ iproute2-2.6.9/tc/paretonormal.c 2005-03-21 21:07:34.590781000 +0100 @@ -62,7 +62,8 @@ for (x = -10.0; x < 10.05; x += .00005) { i = (int)rint(TABLESIZE*normal(x, 0.0, 1.0)); - table[i] = x; + if (i >= 0 && i < TABLESIZE) + table[i] = x; } printf( "# This is the distribution table for the paretonormal distribution.\n" --- iproute2-2.6.9/tc/normal.c.orig 2005-03-21 21:00:40.420057000 +0100 +++ iproute2-2.6.9/tc/normal.c 2005-03-21 21:01:08.040316000 +0100 @@ -35,7 +35,8 @@ for (x = -10.0; x < 10.05; x += .00005) { i = (int)rint(TABLESIZE*normal(x, 0.0, 1.0)); - table[i] = x; + if (i >= 0 && i < TABLESIZE) + table[i] = x; } From herbert@gondor.apana.org.au Mon Mar 21 12:30:14 2005 Received: with ECARTIS (v1.0.0; list netdev); Mon, 21 Mar 2005 12:30:21 -0800 (PST) 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 j2LKUCKg001591 for ; Mon, 21 Mar 2005 12:30:13 -0800 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 1DDTWM-0002Bz-00; Tue, 22 Mar 2005 07:29:06 +1100 Received: from herbert by gondolin.me.apana.org.au with local (Exim 3.36 #1 (Debian)) id 1DDTVM-0000oN-00; Tue, 22 Mar 2005 07:28:04 +1100 Date: Tue, 22 Mar 2005 07:28:04 +1100 To: Mika Penttil? Cc: "David S. Miller" , Alexey Kuznetsov , YOSHIFUJI Hideaki , Patrick McHardy , netdev@oss.sgi.com Subject: Re: [15/*] [INET] Fix IPsec calculation in ip_append_data/ip6_append_data Message-ID: <20050321202804.GA3106@gondor.apana.org.au> References: <20050214221607.GC18465@gondor.apana.org.au> <20050306213214.7d8a143d.davem@davemloft.net> <20050307103536.GB7137@gondor.apana.org.au> <20050308102741.GA23468@gondor.apana.org.au> <20050314102614.GA9610@gondor.apana.org.au> <20050314105313.GA21001@gondor.apana.org.au> <20050314111002.GA29156@gondor.apana.org.au> <20050315091904.GA6256@gondor.apana.org.au> <20050316113149.GA10960@gondor.apana.org.au> <423EF2CF.7020403@kolumbus.fi> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <423EF2CF.7020403@kolumbus.fi> User-Agent: Mutt/1.5.6+20040907i From: Herbert Xu X-Virus-Scanned: ClamAV 0.83/778/Mon Mar 21 02:48:43 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 439 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: herbert@gondor.apana.org.au Precedence: bulk X-list: netdev Content-Length: 631 Lines: 17 On Mon, Mar 21, 2005 at 06:14:07PM +0200, Mika Penttil? wrote: > > Shouldn't ip_output also use the path variant, dst_mtu(skb->dst->path), > it's surely after ipsec- processing? That's the reason why it shouldn't use dst->path. The only time you should use dst_mtu(dst->path) is when dst may contain IPsec AND you need the MTU outside IPsec. In this case dst cannot contain IPsec so dst_mtu(dst) is correct. Cheers, -- Visit Openswan at http://www.openswan.org/ Email: Herbert Xu ~{PmV>HI~} Home Page: http://gondor.apana.org.au/~herbert/ PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt From mika.penttila@kolumbus.fi Mon Mar 21 13:26:21 2005 Received: with ECARTIS (v1.0.0; list netdev); Mon, 21 Mar 2005 13:26:26 -0800 (PST) Received: from mail-gw.turkuamk.fi (mail-gw.turkuamk.fi [195.148.208.32]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j2LLQJbZ006170 for ; Mon, 21 Mar 2005 13:26:20 -0800 Received: from localhost (localhost.localdomain [127.0.0.1]) by mail-gw.turkuamk.fi (Postfix) with ESMTP id 42743F3149; Mon, 21 Mar 2005 23:26:13 +0200 (EET) Received: from mail-gw.turkuamk.fi ([127.0.0.1]) by localhost (mail-gw.turkuamk.fi [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 12348-01; Mon, 21 Mar 2005 23:26:13 +0200 (EET) Received: from notes.hallinto.turkuamk.fi (notes.hallinto.turkuamk.fi [195.148.215.149]) by mail-gw.turkuamk.fi (Postfix) with ESMTP id 1C3FFF3147; Mon, 21 Mar 2005 23:26:13 +0200 (EET) Received: from [192.168.0.34] ([193.166.136.70]) by marconi.hallinto.turkuamk.fi (Lotus Domino Release 5.0.8) with ESMTP id 2005032123281266:54529 ; Mon, 21 Mar 2005 23:28:12 +0200 Message-ID: <423F3CD6.7090109@kolumbus.fi> Date: Mon, 21 Mar 2005 23:29:58 +0200 From: =?ISO-8859-1?Q?Mika_Penttil=E4?= User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.3) Gecko/20041020 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Herbert Xu Cc: "David S. Miller" , Alexey Kuznetsov , YOSHIFUJI Hideaki , Patrick McHardy , netdev@oss.sgi.com Subject: Re: [15/*] [INET] Fix IPsec calculation in ip_append_data/ip6_append_data References: <20050214221607.GC18465@gondor.apana.org.au> <20050306213214.7d8a143d.davem@davemloft.net> <20050307103536.GB7137@gondor.apana.org.au> <20050308102741.GA23468@gondor.apana.org.au> <20050314102614.GA9610@gondor.apana.org.au> <20050314105313.GA21001@gondor.apana.org.au> <20050314111002.GA29156@gondor.apana.org.au> <20050315091904.GA6256@gondor.apana.org.au> <20050316113149.GA10960@gondor.apana.org.au> <423EF2CF.7020403@kolumbus.fi> <20050321202804.GA3106@gondor.apana.org.au> In-Reply-To: <20050321202804.GA3106@gondor.apana.org.au> X-MIMETrack: Itemize by SMTP Server on marconi.hallinto.turkuamk.fi/TAMK(Release 5.0.8 |June 18, 2001) at 21.03.2005 23:28:12, Serialize by Router on notes.hallinto.turkuamk.fi/TAMK(Release 5.0.10 |March 22, 2002) at 21.03.2005 23:28:40, Serialize complete at 21.03.2005 23:28:40 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii; format=flowed X-Virus-Scanned: ClamAV 0.83/778/Mon Mar 21 02:48:43 2005 on oss.sgi.com X-Virus-Scanned: by amavisd-new at tekniikka.turkuamk.fi X-Virus-Status: Clean X-archive-position: 440 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: mika.penttila@kolumbus.fi Precedence: bulk X-list: netdev Content-Length: 541 Lines: 24 Herbert Xu wrote: >On Mon, Mar 21, 2005 at 06:14:07PM +0200, Mika Penttil? wrote: > > >>Shouldn't ip_output also use the path variant, dst_mtu(skb->dst->path), >>it's surely after ipsec- processing? >> >> > >That's the reason why it shouldn't use dst->path. The only time you >should use dst_mtu(dst->path) is when dst may contain IPsec AND you >need the MTU outside IPsec. > >In this case dst cannot contain IPsec so dst_mtu(dst) is correct. > >Cheers, > > ok I see it now, but this is really easy to get wrong... Thanks, Mika From jheffner@psc.edu Mon Mar 21 13:26:21 2005 Received: with ECARTIS (v1.0.0; list netdev); Mon, 21 Mar 2005 13:26:27 -0800 (PST) Received: from mailer2.psc.edu (mailer2.psc.edu [128.182.66.106]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j2LLQKFq006175 for ; Mon, 21 Mar 2005 13:26:21 -0800 Received: from dexter.psc.edu (dexter.psc.edu [128.182.61.232]) by mailer2.psc.edu (8.13.3/8.13.3) with ESMTP id j2LLSvNv021061 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 21 Mar 2005 16:29:01 -0500 (EST) Received: from dexter.psc.edu (localhost.psc.edu [127.0.0.1]) by dexter.psc.edu (8.12.11/8.12.10) with ESMTP id j2LLPvnU007534; Mon, 21 Mar 2005 16:25:57 -0500 Received: from localhost (jheffner@localhost) by dexter.psc.edu (8.12.11/8.12.11/Submit) with ESMTP id j2LLPu3u007531; Mon, 21 Mar 2005 16:25:56 -0500 X-Authentication-Warning: dexter.psc.edu: jheffner owned process doing -bs Date: Mon, 21 Mar 2005 16:25:56 -0500 (EST) From: John Heffner To: Andi Kleen cc: Stephen Hemminger , baruch@ev-en.org, netdev@oss.sgi.com Subject: Re: [RFC] TCP congestion schedulers In-Reply-To: Message-ID: References: <421CF5E5.1060606@ev-en.org> <20050223135732.39e62c6c.davem@davemloft.net> <421D1E66.5090301@osdl.org> <421D30FA.1060900@ev-en.org> <20050225120814.5fa77b13@dxpl.pdx.osdl.net> <20050309210442.3e9786a6.davem@davemloft.net> <4230288F.1030202@ev-en.org> <20050310182629.1eab09ec.davem@davemloft.net> <20050311120054.4bbf675a@dxpl.pdx.osdl.net> <20050311201011.360c00da.davem@davemloft.net> <20050314151726.532af90d@dxpl.pdx.osdl.net> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Virus-Scanned: ClamAV 0.83/778/Mon Mar 21 02:48:43 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 441 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: jheffner@psc.edu Precedence: bulk X-list: netdev Content-Length: 1028 Lines: 27 On Sat, 19 Mar 2005, Andi Kleen wrote: > Stephen Hemminger writes: > > > Since developers want to experiment with different congestion > > control mechanisms, and the kernel is getting bloated with overlapping > > data structure and code for multiple algorithms; here is a patch to > > split out the Reno, Vegas, Westwood, BIC congestion control stuff > > into an infrastructure similar to the I/O schedulers. > > [...] > > Did you do any benchmarks to check that wont slow it down? > > I would recommend to try it on a IA64 machine if possible. In the > past we found that adding indirect function calls on IA64 to networking > caused measurable slowdowns in macrobenchmarks. > In that case it was LSM callbacks, but your code looks like it will > add even more. Is there a canonical benchmark? Would you really expect a single extra indirect call per ack to have a significant performance impact? This is surprising to me. Where does the cost come from? Replacing instruction cache lines? -John From romieu@fr.zoreil.com Mon Mar 21 13:36:37 2005 Received: with ECARTIS (v1.0.0; list netdev); Mon, 21 Mar 2005 13:36:44 -0800 (PST) Received: from fr.zoreil.com (electric-eye.fr.zoreil.com [213.41.134.224]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j2LLaaKP007900 for ; Mon, 21 Mar 2005 13:36:37 -0800 Received: from electric-eye.fr.zoreil.com (localhost.localdomain [127.0.0.1]) by fr.zoreil.com (8.13.1/8.12.1) with ESMTP id j2LLYERN031244; Mon, 21 Mar 2005 22:34:14 +0100 Received: (from romieu@localhost) by electric-eye.fr.zoreil.com (8.13.1/8.13.1/Submit) id j2LLY9MA031243; Mon, 21 Mar 2005 22:34:09 +0100 Date: Mon, 21 Mar 2005 22:34:09 +0100 From: Francois Romieu To: "David S. Miller" Cc: netdev@oss.sgi.com Subject: [patch 2.6.12-rc1-bk1] multipath: early use of inlined function Message-ID: <20050321213409.GA28998@electric-eye.fr.zoreil.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.4.1i X-Organisation: Land of Sunshine Inc. X-Virus-Scanned: ClamAV 0.83/778/Mon Mar 21 02:48:43 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 442 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: romieu@fr.zoreil.com Precedence: bulk X-list: netdev Content-Length: 1948 Lines: 54 Early use of inlined function $ grep -n compare_keys net/ipv4/route.c 151:static inline int compare_keys(struct flowi *fl1, struct flowi *fl2); ^^^ 541: compare_keys(&(*rthp)->fl, &expentry->fl)) { 861:static inline int compare_keys(struct flowi *fl1, struct flowi *fl2) 890: compare_keys(&rth->fl, &rt->fl)) { 892: if (compare_keys(&rth->fl, &rt->fl)) { Signed-off-by: Francois Romieu diff -puN net/ipv4/route.c~netdev-10 net/ipv4/route.c --- linux-2.6.12-rcX/net/ipv4/route.c~netdev-10 2005-03-21 22:24:16.639836385 +0100 +++ linux-2.6.12-rcX-fr/net/ipv4/route.c 2005-03-21 22:30:05.904038902 +0100 @@ -148,7 +148,6 @@ static struct dst_entry *ipv4_negative_a static void ipv4_link_failure(struct sk_buff *skb); static void ip_rt_update_pmtu(struct dst_entry *dst, u32 mtu); static int rt_garbage_collect(void); -static inline int compare_keys(struct flowi *fl1, struct flowi *fl2); static struct dst_ops ipv4_dst_ops = { @@ -520,6 +519,13 @@ static inline u32 rt_score(struct rtable return score; } +static inline int compare_keys(struct flowi *fl1, struct flowi *fl2) +{ + return memcmp(&fl1->nl_u.ip4_u, &fl2->nl_u.ip4_u, sizeof(fl1->nl_u.ip4_u)) == 0 && + fl1->oif == fl2->oif && + fl1->iif == fl2->iif; +} + #ifdef CONFIG_IP_ROUTE_MULTIPATH_CACHED static struct rtable **rt_remove_balanced_route(struct rtable **chain_head, struct rtable *expentry, @@ -858,13 +864,6 @@ work_done: out: return 0; } -static inline int compare_keys(struct flowi *fl1, struct flowi *fl2) -{ - return memcmp(&fl1->nl_u.ip4_u, &fl2->nl_u.ip4_u, sizeof(fl1->nl_u.ip4_u)) == 0 && - fl1->oif == fl2->oif && - fl1->iif == fl2->iif; -} - static int rt_intern_hash(unsigned hash, struct rtable *rt, struct rtable **rp) { struct rtable *rth, **rthp; _ From andy.furniss@dsl.pipex.com Mon Mar 21 13:50:35 2005 Received: with ECARTIS (v1.0.0; list netdev); Mon, 21 Mar 2005 13:50:40 -0800 (PST) Received: from astro.systems.pipex.net (astro.systems.pipex.net [62.241.163.6]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j2LLoXPq009381 for ; Mon, 21 Mar 2005 13:50:34 -0800 Received: from [192.168.0.3] (81-178-205-19.dsl.pipex.com [81.178.205.19]) by astro.systems.pipex.net (Postfix) with ESMTP id B4CE7E0000A3; Mon, 21 Mar 2005 21:50:15 +0000 (GMT) Message-ID: <423F41AD.3010902@dsl.pipex.com> Date: Mon, 21 Mar 2005 21:50:37 +0000 From: Andy Furniss User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.8b) Gecko/20050217 MIME-Version: 1.0 To: hadi@cyberus.ca CC: Harald Welte , Patrick McHardy , Remus , netdev@oss.sgi.com, Nguyen Dinh Nam , Andre Tomt , syrius.ml@no-log.org, Damion de Soto Subject: Re: iptables breakage WAS(Re: dummy as IMQ replacement References: <1107123123.8021.80.camel@jzny.localdomain> <0fcf01c5077f$579e4b80$6e69690a@RIMAS> <1107174142.8021.121.camel@jzny.localdomain> <00c301c524b4$938cd240$6e69690a@RIMAS> <1110379135.1091.143.camel@jzny.localdomain> <1110416767.1111.76.camel@jzny.localdomain> <025501c52552$2dbf87c0$6e69690a@RIMAS> <1110453757.1108.87.camel@jzny.localdomain> <423B7BCB.10400@dsl.pipex.com> <1111410890.1092.195.camel@jzny.localdomain> In-Reply-To: <1111410890.1092.195.camel@jzny.localdomain> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV 0.83/778/Mon Mar 21 02:48:43 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 443 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: andy.furniss@dsl.pipex.com Precedence: bulk X-list: netdev Content-Length: 2748 Lines: 75 jamal wrote: > On Fri, 2005-03-18 at 20:09, Andy Furniss wrote: > >>jamal wrote: >> >>>Hi Remus, >>>I could not reproduce this one - it is also a bit odd for calloc to >>>fail. I dont have iptables 1.3.1 but i will get and retry. >>>Does this happen all the time? >> >>I get the same with iptables 1.3.1 and 1.3.0 >> >>iptables: calloc failed: Cannot allocate memory >> >>using kernel 2.6.11.3 and tc iproute2-ss050314 >> >>If I try an earlier iptables (tested 9, 10, 11) I get >> > > > Ok, I think i figured this one out as well - sorry dont have access to > my test hardware still to verify. > > As i was suspecting this is related to iptables breaking backwards > compatibility. Starting with 1.3.0 the target structure changed ;-> > (right at the top is a new field called version) > I suspect the iptables folks maybe unaware that there are other users of > iptables and assume that anyone needing to use new iptables will > recompile everything from scratch. BAD! BAD! > I am ccing the necessary evil doers (Harald and Patrick - at least they > would know who the real evildoer is). > > To test the theory copy iptables.h and iptables_common.h from > iptables-1.3.1/include into iproute2/include with the latest iproute2 > and recompile. Make sure m_ipt.c is recompiled - you may have to do a > make clean in iproute2/tc/ I haven't done a new kernel with stats patched yet. Using iptables 1.3.1 and iproute2-ss050314 with iptables headers I now get below instead of memory error. ++ /usr/sbin/tc filter add dev eth0 parent ffff: protocol ip prio 10 u32 match u32 0 0 flowid 1:1 action ipt -j MARK --set-mark 1 action mirred egress redirect dev dummy0 tablename: mangle hook: NF_IP_PRE_ROUTING target: MARK set 0x1 index 0 bad action type mirred Usage: ... gact [RAND] [INDEX] Where: ACTION := reclassify | drop | continue | pass RAND := random RANDTYPE := netrand | determVAL : = value not exceeding 10000INDEX := index value used bad action parsing parse_action: bad value (5:mirred)! Illegal "action" I will try with new kernel later tonight. > > I should be able to validate all this stuff starting tommorow evening. > Also I have a feeling if you make this change, things will not work for > iptables <=1.2.9/10/11. Can you verify that? > Yes it segfaults with iptables v1.2.11 ++ /usr/sbin/tc filter add dev eth0 parent ffff: protocol ip prio 10 u32 match u32 0 0 flowid 1:1 action ipt -j MARK --set-mark 1 action mirred egress redirect dev dummy0 ./dummy-ingress-2: line 43: 1345 Segmentation fault $TC filter add dev eth0 parent ffff: protocol ip prio 10 u32 match u32 0 0 flowid 1:1 action ipt -j MARK --set-mark 1 action mirred egress redirect dev dummy0 From davem@davemloft.net Mon Mar 21 13:53:24 2005 Received: with ECARTIS (v1.0.0; list netdev); Mon, 21 Mar 2005 13:53:31 -0800 (PST) Received: from cheetah.davemloft.net (mail@dsl027-180-174.sfo1.dsl.speakeasy.net [216.27.180.174]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j2LLrOkn010146 for ; Mon, 21 Mar 2005 13:53:24 -0800 Received: from localhost ([127.0.0.1] helo=cheetah.davemloft.net ident=davem) by cheetah.davemloft.net with smtp (Exim 3.36 #1 (Debian)) id 1DDUoU-0000rB-00; Mon, 21 Mar 2005 13:51:54 -0800 Date: Mon, 21 Mar 2005 13:51:54 -0800 From: "David S. Miller" To: John Heffner Cc: ak@muc.de, shemminger@osdl.org, baruch@ev-en.org, netdev@oss.sgi.com Subject: Re: [RFC] TCP congestion schedulers Message-Id: <20050321135154.0bbeae85.davem@davemloft.net> In-Reply-To: References: <421CF5E5.1060606@ev-en.org> <20050223135732.39e62c6c.davem@davemloft.net> <421D1E66.5090301@osdl.org> <421D30FA.1060900@ev-en.org> <20050225120814.5fa77b13@dxpl.pdx.osdl.net> <20050309210442.3e9786a6.davem@davemloft.net> <4230288F.1030202@ev-en.org> <20050310182629.1eab09ec.davem@davemloft.net> <20050311120054.4bbf675a@dxpl.pdx.osdl.net> <20050311201011.360c00da.davem@davemloft.net> <20050314151726.532af90d@dxpl.pdx.osdl.net> X-Mailer: Sylpheed version 1.0.1 (GTK+ 1.2.10; sparc-unknown-linux-gnu) X-Face: "_;p5u5aPsO,_Vsx"^v-pEq09'CU4&Dc1$fQExov$62l60cgCc%FnIwD=.UF^a>?5'9Kn[;433QFVV9M..2eN.@4ZWPGbdi<=?[:T>y?SD(R*-3It"Vj:)"dP Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV 0.83/778/Mon Mar 21 02:48:43 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 444 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: davem@davemloft.net Precedence: bulk X-list: netdev Content-Length: 394 Lines: 9 On Mon, 21 Mar 2005 16:25:56 -0500 (EST) John Heffner wrote: > Would you really expect a single extra indirect call per ack to have a > significant performance impact? This is surprising to me. Where does the > cost come from? Replacing instruction cache lines? Maybe not for ACK processing (that's very thick already) but perhaps for a lighter fast path definitely so. From herbert@gondor.apana.org.au Mon Mar 21 14:06:04 2005 Received: with ECARTIS (v1.0.0; list netdev); Mon, 21 Mar 2005 14:06:11 -0800 (PST) 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 j2LM62Hs011685 for ; Mon, 21 Mar 2005 14:06:03 -0800 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 1DDV1N-000396-00; Tue, 22 Mar 2005 09:05:13 +1100 Received: from herbert by gondolin.me.apana.org.au with local (Exim 3.36 #1 (Debian)) id 1DDV0q-0001X1-00; Tue, 22 Mar 2005 09:04:40 +1100 Date: Tue, 22 Mar 2005 09:04:40 +1100 To: Mika Penttil? Cc: "David S. Miller" , Alexey Kuznetsov , YOSHIFUJI Hideaki , Patrick McHardy , netdev@oss.sgi.com Subject: Re: [15/*] [INET] Fix IPsec calculation in ip_append_data/ip6_append_data Message-ID: <20050321220440.GA5868@gondor.apana.org.au> References: <20050307103536.GB7137@gondor.apana.org.au> <20050308102741.GA23468@gondor.apana.org.au> <20050314102614.GA9610@gondor.apana.org.au> <20050314105313.GA21001@gondor.apana.org.au> <20050314111002.GA29156@gondor.apana.org.au> <20050315091904.GA6256@gondor.apana.org.au> <20050316113149.GA10960@gondor.apana.org.au> <423EF2CF.7020403@kolumbus.fi> <20050321202804.GA3106@gondor.apana.org.au> <423F3CD6.7090109@kolumbus.fi> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <423F3CD6.7090109@kolumbus.fi> User-Agent: Mutt/1.5.6+20040907i From: Herbert Xu X-Virus-Scanned: ClamAV 0.83/778/Mon Mar 21 02:48:43 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 445 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: herbert@gondor.apana.org.au Precedence: bulk X-list: netdev Content-Length: 612 Lines: 15 On Mon, Mar 21, 2005 at 11:29:58PM +0200, Mika Penttil? wrote: > > ok I see it now, but this is really easy to get wrong... Well the rule is actually quite simple. If IPsec can't be present, then you should always use dst_mtu(dst). If IPsec may be present, then you should also use dst_mtu(dst) *unless* you're performing an operation such as fragmentation that has to be done after IPsec. Cheers, -- Visit Openswan at http://www.openswan.org/ Email: Herbert Xu ~{PmV>HI~} Home Page: http://gondor.apana.org.au/~herbert/ PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt From andy.furniss@dsl.pipex.com Mon Mar 21 14:08:18 2005 Received: with ECARTIS (v1.0.0; list netdev); Mon, 21 Mar 2005 14:08:23 -0800 (PST) Received: from blaster.systems.pipex.net (blaster.systems.pipex.net [62.241.163.7]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j2LM8HkQ012346 for ; Mon, 21 Mar 2005 14:08:18 -0800 Received: from [192.168.0.3] (81-178-205-19.dsl.pipex.com [81.178.205.19]) by blaster.systems.pipex.net (Postfix) with ESMTP id F0B14E000266; Mon, 21 Mar 2005 22:08:06 +0000 (GMT) Message-ID: <423F45DC.6090803@dsl.pipex.com> Date: Mon, 21 Mar 2005 22:08:28 +0000 From: Andy Furniss User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.8b) Gecko/20050217 MIME-Version: 1.0 To: hadi@cyberus.ca Cc: Thomas Graf , Remus , netdev@oss.sgi.com, Nguyen Dinh Nam , Andre Tomt , syrius.ml@no-log.org, Damion de Soto Subject: Re: dummy as IMQ replacement References: <1107123123.8021.80.camel@jzny.localdomain> <0fcf01c5077f$579e4b80$6e69690a@RIMAS> <1107174142.8021.121.camel@jzny.localdomain> <00c301c524b4$938cd240$6e69690a@RIMAS> <1110379135.1091.143.camel@jzny.localdomain> <1110416767.1111.76.camel@jzny.localdomain> <025501c52552$2dbf87c0$6e69690a@RIMAS> <1110453757.1108.87.camel@jzny.localdomain> <423B7BCB.10400@dsl.pipex.com> <1111196668.1146.114.camel@jzny.localdomain> <423BFD9F.50401@dsl.pipex.com> <1111324805.1094.11.camel@jzny.localdomain> In-Reply-To: <1111324805.1094.11.camel@jzny.localdomain> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV 0.83/778/Mon Mar 21 02:48:43 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 446 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: andy.furniss@dsl.pipex.com Precedence: bulk X-list: netdev Content-Length: 1903 Lines: 60 jamal wrote: > Hi Andy, > Apologies again - I wont be able to get access to my test machine until > tuesday. > > On Sat, 2005-03-19 at 05:23, Andy Furniss wrote: > > >>$TC filter add dev eth0 parent ffff: protocol ip prio 10 u32 \ >>match u32 0 0 flowid 1:1 \ >>action ipt -j MARK --set-mark 1 >> >>It still gives memory error with 1.3.1 , with 1.2.11 it parses OK but I >>get bogus stats - hit count is OK >> >>[root@amd /home/andy/Qos]# tc -s filter ls dev eth0 parent ffff: >> >>filter protocol ip pref 10 u32 >>filter protocol ip pref 10 u32 fh 800: ht divisor 1 >>filter protocol ip pref 10 u32 fh 800::800 order 2048 key ht 800 bkt 0 >>flowid 1:1 (rule hit 12 success 12) >> match 00000000/00000000 at 0 (success 12 ) >> action order 1: tablename: mangle hook: NF_IP_PRE_ROUTING >> target MARK set 0x1 >> index 1 ref 1 bind 1 installed 251 sec expires 1 sec >> Action statistics: >> Sent 7630953 bytes 0 pkt >> rate 3146Kbit 1095565348pps >> > > > Ok, this seems to be a bug in the stats - I think it may have been > introduced during the new kernel stats code updates. > Ive cced Thomas who added that code, he may be able to figure it oput > before i get back > > >>If I try with the lines below added >> >>action egress redirect dev dummy0 or >>action redirect dev dummy0 >> >>I just get errors on whatever is after action - or memory errors with 1.3.1. >> >>Using tc iproute2-ss050112 + patch for these tests. >> > > > So if i have understood you correctly, with this version of tc and > version of iproute2, you have no problems other than stats being messed > up? i.e action ipt .. action mirred .. looks/works fine? No, I haven't got anything to work with action mirred the stats was just using $TC filter add dev eth0 parent ffff: protocol ip prio 10 u32 \ match u32 0 0 flowid 1:1 \ action ipt -j MARK --set-mark 1 Andy. From baruch@ev-en.org Mon Mar 21 14:30:18 2005 Received: with ECARTIS (v1.0.0; list netdev); Mon, 21 Mar 2005 14:31:01 -0800 (PST) Received: from galon.ev-en.org (rrcs-24-123-59-149.central.biz.rr.com [24.123.59.149]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j2LMUIms013985 for ; Mon, 21 Mar 2005 14:30:18 -0800 Received: by galon.ev-en.org (Postfix, from userid 105) id 7A67711A607; Tue, 22 Mar 2005 00:30:11 +0200 (IST) Received: from [10.220.3.66] (hamilton.nuim.ie [149.157.192.252]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by galon.ev-en.org (Postfix) with ESMTP id C737311A5A3; Tue, 22 Mar 2005 00:30:05 +0200 (IST) Message-ID: <423F4AEB.9040100@ev-en.org> Date: Mon, 21 Mar 2005 22:30:03 +0000 From: Baruch Even User-Agent: Debian Thunderbird 1.0 (X11/20050116) X-Accept-Language: en-us, en MIME-Version: 1.0 To: "David S. Miller" Cc: John Heffner , ak@muc.de, shemminger@osdl.org, netdev@oss.sgi.com Subject: Re: [RFC] TCP congestion schedulers References: <421CF5E5.1060606@ev-en.org> <20050223135732.39e62c6c.davem@davemloft.net> <421D1E66.5090301@osdl.org> <421D30FA.1060900@ev-en.org> <20050225120814.5fa77b13@dxpl.pdx.osdl.net> <20050309210442.3e9786a6.davem@davemloft.net> <4230288F.1030202@ev-en.org> <20050310182629.1eab09ec.davem@davemloft.net> <20050311120054.4bbf675a@dxpl.pdx.osdl.net> <20050311201011.360c00da.davem@davemloft.net> <20050314151726.532af90d@dxpl.pdx.osdl.net> <20050321135154.0bbeae85.davem@davemloft.net> In-Reply-To: <20050321135154.0bbeae85.davem@davemloft.net> X-Enigmail-Version: 0.90.0.0 X-Enigmail-Supports: pgp-inline, pgp-mime Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV 0.83/778/Mon Mar 21 02:48:43 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 447 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: baruch@ev-en.org Precedence: bulk X-list: netdev Content-Length: 908 Lines: 24 David S. Miller wrote: > On Mon, 21 Mar 2005 16:25:56 -0500 (EST) > John Heffner wrote: > > >>Would you really expect a single extra indirect call per ack to have a >>significant performance impact? This is surprising to me. Where does the >>cost come from? Replacing instruction cache lines? > > Maybe not for ACK processing (that's very thick already) but > perhaps for a lighter fast path definitely so. According to my tests (wrapping tcp_ack with rdtsc's) it takes about 3000 clocks to do tcp_ack() even for fast path, slow path is not much slower in most cases and anyway most of the time is spent either handling SACKs or remove packets from the transmit queue (clean_rtx). I doubt if the extra calls by function are going to be that much of an issue. Now, if I knew how to improve performance of the clean_rtx case that would give a boost to ack performance. Baruch From akpm@osdl.org Mon Mar 21 14:36:57 2005 Received: with ECARTIS (v1.0.0; list netdev); Mon, 21 Mar 2005 14:37:03 -0800 (PST) Received: from smtp.osdl.org (fire.osdl.org [65.172.181.4]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j2LMateh014858 for ; Mon, 21 Mar 2005 14:36:56 -0800 Received: from shell0.pdx.osdl.net (fw.osdl.org [65.172.181.6]) by smtp.osdl.org (8.12.8/8.12.8) with ESMTP id j2LMaiqi028699 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO); Mon, 21 Mar 2005 14:36:44 -0800 Received: from akpm.pao.digeo.com (shell0.pdx.osdl.net [10.9.0.31]) by shell0.pdx.osdl.net (8.13.1/8.11.6) with SMTP id j2LMagDr014804; Mon, 21 Mar 2005 14:36:43 -0800 Date: Mon, 21 Mar 2005 14:36:48 -0800 From: Andrew Morton To: Richard Fuchs Cc: linux-kernel@vger.kernel.org, netdev@oss.sgi.com, Jeff Garzik Subject: Re: slab corruption in skb allocs Message-Id: <20050321143648.4608a912.akpm@osdl.org> In-Reply-To: <42283093.7040405@inode.info> References: <42283093.7040405@inode.info> X-Mailer: Sylpheed version 1.0.0 (GTK+ 1.2.10; i386-vine-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Received-SPF: pass (domain of akpm@osdl.org designates 65.172.181.6 as permitted sender) X-MIMEDefang-Filter: osdl$Revision: 1.105 $ X-Scanned-By: MIMEDefang 2.36 X-Virus-Scanned: ClamAV 0.83/778/Mon Mar 21 02:48:43 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 448 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: akpm@osdl.org Precedence: bulk X-list: netdev Content-Length: 662 Lines: 18 Richard Fuchs wrote: > > he memory allocation debugger gives me the following messages under a > vanilla 2.6.10 and 2.6.11 kernel when doing > > 1) hdparm -d0 on my hard disk > 2) tar c / > /dev/null > 3) sending lots of network traffic to the machine (e.g. close to 100 > mbit/s udp packets) > We ended up deciding that this was a bug in the e100 NAPI implementation. I have a not-very-official patch in -mm, at ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.12-rc1/2.6.12-rc1-mm1/broken-out/e100-napi-state-machine-fix.patch. Would you be able to test that? AFAIK there has been no official fix for this yet. From hadi@cyberus.ca Mon Mar 21 14:41:48 2005 Received: with ECARTIS (v1.0.0; list netdev); Mon, 21 Mar 2005 14:41:53 -0800 (PST) Received: from mx01.cybersurf.com (mx01.cybersurf.com [209.197.145.104]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j2LMfl2b015618 for ; Mon, 21 Mar 2005 14:41:48 -0800 Received: from mail.cyberus.ca ([209.197.145.21]) by mx01.cybersurf.com with esmtp (Exim 4.30) id 1DDVae-0000ka-5z for netdev@oss.sgi.com; Mon, 21 Mar 2005 15:41:40 -0700 Received: from [216.209.86.2] (helo=[10.0.0.9]) by mail.cyberus.ca with esmtp (Exim 4.20) id 1DDVad-0001sa-3c; Mon, 21 Mar 2005 17:41:39 -0500 Subject: Re: iptables breakage WAS(Re: dummy as IMQ replacement From: jamal Reply-To: hadi@cyberus.ca To: Andy Furniss Cc: Harald Welte , Patrick McHardy , Remus , netdev@oss.sgi.com, Nguyen Dinh Nam , Andre Tomt , syrius.ml@no-log.org, Damion de Soto In-Reply-To: <423F41AD.3010902@dsl.pipex.com> References: <1107123123.8021.80.camel@jzny.localdomain> <0fcf01c5077f$579e4b80$6e69690a@RIMAS> <1107174142.8021.121.camel@jzny.localdomain> <00c301c524b4$938cd240$6e69690a@RIMAS> <1110379135.1091.143.camel@jzny.localdomain> <1110416767.1111.76.camel@jzny.localdomain> <025501c52552$2dbf87c0$6e69690a@RIMAS> <1110453757.1108.87.camel@jzny.localdomain> <423B7BCB.10400@dsl.pipex.com> <1111410890.1092.195.camel@jzny.localdomain> <423F41AD.3010902@dsl.pipex.com> Content-Type: text/plain Organization: jamalopolous Message-Id: <1111444869.1072.51.camel@jzny.localdomain> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.2.2 Date: 21 Mar 2005 17:41:09 -0500 Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV 0.83/778/Mon Mar 21 02:48:43 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 449 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: hadi@cyberus.ca Precedence: bulk X-list: netdev Content-Length: 2070 Lines: 60 On Mon, 2005-03-21 at 16:50, Andy Furniss wrote: > jamal wrote: > > To test the theory copy iptables.h and iptables_common.h from > > iptables-1.3.1/include into iproute2/include with the latest iproute2 > > and recompile. Make sure m_ipt.c is recompiled - you may have to do a > > make clean in iproute2/tc/ > > I haven't done a new kernel with stats patched yet. Thanks for atching that btw - it was tricky; i have a strong feeling it was resolved by patch i sent. > Using iptables 1.3.1 > and iproute2-ss050314 with iptables headers I now get below instead of > memory error. > > ++ /usr/sbin/tc filter add dev eth0 parent ffff: protocol ip prio 10 u32 > match u32 0 0 flowid 1:1 action ipt -j MARK --set-mark 1 action mirred > egress redirect dev dummy0 > tablename: mangle hook: NF_IP_PRE_ROUTING > target: MARK set 0x1 index 0 > bad action type mirred > Usage: ... gact [RAND] [INDEX] > Where: ACTION := reclassify | drop | continue | pass RAND := random > RANDTYPE := netrand | determVAL : = value not > exceeding 10000INDEX := index value used > bad action parsing > parse_action: bad value (5:mirred)! > Illegal "action" > But what happens when you try without mirred? Lets debug that first. The fact that mirred fails is very strange - shouldnt; [You could try something like "action ok" instead of "action mirred .." and see if cascading of actions works ..]. Remus didnt seem to have this specific issue. > I will try with new kernel later tonight. > > > > > I should be able to validate all this stuff starting tommorow evening. > > Also I have a feeling if you make this change, things will not work for > > iptables <=1.2.9/10/11. Can you verify that? > > > > Yes it segfaults with iptables v1.2.11 So the changes that happened on iptables are neither forward nor backward compatible. I am begining to question the wisdom of putting the header files in iproute2. We may have to make a call and say we are going to work only on iptables >= 1.3.0 - would this make sense? cheers, jamal From akpm@osdl.org Mon Mar 21 14:56:27 2005 Received: with ECARTIS (v1.0.0; list netdev); Mon, 21 Mar 2005 14:56:37 -0800 (PST) Received: from smtp.osdl.org (fire.osdl.org [65.172.181.4]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j2LMuRGH016994 for ; Mon, 21 Mar 2005 14:56:27 -0800 Received: from shell0.pdx.osdl.net (fw.osdl.org [65.172.181.6]) by smtp.osdl.org (8.12.8/8.12.8) with ESMTP id j2LMuFqi030385 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO); Mon, 21 Mar 2005 14:56:16 -0800 Received: from akpm.pao.digeo.com (shell0.pdx.osdl.net [10.9.0.31]) by shell0.pdx.osdl.net (8.13.1/8.11.6) with SMTP id j2LMu93c016053; Mon, 21 Mar 2005 14:56:11 -0800 Date: Mon, 21 Mar 2005 14:56:16 -0800 From: Andrew Morton To: olof@austin.ibm.com (Olof Johansson) Cc: rl@hellgate.ch, netdev@oss.sgi.com, jgarzik@pobox.com Subject: Re: [PATCH] [VIA RHINE] older chips oops on shutdown Message-Id: <20050321145616.192afadc.akpm@osdl.org> In-Reply-To: <20050305184056.GA11056@austin.ibm.com> References: <20050305184056.GA11056@austin.ibm.com> X-Mailer: Sylpheed version 1.0.0 (GTK+ 1.2.10; i386-vine-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Received-SPF: pass (domain of akpm@osdl.org designates 65.172.181.6 as permitted sender) X-MIMEDefang-Filter: osdl$Revision: 1.105 $ X-Scanned-By: MIMEDefang 2.36 X-Virus-Scanned: ClamAV 0.83/778/Mon Mar 21 02:48:43 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 450 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: akpm@osdl.org Precedence: bulk X-list: netdev Content-Length: 3225 Lines: 87 olof@austin.ibm.com (Olof Johansson) wrote: > > Hi, > > Kernel 2.6.11, hardware is a MSI KT333-based board with an XP1800. > > I'm oopsing on shutdown on a machine that has a Via Rhine adapter in it: Roger, are you OK with merging this patch? > Unable to handle kernel paging request at virtual address e0803003 > printing eip: > c01f262c > *pde = 014dc067 > *pte = 00000000 > Oops: 0000 [#1] > Modules linked in: cpufreq_userspace cpufreq_powersave cpufreq_ondemand > CPU: 0 > EIP: 0060:[] Not tainted VLI > EFLAGS: 00010292 (2.6.11) > EIP is at ioread8+0x2c/0x40 > eax: e0803003 ebx: e0803003 ecx: c026b430 edx: e0803003 > esi: dff90260 edi: e0802f80 ebp: dd117e74 esp: dd117e74 > ds: 007b es: 007b ss: 0068 > Process reboot (pid: 5769, threadinfo=dd117000 task=dfafa080) > Stack: dd117e8c c026b490 dff90040 c151ccd4 c044a1a8 b7fdc078 dd117ea4 c0253ad9 > c151ccd4 00000042 fee1dead 00000001 dd117fbc c012461c c04d72a8 00000001 > 00000000 00010800 00000000 dd117ed8 c013b40b dffe7380 00030800 00000000 > Call Trace: > [] show_stack+0x7f/0xa0 > [] show_registers+0x15a/0x1c0 > [] die+0xce/0x150 > [] do_page_fault+0x356/0x692 > [] error_code+0x2b/0x30 > [] rhine_shutdown+0x60/0x140 > [] device_shutdown+0x89/0x8b > [] sys_reboot+0xac/0x200 > [] sysenter_past_esp+0x52/0x75 > Code: 3d ff ff 03 00 89 c2 89 e5 77 20 66 31 c0 3d 00 00 01 00 75 0c 81 e2 ff ff 00 00 ec 0f b6 c0 c9 c3 0f 0b 37 00 7b 65 3b c0 eb ea <0f> b6 00 eb ec eb 0d 90 90 90 90 90 90 90 90 90 90 90 90 90 55 > > > Seems like it is the ioread8 in: > > /* Hit power state D3 (sleep) */ > iowrite8(ioread8(ioaddr + StickyHW) | 0x03, ioaddr + StickyHW); > > that fails. StickyHW is 0x83. lspci says: > > 0000:00:07.0 Ethernet controller: VIA Technologies, Inc. VT86C100A [Rhine] (rev 06) > Flags: bus master, medium devsel, latency 32, IRQ 18 > I/O ports at ec00 [size=128] > Memory at dfffff80 (32-bit, non-prefetchable) [size=128] > > In other words, it's trying to read outside of the I/O range (0x80), > which matches the fauling address. > > I'm guessing my chip revision doesn't support WOL, it's a crappy noname > card. > > It does seem as if rhine_power_init checks quirks for rqWOL before > touching any registers. Should rhine_shutdown do the same? Proposed > patch below, which resolves the problem on my system. > > > -Olof > > --- > > Check to make sure WOL is supported before setting it up in rhine_shutdown. > > > Signed-off-by: Olof Johansson > > Index: linux-2.6.11/drivers/net/via-rhine.c > =================================================================== > --- linux-2.6.11.orig/drivers/net/via-rhine.c 2005-03-02 01:38:32.000000000 -0600 > +++ linux-2.6.11/drivers/net/via-rhine.c 2005-03-05 12:25:34.000000000 -0600 > @@ -1899,6 +1899,9 @@ > struct rhine_private *rp = netdev_priv(dev); > void __iomem *ioaddr = rp->base; > > + if (!(rp->quirks & rqWOL)) > + return; /* Nothing to do for non-WOL adapters */ > + > rhine_power_init(dev); > > /* Make sure we use pattern 0, 1 and not 4, 5 */ From wolfgang.walter@studentenwerk.mhn.de Mon Mar 21 15:53:01 2005 Received: with ECARTIS (v1.0.0; list netdev); Mon, 21 Mar 2005 15:53:06 -0800 (PST) Received: from mailout.stusta.mhn.de (emailhub.stusta.mhn.de [141.84.69.5]) by oss.sgi.com (8.13.0/8.13.0) with SMTP id j2LNr0S4020757 for ; Mon, 21 Mar 2005 15:53:01 -0800 Received: (qmail 23491 invoked from network); 21 Mar 2005 23:52:53 -0000 Received: from mailhub.stusta.mhn.de (HELO eumel.h3.stusta.mhn.de) (10.150.127.10) by mailhub.stusta.mhn.de with SMTP; 21 Mar 2005 23:52:53 -0000 From: Wolfgang Walter To: netdev@oss.sgi.com Subject: Re: [IPSEC] Too many SADs! Date: Tue, 22 Mar 2005 00:52:52 +0100 User-Agent: KMail/1.7.2 Organization: Studentenwerk =?utf-8?q?M=C3=BCnchen?= Cc: sfrost@snowman.net MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200503220052.52756.wolfgang.walter@studentenwerk.mhn.de> X-Virus-Scanned: ClamAV 0.83/778/Mon Mar 21 02:48:43 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 451 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: wolfgang.walter@studentenwerk.mhn.de Precedence: bulk X-list: netdev Content-Length: 303 Lines: 11 We had the same problem. Seems to be a limitation of the pfkey-implementation of linux. racoon and setkey both use the pfkey-interface. We switched to iproute2 and openswan which both use the netfilter-interface. Therefor they can handle thousands of SAD and SPD rules. Greetings, Wolfgang Walter From rick.jones2@hp.com Mon Mar 21 16:10:37 2005 Received: with ECARTIS (v1.0.0; list netdev); Mon, 21 Mar 2005 16:10:42 -0800 (PST) Received: from palrel13.hp.com (palrel13.hp.com [156.153.255.238]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j2M0AbJ2022192 for ; Mon, 21 Mar 2005 16:10:37 -0800 Received: from tardy.cup.hp.com (tardy.cup.hp.com [15.244.44.58]) by palrel13.hp.com (Postfix) with ESMTP id E02C11C00632 for ; Mon, 21 Mar 2005 16:10:36 -0800 (PST) Received: from hp.com (localhost [127.0.0.1]) by tardy.cup.hp.com (8.9.3 (PHNE_28810)/8.9.3 SMKit7.02) with ESMTP id QAA13693 for ; Mon, 21 Mar 2005 16:10:36 -0800 (PST) Message-ID: <423F627C.2060100@hp.com> Date: Mon, 21 Mar 2005 16:10:36 -0800 From: Rick Jones User-Agent: Mozilla/5.0 (X11; U; HP-UX 9000/785; en-US; rv:1.6) Gecko/20040304 X-Accept-Language: en-us, en MIME-Version: 1.0 To: netdev@oss.sgi.com Subject: Re: [RFC] TCP congestion schedulers References: <421CF5E5.1060606@ev-en.org> <20050223135732.39e62c6c.davem@davemloft.net> <421D1E66.5090301@osdl.org> <421D30FA.1060900@ev-en.org> <20050225120814.5fa77b13@dxpl.pdx.osdl.net> <20050309210442.3e9786a6.davem@davemloft.net> <4230288F.1030202@ev-en.org> <20050310182629.1eab09ec.davem@davemloft.net> <20050311120054.4bbf675a@dxpl.pdx.osdl.net> <20050311201011.360c00da.davem@davemloft.net> <20050314151726.532af90d@dxpl.pdx.osdl.net> In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV 0.83/778/Mon Mar 21 02:48:43 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 452 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: rick.jones2@hp.com Precedence: bulk X-list: netdev Content-Length: 6350 Lines: 132 John Heffner wrote: > On Sat, 19 Mar 2005, Andi Kleen wrote: > > >>Stephen Hemminger writes: >> >> >>>Since developers want to experiment with different congestion >>>control mechanisms, and the kernel is getting bloated with overlapping >>>data structure and code for multiple algorithms; here is a patch to >>>split out the Reno, Vegas, Westwood, BIC congestion control stuff >>>into an infrastructure similar to the I/O schedulers. >> >>[...] >> >>Did you do any benchmarks to check that wont slow it down? >> >>I would recommend to try it on a IA64 machine if possible. In the >>past we found that adding indirect function calls on IA64 to networking >>caused measurable slowdowns in macrobenchmarks. >>In that case it was LSM callbacks, but your code looks like it will >>add even more. > > > Is there a canonical benchmark? I would put-forth netperf - but then I'm of course biased. It is reasonably straightforward to run, is sophisticated enough to look for interesting things, and not so big as some benchmarketing benchmarks that require other software besides the stack (eg web servers and whatnot). If using netperf (not to be confused with Linux versions) versions < 2.4.0 then make sure it is compiled with the makefile edited to have -DUSE_PROC_STAT and _NOT_ have -DHISTOGRAM or -DINTERVALS. If using the rc1 of 2.4.0, just typing "configure" after unpacking the tar file should suffice under linux, but before compiling make sure config.h has a "USE_PROC_STAT" in it. If it is missing USE_PROC_STAT then add a --enable-cpuutil=procstat to the configure step. Be certain to request CPU utilization numbers with the -c/-C options. Probably best to request confidence intervals. I'd suggest a "128x32" TCP_STREAM test and a "1x1" TCP_RR test. So, something along the lines of: netperf -H -i 10,3 -I 99,5 -l 60 -t TCP_STREAM -- -s 128K -S 128K -m 32K to have netperf reqeust 128KB socket buffers, and pass 32KB in each call to send. Each iteration lasting 60 seconds, and running at least three and no more than 10 iterations to get to the point that it is 99% certain ("confident") that the reported mean for throughput and CPU util is within +/- 2.5% of the actual mean. You can make that -I 99,2 to be +/- 1% at the risk of having a harder time hitting the confidence intervals. If at first you do not hit the confidence intervals you can increase the values in -i up to 30 and/or increase the iteration run time with -l. For the TCP_RR test: netperf -H -I 10,3 -I 99,5 -l 60 -t TCP_RR which will be as above except running a TCP_RR test. The default in a TCP_RR test is to have a single-byte request and a single-byte response. If you grab 2.4.0rc1 and run on an MP system, it may be good for reproducability to use the -T option to pin netperf and/or netserver to specific CPUs. -T 0 will attempt to bind both netperf and netserver to CPU 0 -T 1,0 will attempt to bind netperf to CPU 1 and netserver to CPU 0 -T 0, will bind netperf to CPU 0 and leave netserver floating -T ,1 will bind netserver to CPU 1 and leave netperf floating I would suggest two sitations - netperf/netserver bound to the same CPU as that taking interrupts from the NIC, and one where it is not. How broad the "where it is not" case needs/wants to be depends on just how many degrees of "not the same CPU" as one hase on the system (thinking NUMA). netperf bits can be found at: ftp://ftp.cup.hp.com/dist/networking/benchmarks/netperf/ with the 2.4.0rc1 bits in the experimental/ subdirectory. There is a Debian package floating around somewhere but I cannot recall the revision of netperf on which it is based so probably best to grab source bits and compile them. Interrupt avoidance/coalescing may have a noticable effect on the single-stream netperf TCP_RR performance, capping it at a lower transaction per second rating no matter the increase in CPU util. So, it is very important to include the CPU util measurements. Similarly, if a system can already max-out a GbE link, just looking at Bits per second does not sufice. For situations where the CPU utilization measurement mechanism is questionable (I'm still not sure about the -DUSE_PROC_STAT stuff and interrupt time...any comments there most welcome) it may be preferred to run aggregate tests. Netperf2 has no explicit synchronization, but if one is content with "stopwatch" accuracy, aggregate performance along the lines of: for i in 1 2 ... N do netperf -t TCP_RR -H -i 30 -L 60 -P 0 -v 0 & done may suffice. The -P 0 stuff disables output of the test headers. The -v 0 will cause just the Single Figure of Merit (SFM) to be displayed - in this case the transaction per second rate. Here the -i 30 is to make each instance of netperf run 30 iterations. The idea being that at least 28 of them will be while the other N-1 netperfs are running. And, hitting the (default -I 99,5) confidence interval gives us some confidence that any skew is reasonably close to epsilon. The idea is to take N high enough to saturate the CPU(s) in the system and peak the aggregate transaction rate. Single-byte is used to avoid pegging the link on bits per second. Since this is "stopwatch" I tend to watch to make sure that they all start and end "close" to one another. (NB the combination of -i 30 and -l 60 means the test will run for an hour...alter at your discression) For aggregate tests it is generally best to have three systems - the System Under Test (SUT) and a pair or more of LG's - sometimes just using a pair of systems saturates before driving the SUT with two or more LGs would. > Would you really expect a single extra indirect call per ack to have a > significant performance impact? This is surprising to me. Where does the > cost come from? Replacing instruction cache lines? I don't have specific data on hand, but the way the selinux stuff (used?) to be implemented did indeed not run very well at all even when selinux was disabled (enabled was another story entirely...) Even if a single extra indirect call is nearly epsilon, the "thousand cuts" principle would apply. Enough of them and the claims about other OSes having faster networking may actually become true - if it isn't true already. But I may be drifting... rick jones From akpm@osdl.org Mon Mar 21 16:24:48 2005 Received: with ECARTIS (v1.0.0; list netdev); Mon, 21 Mar 2005 16:24:54 -0800 (PST) Received: from smtp.osdl.org (fire.osdl.org [65.172.181.4]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j2M0Olau026799 for ; Mon, 21 Mar 2005 16:24:47 -0800 Received: from shell0.pdx.osdl.net (fw.osdl.org [65.172.181.6]) by smtp.osdl.org (8.12.8/8.12.8) with ESMTP id j2M0Ocqi006155 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO); Mon, 21 Mar 2005 16:24:38 -0800 Received: from akpm.pao.digeo.com (shell0.pdx.osdl.net [10.9.0.31]) by shell0.pdx.osdl.net (8.13.1/8.11.6) with SMTP id j2M0ObpH021043; Mon, 21 Mar 2005 16:24:37 -0800 Date: Mon, 21 Mar 2005 16:24:44 -0800 From: Andrew Morton To: cel@citi.umich.edu Cc: netdev@oss.sgi.com, linux-kernel@vger.kernel.org Subject: Re: 2.6.11 oops in skb_drop_fraglist Message-Id: <20050321162444.31c6c68d.akpm@osdl.org> In-Reply-To: <423097D5.30605@citi.umich.edu> References: <423097D5.30605@citi.umich.edu> X-Mailer: Sylpheed version 1.0.0 (GTK+ 1.2.10; i386-vine-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Received-SPF: pass (domain of akpm@osdl.org designates 65.172.181.6 as permitted sender) X-MIMEDefang-Filter: osdl$Revision: 1.105 $ X-Scanned-By: MIMEDefang 2.36 X-Virus-Scanned: ClamAV 0.83/778/Mon Mar 21 02:48:43 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 453 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: akpm@osdl.org Precedence: bulk X-list: netdev Content-Length: 4135 Lines: 101 Chuck Lever wrote: > > testing NFS client workloads on a dual Pentium-III system running 2.6.11 > with some NFS patches. i hit this oops while doing simple-minded ftps > and tars. > > the system locks up once or twice a day under this workload. this is > the first time i had the console and captured the oops output. > Chuck, I didn't see any followup to this. Is it still happening in current kernels? Thanks. > Unable to handle kernel NULL pointer dereference at virtual address 00000001 > printing eip: > c02fc752 > *pde = 00000000 > Oops: 0000 [#1] > SMP > CPU: 0 > EIP: 0060:[] Not tainted VLI > EFLAGS: 00010202 (2.6.11-CITI_NFS4_ALL-1) > EIP is at skb_drop_fraglist+0x22/0x50 > eax: f6fe26e0 ebx: 00000001 ecx: f6fe26e0 edx: 00000001 > esi: f6f29240 edi: 00000004 ebp: f697ed24 esp: c04cadd8 > ds: 007b es: 007b ss: 0068 > Process swapper (pid: 0, threadinfo=c04ca000 task=c03efb60) > Stack: 00000001 c02fc7fa f6f29240 f697ecc0 c02fc838 00000000 c02fc8ba > ccbf2ab0 > 00000b50 c0326a16 f6f87740 f6f29240 f6f29240 c0321c4a 00000020 > f6f87778 > f6f87740 f697ecc0 f69d1560 00625a79 c04cae6c 00000000 00000012 > f697ecc0 > Call Trace: > [] skb_release_data+0x5a/0x90 > [] kfree_skbmem+0x8/0x20 > [] __kfree_skb+0x6a/0xf0 > [] tcp_transmit_skb+0x406/0x720 > [] tcp_clean_rtx_queue+0x17a/0x410 > [] tcp_ack+0xf6/0x580 > [] tcp_rcv_established+0x409/0x7f0 > [] apic_timer_interrupt+0x1c/0x24 > [] tcp_v4_do_rcv+0x110/0x120 > [] tcp_v4_rcv+0x6bf/0x940 > [] ip_local_deliver+0xc2/0x1f0 > [] ip_rcv+0x336/0x450 > [] alloc_skb+0x41/0xf0 > [] netif_receive_skb+0x136/0x1a0 > [] e1000_clean_rx_irq+0x15e/0x4a0 > [] __kfree_skb+0x6a/0xf0 > [] e1000_clean+0xba/0xf0 > [] net_rx_action+0x6f/0x100 > [] __do_softirq+0xb9/0xd0 > [] do_softirq+0x4a/0x60 > > c02fc730: 53 push %ebx > c02fc731: 8b 80 94 00 00 00 mov 0x94(%eax),%eax > c02fc737: 8b 58 0c mov 0xc(%eax),%ebx > c02fc73a: c7 40 0c 00 00 00 00 movl $0x0,0xc(%eax) > c02fc741: eb 0d jmp c02fc750 > > c02fc743: 90 nop > c02fc744: 90 nop > c02fc745: 90 nop > c02fc746: 90 nop > c02fc747: 90 nop > c02fc748: 90 nop > c02fc749: 90 nop > c02fc74a: 90 nop > c02fc74b: 90 nop > c02fc74c: 90 nop > c02fc74d: 90 nop > c02fc74e: 90 nop > c02fc74f: 90 nop > c02fc750: 89 da mov %ebx,%edx > c02fc752: 8b 1b mov (%ebx),%ebx > c02fc754: 8b 82 84 00 00 00 mov 0x84(%edx),%eax > c02fc75a: 48 dec %eax > c02fc75b: 75 13 jne c02fc770 > > c02fc75d: f0 83 44 24 00 00 lock addl $0x0,0x0(%esp,1) > c02fc763: 89 d0 mov %edx,%eax > c02fc765: e8 e6 00 00 00 call c02fc850 <__kfree_skb> > c02fc76a: 85 db test %ebx,%ebx > c02fc76c: 75 e2 jne c02fc750 > > c02fc76e: 5b pop %ebx > c02fc76f: c3 ret > c02fc770: f0 ff 8a 84 00 00 00 lock decl 0x84(%edx) > c02fc777: 0f 94 c0 sete %al > c02fc77a: 84 c0 test %al,%al > c02fc77c: 74 ec je c02fc76a > > c02fc77e: eb e3 jmp c02fc763 > > > > > From akpm@osdl.org Mon Mar 21 16:34:02 2005 Received: with ECARTIS (v1.0.0; list netdev); Mon, 21 Mar 2005 16:34:08 -0800 (PST) Received: from smtp.osdl.org (fire.osdl.org [65.172.181.4]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j2M0Y13Q027694 for ; Mon, 21 Mar 2005 16:34:02 -0800 Received: from shell0.pdx.osdl.net (fw.osdl.org [65.172.181.6]) by smtp.osdl.org (8.12.8/8.12.8) with ESMTP id j2M0Xqqi007259 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO); Mon, 21 Mar 2005 16:33:52 -0800 Received: from akpm.pao.digeo.com (shell0.pdx.osdl.net [10.9.0.31]) by shell0.pdx.osdl.net (8.13.1/8.11.6) with SMTP id j2M0Xp2F021550; Mon, 21 Mar 2005 16:33:51 -0800 Date: Mon, 21 Mar 2005 16:33:58 -0800 From: Andrew Morton To: felix-linuxkernel@fefe.de, linux-kernel@vger.kernel.org, netdev@oss.sgi.com Subject: Re: 2.6.11: USB broken on nforce4, ipv6 still broken, centrino speedstep even more broken than in 2.6.10 Message-Id: <20050321163358.1b4968a0.akpm@osdl.org> In-Reply-To: <20050311173308.7a076e8f.akpm@osdl.org> References: <20050311202122.GA13205@fefe.de> <20050311173308.7a076e8f.akpm@osdl.org> X-Mailer: Sylpheed version 1.0.0 (GTK+ 1.2.10; i386-vine-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Received-SPF: pass (domain of akpm@osdl.org designates 65.172.181.6 as permitted sender) X-MIMEDefang-Filter: osdl$Revision: 1.105 $ X-Scanned-By: MIMEDefang 2.36 X-Virus-Scanned: ClamAV 0.83/778/Mon Mar 21 02:48:43 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 454 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: akpm@osdl.org Precedence: bulk X-list: netdev Content-Length: 1031 Lines: 23 Andrew Morton wrote: > > > (Added netdev cc) > > Felix von Leitner wrote: > > > > Now about IPv6: npush and npoll are two applications I wrote. npush > > sends multicast announcements and opens a TCP socket. npoll receives > > the multicast announcement and connects to the source IP/port/scope_id > > of the announcement. If both are run on the same machine, npoll sees > > the link local address of eth0 as source IP, and the interface number of > > eth0 as scope_id. So far so good. Trying to connect() however hangs. > > Since this has been broken in different ways for as long as I can > > remember in Linux, and I keep complaining about it every half a year or > > so. Can't someone fix this once and for all? IPv4 checks whether we > > are connecting to our own address and reroutes through loopback, why > > can't IPv6? afaik, this problem is still open. If you have time, please provide additional info for the net developers. Maybe the source to npoll anbd npush? From andy.furniss@dsl.pipex.com Mon Mar 21 17:15:48 2005 Received: with ECARTIS (v1.0.0; list netdev); Mon, 21 Mar 2005 17:15:53 -0800 (PST) Received: from astro.systems.pipex.net (astro.systems.pipex.net [62.241.163.6]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j2M1FlC9030475 for ; Mon, 21 Mar 2005 17:15:47 -0800 Received: from [192.168.0.3] (81-178-205-19.dsl.pipex.com [81.178.205.19]) by astro.systems.pipex.net (Postfix) with ESMTP id 415DBE000047; Tue, 22 Mar 2005 01:15:23 +0000 (GMT) Message-ID: <423F71C2.8040802@dsl.pipex.com> Date: Tue, 22 Mar 2005 01:15:46 +0000 From: Andy Furniss User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.8b) Gecko/20050217 MIME-Version: 1.0 To: hadi@cyberus.ca CC: Harald Welte , Patrick McHardy , Remus , netdev@oss.sgi.com, Nguyen Dinh Nam , Andre Tomt , syrius.ml@no-log.org, Damion de Soto Subject: Re: iptables breakage WAS(Re: dummy as IMQ replacement References: <1107123123.8021.80.camel@jzny.localdomain> <0fcf01c5077f$579e4b80$6e69690a@RIMAS> <1107174142.8021.121.camel@jzny.localdomain> <00c301c524b4$938cd240$6e69690a@RIMAS> <1110379135.1091.143.camel@jzny.localdomain> <1110416767.1111.76.camel@jzny.localdomain> <025501c52552$2dbf87c0$6e69690a@RIMAS> <1110453757.1108.87.camel@jzny.localdomain> <423B7BCB.10400@dsl.pipex.com> <1111410890.1092.195.camel@jzny.localdomain> <423F41AD.3010902@dsl.pipex.com> <1111444869.1072.51.camel@jzny.localdomain> In-Reply-To: <1111444869.1072.51.camel@jzny.localdomain> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV 0.83/778/Mon Mar 21 02:48:43 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 455 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: andy.furniss@dsl.pipex.com Precedence: bulk X-list: netdev Content-Length: 2184 Lines: 63 jamal wrote: > On Mon, 2005-03-21 at 16:50, Andy Furniss wrote: > >>jamal wrote: > > But what happens when you try without mirred? Lets debug that first. > > The fact that mirred fails is very strange - shouldnt; > [You could try something like "action ok" instead of "action mirred .." > and see if cascading of actions works ..]. Remus didnt seem to have this > specific issue. Using 2.6.11.5 with new dummy.c and p_kstats. p_tcstats wouldn't apply to latest iproute2 so used patched iproute2-ss050112 + p_tcstats With iptables 1.3.1 and tc with it's iptables.h and iptables_common.h all I can do is - ++ /usr/sbin/tc filter add dev eth0 parent ffff: protocol ip prio 10 u32 match u32 0 0 flowid 1:1 action ok action ok 6 packets transmitted, 6 packets received, 0% packet loss round-trip min/avg/max/stddev = 0.337/0.566/1.630/0.476 ms [root@amd /home/andy/Qos]# tc -s filter ls dev eth0 parent ffff: filter protocol ip pref 10 u32 filter protocol ip pref 10 u32 fh 800: ht divisor 1 filter protocol ip pref 10 u32 fh 800::800 order 2048 key ht 800 bkt 0 flowid 1:1 (rule hit 6 success 6) match 00000000/00000000 at 0 (success 6 ) action order 1: gact action pass random type none pass val 0 index 3 ref 1 bind 1 installed 115 sec used 3 sec Action statistics: Sent 504 bytes 6 pkt (dropped 0, overlimits 0 requeues 0) rate 0bit 0pps backlog 0b 0p requeues 0 action order 2: gact action pass random type none pass val 0 index 4 ref 1 bind 1 installed 115 sec used 115 sec Action statistics: Sent 0 bytes 0 pkt (dropped 0, overlimits 0 requeues 0) rate 0bit 0pps backlog 0b 0p requeues 0 ipt MARK now fails though - ++ /usr/sbin/tc filter add dev eth0 parent ffff: protocol ip prio 10 u32 match u32 0 0 flowid 1:1 action ipt -j MARK --set-mark 1 action ok tablename: mangle hook: NF_IP_PRE_ROUTING target: MARK set 0x1 index 0 RTNETLINK answers: Invalid argument We have an error talking to the kernel If I build same tc with iptables 1.2.11 headers and use iptables 1.2.11 the above works. mirred still fails whatever I try. Andy. From herbert@gondor.apana.org.au Mon Mar 21 17:20:46 2005 Received: with ECARTIS (v1.0.0; list netdev); Mon, 21 Mar 2005 17:20:53 -0800 (PST) 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 j2M1KiIl031224 for ; Mon, 21 Mar 2005 17:20:45 -0800 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 1DDY45-0004tM-00; Tue, 22 Mar 2005 12:20:13 +1100 Received: from herbert by gondolin.me.apana.org.au with local (Exim 3.36 #1 (Debian)) id 1DDY3j-00047A-00; Tue, 22 Mar 2005 12:19:51 +1100 From: Herbert Xu To: akpm@osdl.org (Andrew Morton) Subject: Re: 2.6.11 oops in skb_drop_fraglist Cc: cel@citi.umich.edu, netdev@oss.sgi.com, linux-kernel@vger.kernel.org Organization: Core In-Reply-To: <20050321162444.31c6c68d.akpm@osdl.org> X-Newsgroups: apana.lists.os.linux.kernel,apana.lists.os.linux.netdev User-Agent: tin/1.7.4-20040225 ("Benbecula") (UNIX) (Linux/2.4.27-hx-1-686-smp (i686)) Message-Id: Date: Tue, 22 Mar 2005 12:19:51 +1100 X-Virus-Scanned: ClamAV 0.83/778/Mon Mar 21 02:48:43 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 456 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: herbert@gondor.apana.org.au Precedence: bulk X-list: netdev Content-Length: 759 Lines: 19 Andrew Morton wrote: > Chuck Lever wrote: >> >> testing NFS client workloads on a dual Pentium-III system running 2.6.11 >> with some NFS patches. i hit this oops while doing simple-minded ftps >> and tars. >> >> the system locks up once or twice a day under this workload. this is >> the first time i had the console and captured the oops output. > > Chuck, I didn't see any followup to this. Is it still happening in current > kernels? In the past the same Oops have been caused by memory problems... -- 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 okir@suse.de Mon Mar 21 17:42:01 2005 Received: with ECARTIS (v1.0.0; list netdev); Mon, 21 Mar 2005 17:42:07 -0800 (PST) Received: from mail.suse.de (mx1.suse.de [195.135.220.2]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j2M1g1JH032735 for ; Mon, 21 Mar 2005 17:42:01 -0800 Date: Tue, 22 Mar 2005 02:41:54 +0100 From: Olaf Kirch To: Rick Jones Cc: netdev@oss.sgi.com Subject: Re: [RFC] TCP congestion schedulers Message-ID: <20050322014154.GB4555@suse.de> References: <20050225120814.5fa77b13@dxpl.pdx.osdl.net> <20050309210442.3e9786a6.davem@davemloft.net> <4230288F.1030202@ev-en.org> <20050310182629.1eab09ec.davem@davemloft.net> <20050311120054.4bbf675a@dxpl.pdx.osdl.net> <20050311201011.360c00da.davem@davemloft.net> <20050314151726.532af90d@dxpl.pdx.osdl.net> <423F627C.2060100@hp.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <423F627C.2060100@hp.com> User-Agent: Mutt/1.5.6i X-Virus-Scanned: ClamAV 0.83/778/Mon Mar 21 02:48:43 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 457 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: okir@suse.de Precedence: bulk X-list: netdev Content-Length: 717 Lines: 16 On Mon, Mar 21, 2005 at 04:10:36PM -0800, Rick Jones wrote: > I would put-forth netperf - but then I'm of course biased. It is I think that was one of the benchmarks where the ia64 slowdown with LSM was diagnosed; netperf suffered some 10-15% degradation. And that was just with the capability module loaded, no fancy stuff going on. After we hacked up LSM to inline the capability checks in the default case, performance was back to normal. We didn't bother to pin-point where the loss actually occured, but my suspicion is the major offender was the per-skb check. Olaf -- Olaf Kirch | --- o --- Nous sommes du soleil we love when we play okir@suse.de | / | \ sol.dhoop.naytheet.ah kin.ir.samse.qurax From jdmason@us.ibm.com Mon Mar 21 17:59:51 2005 Received: with ECARTIS (v1.0.0; list netdev); Mon, 21 Mar 2005 17:59:55 -0800 (PST) Received: from e32.co.us.ibm.com (e32.co.us.ibm.com [32.97.110.130]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j2M1xiWb001660 for ; Mon, 21 Mar 2005 17:59:50 -0800 Received: from westrelay03.boulder.ibm.com (westrelay03.boulder.ibm.com [9.17.195.12]) by e32.co.us.ibm.com (8.12.10/8.12.9) with ESMTP id j2M1xc5j757770 for ; Mon, 21 Mar 2005 20:59:38 -0500 Received: from d03av01.boulder.ibm.com (d03av01.boulder.ibm.com [9.17.195.167]) by westrelay03.boulder.ibm.com (8.12.10/NCO/VER6.6) with ESMTP id j2M1xcc5135512 for ; Mon, 21 Mar 2005 18:59:38 -0700 Received: from d03av01.boulder.ibm.com (loopback [127.0.0.1]) by d03av01.boulder.ibm.com (8.12.11/8.12.11) with ESMTP id j2M1xbPL018380 for ; Mon, 21 Mar 2005 18:59:38 -0700 Received: from sig-9-65-34-173.mts.ibm.com (sig-9-65-34-173.mts.ibm.com [9.65.34.173]) by d03av01.boulder.ibm.com (8.12.11/8.12.11) with ESMTP id j2M1xbrd018368; Mon, 21 Mar 2005 18:59:37 -0700 From: Jon Mason Organization: IBM To: hadi@cyberus.ca Subject: Re: Network card driver problem (znb.o/tulip) Date: Mon, 21 Mar 2005 19:59:36 -0600 User-Agent: KMail/1.7.2 Cc: Kosta Todorovic , Francois Romieu , Ben Greear , jgarzik@pobox.com, tulip-users@lists.sourceforge.net, netdev@oss.sgi.com References: <1111346944.1094.91.camel@jzny.localdomain> In-Reply-To: <1111346944.1094.91.camel@jzny.localdomain> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200503211959.36089.jdmason@us.ibm.com> X-Virus-Scanned: ClamAV 0.83/778/Mon Mar 21 02:48:43 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 458 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: jdmason@us.ibm.com Precedence: bulk X-list: netdev Content-Length: 1187 Lines: 34 On Sunday 20 March 2005 01:29 pm, jamal wrote: > On Sun, 2005-03-20 at 14:18, Kosta Todorovic wrote: > > > I dont think mii-tool will tell you the truth with these cards. > > > Like i was saying earlier - they use SYM PHYs. > > > > Either way, no traffic moved across them when I tried. > > Probably the stats display is your best bet for debugging. > > > > Does it work on 32 bit machines? I am assuming when you say "64 bit" > > > you mean the architecture not PCI bus. > > > > Yes it does work on 32bit machines, but with the actual znb.o driver > > thats supplied by ZNXY. > > And yes i am refering to architecture and NOT pci bus. > > It works just fine for me with 32 bit machine with the standard tulip > driver(sorry dont have 64 bit - too poor); does it work for you? > i.e i dont use the Znyx driver at all. I always have mine running > 100Mbps FDX. My Linksys NC100 adapter works fine on my Athlon 64 system. So, it is probably an adapter/driver interaction issue, and not a 64bit one. Kosta, Can you confrim that the tulip driver works for you on a 32bit system? > If it works on 32 bit, then it maybe an issue with the tulip driver. > > cheers, > jamal Thanks, Jon From js@linuxtv.org Mon Mar 21 18:15:48 2005 Received: with ECARTIS (v1.0.0; list netdev); Mon, 21 Mar 2005 18:15:54 -0800 (PST) Received: from allen.werkleitz.de (ipx10786.ipxserver.de [80.190.251.108]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j2M2Fl5k002935 for ; Mon, 21 Mar 2005 18:15:47 -0800 Received: from pd9e737a9.dip.t-dialin.net ([217.231.55.169] helo=abc.local) by allen.werkleitz.de with esmtpsa (TLS-1.0:DHE_RSA_3DES_EDE_CBC_SHA:24) (Exim 4.44) id 1DDYvQ-0001Dm-86; Tue, 22 Mar 2005 03:15:31 +0100 Received: from js by abc.local with local (Exim 3.35 #1 (Debian)) id 1DDYyv-0004gS-00; Tue, 22 Mar 2005 03:18:57 +0100 Date: Tue, 22 Mar 2005 03:18:57 +0100 From: Johannes Stezenbach To: Andrew Morton Cc: felix-linuxkernel@fefe.de, linux-kernel@vger.kernel.org, netdev@oss.sgi.com Message-ID: <20050322021857.GA17972@linuxtv.org> Mail-Followup-To: Johannes Stezenbach , Andrew Morton , felix-linuxkernel@fefe.de, linux-kernel@vger.kernel.org, netdev@oss.sgi.com References: <20050311202122.GA13205@fefe.de> <20050311173308.7a076e8f.akpm@osdl.org> <20050321163358.1b4968a0.akpm@osdl.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20050321163358.1b4968a0.akpm@osdl.org> User-Agent: Mutt/1.5.6+20040907i X-SA-Exim-Connect-IP: 217.231.55.169 Subject: Re: 2.6.11: USB broken on nforce4, ipv6 still broken, centrino speedstep even more broken than in 2.6.10 X-SA-Exim-Version: 4.2 (built Tue, 25 Jan 2005 19:36:50 +0100) X-SA-Exim-Scanned: Yes (on allen.werkleitz.de) X-Virus-Scanned: ClamAV 0.83/778/Mon Mar 21 02:48:43 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 459 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: js@linuxtv.org Precedence: bulk X-list: netdev Content-Length: 1449 Lines: 33 Andrew Morton wrote: > Andrew Morton wrote: > > > > > > (Added netdev cc) > > > > Felix von Leitner wrote: > > > > > > Now about IPv6: npush and npoll are two applications I wrote. npush > > > sends multicast announcements and opens a TCP socket. npoll receives > > > the multicast announcement and connects to the source IP/port/scope_id > > > of the announcement. If both are run on the same machine, npoll sees > > > the link local address of eth0 as source IP, and the interface number of > > > eth0 as scope_id. So far so good. Trying to connect() however hangs. > > > Since this has been broken in different ways for as long as I can > > > remember in Linux, and I keep complaining about it every half a year or > > > so. Can't someone fix this once and for all? IPv4 checks whether we > > > are connecting to our own address and reroutes through loopback, why > > > can't IPv6? > > afaik, this problem is still open. If you have time, please provide > additional info for the net developers. Maybe the source to npoll anbd > npush? Grab the ncp package from http://www.fefe.de/ncp/, or more specifically ftp://ftp.fu-berlin.de/unix/network/ncp/ncp-1.2.3.tar.bz2. It's a very useful and handy tool for pushing around data within a LAN of a small workgroup, one guy does "npush foo" and yells at the intended recepient "do npoll". The first one to do it wins and gets foo ;-) Johannes From cel@citi.umich.edu Mon Mar 21 18:41:02 2005 Received: with ECARTIS (v1.0.0; list netdev); Mon, 21 Mar 2005 18:41:09 -0800 (PST) Received: from citi.umich.edu (citi.umich.edu [141.211.133.111]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j2M2f2MK004428 for ; Mon, 21 Mar 2005 18:41:02 -0800 Received: from [10.58.48.184] (nat-198-95-226-230.netapp.com [198.95.226.230]) by citi.umich.edu (Postfix) with ESMTP id AE9D21BB40; Mon, 21 Mar 2005 21:40:58 -0500 (EST) Message-ID: <423F85B9.3020406@citi.umich.edu> Date: Mon, 21 Mar 2005 21:40:57 -0500 From: Chuck Lever Reply-To: cel@citi.umich.edu Organization: Network Appliance, Inc. User-Agent: Mozilla Thunderbird 1.0 (Windows/20041206) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Andrew Morton Cc: netdev@oss.sgi.com, linux-kernel@vger.kernel.org Subject: Re: 2.6.11 oops in skb_drop_fraglist References: <423097D5.30605@citi.umich.edu> <20050321162444.31c6c68d.akpm@osdl.org> In-Reply-To: <20050321162444.31c6c68d.akpm@osdl.org> Content-Type: multipart/mixed; boundary="------------090503080202090607040601" X-Virus-Scanned: ClamAV 0.83/778/Mon Mar 21 02:48:43 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 460 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: cel@citi.umich.edu Precedence: bulk X-list: netdev Content-Length: 1866 Lines: 56 This is a multi-part message in MIME format. --------------090503080202090607040601 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Andrew Morton wrote: > Chuck Lever wrote: > >>testing NFS client workloads on a dual Pentium-III system running 2.6.11 >>with some NFS patches. i hit this oops while doing simple-minded ftps >>and tars. >> >>the system locks up once or twice a day under this workload. this is >>the first time i had the console and captured the oops output. >> > > > Chuck, I didn't see any followup to this. Is it still happening in current > kernels? i have not been able to reproduce it with the aforementioned NFS patches removed. i'm now convinced it was a bug in one of the NFS patches i had applied, even though none of them come near the fraglist stuff, but i haven't had a chance to nail it down. i had implemented a patch to cause the RPC client to reuse the port number when reconnecting to the server after the server drops the connection... this is a standard practice for other RPC implementations. i suspect it was that patch that was causing the trouble. thanks for the follow-up! --------------090503080202090607040601 Content-Type: text/x-vcard; charset=utf-8; name="cel.vcf" Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="cel.vcf" begin:vcard fn:Chuck Lever n:Lever;Charles org:Network Appliance, Incorporated;Linux NFS Client Development adr:535 West William Street, Suite 3100;;Center for Information Technology Integration;Ann Arbor;MI;48103-4943;USA email;internet:cel@citi.umich.edu title:Member of Technical Staff tel;work:+1 734 763-4415 tel;fax:+1 734 763 4434 tel;home:+1 734 668-1089 x-mozilla-html:FALSE url:http://www.monkey.org/~cel/ version:2.1 end:vcard --------------090503080202090607040601-- From davej@redhat.com Mon Mar 21 18:44:59 2005 Received: with ECARTIS (v1.0.0; list netdev); Mon, 21 Mar 2005 18:45:03 -0800 (PST) Received: from mx1.redhat.com (mx1.redhat.com [66.187.233.31]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j2M2iwYP005114 for ; Mon, 21 Mar 2005 18:44:59 -0800 Received: from int-mx1.corp.redhat.com (int-mx1.corp.redhat.com [172.16.52.254]) by mx1.redhat.com (8.12.11/8.12.11) with ESMTP id j2M2iwVq013943 for ; Mon, 21 Mar 2005 21:44:58 -0500 Received: from devserv.devel.redhat.com (devserv.devel.redhat.com [172.16.58.1]) by int-mx1.corp.redhat.com (8.11.6/8.11.6) with ESMTP id j2M2iwO20205 for ; Mon, 21 Mar 2005 21:44:58 -0500 Received: from devserv.devel.redhat.com (localhost.localdomain [127.0.0.1]) by devserv.devel.redhat.com (8.12.11/8.12.11) with ESMTP id j2M2iwl8012383 for ; Mon, 21 Mar 2005 21:44:58 -0500 Received: (from davej@localhost) by devserv.devel.redhat.com (8.12.11/8.12.11/Submit) id j2M2ivkk012381 for netdev@oss.sgi.com; Mon, 21 Mar 2005 21:44:57 -0500 X-Authentication-Warning: devserv.devel.redhat.com: davej set sender to davej@redhat.com using -f Date: Mon, 21 Mar 2005 21:44:57 -0500 From: Dave Jones To: netdev@oss.sgi.com Subject: swapped memset arguments. Message-ID: <20050322024457.GA11569@redhat.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.4.1i X-Virus-Scanned: ClamAV 0.83/778/Mon Mar 21 02:48:43 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 461 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: davej@redhat.com Precedence: bulk X-list: netdev Content-Length: 1027 Lines: 25 You wouldn't believe how many instances of this bug I've seen in the last few days in both userspace and kernelspace. Signed-off-by: Dave Jones --- bk-linus/net/ipv4/multipath_wrandom.c~ 2005-03-21 21:40:15.535597104 -0500 +++ bk-linus/net/ipv4/multipath_wrandom.c 2005-03-21 21:40:41.406664104 -0500 @@ -248,7 +248,7 @@ static void wrandom_set_nhinfo(__u32 net target_route->gw = nh->nh_gw; target_route->oif = nh->nh_oif; - memset(&target_route->rcu, sizeof(struct rcu_head), 0); + memset(&target_route->rcu, 0, sizeof(struct rcu_head)); INIT_LIST_HEAD(&target_route->dests); list_add_rcu(&target_route->list, &state[state_idx].head); @@ -271,7 +271,7 @@ static void wrandom_set_nhinfo(__u32 net target_dest->network = network; target_dest->netmask = netmask; target_dest->prefixlen = prefixlen; - memset(&target_dest->rcu, sizeof(struct rcu_head), 0); + memset(&target_dest->rcu, 0, sizeof(struct rcu_head)); list_add_rcu(&target_dest->list, &target_route->dests); } From hadi@cyberus.ca Mon Mar 21 19:31:20 2005 Received: with ECARTIS (v1.0.0; list netdev); Mon, 21 Mar 2005 19:31:24 -0800 (PST) Received: from mx04.cybersurf.com (mx04.cybersurf.com [209.197.145.108]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j2M3VJ4S007538 for ; Mon, 21 Mar 2005 19:31:20 -0800 Received: from mail.cyberus.ca ([209.197.145.21]) by mx04.cybersurf.com with esmtp (Exim 4.30) id 1DDa6v-0005Gu-0t for netdev@oss.sgi.com; Mon, 21 Mar 2005 22:31:17 -0500 Received: from [24.103.99.32] (helo=[10.0.0.9]) by mail.cyberus.ca with esmtp (Exim 4.20) id 1DDa6n-0005Vh-1h; Mon, 21 Mar 2005 22:31:09 -0500 Subject: Re: iptables breakage WAS(Re: dummy as IMQ replacement From: jamal Reply-To: hadi@cyberus.ca To: Andy Furniss Cc: Harald Welte , Patrick McHardy , Remus , netdev@oss.sgi.com, Nguyen Dinh Nam , Andre Tomt , syrius.ml@no-log.org, Damion de Soto In-Reply-To: <423F71C2.8040802@dsl.pipex.com> References: <1107123123.8021.80.camel@jzny.localdomain> <0fcf01c5077f$579e4b80$6e69690a@RIMAS> <1107174142.8021.121.camel@jzny.localdomain> <00c301c524b4$938cd240$6e69690a@RIMAS> <1110379135.1091.143.camel@jzny.localdomain> <1110416767.1111.76.camel@jzny.localdomain> <025501c52552$2dbf87c0$6e69690a@RIMAS> <1110453757.1108.87.camel@jzny.localdomain> <423B7BCB.10400@dsl.pipex.com> <1111410890.1092.195.camel@jzny.localdomain> <423F41AD.3010902@dsl.pipex.com> <1111444869.1072.51.camel@jzny.localdomain> <423F71C2.8040802@dsl.pipex.com> Content-Type: text/plain Organization: jamalopolous Message-Id: <1111462263.1109.6.camel@jzny.localdomain> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.2.2 Date: 21 Mar 2005 22:31:03 -0500 Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV 0.83/778/Mon Mar 21 02:48:43 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 462 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: hadi@cyberus.ca Precedence: bulk X-list: netdev Content-Length: 704 Lines: 26 Andy, Thanks for all your efforts. I will be back on my regular setup by tommorow evening and should be able to hopefuly test this. I am going to try: - latest iproute2 with 1.3.x ipt changes - i am just gonna jump to iptables 1.3.x - we are going to ignore 1.2.11 and below - kernel 2.6.11.5 patches with stats Issues seen so far - the following dont work: a) tc filter add dev eth0 parent ffff: protocol ip prio 10 u32 \ match u32 0 0 flowid 1:1 action ipt -j MARK --set-mark [Actually did you test this?] b) above with mirred as the next action fails in user space c) a) with a simple "action ok" is also rejected by the kernel with "Invalid argument" Did i miss anything else? cheers, jamal From akpm@osdl.org Mon Mar 21 19:40:49 2005 Received: with ECARTIS (v1.0.0; list netdev); Mon, 21 Mar 2005 19:40:54 -0800 (PST) Received: from smtp.osdl.org (fire.osdl.org [65.172.181.4]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j2M3en7g008362 for ; Mon, 21 Mar 2005 19:40:49 -0800 Received: from shell0.pdx.osdl.net (fw.osdl.org [65.172.181.6]) by smtp.osdl.org (8.12.8/8.12.8) with ESMTP id j2M3ecqi023561 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO); Mon, 21 Mar 2005 19:40:39 -0800 Received: from bix (shell0.pdx.osdl.net [10.9.0.31]) by shell0.pdx.osdl.net (8.13.1/8.11.6) with SMTP id j2M3ecJK029808; Mon, 21 Mar 2005 19:40:38 -0800 Date: Mon, 21 Mar 2005 19:40:22 -0800 From: Andrew Morton To: buakaw@buakaw.homelinux.net Cc: linux-kernel@vger.kernel.org, netdev@oss.sgi.com Subject: Re: dst cache overflow Message-Id: <20050321194022.491060c7.akpm@osdl.org> In-Reply-To: <1144.192.168.0.37.1111351868.squirrel@buakaw.homelinux.net> References: <1144.192.168.0.37.1111351868.squirrel@buakaw.homelinux.net> X-Mailer: Sylpheed version 0.9.7 (GTK+ 1.2.10; i386-redhat-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Received-SPF: pass (domain of akpm@osdl.org designates 65.172.181.6 as permitted sender) X-MIMEDefang-Filter: osdl$Revision: 1.105 $ X-Scanned-By: MIMEDefang 2.36 X-Virus-Scanned: ClamAV 0.83/778/Mon Mar 21 02:48:43 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 463 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: akpm@osdl.org Precedence: bulk X-list: netdev Content-Length: 613 Lines: 17 buakaw@buakaw.homelinux.net wrote: > > the system become very laggy. > i use kernel 2.6.10/2.6.11.3 on p4 2.8, msi915p, 3 x 3com905 boomerang. > and the cpu usage normally be about 12% and after something happens it > boost to 100% and it is used mostly by ksoftirqd/0, and a little bit by > migration/0 and event/0. and in syslog i found thies lines > > Mar 20 22:21:09 buakaw kernel: printk: 5543 messages suppressed. > Mar 20 22:21:09 buakaw kernel: dst cache overflow > > what can cause this? Could you please describe the workload? What is the computer doing at the time, and how is it set up? Thanks. From akpm@osdl.org Mon Mar 21 20:12:17 2005 Received: with ECARTIS (v1.0.0; list netdev); Mon, 21 Mar 2005 20:12:23 -0800 (PST) Received: from smtp.osdl.org (fire.osdl.org [65.172.181.4]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j2M4CHob010398 for ; Mon, 21 Mar 2005 20:12:17 -0800 Received: from shell0.pdx.osdl.net (fw.osdl.org [65.172.181.6]) by smtp.osdl.org (8.12.8/8.12.8) with ESMTP id j2M4C6qi026847 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO); Mon, 21 Mar 2005 20:12:07 -0800 Received: from bix (shell0.pdx.osdl.net [10.9.0.31]) by shell0.pdx.osdl.net (8.13.1/8.11.6) with SMTP id j2M4C670031387; Mon, 21 Mar 2005 20:12:06 -0800 Date: Mon, 21 Mar 2005 20:11:50 -0800 From: Andrew Morton To: netdev@oss.sgi.com Cc: o.cornu@gmail.com Subject: Fw: [Bugme-new] [Bug 4381] New: When i try to start a pppoe conn., crash at net/core/skbuff.c:91 Message-Id: <20050321201150.39ba3467.akpm@osdl.org> X-Mailer: Sylpheed version 0.9.7 (GTK+ 1.2.10; i386-redhat-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Received-SPF: pass (domain of akpm@osdl.org designates 65.172.181.6 as permitted sender) X-MIMEDefang-Filter: osdl$Revision: 1.105 $ X-Scanned-By: MIMEDefang 2.36 X-Virus-Scanned: ClamAV 0.83/778/Mon Mar 21 02:48:43 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 464 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: akpm@osdl.org Precedence: bulk X-list: netdev Content-Length: 3271 Lines: 76 Repeatable pppoe crash :( Begin forwarded message: Date: Mon, 21 Mar 2005 19:54:24 -0800 From: bugme-daemon@osdl.org To: bugme-new@lists.osdl.org Subject: [Bugme-new] [Bug 4381] New: When i try to start a pppoe conn., crash at net/core/skbuff.c:91 http://bugme.osdl.org/show_bug.cgi?id=4381 Summary: When i try to start a pppoe conn., crash at net/core/skbuff.c:91 Kernel Version: 2.6.11 (gentoo-dev-sources) Status: NEW Severity: blocking Owner: shemminger@osdl.org Submitter: o.cornu@gmail.com Distribution: Gentoo Hardware Environment: Intel P4 / Asus P4C800E Software Environment: Problem Description: When i try to start a pppoe conn., crash at net/core/skbuff.c:91 Might be related to Bug 4279, but with ppp_generic (not tun). Mar 21 21:27:59 Pai-mei adsl-connect: ADSL connection lost; attempting re-connection. Mar 21 21:28:04 Pai-mei pppd[6735]: pppd 2.4.2 started by root, uid 0 Mar 21 21:28:04 Pai-mei pppd[6735]: Using interface ppp0 Mar 21 21:28:04 Pai-mei pppd[6735]: Connect: ppp0 <--> /dev/pts/3 Mar 21 21:28:05 Pai-mei <6>skput:over: f89b2335:16 put:16 dev:------------[ cut here ]------------ Mar 21 21:28:05 Pai-mei kernel BUG at net/core/skbuff.c:91! Mar 21 21:28:05 Pai-mei invalid operand: 0000 [#5] Mar 21 21:28:05 Pai-mei PREEMPT SMP Mar 21 21:28:05 Pai-mei Modules linked in: usbcore slip ppp_synctty parport_pc plip parport ppp_deflate zlib_deflate dummy pppoe pppox ppp_async crc_ccitt bsd_comp ppp_generic slhc nvidia_agp agpgart sr_mod Mar 21 21:28:05 Pai-mei CPU: 0 Mar 21 21:28:05 Pai-mei EIP: 0060:[] Not tainted VLI Mar 21 21:28:05 Pai-mei EFLAGS: 00210282 (2.6.11-gentoo-r4) Mar 21 21:28:05 Pai-mei EIP is at skb_over_panic+0x3b/0x50 Mar 21 21:28:05 Pai-mei eax: 0000002c ebx: f6a43e80 ecx: 000008fc edx: 00000001 Mar 21 21:28:05 Pai-mei esi: f7f59680 edi: f6f36a80 ebp: 00000010 esp: f6a07f3c Mar 21 21:28:05 Pai-mei ds: 007b es: 007b ss: 0068 Mar 21 21:28:05 Pai-mei Process pppd (pid: 6735, threadinfo=f6a06000 task=f6ff8a80) Mar 21 21:28:05 Pai-mei Stack: c03ee4a0 f89b2335 00000010 00000010 c03d008c f89b2341 f6a43e80 00000010 Mar 21 21:28:05 Pai-mei f89b2335 fffffff2 00000010 00000000 f6fd0e80 08087f22 c0160909 f6fd0e80 Mar 21 21:28:05 Pai-mei 08087f22 00000010 f6a07fac f6fd0e80 fffffff7 00000007 f6a06000 c0160a91 Mar 21 21:28:05 Pai-mei Call Trace: Mar 21 21:28:05 Pai-mei [] ppp_write+0x115/0x140 [ppp_generic] Mar 21 21:28:05 Pai-mei [] ppp_write+0x121/0x140 [ppp_generic] Mar 21 21:28:05 Pai-mei [] ppp_write+0x115/0x140 [ppp_generic] Mar 21 21:28:05 Pai-mei [] vfs_write+0xe9/0x1a0 Mar 21 21:28:05 Pai-mei [] sys_write+0x51/0x80 Mar 21 21:28:05 Pai-mei [] syscall_call+0x7/0xb Mar 21 21:28:05 Pai-mei Code: c0 0f 44 c2 89 44 24 10 8b 44 24 1c 89 44 24 0c 8b 41 60 c7 04 24 a0 e4 3e c0 89 44 24 08 8b 44 24 20 89 44 24 04 e8 55 34 e0 ff <0f> 0b 5b 00 0b b9 3e c0 83 c4 14 c3 89 f6 8d bc 27 00 00 00 00 Mar 21 21:28:05 Pai-mei adsl-connect: ADSL connection lost; attempting re-connection. Steps to reproduce: ------- You are receiving this mail because: ------- You are on the CC list for the bug, or are watching someone who is. From kostodo@gmail.com Mon Mar 21 23:18:12 2005 Received: with ECARTIS (v1.0.0; list netdev); Mon, 21 Mar 2005 23:18:22 -0800 (PST) Received: from rproxy.gmail.com (rproxy.gmail.com [64.233.170.199]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j2M7IBaQ023618 for ; Mon, 21 Mar 2005 23:18:12 -0800 Received: by rproxy.gmail.com with SMTP id j1so1093140rnf for ; Mon, 21 Mar 2005 23:18:11 -0800 (PST) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:reply-to:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:references; b=cfPUSDvORGrLQXz3FXny+yzQH65JZ2iTCqm4F1TrWJSWAIugVNtlqFyMuuKJR7mablgxM5V1AYMjUjv7NT4na97/gUlo+UcqmskHswqOngRLDqHhPrpTJRXtxuZHPvvjMLFalsQr6qC/amORsTgkkUbzpkuXAOthJwDKmbuUYAw= Received: by 10.38.65.14 with SMTP id n14mr6084506rna; Mon, 21 Mar 2005 23:18:11 -0800 (PST) Received: by 10.38.208.49 with HTTP; Mon, 21 Mar 2005 23:18:11 -0800 (PST) Message-ID: Date: Tue, 22 Mar 2005 11:18:11 +0400 From: Kosta Todorovic Reply-To: Kosta Todorovic To: Jon Mason Subject: Re: Network card driver problem (znb.o/tulip) Cc: hadi@cyberus.ca, Francois Romieu , Ben Greear , jgarzik@pobox.com, tulip-users@lists.sourceforge.net, netdev@oss.sgi.com In-Reply-To: <200503211959.36089.jdmason@us.ibm.com> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit References: <1111346944.1094.91.camel@jzny.localdomain> <200503211959.36089.jdmason@us.ibm.com> X-Virus-Scanned: ClamAV 0.83/778/Mon Mar 21 02:48:43 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 465 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: kostodo@gmail.com Precedence: bulk X-list: netdev Content-Length: 589 Lines: 14 > Kosta, Can you confrim that the tulip driver works for you on a 32bit system? Just tried on 32bit mode and exactly the SAME thing happens with the tulip driver as in 64bit mode. Its very strange thought, for a few seconds there was traffic passing through the card (icmp echo reply). The it stopped and would answer anymore. I tried restarting the interface a few times but no joy. When i checked with 'mii-tool -w' i keep showing the NIC trying to autonegotiate and saying it Failed. Also i can see the card switching back and forth from 10mbps to 100mbps. I'm slightly confused ;) From rl@hellgate.ch Mon Mar 21 23:32:06 2005 Received: with ECARTIS (v1.0.0; list netdev); Mon, 21 Mar 2005 23:32:16 -0800 (PST) Received: from mail11.bluewin.ch (mail11.bluewin.ch [195.186.18.61]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j2M7W6LI024754 for ; Mon, 21 Mar 2005 23:32:06 -0800 Received: from k3.hellgate.ch (83.77.52.69) by mail11.bluewin.ch (Bluewin 7.0.043) id 423AED5F00026610; Tue, 22 Mar 2005 07:31:15 +0000 Received: by k3.hellgate.ch (Postfix, from userid 1000) id 68BD85E5ABD; Tue, 22 Mar 2005 08:30:39 +0100 (CET) Date: Tue, 22 Mar 2005 08:30:39 +0100 From: Roger Luethi To: Andrew Morton Cc: Olof Johansson , netdev@oss.sgi.com, jgarzik@pobox.com Subject: Re: [PATCH] [VIA RHINE] older chips oops on shutdown Message-ID: <20050322073039.GA15540@k3.hellgate.ch> References: <20050305184056.GA11056@austin.ibm.com> <20050321145616.192afadc.akpm@osdl.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20050321145616.192afadc.akpm@osdl.org> X-Operating-System: Linux 2.6.11 on i686 X-GPG-Fingerprint: 92 F4 DC 20 57 46 7B 95 24 4E 9E E7 5A 54 DC 1B X-GPG: 1024/80E744BD wwwkeys.ch.pgp.net User-Agent: Mutt/1.5.8i X-Virus-Scanned: ClamAV 0.83/778/Mon Mar 21 02:48:43 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 466 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: rl@hellgate.ch Precedence: bulk X-list: netdev Content-Length: 287 Lines: 8 On Mon, 21 Mar 2005 14:56:16 -0800, Andrew Morton wrote: > Roger, are you OK with merging this patch? Uhm, it's been merged in mainline more than two weeks ago, no? Denying access to non-existant registers is the right thing to do (an equivalent is already in rhine_power_init). Roger From ak@muc.de Mon Mar 21 23:41:24 2005 Received: with ECARTIS (v1.0.0; list netdev); Mon, 21 Mar 2005 23:41:32 -0800 (PST) Received: from colin2.muc.de (qmailr@colin2.muc.de [193.149.48.15]) by oss.sgi.com (8.13.0/8.13.0) with SMTP id j2M7fNPI025768 for ; Mon, 21 Mar 2005 23:41:24 -0800 Received: (qmail 65498 invoked by uid 3709); 22 Mar 2005 07:41:22 -0000 Date: 22 Mar 2005 08:41:22 +0100 Date: Tue, 22 Mar 2005 08:41:22 +0100 From: Andi Kleen To: John Heffner Cc: Stephen Hemminger , baruch@ev-en.org, netdev@oss.sgi.com Subject: Re: [RFC] TCP congestion schedulers Message-ID: <20050322074122.GA64595@muc.de> References: <421D30FA.1060900@ev-en.org> <20050225120814.5fa77b13@dxpl.pdx.osdl.net> <20050309210442.3e9786a6.davem@davemloft.net> <4230288F.1030202@ev-en.org> <20050310182629.1eab09ec.davem@davemloft.net> <20050311120054.4bbf675a@dxpl.pdx.osdl.net> <20050311201011.360c00da.davem@davemloft.net> <20050314151726.532af90d@dxpl.pdx.osdl.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.1i X-Virus-Scanned: ClamAV 0.83/778/Mon Mar 21 02:48:43 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 467 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: ak@muc.de Precedence: bulk X-list: netdev Content-Length: 1561 Lines: 40 On Mon, Mar 21, 2005 at 04:25:56PM -0500, John Heffner wrote: > On Sat, 19 Mar 2005, Andi Kleen wrote: > > > Stephen Hemminger writes: > > > > > Since developers want to experiment with different congestion > > > control mechanisms, and the kernel is getting bloated with overlapping > > > data structure and code for multiple algorithms; here is a patch to > > > split out the Reno, Vegas, Westwood, BIC congestion control stuff > > > into an infrastructure similar to the I/O schedulers. > > > > [...] > > > > Did you do any benchmarks to check that wont slow it down? > > > > I would recommend to try it on a IA64 machine if possible. In the > > past we found that adding indirect function calls on IA64 to networking > > caused measurable slowdowns in macrobenchmarks. > > In that case it was LSM callbacks, but your code looks like it will > > add even more. > > Is there a canonical benchmark? For the LSM case we saw the problem with running netperf over loopback. It added one or two hooks per packet, but it already made a noticeable difference on IA64 boxes. On other systems it is unnoticeable. > Would you really expect a single extra indirect call per ack to have a > significant performance impact? This is surprising to me. Where does the > cost come from? Replacing instruction cache lines? I was never quite clear. Some instruction stalls in the CPUs. One not very good theory was that McKinley really likes to have its jump registers loaded early for indirect calls, and gcc doesn't even attempt this. -Andi From bunk@stusta.de Tue Mar 22 04:22:22 2005 Received: with ECARTIS (v1.0.0; list netdev); Tue, 22 Mar 2005 04:22:35 -0800 (PST) Received: from mailout.stusta.mhn.de (emailhub.stusta.mhn.de [141.84.69.5]) by oss.sgi.com (8.13.0/8.13.0) with SMTP id j2MCMKjZ020461 for ; Tue, 22 Mar 2005 04:22:21 -0800 Received: (qmail 7588 invoked from network); 22 Mar 2005 12:22:15 -0000 Received: from r063144.stusta.swh.mhn.de (10.150.63.144) by mailout.stusta.mhn.de with SMTP; 22 Mar 2005 12:22:15 -0000 Received: by r063144.stusta.swh.mhn.de (Postfix, from userid 1000) id A44B9BBA5F; Tue, 22 Mar 2005 13:22:13 +0100 (CET) Date: Tue, 22 Mar 2005 13:22:13 +0100 From: Adrian Bunk To: Einar Lueck Cc: linux-kernel@vger.kernel.org, netdev@oss.sgi.com Subject: [2.6 patch] fix net/ipv4/route.c with gcc 3.4 Message-ID: <20050322122213.GH3982@stusta.de> References: <20050321025159.1cabd62e.akpm@osdl.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20050321025159.1cabd62e.akpm@osdl.org> User-Agent: Mutt/1.5.6+20040907i X-Virus-Scanned: ClamAV 0.83/778/Mon Mar 21 02:48:43 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 469 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: bunk@stusta.de Precedence: bulk X-list: netdev Content-Length: 1864 Lines: 63 The following compile error comes from Linus' tree with CONFIG_IP_ROUTE_MULTIPATH_CACHED=y: <-- snip --> ... CC net/ipv4/route.o net/ipv4/route.c: In function `rt_remove_balanced_route': net/ipv4/route.c:151: sorry, unimplemented: inlining failed in call to 'compare_keys': function body not available net/ipv4/route.c:540: sorry, unimplemented: called from here make[2]: *** [net/ipv4/route.o] Error 1 <-- snip --> This patch fixes this compile error by moving compare_keys up. Signed-off-by: Adrian Bunk --- net/ipv4/route.c | 15 +++++++-------- 1 files changed, 7 insertions(+), 8 deletions(-) --- linux-2.6.12-rc1-mm1-full/net/ipv4/route.c.old 2005-03-22 13:10:35.000000000 +0100 +++ linux-2.6.12-rc1-mm1-full/net/ipv4/route.c 2005-03-22 13:12:29.000000000 +0100 @@ -148,7 +148,6 @@ static void ipv4_link_failure(struct sk_buff *skb); static void ip_rt_update_pmtu(struct dst_entry *dst, u32 mtu); static int rt_garbage_collect(void); -static inline int compare_keys(struct flowi *fl1, struct flowi *fl2); static struct dst_ops ipv4_dst_ops = { @@ -450,6 +449,13 @@ #endif /* CONFIG_PROC_FS */ +static inline int compare_keys(struct flowi *fl1, struct flowi *fl2) +{ + return memcmp(&fl1->nl_u.ip4_u, &fl2->nl_u.ip4_u, sizeof(fl1->nl_u.ip4_u)) == 0 && + fl1->oif == fl2->oif && + fl1->iif == fl2->iif; +} + static __inline__ void rt_free(struct rtable *rt) { multipath_remove(rt); @@ -858,13 +864,6 @@ out: return 0; } -static inline int compare_keys(struct flowi *fl1, struct flowi *fl2) -{ - return memcmp(&fl1->nl_u.ip4_u, &fl2->nl_u.ip4_u, sizeof(fl1->nl_u.ip4_u)) == 0 && - fl1->oif == fl2->oif && - fl1->iif == fl2->iif; -} - static int rt_intern_hash(unsigned hash, struct rtable *rt, struct rtable **rp) { struct rtable *rth, **rthp; From mkomu@twilight.cs.hut.fi Tue Mar 22 06:08:43 2005 Received: with ECARTIS (v1.0.0; list netdev); Tue, 22 Mar 2005 06:08:51 -0800 (PST) Received: from twilight.cs.hut.fi (twilight.cs.hut.fi [130.233.40.5]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j2ME8gHk029587 for ; Tue, 22 Mar 2005 06:08:43 -0800 Received: by twilight.cs.hut.fi (Postfix, from userid 60001) id B583A2D19; Tue, 22 Mar 2005 16:08:36 +0200 (EET) Received: from kekkonen.cs.hut.fi (kekkonen.cs.hut.fi [130.233.41.50]) by twilight.cs.hut.fi (Postfix) with ESMTP id 6960B2D19; Tue, 22 Mar 2005 16:08:34 +0200 (EET) Received: (from mkomu@localhost) by kekkonen.cs.hut.fi (8.11.7p1+Sun/8.10.2) id j2ME8V622086; Tue, 22 Mar 2005 16:08:31 +0200 (EET) Date: Tue, 22 Mar 2005 16:08:31 +0200 (EET) From: Miika Komu X-X-Sender: mkomu@kekkonen.cs.hut.fi To: "David S. Miller" Cc: yoshfuji@linux-ipv6.org, Andrei Gurtov , netdev@oss.sgi.com, infrahip@hiit.fi Subject: Re: [Infrahip] [PATCH] Host Identity Protocol In-Reply-To: <20050320200356.5f8fa583.davem@davemloft.net> Message-ID: References: <42369919.9010203@cs.helsinki.fi> <20050321.024241.67451836.yoshfuji@linux-ipv6.org> <20050320200356.5f8fa583.davem@davemloft.net> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=ISO-8859-1 X-Virus-Scanned: ClamAV 0.83/778/Mon Mar 21 02:48:43 2005 on oss.sgi.com X-Virus-Status: Clean Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from QUOTED-PRINTABLE to 8bit by oss.sgi.com id j2ME8gHk029587 X-archive-position: 470 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: miika@iki.fi Precedence: bulk X-list: netdev Content-Length: 2101 Lines: 44 On Sun, 20 Mar 2005, David S. Miller wrote: > On Mon, 21 Mar 2005 02:42:41 +0900 (JST) > YOSHIFUJI Hideaki / µÈÆ£±ÑÌÀ wrote: > > > However, all signaling should be handled in userspace as we (will) do > > for MIP6. > > Yes, I've been telling them similarly in a private > email discussion. I'm very glad someone else says > this too, so I don't appear as the only person who > feels this way :-) Thank you, David and Yoshifugi, for your feedback. Please accept my apologies for my late response. I am having difficulties in digesting the counterarguments against the kernel based approach because of the lack of detailed reasoning and ambiguities. Yes, MIP6 and IKE signalling is handled in the userspace, but the same is not true for SCTP (lksctp). At the same time, Linux is a monolithic kernel instead of microkernel architecture. Finally, good engineering practise is to put everything in the userspace, unless there is good reason for putting it in to the kernelspace. We don't currently have concrete measurements (comparing userspace and kernelspace approaches) to justify our kernel oriented approach, so we will have to get back to you later with some figures. If the results show that an userspace implementation is superior to a kernel based approach in terms of security or performance, we may have rewrite the code to the userspace. In the mean time, do you happen to know any good references where any userspace network protocol implementation has been compared and measured against a kernelspace implementation? It would be a good starting point for us. I would like to mention that lksctp was implemented in the 2.6 kernel because of better performance and tighter integration to the socket API. We are dealing with similar issues with HIPL but seems like we need to justify the reasons by analyzing and measuring. In addition, security issues (DoS protection, user supplied public keys, etc) are taken pretty seriously in HIP and may benefit from a kernel oriented approach. -- Miika Komu miika@iki.fi http://www.iki.fi/miika/ From hadi@cyberus.ca Tue Mar 22 06:57:03 2005 Received: with ECARTIS (v1.0.0; list netdev); Tue, 22 Mar 2005 06:57:16 -0800 (PST) Received: from mx04.cybersurf.com (mx04.cybersurf.com [209.197.145.108]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j2MEv25I000458 for ; Tue, 22 Mar 2005 06:57:03 -0800 Received: from mail.cyberus.ca ([209.197.145.21]) by mx04.cybersurf.com with esmtp (Exim 4.30) id 1DDkoV-00047G-Mu for netdev@oss.sgi.com; Tue, 22 Mar 2005 09:56:59 -0500 Received: from [216.209.86.2] (helo=[10.0.0.9]) by mail.cyberus.ca with esmtp (Exim 4.20) id 1DDkoR-00055G-Gk; Tue, 22 Mar 2005 09:56:55 -0500 Subject: Re: Network card driver problem (znb.o/tulip) From: jamal Reply-To: hadi@cyberus.ca To: Kosta Todorovic Cc: Jon Mason , Francois Romieu , Ben Greear , jgarzik@pobox.com, tulip-users@lists.sourceforge.net, netdev@oss.sgi.com In-Reply-To: References: <1111346944.1094.91.camel@jzny.localdomain> <200503211959.36089.jdmason@us.ibm.com> Content-Type: text/plain Organization: jamalopolous Message-Id: <1111503412.1081.49.camel@jzny.localdomain> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.2.2 Date: 22 Mar 2005 09:56:52 -0500 Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV 0.83/778/Mon Mar 21 02:48:43 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 471 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: hadi@cyberus.ca Precedence: bulk X-list: netdev Content-Length: 1215 Lines: 37 Kosta, As i told you earlier: You can NOT use mii-tool. This board uses SYM PHY. Try finding out what the other side reports instead in terms of speed and duplexity. When you say switching back/forth between 10/100 - how can you tell that? I think this may be your problem. Dont try to force speeds; just let it AN. Find something on the other side that is capable of reporting correctly like e1000 and test. All i can tell you is this works on 32 bit machines - I cant validate 64 bit machines because i dont have one. cheers, jamal On Tue, 2005-03-22 at 02:18, Kosta Todorovic wrote: > > Kosta, Can you confrim that the tulip driver works for you on a 32bit system? > > Just tried on 32bit mode and exactly the SAME thing happens with the > tulip driver as in 64bit mode. > > Its very strange thought, for a few seconds there was traffic passing > through the card (icmp echo reply). The it stopped and would answer > anymore. I tried restarting the interface a few times but no joy. > > When i checked with 'mii-tool -w' i keep showing the NIC trying to > autonegotiate and saying it Failed. Also i can see the card switching > back and forth from 10mbps to 100mbps. > > I'm slightly confused ;) > From js@linuxtv.org Tue Mar 22 08:18:53 2005 Received: with ECARTIS (v1.0.0; list netdev); Tue, 22 Mar 2005 08:19:01 -0800 (PST) Received: from allen.werkleitz.de (ipx10786.ipxserver.de [80.190.251.108]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j2MGIpiP005180 for ; Tue, 22 Mar 2005 08:18:53 -0800 Received: from pd9e72d32.dip.t-dialin.net ([217.231.45.50] helo=abc.local) by allen.werkleitz.de with esmtpsa (TLS-1.0:DHE_RSA_3DES_EDE_CBC_SHA:24) (Exim 4.44) id 1DDm5H-0003aA-1G; Tue, 22 Mar 2005 17:18:39 +0100 Received: from js by abc.local with local (Exim 3.35 #1 (Debian)) id 1DDm8p-0005jl-00; Tue, 22 Mar 2005 17:22:03 +0100 Date: Tue, 22 Mar 2005 17:22:03 +0100 From: Johannes Stezenbach To: Andrew Morton , felix-linuxkernel@fefe.de, linux-kernel@vger.kernel.org, netdev@oss.sgi.com Message-ID: <20050322162203.GB19668@linuxtv.org> Mail-Followup-To: Johannes Stezenbach , Andrew Morton , felix-linuxkernel@fefe.de, linux-kernel@vger.kernel.org, netdev@oss.sgi.com References: <20050311202122.GA13205@fefe.de> <20050311173308.7a076e8f.akpm@osdl.org> <20050321163358.1b4968a0.akpm@osdl.org> <20050322021857.GA17972@linuxtv.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20050322021857.GA17972@linuxtv.org> User-Agent: Mutt/1.5.6+20040907i X-SA-Exim-Connect-IP: 217.231.45.50 Subject: Re: 2.6.11: USB broken on nforce4, ipv6 still broken, centrino speedstep even more broken than in 2.6.10 X-SA-Exim-Version: 4.2 (built Tue, 25 Jan 2005 19:36:50 +0100) X-SA-Exim-Scanned: Yes (on allen.werkleitz.de) X-Virus-Scanned: ClamAV 0.83/778/Mon Mar 21 02:48:43 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 472 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: js@linuxtv.org Precedence: bulk X-list: netdev Content-Length: 774 Lines: 17 Johannes Stezenbach wrote: > Grab the ncp package from http://www.fefe.de/ncp/, or more specifically > ftp://ftp.fu-berlin.de/unix/network/ncp/ncp-1.2.3.tar.bz2. > > It's a very useful and handy tool for pushing around data within > a LAN of a small workgroup, one guy does "npush foo" and yells > at the intended recepient "do npoll". The first one to do > it wins and gets foo ;-) In case that description sounded too silly: The essential feature of ncp is that it requires no configuration or installation of a server daemon, and you don't even need to worry about host names or the IP address of the source or destination machine. Just hook two computers to the same network and you're ready to npush/npoll. Similar to netcat + tar, but way more convenient. Johannes From sfrost@ns.snowman.net Tue Mar 22 08:59:05 2005 Received: with ECARTIS (v1.0.0; list netdev); Tue, 22 Mar 2005 08:59:13 -0800 (PST) Received: from relay.snowman.net (relay.snowman.net [66.92.160.56]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j2MGx4pu011424 for ; Tue, 22 Mar 2005 08:59:05 -0800 Received: from ns.snowman.net (ns.snowman.net [10.10.0.2]) by relay.snowman.net (8.13.1/8.13.1/Debian-19) with ESMTP id j2MGwv1U025574 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Tue, 22 Mar 2005 11:58:57 -0500 Received: from ns.snowman.net (localhost [127.0.0.1]) by ns.snowman.net (8.13.1/8.13.1/Debian-19) with ESMTP id j2MGxSeA022374 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Tue, 22 Mar 2005 11:59:28 -0500 Received: (from sfrost@localhost) by ns.snowman.net (8.13.1/8.13.1/Submit) id j2MGxSNR022372; Tue, 22 Mar 2005 11:59:28 -0500 Date: Tue, 22 Mar 2005 11:59:28 -0500 From: Stephen Frost To: Wolfgang Walter Cc: netdev@oss.sgi.com Subject: Re: [IPSEC] Too many SADs! Message-ID: <20050322165928.GC8725@ns.snowman.net> References: <200503220052.52756.wolfgang.walter@studentenwerk.mhn.de> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="TRYliJ5NKNqkz5bu" Content-Disposition: inline In-Reply-To: <200503220052.52756.wolfgang.walter@studentenwerk.mhn.de> X-Editor: Vim http://www.vim.org/ X-Info: http://www.snowman.net X-Operating-System: Linux/2.4.24ns.3.0 (i686) X-Uptime: 11:55:26 up 416 days, 11:47, 9 users, load average: 0.26, 0.29, 0.22 User-Agent: Mutt/1.5.6+20040907i X-Virus-Scanned: ClamAV 0.83/778/Mon Mar 21 02:48:43 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 473 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: sfrost@snowman.net Precedence: bulk X-list: netdev Content-Length: 1757 Lines: 48 --TRYliJ5NKNqkz5bu Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable * Wolfgang Walter (wolfgang.walter@studentenwerk.mhn.de) wrote: > We had the same problem. Seems to be a limitation of the pfkey-implementa= tion=20 > of linux. >=20 > racoon and setkey both use the pfkey-interface. >=20 > We switched to iproute2 and openswan which both use the netfilter-interfa= ce.=20 > Therefor they can handle thousands of SAD and SPD rules. Well, that's quite interesting. I didn't realize there were multiple interfaces to the IPSEC in Linux. Additionally, the problem isn't that I've got too many policies which end up requiring too many SADs- the problem is that SADs are being created above and beyond what's actually necessary for my policies, which is a problem. I'm not entirely sure why that's happening either. At one point a SAD was being added every second when there was *already* an apparently current SAD for the required policy. Not good, looks like a bug to me, and I would have thought it was a kernel bug but I could be wrong there. I'm certainly curious about the alternative interface to IPSEC in Linux, and especially your claim that it's a 'netfilter' interface. I'll certainly look into that... What kernel are you using? What version of iproute2 and Openswan? Do you have to patch the kernel? Stephen --TRYliJ5NKNqkz5bu 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) iD8DBQFCQE7vrzgMPqB3kigRAsEfAJ47pfPW9pXIg/onxRgPQ74AwSYtvgCghzem EQII5fyl34+XyQRsTlF559o= =ehm+ -----END PGP SIGNATURE----- --TRYliJ5NKNqkz5bu-- From davem@davemloft.net Tue Mar 22 09:21:55 2005 Received: with ECARTIS (v1.0.0; list netdev); Tue, 22 Mar 2005 09:22:03 -0800 (PST) Received: from cheetah.davemloft.net (mail@dsl027-180-174.sfo1.dsl.speakeasy.net [216.27.180.174]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j2MHLt9R013692 for ; Tue, 22 Mar 2005 09:21:55 -0800 Received: from localhost ([127.0.0.1] helo=cheetah.davemloft.net ident=davem) by cheetah.davemloft.net with smtp (Exim 3.36 #1 (Debian)) id 1DDn2w-0007BT-00; Tue, 22 Mar 2005 09:20:02 -0800 Date: Tue, 22 Mar 2005 09:20:02 -0800 From: "David S. Miller" To: Miika Komu Cc: yoshfuji@linux-ipv6.org, gurtov@cs.helsinki.fi, netdev@oss.sgi.com, infrahip@hiit.fi Subject: Re: [Infrahip] [PATCH] Host Identity Protocol Message-Id: <20050322092002.486fdf1c.davem@davemloft.net> In-Reply-To: References: <42369919.9010203@cs.helsinki.fi> <20050321.024241.67451836.yoshfuji@linux-ipv6.org> <20050320200356.5f8fa583.davem@davemloft.net> X-Mailer: Sylpheed version 1.0.1 (GTK+ 1.2.10; sparc-unknown-linux-gnu) X-Face: "_;p5u5aPsO,_Vsx"^v-pEq09'CU4&Dc1$fQExov$62l60cgCc%FnIwD=.UF^a>?5'9Kn[;433QFVV9M..2eN.@4ZWPGbdi<=?[:T>y?SD(R*-3It"Vj:)"dP Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV 0.83/778/Mon Mar 21 02:48:43 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 474 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: davem@davemloft.net Precedence: bulk X-list: netdev Content-Length: 1560 Lines: 32 On Tue, 22 Mar 2005 16:08:31 +0200 (EET) Miika Komu wrote: > Yes, MIP6 and IKE signalling is handled in the userspace, but > the same is not true for SCTP (lksctp). SCTP is a network protocol used for data transfer. HIP is a signalling mechanism used to setup configuration. > engineering practise is to put everything in the userspace, unless there > is good reason for putting it in to the kernelspace. > > We don't currently have concrete measurements (comparing userspace and > kernelspace approaches) to justify our kernel oriented approach, so we > will have to get back to you later with some figures. If the results show > that an userspace implementation is superior to a kernel based approach in > terms of security or performance, we may have rewrite the code to the > userspace. In the mean time, do you happen to know any good references > where any userspace network protocol implementation has been compared and > measured against a kernelspace implementation? It would be a good starting > point for us. > > I would like to mention that lksctp was implemented in the 2.6 kernel > because of better performance and tighter integration to the socket API. > We are dealing with similar issues with HIPL but seems like we need to > justify the reasons by analyzing and measuring. In addition, security > issues (DoS protection, user supplied public keys, etc) are taken pretty > seriously in HIP and may benefit from a kernel oriented approach. > > -- > Miika Komu miika@iki.fi http://www.iki.fi/miika/ From yoshfuji@linux-ipv6.org Tue Mar 22 09:55:11 2005 Received: with ECARTIS (v1.0.0; list netdev); Tue, 22 Mar 2005 09:55:21 -0800 (PST) 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 j2MHtA0w016824 for ; Tue, 22 Mar 2005 09:55:11 -0800 Received: from localhost (localhost [127.0.0.1]) by yue.st-paulia.net (Postfix) with ESMTP id 8642E33CC2; Wed, 23 Mar 2005 02:57:01 +0900 (JST) Date: Wed, 23 Mar 2005 02:57:01 +0900 (JST) Message-Id: <20050323.025701.31052798.yoshfuji@linux-ipv6.org> To: miika@iki.fi Cc: davem@davemloft.net, gurtov@cs.helsinki.fi, netdev@oss.sgi.com, infrahip@hiit.fi, yoshfuji@linux-ipv6.org Subject: Re: [Infrahip] [PATCH] Host Identity Protocol From: YOSHIFUJI Hideaki / =?iso-2022-jp?B?GyRCNUhGIzFRTEAbKEI=?= In-Reply-To: References: <20050321.024241.67451836.yoshfuji@linux-ipv6.org> <20050320200356.5f8fa583.davem@davemloft.net> Organization: USAGI Project X-URL: http://www.yoshifuji.org/%7Ehideaki/ X-Fingerprint: 9022 65EB 1ECF 3AD1 0BDF 80D8 4807 F894 E062 0EEA X-PGP-Key-URL: http://www.yoshifuji.org/%7Ehideaki/hideaki@yoshifuji.org.asc X-Face: "5$Al-.M>NJ%a'@hhZdQm:."qn~PA^gq4o*>iCFToq*bAi#4FRtx}enhuQKz7fNqQz\BYU] $~O_5m-9'}MIs`XGwIEscw;e5b>n"B_?j/AkL~i/MEaZBLP X-Mailer: Mew version 2.2 on Emacs 20.7 / Mule 4.1 (AOI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV 0.83/778/Mon Mar 21 02:48:43 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 475 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: yoshfuji@linux-ipv6.org Precedence: bulk X-list: netdev Content-Length: 937 Lines: 21 In article (at Tue, 22 Mar 2005 16:08:31 +0200 (EET)), Miika Komu says: > will have to get back to you later with some figures. If the results show > that an userspace implementation is superior to a kernel based approach in > terms of security or performance, we may have rewrite the code to the And, IMHO, the most important argument is, probably, in terms of simplicity and universality of kernel part. e.g. MIP6 uses XFRM / stackable destination architecture as its fundamental infrastructure. They (simplicity and universality) are unlikely measurable, though. > justify the reasons by analyzing and measuring. In addition, security > issues (DoS protection, user supplied public keys, etc) are taken pretty > seriously in HIP and may benefit from a kernel oriented approach. I belive that we can find solutions to solve these issues (if any). --yoshfuji From mcr@sandelman.ottawa.on.ca Tue Mar 22 10:46:31 2005 Received: with ECARTIS (v1.0.0; list netdev); Tue, 22 Mar 2005 10:46:39 -0800 (PST) Received: from pike.sandelman.ca (pike.sandelman.ca [205.150.200.164]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j2MIkUfv020770 for ; Tue, 22 Mar 2005 10:46:30 -0800 Received: from sandelman.ottawa.on.ca (road.marajade.sandelman.ca [205.150.200.163]) by pike.sandelman.ca (Postfix) with ESMTP id EEDEB6479C; Tue, 22 Mar 2005 13:46:26 -0500 (EST) Received: from marajade.sandelman.ottawa.on.ca (marajade [127.0.0.1]) by sandelman.ottawa.on.ca (Postfix) with ESMTP id D99AFBD00; Tue, 22 Mar 2005 13:46:25 -0500 (EST) To: Stephen Frost Cc: Wolfgang Walter , netdev@oss.sgi.com Subject: Re: [IPSEC] Too many SADs! In-Reply-To: Message from Stephen Frost of "Tue, 22 Mar 2005 11:59:28 EST." <20050322165928.GC8725@ns.snowman.net> References: <200503220052.52756.wolfgang.walter@studentenwerk.mhn.de> <20050322165928.GC8725@ns.snowman.net> X-Mailer: MH-E 7.82; nmh 1.0.4+dev; XEmacs 21.4 (patch 17) Date: Tue, 22 Mar 2005 13:46:25 -0500 Message-ID: <6298.1111517185@marajade.sandelman.ottawa.on.ca> From: Michael Richardson X-Virus-Scanned: ClamAV 0.83/778/Mon Mar 21 02:48:43 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 476 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: mcr@sandelman.ottawa.on.ca Precedence: bulk X-list: netdev Content-Length: 1563 Lines: 34 -----BEGIN PGP SIGNED MESSAGE----- >>>>> "Stephen" == Stephen Frost writes: Stephen> interfaces to the IPSEC in Linux. Additionally, the Stephen> problem isn't that I've got too many policies which end up Stephen> requiring too many SADs- the problem is that SADs are Stephen> being created above and beyond what's actually necessary Stephen> for my policies, which is a problem. I'm not entirely sure There is certainly a bug in openswan 2.3.1drX, possibly in 2.3.0, where more SPD entries get created than necessary. This would result in many SAD entries, since the incoming SAs are not removed until they expire, or the remote end asks for them to be deleted. As the SAD interface in NETKEY provided by netfilter/pfkey does not permit any kind of "insert here" option, it is possible that there is some other bug whereby SAD entries multiply. - -- ] Michael Richardson Xelerance Corporation, Ottawa, ON | firewalls [ ] mcr @ xelerance.com Now doing IPsec training, see |net architect[ ] http://www.sandelman.ca/mcr/ www.xelerance.com/training/ |device driver[ ] panic("Just another Debian GNU/Linux using, kernel hacking, security guy"); [ -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.2 (GNU/Linux) Comment: Finger me for keys iQCVAwUBQkBoAIqHRg3pndX9AQEb3wQA4NNgcrdmwlloOJPJX+Z8xdfXNA42Gm1P M7wDT2nFlOavn04FVNPdp45EzITyoICYHkRXSxhorb42lW5mWahRckSjbujMLw9W bFdpeVqUj+gitmwAs5VYZ2C3KAxiws6puKnINWgxiZgOHiIkAUotAX6jRkPHF8E5 loREL0C1ykM= =aC1v -----END PGP SIGNATURE----- From sfrost@ns.snowman.net Tue Mar 22 11:11:10 2005 Received: with ECARTIS (v1.0.0; list netdev); Tue, 22 Mar 2005 11:11:16 -0800 (PST) Received: from relay.snowman.net (relay.snowman.net [66.92.160.56]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j2MJB9Na023174 for ; Tue, 22 Mar 2005 11:11:09 -0800 Received: from ns.snowman.net (ns.snowman.net [10.10.0.2]) by relay.snowman.net (8.13.1/8.13.1/Debian-19) with ESMTP id j2MJB2mx027560 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Tue, 22 Mar 2005 14:11:02 -0500 Received: from ns.snowman.net (localhost [127.0.0.1]) by ns.snowman.net (8.13.1/8.13.1/Debian-19) with ESMTP id j2MJBX26026889 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Tue, 22 Mar 2005 14:11:33 -0500 Received: (from sfrost@localhost) by ns.snowman.net (8.13.1/8.13.1/Submit) id j2MJBXw9026887; Tue, 22 Mar 2005 14:11:33 -0500 Date: Tue, 22 Mar 2005 14:11:33 -0500 From: Stephen Frost To: Michael Richardson Cc: Wolfgang Walter , netdev@oss.sgi.com Subject: Re: [IPSEC] Too many SADs! Message-ID: <20050322191133.GD8725@ns.snowman.net> References: <200503220052.52756.wolfgang.walter@studentenwerk.mhn.de> <20050322165928.GC8725@ns.snowman.net> <6298.1111517185@marajade.sandelman.ottawa.on.ca> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="LwW0XdcUbUexiWVK" Content-Disposition: inline In-Reply-To: <6298.1111517185@marajade.sandelman.ottawa.on.ca> X-Editor: Vim http://www.vim.org/ X-Info: http://www.snowman.net X-Operating-System: Linux/2.4.24ns.3.0 (i686) X-Uptime: 14:08:34 up 416 days, 14:00, 9 users, load average: 0.16, 0.13, 0.15 User-Agent: Mutt/1.5.6+20040907i X-Virus-Scanned: ClamAV 0.83/778/Mon Mar 21 02:48:43 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 477 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: sfrost@snowman.net Precedence: bulk X-list: netdev Content-Length: 1734 Lines: 49 --LwW0XdcUbUexiWVK Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable * Michael Richardson (mcr@sandelman.ottawa.on.ca) wrote: > -----BEGIN PGP SIGNED MESSAGE----- >=20 >=20 > >>>>> "Stephen" =3D=3D Stephen Frost writes: > Stephen> interfaces to the IPSEC in Linux. Additionally, the > Stephen> problem isn't that I've got too many policies which end up > Stephen> requiring too many SADs- the problem is that SADs are > Stephen> being created above and beyond what's actually necessary > Stephen> for my policies, which is a problem. I'm not entirely sure >=20 > There is certainly a bug in openswan 2.3.1drX, possibly in 2.3.0, > where more SPD entries get created than necessary. Well, that's interesting, since my problem had been with racoon... > This would result in many SAD entries, since the incoming SAs are not > removed until they expire, or the remote end asks for them to be deleted. > =20 > As the SAD interface in NETKEY provided by netfilter/pfkey does not > permit any kind of "insert here" option, it is possible that there is > some other bug whereby SAD entries multiply. Got me, but if you're seeing this with openswan too, well, that'd be rather interesting and might point to a problem outside of the userspace tools... Stephen --LwW0XdcUbUexiWVK 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) iD8DBQFCQG3lrzgMPqB3kigRAoSYAKCVDYpxoU8EdW36WDrlOlUC/1Y5lgCglwPh vLUjV8ROBw1jhUzGrdH7fiE= =caNA -----END PGP SIGNATURE----- --LwW0XdcUbUexiWVK-- From jgarzik@pobox.com Tue Mar 22 11:14:24 2005 Received: with ECARTIS (v1.0.0; list netdev); Tue, 22 Mar 2005 11:14:30 -0800 (PST) Received: from parcelfarce.linux.theplanet.co.uk (IDENT:93@parcelfarce.linux.theplanet.co.uk [195.92.249.252]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j2MJENS7023848 for ; Tue, 22 Mar 2005 11:14:23 -0800 Received: from cpe-069-134-152-124.nc.rr.com ([69.134.152.124] helo=[10.10.10.88]) by parcelfarce.linux.theplanet.co.uk with asmtp (TLSv1:AES256-SHA:256) (Exim 4.33) id 1DDopZ-0007o5-Do; Tue, 22 Mar 2005 19:14:21 +0000 Message-ID: <42406E81.3090202@pobox.com> Date: Tue, 22 Mar 2005 14:14:09 -0500 From: Jeff Garzik User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.3) Gecko/20040922 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Andrew Morton CC: Don Fry , davem@davemloft.net, netdev@oss.sgi.com, steven.hardy@astrium.eads.net Subject: Re: [patch 12/13] pcnet32 79C975 fiber fix References: <200503152222.j2FMMiLB016826@shell0.pdx.osdl.net> <20050316005630.GA9421@us.ibm.com> <20050315170322.3398bd60.akpm@osdl.org> In-Reply-To: <20050315170322.3398bd60.akpm@osdl.org> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV 0.83/778/Mon Mar 21 02:48:43 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 478 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: jgarzik@pobox.com Precedence: bulk X-list: netdev Content-Length: 802 Lines: 27 Andrew Morton wrote: > Don Fry wrote: > >>I had not seen this problem until now. The patch looks ok and >> probably should have been written that way initially. I have been >> able to do a quick touch test with a 970A, 971, 972, 973, 975, 976, and >> 978 (some on ia32 and others on ppc64) without any adverse effects. >> The 975 I have is copper not fiber. > > > Great, thanks. > > >> Since only bit 12 is needed to enable LED writes, the code could >> really be "a->write_bcr(ioaddr, 2, a->read_bcr(ioaddr, 2) | 0x1000);" >> During pcnet32_open the ASEL bit is changed anyway. > > > OK, could you please prepare a final patch sometime and get it into Jeff? > cc me as well please so I can update the patch I have. Yes, please do Don, if you have the time. Jeff From jgarzik@pobox.com Tue Mar 22 12:37:36 2005 Received: with ECARTIS (v1.0.0; list netdev); Tue, 22 Mar 2005 12:37:43 -0800 (PST) Received: from parcelfarce.linux.theplanet.co.uk (IDENT:93@parcelfarce.linux.theplanet.co.uk [195.92.249.252]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j2MKbZjR000755 for ; Tue, 22 Mar 2005 12:37:36 -0800 Received: from cpe-069-134-152-124.nc.rr.com ([69.134.152.124] helo=[10.10.10.88]) by parcelfarce.linux.theplanet.co.uk with asmtp (TLSv1:AES256-SHA:256) (Exim 4.33) id 1DDq86-00011G-2d; Tue, 22 Mar 2005 20:37:34 +0000 Message-ID: <42408200.2090402@pobox.com> Date: Tue, 22 Mar 2005 15:37:20 -0500 From: Jeff Garzik User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.3) Gecko/20040922 X-Accept-Language: en-us, en MIME-Version: 1.0 To: "John W. Linville" CC: linux-kernel@vger.kernel.org, netdev@oss.sgi.com, cramerj@intel.com, john.ronciak@intel.com, ganesh.venkatesan@intel.com Subject: Re: [patch 2.6.11] e1000: avoid sleeping in watchdog timer context References: <20050314212510.GA12573@tuxdriver.com> In-Reply-To: <20050314212510.GA12573@tuxdriver.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV 0.83/778/Mon Mar 21 02:48:43 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 479 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: jgarzik@pobox.com Precedence: bulk X-list: netdev Content-Length: 43 Lines: 2 applied this an the flush-workqueue patch From jgarzik@pobox.com Tue Mar 22 12:52:43 2005 Received: with ECARTIS (v1.0.0; list netdev); Tue, 22 Mar 2005 12:52:48 -0800 (PST) Received: from parcelfarce.linux.theplanet.co.uk (IDENT:93@parcelfarce.linux.theplanet.co.uk [195.92.249.252]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j2MKqgEs002226 for ; Tue, 22 Mar 2005 12:52:42 -0800 Received: from cpe-069-134-152-124.nc.rr.com ([69.134.152.124] helo=[10.10.10.88]) by parcelfarce.linux.theplanet.co.uk with asmtp (TLSv1:AES256-SHA:256) (Exim 4.33) id 1DDqMi-0001FH-Ap; Tue, 22 Mar 2005 20:52:40 +0000 Message-ID: <4240858B.5080209@pobox.com> Date: Tue, 22 Mar 2005 15:52:27 -0500 From: Jeff Garzik User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.3) Gecko/20040922 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Michael Chan , "David S. Miller" CC: netdev@oss.sgi.com Subject: Re: [PATCH 2.6.11 1/8] tg3: add 5705_plus flag References: In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV 0.83/778/Mon Mar 21 02:48:43 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 480 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: jgarzik@pobox.com Precedence: bulk X-list: netdev Content-Length: 1377 Lines: 45 Michael Chan wrote: > Add a 5705_plus flag to indicate the device is 5705, 5750, or future chips > that all share the same basic architecture. This makes it easier to add > support for future devices. > > > Signed-off-by: Michael Chan pci_chip_rev_id) == ASIC_REV_5705 || - GET_ASIC_REV(tp->pci_chip_rev_id) == ASIC_REV_5750) { + if (tp->tg3_flags2 & TG3_FLG2_5705_PLUS) { can be an example to others for future changes. 2) [administrivia] Your patches are encoded as base64, which makes reviewing and applying your patches difficult. You are violating clause #3, rules one and two: http://linux.yyz.us/patch-format.html For sending patches, I highly recommend using a text file template, and /usr/sbin/sendmail (sendmail/postfix/exim mail servers provide this). See http://lkml.org/lkml/2005/2/24/3 for more info. If you don't want to bother with Unix, I -think- Mozilla Thunderbird for Windows will correctly attach patches in a way that is useable. http://www.mozilla.org/products/thunderbird/ Regards, Jeff From jgarzik@pobox.com Tue Mar 22 12:53:42 2005 Received: with ECARTIS (v1.0.0; list netdev); Tue, 22 Mar 2005 12:53:47 -0800 (PST) Received: from parcelfarce.linux.theplanet.co.uk (IDENT:93@parcelfarce.linux.theplanet.co.uk [195.92.249.252]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j2MKrgx5002623 for ; Tue, 22 Mar 2005 12:53:42 -0800 Received: from cpe-069-134-152-124.nc.rr.com ([69.134.152.124] helo=[10.10.10.88]) by parcelfarce.linux.theplanet.co.uk with asmtp (TLSv1:AES256-SHA:256) (Exim 4.33) id 1DDqNh-0001GD-DG; Tue, 22 Mar 2005 20:53:41 +0000 Message-ID: <424085C9.3020608@pobox.com> Date: Tue, 22 Mar 2005 15:53:29 -0500 From: Jeff Garzik User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.3) Gecko/20040922 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Michael Chan CC: "David S. Miller" , netdev@oss.sgi.com Subject: Re: [PATCH 2.6.11 2/8] tg3: flush status block in tg3_interrupt References: In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV 0.83/778/Mon Mar 21 02:48:43 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 481 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: jgarzik@pobox.com Precedence: bulk X-list: netdev Content-Length: 393 Lines: 10 Michael Chan wrote: > Add register read of PCI state register in tg3_interrupt() if status block's > updated bit is not set. This will flush the status block and confirm whether > the interrupt is ours or not. PCI ordering rules allow the interrupt to > arrive at the CPU ahead of the status block that may be posted at the > chipset. > > Signed-off-by: Michael Chan ; Tue, 22 Mar 2005 12:56:38 -0800 Received: from cpe-069-134-152-124.nc.rr.com ([69.134.152.124] helo=[10.10.10.88]) by parcelfarce.linux.theplanet.co.uk with asmtp (TLSv1:AES256-SHA:256) (Exim 4.33) id 1DDqQX-0001J8-HP; Tue, 22 Mar 2005 20:56:37 +0000 Message-ID: <42408679.7020407@pobox.com> Date: Tue, 22 Mar 2005 15:56:25 -0500 From: Jeff Garzik User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.3) Gecko/20040922 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Michael Chan CC: "David S. Miller" , netdev@oss.sgi.com Subject: Re: [PATCH 2.6.11 3/8] tg3: Add msi support for 5750 C0 References: In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV 0.83/778/Mon Mar 21 02:48:43 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 482 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: jgarzik@pobox.com Precedence: bulk X-list: netdev Content-Length: 644 Lines: 21 Michael Chan wrote: > Add MSI support for 5750 C0 and newer chips. MSI is handled by a new > interrupt service routine that is very similar to the existing > tg3_interrupt() for INTx mode. The MSI version is optimized by not checking > for shared interrupt and not flushing the status block. > > The code is also changed to reference the irq from tp->pdev->irq instead of > dev->irq. > > Signed-off-by: Michael Chan ; Tue, 22 Mar 2005 12:57:48 -0800 Received: from cpe-069-134-152-124.nc.rr.com ([69.134.152.124] helo=[10.10.10.88]) by parcelfarce.linux.theplanet.co.uk with asmtp (TLSv1:AES256-SHA:256) (Exim 4.33) id 1DDqRf-0001L9-2t; Tue, 22 Mar 2005 20:57:47 +0000 Message-ID: <424086BF.6030300@pobox.com> Date: Tue, 22 Mar 2005 15:57:35 -0500 From: Jeff Garzik User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.3) Gecko/20040922 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Michael Chan , "David S. Miller" CC: netdev@oss.sgi.com Subject: Re: [PATCH 2.6.11 4/8] tg3: Add msi test References: In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV 0.83/778/Mon Mar 21 02:48:43 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 483 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: jgarzik@pobox.com Precedence: bulk X-list: netdev Content-Length: 357 Lines: 16 Michael Chan wrote: > Add an MSI test to make sure MSI is working at the system level. If the test > fails, the driver will go back to INTx mode. > > Signed-off-by: Michael Chan ; Tue, 22 Mar 2005 12:58:36 -0800 Received: from cpe-069-134-152-124.nc.rr.com ([69.134.152.124] helo=[10.10.10.88]) by parcelfarce.linux.theplanet.co.uk with asmtp (TLSv1:AES256-SHA:256) (Exim 4.33) id 1DDqSP-0001Lx-PA; Tue, 22 Mar 2005 20:58:34 +0000 Message-ID: <424086EB.50302@pobox.com> Date: Tue, 22 Mar 2005 15:58:19 -0500 From: Jeff Garzik User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.3) Gecko/20040922 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Michael Chan CC: "David S. Miller" , netdev@oss.sgi.com Subject: Re: [PATCH 2.6.11 5/8] tg3: Add unstable PLL workaround for 5750 References: In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV 0.83/778/Mon Mar 21 02:48:43 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 484 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: jgarzik@pobox.com Precedence: bulk X-list: netdev Content-Length: 207 Lines: 9 Michael Chan wrote: > Add unstable PLL clock workaround for 5750 Ax and Bx devices. The workaround > code is run just before entering D3hot state. > > Signed-off-by: Michael Chan ; Tue, 22 Mar 2005 12:59:02 -0800 Received: from cpe-069-134-152-124.nc.rr.com ([69.134.152.124] helo=[10.10.10.88]) by parcelfarce.linux.theplanet.co.uk with asmtp (TLSv1:AES256-SHA:256) (Exim 4.33) id 1DDqSq-0001MH-6J; Tue, 22 Mar 2005 20:59:00 +0000 Message-ID: <42408704.2030800@pobox.com> Date: Tue, 22 Mar 2005 15:58:44 -0500 From: Jeff Garzik User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.3) Gecko/20040922 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Michael Chan CC: "David S. Miller" , netdev@oss.sgi.com Subject: Re: [PATCH 2.6.11 6/8] tg3: Fix jumbo frames phy settings References: In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV 0.83/778/Mon Mar 21 02:48:43 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 485 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: jgarzik@pobox.com Precedence: bulk X-list: netdev Content-Length: 352 Lines: 11 Michael Chan wrote: > Fix jumbo frame settings on all copper phys that support jumbo frames by > setting the fifo elasticity bit. This setting is for the phy's tx fifo to > properly handle jumbo frames. Note that a similar jumbo frame fix for the > phy's rx fifo was made to tg3 in the past. > > Signed-off-by: Michael Chan ; Tue, 22 Mar 2005 12:59:18 -0800 Received: from cpe-069-134-152-124.nc.rr.com ([69.134.152.124] helo=[10.10.10.88]) by parcelfarce.linux.theplanet.co.uk with asmtp (TLSv1:AES256-SHA:256) (Exim 4.33) id 1DDqT7-0001Mi-BD; Tue, 22 Mar 2005 20:59:17 +0000 Message-ID: <42408719.5000307@pobox.com> Date: Tue, 22 Mar 2005 15:59:05 -0500 From: Jeff Garzik User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.3) Gecko/20040922 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Michael Chan CC: "David S. Miller" , netdev@oss.sgi.com Subject: Re: [PATCH 2.6.11 7/8] tg3: Fix ethtool set functions References: In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV 0.83/778/Mon Mar 21 02:48:43 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 486 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: jgarzik@pobox.com Precedence: bulk X-list: netdev Content-Length: 435 Lines: 13 Michael Chan wrote: > Fix all relevant ethtool set functions to properly handle the > !netif_running() case. In most cases, the new settings are accepted without > setting the hardware if !netif_running(). The new settings will take effect > when the device is subsequently brought up. tg3_nway_reset() is the exception > where it will return -EAGAIN if !netif_running(). > > > Signed-off-by: Michael Chan ; Tue, 22 Mar 2005 12:59:29 -0800 Received: from cpe-069-134-152-124.nc.rr.com ([69.134.152.124] helo=[10.10.10.88]) by parcelfarce.linux.theplanet.co.uk with asmtp (TLSv1:AES256-SHA:256) (Exim 4.33) id 1DDqTI-0001Mp-CU; Tue, 22 Mar 2005 20:59:28 +0000 Message-ID: <42408724.60608@pobox.com> Date: Tue, 22 Mar 2005 15:59:16 -0500 From: Jeff Garzik User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.3) Gecko/20040922 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Michael Chan CC: "David S. Miller" , netdev@oss.sgi.com Subject: Re: [PATCH 2.6.11 8/8] tg3: Add Broadcom copyright References: In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV 0.83/778/Mon Mar 21 02:48:43 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 487 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: jgarzik@pobox.com Precedence: bulk X-list: netdev Content-Length: 106 Lines: 8 Michael Chan wrote: > Add Broadcom copyright. > > Signed-off-by: Michael Chan ; Tue, 22 Mar 2005 13:09:38 -0800 Received: from [192.168.0.3] (81-178-222-176.dsl.pipex.com [81.178.222.176]) by blaster.systems.pipex.net (Postfix) with ESMTP id 5CC15E0002EE; Tue, 22 Mar 2005 21:09:18 +0000 (GMT) Message-ID: <42408998.5000202@dsl.pipex.com> Date: Tue, 22 Mar 2005 21:09:44 +0000 From: Andy Furniss User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.8b) Gecko/20050217 MIME-Version: 1.0 To: hadi@cyberus.ca Cc: Harald Welte , Patrick McHardy , Remus , netdev@oss.sgi.com, Nguyen Dinh Nam , Andre Tomt , syrius.ml@no-log.org, Damion de Soto Subject: Re: iptables breakage WAS(Re: dummy as IMQ replacement References: <1107123123.8021.80.camel@jzny.localdomain> <0fcf01c5077f$579e4b80$6e69690a@RIMAS> <1107174142.8021.121.camel@jzny.localdomain> <00c301c524b4$938cd240$6e69690a@RIMAS> <1110379135.1091.143.camel@jzny.localdomain> <1110416767.1111.76.camel@jzny.localdomain> <025501c52552$2dbf87c0$6e69690a@RIMAS> <1110453757.1108.87.camel@jzny.localdomain> <423B7BCB.10400@dsl.pipex.com> <1111410890.1092.195.camel@jzny.localdomain> <423F41AD.3010902@dsl.pipex.com> <1111444869.1072.51.camel@jzny.localdomain> <423F71C2.8040802@dsl.pipex.com> <1111462263.1109.6.camel@jzny.localdomain> In-Reply-To: <1111462263.1109.6.camel@jzny.localdomain> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV 0.83/778/Mon Mar 21 02:48:43 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 488 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: andy.furniss@dsl.pipex.com Precedence: bulk X-list: netdev Content-Length: 2211 Lines: 70 jamal wrote: > Andy, > Thanks for all your efforts. > I will be back on my regular setup by tommorow evening and should be > able to hopefuly test this. I am going to try: > > - latest iproute2 with 1.3.x ipt changes > - i am just gonna jump to iptables 1.3.x - we are going to ignore 1.2.11 > and below > - kernel 2.6.11.5 patches with stats > > Issues seen so far - the following dont work: > > a) tc filter add dev eth0 parent ffff: protocol ip prio 10 u32 \ > match u32 0 0 flowid 1:1 action ipt -j MARK --set-mark > [Actually did you test this?] Not without the 1 - If I do I get ++ /usr/sbin/tc filter add dev eth0 parent ffff: protocol ip prio 10 u32 match u32 0 0 flowid 1:1 action ipt -j MARK --set-mark ipt: option `--set-mark' requires an argument tablename: mangle hook: NF_IP_PRE_ROUTING target: MARK set 0x0 index 0 RTNETLINK answers: Invalid argument We have an error talking to the kernel With the one - ++ /usr/sbin/tc filter add dev eth0 parent ffff: protocol ip prio 10 u32 match u32 0 0 flowid 1:1 action ipt -j MARK --set-mark 1 tablename: mangle hook: NF_IP_PRE_ROUTING target: MARK set 0x1 index 0 RTNETLINK answers: Invalid argument We have an error talking to the kernel > > b) above with mirred as the next action fails in user space Yes - ++ /usr/sbin/tc filter add dev eth0 parent ffff: protocol ip prio 10 u32 match u32 0 0 flowid 1:1 action ipt -j MARK --set-mark 1 action mirred egress redirect dev dummy0 tablename: mangle hook: NF_IP_PRE_ROUTING target: MARK set 0x1 index 0 bad action type mirred Usage: ... gact [RAND] [INDEX] Where: ACTION := reclassify | drop | continue | pass RAND := random RANDTYPE := netrand | determVAL : = value not exceeding 10000INDEX := index value used bad action parsing parse_action: bad value (5:mirred)! Illegal "action" I notice if I grep iproute for "bad action type" it's in m_gact.c which does not contain the word mirred to test at all. > > c) a) with a simple "action ok" is also rejected by the kernel > with "Invalid argument" Yes. > > Did i miss anything else? Don't think so - I can get a and c to work with older iptables and headers. Andy. From cliffw@osdl.org Tue Mar 22 13:55:44 2005 Received: with ECARTIS (v1.0.0; list netdev); Tue, 22 Mar 2005 13:55:49 -0800 (PST) Received: from smtp.osdl.org (fire.osdl.org [65.172.181.4]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j2MLthhx010714 for ; Tue, 22 Mar 2005 13:55:44 -0800 Received: from es175 (fw.osdl.org [65.172.181.6]) (authenticated bits=0) by smtp.osdl.org (8.12.8/8.12.8) with ESMTP id j2MLtXqi017426 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO); Tue, 22 Mar 2005 13:55:34 -0800 Date: Tue, 22 Mar 2005 13:55:33 -0800 From: cliff white To: Baruch Even , netdev@oss.sgi.com Subject: Re: netif_rx packet dumping Message-ID: <20050322135533.55313a42@es175> In-Reply-To: <422DCB14.1040805@ev-en.org> References: <20050303123811.4d934249@dxpl.pdx.osdl.net> <20050303125556.6850cfe5.davem@davemloft.net> <1109884688.1090.282.camel@jzny.localdomain> <20050303132143.7eef517c@dxpl.pdx.osdl.net> <1109885065.1098.285.camel@jzny.localdomain> <20050303133237.5d64578f.davem@davemloft.net> <20050303135416.0d6e7708@dxpl.pdx.osdl.net> <1109888811.1092.352.camel@jzny.localdomain> <20050303151606.3587394f@dxpl.pdx.osdl.net> <4227A23C.5050300@ev-en.org> <1109907956.1092.476.camel@jzny.localdomain> <42282098.8010506@ev-en.org> <1110203711.1088.1393.camel@jzny.localdomain> <422DCB14.1040805@ev-en.org> Organization: OSDL X-Mailer: Sylpheed-Claws 1.0.1 (GTK+ 1.2.10; i386-pc-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-MIMEDefang-Filter: osdl$Revision: 1.105 $ X-Scanned-By: MIMEDefang 2.36 X-Virus-Scanned: ClamAV 0.83/778/Mon Mar 21 02:48:43 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 489 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: cliffw@osdl.org Precedence: bulk X-list: netdev Content-Length: 1126 Lines: 37 On Tue, 08 Mar 2005 15:56:04 +0000 Baruch Even wrote: > jamal wrote: > > On Fri, 2005-03-04 at 03:47, Baruch Even wrote: > > > >>jamal wrote: > > > > [snip] > > > So if i was you i would repeat 1.2 with the fix from 1.1 as well as > > tying the NIC to one CPU. And it would be a good idea to present more > > detailed results - not just tcp windows fluctuating (you may not need > > them for the paper, but would be useful to see for debugging purposes > > other parameters). > > I'd be happy to hear what other benchmarks you would like to see, I > currently intend to add some ack processing time analysis and oprofile > information. With possibly showing the size of the ingress queue as a > measure as well. > > Making it as thorough as possible is one of my goals. Input is always > welcome. I am collecting network benchmarks/test in hope of doing some testing here at OSDL. Would love to run your benchmark, if you wished to share. cliffw > > Baruch > -- "Ive always gone through periods where I bolt upright at four in the morning; now at least theres a reason." -Michael Feldman From mchan@broadcom.com Tue Mar 22 14:07:32 2005 Received: with ECARTIS (v1.0.0; list netdev); Tue, 22 Mar 2005 14:07:38 -0800 (PST) Received: from MMS1.broadcom.com (mms1.broadcom.com [216.31.210.17]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j2MM7WTk011584 for ; Tue, 22 Mar 2005 14:07:32 -0800 Received: from 10.10.64.121 by MMS1.broadcom.com with SMTP (Broadcom SMTP Relay (Email Firewall v6.1.0)); Tue, 22 Mar 2005 14:07:23 -0800 X-Server-Uuid: 146C3151-C1DE-4F71-9D02-C3BE503878DD Received: from mail-irva-8.broadcom.com ([10.10.64.221]) by mail-irva-1.broadcom.com (Post.Office MTA v3.5.3 release 223 ID# 0-72233U7200L2200S0V35) with ESMTP id com; Tue, 22 Mar 2005 14:07:16 -0800 Received: from mon-irva-10.broadcom.com (mon-irva-10.broadcom.com [10.10.64.171]) by mail-irva-8.broadcom.com (MOS 3.5.6-GR) with ESMTP id APQ03461; Tue, 22 Mar 2005 14:07:14 -0800 (PST) Received: from nt-irva-0741.brcm.ad.broadcom.com ( nt-irva-0741.brcm.ad.broadcom.com [10.8.194.54]) by mon-irva-10.broadcom.com (8.9.1/8.9.1) with ESMTP id OAA21049; Tue, 22 Mar 2005 14:07:14 -0800 (PST) X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Subject: Re: [PATCH 2.6.11 4/8] tg3: Add msi test Date: Tue, 22 Mar 2005 14:07:13 -0800 Message-ID: Thread-Topic: [PATCH 2.6.11 4/8] tg3: Add msi test Thread-Index: AcUvId9elZovvXdPRk2S+TUl8AMnDgABfxwg From: "Michael Chan" To: "Jeff Garzik" , "David S. Miller" cc: netdev@oss.sgi.com X-WSS-ID: 6E5E48902982398373-01-01 Content-Type: text/plain; charset=us-ascii X-Virus-Scanned: ClamAV 0.83/778/Mon Mar 21 02:48:43 2005 on oss.sgi.com X-Virus-Status: Clean Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by oss.sgi.com id j2MM7WTk011584 X-archive-position: 490 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: mchan@broadcom.com Precedence: bulk X-list: netdev Content-Length: 1146 Lines: 36 "Jeff Garzik" wrote: > Michael Chan wrote: > > Add an MSI test to make sure MSI is working at the system level. If > > the test fails, the driver will go back to INTx mode. > > > > Signed-off-by: Michael Chan > In theory, this patch is not necessary. > > pci_enable_msi() should fail, if MSI is not available at the > system level. > > What behavior are you seeing? > > Jeff > Some older chipsets/APICs in older PCI machines do not properly support MSI. In some cases you will get no interrupts and in a few cases you can get SERR/NMI because the MSI cycle terminates abnormally. The pci_msi_quirk does not cover all problem chipsets out there. pci_enable_msi() can succeed on these problem machines. Most newer PCI Express machines have no problem with MSI, but we have at least one machine in the lab that doesn't work with MSI. The interrupt test code is very small and can conclusively determine if MSI is working on the machine or not. The code can later be used as part of the ethtool self test. Without the test, we'll have to resort of a parameter or a config option to disable MSI in tg3. Michael From jgarzik@pobox.com Tue Mar 22 14:15:13 2005 Received: with ECARTIS (v1.0.0; list netdev); Tue, 22 Mar 2005 14:15:19 -0800 (PST) Received: from parcelfarce.linux.theplanet.co.uk (IDENT:93@parcelfarce.linux.theplanet.co.uk [195.92.249.252]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j2MMFCZm012514 for ; Tue, 22 Mar 2005 14:15:13 -0800 Received: from cpe-069-134-152-124.nc.rr.com ([69.134.152.124] helo=[10.10.10.88]) by parcelfarce.linux.theplanet.co.uk with asmtp (TLSv1:AES256-SHA:256) (Exim 4.33) id 1DDreZ-0002Pv-C3; Tue, 22 Mar 2005 22:15:11 +0000 Message-ID: <424098E2.6090007@pobox.com> Date: Tue, 22 Mar 2005 17:14:58 -0500 From: Jeff Garzik User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.3) Gecko/20040922 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Michael Chan CC: "David S. Miller" , netdev@oss.sgi.com Subject: Re: [PATCH 2.6.11 4/8] tg3: Add msi test References: In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV 0.83/778/Mon Mar 21 02:48:43 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 491 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: jgarzik@pobox.com Precedence: bulk X-list: netdev Content-Length: 1134 Lines: 28 Michael Chan wrote: > Some older chipsets/APICs in older PCI machines do not properly support MSI. > In some cases you will get no interrupts and in a few cases you can get > SERR/NMI because the MSI cycle terminates abnormally. The pci_msi_quirk does > not cover all problem chipsets out there. pci_enable_msi() can succeed on > these problem machines. > > Most newer PCI Express machines have no problem with MSI, but we have at > least one machine in the lab that doesn't work with MSI. > > The interrupt test code is very small and can conclusively determine if MSI > is working on the machine or not. The code can later be used as part of the > ethtool self test. Without the test, we'll have to resort of a parameter or a > config option to disable MSI in tg3. OK, so this is not a tg3-related problem at all. It really sounds like you should update pci_msi_quirk() to cover the other affected cases. I also disagree that a tg3 config option is needed, if the tg3 MSI test is not present. An option to globally disable PCI MSI in the kernel is the preferred approach, if such an option doesn't already exist. Jeff From davem@davemloft.net Tue Mar 22 14:18:47 2005 Received: with ECARTIS (v1.0.0; list netdev); Tue, 22 Mar 2005 14:18:52 -0800 (PST) Received: from cheetah.davemloft.net (mail@dsl027-180-174.sfo1.dsl.speakeasy.net [216.27.180.174]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j2MMIiB8013259 for ; Tue, 22 Mar 2005 14:18:46 -0800 Received: from localhost ([127.0.0.1] helo=cheetah.davemloft.net ident=davem) by cheetah.davemloft.net with smtp (Exim 3.36 #1 (Debian)) id 1DDrgY-0000QB-00; Tue, 22 Mar 2005 14:17:14 -0800 Date: Tue, 22 Mar 2005 14:17:14 -0800 From: "David S. Miller" To: Jeff Garzik Cc: mchan@broadcom.com, netdev@oss.sgi.com Subject: Re: [PATCH 2.6.11 4/8] tg3: Add msi test Message-Id: <20050322141714.4515258f.davem@davemloft.net> In-Reply-To: <424098E2.6090007@pobox.com> References: <424098E2.6090007@pobox.com> X-Mailer: Sylpheed version 1.0.1 (GTK+ 1.2.10; sparc-unknown-linux-gnu) X-Face: "_;p5u5aPsO,_Vsx"^v-pEq09'CU4&Dc1$fQExov$62l60cgCc%FnIwD=.UF^a>?5'9Kn[;433QFVV9M..2eN.@4ZWPGbdi<=?[:T>y?SD(R*-3It"Vj:)"dP Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV 0.83/778/Mon Mar 21 02:48:43 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 492 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: davem@davemloft.net Precedence: bulk X-list: netdev Content-Length: 805 Lines: 24 On Tue, 22 Mar 2005 17:14:58 -0500 Jeff Garzik wrote: > OK, so this is not a tg3-related problem at all. Right. > It really sounds like you should update pci_msi_quirk() to cover the > other affected cases. That's not possible without either: 1) getting a lot of chipset vendors to reveal stuff they probably would rather keep secret (ie. that their chip in particular has MSI problems) 2) having a device on which to perform the MSI usability check See #2? That's the main issue from genericizing this, we need a device on which to perform the usability check so that we can handling a test interrupt and see if state got updated correctly. So for the time being, Michael's change is OK until we find a better solution that really does cover all the problem chipsets. From jgarzik@pobox.com Tue Mar 22 14:27:00 2005 Received: with ECARTIS (v1.0.0; list netdev); Tue, 22 Mar 2005 14:27:04 -0800 (PST) Received: from parcelfarce.linux.theplanet.co.uk (IDENT:93@parcelfarce.linux.theplanet.co.uk [195.92.249.252]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j2MMQx0R014229 for ; Tue, 22 Mar 2005 14:26:59 -0800 Received: from cpe-069-134-152-124.nc.rr.com ([69.134.152.124] helo=[10.10.10.88]) by parcelfarce.linux.theplanet.co.uk with asmtp (TLSv1:AES256-SHA:256) (Exim 4.33) id 1DDrpx-0002aQ-Fi; Tue, 22 Mar 2005 22:26:57 +0000 Message-ID: <42409BA4.3090302@pobox.com> Date: Tue, 22 Mar 2005 17:26:44 -0500 From: Jeff Garzik User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.3) Gecko/20040922 X-Accept-Language: en-us, en MIME-Version: 1.0 To: "David S. Miller" CC: mchan@broadcom.com, netdev@oss.sgi.com Subject: Re: [PATCH 2.6.11 4/8] tg3: Add msi test References: <424098E2.6090007@pobox.com> <20050322141714.4515258f.davem@davemloft.net> In-Reply-To: <20050322141714.4515258f.davem@davemloft.net> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV 0.83/778/Mon Mar 21 02:48:43 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 493 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: jgarzik@pobox.com Precedence: bulk X-list: netdev Content-Length: 1515 Lines: 52 David S. Miller wrote: > On Tue, 22 Mar 2005 17:14:58 -0500 > Jeff Garzik wrote: > > >>OK, so this is not a tg3-related problem at all. > > > Right. > > >>It really sounds like you should update pci_msi_quirk() to cover the >>other affected cases. > > > That's not possible without either: > > 1) getting a lot of chipset vendors to reveal stuff they probably > would rather keep secret (ie. that their chip in particular has > MSI problems) > > 2) having a device on which to perform the MSI usability check > > See #2? That's the main issue from genericizing this, we need > a device on which to perform the usability check so that we can > handling a test interrupt and see if state got updated correctly. > > So for the time being, Michael's change is OK until we find a > better solution that really does cover all the problem chipsets. I disagree: this will hide bugs. We already have a standard process in Linux to handle this stuff: * avoid platform tests in the driver * when the driver fails, have the user try "pci=nomsi" * if that works, add system to blacklist In short, the tg3 driver -without- the MSI test is actually a better MSI test. And as an added bonus, hardware setups with buggy MSI are easily highlighted. MSI is going to hit big, real soon. We don't need this sort of test in ever driver... that will just slow the deployment of a kernel that knows which systems are bad for MSI. Jeff, who just added MSI support to AHCI SATA driver From jgarzik@pobox.com Tue Mar 22 14:46:24 2005 Received: with ECARTIS (v1.0.0; list netdev); Tue, 22 Mar 2005 14:46:29 -0800 (PST) Received: from parcelfarce.linux.theplanet.co.uk (IDENT:93@parcelfarce.linux.theplanet.co.uk [195.92.249.252]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j2MMkNgw016088 for ; Tue, 22 Mar 2005 14:46:24 -0800 Received: from cpe-069-134-152-124.nc.rr.com ([69.134.152.124] helo=[10.10.10.88]) by parcelfarce.linux.theplanet.co.uk with asmtp (TLSv1:AES256-SHA:256) (Exim 4.33) id 1DDs8k-0002pv-IX; Tue, 22 Mar 2005 22:46:22 +0000 Message-ID: <4240A031.9050909@pobox.com> Date: Tue, 22 Mar 2005 17:46:09 -0500 From: Jeff Garzik User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.3) Gecko/20040922 X-Accept-Language: en-us, en MIME-Version: 1.0 To: akpm@osdl.org CC: davem@davemloft.net, netdev@oss.sgi.com Subject: Re: [patch 09/13] bonding needs inet References: <200503152222.j2FMMfU6016817@shell0.pdx.osdl.net> In-Reply-To: <200503152222.j2FMMfU6016817@shell0.pdx.osdl.net> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV 0.83/778/Mon Mar 21 02:48:43 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 494 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: jgarzik@pobox.com Precedence: bulk X-list: netdev Content-Length: 454 Lines: 16 akpm@osdl.org wrote: > The bonding driver needs CONFIG_INET, for arp_create(), arp_send(), arp_xmit(). > > Signed-off-by: Andrew Morton > --- > > 25-akpm/drivers/net/Kconfig | 1 + > 1 files changed, 1 insertion(+) > > diff -puN drivers/net/Kconfig~bonding-needs-inet drivers/net/Kconfig > --- 25/drivers/net/Kconfig~bonding-needs-inet Tue Mar 15 14:19:54 2005 > +++ 25-akpm/drivers/net/Kconfig Tue Mar 15 14:19:54 2005 applied From smcdermott@questra.com Tue Mar 22 14:49:29 2005 Received: with ECARTIS (v1.0.0; list netdev); Tue, 22 Mar 2005 14:49:33 -0800 (PST) Received: from ns2.questra.com (ns2.questra.com [208.2.147.3]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j2MMnS16016786 for ; Tue, 22 Mar 2005 14:49:28 -0800 Received: from animus.roc.questra.com (gopher.roc.questra.com [208.2.147.49]) by ns2.questra.com (Questra-MTA) with ESMTP id 2A041C93B for ; Tue, 22 Mar 2005 17:48:26 -0500 (EST) Received: by animus.roc.questra.com (Questra-MTA, from userid 99) id C54F52B667; Tue, 22 Mar 2005 17:48:27 -0500 (EST) Received: from animus.roc.questra.com (localhost.localdomain [127.0.0.1]) by animus.roc.questra.com (Questra-MTA) with SMTP id B39362B665 for ; Tue, 22 Mar 2005 17:48:24 -0500 (EST) Received: from animus.roc.questra.com ([127.0.0.1]) by animus.roc.questra.com ([10.20.8.33]) with SMTP (gateway) id A0671CCAD8A; Tue, 22 Mar 2005 17:48:23 -0500 Received: from diabolus2.rwc.questra.com (diabolus2.rwc.questra.com [10.30.4.25]) by animus.roc.questra.com (Questra-MTA) with ESMTP id A71652B666 for ; Tue, 22 Mar 2005 17:48:23 -0500 (EST) Received: from rovina.ddns.rwc.questra.com (rovina.ddns.rwc.questra.com [10.30.6.248]) by diabolus2.rwc.questra.com (Questra-MTA) with ESMTP id 0F15230003 for ; Tue, 22 Mar 2005 14:48:21 -0800 (PST) Received: by rovina.ddns.rwc.questra.com (Postfix, from userid 500) id 97E811C0F8; Tue, 22 Mar 2005 14:48:21 -0800 (PST) Date: Tue, 22 Mar 2005 14:48:21 -0800 From: Scott Mcdermott To: netdev@oss.sgi.com Subject: Re: [IPSEC] Too many SADs! Message-ID: <20050322224819.GB4924@questra.com> Mail-Followup-To: netdev@oss.sgi.com References: <200503220052.52756.wolfgang.walter@studentenwerk.mhn.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200503220052.52756.wolfgang.walter@studentenwerk.mhn.de> User-Agent: Mutt/1.4.1i X-Virus-Scanned: ClamAV 0.83/778/Mon Mar 21 02:48:43 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 495 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: smcdermott@questra.com Precedence: bulk X-list: netdev Content-Length: 906 Lines: 24 Wolfgang Walter on Tue 22/03 00:52 +0100: > We had the same problem. Seems to be a limitation of the > pfkey-implementation of linux. > > racoon and setkey both use the pfkey-interface. > > We switched to iproute2 and openswan which both use the > netfilter-interface. Therefor they can handle thousands > of SAD and SPD rules. What, openswan uses PF_KEY last I checked on kernel 2.6. I guess you can use KLIPS, but why would you? What's this "netfilter-interface" to ipsec code? I had the exact same problem the original poster had with Racoon. SPDs would multiply without bounds, seemingly geometrically. I switched to strongswan and the problems immediately vanished. There is some bug in racoon where it doesn't replace SPDs. I used the latest ipsec-utils and kernel and this problem did not go away until I switched instead to strongswan (still using PF_KEY) (it also worked with openswan). From jgarzik@pobox.com Tue Mar 22 14:49:49 2005 Received: with ECARTIS (v1.0.0; list netdev); Tue, 22 Mar 2005 14:49:56 -0800 (PST) Received: from parcelfarce.linux.theplanet.co.uk (IDENT:93@parcelfarce.linux.theplanet.co.uk [195.92.249.252]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j2MMnm9R016924 for ; Tue, 22 Mar 2005 14:49:49 -0800 Received: from cpe-069-134-152-124.nc.rr.com ([69.134.152.124] helo=[10.10.10.88]) by parcelfarce.linux.theplanet.co.uk with asmtp (TLSv1:AES256-SHA:256) (Exim 4.33) id 1DDsBz-0002th-BE; Tue, 22 Mar 2005 22:49:44 +0000 Message-ID: <4240A0FA.90807@pobox.com> Date: Tue, 22 Mar 2005 17:49:30 -0500 From: Jeff Garzik User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.3) Gecko/20040922 X-Accept-Language: en-us, en MIME-Version: 1.0 To: akpm@osdl.org, domen@coderock.org CC: davem@davemloft.net, netdev@oss.sgi.com Subject: Re: [patch 03/13] drivers/net/myri_code.h cleanup References: <200503152222.j2FMMZ1i016799@shell0.pdx.osdl.net> In-Reply-To: <200503152222.j2FMMZ1i016799@shell0.pdx.osdl.net> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV 0.83/778/Mon Mar 21 02:48:43 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 496 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: jgarzik@pobox.com Precedence: bulk X-list: netdev Content-Length: 324 Lines: 19 akpm@osdl.org wrote: > From: Domen Puncer > > Replace > > static unsigned char lanai4_data[20472] __initdata = { > > } > > with > > static unsigned char lanai4_data[20472] __initdata = { }; Proper change: Don't bother with an initializer at all. it's static. Jeff From jgarzik@pobox.com Tue Mar 22 14:57:58 2005 Received: with ECARTIS (v1.0.0; list netdev); Tue, 22 Mar 2005 14:58:05 -0800 (PST) Received: from parcelfarce.linux.theplanet.co.uk (IDENT:93@parcelfarce.linux.theplanet.co.uk [195.92.249.252]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j2MMvvA6018254 for ; Tue, 22 Mar 2005 14:57:58 -0800 Received: from cpe-069-134-152-124.nc.rr.com ([69.134.152.124] helo=[10.10.10.88]) by parcelfarce.linux.theplanet.co.uk with asmtp (TLSv1:AES256-SHA:256) (Exim 4.33) id 1DDsJw-00030R-Es; Tue, 22 Mar 2005 22:57:56 +0000 Message-ID: <4240A2E7.50308@pobox.com> Date: Tue, 22 Mar 2005 17:57:43 -0500 From: Jeff Garzik User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.3) Gecko/20040922 X-Accept-Language: en-us, en MIME-Version: 1.0 To: jt@hpl.hp.com CC: Jouni Malinen , netdev@oss.sgi.com, Linux kernel mailing list Subject: Re: [PATCH 2.6.11] WE-18 (aka WPA) References: <20050314201932.GA1467@bougret.hpl.hp.com> In-Reply-To: <20050314201932.GA1467@bougret.hpl.hp.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV 0.83/778/Mon Mar 21 02:48:43 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 497 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: jgarzik@pobox.com Precedence: bulk X-list: netdev Content-Length: 1215 Lines: 30 Jean Tourrilhes wrote: > Hi Jeff, > > This is version 18 of the Wireless Extensions. The main change > is that it adds all the necessary APIs for WPA and WPA2 support. This > work was entirely done by Jouni Malinen, so let's thank him for both > his hard work and deep expertise on the subject ;-) > This APIs obviously doesn't do much by itself and works in > concert with driver support (Jouni already sent you the HostAP > changes) and userspace (Jouni is updating wpa_supplicant). This is > also orthogonal with the ongoing work on in-kernel IEEE support (but > potentially useful). > The patch is attached, tested with 2.6.11. Normally, I would > ask you to push that directly in the kernel (99% of the patch has been > on my web page for ages and it does not affect non-WPA stuff), but > Jouni convinced me that it should bake a few weeks in wireless-2.6 > first, so that other driver maintainers can get up to speed with it. > > So, would you mind pushing that in wireless-2.6 ? > Thanks in advance... Applied to wireless-2.6, and will soon push upstream. NOTE: Please include a Signed-off-by line in ALL patches that you submit. See http://linux.yyz.us/patch-format.html for more info. Jeff From jgarzik@pobox.com Tue Mar 22 15:11:15 2005 Received: with ECARTIS (v1.0.0; list netdev); Tue, 22 Mar 2005 15:11:19 -0800 (PST) Received: from parcelfarce.linux.theplanet.co.uk (IDENT:93@parcelfarce.linux.theplanet.co.uk [195.92.249.252]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j2MNBEXb019399 for ; Tue, 22 Mar 2005 15:11:14 -0800 Received: from cpe-069-134-152-124.nc.rr.com ([69.134.152.124] helo=[10.10.10.88]) by parcelfarce.linux.theplanet.co.uk with asmtp (TLSv1:AES256-SHA:256) (Exim 4.33) id 1DDsWn-0003Ak-6I; Tue, 22 Mar 2005 23:11:13 +0000 Message-ID: <4240A604.60900@pobox.com> Date: Tue, 22 Mar 2005 18:11:00 -0500 From: Jeff Garzik User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.3) Gecko/20040922 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Jouni Malinen CC: netdev@oss.sgi.com Subject: Re: [PATCH wireless-2.6 10/10] hostap: Update to use the new WE18 proposal References: <20050313001706.GA8253@jm.kir.nu> <20050313004130.GK8253@jm.kir.nu> In-Reply-To: <20050313004130.GK8253@jm.kir.nu> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV 0.83/778/Mon Mar 21 02:48:43 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 498 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: jgarzik@pobox.com Precedence: bulk X-list: netdev Content-Length: 74 Lines: 2 applied all 10 patches to wireless-2.6 (after applying WE18 from JeanT). From jgarzik@pobox.com Tue Mar 22 15:12:08 2005 Received: with ECARTIS (v1.0.0; list netdev); Tue, 22 Mar 2005 15:12:15 -0800 (PST) Received: from parcelfarce.linux.theplanet.co.uk (IDENT:93@parcelfarce.linux.theplanet.co.uk [195.92.249.252]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j2MNC8qq019767 for ; Tue, 22 Mar 2005 15:12:08 -0800 Received: from cpe-069-134-152-124.nc.rr.com ([69.134.152.124] helo=[10.10.10.88]) by parcelfarce.linux.theplanet.co.uk with asmtp (TLSv1:AES256-SHA:256) (Exim 4.33) id 1DDsXd-0003B6-R4; Tue, 22 Mar 2005 23:12:06 +0000 Message-ID: <4240A638.8090702@pobox.com> Date: Tue, 22 Mar 2005 18:11:52 -0500 From: Jeff Garzik User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.3) Gecko/20040922 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Jouni Malinen CC: netdev@oss.sgi.com Subject: Re: [PATCH wireless-2.6 7/10] hostap: Rate limiting for debug messages References: <20050313001706.GA8253@jm.kir.nu> <20050313003412.GH8253@jm.kir.nu> In-Reply-To: <20050313003412.GH8253@jm.kir.nu> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV 0.83/778/Mon Mar 21 02:48:43 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 499 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: jgarzik@pobox.com Precedence: bulk X-list: netdev Content-Length: 1083 Lines: 31 Jouni Malinen wrote: > Limit rate of debug messages for interrupts before card is ready. This > could happen when multiple devices are sharing the same interrupt. > > Signed-off-by: Jouni Malinen > > Index: jm-wireless-2.6/drivers/net/wireless/hostap/hostap_hw.c > =================================================================== > --- jm-wireless-2.6.orig/drivers/net/wireless/hostap/hostap_hw.c 2005-03-12 16:10:40.000000000 -0800 > +++ jm-wireless-2.6/drivers/net/wireless/hostap/hostap_hw.c 2005-03-12 16:10:58.000000000 -0800 > @@ -2790,8 +2790,10 @@ > prism2_io_debug_add(dev, PRISM2_IO_DEBUG_CMD_INTERRUPT, 0, 0); > > if (local->func->card_present && !local->func->card_present(local)) { > - printk(KERN_DEBUG "%s: Interrupt, but dev not OK\n", > - dev->name); > + if (net_ratelimit()) { > + printk(KERN_DEBUG "%s: Interrupt, but dev not OK\n", > + dev->name); > + } > return IRQ_HANDLED; Patch is OK, but it highlights a bug: You should return IRQ_NONE if the interrupt is not intended for your hardware. Jeff From jgarzik@pobox.com Tue Mar 22 15:13:49 2005 Received: with ECARTIS (v1.0.0; list netdev); Tue, 22 Mar 2005 15:13:53 -0800 (PST) Received: from parcelfarce.linux.theplanet.co.uk (IDENT:93@parcelfarce.linux.theplanet.co.uk [195.92.249.252]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j2MNDnXk020589 for ; Tue, 22 Mar 2005 15:13:49 -0800 Received: from cpe-069-134-152-124.nc.rr.com ([69.134.152.124] helo=[10.10.10.88]) by parcelfarce.linux.theplanet.co.uk with asmtp (TLSv1:AES256-SHA:256) (Exim 4.33) id 1DDsZI-0003Da-2i; Tue, 22 Mar 2005 23:13:48 +0000 Message-ID: <4240A6A0.8090509@pobox.com> Date: Tue, 22 Mar 2005 18:13:36 -0500 From: Jeff Garzik User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.3) Gecko/20040922 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Jouni Malinen CC: netdev@oss.sgi.com Subject: Re: [PATCH wireless-2.6 2/10] hostap: Include asm/io.h References: <20050313001706.GA8253@jm.kir.nu> <20050313002940.GC8253@jm.kir.nu> In-Reply-To: <20050313002940.GC8253@jm.kir.nu> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV 0.83/778/Mon Mar 21 02:48:43 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 500 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: jgarzik@pobox.com Precedence: bulk X-list: netdev Content-Length: 464 Lines: 17 Jouni Malinen wrote: > Include asm/io.h into hostap_{pci,plx}.c since this seems to be needed > for ARM on Linux 2.6.x and this file is already included into > hostap_cs.c anyway. > > Signed-off-by: Jouni Malinen Patch is correct, but description is incorrect: asm/io.h is a required include for any driver that uses the bus IO functions {in,out,read,write}[bwlq]. It's not just ARM, but instead is required for all platforms. Jeff From dale@farnsworth.org Tue Mar 22 15:15:11 2005 Received: with ECARTIS (v1.0.0; list netdev); Tue, 22 Mar 2005 15:15:17 -0800 (PST) Received: from xyzzy.farnsworth.org (qmailr@h142-az.mvista.com [65.200.49.142] (may be forged)) by oss.sgi.com (8.13.0/8.13.0) with SMTP id j2MNFA8w021160 for ; Tue, 22 Mar 2005 15:15:11 -0800 Received: (qmail 27736 invoked by uid 1000); 22 Mar 2005 23:15:08 -0000 From: "Dale Farnsworth" Date: Tue, 22 Mar 2005 16:15:08 -0700 To: Netdev , Jeff Garzik Cc: James Chapman Subject: [PATCH: 2.6.12-rc1] mii: GigE support bug fixes Message-ID: <20050322231508.GA27373@xyzzy> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.5.6+20040907i X-Virus-Scanned: ClamAV 0.83/778/Mon Mar 21 02:48:43 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 501 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: dale@farnsworth.org Precedence: bulk X-list: netdev Content-Length: 1455 Lines: 40 This patch fixes a couple bugs in mii.c GigE support. Signed-off-by: Dale Farnsworth Acked-by: James Chapman Index: linux-2.5-enet/drivers/net/mii.c =================================================================== --- linux-2.5-enet.orig/drivers/net/mii.c +++ linux-2.5-enet/drivers/net/mii.c @@ -43,6 +43,9 @@ (SUPPORTED_10baseT_Half | SUPPORTED_10baseT_Full | SUPPORTED_100baseT_Half | SUPPORTED_100baseT_Full | SUPPORTED_Autoneg | SUPPORTED_TP | SUPPORTED_MII); + if (mii->supports_gmii) + ecmd->supported |= SUPPORTED_1000baseT_Half | + SUPPORTED_1000baseT_Full; /* only supports twisted-pair */ ecmd->port = PORT_MII; @@ -100,7 +103,7 @@ } else { ecmd->autoneg = AUTONEG_DISABLE; - ecmd->speed = ((bmcr2 & BMCR_SPEED1000 && + ecmd->speed = ((bmcr & BMCR_SPEED1000 && (bmcr & BMCR_SPEED100) == 0) ? SPEED_1000 : (bmcr & BMCR_SPEED100) ? SPEED_100 : SPEED_10); ecmd->duplex = (bmcr & BMCR_FULLDPLX) ? DUPLEX_FULL : DUPLEX_HALF; @@ -163,9 +166,9 @@ tmp |= ADVERTISE_100FULL; if (mii->supports_gmii) { if (ecmd->advertising & ADVERTISED_1000baseT_Half) - advert2 |= ADVERTISE_1000HALF; + tmp2 |= ADVERTISE_1000HALF; if (ecmd->advertising & ADVERTISED_1000baseT_Full) - advert2 |= ADVERTISE_1000FULL; + tmp2 |= ADVERTISE_1000FULL; } if (advert != tmp) { mii->mdio_write(dev, mii->phy_id, MII_ADVERTISE, tmp); From dale@farnsworth.org Tue Mar 22 15:17:47 2005 Received: with ECARTIS (v1.0.0; list netdev); Tue, 22 Mar 2005 15:17:52 -0800 (PST) Received: from xyzzy.farnsworth.org (qmailr@h142-az.mvista.com [65.200.49.142] (may be forged)) by oss.sgi.com (8.13.0/8.13.0) with SMTP id j2MNHlxQ021802 for ; Tue, 22 Mar 2005 15:17:47 -0800 Received: (qmail 27823 invoked by uid 1000); 22 Mar 2005 23:17:46 -0000 From: "Dale Farnsworth" Date: Tue, 22 Mar 2005 16:17:46 -0700 To: Netdev , Jeff Garzik Cc: James Chapman Subject: [PATCH: 2.6.12-rc1] mii: Add test for GigE support Message-ID: <20050322231746.GA27770@xyzzy> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.5.6+20040907i X-Virus-Scanned: ClamAV 0.83/778/Mon Mar 21 02:48:43 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 502 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: dale@farnsworth.org Precedence: bulk X-list: netdev Content-Length: 3130 Lines: 73 This patch adds the ability to test a PHY for GigE support Signed-off-by: Dale Farnsworth Index: linux-2.5-enet/drivers/net/mii.c =================================================================== --- linux-2.5-enet.orig/drivers/net/mii.c +++ linux-2.5-enet/drivers/net/mii.c @@ -207,6 +207,21 @@ return 0; } +int mii_check_gmii_support(struct mii_if_info *mii) +{ + int reg; + + reg = mii->mdio_read(mii->dev, mii->phy_id, MII_BMSR); + if (reg & BMSR_HAS_EXTSTAT1000) { + reg = mii->mdio_read(mii->dev, mii->phy_id, MII_EXTSTAT1000); + if (reg & (ESR_1000_BASE_X_FD | ESR_1000_BASE_T_FD | + ESR_1000_BASE_X_HD | ESR_1000_BASE_T_HD)) + return 1; + } + + return 0; +} + int mii_link_ok (struct mii_if_info *mii) { /* first, a dummy read, needed to latch some MII phys */ Index: linux-2.5-enet/include/linux/mii.h =================================================================== --- linux-2.5-enet.orig/include/linux/mii.h +++ linux-2.5-enet/include/linux/mii.h @@ -22,6 +22,7 @@ #define MII_EXPANSION 0x06 /* Expansion register */ #define MII_CTRL1000 0x09 /* 1000BASE-T control */ #define MII_STAT1000 0x0a /* 1000BASE-T status */ +#define MII_EXTSTAT1000 0x0f /* 1000BASE-XX extended status */ #define MII_DCOUNTER 0x12 /* Disconnect counter */ #define MII_FCSCOUNTER 0x13 /* False carrier counter */ #define MII_NWAYTEST 0x14 /* N-way auto-neg test reg */ @@ -54,7 +55,8 @@ #define BMSR_ANEGCAPABLE 0x0008 /* Able to do auto-negotiation */ #define BMSR_RFAULT 0x0010 /* Remote fault detected */ #define BMSR_ANEGCOMPLETE 0x0020 /* Auto-negotiation complete */ -#define BMSR_RESV 0x07c0 /* Unused... */ +#define BMSR_HAS_EXTSTAT1000 0x0100 /* Has 1000BASE extended status*/ +#define BMSR_RESV 0x06c0 /* Unused... */ #define BMSR_10HALF 0x0800 /* Can do 10mbps, half-duplex */ #define BMSR_10FULL 0x1000 /* Can do 10mbps, full-duplex */ #define BMSR_100HALF 0x2000 /* Can do 100mbps, half-duplex */ @@ -121,6 +123,12 @@ #define LPA_1000FULL 0x0800 /* Link partner 1000BASE-T full duplex */ #define LPA_1000HALF 0x0400 /* Link partner 1000BASE-T half duplex */ +/* 1000BASE Ext Status register */ +#define ESR_1000_BASE_X_FD 0x8000 +#define ESR_1000_BASE_X_HD 0x4000 +#define ESR_1000_BASE_T_FD 0x2000 +#define ESR_1000_BASE_T_HD 0x1000 + struct mii_if_info { int phy_id; int advertising; @@ -143,6 +151,7 @@ extern int mii_nway_restart (struct mii_if_info *mii); extern int mii_ethtool_gset(struct mii_if_info *mii, struct ethtool_cmd *ecmd); extern int mii_ethtool_sset(struct mii_if_info *mii, struct ethtool_cmd *ecmd); +extern int mii_check_gmii_support(struct mii_if_info *mii); extern void mii_check_link (struct mii_if_info *mii); extern unsigned int mii_check_media (struct mii_if_info *mii, unsigned int ok_to_print, From jgarzik@pobox.com Tue Mar 22 15:21:12 2005 Received: with ECARTIS (v1.0.0; list netdev); Tue, 22 Mar 2005 15:21:16 -0800 (PST) Received: from parcelfarce.linux.theplanet.co.uk (IDENT:93@parcelfarce.linux.theplanet.co.uk [195.92.249.252]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j2MNLBZH022489 for ; Tue, 22 Mar 2005 15:21:11 -0800 Received: from cpe-069-134-152-124.nc.rr.com ([69.134.152.124] helo=[10.10.10.88]) by parcelfarce.linux.theplanet.co.uk with asmtp (TLSv1:AES256-SHA:256) (Exim 4.33) id 1DDsgP-0003If-JO; Tue, 22 Mar 2005 23:21:09 +0000 Message-ID: <4240A858.2040800@pobox.com> Date: Tue, 22 Mar 2005 18:20:56 -0500 From: Jeff Garzik User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.3) Gecko/20040922 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Francois Romieu CC: netdev@oss.sgi.com, Jon Mason , Stephen Hemminger , mark@kiora.ath.cx Subject: Re: [patch linux-2.6.11-bk10 1/1] r8169: incoming frame length check References: <20050314233103.GC16072@electric-eye.fr.zoreil.com> In-Reply-To: <20050314233103.GC16072@electric-eye.fr.zoreil.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV 0.83/778/Mon Mar 21 02:48:43 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 503 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: jgarzik@pobox.com Precedence: bulk X-list: netdev Content-Length: 45 Lines: 2 applied, let me know when to send upstream. From jgarzik@pobox.com Tue Mar 22 15:26:22 2005 Received: with ECARTIS (v1.0.0; list netdev); Tue, 22 Mar 2005 15:26:26 -0800 (PST) Received: from parcelfarce.linux.theplanet.co.uk (IDENT:93@parcelfarce.linux.theplanet.co.uk [195.92.249.252]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j2MNQLJM023211 for ; Tue, 22 Mar 2005 15:26:22 -0800 Received: from cpe-069-134-152-124.nc.rr.com ([69.134.152.124] helo=[10.10.10.88]) by parcelfarce.linux.theplanet.co.uk with asmtp (TLSv1:AES256-SHA:256) (Exim 4.33) id 1DDslQ-0003R5-Jj; Tue, 22 Mar 2005 23:26:20 +0000 Message-ID: <4240A990.6070209@pobox.com> Date: Tue, 22 Mar 2005 18:26:08 -0500 From: Jeff Garzik User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.3) Gecko/20040922 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Dale Farnsworth CC: Netdev , James Chapman Subject: Re: [PATCH: 2.6.12-rc1] mii: GigE support bug fixes References: <20050322231508.GA27373@xyzzy> In-Reply-To: <20050322231508.GA27373@xyzzy> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV 0.83/778/Mon Mar 21 02:48:43 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 504 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: jgarzik@pobox.com Precedence: bulk X-list: netdev Content-Length: 346 Lines: 12 Dale Farnsworth wrote: > This patch fixes a couple bugs in mii.c GigE support. > > Signed-off-by: Dale Farnsworth > Acked-by: James Chapman Applied, but a small nit: Don't bother including a patch description in the body of the email, if it simply re-states the Subject and nothing more. Jeff From jgarzik@pobox.com Tue Mar 22 15:28:01 2005 Received: with ECARTIS (v1.0.0; list netdev); Tue, 22 Mar 2005 15:28:06 -0800 (PST) Received: from parcelfarce.linux.theplanet.co.uk (IDENT:93@parcelfarce.linux.theplanet.co.uk [195.92.249.252]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j2MNS0KA023797 for ; Tue, 22 Mar 2005 15:28:00 -0800 Received: from cpe-069-134-152-124.nc.rr.com ([69.134.152.124] helo=[10.10.10.88]) by parcelfarce.linux.theplanet.co.uk with asmtp (TLSv1:AES256-SHA:256) (Exim 4.33) id 1DDsn1-0003Sn-Mj; Tue, 22 Mar 2005 23:27:59 +0000 Message-ID: <4240A9F3.5040704@pobox.com> Date: Tue, 22 Mar 2005 18:27:47 -0500 From: Jeff Garzik User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.3) Gecko/20040922 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Dale Farnsworth CC: Netdev , James Chapman Subject: Re: [PATCH: 2.6.12-rc1] mii: Add test for GigE support References: <20050322231746.GA27770@xyzzy> In-Reply-To: <20050322231746.GA27770@xyzzy> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV 0.83/778/Mon Mar 21 02:48:43 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 505 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: jgarzik@pobox.com Precedence: bulk X-list: netdev Content-Length: 1012 Lines: 38 Dale Farnsworth wrote: > This patch adds the ability to test a PHY for GigE support > > Signed-off-by: Dale Farnsworth > > Index: linux-2.5-enet/drivers/net/mii.c > =================================================================== > --- linux-2.5-enet.orig/drivers/net/mii.c > +++ linux-2.5-enet/drivers/net/mii.c > @@ -207,6 +207,21 @@ > return 0; > } > > +int mii_check_gmii_support(struct mii_if_info *mii) > +{ > + int reg; > + > + reg = mii->mdio_read(mii->dev, mii->phy_id, MII_BMSR); > + if (reg & BMSR_HAS_EXTSTAT1000) { > + reg = mii->mdio_read(mii->dev, mii->phy_id, MII_EXTSTAT1000); > + if (reg & (ESR_1000_BASE_X_FD | ESR_1000_BASE_T_FD | > + ESR_1000_BASE_X_HD | ESR_1000_BASE_T_HD)) > + return 1; > + } > + > + return 0; Two comments: 1) you need to add EXPORT_SYMBOL() when adding new API functions (see the bottom of the file). 2) Reading a non-existent register will return all 1's in most cases, so I am not sure if this is the best test. Jeff From alex@neterion.com Tue Mar 22 15:31:37 2005 Received: with ECARTIS (v1.0.0; list netdev); Tue, 22 Mar 2005 15:31:42 -0800 (PST) Received: from ns1.s2io.com (ns1.s2io.com [142.46.200.198]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j2MNVafE024484 for ; Tue, 22 Mar 2005 15:31:37 -0800 Received: from guinness.s2io.com (sentry.s2io.com [142.46.200.199]) by ns1.s2io.com (8.12.10/8.12.10) with ESMTP id j2MNUJuN013401; Tue, 22 Mar 2005 18:30:19 -0500 (EST) Received: from aaizmanlt ([10.16.16.78]) by guinness.s2io.com (8.12.6/8.12.6) with ESMTP id j2MNU2DD028953; Tue, 22 Mar 2005 18:30:08 -0500 (EST) Message-Id: <200503222330.j2MNU2DD028953@guinness.s2io.com> Reply-To: From: "Alex Aizman" To: Cc: , , Subject: [ANNOUNCE] Experimental Driver for Neterion/S2io 10GbE Adapters Date: Tue, 22 Mar 2005 15:29:34 -0800 Organization: neterion MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook, Build 11.0.5510 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 Thread-Index: AcUvNwC+suihXPTSQNuF1VHAkbUKyg== X-Scanned-By: MIMEDefang 2.34 X-Virus-Scanned: ClamAV 0.83/778/Mon Mar 21 02:48:43 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 506 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: alex@neterion.com Precedence: bulk X-list: netdev Content-Length: 872 Lines: 24 This is our 2nd attempt to submit "xge", the experimental driver for Neterion, Inc (formerly S2io, Inc) family of 10GbE adapters. The "first attempt", along with the still relevant description of features and motivations, can be looked up at http://oss.sgi.com/archives/netdev/2005-03/msg00854.html. Note that the xge driver supports the new 10GbE PCI-X 266MHz adapter. Changes ====== Removed HAL layering, worked on the coding style to make it compliant with the kernel style, re-organized the code to accommodate community feedback. Download ====== A single gzipped patch (filename xge-v.1.1.2870-2.6.11.patch.gz, cksum 2732698831) can be downloaded from: ftp://linuxsrc:opensource@ns1.s2io.com Signed-off-by: Dmitry Yusupov Signed-off-by: Raghavendra Koushik Signed-off-by: Alex Aizman From davem@davemloft.net Tue Mar 22 15:42:05 2005 Received: with ECARTIS (v1.0.0; list netdev); Tue, 22 Mar 2005 15:42:10 -0800 (PST) Received: from cheetah.davemloft.net (mail@dsl027-180-174.sfo1.dsl.speakeasy.net [216.27.180.174]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j2MNg4Vq025681 for ; Tue, 22 Mar 2005 15:42:04 -0800 Received: from localhost ([127.0.0.1] helo=cheetah.davemloft.net ident=davem) by cheetah.davemloft.net with smtp (Exim 3.36 #1 (Debian)) id 1DDsz8-0000ui-00; Tue, 22 Mar 2005 15:40:30 -0800 Date: Tue, 22 Mar 2005 15:40:30 -0800 From: "David S. Miller" To: Jeff Garzik Cc: mchan@broadcom.com, netdev@oss.sgi.com Subject: Re: [PATCH 2.6.11 4/8] tg3: Add msi test Message-Id: <20050322154030.310e85c1.davem@davemloft.net> In-Reply-To: <42409BA4.3090302@pobox.com> References: <424098E2.6090007@pobox.com> <20050322141714.4515258f.davem@davemloft.net> <42409BA4.3090302@pobox.com> X-Mailer: Sylpheed version 1.0.1 (GTK+ 1.2.10; sparc-unknown-linux-gnu) X-Face: "_;p5u5aPsO,_Vsx"^v-pEq09'CU4&Dc1$fQExov$62l60cgCc%FnIwD=.UF^a>?5'9Kn[;433QFVV9M..2eN.@4ZWPGbdi<=?[:T>y?SD(R*-3It"Vj:)"dP Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV 0.83/778/Mon Mar 21 02:48:43 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 507 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: davem@davemloft.net Precedence: bulk X-list: netdev Content-Length: 994 Lines: 29 On Tue, 22 Mar 2005 17:26:44 -0500 Jeff Garzik wrote: > I disagree: this will hide bugs. It actually spots them too. :-) If you'd like it to print out something like: TG3 MSI test failed on chipset ven[%x] devid[%x] please email this info to PCI maintainers at x@y.com that's fine. > We already have a standard process in Linux to handle this stuff: > > * avoid platform tests in the driver > * when the driver fails, have the user try "pci=nomsi" > * if that works, add system to blacklist Just because it's what we've been doing doesn't mean it's the best solution in this case. If you hope users will just report this stuff, most of them won't. They'll say Linux doesn't work on my computer and I have real life stuff to take care of so I'll install freebsd or windows or a different networking card and get on with life. Eventually, say over a year or so, the database of bad chipsets will get built with your scheme, but to much hardship and pain to users. From jgarzik@pobox.com Tue Mar 22 15:45:43 2005 Received: with ECARTIS (v1.0.0; list netdev); Tue, 22 Mar 2005 15:45:48 -0800 (PST) Received: from parcelfarce.linux.theplanet.co.uk (IDENT:93@parcelfarce.linux.theplanet.co.uk [195.92.249.252]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j2MNjfxW026409 for ; Tue, 22 Mar 2005 15:45:43 -0800 Received: from cpe-069-134-152-124.nc.rr.com ([69.134.152.124] helo=[10.10.10.88]) by parcelfarce.linux.theplanet.co.uk with asmtp (TLSv1:AES256-SHA:256) (Exim 4.33) id 1DDt47-0003gT-WD; Tue, 22 Mar 2005 23:45:40 +0000 Message-ID: <4240AE17.2030706@pobox.com> Date: Tue, 22 Mar 2005 18:45:27 -0500 From: Jeff Garzik User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.3) Gecko/20040922 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Jesse Brandeburg CC: netdev@oss.sgi.com Subject: Re: [PATCH ethtool-3] add ixgb dump register support References: In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV 0.83/778/Mon Mar 21 02:48:43 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 508 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: jgarzik@pobox.com Precedence: bulk X-list: netdev Content-Length: 1548 Lines: 48 Jesse Brandeburg wrote: > I didn't to a push to gkernel bitkeeper because I've never done that > before, Jeff if you want that, I can try it. > > This is off a bitkeeper clone from yesterday. > > Apologies if I screwed up something with bitkeeper, as I'm just figuring > it all out but want to learn! Sorry for taking so long to get to this. Applied your patch just fine, you did everything right. If you wish to submit via BitKeeper, the model (for ethtool, the kernel, whatever) is as follows: 1) Clone your own repository (usually at bkbits.net). Let's call it jesse.bkbits.net/ethtool. 2) Check in changes to a local (on your workstation) clone of ethtool. 3) 'bk push" to jesse.bkbits.net/ethtool 4) Use Docuementation/BK-usage/bk-make-sum script in kernel tree to create a summary of your changes: cd /work/repo/ethtool-jesse bk-make-sum ../ethtool-vanilla mv /tmp/linus.txt my-submission.txt gcapatch >> my-submission.txt NOTE: gcapatch (also in BK-usage subdir) must be modified slightly, to change an embedded URL, before it can be used with ethtool. 5) Email my-submission.txt to jgarzik@pobox.com and netdev@oss.sgi.com. 6) I receive the email, and do a 'bk pull bk://jesse.bkbits.net/ethtool' to incorporate your changes into my local tree. 7) I do a 'bk push' to push the changes into bk://gkernel.bkbits.net/ethtool So as you can see, given BitKeeper's highly distributed model, there is no concept of "a bunch of people have permission to push to the tree." It's a pull model, not a push model. Jeff From jgarzik@pobox.com Tue Mar 22 15:50:50 2005 Received: with ECARTIS (v1.0.0; list netdev); Tue, 22 Mar 2005 15:50:54 -0800 (PST) Received: from parcelfarce.linux.theplanet.co.uk (IDENT:93@parcelfarce.linux.theplanet.co.uk [195.92.249.252]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j2MNonGK027165 for ; Tue, 22 Mar 2005 15:50:50 -0800 Received: from cpe-069-134-152-124.nc.rr.com ([69.134.152.124] helo=[10.10.10.88]) by parcelfarce.linux.theplanet.co.uk with asmtp (TLSv1:AES256-SHA:256) (Exim 4.33) id 1DDt95-0003kS-Vi; Tue, 22 Mar 2005 23:50:48 +0000 Message-ID: <4240AF4C.9030109@pobox.com> Date: Tue, 22 Mar 2005 18:50:36 -0500 From: Jeff Garzik User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.3) Gecko/20040922 X-Accept-Language: en-us, en MIME-Version: 1.0 To: "David S. Miller" CC: mchan@broadcom.com, netdev@oss.sgi.com Subject: Re: [PATCH 2.6.11 4/8] tg3: Add msi test References: <424098E2.6090007@pobox.com> <20050322141714.4515258f.davem@davemloft.net> <42409BA4.3090302@pobox.com> <20050322154030.310e85c1.davem@davemloft.net> In-Reply-To: <20050322154030.310e85c1.davem@davemloft.net> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV 0.83/778/Mon Mar 21 02:48:43 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 509 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: jgarzik@pobox.com Precedence: bulk X-list: netdev Content-Length: 953 Lines: 28 David S. Miller wrote: > Just because it's what we've been doing doesn't mean it's the > best solution in this case. > > If you hope users will just report this stuff, most of them won't. > They'll say Linux doesn't work on my computer and I have real life > stuff to take care of so I'll install freebsd or windows or a different > networking card and get on with life. > > Eventually, say over a year or so, the database of bad chipsets will > get built with your scheme, but to much hardship and pain to users. What do you think will happen for all the other MSI drivers/hardware out there? Adding this test to tg3 simply means another piece of hardware doesn't work. The problem disappears for -you-, but not the user. You're just pushing the pain around, for the -few- -early- systems with problems. Sorry, I still disagree. We need to think about how to handle this situation for -all- drivers and -all- users, not just tg3. Jeff From davem@davemloft.net Tue Mar 22 15:54:12 2005 Received: with ECARTIS (v1.0.0; list netdev); Tue, 22 Mar 2005 15:54:16 -0800 (PST) Received: from cheetah.davemloft.net (mail@dsl027-180-174.sfo1.dsl.speakeasy.net [216.27.180.174]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j2MNs8uU027825 for ; Tue, 22 Mar 2005 15:54:12 -0800 Received: from localhost ([127.0.0.1] helo=cheetah.davemloft.net ident=davem) by cheetah.davemloft.net with smtp (Exim 3.36 #1 (Debian)) id 1DDtAp-0000xH-00; Tue, 22 Mar 2005 15:52:35 -0800 Date: Tue, 22 Mar 2005 15:52:35 -0800 From: "David S. Miller" To: Jeff Garzik Cc: mchan@broadcom.com, netdev@oss.sgi.com Subject: Re: [PATCH 2.6.11 4/8] tg3: Add msi test Message-Id: <20050322155235.267c4757.davem@davemloft.net> In-Reply-To: <4240AF4C.9030109@pobox.com> References: <424098E2.6090007@pobox.com> <20050322141714.4515258f.davem@davemloft.net> <42409BA4.3090302@pobox.com> <20050322154030.310e85c1.davem@davemloft.net> <4240AF4C.9030109@pobox.com> X-Mailer: Sylpheed version 1.0.1 (GTK+ 1.2.10; sparc-unknown-linux-gnu) X-Face: "_;p5u5aPsO,_Vsx"^v-pEq09'CU4&Dc1$fQExov$62l60cgCc%FnIwD=.UF^a>?5'9Kn[;433QFVV9M..2eN.@4ZWPGbdi<=?[:T>y?SD(R*-3It"Vj:)"dP Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV 0.83/778/Mon Mar 21 02:48:43 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 510 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: davem@davemloft.net Precedence: bulk X-list: netdev Content-Length: 394 Lines: 10 On Tue, 22 Mar 2005 18:50:36 -0500 Jeff Garzik wrote: > Sorry, I still disagree. We need to think about how to handle this > situation for -all- drivers and -all- users, not just tg3. When you come up with something that doesn't require the users to ask around and report stuff when MSI doesn't work, let me know. But for now let's hold off on the tg3 MSI support, ok? From jgarzik@pobox.com Tue Mar 22 15:57:08 2005 Received: with ECARTIS (v1.0.0; list netdev); Tue, 22 Mar 2005 15:57:12 -0800 (PST) Received: from parcelfarce.linux.theplanet.co.uk (IDENT:93@parcelfarce.linux.theplanet.co.uk [195.92.249.252]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j2MNv5tG028511 for ; Tue, 22 Mar 2005 15:57:08 -0800 Received: from cpe-069-134-152-124.nc.rr.com ([69.134.152.124] helo=[10.10.10.88]) by parcelfarce.linux.theplanet.co.uk with asmtp (TLSv1:AES256-SHA:256) (Exim 4.33) id 1DDtFA-0003q5-PF; Tue, 22 Mar 2005 23:57:05 +0000 Message-ID: <4240B0C4.5020505@pobox.com> Date: Tue, 22 Mar 2005 18:56:52 -0500 From: Jeff Garzik User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.3) Gecko/20040922 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Stephen Hemminger CC: netdev@oss.sgi.com Subject: Re: [PATCH] ethtool: add skge register dump References: <20050309142449.4682340b@dxpl.pdx.osdl.net> In-Reply-To: <20050309142449.4682340b@dxpl.pdx.osdl.net> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV 0.83/778/Mon Mar 21 02:48:43 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 511 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: jgarzik@pobox.com Precedence: bulk X-list: netdev Content-Length: 9 Lines: 2 applied From jgarzik@pobox.com Tue Mar 22 15:59:29 2005 Received: with ECARTIS (v1.0.0; list netdev); Tue, 22 Mar 2005 15:59:34 -0800 (PST) Received: from parcelfarce.linux.theplanet.co.uk (IDENT:93@parcelfarce.linux.theplanet.co.uk [195.92.249.252]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j2MNxT8h029193 for ; Tue, 22 Mar 2005 15:59:29 -0800 Received: from cpe-069-134-152-124.nc.rr.com ([69.134.152.124] helo=[10.10.10.88]) by parcelfarce.linux.theplanet.co.uk with asmtp (TLSv1:AES256-SHA:256) (Exim 4.33) id 1DDtHR-0003so-MZ; Tue, 22 Mar 2005 23:59:25 +0000 Message-ID: <4240B152.4080904@pobox.com> Date: Tue, 22 Mar 2005 18:59:14 -0500 From: Jeff Garzik User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.3) Gecko/20040922 X-Accept-Language: en-us, en MIME-Version: 1.0 To: domen@coderock.org CC: netdev@oss.sgi.com, nacc@us.ibm.com Subject: Re: [patch 14/26] net/slip: replace schedule_timeout() with msleep() References: <20050306103322.857041F203@trashy.coderock.org> In-Reply-To: <20050306103322.857041F203@trashy.coderock.org> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV 0.83/778/Mon Mar 21 02:48:43 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 512 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: jgarzik@pobox.com Precedence: bulk X-list: netdev Content-Length: 1206 Lines: 39 domen@coderock.org wrote: > Use msleep() instead of schedule_timeout() to guarantee > the task delays as expected. While the original code does use > TASK_INTERRUPTIBLE, it does not check for signals, so I believe msleep() is more > appropriate. > > Signed-off-by: Nishanth Aravamudan > Signed-off-by: Domen Puncer > --- > > > kj-domen/drivers/net/slip.c | 7 +++---- > 1 files changed, 3 insertions(+), 4 deletions(-) > > diff -puN drivers/net/slip.c~msleep-drivers_net_slip drivers/net/slip.c > --- kj/drivers/net/slip.c~msleep-drivers_net_slip 2005-03-05 16:10:49.000000000 +0100 > +++ kj-domen/drivers/net/slip.c 2005-03-05 16:10:49.000000000 +0100 > @@ -75,6 +75,7 @@ > #include > #include > #include > +#include > #include "slip.h" > #ifdef CONFIG_INET > #include > @@ -1395,10 +1396,8 @@ static void __exit slip_exit(void) > /* First of all: check for active disciplines and hangup them. > */ > do { > - if (busy) { > - set_current_state(TASK_INTERRUPTIBLE); > - schedule_timeout(HZ / 10); > - } > + if (busy) > + msleep(100); msleep_interruptible From jgarzik@pobox.com Tue Mar 22 16:01:30 2005 Received: with ECARTIS (v1.0.0; list netdev); Tue, 22 Mar 2005 16:01:34 -0800 (PST) Received: from parcelfarce.linux.theplanet.co.uk (IDENT:93@parcelfarce.linux.theplanet.co.uk [195.92.249.252]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j2N01Spd029819 for ; Tue, 22 Mar 2005 16:01:30 -0800 Received: from cpe-069-134-152-124.nc.rr.com ([69.134.152.124] helo=[10.10.10.88]) by parcelfarce.linux.theplanet.co.uk with asmtp (TLSv1:AES256-SHA:256) (Exim 4.33) id 1DDtJP-0003us-53; Wed, 23 Mar 2005 00:01:27 +0000 Message-ID: <4240B1CB.3020103@pobox.com> Date: Tue, 22 Mar 2005 19:01:15 -0500 From: Jeff Garzik User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.3) Gecko/20040922 X-Accept-Language: en-us, en MIME-Version: 1.0 To: domen@coderock.org CC: netdev@oss.sgi.com, tklauser@nuerscht.ch Subject: Re: [patch 26/26] drivers/net/: Use the DMA_{64,32}BIT_MASK constants References: <20050306103404.12D9C1E46E@trashy.coderock.org> In-Reply-To: <20050306103404.12D9C1E46E@trashy.coderock.org> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV 0.83/778/Mon Mar 21 02:48:43 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 513 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: jgarzik@pobox.com Precedence: bulk X-list: netdev Content-Length: 308 Lines: 12 domen@coderock.org wrote: > Use the DMA_{64,32}BIT_MASK constants from dma-mapping.h > when calling pci_set_dma_mask() or pci_set_consistent_dma_mask() > > [Merged multiple patches, I can send split ones if desired -domen] you don't need to split, but you do need to include linux/dma-mapping.h. Jeff From mchan@broadcom.com Tue Mar 22 16:25:06 2005 Received: with ECARTIS (v1.0.0; list netdev); Tue, 22 Mar 2005 16:25:10 -0800 (PST) Received: from MMS2.broadcom.com (mms2.broadcom.com [216.31.210.18]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j2N0P5jG003417 for ; Tue, 22 Mar 2005 16:25:05 -0800 Received: from 10.10.64.121 by MMS2.broadcom.com with SMTP (Broadcom SMTP Relay (Email Firewall v6.1.0)); Tue, 22 Mar 2005 16:24:53 -0800 X-Server-Uuid: 1F20ACF3-9CAF-44F7-AB47-F294E2D5B4EA Received: from mail-irva-8.broadcom.com ([10.10.64.221]) by mail-irva-1.broadcom.com (Post.Office MTA v3.5.3 release 223 ID# 0-72233U7200L2200S0V35) with ESMTP id com; Tue, 22 Mar 2005 16:24:46 -0800 Received: from mon-irva-10.broadcom.com (mon-irva-10.broadcom.com [10.10.64.171]) by mail-irva-8.broadcom.com (MOS 3.5.6-GR) with ESMTP id APQ27382; Tue, 22 Mar 2005 16:24:38 -0800 (PST) Received: from nt-irva-0741.brcm.ad.broadcom.com ( nt-irva-0741.brcm.ad.broadcom.com [10.8.194.54]) by mon-irva-10.broadcom.com (8.9.1/8.9.1) with ESMTP id QAA28279; Tue, 22 Mar 2005 16:24:38 -0800 (PST) X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Subject: RE: [PATCH 2.6.11 3/8] tg3: Add msi support for 5750 C0 Date: Tue, 22 Mar 2005 16:24:37 -0800 Message-ID: Thread-Topic: [PATCH 2.6.11 3/8] tg3: Add msi support for 5750 C0 Thread-Index: AcUvIbJcHBTI/nbqTeuLlR1Hc4GlCAAG8e3g From: "Michael Chan" To: "Jeff Garzik" cc: "David S. Miller" , netdev@oss.sgi.com X-WSS-ID: 6E5E68DF2WW1401488-01-01 Content-Type: text/plain; charset=us-ascii X-Virus-Scanned: ClamAV 0.83/778/Mon Mar 21 02:48:43 2005 on oss.sgi.com X-Virus-Status: Clean Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by oss.sgi.com id j2N0P5jG003417 X-archive-position: 514 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: mchan@broadcom.com Precedence: bulk X-list: netdev Content-Length: 592 Lines: 22 "Jeff Garzik" wrote: > > I would prefer that a new 'static inline' function was created, > containing the core interrupt handler code. > > This avoids the code duplication you have in this patch, in > new function > tg3_msi(). > > Jeff > There are enough subtle differences between tg3_interrupt() and tg3_msi() that makes it impractical to create a core inline function to be shared by the two. To share a meaningful chunk of the code, it will have to check for MSI mode and skip some of the register reads. The reason I created tg3_msi() was to avoid all conditionals. Michael From jgarzik@pobox.com Tue Mar 22 16:28:59 2005 Received: with ECARTIS (v1.0.0; list netdev); Tue, 22 Mar 2005 16:29:03 -0800 (PST) Received: from parcelfarce.linux.theplanet.co.uk (IDENT:93@parcelfarce.linux.theplanet.co.uk [195.92.249.252]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j2N0SwP7004093 for ; Tue, 22 Mar 2005 16:28:58 -0800 Received: from cpe-069-134-152-124.nc.rr.com ([69.134.152.124] helo=[10.10.10.88]) by parcelfarce.linux.theplanet.co.uk with asmtp (TLSv1:AES256-SHA:256) (Exim 4.33) id 1DDtjy-0004KP-0D; Wed, 23 Mar 2005 00:28:54 +0000 Message-ID: <4240B839.6090604@pobox.com> Date: Tue, 22 Mar 2005 19:28:41 -0500 From: Jeff Garzik User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.3) Gecko/20040922 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Michael Chan CC: "David S. Miller" , netdev@oss.sgi.com Subject: Re: [PATCH 2.6.11 3/8] tg3: Add msi support for 5750 C0 References: In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV 0.83/778/Mon Mar 21 02:48:43 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 515 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: jgarzik@pobox.com Precedence: bulk X-list: netdev Content-Length: 709 Lines: 27 Michael Chan wrote: > "Jeff Garzik" wrote: > > >>I would prefer that a new 'static inline' function was created, >>containing the core interrupt handler code. >> >>This avoids the code duplication you have in this patch, in >>new function >>tg3_msi(). >> >> Jeff >> > > > There are enough subtle differences between tg3_interrupt() and tg3_msi() > that makes it impractical to create a core inline function to be shared by > the two. To share a meaningful chunk of the code, it will have to check for > MSI mode and skip some of the register reads. The reason I created tg3_msi() > was to avoid all conditionals. After reviewing the existing tg3.c code again, I agree. Objection withdrawn. Jeff From sfrost@ns.snowman.net Tue Mar 22 16:32:47 2005 Received: with ECARTIS (v1.0.0; list netdev); Tue, 22 Mar 2005 16:32:53 -0800 (PST) Received: from relay.snowman.net (relay.snowman.net [66.92.160.56]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j2N0Wku0004829 for ; Tue, 22 Mar 2005 16:32:46 -0800 Received: from ns.snowman.net (ns.snowman.net [10.10.0.2]) by relay.snowman.net (8.13.1/8.13.1/Debian-19) with ESMTP id j2N0Wd4c032320 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT) for ; Tue, 22 Mar 2005 19:32:39 -0500 Received: from ns.snowman.net (localhost [127.0.0.1]) by ns.snowman.net (8.13.1/8.13.1/Debian-19) with ESMTP id j2N0XAVp005713 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT) for ; Tue, 22 Mar 2005 19:33:10 -0500 Received: (from sfrost@localhost) by ns.snowman.net (8.13.1/8.13.1/Submit) id j2N0XAiw005711 for netdev@oss.sgi.com; Tue, 22 Mar 2005 19:33:10 -0500 Date: Tue, 22 Mar 2005 19:33:10 -0500 From: Stephen Frost To: netdev@oss.sgi.com Subject: Re: [IPSEC] Too many SADs! Message-ID: <20050323003310.GE8725@ns.snowman.net> References: <200503220052.52756.wolfgang.walter@studentenwerk.mhn.de> <20050322224819.GB4924@questra.com> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="rz+pwK2yUstbofK6" Content-Disposition: inline In-Reply-To: <20050322224819.GB4924@questra.com> X-Editor: Vim http://www.vim.org/ X-Info: http://www.snowman.net X-Operating-System: Linux/2.4.24ns.3.0 (i686) X-Uptime: 19:31:20 up 416 days, 19:23, 9 users, load average: 0.48, 0.31, 0.21 User-Agent: Mutt/1.5.6+20040907i X-Virus-Scanned: ClamAV 0.83/778/Mon Mar 21 02:48:43 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 516 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: sfrost@snowman.net Precedence: bulk X-list: netdev Content-Length: 1459 Lines: 49 --rz+pwK2yUstbofK6 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable * Scott Mcdermott (smcdermott@questra.com) wrote: > What, openswan uses PF_KEY last I checked on kernel 2.6. I > guess you can use KLIPS, but why would you? What's this > "netfilter-interface" to ipsec code? This confused me too... > I had the exact same problem the original poster had with > Racoon. SPDs would multiply without bounds, seemingly > geometrically. Yeah. Not good. :( > I switched to strongswan and the problems immediately > vanished. There is some bug in racoon where it doesn't > replace SPDs. I used the latest ipsec-utils and kernel and > this problem did not go away until I switched instead to > strongswan (still using PF_KEY) (it also worked with > openswan). Sounds like I may need to check out strongswan/openswan. =20 I can tell you I wasn't exactly a fan of freeswan for a variety of reasons. I'm suprised there havn't been more people talking about and looking into fixing this, kind of concerning.. Thanks, Stephen --rz+pwK2yUstbofK6 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) iD8DBQFCQLlErzgMPqB3kigRAgzEAJ417C1FG8/LJDk2D06g/Q0uktkE4QCbBBJD YynzJXlu9+jk7AbOMhjHPCw= =NtUT -----END PGP SIGNATURE----- --rz+pwK2yUstbofK6-- From chas@cmf.nrl.navy.mil Tue Mar 22 16:54:23 2005 Received: with ECARTIS (v1.0.0; list netdev); Tue, 22 Mar 2005 16:54:29 -0800 (PST) Received: from ginger.cmf.nrl.navy.mil (ginger.cmf.nrl.navy.mil [134.207.10.161]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j2N0sMTp006366 for ; Tue, 22 Mar 2005 16:54:22 -0800 Received: from cmf.nrl.navy.mil (thirdoffive.cmf.nrl.navy.mil [134.207.10.180]) by ginger.cmf.nrl.navy.mil (8.12.11/8.12.11) with ESMTP id j2N0sC52028366; Tue, 22 Mar 2005 19:54:13 -0500 (EST) Message-Id: <200503230054.j2N0sC52028366@ginger.cmf.nrl.navy.mil> To: netdev@oss.sgi.com Cc: davem@redhat.com Subject: [PATCH 1/6][ATM]: remove bridge/lec interdependency Date: Tue, 22 Mar 2005 19:54:14 -0500 From: "chas williams - CONTRACTOR" X-Virus-Scanned: ClamAV 0.83/778/Mon Mar 21 02:48:43 2005 on oss.sgi.com X-Virus-Scanned: NAI Completed X-Scanned-By: MIMEDefang 2.30 (www . roaringpenguin . com / mimedefang) X-Virus-Status: Clean X-archive-position: 517 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: chas@cmf.nrl.navy.mil Precedence: bulk X-list: netdev Content-Length: 6052 Lines: 181 please apply to 2.6 -- thanks! # This is a BitKeeper generated diff -Nru style patch. # # ChangeSet # 2005/03/22 08:39:37-05:00 chas@relax.cmf.nrl.navy.mil # [ATM]: remove bridge/lec interdependency # # Signed-off-by: Chas Williams # # net/core/dev.c # 2005/03/22 08:39:19-05:00 chas@relax.cmf.nrl.navy.mil +6 -0 # [ATM]: remove bridge/lec interdependency # # Signed-off-by: Chas Williams # # net/bridge/br_private.h # 2005/03/22 08:39:18-05:00 chas@relax.cmf.nrl.navy.mil +6 -0 # [ATM]: remove bridge/lec interdependency # # Signed-off-by: Chas Williams # # net/bridge/br.c # 2005/03/22 08:39:18-05:00 chas@relax.cmf.nrl.navy.mil +1 -8 # [ATM]: remove bridge/lec interdependency # # Signed-off-by: Chas Williams # # net/atm/lec.h # 2005/03/22 08:39:18-05:00 chas@relax.cmf.nrl.navy.mil +0 -8 # [ATM]: remove bridge/lec interdependency # # Signed-off-by: Chas Williams # # net/atm/lec.c # 2005/03/22 08:39:18-05:00 chas@relax.cmf.nrl.navy.mil +1 -4 # [ATM]: remove bridge/lec interdependency # # Signed-off-by: Chas Williams # # net/atm/common.c # 2005/03/22 08:39:18-05:00 chas@relax.cmf.nrl.navy.mil +0 -15 # [ATM]: remove bridge/lec interdependency # # Signed-off-by: Chas Williams # diff -Nru a/net/atm/common.c b/net/atm/common.c --- a/net/atm/common.c 2005-03-22 19:50:34 -05:00 +++ b/net/atm/common.c 2005-03-22 19:50:34 -05:00 @@ -755,21 +755,6 @@ return vcc->dev->ops->getsockopt(vcc, level, optname, optval, len); } - -#if defined(CONFIG_ATM_LANE) || defined(CONFIG_ATM_LANE_MODULE) -#if defined(CONFIG_BRIDGE) || defined(CONFIG_BRIDGE_MODULE) -struct net_bridge; -struct net_bridge_fdb_entry *(*br_fdb_get_hook)(struct net_bridge *br, - unsigned char *addr) = NULL; -void (*br_fdb_put_hook)(struct net_bridge_fdb_entry *ent) = NULL; -#if defined(CONFIG_ATM_LANE_MODULE) || defined(CONFIG_BRIDGE_MODULE) -EXPORT_SYMBOL(br_fdb_get_hook); -EXPORT_SYMBOL(br_fdb_put_hook); -#endif /* defined(CONFIG_ATM_LANE_MODULE) || defined(CONFIG_BRIDGE_MODULE) */ -#endif /* defined(CONFIG_BRIDGE) || defined(CONFIG_BRIDGE_MODULE) */ -#endif /* defined(CONFIG_ATM_LANE) || defined(CONFIG_ATM_LANE_MODULE) */ - - static int __init atm_init(void) { int error; diff -Nru a/net/atm/lec.c b/net/atm/lec.c --- a/net/atm/lec.c 2005-03-22 19:50:34 -05:00 +++ b/net/atm/lec.c 2005-03-22 19:50:34 -05:00 @@ -37,11 +37,8 @@ #if defined(CONFIG_BRIDGE) || defined(CONFIG_BRIDGE_MODULE) #include #include "../bridge/br_private.h" -static unsigned char bridge_ula_lec[] = {0x01, 0x80, 0xc2, 0x00, 0x00}; -extern struct net_bridge_fdb_entry *(*br_fdb_get_hook)(struct net_bridge *br, - unsigned char *addr); -extern void (*br_fdb_put_hook)(struct net_bridge_fdb_entry *ent); +static unsigned char bridge_ula_lec[] = {0x01, 0x80, 0xc2, 0x00, 0x00}; #endif /* Modular too */ diff -Nru a/net/atm/lec.h b/net/atm/lec.h --- a/net/atm/lec.h 2005-03-22 19:50:34 -05:00 +++ b/net/atm/lec.h 2005-03-22 19:50:34 -05:00 @@ -14,14 +14,6 @@ #include #include -#if defined (CONFIG_BRIDGE) || defined(CONFIG_BRIDGE_MODULE) -#include -struct net_bridge; -extern struct net_bridge_fdb_entry *(*br_fdb_get_hook)(struct net_bridge *br, - unsigned char *addr); -extern void (*br_fdb_put_hook)(struct net_bridge_fdb_entry *ent); -#endif /* defined(CONFIG_BRIDGE) || defined(CONFIG_BRIDGE_MODULE) */ - #define LEC_HEADER_LEN 16 struct lecdatahdr_8023 { diff -Nru a/net/bridge/br.c b/net/bridge/br.c --- a/net/bridge/br.c 2005-03-22 19:50:34 -05:00 +++ b/net/bridge/br.c 2005-03-22 19:50:34 -05:00 @@ -22,10 +22,6 @@ #include "br_private.h" -#if defined(CONFIG_ATM_LANE) || defined(CONFIG_ATM_LANE_MODULE) -#include "../atm/lec.h" -#endif - int (*br_should_route_hook) (struct sk_buff **pskb) = NULL; static int __init br_init(void) @@ -39,10 +35,9 @@ brioctl_set(br_ioctl_deviceless_stub); br_handle_frame_hook = br_handle_frame; -#if defined(CONFIG_ATM_LANE) || defined(CONFIG_ATM_LANE_MODULE) br_fdb_get_hook = br_fdb_get; br_fdb_put_hook = br_fdb_put; -#endif + register_netdevice_notifier(&br_device_notifier); return 0; @@ -60,10 +55,8 @@ synchronize_net(); -#if defined(CONFIG_ATM_LANE) || defined(CONFIG_ATM_LANE_MODULE) br_fdb_get_hook = NULL; br_fdb_put_hook = NULL; -#endif br_handle_frame_hook = NULL; br_fdb_fini(); diff -Nru a/net/bridge/br_private.h b/net/bridge/br_private.h --- a/net/bridge/br_private.h 2005-03-22 19:50:34 -05:00 +++ b/net/bridge/br_private.h 2005-03-22 19:50:34 -05:00 @@ -216,6 +216,12 @@ extern void br_stp_port_timer_init(struct net_bridge_port *p); extern unsigned long br_timer_value(const struct timer_list *timer); +/* br.c */ +extern struct net_bridge_fdb_entry *(*br_fdb_get_hook)(struct net_bridge *br, + unsigned char *addr); +extern void (*br_fdb_put_hook)(struct net_bridge_fdb_entry *ent); + + #ifdef CONFIG_SYSFS /* br_sysfs_if.c */ extern int br_sysfs_addif(struct net_bridge_port *p); diff -Nru a/net/core/dev.c b/net/core/dev.c --- a/net/core/dev.c 2005-03-22 19:50:34 -05:00 +++ b/net/core/dev.c 2005-03-22 19:50:34 -05:00 @@ -1561,6 +1561,10 @@ #if defined(CONFIG_BRIDGE) || defined (CONFIG_BRIDGE_MODULE) int (*br_handle_frame_hook)(struct net_bridge_port *p, struct sk_buff **pskb); +struct net_bridge; +struct net_bridge_fdb_entry *(*br_fdb_get_hook)(struct net_bridge *br, + unsigned char *addr); +void (*br_fdb_put_hook)(struct net_bridge_fdb_entry *ent); static __inline__ int handle_bridge(struct sk_buff **pskb, struct packet_type **pt_prev, int *ret) @@ -3347,6 +3351,8 @@ #if defined(CONFIG_BRIDGE) || defined(CONFIG_BRIDGE_MODULE) EXPORT_SYMBOL(br_handle_frame_hook); +EXPORT_SYMBOL(br_fdb_get_hook); +EXPORT_SYMBOL(br_fdb_put_hook); #endif #ifdef CONFIG_KMOD From chas@cmf.nrl.navy.mil Tue Mar 22 16:54:50 2005 Received: with ECARTIS (v1.0.0; list netdev); Tue, 22 Mar 2005 16:54:56 -0800 (PST) Received: from ginger.cmf.nrl.navy.mil (ginger.cmf.nrl.navy.mil [134.207.10.161]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j2N0sn7x006403 for ; Tue, 22 Mar 2005 16:54:49 -0800 Received: from cmf.nrl.navy.mil (thirdoffive.cmf.nrl.navy.mil [134.207.10.180]) by ginger.cmf.nrl.navy.mil (8.12.11/8.12.11) with ESMTP id j2N0sg7s028376; Tue, 22 Mar 2005 19:54:42 -0500 (EST) Message-Id: <200503230054.j2N0sg7s028376@ginger.cmf.nrl.navy.mil> To: netdev@oss.sgi.com Cc: davem@redhat.com Subject: [PATCH 2/6][ATM]: [zatm] fix sparse warning Date: Tue, 22 Mar 2005 19:54:43 -0500 From: "chas williams - CONTRACTOR" X-Virus-Scanned: ClamAV 0.83/778/Mon Mar 21 02:48:43 2005 on oss.sgi.com X-Virus-Scanned: NAI Completed X-Scanned-By: MIMEDefang 2.30 (www . roaringpenguin . com / mimedefang) X-Virus-Status: Clean X-archive-position: 518 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: chas@cmf.nrl.navy.mil Precedence: bulk X-list: netdev Content-Length: 1173 Lines: 32 please apply to 2.6 -- thanks! # This is a BitKeeper generated diff -Nru style patch. # # ChangeSet # 2005/03/22 09:55:38-05:00 chas@relax.cmf.nrl.navy.mil # [ATM]: [zatm] fix sparse warning # # Signed-off-by: Alexey Dobriyan # Signed-off-by: Domen Puncer # Signed-off-by: Chas Williams # # drivers/atm/zatm.c # 2005/03/22 09:55:19-05:00 chas@relax.cmf.nrl.navy.mil +1 -1 # [ATM]: [zatm] fix sparse warning # # Signed-off-by: Alexey Dobriyan # Signed-off-by: Domen Puncer # Signed-off-by: Chas Williams # diff -Nru a/drivers/atm/zatm.c b/drivers/atm/zatm.c --- a/drivers/atm/zatm.c 2005-03-22 19:50:21 -05:00 +++ b/drivers/atm/zatm.c 2005-03-22 19:50:21 -05:00 @@ -411,7 +411,7 @@ #if 0 printk("dummy: 0x%08lx, 0x%08lx\n",dummy[0],dummy[1]); #endif - size = error ? 0 : ntohs(((u16 *) skb->data)[cells* + size = error ? 0 : ntohs(((__be16 *) skb->data)[cells* ATM_CELL_PAYLOAD/sizeof(u16)-3]); EVENT("got skb 0x%lx, size %d\n",(unsigned long) skb,size); chan = (here[3] & uPD98401_AAL5_CHAN) >> From chas@cmf.nrl.navy.mil Tue Mar 22 16:55:18 2005 Received: with ECARTIS (v1.0.0; list netdev); Tue, 22 Mar 2005 16:55:23 -0800 (PST) Received: from ginger.cmf.nrl.navy.mil (ginger.cmf.nrl.navy.mil [134.207.10.161]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j2N0tH8T006607 for ; Tue, 22 Mar 2005 16:55:18 -0800 Received: from cmf.nrl.navy.mil (thirdoffive.cmf.nrl.navy.mil [134.207.10.180]) by ginger.cmf.nrl.navy.mil (8.12.11/8.12.11) with ESMTP id j2N0t7xf028383; Tue, 22 Mar 2005 19:55:07 -0500 (EST) Message-Id: <200503230055.j2N0t7xf028383@ginger.cmf.nrl.navy.mil> To: netdev@oss.sgi.com Cc: davem@redhat.com Subject: [PATCH 3/6][ATM]: [nicstar] fix some sparse warnings Date: Tue, 22 Mar 2005 19:55:08 -0500 From: "chas williams - CONTRACTOR" X-Virus-Scanned: ClamAV 0.83/778/Mon Mar 21 02:48:43 2005 on oss.sgi.com X-Virus-Scanned: NAI Completed X-Scanned-By: MIMEDefang 2.30 (www . roaringpenguin . com / mimedefang) X-Virus-Status: Clean X-archive-position: 519 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: chas@cmf.nrl.navy.mil Precedence: bulk X-list: netdev Content-Length: 2044 Lines: 63 please apply to 2.6 -- thanks! # This is a BitKeeper generated diff -Nru style patch. # # ChangeSet # 2005/03/22 11:35:05-05:00 chas@relax.cmf.nrl.navy.mil # [ATM]: [nicstar] fix some sparse warnings # # Signed-off-by: Alexey Dobriyan # Signed-off-by: Domen Puncer # Signed-off-by: Chas Williams # # drivers/atm/nicstar.h # 2005/03/22 11:34:46-05:00 chas@relax.cmf.nrl.navy.mil +2 -2 # [ATM]: [nicstar] fix some sparse warnings # # Signed-off-by: Alexey Dobriyan # Signed-off-by: Domen Puncer # Signed-off-by: Chas Williams # # drivers/atm/nicstar.c # 2005/03/22 11:34:46-05:00 chas@relax.cmf.nrl.navy.mil +2 -2 # [ATM]: [nicstar] fix some sparse warnings # # Signed-off-by: Alexey Dobriyan # Signed-off-by: Domen Puncer # Signed-off-by: Chas Williams # diff -Nru a/drivers/atm/nicstar.c b/drivers/atm/nicstar.c --- a/drivers/atm/nicstar.c 2005-03-22 19:50:00 -05:00 +++ b/drivers/atm/nicstar.c 2005-03-22 19:50:00 -05:00 @@ -350,7 +350,7 @@ kfree(card->rsq.org); kfree(card->tsq.org); free_irq(card->pcidev->irq, card); - iounmap((void *) card->membase); + iounmap(card->membase); kfree(card); } @@ -976,7 +976,7 @@ } if (error >= 4) { - iounmap((void *) card->membase); + iounmap(card->membase); } if (error >= 3) { diff -Nru a/drivers/atm/nicstar.h b/drivers/atm/nicstar.h --- a/drivers/atm/nicstar.h 2005-03-22 19:50:00 -05:00 +++ b/drivers/atm/nicstar.h 2005-03-22 19:50:00 -05:00 @@ -739,8 +739,8 @@ typedef struct vc_map { - volatile int tx:1; /* TX vc? */ - volatile int rx:1; /* RX vc? */ + volatile unsigned int tx:1; /* TX vc? */ + volatile unsigned int rx:1; /* RX vc? */ struct atm_vcc *tx_vcc, *rx_vcc; struct sk_buff *rx_iov; /* RX iovector skb */ scq_info *scq; /* To keep track of the SCQ */ From chas@cmf.nrl.navy.mil Tue Mar 22 16:55:44 2005 Received: with ECARTIS (v1.0.0; list netdev); Tue, 22 Mar 2005 16:55:51 -0800 (PST) Received: from ginger.cmf.nrl.navy.mil (ginger.cmf.nrl.navy.mil [134.207.10.161]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j2N0tiNr007049 for ; Tue, 22 Mar 2005 16:55:44 -0800 Received: from cmf.nrl.navy.mil (thirdoffive.cmf.nrl.navy.mil [134.207.10.180]) by ginger.cmf.nrl.navy.mil (8.12.11/8.12.11) with ESMTP id j2N0tTq3028390; Tue, 22 Mar 2005 19:55:29 -0500 (EST) Message-Id: <200503230055.j2N0tTq3028390@ginger.cmf.nrl.navy.mil> To: netdev@oss.sgi.com Cc: davem@redhat.com Subject: [PATCH 4/6][ATM]: [ambassador] fix sparse warnings Date: Tue, 22 Mar 2005 19:55:30 -0500 From: "chas williams - CONTRACTOR" X-Virus-Scanned: ClamAV 0.83/778/Mon Mar 21 02:48:43 2005 on oss.sgi.com X-Virus-Scanned: NAI Completed X-Scanned-By: MIMEDefang 2.30 (www . roaringpenguin . com / mimedefang) X-Virus-Status: Clean X-archive-position: 520 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: chas@cmf.nrl.navy.mil Precedence: bulk X-list: netdev Content-Length: 5977 Lines: 243 please apply to 2.6 -- thanks! # This is a BitKeeper generated diff -Nru style patch. # # ChangeSet # 2005/03/22 14:56:16-05:00 chas@relax.cmf.nrl.navy.mil # [ATM]: [ambassador] fix sparse warnings # # Signed-off-by: Alexey Dobriyan # Signed-off-by: Domen Puncer # Signed-off-by: Chas Williams # # drivers/atm/ambassador.h # 2005/03/22 14:55:57-05:00 chas@relax.cmf.nrl.navy.mil +50 -50 # [ATM]: [ambassador] fix sparse warnings # # Signed-off-by: Alexey Dobriyan # Signed-off-by: Domen Puncer # Signed-off-by: Chas Williams # # drivers/atm/ambassador.c # 2005/03/22 14:55:57-05:00 chas@relax.cmf.nrl.navy.mil +4 -4 # [ATM]: [ambassador] fix sparse warnings # # Signed-off-by: Alexey Dobriyan # Signed-off-by: Domen Puncer # Signed-off-by: Chas Williams # diff -Nru a/drivers/atm/ambassador.c b/drivers/atm/ambassador.c --- a/drivers/atm/ambassador.c 2005-03-22 19:49:36 -05:00 +++ b/drivers/atm/ambassador.c 2005-03-22 19:49:36 -05:00 @@ -345,7 +345,7 @@ } static inline void wr_mem (const amb_dev * dev, size_t addr, u32 data) { - u32 be = cpu_to_be32 (data); + __be32 be = cpu_to_be32 (data); PRINTD (DBG_FLOW|DBG_REGS, "wr: %08zx <- %08x b[%08x]", addr, data, be); #ifdef AMB_MMIO dev->membase[addr / sizeof(u32)] = be; @@ -356,9 +356,9 @@ static inline u32 rd_mem (const amb_dev * dev, size_t addr) { #ifdef AMB_MMIO - u32 be = dev->membase[addr / sizeof(u32)]; + __be32 be = dev->membase[addr / sizeof(u32)]; #else - u32 be = inl (dev->iobase + addr); + __be32 be = inl (dev->iobase + addr); #endif u32 data = be32_to_cpu (be); PRINTD (DBG_FLOW|DBG_REGS, "rd: %08zx -> %08x b[%08x]", addr, data, be); @@ -2007,7 +2007,7 @@ /********** give adapter parameters **********/ -static inline u32 bus_addr(void * addr) { +static inline __be32 bus_addr(void * addr) { return cpu_to_be32 (virt_to_bus (addr)); } diff -Nru a/drivers/atm/ambassador.h b/drivers/atm/ambassador.h --- a/drivers/atm/ambassador.h 2005-03-22 19:49:36 -05:00 +++ b/drivers/atm/ambassador.h 2005-03-22 19:49:36 -05:00 @@ -342,21 +342,21 @@ #define MAX_TRANSFER_DATA 11 typedef struct { - u32 address; - u32 count; - u32 data[MAX_TRANSFER_DATA]; + __be32 address; + __be32 count; + __be32 data[MAX_TRANSFER_DATA]; } transfer_block; typedef struct { - u32 result; - u32 command; + __be32 result; + __be32 command; union { transfer_block transfer; - u32 version; - u32 start; - u32 data[MAX_COMMAND_DATA]; + __be32 version; + __be32 start; + __be32 data[MAX_COMMAND_DATA]; } payload; - u32 valid; + __be32 valid; } loader_block; /* command queue */ @@ -366,46 +366,46 @@ typedef struct { union { struct { - u32 vc; - u32 flags; - u32 rate; + __be32 vc; + __be32 flags; + __be32 rate; } open; struct { - u32 vc; - u32 rate; + __be32 vc; + __be32 rate; } modify_rate; struct { - u32 vc; - u32 flags; + __be32 vc; + __be32 flags; } modify_flags; struct { - u32 vc; + __be32 vc; } close; struct { - u32 lower4; - u32 upper2; + __be32 lower4; + __be32 upper2; } bia; struct { - u32 address; + __be32 address; } suni; struct { - u32 major; - u32 minor; + __be32 major; + __be32 minor; } version; struct { - u32 read; - u32 write; + __be32 read; + __be32 write; } speed; struct { - u32 flags; + __be32 flags; } flush; struct { - u32 address; - u32 data; + __be32 address; + __be32 data; } memory; - u32 par[3]; + __be32 par[3]; } args; - u32 request; + __be32 request; } command; /* transmit queues and associated structures */ @@ -417,8 +417,8 @@ /* TX is described by 1+ tx_frags followed by a tx_frag_end */ typedef struct { - u32 bytes; - u32 address; + __be32 bytes; + __be32 address; } tx_frag; /* apart from handle the fields here are for the adapter to play with @@ -452,9 +452,9 @@ /* this "points" to the sequence of fragments and trailer */ typedef struct { - u16 vc; - u16 tx_descr_length; - u32 tx_descr_addr; + __be16 vc; + __be16 tx_descr_length; + __be32 tx_descr_addr; } tx_in; /* handle is the handle from tx_in */ @@ -471,17 +471,17 @@ typedef struct { u32 handle; - u16 vc; - u16 lec_id; // unused - u16 status; - u16 length; + __be16 vc; + __be16 lec_id; // unused + __be16 status; + __be16 length; } rx_out; /* buffer supply structure */ typedef struct { u32 handle; - u32 host_address; + __be32 host_address; } rx_in; /* This first structure is the area in host memory where the adapter @@ -495,22 +495,22 @@ adapter. */ typedef struct { - u32 command_start; /* SRB commands completions */ - u32 command_end; /* SRB commands completions */ - u32 tx_start; - u32 tx_end; - u32 txcom_start; /* tx completions */ - u32 txcom_end; /* tx completions */ + __be32 command_start; /* SRB commands completions */ + __be32 command_end; /* SRB commands completions */ + __be32 tx_start; + __be32 tx_end; + __be32 txcom_start; /* tx completions */ + __be32 txcom_end; /* tx completions */ struct { - u32 buffer_start; - u32 buffer_end; + __be32 buffer_start; + __be32 buffer_end; u32 buffer_q_get; u32 buffer_q_end; u32 buffer_aptr; - u32 rx_start; /* rx completions */ - u32 rx_end; + __be32 rx_start; /* rx completions */ + __be32 rx_end; u32 rx_ptr; - u32 buffer_size; /* size of host buffer */ + __be32 buffer_size; /* size of host buffer */ } rec_struct[NUM_RX_POOLS]; #ifdef AMB_NEW_MICROCODE u16 init_flags; From chas@cmf.nrl.navy.mil Tue Mar 22 16:56:47 2005 Received: with ECARTIS (v1.0.0; list netdev); Tue, 22 Mar 2005 16:56:53 -0800 (PST) Received: from ginger.cmf.nrl.navy.mil (ginger.cmf.nrl.navy.mil [134.207.10.161]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j2N0uknI008182 for ; Tue, 22 Mar 2005 16:56:47 -0800 Received: from cmf.nrl.navy.mil (thirdoffive.cmf.nrl.navy.mil [134.207.10.180]) by ginger.cmf.nrl.navy.mil (8.12.11/8.12.11) with ESMTP id j2N0uZcf028407; Tue, 22 Mar 2005 19:56:35 -0500 (EST) Message-Id: <200503230056.j2N0uZcf028407@ginger.cmf.nrl.navy.mil> To: netdev@oss.sgi.com Cc: davem@redhat.com Subject: [PATCH 5/6][ATM]: [lanai] alpha build fixes Date: Tue, 22 Mar 2005 19:56:36 -0500 From: "chas williams - CONTRACTOR" X-Virus-Scanned: ClamAV 0.83/778/Mon Mar 21 02:48:43 2005 on oss.sgi.com X-Virus-Scanned: NAI Completed X-Scanned-By: MIMEDefang 2.30 (www . roaringpenguin . com / mimedefang) X-Virus-Status: Clean X-archive-position: 521 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: chas@cmf.nrl.navy.mil Precedence: bulk X-list: netdev Content-Length: 918 Lines: 29 please apply to 2.6 -- thanks! # This is a BitKeeper generated diff -Nru style patch. # # ChangeSet # 2005/03/22 15:01:18-05:00 chas@relax.cmf.nrl.navy.mil # [ATM]: [lanai] alpha build fixes # # Signed-off-by: Jeff Garzik # Signed-off-by: Chas Williams # # drivers/atm/lanai.c # 2005/03/22 15:01:00-05:00 chas@relax.cmf.nrl.navy.mil +1 -0 # [ATM]: [lanai] alpha build fixes # # Signed-off-by: Jeff Garzik # Signed-off-by: Chas Williams # diff -Nru a/drivers/atm/lanai.c b/drivers/atm/lanai.c --- a/drivers/atm/lanai.c 2005-03-22 19:49:16 -05:00 +++ b/drivers/atm/lanai.c 2005-03-22 19:49:16 -05:00 @@ -61,6 +61,7 @@ #include #include #include +#include #include #include #include From chas@cmf.nrl.navy.mil Tue Mar 22 16:57:30 2005 Received: with ECARTIS (v1.0.0; list netdev); Tue, 22 Mar 2005 16:57:38 -0800 (PST) Received: from ginger.cmf.nrl.navy.mil (ginger.cmf.nrl.navy.mil [134.207.10.161]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j2N0vUEj008724 for ; Tue, 22 Mar 2005 16:57:30 -0800 Received: from cmf.nrl.navy.mil (thirdoffive.cmf.nrl.navy.mil [134.207.10.180]) by ginger.cmf.nrl.navy.mil (8.12.11/8.12.11) with ESMTP id j2N0vBlq028423; Tue, 22 Mar 2005 19:57:11 -0500 (EST) Message-Id: <200503230057.j2N0vBlq028423@ginger.cmf.nrl.navy.mil> To: netdev@oss.sgi.com Cc: davem@redhat.com Subject: [PATCH 6/6][ATM]: assorted cleanups Date: Tue, 22 Mar 2005 19:57:12 -0500 From: "chas williams - CONTRACTOR" X-Virus-Scanned: ClamAV 0.83/778/Mon Mar 21 02:48:43 2005 on oss.sgi.com X-Virus-Scanned: NAI Completed X-Scanned-By: MIMEDefang 2.30 (www . roaringpenguin . com / mimedefang) X-Virus-Status: Clean X-archive-position: 522 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: chas@cmf.nrl.navy.mil Precedence: bulk X-list: netdev Content-Length: 13994 Lines: 463 please apply to 2.6 -- thanks! # This is a BitKeeper generated diff -Nru style patch. # # ChangeSet # 2005/03/22 15:26:29-05:00 chas@relax.cmf.nrl.navy.mil # [ATM]: assorted cleanups # # Signed-off-by: Adrian Bunk # Signed-off-by: Chas Williams # # net/atm/raw.c # 2005/03/22 15:26:10-05:00 chas@relax.cmf.nrl.navy.mil +1 -1 # [ATM]: assorted cleanups # # Signed-off-by: Adrian Bunk # Signed-off-by: Chas Williams # # net/atm/protocols.h # 2005/03/22 15:26:10-05:00 chas@relax.cmf.nrl.navy.mil +0 -2 # [ATM]: assorted cleanups # # Signed-off-by: Adrian Bunk # Signed-off-by: Chas Williams # # net/atm/pppoatm.c # 2005/03/22 15:26:10-05:00 chas@relax.cmf.nrl.navy.mil +1 -1 # [ATM]: assorted cleanups # # Signed-off-by: Adrian Bunk # Signed-off-by: Chas Williams # # net/atm/mpc.h # 2005/03/22 15:26:10-05:00 chas@relax.cmf.nrl.navy.mil +0 -4 # [ATM]: assorted cleanups # # Signed-off-by: Adrian Bunk # Signed-off-by: Chas Williams # # net/atm/mpc.c # 2005/03/22 15:26:10-05:00 chas@relax.cmf.nrl.navy.mil +3 -3 # [ATM]: assorted cleanups # # Signed-off-by: Adrian Bunk # Signed-off-by: Chas Williams # # net/atm/lec_arpc.h # 2005/03/22 15:26:10-05:00 chas@relax.cmf.nrl.navy.mil +0 -24 # [ATM]: assorted cleanups # # Signed-off-by: Adrian Bunk # Signed-off-by: Chas Williams # # net/atm/lec.h # 2005/03/22 15:26:10-05:00 chas@relax.cmf.nrl.navy.mil +0 -9 # [ATM]: assorted cleanups # # Signed-off-by: Adrian Bunk # Signed-off-by: Chas Williams # # net/atm/lec.c # 2005/03/22 15:26:10-05:00 chas@relax.cmf.nrl.navy.mil +45 -38 # [ATM]: assorted cleanups # # Signed-off-by: Adrian Bunk # Signed-off-by: Chas Williams # # net/atm/common.c # 2005/03/22 15:26:10-05:00 chas@relax.cmf.nrl.navy.mil +1 -1 # [ATM]: assorted cleanups # # Signed-off-by: Adrian Bunk # Signed-off-by: Chas Williams # diff -Nru a/net/atm/common.c b/net/atm/common.c --- a/net/atm/common.c 2005-03-22 19:49:03 -05:00 +++ b/net/atm/common.c 2005-03-22 19:49:03 -05:00 @@ -41,7 +41,7 @@ struct hlist_head vcc_hash[VCC_HTABLE_SIZE]; DEFINE_RWLOCK(vcc_sklist_lock); -void __vcc_insert_socket(struct sock *sk) +static void __vcc_insert_socket(struct sock *sk) { struct atm_vcc *vcc = atm_sk(sk); struct hlist_head *head = &vcc_hash[vcc->vci & diff -Nru a/net/atm/lec.c b/net/atm/lec.c --- a/net/atm/lec.c 2005-03-22 19:49:03 -05:00 +++ b/net/atm/lec.c 2005-03-22 19:49:03 -05:00 @@ -80,6 +80,29 @@ static int lane2_associate_req (struct net_device *dev, u8 *lan_dst, u8 *tlvs, u32 sizeoftlvs); +static int lec_addr_delete(struct lec_priv *priv, unsigned char *atm_addr, + unsigned long permanent); +static void lec_arp_check_empties(struct lec_priv *priv, + struct atm_vcc *vcc, struct sk_buff *skb); +static void lec_arp_destroy(struct lec_priv *priv); +static void lec_arp_init(struct lec_priv *priv); +static struct atm_vcc* lec_arp_resolve(struct lec_priv *priv, + unsigned char *mac_to_find, + int is_rdesc, + struct lec_arp_table **ret_entry); +static void lec_arp_update(struct lec_priv *priv, unsigned char *mac_addr, + unsigned char *atm_addr, unsigned long remoteflag, + unsigned int targetless_le_arp); +static void lec_flush_complete(struct lec_priv *priv, unsigned long tran_id); +static int lec_mcast_make(struct lec_priv *priv, struct atm_vcc *vcc); +static void lec_set_flush_tran_id(struct lec_priv *priv, + unsigned char *atm_addr, + unsigned long tran_id); +static void lec_vcc_added(struct lec_priv *priv, struct atmlec_ioc *ioc_data, + struct atm_vcc *vcc, + void (*old_push)(struct atm_vcc *vcc, struct sk_buff *skb)); +static void lec_vcc_close(struct lec_priv *priv, struct atm_vcc *vcc); + static struct lane2_ops lane2_ops = { lane2_resolve, /* resolve, spec 3.1.3 */ lane2_associate_req, /* associate_req, spec 3.1.4 */ @@ -91,21 +114,6 @@ /* Device structures */ static struct net_device *dev_lec[MAX_LEC_ITF]; -/* This will be called from proc.c via function pointer */ -struct net_device *get_dev_lec(int itf) -{ - struct net_device *dev; - - if (itf >= MAX_LEC_ITF) - return NULL; - rtnl_lock(); - dev = dev_lec[itf]; - if (dev) - dev_hold(dev); - rtnl_unlock(); - return dev; -} - #if defined(CONFIG_BRIDGE) || defined(CONFIG_BRIDGE_MODULE) static void lec_handle_bridge(struct sk_buff *skb, struct net_device *dev) { @@ -152,7 +160,7 @@ * and returns NULL. */ #ifdef CONFIG_TR -unsigned char *get_tr_dst(unsigned char *packet, unsigned char *rdesc) +static unsigned char *get_tr_dst(unsigned char *packet, unsigned char *rdesc) { struct trh_hdr *trh; int riflen, num_rdsc; @@ -596,7 +604,7 @@ * LANE2: new argument struct sk_buff *data contains * the LE_ARP based TLVs introduced in the LANE2 spec */ -int +static int send_to_lecd(struct lec_priv *priv, atmlec_msg_type type, unsigned char *mac_addr, unsigned char *atm_addr, struct sk_buff *data) @@ -678,7 +686,7 @@ 0x01, 0x01 }; -void +static void lec_push(struct atm_vcc *vcc, struct sk_buff *skb) { struct net_device *dev = (struct net_device *)vcc->proto_data; @@ -761,7 +769,7 @@ } } -void +static void lec_pop(struct atm_vcc *vcc, struct sk_buff *skb) { struct lec_vcc_priv *vpriv = LEC_VCC_PRIV(vcc); @@ -781,7 +789,7 @@ } } -int +static int lec_vcc_attach(struct atm_vcc *vcc, void __user *arg) { struct lec_vcc_priv *vpriv; @@ -810,7 +818,7 @@ return 0; } -int +static int lec_mcast_attach(struct atm_vcc *vcc, int arg) { if (arg <0 || arg >= MAX_LEC_ITF || !dev_lec[arg]) @@ -820,7 +828,7 @@ } /* Initialize device. */ -int +static int lecd_attach(struct atm_vcc *vcc, int arg) { int i; @@ -1380,7 +1388,6 @@ static void lec_arp_check_expire(unsigned long data); static void lec_arp_expire_arp(unsigned long data); -void dump_arp_table(struct lec_priv *priv); /* * Arp table funcs @@ -1391,7 +1398,7 @@ /* * Initialization of arp-cache */ -void +static void lec_arp_init(struct lec_priv *priv) { unsigned short i; @@ -1407,7 +1414,7 @@ add_timer(&priv->lec_arp_timer); } -void +static void lec_arp_clear_vccs(struct lec_arp_table *entry) { if (entry->vcc) { @@ -1536,7 +1543,7 @@ } #endif -void +static void dump_arp_table(struct lec_priv *priv) { #if DEBUG_ARP_TABLE @@ -1688,7 +1695,7 @@ /* * Destruction of arp-cache */ -void +static void lec_arp_destroy(struct lec_priv *priv) { unsigned long flags; @@ -1950,9 +1957,9 @@ * Try to find vcc where mac_address is attached. * */ -struct atm_vcc* -lec_arp_resolve(struct lec_priv *priv, unsigned char *mac_to_find, int is_rdesc, - struct lec_arp_table **ret_entry) +static struct atm_vcc* +lec_arp_resolve(struct lec_priv *priv, unsigned char *mac_to_find, + int is_rdesc, struct lec_arp_table **ret_entry) { unsigned long flags; struct lec_arp_table *entry; @@ -2031,7 +2038,7 @@ return found; } -int +static int lec_addr_delete(struct lec_priv *priv, unsigned char *atm_addr, unsigned long permanent) { @@ -2061,7 +2068,7 @@ /* * Notifies: Response to arp_request (atm_addr != NULL) */ -void +static void lec_arp_update(struct lec_priv *priv, unsigned char *mac_addr, unsigned char *atm_addr, unsigned long remoteflag, unsigned int targetless_le_arp) @@ -2173,7 +2180,7 @@ /* * Notifies: Vcc setup ready */ -void +static void lec_vcc_added(struct lec_priv *priv, struct atmlec_ioc *ioc_data, struct atm_vcc *vcc, void (*old_push)(struct atm_vcc *vcc, struct sk_buff *skb)) @@ -2317,7 +2324,7 @@ spin_unlock_irqrestore(&priv->lec_arp_lock, flags); } -void +static void lec_flush_complete(struct lec_priv *priv, unsigned long tran_id) { unsigned long flags; @@ -2343,7 +2350,7 @@ dump_arp_table(priv); } -void +static void lec_set_flush_tran_id(struct lec_priv *priv, unsigned char *atm_addr, unsigned long tran_id) { @@ -2361,7 +2368,7 @@ spin_unlock_irqrestore(&priv->lec_arp_lock, flags); } -int +static int lec_mcast_make(struct lec_priv *priv, struct atm_vcc *vcc) { unsigned long flags; @@ -2398,7 +2405,7 @@ return err; } -void +static void lec_vcc_close(struct lec_priv *priv, struct atm_vcc *vcc) { unsigned long flags; @@ -2473,7 +2480,7 @@ dump_arp_table(priv); } -void +static void lec_arp_check_empties(struct lec_priv *priv, struct atm_vcc *vcc, struct sk_buff *skb) { diff -Nru a/net/atm/lec.h b/net/atm/lec.h --- a/net/atm/lec.h 2005-03-22 19:49:03 -05:00 +++ b/net/atm/lec.h 2005-03-22 19:49:03 -05:00 @@ -138,14 +138,5 @@ #define LEC_VCC_PRIV(vcc) ((struct lec_vcc_priv *)((vcc)->user_back)) -int lecd_attach(struct atm_vcc *vcc, int arg); -int lec_vcc_attach(struct atm_vcc *vcc, void __user *arg); -int lec_mcast_attach(struct atm_vcc *vcc, int arg); -struct net_device *get_dev_lec(int itf); -int send_to_lecd(struct lec_priv *priv, - atmlec_msg_type type, unsigned char *mac_addr, - unsigned char *atm_addr, struct sk_buff *data); -void lec_push(struct atm_vcc *vcc, struct sk_buff *skb); - #endif /* _LEC_H_ */ diff -Nru a/net/atm/lec_arpc.h b/net/atm/lec_arpc.h --- a/net/atm/lec_arpc.h 2005-03-22 19:49:03 -05:00 +++ b/net/atm/lec_arpc.h 2005-03-22 19:49:03 -05:00 @@ -89,28 +89,4 @@ #define LEC_REMOTE_FLAG 0x0001 #define LEC_PERMANENT_FLAG 0x0002 -/* Protos */ -void lec_arp_init(struct lec_priv *priv); -int lec_mcast_make(struct lec_priv *priv, struct atm_vcc *vcc); -void lec_arp_destroy(struct lec_priv *priv); -void lec_vcc_close(struct lec_priv *priv, struct atm_vcc *vcc); - -struct atm_vcc *lec_arp_resolve(struct lec_priv *priv, - unsigned char *mac_to_addr, - int is_rdesc, - struct lec_arp_table **ret_entry); -void lec_vcc_added(struct lec_priv *dev, - struct atmlec_ioc *ioc_data, struct atm_vcc *vcc, - void (*old_push)(struct atm_vcc *vcc, struct sk_buff *skb)); -void lec_arp_check_empties(struct lec_priv *priv, - struct atm_vcc *vcc, struct sk_buff *skb); -int lec_addr_delete(struct lec_priv *priv, - unsigned char *mac_addr, unsigned long permanent); -void lec_flush_complete(struct lec_priv *priv, unsigned long tran_id); -void lec_arp_update(struct lec_priv *priv, - unsigned char *mac_addr, unsigned char *atm_addr, - unsigned long remoteflag, unsigned int targetless_le_arp); -void lec_set_flush_tran_id(struct lec_priv *priv, - unsigned char *mac_addr, unsigned long tran_id); - #endif diff -Nru a/net/atm/mpc.c b/net/atm/mpc.c --- a/net/atm/mpc.c 2005-03-22 19:49:03 -05:00 +++ b/net/atm/mpc.c 2005-03-22 19:49:03 -05:00 @@ -564,7 +564,7 @@ return retval; } -int atm_mpoa_vcc_attach(struct atm_vcc *vcc, void __user *arg) +static int atm_mpoa_vcc_attach(struct atm_vcc *vcc, void __user *arg) { int bytes_left; struct mpoa_client *mpc; @@ -753,7 +753,7 @@ /* members not explicitly initialised will be 0 */ }; -int atm_mpoa_mpoad_attach (struct atm_vcc *vcc, int arg) +static int atm_mpoa_mpoad_attach (struct atm_vcc *vcc, int arg) { struct mpoa_client *mpc; struct lec_priv *priv; @@ -1460,7 +1460,7 @@ return 0; } -void __exit atm_mpoa_cleanup(void) +static void __exit atm_mpoa_cleanup(void) { struct mpoa_client *mpc, *tmp; struct atm_mpoa_qos *qos, *nextqos; diff -Nru a/net/atm/mpc.h b/net/atm/mpc.h --- a/net/atm/mpc.h 2005-03-22 19:49:03 -05:00 +++ b/net/atm/mpc.h 2005-03-22 19:49:03 -05:00 @@ -11,10 +11,6 @@ /* kernel -> mpc-daemon */ int msg_to_mpoad(struct k_message *msg, struct mpoa_client *mpc); -/* Functions for ioctl(ATMMPC_*) operations */ -int atm_mpoa_mpoad_attach(struct atm_vcc *vcc, int arg); -int atm_mpoa_vcc_attach(struct atm_vcc *vcc, void __user *arg); - struct mpoa_client { struct mpoa_client *next; struct net_device *dev; /* lec in question */ diff -Nru a/net/atm/pppoatm.c b/net/atm/pppoatm.c --- a/net/atm/pppoatm.c 2005-03-22 19:49:03 -05:00 +++ b/net/atm/pppoatm.c 2005-03-22 19:49:03 -05:00 @@ -345,7 +345,7 @@ return -ENOIOCTLCMD; } -struct atm_ioctl pppoatm_ioctl_ops = { +static struct atm_ioctl pppoatm_ioctl_ops = { .owner = THIS_MODULE, .ioctl = pppoatm_ioctl, }; diff -Nru a/net/atm/protocols.h b/net/atm/protocols.h --- a/net/atm/protocols.h 2005-03-22 19:49:03 -05:00 +++ b/net/atm/protocols.h 2005-03-22 19:49:03 -05:00 @@ -6,8 +6,6 @@ #ifndef NET_ATM_PROTOCOLS_H #define NET_ATM_PROTOCOLS_H -void atm_push_raw(struct atm_vcc *vcc,struct sk_buff *skb); - int atm_init_aal0(struct atm_vcc *vcc); /* "raw" AAL0 */ int atm_init_aal34(struct atm_vcc *vcc);/* "raw" AAL3/4 transport */ int atm_init_aal5(struct atm_vcc *vcc); /* "raw" AAL5 transport */ diff -Nru a/net/atm/raw.c b/net/atm/raw.c --- a/net/atm/raw.c 2005-03-22 19:49:03 -05:00 +++ b/net/atm/raw.c 2005-03-22 19:49:03 -05:00 @@ -25,7 +25,7 @@ * SKB == NULL indicates that the link is being closed */ -void atm_push_raw(struct atm_vcc *vcc,struct sk_buff *skb) +static void atm_push_raw(struct atm_vcc *vcc,struct sk_buff *skb) { if (skb) { struct sock *sk = sk_atm(vcc); From afleming@freescale.com Tue Mar 22 17:22:02 2005 Received: with ECARTIS (v1.0.0; list netdev); Tue, 22 Mar 2005 17:22:06 -0800 (PST) Received: from az33egw01.freescale.net (az33egw01.freescale.net [192.88.158.102]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j2N1M2M2010512 for ; Tue, 22 Mar 2005 17:22:02 -0800 Received: from az33smr02.freescale.net (az33smr02.freescale.net [10.64.34.200]) by az33egw01.freescale.net (8.12.11/az33egw01) with ESMTP id j2N1OUxH005208; Tue, 22 Mar 2005 18:24:30 -0700 (MST) Received: from [10.82.16.201] ([10.82.16.201]) by az33smr02.freescale.net (8.13.1/8.13.0) with ESMTP id j2N1NR1u028583; Tue, 22 Mar 2005 19:23:27 -0600 (CST) In-Reply-To: <4240A9F3.5040704@pobox.com> References: <20050322231746.GA27770@xyzzy> <4240A9F3.5040704@pobox.com> Mime-Version: 1.0 (Apple Message framework v619.2) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <212e5bf54766a68d2ab8716574225203@freescale.com> Content-Transfer-Encoding: 7bit Cc: Dale Farnsworth , James Chapman , Netdev From: Andy Fleming Subject: Re: [PATCH: 2.6.12-rc1] mii: Add test for GigE support Date: Tue, 22 Mar 2005 19:21:56 -0600 To: Jeff Garzik X-Mailer: Apple Mail (2.619.2) X-Virus-Scanned: ClamAV 0.83/778/Mon Mar 21 02:48:43 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 523 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: afleming@freescale.com Precedence: bulk X-list: netdev Content-Length: 736 Lines: 28 On Mar 22, 2005, at 17:27, Jeff Garzik wrote: >> +int mii_check_gmii_support(struct mii_if_info *mii) >> +{ >> + int reg; >> + >> + reg = mii->mdio_read(mii->dev, mii->phy_id, MII_BMSR); >> + if (reg & BMSR_HAS_EXTSTAT1000) { >> + reg = mii->mdio_read(mii->dev, mii->phy_id, MII_EXTSTAT1000); >> + if (reg & (ESR_1000_BASE_X_FD | ESR_1000_BASE_T_FD | >> + ESR_1000_BASE_X_HD | ESR_1000_BASE_T_HD)) >> + return 1; >> + } >> + >> + return 0; > > 2) Reading a non-existent register will return all 1's in most cases, > so I am not sure if this is the best test. He reads a standard register (BMSR) to determine whether or not EXTSTAT1000 exists. This is part of the 802.3 standard, so it should work. Andy Andy Fleming From kaber@trash.net Tue Mar 22 17:32:11 2005 Received: with ECARTIS (v1.0.0; list netdev); Tue, 22 Mar 2005 17:32:15 -0800 (PST) Received: from kaber.coreworks.de ([62.206.217.67]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j2N1WA3Z011292 for ; Tue, 22 Mar 2005 17:32:11 -0800 Received: from localhost ([127.0.0.1]) by kaber.coreworks.de with esmtp (Exim 4.50) id 1DDuj0-0003o9-7Q; Wed, 23 Mar 2005 02:31:58 +0100 Message-ID: <4240C70E.8060503@trash.net> Date: Wed, 23 Mar 2005 02:31:58 +0100 From: Patrick McHardy User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.7.5) Gecko/20050106 Debian/1.7.5-1 X-Accept-Language: en MIME-Version: 1.0 To: hadi@cyberus.ca CC: Andy Furniss , Harald Welte , Remus , netdev@oss.sgi.com, Nguyen Dinh Nam , Andre Tomt , syrius.ml@no-log.org, Damion de Soto , Netfilter Development Mailinglist Subject: Re: iptables breakage WAS(Re: dummy as IMQ replacement References: <1107123123.8021.80.camel@jzny.localdomain> <0fcf01c5077f$579e4b80$6e69690a@RIMAS> <1107174142.8021.121.camel@jzny.localdomain> <00c301c524b4$938cd240$6e69690a@RIMAS> <1110379135.1091.143.camel@jzny.localdomain> <1110416767.1111.76.camel@jzny.localdomain> <025501c52552$2dbf87c0$6e69690a@RIMAS> <1110453757.1108.87.camel@jzny.localdomain> <423B7BCB.10400@dsl.pipex.com> <1111410890.1092.195.camel@jzny.localdomain> In-Reply-To: <1111410890.1092.195.camel@jzny.localdomain> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV 0.83/778/Mon Mar 21 02:48:43 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 524 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: kaber@trash.net Precedence: bulk X-list: netdev Content-Length: 668 Lines: 16 jamal wrote: > As i was suspecting this is related to iptables breaking backwards > compatibility. Starting with 1.3.0 the target structure changed ;-> > (right at the top is a new field called version) > I suspect the iptables folks maybe unaware that there are other users of > iptables and assume that anyone needing to use new iptables will > recompile everything from scratch. BAD! BAD! > I am ccing the necessary evil doers (Harald and Patrick - at least they > would know who the real evildoer is). We'll try to keep this in mind in the future. We could move the version field to the end, but I guess its already too late. What do you think? Regards Patrick From jgarzik@pobox.com Tue Mar 22 17:46:39 2005 Received: with ECARTIS (v1.0.0; list netdev); Tue, 22 Mar 2005 17:46:46 -0800 (PST) Received: from parcelfarce.linux.theplanet.co.uk (IDENT:93@parcelfarce.linux.theplanet.co.uk [195.92.249.252]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j2N1kc7S012230 for ; Tue, 22 Mar 2005 17:46:39 -0800 Received: from cpe-069-134-152-124.nc.rr.com ([69.134.152.124] helo=[10.10.10.88]) by parcelfarce.linux.theplanet.co.uk with asmtp (TLSv1:AES256-SHA:256) (Exim 4.33) id 1DDuxA-0005nO-0M; Wed, 23 Mar 2005 01:46:36 +0000 Message-ID: <4240CA69.9020902@pobox.com> Date: Tue, 22 Mar 2005 20:46:17 -0500 From: Jeff Garzik User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.3) Gecko/20040922 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Netdev CC: Linux Kernel , James Ketrenos , Jouni Malinen , "Luis R. Rodriguez" , "David S. Miller" Subject: 2.6.x wireless update and status Content-Type: multipart/mixed; boundary="------------060906070504060809050909" X-Virus-Scanned: ClamAV 0.83/778/Mon Mar 21 02:48:43 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 525 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: jgarzik@pobox.com Precedence: bulk X-list: netdev Content-Length: 7672 Lines: 190 This is a multi-part message in MIME format. --------------060906070504060809050909 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Just updated the wireless-2.6 queue to include a HostAP update, and to add Wireless Extensions 18 (WPA). See attached for BK info, patch info, and changelog. I also wanted to comment on the general status and direction of wireless. So far, the following decisions have been made: 1) Use HostAP as the basis for a wireless stack that can drive "softMAC" wireless hardware. 2) We want wireless to be better integrated into the network stack, rather than "faking" 802.3 ethernet. 3) The in-kernel Wireless Extensions API will see some changes, to be more type-safe (and more like other Linux APIs). Userland ABI compatibility is desired, but don't care about kernel API compatibility. Along these lines, the following work has been done: * HostAP has been integrated into wireless-2.6, and Jouni has been updating it. * Intel submitted the HostAP-derived ieee80211 lib code. * DaveM posted some template code[1] that hackers can use as a starting point for true wireless protocol/management code. * A few people have submitted some wireless cleanup patches associated with this. Moving forward, the next "todo" for kernel wireless hackers is to get ieee80211 common code lib into shape, namely: * Merge Intel ipw drivers, which use ieee80211 * Update HostAP to use ieee80211 * Merge/convert other drivers to use ieee80211? At that point, ieee80211 has in-tree users, and I can push both the ipw and HostAP drivers upstream. After that milestone, working on the wireless protocol layer (DaveM code template) and improving the in-kernel WE API will be key focus. There is one minor point of contention so far. Jouni stated he prefers that HostAP go upstream before it gets updated to use ieee80211. I respectfully disagree, and prefer that HostAP is updated -first- to use the ieee80211 lib, before going upstream. Jeff P.S. For Realtek RTL8180 owners, I'm hoping to have some time in the next month or two to flesh out a driver that uses the ieee80211 lib in the wireless-2.6 queue. [1] http://www.kernel.org/pub/linux/kernel/people/jgarzik/patchkits/2.6/davem-p80211.tar.bz2 --------------060906070504060809050909 Content-Type: text/plain; name="changelog.txt" Content-Transfer-Encoding: 8bit Content-Disposition: inline; filename="changelog.txt" BK users: bk pull bk://gkernel.bkbits.net/wireless-2.6 Patch: http://www.kernel.org/pub/linux/kernel/people/jgarzik/patchkits/2.6/2.6.12-rc1-bk1-wireless1.patch.bz2 This will update the following files: drivers/net/wireless/ieee802_11.h | 78 MAINTAINERS | 7 drivers/net/wireless/Kconfig | 2 drivers/net/wireless/Makefile | 2 drivers/net/wireless/atmel.c | 62 drivers/net/wireless/hostap/Kconfig | 104 drivers/net/wireless/hostap/Makefile | 8 drivers/net/wireless/hostap/hostap.c | 1205 +++++++ drivers/net/wireless/hostap/hostap.h | 57 drivers/net/wireless/hostap/hostap_80211.h | 107 drivers/net/wireless/hostap/hostap_80211_rx.c | 1084 ++++++ drivers/net/wireless/hostap/hostap_80211_tx.c | 522 +++ drivers/net/wireless/hostap/hostap_ap.c | 3286 +++++++++++++++++++ drivers/net/wireless/hostap/hostap_ap.h | 272 + drivers/net/wireless/hostap/hostap_common.h | 557 +++ drivers/net/wireless/hostap/hostap_config.h | 86 drivers/net/wireless/hostap/hostap_crypt.c | 167 drivers/net/wireless/hostap/hostap_crypt.h | 50 drivers/net/wireless/hostap/hostap_crypt_ccmp.c | 486 ++ drivers/net/wireless/hostap/hostap_crypt_tkip.c | 696 ++++ drivers/net/wireless/hostap/hostap_crypt_wep.c | 281 + drivers/net/wireless/hostap/hostap_cs.c | 929 +++++ drivers/net/wireless/hostap/hostap_download.c | 766 ++++ drivers/net/wireless/hostap/hostap_hw.c | 3631 +++++++++++++++++++++ drivers/net/wireless/hostap/hostap_info.c | 478 ++ drivers/net/wireless/hostap/hostap_ioctl.c | 4116 ++++++++++++++++++++++++ drivers/net/wireless/hostap/hostap_pci.c | 453 ++ drivers/net/wireless/hostap/hostap_plx.c | 612 +++ drivers/net/wireless/hostap/hostap_proc.c | 466 ++ drivers/net/wireless/hostap/hostap_wlan.h | 1075 ++++++ drivers/net/wireless/orinoco.c | 11 drivers/net/wireless/wl3501.h | 4 include/linux/wireless.h | 283 + include/net/ieee80211.h | 887 +++++ include/net/ieee80211_crypt.h | 86 net/Kconfig | 2 net/Makefile | 1 net/core/wireless.c | 74 net/ieee80211/Kconfig | 67 net/ieee80211/Makefile | 11 net/ieee80211/ieee80211_crypt.c | 259 + net/ieee80211/ieee80211_crypt_ccmp.c | 470 ++ net/ieee80211/ieee80211_crypt_tkip.c | 708 ++++ net/ieee80211/ieee80211_crypt_wep.c | 272 + net/ieee80211/ieee80211_module.c | 268 + net/ieee80211/ieee80211_rx.c | 1206 +++++++ net/ieee80211/ieee80211_tx.c | 448 ++ net/ieee80211/ieee80211_wx.c | 471 ++ 48 files changed, 27052 insertions(+), 121 deletions(-) through these ChangeSets: : o ieee80211 subsystem : o wireless-2.6 cleanup Adrian Bunk: o net/ieee80211/Kconfig: don't describe what gets selected Alexander Viro: o hostap __user annotations François Romieu: o ieee80211: offset_in_page() removal o ieee80211: C99 initialization for eap_types o ieee80211: failure of ieee80211_crypto_init() Jean Tourrilhes: o Wireless Extensions 18 (aka WPA) Jeff Garzik: o [wireless hostap] update for new pci_save_state() Joshua Kwan: o hostap: fix Kconfig typos and missing select CRYPTO Jouni Malinen: o hostap: Update to use the new WE18 proposal o hostap: Filter disconnect events o hostap: Improved suspend o hostap: Rate limiting for debug messages o hostap: Clear station statistic on accounting start o hostap: Fix procfs rmdir after ifname change o hostap: Add support for multi-func SanDisk ConnectPlus o hostap: Disable interrupts before Genesis mode o hostap: Include asm/io.h o hostap: Clear station statistic on accounting start o Host AP: Replaced MODULE_PARM with module_param* o Host AP: Replaced direct dev->priv references with netdev_priv(dev) o Host AP: Updated to use Linux wireless extensions v17 o Host AP: pci_register_driver() return value changes o Host AP: Fix netif_carrier_off() in non-client modes o Host AP: Fix PRISM2_IO_DEBUG o Host AP: Use void __iomem * with {read,write}{b,w} o Host AP: Fix card enabling after firmware download o Host AP: Do not bridge packets to unauthorized ports o Host AP: Fix compilation with PRISM2_NO_STATION_MODES defined o Host AP: Prevent STAs from associating using AP address o Host AP: Fix hw address changing for wifi# interface o Host AP: Remove ioctl debug messages o Host AP: Ignore (Re)AssocResp messages silently o Host AP: Fix interface packet counters o Host AP: Disable EAPOL TX/RX debug messages o fix hostap crypto bugs o Add HostAP wireless driver --------------060906070504060809050909-- From jgarzik@pobox.com Tue Mar 22 17:47:53 2005 Received: with ECARTIS (v1.0.0; list netdev); Tue, 22 Mar 2005 17:47:57 -0800 (PST) Received: from parcelfarce.linux.theplanet.co.uk (IDENT:93@parcelfarce.linux.theplanet.co.uk [195.92.249.252]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j2N1lqup012502 for ; Tue, 22 Mar 2005 17:47:52 -0800 Received: from cpe-069-134-152-124.nc.rr.com ([69.134.152.124] helo=[10.10.10.88]) by parcelfarce.linux.theplanet.co.uk with asmtp (TLSv1:AES256-SHA:256) (Exim 4.33) id 1DDuyN-0005pW-Na; Wed, 23 Mar 2005 01:47:51 +0000 Message-ID: <4240CABB.5090701@pobox.com> Date: Tue, 22 Mar 2005 20:47:39 -0500 From: Jeff Garzik User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.3) Gecko/20040922 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Andy Fleming CC: Dale Farnsworth , James Chapman , Netdev Subject: Re: [PATCH: 2.6.12-rc1] mii: Add test for GigE support References: <20050322231746.GA27770@xyzzy> <4240A9F3.5040704@pobox.com> <212e5bf54766a68d2ab8716574225203@freescale.com> In-Reply-To: <212e5bf54766a68d2ab8716574225203@freescale.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV 0.83/778/Mon Mar 21 02:48:43 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 526 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: jgarzik@pobox.com Precedence: bulk X-list: netdev Content-Length: 964 Lines: 35 Andy Fleming wrote: > > On Mar 22, 2005, at 17:27, Jeff Garzik wrote: > >>> +int mii_check_gmii_support(struct mii_if_info *mii) >>> +{ >>> + int reg; >>> + >>> + reg = mii->mdio_read(mii->dev, mii->phy_id, MII_BMSR); >>> + if (reg & BMSR_HAS_EXTSTAT1000) { >>> + reg = mii->mdio_read(mii->dev, mii->phy_id, MII_EXTSTAT1000); >>> + if (reg & (ESR_1000_BASE_X_FD | ESR_1000_BASE_T_FD | >>> + ESR_1000_BASE_X_HD | ESR_1000_BASE_T_HD)) >>> + return 1; >>> + } >>> + >>> + return 0; >> >> >> 2) Reading a non-existent register will return all 1's in most cases, >> so I am not sure if this is the best test. > > > He reads a standard register (BMSR) to determine whether or not > EXTSTAT1000 exists. This is part of the 802.3 standard, so it should work. Whoops, I read the patch incorrectly, and thought he read an extended register. Objection removed. Still need an EXPORT_SYMBOL() though. Jeff From jgarzik@pobox.com Tue Mar 22 18:16:07 2005 Received: with ECARTIS (v1.0.0; list netdev); Tue, 22 Mar 2005 18:16:11 -0800 (PST) Received: from parcelfarce.linux.theplanet.co.uk (IDENT:93@parcelfarce.linux.theplanet.co.uk [195.92.249.252]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j2N2G68J014892 for ; Tue, 22 Mar 2005 18:16:06 -0800 Received: from cpe-069-134-152-124.nc.rr.com ([69.134.152.124] helo=[10.10.10.88]) by parcelfarce.linux.theplanet.co.uk with asmtp (TLSv1:AES256-SHA:256) (Exim 4.33) id 1DDvPg-0006Gm-WE; Wed, 23 Mar 2005 02:16:05 +0000 Message-ID: <4240D158.1060302@pobox.com> Date: Tue, 22 Mar 2005 21:15:52 -0500 From: Jeff Garzik User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.3) Gecko/20040922 X-Accept-Language: en-us, en MIME-Version: 1.0 To: "Luis R. Rodriguez" CC: Netdev , Dan Williams , vkondra@mail.ru, Linux Kernel Subject: Re: wireless 2.6 work References: <20050310025036.GE17854@ruslug.rutgers.edu> In-Reply-To: <20050310025036.GE17854@ruslug.rutgers.edu> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV 0.83/778/Mon Mar 21 02:48:43 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 527 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: jgarzik@pobox.com Precedence: bulk X-list: netdev Content-Length: 2036 Lines: 49 Luis R. Rodriguez wrote: > Jeff, > > I'm sick off the low activiity and slow support on wireless we have. I > know you're busy so I wanted to offer my help in helping around work on > wireless-2.6, now that I have time after work, and before I commit > myself to anything else. It's a bit suicidal, but oh well. Oh yeah and > I'll also start using bitkeeper due to the recent clarifications on the > license of its usage. Great! While I think BitKeeper is useful, you are more than welcome to continue sending patches. To wireless developers, BitKeeper will mainly be of use in sync'ing with the latest wireless-2.6 tree. > I'll willing to review as much patches as I have to and also hopefully > write documentation on writing new wireless drivers. That said, if I can > be of any assistance, where what you like me to start on? > > Here's what's on my agenda so far: > > * Help cleanup new ralink driver, start using ieee802211 and get into wireless-2.6. > * Push prism54's new WPA and WDS support into wireless-2.6 > * Start seeing what I can use off of ieee80211 for prism54, clean it, > and move to wireless-2.6 > * Start incorporating WPA through wpa_supplicant onto as many drivers > * Start standardizing all things a bit, as bitched about and well pointed out > by Dan Williams > * Listen to Jouni, he's the man Well, all this sounds good to me. See also the 'status' post I just made, and the 'note on wireless development process' I am about to write. I'm really hoping someone will look into integrating wireless 802.11 as a "real" protocol, rather than faking ethernet. This work starts with the "p80211" template DaveM provided, and hopefully continues with Vladimir's updates of DaveM's code (did he post those anywhere?). There are also issues such as ARP types that Dan Williams mentioned to me as issues. The "integrate wireless into net stack" work requires a very self-motivated person who is willing to poke into the net stack, and answer their own questions. Jeff From kaber@trash.net Tue Mar 22 18:20:27 2005 Received: with ECARTIS (v1.0.0; list netdev); Tue, 22 Mar 2005 18:20:33 -0800 (PST) Received: from kaber.coreworks.de ([62.206.217.67]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j2N2KQbl015529 for ; Tue, 22 Mar 2005 18:20:26 -0800 Received: from localhost ([127.0.0.1]) by kaber.coreworks.de with esmtp (Exim 4.50) id 1DDvTq-0004Ti-Dm; Wed, 23 Mar 2005 03:20:22 +0100 Message-ID: <4240D266.4080403@trash.net> Date: Wed, 23 Mar 2005 03:20:22 +0100 From: Patrick McHardy User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.7.5) Gecko/20050106 Debian/1.7.5-1 X-Accept-Language: en MIME-Version: 1.0 To: Andrew Morton CC: netdev@oss.sgi.com, o.cornu@gmail.com, paulus@samba.org Subject: Re: Fw: [Bugme-new] [Bug 4381] New: When i try to start a pppoe conn., crash at net/core/skbuff.c:91 References: <20050321201150.39ba3467.akpm@osdl.org> In-Reply-To: <20050321201150.39ba3467.akpm@osdl.org> Content-Type: multipart/mixed; boundary="------------070500070604000205000301" X-Virus-Scanned: ClamAV 0.83/778/Mon Mar 21 02:48:43 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 528 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: kaber@trash.net Precedence: bulk X-list: netdev Content-Length: 1454 Lines: 51 This is a multi-part message in MIME format. --------------070500070604000205000301 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Andrew Morton wrote: > Repeatable pppoe crash :( > > > Begin forwarded message: > > http://bugme.osdl.org/show_bug.cgi?id=4381 > > Summary: When i try to start a pppoe conn., crash at > net/core/skbuff.c:91 > Kernel Version: 2.6.11 (gentoo-dev-sources) > Status: NEW > Severity: blocking > Owner: shemminger@osdl.org > Submitter: o.cornu@gmail.com > > Mar 21 21:28:05 Pai-mei <6>skput:over: f89b2335:16 put:16 > dev: Looks like hdrlen is uninitialized in ppp_async. This patch initializes it to 2 like in ppp_synctty, but I'm not sure whether this value is correct here. Paul? Signed-off-by: Patrick McHardy --------------070500070604000205000301 Content-Type: text/plain; name="x" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="x" ===== drivers/net/ppp_async.c 1.26 vs edited ===== --- 1.26/drivers/net/ppp_async.c 2005-01-21 06:02:12 +01:00 +++ edited/drivers/net/ppp_async.c 2005-03-23 03:15:31 +01:00 @@ -183,6 +183,7 @@ ap->chan.private = ap; ap->chan.ops = &async_ops; ap->chan.mtu = PPP_MRU; + ap->chan.hdrlen = 2; err = ppp_register_channel(&ap->chan); if (err) goto out_free; --------------070500070604000205000301-- From kaber@trash.net Tue Mar 22 18:27:40 2005 Received: with ECARTIS (v1.0.0; list netdev); Tue, 22 Mar 2005 18:27:44 -0800 (PST) Received: from kaber.coreworks.de ([62.206.217.67]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j2N2RdGD016193 for ; Tue, 22 Mar 2005 18:27:39 -0800 Received: from localhost ([127.0.0.1]) by kaber.coreworks.de with esmtp (Exim 4.50) id 1DDvah-0004Ud-Vf; Wed, 23 Mar 2005 03:27:28 +0100 Message-ID: <4240D40F.107@trash.net> Date: Wed, 23 Mar 2005 03:27:27 +0100 From: Patrick McHardy User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.7.5) Gecko/20050106 Debian/1.7.5-1 X-Accept-Language: en MIME-Version: 1.0 To: hadi@znyx.com CC: "David S. Miller" , netdev@oss.sgi.com, Thomas Graf Subject: Re: patch: introduce simple actions References: <1111345551.1095.82.camel@jzny.localdomain> <423DCD8C.6030100@trash.net> <1111347345.1094.98.camel@jzny.localdomain> <423DD5E6.2020708@trash.net> <1111349853.1093.136.camel@jzny.localdomain> In-Reply-To: <1111349853.1093.136.camel@jzny.localdomain> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV 0.83/778/Mon Mar 21 02:48:43 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 529 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: kaber@trash.net Precedence: bulk X-list: netdev Content-Length: 985 Lines: 22 Jamal Hadi Salim wrote: > Unfortunately code "augmentation"( as opposed to inheritance - cant > think of a better word) is much easier to do this way. The benefit of it > is the user gets a very simple programming interface - which is the main > reason this was written to begin with. The standard interface exists, > and more versed people or someone wanting to write something complex can > go that path. At some point i would like to document all this stuff. I don't think that a simple interface and this cleanup conflict with each other. > How about this: > I submit this patch (with Thomas cleanup) and the simple action. I will > hold onto the 4 other actions i already have some of them complete until > you get around to moving things around and then i will redo them to > conform. This gets it off my back and we dont have any miscommunication > of what you are trying to do. sounds fair? Go ahead, it will be a while before I continue with the cleanups. Regards Patrick From jgarzik@pobox.com Tue Mar 22 18:29:32 2005 Received: with ECARTIS (v1.0.0; list netdev); Tue, 22 Mar 2005 18:29:36 -0800 (PST) Received: from parcelfarce.linux.theplanet.co.uk (IDENT:93@parcelfarce.linux.theplanet.co.uk [195.92.249.252]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j2N2TVDa016616 for ; Tue, 22 Mar 2005 18:29:31 -0800 Received: from cpe-069-134-152-124.nc.rr.com ([69.134.152.124] helo=[10.10.10.88]) by parcelfarce.linux.theplanet.co.uk with asmtp (TLSv1:AES256-SHA:256) (Exim 4.33) id 1DDvcf-0006X2-W6; Wed, 23 Mar 2005 02:29:30 +0000 Message-ID: <4240D47C.8090707@pobox.com> Date: Tue, 22 Mar 2005 21:29:16 -0500 From: Jeff Garzik User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.3) Gecko/20040922 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Netdev CC: Linux Kernel , "David S. Miller" Subject: Note on wireless development process Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV 0.83/778/Mon Mar 21 02:48:43 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 530 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: jgarzik@pobox.com Precedence: bulk X-list: netdev Content-Length: 1351 Lines: 31 Just a general note... like many other areas of the kernel, there is no wireless roadmap. There is a set of technical criteria (see '2.6.x wireless update and status' post), but there is no One True Path to follow to get there. People interested in working on wireless need to be their own guides, and find their own path. There has been endless discussion on wireless, and not much movement. So asking questions without attaching a patch won't get very far. The general process is just like any other kernel development process: post a patch, get feedback, revise patch, lather rinse repeat. Don't wait for DaveM or me to suddenly post reams of wireless code. I'm speculating about David's time, but I'm just too darned busy. David and I play the roles of reviewer and advisor. It's up to YOU to "scratch the itch" and get world-class wireless support into Linux. With regards to development process, the main point of coordination is the wireless-2.6 queue itself, not a human. Look at the wireless-2.6 tree, consider what your next step is, and go there. Don't bother thinking too much about code outside that tree (and upstream). Please direct questions and comments to the netdev@oss.sgi.com mailing list, rather than privately emailing me or DaveM. That way knowledge is shared, debated, and archived. Jeff From kaber@trash.net Tue Mar 22 18:29:36 2005 Received: with ECARTIS (v1.0.0; list netdev); Tue, 22 Mar 2005 18:29:40 -0800 (PST) Received: from kaber.coreworks.de ([62.206.217.67]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j2N2TZrW016615 for ; Tue, 22 Mar 2005 18:29:36 -0800 Received: from localhost ([127.0.0.1]) by kaber.coreworks.de with esmtp (Exim 4.50) id 1DDvc9-0004Uk-KJ; Wed, 23 Mar 2005 03:28:57 +0100 Message-ID: <4240D469.2050500@trash.net> Date: Wed, 23 Mar 2005 03:28:57 +0100 From: Patrick McHardy User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.7.5) Gecko/20050106 Debian/1.7.5-1 X-Accept-Language: en MIME-Version: 1.0 To: Herbert Xu CC: "David S. Miller" , netdev@oss.sgi.com Subject: Re: IPsec xfrm resolution References: <420B9DF1.3020704@trash.net> <20050210202810.GA1609@gondor.apana.org.au> <42144C3F.2060501@trash.net> <20050217091137.GA9476@gondor.apana.org.au> <42152841.5000707@trash.net> <20050218100854.GA19427@gondor.apana.org.au> <4216D6B4.5070901@trash.net> <20050219092314.GA8153@gondor.apana.org.au> <20050317203231.1b649f60.davem@davemloft.net> <423D9BFB.2090309@trash.net> <20050320203841.GA29078@gondor.apana.org.au> In-Reply-To: <20050320203841.GA29078@gondor.apana.org.au> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV 0.83/778/Mon Mar 21 02:48:43 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 531 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: kaber@trash.net Precedence: bulk X-list: netdev Content-Length: 389 Lines: 14 Herbert Xu wrote: > On Sun, Mar 20, 2005 at 04:51:23PM +0100, Patrick McHardy wrote: > >>Not yet, I've put it on hold after clashing with Herbert's MTU work. >>I'll have a few free days this week where I will continue to work >>on this. > > I've completed the first stage of the MTU work so please feel free to > send patches through. I'll send something this weekend. Regards Patrick From davem@davemloft.net Tue Mar 22 18:34:57 2005 Received: with ECARTIS (v1.0.0; list netdev); Tue, 22 Mar 2005 18:35:03 -0800 (PST) Received: from cheetah.davemloft.net (mail@dsl027-180-174.sfo1.dsl.speakeasy.net [216.27.180.174]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j2N2Yv3b018007 for ; Tue, 22 Mar 2005 18:34:57 -0800 Received: from localhost ([127.0.0.1] helo=cheetah.davemloft.net ident=davem) by cheetah.davemloft.net with smtp (Exim 3.36 #1 (Debian)) id 1DDvgO-0001r2-00; Tue, 22 Mar 2005 18:33:20 -0800 Date: Tue, 22 Mar 2005 18:33:20 -0800 From: "David S. Miller" To: Matt Mackall Cc: netdev@oss.sgi.com, jmoyer@redhat.com Subject: Re: [PATCH 0/6] netpoll: recursion fixes, queueing, and cleanups Message-Id: <20050322183320.3ef997ef.davem@davemloft.net> In-Reply-To: <1.378217222@selenic.com> References: <1.378217222@selenic.com> X-Mailer: Sylpheed version 1.0.1 (GTK+ 1.2.10; sparc-unknown-linux-gnu) X-Face: "_;p5u5aPsO,_Vsx"^v-pEq09'CU4&Dc1$fQExov$62l60cgCc%FnIwD=.UF^a>?5'9Kn[;433QFVV9M..2eN.@4ZWPGbdi<=?[:T>y?SD(R*-3It"Vj:)"dP Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV 0.83/778/Mon Mar 21 02:48:43 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 532 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: davem@davemloft.net Precedence: bulk X-list: netdev Content-Length: 377 Lines: 12 On Thu, 17 Feb 2005 23:25:18 -0600 Matt Mackall wrote: > This patch series against -rc4 fixes up some recursion deadlocks in > netpoll and adds support for fallback to queueing. Various cleanups > along the way. > > Holds up under load testing via ipt_LOG on a dual Opteron with tg3. I've applied all 6 patches to my tree. Sorry for taking so long Matt. From davem@davemloft.net Tue Mar 22 18:36:57 2005 Received: with ECARTIS (v1.0.0; list netdev); Tue, 22 Mar 2005 18:37:01 -0800 (PST) Received: from cheetah.davemloft.net (mail@dsl027-180-174.sfo1.dsl.speakeasy.net [216.27.180.174]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j2N2audM018547 for ; Tue, 22 Mar 2005 18:36:57 -0800 Received: from localhost ([127.0.0.1] helo=cheetah.davemloft.net ident=davem) by cheetah.davemloft.net with smtp (Exim 3.36 #1 (Debian)) id 1DDviL-0001rS-00; Tue, 22 Mar 2005 18:35:21 -0800 Date: Tue, 22 Mar 2005 18:35:21 -0800 From: "David S. Miller" To: Matt Mackall Cc: jgarzik@pobox.com, netdev@oss.sgi.com, jmoyer@redhat.com Subject: Re: [PATCH 7/7] netpoll: avoid kfree_skb on packets with destructo Message-Id: <20050322183521.359cd068.davem@davemloft.net> In-Reply-To: <20050303213228.GU3120@waste.org> References: <7.454130102@selenic.com> <8.454130102@selenic.com> <20050303130031.066f0862.davem@davemloft.net> <20050303213228.GU3120@waste.org> X-Mailer: Sylpheed version 1.0.1 (GTK+ 1.2.10; sparc-unknown-linux-gnu) X-Face: "_;p5u5aPsO,_Vsx"^v-pEq09'CU4&Dc1$fQExov$62l60cgCc%FnIwD=.UF^a>?5'9Kn[;433QFVV9M..2eN.@4ZWPGbdi<=?[:T>y?SD(R*-3It"Vj:)"dP Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV 0.83/778/Mon Mar 21 02:48:43 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 533 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: davem@davemloft.net Precedence: bulk X-list: netdev Content-Length: 327 Lines: 13 On Thu, 3 Mar 2005 13:32:28 -0800 Matt Mackall wrote: > Doh. Plain as day. How's this look? > > Packets that have destructors should not be zapped here as that might > produce additional printk warnings via netconsole. > > Signed-off-by: Matt Mackall Looks great Matt, applied. Thanks. From davem@davemloft.net Tue Mar 22 18:41:13 2005 Received: with ECARTIS (v1.0.0; list netdev); Tue, 22 Mar 2005 18:41:17 -0800 (PST) Received: from cheetah.davemloft.net (mail@dsl027-180-174.sfo1.dsl.speakeasy.net [216.27.180.174]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j2N2fCLi019202 for ; Tue, 22 Mar 2005 18:41:12 -0800 Received: from localhost ([127.0.0.1] helo=cheetah.davemloft.net ident=davem) by cheetah.davemloft.net with smtp (Exim 3.36 #1 (Debian)) id 1DDvmU-0001vD-00; Tue, 22 Mar 2005 18:39:38 -0800 Date: Tue, 22 Mar 2005 18:39:38 -0800 From: "David S. Miller" To: Matt Mackall Cc: netdev@oss.sgi.com, kaber@trash.net Subject: Re: [PATCH] netpoll carrier clarification Message-Id: <20050322183938.0e074856.davem@davemloft.net> In-Reply-To: <20050310232138.GQ3120@waste.org> References: <20050310232138.GQ3120@waste.org> X-Mailer: Sylpheed version 1.0.1 (GTK+ 1.2.10; sparc-unknown-linux-gnu) X-Face: "_;p5u5aPsO,_Vsx"^v-pEq09'CU4&Dc1$fQExov$62l60cgCc%FnIwD=.UF^a>?5'9Kn[;433QFVV9M..2eN.@4ZWPGbdi<=?[:T>y?SD(R*-3It"Vj:)"dP Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV 0.83/778/Mon Mar 21 02:48:43 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 534 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: davem@davemloft.net Precedence: bulk X-list: netdev Content-Length: 214 Lines: 8 On Thu, 10 Mar 2005 15:21:38 -0800 Matt Mackall wrote: > Clarify the flaky carrier detect code and use msleep(). > > Signed-off-by: Matt Mackall Ok, I'll apply this. Thanks. From davem@davemloft.net Tue Mar 22 18:42:32 2005 Received: with ECARTIS (v1.0.0; list netdev); Tue, 22 Mar 2005 18:42:36 -0800 (PST) Received: from cheetah.davemloft.net (mail@dsl027-180-174.sfo1.dsl.speakeasy.net [216.27.180.174]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j2N2gWDC019604 for ; Tue, 22 Mar 2005 18:42:32 -0800 Received: from localhost ([127.0.0.1] helo=cheetah.davemloft.net ident=davem) by cheetah.davemloft.net with smtp (Exim 3.36 #1 (Debian)) id 1DDvnn-0001vk-00; Tue, 22 Mar 2005 18:40:59 -0800 Date: Tue, 22 Mar 2005 18:40:59 -0800 From: "David S. Miller" To: Matt Mackall Cc: netdev@oss.sgi.com, kaber@trash.net Subject: Re: [PATCH] netpoll fix racy dev->flags usage Message-Id: <20050322184059.73bef4d5.davem@davemloft.net> In-Reply-To: <20050310232245.GR3120@waste.org> References: <20050310232245.GR3120@waste.org> X-Mailer: Sylpheed version 1.0.1 (GTK+ 1.2.10; sparc-unknown-linux-gnu) X-Face: "_;p5u5aPsO,_Vsx"^v-pEq09'CU4&Dc1$fQExov$62l60cgCc%FnIwD=.UF^a>?5'9Kn[;433QFVV9M..2eN.@4ZWPGbdi<=?[:T>y?SD(R*-3It"Vj:)"dP Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV 0.83/778/Mon Mar 21 02:48:43 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 535 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: davem@davemloft.net Precedence: bulk X-list: netdev Content-Length: 216 Lines: 8 On Thu, 10 Mar 2005 15:22:46 -0800 Matt Mackall wrote: > Put ndev->flags usage under the lock. Spotted by Patrick McHardy. > > Signed-off-by: Matt Mackall Applied, thanks Matt. From davem@davemloft.net Tue Mar 22 18:45:42 2005 Received: with ECARTIS (v1.0.0; list netdev); Tue, 22 Mar 2005 18:45:47 -0800 (PST) Received: from cheetah.davemloft.net (mail@dsl027-180-174.sfo1.dsl.speakeasy.net [216.27.180.174]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j2N2jg1v020333 for ; Tue, 22 Mar 2005 18:45:42 -0800 Received: from localhost ([127.0.0.1] helo=cheetah.davemloft.net ident=davem) by cheetah.davemloft.net with smtp (Exim 3.36 #1 (Debian)) id 1DDvqj-0001xz-00; Tue, 22 Mar 2005 18:44:01 -0800 Date: Tue, 22 Mar 2005 18:44:00 -0800 From: "David S. Miller" To: Patrick McHardy Cc: maxk@qualcomm.com, shemminger@osdl.org, netdev@oss.sgi.com Subject: Re: Fw: [Bug 4279] New: When I try to start vpnc the net/core/skbuff.c:91 crash Message-Id: <20050322184400.7ab1f5f7.davem@davemloft.net> In-Reply-To: <42312692.7040806@trash.net> References: <20050303095832.6a084856@dxpl.pdx.osdl.net> <4228A354.8020904@qualcomm.com> <4228AD8F.4020000@trash.net> <20050310192023.1270fef6.davem@davemloft.net> <42312692.7040806@trash.net> X-Mailer: Sylpheed version 1.0.1 (GTK+ 1.2.10; sparc-unknown-linux-gnu) X-Face: "_;p5u5aPsO,_Vsx"^v-pEq09'CU4&Dc1$fQExov$62l60cgCc%FnIwD=.UF^a>?5'9Kn[;433QFVV9M..2eN.@4ZWPGbdi<=?[:T>y?SD(R*-3It"Vj:)"dP Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV 0.83/778/Mon Mar 21 02:48:43 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 536 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: davem@davemloft.net Precedence: bulk X-list: netdev Content-Length: 188 Lines: 6 On Fri, 11 Mar 2005 06:03:14 +0100 Patrick McHardy wrote: > The patch is also needed (and applies with fuzz) for 2.4. I've put it into my net-2.4 tree, thanks Patrick. From davem@davemloft.net Tue Mar 22 18:48:05 2005 Received: with ECARTIS (v1.0.0; list netdev); Tue, 22 Mar 2005 18:48:10 -0800 (PST) Received: from cheetah.davemloft.net (mail@dsl027-180-174.sfo1.dsl.speakeasy.net [216.27.180.174]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j2N2m5LF020904 for ; Tue, 22 Mar 2005 18:48:05 -0800 Received: from localhost ([127.0.0.1] helo=cheetah.davemloft.net ident=davem) by cheetah.davemloft.net with smtp (Exim 3.36 #1 (Debian)) id 1DDvt5-0001ym-00; Tue, 22 Mar 2005 18:46:27 -0800 Date: Tue, 22 Mar 2005 18:46:26 -0800 From: "David S. Miller" To: Arthur Kepner Cc: netdev@oss.sgi.com Subject: Re: [PATCH] use NETIF_F_LLTX in bonding device Message-Id: <20050322184626.543a78da.davem@davemloft.net> In-Reply-To: References: X-Mailer: Sylpheed version 1.0.1 (GTK+ 1.2.10; sparc-unknown-linux-gnu) X-Face: "_;p5u5aPsO,_Vsx"^v-pEq09'CU4&Dc1$fQExov$62l60cgCc%FnIwD=.UF^a>?5'9Kn[;433QFVV9M..2eN.@4ZWPGbdi<=?[:T>y?SD(R*-3It"Vj:)"dP Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV 0.83/778/Mon Mar 21 02:48:43 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 537 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: davem@davemloft.net Precedence: bulk X-list: netdev Content-Length: 453 Lines: 15 On Tue, 15 Mar 2005 10:29:16 -0800 (PST) Arthur Kepner wrote: > > Lock contention on the bonding device's xmit_lock can > become a bottleneck when 3 or more gige links are aggregated. > And it looks like it's unnecessary too, so use the > NETIF_F_LLTX flag to avoid grabbing this lock. > > Signed-off-by: Yes, bonding does all of it's own internal locking, so this change is correct. Applied, thanks Arthur. From davem@davemloft.net Tue Mar 22 18:49:29 2005 Received: with ECARTIS (v1.0.0; list netdev); Tue, 22 Mar 2005 18:49:37 -0800 (PST) Received: from cheetah.davemloft.net (mail@dsl027-180-174.sfo1.dsl.speakeasy.net [216.27.180.174]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j2N2nTTc021316 for ; Tue, 22 Mar 2005 18:49:29 -0800 Received: from localhost ([127.0.0.1] helo=cheetah.davemloft.net ident=davem) by cheetah.davemloft.net with smtp (Exim 3.36 #1 (Debian)) id 1DDvuR-000212-00; Tue, 22 Mar 2005 18:47:51 -0800 Date: Tue, 22 Mar 2005 18:47:50 -0800 From: "David S. Miller" To: Jesper Juhl Cc: netdev@oss.sgi.com, obz@Kodak.COM, bir7@leland.Stanford.Edu, waltje@uWalt.NL.Mugnet.ORG, linux-net@vger.kernel.org, linux-kernel@vger.kernel.org Subject: Re: [PATCH] net/socket.c : remove redundant NULL pointer check before kfree() Message-Id: <20050322184750.4ec7a51c.davem@davemloft.net> In-Reply-To: References: X-Mailer: Sylpheed version 1.0.1 (GTK+ 1.2.10; sparc-unknown-linux-gnu) X-Face: "_;p5u5aPsO,_Vsx"^v-pEq09'CU4&Dc1$fQExov$62l60cgCc%FnIwD=.UF^a>?5'9Kn[;433QFVV9M..2eN.@4ZWPGbdi<=?[:T>y?SD(R*-3It"Vj:)"dP Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV 0.83/778/Mon Mar 21 02:48:43 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 538 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: davem@davemloft.net Precedence: bulk X-list: netdev Content-Length: 228 Lines: 8 On Thu, 17 Mar 2005 20:34:05 +0100 (CET) Jesper Juhl wrote: > kfree() handles NULL pointers just fine, checking first is pointless. > > Signed-off-by: Jesper Juhl Applied, thanks Jesper. From herbert@gondor.apana.org.au Tue Mar 22 18:50:42 2005 Received: with ECARTIS (v1.0.0; list netdev); Tue, 22 Mar 2005 18:50:50 -0800 (PST) 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 j2N2ofAf021892 for ; Tue, 22 Mar 2005 18:50:42 -0800 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 1DDvwt-000099-00; Wed, 23 Mar 2005 13:50:23 +1100 Received: from herbert by gondolin.me.apana.org.au with local (Exim 3.36 #1 (Debian)) id 1DDvvZ-000350-00; Wed, 23 Mar 2005 13:49:01 +1100 From: Herbert Xu To: kaber@trash.net (Patrick McHardy) Subject: Re: Fw: [Bugme-new] [Bug 4381] New: When i try to start a pppoe conn., crash at net/core/skbuff.c:91 Cc: akpm@osdl.org, netdev@oss.sgi.com, o.cornu@gmail.com, paulus@samba.org Organization: Core In-Reply-To: <4240D266.4080403@trash.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: Wed, 23 Mar 2005 13:49:01 +1100 X-Virus-Scanned: ClamAV 0.83/778/Mon Mar 21 02:48:43 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 539 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: herbert@gondor.apana.org.au Precedence: bulk X-list: netdev Content-Length: 864 Lines: 22 Patrick McHardy wrote: > > ===== drivers/net/ppp_async.c 1.26 vs edited ===== > --- 1.26/drivers/net/ppp_async.c 2005-01-21 06:02:12 +01:00 > +++ edited/drivers/net/ppp_async.c 2005-03-23 03:15:31 +01:00 > @@ -183,6 +183,7 @@ > ap->chan.private = ap; > ap->chan.ops = &async_ops; > ap->chan.mtu = PPP_MRU; > + ap->chan.hdrlen = 2; > err = ppp_register_channel(&ap->chan); I'm not sure whether this could cause the original crash that we saw. If ap->chan.hdrlen is not set then it should be zero. It being zero should not cause skb_over_panic to trigger in ppp_write, should it? Cheers, -- Visit Openswan at http://www.openswan.org/ Email: Herbert Xu ~{PmV>HI~} Home Page: http://gondor.apana.org.au/~herbert/ PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt From kaber@trash.net Tue Mar 22 18:55:21 2005 Received: with ECARTIS (v1.0.0; list netdev); Tue, 22 Mar 2005 18:55:26 -0800 (PST) Received: from kaber.coreworks.de ([62.206.217.67]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j2N2tJ49022605 for ; Tue, 22 Mar 2005 18:55:21 -0800 Received: from localhost ([127.0.0.1]) by kaber.coreworks.de with esmtp (Exim 4.50) id 1DDw1V-0004an-Nk; Wed, 23 Mar 2005 03:55:09 +0100 Message-ID: <4240DA8D.1050906@trash.net> Date: Wed, 23 Mar 2005 03:55:09 +0100 From: Patrick McHardy User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.7.5) Gecko/20050106 Debian/1.7.5-1 X-Accept-Language: en MIME-Version: 1.0 To: Herbert Xu CC: akpm@osdl.org, netdev@oss.sgi.com, o.cornu@gmail.com, paulus@samba.org Subject: Re: Fw: [Bugme-new] [Bug 4381] New: When i try to start a pppoe conn., crash at net/core/skbuff.c:91 References: In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV 0.83/778/Mon Mar 21 02:48:43 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 540 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: kaber@trash.net Precedence: bulk X-list: netdev Content-Length: 731 Lines: 22 Herbert Xu wrote: > Patrick McHardy wrote: > >>===== drivers/net/ppp_async.c 1.26 vs edited ===== >>--- 1.26/drivers/net/ppp_async.c 2005-01-21 06:02:12 +01:00 >>+++ edited/drivers/net/ppp_async.c 2005-03-23 03:15:31 +01:00 >>@@ -183,6 +183,7 @@ >> ap->chan.private = ap; >> ap->chan.ops = &async_ops; >> ap->chan.mtu = PPP_MRU; >>+ ap->chan.hdrlen = 2; >> err = ppp_register_channel(&ap->chan); > > > I'm not sure whether this could cause the original crash that we saw. > If ap->chan.hdrlen is not set then it should be zero. It being zero > should not cause skb_over_panic to trigger in ppp_write, should it? You're right, I missed the memset(). Regards Patrick From paulus@ozlabs.org Tue Mar 22 19:04:42 2005 Received: with ECARTIS (v1.0.0; list netdev); Tue, 22 Mar 2005 19:04:46 -0800 (PST) Received: from ozlabs.org (ozlabs.org [203.10.76.45]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j2N34fsZ023706 for ; Tue, 22 Mar 2005 19:04:41 -0800 Received: by ozlabs.org (Postfix, from userid 1003) id 1F71367A9B; Wed, 23 Mar 2005 14:04:35 +1100 (EST) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <16960.56651.563544.695661@cargo.ozlabs.ibm.com> Date: Wed, 23 Mar 2005 14:06:51 +1100 From: Paul Mackerras To: Patrick McHardy Cc: Andrew Morton , netdev@oss.sgi.com, o.cornu@gmail.com Subject: Re: Fw: [Bugme-new] [Bug 4381] New: When i try to start a pppoe conn., crash at net/core/skbuff.c:91 In-Reply-To: <4240D266.4080403@trash.net> References: <20050321201150.39ba3467.akpm@osdl.org> <4240D266.4080403@trash.net> X-Mailer: VM 7.19 under Emacs 21.3.1 X-Virus-Scanned: ClamAV 0.83/778/Mon Mar 21 02:48:43 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 541 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: paulus@samba.org Precedence: bulk X-list: netdev Content-Length: 413 Lines: 11 Patrick McHardy writes: > Looks like hdrlen is uninitialized in ppp_async. This patch No, it is initialized by the memset at line 165, and 0 is the correct value for ap->chan.hdrlen, since the ppp_async driver doesn't prepend any bytes to the skb on transmit. The bug must be somewhere else. It would be very interesting to know what value pf->hdrlen has in ppp_write and how it got that value though. Paul. From jgarzik@pobox.com Tue Mar 22 19:05:30 2005 Received: with ECARTIS (v1.0.0; list netdev); Tue, 22 Mar 2005 19:05:34 -0800 (PST) Received: from parcelfarce.linux.theplanet.co.uk (IDENT:93@parcelfarce.linux.theplanet.co.uk [195.92.249.252]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j2N35Tec023917 for ; Tue, 22 Mar 2005 19:05:30 -0800 Received: from cpe-069-134-152-124.nc.rr.com ([69.134.152.124] helo=[10.10.10.88]) by parcelfarce.linux.theplanet.co.uk with asmtp (TLSv1:AES256-SHA:256) (Exim 4.33) id 1DDwBU-0007fR-DF for netdev@oss.sgi.com; Wed, 23 Mar 2005 03:05:28 +0000 Message-ID: <4240DCEB.70100@pobox.com> Date: Tue, 22 Mar 2005 22:05:15 -0500 From: Jeff Garzik User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.3) Gecko/20040922 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Netdev Subject: Random todo for a hacker: update pci-skeleton.c Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV 0.83/778/Mon Mar 21 02:48:43 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 542 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: jgarzik@pobox.com Precedence: bulk X-list: netdev Content-Length: 249 Lines: 11 If someone is looking for a small, self-contained project: drivers/net/pci-skeleton.c needs updating for the latest net stack and PCI API changes. Possibly, it should be upgraded to a gigabit ethernet driver [for fictional hardware]. Jeff From davem@davemloft.net Tue Mar 22 19:11:18 2005 Received: with ECARTIS (v1.0.0; list netdev); Tue, 22 Mar 2005 19:11:23 -0800 (PST) Received: from cheetah.davemloft.net (mail@dsl027-180-174.sfo1.dsl.speakeasy.net [216.27.180.174]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j2N3BGqt024925 for ; Tue, 22 Mar 2005 19:11:18 -0800 Received: from localhost ([127.0.0.1] helo=cheetah.davemloft.net ident=davem) by cheetah.davemloft.net with smtp (Exim 3.36 #1 (Debian)) id 1DDwFX-00028y-00; Tue, 22 Mar 2005 19:09:39 -0800 Date: Tue, 22 Mar 2005 19:09:38 -0800 From: "David S. Miller" To: Stephen Hemminger Cc: marcelo.tosatti@cyclades.com.br, netdev@oss.sgi.com Subject: Re: [PATCH] TCP BIC not binary searching correctly Message-Id: <20050322190938.476db46b.davem@davemloft.net> In-Reply-To: <20050318140547.1ca66106@dxpl.pdx.osdl.net> References: <20050318135713.1171df83@dxpl.pdx.osdl.net> <20050318140547.1ca66106@dxpl.pdx.osdl.net> X-Mailer: Sylpheed version 1.0.1 (GTK+ 1.2.10; sparc-unknown-linux-gnu) X-Face: "_;p5u5aPsO,_Vsx"^v-pEq09'CU4&Dc1$fQExov$62l60cgCc%FnIwD=.UF^a>?5'9Kn[;433QFVV9M..2eN.@4ZWPGbdi<=?[:T>y?SD(R*-3It"Vj:)"dP Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV 0.83/778/Mon Mar 21 02:48:43 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 543 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: davem@davemloft.net Precedence: bulk X-list: netdev Content-Length: 159 Lines: 6 On Fri, 18 Mar 2005 14:05:47 -0800 Stephen Hemminger wrote: > 2.4 version of same fix as 2.6.11. Both patches applied, thanks Stephen. From davem@davemloft.net Tue Mar 22 19:24:18 2005 Received: with ECARTIS (v1.0.0; list netdev); Tue, 22 Mar 2005 19:24:24 -0800 (PST) Received: from cheetah.davemloft.net (mail@dsl027-180-174.sfo1.dsl.speakeasy.net [216.27.180.174]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j2N3OIaI026067 for ; Tue, 22 Mar 2005 19:24:18 -0800 Received: from localhost ([127.0.0.1] helo=cheetah.davemloft.net ident=davem) by cheetah.davemloft.net with smtp (Exim 3.36 #1 (Debian)) id 1DDwS3-0002Cs-00; Tue, 22 Mar 2005 19:22:35 -0800 Date: Tue, 22 Mar 2005 19:22:35 -0800 From: "David S. Miller" To: Max Krasnyansky Cc: hadi@cyberus.ca, chrisw@osdl.org, netdev@oss.sgi.com Subject: Re: [PATCH] remove unused netlink NL_EMULATE_DEV code Message-Id: <20050322192235.03627a5f.davem@davemloft.net> In-Reply-To: <423F11C3.2020803@qualcomm.com> References: <20050318233637.GS5389@shell0.pdx.osdl.net> <423B6DAE.9050803@qualcomm.com> <20050319010253.GU5389@shell0.pdx.osdl.net> <1111196899.1264.118.camel@jzny.localdomain> <423F11C3.2020803@qualcomm.com> X-Mailer: Sylpheed version 1.0.1 (GTK+ 1.2.10; sparc-unknown-linux-gnu) X-Face: "_;p5u5aPsO,_Vsx"^v-pEq09'CU4&Dc1$fQExov$62l60cgCc%FnIwD=.UF^a>?5'9Kn[;433QFVV9M..2eN.@4ZWPGbdi<=?[:T>y?SD(R*-3It"Vj:)"dP Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV 0.83/778/Mon Mar 21 02:48:43 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 544 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: davem@davemloft.net Precedence: bulk X-list: netdev Content-Length: 600 Lines: 21 On Mon, 21 Mar 2005 10:26:11 -0800 Max Krasnyansky wrote: > jamal wrote: > > 1 > > On Fri, 2005-03-18 at 20:02, Chris Wright wrote: > > > > > >>I'd prefer that too. What about the netlink_dev implementation itself? > >>Should it be marked obsolete? > >> > > > > It should die - pieces of it have already been slowly disapearing. > > Totally agree. Even for Ethertap it was easy to use Netlink sockets directly. I've applied Chris's original patch, then killed ethertap and netlink_dev from my tree. It's very telling that CONFIG_ETHERTAP was still marked EXPERIMENTAL :-) From jgarzik@pobox.com Tue Mar 22 19:30:47 2005 Received: with ECARTIS (v1.0.0; list netdev); Tue, 22 Mar 2005 19:30:52 -0800 (PST) Received: from parcelfarce.linux.theplanet.co.uk (IDENT:93@parcelfarce.linux.theplanet.co.uk [195.92.249.252]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j2N3UiqH026858 for ; Tue, 22 Mar 2005 19:30:47 -0800 Received: from cpe-069-134-152-124.nc.rr.com ([69.134.152.124] helo=[10.10.10.88]) by parcelfarce.linux.theplanet.co.uk with asmtp (TLSv1:AES256-SHA:256) (Exim 4.33) id 1DDwZo-0000Wq-0R; Wed, 23 Mar 2005 03:30:36 +0000 Message-ID: <4240E2CE.4080400@pobox.com> Date: Tue, 22 Mar 2005 22:30:22 -0500 From: Jeff Garzik User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.3) Gecko/20040922 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Herbert Xu CC: netdev@oss.sgi.com Subject: Re: Resend: [NETDRV] Merge register_netdev calls References: <20040701111914.GA11120@gondor.apana.org.au> <414F2997.9030901@pobox.com> <20040925083208.GA27592@gondor.apana.org.au> In-Reply-To: <20040925083208.GA27592@gondor.apana.org.au> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV 0.83/778/Mon Mar 21 02:48:43 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 545 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: jgarzik@pobox.com Precedence: bulk X-list: netdev Content-Length: 576 Lines: 28 Herbert Xu wrote: > On Mon, Sep 20, 2004 at 03:03:51PM -0400, Jeff Garzik wrote: > >>Herbert Xu wrote: >> >>>On Fri, Jun 11, 2004 at 12:08:55PM +1000, herbert wrote: >>> >>> >>>>In fact it's really making these ISA/MCA probe() functions more >>>>like the ones we have for PCI. >> >>there was a lot of churn and I held off on this patch. >> >>could you be convinced to rediff and resend (again)? > > > Thanks for reminding me. Here it is diffed against net-drivers-2.6. > > Signed-off-by: Herbert Xu applied. finally. :) Thanks, Jeff From jgarzik@pobox.com Tue Mar 22 19:32:59 2005 Received: with ECARTIS (v1.0.0; list netdev); Tue, 22 Mar 2005 19:33:05 -0800 (PST) Received: from parcelfarce.linux.theplanet.co.uk (IDENT:93@parcelfarce.linux.theplanet.co.uk [195.92.249.252]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j2N3Wvmh027450 for ; Tue, 22 Mar 2005 19:32:58 -0800 Received: from cpe-069-134-152-124.nc.rr.com ([69.134.152.124] helo=[10.10.10.88]) by parcelfarce.linux.theplanet.co.uk with asmtp (TLSv1:AES256-SHA:256) (Exim 4.33) id 1DDwc4-0000Zc-Ii; Wed, 23 Mar 2005 03:32:57 +0000 Message-ID: <4240E35C.2090203@pobox.com> Date: Tue, 22 Mar 2005 22:32:44 -0500 From: Jeff Garzik User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.3) Gecko/20040922 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Netdev CC: Linux Kernel Subject: netdev-2.6 queue updated Content-Type: multipart/mixed; boundary="------------070301080309020608040309" X-Virus-Scanned: ClamAV 0.83/778/Mon Mar 21 02:48:43 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 546 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: jgarzik@pobox.com Precedence: bulk X-list: netdev Content-Length: 10033 Lines: 260 This is a multi-part message in MIME format. --------------070301080309020608040309 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Wireless update, and various minor fixes. BK URL, patch URL, and changelog attached. Jeff --------------070301080309020608040309 Content-Type: text/plain; name="changelog.txt" Content-Transfer-Encoding: 8bit Content-Disposition: inline; filename="changelog.txt" BK users: bk pull bk://gkernel.bkbits.net/netdev-2.6 Patch: http://www.kernel.org/pub/linux/kernel/people/jgarzik/patchkits/2.6/2.6.12-rc1-bk1-netdev1.patch.bz2 This will update the following files: drivers/net/fmv18x.c | 689 ---- drivers/net/sk_g16.c | 2045 ----------- drivers/net/sk_g16.h | 164 drivers/net/wireless/ieee802_11.h | 78 Documentation/networking/multicast.txt | 1 Documentation/networking/net-modules.txt | 3 MAINTAINERS | 14 drivers/net/3c505.c | 6 drivers/net/8139cp.c | 109 drivers/net/8139too.c | 202 - drivers/net/Kconfig | 40 drivers/net/Makefile | 3 drivers/net/Space.c | 6 drivers/net/arcnet/arcnet.c | 4 drivers/net/b44.c | 36 drivers/net/b44.h | 3 drivers/net/bonding/bond_alb.c | 4 drivers/net/depca.c | 2 drivers/net/e100.c | 69 drivers/net/eql.c | 4 drivers/net/mii.c | 9 drivers/net/myri_code.h | 1283 ------- drivers/net/natsemi.c | 11 drivers/net/r8169.c | 31 drivers/net/sis900.c | 54 drivers/net/sk98lin/skethtool.c | 3 drivers/net/skge.c | 3385 +++++++++++++++++++ drivers/net/skge.h | 3005 +++++++++++++++++ drivers/net/smc91x.c | 161 drivers/net/smc91x.h | 15 drivers/net/starfire.c | 142 drivers/net/starfire_firmware.h | 346 ++ drivers/net/tulip/dmfe.c | 3 drivers/net/tulip/winbond-840.c | 3 drivers/net/via-velocity.c | 6 drivers/net/wireless/Kconfig | 2 drivers/net/wireless/Makefile | 2 drivers/net/wireless/atmel.c | 62 drivers/net/wireless/hostap/Kconfig | 104 drivers/net/wireless/hostap/Makefile | 8 drivers/net/wireless/hostap/hostap.c | 1205 +++++++ drivers/net/wireless/hostap/hostap.h | 57 drivers/net/wireless/hostap/hostap_80211.h | 107 drivers/net/wireless/hostap/hostap_80211_rx.c | 1084 ++++++ drivers/net/wireless/hostap/hostap_80211_tx.c | 522 +++ drivers/net/wireless/hostap/hostap_ap.c | 3286 +++++++++++++++++++ drivers/net/wireless/hostap/hostap_ap.h | 272 + drivers/net/wireless/hostap/hostap_common.h | 557 +++ drivers/net/wireless/hostap/hostap_config.h | 86 drivers/net/wireless/hostap/hostap_crypt.c | 167 drivers/net/wireless/hostap/hostap_crypt.h | 50 drivers/net/wireless/hostap/hostap_crypt_ccmp.c | 486 ++ drivers/net/wireless/hostap/hostap_crypt_tkip.c | 696 ++++ drivers/net/wireless/hostap/hostap_crypt_wep.c | 281 + drivers/net/wireless/hostap/hostap_cs.c | 929 +++++ drivers/net/wireless/hostap/hostap_download.c | 766 ++++ drivers/net/wireless/hostap/hostap_hw.c | 3631 +++++++++++++++++++++ drivers/net/wireless/hostap/hostap_info.c | 478 ++ drivers/net/wireless/hostap/hostap_ioctl.c | 4116 ++++++++++++++++++++++++ drivers/net/wireless/hostap/hostap_pci.c | 453 ++ drivers/net/wireless/hostap/hostap_plx.c | 612 +++ drivers/net/wireless/hostap/hostap_proc.c | 466 ++ drivers/net/wireless/hostap/hostap_wlan.h | 1075 ++++++ drivers/net/wireless/orinoco.c | 11 drivers/net/wireless/wl3501.h | 4 include/linux/pci_ids.h | 3 include/linux/wireless.h | 283 + include/net/ieee80211.h | 887 +++++ include/net/ieee80211_crypt.h | 86 net/Kconfig | 2 net/Makefile | 1 net/core/wireless.c | 74 net/ieee80211/Kconfig | 67 net/ieee80211/Makefile | 11 net/ieee80211/ieee80211_crypt.c | 259 + net/ieee80211/ieee80211_crypt_ccmp.c | 470 ++ net/ieee80211/ieee80211_crypt_tkip.c | 708 ++++ net/ieee80211/ieee80211_crypt_wep.c | 272 + net/ieee80211/ieee80211_module.c | 268 + net/ieee80211/ieee80211_rx.c | 1206 +++++++ net/ieee80211/ieee80211_tx.c | 448 ++ net/ieee80211/ieee80211_wx.c | 471 ++ 82 files changed, 34377 insertions(+), 4653 deletions(-) through these ChangeSets: : o ieee80211 subsystem : o net/Kconfig: remove unsupported network adapter names : o wireless-2.6 cleanup : o [netdrvr 8139cp] add PCI ID Adrian Bunk: o remove two obsolete net drivers o drivers/net/sis900.c: fix a warning o drivers/net/eql.c: kill dead code o net/ieee80211/Kconfig: don't describe what gets selected Alexander Viro: o hostap __user annotations Andres Salomon: o fix pci_disable_device in 8139too Andrew Morton: o bonding needs inet Dale Farnsworth: o mii: GigE support bug fixes Daniele Venzano: o More ethtool support for sis900 and warning fix o Maintainer change for the sis900 driver Domen Puncer: o drivers/net/myri_code.h cleanup o net/sk98lin: remove duplicate delay o net/3c505: replace schedule_timeout() with msleep() Felipe Damasio: o 8139cp net driver: add MODULE_VERSION François Romieu: o r8169: incoming frame length check o ieee80211: offset_in_page() removal o ieee80211: C99 initialization for eap_types o ieee80211: failure of ieee80211_crypto_init() o 8139cp: SG support fixes Greg Kroah-Hartman: o net drivers: convert pci_dev->slot_name usage to pci_name() Jean Tourrilhes: o Wireless Extensions 18 (aka WPA) Jeff Garzik: o [netdrvr smc91x] use __iomem addresses in eeprom read/write changes o [netdrvr starfire] Add GPL'd firmware, remove compat code o [wireless hostap] update for new pci_save_state() o [netdrvr 8139cp] TSO support John W. Linville: o e100: NAPI state machine fix o bonding: avoid tx balance for IGMP (alb/tlb mode) o b44: allocate tx bounce bufs as needed Joshua Kwan: o hostap: fix Kconfig typos and missing select CRYPTO Jouni Malinen: o hostap: Update to use the new WE18 proposal o hostap: Filter disconnect events o hostap: Improved suspend o hostap: Rate limiting for debug messages o hostap: Clear station statistic on accounting start o hostap: Fix procfs rmdir after ifname change o hostap: Add support for multi-func SanDisk ConnectPlus o hostap: Disable interrupts before Genesis mode o hostap: Include asm/io.h o hostap: Clear station statistic on accounting start o Host AP: Replaced MODULE_PARM with module_param* o Host AP: Replaced direct dev->priv references with netdev_priv(dev) o Host AP: Updated to use Linux wireless extensions v17 o Host AP: pci_register_driver() return value changes o Host AP: Fix netif_carrier_off() in non-client modes o Host AP: Fix PRISM2_IO_DEBUG o Host AP: Use void __iomem * with {read,write}{b,w} o Host AP: Fix card enabling after firmware download o Host AP: Do not bridge packets to unauthorized ports o Host AP: Fix compilation with PRISM2_NO_STATION_MODES defined o Host AP: Prevent STAs from associating using AP address o Host AP: Fix hw address changing for wifi# interface o Host AP: Remove ioctl debug messages o Host AP: Ignore (Re)AssocResp messages silently o Host AP: Fix interface packet counters o Host AP: Disable EAPOL TX/RX debug messages o fix hostap crypto bugs o Add HostAP wireless driver Ladislav Michl: o smc91x: get/set eeprom Mikael Pettersson: o drivers/net/depca.c gcc4 fix o drivers/net/arcnet/arcnet.c gcc4 fixes Nicolas Pitre: o smc91x warning fix o smc91x addr config check Olaf Kirch: o natsemi: long cable, short cable Pavel Machek: o Fix suspend/resume on via-velocity Pekka Enberg: o 8139too: use iomap for pio/mmio Steffen Klassert: o 8139cp - add netpoll support Stephen Hemminger: o skge: change driver version o skge: fix race with receive interrupt and NAPI o skge: use lockless transmit o skge: interrupt coalecsing related fixes o skge: only allow tx/rx csum on Yukon chipset o skge: use array for port irq masks o skge: use chip MIB stats for packet and byte counts o skge: simplify definition of wake on lan support o skge: suspend/resume related state management o skge: remove unneeded include's o skge: spelling and whitespace o skge: use PFX string o skge driver (0.5) o 8139cp - module_param Tobias Klauser: o drivers/net/tulip/winbond-840: Use the DMA_32BIT_MASK constant o drivers/net/tulip/dmfe: Use the DMA_32BIT_MASK constant o drivers/net/8139cp: Use the DMA_{64, 32}BIT_MASK constants --------------070301080309020608040309-- From davem@davemloft.net Tue Mar 22 19:51:27 2005 Received: with ECARTIS (v1.0.0; list netdev); Tue, 22 Mar 2005 19:51:32 -0800 (PST) Received: from cheetah.davemloft.net (mail@dsl027-180-174.sfo1.dsl.speakeasy.net [216.27.180.174]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j2N3pQjs028857 for ; Tue, 22 Mar 2005 19:51:27 -0800 Received: from localhost ([127.0.0.1] helo=cheetah.davemloft.net ident=davem) by cheetah.davemloft.net with smtp (Exim 3.36 #1 (Debian)) id 1DDwrm-0002Me-00; Tue, 22 Mar 2005 19:49:10 -0800 Date: Tue, 22 Mar 2005 19:49:10 -0800 From: "David S. Miller" To: Patrick McHardy Cc: herbert@gondor.apana.org.au, kuznet@ms2.inr.ac.ru, yoshfuji@linux-ipv6.org, netdev@oss.sgi.com Subject: Re: [22/*] [NETFILTER] Use correct IPsec MTU in TCPMSS Message-Id: <20050322194910.6a9fa3a4.davem@davemloft.net> In-Reply-To: <423D9ADA.6050407@trash.net> References: <20050214221607.GC18465@gondor.apana.org.au> <20050306213214.7d8a143d.davem@davemloft.net> <20050307103536.GB7137@gondor.apana.org.au> <20050308102741.GA23468@gondor.apana.org.au> <20050314102614.GA9610@gondor.apana.org.au> <20050314105313.GA21001@gondor.apana.org.au> <20050314111002.GA29156@gondor.apana.org.au> <20050315091904.GA6256@gondor.apana.org.au> <20050315095837.GA7130@gondor.apana.org.au> <20050318090310.GA28443@gondor.apana.org.au> <20050318091129.GA28658@gondor.apana.org.au> <20050318104013.57d65e99.davem@davemloft.net> <423D9ADA.6050407@trash.net> X-Mailer: Sylpheed version 1.0.1 (GTK+ 1.2.10; sparc-unknown-linux-gnu) X-Face: "_;p5u5aPsO,_Vsx"^v-pEq09'CU4&Dc1$fQExov$62l60cgCc%FnIwD=.UF^a>?5'9Kn[;433QFVV9M..2eN.@4ZWPGbdi<=?[:T>y?SD(R*-3It"Vj:)"dP Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV 0.83/778/Mon Mar 21 02:48:43 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 547 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: davem@davemloft.net Precedence: bulk X-list: netdev Content-Length: 635 Lines: 14 On Sun, 20 Mar 2005 16:46:34 +0100 Patrick McHardy wrote: > So what's holding back these patches is getting some consensus on what > exactly we want to do and finding a better method for determining when > decapsulation is done. One possibility would be stealing packets > in xfrm_policy_check(), but I haven't thought much about this yet. That latter idea sounds pursuable. I guess you'd do a netfilter hook in xfrm_policy_check() right? So then you'd need to pass struct sk_buff ** instead of a direct pointer. And that looks fine too, as nobody seems to cache skb->XXX state across xfrm_policy_check() calls. From hadi@cyberus.ca Tue Mar 22 19:57:51 2005 Received: with ECARTIS (v1.0.0; list netdev); Tue, 22 Mar 2005 19:57:56 -0800 (PST) Received: from mx02.cybersurf.com (mx02.cybersurf.com [209.197.145.105]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j2N3voBe029586 for ; Tue, 22 Mar 2005 19:57:50 -0800 Received: from mail.cyberus.ca ([209.197.145.21]) by mx02.cybersurf.com with esmtp (Exim 4.30) id 1DDx0A-0004YP-D6 for netdev@oss.sgi.com; Tue, 22 Mar 2005 22:57:50 -0500 Received: from [24.103.99.32] (helo=[10.0.0.9]) by mail.cyberus.ca with esmtp (Exim 4.20) id 1DDwzz-0004lh-TT; Tue, 22 Mar 2005 22:57:40 -0500 Subject: Re: iptables breakage WAS(Re: dummy as IMQ replacement From: jamal Reply-To: hadi@cyberus.ca To: Andy Furniss Cc: Harald Welte , Patrick McHardy , Remus , netdev@oss.sgi.com, Nguyen Dinh Nam , Andre Tomt , syrius.ml@no-log.org, Damion de Soto In-Reply-To: <42408998.5000202@dsl.pipex.com> References: <1107123123.8021.80.camel@jzny.localdomain> <0fcf01c5077f$579e4b80$6e69690a@RIMAS> <1107174142.8021.121.camel@jzny.localdomain> <00c301c524b4$938cd240$6e69690a@RIMAS> <1110379135.1091.143.camel@jzny.localdomain> <1110416767.1111.76.camel@jzny.localdomain> <025501c52552$2dbf87c0$6e69690a@RIMAS> <1110453757.1108.87.camel@jzny.localdomain> <423B7BCB.10400@dsl.pipex.com> <1111410890.1092.195.camel@jzny.localdomain> <423F41AD.3010902@dsl.pipex.com> <1111444869.1072.51.camel@jzny.localdomain> <423F71C2.8040802@dsl.pipex.com> <1111462263.1109.6.camel@jzny.localdomain> <42408998.5000202@dsl.pipex.com> Content-Type: multipart/mixed; boundary="=-vNini9tDqgL1Ex1jILZE" Organization: jamalopolous Message-Id: <1111550254.1089.21.camel@jzny.localdomain> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.2.2 Date: 22 Mar 2005 22:57:34 -0500 X-Virus-Scanned: ClamAV 0.83/778/Mon Mar 21 02:48:43 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 548 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: hadi@cyberus.ca Precedence: bulk X-list: netdev Content-Length: 7745 Lines: 182 --=-vNini9tDqgL1Ex1jILZE Content-Type: text/plain Content-Transfer-Encoding: 7bit Ok, Andy - I have tested this and should all work. Can you double check on your side before i push kernel patch to Dave? I tested on ubuntu distro on an AMD athlon. Attached tar.gz with necessary patches. I only bothered to do 2 out of 3 tests. The second one covers the third. iptables libraries at runtime: 1.3.1 cheers, jamal -- start details (collected while i was testing) ----------- patch to kernel 2.6.11.5: 1)stats fix - attached as p_kernel patch to tc: 1) stats - in patch file p_tc 2) mirred structure - in patch file p_tc 3) iptables headers copied from iptables 1.3.1 - both files in attachment bantu:~# uname -a Linux bantu.foo 2.6.11.5 #1 Mon Mar 21 23:23:51 EST 2005 i686 GNU/Linux bantu:~# bantu:~# tc -V tc utility, iproute2-ss050314 bantu:~# TEST1: Check if ipt works on its own and stats are fixed. tc qdisc del dev eth0 ingress tc qdisc add dev eth0 ingress tc filter add dev eth0 parent ffff: protocol ip prio 6 u32 \ match ip src 10.0.2.24/32 flowid 1:16 \ action ipt -j TOS --set-tos Maximize-Reliability ** machine 10.0.2.24/32 is directly connected (via switch) to eth0 tc -s filter ls dev eth0 parent ffff: bantu:~# tc -s filter ls dev eth0 parent ffff: filter protocol ip pref 6 u32 filter protocol ip pref 6 u32 fh 800: ht divisor 1 filter protocol ip pref 6 u32 fh 800::800 order 2048 key ht 800 bkt 0 flowid 1:16 (rule hit 0 success 0) match 0a000218/ffffffff at 12 (success 0 ) action order 1: tablename: mangle hook: NF_IP_PRE_ROUTING target TOS set Maximize-Reliability index 5 ref 1 bind 1 installed 10 sec used 10 sec Action statistics: Sent 0 bytes 0 pkt (dropped 0, overlimits 0 requeues 0) rate 0bit 0pps backlog 0b 0p requeues 0 ke82:~# ping -c 2 10.0.2.24 PING 10.0.2.24 (10.0.2.24) 56(84) bytes of data. 64 bytes from 10.0.2.24: icmp_seq=1 ttl=64 time=36.1 ms 64 bytes from 10.0.2.24: icmp_seq=2 ttl=64 time=3.79 ms --- 10.0.2.24 ping statistics --- 2 packets transmitted, 2 received, 0% packet loss, time 1005ms rtt min/avg/max/mdev = 3.798/19.960/36.122/16.162 ms bantu:~# bantu:~# tc -s filter ls dev eth0 parent ffff: filter protocol ip pref 6 u32 filter protocol ip pref 6 u32 fh 800: ht divisor 1 filter protocol ip pref 6 u32 fh 800::800 order 2048 key ht 800 bkt 0 flowid 1:16 (rule hit 2 success 2) match 0a000218/ffffffff at 12 (success 2 ) action order 1: tablename: mangle hook: NF_IP_PRE_ROUTING target TOS set Maximize-Reliability index 5 ref 1 bind 1 installed 109 sec used 36 sec Action statistics: Sent 168 bytes 2 pkt (dropped 0, overlimits 0 requeues 0) rate 0bit 0pps backlog 0b 0p requeues 0 TEST2: - check if ipt followed by another action works. - check if mirred works tc qdisc del dev eth0 ingress tc qdisc add dev eth0 ingress tc filter add dev eth0 parent ffff: protocol ip prio 6 \ u32 match ip src 10.0.2.24/32 flowid 1:16 \ action ipt -j TOS --set-tos Maximize-Reliability \ action mirred egress redirect dev lo --> Installs fine ping Replies should never be seen since they are redirected to loopback device; tcdump on dev lo should show them.Actually even tcpdump on eth0 should see them - they just dont make it up the stack. bantu:~# ping -c 2 10.0.2.24 PING 10.0.2.24 (10.0.2.24) 56(84) bytes of data. --- 10.0.2.24 ping statistics --- 2 packets transmitted, 0 received, 100% packet loss, time 1145ms bantu:~# bantu:~# tc -s filter ls dev eth0 parent ffff: filter protocol ip pref 6 u32 filter protocol ip pref 6 u32 fh 800: ht divisor 1 filter protocol ip pref 6 u32 fh 800::800 order 2048 key ht 800 bkt 0 flowid 1:16 (rule hit 2 success 2) match 0a000218/ffffffff at 12 (success 2 ) action order 1: tablename: mangle hook: NF_IP_PRE_ROUTING target TOS set Maximize-Reliability index 6 ref 1 bind 1 installed 128 sec used 123 sec Action statistics: Sent 168 bytes 2 pkt (dropped 0, overlimits 0 requeues 0) rate 0bit 0pps backlog 0b 0p requeues 0 action order 2: mirred (Egress Redirect to device lo) stolen index 1 ref 1 bind 1 installed 128 sec used 123 sec Action statistics: Sent 168 bytes 2 pkt (dropped 0, overlimits 0 requeues 0) rate 0bit 0pps backlog 0b 0p requeues 0 --=-vNini9tDqgL1Ex1jILZE Content-Disposition: attachment; filename=iptmir.tgz Content-Type: application/x-gzip; name=iptmir.tgz Content-Transfer-Encoding: base64 H4sIAE7fQEIAA+1aW2/iyBKeV/wrWpkXIATMLcyAVhomYc5Em0AEZDWr1apl7CZYMTay25nJWe1/ P1XdtrENDpmjJDNnT9dDbPelLl3VX1V3sDd8bfuNNy9Jut7Re90uPHW9d9rJPCN609RbLb3Z7XV6 rTd6U+/Bg3RfVKuIwoAbPiFvVoZlPzbuUP//KNnS/xvKzReTAf7UTzudIv83W73m1v+tNoxvnrY7 b4j+Yhql6P/c/ycnJ8Ro2K7phBZrOLYbfmv43GUcXu/qq1JL17sNvd1otUir3deb/da7UrPe1I6P j8ni6fO6fb2jffhATk7fv6/1yDE+TsmHDxopzc+GdDqcj2rR+6ez8Tx+n82H81mrpp2Ir+HZXLZg N6XYdDX8opG/BxrR9hmyuePUdIJddVr9brEZhbM6/bY04p0Oyh/D397WBFTu14vxeS31PbmeX0zG s3QTjBh9qWnHRQZhU94objbWFHapz6y6uVWqTfR2v6n3u+9Tpjw6Fr0nDGi966IX5EOY4DMe+i7R QerfKDjgfmhyYpjc9lwactshkqt4lw2/kL+04+KB6SYcSkp124K3I9l/hEbXN4YfMGp4Gw498kN2 y17fdnnSKz7i3h+9cf4hFOE/PIyFwyDoX0DG4/gPYH/ajfC/AwMR/1u9jq7w/zXorb10LbYk9OJ6 Pvx4OZrRm9loSj9rb6HVdtluh/Y2gktyFEcNNb312nPrq6NUp2MvoN9sRE/s1GJpwJNeXnyk5xfT RFCqjRw1wsBvOJ5pODg/CU/gz1zLXqY5XU8n8wmdnc2vU6y2jaTZbu2ZBcA7of8azel09NvFDFAa UHd+9pk0qmTiWOSO+S5zSOCFvsnqpNrIqLl3aqmMXR+HsxE9m1+SY9KqPDppPpzC986sdkXTIkwF q+kt49Rn93YAUKr9pZXMFUSra6zZHzjv0834bC41+DIeXo0uR+OT5p8DTSuFFMDyHeUknjzQIKPI dUAji1eA7C4A2p9SSvrcDx3AaoObK9SruJdUXfaNo075MVG3eAj1NFQsip+l7cAfzyeGZdmYSII+ cdlXIkazgBiuRWDnwvoEwj97me/TLKcULjIsqu06xgIMxqXFZtBkGq0c8ZZSKinrZPFAwKdG6PCK ELtvocFLoC4nwlfVe+bHzcB0Zv+bbRlaBjckmwDagQk+CkeCCIfdM5eLdQkDYLwxwDuw+yBz2gGo ugn9jRfA8qR4JgNTzD+FrsjO5OvKBu4itQbEC3G0ccvImgX4lLrde5C3y9UVczaVMn5UIi4XLnjG cFBRvmJS08wUGwZUyqlwBuX9h8TxNRK6gX3rMouAfPDJ0jTAuZUCJbE6CNDaNTofigKMigGRpUtA QAojEN0218iWDM4gVqLRQjcUVa4KbpUyfpi1yFVViKf7mtDFdsFvPK/g0jFug5pWKgnW0st560hV PJJRe01MeovWRu6KZCVs13BASWbeDQj7ZnO00/U48e4y673EcVSMq5QzgoXmMbvrrbsTvwFHZOme jG8uL/sQSGCZiC6DE0CNtBQRLZXyjvn2hlTtTWJawfpktr1cbDdcM982Y/Vmxj34OaWZu/TgjwgA 3MMY/mvCPWBtgQ2ZFQhg7mHVnqBZslYeaMh8FOfYMAl2JCCHb8RxeOIgwEfBKDTJMI/jTsyh8BXE e+fW9XyxbwLcbi5ZsJWNmAZmm6HPAZH6EmDSbpTsqLdcBgzgq1RowiA3cS0CYIAZEBPgGJLj5+F0 dI4pd5Yb63iGxawBponAXocObiFss91bSAiJrYaPigMCW4Af3ob5zoNIlDLXIpznoVfi9T5Qlj3f i8rRrGeE5YjjU3A5NfRnB2ap6lOQOfbDDvL9I6G50PyqfHkd+I2Evhr+Jj4WzwMIjINeDX+zmv33 CPyDsDdRPw++PALfbCtsf+uVARlWAup6yRMWTVbcv0ONTwLYZTAPDlu+ARslWHkhnALg/OUQz5V4 h6slfB1xER732S34hPky8ZSLSnwEjr3T5JrtzIuXUkyMZ8aDXApnAsAEy+OcWZR74rucRnfZtRUq W3EYDpe9uSiNueLfTdFMw33AXPTI1PzMtRHcHZSJg1KGiiWSl2ErL8Bb1a+ef4eDMkaiJrUdXtIA 2GtkL+0TvdlBe+wLtqaIbNo8hZwltYLw4p7pORl1gko2wiyPRjtUQDl4NEFzBPM//kywXTh9i1t4 XUBXMM/BLFmVb8AcYvVXxjYY9bChzbsICUAeoPOec2Efg/xORHWAp8RU7BbEafabBYOi8XF85hoQ YBhgqQAFgATcpATKnfPJeE4vJ8NzMHI+/T1+xQe9upnBUfzm7Gw0Ok9v0iKRkGSseNvsRkNeeqXQ hMhkwU5u3sPcajtc0uf8beGcjgIojTiTxVwkIVfciVeZhiCxL6BKwlAoFUVBivfSCYOVAF+bBU9m Tp7K3fMpg6In0l3WJku3sleQEFHLh24FLcnIxo9FaDvcBh6etzMjUSS5qslfwEEQP+P9X+7+N7nJ e0YRh/7/12p28ve/nbbeVPe/r0G7979nk6uryXjvDXDShSWiLBjEGHk/B1UU/8qgmrI39x2Bw/By KioGCYpYOfOHDUNEnMw/QzBfTyfA+Ir8QpqwU66H0+HVaL5th7bfRlNxNxm1IECmkySypKIexkNQ uUIoNTjAwSIEzKHlMtZ5eASpVPbMA1ATs7CafmyiOIhgUU/F0SNgaaSUxRcmM5E548OJ+MA+15If mP6y+AJQCqkMawNYnAXLFjASpfL3RwWt+xoBfB6VRp1D8hwPEu1+oUnX/p6Dop8m+5ACB7TYp0qC cwC/a8/KqAHfMuvlGqHYWSAibwOH+b7nlzMxXUtsqdfrlYJgEoqWhLJ4hDJ4WYTustaqtSupEE0r ANJvfWNNpWrJZ3J9kSk2oXynlu0PtIJjxVsim+nF+GIOXyTe4riHk1Z5XiAkvWFwAMUGF8UG8W1D 8o+V3WwVg8Xz5itFz0vJ73/kP3xeRMaB/A8p/zT//9+u3lL5/zXoO37/0+z1u+2+3vve3//Iee2f 5fc/qE6n32p/3+9/cFa33+y+7u9/fnR0KFKkSJEiRYoUKVKkSJEiRYoUKVKkSJEiRYoUKVKkSJEi RYoUKVKkSJGin5X+A1wqUg8AUAAA --=-vNini9tDqgL1Ex1jILZE-- From davem@davemloft.net Tue Mar 22 20:00:10 2005 Received: with ECARTIS (v1.0.0; list netdev); Tue, 22 Mar 2005 20:00:18 -0800 (PST) Received: from cheetah.davemloft.net (mail@dsl027-180-174.sfo1.dsl.speakeasy.net [216.27.180.174]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j2N408tN030143 for ; Tue, 22 Mar 2005 20:00:10 -0800 Received: from localhost ([127.0.0.1] helo=cheetah.davemloft.net ident=davem) by cheetah.davemloft.net with smtp (Exim 3.36 #1 (Debian)) id 1DDx0l-0002P1-00; Tue, 22 Mar 2005 19:58:27 -0800 Date: Tue, 22 Mar 2005 19:58:27 -0800 From: "David S. Miller" To: hadi@znyx.com Cc: kaber@trash.net, netdev@oss.sgi.com, tgraf@suug.ch Subject: Re: patch: introduce simple actions Message-Id: <20050322195827.5ecd0c33.davem@davemloft.net> In-Reply-To: <1111349853.1093.136.camel@jzny.localdomain> References: <1111345551.1095.82.camel@jzny.localdomain> <423DCD8C.6030100@trash.net> <1111347345.1094.98.camel@jzny.localdomain> <423DD5E6.2020708@trash.net> <1111349853.1093.136.camel@jzny.localdomain> X-Mailer: Sylpheed version 1.0.1 (GTK+ 1.2.10; sparc-unknown-linux-gnu) X-Face: "_;p5u5aPsO,_Vsx"^v-pEq09'CU4&Dc1$fQExov$62l60cgCc%FnIwD=.UF^a>?5'9Kn[;433QFVV9M..2eN.@4ZWPGbdi<=?[:T>y?SD(R*-3It"Vj:)"dP Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV 0.83/778/Mon Mar 21 02:48:43 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 549 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: davem@davemloft.net Precedence: bulk X-list: netdev Content-Length: 452 Lines: 20 On 20 Mar 2005 15:17:34 -0500 Jamal Hadi Salim wrote: > How about this: > I submit this patch (with Thomas cleanup) and the simple action. I'm waiting for this, send whenever it's ready. You may want to add the standard stuff to that header file BTW, ala: /* foo.h: This is the foo interface header. * * Copyright (C) 2005 Jamal Hadi Salim */ #ifndef _NET_FOO_H #define _NET_FOO_H ... #endif /* _NET_FOO_H */ From hadi@cyberus.ca Tue Mar 22 20:02:07 2005 Received: with ECARTIS (v1.0.0; list netdev); Tue, 22 Mar 2005 20:02:11 -0800 (PST) Received: from mx04.cybersurf.com (mx04.cybersurf.com [209.197.145.108]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j2N427gs030746 for ; Tue, 22 Mar 2005 20:02:07 -0800 Received: from mail.cyberus.ca ([209.197.145.21]) by mx04.cybersurf.com with esmtp (Exim 4.30) id 1DDx4I-0000WT-N3 for netdev@oss.sgi.com; Tue, 22 Mar 2005 23:02:06 -0500 Received: from [24.103.99.32] (helo=[10.0.0.9]) by mail.cyberus.ca with esmtp (Exim 4.20) id 1DDx4D-0005FM-W4; Tue, 22 Mar 2005 23:02:02 -0500 Subject: Re: iptables breakage WAS(Re: dummy as IMQ replacement From: jamal Reply-To: hadi@cyberus.ca To: Patrick McHardy Cc: Andy Furniss , Harald Welte , Remus , netdev@oss.sgi.com, Nguyen Dinh Nam , Andre Tomt , syrius.ml@no-log.org, Damion de Soto , Netfilter Development Mailinglist In-Reply-To: <4240C70E.8060503@trash.net> References: <1107123123.8021.80.camel@jzny.localdomain> <0fcf01c5077f$579e4b80$6e69690a@RIMAS> <1107174142.8021.121.camel@jzny.localdomain> <00c301c524b4$938cd240$6e69690a@RIMAS> <1110379135.1091.143.camel@jzny.localdomain> <1110416767.1111.76.camel@jzny.localdomain> <025501c52552$2dbf87c0$6e69690a@RIMAS> <1110453757.1108.87.camel@jzny.localdomain> <423B7BCB.10400@dsl.pipex.com> <1111410890.1092.195.camel@jzny.localdomain> <4240C70E.8060503@trash.net> Content-Type: text/plain Organization: jamalopolous Message-Id: <1111550516.1088.25.camel@jzny.localdomain> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.2.2 Date: 22 Mar 2005 23:01:56 -0500 Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV 0.83/778/Mon Mar 21 02:48:43 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 550 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: hadi@cyberus.ca Precedence: bulk X-list: netdev Content-Length: 529 Lines: 17 On Tue, 2005-03-22 at 20:31, Patrick McHardy wrote: > We'll try to keep this in mind in the future. We could move > the version field to the end, but I guess its already too > late. What do you think? > I think its ok for now - we'll say if you want to use ipt you have to use iptables 1.3.1 and above. Just keep me in mind in the future. Like i suggested a while back since i am ripping code off iptables anyways. if that code gets modularized and in a library then the maintainance of this should be easier. cheers, jamal From kaber@trash.net Tue Mar 22 20:04:03 2005 Received: with ECARTIS (v1.0.0; list netdev); Tue, 22 Mar 2005 20:04:07 -0800 (PST) Received: from kaber.coreworks.de ([62.206.217.67]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j2N4429x031321 for ; Tue, 22 Mar 2005 20:04:02 -0800 Received: from localhost ([127.0.0.1]) by kaber.coreworks.de with esmtp (Exim 4.50) id 1DDx5E-0004rA-Dl; Wed, 23 Mar 2005 05:03:04 +0100 Message-ID: <4240EA78.5050402@trash.net> Date: Wed, 23 Mar 2005 05:03:04 +0100 From: Patrick McHardy User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.7.5) Gecko/20050106 Debian/1.7.5-1 X-Accept-Language: en MIME-Version: 1.0 To: "David S. Miller" CC: herbert@gondor.apana.org.au, kuznet@ms2.inr.ac.ru, yoshfuji@linux-ipv6.org, netdev@oss.sgi.com Subject: Re: [22/*] [NETFILTER] Use correct IPsec MTU in TCPMSS References: <20050214221607.GC18465@gondor.apana.org.au> <20050306213214.7d8a143d.davem@davemloft.net> <20050307103536.GB7137@gondor.apana.org.au> <20050308102741.GA23468@gondor.apana.org.au> <20050314102614.GA9610@gondor.apana.org.au> <20050314105313.GA21001@gondor.apana.org.au> <20050314111002.GA29156@gondor.apana.org.au> <20050315091904.GA6256@gondor.apana.org.au> <20050315095837.GA7130@gondor.apana.org.au> <20050318090310.GA28443@gondor.apana.org.au> <20050318091129.GA28658@gondor.apana.org.au> <20050318104013.57d65e99.davem@davemloft.net> <423D9ADA.6050407@trash.net> <20050322194910.6a9fa3a4.davem@davemloft.net> In-Reply-To: <20050322194910.6a9fa3a4.davem@davemloft.net> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV 0.83/778/Mon Mar 21 02:48:43 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 551 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: kaber@trash.net Precedence: bulk X-list: netdev Content-Length: 828 Lines: 22 David S. Miller wrote: > On Sun, 20 Mar 2005 16:46:34 +0100 > Patrick McHardy wrote: > > >>So what's holding back these patches is getting some consensus on what >>exactly we want to do and finding a better method for determining when >>decapsulation is done. One possibility would be stealing packets >>in xfrm_policy_check(), but I haven't thought much about this yet. > > > That latter idea sounds pursuable. I guess you'd do a netfilter > hook in xfrm_policy_check() right? It would call netif_rx(). The packet should pass all hooks as usual, so everything works as expected. It is cleaner than my current approach, but has the same problems wrt. statistics and AF_PACKET/raw sockets. I'll post a patch (probably tomorrow, its late here) so we have something concrete to talk about. Regards Patrick From hadi@znyx.com Tue Mar 22 20:06:48 2005 Received: with ECARTIS (v1.0.0; list netdev); Tue, 22 Mar 2005 20:06:53 -0800 (PST) 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 j2N46mCc031959 for ; Tue, 22 Mar 2005 20:06:48 -0800 Received: from [127.0.0.1] ([208.2.156.2]) by lotus.znyx.com (Lotus Domino Release 5.0.11) with ESMTP id 2005032220074736:20903 ; Tue, 22 Mar 2005 20:07:47 -0800 Subject: Re: patch: introduce simple actions From: Jamal Hadi Salim Reply-To: hadi@znyx.com To: "David S. Miller" Cc: kaber@trash.net, netdev@oss.sgi.com, tgraf@suug.ch In-Reply-To: <20050322195827.5ecd0c33.davem@davemloft.net> References: <1111345551.1095.82.camel@jzny.localdomain> <423DCD8C.6030100@trash.net> <1111347345.1094.98.camel@jzny.localdomain> <423DD5E6.2020708@trash.net> <1111349853.1093.136.camel@jzny.localdomain> <20050322195827.5ecd0c33.davem@davemloft.net> Organization: ZNYX Networks Message-Id: <1111550799.1116.28.camel@jzny.localdomain> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.2.2 Date: 22 Mar 2005 23:06:39 -0500 X-MIMETrack: Itemize by SMTP Server on Lotus/Znyx(Release 5.0.11 |July 24, 2002) at 03/22/2005 08:07:47 PM, Serialize by Router on Lotus/Znyx(Release 5.0.11 |July 24, 2002) at 03/22/2005 08:07:54 PM, Serialize complete at 03/22/2005 08:07:54 PM Content-Transfer-Encoding: 7bit Content-Type: text/plain X-Virus-Scanned: ClamAV 0.83/778/Mon Mar 21 02:48:43 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 552 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: hadi@znyx.com Precedence: bulk X-list: netdev Content-Length: 633 Lines: 30 On Tue, 2005-03-22 at 22:58, David S. Miller wrote: > On 20 Mar 2005 15:17:34 -0500 > Jamal Hadi Salim wrote: > > > How about this: > > I submit this patch (with Thomas cleanup) and the simple action. > > I'm waiting for this, send whenever it's ready. > I will tommorow - need to plonk tonight > You may want to add the standard stuff to that header > file BTW, ala: > > /* foo.h: This is the foo interface header. > * > * Copyright (C) 2005 Jamal Hadi Salim > */ > > #ifndef _NET_FOO_H > #define _NET_FOO_H > ... > #endif /* _NET_FOO_H */ dang, yes. Thanks - will do. cheers, jamal From davem@davemloft.net Tue Mar 22 20:09:39 2005 Received: with ECARTIS (v1.0.0; list netdev); Tue, 22 Mar 2005 20:09:45 -0800 (PST) Received: from cheetah.davemloft.net (mail@dsl027-180-174.sfo1.dsl.speakeasy.net [216.27.180.174]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j2N49ddX032697 for ; Tue, 22 Mar 2005 20:09:39 -0800 Received: from localhost ([127.0.0.1] helo=cheetah.davemloft.net ident=davem) by cheetah.davemloft.net with smtp (Exim 3.36 #1 (Debian)) id 1DDxA2-0002T1-00; Tue, 22 Mar 2005 20:08:02 -0800 Date: Tue, 22 Mar 2005 20:08:02 -0800 From: "David S. Miller" To: Francois Romieu Cc: netdev@oss.sgi.com Subject: Re: [patch 2.6.12-rc1-bk1] multipath: early use of inlined function Message-Id: <20050322200802.014d7f57.davem@davemloft.net> In-Reply-To: <20050321213409.GA28998@electric-eye.fr.zoreil.com> References: <20050321213409.GA28998@electric-eye.fr.zoreil.com> X-Mailer: Sylpheed version 1.0.1 (GTK+ 1.2.10; sparc-unknown-linux-gnu) X-Face: "_;p5u5aPsO,_Vsx"^v-pEq09'CU4&Dc1$fQExov$62l60cgCc%FnIwD=.UF^a>?5'9Kn[;433QFVV9M..2eN.@4ZWPGbdi<=?[:T>y?SD(R*-3It"Vj:)"dP Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV 0.83/778/Mon Mar 21 02:48:43 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 553 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: davem@davemloft.net Precedence: bulk X-list: netdev Content-Length: 619 Lines: 14 On Mon, 21 Mar 2005 22:34:09 +0100 Francois Romieu wrote: > $ grep -n compare_keys net/ipv4/route.c > 151:static inline int compare_keys(struct flowi *fl1, struct flowi *fl2); > ^^^ > 541: compare_keys(&(*rthp)->fl, &expentry->fl)) { > 861:static inline int compare_keys(struct flowi *fl1, struct flowi *fl2) > 890: compare_keys(&rth->fl, &rt->fl)) { > 892: if (compare_keys(&rth->fl, &rt->fl)) { > > Signed-off-by: Francois Romieu Applied, thanks Francois. From davem@davemloft.net Tue Mar 22 20:10:49 2005 Received: with ECARTIS (v1.0.0; list netdev); Tue, 22 Mar 2005 20:10:53 -0800 (PST) Received: from cheetah.davemloft.net (mail@dsl027-180-174.sfo1.dsl.speakeasy.net [216.27.180.174]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j2N4AlEM000653 for ; Tue, 22 Mar 2005 20:10:49 -0800 Received: from localhost ([127.0.0.1] helo=cheetah.davemloft.net ident=davem) by cheetah.davemloft.net with smtp (Exim 3.36 #1 (Debian)) id 1DDxBA-0002TQ-00; Tue, 22 Mar 2005 20:09:12 -0800 Date: Tue, 22 Mar 2005 20:09:12 -0800 From: "David S. Miller" To: Dave Jones Cc: netdev@oss.sgi.com Subject: Re: swapped memset arguments. Message-Id: <20050322200912.06e8df6c.davem@davemloft.net> In-Reply-To: <20050322024457.GA11569@redhat.com> References: <20050322024457.GA11569@redhat.com> X-Mailer: Sylpheed version 1.0.1 (GTK+ 1.2.10; sparc-unknown-linux-gnu) X-Face: "_;p5u5aPsO,_Vsx"^v-pEq09'CU4&Dc1$fQExov$62l60cgCc%FnIwD=.UF^a>?5'9Kn[;433QFVV9M..2eN.@4ZWPGbdi<=?[:T>y?SD(R*-3It"Vj:)"dP Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV 0.83/778/Mon Mar 21 02:48:43 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 554 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: davem@davemloft.net Precedence: bulk X-list: netdev Content-Length: 273 Lines: 11 On Mon, 21 Mar 2005 21:44:57 -0500 Dave Jones wrote: > You wouldn't believe how many instances of this bug I've > seen in the last few days in both userspace and kernelspace. Hehe. > Signed-off-by: Dave Jones Applied, thanks Dave. From jm@jm.kir.nu Tue Mar 22 20:59:34 2005 Received: with ECARTIS (v1.0.0; list netdev); Tue, 22 Mar 2005 20:59:38 -0800 (PST) Received: from jm.kir.nu (dsl017-049-110.sfo4.dsl.speakeasy.net [69.17.49.110]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j2N4xVkH007365 for ; Tue, 22 Mar 2005 20:59:34 -0800 Received: from jm by jm.kir.nu with local (Exim 4.43) id 1DDxxX-0005dX-5L; Tue, 22 Mar 2005 20:59:11 -0800 Date: Tue, 22 Mar 2005 20:59:10 -0800 From: Jouni Malinen To: Adrian Bunk Cc: Andrew Morton , jgarzik@pobox.com, linux-kernel@vger.kernel.org, hostap@shmoo.com, linux-net@vger.kernel.org, netdev@oss.sgi.com Subject: Re: 2.6.12-rc1-mm1: hostap stack usage Message-ID: <20050323045909.GT8648@jm.kir.nu> Mail-Followup-To: Adrian Bunk , Andrew Morton , jgarzik@pobox.com, linux-kernel@vger.kernel.org, hostap@shmoo.com, linux-net@vger.kernel.org, netdev@oss.sgi.com References: <20050321025159.1cabd62e.akpm@osdl.org> <20050322163340.GD1948@stusta.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20050322163340.GD1948@stusta.de> User-Agent: Mutt/1.5.8i X-Virus-Scanned: ClamAV 0.83/778/Mon Mar 21 02:48:43 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 555 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: jkmaline@cc.hut.fi Precedence: bulk X-list: netdev Content-Length: 1464 Lines: 58 (netdev added to cc:) On Tue, Mar 22, 2005 at 05:33:40PM +0100, Adrian Bunk wrote: > The stack usage in some files under drivers/net/wireless/hostap/ is > too high. Thanks; I'll fix these and submit a patch (or two) after some testing. > drivers/net/wireless/hostap/hostap_ioctl.c: > > prism2_ioctl_giwaplist: > struct sockaddr addr[IW_MAX_AP]; > struct iw_quality qual[IW_MAX_AP]; > > 64 * (16 + 4) Bytes = 1280 Bytes OK. > prism2_ioctl_ethtool: > struct ethtool_drvinfo info = { ETHTOOL_GDRVINFO }; > > 196 Bytes This seems to be somewhat obsolete now since most drivers have moved to use get_drvinfo of ethtool_ops; I'll do the same. > __prism2_translate_scan: > char buf[MAX_WPA_IE_LEN * 2 + 30]; > > (64 * 2) + 30 Bytes = 158 Bytes OK. > drivers/net/wireless/hostap/hostap_cs.c: > > prism2_config: > cisparse_t parse; > u_char buf[64]; > config_info_t conf; > > The main offender seems to be "parse" (but I'm too lame counting how > many bytes it's exactly) resulting in nearly 1 kB stack usage. This is actually very common for PC Card drivers in the current kernel tree.. I'll change Host AP to kmalloc this, but someone might consider going through all *_cs.c drivers.. > drivers/net/wireless/hostap/hostap_plx.c: > > prism2_plx_check_cis: > #define CIS_MAX_LEN 256 > u8 cis[CIS_MAX_LEN]; OK. -- Jouni Malinen PGP id EFC895FA From jm@jm.kir.nu Tue Mar 22 21:52:58 2005 Received: with ECARTIS (v1.0.0; list netdev); Tue, 22 Mar 2005 21:53:03 -0800 (PST) Received: from jm.kir.nu (dsl017-049-110.sfo4.dsl.speakeasy.net [69.17.49.110]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j2N5qsMP010630 for ; Tue, 22 Mar 2005 21:52:58 -0800 Received: from jm by jm.kir.nu with local (Exim 4.43) id 1DDynN-0006zw-1e; Tue, 22 Mar 2005 21:52:45 -0800 Date: Tue, 22 Mar 2005 21:52:43 -0800 From: Jouni Malinen To: Jeff Garzik Cc: Netdev , Linux Kernel , James Ketrenos , "Luis R. Rodriguez" , "David S. Miller" Subject: Re: 2.6.x wireless update and status Message-ID: <20050323055243.GU8648@jm.kir.nu> References: <4240CA69.9020902@pobox.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4240CA69.9020902@pobox.com> User-Agent: Mutt/1.5.8i X-Virus-Scanned: ClamAV 0.83/778/Mon Mar 21 02:48:43 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 556 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: jkmaline@cc.hut.fi Precedence: bulk X-list: netdev Content-Length: 2485 Lines: 49 On Tue, Mar 22, 2005 at 08:46:17PM -0500, Jeff Garzik wrote: > Just updated the wireless-2.6 queue to include a HostAP update, and to > add Wireless Extensions 18 (WPA). See attached for BK info, patch info, > and changelog. Thanks! > Moving forward, the next "todo" for kernel wireless hackers is to get > ieee80211 common code lib into shape, namely: > * Merge Intel ipw drivers, which use ieee80211 > * Update HostAP to use ieee80211 > * Merge/convert other drivers to use ieee80211? I'll be working on HostAP driver next; and ieee80211 code of course at the same time, since it is likely to need some changes for this. As far as other drivers are concerned, I'd like to see Atheros cards working with the generic ieee80211 code. They would be a good test target since they are an example of design where very large part of functionality is in the driver/network stack (no firmware used). This would be a good test to verify that the 802.11 code is generic enough for such a design. > There is one minor point of contention so far. Jouni stated he prefers > that HostAP go upstream before it gets updated to use ieee80211. I > respectfully disagree, and prefer that HostAP is updated -first- to use > the ieee80211 lib, before going upstream. I think we can resolve this quite easily. The main reason for the other order was in trying to save my time by not having to work in more than one active development tree at the same time. This is kind of required since designing and maintaining an IEEE 802.11 stack would really be a full-time job and unfortunately, I have not yet managed to reach this goal in a way that would allow me to use all my time on open source development. BK did not really work that well for me, but it looks like I'm having better luck with quilt as far as the amount of time needed for organizing changes to wireless-2.6 is concerned. In addition, the total number of changes to the driver code has been quite small lately, so I'm beginning to be more open to moving all future development into wireless-2.6 tree and just keeping my current CVS repository as a backwards compatible (2.2/2.4/2.6 kernels), stable version that wouldn't get any more new features. This would allow the order that you prefer. In addition, if someone really wants to get the new features I may be adding, these should be available through wireless-2.6 tree (and -mm for that matter). -- Jouni Malinen PGP id EFC895FA From dale@farnsworth.org Tue Mar 22 22:14:48 2005 Received: with ECARTIS (v1.0.0; list netdev); Tue, 22 Mar 2005 22:14:53 -0800 (PST) Received: from xyzzy.farnsworth.org (qmailr@h142-az.mvista.com [65.200.49.142] (may be forged)) by oss.sgi.com (8.13.0/8.13.0) with SMTP id j2N6EliQ012337 for ; Tue, 22 Mar 2005 22:14:47 -0800 Received: (qmail 7199 invoked by uid 1000); 23 Mar 2005 06:14:46 -0000 From: "Dale Farnsworth" Date: Tue, 22 Mar 2005 23:14:46 -0700 To: Jeff Garzik , Netdev Subject: Re: [PATCH: 2.6.12-rc1] mii: Add test for GigE support Message-ID: <20050323061446.GA6943@xyzzy> References: <20050322231746.GA27770@xyzzy> <4240A9F3.5040704@pobox.com> <212e5bf54766a68d2ab8716574225203@freescale.com> <4240CABB.5090701@pobox.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4240CABB.5090701@pobox.com> User-Agent: Mutt/1.5.6+20040907i X-Virus-Scanned: ClamAV 0.83/778/Mon Mar 21 02:48:43 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 557 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: dale@farnsworth.org Precedence: bulk X-list: netdev Content-Length: 3267 Lines: 79 Signed-off-by: Dale Farnsworth Index: linux-2.5-enet/drivers/net/mii.c =================================================================== --- linux-2.5-enet.orig/drivers/net/mii.c +++ linux-2.5-enet/drivers/net/mii.c @@ -207,6 +207,21 @@ return 0; } +int mii_check_gmii_support(struct mii_if_info *mii) +{ + int reg; + + reg = mii->mdio_read(mii->dev, mii->phy_id, MII_BMSR); + if (reg & BMSR_HAS_EXTSTAT1000) { + reg = mii->mdio_read(mii->dev, mii->phy_id, MII_EXTSTAT1000); + if (reg & (ESR_1000_BASE_X_FD | ESR_1000_BASE_T_FD | + ESR_1000_BASE_X_HD | ESR_1000_BASE_T_HD)) + return 1; + } + + return 0; +} + int mii_link_ok (struct mii_if_info *mii) { /* first, a dummy read, needed to latch some MII phys */ @@ -394,5 +409,6 @@ EXPORT_SYMBOL(mii_ethtool_sset); EXPORT_SYMBOL(mii_check_link); EXPORT_SYMBOL(mii_check_media); +EXPORT_SYMBOL(mii_check_gmii_support); EXPORT_SYMBOL(generic_mii_ioctl); Index: linux-2.5-enet/include/linux/mii.h =================================================================== --- linux-2.5-enet.orig/include/linux/mii.h +++ linux-2.5-enet/include/linux/mii.h @@ -22,6 +22,7 @@ #define MII_EXPANSION 0x06 /* Expansion register */ #define MII_CTRL1000 0x09 /* 1000BASE-T control */ #define MII_STAT1000 0x0a /* 1000BASE-T status */ +#define MII_EXTSTAT1000 0x0f /* 1000BASE-XX extended status */ #define MII_DCOUNTER 0x12 /* Disconnect counter */ #define MII_FCSCOUNTER 0x13 /* False carrier counter */ #define MII_NWAYTEST 0x14 /* N-way auto-neg test reg */ @@ -54,7 +55,8 @@ #define BMSR_ANEGCAPABLE 0x0008 /* Able to do auto-negotiation */ #define BMSR_RFAULT 0x0010 /* Remote fault detected */ #define BMSR_ANEGCOMPLETE 0x0020 /* Auto-negotiation complete */ -#define BMSR_RESV 0x07c0 /* Unused... */ +#define BMSR_HAS_EXTSTAT1000 0x0100 /* Has 1000BASE extended status*/ +#define BMSR_RESV 0x06c0 /* Unused... */ #define BMSR_10HALF 0x0800 /* Can do 10mbps, half-duplex */ #define BMSR_10FULL 0x1000 /* Can do 10mbps, full-duplex */ #define BMSR_100HALF 0x2000 /* Can do 100mbps, half-duplex */ @@ -121,6 +123,12 @@ #define LPA_1000FULL 0x0800 /* Link partner 1000BASE-T full duplex */ #define LPA_1000HALF 0x0400 /* Link partner 1000BASE-T half duplex */ +/* 1000BASE Ext Status register */ +#define ESR_1000_BASE_X_FD 0x8000 +#define ESR_1000_BASE_X_HD 0x4000 +#define ESR_1000_BASE_T_FD 0x2000 +#define ESR_1000_BASE_T_HD 0x1000 + struct mii_if_info { int phy_id; int advertising; @@ -143,6 +151,7 @@ extern int mii_nway_restart (struct mii_if_info *mii); extern int mii_ethtool_gset(struct mii_if_info *mii, struct ethtool_cmd *ecmd); extern int mii_ethtool_sset(struct mii_if_info *mii, struct ethtool_cmd *ecmd); +extern int mii_check_gmii_support(struct mii_if_info *mii); extern void mii_check_link (struct mii_if_info *mii); extern unsigned int mii_check_media (struct mii_if_info *mii, unsigned int ok_to_print, From ahu@outpost.ds9a.nl Tue Mar 22 23:55:30 2005 Received: with ECARTIS (v1.0.0; list netdev); Tue, 22 Mar 2005 23:55:37 -0800 (PST) Received: from outpost.ds9a.nl (postfix@outpost.ds9a.nl [213.244.168.210]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j2N7tUFt018773 for ; Tue, 22 Mar 2005 23:55:30 -0800 Received: by outpost.ds9a.nl (Postfix, from userid 1000) id 15F36409A; Wed, 23 Mar 2005 08:55:25 +0100 (CET) Date: Wed, 23 Mar 2005 08:55:25 +0100 From: bert hubert To: Jeff Garzik Cc: Netdev , "akpm @ osdl. org Linux Kernel" Subject: Re: netdev-2.6 queue updated Message-ID: <20050323075525.GA25273@outpost.ds9a.nl> Mail-Followup-To: bert hubert , Jeff Garzik , Netdev , "akpm @ osdl. org Linux Kernel" References: <4240E35C.2090203@pobox.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4240E35C.2090203@pobox.com> User-Agent: Mutt/1.3.28i X-Virus-Scanned: ClamAV 0.83/778/Mon Mar 21 02:48:43 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 558 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: ahu@ds9a.nl Precedence: bulk X-list: netdev Content-Length: 1002 Lines: 23 On Tue, Mar 22, 2005 at 10:32:44PM -0500, Jeff Garzik wrote: > Wireless update, and various minor fixes. > > BK URL, patch URL, and changelog attached. Jeff, akpm can you predict if this will make 2.6.12? Especially the wireless & hostap stuff. > net/ieee80211/Kconfig | 67 > net/ieee80211/Makefile | 11 > net/ieee80211/ieee80211_crypt.c | 259 + > net/ieee80211/ieee80211_crypt_ccmp.c | 470 ++ > net/ieee80211/ieee80211_crypt_tkip.c | 708 ++++ > net/ieee80211/ieee80211_crypt_wep.c | 272 + > net/ieee80211/ieee80211_module.c | 268 + > net/ieee80211/ieee80211_rx.c | 1206 +++++++ > net/ieee80211/ieee80211_tx.c | 448 ++ > net/ieee80211/ieee80211_wx.c | 471 ++ -- http://www.PowerDNS.com Open source, database driven DNS Software http://netherlabs.nl Open and Closed source services From jean-mickael.guerin@6wind.com Wed Mar 23 00:33:54 2005 Received: with ECARTIS (v1.0.0; list netdev); Wed, 23 Mar 2005 00:33:58 -0800 (PST) Received: from eagle.6wind.com (46.106-14-84.ripe.coltfrance.com [84.14.106.46]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j2N8Xr6B025291 for ; Wed, 23 Mar 2005 00:33:53 -0800 Received: from [10.16.0.134] (unknown [10.16.0.134]) by eagle.6wind.com (Postfix) with ESMTP id CACCA2AD; Wed, 23 Mar 2005 09:33:51 +0100 (CET) Message-ID: <4241292B.6090207@6wind.com> Date: Wed, 23 Mar 2005 09:30:35 +0100 From: jean-mickael guerin Reply-To: jean-mickael.guerin@6wind.com User-Agent: Mozilla Thunderbird 1.0 (Windows/20041206) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Wolfgang Walter Cc: netdev@oss.sgi.com, sfrost@snowman.net Subject: Re: [IPSEC] Too many SADs! References: <200503220052.52756.wolfgang.walter@studentenwerk.mhn.de> In-Reply-To: <200503220052.52756.wolfgang.walter@studentenwerk.mhn.de> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV 0.83/778/Mon Mar 21 02:48:43 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 559 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: jean-mickael.guerin@6wind.com Precedence: bulk X-list: netdev Content-Length: 127 Lines: 5 > We switched to iproute2 and openswan which both use the netfilter-interface. Do you mean netlink interface ? Jean-Mickael From jgarzik@pobox.com Wed Mar 23 00:58:12 2005 Received: with ECARTIS (v1.0.0; list netdev); Wed, 23 Mar 2005 00:58:16 -0800 (PST) Received: from parcelfarce.linux.theplanet.co.uk (IDENT:93@parcelfarce.linux.theplanet.co.uk [195.92.249.252]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j2N8wBfJ027252 for ; Wed, 23 Mar 2005 00:58:12 -0800 Received: from cpe-069-134-152-124.nc.rr.com ([69.134.152.124] helo=[10.10.10.88]) by parcelfarce.linux.theplanet.co.uk with asmtp (TLSv1:AES256-SHA:256) (Exim 4.33) id 1DE1go-0001WY-Gv; Wed, 23 Mar 2005 08:58:10 +0000 Message-ID: <42412F94.7040603@pobox.com> Date: Wed, 23 Mar 2005 03:57:56 -0500 From: Jeff Garzik User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.3) Gecko/20040922 X-Accept-Language: en-us, en MIME-Version: 1.0 To: bert hubert CC: Netdev , "akpm @ osdl. org Linux Kernel" Subject: Re: netdev-2.6 queue updated References: <4240E35C.2090203@pobox.com> <20050323075525.GA25273@outpost.ds9a.nl> In-Reply-To: <20050323075525.GA25273@outpost.ds9a.nl> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV 0.83/778/Mon Mar 21 02:48:43 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 560 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: jgarzik@pobox.com Precedence: bulk X-list: netdev Content-Length: 358 Lines: 17 bert hubert wrote: > On Tue, Mar 22, 2005 at 10:32:44PM -0500, Jeff Garzik wrote: > >>Wireless update, and various minor fixes. >> >>BK URL, patch URL, and changelog attached. > > > Jeff, akpm can you predict if this will make 2.6.12? Especially the wireless > & hostap stuff. 2.6.12 is in release candidate status, which means only bug fixes. Jeff From herbert@gondor.apana.org.au Wed Mar 23 01:26:38 2005 Received: with ECARTIS (v1.0.0; list netdev); Wed, 23 Mar 2005 01:26:45 -0800 (PST) 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 j2N9QasL001938 for ; Wed, 23 Mar 2005 01:26:37 -0800 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 1DE27H-0002GA-00; Wed, 23 Mar 2005 20:25:31 +1100 Received: from herbert by gondolin.me.apana.org.au with local (Exim 3.36 #1 (Debian)) id 1DE26e-0003as-00; Wed, 23 Mar 2005 20:24:52 +1100 Date: Wed, 23 Mar 2005 20:24:52 +1100 To: Patrick McHardy Cc: "David S. Miller" , kuznet@ms2.inr.ac.ru, yoshfuji@linux-ipv6.org, netdev@oss.sgi.com Subject: Re: [22/*] [NETFILTER] Use correct IPsec MTU in TCPMSS Message-ID: <20050323092451.GA13758@gondor.apana.org.au> References: <20050308102741.GA23468@gondor.apana.org.au> <20050314102614.GA9610@gondor.apana.org.au> <20050314105313.GA21001@gondor.apana.org.au> <20050314111002.GA29156@gondor.apana.org.au> <20050315091904.GA6256@gondor.apana.org.au> <20050315095837.GA7130@gondor.apana.org.au> <20050318090310.GA28443@gondor.apana.org.au> <20050318091129.GA28658@gondor.apana.org.au> <20050318104013.57d65e99.davem@davemloft.net> <423D9ADA.6050407@trash.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <423D9ADA.6050407@trash.net> User-Agent: Mutt/1.5.6+20040907i From: Herbert Xu X-Virus-Scanned: ClamAV 0.83/778/Mon Mar 21 02:48:43 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 561 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: herbert@gondor.apana.org.au Precedence: bulk X-list: netdev Content-Length: 632 Lines: 15 On Sun, Mar 20, 2005 at 04:46:34PM +0100, Patrick McHardy wrote: > > been done. The current input patch makes packets that have been > handled by IPsec skip the netfilter hooks until we know no further > IPsec processing will be done (route is non-local or protocol handler > is not marked as xfrm_prot). The packet is then marked as completely Could you send me (or the list) a copy of the current input patch? 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 hidden@balabit.hu Wed Mar 23 01:57:17 2005 Received: with ECARTIS (v1.0.0; list netdev); Wed, 23 Mar 2005 01:57:23 -0800 (PST) Received: from balabit.hu (balabit.hu [195.70.34.196]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j2N9vF1h004253 for ; Wed, 23 Mar 2005 01:57:16 -0800 Subject: Re: [IPSEC] Too many SADs! From: KOVACS Krisztian To: Wolfgang Walter Cc: netdev@oss.sgi.com, sfrost@snowman.net, ipsec-tools-devel In-Reply-To: <200503220052.52756.wolfgang.walter@studentenwerk.mhn.de> References: <200503220052.52756.wolfgang.walter@studentenwerk.mhn.de> Content-Type: multipart/mixed; boundary="=-K1x4Qy0k3vMShwSfUgYa" Date: Wed, 23 Mar 2005 10:57:25 +0100 Message-Id: <1111571845.3833.25.camel@nienna.balabit> Mime-Version: 1.0 X-Virus-Scanned: ClamAV 0.83/778/Mon Mar 21 02:48:43 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 562 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: hidden@balabit.hu Precedence: bulk X-list: netdev Content-Length: 3710 Lines: 90 --=-K1x4Qy0k3vMShwSfUgYa Content-Type: text/plain; charset=ISO-8859-2 Content-Transfer-Encoding: 8bit Hi, 2005-03-22, k keltezéssel 00.52-kor Wolfgang Walter ezt írta: > We had the same problem. Seems to be a limitation of the pfkey-implementation > of linux. This is not really a limitation of the PFKEY implementation, at least not a limitation related to some upper limit of the number of entries (no such limit exists). The problem itself is caused by the too simplistic SAD/SPD dumping code in the implementation, which does not care about possibly lost messages. The problem is as follows: when setkey requests a dump, the kernel responds with a stream of messages. Each of these contains the dump of an SAD/SPD entry, and contains a decreasing sequence number. The sequence number of the last message is zero, this way the receiving user-space application can tell that the dump is over. The problem occurs when there's not enough space in the socket buffer of the PFKEY socket. In this case the kernel simply drops all messages after the buffer becomes full, thus losing the precious end-of-dump marker last message as well. Racoon's setkey obviously cannot cope with this and is still waiting for the missing messages. The problem itself comes from the unreliable nature of PFKEY, so it's not something which can be solved, but there are more ways to work it around. AFAIK early Solaris PFKEY implementations made sure the first and last message in the dump is delivered. This way the user-space application has the possibility to detect problems and do something about them. Another solution is to make dumping an all-or-nothing operation, even at the cost of the socket buffer growing past its upper limit (this is in current NetBSD versions, for example). More information about the problem and its NetBSD workaround can be found here: http://mail-index.netbsd.org/tech-net/2004/05/21/0006.html As a quick and dirty hack to see if you have the same problem, try increasing the net.core.rmem_default sysctl value. If you set that to a larger value than the memory needed for the complete dump you should have no problems. Of course I wouldn't recommend this as a long-term "solution". Oh, wait, this is where a limitation of ipsec-tools comes into the picture. For some unknown reason, libipsec (PFKEY interface used by both setkey and racoon) sets the socket buffer size to 128K for _all_ PFKEY sockets. So even if you set a much higher default value through sysctl, setkey dumbly sets the limit to 128K. IMHO this is a bug in ipsec-tools, it should not impose such limitations. I've attached a quick-and-dirty patch which removes those ugly setsockopts. > We switched to iproute2 and openswan which both use the netfilter-interface. > Therefor they can handle thousands of SAD and SPD rules. Seems to justify the PFKEY problems I've summarized above. -- Regards, Krisztian Kovacs --=-K1x4Qy0k3vMShwSfUgYa Content-Disposition: attachment; filename=ipsec-tools_pfkey_limitation_fix.diff Content-Type: text/x-patch; name=ipsec-tools_pfkey_limitation_fix.diff; charset=ISO-8859-2 Content-Transfer-Encoding: 7bit --- ipsec-tools-0_5-branch/src/libipsec/pfkey.c 2004-09-13 16:09:18.000000000 +0200 +++ ipsec-tools-0_5-branch/src/libipsec/pfkey.c.new 2005-03-23 10:55:50.000000000 +0100 @@ -1713,13 +1713,6 @@ return -1; } - /* - * This is a temporary workaround for KAME PR 154. - * Don't really care even if it fails. - */ - (void)setsockopt(so, SOL_SOCKET, SO_SNDBUF, &bufsiz, sizeof(bufsiz)); - (void)setsockopt(so, SOL_SOCKET, SO_RCVBUF, &bufsiz, sizeof(bufsiz)); - __ipsec_errcode = EIPSEC_NO_ERROR; return so; } --=-K1x4Qy0k3vMShwSfUgYa-- From herbert@gondor.apana.org.au Wed Mar 23 03:32:36 2005 Received: with ECARTIS (v1.0.0; list netdev); Wed, 23 Mar 2005 03:32:44 -0800 (PST) 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 j2NBWYx6013359 for ; Wed, 23 Mar 2005 03:32:35 -0800 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 1DE45w-0003OH-00; Wed, 23 Mar 2005 22:32:16 +1100 Received: from herbert by gondolin.me.apana.org.au with local (Exim 3.36 #1 (Debian)) id 1DE44X-0001QM-00; Wed, 23 Mar 2005 22:30:49 +1100 From: Herbert Xu To: yxie@cs.stanford.edu (Yichen Xie) Subject: Re: memory leak in net/sched/ipt.c? Cc: linux-kernel@vger.kernel.org, netdev@oss.sgi.com, davem@davemloft.net, kaber@trash.net, hadi@cyberus.ca Organization: Core In-Reply-To: X-Newsgroups: apana.lists.os.linux.kernel User-Agent: tin/1.7.4-20040225 ("Benbecula") (UNIX) (Linux/2.4.27-hx-1-686-smp (i686)) Message-Id: Date: Wed, 23 Mar 2005 22:30:49 +1100 X-Virus-Scanned: ClamAV 0.83/778/Mon Mar 21 02:48:43 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 563 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: herbert@gondor.apana.org.au Precedence: bulk X-list: netdev Content-Length: 958 Lines: 33 Yichen Xie wrote: > Is the memory block allocated on line 315 leaked every time tcp_ipt_dump > is called? It seems to be. This patch should free it. Signed-off-by: Herbert Xu BTW, please report networking bugs to netdev@oss.sgi.com. 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 -- ===== net/sched/ipt.c 1.14 vs edited ===== --- 1.14/net/sched/ipt.c 2005-02-07 16:39:40 +11:00 +++ edited/net/sched/ipt.c 2005-03-23 22:28:13 +11:00 @@ -284,10 +284,12 @@ tm.lastuse = jiffies_to_clock_t(jiffies - p->tm.lastuse); tm.expires = jiffies_to_clock_t(p->tm.expires); RTA_PUT(skb, TCA_IPT_TM, sizeof (tm), &tm); + kfree(t); return skb->len; rtattr_failure: skb_trim(skb, b - skb->data); + kfree(t); return -1; } From wolfgang.walter@studentenwerk.mhn.de Wed Mar 23 04:20:30 2005 Received: with ECARTIS (v1.0.0; list netdev); Wed, 23 Mar 2005 04:20:35 -0800 (PST) Received: from mailout.stusta.mhn.de (emailhub.stusta.mhn.de [141.84.69.5]) by oss.sgi.com (8.13.0/8.13.0) with SMTP id j2NCKTJs025236 for ; Wed, 23 Mar 2005 04:20:30 -0800 Received: (qmail 11938 invoked from network); 23 Mar 2005 12:20:23 -0000 Received: from mailhub.stusta.mhn.de (HELO eumel.h3.stusta.mhn.de) (10.150.127.10) by mailout.stusta.mhn.de with SMTP; 23 Mar 2005 12:20:23 -0000 From: Wolfgang Walter To: Stephen Frost Subject: Re: [IPSEC] Too many SADs! Date: Wed, 23 Mar 2005 13:20:21 +0100 User-Agent: KMail/1.7.2 Organization: Studentenwerk =?utf-8?q?M=C3=BCnchen?= Cc: netdev@oss.sgi.com MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200503231320.21645.wolfgang.walter@studentenwerk.mhn.de> X-Virus-Scanned: ClamAV 0.83/781/Wed Mar 23 03:58:42 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 564 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: wolfgang.walter@studentenwerk.mhn.de Precedence: bulk X-list: netdev Content-Length: 2501 Lines: 65 > > We had the same problem. Seems to be a limitation of the pfkey-implementation > > of linux. > > > > racoon and setkey both use the pfkey-interface. > > > > We switched to iproute2 and openswan which both use the netfilter-interface. Sorry, wanted to say netlink-interface. > > Therefor they can handle thousands of SAD and SPD rules. > > Well, that's quite interesting. I didn't realize there were multiple > interfaces to the IPSEC in Linux. Additionally, the problem isn't that > I've got too many policies which end up requiring too many SADs- the > problem is that SADs are being created above and beyond what's actually > necessary for my policies, which is a problem. I'm not entirely sure > why that's happening either. At one point a SAD was being added every > second when there was *already* an apparently current SAD for the > required policy. Not good, looks like a bug to me, and I would have > thought it was a kernel bug but I could be wrong there. Hmm, we saw this with racoon, too. I think that linux sometimes can not send pfkey-messages because it can not allocate enough memory in that moment. The message get lost and then racoon and kernel have different views of the situation. I think the pfkey-protocoll is unreliable by design so racoon should handle that. If you start racoon with no spd-rules and then start to add a lot of them with setkey you get a similar behaviour: some of the new rules don't make it to racoon and racoon will never learn them. (we tried this as a workaround because racoon does not start when more than about 400 spd-rules are already set). That racoon does not start with more then about 400 spd-rules seems to be also a problem of the pfkey-implementation: the pfkey-answer to the dump-request which racoons does at startup gets to large: the kernel can not allocate enough memory. (and this is the reason setkey can not list the rules, either, so you may use it to add more spd-rules it can later list). > > I'm certainly curious about the alternative interface to IPSEC in > Linux, and especially your claim that it's a 'netfilter' interface. As mentioned, meant netlink-interface, not netfilter. > I'll certainly look into that... What kernel are you using? What > version of iproute2 and Openswan? Do you have to patch the kernel? > iproute2 from debian unstable (20041019-3). openswan from debian unstable: openswan 2.3.0 (debian version: 2.3.0-2) > Stephen > Greetings, Wolfgang Walter From wolfgang.walter@studentenwerk.mhn.de Wed Mar 23 04:22:15 2005 Received: with ECARTIS (v1.0.0; list netdev); Wed, 23 Mar 2005 04:22:19 -0800 (PST) Received: from mailout.stusta.mhn.de (mailout.stusta.mhn.de [141.84.69.5]) by oss.sgi.com (8.13.0/8.13.0) with SMTP id j2NCMENJ025720 for ; Wed, 23 Mar 2005 04:22:14 -0800 Received: (qmail 11988 invoked from network); 23 Mar 2005 12:22:08 -0000 Received: from mailout.stusta.mhn.de (HELO eumel.h3.stusta.mhn.de) (10.150.127.10) by mailout.stusta.mhn.de with SMTP; 23 Mar 2005 12:22:08 -0000 From: Wolfgang Walter To: netdev@oss.sgi.com Subject: Re: [IPSEC] Too many SADs! Date: Wed, 23 Mar 2005 13:22:07 +0100 User-Agent: KMail/1.7.2 Organization: Studentenwerk =?iso-8859-1?q?M=FCnchen?= MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200503231322.07455.wolfgang.walter@studentenwerk.mhn.de> X-Virus-Scanned: ClamAV 0.83/781/Wed Mar 23 03:58:42 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 565 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: wolfgang.walter@studentenwerk.mhn.de Precedence: bulk X-list: netdev Content-Length: 1405 Lines: 38 > What, openswan uses PF_KEY last I checked on kernel 2.6. I > guess you can use KLIPS, but why would you? What's this > "netfilter-interface" to ipsec code? > Sorry, meant netlink-interface. > I had the exact same problem the original poster had with > Racoon. SPDs would multiply without bounds, seemingly > geometrically. > I switched to strongswan and the problems immediately > vanished. There is some bug in racoon where it doesn't > replace SPDs. I used the latest ipsec-utils and kernel and > this problem did not go away until I switched instead to > strongswan (still using PF_KEY) (it also worked with > openswan). We don't use openswan with KLIPS but with native ipsec. I'm rather sure that openswan 2.3.0 uses netlink with native ipsec - there is no pfkey-socket open when running pluto and pluto opens a netlink-socket. Does not really matter. The problem of racoon is that it does a spd-dump when started. The kernel seems to run out of memory when generating such a huge pfkey-message. The same is true for setkey. You can use it to add thousands of spd-rules but you may not dump (and so list) them (you can use iproute2 to check that setkey really added those entries). So we use iproute2 to flush and list our spd and to set up static spd-rules (especially those for discard and none policies). We use pluto from openswan 2.3.0 for IKE. Greetings, Wolfgang Walter From hadi@cyberus.ca Wed Mar 23 04:40:28 2005 Received: with ECARTIS (v1.0.0; list netdev); Wed, 23 Mar 2005 04:40:33 -0800 (PST) Received: from mx03.cybersurf.com (mx03.cybersurf.com [209.197.145.106]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j2NCeS0H027454 for ; Wed, 23 Mar 2005 04:40:28 -0800 Received: from mail.cyberus.ca ([209.197.145.21]) by mx03.cybersurf.com with esmtp (Exim 4.30) id 1DE59t-0005ws-GE for netdev@oss.sgi.com; Wed, 23 Mar 2005 07:40:25 -0500 Received: from [24.103.99.32] (helo=[10.0.0.9]) by mail.cyberus.ca with esmtp (Exim 4.20) id 1DE59p-0004cF-0B; Wed, 23 Mar 2005 07:40:21 -0500 Subject: Re: memory leak in net/sched/ipt.c? From: jamal Reply-To: hadi@cyberus.ca To: Herbert Xu Cc: Yichen Xie , linux-kernel@vger.kernel.org, netdev@oss.sgi.com, "David S. Miller" , kaber@trash.net In-Reply-To: References: Content-Type: text/plain Organization: jamalopolous Message-Id: <1111581618.1088.72.camel@jzny.localdomain> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.2.2 Date: 23 Mar 2005 07:40:18 -0500 Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV 0.83/781/Wed Mar 23 03:58:42 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 566 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: hadi@cyberus.ca Precedence: bulk X-list: netdev Content-Length: 700 Lines: 25 On Wed, 2005-03-23 at 06:30, Herbert Xu wrote: > Yichen Xie wrote: > > Is the memory block allocated on line 315 leaked every time tcp_ipt_dump > > is called? > > It seems to be. This patch should free it. > > Signed-off-by: Herbert Xu > > BTW, please report networking bugs to netdev@oss.sgi.com. > Thanks for pointing this out - I _know_ its in the kernel list FAQ. I was sitting beside R Gooch when he added "thou shalt post to netdev". And of course i am gonna bitch about it every time someone doesnt post to netdev;-> Just a small correction to patchlet: The second kfree should check for existence of t. cheers, jamal > Thanks, From tgraf@suug.ch Wed Mar 23 04:55:00 2005 Received: with ECARTIS (v1.0.0; list netdev); Wed, 23 Mar 2005 04:55:05 -0800 (PST) Received: from b.mx.projectdream.org (eth0-0.arisu.projectdream.org [194.158.4.191]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j2NCsxIi030126 for ; Wed, 23 Mar 2005 04:55:00 -0800 Received: from postel.suug.ch (postel.suug.ch [195.134.158.23]) (using TLSv1 with cipher EDH-RSA-DES-CBC3-SHA (168/168 bits)) (No client certificate requested) by b.mx.projectdream.org (Postfix) with ESMTP id 0ACB585; Wed, 23 Mar 2005 13:54:33 +0100 (CET) Received: by postel.suug.ch (Postfix, from userid 10001) id 187991C0E9; Wed, 23 Mar 2005 13:55:16 +0100 (CET) Date: Wed, 23 Mar 2005 13:55:16 +0100 From: Thomas Graf To: jamal Cc: Herbert Xu , Yichen Xie , linux-kernel@vger.kernel.org, netdev@oss.sgi.com, "David S. Miller" , kaber@trash.net Subject: Re: memory leak in net/sched/ipt.c? Message-ID: <20050323125516.GP3086@postel.suug.ch> References: <1111581618.1088.72.camel@jzny.localdomain> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1111581618.1088.72.camel@jzny.localdomain> X-Virus-Scanned: ClamAV 0.83/781/Wed Mar 23 03:58:42 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 567 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: tgraf@suug.ch Precedence: bulk X-list: netdev Content-Length: 574 Lines: 15 * jamal <1111581618.1088.72.camel@jzny.localdomain> 2005-03-23 07:40 > On Wed, 2005-03-23 at 06:30, Herbert Xu wrote: > > Yichen Xie wrote: > > > Is the memory block allocated on line 315 leaked every time tcp_ipt_dump > > > is called? > > > > It seems to be. This patch should free it. > > > > Signed-off-by: Herbert Xu > Just a small correction to patchlet: > The second kfree should check for existence of t. t is either valid or NULL so it's not a problem, unless you want to create janitor work of course. ;-> From hadi@cyberus.ca Wed Mar 23 05:11:46 2005 Received: with ECARTIS (v1.0.0; list netdev); Wed, 23 Mar 2005 05:11:50 -0800 (PST) Received: from mx03.cybersurf.com (mx03.cybersurf.com [209.197.145.106]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j2NDBjCW031960 for ; Wed, 23 Mar 2005 05:11:45 -0800 Received: from mail.cyberus.ca ([209.197.145.21]) by mx03.cybersurf.com with esmtp (Exim 4.30) id 1DE5eA-000872-NE for netdev@oss.sgi.com; Wed, 23 Mar 2005 08:11:42 -0500 Received: from [24.103.99.32] (helo=[10.0.0.9]) by mail.cyberus.ca with esmtp (Exim 4.20) id 1DE5e7-0000T9-NO; Wed, 23 Mar 2005 08:11:40 -0500 Subject: Re: memory leak in net/sched/ipt.c? From: jamal Reply-To: hadi@cyberus.ca To: Thomas Graf Cc: Herbert Xu , Yichen Xie , linux-kernel@vger.kernel.org, netdev@oss.sgi.com, "David S. Miller" , kaber@trash.net In-Reply-To: <20050323125516.GP3086@postel.suug.ch> References: <1111581618.1088.72.camel@jzny.localdomain> <20050323125516.GP3086@postel.suug.ch> Content-Type: text/plain Organization: jamalopolous Message-Id: <1111583497.1089.92.camel@jzny.localdomain> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.2.2 Date: 23 Mar 2005 08:11:37 -0500 Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV 0.83/781/Wed Mar 23 03:58:42 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 568 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: hadi@cyberus.ca Precedence: bulk X-list: netdev Content-Length: 560 Lines: 17 On Wed, 2005-03-23 at 07:55, Thomas Graf wrote: > * jamal <1111581618.1088.72.camel@jzny.localdomain> 2005-03-23 07:40 > > Just a small correction to patchlet: > > The second kfree should check for existence of t. > > t is either valid or NULL so it's not a problem, unless you want > to create janitor work of course. ;-> if t is null you still goto rtattr_failure I have seen people put little comments of "kfree will work if you pass it NULL" - are you saying such assumptions exist all over net/sched? didnt understand the janitor part. cheers, jamal From tgraf@suug.ch Wed Mar 23 05:23:14 2005 Received: with ECARTIS (v1.0.0; list netdev); Wed, 23 Mar 2005 05:23:19 -0800 (PST) Received: from b.mx.projectdream.org (eth0-0.arisu.projectdream.org [194.158.4.191]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j2NDNDvs000765 for ; Wed, 23 Mar 2005 05:23:14 -0800 Received: from postel.suug.ch (postel.suug.ch [195.134.158.23]) (using TLSv1 with cipher EDH-RSA-DES-CBC3-SHA (168/168 bits)) (No client certificate requested) by b.mx.projectdream.org (Postfix) with ESMTP id 91D8085; Wed, 23 Mar 2005 14:22:50 +0100 (CET) Received: by postel.suug.ch (Postfix, from userid 10001) id 0E43F1C0E9; Wed, 23 Mar 2005 14:23:33 +0100 (CET) Date: Wed, 23 Mar 2005 14:23:32 +0100 From: Thomas Graf To: jamal Cc: Herbert Xu , Yichen Xie , linux-kernel@vger.kernel.org, netdev@oss.sgi.com, "David S. Miller" , kaber@trash.net Subject: Re: memory leak in net/sched/ipt.c? Message-ID: <20050323132332.GQ3086@postel.suug.ch> References: <1111581618.1088.72.camel@jzny.localdomain> <20050323125516.GP3086@postel.suug.ch> <1111583497.1089.92.camel@jzny.localdomain> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1111583497.1089.92.camel@jzny.localdomain> X-Virus-Scanned: ClamAV 0.83/781/Wed Mar 23 03:58:42 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 569 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: tgraf@suug.ch Precedence: bulk X-list: netdev Content-Length: 991 Lines: 24 * jamal <1111583497.1089.92.camel@jzny.localdomain> 2005-03-23 08:11 > On Wed, 2005-03-23 at 07:55, Thomas Graf wrote: > > * jamal <1111581618.1088.72.camel@jzny.localdomain> 2005-03-23 07:40 > > > > Just a small correction to patchlet: > > > The second kfree should check for existence of t. > > > > t is either valid or NULL so it's not a problem, unless you want > > to create janitor work of course. ;-> > > if t is null you still goto rtattr_failure > I have seen people put little comments of "kfree will work if you > pass it NULL" - are you saying such assumptions exist all over > net/sched? kfree simply does nothing if it is given a null pointer so that goto rtattr_failure for t == NULL is handled just fine without a check. I will never get used to this behaviour and policy as well though, it somewhat makes code less readable. > didnt understand the janitor part. It will probably be removed again by one of the regular 'remove unnecessary pre kfree checks' patchsets. From hadi@cyberus.ca Wed Mar 23 05:32:51 2005 Received: with ECARTIS (v1.0.0; list netdev); Wed, 23 Mar 2005 05:32:57 -0800 (PST) Received: from mx02.cybersurf.com (mx02.cybersurf.com [209.197.145.105]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j2NDWolQ007761 for ; Wed, 23 Mar 2005 05:32:51 -0800 Received: from mail.cyberus.ca ([209.197.145.21]) by mx02.cybersurf.com with esmtp (Exim 4.30) id 1DE5yY-0005df-HY for netdev@oss.sgi.com; Wed, 23 Mar 2005 08:32:46 -0500 Received: from [24.103.99.32] (helo=[10.0.0.9]) by mail.cyberus.ca with esmtp (Exim 4.20) id 1DE5yV-0003TN-6E; Wed, 23 Mar 2005 08:32:43 -0500 Subject: Re: memory leak in net/sched/ipt.c? From: jamal Reply-To: hadi@cyberus.ca To: Thomas Graf Cc: Herbert Xu , Yichen Xie , linux-kernel@vger.kernel.org, netdev@oss.sgi.com, "David S. Miller" , kaber@trash.net In-Reply-To: <20050323132332.GQ3086@postel.suug.ch> References: <1111581618.1088.72.camel@jzny.localdomain> <20050323125516.GP3086@postel.suug.ch> <1111583497.1089.92.camel@jzny.localdomain> <20050323132332.GQ3086@postel.suug.ch> Content-Type: text/plain Organization: jamalopolous Message-Id: <1111584760.1089.112.camel@jzny.localdomain> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.2.2 Date: 23 Mar 2005 08:32:40 -0500 Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV 0.83/781/Wed Mar 23 03:58:42 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 570 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: hadi@cyberus.ca Precedence: bulk X-list: netdev Content-Length: 718 Lines: 26 On Wed, 2005-03-23 at 08:23, Thomas Graf wrote: > > kfree simply does nothing if it is given a null pointer so that > goto rtattr_failure for t == NULL is handled just fine without > a check. I will never get used to this behaviour and policy as > well though, it somewhat makes code less readable. > I cant get used to it either; actually i dont think i would be able to stop my fingers ;-> > > didnt understand the janitor part. > > It will probably be removed again by one of the regular 'remove > unnecessary pre kfree checks' patchsets. > Yes, already Jan Engelhardt has made that point - although he did not post to netdev!! ;-> So ignore my comment Herbert cheers, jamal From jengelh@linux01.gwdg.de Wed Mar 23 05:40:41 2005 Received: with ECARTIS (v1.0.0; list netdev); Wed, 23 Mar 2005 05:40:45 -0800 (PST) Received: from linux01.gwdg.de (root@linux01.gwdg.de [134.76.13.21]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j2NDeeM0008829 for ; Wed, 23 Mar 2005 05:40:40 -0800 Received: from linux01.gwdg.de (localhost [127.0.0.1]) by linux01.gwdg.de (8.12.7/8.12.7/SuSE Linux 0.6) with ESMTP id j2NDea33013329; Wed, 23 Mar 2005 14:40:36 +0100 Received: from localhost (jengelh@localhost) by linux01.gwdg.de (8.12.7/8.12.7/Submit) with ESMTP id j2NDeanZ013315; Wed, 23 Mar 2005 14:40:36 +0100 Date: Wed, 23 Mar 2005 14:40:36 +0100 (MET) From: Jan Engelhardt To: jamal cc: linux-kernel@vger.kernel.org, netdev@oss.sgi.com Subject: Re: memory leak in net/sched/ipt.c? In-Reply-To: <1111583497.1089.92.camel@jzny.localdomain> Message-ID: References: <1111581618.1088.72.camel@jzny.localdomain> <20050323125516.GP3086@postel.suug.ch> <1111583497.1089.92.camel@jzny.localdomain> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Virus-Scanned: ClamAV 0.83/781/Wed Mar 23 03:58:42 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 571 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: jengelh@linux01.gwdg.de Precedence: bulk X-list: netdev Content-Length: 232 Lines: 9 >I have seen people put little comments of "kfree will work if you >pass it NULL" - are you saying such assumptions exist all over >net/sched? Not only net/sched. The C standard requires that free(NULL) works. Jan Engelhardt -- From hadi@cyberus.ca Wed Mar 23 06:05:59 2005 Received: with ECARTIS (v1.0.0; list netdev); Wed, 23 Mar 2005 06:06:03 -0800 (PST) Received: from mx01.cybersurf.com (mx01.cybersurf.com [209.197.145.104]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j2NE5wGN023368 for ; Wed, 23 Mar 2005 06:05:59 -0800 Received: from mail.cyberus.ca ([209.197.145.21]) by mx01.cybersurf.com with esmtp (Exim 4.30) id 1DE6Ua-0002Tz-VW for netdev@oss.sgi.com; Wed, 23 Mar 2005 07:05:52 -0700 Received: from [216.209.86.2] (helo=[10.0.0.9]) by mail.cyberus.ca with esmtp (Exim 4.20) id 1DE6Ua-0000jz-JZ; Wed, 23 Mar 2005 09:05:52 -0500 Subject: Re: memory leak in net/sched/ipt.c? From: jamal Reply-To: hadi@cyberus.ca To: Jan Engelhardt Cc: linux-kernel@vger.kernel.org, netdev@oss.sgi.com In-Reply-To: References: <1111581618.1088.72.camel@jzny.localdomain> <20050323125516.GP3086@postel.suug.ch> <1111583497.1089.92.camel@jzny.localdomain> Content-Type: text/plain Organization: jamalopolous Message-Id: <1111586750.1075.0.camel@jzny.localdomain> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.2.2 Date: 23 Mar 2005 09:05:50 -0500 Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV 0.83/781/Wed Mar 23 03:58:42 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 572 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: hadi@cyberus.ca Precedence: bulk X-list: netdev Content-Length: 317 Lines: 12 On Wed, 2005-03-23 at 08:40, Jan Engelhardt wrote: > >I have seen people put little comments of "kfree will work if you > >pass it NULL" - are you saying such assumptions exist all over > >net/sched? > > Not only net/sched. The C standard requires that free(NULL) works. Thanks for clarifying this. cheers, jamal From hadi@cyberus.ca Wed Mar 23 06:12:55 2005 Received: with ECARTIS (v1.0.0; list netdev); Wed, 23 Mar 2005 06:13:00 -0800 (PST) Received: from mx01.cybersurf.com (mx01.cybersurf.com [209.197.145.104]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j2NECt14024321 for ; Wed, 23 Mar 2005 06:12:55 -0800 Received: from mail.cyberus.ca ([209.197.145.21]) by mx01.cybersurf.com with esmtp (Exim 4.30) id 1DE6bJ-0002qD-QB for netdev@oss.sgi.com; Wed, 23 Mar 2005 07:12:49 -0700 Received: from [216.209.86.2] (helo=[10.0.0.9]) by mail.cyberus.ca with esmtp (Exim 4.20) id 1DE6bL-00023B-6t; Wed, 23 Mar 2005 09:12:51 -0500 Subject: Re: memory leak in net/sched/ipt.c? From: jamal Reply-To: hadi@cyberus.ca To: Jan Engelhardt Cc: linux-kernel@vger.kernel.org, netdev@oss.sgi.com In-Reply-To: <1111586750.1075.0.camel@jzny.localdomain> References: <1111581618.1088.72.camel@jzny.localdomain> <20050323125516.GP3086@postel.suug.ch> <1111583497.1089.92.camel@jzny.localdomain> <1111586750.1075.0.camel@jzny.localdomain> Content-Type: text/plain Organization: jamalopolous Message-Id: <1111587168.1072.4.camel@jzny.localdomain> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.2.2 Date: 23 Mar 2005 09:12:48 -0500 Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV 0.83/781/Wed Mar 23 03:58:42 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 573 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: hadi@cyberus.ca Precedence: bulk X-list: netdev Content-Length: 622 Lines: 24 Actually its well documented even on the man pages - so should have not even have bothered discussing it;-> Should get new brand of coffee. Apologies for unecessarily abused electrons - which means dont respond ;-> cheers, jamal On Wed, 2005-03-23 at 09:05, jamal wrote: > On Wed, 2005-03-23 at 08:40, Jan Engelhardt wrote: > > >I have seen people put little comments of "kfree will work if you > > >pass it NULL" - are you saying such assumptions exist all over > > >net/sched? > > > > Not only net/sched. The C standard requires that free(NULL) works. > > Thanks for clarifying this. > > cheers, > jamal > > > From colin@colino.net Wed Mar 23 06:26:42 2005 Received: with ECARTIS (v1.0.0; list netdev); Wed, 23 Mar 2005 06:26:50 -0800 (PST) Received: from paperstreet.colino.net (colino.net [213.41.131.56]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j2NEQf0L026038 for ; Wed, 23 Mar 2005 06:26:42 -0800 Received: by paperstreet.colino.net (Postfix, from userid 1015) id 67D2A101A1; Wed, 23 Mar 2005 15:26:30 +0100 (CET) Received: from jack.colino.net (yannmarigo.net1.nerim.net [62.212.96.151]) by paperstreet.colino.net (Postfix) with ESMTP id 183F810196; Wed, 23 Mar 2005 15:26:21 +0100 (CET) Date: Wed, 23 Mar 2005 15:26:12 +0100 From: Colin Leroy To: netdev@oss.sgi.com Cc: linux-kernel@vger.kernel.org Subject: RFC: workaround quality bug in zd1201 hardware Message-ID: <20050323152612.66dce7e2@jack.colino.net> X-Mailer: Sylpheed-Claws 1.9.6cvs9 (GTK+ 2.6.1; powerpc-unknown-linux-gnu) X-Face: Fy:*XpRna1/tz}cJ@O'0^:qYs:8b[Rg`*8,+o^[fI?<%5LeB,Xz8ZJK[r7V0hBs8G)*&C+XA0qHoR=LoTohe@7X5K$A-@cN6n~~J/]+{[)E4h'lK$13WQf$.R+Pi;E09tk&{t|;~dakRD%CLHrk6m!?gA,5|Sb=fJ=>[9#n1Bu8?VngkVM4{'^'V_qgdA.8yn3) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV 0.83/781/Wed Mar 23 03:58:42 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 574 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: colin@colino.net Precedence: bulk X-list: netdev Content-Length: 2175 Lines: 64 Hi, I saw in zd1201.c that there's a hardware bug related to quality statistics: /* Unfortunatly the quality and noise reported is useless. they seem to be accumulators that increase until you read them, unless we poll on a fixed interval we can't use them */ Given that I couldn't find any spec for the zd1201, I tried the following patch to see if we could cheat by updating commsquality while scanning. The idea is to use the values we find during scan and copy them to zd->iwstats; this can be useful because there are a lots of tools out there that perform scanning periodically (netapplet, NetworkManager, ...). Unfortunately this doesn't work perfectly, because it looks like the scale is different when reporting AP quality on scanning and "normal" quality. Maybe this can be made useful with a simple conversion ? If anyone that has more knowledge on 802.11b than I have could give me an hint, it'd be appreciated. Thanks! Signed-off-by: Colin Leroy --- a/drivers/usb/net/zd1201.c 2005-03-23 15:17:12.000000000 +0100 +++ b/drivers/usb/net/zd1201.c 2005-03-23 15:17:50.000000000 +0100 @@ -1160,6 +1160,7 @@ return -EIO; for(i=8; irxlen; i+=62) { + const char *ap_essid; iwe.cmd = SIOCGIWAP; iwe.u.ap_addr.sa_family = ARPHRD_ETHER; memcpy(iwe.u.ap_addr.sa_data, zd->rxdata+i+6, 6); @@ -1169,6 +1170,7 @@ iwe.u.data.length = zd->rxdata[i+16]; iwe.u.data.flags = 1; cev = iwe_stream_add_point(cev, end_buf, &iwe, zd->rxdata+i+18); + ap_essid = zd->rxdata+i+18; iwe.cmd = SIOCGIWMODE; if (zd->rxdata[i+14]&0x01) @@ -1204,6 +1206,17 @@ iwe.u.qual.noise= zd->rxdata[i+2]/10-100; iwe.u.qual.level = (256+zd->rxdata[i+4]*100)/255-100; iwe.u.qual.updated = 7; + + if (ap_essid && zd->essid && !strcmp(ap_essid, zd->essid)) { + /* hack: work around hardware bug, update current + * link quality using the scan result. + */ + zd->iwstats.qual.qual = iwe.u.qual.qual; + zd->iwstats.qual.level = iwe.u.qual.level; + zd->iwstats.qual.noise = iwe.u.qual.noise; + zd->iwstats.qual.updated = 2; + } + cev = iwe_stream_add_event(cev, end_buf, &iwe, IW_EV_QUAL_LEN); } From nacc@us.ibm.com Wed Mar 23 09:28:54 2005 Received: with ECARTIS (v1.0.0; list netdev); Wed, 23 Mar 2005 09:29:00 -0800 (PST) Received: from e35.co.us.ibm.com (e35.co.us.ibm.com [32.97.110.133]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j2NHSl2Y009434 for ; Wed, 23 Mar 2005 09:28:54 -0800 Received: from westrelay02.boulder.ibm.com (westrelay02.boulder.ibm.com [9.17.195.11]) by e35.co.us.ibm.com (8.12.10/8.12.9) with ESMTP id j2NHSeLg450700 for ; Wed, 23 Mar 2005 12:28:40 -0500 Received: from d03av02.boulder.ibm.com (d03av02.boulder.ibm.com [9.17.195.168]) by westrelay02.boulder.ibm.com (8.12.10/NCO/VER6.6) with ESMTP id j2NHSed3211228 for ; Wed, 23 Mar 2005 10:28:40 -0700 Received: from d03av02.boulder.ibm.com (loopback [127.0.0.1]) by d03av02.boulder.ibm.com (8.12.11/8.12.11) with ESMTP id j2NHSeRl025677 for ; Wed, 23 Mar 2005 10:28:40 -0700 Received: from joust (joust.beaverton.ibm.com [9.47.17.68]) by d03av02.boulder.ibm.com (8.12.11/8.12.11) with ESMTP id j2NHSdVC025648; Wed, 23 Mar 2005 10:28:40 -0700 Received: by joust (Postfix, from userid 1000) id 8E2EF4F8A4; Wed, 23 Mar 2005 09:28:38 -0800 (PST) Date: Wed, 23 Mar 2005 09:28:38 -0800 From: Nishanth Aravamudan To: Jeff Garzik Cc: domen@coderock.org, netdev@oss.sgi.com Subject: Re: [patch 14/26] net/slip: replace schedule_timeout() with msleep() Message-ID: <20050323172838.GA2679@us.ibm.com> References: <20050306103322.857041F203@trashy.coderock.org> <4240B152.4080904@pobox.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4240B152.4080904@pobox.com> X-Operating-System: Linux 2.6.11 (i686) User-Agent: Mutt/1.5.6+20040907i X-Virus-Scanned: ClamAV 0.83/781/Wed Mar 23 03:58:42 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 575 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: nacc@us.ibm.com Precedence: bulk X-list: netdev Content-Length: 1535 Lines: 47 On Tue, Mar 22, 2005 at 06:59:14PM -0500, Jeff Garzik wrote: > domen@coderock.org wrote: > >Use msleep() instead of schedule_timeout() to guarantee > >the task delays as expected. While the original code does use > >TASK_INTERRUPTIBLE, it does not check for signals, so I believe msleep() > >is more > >appropriate. > > > >Signed-off-by: Nishanth Aravamudan > >Signed-off-by: Domen Puncer > >--- > > > > > > kj-domen/drivers/net/slip.c | 7 +++---- > > 1 files changed, 3 insertions(+), 4 deletions(-) > > > >diff -puN drivers/net/slip.c~msleep-drivers_net_slip drivers/net/slip.c > >--- kj/drivers/net/slip.c~msleep-drivers_net_slip 2005-03-05 > >16:10:49.000000000 +0100 > >+++ kj-domen/drivers/net/slip.c 2005-03-05 16:10:49.000000000 +0100 > >@@ -75,6 +75,7 @@ > > #include > > #include > > #include > >+#include > > #include "slip.h" > > #ifdef CONFIG_INET > > #include > >@@ -1395,10 +1396,8 @@ static void __exit slip_exit(void) > > /* First of all: check for active disciplines and hangup them. > > */ > > do { > >- if (busy) { > >- set_current_state(TASK_INTERRUPTIBLE); > >- schedule_timeout(HZ / 10); > >- } > >+ if (busy) > >+ msleep(100); > > msleep_interruptible I'm fine with changing this; what should the code do if a signal causes an early return? I switched to msleep() in my patch because the current code did nothing and that seemed buggy to me. Thanks for the feedback, Nish From wolfgang.walter@studentenwerk.mhn.de Wed Mar 23 10:15:48 2005 Received: with ECARTIS (v1.0.0; list netdev); Wed, 23 Mar 2005 10:15:56 -0800 (PST) Received: from email.studentenwerk.mhn.de (dresden.studentenwerk.mhn.de [141.84.225.229]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j2NIFlen013160 for ; Wed, 23 Mar 2005 10:15:48 -0800 Received: from mailhub.studentenwerk.mhn.de (s007034.int.studentenwerk.mhn.de [10.148.7.34]) by email.studentenwerk.mhn.de (Postfix) with ESMTP id A19E858002; Wed, 23 Mar 2005 19:15:41 +0100 (CET) Received: from mist.studentenwerk.mhn.de (mist.studentenwerk.mhn.de [10.148.0.198]) by mailhub.studentenwerk.mhn.de (Postfix) with ESMTP id 9791754002; Wed, 23 Mar 2005 19:15:41 +0100 (CET) From: Wolfgang Walter Organization: Studentenwerk =?iso-8859-1?q?M=FCnchen?= To: KOVACS Krisztian Subject: Re: [IPSEC] Too many SADs! Date: Wed, 23 Mar 2005 19:15:40 +0100 User-Agent: KMail/1.7.2 References: <200503220052.52756.wolfgang.walter@studentenwerk.mhn.de> <1111571845.3833.25.camel@nienna.balabit> In-Reply-To: <1111571845.3833.25.camel@nienna.balabit> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-15" Content-Disposition: inline Message-Id: <200503231915.40882.wolfgang.walter@studentenwerk.mhn.de> X-Virus-Scanned: ClamAV 0.83/781/Wed Mar 23 03:58:42 2005 on oss.sgi.com X-Virus-Status: Clean Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by oss.sgi.com id j2NIFlen013160 X-archive-position: 576 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: wolfgang.walter@studentenwerk.mhn.de Precedence: bulk X-list: netdev Content-Length: 4874 Lines: 110 Am Mittwoch, 23. März 2005 10:57 schrieben Sie: > Hi, > > 2005-03-22, k keltezéssel 00.52-kor Wolfgang Walter ezt írta: > > We had the same problem. Seems to be a limitation of the > > pfkey-implementation of linux. > > This is not really a limitation of the PFKEY implementation, at least > not a limitation related to some upper limit of the number of entries > (no such limit exists). The problem itself is caused by the too > simplistic SAD/SPD dumping code in the implementation, which does not > care about possibly lost messages. The problem is as follows: when > setkey requests a dump, the kernel responds with a stream of messages. > Each of these contains the dump of an SAD/SPD entry, and contains a > decreasing sequence number. The sequence number of the last message is > zero, this way the receiving user-space application can tell that the > dump is over. > > The problem occurs when there's not enough space in the socket buffer > of the PFKEY socket. In this case the kernel simply drops all messages > after the buffer becomes full, thus losing the precious end-of-dump > marker last message as well. Racoon's setkey obviously cannot cope with > this and is still waiting for the missing messages. > > The problem itself comes from the unreliable nature of PFKEY, so it's > not something which can be solved, but there are more ways to work it > around. > > AFAIK early Solaris PFKEY implementations made sure the first and last > message in the dump is delivered. This way the user-space application > has the possibility to detect problems and do something about them. > Another solution is to make dumping an all-or-nothing operation, even at > the cost of the socket buffer growing past its upper limit (this is in > current NetBSD versions, for example). More information about the > problem and its NetBSD workaround can be found here: > Thanks for the explanation. > http://mail-index.netbsd.org/tech-net/2004/05/21/0006.html > > As a quick and dirty hack to see if you have the same problem, try > increasing the net.core.rmem_default sysctl value. If you set that to a > larger value than the memory needed for the complete dump you should > have no problems. Of course I wouldn't recommend this as a long-term > "solution". We tried that. Detected a hard limit you mention later. I think one should not need to manipulate net.core.rmem_default. It would be better if racoon tried to set the buffer size high enough or had at least a option to set the size. > > Oh, wait, this is where a limitation of ipsec-tools comes into the > picture. For some unknown reason, libipsec (PFKEY interface used by both > setkey and racoon) sets the socket buffer size to 128K for _all_ PFKEY > sockets. So even if you set a much higher default value through sysctl, > setkey dumbly sets the limit to 128K. IMHO this is a bug in ipsec-tools, > it should not impose such limitations. I've attached a quick-and-dirty > patch which removes those ugly setsockopts. > Though this may solve the problem with dump I still think racoon together with pfkey will not handle large spd-sets reliable. We did the following test: start racoon with an empty set and then add spd-rules with setkey. Even with a relativ slow rate (say 1 rule/s) the kernel seems to drop pfkey-messages once and again and racoon will therfor not see these policies. I think that the kernel dropped these messages simply because it fails to allocate memory for the message. Probably this will happen for other pfkey-messages from kernel to userspace, too. > > We switched to iproute2 and openswan which both use the > > netfilter-interface. Therefor they can handle thousands of SAD and SPD > > rules. > > Seems to justify the PFKEY problems I've summarized above. Probably, for the dump-case especially. But I think that the way racoon works makes it more difficult to ensure that kernel and racoon are synchronous. The relationship between pluto and kernel is simple: pluto is the master of its rules: if you want to change policy-rules created by pluto you must not change them via the kernel but change them via pluto which then updates them in the kernel. On the other side pluto only manipulates its own rules. With racoon you manipulate the ruleset in the kernel and racoon updates its own database from it. If a pfkey-message is lost racoon would have to know that so it can dump the spd (res. sad for messages concerning the sad). I personally think that it would be better if racoon would not read the spd but instead create the spd-rules itself from its racoon.conf because your racoon.conf must fit your spd anyway (and sometimes racoon already needs to create spd-rules itself (for the road-warrior-case i.e.)). Greetings, -- Wolfgang Walter Studentenwerk München Anstalt des öffentlichen Rechts EDV Leopoldstraße 15 80802 München From mchan@broadcom.com Wed Mar 23 10:17:01 2005 Received: with ECARTIS (v1.0.0; list netdev); Wed, 23 Mar 2005 10:17:08 -0800 (PST) Received: from MMS3.broadcom.com (mms3.broadcom.com [216.31.210.19]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j2NIH1FZ013433 for ; Wed, 23 Mar 2005 10:17:01 -0800 Received: from 10.10.64.121 by MMS3.broadcom.com with SMTP (Broadcom SMTP Relay (Email Firewall v6.1.0)); Wed, 23 Mar 2005 10:16:52 -0800 X-Server-Uuid: 35E76369-CF33-4172-911A-D1698BD5E887 Received: from mail-irva-8.broadcom.com ([10.10.64.221]) by mail-irva-1.broadcom.com (Post.Office MTA v3.5.3 release 223 ID# 0-72233U7200L2200S0V35) with ESMTP id com; Wed, 23 Mar 2005 10:16:40 -0800 Received: from mon-irva-10.broadcom.com (mon-irva-10.broadcom.com [10.10.64.171]) by mail-irva-8.broadcom.com (MOS 3.5.6-GR) with ESMTP id APV01848; Wed, 23 Mar 2005 10:16:24 -0800 (PST) Received: from nt-irva-0741.brcm.ad.broadcom.com ( nt-irva-0741.brcm.ad.broadcom.com [10.8.194.54]) by mon-irva-10.broadcom.com (8.9.1/8.9.1) with ESMTP id KAA08219; Wed, 23 Mar 2005 10:16:23 -0800 (PST) X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Subject: Re: [PATCH 2.6.11 4/8] tg3: Add msi test Date: Wed, 23 Mar 2005 10:16:23 -0800 Message-ID: Thread-Topic: [PATCH 2.6.11 4/8] tg3: Add msi test Thread-Index: AcUvOn0zVk5wkESmSNqgFq43XYPMMAAj54ig From: "Michael Chan" To: "David S. Miller" , "Jeff Garzik" cc: netdev@oss.sgi.com X-WSS-ID: 6E5F6D1925S2409557-01-01 Content-Type: text/plain; charset=us-ascii X-Virus-Scanned: ClamAV 0.83/781/Wed Mar 23 03:58:42 2005 on oss.sgi.com X-Virus-Status: Clean Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by oss.sgi.com id j2NIH1FZ013433 X-archive-position: 577 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: mchan@broadcom.com Precedence: bulk X-list: netdev Content-Length: 1055 Lines: 32 "David S. Miller" wrote: > > On Tue, 22 Mar 2005 18:50:36 -0500 > Jeff Garzik wrote: > > > Sorry, I still disagree. We need to think about how to handle this > > situation for -all- drivers and -all- users, not just tg3. > > When you come up with something that doesn't require the > users to ask around and report stuff when MSI doesn't work, > let me know. > > But for now let's hold off on the tg3 MSI support, ok? > > Jeff, I understand your point of view which is from the kernel development perspective. For us, we have to consider the user's perspective when he is trying to figure out why things are not working. Let's see if we can address your concerns with the following: #1. Keep the msi test but add a message telling the user to report to the PCI maintainer when msi test fails, as David suggested. #2. Do the msi test and if it fails, just print a message telling the user to disable MSI some other way and report to PCI maintainer. This will at least identify the potential problem to the user. Michael From yxie@cs.stanford.edu Wed Mar 23 10:28:11 2005 Received: with ECARTIS (v1.0.0; list netdev); Wed, 23 Mar 2005 10:28:19 -0800 (PST) Received: from smtp-roam.Stanford.EDU (smtp-roam.Stanford.EDU [171.64.10.152]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j2NISBGC014850 for ; Wed, 23 Mar 2005 10:28:11 -0800 Received: from 0lv07r (shangri-la.Stanford.EDU [128.12.172.101]) (authenticated bits=0) by smtp-roam.Stanford.EDU (8.12.11/8.12.11) with ESMTP id j2NIRWNR004495 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Wed, 23 Mar 2005 10:27:32 -0800 Message-Id: <200503231827.j2NIRWNR004495@smtp-roam.Stanford.EDU> From: "Yichen Xie" To: "'Herbert Xu'" Cc: , , , , Subject: RE: memory leak in net/sched/ipt.c? Date: Wed, 23 Mar 2005 10:27:32 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook, Build 11.0.6353 In-Reply-To: Thread-Index: AcUvnALmsC8+39CcQWaO7tjvU6FmxgAOYmKw X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2527 X-Virus-Scanned: ClamAV 0.83/781/Wed Mar 23 03:58:42 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 578 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: yxie@cs.stanford.edu Precedence: bulk X-list: netdev Content-Length: 1471 Lines: 46 Thanks for confirming. Are you guys interested in this kind of leaks? I have a list of about a hundred generated by our tool. -yichen > -----Original Message----- > From: Herbert Xu [mailto:herbert@gondor.apana.org.au] > Sent: Wednesday, March 23, 2005 3:31 AM > To: Yichen Xie > Cc: linux-kernel@vger.kernel.org; netdev@oss.sgi.com; > davem@davemloft.net; kaber@trash.net; hadi@cyberus.ca > Subject: Re: memory leak in net/sched/ipt.c? > > Yichen Xie wrote: > > Is the memory block allocated on line 315 leaked every time > > tcp_ipt_dump is called? > > It seems to be. This patch should free it. > > Signed-off-by: Herbert Xu > > BTW, please report networking bugs to netdev@oss.sgi.com. > > 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 > -- > ===== net/sched/ipt.c 1.14 vs edited ===== > --- 1.14/net/sched/ipt.c 2005-02-07 16:39:40 +11:00 > +++ edited/net/sched/ipt.c 2005-03-23 22:28:13 +11:00 > @@ -284,10 +284,12 @@ > tm.lastuse = jiffies_to_clock_t(jiffies - p->tm.lastuse); > tm.expires = jiffies_to_clock_t(p->tm.expires); > RTA_PUT(skb, TCA_IPT_TM, sizeof (tm), &tm); > + kfree(t); > return skb->len; > > rtattr_failure: > skb_trim(skb, b - skb->data); > + kfree(t); > return -1; > } > > From davem@davemloft.net Wed Mar 23 10:55:53 2005 Received: with ECARTIS (v1.0.0; list netdev); Wed, 23 Mar 2005 10:55:57 -0800 (PST) Received: from cheetah.davemloft.net (mail@dsl027-180-174.sfo1.dsl.speakeasy.net [216.27.180.174]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j2NItrca016775 for ; Wed, 23 Mar 2005 10:55:53 -0800 Received: from localhost ([127.0.0.1] helo=cheetah.davemloft.net ident=davem) by cheetah.davemloft.net with smtp (Exim 3.36 #1 (Debian)) id 1DEAzR-0007Rh-00; Wed, 23 Mar 2005 10:54:01 -0800 Date: Wed, 23 Mar 2005 10:54:00 -0800 From: "David S. Miller" To: "chas williams - CONTRACTOR" Cc: netdev@oss.sgi.com Subject: Re: [PATCH 2/6][ATM]: [zatm] fix sparse warning Message-Id: <20050323105400.6c258dcc.davem@davemloft.net> In-Reply-To: <200503230054.j2N0sg7s028376@ginger.cmf.nrl.navy.mil> References: <200503230054.j2N0sg7s028376@ginger.cmf.nrl.navy.mil> X-Mailer: Sylpheed version 1.0.1 (GTK+ 1.2.10; sparc-unknown-linux-gnu) X-Face: "_;p5u5aPsO,_Vsx"^v-pEq09'CU4&Dc1$fQExov$62l60cgCc%FnIwD=.UF^a>?5'9Kn[;433QFVV9M..2eN.@4ZWPGbdi<=?[:T>y?SD(R*-3It"Vj:)"dP Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV 0.83/781/Wed Mar 23 03:58:42 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 580 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: davem@davemloft.net Precedence: bulk X-list: netdev Content-Length: 152 Lines: 6 On Tue, 22 Mar 2005 19:54:43 -0500 "chas williams - CONTRACTOR" wrote: > please apply to 2.6 -- thanks! Applied, thanks Chas. From davem@davemloft.net Wed Mar 23 10:55:13 2005 Received: with ECARTIS (v1.0.0; list netdev); Wed, 23 Mar 2005 10:55:19 -0800 (PST) Received: from cheetah.davemloft.net (mail@dsl027-180-174.sfo1.dsl.speakeasy.net [216.27.180.174]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j2NItBCE016712 for ; Wed, 23 Mar 2005 10:55:13 -0800 Received: from localhost ([127.0.0.1] helo=cheetah.davemloft.net ident=davem) by cheetah.davemloft.net with smtp (Exim 3.36 #1 (Debian)) id 1DEAya-0007RK-00; Wed, 23 Mar 2005 10:53:08 -0800 Date: Wed, 23 Mar 2005 10:53:08 -0800 From: "David S. Miller" To: "chas williams - CONTRACTOR" Cc: netdev@oss.sgi.com, davem@redhat.com Subject: Re: [PATCH 1/6][ATM]: remove bridge/lec interdependency Message-Id: <20050323105308.64c3f597.davem@davemloft.net> In-Reply-To: <200503230054.j2N0sC52028366@ginger.cmf.nrl.navy.mil> References: <200503230054.j2N0sC52028366@ginger.cmf.nrl.navy.mil> X-Mailer: Sylpheed version 1.0.1 (GTK+ 1.2.10; sparc-unknown-linux-gnu) X-Face: "_;p5u5aPsO,_Vsx"^v-pEq09'CU4&Dc1$fQExov$62l60cgCc%FnIwD=.UF^a>?5'9Kn[;433QFVV9M..2eN.@4ZWPGbdi<=?[:T>y?SD(R*-3It"Vj:)"dP Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV 0.83/781/Wed Mar 23 03:58:42 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 579 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: davem@davemloft.net Precedence: bulk X-list: netdev Content-Length: 150 Lines: 6 On Tue, 22 Mar 2005 19:54:14 -0500 "chas williams - CONTRACTOR" wrote: > please apply to 2.6 -- thanks! Apply, thanks Chas. From davem@davemloft.net Wed Mar 23 10:59:12 2005 Received: with ECARTIS (v1.0.0; list netdev); Wed, 23 Mar 2005 10:59:16 -0800 (PST) Received: from cheetah.davemloft.net (mail@dsl027-180-174.sfo1.dsl.speakeasy.net [216.27.180.174]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j2NIxCtY017989 for ; Wed, 23 Mar 2005 10:59:12 -0800 Received: from localhost ([127.0.0.1] helo=cheetah.davemloft.net ident=davem) by cheetah.davemloft.net with smtp (Exim 3.36 #1 (Debian)) id 1DEB2e-0007SE-00; Wed, 23 Mar 2005 10:57:20 -0800 Date: Wed, 23 Mar 2005 10:57:20 -0800 From: "David S. Miller" To: "chas williams - CONTRACTOR" Cc: netdev@oss.sgi.com Subject: Re: [PATCH 3/6][ATM]: [nicstar] fix some sparse warnings Message-Id: <20050323105720.3b56d74d.davem@davemloft.net> In-Reply-To: <200503230055.j2N0t7xf028383@ginger.cmf.nrl.navy.mil> References: <200503230055.j2N0t7xf028383@ginger.cmf.nrl.navy.mil> X-Mailer: Sylpheed version 1.0.1 (GTK+ 1.2.10; sparc-unknown-linux-gnu) X-Face: "_;p5u5aPsO,_Vsx"^v-pEq09'CU4&Dc1$fQExov$62l60cgCc%FnIwD=.UF^a>?5'9Kn[;433QFVV9M..2eN.@4ZWPGbdi<=?[:T>y?SD(R*-3It"Vj:)"dP Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV 0.83/781/Wed Mar 23 03:58:42 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 581 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: davem@davemloft.net Precedence: bulk X-list: netdev Content-Length: 152 Lines: 6 On Tue, 22 Mar 2005 19:55:08 -0500 "chas williams - CONTRACTOR" wrote: > please apply to 2.6 -- thanks! Applied, thanks Chas. From davem@davemloft.net Wed Mar 23 11:00:09 2005 Received: with ECARTIS (v1.0.0; list netdev); Wed, 23 Mar 2005 11:00:13 -0800 (PST) Received: from cheetah.davemloft.net (mail@dsl027-180-174.sfo1.dsl.speakeasy.net [216.27.180.174]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j2NJ07Se018074 for ; Wed, 23 Mar 2005 11:00:09 -0800 Received: from localhost ([127.0.0.1] helo=cheetah.davemloft.net ident=davem) by cheetah.davemloft.net with smtp (Exim 3.36 #1 (Debian)) id 1DEB3S-0007Se-00; Wed, 23 Mar 2005 10:58:10 -0800 Date: Wed, 23 Mar 2005 10:58:10 -0800 From: "David S. Miller" To: "chas williams - CONTRACTOR" Cc: netdev@oss.sgi.com, davem@redhat.com Subject: Re: [PATCH 4/6][ATM]: [ambassador] fix sparse warnings Message-Id: <20050323105810.439101ca.davem@davemloft.net> In-Reply-To: <200503230055.j2N0tTq3028390@ginger.cmf.nrl.navy.mil> References: <200503230055.j2N0tTq3028390@ginger.cmf.nrl.navy.mil> X-Mailer: Sylpheed version 1.0.1 (GTK+ 1.2.10; sparc-unknown-linux-gnu) X-Face: "_;p5u5aPsO,_Vsx"^v-pEq09'CU4&Dc1$fQExov$62l60cgCc%FnIwD=.UF^a>?5'9Kn[;433QFVV9M..2eN.@4ZWPGbdi<=?[:T>y?SD(R*-3It"Vj:)"dP Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV 0.83/781/Wed Mar 23 03:58:42 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 582 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: davem@davemloft.net Precedence: bulk X-list: netdev Content-Length: 152 Lines: 6 On Tue, 22 Mar 2005 19:55:30 -0500 "chas williams - CONTRACTOR" wrote: > please apply to 2.6 -- thanks! Applied, thanks Chas. From davem@davemloft.net Wed Mar 23 11:00:52 2005 Received: with ECARTIS (v1.0.0; list netdev); Wed, 23 Mar 2005 11:00:56 -0800 (PST) Received: from cheetah.davemloft.net (mail@dsl027-180-174.sfo1.dsl.speakeasy.net [216.27.180.174]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j2NJ0pcj018448 for ; Wed, 23 Mar 2005 11:00:51 -0800 Received: from localhost ([127.0.0.1] helo=cheetah.davemloft.net ident=davem) by cheetah.davemloft.net with smtp (Exim 3.36 #1 (Debian)) id 1DEB4E-0007Sz-00; Wed, 23 Mar 2005 10:58:58 -0800 Date: Wed, 23 Mar 2005 10:58:58 -0800 From: "David S. Miller" To: "chas williams - CONTRACTOR" Cc: netdev@oss.sgi.com, davem@redhat.com Subject: Re: [PATCH 5/6][ATM]: [lanai] alpha build fixes Message-Id: <20050323105858.6d730d23.davem@davemloft.net> In-Reply-To: <200503230056.j2N0uZcf028407@ginger.cmf.nrl.navy.mil> References: <200503230056.j2N0uZcf028407@ginger.cmf.nrl.navy.mil> X-Mailer: Sylpheed version 1.0.1 (GTK+ 1.2.10; sparc-unknown-linux-gnu) X-Face: "_;p5u5aPsO,_Vsx"^v-pEq09'CU4&Dc1$fQExov$62l60cgCc%FnIwD=.UF^a>?5'9Kn[;433QFVV9M..2eN.@4ZWPGbdi<=?[:T>y?SD(R*-3It"Vj:)"dP Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV 0.83/781/Wed Mar 23 03:58:42 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 583 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: davem@davemloft.net Precedence: bulk X-list: netdev Content-Length: 152 Lines: 6 On Tue, 22 Mar 2005 19:56:36 -0500 "chas williams - CONTRACTOR" wrote: > please apply to 2.6 -- thanks! Applied, thanks Chas. From davem@davemloft.net Wed Mar 23 11:01:53 2005 Received: with ECARTIS (v1.0.0; list netdev); Wed, 23 Mar 2005 11:01:58 -0800 (PST) Received: from cheetah.davemloft.net (mail@dsl027-180-174.sfo1.dsl.speakeasy.net [216.27.180.174]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j2NJ1rOQ019107 for ; Wed, 23 Mar 2005 11:01:53 -0800 Received: from localhost ([127.0.0.1] helo=cheetah.davemloft.net ident=davem) by cheetah.davemloft.net with smtp (Exim 3.36 #1 (Debian)) id 1DEB5F-0007Tf-00; Wed, 23 Mar 2005 11:00:01 -0800 Date: Wed, 23 Mar 2005 11:00:00 -0800 From: "David S. Miller" To: "chas williams - CONTRACTOR" Cc: netdev@oss.sgi.com, davem@redhat.com Subject: Re: [PATCH 6/6][ATM]: assorted cleanups Message-Id: <20050323110000.423fb6b9.davem@davemloft.net> In-Reply-To: <200503230057.j2N0vBlq028423@ginger.cmf.nrl.navy.mil> References: <200503230057.j2N0vBlq028423@ginger.cmf.nrl.navy.mil> X-Mailer: Sylpheed version 1.0.1 (GTK+ 1.2.10; sparc-unknown-linux-gnu) X-Face: "_;p5u5aPsO,_Vsx"^v-pEq09'CU4&Dc1$fQExov$62l60cgCc%FnIwD=.UF^a>?5'9Kn[;433QFVV9M..2eN.@4ZWPGbdi<=?[:T>y?SD(R*-3It"Vj:)"dP Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV 0.83/781/Wed Mar 23 03:58:42 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 584 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: davem@davemloft.net Precedence: bulk X-list: netdev Content-Length: 157 Lines: 6 On Tue, 22 Mar 2005 19:57:12 -0500 "chas williams - CONTRACTOR" wrote: > please apply to 2.6 -- thanks! Also applied, thanks Chas. From davem@davemloft.net Wed Mar 23 11:05:35 2005 Received: with ECARTIS (v1.0.0; list netdev); Wed, 23 Mar 2005 11:05:40 -0800 (PST) Received: from cheetah.davemloft.net (mail@dsl027-180-174.sfo1.dsl.speakeasy.net [216.27.180.174]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j2NJ5YGL020443 for ; Wed, 23 Mar 2005 11:05:34 -0800 Received: from localhost ([127.0.0.1] helo=cheetah.davemloft.net ident=davem) by cheetah.davemloft.net with smtp (Exim 3.36 #1 (Debian)) id 1DEB8u-0007Vz-00; Wed, 23 Mar 2005 11:03:48 -0800 Date: Wed, 23 Mar 2005 11:03:47 -0800 From: "David S. Miller" To: "Michael Chan" Cc: netdev@oss.sgi.com Subject: Re: [PATCH 2.6.11 1/8] tg3: add 5705_plus flag Message-Id: <20050323110347.3b6dba18.davem@davemloft.net> In-Reply-To: References: X-Mailer: Sylpheed version 1.0.1 (GTK+ 1.2.10; sparc-unknown-linux-gnu) X-Face: "_;p5u5aPsO,_Vsx"^v-pEq09'CU4&Dc1$fQExov$62l60cgCc%FnIwD=.UF^a>?5'9Kn[;433QFVV9M..2eN.@4ZWPGbdi<=?[:T>y?SD(R*-3It"Vj:)"dP Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV 0.83/781/Wed Mar 23 03:58:42 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 585 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: davem@davemloft.net Precedence: bulk X-list: netdev Content-Length: 347 Lines: 11 On Sun, 20 Mar 2005 23:14:42 -0800 "Michael Chan" wrote: > Add a 5705_plus flag to indicate the device is 5705, 5750, or future chips > that all share the same basic architecture. This makes it easier to add > support for future devices. > > Signed-off-by: Michael Chan Patch applied, thanks Michael. From davem@davemloft.net Wed Mar 23 11:08:47 2005 Received: with ECARTIS (v1.0.0; list netdev); Wed, 23 Mar 2005 11:08:51 -0800 (PST) Received: from cheetah.davemloft.net (mail@dsl027-180-174.sfo1.dsl.speakeasy.net [216.27.180.174]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j2NJ8ln1021129 for ; Wed, 23 Mar 2005 11:08:47 -0800 Received: from localhost ([127.0.0.1] helo=cheetah.davemloft.net ident=davem) by cheetah.davemloft.net with smtp (Exim 3.36 #1 (Debian)) id 1DEBC1-0007Xw-00; Wed, 23 Mar 2005 11:07:01 -0800 Date: Wed, 23 Mar 2005 11:07:00 -0800 From: "David S. Miller" To: "Michael Chan" Cc: netdev@oss.sgi.com Subject: Re: [PATCH 2.6.11 2/8] tg3: flush status block in tg3_interrupt Message-Id: <20050323110700.0f071073.davem@davemloft.net> In-Reply-To: References: X-Mailer: Sylpheed version 1.0.1 (GTK+ 1.2.10; sparc-unknown-linux-gnu) X-Face: "_;p5u5aPsO,_Vsx"^v-pEq09'CU4&Dc1$fQExov$62l60cgCc%FnIwD=.UF^a>?5'9Kn[;433QFVV9M..2eN.@4ZWPGbdi<=?[:T>y?SD(R*-3It"Vj:)"dP Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV 0.83/781/Wed Mar 23 03:58:42 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 586 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: davem@davemloft.net Precedence: bulk X-list: netdev Content-Length: 474 Lines: 12 On Sun, 20 Mar 2005 23:26:26 -0800 "Michael Chan" wrote: > Add register read of PCI state register in tg3_interrupt() if status block's > updated bit is not set. This will flush the status block and confirm whether > the interrupt is ours or not. PCI ordering rules allow the interrupt to > arrive at the CPU ahead of the status block that may be posted at the > chipset. > > Signed-off-by: Michael Chan Applied, thanks Michael. From davem@davemloft.net Wed Mar 23 11:11:08 2005 Received: with ECARTIS (v1.0.0; list netdev); Wed, 23 Mar 2005 11:11:12 -0800 (PST) Received: from cheetah.davemloft.net (mail@dsl027-180-174.sfo1.dsl.speakeasy.net [216.27.180.174]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j2NJB82D021700 for ; Wed, 23 Mar 2005 11:11:08 -0800 Received: from localhost ([127.0.0.1] helo=cheetah.davemloft.net ident=davem) by cheetah.davemloft.net with smtp (Exim 3.36 #1 (Debian)) id 1DEBEE-0007ZT-00; Wed, 23 Mar 2005 11:09:18 -0800 Date: Wed, 23 Mar 2005 11:09:18 -0800 From: "David S. Miller" To: "Michael Chan" Cc: netdev@oss.sgi.com Subject: Re: [PATCH 2.6.11 5/8] tg3: Add unstable PLL workaround for 5750 Message-Id: <20050323110918.460ff255.davem@davemloft.net> In-Reply-To: References: X-Mailer: Sylpheed version 1.0.1 (GTK+ 1.2.10; sparc-unknown-linux-gnu) X-Face: "_;p5u5aPsO,_Vsx"^v-pEq09'CU4&Dc1$fQExov$62l60cgCc%FnIwD=.UF^a>?5'9Kn[;433QFVV9M..2eN.@4ZWPGbdi<=?[:T>y?SD(R*-3It"Vj:)"dP Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV 0.83/781/Wed Mar 23 03:58:42 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 587 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: davem@davemloft.net Precedence: bulk X-list: netdev Content-Length: 287 Lines: 10 On Sun, 20 Mar 2005 23:48:13 -0800 "Michael Chan" wrote: > Add unstable PLL clock workaround for 5750 Ax and Bx devices. The workaround > code is run just before entering D3hot state. > > Signed-off-by: Michael Chan Applied, thanks Michael. From davem@davemloft.net Wed Mar 23 11:13:27 2005 Received: with ECARTIS (v1.0.0; list netdev); Wed, 23 Mar 2005 11:13:31 -0800 (PST) Received: from cheetah.davemloft.net (mail@dsl027-180-174.sfo1.dsl.speakeasy.net [216.27.180.174]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j2NJDQub022453 for ; Wed, 23 Mar 2005 11:13:27 -0800 Received: from localhost ([127.0.0.1] helo=cheetah.davemloft.net ident=davem) by cheetah.davemloft.net with smtp (Exim 3.36 #1 (Debian)) id 1DEBGW-0007br-00; Wed, 23 Mar 2005 11:11:40 -0800 Date: Wed, 23 Mar 2005 11:11:40 -0800 From: "David S. Miller" To: "Michael Chan" Cc: netdev@oss.sgi.com Subject: Re: [PATCH 2.6.11 6/8] tg3: Fix jumbo frames phy settings Message-Id: <20050323111140.4faf1561.davem@davemloft.net> In-Reply-To: References: X-Mailer: Sylpheed version 1.0.1 (GTK+ 1.2.10; sparc-unknown-linux-gnu) X-Face: "_;p5u5aPsO,_Vsx"^v-pEq09'CU4&Dc1$fQExov$62l60cgCc%FnIwD=.UF^a>?5'9Kn[;433QFVV9M..2eN.@4ZWPGbdi<=?[:T>y?SD(R*-3It"Vj:)"dP Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV 0.83/781/Wed Mar 23 03:58:42 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 588 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: davem@davemloft.net Precedence: bulk X-list: netdev Content-Length: 432 Lines: 12 On Mon, 21 Mar 2005 00:02:02 -0800 "Michael Chan" wrote: > Fix jumbo frame settings on all copper phys that support jumbo frames by > setting the fifo elasticity bit. This setting is for the phy's tx fifo to > properly handle jumbo frames. Note that a similar jumbo frame fix for the > phy's rx fifo was made to tg3 in the past. > > Signed-off-by: Michael Chan Applied, thanks Michael. From davem@davemloft.net Wed Mar 23 11:16:09 2005 Received: with ECARTIS (v1.0.0; list netdev); Wed, 23 Mar 2005 11:16:13 -0800 (PST) Received: from cheetah.davemloft.net (mail@dsl027-180-174.sfo1.dsl.speakeasy.net [216.27.180.174]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j2NJG8MJ023139 for ; Wed, 23 Mar 2005 11:16:09 -0800 Received: from localhost ([127.0.0.1] helo=cheetah.davemloft.net ident=davem) by cheetah.davemloft.net with smtp (Exim 3.36 #1 (Debian)) id 1DEBJ7-0007cM-00; Wed, 23 Mar 2005 11:14:21 -0800 Date: Wed, 23 Mar 2005 11:14:21 -0800 From: "David S. Miller" To: "Michael Chan" Cc: netdev@oss.sgi.com Subject: Re: [PATCH 2.6.11 7/8] tg3: Fix ethtool set functions Message-Id: <20050323111421.372c20a3.davem@davemloft.net> In-Reply-To: References: X-Mailer: Sylpheed version 1.0.1 (GTK+ 1.2.10; sparc-unknown-linux-gnu) X-Face: "_;p5u5aPsO,_Vsx"^v-pEq09'CU4&Dc1$fQExov$62l60cgCc%FnIwD=.UF^a>?5'9Kn[;433QFVV9M..2eN.@4ZWPGbdi<=?[:T>y?SD(R*-3It"Vj:)"dP Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV 0.83/781/Wed Mar 23 03:58:42 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 589 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: davem@davemloft.net Precedence: bulk X-list: netdev Content-Length: 512 Lines: 13 On Mon, 21 Mar 2005 00:13:07 -0800 "Michael Chan" wrote: > Fix all relevant ethtool set functions to properly handle the > !netif_running() case. In most cases, the new settings are accepted without > setting the hardware if !netif_running(). The new settings will take effect > when the device is subsequently brought up. tg3_nway_reset() is the exception > where it will return -EAGAIN if !netif_running(). > > Signed-off-by: Michael Chan Applied, thanks Michael. From davem@davemloft.net Wed Mar 23 11:17:34 2005 Received: with ECARTIS (v1.0.0; list netdev); Wed, 23 Mar 2005 11:17:38 -0800 (PST) Received: from cheetah.davemloft.net (mail@dsl027-180-174.sfo1.dsl.speakeasy.net [216.27.180.174]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j2NJHYhq023606 for ; Wed, 23 Mar 2005 11:17:34 -0800 Received: from localhost ([127.0.0.1] helo=cheetah.davemloft.net ident=davem) by cheetah.davemloft.net with smtp (Exim 3.36 #1 (Debian)) id 1DEBKV-0007dW-00; Wed, 23 Mar 2005 11:15:47 -0800 Date: Wed, 23 Mar 2005 11:15:47 -0800 From: "David S. Miller" To: "Michael Chan" Cc: netdev@oss.sgi.com Subject: Re: [PATCH 2.6.11 8/8] tg3: Add Broadcom copyright Message-Id: <20050323111547.5d4afa60.davem@davemloft.net> In-Reply-To: References: X-Mailer: Sylpheed version 1.0.1 (GTK+ 1.2.10; sparc-unknown-linux-gnu) X-Face: "_;p5u5aPsO,_Vsx"^v-pEq09'CU4&Dc1$fQExov$62l60cgCc%FnIwD=.UF^a>?5'9Kn[;433QFVV9M..2eN.@4ZWPGbdi<=?[:T>y?SD(R*-3It"Vj:)"dP Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV 0.83/781/Wed Mar 23 03:58:42 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 590 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: davem@davemloft.net Precedence: bulk X-list: netdev Content-Length: 186 Lines: 9 On Mon, 21 Mar 2005 00:16:31 -0800 "Michael Chan" wrote: > Add Broadcom copyright. > > Signed-off-by: Michael Chan Applied, thanks Michael. From davem@davemloft.net Wed Mar 23 11:18:52 2005 Received: with ECARTIS (v1.0.0; list netdev); Wed, 23 Mar 2005 11:18:57 -0800 (PST) Received: from cheetah.davemloft.net (mail@dsl027-180-174.sfo1.dsl.speakeasy.net [216.27.180.174]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j2NJIqLd024310 for ; Wed, 23 Mar 2005 11:18:52 -0800 Received: from localhost ([127.0.0.1] helo=cheetah.davemloft.net ident=davem) by cheetah.davemloft.net with smtp (Exim 3.36 #1 (Debian)) id 1DEBLh-0007dt-00; Wed, 23 Mar 2005 11:17:01 -0800 Date: Wed, 23 Mar 2005 11:17:01 -0800 From: "David S. Miller" To: Ralf Baechle DL5RB Cc: netdev@oss.sgi.com, linux-hams@vger.kernel.org Subject: Re: [PATCH] Get rid of sk_protinfo use in netrom Message-Id: <20050323111701.43e31617.davem@davemloft.net> In-Reply-To: <20050321094905.GA10022@linux-mips.org> References: <20050321094905.GA10022@linux-mips.org> X-Mailer: Sylpheed version 1.0.1 (GTK+ 1.2.10; sparc-unknown-linux-gnu) X-Face: "_;p5u5aPsO,_Vsx"^v-pEq09'CU4&Dc1$fQExov$62l60cgCc%FnIwD=.UF^a>?5'9Kn[;433QFVV9M..2eN.@4ZWPGbdi<=?[:T>y?SD(R*-3It"Vj:)"dP Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV 0.83/781/Wed Mar 23 03:58:42 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 591 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: davem@davemloft.net Precedence: bulk X-list: netdev Content-Length: 297 Lines: 8 On Mon, 21 Mar 2005 09:49:05 +0000 Ralf Baechle DL5RB wrote: > Below patch puts struct sock into nr_cb to get rid of the need for the > use of sk_protinfo in nr_sk(). While we're touching the data structure > convert it from a typedef into a struct. Applied, thanks Ralf. From davem@davemloft.net Wed Mar 23 11:19:42 2005 Received: with ECARTIS (v1.0.0; list netdev); Wed, 23 Mar 2005 11:19:46 -0800 (PST) Received: from cheetah.davemloft.net (mail@dsl027-180-174.sfo1.dsl.speakeasy.net [216.27.180.174]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j2NJJfs1024645 for ; Wed, 23 Mar 2005 11:19:41 -0800 Received: from localhost ([127.0.0.1] helo=cheetah.davemloft.net ident=davem) by cheetah.davemloft.net with smtp (Exim 3.36 #1 (Debian)) id 1DEBMX-0007eF-00; Wed, 23 Mar 2005 11:17:53 -0800 Date: Wed, 23 Mar 2005 11:17:53 -0800 From: "David S. Miller" To: Ralf Baechle DL5RB Cc: netdev@oss.sgi.com, linux-hams@vger.kernel.org Subject: Re: [PATCH] Get rid of sk_protinfo use in rose Message-Id: <20050323111753.5bb1f619.davem@davemloft.net> In-Reply-To: <20050321095037.GA10220@linux-mips.org> References: <20050321095037.GA10220@linux-mips.org> X-Mailer: Sylpheed version 1.0.1 (GTK+ 1.2.10; sparc-unknown-linux-gnu) X-Face: "_;p5u5aPsO,_Vsx"^v-pEq09'CU4&Dc1$fQExov$62l60cgCc%FnIwD=.UF^a>?5'9Kn[;433QFVV9M..2eN.@4ZWPGbdi<=?[:T>y?SD(R*-3It"Vj:)"dP Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV 0.83/781/Wed Mar 23 03:58:42 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 592 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: davem@davemloft.net Precedence: bulk X-list: netdev Content-Length: 306 Lines: 8 On Mon, 21 Mar 2005 09:50:37 +0000 Ralf Baechle DL5RB wrote: > Below patch puts struct sock into rose_cb to get rid of the need for the > use of sk_protinfo in rose_sk(). While we're touching the data structure > convert it from a typedef into a struct. Also applied, thanks Ralf. From dcn@sgi.com Wed Mar 23 11:30:05 2005 Received: with ECARTIS (v1.0.0; list netdev); Wed, 23 Mar 2005 11:30:09 -0800 (PST) Received: from omx2.sgi.com (omx2-ext.sgi.com [192.48.171.19]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j2NJTrd1026101 for ; Wed, 23 Mar 2005 11:29:53 -0800 Received: from flecktone.americas.sgi.com (flecktone.americas.sgi.com [198.149.16.15]) by omx2.sgi.com (8.12.11/8.12.9/linux-outbound_gateway-1.1) with ESMTP id j2NL5sWL023955 for ; Wed, 23 Mar 2005 13:06:04 -0800 Received: from sgi.com (aqua.americas.sgi.com [128.162.233.32]) by flecktone.americas.sgi.com (8.12.9/8.12.10/SGI_generic_relay-1.2) with ESMTP id j2NJTMR04574697; Wed, 23 Mar 2005 13:29:22 -0600 (CST) Received: by sgi.com (Postfix, from userid 144) id CB4E120423; Wed, 23 Mar 2005 13:29:21 -0600 (CST) Date: Wed, 23 Mar 2005 13:29:21 -0600 To: tony.luck@intel.com Cc: linux-ia64@vger.kernel.org, netdev@oss.sgi.com Subject: [PATCH 0/3] SGI Altix cross partition functionality (2nd revision) Message-ID: <4241C391.mailxHNA15A8V0@aqua.americas.sgi.com> User-Agent: nail 11.4 8/29/04 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit From: dcn@sgi.com (Dean Nelson) X-Virus-Scanned: ClamAV 0.83/781/Wed Mar 23 03:58:42 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 593 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: dcn@sgi.com Precedence: bulk X-list: netdev Content-Length: 2596 Lines: 58 Terminology The term 'partition', adopted by the SGI hardware designers and which perculated up into the software, is used in reference to a single SSI when multiple SSIs are running on a single Altix. An Altix running multiple SSIs is said to be 'partitioned', whereas one that is running only a single SSI is said to be 'unpartitioned'. The term '[a]cross partition' refers to a functionality that spans between two SSIs on a multi-SSI Altix. ('XP' is its abbreviation.) Introduction This feature provides cross partition functionality when running multiple partitions on a single SGI Altix. This functionality includes such things as a pseudo-ethernet driver and memory sharing, which are provided by functional support modules that sit on top of a low-level communication module. The communication module provides channels for point-to-point communication between the partitions. There is support for eight channels between any two partitions (currently only two channels are in use, the remainder are available for possible future expansion). A functional support module uses the same channel number for all of its cross partition communication across the entire Altix. There is a shim module that acts as an interface between the functional support modules and the communication module. Its sole purpose is to allow for the communication module to be rmmod'd/insmod'd without 'disturbing' the functional support modules and the user processes utilizing them. The shim module has also proven itself to be invaluable for debugging. This feature is being submitted as three separate quilt patches: XP - shim module XPC - cross partition (low-level) communication module XPNET - cross partition pseudo-ethernet driver functional support module (When time permits a patch will be submitted to add XPMEM, which is the functional support module that provides cross partition memory sharing.) This patch set is dependent upon the following patches: [patch - 2.6.11-rc5-mm1] genalloc - general purpose allocator [patch - 2.6.11-rc5-mm1] mspec ia64 memory special driver [patch 1/2] Altix: Shub2 BTE support [patch 2/2] Altix: Shub2 BTE support - BTE recovery code [PATCH] move cnodeid_to_nasid_table out of pda [PATCH] move nodepda pointer out of pda [PATCH] Export node_online_map and node_possible_map [PATCH] convert some sn SAL_CALLs to ia64_sal_oemcall calls [PATCH] Define some additional SHub1 and Shub2 register symbols [PATCH] Add some needed externs currently not defined ( The netdev folks only need to review the XPNET patch. ) From andy.furniss@dsl.pipex.com Wed Mar 23 11:33:01 2005 Received: with ECARTIS (v1.0.0; list netdev); Wed, 23 Mar 2005 11:33:07 -0800 (PST) Received: from galaxy.systems.pipex.net (galaxy.systems.pipex.net [62.241.162.31]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j2NJX0Mv026792 for ; Wed, 23 Mar 2005 11:33:01 -0800 Received: from [192.168.0.3] (81-178-146-253.dsl.pipex.com [81.178.146.253]) by galaxy.systems.pipex.net (Postfix) with ESMTP id 86B6AE000215; Wed, 23 Mar 2005 19:32:44 +0000 (GMT) Message-ID: <4241C478.5030309@dsl.pipex.com> Date: Wed, 23 Mar 2005 19:33:12 +0000 From: Andy Furniss User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.8b) Gecko/20050217 MIME-Version: 1.0 To: hadi@cyberus.ca Cc: Harald Welte , Patrick McHardy , Remus , netdev@oss.sgi.com, Nguyen Dinh Nam , Andre Tomt , syrius.ml@no-log.org, Damion de Soto Subject: Re: iptables breakage WAS(Re: dummy as IMQ replacement References: <1107123123.8021.80.camel@jzny.localdomain> <0fcf01c5077f$579e4b80$6e69690a@RIMAS> <1107174142.8021.121.camel@jzny.localdomain> <00c301c524b4$938cd240$6e69690a@RIMAS> <1110379135.1091.143.camel@jzny.localdomain> <1110416767.1111.76.camel@jzny.localdomain> <025501c52552$2dbf87c0$6e69690a@RIMAS> <1110453757.1108.87.camel@jzny.localdomain> <423B7BCB.10400@dsl.pipex.com> <1111410890.1092.195.camel@jzny.localdomain> <423F41AD.3010902@dsl.pipex.com> <1111444869.1072.51.camel@jzny.localdomain> <423F71C2.8040802@dsl.pipex.com> <1111462263.1109.6.camel@jzny.localdomain> <42408998.5000202@dsl.pipex.com> <1111550254.1089.21.camel@jzny.localdomain> In-Reply-To: <1111550254.1089.21.camel@jzny.localdomain> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV 0.83/781/Wed Mar 23 03:58:42 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 594 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: andy.furniss@dsl.pipex.com Precedence: bulk X-list: netdev Content-Length: 1983 Lines: 64 jamal wrote: > Ok, Andy - I have tested this and should all work. > Can you double check on your side before i push kernel patch to Dave? I > tested on ubuntu distro on an AMD athlon. > Attached tar.gz with necessary patches. I only bothered to do 2 out of 3 > tests. The second one covers the third. iptables libraries at runtime: > 1.3.1 OK rebuilt with those versions and patches. > TEST1: > > Check if ipt works on its own and stats are fixed. > > tc qdisc del dev eth0 ingress > tc qdisc add dev eth0 ingress > > tc filter add dev eth0 parent ffff: protocol ip prio 6 u32 \ > match ip src 10.0.2.24/32 flowid 1:16 \ > action ipt -j TOS --set-tos Maximize-Reliability Yes this works OK > TEST2: > - check if ipt followed by another action works. > - check if mirred works > > tc qdisc del dev eth0 ingress > tc qdisc add dev eth0 ingress > > tc filter add dev eth0 parent ffff: protocol ip prio 6 \ > u32 match ip src 10.0.2.24/32 flowid 1:16 \ > action ipt -j TOS --set-tos Maximize-Reliability \ > action mirred egress redirect dev lo Also works OK > bantu:~# tc -s filter ls dev eth0 parent ffff: didn't get bash prompt back after doing this till but works and looks OK. Works if I direct to dummy0 aswell :-) The thing that still fails is trying to use MARK - but I guess that's not to do with mirred as I don't get any mention of it anymore. [root@amd /home/andy/Qos]# tc qdisc del dev eth0 ingress RTNETLINK answers: No such file or directory [root@amd /home/andy/Qos]# tc qdisc add dev eth0 ingress [root@amd /home/andy/Qos]# tc filter add dev eth0 parent ffff: protocol ip prio 6 \ > u32 match ip src 10.0.2.24/32 flowid 1:16 \ > action ipt -j MARK --set-mark 1 tablename: mangle hook: NF_IP_PRE_ROUTING target: MARK set 0x1 index 0 RTNETLINK answers: Invalid argument We have an error talking to the kernel I get exactly the same error if I also add action mirred egress redirect dev lo - before I would get different. Andy. From hadi@cyberus.ca Wed Mar 23 11:45:31 2005 Received: with ECARTIS (v1.0.0; list netdev); Wed, 23 Mar 2005 11:45:36 -0800 (PST) Received: from mx02.cybersurf.com (mx02.cybersurf.com [209.197.145.105]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j2NJjUus028066 for ; Wed, 23 Mar 2005 11:45:31 -0800 Received: from mail.cyberus.ca ([209.197.145.21]) by mx02.cybersurf.com with esmtp (Exim 4.30) id 1DEBnE-0002St-OB for netdev@oss.sgi.com; Wed, 23 Mar 2005 14:45:28 -0500 Received: from [216.209.86.2] (helo=[10.0.0.9]) by mail.cyberus.ca with esmtp (Exim 4.20) id 1DEBn3-0007Se-FI; Wed, 23 Mar 2005 14:45:17 -0500 Subject: Re: iptables breakage WAS(Re: dummy as IMQ replacement From: jamal Reply-To: hadi@cyberus.ca To: Andy Furniss Cc: Harald Welte , Patrick McHardy , Remus , netdev@oss.sgi.com, Nguyen Dinh Nam , Andre Tomt , syrius.ml@no-log.org, Damion de Soto In-Reply-To: <4241C478.5030309@dsl.pipex.com> References: <1107123123.8021.80.camel@jzny.localdomain> <0fcf01c5077f$579e4b80$6e69690a@RIMAS> <1107174142.8021.121.camel@jzny.localdomain> <00c301c524b4$938cd240$6e69690a@RIMAS> <1110379135.1091.143.camel@jzny.localdomain> <1110416767.1111.76.camel@jzny.localdomain> <025501c52552$2dbf87c0$6e69690a@RIMAS> <1110453757.1108.87.camel@jzny.localdomain> <423B7BCB.10400@dsl.pipex.com> <1111410890.1092.195.camel@jzny.localdomain> <423F41AD.3010902@dsl.pipex.com> <1111444869.1072.51.camel@jzny.localdomain> <423F71C2.8040802@dsl.pipex.com> <1111462263.1109.6.camel@jzny.localdomain> <42408998.5000202@dsl.pipex.com> <1111550254.1089.21.camel@jzny.localdomain> <4241C478.5030309@dsl.pipex.com> Content-Type: text/plain Organization: jamalopolous Message-Id: <1111607112.1072.48.camel@jzny.localdomain> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.2.2 Date: 23 Mar 2005 14:45:12 -0500 Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV 0.83/781/Wed Mar 23 03:58:42 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 595 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: hadi@cyberus.ca Precedence: bulk X-list: netdev Content-Length: 1581 Lines: 51 On Wed, 2005-03-23 at 14:33, Andy Furniss wrote: > > bantu:~# tc -s filter ls dev eth0 parent ffff: > > didn't get bash prompt back after doing this till but works > and looks OK. Needs investigation. Lets defer for now, and see if it continues to happen > Works if I direct to dummy0 aswell :-) > Good - hopefully we can now get to where you started ;-> I will send the kernel patch to Dave later. > The thing that still fails is trying to use MARK - but I guess that's > not to do with mirred as I don't get any mention of it anymore. > For me all targets are compiled into the kernel; I didnt try with modules. If you have any modules try to compile in and see what happens. If it works it could spell trouble perhaps with some of the module replay code added recently. > [root@amd /home/andy/Qos]# tc qdisc del dev eth0 ingress > RTNETLINK answers: No such file or directory > [root@amd /home/andy/Qos]# tc qdisc add dev eth0 ingress > [root@amd /home/andy/Qos]# tc filter add dev eth0 parent ffff: protocol > ip prio 6 \ > > u32 match ip src 10.0.2.24/32 flowid 1:16 \ > > action ipt -j MARK --set-mark 1 > tablename: mangle hook: NF_IP_PRE_ROUTING > target: MARK set 0x1 index 0 > RTNETLINK answers: Invalid argument > We have an error talking to the kernel > Ok, try the module thing; actually try to modprobe mark target first and see if that works as well. > I get exactly the same error if I also add action mirred egress redirect > dev lo - before I would get different. > Didnt follow - still related to ipt? cheers, jamal From dcn@sgi.com Wed Mar 23 11:46:36 2005 Received: with ECARTIS (v1.0.0; list netdev); Wed, 23 Mar 2005 11:46:45 -0800 (PST) Received: from omx2.sgi.com (omx2-ext.sgi.com [192.48.171.19]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j2NJkNd0028299 for ; Wed, 23 Mar 2005 11:46:23 -0800 Received: from flecktone.americas.sgi.com (flecktone.americas.sgi.com [198.149.16.15]) by omx2.sgi.com (8.12.11/8.12.9/linux-outbound_gateway-1.1) with ESMTP id j2NLMNka027291 for ; Wed, 23 Mar 2005 13:22:33 -0800 Received: from sgi.com (aqua.americas.sgi.com [128.162.233.32]) by flecktone.americas.sgi.com (8.12.9/8.12.10/SGI_generic_relay-1.2) with ESMTP id j2NJjpR04576721; Wed, 23 Mar 2005 13:45:51 -0600 (CST) Received: by sgi.com (Postfix, from userid 144) id CC9EC2040B; Wed, 23 Mar 2005 13:45:50 -0600 (CST) Date: Wed, 23 Mar 2005 13:45:50 -0600 From: Dean Nelson To: tony.luck@intel.com Cc: netdev@oss.sgi.com, linux-ia64@vger.kernel.org Subject: [PATCH 1/3] SGI Altix cross partition functionality (2nd revision) Message-ID: <20050323194550.GA21418@sgi.com> References: <4241C391.mailxHNA15A8V0@aqua.americas.sgi.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4241C391.mailxHNA15A8V0@aqua.americas.sgi.com> User-Agent: Mutt/1.5.6i X-Virus-Scanned: ClamAV 0.83/781/Wed Mar 23 03:58:42 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 596 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: dcn@sgi.com Precedence: bulk X-list: netdev Content-Length: 30105 Lines: 815 This patch contains the shim module (XP) which interfaces between the communication module (XPC) and the functional support modules (like XPNET). Signed-off-by: Dean Nelson Index: linux-2.6/arch/ia64/Kconfig =================================================================== --- linux-2.6.orig/arch/ia64/Kconfig 2005-03-22 08:41:53.128253658 -0600 +++ linux-2.6/arch/ia64/Kconfig 2005-03-22 08:56:39.219766090 -0600 @@ -226,6 +226,16 @@ Fetchops are atomic memory operations that are implemented in the memory controller on SGI SN hardware. +config IA64_SGI_SN_XP + tristate "Support communication between SGI SSIs" + depends on MSPEC + help + An SGI machine can be divided into multiple Single System + Images which act independently of each other and have + hardware based memory protection from the others. Enabling + this feature will allow for direct communication between SSIs + based on a network adapter and DMA messaging. + config FORCE_MAX_ZONEORDER int default "18" Index: linux-2.6/arch/ia64/sn/kernel/xp_main.c =================================================================== --- /dev/null 1970-01-01 00:00:00.000000000 +0000 +++ linux-2.6/arch/ia64/sn/kernel/xp_main.c 2005-03-23 06:17:25.539741042 -0600 @@ -0,0 +1,289 @@ +/* + * This file is subject to the terms and conditions of the GNU General Public + * License. See the file "COPYING" in the main directory of this archive + * for more details. + * + * Copyright (c) 2004-2005 Silicon Graphics, Inc. All Rights Reserved. + */ + + +/* + * Cross Partition (XP) base. + * + * XP provides a base from which its users can interact + * with XPC, yet not be dependent on XPC. + * + */ + + +#include +#include +#include +#include +#include +#include + + +/* + * Target of nofault PIO read. + */ +u64 xp_nofault_PIOR_target; + + +/* + * xpc_registrations[] keeps track of xpc_connect()'s done by the kernel-level + * users of XPC. + */ +struct xpc_registration xpc_registrations[XPC_NCHANNELS]; + + +/* + * Initialize the XPC interface to indicate that XPC isn't loaded. + */ +static enum xpc_retval xpc_notloaded(void) { return xpcNotLoaded; } + +struct xpc_interface xpc_interface = { + (void (*)(int)) xpc_notloaded, + (void (*)(int)) xpc_notloaded, + (enum xpc_retval (*)(partid_t, int, u32, void **)) xpc_notloaded, + (enum xpc_retval (*)(partid_t, int, void *)) xpc_notloaded, + (enum xpc_retval (*)(partid_t, int, void *, xpc_notify_func, void *)) + xpc_notloaded, + (void (*)(partid_t, int, void *)) xpc_notloaded, + (enum xpc_retval (*)(partid_t, void *)) xpc_notloaded +}; + + +/* + * XPC calls this when it (the XPC module) has been loaded. + */ +void +xpc_set_interface(void (*connect)(int), + void (*disconnect)(int), + enum xpc_retval (*allocate)(partid_t, int, u32, void **), + enum xpc_retval (*send)(partid_t, int, void *), + enum xpc_retval (*send_notify)(partid_t, int, void *, + xpc_notify_func, void *), + void (*received)(partid_t, int, void *), + enum xpc_retval (*partid_to_nasids)(partid_t, void *)) +{ + xpc_interface.connect = connect; + xpc_interface.disconnect = disconnect; + xpc_interface.allocate = allocate; + xpc_interface.send = send; + xpc_interface.send_notify = send_notify; + xpc_interface.received = received; + xpc_interface.partid_to_nasids = partid_to_nasids; +} + + +/* + * XPC calls this when it (the XPC module) is being unloaded. + */ +void +xpc_clear_interface(void) +{ + xpc_interface.connect = (void (*)(int)) xpc_notloaded; + xpc_interface.disconnect = (void (*)(int)) xpc_notloaded; + xpc_interface.allocate = (enum xpc_retval (*)(partid_t, int, u32, + void **)) xpc_notloaded; + xpc_interface.send = (enum xpc_retval (*)(partid_t, int, void *)) + xpc_notloaded; + xpc_interface.send_notify = (enum xpc_retval (*)(partid_t, int, void *, + xpc_notify_func, void *)) xpc_notloaded; + xpc_interface.received = (void (*)(partid_t, int, void *)) + xpc_notloaded; + xpc_interface.partid_to_nasids = (enum xpc_retval (*)(partid_t, void *)) + xpc_notloaded; +} + + +/* + * Register for automatic establishment of a channel connection whenever + * a partition comes up. + * + * Arguments: + * + * ch_number - channel # to register for connection. + * func - function to call for asynchronous notification of channel + * state changes (i.e., connection, disconnection, error) and + * the arrival of incoming messages. + * key - pointer to optional user-defined value that gets passed back + * to the user on any callouts made to func. + * payload_size - size in bytes of the XPC message's payload area which + * contains a user-defined message. The user should make + * this large enough to hold their largest message. + * nentries - max #of XPC message entries a message queue can contain. + * The actual number, which is determined when a connection + * is established and may be less then requested, will be + * passed to the user via the xpcConnected callout. + * assigned_limit - max number of kthreads allowed to be processing + * messages (per connection) at any given instant. + * idle_limit - max number of kthreads allowed to be idle at any given + * instant. + */ +enum xpc_retval +xpc_connect(int ch_number, xpc_channel_func func, void *key, u16 payload_size, + u16 nentries, u32 assigned_limit, u32 idle_limit) +{ + struct xpc_registration *registration; + + + DBUG_ON(ch_number < 0 || ch_number >= XPC_NCHANNELS); + DBUG_ON(payload_size == 0 || nentries == 0); + DBUG_ON(func == NULL); + DBUG_ON(assigned_limit == 0 || idle_limit > assigned_limit); + + registration = &xpc_registrations[ch_number]; + + if (down_interruptible(®istration->sema) != 0) { + return xpcInterrupted; + } + + /* if XPC_CHANNEL_REGISTERED(ch_number) */ + if (registration->func != NULL) { + up(®istration->sema); + return xpcAlreadyRegistered; + } + + /* register the channel for connection */ + registration->msg_size = XPC_MSG_SIZE(payload_size); + registration->nentries = nentries; + registration->assigned_limit = assigned_limit; + registration->idle_limit = idle_limit; + registration->key = key; + registration->func = func; + + up(®istration->sema); + + xpc_interface.connect(ch_number); + + return xpcSuccess; +} + + +/* + * Remove the registration for automatic connection of the specified channel + * when a partition comes up. + * + * Before returning this xpc_disconnect() will wait for all connections on the + * specified channel have been closed/torndown. So the caller can be assured + * that they will not be receiving any more callouts from XPC to their + * function registered via xpc_connect(). + * + * Arguments: + * + * ch_number - channel # to unregister. + */ +void +xpc_disconnect(int ch_number) +{ + struct xpc_registration *registration; + + + DBUG_ON(ch_number < 0 || ch_number >= XPC_NCHANNELS); + + registration = &xpc_registrations[ch_number]; + + /* + * We've decided not to make this a down_interruptible(), since we + * figured XPC's users will just turn around and call xpc_disconnect() + * again anyways, so we might as well wait, if need be. + */ + down(®istration->sema); + + /* if !XPC_CHANNEL_REGISTERED(ch_number) */ + if (registration->func == NULL) { + up(®istration->sema); + return; + } + + /* remove the connection registration for the specified channel */ + registration->func = NULL; + registration->key = NULL; + registration->nentries = 0; + registration->msg_size = 0; + registration->assigned_limit = 0; + registration->idle_limit = 0; + + xpc_interface.disconnect(ch_number); + + up(®istration->sema); + + return; +} + + +int __init +xp_init(void) +{ + int ret, ch_number; + u64 func_addr = *(u64 *) xp_nofault_PIOR; + u64 err_func_addr = *(u64 *) xp_error_PIOR; + + + if (!ia64_platform_is("sn2")) { + return -ENODEV; + } + + /* + * Register a nofault code region which performs a cross-partition + * PIO read. If the PIO read times out, the MCA handler will consume + * the error and return to a kernel-provided instruction to indicate + * an error. This PIO read exists because it is guaranteed to timeout + * if the destination is down (AMO operations do not timeout on at + * least some CPUs on Shubs <= v1.2, which unfortunately we have to + * work around). + */ + if ((ret = sn_register_nofault_code(func_addr, err_func_addr, + err_func_addr, 1, 1)) != 0) { + printk(KERN_ERR "XP: can't register nofault code, error=%d\n", + ret); + } + /* + * Setup the nofault PIO read target. (There is no special reason why + * SH_IPI_ACCESS was selected.) + */ + if (is_shub2()) { + xp_nofault_PIOR_target = SH2_IPI_ACCESS0; + } else { + xp_nofault_PIOR_target = SH1_IPI_ACCESS; + } + + /* initialize the connection registration semaphores */ + for (ch_number = 0; ch_number < XPC_NCHANNELS; ch_number++) { + sema_init(&xpc_registrations[ch_number].sema, 1); /* mutex */ + } + + return 0; +} +module_init(xp_init); + + +void __exit +xp_exit(void) +{ + u64 func_addr = *(u64 *) xp_nofault_PIOR; + u64 err_func_addr = *(u64 *) xp_error_PIOR; + + + /* unregister the PIO read nofault code region */ + (void) sn_register_nofault_code(func_addr, err_func_addr, + err_func_addr, 1, 0); +} +module_exit(xp_exit); + + +MODULE_AUTHOR("Silicon Graphics, Inc."); +MODULE_DESCRIPTION("Cross Partition (XP) base"); +MODULE_LICENSE("GPL"); + +EXPORT_SYMBOL(xp_nofault_PIOR); +EXPORT_SYMBOL(xp_nofault_PIOR_target); +EXPORT_SYMBOL(xpc_registrations); +EXPORT_SYMBOL(xpc_interface); +EXPORT_SYMBOL(xpc_clear_interface); +EXPORT_SYMBOL(xpc_set_interface); +EXPORT_SYMBOL(xpc_connect); +EXPORT_SYMBOL(xpc_disconnect); + Index: linux-2.6/arch/ia64/sn/kernel/xp_nofault.S =================================================================== --- /dev/null 1970-01-01 00:00:00.000000000 +0000 +++ linux-2.6/arch/ia64/sn/kernel/xp_nofault.S 2005-03-22 08:56:39.222695744 -0600 @@ -0,0 +1,31 @@ +/* + * This file is subject to the terms and conditions of the GNU General Public + * License. See the file "COPYING" in the main directory of this archive + * for more details. + * + * Copyright (c) 2004-2005 Silicon Graphics, Inc. All Rights Reserved. + */ + + +/* + * The xp_nofault_PIOR function takes a pointer to a remote PIO register + * and attempts to load and consume a value from it. This function + * will be registered as a nofault code block. In the event that the + * PIO read fails, the MCA handler will force the error to look + * corrected and vector to the xp_error_PIOR which will return an error. + * + * extern int xp_nofault_PIOR(void *remote_register); + */ + + .global xp_nofault_PIOR +xp_nofault_PIOR: + mov r8=r0 // Stage a success return value + ld8.acq r9=[r32];; // PIO Read the specified register + adds r9=1,r9 // Add to force a consume + br.ret.sptk.many b0;; // Return success + + .global xp_error_PIOR +xp_error_PIOR: + mov r8=1 // Return value of 1 + br.ret.sptk.many b0;; // Return failure + Index: linux-2.6/include/asm-ia64/sn/xp.h =================================================================== --- /dev/null 1970-01-01 00:00:00.000000000 +0000 +++ linux-2.6/include/asm-ia64/sn/xp.h 2005-03-23 06:18:04.685793855 -0600 @@ -0,0 +1,436 @@ +/* + * This file is subject to the terms and conditions of the GNU General Public + * License. See the file "COPYING" in the main directory of this archive + * for more details. + * + * Copyright (C) 2004-2005 Silicon Graphics, Inc. All rights reserved. + */ + + +/* + * External Cross Partition (XP) structures and defines. + */ + + +#ifndef _ASM_IA64_SN_XP_H +#define _ASM_IA64_SN_XP_H + + +#include +#include +#include +#include +#include + + +#ifdef USE_DBUG_ON +#define DBUG_ON(condition) BUG_ON(condition) +#else +#define DBUG_ON(condition) +#endif + + +/* + * Define the maximum number of logically defined partitions the system + * can support. It is constrained by the maximum number of hardware + * partitionable regions. The term 'region' in this context refers to the + * minimum number of nodes that can comprise an access protection grouping. + * The access protection is in regards to memory, IPI and IOI. + * + * The maximum number of hardware partitionable regions is equal to the + * maximum number of nodes in the entire system divided by the minimum number + * of nodes that comprise an access protection grouping. + */ +#define XP_MAX_PARTITIONS 64 + + +/* + * Define the number of u64s required to represent all the C-brick nasids + * as a bitmap. The cross-partition kernel modules deal only with + * C-brick nasids, thus the need for bitmaps which don't account for + * odd-numbered (non C-brick) nasids. + */ +#define XP_MAX_PHYSNODE_ID (MAX_PHYSNODE_ID / 2) +#define XP_NASID_MASK_BYTES ((XP_MAX_PHYSNODE_ID + 7) / 8) +#define XP_NASID_MASK_WORDS ((XP_MAX_PHYSNODE_ID + 63) / 64) + + +/* + * Wrapper for bte_copy() that should it return a failure status will retry + * the bte_copy() once in the hope that the failure was due to a temporary + * aberration (i.e., the link going down temporarily). + * + * See bte_copy for definition of the input parameters. + * + * Note: xp_bte_copy() should never be called while holding a spinlock. + */ +static inline bte_result_t +xp_bte_copy(u64 src, u64 dest, u64 len, u64 mode, void *notification) +{ + bte_result_t ret; + + + ret = bte_copy(src, dest, len, mode, notification); + + if (ret != BTE_SUCCESS) { + if (!in_interrupt()) { + cond_resched(); + } + ret = bte_copy(src, dest, len, mode, notification); + } + + return ret; +} + + +/* + * XPC establishes channel connections between the local partition and any + * other partition that is currently up. Over these channels, kernel-level + * `users' can communicate with their counterparts on the other partitions. + * + * The maxinum number of channels is limited to eight. For performance reasons, + * the internal cross partition structures require sixteen bytes per channel, + * and eight allows all of this interface-shared info to fit in one cache line. + * + * XPC_NCHANNELS reflects the total number of channels currently defined. + * If the need for additional channels arises, one can simply increase + * XPC_NCHANNELS accordingly. If the day should come where that number + * exceeds the MAXIMUM number of channels allowed (eight), then one will need + * to make changes to the XPC code to allow for this. + */ +#define XPC_MEM_CHANNEL 0 /* memory channel number */ +#define XPC_NET_CHANNEL 1 /* network channel number */ + +#define XPC_NCHANNELS 2 /* #of defined channels */ +#define XPC_MAX_NCHANNELS 8 /* max #of channels allowed */ + +#if XPC_NCHANNELS > XPC_MAX_NCHANNELS +#error XPC_NCHANNELS exceeds MAXIMUM allowed. +#endif + + +/* + * The format of an XPC message is as follows: + * + * +-------+--------------------------------+ + * | flags |////////////////////////////////| + * +-------+--------------------------------+ + * | message # | + * +----------------------------------------+ + * | payload (user-defined message) | + * | | + * : + * | | + * +----------------------------------------+ + * + * The size of the payload is defined by the user via xpc_connect(). A user- + * defined message resides in the payload area. + * + * The user should have no dealings with the message header, but only the + * message's payload. When a message entry is allocated (via xpc_allocate()) + * a pointer to the payload area is returned and not the actual beginning of + * the XPC message. The user then constructs a message in the payload area + * and passes that pointer as an argument on xpc_send() or xpc_send_notify(). + * + * The size of a message entry (within a message queue) must be a cacheline + * sized multiple in order to facilitate the BTE transfer of messages from one + * message queue to another. A macro, XPC_MSG_SIZE(), is provided for the user + * that wants to fit as many msg entries as possible in a given memory size + * (e.g. a memory page). + */ +struct xpc_msg { + u8 flags; /* FOR XPC INTERNAL USE ONLY */ + u8 reserved[7]; /* FOR XPC INTERNAL USE ONLY */ + s64 number; /* FOR XPC INTERNAL USE ONLY */ + + u64 payload; /* user defined portion of message */ +}; + + +#define XPC_MSG_PAYLOAD_OFFSET (u64) (&((struct xpc_msg *)0)->payload) +#define XPC_MSG_SIZE(_payload_size) \ + L1_CACHE_ALIGN(XPC_MSG_PAYLOAD_OFFSET + (_payload_size)) + + +/* + * Define the return values and values passed to user's callout functions. + * (It is important to add new value codes at the end just preceding + * xpcUnknownReason, which must have the highest numerical value.) + */ +enum xpc_retval { + xpcSuccess = 0, + + xpcNotConnected, /* 1: channel is not connected */ + xpcConnected, /* 2: channel connected (opened) */ + xpcRETIRED1, /* 3: (formerly xpcDisconnected) */ + + xpcMsgReceived, /* 4: message received */ + xpcMsgDelivered, /* 5: message delivered and acknowledged */ + + xpcRETIRED2, /* 6: (formerly xpcTransferFailed) */ + + xpcNoWait, /* 7: operation would require wait */ + xpcRetry, /* 8: retry operation */ + xpcTimeout, /* 9: timeout in xpc_allocate_msg_wait() */ + xpcInterrupted, /* 10: interrupted wait */ + + xpcUnequalMsgSizes, /* 11: message size disparity between sides */ + xpcInvalidAddress, /* 12: invalid address */ + + xpcNoMemory, /* 13: no memory available for XPC structures */ + xpcLackOfResources, /* 14: insufficient resources for operation */ + xpcUnregistered, /* 15: channel is not registered */ + xpcAlreadyRegistered, /* 16: channel is already registered */ + + xpcPartitionDown, /* 17: remote partition is down */ + xpcNotLoaded, /* 18: XPC module is not loaded */ + xpcUnloading, /* 19: this side is unloading XPC module */ + + xpcBadMagic, /* 20: XPC MAGIC string not found */ + + xpcReactivating, /* 21: remote partition was reactivated */ + + xpcUnregistering, /* 22: this side is unregistering channel */ + xpcOtherUnregistering, /* 23: other side is unregistering channel */ + + xpcCloneKThread, /* 24: cloning kernel thread */ + xpcCloneKThreadFailed, /* 25: cloning kernel thread failed */ + + xpcNoHeartbeat, /* 26: remote partition has no heartbeat */ + + xpcPioReadError, /* 27: PIO read error */ + xpcPhysAddrRegFailed, /* 28: registration of phys addr range failed */ + + xpcBteDirectoryError, /* 29: maps to BTEFAIL_DIR */ + xpcBtePoisonError, /* 30: maps to BTEFAIL_POISON */ + xpcBteWriteError, /* 31: maps to BTEFAIL_WERR */ + xpcBteAccessError, /* 32: maps to BTEFAIL_ACCESS */ + xpcBtePWriteError, /* 33: maps to BTEFAIL_PWERR */ + xpcBtePReadError, /* 34: maps to BTEFAIL_PRERR */ + xpcBteTimeOutError, /* 35: maps to BTEFAIL_TOUT */ + xpcBteXtalkError, /* 36: maps to BTEFAIL_XTERR */ + xpcBteNotAvailable, /* 37: maps to BTEFAIL_NOTAVAIL */ + xpcBteUnmappedError, /* 38: unmapped BTEFAIL_ error */ + + xpcBadVersion, /* 39: bad version number */ + xpcVarsNotSet, /* 40: the XPC variables are not set up */ + xpcNoRsvdPageAddr, /* 41: unable to get rsvd page's phys addr */ + xpcInvalidPartid, /* 42: invalid partition ID */ + xpcLocalPartid, /* 43: local partition ID */ + + xpcUnknownReason /* 44: unknown reason -- must be last in list */ +}; + + +/* + * Define the callout function types used by XPC to update the user on + * connection activity and state changes (via the user function registered by + * xpc_connect()) and to notify them of messages received and delivered (via + * the user function registered by xpc_send_notify()). + * + * The two function types are xpc_channel_func and xpc_notify_func and + * both share the following arguments, with the exception of "data", which + * only xpc_channel_func has. + * + * Arguments: + * + * reason - reason code. (See following table.) + * partid - partition ID associated with condition. + * ch_number - channel # associated with condition. + * data - pointer to optional data. (See following table.) + * key - pointer to optional user-defined value provided as the "key" + * argument to xpc_connect() or xpc_send_notify(). + * + * In the following table the "Optional Data" column applies to callouts made + * to functions registered by xpc_connect(). A "NA" in that column indicates + * that this reason code can be passed to functions registered by + * xpc_send_notify() (i.e. they don't have data arguments). + * + * Also, the first three reason codes in the following table indicate + * success, whereas the others indicate failure. When a failure reason code + * is received, one can assume that the channel is not connected. + * + * + * Reason Code | Cause | Optional Data + * =====================+================================+===================== + * xpcConnected | connection has been established| max #of entries + * | to the specified partition on | allowed in message + * | the specified channel | queue + * ---------------------+--------------------------------+--------------------- + * xpcMsgReceived | an XPC message arrived from | address of payload + * | the specified partition on the | + * | specified channel | [the user must call + * | | xpc_received() when + * | | finished with the + * | | payload] + * ---------------------+--------------------------------+--------------------- + * xpcMsgDelivered | notification that the message | NA + * | was delivered to the intended | + * | recipient and that they have | + * | acknowledged its receipt by | + * | calling xpc_received() | + * =====================+================================+===================== + * xpcUnequalMsgSizes | can't connect to the specified | NULL + * | partition on the specified | + * | channel because of mismatched | + * | message sizes | + * ---------------------+--------------------------------+--------------------- + * xpcNoMemory | insufficient memory avaiable | NULL + * | to allocate message queue | + * ---------------------+--------------------------------+--------------------- + * xpcLackOfResources | lack of resources to create | NULL + * | the necessary kthreads to | + * | support the channel | + * ---------------------+--------------------------------+--------------------- + * xpcUnregistering | this side's user has | NULL or NA + * | unregistered by calling | + * | xpc_disconnect() | + * ---------------------+--------------------------------+--------------------- + * xpcOtherUnregistering| the other side's user has | NULL or NA + * | unregistered by calling | + * | xpc_disconnect() | + * ---------------------+--------------------------------+--------------------- + * xpcNoHeartbeat | the other side's XPC is no | NULL or NA + * | longer heartbeating | + * | | + * ---------------------+--------------------------------+--------------------- + * xpcUnloading | this side's XPC module is | NULL or NA + * | being unloaded | + * | | + * ---------------------+--------------------------------+--------------------- + * xpcOtherUnloading | the other side's XPC module is | NULL or NA + * | is being unloaded | + * | | + * ---------------------+--------------------------------+--------------------- + * xpcPioReadError | xp_nofault_PIOR() returned an | NULL or NA + * | error while sending an IPI | + * | | + * ---------------------+--------------------------------+--------------------- + * xpcInvalidAddress | the address either received or | NULL or NA + * | sent by the specified partition| + * | is invalid | + * ---------------------+--------------------------------+--------------------- + * xpcBteNotAvailable | attempt to pull data from the | NULL or NA + * xpcBtePoisonError | specified partition over the | + * xpcBteWriteError | specified channel via a | + * xpcBteAccessError | bte_copy() failed | + * xpcBteTimeOutError | | + * xpcBteXtalkError | | + * xpcBteDirectoryError | | + * xpcBteGenericError | | + * xpcBteUnmappedError | | + * ---------------------+--------------------------------+--------------------- + * xpcUnknownReason | the specified channel to the | NULL or NA + * | specified partition was | + * | unavailable for unknown reasons| + * =====================+================================+===================== + */ + +typedef void (*xpc_channel_func)(enum xpc_retval reason, partid_t partid, + int ch_number, void *data, void *key); + +typedef void (*xpc_notify_func)(enum xpc_retval reason, partid_t partid, + int ch_number, void *key); + + +/* + * The following is a registration entry. There is a global array of these, + * one per channel. It is used to record the connection registration made + * by the users of XPC. As long as a registration entry exists, for any + * partition that comes up, XPC will attempt to establish a connection on + * that channel. Notification that a connection has been made will occur via + * the xpc_channel_func function. + * + * The 'func' field points to the function to call when aynchronous + * notification is required for such events as: a connection established/lost, + * or an incomming message received, or an error condition encountered. A + * non-NULL 'func' field indicates that there is an active registration for + * the channel. + */ +struct xpc_registration { + struct semaphore sema; + xpc_channel_func func; /* function to call */ + void *key; /* pointer to user's key */ + u16 nentries; /* #of msg entries in local msg queue */ + u16 msg_size; /* message queue's message size */ + u32 assigned_limit; /* limit on #of assigned kthreads */ + u32 idle_limit; /* limit on #of idle kthreads */ +} ____cacheline_aligned; + + +#define XPC_CHANNEL_REGISTERED(_c) (xpc_registrations[_c].func != NULL) + + +/* the following are valid xpc_allocate() flags */ +#define XPC_WAIT 0 /* wait flag */ +#define XPC_NOWAIT 1 /* no wait flag */ + + +struct xpc_interface { + void (*connect)(int); + void (*disconnect)(int); + enum xpc_retval (*allocate)(partid_t, int, u32, void **); + enum xpc_retval (*send)(partid_t, int, void *); + enum xpc_retval (*send_notify)(partid_t, int, void *, + xpc_notify_func, void *); + void (*received)(partid_t, int, void *); + enum xpc_retval (*partid_to_nasids)(partid_t, void *); +}; + + +extern struct xpc_interface xpc_interface; + +extern void xpc_set_interface(void (*)(int), + void (*)(int), + enum xpc_retval (*)(partid_t, int, u32, void **), + enum xpc_retval (*)(partid_t, int, void *), + enum xpc_retval (*)(partid_t, int, void *, xpc_notify_func, + void *), + void (*)(partid_t, int, void *), + enum xpc_retval (*)(partid_t, void *)); +extern void xpc_clear_interface(void); + + +extern enum xpc_retval xpc_connect(int, xpc_channel_func, void *, u16, + u16, u32, u32); +extern void xpc_disconnect(int); + +static inline enum xpc_retval +xpc_allocate(partid_t partid, int ch_number, u32 flags, void **payload) +{ + return xpc_interface.allocate(partid, ch_number, flags, payload); +} + +static inline enum xpc_retval +xpc_send(partid_t partid, int ch_number, void *payload) +{ + return xpc_interface.send(partid, ch_number, payload); +} + +static inline enum xpc_retval +xpc_send_notify(partid_t partid, int ch_number, void *payload, + xpc_notify_func func, void *key) +{ + return xpc_interface.send_notify(partid, ch_number, payload, func, key); +} + +static inline void +xpc_received(partid_t partid, int ch_number, void *payload) +{ + return xpc_interface.received(partid, ch_number, payload); +} + +static inline enum xpc_retval +xpc_partid_to_nasids(partid_t partid, void *nasids) +{ + return xpc_interface.partid_to_nasids(partid, nasids); +} + + +extern u64 xp_nofault_PIOR_target; +extern int xp_nofault_PIOR(void *); +extern int xp_error_PIOR(void); + + +#endif /* _ASM_IA64_SN_XP_H */ + Index: linux-2.6/arch/ia64/sn/kernel/Makefile =================================================================== --- linux-2.6.orig/arch/ia64/sn/kernel/Makefile 2005-03-22 08:41:53.129230210 -0600 +++ linux-2.6/arch/ia64/sn/kernel/Makefile 2005-03-23 06:17:46.758257105 -0600 @@ -4,9 +4,11 @@ # License. See the file "COPYING" in the main directory of this archive # for more details. # -# Copyright (C) 1999,2001-2003 Silicon Graphics, Inc. All Rights Reserved. +# Copyright (C) 1999,2001-2005 Silicon Graphics, Inc. All Rights Reserved. # obj-y += setup.o bte.o bte_error.o irq.o mca.o idle.o \ huberror.o io_init.o iomv.o klconflib.o sn2/ obj-$(CONFIG_IA64_GENERIC) += machvec.o +obj-$(CONFIG_IA64_SGI_SN_XP) += xp.o +xp-y := xp_main.o xp_nofault.o From dcn@sgi.com Wed Mar 23 11:51:12 2005 Received: with ECARTIS (v1.0.0; list netdev); Wed, 23 Mar 2005 11:51:16 -0800 (PST) Received: from omx2.sgi.com (omx2-ext.sgi.com [192.48.171.19]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j2NJp1vi029523 for ; Wed, 23 Mar 2005 11:51:01 -0800 Received: from flecktone.americas.sgi.com (flecktone.americas.sgi.com [198.149.16.15]) by omx2.sgi.com (8.12.11/8.12.9/linux-outbound_gateway-1.1) with ESMTP id j2NLR2rB028210 for ; Wed, 23 Mar 2005 13:27:12 -0800 Received: from sgi.com (aqua.americas.sgi.com [128.162.233.32]) by flecktone.americas.sgi.com (8.12.9/8.12.10/SGI_generic_relay-1.2) with ESMTP id j2NJoUR04576333; Wed, 23 Mar 2005 13:50:30 -0600 (CST) Received: by sgi.com (Postfix, from userid 144) id ADCD62040B; Wed, 23 Mar 2005 13:50:29 -0600 (CST) Date: Wed, 23 Mar 2005 13:50:29 -0600 From: Dean Nelson To: tony.luck@intel.com Cc: netdev@oss.sgi.com, linux-ia64@vger.kernel.org Subject: [PATCH 2/3] SGI Altix cross partition functionality (2nd revision) Message-ID: <20050323195029.GB21418@sgi.com> References: <4241C391.mailxHNA15A8V0@aqua.americas.sgi.com> Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="EVF5PPMfhYS0aIcm" Content-Disposition: inline In-Reply-To: <4241C391.mailxHNA15A8V0@aqua.americas.sgi.com> User-Agent: Mutt/1.5.6i X-Virus-Scanned: ClamAV 0.83/781/Wed Mar 23 03:58:42 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 597 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: dcn@sgi.com Precedence: bulk X-list: netdev Content-Length: 49959 Lines: 698 --EVF5PPMfhYS0aIcm Content-Type: text/plain; charset=us-ascii Content-Disposition: inline This patch contains the communication module (XPC) for cross partition communication on a partitioned SGI Altix. Signed-off-by: Dean Nelson --EVF5PPMfhYS0aIcm Content-Type: application/x-gunzip Content-Disposition: attachment; filename="xpc.gz" Content-Transfer-Encoding: base64 H4sICCC1QUIAA3hwYwCsW3tz27aW/1v5FJhm5lpK/JAVx03jNlNFlh1tbUmV7ORmezscmoQt XlOkSlB2tG33s+95AARIUbaTu+rDEoHzwwFw3gAHSSi/vBVxlCy/7HR2D/f8LJjtRf7hwZ5K 9m5llsh478si2J09++k//zzb2dkRe6G820uWcdzY/+H79k57H/4V7fZb+ne3bT7iJf7/2cuX L5/CXaPTbr/eab/a6bwS7cO3nddvD97svn7z+ofD/TedN2KnfQhYP/8MX7YBeX/7hx/2xc8/ P3u59+LZS/FCXMwiJa6jWAr4q5ZX/5ZBLvJU5DMpcpnNlfCTUARpEkZ5lCZKpNfUdjq8FKcy kZkfi/HyKo4CgjuLApkouSvEVErqSNjf9Ubjz4Ph6XciSujp3IcvYZTBaGm2YlBgAGcZ3UmC uk4zMU8zKUKZ+1GsdvEptfTSxSqLbma5aAYtAfM/2MFFENMI2EgTcZr5i1kUqG0xSAJgpRvH YoL9lZhIJbM7GRLY3rOX+I9eiV6WKiXGfpbTTGGU+XyZRIFPv5r/HPdaQuXZMsiXmeRlmfsB EFms59E1SNW18AbdwwNvOvR+6U+G/TMPaL0P0AxtUSI3NTNCEsTLUIofaev3YDrX0c3u7N16 U5TA/mTLRV7bqlYqyOPaJpBC2KVKk6/me4ub3L+Ka1uyNJBKpVlNG8jjVV5HBA1BfKuWi0Wa VZnU7X4YZqq+aa4WMqhvUrPllTefb2Dmy4KeOzsL6ys+ykzhPibL+RV8RYlWkcpR8nzYx3+D sNGORgl84067RBj4ifDje3+lCCv341vUjzvGU+I+ymdC+XOpUZ5vE1AioceG3j4hhdH1tcxk khtCI0eFmKBcfOxPpoPRsOlBp23hAX+tRrNJP1vixx/FQUv8JfA3NIh/iPaX61bLQjgI3nn3 v0aTpnfXagAA/BHv3gH1hr6DYbkvI5dW9QLUOJFfcq0FQsPcp1koYDpXUS4yuQBVgSn6bDtQ pW9AvxNWuJ2rLApuReKrKETDIGFxcNEAeNo9EyB0d1EoQ4Lys8xfWcAouSEMolXGqiyM8u4B TzPkJmW47vnIMxhLBZDACdGTEu0UdPAb/rLGB67+O9bnBDCnw47QQ4CV6e28x4mg+ZIsKwJ2 38gajDbsTgfHCi0RC5FaBrNtoVIQGrXwA1i0CEzUFfzy73C+K+ADpRNmCez7ebFEwPac+CGY ha9oLlk6pwVjMUUcAL3lWTrMgVTCWhAlbpgqTVvbEoXLQ0tGIo04yIQKZnIuqwKKEkNT8z55 g+Fx/59NT0snyOKeODzA/3dadQTv6wg6KGfNwwOxI/arUsxkg6HXnUy6n4EAlGHRQslftH6r ZeR3APvXs5cN+Aj4NPcvz1BhanmoH+1kMjoHxPdN7x5Gu8LR4GsL1g94fCma8Ah/dEgvXPIP 773j/kn38uwChrjoTz52zxqN1409lLcgEx/eo3yA2/silAzU2poCee9Dv/dLAXIxOO+PLi/A 1SMG7AVoTR0I6qbRQ9IHNtsgPrCXYOmAhohlZqRB9MaXAtQLfO8iShKQGbBWG/m5+DDpd49h dc77je8g+vBmV99t6Aq4jUb7cZbwWRipIKW55LNM+uEaA8eDaW8EtunzOgcF7XfagZaZ6Z6d jT71j0FKYAfvWmzNdt7NJIj+lfRRw7w8BWuqblH2tIygUFVFgpAA0kJtRvrrpzLU2my+Buwf APa/Vc4cO2xCGghdbqRjNFdoE6zZciwqBHEJ6jZ2B1GwZgD2IzNocwnB1wps1qcZmDKg1vYS 7WMc/Q/byAgd6XwRy1xuYx9PRTeJjwES/9R+b5vHCLe12cpyjw33tgmjZvoBmVAlc8v3MM3l W3EJJj8Wd36mvIVPoarMt8s2n711CpHAzAf5SnMwhDKxHNugj6M4geKTqbvQo5X4E0zFEvS6 NIsj1DdcOXAEfyyBM9NAOEV/Pc2iN4Yu0XUEq6hbdPc3eh2OGtjTcj44tkbc9DSYhi787fB3 Q0daioPDvG4Sy4tenyP901loMJHaqJ13p794n0aT4+nvwoNPAIsvITCUHoHJ0FA7u/J11H8f leV9MjZxRTmk2d9ug9V/UazR/m7bWIRCCmlrdHDtQk4/Hnvj7mkf1HJwOuwfe9PBf/e1uW+e 7Xu9Lpghbmwq2Pv0ulm361VdOraGygn1QZXuIZ+YkYTBGkcYJSuKDMHXyi8Y37LlTDGAKYSc M6Zd0YRQCSMD+C+/T98KhxPcMdKByjMP6VtFYuGEXNdpHKf35JQNh2BfVZBFV8BTWSNuMEGL Asszx0xSagNB7DqsYhwF4RvGYCkaC7AO8crRIKuV1SnclcJrkEuVCn+xiCPkKa2d3S4HgTM/ ueFOOvyz04J12YMIJpOxj+t7vUwCZBNYyVdCzdJlDLPggCaT1zHkkiZ4CjIIVyhKdINKjrMx raQov8wzrw3IX4XXGqNBM/5zXU1BaQoLvvbAMemm7Ta88hTExkvFit0WP5moUmTLJEH2Sbch PBN+oHX5yHmwmK2UFyyWUaG1xfI6dsCfp4rEHZ9pCxJmOFdSL/gL8bFiE3Q+Hfd7IswiTF9o cI6dXxQghHD3LQjAMKIwCynFnKbUcB1liqYU3bFnARoirhqTj/W25FXFlryytoRiXVqXGkPy sTuZlm2IeNx8IJa2HF+nmCVnq52Eo51WvbqJTlZ4Dso1R9vsvV2s7SKB4KmFu5Bp6DTTDngl wVdj5QJXmabPZEG6WBF/PCToDURiQZrBWAus+2ASkrL3z5WMr3mbKS8pwHfFgIJImHCU4WS4 nQwprJ8p8Di2A5cHsyQwMGGEUQkmIWA0ROFStilP0gkQzllvKDIYaVtGiR8VjpB12mqcoQUR V+kyCX2MZGBJONJNUojnJfTgubLiB8FygdZq5sfXLsAG/ScdK4KGuX8TBUcoEPQTDGcSxKkC r5jdqELrQFkhnYwF6g7GwDAf7MkVNuwusLt156djpt1EfCrzvfEyBwGKl9JIN1EOxgNUtQep oY/Oi+2GFNYGAdjaED3nn0B0T54MLboEpqGXKtM4Bqk0LqYZEOVsRmBrmgTgDhIZa4P4HPpr iRamReiCkgwdOhMv/NZ59fuREyP54DRAwmFFrla5XqK/jyqKa7fzvHs66BUlokUMIuWTjJsC A5upIE1yUCL0kHkapLHVWwLYh94h1g1I7bUWPKb7lKv7MJE5xLsVxZ35oK7VYBYdHYm+1cEy G511NtzeFCUvYHVkqEMuHNm0UzjAbJQYt/yy/sssx0ouWfESL4LURlSs7djjFWq0v7Tbr1+9 7hzsvz48ePW6/frNmUD7vQXd0Cb/q711Jprg6PMYFT6M/KS1lhYauA7Bff/q+87h/vdrcLi9 G+FK0d+JDjAULMZNpHKq3cAyg9J4eTSXWbOF0QPIc8wNXIf3OGvFRrRmBOWjL9B7qsCCwrCH BztcyLpZYmyyW3Eauoqmg0oqUmmri0UYshHLhL5CDCmarzqIti32DwkVBnqDX1oFvmJ7igEP mAg02Vy/pACR6kYFJzVlnXEXcvju5HTaRBO2D0kq/Om0TIQNnyWWd6hRVwf1B+uRNb061V6Q zL7qtNZKJ5dDM/Q+Da2oPlTAqArMJuKOQ1yifvcOh62C1CUBftm+wqpFmWjquAWQaIu4ngvJ slIYCEGOuKzzGDcLchUKDNGNzMlCAbgGJgOKTYslN9kxrb1yp3k6dtKdR6OVm0WLa+DesPeh Oxz2z6YbZ2w9Aak3GbooUY5QgeikQUTxOM0dHRiKL8gnVxbBj9FvY7BrVqPsHtmJ7h+C0vkK k2hcAv4OzmJlcKjWoMHZQwLJXN14OGMm4rmzZzc7wtFMQcBWzkt0DHFkvIzbHaMAsGnaIMIQ vK0WJE7BBDwJg3quQcBWMwQ00POHIgQN4QrYBrEYjfvD3tlo2ifFtSIi6POonJR35SGZcVMk nNt17N9UgusG0p57x6Nhv4HWeR+nh33R65Ary2QgIQwN8YhLgXCVqn6aHGt9n4m+Y+gjNM5+ uEKXgwVzPD9ZJ6Sq6+RyfEHEByQcGG4UdW4MQxICLA1fXdLz6anXPT6e9KdgCBf+Kk79UBvB ZrOyCi9aYGne4B/bc6dAGXc/n426x97o5GTav2jVayCVraJrHYNbf06HtJEyXsH0KuzOlqLp UZrL8QaYKiMy974qFpt9Ex/o8qyvOPTHhUmwKgA9I4iDrVdwZqmHJUvGT5Wc+4tZSjW7uY41 dS/bZCpa+WqBiop98CsKN/U1R6w6nNtjJ2U9I/q760jGujpITpZWIrpmoJ9+YlEFAT/TBTTL rodlA6odMHtAmW0VC21qCkx1l0KU++JWrjSbTpKqyaCtFESK9eV5YG6ukDK3VjmqDLmFXBx8 PVypK1axAMz9xMeiCkQhunl5jaXdP5aRCWkK8ywGiQ03g2XsZ1RXXdFaG4FjQC6isFgpVj2f s2vKsx17L6zYWtYwPswwv5ccmjvpK4okNA9HF0LNfOTRAlezWJPPOdohGd1/IGumWIw8QznQ LVLXImwLyLnpsB3DPpfVShLNQZxOPo2zhFTV1JI2c7EAHhKM5Qv/BvSJ5L2ncLqUXheT7SNx HbLZc9SWkrdQohlEGe2suFrimbNq7ZqFW+kzy/pp17AW4UghTHxECbmJKZVcG7Ts4lpilqIG Izq1xJiuSxrUiJQG83NiKpR4AKpPMdczFNw4XHyuYRYrorEIynCinb5lBWXFcoGZfshVkKL8 XB5pSxcH75OK4y4JoWOyaAAu/izMyQrdmtERpYkiaxRMMe/r27grenhnIdTFzDIj2h3iSInD eGHv7ayqJFGuykuA9YhKYXhXdPnKQnlG97hV0gqkiGXOSZOP8ZvVCPRefEsjLFaMAOs+lYnR p8L6g/Tw+WvPfP5ae2Do7j0NejrehZhc7Oy8Ey93zOflRrra8fB/J8W3errycPXjuQ9+3NnR a3E63nkHNI9y4H5zHnw9Xf8b6b5hvOqM7z0z592nTPm9y8JXbFaJdSQ5/ka6bxhvfcpWNCAF /HoeehUerNQA3NME7T/k4Imr0P1GusfGc4Rm44yfOt4jpsP8x3dKnHX7DcT1Lxj9d3Je1qJi JlhyKwW1cB2Ms2kF0rY23UulQ3pd6A38xAGB5Avs+CxiKw+9AoiQwAwjOAYjG3xnq2yIu5Cr nJvQjnywrToW4cE2BBC6Ac/XV1KfsVMoyCc5xNjaaHac9w+MgzCbhvCD2yS9j2V4UyQtdhur 4wkf6/h36IlLuabDRw/46IKX0scLUoZKO8RFJhcUgpq4A90iQuHZIF3X0+wDq3R20KBOsfQz 3csJk3VujLcMkxVC30XpUsWrgqUCzeHt2PBGFTw+ei6NzEfJxC1JWGiOZEoyti5dhVPVIUEC Hj3GczoOQlh8TCqod1KngxB+/CYu0lJhc76M82jHzBSXadvGDhzhEEgTrwni4HgAiiXnli0D +GHIg99KuRB5hgVOvYR8udDGcw19uIybxYdSzgI0uZTdomge4lY6BrrG5K1iXmmdG13YjWI1 4xVLSn6PHJU9kL7MWeaf5JNwaA6aBeyJG+PWJ4r13RW/2w3uP6AEDlhBvEEpiIMaxbBJ/BMU 4eQhxXewmQc8NDTXa5ANTnJlcbOwUalD1FYh6IyeC9R1RYeGKXfwLYKEoskn6Kk2U6yELDDy vqSt4kmaSljOzAmqpKblsojJkrAuwvd7vLx00YcPvtaMlM6qdOmpoRZRAhO4BWL8w6T4jSa4 XIS+vg9aSqq5uPKqw+zrusWNvpjvFuYaEtSHb7/IHBzJE8qtdLeOeNxyLiJwXw/PRjWP8O25 09lcojVmyRzT7R/qozXNpRnpudvDqeiulXTVTbWcW63EFqVY3fXBMmxdOXgDQLUWrBnmelGl lnsFtoequfjFreTezklCt0J96Zd3vVJELIMdaRmorQDr4Su50X84fgXtCPepnCCvJ8eM1Gg0 HuQWy95VXt3zaWGulHzjANDDz9N5FHgoo3S1PnC3FGy4zBISfNOIlkQXCaoIiQcyjsJogh/v /o8jQYeKz1OuHBt7g4rjR7k7V/zt8RRn4A0Abw1K17M3g3AplH9riWTjqkBPISzwOea6ktYI F0XtwtKuTwtcGJcay8JuoG11uSoe5rEuqxbioZ8zo/TSTqlCqDlwDOWGiqwxB99akq2rSjs+ 26MKNS47xxWKAgjy5oDj3Gl1522RcnAaYXqfaBiWBNoxcj+61dyGdcrZm8+9tK6XnxKH1KxP aQ1HWvrNeRueQ+vTMNhBs3ZWbvCgHiJNdAF3aeacJGFgoTWs/v5I+djyhQmGHFNUQ1ehKiKu I/Yum4arkNnQi+ju04zePnjqqE6kV6J/aHwwStXojqXSHsJiLb8qMnahb/Wdda7g4SGpvbDI hxb6CueeePfuHbSBA09uTVSmqZUHm033Z8GvziOOOou2KIwlPz/CGxczf6EKPI7HKWTRCIIR 8BJBQsVyHU2CWPJRD6DZPuEq8ef48p7GC+UCLQHMAtMoLHLjZcv0zlQdfZXzKRqGEBgsRXPp Gpi1CRXHo6bFMgqL6QouhTEbFuRIcKSBXANj9XgEss4JTtgau4KM1gE1GPcBlRjFpYYRZ/U3 80BgG8bno4KadaDnkAsaOSV6vQ+2lkxShOFYLueLNPPxwlqZQ11H5znmaQ47UxrI1Nm10K47 J5oiOCV6QwVnYoR6zSX9vfHW9/p5WGHQNxwP97xP3WlvNBz2exf9Y7rDQ5994QSH91xHdgLl KsgEz70n/fHZZwvREdbs0BU7Awc5Q7xaOzDms3PGsCAHorB4T8LQjPx62Z9eWJQ3m1mBhVXr p9eGmTLOfnsjNxamCjTtX1yO7Yw6bWdlwXOaMEzZQ6Ct9WN4+If3CM8r8S0kA3fgwjmbhMcq eOcIz4k2o8GOF0hvnMm51z1K+16LMhieGpT9domfCAsMqD+PSA/dmCiJT4eB9J7xxczH9n4d 5aDtTupJIIaX0s6/eZCbTSJUg7TffoijzUJEL1+VlbTTXltrm/7VbpcFsTt2sI7CO7aGVTr2 PtcHncWFUHRU7gmtryK1a0+F7c3h0oEpYdnj2IK86WLR/Wh+lXeZR3jvsua4Xb+AoN9MVfqW dKumUmCB/zThAxZUPrzHVzszv5zVl1OmbFGfLLlZEr7WIhbmepSlNa8FPUxd3JCvIeXXCR4n p7uy9pITzMizb0TQ8DBXP+cwonjVzx1w/V2FTQNiT/t+kC5NMEbxqgQNqe+7I+0Wed29UOL1 Xb7UXEdcucW8CYBYo242bEDyweRXLwvuTPVn8qvCO6CBdN9vqJZ8kM6WffBmMVZSiqoPFpCh B74tYi/UFE90bkTVFi1Qd5G8p1yJez+h+OO8DYz3+A2vyRNKP9KZWE3xx9ByJ7l+sTxyR4eo 0PYt1N/oSkVRTC6vryC6iViSZ2kRqMNqKZkvF6X1qmBRB+Es8XqgVGSBOlhy4yRdki44IPRK TFhXlyiXI2oNAU0fb/K9EMPRsC9GJ+LiQ1+MJ/1e/xgMqjgZ9M+Op/x8MBXTi8ll7+Jy0hef Bmdn4n1f9M763Un/WHz60B8yEC4mxAdTcTkmMLDN/em0O/ksBsOTSddCXIzE9HI8Hk0uRG8y mk7FuDu5GFwMRhqoNzo/vxwOel18tCvwCpbm72SEr7k6/FW4wTfjPvQZZau4+r/FvcX55fQC OxPSYAI/DCyDAV8OVItgzGpVXiUwdZtH3yZwCiWmhwnfDUJBWVxUwVq46yTXUtMiySlYohxf 31Qyrc5dnpryIr4LwpU9msvX1vbcTJ5rDJuT6lJZsRhXlzy+ZWALReXEzXXEMk+m7EHjugw6 7sK8IkN9Cleheds4Qgm5tgrCBkcn8OaSDlZkuDZDhbaaUoxfrcS4W1h5K0iv6jes6dPqSMUm bynnvaLS5tZy9P/AUC08IZc3363siqLwVd3jmrepyttdAiwgzCbie05Y3YT92daFUeMtYK/C mCtENRUbNypw3ofSivCkV6IcaiemsNw/+lqUeXfSAcL3uu58XYtel/ZNr3VZLBaXMlQFa+O7 YfbuuqYv1gNJ4LfO9vFs8P/ae/e2No5sX/hv+BRtz2tbMgKDnWQSEzyDjWzzBgPDJZ7snDw6 DWqgx0KtUUvG7J2cz/7WulWtqq5uSdjJzD7vnr0fx1bX/bJqXX+LlNO4xkJeze0YY5yYeSCz 8c/f/uJVxx8fMTaEPmMYfGPYDsM09sfFaJT1sXv8GY8V/4qt4K9Wmek4LKhBHJbqkkY3Jjub PjVyj0mtN645Ifa5ENX29eW4x8KUCwyQH9DtVRgbqJGY4nWshm6R7QV2TJewSp+lm1GuEpat ZALYAqGIuEiJkdKy3GFvd3/biHE/kmP/uo9kkJNpmDlmJQdSVFEPayKn0DPSqXV+Fg0Vs1N6 nerbIEHyqeXQif/kJsyUxoEoqqvT4J9BXW85etNRq01KJ4ryqtbf6foD+MpfgRpmOBZdYFvq 9ixPRYggxGhLuBXinDj22fbV6vX2dve7vV4HcUHgT67Ybt5zxQr7z54/09N9wyC6XQ5YU1gk Eo2Jca6ulFM/bUTqE4hHtOL7E8PU7Ry833exH7Uctk+g/HZODo72bTPP4mOYFOMhtiY79KSC cKCAOoTq4L0uM8DFw2uNl/EsuwBTEULssFKZ3GYddSLFhHldId54jHwELmE6tAT0ZpybbekX WTl8NLHwKskUEFDInxfdWkAPAVW0Y0U0kq+3c3RweNjdQZL5fnv3ZKm1vvb0a9PQ2/9oVw8l nkQAzIHYOXFnYKClZDV56C1I+fP6LzqWxUx5imE2Zt16gPG3do4DIturXlOKsBzTNQl/KH/+ xVEt0obbZs+lXYwDqTZO6HbJYxnnZlMBoKiuQD7+pxGPp+NhT1s8UZznd6KVg4ca8VAdaXA0 gcGbK9R2TWERvLfqvcKD0YoerGhde+NFk9+KCRUdsMfEqhNRvWNlp4PrwdlucbHqNtv9AIbK HKNVQKX0dr06H0fB6hcj1pNzKPQ6AE4LPmefkEZsVj5cnfXEZhX9iBsTKRJifjyWv0WLOCyh x94/a9ujoPPH3j+jhd3SBLfv7xAB/Xf3ehwnK8nGL64N5LfodiH/COx3j4JAfv5loUn04Clr wVZGTyoYq/CMF6OSSyXVYoa9nIxz0JB5JStbkoMBEq6eaNPIOyEsHiq16DCOP6jnnBiRBe5c UD8fLtyCRSSrXS06brwlV2e15aJvPkTuoQm2Ez8hjzssUIU6vxkLJ6xKT2h+weBP9hEQwld3 OyUALH75bftMVlo1hMeWcxQoKNo4evGxUaPGtZo+eyrjfzxvW3DqwnbcEszbAj8j8YbsZgUB i5GOqiskz/6dxkg8oM8PzT7lsZbQuya0FyxwYRgS0LoHidfBAk1Yc1GPjY/Rxy5+x9DHFvw/ 5q/j3kYuV3Mr3TPL2xwsnzmWQ3HaKEDR3tzbHabnKBnwuDUr2gm3NdaSVX3PfWTo/0DKyM/N 0iAaDzS3vAKFb9IPmTmASsytaYqR0MC7Nr9IWixy50McrGHWWg+hxOqLmAjehtjgjTa65i5B jyDfRcrf/BMGvPSbEaIDayNx6+j/AyF5NI3SC45Fz/Upo19N2LkYRYrUGduxMes/ChpEwMVO E+s9dAvKEm3OMAz+tbMhxhfROlKaitEzcX7FS+eWrfXw/Gr1hbM6wMx/a9op24l5gmd1Uz57 CpMok62Ee+xnbqOqHZsqOy9P3/SM4IvVvk/WcSdgp6mdLfML7V/NqQklEuiECOIvlU2tgIqi yr7HGAetHsDysgxt/mLkgYsBQCH8L+k+cvOdDF5TO3Kc7nKSwmBUkp1DmXzmqcons84UWnsr Wx2/kM3bTfcs3PC5tjx5+DCh6lpXwYH+SkEQv9rKTOcdAX/KhlqrGc81X2BQcUAyE32tYtNd om3aSloNs0E9iV2De1hGnXm1ITgUntESLbMdT4RyhfBCpO+w+EISOGFamKiACLYHC6KLMvqK 9jOHMPzJlfKF8MhBgGfpRyM7M1dMW2GWAlA/jn1FmPkLdE8X8b8Yf6M3asNq41i3pORm9SON fIuaoO/NS2WWAx2uCZAJoQnCu+pWjvDx3FqJeYGU6KV5ryCIBYJJMCoNnAHa4pzCgKDaRxfq EEpuMWQwh7wKuuNpb8lDs3X8ZhcREUWl2LaDmtgo+br27MZVWts/ONl9/ZP1ZQmv0PSbr+gK gUDH7GjLAUbyreGD+rp78urtwWGPcFAOWycHPVOU4ZkemuKrLwRerN2xpdHA23bn2x9AwLi4 wSDv7kbSQbhcsE0gj0zWG/qrM8zQvz9iTgp14U3T5visI5qmx64ZCt+jsBumBmQZgZ8ByL1l v/NLJ1M6Pjk46s6/AgdHHRw50ZMhCRViUmrxTPQsaAYdoqvKd+B9llxPAWaTcOIF6X1YXKTT wcQ53o+zS0M/B2wLurnK8PDcZNQKYbCYR+b4anqWbKxtJOVtOcmuE4wJ5B+fJuUAtGzrn84T lzwi2b2wzfTz/vCRYZdvskeSLQFuiYscCzAI0CsFb5G5kDeA/Urt4Jsp9xCvHBRAOFJwp5iQ 4hRbtK5IaCMqARhtTdwGlmiXP416vBy9w92DI9waw80mb/YOXm7v9d69O0I8oBahIb/pnrTC bSNOP2inN0nHl9mkzRvizgloRIpx9ajwlWm1cFjIA/0Fzvnx9Bzh05/DPw7z4sg8893x2JxX d0OYqNFaBDc9pBJAkNzlFhw8CClGl/IRgACPoT4CssosicKDoZL11ozi6nCvh0U/m8VoWOWG aHhaHlgt3UZghXrqtopagtaZf3GHX13bG/Mq97NPyVYkT4FrtS1wumeR4i/jxRUiLrzs/M92 0jPib8uOP1lhoa9V1dJJYBvVbbctZ0S6oMSjYnDCyp95Or90LLQ8j9hQCn9RlrwV6VT2fCbD Lz3bHQrBb5PHCIFLax3fSiiw+kJ783WSczgVSrXUWpfrwqXFb6+TuB/U3i487v5sji4+emHl Ki6JDZPw67ipVH6/y4ycR9xdpyR7F26KDM/3zrNkzFZyE/J/jMxmPhJErEWUAB1XSUsleraO lxFgAEeLAiBCL88HjgEX6bi7v8MCYD7KexckwfUulPSn7EG4pF7pPwXVmrY1bCguUhue5dsE G0W2BXX5j+XfPdCkDy9pnwItkntMWEqrPTGGfDWIz5tRx9GJ0CoQVgb5h2xwy/fFuRLc24oY y9ss08hLq0icd0ecZ4qozYhBkqljHgwYJuMBPE6+FTqyVGlIn+bqV0UmuUjA+MISLPWzj73+ 2WVL9qeT3H9QWtALWqytB/2OnDT8u5ml+e//Gt7nlyrYt8StM/2dJoP1qFdY3umQFxjW7N6W 4gBkMbGY3XAos3+6tycf0f+lNyUXGDRvEruBmhj4saNPC3aLouXSUq1/AoxZjXKe/qV3ZIpn dv2bp7OxTv8fAKrKHPDiQwJrEiUKHQbLWIQsdGgjpyUTnDVOiZd+YH8igVZnRyZs5ey2xrjb noPKGAHo1faeph71NIYCIqOUZhEKw83MQ2do36LE5vPJyTxiEF3S0EmtwmJr6ag1m0Agi9V0 k8kzFDVv0RstN3nOi1x9DE98fUFEV8AYaWWolEmHHvdNQn1h4b210kZ7hZQWZZqhpy37jvE6 iC6JbaEeERNwQE5FRErvUB4Q8eKnbIumyCC7MG2+NEWS/8zGhQCAl4JVLcdqvYPtkBbDhXlu EKRRWSQAQYRYhliMMgdgqoQ+o+oEIKAwKSQVKtui8kqDgxLGPG3UFuEwrafVAkHo3Vd1JbiF b6vf3x2/cQ1srFtTKea9C7eSMGNkef7UAXRohEZR5MvOvEJXjPiJXb7e20agblBz9M7Bb2f6 LSUrAx0MQF6bv5636R4w9LWHvI2D397/SUEI23ZBJccNSYPQwvqF/39htizTGMDexpqh/+nG Ntb9/2s3m44sV4xewWzrqSduczNHoRsz/rmV8INVdbEWHbD5u9JEkpEDlZH4OcZnwrhix7aT eE/ifLIBr8JocHvXNZhziObQ32mAsGz/Jrsk8DJcwaLN2AI+oozXrkWJmWtbFSX5jEX7jE39 cgfbw8ixJ9xHzllwAb3CCg4G9PTmPy1XyaK2LrLsdz2pprPmgzrnhXGPQIf44blHYCd913Ew dxkfTZUreYdp/hL2+X5Ues8To3AJODADaOkET+zOyhjNAk0nFThrinnCIbj4cpwOpwPGTPZ/ A110mXz1gdqwobmMPKQi5FJSDKQDxPIxnMPJ3kvrxA/YNahIZuxszoCEreBre52ORoL2wJmE cgwivGQ44bwkdh+A+oApBGlhOkgnkpMarKoCuRIiPBbTcUJmImSZKJQ5L8spAvOAWELZltIp r1eamJf99fHL5JDzyCQZaHLZQkcYXmrZj9+evlzD7LNmo0BvjmhoCVhgTGNVJWM72EoFzeNj k7fI7w2cONsWMDhFaL6c8q0lG99EGgusUKqxqzPTVFz9y8pSd+rRrzCATePTzWXR/gme0Vta 9eTUrIK1xlQrNEdJdRQAWK8uv2mz6RyGJXN+emeG6uE+la0z9MEqQck/ob2DgTN/AxTYSJ5m 21v0CUXic4isemkE6uPTVxBv+VxG5CT7TVXs9fbuXm9n90gXeznJdiRxOqr+KxUOD3aPD/aD OodFbliSeIX33aOwi/fghR4vvV0ZuSm/jWOvGU+k/cOGDg6PIuWtpaNS/OTg9CQofZJfZwfT Sbz830+qzf8dMnVT8SQsbwjs9o/mL0GV/WKy/THNB3AhSLZEe8/zJb/Y6RCoTubG/lvtmSO/ PTpqHHJXDefBzB0QmGX+wyYSeOOscyPE7vH9gfCPLIM0CdwaUSCQREDfAU1jv9wyp3wFesNz IcsYNmkuHzfSop6d3gY0QFzG0/7wMsAv4rIARUlWtxWCvCTqa9tvB3+Thj5cjLOMerVGTkPV RhkaFBmhEyhpH22AhjaX2eCjBJDGZmToiB3Ky59Ousd3nKJY7tgJs2l++jGmjAmvMLUzRgHi vk1caoPbqpV+UjyxuK9Wr+WnS5hlgyNXZEPN5/W+FDuDo3Iq39wcJnIuqRTAmk5X9T52+W1F 5xBGS70pDh0xZSM1KqF/AU+4FOkScjer2dTpTxvbjSuaLCYfCvSBnom73Fr/9GDwSVRNKhwH l90W405qHOLESYjP1p9A53QB8YO93e1vvuod7/d+6B7td/dQz/2WlCm7YEl8DvzL9NPq07Vv nqTj86snefrNV0/K4RPKc/bE8QnLW5//v+XV1dXkiVmoJ4YDHCxtfPfn9dX1DfP/yfr6c/z/ tXX5X7ICfy6vrKzMPcSlp+vrX6+uP1t9+ixZ/+b506+eP9tY++rb7za+fvrdt39OVte/MQ3+ 9a/mLx3T/EZnY92c47/+VanrQAuck7asnJ79A/A42BhlmM/rUvLo9Dl3rqR42D9N3jD+6uH0 bADYaqa5vfw8G5aG+U2Os4xzCZq27786OPxpd//NfeGVYfBJX953yZuZwFyFCUVGrsAMGRPz /ijk6FfF6JZUda3zdmIW4KtVWIXkODfDMLf3zTgdGU7UPBa7w3MzlG1DKI+gfGmziDv1ml2J V5iJ5dDSgFfF9fV0aLlHc4raAqOQrELgJeRnsamv7ejgOLsM5C5nGkTVI05TOkrPcsztS8nH OJmn5z62xOlf8qxkfv266E9pkxBvajrCNbshu0z53MNrt00RxDCqrM0imrXmBK0I4XOePUnP 8L/I1ktKZ7YfSVLn3YmejHMtwYTmhWFqC0opDPZ47XtS2kZ1jmhvmHyZ1SBtcheXZ6e0Thjl EyYt0p+DCbdJdK7tY1HftXNKSwFDfjTA+Ssp4ELlRyxzFIRySLvOZhcCHRfRa0gwgReAF2Cu DWw+HFxQbgJwp+sXq70y1Dr1t2sN/JXOp2Mj+U0Gt4J+ndykiK0N2za+hseMZCsKx2eb8Xl6 7WD2YdZwVqZlxzc6tjHI0ibdRAmHgi9J7WxV0diMsw5RSZdck0L3++kkdf6VnFgT+u4kZeFa 8WI30zEI0WUnbuHGt5n2HIdWjOl2YkMn3ATkizRP9hRT2VB7EocqFa/MVD6CabHkBOVmd/tu fdAlbJSN8wImhBlxkAshIRlg2FKgW9uDsujopYLs4KnNE4pN9RE8FmLlQUy8pTRC4GWFyw8i a79w6324e0AYUGUxABjEiVsm9AQTx7Po4njeYNZDjbOC23bMax04h6FPGJOOcBx2RhybbIiJ bSkHjzdkssxFEI85UhzAuh5v7+GgqYPLIax/i/L6ZulwOmqrc3RLsqKZACXhUfOzR7BjR9WR NOjwg22FzqnbAp+A7F48QYQSwD+/MrT4Bi61WeWPSELM5ODkmJtqJJfrjlu2JD0zfRUuuQSS G7qB5AtmJAbbkwS0s9Uq+R5fZn6I165eVD8RqY5+Ai1A9EMJWpb4l9sSjmsZ/YhiU01PnAIw 3qgR54IPaXkNDIapN45/AZfMNJwxfJumKBT7X+4bGrR2dd/y/Ww0gRcLaGQ/O5teSoyyggRS bttozxYGs51AjoKB9c5VIc49zsGOluqzyx7Camwh67zGf4fB3Jdsdn58tPM8N1UN/6Nrn00B FhX+tf5bh3DaCe/jPtS4DwhvEqhmBohUAOWuNR4Rm4llUPUDgLdusQFAjS80ABtCrs3aejSb 0RoI7ME1wvFvOlyG23IyHWYWV8RXrT0Bn1k44ZYVzC1GgxXlbPiyeQZNhxub0W8puDRurG/G q5L8xw2sR1vgItTOU6+h88mgN0HNKpQ1w+1xHTPqn3/hzUJRbQMFmvsqEJtEnIdcQX7FH9k3 EqI+8d+GM/8K/wJyNlWD9en1Ad/uY3YO4zfjoy9AFsyw6EtQy61XJ3noFggEyI6M9KkdqR8V 7o/X//aHjNpulRu73Ro7g/Xf6Cw3blD97tz3u16nP7/++uuO+Kf4mzx/v3V9AgGau9OGHvki 2o4RRgd8P7i++eAuH4B3ICyjh5PPLVlMH/ajdHCOXNv825ocGHqfn1UFyVNwspXRhD04oJbq Zaf7am/7qIuAHL2/nXZPu7233e2dlu6UopdsFV+z4h0BoHCGz5IR6m/IQCF7A/AI6Jod5CUN RvTu9KT7d7Ai/dDdafkt9aiJtu7Hhrt/bje2Ia+XcIMVFBSPjVCgvLI2aJWxLxDC4rq8LGsD YOviaZUYvM/pXb1AAmKVBbYIEQGHfEDKSModpYlzWCPWGz5EGoFCoteF9x48jELMEfgzEuIZ nl1Ud3GUXM+yQLm5KH5ZDphjJSb88nZ7f2evu1N1Z0IYHPB/HBu27jzzF2aNJBTCytH5TyXG xCZcpWxJ8Hwjyzrh3D8U5E75OUGUAm1FYl5M8V/ikEnl03crDUi4Lt0J4W0RcCfYBKcHNecI hm3W3b9l/en19a3yqybjk53mysqmdYX9R36BlODFVvRu+pGKc+zBb1bHJ4d8Lfs0ysdoVJfO VsTgZt8iwvVBE3u/T/VaD3UrMc80kFvpDKNYVI4g0yisNDAjQzNbEC4HA9Fx+RF9zvr3RINf VVTPE7vUTE5YR07ikorcQNxgWAnMZCexVxi2ld24D/KjGeM5OrpvrYuWGXDw1aTAGw6APTCv MCKTsQMnrhvyiAzo1k8zUN78Z9ZC5ejL3qu33Vc/9E7eQiry3v72uy7rXs2BBcfhkqBPsn6L 5aQOAAJfp+WHXnEBBfx2Xh2etpXyNjwj0Y31WQ27vXCfMdq3dc+sI9ioBxjS2tZQOG0GmhYE LdxPIE8g23OfhMDIgSeIQ4e27+CE+geUXDDRjSvYrO/l/YSFj9Ch5Ndfl8nTesZ9cQWXGubH K+Hp28lD+f5N8QHVgSguPTDEIgdtihG0N+Ff+PyjTuk+dnPfI9bWbRvZuWArZICrslnskTpj 4qvBubYxPwQ3yJhhDshRaQxBHfEhI4WUYz8sNPMC5Ce2ULbvSsdmGdgz29mKHGyNrD3FFy5x hCE6JUwKX6Nk1lUsW9mwnCJortTZPdx9AnqPUZqPS5V87jqH/Df4kMhDK1V0FCOobCfRKa9x cUIYtVSCRaUliQJeWvKoigtlr9lI65xfOfl+O7/+6igT+MWL1cobybqsYWRfCFyH+Ql6aNE/ wHqk08lduo9LgM7CsWXgTcSywZBXthrhlpSHf/Ncrbs/oolDhrZiSGrfq2wwSlKk87CfMEbY a0F9VeFuMwbxW2z8W5UHwR7WJtK6LIizs2isDUYILHq8QQEbaDgdc1GZMtlVp9cIXh/vSUqB xVEwmUuAXlDLbQtDtt74duO5SCeQJwaVIcJRV3T+GmCT4hlSTjWVDy8KsWsgtTne3mNtKSgT HZNguKqxealReJJAc+wfBk3b7yQDzOVBOIZ1XIEP+2ThswLuwH+eEcHjx+7RT5H32ZMoWhGr LO9hRXyJbOFiGxiTY+r3r1uCuJqXV8mFIX8TypluGHwJWgk03xPrp5YPP5JCF0wNZrTWZx7N bF7ktNIt+WlitQvXsK+TIdnWqnF3nAELXCqCzazxmTIML86tx3ObHcHYEHTGPE/LBZHF4aew tXYQM0VkioBGJJ7qCOiVELC5o554P2lg/JREA8UUbimsRGyXmQFxS0HBJklo/hcqLrxcmmw8 +Qq1C4xEClxdWTBxRQaVeFIKymudbB//0NvdB++n08OT3Zd7XZoME2HUtE8HmVBMhRLKHcPC hZF+W9FIP15O5W2nfOI1VXWuUjXIfYEzgwbswJX8YK+jSyqWAq0CiUXCgH27EYILDInwCfCw oXScOAO3hMPIJih8lgGSFkAEr3Em3OElpdgu+MKkbkQOd8Dr/WxcTMFCD9arDiiqqS/UUev6 7G8Ky2MqpcQ80RghbwJeTVw7lMlUv0iFYTFQWyF13Pgkha+hU9fpcAJmShDtzj2rfoArZFPs 2rCUwM2oTURJxnBmzuO1b6+2SNrUVjqJpQfHiCCVboVWDUabhu2A0bnomJ5KNMEzLJMGY3Fg TehewGbzDj9TxIbiQDADUCjaPlL5p3RoU4nDIdL4z2kOIVIcZgY3UU6hzb1mNuCSE+9hfrm+ OXm1WoiFwNCYEs4VemuFKY+1paphpot28oJ5VVG/1gL0yeUUugR/ghSQWtiNm+yR8PPs0J75 8N52oeDNwdpKz6BSlel0r1pKAPhmsgS7BvD0p5hQakS23zX+xP85cW17cHFi9zUD3GBTPblx p6C2MfvasQ2QlqrP8W3iL+6d98sxvbeG7qNkNyRfF27CzBsIATvIFyOXi4pH0+GkQXByzInl amcQGTj+mFPGm8HAnkQa/9B2Q54KHJWUTx5Jv3Z++dBsRoopDNZx4gXdBmIW7b7gbQHTth13 Wp0naI2mw6GENt4UAF19xqBD41t6ALkBWMrkKr82sjlvC75XDj+sEdBPv1i1yooYwB8HtrYi NyCOHGhugb02TgOB7psxv0GQ8Fx5VeFbKa8fTVFtLEXu6sOHC9xVdIek4FapYHa4aWadZMNy EpRrcgfcYPKJFd3Jp9CX4FNw3xgM/pLsDtEhhHB8pAUj25liGCpBueD9BJSuTQjqwCf3L8uR KO/3oMDld9g6+EimneBBgAfGHKEODJwCK7BdevyxNcsaDPuRF/KcLk+udNJAl5z0RA4gNnAc 0sqdh++iBQNr9pGzzDzyJRxzO9J8iXsC4dZ+0AYFTEZQYVPI7wU4B0KYY84fmwhBAWG6hkEG z0LNJvmsSYRdwcYu4XAAgV1LtgNmJfNX1OLyixTij8OGlkxgl0E2cpO2vBfE3kwnUcnDvAJV 0Ybdns+djEOMydVtmWO2Y85pgvHN3lta/sxh6WuRVHeGoOcYicMBRChhxdjAupfcKzbzKRc8 RO/SOjCFWpdilaNtXukBeHg0icbgf7FgVGYKXa0FUqxyWnknOXsGOH0hP00aK7yzeKGWkmqK Fetw5m4FeFlSDkZ0K4MxUF2fIY4dXj4u4RmEytY251hgiwO27GEw4XFwwIvWrkCaFlJAlrBQ LruuLHBE7qXl3Yosb8j8CWOljEDkfOKhQPKXOmTeQHQKNS7u8LCmpdfzoq+CmCxAusLHT4qh e/wiUBAKVaY+SMBmXgdpFGqn6Cdv/txK/kt+hctp+M/nCUS8nR53j3pHJ73Do92DZNUwNr+J YUipDfQNM3P5nh5rmdoL4JnD8LnN5pgCSdhY9f1fVEyulE38PDv4tjcHItQMJkC8wRyiYk7T Kil7qX1MCacRC5NB+gQrInz4eX5UsEV1mm49Nm2Er4IBJc3LOqMZ3m0d4qq/M8DvCGmneZiR fPJV2AysguCv8mD9aT8s4eih0xACO4W8j2GNE+RgzM8DfDvlBGvZIaUWSHI3mzBEr1xDFA2J Am1qdjlO+2JZ9UAL6VYYii4qnLGzRh6/etvd6b3efX3QQWiV9FqB7U60XQJW6CYdD/USsb2d uaGRuSoPWMNipyLaK56RBj4S39HVF6O877Rn9rBJ7nqlVAWw1Qnk9s0H5uEeyuqhgvIW06VR XrBa66spYi7y8Q+9bftwyt4cYYaZGodiinzm5wq8ecuC9D9D9vWhNpRLr3jxQo2c8ciE3Rin w0vrVeu6ozbccbssmLN6D57RIDNNh2M3ylwaMi8nRA3DgMBvguAzL8whASdkzIhkniPKSTid YAAGHGv0ES7rANSWLZjnRT7My6tMGOUppzfEzpIyvcD9dwNj/bN4WkMr9DpDICxIoIZhBV6V UgVyWAus6KdRD9anx17T5B/GU6N2nCey6ExKcPrEMF/gDiKAfCymk2sxtTLOBgVIHRgfQdCk 4+ysKCaluzhw/sthT+bU88fWgP9nBbfD7Tfd3vHuf3RBnkIQ6/prVOEIHxj+4iLNB8SI2y3n u8SDYffyKjla+FGa842JUl4z9kPDTW+bAZkL9BoH3UkE9bz9hz1OiCoD+WR7b1/yM+6gCLE9 HdyhICA9JZXQgiorn1wVAG0dUiPQSpcBW2qkqGXJoWsTyoFspgUFdC0dfxA9dtudvYC/tEMI 2Lq6TDSqmOM0BH2GTRruveZTiU+7qEhAGWUDYuneouooKk6QdsZbWwVGGTCqVTNXBO7Vtj1b MKryoKFYM4ObHFFthw5wB35uhB1TXEOPjkbLZ6A7LtyXA3z5vjoM5pkck9xEvbXAmlrCMot/ Ilar8SK/MguU/XByRXEl3h3+LTESZ0Y9zVM9SghUGO6i1MBXBL3FJ5ffLedFG8EOhWtXZqik 1fFCNeHQLlQKMd8gEugYlazVhkvJnlBepWNSvUDQpdhRRNHqkAdRG8QAX17iVF9joYDbyGjO ow71WzhAjmcr0NF4LUFd2+4FPM2mSIc0KahPVYoqBR1mJfOCmZhEK10g+jM2b+sUzdqmdCw7 gS+8oNXhAKkI2apYAWzGXxtjCE602U0xnlzdJtvjy+m1aUMF/ZkTYSS4XSFUhmP7G6gs2cCy lphRJkbc23HRTuQWayoxgaDBGWZuZDoaggdpQn4krgr6za46VHIy9EzAZVQFztnPABIDQHg2 KAqDwWSEEEkXjMvQy4pzbzyT4IL+vRGBXH5qs2xOrXyGZP55wrLoPny1iafjqIUbUM/aPFkv mlyTQxSFmh1o28ScIFvgmWYExYtBwS4Qwnmj/Q5j7oidzschRB/YAMTJpa/jPI/+9sR8p7se ydXpHsh5U0Wq9/FLLTiR5kpu5ZjDcWi5CJKLkiHCeR7XtEwMYMM+17MPjfksAfaKHIWzfqbR 4HOgfoFrH4CMSWs9KNAWzZFVkzfVkEK2Ftk4wltEQ8FbpK4Jjsc97mweMVeai7/AEQPqP5Z8 zjPCZeMiq1u6xxrvE2zWCO3Yigxd5AmEnmChw0c65Zab0E2ZrcQ0rNyPskV6ZnFrCCJmUnzg h2NaURgbWOi4GcVKwErp9Ysro1WpFbd1L5LobvUG+XUuHotca6upqHkr5AdcfTJ5sZxKeGOG S8BsGcgXrC+zq0x14GrkNZ6FvG9sy3rQR6+76LZVkWmpvxlbhp0EiWHh0vCFifsXqqgNjnYn rDhnJBbfcgs9gCH6mFqv1kYyZ3AOsZ+NMHj9wko53Kk3EKLX8GgP+wgnd56PcuA8RGdvvcqs 1baE1xQW74YR+d4croFO4vvlwB6sCrIga0qCCUusuEv3tDH42VMqTYCuUgRpqc5IptDSOfu3 y1JoZq19zmpy4lVpW/JCeqt88+4EGjkKcFczr6JHNuh5BGdO2QFy49Wm+zhNXVo6M798mOEr pzuzsjSTpzpbfy/7dD6YlihiK0/nGR4CqpYmQMuh8X7GMZjnHMRcAhY5BTKjmYuMQpwNCanv LYl2U28nsspvubAs6wKCZ6OYfrp/uP3qh9720ZuNFhZGWX3jGzOYHr8NYcGnruBdTUtxQiFP 9LBn39Eazf75A6fc77ih1hth5cCadRuTMqCRSte1fH4F8/ItwD/bQr84zuFea+Zm0kUWBiRW gUt3d7RXqWFdrS7SS8ckbnQsmqLtNBPHZWf61LSoiV/SSTnpQarkNyUit+xHl+yiRnpUlBSb Rt4ReODRH4mqIpONXltSDXGBrNtSxaEZ5dgSLNPyZqzZDtm1kp1Gwe8FBX3QDIizjPOjpzoK L0f7v2AghDxOmNoTlP7APElFbBCUCo6VmBQT0wy40sTfVRXeIgebeZmQCq3GqNgqB8IQt9Kz nOe6frzmPGxLS3EmHXmLnuMuVJYHkQAqfAC9+PzOORavJqFo/HxhBknsrlV//F+BQvn0xAWl tRx4N7tBnFq7BzxGdl0q5Q5A5eEVbms5LJrEV89QlL5+rlV7DRroDkcr3JHs1IlgtQELr8VN Uam0tFuxpgueTzFZyjoW05AxcK/zYX49vUZULHP4Sc3qgiycuxIbQ1FYd0g90De2BHfSKn1A wTeAxHBmsGegbUxa6L+FXxSxsNaxtLwdnl+Ni2ExZfhhhXXFFLGffMzTRNGrVruttGmRew+a M3HdAmNC3yzOuLhVqrXSegaDzYrcljPDefWVzmzb8kSU18SuCKwXe8qyz7R1HSK/5k85OIVe YGI+zD8QB4dUDsiBZDC3iD2nCh7BIhl9nDT59O4ft5qElmXr7Ex9rq5qtXiNdr7CtiglPYxA HAqspt2Z8MjNB02OH8RMJ0/c3G+csIizuG1535Zc4j3cZtD9Eh40Stg5ZE4kv+d0aCvkw3IK dmCQZnyXS/HY522zNcyxkaO9Jj/aj/vkI+dllW4nGPuFTwPeXPRKdu1VPYEB4ISmYXvgcL/G bEBhMqClmiTNcP7MKPfS8w8HF0dZWUzH51npDLNLDystzc6CFE+CVBFarIv7iZecRDzBDT06 y67SwYVcS4pDYRLAVXmL1iiuVV3tMO5e1jHjihjjmI2RBWay5YbAquscbz1Zupf80G5PTzgr afZS5RyI2BkmEo+rw/xTzwuwsrIpDsPgZVuM0/EtA17BGb93716N7k+l3QYmAXXn7iGLyiDN IkSjoCDuKYhBJ4qNlF2G9aOBTo5gP9AexOcZeEfjykO9lhWJNjZFPPq+qkCXbysryto3Q1O/ 1Kz+nUui4O24MlPtF0BhMJ0qhi1csACOrrP4SuXDvil3lk1uMnQ1GTP8CTxtlwVy3NyeheYz HACeTnDXhFh8oiDmhaMDvwphn1n/L5ayVlk1So4txJLPMrRPx886P0Kj7vJa0SLG2wQpxiqK qX6BoZvUV+3pQj0xPrvUicWkaDx2+nBBVAb7UhdJBq8CpjSAhXWhxXiS+vC2IfIN8ClVPI8Y NolZd0hSCVgULtDcc/FjOEjmFqDbMaPAkssNwKwMGYjFPKT0CGJX4/JjH11iMC1X6Tw3lp2L xS6hIMLFMcSCzoFVwpRG/DHcIMhr+Bv85CPILLOPMAVWU0SJjRoCHhA0o+5m0ByACeTAAOdv AVDhQPYrKbI72r1ahv3K2nuq4d3svZ6EQcNIEdijnWEQyJ3rJqWgoGsJLOBQUDuRYBIYZUFt QBQ9Cnu2LGasAJaOo4mUO5OCxBB4g7mBZuhUWEIXn7kzJGMgtHlhMvPK+QHQdClrY9gj/VSC r+dsvw4qav6g10iw6zMX9l/TzNHp/j6IvOoae++DPo2FuLt7c1h2uuoK6VBoEJ/zcMx+OZbi kbxVTxQhupWhCuzR0syIaZSgQbQBgbgq/iMzHbYu/c4fwTxjO2ubUhsqQ7Iq1Or+vBADHm09 5kuil240LiYZi4uIsAM+GxabVZFNkP9yuH2Hu71iVLb89sytw2sRAicrDkM1huV7tqxgHNgA D8S847V03pv8O4Hk6YK+3RUetx6CMjh4Bv0eOvf6xRmvik+WdspjtdV5MbrtnRnZhkA1MM4K o4Ad48hfYb3PuMYjVPqB2d48bNqj5lEZPG3iaAxCuA0dgnCTEhNrgBKRWxJkDPQqgk/oiOS1 tpYcFzYfj4O4EZXjsvgKKiAGDCC5gCB+iqvzPVPhUv24fXRMOSO6O+hnas4f/H50/ONOD51P 9UflfGqofeh7Gl9U8No9yy/NcCEQ1WL9sOZntXvYPXonXheiSyY3k5o273FYYzTlRbyOqJ/L 4WhsztSFHfnqC8J47SQvT497uzvsaksAs0SkdRXgb+uqICSsUnfRgTcksvFOANikC5XU8U4E PHBhXu6LPAOfUXMiUCMG6c0Qsj8gvb/IyeAjlSWaqQJOUGJvCW6AQ9Wsloki2uWGOGHIfAH/ 9LOMVNwSs+YUQqQiQ/zJ27gLOvoudZOTt9sn5m/73eTgtfmH+Y/54yh5vdvd2zlOXnb3Dvbf QGjqyQF8Pe5SK939k6Pd7nGyfdRN3nW3gZS+Pt1LTvdPdveS7deGTCfb+1jqp0fHyauDo6Pu 8eHB/o4pRw3Y1yJ5uw3ddPcTeUl2FP/2e4tR/uHGKvdqEtOQgOV5zWhwKOu/rDQdQDkD38fP 9cm20TDcBgXz+a2c7ptqpOAyI0C5mYT5KxVPbKUnxhyMhBC75GvSqR8BeDAysiBECze/gQiG 7sPGJxKEcHw1PUs21jbYW79s+4wtxngET6aTMqxEwaH67LiXcVCqET3MwafYfNCr4fy8/KvU DkX4B9yvRLe67G3cunumSZix49Xrp1ltOBzOGdiLFlJBFv1CuyD6nLQMBn1DwdSY9YWcOBc1 gaUdZwNQQ8CD6TBp1wAY3iZmQPdFiSZxLp+ue6eYYgwbF2oNL8dlgR52oGXv8ECMMGe2Flw/ 8+vrrA++cYPb+JKFIUzsNVQjpumV5CnCJVgWlR88cgmgF1uBri7AKXgcDfl85GyelvhoiF/r IGWqDgtxj1rlYCZRldVwdktxdmxefox4Zfsgm2ftp+oFfJ0PQpgZn9ex0ecA7jW+pkeBNbqQ 4AIaiSGEWfiwG84KAmZH5JysjUceMhbWPXOPf4mtxoBRm+y/GYBT9iwo62Xbim0geWGZ80hh 8BUlhvIJmUMP8K/aTLWdxxz5xCocq6XRm4MqOfOa4wMuVITVBgAnkpYTQadB0gf0OGzkkZa+ mTMRELaY4c7w4IpJhSelBlvWh6y1qlELS0k4u6ogA+9q4coxWxBniPax1atiXMKyXOVDBHeW mQvBL62aSSZjXwadk6eKcummVWdLclSYjoq8hFXTUeSIsgGJxEowKcGuXp150NHqlH4BDd1M Fd1sfeJ/l8sCD6G59qlVIKFPyAI4iPz6i47tjkCI1IpFQ5wXCXHGsatiIn6p4xcq3vzz57AO 1VRR+h4Ww1ViPsZ81JpQD+WIiD49kC+rm0rgRKEGZFSgqn1SrwoB9Y5ThHhLx6JSJ6kuKH3A U5n4nyXlcVALIkmi5TEqjiIMgirCWEWrieak6GH2Kok3810vKLKVXkmpLZQS7dk9XFxS04Rm i3D1XXv4k1SR9t4d7JzuGYHn9OTtwVHrfjxtHJ4ULrnTPX51tHuICr/7C+SJ023s7b7qGlml df/N4R6fQh7jCMLVQ3xzdD7gG8AtGPnvHQ6lWvb+vnVCJ4zE0tqvkK1TGK5WUijXGoYRJP6Y YzBhjQWGRBnAeDhzp2h0wv2/d55GNc4gWeOzjedfmVa/+vq7P2+sf/11NVmj+f1/cjXeNVej cn2k26hTAJJAKuIEzAkUl/iszsiUiA1UIv/mypMosYtLc2ZJXDz1GLEWC6YKu77+T0BrjH0a FuCmVX6IZwQ7m4S17p5EzHyDzkb9NP4RkAJmpBhDHCQLa4xpjSlMkZM88YdNW+H4LXJzlOjb cDjTMycjGxpG6W1K5r1UbAd4d+F7fLVBuHiS0Lzy/an6vj6rwMasAk9nFXjm5laYS5eDl55T WNGcSofACAuO85LWoGzvY3b+M6gbXx28OzTccG//wJD5X1zLPkhAxeRA62QNI07Ifez9c7Ou Nd+A0LKwI5nfTzvsCLh/6gP+tln5RinOHnv/3PSICrh8aigacnw1lGmG1junHOOYvpyzvaCH 0FqyTSJcpfjInGbJcAeJLZ1PJfUiBhXTVgboHoXz60ahd2BOqRFigJOnCpDhE1Q8GMRN0DIy IuyFQemI0sjquoiliBkrGHZFBZ2sJBu/+OuHT4w5m2wm4dQ1CTqhGZqIPtkJGEXkXQp91EsG A9bHyeyJb7yyL4vHjkNYdkkuhCiKoOGrRMhoVMRmnuTEXrlYcZB/APXdZcFaiDMbFM2JX4Ev GgyyAW0XcboCRO7pRnExz80OGF61V81o7yTJ0Dr0c73BS927+lR6msjpFDmkI3/70vBpr7dP 907IpvzjNiRxr2S+q9aiXC5S92T3Xffg9CTYcvC2BYEJGPuOhbOp4BLyhteTDctF4P5gc2tB UJ6ARK8LTBK6jQZhd4aSkYhghqKUb6MUnel4mEDuzMrbv/TA4MmixBlKM4AA0Jsk/A80w5mi 0McU/wUVz4viQ56JKQR+EWwX7GaTBD255pS4lxD0TdFBNrR6imXr97th8YipKwC9GipwFFky OymcxUMaifkLDkC7iJpuREKNIIMBWhGtqoySut16MMg7PL8tVguvf3qwvvHN4FNH9nTL/WJ6 sf+yKWWoKWmmQ4uDZbXmhOd5bwsUD0fdk967gyMQLo6Pu8eiS6m4p2KmDrOAL9zmqbQvgWIA Crbs8NqqEmq4eTxLasl5JN2jo4OjzfgI+GCgtq8nZvkWTxFkgN6Edqfdsd3JvrRennQFiOLX BP7xfvvV3053j7ptrXSCSUo3Znmg3PEpcioNOW7UaMSj+0GO8+SmFpyrCkup7NTBDxKnrCGN oFJkYIFbwgRJhCUP+vDQQdHBGfjDZiVA43PtAV/CHBCzBjRwQESaApuA0mPEa40h8n2J4FYe W5Quj+h0MBdc79zI3Uhoeul4nN7qlGJ5R+NEGtIktJqeZW/pHrmdYW8u2eIoZT0HPlIpeFrr bXvWG3wiLJ1qcPewJi7qv9HIBdTMgY2RZqvKN4b+H3Dh5NyOEZkgvgkACPoxbdnDaQcmDuVw MzxiDQ68dWOtDOtRqaBdHvQFH85mP7rPBjnXX6fSW820cGKrL8yRLslAget92Puxe3RsODnf VHs4SDnHoc+Hs2cQMjUJspXOJ9/6/vj3zyIDOQ0wH1KLsWoWfKXB20eMJ8ja+ztD3H5bjr0/ iZdk3UXPMcEpgwodQUpJmbe8IDDEK0zlkA0RozIvpuWAzYWiIDW8yO4Fmt9uskdgGJagSP6O IUqIw5chmiXmgEJ+FqEuxesFlBarjlxh30RiEN2R1snZhGzvCeUNu8wYa/Pdq22z1qDSYJ6V Ua8N6YLdYliWZeuPBbb0KbonUqIxztFCEL/F+EPHesSnHn+OGmlpCPVMKLuYcbTytWytk1hi 1BZdUbhF9hCw8ZwzjpTcNq7i2W31mmI6ePCcJ5O/WT2Io+nj8NiUC3qdsxIM6pBLEaEQSY3D jKNdNFTwA0UHYw8lmgcRiZq5NnRpfOu5dcCWUAUx+ijgZLz1LTtxponkk66Ww7fo6uItJuTt 5BrQu3ofcJvxa0uFaqkqXlP15n17GPXZdqntAsKw9BthPMFfl3XIjzi6mNqrR0/eY6zHaOrs rxQCBKx66M/CDSCqZsShheRkxMuWAEObl1LH8WDwd4aIrD3QyQDMZNnb6G20bMgH48EO0R/O PEJmE3kDW5b5IgrjtkSeGwVoebzfe9d9d3h0cMI6oN6rPcN59jak7EP1mPIyRhwuGvaExieH jBPZAYqsPW1ug5b4PKBJEo+Dn6RVT4ZrhHtqnY6Z7pt+wUXH0b/1TsL5u4OLKs5e8XdgFhh9 9XmgVrw3InhRGp6HFXqjKq6hm25KsLuK/jfMDDekLdF/yG5EUL2WvOKRx4bVR/rFUdEoHqj+ FmKHt7ig8sjkst5D/KN6h1UhcAMikXELrp/PXVWLAjfdw3JUvicSeC9WQVEjx04mCcirEHhJ yXA/EVEV1bgoo4F1XGaXNLHHh56YoqEACqwVN8pPxg0dRsBUFEgF0oP4FqGDZE6+kTm5Re5v H+/uEBDy+4OjnWPzwfpEei3myGjEWv2N5pR9gvfUPhrAj4VKjJiLSjghDdm7lQTEKPZSRDzl GBq7HtO46iaxzO6u9NopTwkPjlXndkGW0DpM4IG1tMCzz6L0EQLPIVXTbyYzQzfz+kPWuEMG cdr+CxL45YPUIdINaVzkhFJwHo/SV/IDkCHiPJcE1ozpUVBjSDjQ6UcjQbBylB/7vMRn6GlL Ax0Eqv2EXMJpm9+evuztWQq1d/Bqe6/37t1Rb3tn56h1/PapGs9623mYBMaAuza5Udvk07s2 +bS2yWd3bfKZ9S4G0D5QsPeKIWpLYVtb8Ie8rpYMhmImFqJ3D3o+tj2/2Tt4qbtmtV+49EpR trpxunf3pja+XFNPv1xTz+JNSfyPw8GtmrIW2dUN1eW/ZFO9AUSmjL84dB0CwgWy+nL3+MQQ hMEAjbaoLmJGLXTepopmPESvYnwnxihgqAmlS/Jha4CONLO0iDHIrDfIHrdg9pLE1zY/HVnn YI1+sUK0tz8y/fhqyVdYtHc7vZ2/7R1ikZ3dI8gr8mP3lRCk+VZ/nvbi5/luzR/N27zmg/23 64hFuvD1Atn5yz9gFa/Bf4837N+F7kZe0i9DhSPv6ZehyZFX9ctQ6MjbGqfX/ybktfpoWFo7 B7H78sSlSiB/P0pT21c92dme2DyDiVhaQR8JgW2SIhOucZgUlly6KNJSklXnGjcB5IVJbmtS 8It5hzqBbQQUNzbGPoLKTEZg1tJfndVYJUjtqjLJbS7PDIOtxs36NlYysJqfUeawLdcofOO2 hE2q/jkhdBIrDlXrNPlLgKCeD6eZtY+h7mxuEJNKKFwYC2cR2mpLxvJPx0dlGArMYO4kyB64 4zsNPvEWZ1U7pkTE6XyBcvoDkVYVshckqru5i/Wz3vTZHI4vFxX24zqliVEWI2xTWJxw2ZZX ojZVe54Acc5dPPPvgfkB/HF69lc21sjHD/2znjW14i9vX1qkkk8P2ODJ9pxl0mza9VQYJx1J xep1FqnhOmxqTkGm0FLIikO++VgFOH6xEbQFKbBVMwrO2yrHGjXO99i9BLPcdHdawVXreGfK sitzIDDsF2/twOI77K5rOBOMzYtNfTNGzd9kk8BUEsmzBcZDipu3Lks2BxCZP0htIv5SAsHp PLfYcQgVcuYSQIegFZLE32lZTq/ZhIIKf4zbrzenBa4y2XB6zeR08hGM2da4K6MMfWYei208 67MrP56yGqu1tMJ15d/KcqwYYbiXnSSP2KcrZtJQLccm6lgHdRZrnpNHwsajRQzS8d5C7HY6 lUemzKEpArmlrE2WJokEuvhok7VF7acywwiljg2jE6od7QSFQtfPT6Ch5yLSzTTarUCUBuuF gIYqR8umhaXmrPJ3fS7l71KlvZ/zX5Jft9xikB3dffRdXmh7JHaNfS/5JcgZa3IYaIN1atSg G+RBNuzrXv36IqkqvQG4tl1Zzd2huax5/9ByU781dFrLybj29sD/I2htWeFzkHXCDO3/PTjS PbAZo23hMJaqxX1Pg+pcXqb9H6kZ5atgv3Lu2Ir6eS7qW+M0qhnM35cGVzigBckvDBGFloAP q5jYNTseUNRNtZl+M3Fa9aP5uF9MjrNJI51CRwZ17n1P1DilCmcxm49sYiP/SALVfBU8m97M y/Djl74LhwiGghoh8PKw2eQJlhO1AORycYnxP4TQCzouEBSHYMmdSKovfuoJjU2ayS/Qm9zt tc32emZNfhBJOmZMX1/CZFxfTwo9B+zPPmSBTBlwQZkO70OHYNiyVcgxGKESbbwwqblA2cri Mnl04Aqo2BuIJgryoqn+zajdCOzAFxwD9w+QENz/sFAygtkaO1ZsBCIo0a3crKnC3ygo6pwX 7KQI9lHJAYra0W5dT8sJ4+WCSnOUjQe37JruwqV9GKe6RCVmVYaYPcqieWT/dCxgs4uivAuB PiCqL1BETfMtwSemFDUqhGadQ0BbA8/HhZgux7I3uAbWKiWWBfijylszD0qBzopZfhhjlDeX PaiPT2Fi9eakxpeY8EBPE5FP6QCp3EhEKShloAQ2dDgMRhBBeNiS5LiSpCh8ZjTDVdnSpMKP 0e7OoVC507v0Geqlup3EZzp83PRr1rx1822e7znzpTYP6s2Qquu2eXklggolcIn1OhT0LOGB A1l80N+kXIxb+Ne3L81fKDj4waD/3GlIgAq1ZfT0D3GCrQ6jQ+ON61HmUojYV3+mvs7uoacy E2/pGiIXW6AkCepW4imqPfj4XHUXT126xo4VekZj11zO73wBZUp8EJUGagYR6J8aVkB8sXw+ TX2bd0WkobmWBQtHh6U9urwx2Q8zB6SbMKOpGYktVTsMz1usMhb3da4BeY01j8oVdWpHv5Dv PuUPTX2bPTC/IUtJIuNSJTWYRySNMzoSbmpznE5MXe33XsMMRBVwN2Wo9GkHKafCnaPZ6lIv fXZUzblXFCNrnQp8/DzfPmTABQANQvPO0L/a+nuniIYODHkXQmnPgClmRrqU6EHLG6cB460h Hscepy5wao51PiKBCVJE4LtCsfzO3mWzfVV4XUqfG9rnb4qx2QMzXmFOySEYHgrvl80ltLd4 nDkjSEEyLhhLT8YiUTkS0MM+kAFX68X/zOQ9vahq01DgWOl7Wyr+ybc/nk+8bU0GELoHkfSY mHm4+p/ZuMCA45xZKtLKwSKRYg7/VqObg2+snoPz6RZSOX8yjEzroQz1Z6j1izMJ6VpbXiIT I3fhjjvmqKSYBMNm2AmxN82chh+zFj8/6P+SXIJ0hdD+jiPBg7FsTe0+6+Cc6XcZK4NOhE0q RuHf7N15ba4ESHo24QgEN2jxk/PpmgvU4ZgNsPeOAWljqPJmeIcvH1ZhtErbFUI6cDVx68dw bY7iwFSCoM0iaBhw6C3SvnbSB34dWhP9Ke4T6Fe9CyKroaOxyA/BcL8xhtWlqsSTBYQCDxb8 5fuk9S2I0OTlDVqjNn5wOt/ghDxMWhune8n330Mp53sQXEfkWpeUzwTmCcfj+/ro4F3vfe9l y5IB8SmInBaHNqn584HNTCU9SBO1ErcupR0KRBsUjL+iEnoHsFY2MbxOCi/6CqGGURUkoGKp N4hqzE7R3JAZqUEaj6yjOeaoknHdPMCrQgw3Xj5KqWQetB3OBEKPciTtjmPgY/lvGln8ipm9 UlIX7IqUlGz56jrP01JnHLeJ1bY8oVC1o0vx+1yb4qdxou7s0NL752UfAb0c/k3Vb6S4ieTQ cro+xSKBcg2vM3oYeLrq4NjwnaieDZjtHNm2fJWQzbPlDoUcsUVPxUKiXw1wMc2ig4tAO3qn fZNoI3VMPKbNvX43CnMWCH+ZDT5S/IBjEgND1ZKLkEBcN1cwyCDjy/7NixPxTkG/gsiBt/kS IINhkItQMilYg9nSzEWYcx9++4zNCFVddQRBLwKUnmton3G3OYEYihBGlmiJaiSI54jQ2jMI j60QW7jvMkDUzIReKnxJN21gk3suMHmJnmH7M94nR2yCR0mSjXzOs7To+yP3Xt7zL/UI1Z0i DY9+twMb1UlVM12CCzFwphYFNNV7AvBlmmtMMDTZFYAfGQdhCAwpyHNnnCyGcJMAIcZjSm1l bozb5/SWhnGbrylkVA37NLYtODnwtKSgQ0hdMrkpsBmM4iwx1hmkHmdiIUaUZYaU/SwhK/DQ IeBR+yy/cnB+OigLMb1UwWy0/SVHM/UtBXuLdzbOy66FGW/kjRV4Iy2XUnZHt62A5dogPP6u lhnKj3LJRkv413X6qUe/lPKTVUo0wVssbOOJOyTN4De1NQdKfLim6OsKWFNrpo/M0tKb14e9 H7pH+909ZbWh/VBaf9uh587iv6mz7RJ6G4lyVfxlthKeTUuJSIgAUJHGnSuzm4MdcqRlb+gY oNyKzDeYFEfqVn3GVKxu/RCFb11Q9+GBasMFTx7RaXxktQFAXSC6FTM+2BhLyc87FNRSaga8 u0tJWjJEUONxXmaI2kahUgpf73JcTEdwkQm+Ab9TM6oQxmfCpUnHZEinmKNOsnuwi+QWjPPL HLX55AlEgVyb9eM8m2bcQM/+1M8uzGlliPQsp2wEhIv4JC2vVwWHFEA6167QPk9tRQsRtuLy CjeLXv/gi3TUfQOOSEtLgKrlPj71Pz79+hvYbnfxIfLVBpwkfwlrJM/DDmjrUOSnJkjq579/ 7xEV/lWpkpDDtNGtaB2Cg8Fwj7UoUtG3H0FNzdPBXQvqCv5LBbexngHOJpd8DI5W9HdEezI/ cGQIOr1S8e+TlpRfgdTwc1Va2TI/WjfY+SarZmvTREbmi/5tMF0xyjkroVNmWf8XuqK7+73t o6Ptn8SAHXjSOT1LpL/Do4N3SvO7r0yBDhshJTxWh01kif9mUn7IR3DDXHFaPX/cNQuAwBIz ZqJ0Wu07TQV0dXZw4KJi9np/ep2u7uXDD+YCTwBwBQCwUKFXpxzyNJTeBOqHXyG0jePXay9L nvq7wMpHygqDDKKg47hyrtPqFkQmIfLqQi4YS7N8KOJuyeJvPpdzxVKje0V0BZv8K+z6BLb6 mDneSrjWnOkGQ/KuctG0A9IHnNM415ya+TwylsUyVu+VMVegS3yHZ3pm1OzxXN4Vn713vnvF 5+7dvC4VTbc8FArrk1bWOVuI5FoMPY8LO7l0AHCot4nTpGgpfyYtdfHUR4KYXOOIiyhXGFwN gqaRmADEn6oCR0Xphwi4fJClQwh/Ri/MxCL/Aoo2+fpLxTFGxbIYFkXIuCxIbWlz1EpVl5iD uEFqSpJLkbdeP4dk89PBhBJnUAL4zJxnhDaC1NiTlGyVN+N8Uo/TIXVB7DOsU15ecd6MydW0 pMaoQ/w3Z8eqDpTxrHi68KZQ8BzwkYYug0mxHKWcrB4lTxwNLPenUQ+WjnmMBHOQ2MneyBJK RQm5KNNrRpECVkcZ8NmCbfHFsJZnIyJTMAVEm5/OioKTtHuh8Mz1YHoUf4gtRblrjedOfFFg Toad+j6AZGq6Fw4p0GMl8GDwkIQJrDh+CKHs1A/RJwcV7Z8Z1eHVbQkRIeb+vMax2Fn1enu7 +91eb67rdxI6hKK9c5DTQdOh4FT+GAClveRokyLw/qUMH/Y0TTjbDMFhEtVA/9/LfKiM8/4u R5lrtu8HnYPJGQ2r4spm+CZLdJV3iedbsjTrcMRdbOo+hp4p6Jri68etdrzy/Di8LRKNq4zY pv1WFZuD2AYGVJYDJleSJXFD0ihND26JO9D4VAlkeAVWO+7/G7X+1SZtaQUKmk5Ceihl/q44 CNdobZy0oLRIDmrZ6tabsztXfG8qGKHOe/5QWtgxC+gr8O1AlMFNNYfXjdQUD1u1eoj1ticD 0d2PYwR7fVbCINRq8lEN0nP6mpKXP510bVD+XDERyzqooBL3MLEYwbBAc2diATQUyEjx752H xY4yyMLy9JvnG9+tbXz39Xd//nM0C8vTp9/9+X/SsNw1DQsv+4JJWK7TIXqsoPBALdigqyWg x+UTdhYqk2vDGWLhlMQMU8cQw+IJEsUvmFwFaGM86wqkZV8w6YpLERpt0TzaC+ZciWVWCTKk kLnHvCjTEQNjo4lC5wUhnMaaDZWNqI8gsTYPuW1lg4lOpA37pijHO9DCoCY2MATIaXp8fiVP BarjbHnSHLp/fs9UfSgDUh+t59D5Fbw1VFDK/WyLCYLD+ZWLq1RmCvzddu4NHD9R4BAJcGio fXWwv999ddLdUe2ipqv35tCNQ34JBqKLA17U+aAoDXM+vhTQrqUlrwG/THVSOpMvtPyB8mSU vbQky6nNwVxbMjcC3OxSZLF1yYErJasZmCtFhsiPcAI621CYhJoXiLENyuw6VR+uS3T1B/VE Dz5h7nPMBjidZJ+sOqLaczHsQV1B2e3d/NMOM5p5WjpTFWaUhnWUUhVf3GPM+8pw9uPUKcmG GSg7UkxvKkS29gpjU5KGDUU9a4eviNAkqIoSthg2M46Um9sf22zzPNkPJ+qSU7rOgRHEksf4 98W8fcT88x/gqmok9eTdwfGJPMCUK4fInM46tJYcQOIYenoh1T21gZmfUMoH7cX/thTkETlg nmUJOMRmfTL3jOA9QgGH2sDIvGXGRce3+39/RA3TI3mn3JJMR8QzgMoCUIEEou7WvIO3piNp hi+IKTgdk4E7h+cP7Wxth1DmQD/528OABtbA5doBtZNVoiXFxYWpX1Oqk9gGQ/jgbcGiRmiy C/2MO/1uSck2UQt2OS2mpSkyHX6wtjcyjKn8oR59rto7q88E2RZf9fZfvd02NHdPGT5jls+w g9qszFDEYjyDiMa4gXC0pHqYaAChIN5hucBC6ndbszd1M+KFDzZY3FillLseDiY8tdhAmEG5 n7zpnjw5PD0RdoBJYfAazWU4f3PoWco9Q3nQnm8ur3QWsTz7y0VrXDkaFhJ73m0jKmd+fDIy VINj6mglFt1JO3zcSrUe3l6xmPnlltQ1GFtT3d1nL6quE9nJyJlZeD/4OfoiG+LmHt+RWRcD cTlJQw0ORchsRW5HyI7N2FXeSRjNwWF3/9XewbGR8o/eHLNCU23xbMau/hqFo/pXbr6uGjuu satxx5vMeY9xs+52gf2Fsycnslexe/1HHYZodw0E4P+a41Dtt24Nmi/pXSnT5xyw6F7MPmHL 5G0bk7K1PM3HUYswAXsQCmNEAGmBENDzukhuMgraA7FiHVTO6TDJ0vEgN2KuZTmZCj4JsgFo 5hotgIZ198363p5wl72PAthlYfu9CYVyHjUBZUXai86aJ927vgQjEwYMlij1ofwRkcWq1Ugo wyEYvnty0XJdg0Z+jJnXzh+sP+3f15vANm3uFDx3W8dvdnvImaGelny0SaDF+B+yhpr2jrd7 x2/NL3zbK/21SPveZgwz1WckQcn/r691ZDQzWqyj4LMphbUgshrebGBit5RZGFNxWIgXwWoA sIDeHun5h4OLo6wspuNzSj75m9wy0gKkJCVjah5EKAOy1B8Xo1GG7oMcnEmFrEKJC+DlspI1 XgD8Vwv/xMHg31Zf2MybW3zcWo/bQUoacj7TLeOAVCP9dJIiVLmfykbsQVwq+zTKyVbyD7C9 m7+tSDDF0cHhYXcH236/vQv5R5fSfj8cs5I930veP/Hkl2xWVtwmXQV5Vpg1pI6Ouyenh+Ad /mjM8nY/Ox+kLGdjXJQma6C5trbQyyKaZ+PbNisfdYdbur9QbeG0PDNT7ljulNJnWU2Dr8QB 71CbtlAkcH66kDijbmNahrnHgrW7Ti9N539SDm8SKlYGQ2XVSXW8gfHYguT7KVRQuyBmvjUg Gy4/SUBy8KjG6wUXHJpgrqnSkF+0oU15pOLjcU/YjCZqkvqU16MeB9AXY0ja057RjoZd4LmF eX8WalOrDkKN+XIle0y8DTolnNcI0Azf7L7aCI2OdUhmr8zhAOEruRmno5Fg8V3lfbYCTSE+ f3ALh/I6g6Hl5TWFUEwHA8IN8LNwt8AYNh1M8tEgc5/KNhnL08pdccaycnxOuFqAcRbBAqym N5YE5ZEWk75pqKm1j/l4Mg0b89STFF8zVM0MVTugK+rPgS2IKm/BNrLL0WifISbDTIDZEArv pF/NIpGeyvB2Zmz16ZNt8IVEvxLLAotseJTAvm2/0Vn1q8BK1lUx3/wqsF7VwjDSeaI8I4GM fISFR1BRuXbek8DYb2cjWLOBuR8GLdZ7/MEMzxQlQ/7Ru+29WeCG0mszvqGORq6EvTEDo4fN V8QdB+svhe6LzLxAH6EaXvIMizvkLF+DSdUD5tDHLNevyyT+EorzizNm+Kh/jXYLfSssRZsj rvBbhgz92R4wdMYAD/5fApulSh8HvRlGCQ0R7hJKup26lHPRA0/dt+frC0qpCK6gf+1VS5+i uHtxs8s8YHs2N+CAIA0hmkZi/OCb20tkv8g/LEPPxtzC6obB81WMJgHfDNartoJPMBrTB2pK Qhv9hEI1lm30lqxc6EjkDZHc9wKUH4dqEe080oveOgpC8YfwMPk/rWC8CCbMiip1MppSHfJJ qzm07N8Y6TvaNa71skbRq3mQWJUR7dRmERDxt/5Ac0l/KKGEXPEWj1BG5ymKZ5mdxXmVkPaw ZKfppSaU1mMuFPbGFZxdzk8Mpr9HADoDZtqSHDZuzX8UwLReHwhbAc7rXsB6CTr/0hyFn3rh VDUVrHttZJn07B3+siyT4cXEudN7VhASJ+2zgIHq/aS1he6gbefsKQtYQceKjJMdOD1g3Xfw AX//zULSyBpTzi5wxVYBu7LYup2jbGLVebwJjWxwsBl2fU3f6KArgDjVWIjqDoggZLbApQjx SkREHl04KK2FGdlWu7GBauNuG4tJlM3S4lQraS5CCljZNEY53yaeuLp13pOR5Nfg9YDKheID y5fkBC1LWtFGEZ2OLPIsRZCWJmdsQbUpremkNihEySWFxizzdZsV0VJpmbJazeHBVSp5uH3V mh4KoD2UvmCYvAgqOn8AphNhhbAnT8ZUOzxgt2fy3gO8ZgzIF090uLfUEOdDqt6hOwusT/0r HqOE0avdQCrmg7SH+ULyOfIXQ0Q94Z3sySLbo/n2xBkiQIEKwNNZ1ndOmiwITiFwV2KqYFux 8c9CcwI2kk/kTO5PlFryqI0phgAQAt1M6bqSmtRphJYboDRE5R/Dc2qJ/cJmrNH6mbZ+xSLf BZtvNtRSzRjsuYEDsr3/kzLmQI3Xe9tg0emeyDAVDvwcXJGQnQYjUsggNVMynbKpxuw0I7pu vmi3OqYh4K2Cc66YqwbuqiKDUgXds6EoGASWnLE7MGnFQGuE6nJzINFtmoNXgsOgAjz0zr47 fvMl9jQJnybroxTfQ3qlvFw1ypnhj9wtIDyBokA2a9YWJb/L7jCdddQpyMEnDh7Oq5FdxxM0 /1mPRzLI0Y/zZO2wLp5ES67LS6wacd8Cv+XZJBZBUxhnE+V70rINz24nLkKGM4SCg+BNOpz4 xiDnd/yw4ne8u/9GXEBdM/nEZTcllb9pZtWwU6OO4c/zARBwI4j8RXfNAYnMf8GlBRSNKaBo AAArT+AvySD/kCVfAXjrt6Y+wycIjOhW4vyZ7Zzt7A2Hse7+tbrq4ENxLQDx1uKRJuJxC8uF J8O1LFsy0w+D2nVX0PldJL+iE8bOu22XCfJhtQdlTYSbGBuC53IRyVHG1vVqVfQQoBHK5Ymt Q1WXQAe6bReFLc6yJOJHyZNP4rP2J+U34U+JTK6NaxPfG2thbV4V3XdkTSJ8g7iERwH27NJ9 HzmLDRKvFDFULvErbTlcfn64+vgTUwEbQ87FRbte6byTuJgD+js571vSWa2ijoJbuzpWpnZZ FtMdN7hhVQksE1eC+ectrF+i+vnHfW0aKD5eduvn7g1sISLP7/AfQ+WtNePKMgDuuG7ZGIj/ qx6DYJ5f8jUI9u73eA6CLiLvQWUQCzwIQd0vT/2CxZ+T/AW17k7/gobmIoDhvfh3oYANBIdX p2FtvhDh83olrQLrVCbTiwtIX1ec55jCCx1BUhmGM4bvm8E/T7Yxz10ZjecwF6xkjAtUyeTD heipnOXysyhpPkMZoQmpTwzREUfZhFtObqtj7M2g2lEBK6LYr20zfEdqG52DnWrmplwDmnOq ZQdtvdhswjycMe7dpeE0ot0U3wIItRtdgRQHMT9DRpgHz0tmDUi4C4L19MB+zn9Zo4C99bYb TlBhkqVjCKLq2ZIwBNVZvWqpjhK4A/Prlj4xmw0qopq25lIFHkoaDethLHd4pt8KXVVUOFAj PW6i1QZ3tewTpPtDfzZUuZlNG8jFF+yIysIk5kUkLBEMehtk8JtZSChjKk9HmIYDJlUbFRwO Jn7NO4l/wx+7pSMCMMflvofDz8sejU6Fgqr7fS9CA0D3ddT922n3+MSBTscKHumS7pBDKlj0 TIITDgkUC06aceOZkUS1aMcb6cExZrMGTYSLBzH7KD6uvnAhSXKk2BCjzZncxOPwdM+hfLKc Z49j01qw9WPIbRGM7zfNM8nMW94idXcMGxZhaS3ynVt2MS40LT0v6KYu1yDAV8rVMXb+W1B/ /g73fpKRR6iOLYP9etg0oDcdZ6PBLS6mv47NHR9Veg5RzhsmaM2HtPs62L12n/i1xezKhpiM kaPADAlMmoG7yocXhcdeMZkgJG7PzshEJbMuSY5Z0kyUDiFY5JbgINAzsSeR7LjGFD6wwO3w ifxr8yCDUX8Ge8bmrnFmg9P6FqXBd3aqYdto0xDIHePX7D975IJoWh5kFxP0MUAn8uxsekmI 8NMxiHHAmydsLDeFccvgzQDssiqgAeZXpSK1rwHwIvPyfPPRdVuMYz/GNqJe4QWw5ced1NhZ Jo0ynuPp8FyxQohkkN0Gv4h4qStWtDH2S1VMsZ8qoAtme645901YBFEC9Gev4zeHqy8us0l1 RPABAimrA3pzuBbUcB+CGjc9aSysor5U6tT2oz8FtQDpuKewGtxcwxdBk5WQdj7cSv6Pz7LB 95j8JlXA9eRTg0LKCp1YepZ4+gU593q1Qlyv8ZnMP/M1OTgaG9pcFtdZMUTAI0mZLHRIWG7U ORXXo0E2EW5+Oopw5fIo+QSxSkkVy2rzqyMvamgZWuNn8puIw/ZZLGe9nTyCTeaOAjqATp89 BTAYeRDtmfliPGuU46l7vaOcJhh7LS+7KT5o1+kHs+FTenQI4C+f3KKnFkSFgMiA+32Rj0vP Ja1Cfh2iSxtUd1Ho+1raXaGJHgWHszl5VCKHzcCZCRx0rZl4VIbvKw828gwxvzu/liD0HL9X 6znOV8ksHx6ytAw9WyD52ghEBtS0ArEDuPjivBh4HmFR9s3fw1qut64+V1fsX4zzdKXIOOPx nmivr2M+Z/V/FBmAP3oX+wbWYVwwUja52531raAVcKERyCWf8WQqDvnbMeYCaBy3wweyn53X hc+29YPU8yf2ftv1qVxLF2Bs9fxs8KCPQRxndTuKzYsTW6ViuEL4W0aYc/fGj3HGCDQ45TNJ rnMwMeejMbTEA/liBfD028T6KM3W+qnWg1DNxxoOqylOPoDWir8Ss6DBanKYMZ1fSNlkz5Nd Bj5Q8G/vquvc4QEvEysvWcTMyQGfaQTO68uhcj4cUU00LJScJ8f/1DM9OvmlR58QLhEEfXLy N2fmLD0b3GqOgmsqsoAIzmxcusiNDAOZfADCNtGqGDN8eDy5Omu0THfU0N+Ouqd/wwEMxcuO VtdltIzpGmIklmlU07MavMubMytU3uH5yiPN9Es3E1ixmbi2G46Zal2VYn7aL7dZ924ceWWW 2ddH0XFMnmSRsR3Fg9OgctRFGDp4ah7WvzVNu2IJspguDZM5SCU7TEn0jodL71ZsmSJ6wDC/ o2YOltlEuBRhEmj9FjdReU+lhYYO8KZhodYtUl1UNopAEsrrlw8bX79w232tD9iWf43pTfVu +YerFVlebsP9qs6ypTWYRyxLIY2W4aASj+yEr5gAtBku4jlX5zwRnPGO/6Lq5eKmim9H3yMb DQcf+99sZoHqFJc8Fk19N+2Z5M/fazVr8uuvMvIXlEYRc5gdESMgR9Q2HJbgU+QSmwfZGgXb QGeZ0Y0dAEPrFauey1rtL+VCrFxolTp1QUJgg2pmvKZwluZ/S01p93oGzyY/pvPbcRejVfWk JSZ30NIvTlEW05dHHq6m4kcxgXO+dyO+TsEe/v7Py8xT5dmRZh8rTeVaok1UzhP3K25l7drz J1Wi3Ju0Lf8O3Mzm4OrQij2LeqlwowUCqz/7nNYdu1ZEQy0DJILkW/4ipp+gqaPqu6RtKLb1 wGJji7prPesF0x3N+4ApfTT+p7ioqkIw+xw6DOmaFa11JJGLX8Y+gW69/KNmLUNhgbAvp9SJ MhPRJVdnLtSBqknE+hMpq4akhBeY39tgave2PPcy+x42vHH4hmb/nKaDd+XlMbjMKCzSkNR8 CWYweD4De4U/oc1/Ce/IL0zMRSBCf+cjvXO+5+5mtgLN/Cjd8pKRVElwJ+LtFpJlHRHcIFRX +qYzEaXRlhP0HeTmJN2NZFEz6h7v8XsT6AgJns1F1BevdaYwU5mL3MKBmJfYVvYOIs4qwDAX fFio5hLFe1apqjTzJWiyl/SuuXpQqJamR+a6GHEPi1VGV/cIhC9sncWL1r9mtOoeREe5qOdr hYo8T4bZjXV4jTnDFoM7OsnS9zhFiIxaudIu7DVb81wqT5z45i0YNjFj9SL0FhbvLgEWeu2i jsUxNnietatczWgfd33kFiW3gevvZJJdU2Yth/xm/Xo1eTMlarwJZ7juchuiJL+z365Op4Rq A4o6gLTk6l9sadW/kbFVJ7JgxgCtzDa1Sn42MKumKwIU33XqRQFrzAGul/XdXqDaBqkQMXOY svj4xIidOy11OrgxsHhH+tv0O3JaEt3TImaCeZ+8hnKBQm65zrMikPBwmgvzA3OsizNaaW4P DKd9cCm/KBzOU3CWE++4cCImexCdVbDey8Yfmv95M6ztOeD4Nd0nvfaLmLbnqASdLFSBee7Q AYpdnPwZwI+61epXz6vR+UX5Bc1vrqMII6PLepJZnRGmKpeRilI31CCeJaIdcqG/YERi4meN yhDEYRNg2sy0LtniS86cWSPntTGj6RncAIsjivUuivE5ObEwuqd3YuEqJGfZBfgO3wDQITQg VfVZht/XkpdTysho+LfiQ3qbIKyCy+mpuu2DOVvcuynHFnoUWujQcChSEUa0Vj9Lru9AQKWe Hihoy9lJ3HqP09R46Ztm6QFaLLm0kk105MtJ33cVdyLdOM2hEsYDWTx+ipnfaBTJ55TItUBe 77S0FpXS6W2qX3frjcOJI2krHZNR8cpwmp05FDsRL2fE0o7wTlx6NpO1OIO1PE/cxj7FtU6u IPjx5qrAQEzruYZedrkETPSzgVlfSeIHADasnat1sGAvPViHbFznNdsJ2TVrWSkh7eZ0UnVr 42jcx/RfWPLptxyi25vcjjAIESqT52bMn3M12ZBjcHMFeDutlRX4/XvoMHn4MGn2yn2h0Kd4 MIbhCx0Tf4YWH0R4dkljZuV6BzYjkcYEc+eQi/MJZrMPQt+4empdxswWPgJzMCw47mUZbOVa sovJm0eFecUNp8ktIE3EtM7kVySuk2RXKw1RRlzlMTrUIYVmApo85qbPXT5dpntqQyC6Ef+1 +kL2h8I4dRGN/HV+Pfp0fnXZeqirdfQeAznRJmrdXV1Qqhbpdddsjtrvvdq2CUc9V6rwACjZ XAaIXMY9Pyg2Fn+qiuPTO0CAUvoZlHgjJyICUSVOfevBoD/Lv9chr0iuuUtwW5khGHrjkYsX r9MJ1xo5JtvS7MkSOcqUEOxNu2G6Uj7QR0ZnPEsetjaxAMkZ3evg3Fv48PKSwZ7YAycCDhCQ vnyIEQqOAqLTXhCIWYWzqsqf6iMM47H5QxE1IV219A3K9gs6hVDfh8vEFi1QZsSXe4UPVB39 ageR6rSs5l/OiZEAqZKAuDp8s1K69sZdVQzMsS1zYCPU7Euojvu8jTEvh2wMxQVEogUW3ZjQ RV52Bjp4EFcALrw10NaMrYFX2G1NrSMldLqQC2V1URdxYUQsCtNnCRyGXXtv5CGsbSUzqXCC 8ALfmEewA+9wOrzFyMgOPnfkbkoxTFlqxuU8eAN5nfeQDtM4u2AHbSUgVuJKtqqXwAKgRs5P tQJsTSWiU4ZMORkB8grjsQZpOREIQnqjvREbnsGOueqUX+uN7Qwv/7VYk8sObe81uuUT+gdk BCV+yFp/wU41nAxugbOZQO6IKftJnBEECCaRYFMWZZZQruprSevEkYk3Xc4VSMIdtEIN+Gt2 w6sF2JwgDAJ3tNZedjh/dTt6L7KjyqOeeab3GUqKMFdm+ABekBlljqBjSBTFvGlmjThwXA+7 THZJwtXIxUcVtIymD5Bkz/NRbmqXa3ow6M9v+D0W7KejfgqOJ1w7nGtZSLAfY6GlGroG9RE8 Nm6AiJjoVEaQYhSSK5mNbcGWh2G9rXZbM5TRcI0oX+7pP1jG8RbXLhkuoD5KS95hwvymJPdE j5Yn50dEHhbjjWC9I604Nir6/ClAUV40egIVCTfvnlm6j3kxLeVKyHw6sif2qFAIJOUwAQpW XWO9xDN4FkvPliLPRTVmrjLBzVobd1hZbqM5k3FmMOQFIyPwGNllMYPU+32bK4i6p9SPF/PR oOTw4s08N3yJyGAf03wAaK4dU/lDRvncp6M5zm81R7N3kKG1ngSlRXMzax8vIaj7xY0CUxpm N+FJmUEnqRWbWNURyy9BJ+Ehq9BJ/ZDNd/LtLV3s9AOqLN9p2K+mSxBnEOe+BY4NDJnAOW4B VP7sW2AamecWOC4qzrYmq/yrjqR1Uryr/aIRbR3K2avFrsnFKGc6K0Kepbc4zxlCr+t7pqhb 445J7AtI/gen1n0KzwAqFCtB9K7HtnZbsnxSLf/DVzQCMcJJ+yRq8UshHXdczEhguFRctjDS lisWptghllahmFWGByE4u6JKjeXrogyUYj202aZ1/q7X9dw15VQyVHlkXlVKpcQ0THYoAfMS tSN7JXjThIOAxnr3SevphVAhRpBdBcIKcv/8vpJfyn20wEGzZZbg0bExbYb5w3y9MGCEEjZM EWr5LOJ0R4BeQRELNm0XNKQchAENwfMY1jaK1OVf82OInGcaKcIMj+xAglv2NDmxTem/5oGM Jp10O+IT74fekYToAuxUYJ3jjKTj+Yy+CyHLLeJYfQd7S0wduWg+p9pGZohmyi10pjdbGBhU LW7jiq3ekcDqQx8LEfx8r87F9mReL5Q7bclvNWtae0uFGYzcTxScAMwyHxq24KNWkTOdAjJe XDg6BAIXPXbYdoW8wSPDLVg3AkabVp4vQTBgM9J3/VUU5U1wCRtUpqanR0boNIzS5CzD7Eh9 wucqaS1sKk4zT/CFGF9jHg4k56mKGzakHdu7BO4bnGHWEixo9m9UDPvEqmaU1JJAG67Amm3r vyqur6dDtkBgS6a3cepy90LWRgv98A9IRwfNQE68KhxZdFLI/Q4z2KhzSrSupweE2XurgV1v Y2upMs1D2s81w5iPqbl8kmCDiFygUv7h8hVJluNGSyfx1ljLqVgKOwSYYaMiLm51mw+3UDML 9XwFnskIG2jeL74PANkTIOSrUPHllViuNhcjLkopmR6q3LCU04gFJ4EOQZASFTQX59PxWFRM mLkogoAmukL3MmA4vs0TEuJSwl6FB+1fwG3UaCUXIcOyEwuFwtkuFqHI9dpDx12DRDwdWbb5 +nKsGVJ7Gqi2fPFJ14nFf7nKwjNiNhYI8BhzvpbTEWTpaSY3jEXsI1xV09oKUj/ZkQyxq95f Czrjj2m2REByz4ysdx7DDhHqE/CuKS4ugMIaOkQMo387hil6DoCtGNYDx04N8MNBqoTrdIzV IdAdAE6QcIBiAXIDr4Hj+hB0BUjs8gk1ELYtC6bbRTlcGFl4FObJ2wuBQ5z7t3VzlZuLEk0B bPPvUDOU/EkGjpmY2rhnZhiGGBY4jJSTqbHWFlM9oOQ7KaiVShZU+zpHfd5qQk2qnnJUUOdk vuclZcbC1UJS5v1Jd/to5+D9vrsk9ZmF1uWsIN5MLAN8bSZ374i9JC0ybihyNpYsWvylm4y0 SpOCoE6nhhMbwCpTC9knIzNCTYfKk5wbapO5JMxQrYdgqbxG9g7d/LOTxFZbI/ygD792CQJQ lpuMfOKMxDqsch4BueDdrV/6k4OjfbfyCp+KUkKZ+ZkzdVmYizidmJrEA2KO8FIJzWtrazRf wzFSHvFeeeuClSp50pkaLpBIvqGQguaaP9V9fZma5lSumPigwJDVNJJITfuhpqLN/eWqqLxf UkO3pbOhSYHAZk0QtYZs/P1QeDbYExXaqJ3NQkdg9IkUXjTIha50KuAID9yHZVyIdDjaU1af F/F3s3JUzBobPCUBixc8P7MZQCdFOu4GHH0Uu/OC/W+Yp6CEl8Ik2QdtY1Met+9N8d677b+7 VEDH8s1yRzV4Zw7rTOSlWu5xLgarQaaOYyTM79zeXNj3mJ9PWqeCbBnzlHZwRO0xu4b3zJzV VJ03W4WzhpNFoarTY092WzwSqbGkTGaz+LklB8VQw9eFsqny8RBFYg+EKkNc7xryIXRb8vvZ WY9Vfj+9WJQgFDhCu6ZZPzSIRBzG6jAefV8xlpFMoVcVqK362M1m5bjtxm+10REs4AEioUkJ e9pLL83zc+5hX3qGC8eqRPHkPEPB5vJnRjwt+EhMhzOfCctTqWehooX3RZQKAC9zbLQVwId4 r4ZSibZJieHzbLo3bK4IZSKZmfNUIGyaJ2blhqT6OeZQGFifMfNhpP0oAd+xbzn4W1bLYCpc NgYiiw5qOpgFX3vO9yarxJjxTjkFLSlC9jFPtS4TTYO8OtvjyykQx/K5/LTkHrFVO7k/YcyE DZdqeIbVgsZe4gYtzL/HI70c8aLnxpWSBB2n0HM8ZFHoGfi3f+aXapUozhIwtx5lZsSHAiOq jfdw/S4UENDonTXzhWW50e1sD65/y1MVB2qWwlOWyeHocDDNxQB+NhTkLCW/L6AhEIUAWvSz TEzF7gIC8Nn2EOPewSsdrj7c8RsIUUAiFAMJcPDehtraZiJwquqmn7ztJrwxye5xcnKQvOwm ewevfujuJC9/os/mIegeJdv7O8n73b295Kj7bnt3XwqdHh7sm59OTo/2q/dfraC1lJhTO0Hn SMwYn9TESuA+1cVLzMAFBmzfu4P5fhYWwzyJJOph2FRzPKAII2E1xx1cwdm+A7JqtN6N7FEk nEnX5lJiQbWT2iTyqJyXywyPNpxb9wKWkrbdD4xqiDcKoXsWgfmZY5U3rR9tBSNPI9TFk1hs Lq9EoXZdBFRIlOB01ck2tXklNFSt4/CiHlZBDKpzUTF7g65aQHXgmzPMoRuRYQuA+8g+cQYe 64oFHljUNIbOshvWvFHwYf4ROiTsM4ZhWM5BxvpTpgwf7uyAHIxQXqpURHUrMMvHbKaL2W8N w6SUMagNZSR1ZeZYxGWzxn1SB6X4gP3zsvbRnBYxajyvqCj6zT0WCDUEcUQ01GwRvlo3VF13 jF645EQrjr/ii8uBYarpG3RgMRyV6NHBtmrofiCzG/KC5uS0n8HjMAAbNtqk3JMMLRGCLTDY Z0PTjn1QSq28/lJS64N5vdiaY5EqcuvsKh0c8+fKpF9w/FWD+nuQpuA+uYA+uvXW2dS5mdZL c5T8BKL45Dwh+vCtWDbMmRwmG8k/8ouLMB3BzJx3xPE1Xo6GjFfzu+34+XsUpKeCu2hvJgmD 4e6yx4EZV/YXx3DE4Bm8uOJa4gjFKdWUh8vRKwdZNoIKIKoDnYiRTEm0U40gjPe00MqMlWe1 RUD9zOXy8FMnZBMJssGf0Hw3l/2gcPs9CkPipeKryfXoXjbv3Nt3LsjFWzWxcyaOmEpjgYNd n2xDuGbivcNorccMmtUrLuCH5iix+NUIg8eesBHRmqlIz2HkITbygAEJWkH2Cr2XiT+ZHX40 +3jNjN6p3qn53c9mN/4J0oNOrNbPd7ygV+oNP7qQbEeRQ59ghmxSEBvIDv/DgtNJaef97JFZ bJdORAJcLsfpGbUIZmS2YL85JPd491TGbsyyDTLfsJFA5Boe9R/XLM6mqC/ICXuOqIvvrcog FrfJvcMZO0EIDm/23iKa8l5okFlWrAo2bojQOofVgQWEi1tMx2U2+EhVYAFtINEtVOQQIq5r SK8ZM2a39BMwqWwjOgBdqvaLDH110C9rihawfLIGG4nMer+Q3WOLsu0SNE+Xac7Octb4gLdC As2ra99J5I9kxVB0QxadNmbJRSuQHJGhBRfNKHgA7eVFFS+0IRaPM3N5PljThvY+xJsvY+Xy VW9Eu28YcGWedbV9htZIfErKyUHYT2yJHK3J6OPx7nPwGh2uaWYJwmqa8OtnLdnV3DCGkedK JXs1KuEAvCbAJ8SUM7+UsJcXKIjhJ65HFw8oH4HEcA4Es7nDPmiGIXdONjm/8i+ldyvhIGE4 J1a8SUsbPxgJ41JBOvwIukus/SWtYGsjpJxw6wVwhXLt/sH77d0T3VSdIk4TQ+AJdavxBJii iWtv6jncC59mQLZwHyKTmzEifrCCiCPE2VBvtZGDBEoS9HykHh4AbIxI0p8Rk+4in2fHpHta LhVGZJ1r8DfrgmdDc6KROR6l8gNzNuHmafCG+aEbhLzgFbMWNVO9k6jBzRCDAibETIUYjuV5 IGB+d04s2T846YokDHyNOXMQjQ/KFeSn4+QIW6slSWugWwY9GrYAC1xaQAB32ZBza7TfsKlh NdndAfHZWSbAIQldxwLp3Uns9fYf+kRnbTXhyNa1K5wf+pURR7nGI7gdFCkMQeGvQqcue6YU MUQ/TUYFiiSGtkji8oTdEJcS+z/a9jZ8dLMwVHS82s8u8qGLmeMp0U10CTCj/LI1W8nIWoEV KkyQpJjnhI72Y57KXVLVOZtOjJGuSQ4R58Q9wiDWJsKfEeMTmrsC65PnkNdsKgv8+uSiyk7q lIWN1qk4uW/Vm6s6suAPQRzZFLY7YteRlwLWJQCuUeN8iGSI/x1Ygxrku31yo0vPJ1MzcIq+ 1lSEHTFTG51J4YDyPqf9j+nwHNnG5HEdI2/emUNDPSlA1UZHYU/85DOsog12x9Z8p/8YbpUI VvWQVSCy8bvWi0JURcBBUJlgqwDRh49wY7A/GK9yvaxIDN4PS04q2JpDjLCsqs984n/v/BYz qVnwRbYOU+o9Jv7oHdhXdlxKvdhgTV8rKyGTxaug98Nl1mBIjEcOx4MZcde6TsFE4oC5hgOr QXZ5aDu6D3y6fQiq+Ag8LC1PdpGhCEmJ7KPXv6E0uovN+DxIHMEwl9LKyjd8Tczb4jcpoUMR nscvuHAschh7HFHfqoO/sRnIOUr0zIZOFNeciCdkcTV/0GwkVscrQbVpOvELcmVEQSyTUA4s CxYsLwuSLVOMd/fEBnWzhZNURimZqFKEWDmiKkFUwamK62vM7dTnVQBRmJgEJLBWyBKMJF4g TUkthzYPJYX2yoCKKt6IW1I8BJka2BN+HuWbVV7VktgqMTUMhYfz17FyC/+I1gn4Q/gNUPTX qqWTLZ8vrocYlPc6sSpUsyYfgHUl4MjrUQ4i6VU6Gt3eu+dIvgY1I65cbkDIhARIeA6ODkS2 CoKtJRhMo2GBVit+eEKv28kTnxA7oqWGFyXhurNagr2ojhFCqMaFYMqKkhMUbGdOueljlMwL VxTV+IdIgwpH22lVMgzrszBBqMdAPRdxE9uvfnCmAMok78I75R5Yt08LYaBJhFo/NmO/6+3u n3SPjk4PJd9a1ThRAR1swJucsZvkyuQBFm4lgp2sMf3Mz4SFrBEupt+2PRBHi+kokJu4nnQ7 ckjTen1m9o3i7BHu9y/qmZ0vdtth+Gwb2XQ8BkXjOXo29m3MVTEdEwIJfSfME0PCrPKPM+Si LhPVSSxRUj5ddLuE2WDCDBR2XU0fjRM1jaACA4JBOMQWMKjGq6ed9PM+ASMRl8uxTbVd8IeI frIZCFPrJiNAmLPALJeWagxLlvG6+529k14pelmQ2mx6xgAArBmB6ye+fuhrAW+gqn0NfBCe GgG1woTVBbiNkVoan8S0T463Acfl9PpwmqVvwSfTTy1wGmCRMEuBWINOnkFIuZJJSW45LgcO 4/W4yQSLmVp3pRXr4OQTeCh9T4g7b1T9NjWIecdIHu0iKHAep72YlhVHYqtAaCeKnai6CTss EOZBXJFI6PaJ1i5Z3+AbMarr3aLdEQAhuE8UlY3taEBbKHZpygyJ5ufMesFLnw3XkgNYXE+r dYUoG+Q1YIVXX8PulkZ8jWMLk6swSvJ/Rj4l5WBJ5yMdX4CO6WZyVUwvr9gFg2DzsnHZoSnA 2mAwu6d7aKPdBDVvPs+tQ0K9+LecYJkG6XmG4MJGdAL7g9rXC8OkWjsaD6Ziq2zHz+Yfr7yz r75sGh8xpagTFZxljJV6zttcrEd3NrLF8ynbYCwzFW3E7X4Z5VqE8eZYRoCU2N7ZOeoeH7ek r3q7dp0q3enK67XiniYcyJ6TIX0Mmj9aiae5Yc2SLyvLr5NtmtR0KM+si1eS387vRG7/pcQW nsIIwcTGNNH8PILJEi46Os0mmDway/XD8rII7SJVSgc0p4bWIT5Cw3OADQKwzFBwTplcQdeV +8ysl0TRnAlZJKMoUXtgUEjGZzh3MHiOMwDlTBBOaxWsomAAPpteXFCwsLY5B0J6hz3CDGne PzjBLHLeSlvZRcLv+xKVJICA+Chg06msiFpKtMKrI0HbiUuBnHlHbcAjBZ6CCwAjcovwP+/Z f+P3bAnlylUP/Ae3Ba2EKcSsX42LoaFaPp9VXGjDH2iX8YyNDM04ebt7nLw+3X8F9Dt5d3p8 AtEY+wf7qy8h2sIIjNQzSK6rvpULfiLyw5eTp+iOH3F1oB52h2+uN1nu8EJPMwf0zKey+p8H /A98wO3vobLtji+70+CpIC7aZ/Y+jj70rDINt5DRnaaDgcIkbbROAZzwHY6R09dHj5LrvGPN W2DkBTE1N6/UJ8bHxN/NKOD34uKiJPl+hmtwLA+e6C0nBc2+kgmPrB0Ib54rRxd8pSAcKh14 UE4W0uE3bWUDB5YXJIyDEN9TPSrsboROh+f9WiHBoZORM2OC8lw4DqA6DmydVYC0TEm8szim P+vWtJNvpeILUQDNhqQl1QtukxnGLJ9CdDyUExzr2nocucmt0CFIXsRmoyxjiKrD3mNDMQnf jFPSXrjYFgoxuRGFkgw90rih/3YY2ibmziGp4XmgvoFyk0veNSuDKNSpI1FLS9GaViPtQVrY 2iZltVuOKGmycJ6eX2WggCoZyA+vqrq21C4tYWCfbbNfGFtEnLdo5A24SPMBPad0bvsJtoiI UoL0I4C+uJMPWLsaAL65Z6OjUtFO5BnBcXaid6Ux0QtM2S4XRdwKlmbXPSW8RLqojoLyaI6n rxQiYo8XKAfhRKNpSHAgOTKdVOAdynJHPksKNyh6p5KVLUdHXTKzuoGR2o/Hppl6oYxgrRQH K3HAc/dB5XmZkU2EfeYWvyBJ5RDzaOkN8aXcN+hj6kuP2qKibYvxhzIG8b1oWhcF/xOk3ZEE LngNnX3k2dN2Mqdho2KzJ7z8Zj8ODbnNuUPmIPZ1PXoe4PYt88G5+fXykiCwRSvwDF/AJZzr W8fwWo9wmCN0fVWMWG4bFtA6N2DdKcpGX3D6s8yvR4NbyfbBfujO11o0FqjBJ2A+8RO3Jqsa R3HMMyB/iKN4Ikk/5vIOv8ycG8YM39NYaoSZGaVlZPOlihY+R9MR6wNawTS046YbE+NSgSO9 VCRWM+DsdwZGbu2Le28rsekw6srH7NE7B/vddnO1JscjGWF4WWyypI3ZxGtHAH01AcsnZST1 SgQYgCrfiV5pTrrldiNGCk0zbc/lb9kzhXPwESgYJumHDEX40dhs5/nE0w+YWWWDCzoc6P/B DYCWqq+tbSCSQ2tGJicoJNQF5ObO+M6pXN+BNQIApBHLKwpNUchV8zZcxzE6Qrt6mGZYMVY1 Ua5zhrle+47gn5HF77rJB9zd5OrtFUjpQAUbP4PCU2sAqHfl5ZG1jDVCQC153qGV2Nq5g2v/ hatmH8TQRB45IlXHrNDNNT0H/2NzEi6ziLerw3xwOYVQYDz/8IiMhaHDVoL8vMWSDZ22gFNy Tlvm9LIjGZseI66w0gLplB+Vc3jDqjnN7xSLL+L0W+T7NAhJc2JD5SLLb9Znu8g2cUr6Wf1c F9m4TCg+snNz2LOdZOmNax5tz3pOuAaokBlI1YGW10gt/e/hQItHwjsf2FHMgdYfwRdyoMXo yJrOPtuVVvNwja60d0puNUcmV3VBWu4EPAz9zKT4l3OzhQl5brZwQCNetqaccO4VL1uc3wJe tkQqWCD6Yl6224p4s/GBIDUctdYZr8XslXo2tGC94dx0LCF2HoShTy27iqQT9qF1yx+Yw8Ry 8d/WHqZ53H+FOcydajbq/u7+HRHgP8vA/oscO4IEUItbjPjBnt/B+Q+MspoLt7fRrrUQ91nh PXsR1rNKsWf5cAcMxSJO3CGPEZi9ohzFZq3bJXz+A70uzamKe11SpWNxvQQla6PvpeJb0SnD vCm266qXNvXn8lZ6AxKnTGaU3IKrl6bCJrPeo6PWxffTFIcIcREJ6CXEq/eB7zGEvUI4kxlO m9DJLtg4nsOSTD+tPl375kk6Pr96kqfffPWkHD75kBnZa/DknZHwLwzHtLz1+f9bXl1ddd2t FeP8srHPpafr61+vrj9bffosWf/m+dNnzzeerj395rtnTzfWv/oqWV3/Zn19eWVlZc4phM39 +fmzb9b+/O2z7757ur7xjJv761+T1Y2nnWfJivnz6+Svf11OirN/rP4/rVcH+6933/R2t7/5 qvemu9892n3VJu59xey4EcM+ZudrRaw0JEc43u/9/bC9tAJKFyj1abR6C3fzOfzQuwbwCdjk 3rC4SKeDiSmyMrsh6A/eDdXUuWvLUnH+l5PkiuX/D06VoSRBUQIA --EVF5PPMfhYS0aIcm-- From dcn@sgi.com Wed Mar 23 11:53:21 2005 Received: with ECARTIS (v1.0.0; list netdev); Wed, 23 Mar 2005 11:53:27 -0800 (PST) Received: from omx2.sgi.com (omx2-ext.sgi.com [192.48.171.19]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j2NJrBVk030141 for ; Wed, 23 Mar 2005 11:53:11 -0800 Received: from flecktone.americas.sgi.com (flecktone.americas.sgi.com [198.149.16.15]) by omx2.sgi.com (8.12.11/8.12.9/linux-outbound_gateway-1.1) with ESMTP id j2NLTBNv028398 for ; Wed, 23 Mar 2005 13:29:22 -0800 Received: from sgi.com (aqua.americas.sgi.com [128.162.233.32]) by flecktone.americas.sgi.com (8.12.9/8.12.10/SGI_generic_relay-1.2) with ESMTP id j2NJpeR04576814; Wed, 23 Mar 2005 13:51:40 -0600 (CST) Received: by sgi.com (Postfix, from userid 144) id 5EC0F207C2; Wed, 23 Mar 2005 13:51:39 -0600 (CST) Date: Wed, 23 Mar 2005 13:51:39 -0600 From: Dean Nelson To: tony.luck@intel.com Cc: netdev@oss.sgi.com, linux-ia64@vger.kernel.org Subject: [PATCH 3/3] SGI Altix cross partition functionality (2nd revision) Message-ID: <20050323195139.GC21418@sgi.com> References: <4241C391.mailxHNA15A8V0@aqua.americas.sgi.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4241C391.mailxHNA15A8V0@aqua.americas.sgi.com> User-Agent: Mutt/1.5.6i X-Virus-Scanned: ClamAV 0.83/781/Wed Mar 23 03:58:42 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 598 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: dcn@sgi.com Precedence: bulk X-list: netdev Content-Length: 20914 Lines: 734 This patch contains the cross partition pseudo-ethernet driver (XPNET) functional support module. Signed-off-by: Dean Nelson Index: linux-2.6/arch/ia64/sn/kernel/xpnet.c =================================================================== --- /dev/null 1970-01-01 00:00:00.000000000 +0000 +++ linux-2.6/arch/ia64/sn/kernel/xpnet.c 2005-03-10 08:10:56.439571861 -0600 @@ -0,0 +1,714 @@ +/* + * This file is subject to the terms and conditions of the GNU General Public + * License. See the file "COPYING" in the main directory of this archive + * for more details. + * + * Copyright (C) 1999,2001-2005 Silicon Graphics, Inc. All rights reserved. + */ + + +/* + * Cross Partition Network Interface (XPNET) support + * + * XPNET provides a virtual network layered on top of the Cross + * Partition communication layer. + * + * XPNET provides direct point-to-point and broadcast-like support + * for an ethernet-like device. The ethernet broadcast medium is + * replaced with a point-to-point message structure which passes + * pointers to a DMA-capable block that a remote partition should + * retrieve and pass to the upper level networking layer. + * + */ + + +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include + + +/* + * The message payload transferred by XPC. + * + * buf_pa is the physical address where the DMA should pull from. + * + * NOTE: for performance reasons, buf_pa should _ALWAYS_ begin on a + * cacheline boundary. To accomplish this, we record the number of + * bytes from the beginning of the first cacheline to the first useful + * byte of the skb (leadin_ignore) and the number of bytes from the + * last useful byte of the skb to the end of the last cacheline + * (tailout_ignore). + * + * size is the number of bytes to transfer which includes the skb->len + * (useful bytes of the senders skb) plus the leadin and tailout + */ +struct xpnet_message { + u16 version; /* Version for this message */ + u16 embedded_bytes; /* #of bytes embedded in XPC message */ + u32 magic; /* Special number indicating this is xpnet */ + u64 buf_pa; /* phys address of buffer to retrieve */ + u32 size; /* #of bytes in buffer */ + u8 leadin_ignore; /* #of bytes to ignore at the beginning */ + u8 tailout_ignore; /* #of bytes to ignore at the end */ + unsigned char data; /* body of small packets */ +}; + +/* + * Determine the size of our message, the cacheline aligned size, + * and then the number of message will request from XPC. + * + * XPC expects each message to exist in an individual cacheline. + */ +#define XPNET_MSG_SIZE (L1_CACHE_BYTES - XPC_MSG_PAYLOAD_OFFSET) +#define XPNET_MSG_DATA_MAX \ + (XPNET_MSG_SIZE - (u64)(&((struct xpnet_message *)0)->data)) +#define XPNET_MSG_ALIGNED_SIZE (L1_CACHE_ALIGN(XPNET_MSG_SIZE)) +#define XPNET_MSG_NENTRIES (PAGE_SIZE / XPNET_MSG_ALIGNED_SIZE) + + +#define XPNET_MAX_KTHREADS (XPNET_MSG_NENTRIES + 1) +#define XPNET_MAX_IDLE_KTHREADS (XPNET_MSG_NENTRIES + 1) + +/* + * Version number of XPNET implementation. XPNET can always talk to versions + * with same major #, and never talk to versions with a different version. + */ +#define _XPNET_VERSION(_major, _minor) (((_major) << 4) | (_minor)) +#define XPNET_VERSION_MAJOR(_v) ((_v) >> 4) +#define XPNET_VERSION_MINOR(_v) ((_v) & 0xf) + +#define XPNET_VERSION _XPNET_VERSION(1,0) /* version 1.0 */ +#define XPNET_VERSION_EMBED _XPNET_VERSION(1,1) /* version 1.1 */ +#define XPNET_MAGIC 0x88786984 /* "XNET" */ + +#define XPNET_VALID_MSG(_m) \ + ((XPNET_VERSION_MAJOR(_m->version) == XPNET_VERSION_MAJOR(XPNET_VERSION)) \ + && (msg->magic == XPNET_MAGIC)) + +#define XPNET_DEVICE_NAME "xp0" + + +/* + * When messages are queued with xpc_send_notify, a kmalloc'd buffer + * of the following type is passed as a notification cookie. When the + * notification function is called, we use the cookie to decide + * whether all outstanding message sends have completed. The skb can + * then be released. + */ +struct xpnet_pending_msg { + struct list_head free_list; + struct sk_buff *skb; + atomic_t use_count; +}; + +/* driver specific structure pointed to by the device structure */ +struct xpnet_dev_private { + struct net_device_stats stats; +}; + +struct net_device *xpnet_device; + +/* + * When we are notified of other partitions activating, we add them to + * our bitmask of partitions to which we broadcast. + */ +static u64 xpnet_broadcast_partitions; +/* protect above */ +static spinlock_t xpnet_broadcast_lock = SPIN_LOCK_UNLOCKED; + +/* + * Since the Block Transfer Engine (BTE) is being used for the transfer + * and it relies upon cache-line size transfers, we need to reserve at + * least one cache-line for head and tail alignment. The BTE is + * limited to 8MB transfers. + * + * Testing has shown that changing MTU to greater than 64KB has no effect + * on TCP as the two sides negotiate a Max Segment Size that is limited + * to 64K. Other protocols May use packets greater than this, but for + * now, the default is 64KB. + */ +#define XPNET_MAX_MTU (0x800000UL - L1_CACHE_BYTES) +/* 32KB has been determined to be the ideal */ +#define XPNET_DEF_MTU (0x8000UL) + + +/* + * The partition id is encapsulated in the MAC address. The following + * define locates the octet the partid is in. + */ +#define XPNET_PARTID_OCTET 1 +#define XPNET_LICENSE_OCTET 2 + + +/* + * Define the XPNET debug device structure that is to be used with dev_dbg(), + * dev_err(), dev_warn(), and dev_info(). + */ +struct device_driver xpnet_dbg_name = { + .name = "xpnet" +}; + +struct device xpnet_dbg_subname = { + .bus_id = {0}, /* set to "" */ + .driver = &xpnet_dbg_name +}; + +struct device *xpnet = &xpnet_dbg_subname; + +/* + * Packet was recevied by XPC and forwarded to us. + */ +static void +xpnet_receive(partid_t partid, int channel, struct xpnet_message *msg) +{ + struct sk_buff *skb; + bte_result_t bret; + struct xpnet_dev_private *priv = + (struct xpnet_dev_private *) xpnet_device->priv; + + + if (!XPNET_VALID_MSG(msg)) { + /* + * Packet with a different XPC version. Ignore. + */ + xpc_received(partid, channel, (void *) msg); + + priv->stats.rx_errors++; + + return; + } + dev_dbg(xpnet, "received 0x%lx, %d, %d, %d\n", msg->buf_pa, msg->size, + msg->leadin_ignore, msg->tailout_ignore); + + + /* reserve an extra cache line */ + skb = dev_alloc_skb(msg->size + L1_CACHE_BYTES); + if (!skb) { + dev_err(xpnet, "failed on dev_alloc_skb(%d)\n", + msg->size + L1_CACHE_BYTES); + + xpc_received(partid, channel, (void *) msg); + + priv->stats.rx_errors++; + + return; + } + + /* + * The allocated skb has some reserved space. + * In order to use bte_copy, we need to get the + * skb->data pointer moved forward. + */ + skb_reserve(skb, (L1_CACHE_BYTES - ((u64)skb->data & + (L1_CACHE_BYTES - 1)) + + msg->leadin_ignore)); + + /* + * Update the tail pointer to indicate data actually + * transferred. + */ + skb_put(skb, (msg->size - msg->leadin_ignore - msg->tailout_ignore)); + + /* + * Move the data over from the the other side. + */ + if ((XPNET_VERSION_MINOR(msg->version) == 1) && + (msg->embedded_bytes != 0)) { + dev_dbg(xpnet, "copying embedded message. memcpy(0x%p, 0x%p, " + "%lu)\n", skb->data, &msg->data, + (size_t) msg->embedded_bytes); + + memcpy(skb->data, &msg->data, (size_t) msg->embedded_bytes); + } else { + dev_dbg(xpnet, "transferring buffer to the skb->data area;\n\t" + "bte_copy(0x%p, 0x%p, %hu)\n", (void *)msg->buf_pa, + (void *)__pa((u64)skb->data & ~(L1_CACHE_BYTES - 1)), + msg->size); + + bret = bte_copy(msg->buf_pa, + __pa((u64)skb->data & ~(L1_CACHE_BYTES - 1)), + msg->size, (BTE_NOTIFY | BTE_WACQUIRE), NULL); + + if (bret != BTE_SUCCESS) { + // >>> Need better way of cleaning skb. Currently skb + // >>> appears in_use and we can't just call + // >>> dev_kfree_skb. + dev_err(xpnet, "bte_copy(0x%p, 0x%p, 0x%hx) returned " + "error=0x%x\n", (void *)msg->buf_pa, + (void *)__pa((u64)skb->data & + ~(L1_CACHE_BYTES - 1)), + msg->size, bret); + + xpc_received(partid, channel, (void *) msg); + + priv->stats.rx_errors++; + + return; + } + } + + dev_dbg(xpnet, "head=0x%p skb->data=0x%p skb->tail=0x%p " + "skb->end=0x%p skb->len=%d\n", (void *) skb->head, + (void *) skb->data, (void *) skb->tail, (void *) skb->end, + skb->len); + + skb->dev = xpnet_device; + skb->protocol = eth_type_trans(skb, xpnet_device); + skb->ip_summed = CHECKSUM_UNNECESSARY; + + dev_dbg(xpnet, "passing skb to network layer; \n\tskb->head=0x%p " + "skb->data=0x%p skb->tail=0x%p skb->end=0x%p skb->len=%d\n", + (void *) skb->head, (void *) skb->data, (void *) skb->tail, + (void *) skb->end, skb->len); + + + priv->stats.rx_packets++; + priv->stats.rx_bytes += skb->len + ETH_HLEN; + + netif_rx_ni(skb); + xpc_received(partid, channel, (void *) msg); +} + + +/* + * This is the handler which XPC calls during any sort of change in + * state or message reception on a connection. + */ +static void +xpnet_connection_activity(enum xpc_retval reason, partid_t partid, int channel, + void *data, void *key) +{ + long bp; + + + DBUG_ON(partid <= 0 || partid >= XP_MAX_PARTITIONS); + DBUG_ON(channel != XPC_NET_CHANNEL); + + switch(reason) { + case xpcMsgReceived: /* message received */ + DBUG_ON(data == NULL); + + xpnet_receive(partid, channel, (struct xpnet_message *) data); + break; + + case xpcConnected: /* connection completed to a partition */ + spin_lock_bh(&xpnet_broadcast_lock); + xpnet_broadcast_partitions |= 1UL << (partid -1 ); + bp = xpnet_broadcast_partitions; + spin_unlock_bh(&xpnet_broadcast_lock); + + netif_carrier_on(xpnet_device); + + dev_dbg(xpnet, "%s connection created to partition %d; " + "xpnet_broadcast_partitions=0x%lx\n", + xpnet_device->name, partid, bp); + break; + + default: + spin_lock_bh(&xpnet_broadcast_lock); + xpnet_broadcast_partitions &= ~(1UL << (partid -1 )); + bp = xpnet_broadcast_partitions; + spin_unlock_bh(&xpnet_broadcast_lock); + + if (bp == 0) { + netif_carrier_off(xpnet_device); + } + + dev_dbg(xpnet, "%s disconnected from partition %d; " + "xpnet_broadcast_partitions=0x%lx\n", + xpnet_device->name, partid, bp); + break; + + } +} + + +static int +xpnet_dev_open(struct net_device *dev) +{ + enum xpc_retval ret; + + + dev_dbg(xpnet, "calling xpc_connect(%d, 0x%p, NULL, %ld, %ld, %d, " + "%d)\n", XPC_NET_CHANNEL, xpnet_connection_activity, + XPNET_MSG_SIZE, XPNET_MSG_NENTRIES, XPNET_MAX_KTHREADS, + XPNET_MAX_IDLE_KTHREADS); + + ret = xpc_connect(XPC_NET_CHANNEL, xpnet_connection_activity, NULL, + XPNET_MSG_SIZE, XPNET_MSG_NENTRIES, + XPNET_MAX_KTHREADS, XPNET_MAX_IDLE_KTHREADS); + if (ret != xpcSuccess) { + dev_err(xpnet, "ifconfig up of %s failed on XPC connect, " + "ret=%d\n", dev->name, ret); + + return -ENOMEM; + } + + dev_dbg(xpnet, "ifconfig up of %s; XPC connected\n", dev->name); + + return 0; +} + + +static int +xpnet_dev_stop(struct net_device *dev) +{ + xpc_disconnect(XPC_NET_CHANNEL); + + dev_dbg(xpnet, "ifconfig down of %s; XPC disconnected\n", dev->name); + + return 0; +} + + +static int +xpnet_dev_change_mtu(struct net_device *dev, int new_mtu) +{ + /* 68 comes from min TCP+IP+MAC header */ + if ((new_mtu < 68) || (new_mtu > XPNET_MAX_MTU)) { + dev_err(xpnet, "ifconfig %s mtu %d failed; value must be " + "between 68 and %ld\n", dev->name, new_mtu, + XPNET_MAX_MTU); + return -EINVAL; + } + + dev->mtu = new_mtu; + dev_dbg(xpnet, "ifconfig %s mtu set to %d\n", dev->name, new_mtu); + return 0; +} + + +/* + * Required for the net_device structure. + */ +static int +xpnet_dev_set_config(struct net_device *dev, struct ifmap *new_map) +{ + return 0; +} + + +/* + * Return statistics to the caller. + */ +static struct net_device_stats * +xpnet_dev_get_stats(struct net_device *dev) +{ + struct xpnet_dev_private *priv; + + + priv = (struct xpnet_dev_private *) dev->priv; + + return &priv->stats; +} + + +/* + * Notification that the other end has received the message and + * DMA'd the skb information. At this point, they are done with + * our side. When all recipients are done processing, we + * release the skb and then release our pending message structure. + */ +static void +xpnet_send_completed(enum xpc_retval reason, partid_t partid, int channel, + void *__qm) +{ + struct xpnet_pending_msg *queued_msg = + (struct xpnet_pending_msg *) __qm; + + + DBUG_ON(queued_msg == NULL); + + dev_dbg(xpnet, "message to %d notified with reason %d\n", + partid, reason); + + if (atomic_dec_return(&queued_msg->use_count) == 0) { + dev_dbg(xpnet, "all acks for skb->head=-x%p\n", + (void *) queued_msg->skb->head); + + dev_kfree_skb_any(queued_msg->skb); + kfree(queued_msg); + } +} + + +/* + * Network layer has formatted a packet (skb) and is ready to place it + * "on the wire". Prepare and send an xpnet_message to all partitions + * which have connected with us and are targets of this packet. + * + * MAC-NOTE: For the XPNET driver, the MAC address contains the + * destination partition_id. If the destination partition id word + * is 0xff, this packet is to broadcast to all partitions. + */ +static int +xpnet_dev_hard_start_xmit(struct sk_buff *skb, struct net_device *dev) +{ + struct xpnet_pending_msg *queued_msg; + enum xpc_retval ret; + struct xpnet_message *msg; + u64 start_addr, end_addr; + long dp; + u8 second_mac_octet; + partid_t dest_partid; + struct xpnet_dev_private *priv; + u16 embedded_bytes; + + + priv = (struct xpnet_dev_private *) dev->priv; + + + dev_dbg(xpnet, ">skb->head=0x%p skb->data=0x%p skb->tail=0x%p " + "skb->end=0x%p skb->len=%d\n", (void *) skb->head, + (void *) skb->data, (void *) skb->tail, (void *) skb->end, + skb->len); + + + /* + * The xpnet_pending_msg tracks how many outstanding + * xpc_send_notifies are relying on this skb. When none + * remain, release the skb. + */ + queued_msg = kmalloc(sizeof(struct xpnet_pending_msg), GFP_ATOMIC); + if (queued_msg == NULL) { + dev_warn(xpnet, "failed to kmalloc %ld bytes; dropping " + "packet\n", sizeof(struct xpnet_pending_msg)); + + priv->stats.tx_errors++; + + return -ENOMEM; + } + + + /* get the beginning of the first cacheline and end of last */ + start_addr = ((u64) skb->data & ~(L1_CACHE_BYTES - 1)); + end_addr = L1_CACHE_ALIGN((u64) skb->tail); + + /* calculate how many bytes to embed in the XPC message */ + embedded_bytes = 0; + if (unlikely(skb->len <= XPNET_MSG_DATA_MAX)) { + /* skb->data does fit so embed */ + embedded_bytes = skb->len; + } + + + /* + * Since the send occurs asynchronously, we set the count to one + * and begin sending. Any sends that happen to complete before + * we are done sending will not free the skb. We will be left + * with that task during exit. This also handles the case of + * a packet destined for a partition which is no longer up. + */ + atomic_set(&queued_msg->use_count, 1); + queued_msg->skb = skb; + + + second_mac_octet = skb->data[XPNET_PARTID_OCTET]; + if (second_mac_octet == 0xff) { + /* we are being asked to broadcast to all partitions */ + dp = xpnet_broadcast_partitions; + } else if (second_mac_octet != 0) { + dp = xpnet_broadcast_partitions & + (1UL << (second_mac_octet - 1)); + } else { + /* 0 is an invalid partid. Ignore */ + dp = 0; + } + dev_dbg(xpnet, "destination Partitions mask (dp) = 0x%lx\n", dp); + + /* + * If we wanted to allow promiscous mode to work like an + * unswitched network, this would be a good point to OR in a + * mask of partitions which should be receiving all packets. + */ + + /* + * Main send loop. + */ + for (dest_partid = 1; dp && dest_partid < XP_MAX_PARTITIONS; + dest_partid++) { + + + if (!(dp & (1UL << (dest_partid - 1)))) { + /* not destined for this partition */ + continue; + } + + /* remove this partition from the destinations mask */ + dp &= ~(1UL << (dest_partid - 1)); + + + /* found a partition to send to */ + + ret = xpc_allocate(dest_partid, XPC_NET_CHANNEL, + XPC_NOWAIT, (void **)&msg); + if (unlikely(ret != xpcSuccess)) { + continue; + } + + msg->embedded_bytes = embedded_bytes; + if (unlikely(embedded_bytes != 0)) { + msg->version = XPNET_VERSION_EMBED; + dev_dbg(xpnet, "calling memcpy(0x%p, 0x%p, 0x%lx)\n", + &msg->data, skb->data, (size_t) embedded_bytes); + memcpy(&msg->data, skb->data, (size_t) embedded_bytes); + } else { + msg->version = XPNET_VERSION; + } + msg->magic = XPNET_MAGIC; + msg->size = end_addr - start_addr; + msg->leadin_ignore = (u64) skb->data - start_addr; + msg->tailout_ignore = end_addr - (u64) skb->tail; + msg->buf_pa = __pa(start_addr); + + dev_dbg(xpnet, "sending XPC message to %d:%d\nmsg->buf_pa=" + "0x%lx, msg->size=%u, msg->leadin_ignore=%u, " + "msg->tailout_ignore=%u\n", dest_partid, + XPC_NET_CHANNEL, msg->buf_pa, msg->size, + msg->leadin_ignore, msg->tailout_ignore); + + + atomic_inc(&queued_msg->use_count); + + ret = xpc_send_notify(dest_partid, XPC_NET_CHANNEL, msg, + xpnet_send_completed, queued_msg); + if (unlikely(ret != xpcSuccess)) { + atomic_dec(&queued_msg->use_count); + continue; + } + + } + + if (atomic_dec_return(&queued_msg->use_count) == 0) { + dev_dbg(xpnet, "no partitions to receive packet destined for " + "%d\n", dest_partid); + + + dev_kfree_skb(skb); + kfree(queued_msg); + } + + priv->stats.tx_packets++; + priv->stats.tx_bytes += skb->len; + + return 0; +} + + +/* + * Deal with transmit timeouts coming from the network layer. + */ +static void +xpnet_dev_tx_timeout (struct net_device *dev) +{ + struct xpnet_dev_private *priv; + + + priv = (struct xpnet_dev_private *) dev->priv; + + priv->stats.tx_errors++; + return; +} + + +static int __init +xpnet_init(void) +{ + int i; + u32 license_num; + int result = -ENOMEM; + + + dev_info(xpnet, "registering network device %s\n", XPNET_DEVICE_NAME); + + /* + * use ether_setup() to init the majority of our device + * structure and then override the necessary pieces. + */ + xpnet_device = alloc_netdev(sizeof(struct xpnet_dev_private), + XPNET_DEVICE_NAME, ether_setup); + if (xpnet_device == NULL) { + return -ENOMEM; + } + + netif_carrier_off(xpnet_device); + + xpnet_device->mtu = XPNET_DEF_MTU; + xpnet_device->change_mtu = xpnet_dev_change_mtu; + xpnet_device->open = xpnet_dev_open; + xpnet_device->get_stats = xpnet_dev_get_stats; + xpnet_device->stop = xpnet_dev_stop; + xpnet_device->hard_start_xmit = xpnet_dev_hard_start_xmit; + xpnet_device->tx_timeout = xpnet_dev_tx_timeout; + xpnet_device->set_config = xpnet_dev_set_config; + + /* + * Multicast assumes the LSB of the first octet is set for multicast + * MAC addresses. We chose the first octet of the MAC to be unlikely + * to collide with any vendor's officially issued MAC. + */ + xpnet_device->dev_addr[0] = 0xfe; + xpnet_device->dev_addr[XPNET_PARTID_OCTET] = sn_partition_id; + license_num = sn_partition_serial_number_val(); + for (i = 3; i >= 0; i--) { + xpnet_device->dev_addr[XPNET_LICENSE_OCTET + i] = + license_num & 0xff; + license_num = license_num >> 8; + } + + /* + * ether_setup() sets this to a multicast device. We are + * really not supporting multicast at this time. + */ + xpnet_device->flags &= ~IFF_MULTICAST; + + /* + * No need to checksum as it is a DMA transfer. The BTE will + * report an error if the data is not retrievable and the + * packet will be dropped. + */ + xpnet_device->features = NETIF_F_NO_CSUM | NETIF_F_HIGHDMA; + + result = register_netdev(xpnet_device); + if (result != 0) { + free_netdev(xpnet_device); + } + + return result; +} +module_init(xpnet_init); + + +static void __exit +xpnet_exit(void) +{ + dev_info(xpnet, "unregistering network device %s\n", + xpnet_device[0].name); + + unregister_netdev(xpnet_device); + + free_netdev(xpnet_device); +} +module_exit(xpnet_exit); + + +MODULE_AUTHOR("Silicon Graphics, Inc."); +MODULE_DESCRIPTION("Cross Partition Network adapter (XPNET)"); +MODULE_LICENSE("GPL"); + Index: linux-2.6/arch/ia64/sn/kernel/Makefile =================================================================== --- linux-2.6.orig/arch/ia64/sn/kernel/Makefile 2005-03-10 08:02:31.943325829 -0600 +++ linux-2.6/arch/ia64/sn/kernel/Makefile 2005-03-10 08:07:46.580825194 -0600 @@ -14,3 +14,4 @@ xp-y := xp_main.o xp_nofault.o obj-$(CONFIG_IA64_SGI_SN_XP) += xpc.o xpc-y := xpc_main.o xpc_channel.o xpc_partition.o +obj-$(CONFIG_IA64_SGI_SN_XP) += xpnet.o From davem@davemloft.net Wed Mar 23 12:02:57 2005 Received: with ECARTIS (v1.0.0; list netdev); Wed, 23 Mar 2005 12:03:02 -0800 (PST) Received: from cheetah.davemloft.net (mail@dsl027-180-174.sfo1.dsl.speakeasy.net [216.27.180.174]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j2NK2uIV031335 for ; Wed, 23 Mar 2005 12:02:56 -0800 Received: from localhost ([127.0.0.1] helo=cheetah.davemloft.net ident=davem) by cheetah.davemloft.net with smtp (Exim 3.36 #1 (Debian)) id 1DEC40-0008VX-00; Wed, 23 Mar 2005 12:02:48 -0800 Date: Wed, 23 Mar 2005 12:02:48 -0800 From: "David S. Miller" To: Dean Nelson Cc: tony.luck@intel.com, netdev@oss.sgi.com, linux-ia64@vger.kernel.org Subject: Re: [PATCH 3/3] SGI Altix cross partition functionality (2nd revision) Message-Id: <20050323120248.03755d6b.davem@davemloft.net> In-Reply-To: <20050323195139.GC21418@sgi.com> References: <4241C391.mailxHNA15A8V0@aqua.americas.sgi.com> <20050323195139.GC21418@sgi.com> X-Mailer: Sylpheed version 1.0.3 (GTK+ 1.2.10; sparc-unknown-linux-gnu) X-Face: "_;p5u5aPsO,_Vsx"^v-pEq09'CU4&Dc1$fQExov$62l60cgCc%FnIwD=.UF^a>?5'9Kn[;433QFVV9M..2eN.@4ZWPGbdi<=?[:T>y?SD(R*-3It"Vj:)"dP Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV 0.83/781/Wed Mar 23 03:58:42 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 599 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: davem@davemloft.net Precedence: bulk X-list: netdev Content-Length: 636 Lines: 18 On Wed, 23 Mar 2005 13:51:39 -0600 Dean Nelson wrote: > This patch contains the cross partition pseudo-ethernet driver (XPNET) > functional support module. > > Signed-off-by: Dean Nelson Only a NIT or two. You should be setting the last_rx value. Also, NETIF_F_HIGHDMA is pointless unless you support NETIF_F_SG and thus paged SKBs. skb->data will never be placed in high memory, only non-linear SKB scatterlist pages will. I should probably add a debugging check at device registration time, like we already do to make sure NETIF_F_SG is not set unless some checksumming capability is there as well. From davem@davemloft.net Wed Mar 23 12:20:15 2005 Received: with ECARTIS (v1.0.0; list netdev); Wed, 23 Mar 2005 12:20:20 -0800 (PST) Received: from cheetah.davemloft.net (mail@dsl027-180-174.sfo1.dsl.speakeasy.net [216.27.180.174]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j2NKKF0P003768 for ; Wed, 23 Mar 2005 12:20:15 -0800 Received: from localhost ([127.0.0.1] helo=cheetah.davemloft.net ident=davem) by cheetah.davemloft.net with smtp (Exim 3.36 #1 (Debian)) id 1DECKg-0000CJ-00; Wed, 23 Mar 2005 12:20:02 -0800 Date: Wed, 23 Mar 2005 12:20:02 -0800 From: "David S. Miller" To: Herbert Xu Cc: netdev@oss.sgi.com Subject: Re: [IPV4] Check mtu instead of frag_list in ip_push_pending_frames Message-Id: <20050323122002.04fc046e.davem@davemloft.net> In-Reply-To: <20050321105622.GA23809@gondor.apana.org.au> References: <20050321105622.GA23809@gondor.apana.org.au> X-Mailer: Sylpheed version 1.0.3 (GTK+ 1.2.10; sparc-unknown-linux-gnu) X-Face: "_;p5u5aPsO,_Vsx"^v-pEq09'CU4&Dc1$fQExov$62l60cgCc%FnIwD=.UF^a>?5'9Kn[;433QFVV9M..2eN.@4ZWPGbdi<=?[:T>y?SD(R*-3It"Vj:)"dP Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV 0.83/781/Wed Mar 23 03:58:42 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 600 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: davem@davemloft.net Precedence: bulk X-list: netdev Content-Length: 312 Lines: 10 On Mon, 21 Mar 2005 21:56:22 +1100 Herbert Xu wrote: > The fix is similar to what we did in ip_output. Instead of checking > whether frag_list is empty, we check the condition skb->len <= dst_mtu > directly and set the DF bit based on that. Looks good, applied. Thanks Herbert. From davem@davemloft.net Wed Mar 23 12:21:07 2005 Received: with ECARTIS (v1.0.0; list netdev); Wed, 23 Mar 2005 12:21:11 -0800 (PST) Received: from cheetah.davemloft.net (mail@dsl027-180-174.sfo1.dsl.speakeasy.net [216.27.180.174]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j2NKL6cv003876 for ; Wed, 23 Mar 2005 12:21:06 -0800 Received: from localhost ([127.0.0.1] helo=cheetah.davemloft.net ident=davem) by cheetah.davemloft.net with smtp (Exim 3.36 #1 (Debian)) id 1DECLW-0000CX-00; Wed, 23 Mar 2005 12:20:54 -0800 Date: Wed, 23 Mar 2005 12:20:54 -0800 From: "David S. Miller" To: Herbert Xu Cc: netdev@oss.sgi.com Subject: Re: [IPV4] Clear DF bit in ip_fragment fast path Message-Id: <20050323122054.4603c3c9.davem@davemloft.net> In-Reply-To: <20050321111637.GA24617@gondor.apana.org.au> References: <20050321105622.GA23809@gondor.apana.org.au> <20050321111637.GA24617@gondor.apana.org.au> X-Mailer: Sylpheed version 1.0.3 (GTK+ 1.2.10; sparc-unknown-linux-gnu) X-Face: "_;p5u5aPsO,_Vsx"^v-pEq09'CU4&Dc1$fQExov$62l60cgCc%FnIwD=.UF^a>?5'9Kn[;433QFVV9M..2eN.@4ZWPGbdi<=?[:T>y?SD(R*-3It"Vj:)"dP Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV 0.83/781/Wed Mar 23 03:58:42 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 601 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: davem@davemloft.net Precedence: bulk X-list: netdev Content-Length: 558 Lines: 15 On Mon, 21 Mar 2005 22:16:37 +1100 Herbert Xu wrote: > It is possible for ip_fragment() to send out head fragments with > both DF and MF set for packets with local_df set to true. This is > because the fast path tries to only modify the MF bit of the head > fragment. > > Since the offset is always zero for the head fragment, and we know > that DF should be cleared in case of local_df, we can change |= to > a straight assignment. > > Signed-off-by: Herbert Xu Also applied, thanks Herbert. From vicente.feito@gmail.com Wed Mar 23 12:36:43 2005 Received: with ECARTIS (v1.0.0; list netdev); Wed, 23 Mar 2005 12:36:48 -0800 (PST) Received: from rproxy.gmail.com (rproxy.gmail.com [64.233.170.203]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j2NKag5a005807 for ; Wed, 23 Mar 2005 12:36:43 -0800 Received: by rproxy.gmail.com with SMTP id c51so262600rne for ; Wed, 23 Mar 2005 12:36:42 -0800 (PST) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:from:organization:subject:date:user-agent:to:cc:mime-version:content-type:message-id; b=X2dTZXNupZlWUDFsz3YJLS2QnW7kjhGTBo4qpNBaS/luXHM3ioOJb0obLPWf3TzEwMuDZH5fa0QivTluU/XE8il+r+sytMeZtPnEVlzs3pVy36IfHfLbIGJOvF9g6/GDpCLD/hxxej2pDtpqYwMh44CTLBw1Nd29kTdRkCr7ZGk= Received: by 10.38.150.65 with SMTP id x65mr896357rnd; Wed, 23 Mar 2005 12:36:41 -0800 (PST) Received: from ramanujan.playing.org ([209.13.213.239]) by mx.gmail.com with ESMTP id k6sm98468rnd.2005.03.23.12.36.30; Wed, 23 Mar 2005 12:36:38 -0800 (PST) From: Vicente Feito Organization: none Subject: [PATCH 2.6.12-rc1-mm1] net/ethernet/eth.c - eth_header Date: Wed, 23 Mar 2005 17:34:58 +0000 User-Agent: KMail/1.7.1 To: "David S. Miller" Cc: netdev@oss.sgi.com MIME-Version: 1.0 Content-Type: Multipart/Mixed; boundary="Boundary-00=_DjaQCQ2KX9Rm9+v" Message-Id: <200503231734.59277.vicente.feito@gmail.com> X-Virus-Scanned: ClamAV 0.83/781/Wed Mar 23 03:58:42 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 602 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: vicente.feito@gmail.com Precedence: bulk X-list: netdev Content-Length: 1198 Lines: 37 --Boundary-00=_DjaQCQ2KX9Rm9+v Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Hi, Please consider applying (or droping). Thank you. Description: This patch prevent drivers from calling eth_header with a 802.3 frame using a len>1536. In such a case returns -EINVAL, which was hard to choose because the ETH_HLEN is supposed to return. Signed-off-by: Vicente Feito --Boundary-00=_DjaQCQ2KX9Rm9+v Content-Type: text/x-diff; charset="iso-8859-1"; name="eth.patch" Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="eth.patch" --- linux-2.6.12-rc1-mm1/net/ethernet/eth.c.orig 2005-03-22 12:49:08.000000000 +0000 +++ linux-2.6.12-rc1-mm1/net/ethernet/eth.c 2005-03-22 12:49:36.000000000 +0000 @@ -78,6 +78,8 @@ int eth_header(struct sk_buff *skb, stru { struct ethhdr *eth = (struct ethhdr *)skb_push(skb,ETH_HLEN); + if (type == ETH_P_802_3 && len >= 1536) + return -EINVAL; /* * Set the protocol type. For a packet of type ETH_P_802_3 we put the length * in here instead. It is up to the 802.2 layer to carry protocol information. --Boundary-00=_DjaQCQ2KX9Rm9+v-- From herbert@gondor.apana.org.au Wed Mar 23 12:38:43 2005 Received: with ECARTIS (v1.0.0; list netdev); Wed, 23 Mar 2005 12:38:52 -0800 (PST) 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 j2NKcgHb006125 for ; Wed, 23 Mar 2005 12:38:43 -0800 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 1DECcP-0008Cf-00; Thu, 24 Mar 2005 07:38:21 +1100 Received: from herbert by gondolin.me.apana.org.au with local (Exim 3.36 #1 (Debian)) id 1DECbG-0002BL-00; Thu, 24 Mar 2005 07:37:10 +1100 Date: Thu, 24 Mar 2005 07:37:10 +1100 To: Yichen Xie Cc: linux-kernel@vger.kernel.org, netdev@oss.sgi.com, davem@davemloft.net, kaber@trash.net, hadi@cyberus.ca Subject: Re: memory leak in net/sched/ipt.c? Message-ID: <20050323203710.GC8249@gondor.apana.org.au> References: <200503231827.j2NIRWNR004495@smtp-roam.Stanford.EDU> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200503231827.j2NIRWNR004495@smtp-roam.Stanford.EDU> User-Agent: Mutt/1.5.6+20040907i From: Herbert Xu X-Virus-Scanned: ClamAV 0.83/781/Wed Mar 23 03:58:42 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 603 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: herbert@gondor.apana.org.au Precedence: bulk X-list: netdev Content-Length: 490 Lines: 12 On Wed, Mar 23, 2005 at 10:27:32AM -0800, Yichen Xie wrote: > Thanks for confirming. Are you guys interested in this kind of leaks? I have > a list of about a hundred generated by our tool. -yichen Certainly. Please post all the networking leaks to netdev@oss.sgi.com. 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 jgarzik@pobox.com Wed Mar 23 12:50:43 2005 Received: with ECARTIS (v1.0.0; list netdev); Wed, 23 Mar 2005 12:50:47 -0800 (PST) Received: from parcelfarce.linux.theplanet.co.uk (IDENT:93@parcelfarce.linux.theplanet.co.uk [195.92.249.252]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j2NKogkk007481 for ; Wed, 23 Mar 2005 12:50:42 -0800 Received: from cpe-069-134-152-124.nc.rr.com ([69.134.152.124] helo=[10.10.10.88]) by parcelfarce.linux.theplanet.co.uk with asmtp (TLSv1:AES256-SHA:256) (Exim 4.33) id 1DECoK-0007Zc-Gi; Wed, 23 Mar 2005 20:50:40 +0000 Message-ID: <4241D691.5000707@pobox.com> Date: Wed, 23 Mar 2005 15:50:25 -0500 From: Jeff Garzik User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.3) Gecko/20040922 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Vicente Feito CC: "David S. Miller" , netdev@oss.sgi.com Subject: Re: [PATCH 2.6.12-rc1-mm1] net/ethernet/eth.c - eth_header References: <200503231734.59277.vicente.feito@gmail.com> In-Reply-To: <200503231734.59277.vicente.feito@gmail.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV 0.83/781/Wed Mar 23 03:58:42 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 604 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: jgarzik@pobox.com Precedence: bulk X-list: netdev Content-Length: 858 Lines: 29 Vicente Feito wrote: > Hi, > Please consider applying (or droping). > Thank you. > > Description: This patch prevent drivers from calling eth_header with a 802.3 > frame using a len>1536. In such a case returns -EINVAL, which was hard to > choose because the ETH_HLEN is supposed to return. > > Signed-off-by: Vicente Feito > > > ------------------------------------------------------------------------ > > --- linux-2.6.12-rc1-mm1/net/ethernet/eth.c.orig 2005-03-22 12:49:08.000000000 +0000 > +++ linux-2.6.12-rc1-mm1/net/ethernet/eth.c 2005-03-22 12:49:36.000000000 +0000 > @@ -78,6 +78,8 @@ int eth_header(struct sk_buff *skb, stru > { > struct ethhdr *eth = (struct ethhdr *)skb_push(skb,ETH_HLEN); > > + if (type == ETH_P_802_3 && len >= 1536) > + return -EINVAL; Why? Won't this break for jumbo frames? Jeff From jdmason@us.ibm.com Wed Mar 23 12:52:37 2005 Received: with ECARTIS (v1.0.0; list netdev); Wed, 23 Mar 2005 12:52:41 -0800 (PST) Received: from e33.co.us.ibm.com (e33.co.us.ibm.com [32.97.110.131]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j2NKqaPY007831 for ; Wed, 23 Mar 2005 12:52:36 -0800 Received: from westrelay01.boulder.ibm.com (westrelay01.boulder.ibm.com [9.17.195.10]) by e33.co.us.ibm.com (8.12.10/8.12.9) with ESMTP id j2NKqU4I635202 for ; Wed, 23 Mar 2005 15:52:30 -0500 Received: from d03av01.boulder.ibm.com (d03av01.boulder.ibm.com [9.17.195.167]) by westrelay01.boulder.ibm.com (8.12.10/NCO/VER6.6) with ESMTP id j2NKqUxW184936 for ; Wed, 23 Mar 2005 13:52:30 -0700 Received: from d03av01.boulder.ibm.com (loopback [127.0.0.1]) by d03av01.boulder.ibm.com (8.12.11/8.12.11) with ESMTP id j2NKqTER015048 for ; Wed, 23 Mar 2005 13:52:29 -0700 Received: from dreadnought.austin.ibm.com (dreadnought.austin.ibm.com [9.41.94.123]) by d03av01.boulder.ibm.com (8.12.11/8.12.11) with ESMTP id j2NKqToi015039; Wed, 23 Mar 2005 13:52:29 -0700 From: Jon Mason Organization: IBM To: Vicente Feito Subject: Re: [PATCH 2.6.12-rc1-mm1] net/ethernet/eth.c - eth_header Date: Wed, 23 Mar 2005 14:52:15 -0600 User-Agent: KMail/1.7.2 Cc: "David S. Miller" , netdev@oss.sgi.com References: <200503231734.59277.vicente.feito@gmail.com> In-Reply-To: <200503231734.59277.vicente.feito@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200503231452.15835.jdmason@us.ibm.com> X-Virus-Scanned: ClamAV 0.83/781/Wed Mar 23 03:58:42 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 605 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: jdmason@us.ibm.com Precedence: bulk X-list: netdev Content-Length: 394 Lines: 14 On Wednesday 23 March 2005 11:34 am, Vicente Feito wrote: > Hi, > Please consider applying (or droping). > Thank you. > > Description: This patch prevent drivers from calling eth_header with a > 802.3 frame using a len>1536. In such a case returns -EINVAL, which was > hard to choose because the ETH_HLEN is supposed to return. Won't this break jumbo frames? -- Jon Mason jdmason@us.ibm.com From andy.furniss@dsl.pipex.com Wed Mar 23 12:53:56 2005 Received: with ECARTIS (v1.0.0; list netdev); Wed, 23 Mar 2005 12:54:01 -0800 (PST) Received: from ranger.systems.pipex.net (ranger.systems.pipex.net [62.241.162.32]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j2NKrtb4008273 for ; Wed, 23 Mar 2005 12:53:55 -0800 Received: from [192.168.0.3] (81-178-146-253.dsl.pipex.com [81.178.146.253]) by ranger.systems.pipex.net (Postfix) with ESMTP id 65ADEE0000A1; Wed, 23 Mar 2005 20:53:31 +0000 (GMT) Message-ID: <4241D764.2030306@dsl.pipex.com> Date: Wed, 23 Mar 2005 20:53:56 +0000 From: Andy Furniss User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.8b) Gecko/20050217 MIME-Version: 1.0 To: hadi@cyberus.ca Cc: Harald Welte , Patrick McHardy , Remus , netdev@oss.sgi.com, Nguyen Dinh Nam , Andre Tomt , syrius.ml@no-log.org, Damion de Soto Subject: Re: iptables breakage WAS(Re: dummy as IMQ replacement References: <1107123123.8021.80.camel@jzny.localdomain> <0fcf01c5077f$579e4b80$6e69690a@RIMAS> <1107174142.8021.121.camel@jzny.localdomain> <00c301c524b4$938cd240$6e69690a@RIMAS> <1110379135.1091.143.camel@jzny.localdomain> <1110416767.1111.76.camel@jzny.localdomain> <025501c52552$2dbf87c0$6e69690a@RIMAS> <1110453757.1108.87.camel@jzny.localdomain> <423B7BCB.10400@dsl.pipex.com> <1111410890.1092.195.camel@jzny.localdomain> <423F41AD.3010902@dsl.pipex.com> <1111444869.1072.51.camel@jzny.localdomain> <423F71C2.8040802@dsl.pipex.com> <1111462263.1109.6.camel@jzny.localdomain> <42408998.5000202@dsl.pipex.com> <1111550254.1089.21.camel@jzny.localdomain> <4241C478.5030309@dsl.pipex.com> <1111607112.1072.48.camel@jzny.localdomain> In-Reply-To: <1111607112.1072.48.camel@jzny.localdomain> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV 0.83/781/Wed Mar 23 03:58:42 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 606 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: andy.furniss@dsl.pipex.com Precedence: bulk X-list: netdev Content-Length: 851 Lines: 38 jamal wrote: > > Ok, try the module thing; actually try to modprobe mark target first and > see if that works as well. Looks like they load OK - anyway I rebooted and modprobed ipt and ipt_MARK before test and it still fails - will do new kernel a bit later. > > >>I get exactly the same error if I also add action mirred egress redirect >>dev lo - before I would get different. >> > > > Didnt follow - still related to ipt? When action ipt MARK failed in previous tests and was followed by an action mirred ... I would get an error like ... bad action type mirred ... but I can now follow the action ipt MARK line with an action mirred .. and I just get the MARK error tablename: mangle hook: NF_IP_PRE_ROUTING target: MARK set 0x1 index 0 RTNETLINK answers: Invalid argument We have an error talking to the kernel Andy. From hadi@cyberus.ca Wed Mar 23 13:07:36 2005 Received: with ECARTIS (v1.0.0; list netdev); Wed, 23 Mar 2005 13:07:40 -0800 (PST) Received: from mx01.cybersurf.com (mx01.cybersurf.com [209.197.145.104]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j2NL7ZPv010118 for ; Wed, 23 Mar 2005 13:07:36 -0800 Received: from mail.cyberus.ca ([209.197.145.21]) by mx01.cybersurf.com with esmtp (Exim 4.30) id 1DED4a-0007W0-VK for netdev@oss.sgi.com; Wed, 23 Mar 2005 14:07:28 -0700 Received: from [216.209.86.2] (helo=[10.0.0.9]) by mail.cyberus.ca with esmtp (Exim 4.20) id 1DED4Z-0003Kz-KD; Wed, 23 Mar 2005 16:07:27 -0500 Subject: Re: iptables breakage WAS(Re: dummy as IMQ replacement From: jamal Reply-To: hadi@cyberus.ca To: Andy Furniss Cc: Harald Welte , Patrick McHardy , Remus , netdev@oss.sgi.com, Nguyen Dinh Nam , Andre Tomt , syrius.ml@no-log.org, Damion de Soto In-Reply-To: <4241D764.2030306@dsl.pipex.com> References: <1107123123.8021.80.camel@jzny.localdomain> <0fcf01c5077f$579e4b80$6e69690a@RIMAS> <1107174142.8021.121.camel@jzny.localdomain> <00c301c524b4$938cd240$6e69690a@RIMAS> <1110379135.1091.143.camel@jzny.localdomain> <1110416767.1111.76.camel@jzny.localdomain> <025501c52552$2dbf87c0$6e69690a@RIMAS> <1110453757.1108.87.camel@jzny.localdomain> <423B7BCB.10400@dsl.pipex.com> <1111410890.1092.195.camel@jzny.localdomain> <423F41AD.3010902@dsl.pipex.com> <1111444869.1072.51.camel@jzny.localdomain> <423F71C2.8040802@dsl.pipex.com> <1111462263.1109.6.camel@jzny.localdomain> <42408998.5000202@dsl.pipex.com> <1111550254.1089.21.camel@jzny.localdomain> <4241C478.5030309@dsl.pipex.com> <1111607112.1072.48.camel@jzny.localdomain> <4241D764.2030306@dsl.pipex.com> Content-Type: text/plain Organization: jamalopolous Message-Id: <1111612042.1072.53.camel@jzny.localdomain> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.2.2 Date: 23 Mar 2005 16:07:23 -0500 Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV 0.83/781/Wed Mar 23 03:58:42 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 607 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: hadi@cyberus.ca Precedence: bulk X-list: netdev Content-Length: 487 Lines: 21 On Wed, 2005-03-23 at 15:53, Andy Furniss wrote: > > but I can now follow the action ipt MARK line with an action mirred .. > > and I just get the MARK error > > tablename: mangle hook: NF_IP_PRE_ROUTING > target: MARK set 0x1 index 0 > RTNETLINK answers: Invalid argument > We have an error talking to the kernel > > Ok, this is my worry - that it works when everything is compiled in but not when as modules. So when you rebuild compile everything in. cheers, jamal From vicente.feito@gmail.com Wed Mar 23 13:17:15 2005 Received: with ECARTIS (v1.0.0; list netdev); Wed, 23 Mar 2005 13:17:19 -0800 (PST) Received: from wproxy.gmail.com (wproxy.gmail.com [64.233.184.202]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j2NLHEUF011395 for ; Wed, 23 Mar 2005 13:17:14 -0800 Received: by wproxy.gmail.com with SMTP id 68so293299wra for ; Wed, 23 Mar 2005 13:17:08 -0800 (PST) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:from:organization:to:subject:date:user-agent:cc:references:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:message-id; b=KCoBB4aMV02zJD2hBC+kNhqE9PWkHJ3P7fUeJ0VAzKETDpeRbwZqK8sHofRn+Avp/OuSw6ysGv7B8DQdPDHHoX7+oXffuCcv3jJ0q2Qb23JTk8p9351zWYNz//6x9owoo65WTbMiyn+zf38AK1ORKVZOu6erYad/kSoivQ3ocFw= Received: by 10.54.94.15 with SMTP id r15mr663741wrb; Wed, 23 Mar 2005 13:17:01 -0800 (PST) Received: from ramanujan.playing.org ([209.13.213.239]) by mx.gmail.com with ESMTP id d16sm89378wra.2005.03.23.13.17.00; Wed, 23 Mar 2005 13:17:01 -0800 (PST) From: Vicente Feito Organization: none To: Jeff Garzik Subject: Re: [PATCH 2.6.12-rc1-mm1] net/ethernet/eth.c - eth_header Date: Wed, 23 Mar 2005 18:15:32 +0000 User-Agent: KMail/1.7.1 Cc: netdev@oss.sgi.com References: <200503231734.59277.vicente.feito@gmail.com> <4241D691.5000707@pobox.com> In-Reply-To: <4241D691.5000707@pobox.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200503231815.33162.vicente.feito@gmail.com> X-Virus-Scanned: ClamAV 0.83/781/Wed Mar 23 03:58:42 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 608 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: vicente.feito@gmail.com Precedence: bulk X-list: netdev Content-Length: 1217 Lines: 34 On Wednesday 23 March 2005 08:50 pm, Jeff Garzik wrote: > Vicente Feito wrote: > > Hi, > > Please consider applying (or droping). > > Thank you. > > > > Description: This patch prevent drivers from calling eth_header with a > > 802.3 frame using a len>1536. In such a case returns -EINVAL, which was > > hard to choose because the ETH_HLEN is supposed to return. > > > > Signed-off-by: Vicente Feito > > > > > > ------------------------------------------------------------------------ > > > > --- linux-2.6.12-rc1-mm1/net/ethernet/eth.c.orig 2005-03-22 > > 12:49:08.000000000 +0000 +++ > > linux-2.6.12-rc1-mm1/net/ethernet/eth.c 2005-03-22 12:49:36.000000000 > > +0000 @@ -78,6 +78,8 @@ int eth_header(struct sk_buff *skb, stru > > { > > struct ethhdr *eth = (struct ethhdr *)skb_push(skb,ETH_HLEN); > > > > + if (type == ETH_P_802_3 && len >= 1536) > > + return -EINVAL; > > Why? Won't this break for jumbo frames? > > Jeff True, I completely forgot about it, I was having problems with a driver and I though this would be a correct approach for size violation avoidance, but I guess it doesn't have much sense to change len >= 1536 by the 9000 of a jumbo packet, sorry. Vicente From jdmason@us.ibm.com Wed Mar 23 13:25:42 2005 Received: with ECARTIS (v1.0.0; list netdev); Wed, 23 Mar 2005 13:25:46 -0800 (PST) Received: from e33.co.us.ibm.com (e33.co.us.ibm.com [32.97.110.131]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j2NLPfB3012451 for ; Wed, 23 Mar 2005 13:25:41 -0800 Received: from westrelay01.boulder.ibm.com (westrelay01.boulder.ibm.com [9.17.195.10]) by e33.co.us.ibm.com (8.12.10/8.12.9) with ESMTP id j2NLPZ4I326770 for ; Wed, 23 Mar 2005 16:25:35 -0500 Received: from d03av01.boulder.ibm.com (d03av01.boulder.ibm.com [9.17.195.167]) by westrelay01.boulder.ibm.com (8.12.10/NCO/VER6.6) with ESMTP id j2NLPYxW180092 for ; Wed, 23 Mar 2005 14:25:34 -0700 Received: from d03av01.boulder.ibm.com (loopback [127.0.0.1]) by d03av01.boulder.ibm.com (8.12.11/8.12.11) with ESMTP id j2NLPY86000891 for ; Wed, 23 Mar 2005 14:25:34 -0700 Received: from dreadnought.austin.ibm.com (dreadnought.austin.ibm.com [9.41.94.123]) by d03av01.boulder.ibm.com (8.12.11/8.12.11) with ESMTP id j2NLPYE6000866; Wed, 23 Mar 2005 14:25:34 -0700 From: Jon Mason Organization: IBM To: Vicente Feito Subject: Re: [PATCH 2.6.12-rc1-mm1] net/ethernet/eth.c - eth_header Date: Wed, 23 Mar 2005 15:25:18 -0600 User-Agent: KMail/1.7.2 Cc: Jeff Garzik , netdev@oss.sgi.com References: <200503231734.59277.vicente.feito@gmail.com> <4241D691.5000707@pobox.com> <200503231815.33162.vicente.feito@gmail.com> In-Reply-To: <200503231815.33162.vicente.feito@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200503231525.18110.jdmason@us.ibm.com> X-Virus-Scanned: ClamAV 0.83/781/Wed Mar 23 03:58:42 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 609 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: jdmason@us.ibm.com Precedence: bulk X-list: netdev Content-Length: 1400 Lines: 41 On Wednesday 23 March 2005 12:15 pm, Vicente Feito wrote: > On Wednesday 23 March 2005 08:50 pm, Jeff Garzik wrote: > > Vicente Feito wrote: > > > Hi, > > > Please consider applying (or droping). > > > Thank you. > > > > > > Description: This patch prevent drivers from calling eth_header with a > > > 802.3 frame using a len>1536. In such a case returns -EINVAL, which was > > > hard to choose because the ETH_HLEN is supposed to return. > > > > > > Signed-off-by: Vicente Feito > > > > > > > > > ----------------------------------------------------------------------- > > >- > > > > > > --- linux-2.6.12-rc1-mm1/net/ethernet/eth.c.orig 2005-03-22 > > > 12:49:08.000000000 +0000 +++ > > > linux-2.6.12-rc1-mm1/net/ethernet/eth.c 2005-03-22 12:49:36.000000000 > > > +0000 @@ -78,6 +78,8 @@ int eth_header(struct sk_buff *skb, stru > > > { > > > struct ethhdr *eth = (struct ethhdr *)skb_push(skb,ETH_HLEN); > > > > > > + if (type == ETH_P_802_3 && len >= 1536) > > > + return -EINVAL; > > > > Why? Won't this break for jumbo frames? > > > > Jeff > > True, I completely forgot about it, I was having problems with a driver and > I though this would be a correct approach for size violation avoidance, but > I guess it doesn't have much sense to change len >= 1536 by the 9000 of a > jumbo packet, sorry. Jumbo Frames can be upto 16k. -- Jon Mason jdmason@us.ibm.com From vkondra@mail.ru Wed Mar 23 14:10:17 2005 Received: with ECARTIS (v1.0.0; list netdev); Wed, 23 Mar 2005 14:10:22 -0800 (PST) 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 j2NMAGMZ015029 for ; Wed, 23 Mar 2005 14:10:16 -0800 Received: from [81.218.127.162] (port=40880 helo=[192.168.10.2]) by mx2.mail.ru with esmtp id 1DEE3G-000PuM-00; Thu, 24 Mar 2005 01:10:12 +0300 From: Vladimir Kondratiev To: Jeff Garzik Subject: Re: wireless 2.6 work Date: Thu, 24 Mar 2005 00:07:02 +0200 User-Agent: KMail/1.7 Cc: "Luis R. Rodriguez" , Netdev , Dan Williams , Linux Kernel , James Ketrenos References: <20050310025036.GE17854@ruslug.rutgers.edu> <4240D158.1060302@pobox.com> In-Reply-To: <4240D158.1060302@pobox.com> MIME-Version: 1.0 Content-Type: multipart/signed; boundary="nextPart9429505.gCS1A5zDSB"; protocol="application/pgp-signature"; micalg=pgp-sha1 Content-Transfer-Encoding: 7bit Message-Id: <200503240007.11954.vkondra@mail.ru> X-Spam: Not detected X-Virus-Scanned: ClamAV 0.83/781/Wed Mar 23 03:58:42 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 610 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: vkondra@mail.ru Precedence: bulk X-list: netdev Content-Length: 3362 Lines: 92 --nextPart9429505.gCS1A5zDSB Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline I did posted once; it was long time ago. I am sure I sent it to Dave. I can= =20 resend if needed. Basically, I made Dave's stack work on 2.6 kernels; did=20 some changes toward QoS and provided simple utility to imitate low level=20 driver. I was concentrated on interfaces, it is still just skeleton. I did not touched this work since then. I used to do stuff very close to=20 802.11 stack. Now I am very busy with some different work. I can however consult on any 802.11 standard issues, QoS in particular. Maybe, it is good idea to talk to James Ketrenos as well. Last time I saw h= im=20 doing good work on .11 stack. Vladimir On Wednesday 23 March 2005 04:15, Jeff Garzik wrote: JG> Luis R. Rodriguez wrote: JG> > Jeff, JG> > JG> > I'm sick off the low activity and slow support on wireless we have. I JG> > know you're busy so I wanted to offer my help in helping around work = on JG> > wireless-2.6, now that I have time after work, and before I commit JG> > myself to anything else. It's a bit suicidal, but oh well. Oh yeah and JG> > I'll also start using bitkeeper due to the recent clarifications on t= he JG> > license of its usage. JG> JG> Great! While I think BitKeeper is useful, you are more than welcome to JG> continue sending patches. JG> JG> To wireless developers, BitKeeper will mainly be of use in sync'ing with JG> the latest wireless-2.6 tree. JG> JG> JG> > I'll willing to review as much patches as I have to and also hopefully JG> > write documentation on writing new wireless drivers. That said, if I can JG> > be of any assistance, where what you like me to start on? JG> > JG> > Here's what's on my agenda so far: JG> > JG> > * Help cleanup new ralink driver, start using ieee802211 and get into wireless-2.6. JG> > * Push prism54's new WPA and WDS support into wireless-2.6 JG> > * Start seeing what I can use off of ieee80211 for prism54, clean it, JG> > and move to wireless-2.6 JG> > * Start incorporating WPA through wpa_supplicant onto as many drivers JG> > * Start standardizing all things a bit, as bitched about and well pointed out JG> > by Dan Williams JG> > * Listen to Jouni, he's the man JG> JG> Well, all this sounds good to me. See also the 'status' post I just JG> made, and the 'note on wireless development process' I am about to writ= e. JG> JG> I'm really hoping someone will look into integrating wireless 802.11 as JG> a "real" protocol, rather than faking ethernet. This work starts with JG> the "p80211" template DaveM provided, and hopefully continues with JG> Vladimir's updates of DaveM's code (did he post those anywhere?). There JG> are also issues such as ARP types that Dan Williams mentioned to me as JG> issues. JG> JG> The "integrate wireless into net stack" work requires a very JG> self-motivated person who is willing to poke into the net stack, and JG> answer their own questions. JG> JG> Jeff JG> JG> JG> JG> JG> --nextPart9429505.gCS1A5zDSB Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.6 (GNU/Linux) iD8DBQBCQeiOqxdj7mhC6o0RAhwlAKCXVdrBJ+4GMl3wvY1I2VF8i7oHQgCfX2k7 YiFDk03gK3t8bRVOcbJwW5E= =kAfI -----END PGP SIGNATURE----- --nextPart9429505.gCS1A5zDSB-- From andy.furniss@dsl.pipex.com Wed Mar 23 14:46:35 2005 Received: with ECARTIS (v1.0.0; list netdev); Wed, 23 Mar 2005 14:46:39 -0800 (PST) Received: from galaxy.systems.pipex.net (galaxy.systems.pipex.net [62.241.162.31]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j2NMkYkV016862 for ; Wed, 23 Mar 2005 14:46:35 -0800 Received: from [192.168.0.3] (81-178-146-253.dsl.pipex.com [81.178.146.253]) by galaxy.systems.pipex.net (Postfix) with ESMTP id 375C6E000126; Wed, 23 Mar 2005 22:46:16 +0000 (GMT) Message-ID: <4241F1D2.9050202@dsl.pipex.com> Date: Wed, 23 Mar 2005 22:46:42 +0000 From: Andy Furniss User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.8b) Gecko/20050217 MIME-Version: 1.0 To: hadi@cyberus.ca Cc: Harald Welte , Patrick McHardy , Remus , netdev@oss.sgi.com, Nguyen Dinh Nam , Andre Tomt , syrius.ml@no-log.org, Damion de Soto Subject: Re: iptables breakage WAS(Re: dummy as IMQ replacement References: <1107123123.8021.80.camel@jzny.localdomain> <0fcf01c5077f$579e4b80$6e69690a@RIMAS> <1107174142.8021.121.camel@jzny.localdomain> <00c301c524b4$938cd240$6e69690a@RIMAS> <1110379135.1091.143.camel@jzny.localdomain> <1110416767.1111.76.camel@jzny.localdomain> <025501c52552$2dbf87c0$6e69690a@RIMAS> <1110453757.1108.87.camel@jzny.localdomain> <423B7BCB.10400@dsl.pipex.com> <1111410890.1092.195.camel@jzny.localdomain> <423F41AD.3010902@dsl.pipex.com> <1111444869.1072.51.camel@jzny.localdomain> <423F71C2.8040802@dsl.pipex.com> <1111462263.1109.6.camel@jzny.localdomain> <42408998.5000202@dsl.pipex.com> <1111550254.1089.21.camel@jzny.localdomain> <4241C478.5030309@dsl.pipex.com> <1111607112.1072.48.camel@jzny.localdomain> <4241D764.2030306@dsl.pipex.com> <1111612042.1072.53.camel@jzny.localdomain> In-Reply-To: <1111612042.1072.53.camel@jzny.localdomain> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV 0.83/781/Wed Mar 23 03:58:42 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 611 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: andy.furniss@dsl.pipex.com Precedence: bulk X-list: netdev Content-Length: 557 Lines: 23 jamal wrote: > On Wed, 2005-03-23 at 15:53, Andy Furniss wrote: > > >>but I can now follow the action ipt MARK line with an action mirred .. >> >>and I just get the MARK error >> >>tablename: mangle hook: NF_IP_PRE_ROUTING >> target: MARK set 0x1 index 0 >>RTNETLINK answers: Invalid argument >>We have an error talking to the kernel >> >> > > > Ok, this is my worry - that it works when everything is compiled in > but not when as modules. > So when you rebuild compile everything in. Compiled everything in but it still doesn't work. Andy. From andy.furniss@dsl.pipex.com Wed Mar 23 15:12:47 2005 Received: with ECARTIS (v1.0.0; list netdev); Wed, 23 Mar 2005 15:12:53 -0800 (PST) Received: from astro.systems.pipex.net (astro.systems.pipex.net [62.241.163.6]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j2NNCkqk018100 for ; Wed, 23 Mar 2005 15:12:47 -0800 Received: from [192.168.0.3] (81-178-146-253.dsl.pipex.com [81.178.146.253]) by astro.systems.pipex.net (Postfix) with ESMTP id D66AFE0000B4; Wed, 23 Mar 2005 23:12:22 +0000 (GMT) Message-ID: <4241F7F0.2010403@dsl.pipex.com> Date: Wed, 23 Mar 2005 23:12:48 +0000 From: Andy Furniss User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.8b) Gecko/20050217 MIME-Version: 1.0 To: Andy Furniss CC: hadi@cyberus.ca, Harald Welte , Patrick McHardy , Remus , netdev@oss.sgi.com, Nguyen Dinh Nam , Andre Tomt , syrius.ml@no-log.org, Damion de Soto Subject: Re: iptables breakage WAS(Re: dummy as IMQ replacement References: <1107123123.8021.80.camel@jzny.localdomain> <0fcf01c5077f$579e4b80$6e69690a@RIMAS> <1107174142.8021.121.camel@jzny.localdomain> <00c301c524b4$938cd240$6e69690a@RIMAS> <1110379135.1091.143.camel@jzny.localdomain> <1110416767.1111.76.camel@jzny.localdomain> <025501c52552$2dbf87c0$6e69690a@RIMAS> <1110453757.1108.87.camel@jzny.localdomain> <423B7BCB.10400@dsl.pipex.com> <1111410890.1092.195.camel@jzny.localdomain> <423F41AD.3010902@dsl.pipex.com> <1111444869.1072.51.camel@jzny.localdomain> <423F71C2.8040802@dsl.pipex.com> <1111462263.1109.6.camel@jzny.localdomain> <42408998.5000202@dsl.pipex.com> <1111550254.1089.21.camel@jzny.localdomain> <4241C478.5030309@dsl.pipex.com> <1111607112.1072.48.camel@jzny.localdomain> <4241D764.2030306@dsl.pipex.com> <1111612042.1072.53.camel@jzny.localdomain> <4241F1D2.9050202@dsl.pipex.com> In-Reply-To: <4241F1D2.9050202@dsl.pipex.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV 0.83/781/Wed Mar 23 03:58:42 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 612 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: andy.furniss@dsl.pipex.com Precedence: bulk X-list: netdev Content-Length: 704 Lines: 34 Andy Furniss wrote: > jamal wrote: > >> On Wed, 2005-03-23 at 15:53, Andy Furniss wrote: >> >> >>> but I can now follow the action ipt MARK line with an action mirred .. >>> >>> and I just get the MARK error >>> >>> tablename: mangle hook: NF_IP_PRE_ROUTING >>> target: MARK set 0x1 index 0 >>> RTNETLINK answers: Invalid argument >>> We have an error talking to the kernel >>> >>> >> >> >> Ok, this is my worry - that it works when everything is compiled in >> but not when as modules. >> So when you rebuild compile everything in. > > > Compiled everything in but it still doesn't work. > > Andy. Noticed I get this in logs Mar 23 23:11:18 amd kernel: MARK: targinfosize 8 != 4 Andy. From jketreno@linux.intel.com Wed Mar 23 15:34:30 2005 Received: with ECARTIS (v1.0.0; list netdev); Wed, 23 Mar 2005 15:35:07 -0800 (PST) Received: from orsfmr005.jf.intel.com (fmr20.intel.com [134.134.136.19]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j2NNYSb1019255 for ; Wed, 23 Mar 2005 15:34:29 -0800 Received: from orsfmr101.jf.intel.com (orsfmr101.jf.intel.com [10.7.209.17]) by orsfmr005.jf.intel.com (8.12.10/8.12.10/d: major-outer.mc,v 1.1 2004/09/17 17:50:56 root Exp $) with ESMTP id j2NNYNaQ007354 for ; Wed, 23 Mar 2005 23:34:23 GMT Received: from [192.168.1.154] (hdlrvguser-163.hd.intel.com [10.127.52.182]) by orsfmr101.jf.intel.com (8.12.10/8.12.10/d: major-inner.mc,v 1.2 2004/09/17 18:05:01 root Exp $) with ESMTP id j2NNYEUk030834 for ; Wed, 23 Mar 2005 23:34:14 GMT Message-ID: <4241FC8D.40400@linux.intel.com> Date: Wed, 23 Mar 2005 17:32:29 -0600 From: James Ketrenos User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.5) Gecko/20050113 X-Accept-Language: en-us, en MIME-Version: 1.0 To: netdev@oss.sgi.com Subject: [PATCH] ipw2100 v1.1.0 X-Enigmail-Version: 0.89.6.0 X-Enigmail-Supports: pgp-inline, pgp-mime Content-Type: multipart/mixed; boundary="------------050204000700060403060604" X-Scanned-By: MIMEDefang 2.44 X-Virus-Scanned: ClamAV 0.83/781/Wed Mar 23 03:58:42 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 613 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: jketreno@linux.intel.com Precedence: bulk X-list: netdev Content-Length: 297144 Lines: 10312 This is a multi-part message in MIME format. --------------050204000700060403060604 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Ok, we recently pushed the latest version of the IPW2100 driver to a stable version. The last stable version was 1.0.0, which wasn't compatible with the latest ieee80211 subsystem currently in netdev-2.6. In addition to fixing to be compatible w/ the ieee80211 stack, 1.1.0 also includes quite a few fixes over what was in 1.0.0. Anyway, attached is the patch against netdev-2.6 (build tested w/ the tip of wireless-2.6) that adds ipw2100 1.1.0 to the tree. Please let me know your comments and feedback. I wasn't sure where to actually stick the driver's selection it in the Kconfig menu. Where its at now, it doesn't show up until you enable 'Generic IEEE 80211 subsystem', and then it shows up down under Wireless Lan entries. Any opposition to creating a Wireless Drivers under the Generic IEEE 80211 level and putting drivers using that stack into that location? In terms of the process used for validation on the ipw2100, our plan is to only push patches out for kernel mainline inclusion that have gone through internal regression testing. Kernel API migration changes aren't much of an issue, but any functionality changes or fixes would need to go into our development versions on SourceForge first before we would want them pushed into mainline (assuming we get this into netdev, and then pushed upstream...) I'll be sending an ipw2200-1.0.0 patch out soon. We also have some fixes for ieee80211 that have been incorporated into the latest development snapshots for the ipw2200 project that I'll send a patch out for. Thanks, James --------------050204000700060403060604 Content-Type: text/x-patch; name="netdev-2.6-ipw2100-1.1.0.patch" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="netdev-2.6-ipw2100-1.1.0.patch" diff -Nur --exclude=RCS --exclude=CVS --exclude=SCCS --exclude=BitKeeper --exclude=ChangeSet netdev-2.6/Documentation/networking/README.ipw2100 ipw2100-2.6/Documentation/networking/README.ipw2100 --- netdev-2.6/Documentation/networking/README.ipw2100 1969-12-31 18:00:00 -06:00 +++ ipw2100-2.6/Documentation/networking/README.ipw2100 2005-03-23 13:13:50 -06:00 @@ -0,0 +1,246 @@ + +=========================== +Intel(R) PRO/Wireless 2100 Network Connection Driver for Linux +README.ipw2100 + +March 14, 2005 + +=========================== +Index +--------------------------- +0. Introduction +1. Release 1.1.0 Current Features +2. Command Line Parameters +3. Sysfs Helper Files +4. Radio Kill Switch +5. Dynamic Firmware +6. Power Management +7. Support +8. License + + +=========================== +0. Introduction +------------ ----- ----- ---- --- -- - + +This document provides a brief overview of the features supported by the +IPW2100 driver project. The main project website, where the latest +development version of the driver can be found, is: + + http://ipw2100.sourceforge.net + +There you can find the not only the latest releases, but also information about +potential fixes and patches, as well as links to the development mailing list +for the driver project. + + +=========================== +1. Release 1.1.0 Current Supported Features +--------------------------- +- Managed (BSS) and Ad-Hoc (IBSS) +- WEP (shared key and open) +- Wireless Tools support +- 802.1x (tested with XSupplicant 1.0.1) + +Enabled (but not supported) features: +- Monitor/RFMon mode +- WPA/WPA2 + +The distinction between officially supported and enabled is a reflection +on the amount of validation and interoperability testing that has been +performed on a given feature. + + +=========================== +2. Command Line Parameters +--------------------------- + +If the driver is built as a module, the following optional parameters are used +by entering them on the command line with the modprobe command using this +syntax: + + modprobe ipw2100 [