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 soc