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 n