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) +st